HEVC periodic intra refresh source decoding artifacts, only with slice threading

[Björn Weinehall]

Summary of the bug:

HEVC encoded using periodic intra refresh has clearly visible decoding artifacts, but only when using slice threaded decoding.
With frame threaded decoding or single-threaded decoding, the sample looks as expected.

The visible artifact can be described as excessive discoloration / corruption around the periodic intra refresh sweeping column, and repeats every 2 seconds or so in the sample.

The visibility of the artifacts varies a bit depending on encoded content, and the uploaded sample was chosen because of how obvious the problem is.

How to reproduce:

% ./ffplay -report -flags low_delay slice_thread_decode_artifacts-hevc-pir.mpg
ffplay version N-113840-g1bb7d5ca9f Copyright (c) 2003-2024 the FFmpeg developers

How to _not_ reproduce:

# frame-threaded decoding works as expected:
% ./ffplay slice_thread_decode_artifacts-hevc-pir.mpg

# single-threaded decoding works as expected:
% ./ffplay -threads 1 -flags low_delay slice_thread_decode_artifacts-hevc-pir.mpg

[Balling]

No. Please give full file too. You cut it wrong. All the warnings of PES size did not worry you?

Same happens with ffplay -vcodec hevc_cuvid hevc-pir-decode-sample-shortest.mpeg

so this is bad sample.

[aac @ 0000014c6f2c7640] TYPE_FIL: Input buffer exhausted before END element found

too

[Björn Weinehall]

Thank you for looking.
Sorry, I should have mentioned that this is a sample cur out from a live stream, so there's no clear starting point. Also the initial decoding corruption can be ignored due as those are from the bad cutting.
The visual artifacts I'm reporting are later recurring issues every ~2 seconds (which I believe is the PIR cycle.)
I'll try to recut the sample for a better starting point, though.

[Björn Weinehall]

Cleaner sample cut from live stream

[Björn Weinehall]

New sample attached. It is a cleaner cut from starting with a frame with VPS and doesn't end in the middle of a random TS packet.
Still, there's expected decoding artifacts for the first refresh period (the ~1 second) due to the nature of the sample being cut from a live source.
All following refresh periods have clear sweeping artifacts only with "-flags low_delay" as mentioned earlier.

Not sure if a usable clue or not, but i see now this error appear when ffplay reaches the end of the sample, but only with "-flags low_delay":

[hevc @ 0x7fa5cc33a6c0] entry_point_offset table is corrupted=0/0

[Björn Weinehall]

Standalone sample not from live stream, with clean start and end. The problem artifacts are slightly less visible in this sample.

[Björn Weinehall]

A couple of updates:

By checking different avcodec paths taken when decoding, only -flags low_delay uses the WPP decoding tools (hls_slice_data_wpp() and hls_decode_entry_wpp()).
The frame-threading (default), and single-threaded (-flags low_delay -threads 1) decoding uses non-WPP decoding entrypoints.

The sweeping artifacts are not reproducible with the reference decoder (v18.0):

ffmpeg -i hevc-pir-decode-sample-standalone.mpg -c:v copy -bsf hevc_mp4toannexb out.h265
./bin/TAppDecoderStatic -b out.h265 -o out.yuv
ffplay -f rawvideo -video_size 1920x1080 out.yuv

[quinkblack]

I know there are multiple issues in hevc decoder, especially related to multi-threads.
See the description at

​https://trac.ffmpeg.org/wiki/SponsoringPrograms/STF/2024#CleanupHEVCDecoder

I'll take a look but it will take some time.

[elenril]

Should be fixed in 536bb988889eec08c5a1d5fd733f9e98569ae65e