Opened 9 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)

hevc-norasloutputflag.patch (2.8 KB ) - added by Hendrik 9 years ago.
A quick and dirty patch attempting to implement handling of NoRaslOutputFlag
0001-hevc-try-to-handle-the-NoRaslOutputFlag-logic.patch (2.8 KB ) - added by Philip Langdale 9 years ago.
Updated patch to apply cleanly to 2.8+
0001-hevc-properly-handle-no_rasl_output_flag-when-removi.patch (2.5 KB ) - added by Hendrik 9 years ago.
New patch which more closely matches the spec and passes FATE

Download all attachments as: .zip

Change History (12)

comment:2 by Hendrik, 9 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.
Last edited 9 years ago by Hendrik (previous) (diff)

by Hendrik, 9 years ago

Attachment: hevc-norasloutputflag.patch added

A quick and dirty patch attempting to implement handling of NoRaslOutputFlag

comment:3 by Hendrik, 9 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 Hendrik, 9 years ago

Cc: h.leppkes@gmail.com added

comment:5 by Philip Langdale, 9 years ago

This has come up in kodi testing here:

https://github.com/xbmc/xbmc/pull/7751

by Philip Langdale, 9 years ago

Updated patch to apply cleanly to 2.8+

in reply to:  5 ; comment:6 by Carl Eugen Hoyos, 9 years ago

Cc: Philip Langdale added

Replying to philipl:

From: Philip Langdale <philipl@overt.org>

Did you write this patch?

comment:7 by fritsch, 9 years ago

Cc: fritsch@kodi.tv added

in reply to:  6 comment:8 by Philip Langdale, 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 Hendrik, 9 years ago

New patch which more closely matches the spec and passes FATE

comment:9 by Hendrik, 9 years ago

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.