| Message ID | 1588166662-74153-1-git-send-email-leozhang@qiyi.com |
|---|---|
| Headers | show |
| Series | Patch set to delay output live stream | expand |
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 .... 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. Regards, Marton > For example, you can add 20 seconds to rtmp stream with below command: > ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 > -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name > > leozhang (3): > avformat/fifo: add option to delay output > avformat/fifo: add option to write packets in paced way > doc/muxers: add command example how to delay output live stream > > doc/muxers.texi | 17 +++++++++++++++++ > libavformat/fifo.c | 26 ++++++++++++++++++++++++++ > 2 files changed, 43 insertions(+) > > -- > 1.8.3.1 > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Marton Balint <cus@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. > > 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. > > Regards, > Marton > > > For example, you can add 20 seconds to rtmp stream with below command: > > ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 > > -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name > > > > leozhang (3): > > avformat/fifo: add option to delay output > > avformat/fifo: add option to write packets in paced way > > doc/muxers: add command example how to delay output live stream > > > > doc/muxers.texi | 17 +++++++++++++++++ > > libavformat/fifo.c | 26 ++++++++++++++++++++++++++ > > 2 files changed, 43 insertions(+) > > > > -- > > 1.8.3.1 > > > > _______________________________________________ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe".
On Thu, 30 Apr 2020, Tao Zhang wrote: > Marton Balint <cus@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? >> >> 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? >> >> Regards, >> Marton >> >> > For example, you can add 20 seconds to rtmp stream with below command: >> > ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 >> > -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name >> > >> > leozhang (3): >> > avformat/fifo: add option to delay output >> > avformat/fifo: add option to write packets in paced way >> > doc/muxers: add command example how to delay output live stream >> > >> > doc/muxers.texi | 17 +++++++++++++++++ >> > libavformat/fifo.c | 26 ++++++++++++++++++++++++++ >> > 2 files changed, 43 insertions(+) >> > >> > -- >> > 1.8.3.1 >> > >> > _______________________________________________ >> > ffmpeg-devel mailing list >> > ffmpeg-devel@ffmpeg.org >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> > >> > To unsubscribe, visit link above, or email >> > ffmpeg-devel-request@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-request@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-request@ffmpeg.org with subject "unsubscribe".
Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > > > > On Thu, 30 Apr 2020, Tao Zhang wrote: > > > Marton Balint <cus@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 > > >> > >> 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. > > >> > >> Regards, > >> Marton > >> > >> > For example, you can add 20 seconds to rtmp stream with below command: > >> > ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 > >> > -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name > >> > > >> > leozhang (3): > >> > avformat/fifo: add option to delay output > >> > avformat/fifo: add option to write packets in paced way > >> > doc/muxers: add command example how to delay output live stream > >> > > >> > doc/muxers.texi | 17 +++++++++++++++++ > >> > libavformat/fifo.c | 26 ++++++++++++++++++++++++++ > >> > 2 files changed, 43 insertions(+) > >> > > >> > -- > >> > 1.8.3.1 > >> > > >> > _______________________________________________ > >> > ffmpeg-devel mailing list > >> > ffmpeg-devel@ffmpeg.org > >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > >> > To unsubscribe, visit link above, or email > >> > ffmpeg-devel-request@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-request@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-request@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-request@ffmpeg.org with subject "unsubscribe".
Tao Zhang: > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >>> Marton Balint <cus@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 >> >>>> >>>> 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. What would be the benefit of your patch for API users (i.e. users that directly use libavformat and not ffmpeg.c)? Right now your problem seems to be in ffmpeg.c and not in libavformat. >> >>>> >>>> Regards, >>>> Marton >>>> >>>>> For example, you can add 20 seconds to rtmp stream with below command: >>>>> ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 >>>>> -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name >>>>> >>>>> leozhang (3): >>>>> avformat/fifo: add option to delay output >>>>> avformat/fifo: add option to write packets in paced way >>>>> doc/muxers: add command example how to delay output live stream >>>>> >>>>> doc/muxers.texi | 17 +++++++++++++++++ >>>>> libavformat/fifo.c | 26 ++++++++++++++++++++++++++ >>>>> 2 files changed, 43 insertions(+) >>>>> >>>>> -- >>>>> 1.8.3.1 >>>>>
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午1:45写道： > > Tao Zhang: > > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > >> > >> > >> > >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> > >>> Marton Balint <cus@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 > >> > >>>> > >>>> 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. > > What would be the benefit of your patch for API users (i.e. users that > directly use libavformat and not ffmpeg.c)? Right now your problem seems > to be in ffmpeg.c and not in libavformat. API users can use the fifo psedo muxer directly, without implementing the similar functions by themself. > >> > >>>> > >>>> Regards, > >>>> Marton > >>>> > >>>>> For example, you can add 20 seconds to rtmp stream with below command: > >>>>> ffmpeg -i your_input_stream_address -c copy -map 0:a -map 0:v -f fifo -paced 1 -queue_size 6000000 > >>>>> -output_delay 20000000 -fifo_format flv rtmp://example.com/live/delayed_stream_name > >>>>> > >>>>> leozhang (3): > >>>>> avformat/fifo: add option to delay output > >>>>> avformat/fifo: add option to write packets in paced way > >>>>> doc/muxers: add command example how to delay output live stream > >>>>> > >>>>> doc/muxers.texi | 17 +++++++++++++++++ > >>>>> libavformat/fifo.c | 26 ++++++++++++++++++++++++++ > >>>>> 2 files changed, 43 insertions(+) > >>>>> > >>>>> -- > >>>>> 1.8.3.1 > >>>>> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Thu, 30 Apr 2020, Tao Zhang wrote: > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >> > Marton Balint <cus@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 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. Regards, Marton
Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： > > > > On Thu, 30 Apr 2020, Tao Zhang wrote: > > > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > >> > >> > >> > >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> > >> > Marton Balint <cus@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-request@ffmpeg.org with subject "unsubscribe".
Tao Zhang: > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： >>>> >>>> >>>> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: >>>> >>>>> Marton Balint <cus@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). - Andreas
Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午4:23写道： > > Tao Zhang: > > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： > >> > >> > >> > >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> > >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > >>>> > >>>> > >>>> > >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: > >>>> > >>>>> Marton Balint <cus@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. > > - Andreas > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On Thu, 30 Apr 2020, Tao Zhang wrote: > Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午4:23写道： >> >> Tao Zhang: >> > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： >> >> >> >> >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >> >> >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： >> >>>> >> >>>> >> >>>> >> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >>>> >> >>>>> Marton Balint <cus@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? Regards, Marton
Marton Balint <cus@passwd.hu> 于2020年5月1日周五 下午9:35写道： > > > > On Thu, 30 Apr 2020, Tao Zhang wrote: > > > Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午4:23写道： > >> > >> Tao Zhang: > >> > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： > >> >> > >> >> > >> >> > >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> >> > >> >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> >>>> > >> >>>>> Marton Balint <cus@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-request@ffmpeg.org with subject "unsubscribe".
On Sat, 2 May 2020, Tao Zhang wrote: > Marton Balint <cus@passwd.hu> 于2020年5月1日周五 下午9:35写道： >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >> > Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午4:23写道： >> >> >> >> Tao Zhang: >> >> > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： >> >> >> >> >> >> >> >> >> >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >> >> >> >> >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: >> >> >>>> >> >> >>>>> Marton Balint <cus@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
Marton Balint <cus@passwd.hu> 于2020年5月2日周六 下午7:05写道： > > > > On Sat, 2 May 2020, Tao Zhang wrote: > > > Marton Balint <cus@passwd.hu> 于2020年5月1日周五 下午9:35写道： > >> > >> > >> > >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> > >> > Andreas Rheinhardt <andreas.rheinhardt@gmail.com> 于2020年4月30日周四 下午4:23写道： > >> >> > >> >> Tao Zhang: > >> >> > Marton Balint <cus@passwd.hu> 于2020年4月30日周四 下午3:26写道： > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> >> >> > >> >> >>> Marton Balint <cus@passwd.hu> 于2020年4月30日周四 上午4:55写道： > >> >> >>>> > >> >> >>>> > >> >> >>>> > >> >> >>>> On Thu, 30 Apr 2020, Tao Zhang wrote: > >> >> >>>> > >> >> >>>>> Marton Balint <cus@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-request@ffmpeg.org with subject "unsubscribe".
On Sat, 2 May 2020, Tao Zhang wrote: > Marton Balint <cus@passwd.hu> 于2020年5月2日周六 下午7:05写道： [...] >> 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. Great. I suggest a shorter name for the option of the fifo muxer, delay_write_header I think is enough, you can explain the details in the docs. Also it should be pretty straightforward to add this feature to fifo.c, from a quick look at the code one approach is to add a NOOP message type, and if the option is set, then use that message type for the first message, if it is not set, use the WRITE_HEADER message type, as it is used now. Also we should find a good name for the bitstream filter, maybe "buffer", or "fifo", or if you want to better refer to the use case, then "timeshift" can also work. Another thing you should think about is what should happen at the end of the stream, when flushing the bitstream filter: - drop pending packets - flush pending packets as fast as possible - flush pendning packets realtime Maybe it should be selectable between the 3 options? I can imagine use cases for all three possibilities. Thanks, Marton
Marton Balint <cus@passwd.hu> 于2020年5月5日周二 上午3:48写道： > > > > On Sat, 2 May 2020, Tao Zhang wrote: > > > Marton Balint <cus@passwd.hu> 于2020年5月2日周六 下午7:05写道： > > [...] > > >> 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. > > Great. I suggest a shorter name for the option of the fifo muxer, > delay_write_header I think is enough, you can explain the details in the > docs. Great suggestion. I'll follow it. > > Also it should be pretty straightforward to add this feature to fifo.c, > from a quick look at the code one approach is to add a NOOP message type, > and if the option is set, then use that message type for the first > message, if it is not set, use the WRITE_HEADER message type, as it is > used now. > > Also we should find a good name for the bitstream filter, maybe "buffer", > or "fifo", or if you want to better refer to the use case, then > "timeshift" can also work. Maybe "caching" or "cache"? > > Another thing you should think about is what should happen at the end of > the stream, when flushing the bitstream filter: > - drop pending packets > - flush pending packets as fast as possible > - flush pendning packets realtime > Maybe it should be selectable between the 3 options? I can imagine use > cases for all three possibilities. Although I have not imagined the first and second use cases, I'm glad to implement all three. > > 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-request@ffmpeg.org with subject "unsubscribe".
On Tue, 5 May 2020, Tao Zhang wrote: > Marton Balint <cus@passwd.hu> 于2020年5月5日周二 上午3:48写道： >> >> >> >> On Sat, 2 May 2020, Tao Zhang wrote: >> >> > Marton Balint <cus@passwd.hu> 于2020年5月2日周六 下午7:05写道： >> >> [...] >> >> >> 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. >> >> Great. I suggest a shorter name for the option of the fifo muxer, >> delay_write_header I think is enough, you can explain the details in the >> docs. > Great suggestion. I'll follow it. >> >> Also it should be pretty straightforward to add this feature to fifo.c, >> from a quick look at the code one approach is to add a NOOP message type, >> and if the option is set, then use that message type for the first >> message, if it is not set, use the WRITE_HEADER message type, as it is >> used now. >> >> Also we should find a good name for the bitstream filter, maybe "buffer", >> or "fifo", or if you want to better refer to the use case, then >> "timeshift" can also work. > Maybe "caching" or "cache"? >> >> Another thing you should think about is what should happen at the end of >> the stream, when flushing the bitstream filter: >> - drop pending packets >> - flush pending packets as fast as possible >> - flush pendning packets realtime >> Maybe it should be selectable between the 3 options? I can imagine use >> cases for all three possibilities. > Although I have not imagined the first and second use cases, I'm glad > to implement all three. I have given the bitstream filter approach some additional thought and since each stream will have a different bitstream filter I think you will have problems when flushing them in ffmpeg.c because it will flush them sequentially, the packet interleaving will be something like - all remaining packets from the first stream - all remaining packets from the second stream ... etc. Which will cause issues at muxing the last part of the stream if the buffer duration is larger than a few seconds. Sorry, it looks like hacking the whole thing into fifo.c works the best after all. The only problem is that I don't see a clean way of doing that if you only want to enforce realtiem output there when flushing the buffered packets... Regards, Marton
Marton Balint: > > > On Tue, 5 May 2020, Tao Zhang wrote: > >> Marton Balint <cus@passwd.hu> 于2020年5月5日周二 上午3:48写道： >>> >>> >>> >>> On Sat, 2 May 2020, Tao Zhang wrote: >>> >>> > Marton Balint <cus@passwd.hu> 于2020年5月2日周六 下午7:05写道： >>> >>> [...] >>> >>> >> 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. >>> >>> Great. I suggest a shorter name for the option of the fifo muxer, >>> delay_write_header I think is enough, you can explain the details in the >>> docs. >> Great suggestion. I'll follow it. >>> >>> Also it should be pretty straightforward to add this feature to fifo.c, >>> from a quick look at the code one approach is to add a NOOP message >>> type, >>> and if the option is set, then use that message type for the first >>> message, if it is not set, use the WRITE_HEADER message type, as it is >>> used now. >>> >>> Also we should find a good name for the bitstream filter, maybe >>> "buffer", >>> or "fifo", or if you want to better refer to the use case, then >>> "timeshift" can also work. >> Maybe "caching" or "cache"? >>> >>> Another thing you should think about is what should happen at the end of >>> the stream, when flushing the bitstream filter: >>> - drop pending packets >>> - flush pending packets as fast as possible >>> - flush pendning packets realtime >>> Maybe it should be selectable between the 3 options? I can imagine use >>> cases for all three possibilities. >> Although I have not imagined the first and second use cases, I'm glad >> to implement all three. > > I have given the bitstream filter approach some additional thought and > since each stream will have a different bitstream filter I think you > will have problems when flushing them in ffmpeg.c because it will flush > them sequentially, the packet interleaving will be something like > - all remaining packets from the first stream > - all remaining packets from the second stream Maybe the custom interleavement functions should be split into one that does the "add packet to packet list" part and another one for "return packet from packet list"? This would allow to drain all the bsfs and to add all packets to the interleavement queue, before starting to output them. (This proposal would increase sizeof(AVOutputFormat) and would therefore cause problems when one uses a new libavformat together with an old libavdevice (despite no libavdevice muxer using custom interleavement functions). This could be solved by using a hack: We put the add packet function in place of the old interleave_packet() function and only ever check for the existence of the get_packet() function if the add_packet() function pointer is not NULL.) - Andreas PS: Nothing said above is intended to block your other patchset in any way. I just wanted to mention it because the current interleave_packet() functions are already naturally split into two independent parts.
Andreas Rheinhardt (12020-05-05): > (This proposal would increase sizeof(AVOutputFormat) and would therefore > cause problems when one uses a new libavformat together with an old > libavdevice (despite no libavdevice muxer using custom interleavement > functions) Can I count you among the developers who would be favorable to merging the shared objects to avoid gratuitous issues of ABI compatibility? Regards,