#7471 closed defect (invalid)

Patches for decimal vp9 values seemingly causing issues

Reported by: tbucher Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: vp9
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


It appears that the following patch https://patchwork.ffmpeg.org/patch/10157/ and possibly also https://patchwork.ffmpeg.org/patch/10338/ inadvertently broke what they were meant to fix in the first place. While their intent to fix handling VP9 level values as decimal was sound, for some reason they actually caused the opposite to happen.

I have two builds of FFmpeg to compare, an older one from commit 0bd48ab2d9e463b75ef52c0eaa0cc00c4c385cce from July 10th before these patches and one from today's master.

In both I run ffmpeg -f lavfi -i testsrc -t 4 -c:v libvpx-vp9 -b:v 8M -vf scale=-2:2160,format=yuv420p -g 100 -sc_threshold 0 -single_file 1 -f dash manifest.mpd as bare minimum command line to create a sample dash output with vp9 codec.

The full FFmpeg output log is irrelevant, but here it is for completeness' sake. I have intentionally used UHD for output to demonstrate the issue of written VP9 level and build from master is customized to include just libvpx encoder to save compilation time while testing, but it occurs in regular full build as well.

ffmpeg -f lavfi -i testsrc -t 4 -c:v libvpx-vp9 -b:v 8M -vf scale=-2:2160,format=yuv420p -g 100 -sc_threshold 0 -single_file 1 -f dash manifest.mpd
ffmpeg version N-92103-gebc3d04b8d Copyright (c) 2000-2018 the FFmpeg developers

  built with gcc 8.2.0 (Rev3, Built by MSYS2 project)
  configuration:  --disable-autodetect --enable-d3d11va --enable-dxva2 --enable-iconv --enable-lzma --enable-schannel --enable-zlib --enable-sdl2 --disable-debug --enable-libvpx --extra-libs=-liconv --enable-gpl
  libavutil      56. 19.101 / 56. 19.101
  libavcodec     58. 32.100 / 58. 32.100
  libavformat    58. 18.104 / 58. 18.104
  libavdevice    58.  4.105 / 58.  4.105
  libavfilter     7. 33.100 /  7. 33.100
  libswscale      5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc    55.  2.100 / 55.  2.100
Input #0, lavfi, from 'testsrc':
  Duration: N/A, start: 0.000000, bitrate: N/A
    Stream #0:0: Video: rawvideo (RGB[24] / 0x18424752), rgb24, 320x240 [SAR 1:1 DAR 4:3], 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (rawvideo (native) -> vp9 (libvpx-vp9))
Press [q] to stop, [?] for help
[libvpx-vp9 @ 00000000003e7940] v1.7.0-1133-g5062f3c18
[dash @ 000000000078f7c0] Opening 'manifest-stream0.m4s' for writing
Output #0, dash, to 'manifest.mpd':
    encoder         : Lavf58.18.104
    Stream #0:0: Video: vp9 (libvpx-vp9), yuv420p, 2880x2160 [SAR 1:1 DAR 4:3],
q=-1--1, 8000 kb/s, 25 fps, 12800 tbn, 25 tbc
      encoder         : Lavc58.32.100 libvpx-vp9
    Side data:
      cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1
