[FFmpeg-devel] [PATCH] avformat/segafilmenc - set keyframe bit correctly

James Almer jamrial at gmail.com
Sun May 6 02:32:54 EEST 2018


On 5/5/2018 8:16 PM, Michael Niedermayer wrote:
> On Sat, May 05, 2018 at 08:09:07PM -0300, James Almer wrote:
>> On 5/5/2018 8:06 PM, Michael Niedermayer wrote:
>>> On Sat, May 05, 2018 at 05:16:09PM +0530, Gyan Doshi wrote:
>>>> Since the muxer author hasn't made the change, the patch is submitted.
>>>>
>>>> Reference:
>>>>
>>>> http://www.ffmpeg.org/pipermail/ffmpeg-devel/2018-April/228602.html
>>>
>>>>  segafilmenc.c |    2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>> 710a71f12fae34d125a755bc0f5b290c6a6018e9  0001-avformat-segafilmenc-set-keyframe-bit-correctly.patch
>>>> From 79f87ff264c2989193d5e59da8c5cf285940aa50 Mon Sep 17 00:00:00 2001
>>>> From: Gyan Doshi <ffmpeg at gyani.pro>
>>>> Date: Sat, 5 May 2018 17:04:53 +0530
>>>> Subject: [PATCH] avformat/segafilmenc - set keyframe bit correctly
>>>>
>>>> As per
>>>> https://web.archive.org/web/20020803104640/http://www.pcisys.net:80/~melanson/codecs/film-format.txt,
>>>>
>>>> the top bit of the info1 chunk is set as 1 for inter-coded frames and 0
>>>> otherwise.
>>>> ---
>>>>  libavformat/segafilmenc.c | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/libavformat/segafilmenc.c b/libavformat/segafilmenc.c
>>>> index 5b0d7e69e8..524230e461 100644
>>>> --- a/libavformat/segafilmenc.c
>>>> +++ b/libavformat/segafilmenc.c
>>>> @@ -69,7 +69,7 @@ static int film_write_packet_to_header(AVFormatContext *format_context, FILMPack
>>>>          info1 = pkt->pts;
>>>>          info2 = pkt->duration;
>>>>          /* The top bit being set indicates a key frame */
>>>> -        if (pkt->keyframe)
>>>> +        if (!pkt->keyframe)
>>>>              info1 |= (1 << 31);
>>>>      }
>>>
>>> Fixes to muxers and encoders should always bump the minor or micro version of
>>> the lib.
>>>
>>> It would also be ideal if this version is stored in the file, that way
>>> demuxers/decoders can compensate for bugs in the muxer/encoder.
>>> Not sure the format has a place for this?
>>
>> It's a decades old format used on a few games, it's very likely it doesn't.
> 
> yes
> 
> its probably possible to detect the muxer bug without it, if someone wants to
> implement it

Paul said that if the first video frame was not marked as keyframe then
the file is invalid, so the demuxer can probably use that and flip the
flag accordingly.

Or someone could write a cinepak parser, which would allow us to ignore
container level parameters. But i don't expect that to ever happen :p

> 
> 
>>
>> A micro bump should be enough.
> 
> sure
> 
> [...]
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 



More information about the ffmpeg-devel mailing list