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. > > Regards, > 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". _______________________________________________ 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".