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 B248D42472 for ; Sat, 18 Dec 2021 15:44:09 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id ED9F568AF49; Sat, 18 Dec 2021 17:44:06 +0200 (EET) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08olkn2054.outbound.protection.outlook.com [40.92.45.54]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 2196368AACC for ; Sat, 18 Dec 2021 17:44:00 +0200 (EET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EQqIWq+s1vpQx86SVEj5EyeXY/W1Ts2HLS0ewOravTDLTCpfM74vS8dpSPv/W+izWCm7IyBHJBlGjmouJsdF9RhwUiQLhmE9Cy+SUMjqMff/gL8dc+9uk/Zi9yQJ5ZBBRBHm7ZCUDN+K6hI26LD9Bvz+iikGuMwZO65FFghZJ1NnXYwoTGe+65HVgcCGLscLDDk8PMTFUZVxz5dImbxNy6Y3zae6TjDEu2QU+82Yf7bPZA2/EJAaAPINqAWkCxeuWjckAnuL+kAcA0wmnnXifYENAIDJhM1+u1qQPRaDoXn3I4/jRV3CpK30rymFpQypByK9gRGYmoYr4gMMSgtP4g== 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=ULiTMtvQZGW6NDgDecBLNqGDMQRVyFi3UmtlDfQ4QOc=; b=CxBLVHUzG9OMpKrOUEhP2gZz+rpQp04lvybKKyY+7+2ZGZPgCahBT37zl9tSaEEsM3xyrk7FcuG+mlTOij+1M6HOH/9Tgal1gyYxBmjFVN5WZ8iUc9YspKd/040YM/ytQWaZ6Vaaux7UrbhOqg516dtosOnvRji/W+uK4Eo+uhfyfwTHaRJdJi80BaA8ofJeZ1QYNwkPwi7YVQOr++9GDbiofEe3pFm6NcLZMLjB9Hh+nWJHzPWN23klUEiLURNmBaEY31tpA+9PI3Ygr3d3XMXOBtLAOB2vdib4e0agtKJYpn0BXIE2pEs6wTjZMDsNU82Ui8PfWlloJKXDc+1V6Q== 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=ULiTMtvQZGW6NDgDecBLNqGDMQRVyFi3UmtlDfQ4QOc=; b=j5ugOzJDExJJCtDVRMtl6ETFhVm8I1Td+Hir9kb1w+czSFwPDKNEnZ2Yw/6OW1dExbB4/eMIuZ5ET1umgFbeAFiPagOKQt8R3wBVkTHTTOWGDNsFTfv8sWuXlj3920hD6cWrL4RX+YEl7TX/zb9ZGxV9oZXYw6o8NsF0t65Aa++a2EanoaI+kycqkDcGaEznzKCc17e42yXc4tXWQn9geOIdfRp/0qWd/4jUgFM9d2tcgk7bC6jxvoooWARMLgUZdR8KqF+69Qd9S56OXQ1e8LGWD9zmko8A2Leiuub8k7Gdne0o/axSH7i43xoplER/jME/PgeOPGYXenifMu+ztw== Received: from DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:b::20) by DM8P223MB0221.NAMP223.PROD.OUTLOOK.COM (2603:10b6:5:317::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4801.15; Sat, 18 Dec 2021 15:43:57 +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.4801.017; Sat, 18 Dec 2021 15:43:57 +0000 From: Soft Works To: FFmpeg development discussions and patches Thread-Topic: [FFmpeg-devel] Politics Thread-Index: AdfvHU2CBKI4bcoLRhSl52fM3Tar9QBLh/sAAAAs7YAAA5K2AAAAX9TAAA7bNQAAALs1kAA/KcwAAAg1U6AAkH5iAAAAs7+gAAXLhgAAATjkwAACa1MAAABdVPA= Date: Sat, 18 Dec 2021 15:43:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tmn: [wsr13VFJzseFoFd/P9TPthHMocaQkU8FA1JZ3wCPQB1Pq7UYBVvA7fFDmKl75WvS] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6cb7f9e1-e479-4b24-8feb-08d9c23d342d x-ms-traffictypediagnostic: DM8P223MB0221:EE_ x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ewDfZo91lMw7gEFx4Sh3Qf/NgSIMXGjWewg8i0euhLTzPjdz+MISg6dhl7hsL5DNeNc+TL2KT9RvriH/Cz0dOU2FhY381Gzjc1EA2dg/eLqs9XhPHar7BfR12Tr8eMZpACviQwQ0oaTtgzNJ0DvbZYlRuHH7lKd+y+uMvF2wUaiU7pkfG7Ypd1qGF+jF6Yh9BQUEaa/HtsdDQjyF6UIcTKkEcfioGwzT6nzncjuMMjiBJ1ZmM9zpWgDuQJDC554HEjNmmjIgFxob48jOlGROykefau8H/vq6fv5Wi72uhR+/wBNShh6ZIeosFGBh/X8ucQhdq1slqlaFfszO0SleuHcpDCyB08GwblBAmuaRYMqz0a21xwVy3an1y8jt1DO8kvk48cGqcVDRco3wDlt29V/dtB1hQjB5MJsliP3q3RgfaGH1G5q8ZgZhmf/yENpilCN8wxmSeK0+orRyZS1nLJUze05emJldkL9nF3XrhjoWYTKU3kt/YXa2pOzCCWMzyufvpEdcC2+kb6L9blvaxU8oXE40p1q9OZPkwr3mYVUgY2hb6z43pk0f3Ug0tpIbwmsFTCbwfG6lKy0F0KRy/g== x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?NTFrK2RJMlFuNDhINHR3eWRDWFVMOEs4dnBPbnlSaDQ4bG93alYwRDMyWkd4?= =?utf-8?B?M2hWbGg3UndCZjNBQkFxd2tGQWs5UnE4VnRtRHNqcTR6K2NsaHdDeVNBaytY?= =?utf-8?B?NVJHMHZRZTJkTUQ5ZGhjcUpnT090SXBjdWNSRVEwY1djYTlLNUkxOXdkUytD?= =?utf-8?B?cEtBZlpmVmRzTmRJVFJVTXBrTnh1b1JIZ3ZvcjVCL29HNm52NjNlWUw5dURa?= =?utf-8?B?RkNubTNRYS9IRmlRekVRMVUvWHYrMzFQTEduWm5zRkJzd1AwLzJyNjF6SUZt?= =?utf-8?B?TDNQc1RUVDE5ZFNnYjZNSmhuYldabTBjNDM2a3pZdDN0Wm9JVHk4WVNuOS9U?= =?utf-8?B?ZVo3TnhwYVVXUWFDZmMrOG5tRjZpcTVvdTgvQjBsSTFVMVhkZmJ4V1VuVEp0?= =?utf-8?B?VWVsR29NLzNBdjdNT0ZuOVY1MVpSeXJtWFVjeWdSeDd3cWZFUm12eitIWm13?= =?utf-8?B?RzNiUVQyR3JnYkpZTm50eFRjOEZzeHZiT25CWVpTWWM0U2F5MURpdTlhRlVB?= =?utf-8?B?eHk3OUdOYThndXhrcnpYeXJ2SzdDUGVaTFVzWm5TOXIzSzJaSGx4YWtUOEZq?= =?utf-8?B?eEtLeFljWUhiZWZReUNCYXRsdmZ5a000ZFZaTGtmKzNvWFVlYjU5ZUpBbE5R?= =?utf-8?B?U2laUTl2bmFuVHNoVTNwenNGdUJ5eU9ldnRoajY3OVd0QjAwNWZHTlg0azBt?= =?utf-8?B?VkJJUllXOWd1d3M4YnJxQXlvaFJidTZZNEVsUC9yd01za3BLYUthcG1zTDdD?= =?utf-8?B?WnlwV3JxQytQTjdZRmNpVVR3UElqbHBkV0xqaXljNURkYjlwekQ1c25nNnFR?= =?utf-8?B?OWJodDk3UE9lekFqeVBudHI0SWtMMVlOZHlmN0d1akxjYWJxME5wZU0xbERK?= =?utf-8?B?RldpMlY2RGp2T1lrSzJKdU4waWZlc1VWS2FiVmN4ZHVvU0tCb1BRaFFkZE9C?= =?utf-8?B?SFFHMkcrM1NiL3I3czRMYWpNMDIxUkpIKzgra1hzRGFwdzlTZU03VnAzZDVH?= =?utf-8?B?SlRrRlNqRG85a09DeGMzU2ZGb1VJY3hXTVA2WmhQdXRpVUZidzRVdnNPbS90?= =?utf-8?B?dzdicFRpbDJRM0w4R2pTM2RYYThJb1ZCOFVJMzVxeHB2YVFwb3lnajdHNDlh?= =?utf-8?B?REhYNFI5dGdEWmNMTUoxOEg4U3FkTVZPbWxMck9tQUdZUlNVT2krcHdHMHN0?= =?utf-8?B?UVZSUUUxOFhmV0hFNC8vWjZoSFg0c3JzcCtNeC95Qmw5dXRoS0xmeDcvcTE0?= =?utf-8?B?UDdwN0pBMXdwNU1HeUo0cnp2MHJvVmNETlBuUUJLd1daSmtMaGM5Q3owOU1w?= =?utf-8?Q?ov4zssIYVF+WJgszyEWYNhGY86A6oPPbN6?= 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: 6cb7f9e1-e479-4b24-8feb-08d9c23d342d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Dec 2021 15:43:57.2805 (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: DM8P223MB0221 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 Lynne > Sent: Saturday, December 18, 2021 4:17 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] Politics > > 18 Dec 2021, 15:28 by softworkz@hotmail.com: > > > > > > >> -----Original Message----- > >> From: ffmpeg-devel On Behalf Of Lynne > >> Sent: Saturday, December 18, 2021 2:33 PM > >> To: FFmpeg development discussions and patches > >> Subject: Re: [FFmpeg-devel] Politics > >> > >> Dec 18, 2021, 12:34 by softworkz@hotmail.com: > >> > >> > > >> > > >> >> -----Original Message----- > >> >> From: ffmpeg-devel On Behalf Of Paul > B > >> >> Mahol > >> >> Sent: Saturday, December 18, 2021 11:27 AM > >> >> To: FFmpeg development discussions and patches devel@ffmpeg.org> > >> >> Subject: Re: [FFmpeg-devel] Politics > >> >> > >> >> On Wed, Dec 15, 2021 at 2:34 PM Soft Works > wrote: > >> >> > >> > > >> > [..] > >> > > >> >> > > > Once for the facts: the subtitle_pts field in AVFrame exists > since > >> >> > > > V5 of my patchset, which I have submitted on 2021-09-12. > >> >> > > > This has been 3 months ago. Nobody had objected its existence > >> >> > > > until only 2 or 3 weeks ago. > >> >> > > > >> >> > > > >> >> > > This is really irrelevant, please stop insisting on hacks like > >> >> > subtitle_pts. > >> >> > > >> >> > New idea: > >> >> > > >> >> > I could remove the three fields (subtitle_pts, subtitle_start_time, > >> >> > subtitle_end_time) from AVFrame and add it to AVSubtitleArea. > >> >> > > >> >> > How about that? It would allow the frame to be "clean" at least. > >> >> > > >> >> > >> >> > >> >> Yea, much better, But still original issue is not solved. > >> >> > >> > > >> > Yes, correct, this changes the location but not the logic. > >> > But this is something I could surely do. It's a bit of work, > >> > but it would be safe to do without breaking everything into > >> > dysfunctional pieces ;-) > >> > > >> > It wouldn't be my first choice since there can be multiple > >> > AVSubtitleAreas while only those values from the first one > >> > would be relevant. But when this would help to increase the > >> > acceptance, then it will be fine for me. > >> > > >> > Another possibility I had thought about, might be to leave > >> > them at the side of AVFrame, but put them in a struct field > >> > of AVFrame named 'subtitle_timing', which itself would have > >> > the fields pts, start_time, end_time. > >> > > >> > > >> > I did some research regarding the use of the start_time > >> > field. While it is used and cannot be dropped, I found > >> > that the following changes would be possible with moderate > >> > effort: > >> > > >> > - change the time base of start_time and end_time > >> > to the same like subtitle_pts (AV_TIMEBASE_Q) > >> > - rename subtitle_start_time to subtitle_start_offset > >> > - rename subtitle_end_time to subtitle_duration > >> > and adapt the logic everywhere where it's used > >> > > >> > In combination with the subtitle_timing struct idea it > >> > could then look like: > >> > > >> > frame->subtitle_timing.pts > >> > frame->subtitle_timing.start_offset > >> > frame->subtitle_timing.duration > >> > > >> > or even eliminate the pts naming and do like: > >> > > >> > frame->subtitle_timing.start > >> > frame->subtitle_timing.start_offset > >> > frame->subtitle_timing.duration > >> > > >> > or still move them to AVSubtitleArea, which wouldn't > >> > be that nice to access and require to check the > >> > subtitle_area_nb value wherever it needs to be > >> > accessed: > >> > > >> > frame->subtitle_areas[0].start > >> > frame->subtitle_areas[0].start_offset > >> > frame->subtitle_areas[0].duration > >> > > >> > > >> > Please let me (all) know whether one of those suggestions would > >> > be an acceptable compromise. > >> > > >> > >> Renaming the fields doesn't get around the issue that they're > >> still overriding fields with a different meaning from the > >> AVFrame structure. That's not really a compromise since they're > >> still there. > >> > > > > I'm suggesting those things that are doable. > > > > > >> I also am not accepting a hardcoded timebase of microseconds. > >> Rounding really matters for subtitles, since presenting them > >> a frame early or late is unacceptable, so I'd like a time_base > >> field for the timestamps. > >> > > > > I can't follow. With 120fps, the frame duration is 8300 microseconds. > > And you say that's not enough to hit the right frame? > > > > None of the subtitle storage formats has a precision higher than > > milliseconds, often it's less. > > > > Finally, a fixed time base avoids frequent re-scaling and that > > in turn means less rounding errors. > > > > A timebase completely eliminates all scaling. > Bitmap subtitles exist, > as well as ATSC subtitles There are like 2 or 3 characters in each frame. Sometimes they are shown as they are coming in, sometimes only when a line is completed, sometimes needs to wait for subsequent frames before emitting new characters. This is really not a high-precision thing. , which > are embedded in frames, and therefore have the same timestamp > and timebase as the frames themselves. Forcing them to be > rescaled to whatever timebase you thought is good enough is > a bad, inflexible design choice. What precision do you want? This is nothing like audio. You just need to hit one frame or the next frame, nothing in-between because there is nothing in between. So what's this about? Videos with 1 Million fps? > Also, some text subtitle formats have a timestamp precision > much greater than a millisecond, like Ogg Kate. But only because it uses the same bitstream layout as for audio and video. > We don't > support it yet, but you never know. An API must be able to > handle everything. It will handle this perfectly fine. I'm afraid, but IMO you are trying to construct cases which do not even have a theoretical value. 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".