[Investigation]: DX11 HW decode can cause image corruption on quick time skipping in some sources

[DimkaTsv]

Describe the bug Bug is specific to source, so it may be not AMF related, but source issue. When doing fast skipping by 5-10 seconds forward in back, video gets corrupted by either: 1) Gets stuck to 1 frame while flickering another 2) Parts of image gets heavily corrupted by either greenish or rainbowy artifacs, while video continues to play. 3) Parts of image will get "compression" artifacts all over it (even though there are none). Issue can appear about second after fast scroll After triggering every appearance issue lasts for up to 10 seconds (on eye), after which cease to persist. Then video plays like normal, until you repeat time skip.

While playing normally (without skipping), issue does not appear at all. Described issue disappears after transcoding source (via hw decode and hw encode).

But reason for being reported here as well is that issue appears ONLY on DX11 HW acceleration. DXVA2 (both copy-back and native) as well as CPU decode were not affected. So there can be some underlying issue going on.

Personally tested in MPC-HC [MPCVR, MadVR, customEVR], VLC, Windows 11 "Movies and TV" app, Windows 11 "Photos" app, old Windows Media Player. All were affected, some more, some less. MPC-HC and VLC were affected most severely, then Windows 11 "Movies and TV" with Windows Media Player. Triggering issue on Windows 11 "Photos" app was hardest but doable.

To Reproduce Steps to reproduce the behavior:

1. Use this source [it is cropped, but bug persists through WHOLE video]: https://drive.google.com/file/d/1bBhxS3vGQOQVn-mzR2cLFMFdCcfOZUHX/view?usp=sharing
2. Use MPC-HC
3. Setup HW Decoder to use D3D11
4. Play video
5. Start skipping by using arrow keys. After each skip wait second or two.
6. Observe bugged behaviour

Setup (please complete the following information):

• OS: Windows 11, 23H2, build 22631.3085
• Driver Version: 24.1.1
• GPU: RX 7800XT
• Which component has the issue: Decoder (potentially)

Debug Log (please upload or paste): No logs here, transcoding goes fine. Meaning issue is only on playback of specific source.

Expected behavior No such corruption should occur

Screenshots 1) Green artifacting

2) Rainbowy artifacting

3) "Compression artifact"-like effect, or fade in issue

Additional context Issue seems to be appearing at same exact places, but appearance can be random. Sometimes it will be green corruption, sometimes rainbow, and sometimes it will be compression-like artifacts. All of those can combine with frame freeze, while frame freeze with flickering can also happen by itself. Sometimes it may not even appear at all, and play normally

[MikhailAMD]

From general perspective, seeking is usually not decoder issue. If one wants to accurately seek without visible corruption, it is up to the calling app to find proper keyframe (IDR, not just I-frame) before the seek point in demuxer, decode up to the required point in time and then start presenting. Decoder doesn't know about all of this. Usually app calls Flush() in AMF terms to clear all decoder buffering/history and start submitting compressed buffers again. All apps you mentioned are not AMF-based. And while they all use D3D11VA API, the decoder logic, decoder parser and demuxer are all different, so it kid of points to the file itself. Out of curiosity, you may try AMF sample PlaybackHW. It has Seek bar popup.
Also did you try other files that are known to be correct? BTW: the file you provided doesn't have IDR frames at all, and have many errors reported by analyzer, so I would expect seek problems like the ones you reported.

[DimkaTsv]

Thank you for quick answer here, Mikhail. My main suspicions definitely were that decoder was not in fault, and person who encoded video messed something up hard. [even though he wrote video with sw H.264 library] But i still wrote it up here as potential bug just to be sure that i didn't miss anything (because if it was actual issue, then ignoring it would be wrong)

I know apps are not AMF based, but they use HW acceleration, and i assumed that AMF is intermediary.

Frankly speaking i did try other files, and hadn't encountered issues with those (well, i guess except ones that described in another bug report i posted today. That one is actually applicable to AMF bug). That's why i stated that issue is specific to source. Fact that after transcoding issue was gone supports this point.

