On 4/20/2018 1:09 PM, Paul B Mahol wrote: > On 4/20/18, James Almer <jamr...@gmail.com> wrote: >> On 4/20/2018 12:34 PM, Gyan Doshi wrote: >>> >>> >>> On 4/20/2018 8:35 PM, James Almer wrote: >>> >>> >>>> I don't understand the reasoning to invert the logic here. The current >>>> behavior is clearly not right. We're marking Inter coded frames as key >>>> frames and Intra coded frames as non keyframes. >>> >>> This behaviour was how it was originally. See the sample attached to >>> #7091. Before inversion, first frame on that file is not marked as KF >>> but all remaining frames are. >>> >>> If you streamcopy the FATE sample to a new CPK starting at a frame >>> currently not marked as KF, with -copyinkf, you should see >>> artifact/incorrect decoding in the output. >> >> Wouldn't this hint that the file in question is broken? I see it was >> generated with our muxer, which is indeed setting keyframes wrong. >> >> In line 72 from segafilmenc.c I see >> >> if (pkt->keyframe) >> info1 |= (1 << 31); >> >> So basically, a fifteen years old demuxer got its logic inverted to >> match the behavior of an evidently faulty month old muxer. >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > > > Take real sample from game, if first frame is not marked as keyframe, > demuxer is wrong.
That's exactly what happens right now with the capcom logo sample in the FATE suite, as i mentioned earlier. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
