[FFmpeg-devel] [PATCH] avformat: close parser if codec changed

Andreas Cadhalpun andreas.cadhalpun at googlemail.com
Thu Nov 3 22:03:27 EET 2016


On 03.11.2016 11:07, Michael Niedermayer wrote:
> On Thu, Nov 03, 2016 at 01:04:21AM +0100, Andreas Cadhalpun wrote:
>> Yes, but it's not clear that the parser internal state is still correct
>> after a change of the codec id.
> 
> what exact case are we talking about ?
> 
> A. The parser changeing the codec_id ?
> B. The caller changing the codec_id ?

I meant:
C. The demuxer changing the codec_id.

> B looks like a violation of the API, the caller cant change things
> without reopening the parser

Agreed.

> for A id consider the parser completely broken if it changes the
> codec id and falls in a inconsistent state without the user
> detecting that and closing it.
> Such requirement for user apps also is not documented

Also agreed.

> Parsers dont handle unrelated formats, they handle things that are
> similar or identical like  AV_CODEC_ID_MJPEG, AV_CODEC_ID_JPEGLS
> 
> some parsers dont set the codec_id, like *jpeg doesnt
> mpeg audio contains checks to explicitly check for changing codec id
> only ac3 and mpeg2 seem to set the codec id at all
> 
> which parser becomes inconsistent with itself when changing codec id ?

I guess the gsm parser, as the blocksize is not updated once it is set,
but different between gsm and gsm_ms.

>> It's hard to tell without samples.
> making samples should be as easy as concatenating 2 streams if
> someone wants to check what happens exactly

I tried a few possibly interesting cases, but in no case could I trigger
the added calls to av_parser_close for codec_ids of the same parser.
Nonetheless, some like mp2/mp3 worked just fine, while e.g. gsm/gsm_ms
broke badly.

Best regards,
Andreas


More information about the ffmpeg-devel mailing list