On Thu, Dec 5, 2024 at 2:29 PM Nicolas Gaullier <nicolas.gaullier@cji.paris> wrote: > > >De : Kieran Kunhya <kieran...@googlemail.com> > >Envoyé : mercredi 4 décembre 2024 23:06 > > > >> - a s337m decoder: it includes a resampler: output and input sample_rate > >> are the same, sync is always correct. It would be possible to implement > >> a full pcm fallback, but currently only a silence/pcm fallback is > >> provided. A 'passthrough' option is also provided and would make it > >> possible to mux again into wav, mxf or whatever. I guess one could > >> imagine a bitstream filter to fix the s337m phase to a clean, fixed > >> offset value (as expected by the current s337m demuxer for example). > > > >I don't understand how you can resample non-PCM data. > > > >Also the rest of the changes seem to avoid the actual issue which is > >you want the Dolby E decoder in FFmpeg to output a 1601/1602 cadence > >after resampling back to 48000. > >I also have seen a lot of Dolby E streams in the wild that where the > >Dolby E packet crosses a video frame. There is an ambiguity in PTS in > >this case, do you go forwards or go backwards (FYI in Upipe we go > >backwards) > > > >Kieran > > I resample the decoded data. The s337m decoder requires the dolby_e decoder > (same way the current ftr decoder requires the aac decoder, so should not be > an issue).
Why not just send the packet with the actual PTS (including the guard band) to Dolby E and then resample there? The resampler needs to handle the NTSC 1601/1602 cadence. Kieran _______________________________________________ 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".
