[FFmpeg-devel] FFmpeg's HLS muxer's deprecation of the hls_wrap option

Dennis Mungai dmngaie at gmail.com
Sat Jan 20 18:41:45 EET 2024


On Sat, 20 Jan 2024 at 18:42, Steven Liu <lingjiujianke at gmail.com> wrote:

> Dennis Mungai <dmngaie at gmail.com>于2024年1月20日 周六23:15写道:
>
> > On Sat, 20 Jan 2024, 6:09 pm Steven Liu, <lingjiujianke at gmail.com>
> wrote:
> >
> > > Dennis Mungai <dmngaie at gmail.com>于2024年1月20日 周六21:02写道:
> > >
> > > > Hello,
> > > >
> > > > Is there a valid technical reason as to why FFmpeg's HLS muxer
> dropped
> > > the
> > > > hls_wrap option?
> > >
> > >
> > > eg. three player playing the list and every fragment less or equal 1
> > second
> > > ,
> > > 1. Player 1 from fragment1, fragment2
> > > 2. Now Player 2 from fragment 1, fragment 2,
> > > 3. Now Player 3 from fragment 1, Fragment2 and Player 1 playing
> fragment
> > 3
> > > 4. Network transport with player 3 get loss packet
> > > 5. Player 1 playing new fragment 1, new fragment 2
> > > 6. Player 2 playing fragment 3
> > > 7. Player 3 blocking always because the fragments are flashing too
> fast.
> > >
> > > So the commit message said it is not friendly to downstream users.
> > >
> > > I have no more better way to fix it with ffmpeg, but I think that
> commit
> > > can be revert if you want use hls_wrap.
> > >
> > >
> > > > There are many cases where the hls_wrap option remains critical so as
> > to
> > > > preserve the set of output file names without increments. This
> > > deprecation
> > > > breaks that.
> > > >
> > > > For now, this behavior can be worked around by switching to the
> segment
> > > > muxer and then setting the -segment_wrap option therein, but its' not
> > an
> > > > ideal solution.
> > > >
> > > > Kindly review this deprecation, with an appeal to revert the
> patchwork
> > > that
> > > > removed the hls_wrap option.
> > > >
> > > > Warm regards,
> > > >
> > > > Dennis.
> > >
> >
> > Steven,
> >
> > The option should've been left intact, *but* with a warning on its
> > implications on usage.
>
> Dennis,
>
> agreed with you, let me think about that.
>
> > Multiple ffmpeg flags have similar edge case impacts
> > when used improperly, eg -copyts and non monotonous timestamps, but
> they're
> > not deprecated; they're still in place.
> >
> > >
>
>
> Thanks
> Steven
>
>
>
Perfect, and thanks for considering a revert of this deprecated feature.


More information about the ffmpeg-devel mailing list