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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
