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

[burek]

[00:02:42 CEST] <jamrial> please do it, then. no one else is reviewing it so i want to push it if it's robust enough
[00:02:49 CEST] <jamrial> there's a link to samples in the patchset thread
[00:03:10 CEST] <kierank> I need a way to apply the patchset though
[00:03:39 CEST] <jamrial> only the last patch, [PATCH v2 0/3] DTS Express (LBR) decoder
[00:03:44 CEST] <jamrial> the rest have been applied already
[00:04:12 CEST] <kierank> yeah but I can't actually apply the patch
[00:04:13 CEST] <michaelni> Daemon404, wmv-intrax8 fails: http://fatebeta.ffmpeg.org/report/x86_64-archlinux-gcc-experimental/20160507215840#failed_tests
[00:04:13 CEST] <jamrial> err, 3/3
[00:04:17 CEST] <kierank> i need it as an mbox
[00:04:32 CEST] <michaelni> Daemon404, also is it intended to have 2 tests
[00:04:43 CEST] <michaelni> tests/fate/microsoft.mak:fate-wmv8-x8intra: CMD = framecrc -flags +bitexact -idct 19 -i $(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv
[00:04:53 CEST] <michaelni> tests/fate/microsoft.mak:fate-wmv8-intrax8: CMD = framecrc -flags +bitexact -i $(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv -an
[00:05:02 CEST] <michaelni> using the same sample
[00:08:45 CEST] <Daemon404> michaelni, fate ran fine here, oddly
[00:09:08 CEST] <Daemon404> i have a vague memory of that test existing in the past and being removed
[00:09:15 CEST] <Daemon404> you dont happen to remember details do you
[00:11:38 CEST] <Daemon404> hmmm mayeb related to idct 19?
[00:11:40 CEST] <Daemon404> what does that do
[00:11:52 CEST] <Daemon404> the 2nd test can probably be removed
[00:13:00 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/commit/2169f971ad9b582cc3f1e6a1430aad44d64495d3
[00:13:14 CEST] <Daemon404> well ok
[00:13:21 CEST] <Daemon404> vague, but it confirms my memory
[00:15:21 CEST] <Daemon404> interestingly it does not fail on any of libav's fate machines that i can see
[00:19:44 CEST] <jamrial> kierank: https://github.com/jamrial/FFmpeg/commits/lbr
[00:20:08 CEST] <kierank> thanks
[00:20:10 CEST] <BtbN> I wonder if they enhanced nvenc with pascal.
[00:21:02 CEST] <jamrial> hevc 10 bit encoding, maybe? or was that already available in maxwell?
[00:21:39 CEST] <nevcairiel> wonder if vp9 10-bit decoding appears
[00:21:48 CEST] <nevcairiel> but possibly not, the media chip from the 960 is still relatively new
[00:22:03 CEST] <BtbN> I don't think there's any 10bit stuff in nvenc yet.
[00:32:54 CEST] <kierank> jamrial: running, expect results tomorrow
[00:48:44 CEST] <jamrial> kierank: ok, thanks
[00:51:37 CEST] <jamrial> kierank: are you forcing the use of the dts demuxer so the fuzzing doesn't make probe fail?
[00:51:41 CEST] <jamrial> the probe function in lavf even does an unconditional crc check
[00:52:23 CEST] <nevcairiel> the decoder checks the crc as well, so that might prevent fuzzing properly
[00:52:54 CEST] <jamrial> but only if crc check is requested
[00:53:02 CEST] <nevcairiel> is that not default for audio?
[00:53:11 CEST] <kierank> using fffuzz, not ffmpeg.c
[00:54:59 CEST] <kierank> perf top shows it decoding
[00:58:14 CEST] <jamrial> nevcairiel: doesn't look like
[02:25:59 CEST] <cone-749> ffmpeg 03Michael Niedermayer 07master:caee88d193fe: fate: Remove duplicate wmv8_x8intra.wmv test
[02:41:56 CEST] <BBB> michaelni: is the dithering patch in vf_colorspace ok with you now?
[02:56:46 CEST] <michaelni> BBB, yes, sure
[11:33:06 CEST] <wm4> I'd rather just drop SDL...
[11:36:55 CEST] <ubitux> i think that's the plan?
[11:36:56 CEST] <nevcairiel> that wmv8_x8intra test asks for idct 19, but we dont have an idct 19
[11:37:02 CEST] <nevcairiel> could that result in it breaking everywhere?
[12:19:16 CEST] <Daemon404> nevcairiel, possibly
[12:21:59 CEST] <BugMaster> Can anybody look at this fix for h264: http://pastebin.com/3KRE17ED ? and submit it to mailing list if this is needed
[12:25:53 CEST] <wm4> which configure options do I need again to get debuggable libavcodec?
[12:31:07 CEST] <ubitux> --disable-stripping
[12:31:13 CEST] <ubitux> --enable-debug
[12:31:23 CEST] <wm4> --enable-debug is the default
[12:31:33 CEST] <ubitux> then only --disable-stripping
[12:31:35 CEST] <wm4> I have --disable-stripping and --disable-optimizations
[12:31:41 CEST] <wm4> but the debugger still gives me shit
[13:57:25 CEST] <Compn> wm4 : only use ffmpeg_g binary after that, too
[13:59:26 CEST] <wm4> I'm not using ffmpeg
[14:02:20 CEST] <nevcairiel> if you want a fully un-optimized build you need to use --optflags=-O0 or -Od, but it may explode DCE depending on your compiler (hence why disable optimizations doesnt do that afaik)
[14:02:48 CEST] <nevcairiel> disable optimizations just doesnt set any optflags by default, leaveing the compiler to its defaults
[15:19:26 CEST] <kierank> I find it hard to believe dts-lbr has no fuzz crashes but it appears so
[15:24:44 CEST] <wm4> someone wrote bug-free code???
[15:26:51 CEST] <kierank> the bitstream might well be resilient
[15:27:08 CEST] <kierank> probably because of checked bitstream reading
[15:28:33 CEST] <kierank> then again the files I've got are very large
[15:28:38 CEST] <kierank> for fuzzing
[15:39:43 CEST] <Daemon404> is that foo86's thing?
[15:39:47 CEST] <Daemon404> he consistently writes very good code.
[15:46:59 CEST] <durandal_17> michaelni: say one do multithread audio decoder, which depends on state of previous decoded frame, who to handle this?
[15:47:49 CEST] <durandal_17> i added init_thread_copy and update_thread_context and ff_thread_report_progress
[15:48:31 CEST] Action: Daemon404 pokes jkqxz 
[15:49:01 CEST] <durandal_17> but i fail to understand how to update frames i use in ff_thread_await/report_progress
[16:06:26 CEST] <kierank> Daemon404: yes
[16:18:41 CEST] <michaelni> durandal_17, if for example this is about a normal IMDCT based decoder, each decode_frame() could do bitstream decode of the current frame and then imdct and overlap of this and the previous, the overlap would have to wait for the previous frames imdct
[16:20:14 CEST] <durandal_17> michaelni: yes, but this is about audio, it decompress dsd, and dsd to pcm depends on state of previous frame
[16:21:49 CEST] <durandal_17> decompresssing dsd is very slow ~5x
[16:22:06 CEST] <durandal_17> with 4 threads it goes up to ~13x
[16:22:18 CEST] <durandal_17> but output is not same as for single thread
[16:22:58 CEST] <durandal_17> because I do not sync state between threads properly
[16:25:41 CEST] <durandal_17> and dsd bitstream output does not depends on prev frames
[16:30:10 CEST] <michaelni> isnt dsd just doing a lowpass?, that shuldnt be that slow, lookups should be replaced by multiply and SIMD
[16:30:21 CEST] <michaelni> also indexing in inner loop looks bad
[16:30:29 CEST] <nevcairiel> Could slice thread dsd on a per channel basis
[16:30:55 CEST] <michaelni> buf[(pos                   - i) & FIFOMASK]; can be changed to use 2x as large buffer and simple indexing
[16:30:59 CEST] <michaelni> nevcairiel, yes, that too
[16:31:16 CEST] <durandal_17> michaelni: i'm not doing dsd to pcm, i doing dst->dsd->pcm, dst->dsd needs to be mt
[16:31:20 CEST] <nevcairiel> Channels are independent of each other, just the same channel requires history
[17:25:14 CEST] <durandal_1707> michaelni: see dst decoder on ml, looking to adr mt support
[17:35:37 CEST] <jkqxz> Daemon404:  Pong.
[17:35:49 CEST] <Daemon404> jkqxz, next up for merges is a bunch of patches form you
[17:35:57 CEST] <Daemon404> you mentioned some stuff abotu them but i forget
[17:36:19 CEST] <Daemon404> 4 lavc patches, one to avconv, and one fix after that i will squash in
[17:36:33 CEST] <Daemon404> any i should skip / need attention?
[17:40:14 CEST] <jkqxz> Should be ok.  If the avconv one causes trouble then I can look at it; the others will be fine because they just add new stuff.
[17:40:25 CEST] <Daemon404> cool ok
[17:41:48 CEST] <jkqxz> Uh, you didn't merge the vaapi decode fix with the H.264 NAL unit one.
[17:41:56 CEST] <Daemon404> ?
[17:42:05 CEST] <jkqxz> Sorry, I should have looked at that earlier.
[17:42:16 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=b3051a460cf02a5b86ff0d1e14abba23ea55ff6d
[17:42:19 CEST] <Daemon404> this?
[17:42:34 CEST] <Daemon404> apologies if i forgot
[17:43:12 CEST] <jkqxz> Yeah.  That one needed to go with ca2f19b; the tree is currently broken.
[17:44:06 CEST] <Daemon404> lemme cherry pick it and push
[17:44:37 CEST] <Daemon404> sidenote: merging hw stuff is hard, since i dont actually have a way to test like 80% of them
[17:44:48 CEST] <Daemon404> and there are no fate instances i think
[17:45:22 CEST] <jkqxz> Yeah, I realise it's annoying.  If you point me at any intermediate I'm happy to test it for you.
[17:45:35 CEST] <Daemon404> oh good it cherry-picks cleanly
[17:45:37 CEST] <Daemon404> no conflicts
[17:46:20 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:617cd45ddc9b: vaapi_h264: Fix bit offset of slice data.
[17:46:21 CEST] <Daemon404> ^
[17:46:26 CEST] <jamrial> it's not that you forgot, it's just that you didn't get to that point in the merge queue
[17:46:29 CEST] <Daemon404> indeed
[17:47:07 CEST] <nevcairiel> i should probabvly just push a fix for that in dxva2 as well
[17:47:40 CEST] <wm4> hm didn't you say this didn't matter for dxva, or did I just dream this?
[17:48:30 CEST] <jkqxz> My fault; I tried to point it out earlier, but I didn't chase it enough to pull it forward to the point where it broke.  Thanks for fixing it now.
[17:48:50 CEST] <cone-142> ffmpeg 03Hendrik Leppkes 07master:64fd62d68abe: avcodec/dxva2_h264: fix slice offset in long slice struct after ca2f19b9
[17:51:31 CEST] <nevcairiel> it doesnt matter for most dxva2 devices, but in a month or so some user with some old-ass intel gpu shows up again and complains, so i rather fix it now =p
[17:52:13 CEST] <nevcairiel> (note that vaapi and dxva2 use a different reference point, so the lines are not exactly equal, dxva starts counting at the RBSP, and vaapi from the full NAL)
[18:28:05 CEST] <kurosu_> btw, as people are speaking of merges, the new bitstream api will be a pain, eg aac
[18:33:41 CEST] <wm4> kurosu_: it's not even in Libav yet
[18:34:23 CEST] <kierank> bitstream reader api?
[18:43:32 CEST] <kurosu_> kierank, yes
[18:43:51 CEST] <kurosu_> wm4, yeah and? it will be, that's not a problem
[18:44:38 CEST] <nevcairiel> cant be any worse than what we have merged before
[18:45:47 CEST] <kurosu_> and it's probably worth it
[18:45:59 CEST] <kurosu_> just that it is yet another amount of work
[18:46:36 CEST] <kurosu_> I'm wondering if it can't just be merged by keeping the get_bits API but just replacing its implementation
[18:46:52 CEST] <kurosu_> unlike you guys prefer seeing the new function names and macros over the old ones
[18:46:57 CEST] <kurosu_> *unless
[18:47:22 CEST] <wm4> separating those two changes would probably have been a good idea
[18:47:49 CEST] <kurosu_> on the other hand, the difference would spiral further away - making later merges even harder
[18:47:57 CEST] <nevcairiel> I dont understand their mentality of change is great in that regard, like "we work on it anyway, so might as well make it as complex as possible"
[18:48:14 CEST] <nevcairiel> it just makes no sense to me
[18:48:38 CEST] <kurosu_> I think they just see it as their hobby, friend-made project and no longer care about overall benefit to users
[18:49:03 CEST] <kurosu_> my feelings, not my discussions with them or anything
[18:49:32 CEST] <nevcairiel> their active user base sure isnt very huge anymore, who really ships libav binaries these days?
[18:50:46 CEST] <kurosu_> I meant: I think they no longer really care about userbase (otherwise the projects would have merged back, anyway) or the like
[18:53:23 CEST] <iive> it's not like they have ever cared about users
[18:53:47 CEST] <kurosu_> I probably did a really bad job of getting my points across and instead just made them ignore me, but I feel my reviews were not exactly considered
[18:53:58 CEST] <kurosu_> iive, that kind of sentence is not helping either
[18:54:06 CEST] <kurosu_> antagonizing them is not helping
[18:54:52 CEST] <iive> well, imho it is better to stop merging libav
[18:54:58 CEST] <kierank> they are literally throwing out the baby with the bathwater by changing all the weird names
[18:55:20 CEST] <kurosu_> the real issue is that it requires more and more efforts, but there is really good stuff in their work
[18:55:42 CEST] <kurosu_> maybe a lot of stuff is useless, but you need that too for easier merges
[18:55:43 CEST] <jamrial> kurosu_: could be that considering your points would mean extra work and/or rewriting some parts, and they don't want to
[18:56:31 CEST] <kurosu_> and maybe they consider it was in bad faith, just to make them waste their time
[18:57:11 CEST] <iive> libav people have never been good in separating personal insults from pointing technical shortcomings
[18:57:17 CEST] <kurosu_> https://lwn.net/Articles/659214/
[18:57:25 CEST] <kurosu_> "And every time that happens, somebody does some silly mistake, and the conversion patch to the improved interface actually makes things worse. Because the patch is mindnumbing and trivial, nobody has the attention span to look at it carefully, and it's usually done over large swatches of source code which means that not every conversion gets tested."
[18:57:38 CEST] <jamrial> iive: that also applies to certain people from this project
[18:57:43 CEST] <wm4> iive: neither have you
[18:57:44 CEST] <iive> kurosu_: i'm quite sure the fault is not in you.
[19:00:00 CEST] <iive> wm4: ?
[19:00:14 CEST] <kurosu_> it's not really the point, more that the situation hasn't improved, and partially because of me
[19:01:01 CEST] <iive> kurosu_: well, maybe i should have warned you. You might have better chance of getting your point, if they don't know that you are working on ffmpeg project.
[19:01:17 CEST] <kurosu_> that's dishonest
[19:01:38 CEST] <kurosu_> and could have ended actually way worse
[19:01:43 CEST] <iive> did you introduce yourself as ffmpeg developer?
[19:02:47 CEST] <kurosu_> nope, I have been for a long time developing on either side, just not for a long time on theirs, for lack of time
[19:02:48 CEST] <jamrial> he's has posted to libav-devel before. he didn't show up on that ml out of nowhere a week ago
[19:02:50 CEST] <iive> well, it's muphy's law that things can always get worse :)
[19:03:34 CEST] <iive> hum... i'm quite sure he said he is not subscribed...
[19:03:42 CEST] <iive> or that was somebody else?
[19:04:49 CEST] <jamrial> kurosu_: in any case, i think one of the points you made was, according to one of libav's developers, only an issue if implemented in our tree. so that may have probably made your argument less valid in their eyes
[19:04:55 CEST] <kurosu_> no idea, but I suscribed in mars 2011
[19:05:07 CEST] <kurosu_> *march
[19:05:39 CEST] <iive> sorry, it really hasn't been you.
[19:05:40 CEST] <nevcairiel> they might want the vc2 stuff as well one day
[19:05:56 CEST] <iive> atomnuker also wanted to talk with them about the bistream api
[19:06:39 CEST] <kurosu_> jamrial, most likely, but I tried at first to be thoughtful by asking privately if it was ok referring to that code
[19:06:50 CEST] <kurosu_> external code has the large issue of being difficult to test
[19:07:11 CEST] <kurosu_> but I'd thought that at least it warranted a look as it meant something was not right
[19:07:21 CEST] <kurosu_> whatever
[19:07:52 CEST] <kurosu_> no point delving on this, it's a minor issue
[19:08:21 CEST] <nevcairiel> it certainly gives one the feeling of not caring much if an actual issue is brushed aside of "not in oru codebase", but shrug
[19:09:05 CEST] <jamrial> especially when, as you said, they may at some point want to port that affected piece of code
[19:09:56 CEST] <kurosu_> for the merge work, I started working on the most impacted (performance-wise, not code-wise) ones, precisely to verify their work
[19:09:59 CEST] <durandal_17> but here are people still wanting to merge every single libav commit whetever it is broken or not
[19:10:33 CEST] <kurosu_> I'm not sure I'll be around to help that effort, all the more since it's the old function names
[19:11:08 CEST] <kurosu_> durandal_17, hindsight is 10/10 - and it helps merging the more important stuff
[19:11:27 CEST] <kurosu_> but if it is obviously broken, sure
[19:11:53 CEST] <kurosu_> I think most people merging are already applying this rationale
[19:12:47 CEST] <iive> there will be a point where rewriting a change from scratch would be easier than trying to merge it.
[19:12:53 CEST] <jamrial> yeah, tons of merged commits are being no-oped for one reason or another
[19:13:10 CEST] <iive> and that point is closing in.
[19:13:11 CEST] <jamrial> usually because they don't apply or because they fix something that we already fixed before
[19:15:06 CEST] <wm4> <iive> there will be a point where rewriting a change from scratch would be easier than trying to merge it. <- you volunteer
[19:15:21 CEST] <jamrial> any hevc decoder change will probably not apply at all. afaik they commited the first openhevc dump years ago then didn't bother backporting anything else
[19:15:45 CEST] <nevcairiel> their is far behind in features as well, similar vp9
[19:18:23 CEST] <nevcairiel> when they ever want to get vp9 hwaccel they'll have to port months of changes, or re-implement it
[19:19:14 CEST] <kurosu_> their mc code could help clean up ours, but keeping the same support with the same code quality is an enormous amount of work, and nobody to sponsor it
[19:19:25 CEST] <kurosu_> *hevc mc
[19:20:04 CEST] <iive> motion compensation?
[19:20:35 CEST] <kurosu_> yes
[19:21:35 CEST] <kurosu_> http://forum.doom9.org/showthread.php?t=173465 <- meanwhile, a "Principal Video Specialist" at Amazon is complaining that the s/w decoding solutions he wants to use (free ones, actually) are not good enough
[19:22:09 CEST] <kurosu_> s/good/fast
[19:22:58 CEST] <iive> wm4: let's say that i'm not interesting in working on ffmpeg, while it's internals and api's are decided by libav.
[19:23:31 CEST] <nevcairiel> lets say we're not interested in people that carry around grudges for years either, we already have too many of those
[19:24:48 CEST] <iive> ^_^
[19:26:05 CEST] <kierank> kurosu_: tough, amazon can spend hundreds of millions on gpl violating encoder manufacturers so clearly they can support OSS
[19:26:36 CEST] <kierank> send patches or send money
[19:26:52 CEST] <iive> nevcairiel: my decision is not matter of grudge. If I want to do API breaking changes, they could easily be rejected because "it would make merging stuff harder"
[19:27:29 CEST] <nevcairiel> if there is a good reason for a change i doubt anyone would block it on such reasons
[19:27:44 CEST] <durandal_17> iive: what api changes you want to make?
[19:30:31 CEST] <iive> durandal_17: e.g. getting rid of avcodec_register_all(), by making it into a static const table
[19:31:15 CEST] <nevcairiel> thats actually something coming from libav to some degree, it already happened for bsf's and protocols
[19:32:10 CEST] <iive> yeh, i had it years ago, but every codec touching was pain to merge
[19:33:10 CEST] <wm4> <iive> wm4: let's say that i'm not interesting in working on ffmpeg, while it's internals and api's are decided by libav. <- that's a passive-aggressive attitude that is supposed to say that Libav ruins ffmpeg development, and that implies you would actually work on ffmpeg if Libav died, which is not the case
[19:34:02 CEST] <kierank> i'd recommend you all put iive on ignore like I have for the past few years
[19:34:52 CEST] <jamrial> can we have a drama free sunday?
[19:36:29 CEST] <iive> wm4: and how do you know this is not the case?
[19:38:29 CEST] <durandal_17> non active devs should be demoted and they should give commit rights back - every sane project does this
[19:39:11 CEST] <jamrial> "Actually, even the H.264 decoder wasn't making any progress in the last few years, IIRC. I think it has actually gotten slower, because the guys (in this case, it's mostly libav I think) kept reformatting and rewriting the code repeatedly for cosmetics/readability/maintainability/etc purposes"
[19:39:11 CEST] <iive> durandal_17: i don't have commit rights at the moment. if that is your concern.
[19:39:21 CEST] <iive> if I go back, I'll start by sending patches.
[19:39:22 CEST] <jamrial> from kurosu_'s link. how true is that?
[19:40:18 CEST] <jamrial> i remember a merge had like 2% performance hit but it was undone in our tree after michaelni pointed it out
[19:40:22 CEST] <durandal_17> well you can try old one and last one and compare....
[19:41:54 CEST] <durandal_17> ultimate goal of every maintainer is to rewrite code from scratch, and than start all over again
[19:42:24 CEST] <jamrial> lol
[19:42:29 CEST] <kurosu_> jamrial, those are mostly users, probably a lot of hearsay
[19:51:38 CEST] <durandal_17> some rscc and screenpreso codec changes are still not merged
[19:54:45 CEST] <durandal_17> do those mpegvideo dependency removals help with speed?
[20:10:54 CEST] <cone-142> ffmpeg 03Rostislav Pehlivanov 07master:b6c207f53581: vc2enc_dwt: use 32 bit coefficients by default
[20:16:39 CEST] <kurosu_> atomnuker, I think it'll be simpler for everyone if you just amend my fate vc2 commit with the correct checksums
[20:21:20 CEST] <atomnuker> kurosu_: ok, will do
[20:43:48 CEST] <cone-142> ffmpeg 03Michael Niedermayer 07master:5df703aa1b03: avcodec/simple_idct_template: Fix strict aliasing violation
[20:44:58 CEST] <nevcairiel> guess the test was good for something afterall
[20:46:33 CEST] <durandal_1707> Easyfab: report delogo bug to tracker?
[20:50:52 CEST] <cone-142> ffmpeg 03Christophe Gisquet 07master:01938585f4ce: vc2: fate tests
[20:57:32 CEST] <durandal_1707> michaelni: so do you have idea how to add mt to dst decoder?
[21:09:15 CEST] <jamrial> atomnuker: yuv420p vc2 is lossless?
[21:10:22 CEST] <atomnuker> if the bitrate is high enough it is lossless, yes
[21:14:04 CEST] <iive> is vc2 the next version of microsoft vc1?
[21:14:58 CEST] <JEEB> no
[21:15:15 CEST] <iive> audio codec?
[21:15:26 CEST] <JEEB> it's just the next in number line in that line of specifications
[21:15:29 CEST] <JEEB> it's dirac
[21:15:30 CEST] <iive> nah..
[21:15:45 CEST] <iive> aha
[21:18:22 CEST] <Easyfab> durandal_1707: I will do report tomorrow
[21:30:12 CEST] <michaelni> durandal_1707, you know DST better than i do, so iam not sure how usefull my comments would be but assuming there are steps that can be run in parallel and ones that cant, the ones that cant need ff_thread_await/report_progress, also any setup data one thread sets that the next needs in its context must be before ff_thread_finish_setup()
[21:34:23 CEST] <durandal_1707> michaelni: how to share frame that we use for await/report progress
[21:35:09 CEST] <durandal_1707> obviously second frame depends on first one
[21:37:29 CEST] <michaelni> hmm alloc frame before finish setup then ref it in update of next thread should work
[21:39:14 CEST] <nevcairiel> the threading is unfortunately designed for the opposite direction, running the things that require context first and the things that run in parallel afterwards
[21:39:15 CEST] <michaelni> maybe libavcodec/mimic.c is a simple example but itts video not audio
[21:39:19 CEST] <nevcairiel> the dst decoding works the other way around
[21:39:42 CEST] <nevcairiel> where it can perform dst in parallel first and dsd decoding in sequence after
[21:41:51 CEST] <michaelni> the last step (DSD) is like the last row in video, it also needs the previous pictures last row potentially
[21:42:37 CEST] <nevcairiel> i suppose
[22:55:31 CEST] <Daemon404> jkqxz, just one line that didnt apply easily
[22:55:46 CEST] <Daemon404> http://pastie.org/10829616
[22:55:50 CEST] <Daemon404> it isnt obvious to me how to do that
[23:10:40 CEST] <Daemon404> hmmm...
[23:26:08 CEST] <Daemon404> think i got it
[23:40:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:5d273d3efac3: avconv: VAAPI hwcontext initialisation and hwaccel helper
[23:40:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:172d3568b38c: Merge commit '5d273d3efac340ef8de445c955ff44c7abed4e8f'
[23:41:30 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:104c804bcaac: lavc: VAAPI encode common infrastructure
[23:41:31 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:508957fd0fc3: Merge commit '104c804bcaac24b52eb51ed17df2fb311e6ae73e'
[23:44:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:2c62fcdf5d61: lavc: VAAPI H.264 encoder
[23:44:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:b975aeec02e4: Merge commit '2c62fcdf5d617791a653d7957d449f75569eede0'
[23:45:56 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:31fe1f2577f8: lavc: VAAPI H.265 encoder
[23:45:57 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:a82d1a8c7a4b: Merge commit '31fe1f2577f8208f79a4b3ab59465e78dd497555'
[23:47:06 CEST] <cone-142> ffmpeg 03Mark Thompson 07master:83f230c2445a: lavc: VAAPI MJPEG encoder
[23:47:07 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:939345854a9e: Merge commit '83f230c2445a94fdd94c66504482217fcece5909'
[23:51:46 CEST] <nevcairiel> Daemon404: btw a note about the upcoming matroskaenc patch, the field order element is not WebM compliant, so care needs to be taken to not write it then (the libav mkv muxer has no webm mode)
[23:51:47 CEST] <cone-142> ffmpeg 03Anton Khirnov 07master:69a638019fc0: avconv: fix -frames for video
[23:51:47 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:061dc20351bf: h264: Add missing ff_ prefix to internally visible h264_init_dequant_tables()
[23:51:48 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:3005ee372d47: Merge commit '69a638019fc0db4c2b75b36ef45d0acb6d2e9628'
[23:51:49 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:630586af882c: Merge commit '061dc20351bf3b8a237216d2b39d3a3b736d1916'
[23:51:59 CEST] <Daemon404> nevcairiel, isnt that just an if
[23:52:03 CEST] <Daemon404> if webmmode
[23:52:07 CEST] <nevcairiel> yes
[23:52:12 CEST] <nevcairiel> just saying it needs to be added :)
[23:52:15 CEST] <Daemon404> sure.
[23:54:04 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:bd016dbf23e8: Mark tables used only within their files as static
[23:54:04 CEST] <cone-142> ffmpeg 03Diego Biurrun 07master:44f05f15d4a3: build: Do not check the vaapi_encode.h header if VAAPI is not enabled
[23:54:06 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:4c3732c88173: Merge commit 'bd016dbf23e8e7dc34ff2696912575f7620cec0d'
[23:54:06 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f93c409c0b71: Merge commit '44f05f15d4a34ef2f0d62259e5d5b43371bc0954'
[23:56:38 CEST] <Daemon404> nevcairiel, am i reading this write or is this just a reading patch
[23:56:43 CEST] <Daemon404> no writing
[23:57:05 CEST] <nevcairiel> oh the writing one is a few later
[23:57:35 CEST] <Daemon404> yeah
[23:57:42 CEST] <Daemon404> i suppose it shouldnt be read either though
[23:57:48 CEST] <Daemon404> btw i dont see how to check for webm
[23:57:54 CEST] <nevcairiel> the demuxer is no special
[23:57:59 CEST] <nevcairiel> it only reads elements actually in the file
[23:57:59 CEST] <Daemon404> ah...
[23:58:02 CEST] <nevcairiel> nothing to do there
[23:58:03 CEST] <Daemon404> ok
[23:58:13 CEST] <nevcairiel> its binary xml, remember :)
[23:59:00 CEST] <Daemon404> D: yes
[23:59:23 CEST] <cone-142> ffmpeg 03Luca Barbato 07master:5f0226668124: matroska: Support interlaced content correctly
[23:59:24 CEST] <cone-142> ffmpeg 03Derek Buitenhuis 07master:f3972b3b7dfa: Merge commit '5f0226668124aa7ae4db501ba7f4ace4c770f3d1'
[00:00:00 CEST] --- Mon May  9 2016