Opened 3 years ago

Closed 3 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 3 years ago.
final hevc->yuv444 conversion
ffmpeg-20151102-113519.log (6.6 KB) - added by psteinb 3 years ago.
mp4->yuv444 conversion for input
320x248.hevc (28.9 KB) - added by cehoyos 3 years ago.

Download all attachments as: .zip

Change History (22)

Changed 3 years ago by psteinb

final hevc->yuv444 conversion

Changed 3 years ago by psteinb

mp4->yuv444 conversion for input

comment:1 Changed 3 years ago by cehoyos

  • 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 Changed 3 years ago by psteinb

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 Changed 3 years ago by cehoyos

  • Resolution set to invalid
  • Status changed from new to 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 Changed 3 years ago by psteinb

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 Changed 3 years ago by cehoyos

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 Changed 3 years ago by psteinb

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

Changed 3 years ago by cehoyos

comment:7 Changed 3 years ago by cehoyos

  • Component changed from undetermined to avcodec
  • Keywords hevc added
  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Version changed from unspecified to git-master

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

comment:8 Changed 3 years ago by cehoyos

  • Reproduced by developer set
  • Status changed from reopened to open
  • Summary changed from yuv444 conversion in 1080p video of x265 native format broken? to yuv444p hevc wrong resolution if x265 ultrafast was used for encoding

comment:9 Changed 3 years ago by cehoyos

$ 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 follow-up: Changed 3 years ago by psteinb

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 in reply to: ↑ 10 Changed 3 years ago by cehoyos

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 follow-ups: Changed 3 years ago by psteinb

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:13 in reply to: ↑ 12 Changed 3 years ago by psteinb

Replying to psteinb:
Any news here?

comment:14 in reply to: ↑ 12 Changed 3 years ago by psteinb

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

comment:15 Changed 3 years ago by kurosu

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 3 years ago by kurosu (previous) (diff)

comment:16 Changed 3 years ago by heleppkes

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 Changed 3 years ago by kurosu

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

comment:18 Changed 3 years ago by cehoyos

  • Analyzed by developer set

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

comment:19 Changed 3 years ago by cehoyos

  • Keywords libx265 removed
  • Resolution set to fixed
  • Status changed from open to closed
  • Summary changed from yuv444p hevc wrong resolution if x265 ultrafast was used for encoding to yuv444p 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.