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)

ffmpeg-20151102-113752.log (108.2 KB ) - added by psteinb 8 years ago.
final hevc->yuv444 conversion
ffmpeg-20151102-113519.log (6.6 KB ) - added by psteinb 8 years ago.
mp4->yuv444 conversion for input
320x248.hevc (28.9 KB ) - added by Carl Eugen Hoyos 8 years ago.

Download all attachments as: .zip

Change History (22)

by psteinb, 8 years ago

Attachment: ffmpeg-20151102-113752.log added

final hevc->yuv444 conversion

by psteinb, 8 years ago

Attachment: ffmpeg-20151102-113519.log added

mp4->yuv444 conversion for input

comment:1 by Carl Eugen Hoyos, 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 psteinb, 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 Carl Eugen Hoyos, 8 years ago

Resolution: invalid
Status: newclosed

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 psteinb, 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 Carl Eugen Hoyos, 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 psteinb, 8 years ago

this maybe, but the lossless roundtrip was my original use case. thanks for surfacing this problem.

by Carl Eugen Hoyos, 8 years ago

Attachment: 320x248.hevc added

comment:7 by Carl Eugen Hoyos, 8 years ago

Component: undeterminedavcodec
Keywords: hevc added
Resolution: invalid
Status: closedreopened
Version: unspecifiedgit-master

Otoh, the reference decoder and FFmpeg disagree on the resolution of the attached sample...

comment:8 by Carl Eugen Hoyos, 8 years ago

Reproduced by developer: set
Status: reopenedopen
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 Carl Eugen Hoyos, 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

comment:10 by psteinb, 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

in reply to:  10 comment:11 by Carl Eugen Hoyos, 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...

comment:12 by psteinb, 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

in reply to:  12 comment:13 by psteinb, 8 years ago

Replying to psteinb:
Any news here?

in reply to:  12 comment:14 by psteinb, 8 years ago

Last edited 8 years ago by psteinb (previous) (diff)

comment:15 by Christophe, 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.

Last edited 8 years ago by Christophe (previous) (diff)

comment:16 by Hendrik, 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 Christophe, 8 years ago

@heleppkes, yes just noticed that, and edited my comment, without noticing your comment.

comment:18 by Carl Eugen Hoyos, 8 years ago

Analyzed by developer: set

I can confirm that out-commenting "*2" makes decoding bit-exact.

comment:19 by Carl Eugen Hoyos, 8 years ago

Keywords: libx265 removed
Resolution: fixed
Status: openclosed
Summary: yuv444p hevc wrong resolution if x265 ultrafast was used for encodingyuv444p and yuv422p hevc wrong resolution if x265 ultrafast was used for encoding

Should be fixed in a6a52ef29ac2e8b9cdba110f076b544f98fbf646 - thank you for the report!

Note: See TracTickets for help on using tickets.