On Thu, Jun 13, 2024 at 10:49:15AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Wed, Jun 12, 2024 at 03:48:08PM +0200, Andreas Rheinhardt wrote: > >> MB_TYPE_L[01] is based upon H.264 terminology (it stands for > >> list); yet the mpegvideo based decoders don't have lists > >> of reference frames, they have at most one forward and one > >> backward reference. So use terminology based upon this. > >> > >> This also has a second advantage: MB_TYPE_L[01] is actually > >> an OR of two flags (which are set independently for H.264, > >> but aren't for mpegvideo). Switching to different flags > >> makes the flags fit into an int16_t, which will be useful > >> in future commits. > >> > >> The only downside to this is a very small amount of code > >> in error_resilience.c and mpegutils.c (the only code shared > >> between the H.264 decoder and mpegvideo). > > > > Cant you just call the flags differently but leave them nummerically > > the same, if you dont like L0L1 terminology ? > > > > Having each codec be different does not seem to me to be a good thing > > It adds burden to every bit of common code. It may be thats error_resilience > > ATM, but there are other things people may want to add, like an universal > > encoder for all the block based transform + MC formats > > 1. The terminology is only one part of this: Using the same flags > currently adds a burden to the mpegvideo-decoders, because their > mb_types don't fit into an int16_t, so that they can't use symbols > tables. See the following patches for this. > 2. Furthermore, it is not "each codec" that has its own system of > defines; it is only H.264 vs. the rest. And even these two systems are > mostly the same. > 3. If you create a universal encoder, then you'd be better off to use > your own MB_TYPE_ defines for it and not to reuse this system here. In > fact, mpegvideoenc does not really use it (it uses its > CANDIDATE_MB_TYPE_* system). > 4. And I don't think that a "universal" encoder is even a desirable > idea. An in-tree H.264 encoder would be very complex and all encoders > would benefit if it were not tied to the other encoders. Apart from > that, x264 is a thing.
iam not talking about h.264, I do think though that extending the concept of our mpegvideo encoder which happily encodes from mjpeg, h.261, RV10, RV20 mpeg-1, mpeg-2, mpeg-4, h.263 to WMV1 and WMV2 to some more generic universal encoder that covers the more modern formats does make sense and is desirable That said, i guess it doesnt matter if you change the flags, you are probably correct that they wont be too usefull as they are either ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
signature.asc
Description: PGP signature
_______________________________________________ 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".
