[FFmpeg-devel] [PATCH 0/3] Patch set to delay output live stream

[Marton Balint]

On Sat, 2 May 2020, Tao Zhang wrote:

> Marton Balint <cus at passwd.hu> 于2020年5月1日周五 下午9:35写道：
>>
>>
>>
>> On Thu, 30 Apr 2020, Tao Zhang wrote:
>>
>> > Andreas Rheinhardt <andreas.rheinhardt at gmail.com> 于2020年4月30日周四 下午4:23写道：
>> >>
>> >> Tao Zhang:
>> >> > Marton Balint <cus at passwd.hu> 于2020年4月30日周四 下午3:26写道：
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote:
>> >> >>
>> >> >>> Marton Balint <cus at passwd.hu> 于2020年4月30日周四 上午4:55写道：
>> >> >>>>
>> >> >>>>
>> >> >>>>
>> >> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote:
>> >> >>>>
>> >> >>>>> Marton Balint <cus at passwd.hu> 于2020年4月30日周四 上午12:03写道：
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Wed, 29 Apr 2020, leozhang wrote:
>> >> >>>>>>
>> >> >>>>>>> In some applications, it is required to add delay to live streaming.
>> >> >>>>>>
>> >> >>>>>> In what applications? And if you do this, why not run
>> >> >>>>>>
>> >> >>>>>> sleep 20; ffmpeg ....
>> >> >>>>> In live streaming applications, someone wouldn't want broadcast what's
>> >> >>>>> comming next immediately.
>> >> >>>>> Sleep 20 then ffmpeg is not ok, because the stream is still
>> >> >>>>> broadcasting immediately, and lost 20 seconds signal.
>> >> >>>>
>> >> >>>> So you want to buffer 20 seconds of input, and then start the output?
>> >> >>> yes
>> >> >>
>> >> >> Then your timing based approach is not the best way to do that. What you
>> >> >> want is a buffer fullness based approach. E.g. somewhere in the chain of
>> >> >> ffmpeg components you want to have a fixed buffer size of 20 seconds of
>> >> >> data, which is always kept filled.
>> >> > I don't think bitstream filter can have a buffer which is always
>> >> > filled with 20 seconds data, because bitstream filter don't handle
>> >> > timestamp or time base.
>> >> > Feel free to point out if I have wrong understanding about bitstream filter.
>> >>
>> >> Indeed you have. Your understanding seems to be based on the old
>> >> bitstream filter API, the one before
>> >> 33d18982fa03feb061c8f744a4f0a9175c1f63ab (from November 2013).
>> > Learned it.
>> > One question I met is the actual muxer (not fifo proxy muxer)
>> > write_header function should be called after the delay, seems that I
>> > can not achieve it by the bitstream filter in a clean way.
>>
>> Yes, ffmpeg.c does not delay writing the header until the first
>> packet. Ideally ffmpeg.c code should be unlcuttered to be able to delay
>> writing the header at least until the first packet arrives, but it
>> seems to me that would require quite a bit of nontrivial ffmpeg.c
>> refactoring.
>>
>> Is it a big issue if writing the header is not delayed? Also the fifo code
>> has the abilty to retry if the RTMP strem times out or whatever, can't
>> that be used to work around this?
> Establishing the connection too early, but not pushing the data will
> cause the end user's player buffer to freeze.

I see. But you could add an option to the fifo muxer to only write header 
when the first packet arrives. This way you will be able to use a 
bitstream filter to buffer packets and the fifo muxer will only write 
header when the first packet passes through the bitstream filter. Does 
this seem OK?

Thanks,
Marton