-
-
Notifications
You must be signed in to change notification settings - Fork 792
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
Comments
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. |
I cut it from film i... downloaded, via ffmpeg (.bat command)
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. Here is two other fragments if you interested. From same source movie, but still. |
Thanks a lot for your quick reply. Then could you please share the link where you download the original film if possible? |
Technically, i could. For potentially legal reasons, i probably should not. [Violating ToS and depends on country you live in] |
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:
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.
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.
The text was updated successfully, but these errors were encountered: