When using --avhw while transcoding some source, random fragments can be lost. #101
Comments
|
Interesting detail: There were 6 videos from same source (and they are basically 6 chapters, as you might guess based on log before). But what is especially interesting, is that remaining 2 videos will actually straight up crash driver [24.1.1] closer to the end of the transcoding due to this error: Here is actual log. [it was quite large, so i compressed it into archive] After searching and some ffmpeg cutting i was left with 2 fragments 4-6 seconds each. More information here. |
|
Thank you for the input file and the detailed logs, I was able to reproduce the issue. Although not sure right now about the cause, it should be related to hw decoder. I'll check further later. |
|
Well, yesterday i had original videos linked. Today i changed links for cropped samples that are specific to issue. They were directly cut from original without any additional tricks. |
|
Installed 23.40.19.01 driver (aka 24.2.1 pre-release). Now encoding begins after decently long waiting period, and with atrocious average FPS. Of course as result it will not encode most of the fragment. Actually, now that i checked that source cannot be played properly with AMD HW Playback tool [i... just recently figured out how to compile it myself, as AMF repo contains only source code. And i found one more tool], i probably should ask AMF what is wrong with file? ... Looks like corruption happens here There is part in source fragment where new SPS and PPS are being passed, then for some time every frame is in single slice instead of multiple. |
|
Seems like somehow the video files has progressive frames and interlaced fields mixed up, and the new SPS and PPS might be it's transition. I'm yet not being able to figure out how it can be made decoded properly now. |
Well... I saw that other videos from same source could've had beginning as interlaced, then instant transition into progressive. And it played fine. Oh, i now see what you mean. It is literally just few spikes... Never actually noticed them, weird. Moreover in original video FPS spikes incredibly during this fragment, like 11-140+FPS variation for several frames. I wonder why AMF HW Playback (and hw decoder here, i assume?) cannot approach this one, but ffmpeg can (at least LAV_filters, which is based on libavcodec and libavformat which are parts of ffmpeg).
|
If issue requires to be passed to developers of particular component, tell me, please.
Issue description:
I have series of videos (films to be more specific) which i wanted to transcode to reduce size before remuxing package further (additing or forcing subtitles, and tweaking audio tracks).
Videos are encoded in AVC in .mkv container, nothing special or unique.
By default VCEEnc reasonably in my eyes uses --avhw. But something weird is happening with these particular videos.
When i do transcoding (i tried AVC, HEVC and preanalysis on and off), in at least 2 videos whole fragments are skipped. By "skipped" i mean literally black screen and no sound. Sound can stop later than black screen starts and start earlier than it ends. Fast forwarding to "skipped" fragment is also impossible it will default to some time at middle of skipped fragment. VCEEnc literally doesn't code these frames at all.
Such thing does not happen if i force --avsw instead.
Sources and transcoded samples:
Sadly these files ARE big enough (16GB for source and 8GB for transcoded ones), so i cut a fragment.
Source [it is there but for... potentially legal reasons i won't share it publicly]: -----
Source fragment that is being corrupted [Main difference is that in corrupted frament there is sound which lasts for full 23 minutes of encoded fragment, while actual video is only 2 seconds. In source transcoding, sound also goes blank]:
https://drive.google.com/file/d/17SqY4eXRZ8-QrJQR50ABo8z2lwdxfY02/view?usp=sharing
Corrupted video - fragment (--avhw) [In transcoded file from source broken fragment starts at 1:04:34, no sound and video. Sound appears at 1:27:43, while video appears at 1:30:22]:
https://drive.google.com/file/d/1vrd68dxFwPHXvvmCoXo2nxHgfJS-IBsc/view?usp=sharing
Logs and MediaInfo:
MediaInfo - Source [i will only link relevant tracks]:
VCEEnc - corrupted fragment log
I won't give you debug log, as it was more than 1GB of text.
But default log also presented some info.
VCEEnc log - avhw = corrupted result
VCEEnc log - avsw = correctly transcoded file:
==============
As you can notice, in corrupted video with avhw VCEEnc was only able to encode 167657 frames (166958 Q-frames and 699 I-frames), while for correctly encoded video with avsw it was able to encode 204759 frames (203905 Q-frames and 854 I-frames respectively). Also corrupted video stream takes 6157.75 MB, while correct one takes 7534.55 MB
The text was updated successfully, but these errors were encountered: