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 881AC49D96 for ; Mon, 11 Mar 2024 14:03:25 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 619FB68D04F; Mon, 11 Mar 2024 16:03:24 +0200 (EET) Received: from mail8.parnet.fi (mail8.parnet.fi [77.234.108.134]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 86BBF68CBBC for ; Mon, 11 Mar 2024 16:03:17 +0200 (EET) Received: from mail9.parnet.fi (mail9.parnet.fi [77.234.108.21]) by mail8.parnet.fi with ESMTP id 42BE3GEd028572-42BE3GEe028572 for ; Mon, 11 Mar 2024 16:03:16 +0200 Received: from cone.home.martin.st (host-114-191.parnet.fi [77.234.114.191]) by mail9.parnet.fi (Postfix) with ESMTPS id 9A6D8A1467; Mon, 11 Mar 2024 16:03:16 +0200 (EET) Date: Mon, 11 Mar 2024 16:03:15 +0200 (EET) To: FFmpeg development discussions and patches , FFmpeg development discussions and patches In-Reply-To: <171016369568.662.8737080358093163641@lain.khirnov.net> Message-ID: <9140cb3e-af72-8a9a-c4-366bf7ae27a0@martin.st> References: <20240306110319.17339-1-anton@khirnov.net> <20240306110319.17339-2-anton@khirnov.net> <20240307203739.GI6420@pb2> <170987607651.7287.4766174024309496140@lain.khirnov.net> <20240310033629.GM6420@pb2> <171005119864.662.10837664362214202636@lain.khirnov.net> <20240310192147.GQ6420@pb2> <171010947057.7287.8642196154964262055@lain.khirnov.net> <7d011f1c-f131-412c-85ce-318c71efba0f@gmail.com> <171011095238.7287.16406128798977096207@lain.khirnov.net> <8e8947e3-b54b-4ce7-864a-13ccf4c4bfd3@noa-archive.com> <171015983262.662.304106510805949905@lain.khirnov.net> <9a7a9c5f-f377-bca8-26e1-6bfe12589ed2@martin.st> <171016369568.662.8737080358093163641@lain.khirnov.net> MIME-Version: 1.0 X-FEAS-Client-IP: 77.234.108.21 X-FE-Last-Public-Client-IP: 77.234.108.21 X-FE-Policy-ID: 3:14:2:SYSTEM Subject: Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase 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: , From: =?utf-8?q?Martin_Storsj=C3=B6_via_ffmpeg-devel?= Reply-To: FFmpeg development discussions and patches Cc: =?ISO-8859-15?Q?Martin_Storsj=F6?= 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 Mon, 11 Mar 2024, Anton Khirnov wrote: >> I think the point is, that one can't just dismiss that anybody would want >> to encode mpeg4 video any longer, even if it is obsolete. I also would >> like to keep being able to do that. > > That capability is not going away though, and I'm not arguing that it > should. Ok, good. The generally dismissive arguments about mpeg4 encoding being obsolete and something that nobody should be doing, could be interpreted in such a way. >> That said, I haven't followed the discussion closely enough about what to >> do with the time bases. > > The only change is that in some rare cases the automatically selected > timebase no longer fits into mpeg4 constraints, so the user has to > specify either the framerate or the timebase explicitly. Right, I see. > Specifically, the commandline used by Michael involves the extremely > obscure case of converting subtitles to video (NOT harsubbing, but > really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to > AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4 > encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1 > video), the input video timebase should be used, which would probably > work. > > I don't think it's that big of a deal to require users to specify the > timebase or framerate explicitly in such a sitation. > Inventing new APIs to cover it automagically seems like a waste of time, > unless somebody has actual (not potential) uses for this. Right, I would agree with this. (If someone else would volunteer to add said API I would consider accepting it though.) Is this a usecase that currently works, but would be go away by getting rid of codec specific code in the tools, or is it a nice-to-have new extra feature that is being requested? // Martin _______________________________________________ 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".