Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

While using D3D11 HW decoder on AMD GPU, AVC video with SEI recovery non-IDR keyframes is being occasionally corrupted on seek. #580

Open
DimkaTsv opened this issue Feb 15, 2024 · 4 comments

Comments

@DimkaTsv
Copy link

DimkaTsv commented Feb 15, 2024

Full details on my issue are described here: GPUOpen-LibrariesAndSDKs/AMF#447
As well as discussion with AMF developer on this topic.

Video sample [cut to 1 minute, 1:03 due to "key-frames"]: https://drive.google.com/file/d/1bBhxS3vGQOQVn-mzR2cLFMFdCcfOZUHX/view?usp=drive_link

System spec:

  • OS: Windows 11, 23H2, build 22631.3085
  • Driver Version: 24.1.1
  • GPU: RX 7800XT

Description: I have video, that was encoded by using only 1 IDR I-frame at beginning, and then every other keyframe was done via SEI (recovery_point) + non-IDR I-frame combination [with exact_match flag]. When i seek through it [mostly by using arrow keys in MPC-HC or other players to skip few seconds], i can encounter several situations. When video is simply being played - no issues, meaning problem is exclusively for seek functionality.

  1. Video plays back normally as if nothing happen. (it does sometimes happen)
  2. Video freezes frame and starts flicker to different frame
  3. Video corrupts frame by either green, blue or rainbowy artifacts
  4. Video corrupts as if is corruption artifacts or square-blocky corrupted frame data
    Every issue can happen both instantly after seek, or within few seconds
    Corruption effects can overlap with frame freeze effect.
    When issue triggers it can last from second or two up to 10 seconds (until it hits new key frame?) but no more.

In MPC-HC issue only appears on D3D11 HW acceleration, DXVA2 (both native and copy-back) looks to be safe. It also doesn't happen on Nvidia GPU's based on few tests, which i managed to get from other people (while they streamed that to me).

But! In other players this issue is persistent, including Windows default ones. In every single one. Severity often not AS bad in MPC-HC or VLC though (frequency is less and frame freezes are mush less frequent occurence compared to artifacting, with small seek skip length it can potentially be affected if seeking backwards, but with large one, it will corrupt more if i move forwards.
In D3D11 MPC-HC [tried MPC-VR, MadVR and custom EVR], and VLC it will corrupt easily both ways even on small sample as seek skip time is not tied to video duration, i assume). And in VLC, for example, even DXVA2 mode is affected, compated to MPC-HC.

With FFmpeg i can cut fragments from video without problems, and it will be cut according to SEI marked non-IDR I-frames as keyframes, meaning it will playback fine. But seek functionality will still be in same exact state.

In MPC-HC i noted that skips despite being generally spaced as 0-10-12-17-27-37-49(50)-59-63 seconds, sometimes instead of 37 it skips to 39. If you pause and skip, it will be 27-->37, but 49-->39 instead. VLC doesn't follow this trend, as it always skips 10 seconds.

Originally i thought that it was AMF related problem, but after long discussion and some research on my side i came to conclusion that it was not, as from discussion i understood that HW decoder only passes filled with data structures, and processing of data is being done by recieving side.


Currently i am interested in reason why could that happen, why behaviour is different between DXVA2 and D3D11 in MPC-HC, is it even fixable (it should be based on how other people play it), and where/how should it be fixed so i could at least attempt to ask for resolve (even if it will depend on wish of developers).

Sorry for asking too many questions.

@DimkaTsv DimkaTsv changed the title While using D3D11 HW decoder on AMD GPU, AVC stream with SEI recovery non-IDR keyframes is being occasionally corrupted on seek. While using D3D11 HW decoder on AMD GPU, AVC video with SEI recovery non-IDR keyframes is being occasionally corrupted on seek. Feb 15, 2024
@foikuf1
Copy link

foikuf1 commented Feb 21, 2024

Could you please show me how you created your video sample? Like the command line you used? I have almost the same system as yours. Is it possible that I can make one video like this on my own?

Also, is this issue only reproducible with this single video sample attached? Is there any other videos created on the same way has the same issue?

It would be much appreciated if you can help me out with these questions.

@DimkaTsv
Copy link
Author

DimkaTsv commented Feb 21, 2024

Could you please show me how you created your video sample? Like the command line you used? I have almost the same system as yours. Is it possible that I can make one video like this on my own?

I cut it from film i... downloaded, via ffmpeg (.bat command)

set /p Time_1=Write time of fragment start (FORMAT: hh:mm:ss.ms): 
set /p Time_2=Time of the end of fragment (in hh:mm:ss.ms): 
%~dp0\ffmpeg -hwaccel d3d11va -ss %Time_1% -to %Time_2% -i %1 -c copy "%~n1_fragmented%~x1"
pause

I guess you could find other sources like this? Usually this is how some live cameras or encoders write, due to potential issues with having locked keyframe intervals there, but it is neither common nor widespread method. So, i won't be able to find these ones for you. Frankly speaking in only stumbled on that movie myself at random basically.
Tbh ALL bugs i encounter on some random usage case or source. (As result have like 5 different encoder/decoder issues opened right now, and few more were fixed at some point)

Here is two other fragments if you interested. From same source movie, but still.
https://drive.google.com/file/d/1zhXaEe4ALf6Ys1kDXDS5jUvqFhlq3ADt/view?usp=drive_link
https://drive.google.com/file/d/1_WKRC17Vb24d15TbpwnfmLfy2vfolDJA/view?usp=drive_link

@foikuf1
Copy link

foikuf1 commented Feb 21, 2024

Thanks a lot for your quick reply. Then could you please share the link where you download the original film if possible?

@DimkaTsv
Copy link
Author

DimkaTsv commented Feb 22, 2024

could you please share the link where you download the original film

Technically, i could. For potentially legal reasons, i probably should not. [Violating ToS and depends on country you live in]
On other hand, i think, i can just share original source though:
https://drive.google.com/file/d/1Qcs3bKsUkMpg-cHUgJqXh-jg8RZ1goe4/view?usp=sharing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants