On Sat, 2 May 2020, Tao Zhang wrote:
Marton Balint <c...@passwd.hu> 于2020年5月1日周五 下午9:35写道：
On Thu, 30 Apr 2020, Tao Zhang wrote:
> Andreas Rheinhardt <andreas.rheinha...@gmail.com> 于2020年4月30日周四 下午4:23写道：
>>
>> Tao Zhang:
>> > Marton Balint <c...@passwd.hu> 于2020年4月30日周四 下午3:26写道：
>> >>
>> >>
>> >>
>> >> On Thu, 30 Apr 2020, Tao Zhang wrote:
>> >>
>> >>> Marton Balint <c...@passwd.hu> 于2020年4月30日周四 上午4:55写道：
>> >>>>
>> >>>>
>> >>>>
>> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote:
>> >>>>
>> >>>>> Marton Balint <c...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
