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 9905B42434 for ; Sat, 18 Dec 2021 13:32:45 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 23ABC68ADD0; Sat, 18 Dec 2021 15:32:43 +0200 (EET) Received: from w4.tutanota.de (w4.tutanota.de [81.3.6.165]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 0CB0068ACF8 for ; Sat, 18 Dec 2021 15:32:37 +0200 (EET) Received: from w3.tutanota.de (unknown [192.168.1.164]) by w4.tutanota.de (Postfix) with ESMTP id AF82A10600DF for ; Sat, 18 Dec 2021 13:32:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1639834356; 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=GO/GcibgSZUg5o7i0eRnT2kmkgTVnz/d4YdCDZRdxt4=; b=gBatrX38vg3/Mnh6waMhvdQTU/ZDtndB1h0wzt/BO2EOhWxqT43s4pmMzYDoKc8Q vGEDJ0bSMS4skpE9PthUC/+SOOo6dPgfxCftemuLPPM/nx1Krm6YtqnDEPYJ5wQG1rL QneB3did7v2JuvzOAa19I0gzeBUoqT9378H7BsrqSFq/dIY1xtKRDsRhxq45mdfgN3y P5xF/QvbGSnfvD1+dJRcdrJq/HFKzsr88c3Ybmuhxuv38FY1MJcCICUVPpLzsljOM1V fPAXxQ4wN3OMy6g6yzNilOb6TEnFkWZpbGCksCRnqMejDBgJ0N7S9jdodhpb9Rai5rR LPuDzmyM2A== Date: Sat, 18 Dec 2021 14:32:36 +0100 (CET) From: Lynne To: FFmpeg development discussions and patches Message-ID: In-Reply-To: References: <8dbfd345-c661-459e-b242-94830107eae3@www.fastmail.com> 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: 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 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. Like elenril said, this is an API that'll stay for decades at the least, and replacing and changing will be impossible once it's merged. Just stuffing the entire AVSubtitle field in a frame simply won't do. _______________________________________________ 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".