[FFmpeg-devel] [PATCH v2] avformat/mpegts: set data broadcast streams as such

[Jan Ekström]

On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström <jeebjp at gmail.com> wrote:
>
> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint <cus at passwd.hu> wrote:
> >
> >
> >
> > On Thu, 14 Apr 2022, Jan Ekström wrote:
> >
> > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström <jeebjp at gmail.com> wrote:
> > >>
> > >> From: Jan Ekström <jan.ekstrom at 24i.com>
> > >>
> > >> Additionally, they should not be probed, as this is essentially
> > >> various types of binary data.
> > >>
> > >> Signed-off-by: Jan Ekström <jan.ekstrom at 24i.com>
> > >> ---
> > >
> > > Ping.
> > >
> > > Basically this checks if we have an unknown stream with a private
> > > stream type still at the end of the per-stream loop in PMT parsing,
> > > and then cancels the stop of parsing that usually occurs as a PMT is
> > > hit. Instead the logic will continue parsing further. When an SDT is
> > > then found and a PMT for that program has already been received, it
> > > will then stop header reading at that point.
> >
> > But why does it matter when the initial parsing is stopped? I mean it
> > stops at the first PMT right now, nobody expects it to find all the
> > programs and all the streams or all the stream codecs/parameters.
> >
> > I am saying, that ideally, the ts->stop_parse magic should not be needed
> > to be changed to fix your issue and when an SDT is detected with the
> > broadcast descriptor that should stop any existing data stream parsing. Do
> > you know why it does not work like that?
> >
>
> If the codec is unknown after header parsing, the general parsing
> logic is utilized to probe which codec is possibly in that unknown
> stream, and thus more data is read from that stream, which can cause
> further delays.
>
> If the codec is known as data, it leads to no such result.
>
> Basically, the idea is to figure out whether a stream is a data stream
> or not during header parsing, if possible.
>

Just double-checked and the difference is whether
max_stream_analyze_duration gets utilized in
libavformat/demux.c::avformat_find_stream_info .

If a stream is marked as unknown, it will get checked for longer. If
it is marked as a known "codec" it gets through quicker.

You can check an example locally with multicat:

There is a longer sample from an example stream under:
https://megumin.fushizen.eu/samples/2022-02-04-radio_with_data_stream/
with the files
13699753.{ts,aux}

You can then
`multicat -U ./13699753.ts "239.255.1.1:6001 at 127.0.0.1/ifaddr=127.0.0.1"`
and that should bind & connect and start pushing out UDP multicast via
localhost, using the aux file as timing.

Then you can with f.ex. ffprobe do
`/usr/bin/time -v ffprobe -v verbose -localaddr 127.0.0.1
udp://239.255.1.1:6001`
and compare the probe times with and without SDT being parsed during
the header read :) .

Jan