On Sat, 20 Jan 2024, 6:09 pm Steven Liu, <lingjiujianke@gmail.com> wrote:

Dennis Mungai <dmngaie@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.

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

Dennis Mungai <dmngaie@gmail.com>于2024年1月20日 周六23:15写道：

...

On Sat, 20 Jan 2024, 6:09 pm Steven Liu, <lingjiujianke@gmail.com> wrote:

...

Dennis Mungai <dmngaie@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.

On Mon, 22 Jan 2024 at 13:10, Steven Liu <lingjiujianke@gmail.com> wrote:

Dennis Mungai <dmngaie@gmail.com> 于2024年1月21日周日 00:42写道：

...

...

Perfect, and thanks for considering a revert of this deprecated feature.

Hi Dennis,

Need more talk, Why don't try to use hls_flags +delete_segments+append_list. ?

Thanks Steven

As stated earlier, even with these flags, we cannot replicate the advantage of the deprecated -hls_wrap whereby the segment names remain constant. append_list only omits the #EXT-EXT-ENDLIST tag.