On Tue, Apr 19, 2022 at 1:13 PM Jan Ekström <jee...@gmail.com> wrote: > > On Tue, Apr 19, 2022 at 3:00 AM Marton Balint <c...@passwd.hu> wrote: > > > > > > > > On Thu, 14 Apr 2022, Jan Ekström wrote: > > > > > On Mon, Apr 11, 2022 at 1:50 PM Jan Ekström <jee...@gmail.com> wrote: > > >> > > >> From: Jan Ekström <jan.ekst...@24i.com> > > >> > > >> Additionally, they should not be probed, as this is essentially > > >> various types of binary data. > > >> > > >> Signed-off-by: Jan Ekström <jan.ekst...@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@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-requ...@ffmpeg.org with subject "unsubscribe".