Re: [FFmpeg-devel] [PATCH 12/57] avcodec/mpegutils: Don't use MB_TYPE_L[01] for mpegvideo

[Michael Niedermayer <michael@niedermayer.cc>]

[-- Attachment #1.1: Type: text/plain, Size: 2829 bytes --]

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.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".