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

Andreas Rheinhardt andreas.rheinhardt at outlook.com
Thu Jun 13 11:49:15 EEST 2024


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.

- Andreas



More information about the ffmpeg-devel mailing list