Le sam. 21 juin 2025 à 16:59, Michael Niedermayer <mich...@niedermayer.cc> a écrit : > > On Sat, Jun 21, 2025 at 10:45:32AM +0200, Romain Beauxis wrote: > > Le dim. 15 juin 2025 à 00:57, Michael Niedermayer > > <mich...@niedermayer.cc> a écrit : > > > > > > On Wed, Jun 04, 2025 at 11:58:52AM -0500, Romain Beauxis wrote: > > > > This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat > > > > memory storage for the extradata. > > > > > > > > PR review comments addressed: > > > > * Use flat memory bytestream > > > > * Re-use existing xiph extradata layout > > > > > > > > --- > > > > > > > libavcodec/vorbisdec.c | 42 ++++++++--- > > > > libavformat/oggparsevorbis.c | 83 +++++++++++++++++++++- > > > > > > patches that change both libraries at the same time are suspect > > > > > > if one depends on changes in the other it needs > > > minor API version bump and seperate patches so extension of > > > API and use of it are properly tracked and testable > > > > If I remember well, according to Andreas Rheinhardt there's no need > > for an API bump here since the patch is re-using existing extradata > > bitstream structures. > > If there is really no API extension then the micro versions should be bumped > so a user knows if the specific version he uses has teh fix. > Also it may be usefull in bugreports about ogg to know if its prior or > after this change
Hi Michael, I have created a PR on code.ffmpeg.org here: https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20026 Would you have a minute to have a look? This patch is a redo of a patch that was reverted: https://code.ffmpeg.org/FFmpeg/FFmpeg/commit/848ceb1329cb6102df49379430b277dbb3f07569 It would be great to see if it could be included in the next release, otherwise the round of work on ogg parsing would be incomplete for it. I'm hoping that the PR can help gather and keep review feedback in one place. Thanks, -- Romain > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Awnsering whenever a program halts or runs forever is > On a turing machine, in general impossible (turings halting problem). > On any real computer, always possible as a real computer has a finite number > of states N, and will either halt in less than N cycles or never halt. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
