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

Tao Zhang nowerzt at gmail.com
Thu Apr 30 11:17:56 EEST 2020


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.
>
> >>
> >> >>
> >> >> 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 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".


More information about the ffmpeg-devel mailing list