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