Quoting Andreas Rheinhardt (2022-08-24 16:20:35) > Anton Khirnov: > > Demuxers are not allowed to do this and few callers, if any, will handle > > this correctly. Send the AV_SIDE_DATA_PARAM_CHANGE_SAMPLE_RATE side data > > instead. > > 1. One of the callers which did not handle this correctly is the mov > demuxer: A sample rate update would not propagate to the user, because > it uses a separate AVFormatContext for it. This should be mentioned in > the commit message. (Btw: I don't see anything that guarantees that the > samplerate and timebase of the inner demuxer and the sample rate and > time base reported to the user (presumably taken from mov structures) > coincide. Given that dv_fctx and dv_demux are part of MOVContext, they > would also leak if it would be attempted to allocate them multiple > times. Do you see anything that guarantees that they will not be > allocated multiple times?) > 2. In case of ff_add_param_change() failure, users will just interpret > that as "no more packets available", won't they?
yes, I think so > This might be wrong, but it is not problematic. I agree > 3. Have you tested this with a sample with actual parameter changes? Yes, I made a sample by concatenating two dv files. The side data is exported correctly, but the PCM decoder fails because it is not marked with AV_CODEC_CAP_PARAM_CHANGE. Patches welcome. -- Anton Khirnov _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
