> What is the issue that you are seeing and that this patch fix? Is it only > matters for low bitrate mpegts? (like 64 kbps streams?) Or does this > improve high bitrate streams as well somehow?
I'm muxing hevc video + very low bitrate binary messages into mpegts. If the hevc video is not present, I would have to buffer 8192 bytes of binary messages to get past mpegts_read_header, which was creating a large latency. This patch reduces the startup time. As you mentioned, it does not apply to high bitrate streams. Also in git history, I saw that the size of the buffer was changed in ad-hoc way from 1024 -> 5*1024-> 8 * 1024 because I assume probing failed in some cases. I feel that the proposed patch would be a better solution as it follows the same ideas when probing for unknown parameters in other parts of the code. Regards, Andriy On Tue, 5 Mar 2019 at 11:59, Marton Balint <c...@passwd.hu> wrote: > > > On Mon, 4 Mar 2019, andriy.gel...@gmail.com wrote: > > > From: Andriy Gelman <andriy.gel...@gmail.com> > > > > Reduces buffering during estimation of mpegts raw_packet_size > > parameter. Instead of buffering a fixed 8192 bytes, calculate > > probe scores on a smaller buffer. Increase buffer size until > > probe score is greater than minimum value. > > What is the issue that you are seeing and that this patch fix? Is it only > matters for low bitrate mpegts? (like 64 kbps streams?) Or does this > improve high bitrate streams as well somehow? > > Thanks, > Marton > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
