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

Dennis Mungai dmngaie at gmail.com
Sat Jan 20 17:14:49 EET 2024


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

>


More information about the ffmpeg-devel mailing list