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

[Marton Balint]

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?

Regards,
Marton