On Mon, Apr 13, 2026 at 04:41:59PM +0200, Michael Niedermayer via ffmpeg-devel wrote: > Hi everyone > > On Mon, Apr 13, 2026 at 03:49:30PM +0200, Michael Niedermayer via > ffmpeg-devel wrote: > [...] > > If the concern is mainly the way Fairy writes messages, that is adjustable. > > She is writing in the style I asked for, and I can change the prompting. > > If the tone feels too assertive or too strong, I can try to make it softer > > and more neutral. That is just a matter of adjusting how the messages are > > generated. > > Do you prefer the tone / style of this one: > > https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20971#issuecomment-36421 > > For reference: > Thanks, this looks like a good start, but I think there are a couple of > things to fix before approval: > > In 97e6eca06390, MATROSKA_ID_CHAPTERATOM was removed from > matroska_chapter_entry[]. Previously nested ChapterAtom elements were treated > as known but intentionally skipped. After this change they fall into the > generic unknown-element path instead. That still skips them on the happy > path, but on non-seekable inputs it also feeds the damaged-data heuristic > (unknown_count / SKIP_THRESHOLD), so valid files with hierarchical chapters > can now be treated as malformed. I think ChapterAtom should stay as EBML_NONE > here unless subchapters are parsed properly. > > The forward-declaration block still contains matroska_chapter[6], but > there is no matching real definition/use anymore after the rename to > matroska_edition. That leaves an unused static object behind, which is likely > to trigger a source warning with FFmpeg's warning setup (-Wall, while > -Wno-unused-variable is only disabled for headers) . > > If you already have the sample you mentioned locally, a small FATE case > covering EditionEntry plus a nested ChapterAtom would also make this much > safer.
heres the next one, they are all now softer worded than yesterday also, if they contain technical errors please immedeatly tell me, so i can keep track of, investigate and improve this. This whole thing has one goal and that is to help the project and community. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21098#issuecomment-36426 For reference: Thanks for working on this — the idea makes sense, but I don’t think 7671bb9fd4 is merge-ready yet. I found two blocking correctness issues in vf_fps.c: * shift_frame() breaks the buffer invariant when frame_on_hold exists and only one buffered frame remains. In that case it decrements frames_count to 0 and then stores the held frame in frames[1], so the state becomes frames_count == 1 with frames[0] == NULL. The next write_frame() path clones s->frames[0], so a large-jump frame followed by EOF can mis-handle the tail and can dereference a null frame. * In the “jump seems legitimate” branch, the correction uses last_good_pts + s->fill_check, but last_good_pts / frame->pts are already in the output link time base. fill_check is a duration in AV_TIME_BASE_Q, and you already compute fill_check_pts in config_props(). As written, the default 6s becomes +6000000 output ticks instead of +6s, so for normal fps time bases the cap is effectively not applied. Could you please rework those two paths and add a regression test for at least: a huge jump followed by EOF, and a huge jump followed by a retrograde next PTS? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Direct Democracy is when the decissions are made by the People, most of whom have no interrest, no time and incomplete understanding of a choice while being bombarded with misleading information. Representative Democracy is when you are handed 2 dice and can choose which to roll.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