BTW: the file you provided doesn't have IDR frames at all, and have many errors reported by analyzer, so I would expect seek problems like the ones you reported.

Oh my. Well, then, i guess my guess was correct and issue was actually that person who worked on that video was sloppy with parameters or libraries? Any advice on what analyzer i should use to check such files in the future? ffprobe didn't show me much, but maybe i just don't know proper arguments?

---

Ehmm... How do i use PlaybackHW from source code? As far as i can see there is no executable and everything is... well... source. I guess i need to compile it (oh, it will be my first time ever, so it might take a while. But i at least found instructions. )

Oh, well, after about 30 minutes of installing stuff and troubleshooting why it won't compile (it needed bit more specific atlbase.h version than i installed), i managed to compile and use PlaybackHW.

It still corrupted image on skips, BUT!!! All these corruptions weren't colorful, meaning they looked always like bad compression artifacting. And in addition to that timeline was extremely sticky. Often it didn't want to skip forward or backwards by one step, and returned to the same frame i used skip on.

[MikhailAMD]

The issue with stick-ness of seek bar in PlaybackHW is probably related to the lack of IDRs. You can find seeking logic in ffmpeg demuxer wrapper in AMF samples. I use Vega analyzer from Interra but license is pricy.

[DimkaTsv]

The issue with stick-ness of seek bar in PlaybackHW is probably related to the lack of IDRs. Yeah, in my eyes issue looked like something had been broke with key frames. Either delayed or corrupted.

I use Vega analyzer from Interra but license is pricy.

Oh... I am just an amateur, so paying for license on tool which i will use once at full moon is bit too much Thanks for information though. Can there be some free alternative in terms of video analyzing?

I guess i can close this issue as problem is on source side? Interesting nuance is that it plays and skips fine on any backend except D3D11... Didn't test Vulkan though.

---

Probably i was too hasty to think about closing it right now. But i do see that problem is mostly due to the bad video, and not decoder. It is just "DX11 being much worse in terms of artifacting, while other backends work fine" part kinda sits at the back of the mind here.

---

Ah, to hell with it, it is not AMF problem to solve. Too source specific to be actual problem. Sorry for bothering.

[DimkaTsv]

Did some more investigation with help of other people, after which decided to reopen issue (so it could be potentially forwarded).

New, slightly more extensive, information

• This issue does not exist for Nvidia NVENC decoding (D3D11) [people had 4090 and 3060 12GB], On my GPU issue also won't appear in MPC-HC if i do CPU decoding and DXVA (both native and copy-back)

• When i open video through PlaybackHW module based on presenter it will:

1. Vulkan does not play past first second. Clicking on timeline does nothing.
2. DX12 also won't play past first second. Clicking in general does nothing, but RANDOMLY it can snap on some frame just to get stuck again in fraction of second
3. OGL plays, and skipping with arrow keys causes corruption to appear
4. DX9 plays, skipping causes corruption
5. DX11 plays, skipping causes corruption

Now i am more interested why DXVA (native and copy-back) in MPC-HC plays fine? And why everything else does not? And who this issue should be addressed towards?

[MikhailAMD]

Error concealment may work differently in GPU decoders but unlikely anyone would try to change it for a broken video file. The only guarantee is compliant clips. Also, without seeking the clip is played in DX9 and DX11. And as I said, seeking needs IDRs, that are missing.

[DimkaTsv]

And as I said, seeking needs IDRs, that are missing.

Error concealment may work differently in GPU decoders

I understand that. So your guess is that this issue be related to some nuance in part of DX11 driver implementation responsible for HW Decode processing? Or is that issue lies more towards HW decoder on-die implementation, rather than SW?

I get that this video is broken in terms of keyframes, but it is not only reason for this problem to appear. Because if i use DXVA2 as HW acceleration backend, video actually skips without problems. (as well as with CPU decode and NVENC D3D11), meaning that video CAN be properly interpreted and even while using AMD HW acceleration, but for some reason it does not happen correctly for D3D11 HW acceleration.

