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

[burek]

[00:21:22 CEST] <durandal117> can mplayer utilize encoding via its qtx support?
[00:26:22 CEST] <philipl> so cuvid supports raw input formats. you could feed softeare
[00:26:37 CEST] <philipl> decoded frames in for deinterlacing if you cared.
[00:30:33 CEST] <nevcairiel> i saw that in the API, but i'm not sure that actualyl works
[00:30:53 CEST] <nevcairiel> it looked like something just reserved for the future but never used
[00:33:49 CEST] <philipl> you're probably right. It's unclear how you'd populate picparams and the procpqrams
[00:34:04 CEST] <philipl> don't seem used.
[00:55:50 CEST] <philipl> BtbN: I've got a (vp9) sample that just stops a few seconds in (in mpv) with the new API code. No deinterlacing involved
[00:58:48 CEST] <philipl> seeking to force a flush gets it going again and then it stops again
[00:59:09 CEST] <philipl> This is just vp9 stuff I downloaded from youtube but the matching h.264 clips don't have the problem
[00:59:12 CEST] <philipl> odd.
[00:59:25 CEST] <philipl> no problems without your patche
[02:06:26 CEST] <philipl> BtbN: Ok, so I did a quick test - you can repro just doing a decode to null output with ffmpeg. It chugs along until it thinks the frame queue is full and then it spins forever, never draining the queue.
[02:06:33 CEST] <philipl> And that's the same behaviour in mpv.
[02:10:23 CEST] <philipl> number of waiting frames just goes up and up and up and eventually it maxes out
[02:11:21 CEST] <philipl> same with vp8
[02:12:21 CEST] <philipl> Ok, need to be precise. frame_queue is reported as always being empty but waiting_frames goes up to the max. Then it grinds to a halt.
[02:16:06 CEST] <philipl> If I get rid of the fifo_size + waiting_frames check completely, the files transcode/play correctly. Something's wrong there.
[02:17:09 CEST] <philipl> For a 2615 frame sample, waiting_frames is 426 at the end.
[02:18:56 CEST] <philipl> I think this might be due to vpX Alternate Reference frames.
[02:20:00 CEST] <philipl> The ffmpeg summary says 3042 frames were demuxed with 2615 decoded. and the h.264 version of this sample (from youtube) is 2616 and 2615
[02:20:13 CEST] <philipl> So AR frames go in but never come out.
[02:35:42 CEST] <cone-569> ffmpeg 03Paul B Mahol 07master:d38dff8e5da5: avcodec/dnxhddata: add support for cid 1244
[03:52:25 CEST] <cone-569> ffmpeg 03Paul B Mahol 07n2.8.8:HEAD: avcodec/dnxhddata: add support for cid 1244
[05:39:27 CEST] <philipl> BtbN: So, the picparams for vp8 and vp9 have a showFrame flag and if this is 0, then it's an AR frame that won't be in the output. You can use this to avoid incrementing waiting_frames.
[05:40:06 CEST] <philipl> Unfortunately, the vp9 picparams definition in cuda 7.5 is completely wrong and vp8 is missing. You need the definitions from the video sdk, and because the header doesn't work as is, you end up having to cobble together a frankenstein header.
[05:45:55 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/c09e59938defc325734bd8a2ac36b9c0321c5145
[10:03:18 CEST] <aballier> michaelni: any reason 6aa39080ccea2b60433e920417844c3a3c0da50b is not in 2.8.8 ? is < 3.0 not affected ?
[11:35:39 CEST] <michaelni> aballier, 2.8 is not affected, 3.0 was the first release affected
[11:50:46 CEST] <ubitux> so.
[11:50:52 CEST] <ubitux> any objection to have lowres in codecpar ?
[11:51:19 CEST] <ubitux> or we should just drop it
[11:51:21 CEST] <ubitux> ?
[11:52:16 CEST] <nevcairiel> its not a codec parameter, its a setting
[11:52:28 CEST] <nevcairiel> so yes objections =p
[11:53:08 CEST] <wm4> of course
[11:53:20 CEST] <ubitux> so how do i solve the problem?
[11:53:33 CEST] <wm4> fix ffmpeg.c
[11:53:43 CEST] <nevcairiel> i never understood why avformat even needs to care about lowres
[11:53:47 CEST] <ubitux> that's what i'm doing wm4 
[11:53:48 CEST] <nevcairiel> just tell avcodec to lowres
[11:53:57 CEST] <nevcairiel> leave avformat out of it
[11:54:33 CEST] <ubitux> i may have missed something then, let me check
[11:54:47 CEST] <wm4> this is just like hw decoding
[11:55:07 CEST] <wm4> it should use the decoder ouput format, not what lavf is reporting
[11:55:10 CEST] <nevcairiel> iirc the reason its so f 'ed up is that ffmpeg has to rely on the avformat dimensions to build a filter graph instead of asking avcodec about it after
[11:57:29 CEST] <wm4> yep
[11:57:44 CEST] <wm4> it'll reconfigure the graph, but leave the output dimensions, and insert a scaling filter
[11:57:49 CEST] <nevcairiel> so in a perfect world it would just delay creating the graph  until the decoder actually is created and maybe even produced the first frame
[11:57:50 CEST] <wm4> which messes up fate results
[11:58:05 CEST] <wbs> nevcairiel: iirc avconv actually changed to do things like that recently
[11:58:18 CEST] <wbs> like, don't start outputs until each input actually has decoded one frame
[11:58:41 CEST] <nevcairiel> wbs: yeah and it messed up using fate to test hwaccels since it now builds a nv12 graph instead of converting it to yuv420 =p
[11:58:59 CEST] <wbs> ah :P
[11:59:09 CEST] <nevcairiel> not sure if anton addressed that yet
[11:59:13 CEST] <wm4> why would that make a difference
[11:59:20 CEST] <nevcairiel> because framecrcs then change
[11:59:21 CEST] <wm4> can't you just convert to yuv420p?
[11:59:26 CEST] <aballier> michaelni: thx; oss-sec post says <=3.1.1....
[11:59:28 CEST] <nevcairiel> you can, but the fate tests are not told to do that
[11:59:41 CEST] <nevcairiel> because they never had to before :D
[12:00:39 CEST] <nevcairiel> so eh, let ubitux just break lowres for the time being and hope we can merge the avconv change without too much pain later on, and maybe it works again then? :)
[12:01:49 CEST] <nevcairiel> i kinda lost the overview where in the merges we are, i was kinda on vacation the last month or so
[12:02:04 CEST] <ubitux> we are ~320 commits late
[12:02:16 CEST] <ubitux> because we are stuck in that codecpar thing
[12:02:28 CEST] <ubitux> which was skipped previously, and now we have to deal with it to move on
[12:02:34 CEST] <wm4> put it this way: fuck lowres
[12:02:42 CEST] <ubitux> there is not only lowres
[12:02:46 CEST] <wm4> force michaelni to add it back or something after you're done
[12:02:48 CEST] <ubitux> there is also a flushing packets issue with hevc
[12:02:56 CEST] <wm4> never heard of that
[12:03:09 CEST] <ubitux> i mean it's one of the remaining failure
[12:03:17 CEST] <ubitux> before ffmpeg.c is fully ported to codecpar
[12:03:30 CEST] <ubitux> jamrial helped me with fixing most of them
[12:03:50 CEST] <ubitux> we have now fate-rv20-1239 and the hevc param change that fucks up
[12:03:57 CEST] <ubitux> rv20 is because of lowres
[12:04:13 CEST] <ubitux> hevc i don't know, the last packets have all the same timestamps
[12:04:19 CEST] <ubitux> i haven't investigated
[12:04:39 CEST] <nevcairiel> it looks like the avconv changes we're refering to is only a few easy commits away in the merge history
[12:05:06 CEST] <nevcairiel> so it might be feasible to just break lowres for a while if its otherwise too ugly to fix
[12:05:34 CEST] <ubitux> i don't understand the issue yet
[12:06:44 CEST] <nevcairiel> the issue is simple: ffmpeg.c builds a filter graph using the avformat provided dimensions right now. so if you use lowres, it "needs" avformat to apply the lowres as well, or it'll build a filtergraph using the original dimensions and insert a scale filter later to upscale lowres back to original
[12:07:05 CEST] <wm4> ubitux: there was something about flush packets?
[12:07:11 CEST] <nevcairiel> which is ugly for all sorts of reasons
[12:07:44 CEST] <nevcairiel> the upcoming changes from avconv move filter graph init to a later point when all input streams processed one frame already
[12:07:51 CEST] <ubitux> wm4: it "looks" related to flush packets as it's the last timestamps that are identical, but maybe that's unrelated
[12:07:56 CEST] <nevcairiel> so .. decoupling from avformat details!
[12:08:11 CEST] <ubitux> wm4: it's in a parameter change sample, i havent investigated
[12:10:09 CEST] <wm4> well, flush packets shouldn't have timestamps, if you mean that
[12:14:26 CEST] <jkqxz> This hack <https://git.libav.org/?p=libav.git;a=commit;h=bd31c61cf94d01dbe1051cf65874e7b2c0ac5454> (still in ffmpeg) was "fixing" the same problem in the hwframe case - adding a scaler there doesn't work at all.  Maybe something like that could fix your lowres case temporarily?
[14:35:45 CEST] <cone-829> ffmpeg 03Vittorio Giovara 07master:cb78d14cf9b5: vf_colorspace: Interpret unspecified color range as limited range
[14:45:47 CEST] <tmatth> atomnuker: i'm seeing some pretty psychedelic artifacts with vc2: http://people.videolan.org/~tmatth/akiyo.mkv
[14:47:47 CEST] <atomnuker> tmatth: do they disappear if you reduce the transform depth?
[14:49:25 CEST] <tmatth> atomnuker: yeah, default is 4 but at 3 it's normal
[14:54:06 CEST] <atomnuker> not enough buffer padding probably, I'll take a look at it later
[14:56:49 CEST] <ubitux> gcc is funny with its new markup when in finds something in a macro
[14:57:24 CEST] <tmatth> atomnuker: it's kind of like daala's rainbow vomit, but more splotchy/artistic
[14:57:47 CEST] <ubitux> http://b.pkh.me/gcc-macro-warn.png heh.
[14:59:08 CEST] <nevcairiel> sure is verbose
[15:01:30 CEST] <tmatth> atomnuker: valgrind complaints for wavelet_depth=4 https://paste.debian.net/829624/
[15:02:56 CEST] <funman> tmatth: did you build with -vomit-frame-pointer ?
[15:03:31 CEST] <tmatth> funman: -vomit-wavelet-padding i think
[15:04:00 CEST] <nevcairiel> why do you want it to vomit things at you
[15:05:33 CEST] <funman> i guess he wants to see what this codecs has in its guts
[15:36:51 CEST] <iive> ubitux: looks like gcc bug to me...
[15:46:05 CEST] <ubitux> jamrial: thanks for your work; i merged the commit in my branch
[15:46:19 CEST] <jamrial> ubitux: no prob
[15:46:20 CEST] <ubitux> i'm just starting again to look at the lowres issue
[15:46:30 CEST] <ubitux> ...in case you want to look at that hevc thing
[15:47:35 CEST] <jamrial> ubitux: i tried. something's wrong with timestamps. removing the -vsync 0 option "fixes" them but the last frame is dropped
[15:48:11 CEST] <ubitux> try setting pkt_timebase ;)
[15:48:41 CEST] <JEEB> -vsync... *barf*
[15:48:48 CEST] <JEEB> I had *so* much fun trying the different modes
[15:48:51 CEST] <JEEB> last weekend
[15:49:05 CEST] <JEEB> I should send an e-mail on if anyone can actually explain the differences and what is usually picked as the default
[15:49:12 CEST] <ubitux> (what's 0 btw, cfr or vfr?)
[15:49:22 CEST] <jamrial> i think it's passthrough
[15:49:33 CEST] <JEEB> right, that's what I ended up last with
[15:49:36 CEST] <JEEB> -vsync passthrough -copyts
[15:49:38 CEST] <JEEB> :V
[15:49:57 CEST] <ubitux> not even a copytb option?
[15:50:53 CEST] <JEEB> although the funniest part was
[15:51:16 CEST] <JEEB> -vsync vfr => -itsoffset 300 works, -itsoffset $(date %+s) drops all the packets
[15:51:43 CEST] <JEEB> and not setting vsync just led to ffmpeg.c duplicating the initial frame until -itsoffset
[15:52:01 CEST] <JEEB> (so if you had -itsoffset 300 it would duplicate 300 seconds worth of first frame)
[15:53:16 CEST] <jamrial> ubitux: nope, setting pkt_timebase didn't fix it
[15:53:20 CEST] <ubitux> :(
[15:54:27 CEST] <jamrial> using -debug_ts shows that the affected frames apparently came after EOF
[15:54:44 CEST] <ubitux> ah so that was indeed a flush issue\
[15:54:56 CEST] <ubitux> i'm sure wm4 wants to know more about it
[15:56:05 CEST] <nevcairiel> Flushing changes from codecpar?
[15:58:37 CEST] <ubitux> flushing timing issues due to the move to codecpar somehow yes
[15:58:45 CEST] <ubitux> (or me messing something in the transition)
[16:03:26 CEST] <wm4> frames after eof?
[16:09:31 CEST] <jamrial> ubitux: the lowres issue is weird. -lowres 1 from command line changes the corresponding field in st->codec, and before codepar port it was copied to ist->dec_ctx where it apparently took effect
[16:10:02 CEST] <jamrial> but after codecpar port, where it's obviously not copied, even if i do it manually it has no effect
[16:10:18 CEST] <ubitux> i tried exactly that (set it manually)
[16:10:39 CEST] <jamrial> but what does seem to have effect is setting it in ost->enc_ctx
[16:10:48 CEST] <jamrial> and i'm not sure why
[16:10:57 CEST] <jamrial> since it's an input option
[16:11:57 CEST] <ubitux> maybe it's a "global options"?
[16:12:34 CEST] <ubitux> no it's indeed as decoding only
[16:13:29 CEST] <jamrial> ffplay seems to handle lowres itself instead of relying on the lavc/options_table.h option
[16:13:32 CEST] <ubitux> \ffplay has some specific "lowres" option for some reason
[16:13:35 CEST] <ubitux> yeah
[16:13:38 CEST] <ubitux> ;)
[16:13:50 CEST] <jamrial> heh
[16:19:14 CEST] <ubitux> jamrial: it's likely due to lavf forwarding the lowres setting from internal avctx probing
[16:19:18 CEST] <ubitux> to the codec in use
[16:19:46 CEST] <ubitux> lavf/utils.c around L3820
[16:28:49 CEST] <jamrial> ubitux: i think i found what's wrong with the hevc test
[16:30:32 CEST] <jamrial> yep, ist->dec_ctx->framerate is not set
[16:30:46 CEST] <jamrial> which is apparently needed to set timestamps here
[16:32:38 CEST] <jamrial> in process_input_packet() when pkt is NULL
[16:34:52 CEST] <ubitux> it looks like the same scope as the lowres thing
[16:34:58 CEST] <ubitux> st->codec->framerate = st->avg_frame_rate;
[16:35:02 CEST] <ubitux> you see this in lavf/utils
[16:35:21 CEST] <ubitux> under the FF_API_LAVF_AVCTX ifdefery
[16:35:24 CEST] <jamrial> yeah
[16:35:28 CEST] <ubitux> along with the lowres
[16:36:02 CEST] <cone-829> ffmpeg 03Jai Luthra 07master:dfa489be0199: MAINTAINERS: add myself for mlp/truehd
[16:36:28 CEST] <jamrial> the difference is that manually setting lowres didn't work, but manually setting framerate did
[16:36:48 CEST] <ubitux> lucky you
[16:37:19 CEST] <jamrial> no, just shows that there's something else with lowres, not just an option lost in transition
[17:09:28 CEST] <jamrial> ubitux: pushed the fix for the hevc failure to my repo
[17:14:37 CEST] <ubitux> nice
[17:14:46 CEST] <ubitux> thanks :)
[18:33:30 CEST] <cone-829> ffmpeg 03Paul B Mahol 07master:590f025b3dc0: avcodec/rscc: add support for gray8 format
[19:58:57 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:3cb400c11a75: avutil/frame: Add a flag to discard frame after decode.
[19:58:58 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:778af68c708e: avformat/avframe.h: Add a flag in AVIndexEntry to discard frame after decoding.
[19:58:59 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:2dbedc20ce2f: lavc: Add a flag in AVPacket to discard packet after decoding. Discard frames after decoding based on the flag.
[19:59:00 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:b518d809f163: lavf/utils: Support av_index_search_timestamp in case of AVIndexEntry with discarded packets.
[19:59:01 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:a53201879ca3: avcodec/utils: If using discard frame flag, ignore skip_samples set by the decoder
[19:59:02 CEST] <cone-829> ffmpeg 03Sasi Inguva 07master:ca6cae73db20: lavf/mov: Add support for edit list parsing.
[20:18:59 CEST] <cone-829> ffmpeg 03Moritz Barsnick 07master:2c48014ab2bb: doc/encoders: minor aac encoder formatting improvements
[20:43:17 CEST] <durandal117> michaelni: why you have broke gapless support?
[20:44:00 CEST] <wm4> because google wanted it
[20:47:04 CEST] <michaelni> wm4, do not slander people, also not me, iam not leader or a political figure anymore, this is not ok nor funny
[20:47:19 CEST] <michaelni> durandal117, how can i reproduce?
[20:47:55 CEST] <durandal117> michaelni: see fate gapless test you changed
[20:48:18 CEST] <wm4> michaelni: where did I slander you
[20:49:54 CEST] <michaelni> wm4, you stated "because google wanted it" this is not true, no patch was applied because google wanted it and i very much doubt anyone wanted to break anything
[20:53:29 CEST] <jamrial> the breakage wasn't intentional. lets not start a flamewar and instead try to fix the issue, or worst case scenario revert the faulty commit until a better working solution is written
[20:53:34 CEST] <wm4> michaelni: I'm not sure if that makes it better or worse
[20:54:31 CEST] <wm4> jamrial: well, the breakage is quite obvious: it's literally reflected in the fate ref changes
[20:55:09 CEST] <ubitux> that patchset has been on the mailing list for weeks... why react only now?
[20:55:13 CEST] <jamrial> which evidently went unnoticed
[20:56:31 CEST] <wm4> ubitux: then why did nobody point it out (apparently)
[20:57:01 CEST] <ubitux> why didn't you?
[20:57:22 CEST] <wm4> because I haven't been reading the ML for months
[20:57:40 CEST] <ubitux> maybe most developers haven't been reading that patchset then
[20:57:51 CEST] <wm4> yet it was pushed?
[20:58:17 CEST] <ubitux> it's hard to tell if the patchset was read enough; there was enough visibility of it given the size of the thread
[20:58:45 CEST] <ubitux> if ppl don't read nor comment, then... it's assumed to be good to go if those who read it are ok with it
[21:00:32 CEST] <Chloe> Is a fate ref change always a breakage?
[21:00:47 CEST] <JEEB> no
[21:00:55 CEST] <JEEB> in this case it's... uhh...
[21:01:32 CEST] <wm4> I think I just could think of a way to get in my ffmpeg.c decoding API changes!
[21:08:10 CEST] <Chloe> hi isasi 
[21:08:25 CEST] <isasi> hi
[21:10:58 CEST] <JEEB> anyways, the unfortunate case was that many of the people who could have given a proper review to the patch set were either busy or left before. but the main thing is, how do we go forward? I think many people preferred the edit list to be exported and then utilized as post-processing
[21:11:30 CEST] <wm4> isasi: sorry for being excessively rude
[21:12:57 CEST] <isasi> The  implemented way by doing it inside demuxer was a longstanding implementation that was there in our google code for more than 3 years. So I just tidied it up and tried to submit it to ffmpeg , because we wanted to make changes between open source ffmpeg and our ffmpeg version minimal
[21:13:29 CEST] <wm4> that is commendable
[21:13:35 CEST] <JEEB> yeah, that makes sense
[21:13:59 CEST] <isasi> no worries about the comments . i just want to see if we can fix the gapless playback
[21:15:22 CEST] <isasi> so right now, after av_decode_audio4 timestamps should be monotonic , because that function takes into account discard_frame flag
[21:15:53 CEST] <isasi> the problem wm4 has pointed out is that ff_init_buffer_info might not necessarily be called before av_decode_audio4  
[21:16:01 CEST] <isasi> am I undesrstanding this correct?
[21:16:50 CEST] <wm4> there might be decoders which work differently from the native/builtin decoders (such as external decoder wrappers, which some might unfortunately have to use)
[21:17:07 CEST] <isasi> ok. 
[21:17:13 CEST] <wm4> these might call ff_init_buffer_info on a best effort basis, rather than at the time when a packet is decoded/returned
[21:17:38 CEST] <wm4> so these can't support the current approach from what I can see, and will probably randomly "fail"
[21:19:16 CEST] <isasi> so those 
[21:19:45 CEST] <isasi> "external decoder wrappers" still would rely on the skip_samples field to be set exactly as before the patch 
[21:20:10 CEST] <isasi> along with ofcourse, the timestamps to be set exactly as before the patch
[21:20:44 CEST] <isasi> because in this patch, I am modifying the amount of skip_samples also
[21:22:21 CEST] <isasi> for the fate test in question. Before - the first audio packet audio would have timestamp -1024 and skip_samples will be  1024. 
[21:23:14 CEST] <isasi> After the patch -  the first audio packet timestamp is 0 . the packet is marked DISCARD. and skip_samples will be 0 (because I already use the discard flag to discard the packet )
[21:23:40 CEST] <nevcairiel> shouldnt it for backwards compat just set skip samples to the packet size?
[21:27:06 CEST] <isasi> So the skip_samples is set as the first edit list media time for AAC before this patch http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=6e80b93271a4f998af6ba1af795d7d7c5d67f5a1;hb=7b3bc365f9923e30a925f8dece4fddd127a54c5d#l2800
[21:27:37 CEST] <isasi> So it need not be just packet_size . It could be 48 seconds of samples 
[21:32:48 CEST] <isasi> I cannot just  set skip_samples to the first editlist start time, because i) while modifying the AVIndex, I seek to just 1s. before the audio edit list start time - http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavformat/mov.c;h=b84d9c03fc72af45f243e6e792093db7fa92d5d2;hb=HEAD#l2980  .  so skip_samples has to be modified to be correct
[21:33:15 CEST] <isasi> ii)setting  skip_samples to the first editlist start time , wouldn't be correct in-case of multiple audio edit lists
[22:58:05 CEST] <wm4> isasi: regarding the output stage, here's an idea how it could be done in a somewhat backward compatible way (to some degree), and in pretty much the same way for audio and video: don't change timestamps, but add an edit list segment as side data to the packet
[22:58:43 CEST] <wm4> libavcodec/utils.c would, if a new edit list segment comes, set it as current output range
[22:58:59 CEST] <wm4> then it'd clip all output against this range until the next packet with an edit list side data arrives
[22:59:35 CEST] <wm4> on such a new segment it'd flush the current decoder, then set it as current segment, feed the packet to the decoder (repeat the whole process here)
[22:59:54 CEST] <wm4> just an idea
[23:06:17 CEST] <isasi> two edit lists can repeat the same segment of the video. 
[23:06:39 CEST] <isasi> in that case this method wouldn't work I guess.
[23:07:15 CEST] <wm4> the demuxer would have to repeat the segment
[23:07:45 CEST] <wm4> for API users which strip the side data from packets it would look like a timestamp reset with some repeated data
[23:15:35 CEST] <isasi> yes. so basically the idea is to move just the timestamp modification part of mov_fix_index function to libavcodec/utils.c
[23:16:02 CEST] <wm4> well the important part os "clipping" the decoder output to the edit list segment
[23:16:33 CEST] <wm4> normally edit lists are supposed to be applied at presentation, so doing it after decoding is the closest that's possible if it's supposed to happen within the ffmpeg libs
[23:17:29 CEST] <isasi> yes. I agree. 
[23:18:55 CEST] <isasi> But doing this seems a big implementation change and I probably will have to test it a lot inside google. Instead, to make the gapless playback work I believe I can hack something up easily 
[23:19:41 CEST] <isasi> I just need to know what the behavior of skip_samples should be .  If the skip_samples field also needs to be exactly the same as before the patch?
[23:27:57 CEST] <cone-845> ffmpeg 03Carl Eugen Hoyos 07master:11777eb81421: lavc/rscc: Support pal8 in rscc.
[00:00:00 CEST] --- Tue Sep 20 2016