From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.ffmpeg.org (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTPS id 746344CEEA for ; Sat, 14 Jun 2025 16:02:53 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 16F6568CCF4; Sat, 14 Jun 2025 19:02:49 +0300 (EEST) Received: from iq.passwd.hu (iq.passwd.hu [217.27.212.140]) by ffbox0-bg.ffmpeg.org (Postfix) with ESMTP id 5ED0968C5C3 for ; Sat, 14 Jun 2025 19:02:41 +0300 (EEST) Received: from localhost (localhost [127.0.0.1]) by iq.passwd.hu (Postfix) with ESMTP id D0508E9EF1 for ; Sat, 14 Jun 2025 17:59:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at passwd.hu Received: from iq.passwd.hu ([127.0.0.1]) by localhost (iq.passwd.hu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJVAMp8LTEBd for ; Sat, 14 Jun 2025 17:59:43 +0200 (CEST) Received: from iq (iq [217.27.212.140]) by iq.passwd.hu (Postfix) with ESMTPS id 3A9F4E9EEB for ; Sat, 14 Jun 2025 17:59:43 +0200 (CEST) Date: Sat, 14 Jun 2025 17:59:43 +0200 (CEST) From: Marton Balint To: FFmpeg development discussions and patches In-Reply-To: Message-ID: <4e2b3b0c-27ea-c803-b2d5-4dc8bc602a18@passwd.hu> References: <53b693320f1cf07ee6094342a60002bc9cfc3d79.1749794067.git.ffmpegagent@gmail.com> <764ebc53-28d4-8671-117b-d76b453770b9@passwd.hu> MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH 05/10] doc/muxers: Add documentation for segment_limit option X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On Fri, 13 Jun 2025, softworkz . wrote: [...] >>> (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). >> >> Buy you have to seek in the input to achieve that, don't you? And >> you can >> just as easily specify the input duration to not overwrite segment >> 70... > > Here we're getting at the core of the problem: When specifying -to or > a duration, you cannot achieve the exact same "cut" like the segment > muxer does it. It usually cuts by video key frames. And when it does > the cut it also cuts all other streams at that moment. Timestamp > offsets between video and audio are common, often the audio is > somewhat ahead of the video (specifically in case of TV broadcast > streams), but it varies. Also, when transcoding before segmenting, > it's not easy to predict the exact video key frame times. > > For each segment n to segment n+1 the cut must be done in a way > that for each stream, there is neither a duplicate nor a missing > frame. That is what makes it non-trivial. > > In the end, it always comes down to the same conclusion: the only > way to get the exact same cut point through all streams like the > segment muxer does it - is to let the segment muxer do it. > > At least that was my conclusion from intensive work on this, some > years ago. But this is also a problem for the first segment. You can set segment_start_number to 31, but you still have to know where to seek exactly, because setting segment_start_number alone won't make the segment muxer "ignore" data for the first 30 segments... So what does not make sense to me is that you want to rely on segment muxer behaviour for ending the segments, but not for starting them. The way I see it you either know exactly where the segments supposed to start and end, in which case you don't really need this option, because you can set -ss and -to as you need. Or you don't, in which case this option alone won't help you. > > > >> If you want to implement the segment limit, you have to make sure >> the >> ffmpeg encoding process stops after the last segment. One idea is >> to >> return an error if the segment limit is reached. > > Maybe an EOF/EOS error? I am not sure if it is legal for a muxer to return AVERROR_EOF... Maybe I'd simply return AVERROR_INVALIDDATA. Another possibility is that if you limit the number of segments, then you make all remaining data go to the last segment. I don't know if that helps or hurts any actual use case :) Regards, Marton > > > Thanks, > 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". > _______________________________________________ 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".