I am assuming based on parameters that PlaybackHW presented me with, is that it only allows you to change presenter, rather then decoder? (that will explain different interaction, but stream itself they all manage to get still processed through same API and gets corrupted by skips before application gets chance to interpret)? Meaning that it is somewhere else in chain that issue happen. Question for me is where issue can be located in this chain.

Can it be potential issue in DX11 driver part which corresponds to HW decoder interaction? Not AMF, not application, not hardware itself (because DXVA2 works properly), but DX11 driver? Originally i would've also thought on LAV library, but, again... DXVA2 works, and issue is not specific to MPC-HC (i managed to trigger it on every player i tried. Just frequency of artifacting varied. VLC and MPC-HC had most artifacting).

[MikhailAMD]

All this going into pure speculation. It could be just different memory initialization details in drivers. The decode part between DXVA and D3D11VA is almost identical. PlaybackHW parameter in reality changes whole pipeline : decoder, color converter and presenter between DX9(DXVA), DX11 (VA), DX12 (VA), Vulkan. For OGL selection, the decoder is DX11VA, color converter is OpenCL, presenter is OGL. It is unfortunate naming in menu -will have to change it at some point. Note, that AMF decoder calls the same APIs: DXVA, DX11VA, DX12VA, Vulkan decode. AMF has own private stream parser.

[DimkaTsv]

Did even more digging and probably found something. [Stumbled on that singluar free web-based tool that allows parsing of videos on frame data. Not as detailed as yours, but enough to get general glimpse]

Firstly there actually was singular IDR frame at very beginning of video (ngl, if there wasn't i would've questioned a lot of things from creator of video), all others are encoded as non-IDR I frames. It is just ffmpeg cropped... Nah, it actually cropped at "I" frame, just non-IDR.

But what is more important is these SEI segments right before those non-IDR I frames.

They are marked for me as "AVC SEI (recovery_point)", and based on this patent https://patents.google.com/patent/US20150382018A1/en and specs of AVC and HEVC based on information from ISO/IEC 14496-10 (which i can look into freely) and ISO/IEC 23008-2 (which i can not without buying document) ISO/IEC 14496-10 = AVC page 358 - Annex D: Supplemental enhancement information

SEI messages assist in processes related to decoding, display or other purposes. However, SEI messages are not required for constructing the luma or chroma samples by the decoding process.

page 385 - D.2.8 Recovery point SEI message semantics [looks like important]

The recovery point SEI message assists a decoder in determining when the decoding process will produce acceptable pictures for display after the decoder initiates random access or after the encoder indicates a broken link in the coded video sequence. When the decoding process is started with the access unit in decoding order associated with the recovery point SEI message, all decoded pictures at or subsequent to the recovery point in output order specified in this SEI message are indicated to be correct or approximately correct in content.

The recovery point is specified as a count in units of frame_num increments subsequent to the frame_num of the current access unit at the position of the SEI message...

Next to SEI point there is non-IDR I-frame which has flag [frame_num 3]

SEI block itself only contained single flag - exact_match_flag. Which as i understood tells decoder that if decoder starts from next frame result should be same as if decoder parsed to same frame from previous IDR point. Sounds like alternate keyframe.

exact_match_flag indicates whether decoded pictures at and subsequent to the specified recovery point in output order derived by starting the decoding process at the access unit associated with the recovery point SEI message shall be an exact match to the pictures that would be produced by starting the decoding process at the location of a previous IDR access unit in the NAL unit stream. The value 0 indicates that the match need not be exact and the value 1 indicates that the match shall be exact.

Then there is talk about usage of broken_link_flag which is not used in my case, but indicates decoder "the location of some pictures in the bitstream that can result in serious visual artifacts when displayed, even when the decoding process was begun at the location of a previous IDR access unit in decoding order."

