Opened 6 years ago
Closed 6 years ago
#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 |
Description
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': Metadata: 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 Metadata: 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:1 by , 6 years ago
follow-up: 3 comment:2 by , 6 years ago
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 by , 6 years ago
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 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
All right, thanks. That difference in notation threw me off.
This was corrected in a follow up commit here:
7ff3d2594f9257ace9955086ccace0b36955fed3
422be081a3d8def358d40de3c68b00ddc0b75cdb
e3981c5a21872a6d11104f6a4fbf9be81a358a81