Opened 10 years ago
Closed 9 years ago
#4185 closed defect (fixed)
hevc regression
Reported by: | Carl Eugen Hoyos | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avcodec |
Version: | git-master | Keywords: | hevc regression |
Cc: | h.leppkes@gmail.com, Philip Langdale, fritsch@kodi.tv | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
As reported by Hendrik on irc, some frames are skipped for the hevc sample in http://www.demo-uhd3d.com/fiche.php?cat=uhd&id=22 (very slow download).
This is a regression since 2eddf3a6efd80aa6e9d7f42ad9a892a82c5ece70
$ ffmpeg -i UHD_ENT_Transformer_cut.hevc -f null - ffmpeg version N-68406-g5d0cfb5 Copyright (c) 2000-2014 the FFmpeg developers built on Dec 14 2014 02:32:20 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl libavutil 54. 15.100 / 54. 15.100 libavcodec 56. 14.100 / 56. 14.100 libavformat 56. 15.104 / 56. 15.104 libavdevice 56. 3.100 / 56. 3.100 libavfilter 5. 3.101 / 5. 3.101 libswscale 3. 1.101 / 3. 1.101 libswresample 1. 1.100 / 1. 1.100 libpostproc 53. 3.100 / 53. 3.100 [hevc @ 0x275de00] Stream #0: not enough frames to estimate rate; consider increasing probesize Input #0, hevc, from 'UHD_ENT_Transformer_cut.hevc': Duration: N/A, bitrate: N/A Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv, bt709), 3840x2160 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1200k tbn, 23.98 tbc Output #0, null, to 'pipe:': Metadata: encoder : Lavf56.15.104 Stream #0:0: Video: rawvideo (Y3[11][10] / 0xA0B3359), yuv420p10le, 3840x2160 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 23.98 fps, 23.98 tbn, 23.98 tbc Metadata: encoder : Lavc56.14.100 rawvideo Stream mapping: Stream #0:0 -> #0:0 (hevc (native) -> rawvideo (native)) Press [q] to stop, [?] for help [null @ 0x2765480] Encoder did not produce proper pts, making some up. frame= 118 fps= 43 q=0.0 Lsize=N/A time=00:00:05.08 bitrate=N/A video:11kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
Older versions of FFmpeg decoded 122 frames.
Attachments (3)
Change History (12)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
The reason for the problem, as far as I can see, is in the HEVC Spec, C.3.2
According to the spec, the removal from DPB should only be executed when NoRaslOutputFlag == 1 and no_output_of_prior_pics_flag == 1 or the current picture is a CRA.
However, the libavcodec decoder always performs the removal from the DPB when no_output_of_prior_pics_flag is set, regardless of NoRaslOutputFlag.
NoRaslOutputFlag is defined as follows in the spec:
The value of NoRaslOutputFlag is equal to 1 for each IDR access unit, each BLA access unit, and each CRA access unit that is the first access unit in the bitstream in decoding order, is the first access unit that follows an end of sequence NAL unit in decoding order, or has HandleCraAsBlaFlag equal to 1.
by , 10 years ago
Attachment: | hevc-norasloutputflag.patch added |
---|
A quick and dirty patch attempting to implement handling of NoRaslOutputFlag
comment:3 by , 10 years ago
The attached patch is quite certainly incomplete and the variable name i've chosen doesn't match coding style, but it at least solves the issue in this particular sample.
Anyone that actually knows how the HEVC decoder functions internally could use it as a hint of whats going wrong, its not fit to be commited as-is.
comment:4 by , 10 years ago
Cc: | added |
---|
by , 9 years ago
Attachment: | 0001-hevc-try-to-handle-the-NoRaslOutputFlag-logic.patch added |
---|
Updated patch to apply cleanly to 2.8+
follow-up: 8 comment:6 by , 9 years ago
Cc: | added |
---|
comment:7 by , 9 years ago
Cc: | added |
---|
comment:8 by , 9 years ago
Replying to cehoyos:
Replying to philipl:
From: Philip Langdale <philipl@overt.org>
Did you write this patch?
No. I had to reapply it by hand due to all the changes in the decoder since the original patch was written.
by , 9 years ago
Attachment: | 0001-hevc-properly-handle-no_rasl_output_flag-when-removi.patch added |
---|
New patch which more closely matches the spec and passes FATE
comment:9 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Commited as 0118158efa8e45761f9f65a3bb74f33907bd2aec
Short sample uploaded to http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4185/