--> Referral to ISO/IEC 23002-7 for syntax and semantics --> page 8: SEI messages. Table 4

I also checked 5 or 6 non-IDR frames to be sure. Every single one of them had this sequence.

AVC Sequence Parameter Set (SPS) 
AVC Picture Parameter Set (PPS) 
AVC SEI (recovery_point) 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 
AVC Non-IDR Slice, I 

Timestamps marks were often on such frames, but also sometimes were slightly off. This one should not matter, i think. Amount of frame_num on next frame varied heavily. I saw 3, 18 and 26 just in three I frames i checked.

[MikhailAMD]

SEI messages are not processed by HW decoders. Check FFmpeg code for example and search from SEI_TYPE_RECOVERY_POINT

[DimkaTsv]

SEI messages are not processed by HW decoders.

So... If i understood correctly these messages are being passthrough to application which should be able to interpret them and tell HW decoder to "reset decoder buffer", "copy stream parameters from SPS/PPS header of file", "roll back or forward to closest I-frame, even if it is not IDR", then and "start from here"?

At least that was Intel side told as way of handling this issue for those who write playback or stream parser applications if i understood correctly? https://community.intel.com/t5/Media-Intel-Video-Processing/IDR-non-IDR-slice-I-frame-SEI-recovery-point-how-to-do-H264/td-p/995523

But after i looked at Nvidia repo, they mention something about driver support? What could that mean? https://github.com/NVIDIA/VideoProcessingFramework/issues/218

This is caused by the Video Codec SDK implementation which so far can only do random access to closest IDR I frame in the past, then to decode frames until the actual seek frame is reached. This is done in such a way because IDR I frame is to be preceded by SPS and PPS NALU which may cause decoder reconfigure (unlike non-IDR I frame).

In this video, Recovery Point is non-IDR I frame, hence the behavior mismatch between FFMpeg demuxer which can jump to non-IDR I frame and decoder which can't. If random access to non-IDR I frame is added to driver, I'll re-open this issue and will ask originator to confirm.

I don't think that such feature was added, as this issue hadn't been reopened. But for now it looks like that issue was mitigated based on what i saw from 2 different people. Moreover, they had no issues in multiple players. But, again, now i wonder why in MPC-HC only D3D11 was affected for me, but all other applications, including Windows default ones, were affected in full. VLC, for example had both D3D11 and DXVA2 to provide me corrupt image on seek, even though DXVA2 did it slightly less frequently(?)). What part of chain is not working right?

I also found this one which proves your point.

From the libaviutil point of view keyframe is IDR (instant decode refresh, you are sure that no preceding context is needed to fully resume decoding from that frame) or just resume point (it is used for streaming, some past context is needed but if you seek over the same video file you have it). FFmpeg can resume decoding from both, NVDEC only from IDR. So if the first keyframe is just the refresh point and the next one is IDR you won't decode anything in between so you need to go to one before the refresh point in the hope this is an IDR frame.

