[x264-devel] Possible bug in SPS writing

[Jason Garrett-Glaser]

On Thu, Sep 9, 2010 at 2:07 AM, Alexander Bokovikov
<openworld at uralweb.ru> wrote:
> Hi, All,
>
> I'm sorry, if it is my misunderstanding, but I can't understand what's
> happening. I'm using FFMPEG with libX264 to produce FLV files. My FLV player
> obtains movie frame size from the SPS, storeg in the
> AVCDecoderConfigurationRecord.
>
> All goes OK, but the only unclear point. Here is my command line (Win32):
>
> ffmpeg -i %1 -f flv -s 272x208 -vcodec libx264 -coder 1 -flags +loop -cmp
> +chroma -partitions +parti8x8+parti4x4+partp8x8+partb8x8 -me_method
> umh -subq 8 -me_range 16 -g 20 -keyint_min 15 -sc_threshold 40 -i_qfactor
> 0.71 -b_strategy 2 -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -bf 3 -refs
> 4 -directpred 3 -trellis 1 -flags2
> +wpred+mixed_refs+dct8x8+fastpskip -wpredp 2 -crf 25 -acodec libmp3lame -ab
> 64000 -ar 22050 -ac 1 -threads 0 -y %2
>
> ffmpeg was built with the latest libx264 SVN.
>
> As you can see, here is libx264-hq profile parameters, sent in the command
> line. The problem appears when I set "+dct8x8" in the flags2. Then I have
> strange (for me) data in the pic_width_in_mbs_minus1 and
> pic_height_in_map_units_minus1 fields of SPS. The first of them is always 10
> regardless to the actual width of movie (which is defined by -s parameter
> and is reported correctly by libx264 screen log). The second always is equal
> to the _WIDTH_ of frame in macroblocks, i.e. it is width / 16. I tried
> different frame sizes and always get such results.
>
> All is pretty correct, if I set "-dct8x8" in flags2. But most of x264
> profiles have this flag set to "+".
>
> I'm trying to understand if it is my misunderstanding or it is a real bug in
> the libX264. BTW, VLC player shows such files pretty correctly, but I don't
> know how it obtains the frame size data.
>
> Here are some data saved in the SPS record for "+dct8x8" flag being set and
> movie of 272 x 208 pixels in frame size:
>
> pic_width_in_mbs_minus1 + 1 = 10
> pic_height_in_map_units_minus1 + 1 = 17
> frame_mbs_only_flag = 0
> mb_adaptive_frame_field_flag = 0
> direct_8x8_inference_flag = 0
> frame_cropping_flag = 1
> frame_crop_left_offset = 0
> frame_crop_right_offset = 2
> frame_crop_top_offset = 0
> frame_crop_bottom_offset = 1
>
> The same source movie, encoded with all the same parameters but "-dct8x8"
> flag procuses such data:
>
> pic_width_in_mbs_minus1 + 1 = 17
> pic_height_in_map_units_minus1 + 1 = 13
> frame_mbs_only_flag = 1
> mb_adaptive_frame_field_flag = 0
> direct_8x8_inference_flag = 1
> frame_cropping_flag = 0
> frame_crop_left_offset = 0
> frame_crop_right_offset = 0
> frame_crop_top_offset = 0
> frame_crop_bottom_offset = 0
>
> The first unclear thing is why cropping is used in the first case, where no
> cropping is required because of picture size being multiple of 16.

You are most likely parsing the SPS or PPS incorrectly.

Jason