frame=   26 fps= 24 q=0.0 size=N/A time=00:00:00.04 bitrate=N/A speed=0.0367x
frame=   30 fps= 17 q=0.0 size=N/A time=00:00:00.20 bitrate=N/A speed=0.113x
frame=   33 fps= 13 q=0.0 size=N/A time=00:00:00.32 bitrate=N/A speed=0.131x
frame=   38 fps=9.7 q=0.0 size=N/A time=00:00:00.52 bitrate=N/A speed=0.133x
frame=   40 fps=8.8 q=0.0 size=N/A time=00:00:00.60 bitrate=N/A speed=0.132x
frame=   42 fps=7.8 q=0.0 size=N/A time=00:00:00.68 bitrate=N/A speed=0.127x
frame=   44 fps=7.0 q=0.0 size=N/A time=00:00:00.76 bitrate=N/A speed=0.121x
frame=   46 fps=6.2 q=0.0 size=N/A time=00:00:00.84 bitrate=N/A speed=0.114x
frame=   49 fps=6.0 q=0.0 size=N/A time=00:00:00.96 bitrate=N/A speed=0.117x
frame=   51 fps=5.8 q=0.0 size=N/A time=00:00:01.04 bitrate=N/A speed=0.118x
frame=   53 fps=5.6 q=0.0 size=N/A time=00:00:01.12 bitrate=N/A speed=0.118x
frame=   55 fps=5.4 q=0.0 size=N/A time=00:00:01.20 bitrate=N/A speed=0.119x
frame=   56 fps=5.2 q=0.0 size=N/A time=00:00:01.24 bitrate=N/A speed=0.116x
frame=   58 fps=5.2 q=0.0 size=N/A time=00:00:01.32 bitrate=N/A speed=0.117x
frame=   60 fps=5.0 q=0.0 size=N/A time=00:00:01.40 bitrate=N/A speed=0.117x
frame=   62 fps=4.9 q=0.0 size=N/A time=00:00:01.48 bitrate=N/A speed=0.117x
frame=   64 fps=4.8 q=0.0 size=N/A time=00:00:01.56 bitrate=N/A speed=0.116x
frame=   66 fps=4.6 q=0.0 size=N/A time=00:00:01.64 bitrate=N/A speed=0.114x
frame=   68 fps=4.5 q=0.0 size=N/A time=00:00:01.72 bitrate=N/A speed=0.113x
frame=   70 fps=4.4 q=0.0 size=N/A time=00:00:01.80 bitrate=N/A speed=0.113x
frame=   72 fps=4.3 q=0.0 size=N/A time=00:00:01.88 bitrate=N/A speed=0.112x
frame=   74 fps=4.2 q=0.0 size=N/A time=00:00:01.96 bitrate=N/A speed=0.112x
frame=   78 fps=4.1 q=0.0 size=N/A time=00:00:02.12 bitrate=N/A speed=0.111x
frame=   80 fps=4.0 q=0.0 size=N/A time=00:00:02.20 bitrate=N/A speed=0.111x
frame=   82 fps=4.0 q=0.0 size=N/A time=00:00:02.28 bitrate=N/A speed=0.112x
frame=   84 fps=4.0 q=0.0 size=N/A time=00:00:02.36 bitrate=N/A speed=0.113x
frame=   86 fps=3.9 q=0.0 size=N/A time=00:00:02.44 bitrate=N/A speed=0.112x
frame=   88 fps=3.9 q=0.0 size=N/A time=00:00:02.52 bitrate=N/A speed=0.113x
frame=   90 fps=3.9 q=0.0 size=N/A time=00:00:02.60 bitrate=N/A speed=0.113x
frame=   92 fps=3.9 q=0.0 size=N/A time=00:00:02.68 bitrate=N/A speed=0.114x
frame=   94 fps=3.9 q=0.0 size=N/A time=00:00:02.76 bitrate=N/A speed=0.114x
frame=   96 fps=3.8 q=0.0 size=N/A time=00:00:02.84 bitrate=N/A speed=0.113x
frame=   98 fps=3.8 q=0.0 size=N/A time=00:00:02.92 bitrate=N/A speed=0.114x
frame=  100 fps=3.8 q=0.0 size=N/A time=00:00:03.00 bitrate=N/A speed=0.115x
[dash @ 000000000078f7c0] Opening 'manifest-stream0.m4s' for reading
[dash @ 000000000078f7c0] Opening 'manifest.mpd.tmp' for writing
frame=  100 fps=3.0 q=0.0 Lsize=N/A time=00:00:03.96 bitrate=N/A speed=0.118x

video:1886kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown

The m4s output from FFmpeg build before the patches has the following bytes in vpcC box for this UHD content

00 50 82 02 02 02

Since level should be written as decimal, 50 here is correct for UHD content with level 5.0 and generated mpd states codecs="vp09.00.50.08" which is also correct.

The m4s output from FFmpeg build from master after the patches has the following bytes in vpcC box

00 32 82 02 02 02

level 5.0 is written as 32 in hexadecimal and generated mpd states again codecs="vp09.00.50.08". Although the values are stored as hexadecimal, the dash muxer converts the codec string to decimal.

If I roll back the changes in master source code introduced by https://patchwork.ffmpeg.org/patch/10157/ , the bytes in vpcC box are again correctly decimal

00 50 82 02 02 02

however, dash muxer is considering it still hexadecimal after the other patch and writes invalid codecs="vp09.00.80.08" - level 8.0 does not exist. It looks like the change from https://patchwork.ffmpeg.org/patch/10338/ would need to be rolled back as well. Or there is something else in effect that is causing another conversion of what the patches write to the output.

Attempt to force the level with -level 5.0 does not make any difference in the output.

Change History (4)

comment:2 follow-up: Changed 20 months ago by tbucher

Well, yes, one would think so, but these commits are in the master source code that has the issue and actually 7ff3d2594f9257ace9955086ccace0b36955fed3 is https://patchwork.ffmpeg.org/patch/10338/ I referred to.

comment:3 in reply to: ↑ 2 Changed 20 months ago by jamrial

00 50 82 02 02 02
Since level should be written as decimal, 50 here is correct for UHD content with level 5.0 and generated mpd states codecs="vp09.00.50.08" which is also correct.

The above is an hex dump, not decimal. 0x50 being visible in an hex dump of the vpcC contents means it's wrong.

Since the values in the vpcC box are decimal, as defined in https://www.webmproject.org/vp9/mp4/#vp-codec-configuration-box, level 5 needs to be written as 50 (0x32) and not 0x50 (80).
The dash muxer was adapted to interpret them as decimal as well, and that's why the output is still codecs="vp09.00.50.08".

comment:4 Changed 20 months ago by tbucher

  • Resolution set to invalid
  • Status changed from new to closed

All right, thanks. That difference in notation threw me off.

Note: See TracTickets for help on using tickets.