From: Soft Works <softworkz@hotmail.com> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches Date: Mon, 14 Nov 2022 11:40:31 +0000 Message-ID: <DM8P223MB0365FD547FEA46E289EDC49BBA059@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw) In-Reply-To: <166842406666.1198.894449822855148822@lain.khirnov.net> > -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of > Anton Khirnov > Sent: Monday, November 14, 2022 12:08 PM > To: FFmpeg development discussions and patches <ffmpeg- > devel@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend > the argument for submitting patches > > Quoting Soft Works (2022-11-14 11:46:49) > > > Sorry, but you problems are entirely self-inflicted. You have > been > > > told what changes need to happen right from the beginning, > > > repeatedly, and by several developers independently. > > > > And those are completed and settled, like I had state multiple > times. > > It's ready for review for months already. [...] > > Some random quotes from IRC: > 2022-09-01 00:25:21 @Lynne elenril: I never retracted my > insistence on using the native frame fields for subtitles > 2022-09-01 00:25:27 @Lynne not sure how softworks got that idea I got that "idea" from this discussion: Jan 14 02:46:02 <Lynne> can't you really not hide away everything to do with repetition, subtitle pts, and subtitle duration all into the private opqaue field, and give the user what they expect when the frames go out of lavfi? Jan 14 02:46:55 <softworkz> worth a thought, but I'm not sure Jan 14 02:49:32 <softworkz> I think it's better to make it more transparent. the heartbeat mechanism has been a hidden thing and that's why it wasn't an ideal solution Jan 14 02:50:10 <softworkz> when you already need to understand when and why you need to insert a subfeed filter, then there's no point in hiding the effect imo Jan 14 02:50:53 <Lynne> I think that's worth a really good look Jan 14 02:50:56 <softworkz> the good thing is, that often none of that is needed at all Jan 14 02:51:15 <softworkz> (say sometimes..) Jan 14 02:52:04 <Lynne> if you could hide all of that into the opaque field, I'd be happy with the patch This IS a retraction from the "insistence on using the native frame fields for subtitles." (because the actual subtitle timings would be in that opaque field) 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".
next prev parent reply other threads:[~2022-11-14 11:40 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-14 9:13 [FFmpeg-devel] [PATCH 1/4] doc/developer.texi: improve the introductory text Anton Khirnov 2022-11-14 9:13 ` [FFmpeg-devel] [PATCH 2/4] doc/developer.texi: extend the argument for submitting patches Anton Khirnov 2022-11-14 9:35 ` Soft Works 2022-11-14 9:53 ` Anton Khirnov 2022-11-14 10:46 ` Soft Works 2022-11-14 11:07 ` Anton Khirnov 2022-11-14 11:20 ` Soft Works 2022-11-14 11:40 ` Soft Works [this message] 2022-11-14 12:42 ` Nicolas George 2022-11-14 14:34 ` Anton Khirnov 2022-11-14 15:13 ` Soft Works 2022-11-14 15:18 ` Paul B Mahol 2022-11-14 15:39 ` Soft Works 2022-11-14 15:45 ` Soft Works 2022-11-14 16:13 ` Anton Khirnov 2022-11-14 16:38 ` Soft Works 2022-11-14 16:40 ` Nicolas George 2022-11-14 17:25 ` Soft Works 2022-11-14 17:47 ` Nicolas George 2022-11-14 22:05 ` Michael Niedermayer 2022-11-14 22:49 ` Soft Works 2022-11-14 9:13 ` [FFmpeg-devel] [PATCH 3/4] doc/developer.texi: demote the "contributing" chapter to a section Anton Khirnov 2022-11-14 9:13 ` [FFmpeg-devel] [PATCH 4/4] doc/developer.texi: refine the "contributing code" section Anton Khirnov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=DM8P223MB0365FD547FEA46E289EDC49BBA059@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \ --to=softworkz@hotmail.com \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git