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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
