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. > > >> > >> >> > >> >> I don't see how this is useful at all. > >> >> > >> >> And what is -paced? What it is used for? Isn't it the same as using > >> >> ffmpeg > >> >> -re? You really should better explain your use case. > >> > -re read the input, -paced write the output. > >> > >> But why do you want to delay every output packet? > > By default, ffmpeg will output packets as fast as possible. > > So I delay output every packet at native frame rate to simulate live stream. > > So you want realtime output. But since I guess your input is already > realtime, it is suboptimal to limit processing to realtime in two places, > you want to simply FIFO buffer 20 seconds of data in an ffmpeg component. > > The best place for that may not be the fifo muxer. I'd say maybe a > separate bitstream filter is the most clean solution to achieve that. But > others may have something else in mind. ditto > > 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".