I see LAV filters repo having commit related to sei_recovery... As well as libavcodec has variables for it. So i guess it should be processed on level of either LAV or libav libraries? And it probably does work, based on how i can freely cut fragments from video, based on existing non-IDR I-frames, without corrupting up to 10 seconds of stream beginning. But why is seek functionality not working in SOME places/setups then? Is it issue on application side, or is it on driver side? Well, imo, but based on fact that somehow, in one place it actually works properly, means that it is not that likely to be drivers specifically (especially as DXVA2 in MPC-HC works, but in VLC doesn't). But where should i try to report this to, then...

---

[there is also no sei_recovery_point for HEVC based on what i saw in those repos, if i understood correctly... it is because "recovery_point" is not specified in HEVC spec? I cannot look into ISO documentation for this one to be sure.]

[MikhailAMD]

HW decoder accelerators like DXVA or D3D11VA or Vulkan Video don't work on any of H264 or H265 binary specs. The elementary stream parsing happens outside of the driver and the APIs. These APIs receive filled-in C structures defined by the API. The accelerators don't even manage reference frames or do frame reordering. It is done in the code like FFmpeg, AMF or Media Foundation. So any handling if SEI happens outside of the driver. It seem Video Codec SDK has parser/demuxer inside the SDK or they would not talk about seeking, Different players have different demuxers, different elementary stream parsers and different logic to call DXVA/D3D11VA APIs. So they may behave differently on the faulty stream. The problem may be in any part but player developers don't want to spend much time supporting faulty streams. FFmpeg which is used in some cases doesn't even handle SEI recovery point.

[DimkaTsv]

The elementary stream parsing happens outside of the driver and the APIs. These APIs receive filled-in C structures defined by the API. The accelerators don't even manage reference frames or do frame reordering. It is done in the code like FFmpeg, AMF or Media Foundation. So any handling if SEI happens outside of the driver.

Oh, now i guess i understand what you mean. Basically neither driver, not AMF don't quite control decoding process itself, and basically just provide structured blobs of data to demuxer and decoder, which then tell driver/API/decoder to perform actions according to info they extract from data and/or get from user input.

It seem Video Codec SDK has parser/demuxer inside the SDK or they would not talk about seeking,

Ngl, i don't think so. They hadn't mentioned that he should use this functionality from Media SDK. Person who asked wrote demuxer for AVC himself

As of now I have written a demuxer for mts container files that feeds the H264 video stream to the Intel Media SDK decoder. That works as expected and I can extract and render all of the stream's frames.

So i think Intel meant that repositioning should be done on his side and only then requested new data from Media SDK. So we basically return to same exact starting point that it must be done on level after decoding.

FFmpeg which is used in some cases doesn't even handle SEI recovery point.

I guess not by itself, but it uses libavcodec [source libavcodec->h.264_sei.c] which does handle them based on github repo. At least when i use seek function to crop fragment of video it comes aligned to I frames (SEI ones ofc) from what i checked, and not garbled from beginning. But using --ss to actually extract single frame will cause ffmpeg to parse through whole video, and it doesn't matter if video encoded with proper IDR frames or SEI I-frames instead. And when parsing through video ffmpeg doesn't scream "SEI not implemeted" error for every recovery_point, like it does for me on some other video (idk though if it does it on buffering_point or pic_timing though). Meaning ffmpeg at least does understand them.

There is no visible support recovery point for HEVC, though. And i am not sure if this one is within spec like for AVC? Probably not, even though i cannot peek in ISO materials myself.

---

Anyways, thanks for spending precious time and answering on my questions (again, i am not very proficient in this stuff, so needed more explanation than i should've asked for). Now i, at least, have slightly better understanding of what i am dealing with. I guess i will ask a question (for beginning) to LAV_filters developers/maintaners for behaviour difference between DXVA2 and D3D11 handling if it should be handled either way based on code.

---

What i also noted, is that when i skip frames on this video, it is actually different timing sometimes difference is multiple seconds! So effects are different based on from where i skip, to what place, and in which direction (forwards/backwards)

[clsid2]

Both VLC and LAV Filters use FFmpeg for decoding.

FFmpeg labels recovery frame as a keyframe: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/h264dec.c;h=9f5893c5122dba7597a47330c8073a77d63459dc;hb=HEAD#l892

MPC-HC seeks to keyframes by default. Unless you disable Fast Seek in its options, and unless there is huge gaps between keyframes. VLC can seek to any frame, and is more prone to showing decoding corruption.

[DimkaTsv]

MPC-HC seeks to keyframes by default. Unless you disable Fast Seek in its options, and unless there is huge gaps between keyframes.

Oh, it does stick to keyframe, and gaps aren't that big (around 10 seconds, but average throughout movie is about 5.77 seconds per key-frame [8668 seconds/1501 "key-frames"]), otherwise it would've not stick to same time values in sample no matter where i seek from(i wrote them in description). VLC also does seek to same timestamps if fast search is enabled in settings.

But for some reason specifically on D3D11 decoder MPC-HC seek results in very frequently corrupted image, while on DXVA2 it does not that at all. At least i hadn't seen corruption in sample (and full video) even once in MPC-HC DXVA2 mode.

Can there be some issue with buffer being reset before starting decode on that frame? Or can there be some driver level problem i should at least attempt to report to AMD?

---

Again, to compress nuances. On MPC-HC. D3D11 corrupts all the time, DXVA2, absolutely no issues whatsoever (and I tried by skipping through full film, no deviations). Image freezes are most common type of corruption. And corruption frequently can trigger about second or two after i did skip [mostly frame freezes. color corruption mostly happen immediately]. I checked on MPC-VR, MadVR and customEVR. All behave exactly same [well except part that for some reason MPC-VR reports DXVA2 as D3D11 VP, instead of DXVA or D3D9, but i may just be looking in wrong place. EVR shows that it is for sure DXVA2].

On VLC. Both D3D11 and DXVA2 showed corruption. Behaviour same as with MPC-HC on D3D11.

In Windows players (Windows also uses HW acceleration) i can also trigger corruption, but significantly less frequently, and most of the time it will be color corruption, rather then frame freeze. Often enough instead of showing corruption frame will be skipped. (But sometimes that behaviour breaks and image corrupts)

AMF PlaybackHW only corrupts image like bad TV stream sometimes do. But never freezes frame. Seek is not very responsive, but if video works, it KINDA works too (aka it works, but not great). It plays same way on DX9, DX11 and OGL, but won't play at all on DX12 and Vulkan after first few frames. Seeking on presenters it won't play also is impossible. I guess it is because PlaybackHW is extremely simple tool and doesn't support SEI recovery frames in full?

Ah yes... And this issue doesn't seem to be affecting Nvidia GPU's.

I have slight suspicion that it might have something with bufferisation. Like it player keeps in memory some frames that it should've not, and mixes them with what he gets after seeking. But my knowledge is extremely limited.

[clsid2]

What MPC-VR reports is what video processor it uses. That is unrelated to the hardware decoder. The DXVA2/D3D11 APIs are used for more than just decoding.

FFmpeg uses recovery frames as keyframe (starting point of decoding). If that is allowed by H264 spec, then it is probably an AMD bug. If not correct according to spec, then could be FFmpeg bug. But maybe intentional if it works with NVIDIA and Intel. But likely AMD bug given that it fails in Microsoft apps as well, which doesn't use FFmpeg.

The corruption you see may be due to wrong use of reference frames.

Ask on FFmpeg TRAC and contact AMD.

And when reporting to AMD, focus on Windows 11 Media Player (the modern one). Too many unneeded details about other players may result in the report being take less serious.

MikhailAMD says it is a broken file. So probably waste of effort. You may be blinded by error recovery giving decent results in some situations.

[DimkaTsv]

FFmpeg uses recovery frames as keyframe (starting point of decoding). If that is allowed by H264 spec, then it is probably an AMD bug. But likely AMD bug given that it fails in Microsoft apps as well, which doesn't use FFmpeg.

I checked ISO standard, for H.264 it is allowed. Probably for camera stream use case. Thanks for insight.

The corruption you see may be due to wrong use of reference frames.

There is "exact_match=1" flag on these recovery SEI's, which in theory mean that next non-IDR I frame should be decoded from 0 with same result as it would've been decoded from previous key-frame. At least based on AVC ISO spec.

Ask on FFmpeg TRAC and contact AMD.

Oh, thank you, will ask there as well. And i will contact AMD (even though my possibilities are quite limited to this repo and Adrenalin Bug report tool.

And when reporting to AMD, focus on Windows 11 Media Player (the modern one). Too many unneeded details about other players may result in the report being take less serious.

Thanks for advice. Will take it into account. Which one is default one though... Windows Photos, or Windows "Movie and TV"? [Just checked. Looks like Movies & TV should be default one]

MikhailAMD says it is a broken file. So probably waste of effort. You may be blinded by error recovery giving decent results in some situations.

Well... Mikhail meant that from AMF side of things, as AMF does not work with SEI marks by itself. So from AMF standpoint this file is not correct, because by default HW decoders only able to work with IDR I-frames. [You definitely should not get result similar to sample if AMF was used to encode, heh] ffmpeg crops file into aligned to SEI non-IDR I-frames chunks. [I used FFmpeg to crop out fragment]. So with that in mind i don't even think it is ffmpeg issue. I can seek properly through this video in MPC-HC with DXVA2 mode, instead of D3D11. So it does work in some cases even at this point with AMD HW accel.
And it does seek completely fine for other people with different systems. If file would've been incorrect, issue would've been global. And it does transcode without issues and into file without issues (even seek problem as there are different keyframes)

So... For such "broken" file it can be worked with without problem in quite many different cases. Meaning somewhere something is wrong, but file itself is fine even if not as it should be. Again, i will agree that creator of this video should've not used such parameters, unless he had no choice...

[clsid2]

On Windows 11 there is a new modern app called "Media Player" that is successor of "Movies & TV". But both should work similar. Not to be confused with the still included legacy Windows Media Player v12 from Windows 7 era.

[DimkaTsv]

On Windows 11 there is a new modern app called "Media Player" that is successor of "Movies & TV"

Oh, really? I recently reinstalled Windows and have no such app, interesting. Will install it then. Checked, behaviour same as in other Microsoft players. Corruption is less frequent [compared to VLC and MPC-HC], but can be observed decently reliably.

---

Wait, did i just crashed driver by unpausing on corrupted frame? Well, i knew that corrupted frames could cause driver crashes (i reported this one recently as well), and i even have fragments that can do it consistently, but didn't expect this problem to happen here as well. Probably because here corruption source is different and result is inconsistent.

---

Sent report to AMD through Bug Report tool with step by step reproduction in Windows Media Player also with screenshots and multiple video samples.

[DimkaTsv]

Just did small additional research... If i transcode samples mentioned here with VCEEnc, result is correct and proper, absolutely 0 issues appearing. But if i use TranscodeHW instead, it will corrupt first few frames. Both are using HW decode and encode.

Source: https://drive.google.com/file/d/1_WKRC17Vb24d15TbpwnfmLfy2vfolDJA/view?usp=drive_link VCEEnc result: https://drive.google.com/file/d/1h-i19Yrp_wjhDxUsDZJSU-xKCKy_PMFd/view?usp=sharing TranscodeHW result: https://drive.google.com/file/d/1N4-Y7YnKNlqD24YfsB8ohhmkasJPyeoC/view?usp=sharing

Also, based on feel one of the slightly longer samples (3 minute ones), MPC-HC seek functionality seems to become sluggish when seeking through TranscodeHW result in comparison to VCEEnc transcoded sample. And based on fact MPC-HC playback sometimes will completely freeze if you hit timebar in about middle of the fragment. Not even playback timer will continue to run In Windows players this freeze is just micro-freeze for half-second. Again, it only happens for TranscodeHW sample.

No corruption on seek is detected after transcode in both cases though, just that questionable behaviour from TranscodeHW result.

======== Sorry, my mediocre testing strikes again. I did seek test, but not playback one. This time correcting mistake by doing sped up playback. MPC-HC was completely unable to play through result that comes from TranscodeHW via MPC-HC. At 00:52 it just freezes. There are some small fragments at middle that it can kinda see on skip, but not play properly, and it will continue properly playing video after 02:06 without additional issues. Windows native players, on other hand, kinda stutter on skipping in the middle, and on corrupted beginning frames , but other than that, they able to chew through this same transcoded result without issues.

VCEEnc results are played without any issues at all basically. Weird.

Sadly i don't have capabilities to properly analyze differences in results to understand why this is happening, I can check something simple with tools available for free and my limited knowledge, but not this.