Opened 8 months ago
Closed 7 weeks ago
#10887 closed defect (fixed)
HEVC periodic intra refresh source decoding artifacts, only with slice threading
Reported by: | Björn Weinehall | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | |
Cc: | Björn Weinehall | Blocked By: | |
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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
Attachments (2)
Change History (8)
comment:1 by , 8 months ago
comment:2 by , 8 months ago
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.
by , 8 months ago
Attachment: | hevc-pir-decode-sample-shortest.mpg added |
---|
Cleaner sample cut from live stream
comment:3 by , 8 months ago
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
by , 8 months ago
Attachment: | hevc-pir-decode-sample-standalone.mpg added |
---|
Standalone sample not from live stream, with clean start and end. The problem artifacts are slightly less visible in this sample.
comment:4 by , 8 months ago
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
comment:5 by , 8 months ago
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.
comment:6 by , 7 weeks ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed in 536bb988889eec08c5a1d5fd733f9e98569ae65e
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