Marton Balint <c...@passwd.hu> 于2020年5月2日周六 下午7:05写道： > > > > 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? 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@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".
