[Ffmpeg-devel-irc] ffmpeg-devel.log.20150725

[burek]

[00:28:27 CEST] <jamrial> i seriously wonder what happened with libdcadec's developer
[00:28:33 CEST] <jamrial> it's been almost two months since he was last active
[00:28:38 CEST] <cone-609> ffmpeg 03Michael Niedermayer 07master:dee551bbd280: avcodec/dvdec: skip 3rd stage ac decoding when the headers indicates that the data is inconsistent
[00:30:10 CEST] <wm4> jamrial: all while he promised to make a release soon...?
[00:30:46 CEST] <jamrial> yeah, he was fixing some bugs and was about to tag a first release. he even added placeholder version defines and all
[00:33:03 CEST] <rcombs> isn't the standard procedure at this point to have everything you need for your own application finished, get bored, and abandon the project?
[00:33:58 CEST] <wm4> ffmpeg should adopt it by copying it into its source tree
[00:34:07 CEST] <wm4> (50% joking, 50% serious)
[00:35:19 CEST] <rcombs> it's already LGPL2.1+
[00:38:12 CEST] <jamrial> wm4: actually that'd be great
[00:38:40 CEST] <jamrial> lgpl, better than current ffdca
[00:39:12 CEST] <wm4> ffdca is gpl?
[00:40:10 CEST] <wm4> it's lgpl too
[00:40:54 CEST] <wm4> so I guess you mean libdcadec doesn't have a worse license
[00:40:55 CEST] <jamrial> i mean that it can easily be added to ffmpeg's tree to replace the current decoder
[00:41:03 CEST] <jamrial> yes
[00:41:24 CEST] <wm4> so we'd have 2 dca decoders
[00:43:39 CEST] <jamrial> keyword replace
[00:46:24 CEST] <wm4> but ffmpeg isn't goimg to delete these valuable speed optimizations in ffdca
[00:48:17 CEST] <jamrial> in exchange of getting actual lossless dca decoding and actual maintainable non-spaghetti code, why not?
[00:48:22 CEST] <jamrial> it's not like new asm couldn't be written
[00:58:06 CEST] <wm4> I'm not the one who you need to convince
[00:58:28 CEST] <wm4> I just firnly believe ffmpeg never deletes anything, not even useless code
[01:03:47 CEST] <jamrial> libmpcodecs was deleted in the end, right? so not always :p
[01:04:34 CEST] <cone-609> ffmpeg 03Michael Niedermayer 07n2.6.4:HEAD: avcodec/dvdec: skip 3rd stage ac decoding when the headers indicates that the data is inconsistent
[01:11:23 CEST] <wm4> it took only half a decade
[01:25:26 CEST] <philipl> wm4: send a patch. :-)
[01:38:24 CEST] <wm4> for libdcadec? we don't know about the author yet
[01:50:17 CEST] <philipl> wm4: an attempted fork can often provoke a lazy author into responding.
[02:42:32 CEST] <cone-609> ffmpeg 03Zhang Rui 07master:c0a4af408ee5: avformat/async: move more code into locked area in background thread
[02:42:33 CEST] <cone-609> ffmpeg 03Zhang Rui 07master:8a173351895e: avformat/async: wake up main thread before exit background thread
[05:23:37 CEST] <cone-609> ffmpeg 03Michael Niedermayer 07master:1909a9151cce: swscale/output: Fix "warning: assignment from incompatible pointer type"
[08:30:43 CEST] <nevcairiel> its not like the dcadec author slowly became less active, he just up and vanished one day
[08:30:52 CEST] <nevcairiel> at first i thought, maybe he went on vacation
[08:30:55 CEST] <nevcairiel> but two months is long
[09:19:44 CEST] <durandal_1707> you ....
[11:56:41 CEST] <durandal_1707> anybody working on subtitle support in lavfi?
[12:29:22 CEST] <durandal_1707> hmm I will add overlap option for acrossfade
[12:49:21 CEST] <rcombs> durandal_1707: *points vaguely in the direction of ubitux*
[13:07:20 CEST] <kierank> https://github.com/kaltura/platform-install-packages/issues/392
[13:07:31 CEST] <kierank> lots of linkedin stalking after this
[13:10:35 CEST] <durandal_1707> what they want?
[13:11:18 CEST] <kierank> they are not happy that I am telling them they are violating the gpl and distributing very expensive software with non-free ffmpeg
[13:12:44 CEST] <JEEB> lul
[13:13:01 CEST] <BBB> kierank: youre too nice
[13:13:07 CEST] <BBB> they should always be added to shame list by default
[13:13:10 CEST] <BBB> adding/removing takes seconds
[13:13:15 CEST] <BBB> talking to lawyers takes years
[13:13:43 CEST] <kierank> various VPs of whatever have been stalking me on linkedin as a result
[13:16:08 CEST] <durandal_1707> but we no longer have wall of shame just bug tracker
[13:16:19 CEST] <Compn> its all fun and games until some company sues for defamation and loss of revenue due to hall of shame
[13:16:29 CEST] <Compn> which is why i disabled the shame page
[13:17:34 CEST] <durandal_1707> what's point of bugs on tracker if they never get resolved?
[13:18:19 CEST] <Compn> libav removed it in 2014 it seems, https://lists.libav.org/pipermail/libav-commits/2014-September/015362.html
[13:18:19 CEST] <iive> Compn: huh?
[13:18:23 CEST] <durandal_1707> the ones with license violations
[13:18:59 CEST] <Compn> durandal_1707 : waiting for some volunteer to step up
[13:19:24 CEST] <Compn> to educate and fix companies problematic distribution
[13:19:39 CEST] <durandal_1707> you mean someone to sue them?
[13:20:42 CEST] <Compn> i find its easier to talk than to sue
[13:20:46 CEST] <Compn> iive : https://ffmpeg.org/shame.html
[13:20:52 CEST] <durandal_1707> such companies do not care
[13:22:00 CEST] <iive> Compn: oh, you mean that the page might not be up to date, and because of that it would be defamation.
[13:22:19 CEST] <iive> not that shaming is defamation.
[13:22:27 CEST] <Compn> yes, or maybe an entry was put there in error
[13:23:09 CEST] <Compn> or maybe its a valid entry, it still can take 10 years nonsense to move through courts. even with frivolous lawsuit (in usa anyway)
[13:24:33 CEST] <Compn> durandal_1707 : https://ffmpeg.org/pipermail/ffmpeg-devel/2014-July/160126.html
[13:24:42 CEST] <Compn> there were some that did
[13:27:32 CEST] <Compn> is that violating lgpl or fdk-aac though?
[13:28:14 CEST] <Compn> if they have lgpl source available, i would say they are only violating fdk-aac license ? 
[13:28:14 CEST] <kierank> lgpl
[13:28:36 CEST] <nevcairiel> the fdk-aac license is in general quite liberal
[13:28:40 CEST] <nevcairiel> its just not gpl compatible
[13:28:44 CEST] <kierank> they have --enable-gpl enabled Compn 
[13:29:09 CEST] <Compn> do they provide ffmpeg source y/n ?
[13:29:10 CEST] <nevcairiel> gpl and nonfree are exclusive though, so only one of them takes hold
[13:29:41 CEST] <kierank> then they build nonfree
[13:29:44 CEST] <kierank> and distribute
[13:30:19 CEST] <nevcairiel> they download official ffmpeg relesae sources from ffmpeg.org in their build script
[13:30:28 CEST] <Compn> see, if they provide ffmpeg source, i dont care how they compile it or what nonfree libs they use.
[13:30:39 CEST] <nevcairiel> so in a way, they provide sources =p
[13:30:43 CEST] Action: durandal_1707 waiting for s64 sample format
[13:30:45 CEST] <Compn> but i guess thats just me.
[13:31:38 CEST] <nevcairiel> kierank: do they actually distribute binaries, that github project reads like its meant for me to checkout, and it'll build a binary for me locally then
[13:31:43 CEST] <nevcairiel> which would be fine license wise
[13:31:56 CEST] <JEEB> I think they had repositories
[13:31:59 CEST] <kierank> it's the buildscripts presumably that they use in their commercial product too
[13:38:02 CEST] <nevcairiel> of course the lack of a decent aac encoder outside of fdk-aac screws with everyone
[13:38:39 CEST] <JEEB> thankfully a lot of stuff can start moving towards opus
[13:38:57 CEST] <nevcairiel> i was meaning to investigate that
[13:39:13 CEST] <JEEB> of course it would mean including an opus decoder in your app on mobile depending on the OS
[13:39:16 CEST] <nevcairiel> but since my streaming mostly targets android, i might need to ship libopus for compat
[13:39:31 CEST] <nevcairiel> luckily, ExoPlayer already did the integration recently :D
[13:39:38 CEST] <JEEB> :D
[13:40:09 CEST] <JEEB> yeah, it really depends on how much time it'd take to support opus in addition, because some apps just use the system API calls, and thus including a new decoder would mean quite a bit of code
[13:40:39 CEST] <nevcairiel> yeah we switched to ExoPlayer some time ago because the built-in mediaplayer is dumb as fuck for streaming, and even worse, behaves differently on every device
[13:40:49 CEST] <nevcairiel> so a player we can ship and therefor control is just brilliant
[13:41:21 CEST] <nevcairiel> and its format support grows every day, so yay
[13:54:04 CEST] <BBB> j-b: poke
[14:05:30 CEST] <wm4> * durandal_1707 waiting for s64 sample format <- I'd rather have a 24 bit sample format
[14:05:38 CEST] <wm4> since these are actually used and important
[14:05:50 CEST] <nevcairiel> i dont mind how it works today
[14:06:03 CEST] <nevcairiel> 24-bit values are just annoying to handle
[14:07:37 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:17cc35c76b92: avcodec/aactab: Fix rounding of elements in ff_aac_eld_window_512_fixed
[14:07:38 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:f267d553f76f: avcodec/aactab: Add ff_aac_eld_window_480_fixed
[14:08:50 CEST] <wm4> nevcairiel: so what they can just be converted to 32 bit if you really can't process them
[14:09:23 CEST] <nevcairiel> sure, extra 0s dont hurt the audio
[14:09:28 CEST] <nevcairiel> and if you want to handle it, you can
[14:26:05 CEST] <nardev> guys, i need somebody to write me commands for converting videos i'm prepared to pay that. it should be able to process feew different formats and convert videos to a few most popular formats.. nothing which would not work out of box in ffmpeg.. and maybe some tweaking about processor usage and quality but that second part is less important. Anyone interested?
[14:50:20 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:bbad3811cc86: avcodec/aacps: Fix ;;
[14:57:33 CEST] <durandal_1707> kierank: you were mentioning smptebars the other day..
[14:57:49 CEST] <kierank> yeah I need to take some photos of the scope at work
[15:07:16 CEST] <durandal_1707> you mean some values are out of range?
[15:25:00 CEST] <kierank> some of the colours are too weak
[15:25:05 CEST] <kierank> don't know why
[15:25:13 CEST] <kierank> because the numbers are from the spec
[15:28:24 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:38490e07247e: avcodec/dvdec: only attempt to conceal errors based on STA inconsistencies when error_concealment is set
[17:48:47 CEST] <cone-201> ffmpeg 03Ivan Uskov 07master:6d0123f40e2a: avcodec: Add QSV MPEG-2 video decoder.
[17:58:04 CEST] <durandal_1707> nlmeans is very good denoiser?
[18:07:52 CEST] <ubitux> durandal_1707: i started implementing it
[18:08:10 CEST] <ubitux> i'm sorry i havent made much progress lately
[18:09:00 CEST] <durandal_1707> nlmeans?
[18:09:06 CEST] <ubitux> yes
[18:09:45 CEST] <durandal_1707> there are already gpl implementations available...
[18:10:07 CEST] <ubitux> i like the way it works
[18:10:21 CEST] <ubitux> so i would like to implement it
[18:10:41 CEST] <durandal_1707> then go ahead
[18:11:00 CEST] <ubitux> sure, i'll go back to it as soon as i'm done with selectivecolor
[18:11:29 CEST] <ubitux> i'm trying to figure out the logic behind the black spining adjustment 
[18:11:29 CEST] <durandal_1707> there is also this nl filter from pnm on tracker
[18:12:40 CEST] <durandal_1707> I was planning to add simple subtitle support in lavfi with sshowinfo
[18:13:46 CEST] <ubitux> how are you going to do that without having subtitles structure in libavutil?
[18:14:18 CEST] <durandal_1707> why one would need that?
[18:14:18 CEST] <ubitux> mangled avcodec dependency all over?
[18:14:37 CEST] <ubitux> well, AVSubtitle structures are defined in libavcodec
[18:15:25 CEST] <durandal_1707> Can just move them?
[18:18:15 CEST] <ubitux> that's one solution
[18:18:34 CEST] <ubitux> but not that simple
[18:19:26 CEST] <ubitux> i think i had a patch submitted for that but i wasn't satisfied with it...
[18:21:01 CEST] <durandal_1707> people still use -deinterlace, I hope michaelni will remove it on next major bump
[18:22:16 CEST] <durandal_1707> ubitux: so how much % is selectivecolor complete?
[18:22:58 CEST] <ubitux> technically, it could be made upstreamable with just the addition of the doc
[18:23:09 CEST] <ubitux> but complete i don't know
[18:23:28 CEST] <ubitux> the last bit that needs work is to figure out the way the black spinning works
[18:24:03 CEST] <ubitux> i thought it was a simple addition to all the 3 other spinning parameters, but it seems it isn't
[18:24:24 CEST] <ubitux> i need to do more graph & shit, but i find PS a PITA to use
[18:26:36 CEST] <ubitux> so basically CMY adjustment seems to match PS implementation, but the K parameter is still kind of stronger or something
[18:27:01 CEST] <durandal_1707> graphs? what kind of graphs?
[18:27:45 CEST] <ubitux> graph of data i observe in photoshop while tweaking the filter parameters :p
[18:30:31 CEST] <durandal_1707> What about writting GUI for ffmpeg filtergraph creation in python?
[18:30:32 CEST] <ubitux> durandal_1707: shit like this http://ubitux.fr/pub/pics/_selectivecolor-data.png
[18:30:43 CEST] <ubitux> durandal_1707: would be nice.
[18:31:33 CEST] <ubitux> i'd love to see a GUI for ffmpeg filtergraph
[18:32:40 CEST] <ubitux> you could even make it web 
[18:32:55 CEST] <ubitux> to share your graphs online ;)
[18:44:41 CEST] <nardev> guys, i need somebody to write me commands for converting videos i'm prepared to pay that. it should be able to process feew different formats and convert videos to a few most popular formats.. nothing which would not work out of box in ffmpeg.. and maybe some tweaking about processor usage and quality but that second part is less important. Anyone interested?
[19:07:44 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:7ec5115409ed: avformat/nutenc: Omit AV_PKT_DATA_QUALITY_STATS when storing side data.
[19:15:13 CEST] <kierank> jamrial: I guess you didn't use avx 3-operand because it's float?
[19:17:57 CEST] <jamrial> the aacps patch? no, i just wanted to put all movas together and then the add/sub/mul intructions, rather than having them interleaved like x86inc generates when it converts 3 operand into 2 operand
[19:18:46 CEST] <jamrial> most of these are sse so they will be able to run on really old cpus, where order of instructions is more important
[20:02:31 CEST] <jamrial> huh, there's a qsv mpeg2 decoder committed to libav that's almost the same as ours but with a different author
[20:03:06 CEST] <jamrial> and neither says "based on work by" or such
[20:03:29 CEST] <BtbN> Is it possible that two people actualy wrote them independendly?
[20:06:01 CEST] <jamrial> could be
[20:06:49 CEST] <JEEB> looking at the base file they're seemingly quite different-looking. the timing is quite perfect though :P
[20:06:53 CEST] <jamrial> admitedly, libav's seems more complete now that i look them more closely
[20:06:55 CEST] <jamrial> yeah
[20:08:22 CEST] <jamrial> guess the name, avoptions and configure dependencies being the same gave me the impression they were more similar than they actually are
[20:10:08 CEST] <cone-201> ffmpeg 03Ivan Uskov 07master:fb57bc6c34b9: avcodec: Add QSV VC-1 video decoder.
[20:11:14 CEST] <BtbN> Now if only QSV was actualy a widely available package on distributions, ffmpeg would have quite decent and widely available hardware acceleration support.
[20:12:48 CEST] <BBB> nardev: you might have more success emailing the list, irc is very fleeting in nature so it might not work very well to ask here
[20:12:59 CEST] <BBB> (not sure I like the idea of everyone emailing ffmpeg-devel, but ohwell(
[20:14:05 CEST] <nardev> BBB, i already sent an email there thank you
[20:27:45 CEST] <kierank> ohthisoneagain
[20:27:46 CEST] <kierank> https://news.ycombinator.com/item?id=9948041
[20:28:42 CEST] <nevcairiel> hacking up the bsf even more for this silly qsv decoder seems so stupid
[20:28:45 CEST] <nevcairiel> but noone listens to me
[20:33:16 CEST] <wm4> that gentoo post lol
[20:33:25 CEST] <wm4> users really have no fucking clue and blame Libav for it
[20:33:29 CEST] <JEEB> yes
[20:33:46 CEST] <JEEB> I bet most of the "didn't serve my needs" people actually had an issue with the oldness of the packaged version
[20:33:48 CEST] <wm4> so gentoo packages old age libav -> it causes problems -> install a recent ffmpeg -> it works -> blame libav!
[20:34:06 CEST] <JEEB> same for debian-based systems where version 0.8 was there for a long time
[20:34:15 CEST] <wm4> oh and someone linked my new troll writeup
[20:34:25 CEST] <JEEB> and then they grabbed a static binary from one of the places linked @ #ffmpeg
[20:34:30 CEST] <JEEB> and suddenly shit worked
[20:35:09 CEST] <JEEB> thus=>libav rather than old libav was the issue (and we totally would've not had these issues with ffmpeg when gentoo/debian/whatever had to update the stuff it was packaging)
[20:35:15 CEST] <JEEB> but what can you do, really :D
[20:35:20 CEST] <JEEB> lolperception
[20:35:29 CEST] <JEEB> of course then there are actual things that are only in ffmpeg
[20:35:33 CEST] <JEEB> like the concat vf
[20:35:35 CEST] <JEEB> etc
[20:35:57 CEST] <wm4> yes, it does have some more features
[20:36:11 CEST] <wm4> and libav has some "bugs" ffmpeg doesn't have
[20:36:45 CEST] <wm4> (I'd claim many are issues with slightly broken or obscure files, where often a 1-line patch helps)
[20:37:21 CEST] <jamrial> wm4: only ffmpeg versions gentoo users can use without unmasking "unstable" releases are the "equivalent" to whatever libav version is also available
[20:37:44 CEST] <jamrial> so it's not like they replaced libav 0.8 for ffmpeg 2.6 and they magically got modern features
[20:38:09 CEST] <JEEB> yeah, with gentoo that is true. unless they happened to do those two things. you get around 1.0 of ffmpeg, right?
[20:38:15 CEST] <JEEB> for libav 9 or whatever it was
[20:38:32 CEST] <JEEB> but with debian it usually went so that the person grabbed a new static build
[20:38:41 CEST] <jamrial> 1.2 i think
[20:39:10 CEST] <BtbN> current stable is ffmpeg 2.6.3 and libav 11.3
[20:39:36 CEST] <JEEB> yeah, but there were a lot of birth pains
[20:39:42 CEST] <jamrial> yeah. it was 2.2 until recenty, and 1.2 before that
[20:39:52 CEST] <JEEB> due to packages that nobody wanted to update to newer APIs and all
[20:40:10 CEST] <jamrial> on libav side of things, 9 and 0.8 respectively
[20:40:11 CEST] <JEEB> I think I got one of the gentoo maintainers doing the work to ragequit a channel once when asking about these things (why is the thing so old)
[20:40:49 CEST] <JEEB> I know at least gentoo did a whole lot of work trying to update everything, even if the usage rate of that thing wasn't too high
[20:40:52 CEST] <JEEB> uhh
[20:40:56 CEST] <JEEB> I meant debian there
[20:41:03 CEST] <JEEB> although gentoo probably had some work to be done
[20:41:05 CEST] <jahnyarrow> hi - i saw the news item about needing a new host - do you still need this?
[20:41:05 CEST] <JEEB> as well
[20:41:28 CEST] <JEEB> jahnyarrow: join the mailing list discussion, I think various alternatives are still being discussed there
[21:57:33 CEST] <philipl> nevcairiel: Why aren't the qsv decoders done as proper hwaccels?
[21:57:50 CEST] <nevcairiel> because
[21:57:52 CEST] <philipl> What do the stub hwaccel entries with no methods even mean?
[21:58:02 CEST] <BtbN> because that would mean touching libva.
[21:58:09 CEST] <philipl> would it?
[21:58:13 CEST] <philipl> I guess so.
[21:58:20 CEST] <BtbN> at least on linux
[21:58:41 CEST] <philipl> __gb__ didn't answer when I asked if anyone from Intel would be adding new vaapi hwaccels for the missing formats
[21:58:51 CEST] <philipl> I suppose this QSV work is the answer.
[21:58:53 CEST] <nevcairiel> the main reason is that because ffmpeg.c and other lazy applications couldnt use it easily
[21:58:59 CEST] <nevcairiel> hwaccels require a tad bit of effort
[21:59:08 CEST] <nevcairiel> easier to provide dumb codec wrappers with reduced functionality
[21:59:10 CEST] <philipl> Yeah. Someone could write a vaapi adapter for ffmpeg.c
[21:59:18 CEST] <BtbN> i tried that already
[21:59:23 CEST] <philipl> Heh.
[21:59:26 CEST] <nevcairiel> we have vdpau and dxva2
[21:59:31 CEST] <nevcairiel> not sure why noone finished a vaapi thing
[21:59:33 CEST] <philipl> BtbN: brave but futile.
[21:59:36 CEST] <philipl> ?
[21:59:46 CEST] <BtbN> because libva is... libva
[22:00:00 CEST] <philipl> It's a special library.
[22:00:37 CEST] <BtbN> The fact alone that for propper, fast, read-back of the frames you need a large bunch of assembly...
[22:00:44 CEST] <BtbN> a simple memcpy from its uswc buffers will be dead slow
[22:00:56 CEST] <BtbN> not even fast enough for 30fps, just because of the copy
[22:01:00 CEST] <nevcairiel> someone was working on a patch for that
[22:01:03 CEST] <philipl> As for vdpau: The hevc fix has been made inside nvidia and will appear in another month or so, I think.
[22:01:25 CEST] <nevcairiel> but he made it hard on himself by making the function too generic
[22:01:29 CEST] <nevcairiel> so it never got finished =p
[22:01:30 CEST] <philipl> There was that Kodi announcement about the non-bullshit EGL way to use libva. Of course, that might not help with read-back
[22:01:41 CEST] <BtbN> nevcairiel, vlc already has such a function
[22:01:54 CEST] <nevcairiel> the vlc function is like 200% too complex
[22:02:09 CEST] <BtbN> For some reason vlc allways uses it instead of memcpy. According to my tests it's slower than a plain memcpy for normal memory though.
[22:03:31 CEST] <philipl> Speaking of ass-slow - we still need to work out why the nvenc sample app is so much faster than ffmpeg.
[22:05:31 CEST] <BtbN> I guess because of less copying the frames around
[22:05:34 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:e171309756cb: avutil/softfloat: Add a test for av_sincos_sf()
[22:05:46 CEST] <philipl> But which are the extra copies.
[22:06:11 CEST] <philipl> The sample app writes output frames straight to disk, so it skips a copy there, but when I modified the app to copy to a memory buffer first, it made no significant impact.
[22:06:17 CEST] <BtbN> Was it a fair comparison, yuv without the need to convert the format?
[22:06:32 CEST] <philipl> Yeah, I used the same raw yuv input and tried to normalise as much as possible
[22:06:50 CEST] <BtbN> and the sample was running in CUDA mode, not DirectX?
[22:06:59 CEST] <philipl> and we've got a step up because we use the yv12 input format and the sample app uses nv12 with conversion.
[22:07:04 CEST] <rcombs> I've had similar experiences experimenting with VAAPI encoding
[22:07:07 CEST] <philipl> This was all on linux, so cuda, yeah
[22:07:18 CEST] <BtbN> hmm
[22:07:31 CEST] <BtbN> There shouldn't be anything super inefficient in the ffmpeg encoder
[22:08:13 CEST] <philipl> There shouldn't be, but it ends up 2x slower in the fastest configurations
[22:08:33 CEST] <philipl> When you go all the way to the hardware limits (4k hevc), then the speeds are comparable, unsurprisingly
[22:10:38 CEST] <BtbN> strange
[22:11:19 CEST] <philipl> indeed.
[22:11:43 CEST] <philipl> I tried using gprof and oprofile at various times but I'm clearly not capable of getting anything useful out of them
[22:11:57 CEST] <BtbN> The sample app is using nvenc in some async mode if i remember right?
[22:12:54 CEST] <philipl> The docs say async mode isn't supported on linux.
[22:12:57 CEST] <philipl> but that might be a lie
[22:13:03 CEST] <BtbN> ah, right
[22:13:09 CEST] <BtbN> no, definitely not a lie
[22:13:13 CEST] <BtbN> it uses WinAPI stuff for that
[22:14:22 CEST] <philipl> Yeah, it does use it on windows but that's disabled when built on linux
[22:14:25 CEST] <philipl> so that doesn't explain it
[22:14:42 CEST] <BtbN> that would have been a good explanation though
[22:21:33 CEST] <wm4> <philipl> As for vdpau: The hevc fix has been made inside nvidia and will appear in another month or so, I think. <- oh nice
[22:21:43 CEST] <wm4> <philipl> There was that Kodi announcement about the non-bullshit EGL way to use libva. Of course, that might not help with read-back <- I didn't find any information about that
[22:21:50 CEST] <wm4> may as well not exist
[22:22:05 CEST] <philipl> wm4: Yep. I'm also nudging the nvidia guy towards exposing vp8/9 decode next.
[22:22:12 CEST] <BtbN> It's only usefull for directly rendering decoded stuff
[22:22:17 CEST] <BtbN> not for getting the decoded data
[22:22:52 CEST] <philipl> BtbN: People might start thinking vaapi was usable if they did that.
[22:23:46 CEST] <BtbN> Non-Dev people already think that, and praise intels great open source.
[22:23:51 CEST] <wm4> lol
[22:24:03 CEST] <wm4> I've had so many problems with vaapi
[22:24:15 CEST] <philipl> wm4: That's its job.
[22:24:16 CEST] <wm4> vdpau just works
[22:24:48 CEST] <BtbN> everything from nvidia just works. I don't care anymore that their drivers are closed source. They do what they are supposed to.
[22:25:03 CEST] <philipl> Yeah, working is a feature.
[22:25:42 CEST] <nevcairiel> linux, working is a feature
[22:26:51 CEST] <rcombs> anime, Working!! is a feature
[22:27:15 CEST] <philipl> anime: hardware-incompatible encoding is a feature. :-)
[22:35:29 CEST] <BtbN> philipl, the most notable difference i see is that the sample encoder does not start outputting before it runs out of buffers
[22:36:01 CEST] <BtbN> the ffmpeg encoder start as soon as possible
[22:36:24 CEST] <nevcairiel> introducing delay can help hardware substantially in performance
[22:36:30 CEST] <nevcairiel> as it increases parallelism
[22:37:34 CEST] <BtbN> When the bufferQueue does not have any available encode buffers anymore, it will output one frame from it, so it has a buffer available again.
[22:41:57 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:c105e0f077fb: avcodec/aacps_fixed_tablegen: change f_center to 64bit to avoid overflow
[22:44:33 CEST] <jamrial> philipl: h264 high10 profile anime encoding, also known as how to annoy mobile users
[22:48:12 CEST] <philipl> jamrial: pretty much.
[22:48:35 CEST] <philipl> BtbN: that's a good point. They do say that maximum performance requires filling the queue all the way
[22:48:39 CEST] <wm4> so, uh, does anyone happen to know anything about that new libav EGL interop?
[22:49:04 CEST] <BtbN> libav? libva?
[22:49:14 CEST] <philipl> wm4: No. The libva history doesn't call it out and the Kodi side didn't actually explain what was what.
[22:49:28 CEST] <philipl> I guess look at the relevant kodi dev branch for commits that look related
[22:50:55 CEST] <philipl> https://github.com/FernetMenta/xbmc/commits/EGL
[22:51:00 CEST] <wm4> BtbN: sorry, libva
[22:51:21 CEST] <wm4> github doesn't let you search the commit history
[22:51:28 CEST] <philipl> Probably starting from the change on 31st may
[22:51:39 CEST] <philipl> That is the EGl dev branch by the look of things
[22:52:04 CEST] <BtbN> Basicaly it lets you bind an libva output thing to an OpenGL texture
[22:52:16 CEST] <BtbN> so what vdpau has actual OpenGL extensions for
[22:52:52 CEST] <philipl> Yeah, I think so - except they did it through egl for whatever reason
[22:53:08 CEST] <BtbN> because they failed at doing it for GLX
[22:53:14 CEST] <BtbN> and intel only assigns developers to new stuff
[22:53:29 CEST] <philipl> Tried it once, didn't work, better write a wrapper.
[22:53:45 CEST] <BtbN> The GLX "interop" is a bad joke
[22:54:19 CEST] <philipl> wm4: so presumably, you can take the existing mpv egl support and wire it in relatively easily.
[22:54:30 CEST] <philipl> "relatively"
[22:54:55 CEST] <wm4> can't find it in the xbmc history
[22:55:02 CEST] <wm4> I don't see a branch either
[22:55:06 CEST] <philipl> https://github.com/FernetMenta/xbmc/commit/3588cddce89c50854f548981902f45c143d9f514
[22:55:26 CEST] <philipl> The first link I pasted is the history for the dev branch
[22:55:57 CEST] <wm4> oh
[22:56:00 CEST] <wm4> better
[22:56:05 CEST] <wm4> it's not in the main repo
[22:56:11 CEST] <philipl> right. not there yet.
[22:57:25 CEST] <wm4> this is what the xbmc git history looks like https://0x0.st/scS.png
[22:57:37 CEST] <philipl> hehe.
[22:58:20 CEST] <wm4> reminds me of early mplayer, except with github instead of cvs
[23:00:38 CEST] <philipl> So looks like the core of the change is in VAAPI.cpp in that diff
[23:00:43 CEST] <philipl> all the EGL image stuff
[23:02:28 CEST] <unknown23> hi, I am writing a demuxer for a new file format, in my "read_packet" function, I want to modify the underlying data a bit, so I really can't use "av_get_packet". how do I get my modified data to fit in "pkt"?
[23:05:39 CEST] <wm4> unknown23: there are various methods to create (or set) AVPackets
[23:06:22 CEST] <wm4> you could e.g. read the data from the file into memory, manipulate that, and then copy that to the AVPacket etc.
[23:06:41 CEST] <philipl> ubitux: Can you look at Niklesh's latest diff
[23:06:47 CEST] <unknown23> wm4, I see. searching for a suitable example then :)
[23:07:00 CEST] <philipl> ubitux: is it ok to use an ASS reset tag and not explicitly close style tags?
[23:07:43 CEST] <wm4> philipl: should be ok
[23:07:54 CEST] <wm4> maybe it's actually even better
[23:08:04 CEST] <wm4> because the user style could have some formatting set
[23:08:18 CEST] <wm4> (didn't look at the patch)
[23:09:10 CEST] <philipl> The patch is primarily adding support for font size overrides but he didn't want the reset block to get longer and longer by explicitly closing each separate part of the style.
[23:09:23 CEST] <ubitux> philipl: you don't need to "close" tags in ass between events; tags just replace current markup
[23:09:48 CEST] <ubitux> philipl: the reset will reset them all, is that what you want?
[23:10:13 CEST] <philipl> ubitux: I believe so. The movtext semantic is that you have a style entry which fully describes all text properties and it has a start/end cannot overlap with other entries
[23:10:21 CEST] <philipl> so when an entry ends, you should return to the default style
[23:10:36 CEST] <ubitux> doesn't that mean you start a new Dialogue?
[23:10:39 CEST] <philipl> When you make a partial change to a style, you still two fully described entries
[23:11:03 CEST] <philipl> Well, in movtext you have a single sample line and a set of entries that describe it
[23:11:19 CEST] <philipl> So if I want part of the line to be bold, then I have an entry with bold turned on that starts and ends appropriately
[23:11:39 CEST] <unknown23> wm4, https://www.ffmpeg.org/doxygen/2.7/group__lavc__packet.html doesn't seem to say which function can copy a buffer into a packet? any hints?
[23:12:05 CEST] <philipl> But as entries cannot overlap, each entry must fully describe all properties even if you don't change them at the same points.
[23:12:11 CEST] <philipl> I don't think this is equivalent to dialogues.
[23:12:28 CEST] <unknown23> just memcpy to pkt->buf?
[23:12:30 CEST] <wm4> unknown23: if you want to copy, use memcpy
[23:12:33 CEST] <wm4> yeah
[23:12:41 CEST] <wm4> except pkt->buf is something else
[23:12:42 CEST] <unknown23> ah ok ;) this is C after all :D
[23:12:44 CEST] <ubitux> philipl: ok ok; well i'll try to have a look later, i have to go now
[23:12:51 CEST] <philipl> ubitux: sure. Thanks.
[23:12:57 CEST] <ubitux> but using \r is probably fine
[23:13:07 CEST] <philipl> I think it's fine too.
[23:13:09 CEST] <ubitux> as long as it renders correctly with libass,.. ;)
[23:13:25 CEST] <philipl> I have been assuming he's been checking visually. :-)
[23:14:47 CEST] <wm4> does ffmpeg output valid ASS yet
[23:14:56 CEST] <wm4> instead of just ASS that only libass understands?
[23:15:05 CEST] <philipl> is there any other kind? :-)
[23:15:25 CEST] <wm4> philipl: I tried looking at that xmbc branch, but I have no idea what it does... maybe the VA interaction is still missing?
[23:15:49 CEST] <wm4> yes, ASS is "defined" by vsfilter
[23:16:47 CEST] <philipl> wm4: It looks like it's using eglCreateImageKHR and then using that with vaSyncSurface, roughly speaking
[23:17:18 CEST] <philipl> but I'm no egl or va expert.
[23:17:27 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:aa9d15d89bb4: qsvdec: avoid an infinite loop with no consumed data and no output
[23:17:28 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:ef2a85ac5321: Merge commit 'aa9d15d89bb4ee8a31607d3db1b8c5334eb88d2d'
[23:18:05 CEST] <wm4> ah
[23:18:51 CEST] <wm4> oh, the vaapi headers even have docs for this
[23:21:21 CEST] <philipl> where?
[23:21:41 CEST] <wm4> va.h
[23:21:45 CEST] <wm4> vaSyncSurface
[23:23:51 CEST] <philipl> Well, I hope it makes sense to you :-)
[23:25:38 CEST] <wm4> so apparently this works over VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME
[23:26:03 CEST] <philipl> Ah. PRIME shows its head
[23:26:07 CEST] <wm4> and then you need indeed to use eglCreateImageKHR to create a complicated mapping
[23:26:49 CEST] <philipl> I see it now.
[23:26:50 CEST] <philipl> Lovely
[23:29:31 CEST] <wm4> looks pretty annoying
[23:29:47 CEST] <philipl> But you couldn't expect any less
[23:29:48 CEST] <wm4> I hope the VA surfaces don't need to be pre-mapped on allocation or so
[23:30:13 CEST] <wm4> (that would be slightly annoying)
[23:30:35 CEST] <philipl> Well, if you have two ways to do something and one is more annoying...
[23:36:34 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commit/cbf3d34a9a67ad9900946a5b9a160d2122deb2d7
[23:36:54 CEST] <nevcairiel> does that actually make it faster?
[23:37:00 CEST] <BtbN> Not tested yet
[23:37:03 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:22522d9c2c69: qsvdec: fix a memleak of async_fifo
[23:37:04 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:c3413a712ac2: Merge commit '22522d9c2c69624fe4d81d61ee65a56610f22f1d'
[23:37:08 CEST] <BtbN> but it basicaly does what the nvenc samples do
[23:37:18 CEST] <BtbN> fill all buffers before starting to read frames
[23:37:18 CEST] <philipl> BtbN: will try it out
[23:37:28 CEST] <nevcairiel> i wouldnt be that surpised if it does, as you would be best advised to do the same thing when decoding
[23:37:30 CEST] <BtbN> Not tested yet _at all_
[23:37:37 CEST] <BtbN> i might have missed something and this breaks stuff
[23:38:04 CEST] <BtbN> Might be off by one for the check
[23:38:10 CEST] <nevcairiel> if you force the gpu to sync up while its still working, it might cut into performance, if you give it time to finish a few frames ahead, it might run faster
[23:38:29 CEST] <BtbN> i will put that behind an option though
[23:38:41 CEST] <BtbN> for some usecases the lower latency is more desireable than the enhanced speed
[23:38:53 CEST] <nevcairiel> but should make the fast mode the default
[23:38:57 CEST] <BtbN> yes
[23:41:32 CEST] <philipl> BtbN: big big speed up
[23:41:34 CEST] <wm4> btw. would you agree that for a frame pool (feeding get_buffer2), software decoding would best return the most recently used frame (for better cache use), while hardware decoding would return the oldest frame (to avoid any form of async still-in-use effects)?
[23:42:44 CEST] <BtbN> Also found something else while digging through stuff
[23:43:34 CEST] <BtbN> unrelated, but weird
[23:43:42 CEST] <philipl> oh yeah?
[23:44:10 CEST] <cone-201> ffmpeg 03Timo Rothenpieler 07master:15cd2f8ea9f6: avcodec/nvenc: Remove unused parameter
[23:44:21 CEST] <BtbN> that
[23:45:01 CEST] <philipl> I saw that warning.
[23:45:13 CEST] <philipl> huh
[23:46:07 CEST] <BtbN> the function accesses coded_frame through avctx itself
[23:46:12 CEST] <BtbN> the parameter has allways been unused
[23:47:09 CEST] <philipl> BtbN: for a dvd encode. 390 vs 1000 fps
[23:47:15 CEST] <BtbN> what, wow
[23:48:13 CEST] <nevcairiel> well thats that then
[23:48:42 CEST] <cone-201> ffmpeg 03Anton Khirnov 07master:fa85fcf2b7d1: qsvenc_hevc: fix enum declaration
[23:48:43 CEST] <cone-201> ffmpeg 03Michael Niedermayer 07master:af08d8bfbbed: Merge commit 'fa85fcf2b7d1ab822a59245077b8bb855406d3e9'
[23:50:07 CEST] <BtbN> philipl, try increasing the 48 to 64 or even more, in line 693
[23:50:19 CEST] <BtbN> The 48 is a bit out of date
[23:50:29 CEST] <nevcairiel> doubt that'll help with speed much
[23:50:32 CEST] <BtbN> at least for maxwell cards with tons of ram
[23:50:41 CEST] <nevcairiel> you probably only need ~10 or so for max speed
[23:51:32 CEST] <BtbN> hm, could make it an int parameter for the amount of wait frames
[23:51:42 CEST] <BtbN> so users can tune as they like
[23:51:46 CEST] <nevcairiel> screw that
[23:52:16 CEST] <BtbN> would be easier than a bool, most users would only ever set it from default to 0
[23:58:37 CEST] <philipl> BtbN: 4k h264 is now comfortably above 60fps
[23:58:47 CEST] <philipl> hevc is still in the 50s. That's the hardware - can't do it
[23:58:59 CEST] <philipl> the 48 -> 64 didn't do anything
[23:59:20 CEST] <BtbN> ok, not going to touch that then
[23:59:39 CEST] <BtbN> Interesting though, i expected something more convoluted
[23:59:58 CEST] <philipl> We're owed something simple once in a while.
[00:00:00 CEST] --- Sun Jul 26 2015