[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