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 6F6E44245B for ; Sat, 18 Dec 2021 15:17:01 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 68E9368AE83; Sat, 18 Dec 2021 17:16:59 +0200 (EET) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3D3F168AB42 for ; Sat, 18 Dec 2021 17:16:53 +0200 (EET) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id 9B8CA1060289 for ; Sat, 18 Dec 2021 15:16:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1639840612; s=s1; d=lynne.ee; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=QxYNbXL8aI1gnhel0uAa/nFUJAyRxsBGwEF5i51U6WU=; b=Z30i9UNEl9wiA4+0v7XF8XUG6gn6gYEcLdVoG5td4k3lzEBkf9/ycMs5yU7QOIsI d7aETz6BRes4TPM5HtD/02rtrksOSSEQKp6LgmkTeBpCM6mVzPlRpZnfxQ3sbFu46fk oF65mte0UFcPLiAaayEFMvsgycN+x564NiddICrAZf+l5Lt9mfFmJvicT/v7JKdWdAV 1Bg9J9NmXUvu7Mn84dNnblg6i6LOdSewGkoQqvhSaqxSa/nZqKxYQzsqo3TXjL84O0U heHmyUiPWKVcGWftt8VsZzlOlGoEoFhtzp+7IgJN1EO6pCHITgyAzxPJ0PeM7M1EtuF j3nk/H3eLw== Date: Sat, 18 Dec 2021 16:16:52 +0100 (CET) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: References: MIME-Version: 1.0 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: 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 >> >> 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, 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. Also, some text subtitle formats have a timestamp precision much greater than a millisecond, like Ogg Kate. We don't support it yet, but you never know. An API must be able to handle everything. _______________________________________________ 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".