[FFmpeg-devel] [PATCH 0/7] RFC: complete rework of s337m support

[Kieran Kunhya]

On Thu, Dec 5, 2024 at 2:29 PM Nicolas Gaullier
<nicolas.gaullier at cji.paris> wrote:
>
> >De : Kieran Kunhya <kieran618 at 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