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

[Tao Zhang]

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