Opened 8 years ago
Closed 8 years ago
#4980 closed defect (fixed)
yuv444p and yuv422p hevc wrong resolution if x265 ultrafast was used for encoding
Reported by: | psteinb | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | git-master | Keywords: | hevc |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | yes |
Description
Summary of the bug:
Lossless roundtrips of 1080p yuv444 videos yields output video that does not match the input.
This is a continuation from
https://bitbucket.org/multicoreware/x265/issues/197/yuv444p-lossless-roundtrip-for-1080p
as the x265 devs don't think their app yields a problem. I post it here as a bug report.
How to reproduce:
Use http://ultravideo.cs.tut.fi/video/Jockey_1920x1080_30fps_420_8bit_AVC_MP4.mp4 as input video
$ ffmpeg -report -i Jockey_1920x1080_30fps_420_8bit_AVC_MP4.mp4 -pix_fmt yuv444p Jockey_1920x1080_30fps_444_8bit_AVC_MP4.yuv ffmpeg started on 2015-11-02 at 11:35:19 Report written to "ffmpeg-20151102-113519.log" ffmpeg version n2.8 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8.3 (GCC) 20140911 (Red Hat 4.8.3-9) configuration: --prefix=/home/steinbac/software/ffmpeg/2.8-x265master --enable-libx265 --enable-libx264 --enable-gpl --enable-shared libavutil 54. 31.100 / 54. 31.100 libavcodec 56. 60.100 / 56. 60.100 libavformat 56. 40.101 / 56. 40.101 libavdevice 56. 4.100 / 56. 4.100 libavfilter 5. 40.101 / 5. 40.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 2.101 / 1. 2.101 libpostproc 53. 3.100 / 53. 3.100 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Jockey_1920x1080_30fps_420_8bit_AVC_MP4.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf55.9.100 Duration: 00:00:20.00, start: 0.000000, bitrate: 2961 kb/s Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 2959 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default) Metadata: handler_name : VideoHandler File 'Jockey_1920x1080_30fps_444_8bit_AVC_MP4.yuv' already exists. Overwrite ? [y/N] y Output #0, rawvideo, to 'Jockey_1920x1080_30fps_444_8bit_AVC_MP4.yuv': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 encoder : Lavf56.40.101 Stream #0:0(und): Video: rawvideo (444P / 0x50343434), yuv444p, 1920x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default) Metadata: handler_name : VideoHandler encoder : Lavc56.60.100 rawvideo Stream mapping: Stream #0:0 -> #0:0 (h264 (native) -> rawvideo (native)) Press [q] to stop, [?] for help frame= 600 fps= 97 q=-0.0 Lsize= 3645000kB time=00:00:20.00 bitrate=1492992.0kbits/s video:3645000kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000% $ x265 --lossless --preset=ultrafast --input-depth 8 --input-res 1920x1080 --fps 30 --input-csp i444 Jockey_1920x1080_30fps_444_8bit_AVC_MP4.yuv Jockey_1920x1080_30fps_444_8bit_AVC_MP4_lrt.hevc yuv [info]: 1920x1080 fps 30000/1000 i444p8 frames 0 - 599 of 600 raw [info]: output file: Jockey_1920x1080_30fps_444_8bit_AVC_MP4_lrt.hevc x265 [info]: HEVC encoder version 1.8+43-04575a459a16 x265 [info]: build info [Linux][GCC 4.8.3][64 bit] 8bit x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2 x265 [info]: Main 4:4:4 profile, Level-8.5 (Main tier) x265 [info]: Thread pool 0 using 16 threads on numa nodes 0,1 x265 [info]: frame threads / pool features : 5 / wpp(34 rows) x265 [info]: Coding QT: max CU size, min CU size : 32 / 16 x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra x265 [info]: ME / range / subpel / merge : dia / 57 / 0 / 2 x265 [info]: Keyframe min / max / scenecut : 25 / 250 / 0 x265 [info]: Cb/Cr QP Offset : 6 / 6 x265 [info]: Lookahead / bframes / badapt : 5 / 3 / 0 x265 [info]: b-pyramid / weightp / weightb : 1 / 0 / 0 x265 [info]: References / ref-limit cu / depth : 1 / 0 / 0 x265 [info]: Rate Control : Lossless x265 [info]: tools: rd=2 psy-rd=0.30 early-skip tmvp fast-intra x265 [info]: tools: strong-intra-smoothing deblock x265 [info]: frame I: 3, Avg QP:4.00 kb/s: 349666.56 x265 [info]: frame P: 149, Avg QP:4.00 kb/s: 339413.76 x265 [info]: frame B: 448, Avg QP:4.00 kb/s: 220238.56 x265 [info]: consecutive B-frames: 0.7% 1.3% 0.7% 97.4% x265 [info]: lossless compression ratio 1.99::1 encoded 600 frames in 29.57s (20.29 fps), 250480.88 kb/s, Avg QP:4.00 $ ffmpeg -report -i Jockey_1920x1080_30fps_444_8bit_AVC_MP4_lrt.hevc -pix_fmt yuv444p Jockey_1920x1080_30fps_444_8bit_AVC_MP4_lrt.yuv $ md5sum Jockey_1920x1080_30fps_444*yuv bc55e7201dc65f6cc542dabd4dc50ba9 Jockey_1920x1080_30fps_444_8bit_AVC_MP4_lrt.yuv a5218f68414d8956e6e69bdb48301228 Jockey_1920x1080_30fps_444_8bit_AVC_MP4.yuv
Attachments (3)
Change History (22)
by , 8 years ago
Attachment: | ffmpeg-20151102-113752.log added |
---|
comment:1 by , 8 years ago
Keywords: | libx265 added; x265 removed |
---|
Why are you using a yuv420p input video to test yuv444p losslessness? Did you test ffv1 to confirm that there is a bug in FFmpeg? Did you test another hevc decoder to confirm a bug in FFmpeg?
Please test current FFmpeg git head to make this a valid ticket.
comment:2 by , 8 years ago
well, I needed some input and of yuv444p encoding. Feel free to suggest another file format as I am sure, the result will be the same. I don't understand the comment on ffv1 ... can you elaborate? There are not many x265 decoders around that can do yuv444. I'll check and try to reproduce.
comment:3 by , 8 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
I believe that the bug in x265 is reproducible with the following command line, workaround is to use -preset fast
:
$ ffmpeg -f lavfi -i testsrc=s=320x248 -vframes 1 -pix_fmt yuv444p -vcodec libx265 -preset ultrafast out.hevc
comment:4 by , 8 years ago
interesting:
$ ffmpeg -f lavfi -i testsrc=s=320x248 -vframes 10 -pix_fmt yuv444p out_10.yuv $ ffmpeg -f lavfi -i testsrc=s=320x248 -vframes 10 -strict experimental -pix_fmt yuv444p -vcodec libx265 -preset ultrafast -x265-params lossless=1 out_10_lossless.hevc $ ffmpeg -i out_10_lossless.hevc -pix_fmt yuv444p out_10_lrt.yuv $ md5sum out_10*.yuv cd5e06d1217f093c4265a94b30e11e53 out_10_lrt.yuv bbc307efc496e074b177b51f555f4437 out_10.yuv $ ffmpeg -f lavfi -i testsrc=s=320x248 -vframes 10 -strict experimental -pix_fmt yuv444p -vcodec libx265 -preset fast -x265-params lossless=1 out_10_lossless_fast.hevc $ ffmpeg -i out_10_lossless_fast.hevc -pix_fmt yuv444p out_10_lrt_fast.yuv $ md5sum out_10*.yuv bbc307efc496e074b177b51f555f4437 out_10_lrt_fast.yuv cd5e06d1217f093c4265a94b30e11e53 out_10_lrt.yuv bbc307efc496e074b177b51f555f4437 out_10.yuv
comment:5 by , 8 years ago
You don't need lossless encoding to reproduce the issue (and I suspect this is why nobody at x265 so far was able to explained the issue): Just look at the resolution of the encoded video.
comment:6 by , 8 years ago
this maybe, but the lossless roundtrip was my original use case. thanks for surfacing this problem.
by , 8 years ago
Attachment: | 320x248.hevc added |
---|
comment:7 by , 8 years ago
Component: | undetermined → avcodec |
---|---|
Keywords: | hevc added |
Resolution: | invalid |
Status: | closed → reopened |
Version: | unspecified → git-master |
Otoh, the reference decoder and FFmpeg disagree on the resolution of the attached sample...
comment:8 by , 8 years ago
Reproduced by developer: | set |
---|---|
Status: | reopened → open |
Summary: | yuv444 conversion in 1080p video of x265 native format broken? → yuv444p hevc wrong resolution if x265 ultrafast was used for encoding |
comment:9 by , 8 years ago
$ ffmpeg -i 320x248.hevc ffmpeg version N-76446-g23dffc7 Copyright (c) 2000-2015 the FFmpeg developers built with gcc 4.8 (SUSE Linux) configuration: --enable-libx265 --enable-gpl libavutil 55. 5.100 / 55. 5.100 libavcodec 57. 13.102 / 57. 13.102 libavformat 57. 13.100 / 57. 13.100 libavdevice 57. 0.100 / 57. 0.100 libavfilter 6. 14.101 / 6. 14.101 libswscale 4. 0.100 / 4. 0.100 libswresample 2. 0.100 / 2. 0.100 libpostproc 54. 0.100 / 54. 0.100 Input #0, hevc, from '320x248.hevc': Duration: N/A, bitrate: N/A Stream #0:0: Video: hevc (Rext), yuv444p(tv), 320x240 [SAR 1:1 DAR 4:3], 25 fps, 25 tbr, 1200k tbn, 25 tbc
The reference decoder decodes the sample as 320x248 which I used for encoding:
$ ffmpeg -f lavfi -i testsrc=320x248 -pix_fmt yuv444p -strict -2 -vframes 100 -preset ultrafast 320x248.hevc
follow-up: 11 comment:10 by , 8 years ago
btw, I updated my x265 issue with the information, you guys suggested:
https://bitbucket.org/multicoreware/x265/issues/197/yuv444p-lossless-roundtrip-for-1080p
comment:11 by , 8 years ago
Replying to psteinb:
btw, I updated my x265 issue with the information, you guys suggested
The innocent reader will still assume that you want to report an issue with the lossless option...
follow-ups: 13 14 comment:12 by , 8 years ago
OK, the x265 people think the ffmpeg decoder is wrong. As I am by no means an expert in this, I won't look into the code. I am copy and pasting my reply on https://bitbucket.org/multicoreware/x265/issues/197/yuv444p-lossless-roundtrip-for-1080p:
Ok, I took the yuv444p ducks_take_off sample from here: https://media.xiph.org/video/derf/ (using the x265 tip and ffmpeg master pulled/checkedout on Nov 17, 1:40 CET)
$ x265 --lossless --preset=ultrafast --input-depth 8 --input-res 1200x720 --fps 50 --input-csp i444 ducks_take_off_444_1200x720p50.yuv ducks_take_off_444_1200x720p50_lossless_ultrafast.hevc $ ffmpeg -i ducks_take_off_444_1200x720p50_lossless_ultrafast.hevc -pix_fmt yuv444p ducks_take_off_444_1200x720p50_lossless_ultrafast.yuv $ ${HOME}/software/jctvc-hm/repo/bin/./TAppDecoderStatic -b ducks_take_off_444_1200x720p50_lossless_ultrafast.hevc -o ducks_take_off_444_1200x720p50_lossless_ultrafast_HM.yuv --OutputColourSpaceConvert=UNCHANGED $ md5sum ducks_take_off_444_1200x720p50.yuv ducks_take_off_444_1200x720p50_lossless_ultrafast.yuv ducks_take_off_444_1200x720p50_lossless_ultrafast_HM.yuv c1d2b822af36d5bd84f3f1a516851b45 ducks_take_off_444_1200x720p50.yuv 022c44ad7e5623144e0e7082db243fd4 ducks_take_off_444_1200x720p50_lossless_ultrafast.yuv 2ea9da8efee359221599b502413e957b ducks_take_off_444_1200x720p50_lossless_ultrafast_HM.yuv
Note I took the HEVC reference decoder from the master branch of:
git://hevc.kw.bbc.co.uk/git/jctvc-hm.git
comment:15 by , 8 years ago
EDIT: Nevermind, ffmpeg always multiplies by 2 the default window offset (assuming 4:2:0), while it should use a coordinate system that depends on the chroma format.
comment:16 by , 8 years ago
There is a comment in the conformance window parsing:
"TODO: * 2 is only valid for 420"
Maybe that causes the values to be too large?
comment:17 by , 8 years ago
@heleppkes, yes just noticed that, and edited my comment, without noticing your comment.
comment:18 by , 8 years ago
Analyzed by developer: | set |
---|
I can confirm that out-commenting "*2" makes decoding bit-exact.
comment:19 by , 8 years ago
Keywords: | libx265 removed |
---|---|
Resolution: | → fixed |
Status: | open → closed |
Summary: | yuv444p hevc wrong resolution if x265 ultrafast was used for encoding → yuv444p and yuv422p hevc wrong resolution if x265 ultrafast was used for encoding |
Should be fixed in a6a52ef29ac2e8b9cdba110f076b544f98fbf646 - thank you for the report!
final hevc->yuv444 conversion