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

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

[Dennis Mungai]

Hello,

Is there a valid technical reason as to why FFmpeg's HLS muxer dropped the
hls_wrap option?
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.
_______________________________________________
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".

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

[Steven Liu]

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

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

[Dennis Mungai]

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.

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

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

[Steven Liu]

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

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

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

[Dennis Mungai]

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

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

[Steven Liu]

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

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

[Dennis Mungai]

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

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

[Steven Liu]

Dennis Mungai <dmngaie@gmail.com>于2024年1月22日 周一18:20写道：

> 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

No I don‘t think that is advantage, because hls_wrap can cover the old
segments with same segment file name.
And the deprecated warning has been there more than five years I think.

>
> of the deprecated -hls_wrap whereby the segment names remain constant.
> append_list only omits the #EXT-EXT-ENDLIST tag.




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

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

[Zhao Zhili]

> On Jan 22, 2024, at 18:20, Dennis Mungai <dmngaie@gmail.com> wrote:
> 
> 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.

The hls_wrap conflicts with current HLS specification, which add the restriction
at 2014. The specification explicitly says "EXT-X-MEDIA-SEQUENCE tag MUST
NOT decrease or wrap". So hls_wrap can’t be reverted.

Try what Steven suggests, or figure out a better idea than revert hls_wrap.

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