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

Sat Nov 3 03:05:03 EET 2018

[00:51:38 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:acf4fbddf3fe: doc/APIchanges: Update for 4.1
[00:51:39 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:324d21164d49: Changelog: next is 4.1
[00:51:40 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:780d5e30a0a0: Bump minor versions for branching 4.1
[00:52:18 CET] <cone-124> ffmpeg 03Michael Niedermayer 07release/4.1:HEAD: Bump minor versions for branching 4.1
[01:25:41 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:517573a67088: Bump minor version for master after 4.1 branchpoint
[01:25:42 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:e8ced83f68a7: Changelog: Add new version next tag
[01:25:43 CET] <cone-124> ffmpeg 03Michael Niedermayer 07master:f4dd2db91301: RELEASE: bump to 4.1.git
[02:44:07 CET] <cone-124> ffmpeg 03Michael Niedermayer 07release/4.1:3c7e97343065: Update for 4.1
[02:44:08 CET] <cone-124> ffmpeg 03Michael Niedermayer 07release/4.1:1665ac6a4461: RELEASE_NOTES: Based on the version from 4.0
[02:56:44 CET] <cone-124> ffmpeg 03James Almer 07master:2d2af23349ca: avformat/ivfenc: use the av1_metadata bsf to insert Temporal Delimiter OBUs if needed
[02:58:09 CET] <cone-124> ffmpeg 03kjeyapal at akamai.com 07master:d6d407d2d758: avformat/dashenc: Disable writing CODECS tag for HEVC streams
[04:09:17 CET] <philipl> BtbN: I have posted an updated patchset, mostly just in case michaelni wanted to see it after updates.
[09:34:10 CET] <cone-122> ffmpeg 03Paul B Mahol 07master:97e9e3504d36: avfilter: add tpad filter
[09:40:35 CET] <BradleyS> :)
[11:26:38 CET] <cone-122> ffmpeg 03Paul B Mahol 07master:4620e4c7ad2f: avfilter/f_loop: make sure duration of frame is never zero
[12:07:54 CET] <atomnuker> BBB: had the time to play with the code?
[12:16:50 CET] <BBB> atomnuker: not yet, finishing SGR first& one thing at a time
[12:17:04 CET] <BBB> av1 = big codec, takes some time to get to everything
[12:35:08 CET] <cone-122> ffmpeg 03Paul B Mahol 07master:ef1aadffc785: avfilter/f_loop: switch to activate
[14:50:22 CET] <atomnuker> BBB: did a minor update on the PR, using pand like you suggested
[14:50:42 CET] <atomnuker> are 3 argument instructions more expensive to encode than 2 argument versions?
[14:53:53 CET] <BBB> I dont think so
[14:54:05 CET] <BBB> 2-arg is automatically expanded into 3-arg when using vex encoding, no?
[14:54:14 CET] <BBB> at least thats what the lldb disassembly suggests
[14:58:08 CET] <atomnuker> also ALIGN() definitely does not work, none of the cdfs are actually aligned, mova segfaults
[15:04:38 CET] <BBB> is the cdf itself algined?
[15:05:05 CET] <BBB> hm& it should be
[15:05:06 CET] <BBB> it is a ref
[15:05:25 CET] <BBB> cdf.c:4051 is not though
[15:05:29 CET] <BBB> static CdfThreadContext cdf_init[4] = { ..
[15:05:35 CET] <BBB> that needs to be aligned also
[15:17:46 CET] <jamrial> it's complaining about seta on win32
[15:18:05 CET] <jamrial> probably x86_32 in general
[15:27:15 CET] <atomnuker> yeah, is 32 bit windows not able to use byte regs or something?
[15:27:43 CET] <BBB> 32bit? only a few regs have bye equivalents
[15:27:51 CET] <BBB> for 64bit I thought they all did
[15:27:55 CET] <BBB> but I dont recall exactly
[15:29:01 CET] <jamrial> also, it's still slower than what gcc compiles
[15:29:42 CET] <nevcairiel> A/B/C/D have byte regs
[15:30:09 CET] <BBB> Ill play around with this a bit when I have time
[15:30:29 CET] <BBB> it should be faster when you remove the extra calls
[15:30:33 CET] <nevcairiel> but that comes back to comment from yesterday, in x86inc.asm which register is behind which name varies between  platforms
[15:35:27 CET] <nevcairiel> although r2 or r3 should map to a register with a byte component on all platforms
[15:35:36 CET] <nevcairiel> if oyu can use one of those two
[15:45:34 CET] <BBB> if you use avx2, just make it 64bit only
[15:45:39 CET] <BBB> no reason to use avx2 on 32bit platforms
[15:45:50 CET] <BBB> lets move people off 32bit
[15:46:14 CET] <nevcairiel> you have more choices then for sure, but still like 4 legacy registers left that dont have one :D
[15:46:45 CET] <nevcairiel> or 3 really, since you  dont use the 4th
[15:48:00 CET] <atomnuker> I could do that I suppose but it'll cost 1 more vector reg
[15:57:28 CET] <Gramner> up to 6 vector regs it doesn't matter. e.g using two or six is all the same. above 6 becomes slower on win64, and above 8 becomes 64-bit only
[16:02:11 CET] <atomnuker> does that apply for all platforms?
[16:02:40 CET] <atomnuker> also does it apply to gprs
[17:08:06 CET] <Gramner> atomnuker: volatile registers per platform: x86-32: 3 gpr, 8 vec. win64: 7 gpr, 6 vec. unix64: 9 gpr, 16 vec
[17:08:33 CET] <Gramner> anything more than that costs some performance since registers have to be saved and restored
[17:09:57 CET] <Gramner> avx-512 adds another 16 volatile vector regs on x68-64, so you can use up to 22 on win64 without having to save stuff
[17:10:12 CET] <nevcairiel> callee saved vector registers are so weird
[17:10:29 CET] <Gramner> yes. it makes no sense because they're mostly used in leaf functions
[17:10:47 CET] <BBB> atomnuker: I have a fix for you
[17:10:52 CET] <Gramner> I could _maybe_ understand having like 1 or 2 being callee-saved but certainly not the majority
[17:11:05 CET] <BBB> I can get it down from 14.738 to 14.661 in decoding time for Chimera first 1k frames
[17:11:12 CET] <BBB> atomnuker: I havent tuned anything yet, but it works at least
[17:11:17 CET] <BBB> and it appears to not be slower anymore
[17:11:45 CET] <BBB> I bet you can bring it down further by removing the msac_update_cdf for the boolean one and instead simply having a special version that updates the boolean one without copying
[17:11:46 CET] <BBB> anyway
[17:12:56 CET] <BBB> atomnuker: https://code.videolan.org/rbultje/dav1d/commits/atomnuker-cdf-update-simd
[17:13:11 CET] <BBB> atomnuker: I threw out half of your changes, please dont be angry, was just trying to boil it down to something simple for the proof of concept
[17:13:19 CET] <BBB> so all changes to cdf.c are gone
[17:13:26 CET] <BBB> and the wrapper for the avx2 function is also gone
[17:13:49 CET] <BBB> this works for me, generates same md5, and is faster (a little). I think with some tuning you can speed it up a lot more
[17:15:42 CET] <BBB> atomnuker: one thing that may be interesting is to try and have a version for n_syms == 16 and then another for n_syms < 16 which writes the counter etc. all in avx2 instead of gpr
[17:15:48 CET] <BBB> since then its just one read and one write
[17:15:52 CET] <BBB> not sure how useful that would be though
[17:16:39 CET] <BBB> atomnuker: lmk if you want to discuss or whatever
[17:17:55 CET] <BBB> atomnuker: but most of it shouldbe fairly obvious
[18:13:51 CET] <nicolas17> when using a big image sequence as input, often I see neither CPU nor I/O are saturated, because ffmpeg reads one file (CPU idle) and then decodes it (I/O idle)
[18:13:53 CET] <nicolas17> if I do "cat *.jpg > /dev/null" in the background, overall performance improves
[18:13:54 CET] <nicolas17> would it make sense to add pre-fetching to ffmpeg itself?
[18:14:43 CET] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/576d39d4bde190989925b290442631a218f68e7d
[18:14:59 CET] <philipl> Ticket #7530 is a valid complaint.
[18:15:46 CET] <nevcairiel> that function is CUDA 9.2, which matches the documented driver requirement for the 8.2 branch
[18:16:20 CET] <nevcairiel> if he gets past that function itll probably get stuck on some other function
[18:16:24 CET] <nevcairiel> this is just the first
[18:21:50 CET] <philipl> nevcairiel: technically, they say CUDA 8.0 is the base requirement.
[18:22:04 CET] <philipl> Now, the driver requirements for Video SDK 8.2 imply the presence of this function.
[18:22:08 CET] <nevcairiel> then i dont know where the driver versions in the README file come from
[18:22:34 CET] <philipl> Those come from the Video SDK stated requirements.
[18:22:46 CET] <nevcairiel> in any case, those are high enough for your function
[18:23:02 CET] <philipl> Yes. But it should be made optional or not included for the older SDK releases.
[18:23:09 CET] <philipl> Header releases, rather.
[18:23:22 CET] <nevcairiel> its only useful for the CUDA  10 interop anyway, isnt it?
[18:23:26 CET] <nevcairiel> so just not backport it
[18:23:27 CET] <philipl> So the 8.0 and 8.1 branches shouldn't have it.
[18:23:28 CET] <philipl> Right.
[18:23:32 CET] <philipl> BtbN: did backport it. :-P
[18:23:36 CET] <nevcairiel> ah
[18:23:38 CET] <nevcairiel> oh well
[18:23:39 CET] <philipl> So I guess the right answer is to revert on the old branches.
[18:24:17 CET] <philipl> but the person doing the ffmpeg build might use the latest headers and this shouldn't break people not using vulkan interop
[18:24:25 CET] <philipl> so I think making it optional on the 8.2 headers is correct.
[18:24:33 CET] <philipl> The same way the rest of the vulkan interop functions are optional.
[18:24:42 CET] <nevcairiel> not that it hurts anything
[18:24:47 CET] <nevcairiel> but i dont think it'll fix that guy
[18:24:54 CET] <philipl> It can fix him.
[18:25:10 CET] <philipl> Well, maybe. It's confusing.
[18:25:21 CET] <philipl> I'd rather not try and work it out and just make it optional so the vulkan stuff is consistent.
[18:25:22 CET] <nevcairiel> if he  is u sing the 8.2 headers, those would require a new driver anyway
[18:25:36 CET] <nevcairiel> but yeah just making it optional would be f ine
[18:25:57 CET] <philipl> It's fuzzy. if he tried to use certain nvenc features, it would fail on old drivers. nvdec would work.
[18:26:24 CET] <BtbN> philipl, only mpv is using it so far, is it?
[18:26:26 CET] <nevcairiel> does ffmpeg still build w ith 8.0/8.1?
[18:26:43 CET] <BtbN> nevcairiel, it should, I didn't do a test build in a while though
[18:27:05 CET] <atomnuker> BBB: this is nuts
[18:27:12 CET] <BBB> ?
[18:27:45 CET] <philipl> BtbN: yeah, only mpv
[18:28:08 CET] <atomnuker> BBB: its very clever
[18:28:19 CET] <BBB> atomnuker: so, few suggestions for improvements
[18:28:25 CET] <philipl> BtbN: It already does a null check for the vulkan functions so I don't even have to add a guard to make this one optional.
[18:28:43 CET] <BBB> atomnuker: first of all, remove the shift using [rsp], instead use pmulhuw using a constant vpbroadcastded using r4q
[18:29:02 CET] <BBB> e.g. times 2 dw 4096, times 2 dw 2048, times 2 dw 1024, times 2 512
[18:29:11 CET] <BBB> and then [offset+r4q*4]
[18:29:46 CET] <BBB> then secondly, I think theres merit in having a jumptable and doing 4 versions (maybe even 5) for this function
[18:29:54 CET] <BBB> one for <8, one for ==8, one for <16, one for ==16
[18:30:08 CET] <BBB> the first one does xmm registers only and can do the counter in the simd code
[18:30:28 CET] <BBB> (pcmpgtw pw_32, etc., then or using fixed 0xff psrldqed by 2 ored into the final paddw register)
[18:30:30 CET] <BBB> same for <16
[18:30:37 CET] <BtbN> philipl, it's a CUDA function though
[18:30:38 CET] <BBB> then for ==8 and ==16, do the same as you do now in xmm/ymm registers
[18:30:50 CET] <philipl> BtbN: I mean the interop cuda functions.
[18:30:50 CET] <BBB> ad maybe a amaybe a fifth one for ==1 (which would be the boolean one)
[18:30:58 CET] <BtbN> philipl, ok.
[18:31:02 CET] <BBB> mc shows how to do jumptables
[18:31:04 CET] <BtbN> I'll do another round of releases then
[18:31:47 CET] <BBB> atomnuker: and please add a checkasm test, this is easily testable :)
[18:32:02 CET] <BBB> that also allows exploring performance gains per n_symbol number etc.
[18:34:52 CET] <BtbN> philipl, cuDeviceGetAttribute is around for forever, right?
[18:35:06 CET] <BtbN> Oldest reference I can find is it being in CUDA 8.0, but it's probably even older
[18:35:27 CET] <philipl> BtbN: CUDA 8.0 is old enough to equal forever. All SDK releases we support say they require CUDA 8
[18:36:24 CET] <BtbN> true
[18:38:57 CET] <philipl> michaelni: do you want to re-review the yadif refactoring, or are you happy for me to push?
[18:39:18 CET] <nevcairiel> bonus p oints if  you sneak it into 4.1 before it freezes
[18:39:24 CET] <philipl> woo
[18:39:52 CET] <philipl> I can sneak in all sorts of things if I skip the review step. :-)
[18:45:55 CET] <BBB> atomnuker: Im also guessing that when you use cmov and clz, you can prevent all the conditional code in the beginning
[18:47:55 CET] <BBB> atomnuker: something like clz bla, word [cdfq+nsymsq*2], cmp bla, 28 cmovle bla, 28 (?)
[18:48:30 CET] <BBB> atomnuker: and then you can use that to calculate the offset into the pmulhuw table
[18:48:50 CET] <BBB> atomnuker: I know, a little crazy, but it sounds doable right?
[18:49:48 CET] <BBB> but please make a checkasm test so we can explore speed gains from each of these on various n_symbols numbers
[18:49:57 CET] <BBB> otherwise it gets fairly nonsensical
[18:51:05 CET] <philipl> BtbN: so want me to push?
[18:51:17 CET] <BtbN> push?
[18:51:52 CET] <BtbN> The nv-codec-header stuff is already done
[18:52:45 CET] <BtbN> Or you mean yadif?
[18:52:49 CET] <nevcairiel> you didnt push 8.0 :(
[18:52:57 CET] <BtbN> I'm pretty sure I did
[18:53:07 CET] <nevcairiel> oh you pushed a tag
[18:53:09 CET] <nevcairiel> but not the branch
[18:53:11 CET] <BtbN> oh
[18:53:23 CET] <BtbN> fixed
[18:53:38 CET] <philipl> BtbN: I meant nv-codec-header. but you work fast :-)
[18:54:55 CET] <philipl> I want to push yadif but michaelni was not explicit as to his level of satisfaction.
[18:55:32 CET] <BtbN> I typoed the commit... well, too late now
[18:55:40 CET] <philipl> You can force push it. :-)
[18:55:49 CET] <BtbN> Pretty sure force pushes are blocked
[18:57:03 CET] <philipl> only one way to be sure.
[18:57:30 CET] <BtbN> It would also mean re-doing the whole releases
[18:57:32 CET] <BtbN> not worth it
[18:59:20 CET] <michaelni> philipl, i think its ok to push the yadif change, sorry that my reply was unclear
[19:10:31 CET] <nicolas17> guess I should post to the mailing list instead...
[19:11:13 CET] <tmm1> i wish yadif had neon simd
[19:11:25 CET] <nevcairiel> write some
[19:11:26 CET] <nevcairiel> :D
[19:11:35 CET] <nicolas17> tmm1: compiler autovectorizer not smart enough yet? :)
[19:11:56 CET] <nevcairiel> never
[19:12:01 CET] <nicolas17> :P
[19:12:32 CET] <tmm1> i wrote a simple blend deint using neon intrinsics
[19:12:37 CET] <tmm1> yadif is 100x more complicated
[19:13:02 CET] <nevcairiel> well you have the x86 simd to steal a concept from
[19:13:25 CET] <nicolas17> does ffmpeg "support" having an image2 sequence with gaps? or is the result undefined?
[19:16:40 CET] <nicolas17> if I have frame{1,2,3,4,5,6,8,9,10}.png, and I use ffmpeg -i %d.png, is it supposed to transcode frames 1-6, or transcode 1-10 and skip the missing 7, or give an error because of missing 7, or "there's no guarantees, don't do that"?
[19:17:29 CET] <durandal_1707> nicolas17: error, also wrong channel
[19:23:24 CET] <philipl> michaelni: thanks!
[19:25:09 CET] <JEEB> can someone note if this one is OK so I can push both https://patchwork.ffmpeg.org/patch/10574/ (which was LGTM'd) and it
[19:25:15 CET] <JEEB> asdf
[19:25:20 CET] <JEEB> https://patchwork.ffmpeg.org/patch/10583/
[19:25:25 CET] <JEEB> is the first one I meant, which wasn't ack'd
[19:25:30 CET] Action: JEEB is clearly tired
[19:26:14 CET] <JEEB> or should I add the dts there in that message as well? :V
[19:26:30 CET] <JEEB> since the offset by itself might not be useful possibly
[19:27:56 CET] Action: durandal_1707 wonders when users will appear wondering what new message means
[19:28:40 CET] <JEEB> it's not a new message, but generally if you hit that you're going to get A/V desync
[19:28:55 CET] <JEEB> at least in most cases I've had that happen it means that the vsync logic in ffmpeg.c is going to crash town :P
[19:29:08 CET] <JEEB> either due to weirdness in the input or otherwise
[19:30:10 CET] <JEEB> I have a patch that stops that intra stream discontinuity check from triggering if a stream of the "opposing" type (video if audio, and vice versa) has already reached the jumped-to point
[19:32:29 CET] <nicolas17> durandal_1707: I ask what it's *supposed* to do because the actual behavior is certainly weird https://paste.kde.org/pbemjvxv7
[19:33:41 CET] <cone-675> ffmpeg 03Philip Langdale 07master:598f0f39271d: libavfilter/vf_yadif: Make frame management logic and options shareable
[19:33:41 CET] <cone-675> ffmpeg 03Philip Langdale 07master:d5272e94ab22: avfilter/vf_yadif_cuda: CUDA accelerated yadif deinterlacer
[19:33:41 CET] <cone-675> ffmpeg 03Philip Langdale 07master:1b41115ef708: avcodec/nvdec: Increase frame pool size to help deinterlacing
[19:34:24 CET] <durandal_1707> nicolas17: gaps are not supported, unless you use glob pattern
[19:34:25 CET] <nicolas17> find_image_range is doing some exponential search for the last file in the sequence
[19:36:30 CET] <nicolas17> if find_image_range happens to skip over the gap, then the encoding process will give an error when it can't open the missing file; otherwise, it will successfully encode up to the missing file
[20:26:26 CET] <BtbN> philipl, https://travis-ci.org/FFmpeg/FFmpeg-Coverity/builds/449984694#L1824
[20:26:28 CET] <BtbN> oO
[20:39:22 CET] <BtbN> Why? The configure check looks right to me.
[20:40:00 CET] <BtbN> hm, cuda_sdk _is_ enabled on there
[20:40:05 CET] <BtbN> how
[20:41:04 CET] <BtbN> philipl, seems like it doesn't build on older cuda SDKs, namely on the one Debian Stretch uses.
[20:51:42 CET] <BBB> atomnuker: https://code.videolan.org/videolan/dav1d/merge_requests/289 for you
[20:53:37 CET] <atomnuker> BBB: just write that into the msac_decode_symbol_adapt function
[20:53:47 CET] <atomnuker> I'm not sure if a branching asm code would be worth it
[20:54:04 CET] <BBB> maybe I should move that function from header to .c file
[20:54:14 CET] <BBB> otherwise well blow up the binary size of decode.c by a lot
[20:54:44 CET] <atomnuker> yeah, compiler will inline msac_decode_bool anyway so you save a function call
[21:01:32 CET] <philipl> BtbN: I'll look.
[21:02:13 CET] <BBB> done
[21:05:19 CET] <durandal_1707> anybody against audio match/align report filter?
[21:05:21 CET] <BtbN> philipl, I sent new docker images on the way with a more up to date CUDA SDK (9.2 iirc)
[21:08:02 CET] <atomnuker> BBB: no need for a function for msac_update_bool_cdf, just make the msac_decode_bool_adapt do the adaptation
[21:09:22 CET] <atomnuker> also I don't know the coding style though and through but I don't think msac_update_cdf needs the msac_ prefix as its no longer exposed
[21:09:27 CET] <BBB> you dont think its better self-documentation?
[21:09:28 CET] <atomnuker> other than that lgtm
[21:09:35 CET] <BBB> oh right msac_ prefix should go, yes
[21:09:46 CET] <atomnuker> its fine, _adapt implies it does adaptation
[21:10:01 CET] <BBB> right
[21:12:23 CET] <BBB> done
[21:13:42 CET] <durandal_1707> michaelni: you havent pushed prosumer changes, they need to go to 4.1 too
[21:16:38 CET] <atomnuker> BBB: yeah, looks fine
[21:18:56 CET] <durandal_1707> JEEB: that log message patch should be fine
[21:19:58 CET] <JEEB> durandal_1707: I only poked because 2/2 never got any straight acks even though I could take the "you should also raise teh level for that other one, too" as someone having a positive opinion on it
[21:29:29 CET] <philipl> BtbN: apparently that initialization syntax for built-in vectors is new...
[21:29:55 CET] <philipl> I don't want to change it because the old way requires you to know the exact type (so uchar2 vs ushort2 becomes a problem)
[21:36:52 CET] <BtbN> yeah, it's probably fine
[21:36:56 CET] <BtbN> what syntax exactly?
[21:37:13 CET] <philipl> uchar2 foo = { 1, 2 };
[21:37:29 CET] <philipl> I would need to do: uchar2 foo = make_uchar2(1, 2);
[21:42:19 CET] <nicolas17> durandal_1707: audio align? that sounds like something I could use...
[21:44:12 CET] <durandal_1707> nicolas17: yes, it would report best match between two (or more?) tracks so one could align them for example when mixing, it would not do actual aligning
[21:45:41 CET] <BtbN> philipl, can probably do some C++ template magic
[21:45:59 CET] <philipl> BtbN: well, the point is my current syntax does do C++ magic.
[21:46:07 CET] <BtbN> more
[21:46:49 CET] <BtbN> You can make a make_vector<T> and specifically implement it for the types you use
[21:47:03 CET] <BtbN> and then use that in your template
[21:48:53 CET] <philipl> Does that exist in cuda?
[21:48:58 CET] <philipl> Oh, I see.
[22:02:24 CET] <nicolas17> durandal_1707: I think the audio I need to align like that would be a bitwise match, so I probably have easier ways to do it, but your filter still sounds interesting :)
[22:03:45 CET] <durandal_1707> nicolas17: well it will report score, so if its inf you know its bitexact :)
[22:11:09 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/9df533144fcead8b416ba928d5aefb8de5ab30d0
[22:15:23 CET] <BtbN> it builds on CUDA 10/VS2017 at least
[22:35:12 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/8e50215b5e02074b0773dfcf55867654ee59c179
[22:35:15 CET] <philipl> even simpler.
[22:35:21 CET] <philipl> Obvious in retrospect.
[22:49:32 CET] <cone-671> ffmpeg 03Philip Langdale 07master:8e50215b5e02: avfilter/vf_cuda_yadif: Avoid new syntax for vector initialisation
[22:56:04 CET] <philipl> BtbN, nevcairiel: Well, with that out of the way, we're back to pix fmts. Yay!
[23:47:51 CET] <cone-671> ffmpeg 03Michael Niedermayer 07master:9acdf17b2c30: avcodec/prosumer: Check for bytestream eof in decompress()
[23:47:52 CET] <cone-671> ffmpeg 03Michael Niedermayer 07master:506839a3e9cc: avcodec/prosumer: Remove unneeded ()
[23:47:53 CET] <cone-671> ffmpeg 03Michael Niedermayer 07master:1dfa0b6f36d2: avcodec/prosumer: Remove always true check in decompress()
[23:47:54 CET] <cone-671> ffmpeg 03Michael Niedermayer 07master:66425add270c: avcodec/prosumer: Simplify bit juggling of the c variable in decompress()
[00:00:00 CET] --- Sat Nov  3 2018