[FFmpeg-devel] [PATCH 0/4] Level 1b in h264_levels and h264_metadata

[Andreas Rheinhardt]

There are currently several issues with level 1b in h264_levels and
h264_metadata:
1. The most obvious is that the table in h264_levels.c is simply wrong:
The level_idc for 1b and profile 66, 77 or 88 is 11, not 10. The first
patch corrects this.
2. If profile is 66, 77 or 88 and one lets h264_metadata guess the level
and if the guess is 1b, then it currently simply writes the
level_idc corresponding to this profile; it does not set the
sps->constraint_set3_flag. If the standard used the current table, then
this meant that some tracks that should be set to 1b would be set to
1, a level too low; with the corrected table it means that a track
guessed to be 1b will be set to 1.1, a level higher than 1b.
(Both of this presumes that constraint_set3_flag wasn't already set.)
3. If the profile is 66, 77 or 88 and one lets h264_metadata set the
level to the level that shares the level_idc with 1b, but isn't 1b, then
it might be that the end result is nevertheless declared to be 1b: If
constraint_set3_flag was set at the beginning, it isn't unset.
If the new level has a different level_idc than 1b, then this implies
that the output uses a level/profile/constraint_set3_flag combination
that is reserved by ITU-T|ISO/IEC. Not good.

There are also two more patches included:
4. ff_h264_get_level currently does not give a correct result when used
with any of the High intra profiles: One either gets level 1b (when the
level_idc provided coincides with the level_idc of level 1b; notice that
this is the wrong answer in this case) or nothing (all other cases).
The function can simply be changed to give the correct answer in all
cases except when the input has is one of the High intra flavours whose
level_idc happens to agree with the level_idc of level 1b (for profiles
66, 77 and 88), i.e. with 11. This remaining case is unfixable given
that the arguments to the functions do not contain the profile.
5. If the bitstream_restriction-block in the VUI is absent and it is not
one of the intra-profiles, then max_dec_frame_buffering is currently
inferred to be H264_MAX_DPB_FRAMES, i.e. 16. This is wrong (the value to
infer depends upon the level and the DPB size). But this makes
ff_h264_guess_level very cautious: It only guesses levels so high that
16 frames fit into the DPB. I am not saying that being cautious is
wrong, but relying on a faulty parsing is. Instead my last patch
explicitly uses H264_MAX_DPB_FRAMES when max_dec_frame_buffering is only
inferred (if one wants to change the level, then it is likely that
something is wrong with the level so that it doesn't make sense to use a
value inferred from the old level to guess the new level).


Andreas Rheinhardt (4):
  h264_levels,h264_metadata_bsf: Fix levels typo
  h264_levels: Make get_level intra-profile friendly
  h264_metadata: Fix handling of level 1b
  h264_metadata: Don't use inferred value of buffering frames

 libavcodec/h264_levels.c       |  6 +++---
 libavcodec/h264_metadata_bsf.c | 27 ++++++++++++++++++++++-----
 2 files changed, 25 insertions(+), 8 deletions(-)

-- 
2.19.0