Re: [FFmpeg-devel] [PATCH 05/10] doc/muxers: Add documentation for segment_limit option

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Marton Balint
> Sent: Freitag, 13. Juni 2025 22:26
> To: FFmpeg development discussions and patches <ffmpeg-
> devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 05/10] doc/muxers: Add
> documentation for segment_limit option
> 
> 
> 
> On Fri, 13 Jun 2025, softworkz wrote:
> 
> > From: softworkz <softworkz@hotmail.com>
> >
> > Signed-off-by: softworkz <softworkz@hotmail.com>
> > ---
> > doc/muxers.texi | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index 6d5c17b4cc..1cca8da1fb 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -3510,6 +3510,13 @@ packet written. Defaults to @code{0}.
> > Write segments to files with a .tmp extension. Each file is
> renamed to its
> > actual name on completion. This can help to prevent segment files
> from
> > being accessed before they are complete. Disabled by default
> (@code{0}).
> > +
> > +@item segment_limit @var{number}
> > +Stops after the specified number of segments has been generated.
> > +This can be helpful to fill gaps in a range of already generated
> segments,
> > +which is difficult to achieve otherwise as it would either cause
> the last
> > +segment to be incomplete or to overwrite an existing segment
> with a partial
> > +data. Default is @code{0} - no limit.

Hi Marton,

thanks a lot for reviewing.

> You can merge the documentation patch with the feature patch, there
> is no
> need to split.

Sure, will do that - I just never know which way is right.


> What is not quite clear is that what is going to happen to the
> surplus
> data at after the last segment? Is it silently dropped? Because
> that would be unacceptable IMHO.

Well, that's the whole point of the feature. FFmpeg will stop as 
soon as the specified number of segments has been generated.

(Please note, that the default is 0, which means that nothing is 
dropped and there's no change in behavior when it's 0).

Probably it's best to look at an example. Let's say we have:

- a 300s video
- that we want to stream via HLS
- Segment-Duration: 3s - makes 100 segments
- Now we want to create the segments on-demand only,
  so we deliver a synthetic playlist with 100 3s segments, 
  even though we don't have any segment yet
- Once specific segments are needed, we create them on-the-fly

That's a situation that the commit message is about:

Existing segments 0-30 and 70-99 => we already have them on disk

31-69 need to be created

This option allows to stop precisely after 69. 
Otherwise, it would start overwriting segment 70 before stopping 
via 'q' or break signal.

So, in order to generate segments 31-69, you will set 
segment_start_number to 31 and the segment_limit to 38.
This causes the muxer to write and complete segment 69
in the exact same way like when it would be creating segment
70, but without starting to write segment 70 - which would destroy
the existing segment 70 (which is good already).

Thanks and best regards,
sw

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