From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 9C0C444232 for ; Fri, 2 Dec 2022 04:11:55 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id A2C9B68BA90; Fri, 2 Dec 2022 06:11:52 +0200 (EET) Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id CF0A368B068 for ; Fri, 2 Dec 2022 06:11:45 +0200 (EET) Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4NNfdm2Sn4z9sTM for ; Fri, 2 Dec 2022 05:11:40 +0100 (CET) Message-ID: Date: Fri, 2 Dec 2022 09:41:21 +0530 MIME-Version: 1.0 To: ffmpeg-devel@ffmpeg.org References: <20221201214029.24352-1-chris.ribble@resi.io> <376429bd-4154-a51d-7127-b69057b69934@passwd.hu> Content-Language: en-US From: Gyan Doshi In-Reply-To: Subject: Re: [FFmpeg-devel] [PATCH] Revert "avformat/mov: disallow a zero sample size in trun atoms" 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 2022-12-02 06:16 am, Chris Ribble wrote: > On Thu, Dec 1, 2022 at 4:51 PM Marton Balint wrote: >> Can you explain why those files are considered valid, or why it makes >> sense to generate such files? >> >> Thanks, >> Marton >> > As far as I can tell, the file that a user provided with this problem > was generated by an encoder (running FFmpeg 3.4) that started writing > zero-sized samples when their video switcher + capture card stopped > receiving audio input. I'm not arguing that it's good for files to be > generated like this, but it's nice for FFmpeg to be able to process > them all the same (i.e. the robustness principle). > > With this patch reverted, FFmpeg can accept an input file that is > partially broken (with playback anomalies due to the presence of > zero-sized samples) and produce a valid, working output mp4 (or DASH > stream), just like it could in release 5.0 and older. > > One of the best things about FFmpeg is that it can fix invalid > container metadata. I feel like losing that capability for this > scenario is a regression. FWIW, we don't discard regular MP4s with sample entries of 0 in stts, which is only permitted for the last solo sample in a track. So, I agree. Regards, Gyan _______________________________________________ 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".