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

[Marton Balint <cus@passwd.hu>]

On Tue, 19 Apr 2022, Jan Ekström wrote:

> On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström <jeebjp@gmail.com> wrote:
>>
>> On Tue, Apr 19, 2022 at 3:00 AM Marton Balint <cus@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@gmail.com> wrote:
>> > >>
>> > >> From: Jan Ekström <jan.ekstrom@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@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.

The part of the patch which parses the SDT and sets the codec is fine. 
But the fact that you have to set the codec during mpegts_read_header 
to make it stop parsing definitely looks like some bug in some code 
somewhere. It should be enough to set the codec sometime later in 
mpegts_read_packet() (which is called during avformat_find_stream_info())

Or to make it even more strange: comment out handle_packets() in 
mpegts_read_header. And it will work just fine. So if nothing is parsed 
in mpegts_read_header then it works. If something is parsed, then it does 
not. Kind of unexpected...

Regards,
Marton

>
> 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@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
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".