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

[Tao Zhang]

Marton Balint <cus at passwd.hu> 于2020年5月2日周六 下午7:05写道：
>
>
>
> 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?
It seems OK. If nobody object it, I'm glad to add
write_header_on_first_packet option on fifo muxer and create a new
bitstream filter which buffers fixed duration packets.
>
> Thanks,
> 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".