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 D572340697 for ; Wed, 22 Dec 2021 13:29:14 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E6B2868B076; Wed, 22 Dec 2021 15:29:12 +0200 (EET) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11olkn2066.outbound.protection.outlook.com [40.92.20.66]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 523F268A306 for ; Wed, 22 Dec 2021 15:29:06 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H6XValsLObN14fkoWBk0G5BAPIELRj/wERbpE3jdOCNnx4GVxTHKrRKI47C4CJMMRkDOXpt6cogw+8tx2O8nimTiC1qtxIShgm54L9mwQYuqRkFl/n1WXZ6k+0CnlbPzD81w1fztolanCqfFy0SpfA2HaebUtE7BzfOwbyms4jwU08d61flpIVOc7nP0mkrnDdJdAHiKaKJiVJ9Wg4jTCm7rzmVBE1tbt6kAwTphqw4U0WwdA4Aes6SEU4AD+bAtDHB6PQFYyVMERgJIBQqVV8rKf++KXmJdl/rRg8GaqGO1UJxMcqG4M94Ks/4pc91YQ90dYRT9txFNQoPnnrWAWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=TkFi1spzGo78LA66yhDqGpAt73YgkpL0OorBb2r+mRE=; b=bZvwy7AkgSJPloryjF7U8wdBoJ6U3QEWk4wgHC2qYNCPOouk5vdmJ24kviUeMaMzW1Vtqvbyo/o3kuRktKZMM/in1JxOrfC9oNqYHLTk5QiV9HGSBK7LVMKJPCi/wEv//RxRoto0guPXvpMP7Mfs9PBjJB/xLOvZrTKsnb6d8i1yICDTL0jZZ8bexbn1vnI6uq13bKNJjCDtDJrEmaBg5za5+4WiC05HFi6CBrftnqdvSCiz9ifWWeROZFrO+XtETq+oQT18KZfOE8oRarLkH0dtUfafZUOxQBRwLwQT7rQQpcRncl57NsPLYnxCubEGsht4KiuePjOpx5y4W+of9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TkFi1spzGo78LA66yhDqGpAt73YgkpL0OorBb2r+mRE=; b=ZFqOu8qCIRFCVwTdurPJciSrQIgMsO/NZL7PvHKrjG4mRZoumpmoRFv4gCO9bcathPxVhwDF9ru9x3Yp65fIST1+ve8g0aUI5bszSH550qpNCUOM/pLg4XyPH2BP/T++sTq+ncgATjbNdgtIEi3o/fdhLFKUjpcO0vas0hKsMzswcuUrlfXCuDbZYuMSa2MGXX8Nmb46eWco6nAdjOCbX1/FcrT/PIYxH2GRuSooKhv9ZlMcHzg25m9JXdSSle/c5U95Jjymn4nalc/WI+7STcRRHH0avs3tRMR4E7ml5kJ/eNHxzlTtTJDGaphpPsFqHxRdlmj5WpM1I3+k0cOwkQ== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by DM8P223MB0045.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:8::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.15; Wed, 22 Dec 2021 13:29:04 +0000 Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::9c8d:fc63:9488:9775]) by DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM ([fe80::9c8d:fc63:9488:9775%7]) with mapi id 15.20.4823.019; Wed, 22 Dec 2021 13:29:04 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] Politics Thread-Index: AQHX9arZj9pQ3YFX7kizUGhUZu28Gqw7f9aAgALSmrA= Date: Wed, 22 Dec 2021 13:29:04 +0000 Message-ID: References: <678798058a84fb8a30dcfaa177431607@canta.com.ar> <20211220152349.GS2829255@pb2> In-Reply-To: <20211220152349.GS2829255@pb2> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [+/8/W6aP9DpcfCgEn+3WRbgczVBj1NQg] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 68af0318-5a0d-412f-f492-08d9c54f05e4 x-ms-traffictypediagnostic: DM8P223MB0045:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WfEQivz229h8OtVOx5hkABCnsTYyqMPEenJy69ZiCur/0lMHWY48Os2/yZzVa2MO3Ua9VYkibPWbaW5CoUc5W+FHsVTmyYLnL9Bh0l1pglK2X2u/A7OCLuMNU9O4ALYt2Z6rYfi1ATC0fONoqxX9GUiB4uB/6XHD6GJEn0Chn7m5iLjgIeO4d6LF3mXqOMyuctJz6soEDIOIceagAHWBCU5XAwSN5D/9Ls6b0/9yKWLDtVixARYNJZAqbc85Efb0tqbkEkGe/X8YKIO7FjP3VaxvUyQkCSPlR3j9V1VtD9+8F/4Q8HOxN0t0M1utDxZd4QQIqP1gNYuEab/LVS3JeKD22iB+g/zjNuN9RMu6mvuj/EY4lpHUuYCJtkv3wMG7RZ7N8EGLQv/kfuRUNiYoOVsSCdXwKUJjGjvbJZIwH+u3dKjWcT0ig80EeXvgq29pceRLZusnyshDUpV0WSyo4Qd+9lML5313bfpkOAlhYMvgAgftL9EEkXjqgiVdProZcDlfkwnscZVVML6pdi/2Gy/GIjr1pru0uoGW2Lf+GbejRjYFBIdDNcTjMvLFoI4kMKJqqpphKcqPQS41m+u3ow== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TDQ5VlJzcHc3aVhXUzdNWkRmVU5BeTduR2cvTXMvMllXSlBxR3dNeTIwSG12?= =?utf-8?B?SHpsSkI1V3V4SDBOWkJkTTc2bGNrOFhmRHRCVThvZzVZclFVdUcvZlFiR2V1?= =?utf-8?B?T3czaWpEMklnUy8yK2p2S2JHcXlMN0o5b0FhcXZsUDlIQlhZWXBFSGtPWEVO?= =?utf-8?B?cktnT2l3TzR5ZWkvd0puOFpSSWh6NldSZTJIa1R5NEVIeXB2blhWeGUrV001?= =?utf-8?B?NVgrUDQ2a3ZGVW1aWi96YndGcTdJVmZuK21CRDVsL3VHc01GZFNCQUV0UGdE?= =?utf-8?B?S0lqTXdIbmd6Mi9KZW5DZEg2SzBBTGZwZU56WTVrZVB0Zi9kc3c5RjBjU1U4?= =?utf-8?B?V1hqUWR4c0lGREMwYmR6NTBpL2JYWGQ2SXMxV1VlREltc2hKOEpKSXhDSENC?= =?utf-8?B?VzNnQkFCNC9uT2c5eEg1UmYwR2pvaCtBaTVJUmZOZnpXMW1taThDM01mQWJP?= =?utf-8?B?UVBaWlZJK2Z2cU5qcUgxU0RlSGdaZDFSQVlyaHpXYi9MVHBLUkdyS3U4NmdD?= =?utf-8?B?OVlQUEJPU1JwbVluUmYwcTdGNlFVVGRNTjRoby9ucHZUZSsxenViTmUza0Fh?= =?utf-8?B?S00zeTdUNkxVYlpjcXpRWXBwejlJSnl0cW1OR3JoNFlycnkvOHRDNnJQMWJG?= =?utf-8?B?dDVSbFl5bko0MjRKaXk1UEVnTjFLWEo1N252MzZVN2k4N0dRUHl6RUhoblQx?= =?utf-8?B?UXlqc1JmQ2x3Um9Ha2xsemV0SjFOZUV6UGJJbXJuSi95TitJQ2d5WEhPelFn?= =?utf-8?B?T2NPYnI0MzdGaHY2cXRJWkdDRUI0TkYxVHExVm5hc2ZHVCtUSEZ4dk04MVdV?= =?utf-8?B?cTE4b1lkdHN1R1R6cW1SNGpwME1HSzdmVXBhekYrMm45di9maVpDdWl4eWxk?= =?utf-8?B?eDJjekRvODkvSnpUR3hRSHZHUU1yTzE5Q25rdmNZejZ4OEhIdnZ4NVl2QUU4?= =?utf-8?B?ckpHZllnVVJrYTNyMzFLYm5jcnpNWkZEVUtVcEpGZlhiR1BNOW0vZk5PZUpN?= =?utf-8?B?ZExKTkZKWjVHc2VIQVREV01yMmJJajRVSG94Ym4zUlZtTEphb3g0eGVUTTZ6?= =?utf-8?B?c1pTaVUvMWQya21XNHMyT0NZMWtVbmQ1ZklZaTMwaUx1czBsSld5ZUlzRU9i?= =?utf-8?B?NC9abUpQbkMwMEhyS29VT1FTc3pJa0hoeFV5SjdBcWNVem9DWld0S3kzbGpj?= =?utf-8?B?eWFMM1hKOVA4Qk50cTFySmZGVjR1WWQwcUVURmdaaG1YOGFKUmQvbWtVREh6?= =?utf-8?B?MzhSSW9sQ2gxSnZoeEFvNDFhaUpTLzhEaFIvVlNqZU0zOFdEUT09?= MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-1ff67.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 68af0318-5a0d-412f-f492-08d9c54f05e4 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Dec 2021 13:29:04.0430 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P223MB0045 Subject: Re: [FFmpeg-devel] Politics 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: > -----Original Message----- > From: ffmpeg-devel On Behalf Of Michael > Niedermayer > Sent: Monday, December 20, 2021 4:24 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] Politics > > I am not sure the direction from which you approuch this is going to > increase the chances this patch has. > > All stream types in libavformat/codec are timebase based, that was > done because its exact (for some definition of exact at least) > > I think you should argue why this is the best way forward not why its > not too bad > > also in a few places where a fixed timebase is used ffmpeg uses > AV_TIME_BASE_Q which is micro not milli seconds. That suddenly > allows exactly addressing individual frames and audio samples. > And it should be easy to change to from ms, its just a *1000 > it would weaken the precission argument For the final chapter of this story, let us return to the original subject which I would summarize like: "Even though the whole world is fine using millisecond precision for subtitle display, I think I know better and therefore insist on having a higher precision and/or flexible timebase for subtitle timings, otherwise I won't accept the patchset" I have been waiting for a while to answer, expecting somebody might come to realize himself how useless this whole idea actually is, but I guess it's time to reveal: Let's look at the concern first: The concern is about that with a subtitle precision of milliseconds (let's say milli, even though we actually have microseconds), it would not be possible to make sure that a subtitle event would be shown exactly at a specific video frame. The claim is: This could be achieved by having a high precision (and/or a custom time base) for subtitle timings, because this would allow to have subtitle start times that could exactly match the frame display time of the frame at which a subtitle should be initially displayed. For a moment let's put aside the argument about subtitle format precision. Let's assume we'd have a subtitle format that allows such precisions and maybe even custom time bases and let's assume a player that can handle this. Now we look at the player and a situation where the player needs to display frame N. At this point, a range of different things can happen, mostly specific to the implementation of the player: Whether it reads a frame's time value or infers it from the frame rate or which time base a player is using internally, just to name a few examples. And then - at a total different place of implementation in the player (could be custom, or a library like libass), the player needs to determine whether a (and which) subtitle needs to be displayed over frame N. Here, we have the frame time, which has undergone a number of calculations and we have a subtitle event with our super- precise subtitle start time. The player converts that to its internal time base, and then.. ..how does the player determine whether the subtitle event should be shown on frame N? Does it check like: frame.pts == subtitle.pts? No, it doesn't! It does something like: frame.pts > subtitle.pts && frame.pts < subtitle.end_pts ..because it also needs to display all subtitle events that are already visible. Let's look again at the proposal: to use high precision subtitle timings which would allow us to have subtitle start times that are as close as possible (or even equal) to the video frame time. Now what a surprise: having-frame-equal subtitle start-times wouldn't make it _more_ clear at which video frame the subtitle should be shown - it would make it more and more _unclear_ and non-deterministic whether it should be shown at that frame or the next! Eventually, the final presentation would depend on: client implementation details and rounding errors, which means the opposite of consistent, reliable or predictable. The closer and more precise a subtitle start time would be set to a frame's display time, the higher the chance that it would be shown at the wrong time (due to the >/< tests that clients need to perform. Everybody who is creating computer animations and who wants to achieve sudden changes from one frame to another knows, that this change needs to be authored in a way that it happens in the timely middle between two frames (to make it safe against slight adjustments, rescaling, etc.) And the same goes for subtitle authoring: When you want to make sure that a subtitle is shown at frame N+1 but not at frame N, then you set the subtitle start time to a time half-way between N and N+1. And this doesn't require high-precision timing values nor custom time bases and it's also stable against calculations and rounding errors that might occur during processing. My wish for the future would be criticism that isn't based on mind-farts or unrealistic hypothetical cases, but actual problems, ideally accompanied by an example to demonstrate. Kind regards, softworkz _______________________________________________ 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".