You guys mentioned in the past that you don’t have any AMD hardware to test with, so I’m testing on my own. I renamed/replaced the ffmpeg/ffprobe with versions from Zeranoe’s nightly, and created a copy of the MKV Normal profile that uses h264_vce as the video codec instead of x264.
My source is 30 minute TV shows from HDHomeRun Prime, which convert just fine in software. I made no other changes to the copy of MKV Normal profile other than specifying a different encoder to ffmpeg. Every other setting remains the same.
The first and most obvious result is the video file won’t play:
The file is correctly identified (VCE codec, time length, etc) in MediaInfo, but is corrupted/broken in the players that I use. VLC refuses to play the video, with the warning “Cannot get block EOF?” Plex will often quit the file immediately, then play it later but cannot resume. It seems to be something related to a timestamp telling the player the length of the file, though MediaInfo seems to figure it out fine.
The second big change is that the log file is massive:
The log is 22MB compared to the usual sub-2MB files made in software encodes. I’ve uploaded a copy of the log here for inspection. It seems to be mostly a lot of crop operations that don’t happen in software.
Anyway, I’ll do what I can to help, but I’m stumped. Would like to get this compatible with VLC/Plex and maybe cut down on the giant logs?
I would suggest try playing it back on a different computer with just a basic player like Window Media Player to rule out any issues with your playback codecs.
If that doesn’t work it’s an ffmpeg issue, you may want to report it there for the devs to analyze it.
Also I would try using a simpler options in the profile and mcebuddy and then see where it breaks before reporting it to ffmpeg.
This is basically turning off all advanced options including cropping and tells MCEBuddy not to adjust any video settings as they are optimized for hardware encoding.
If this works, then you can add the options back one by one to see which ones breaks (like enable cropping, then remove the hardware encoding option, then add back the x264opts etc)
The code you gave me worked, produced a file very quickly that could be played even in VLC without problems, and produced a brief (700K) log.
So I changed the container type to VLC. Got a file that could play in Windows Media Player, but not in VLC. I’ll do some more poking and testing in the days to come, but it seems initially that this method works but is most compatible with MP4 files and not with MKV.
Both profiles made videos that play, but the second one produced a lot of warning messages in VLC about audio timings and lost ms of data. The second video didn’t seem to be out of sync at all to the viewer (although I skipped around the timeline and didn’t watch all the way through), but the first video played through with much less drama in the player’s logs and definitely seems preferable.
I’ve taken the first profile, upped the bitrate to 1400, and enabled AutoDeinterlace (I’m recording TV for streaming on devices without a hardware decomber) for use as a daily driver for the immediate future. However, if you want any other tests done, let me know. I’m using 15 minute episodes of Cartoon Network for testing mostly, and so while I wouldn’t use HEVC etc regularly I wouldn’t mind running some tests for you guys. It’d be nice to have AMD added to the Hardware Encoding checkbox in a future beta rather than having to create a custom profile for it.
When I started this thread, I was using a duplicate of “MKV Normal” with the codec changed. That was what was creating the corrupted files with EOF errors.
I think I’ve also had files corrupted by having them converted with AMD hardware encoding in a separate program (A’s, StaxRip, etc) and then having MCEBuddy run them unprocessed to comskip/rename. It produced similar EOF errors. I briefly had a workaround where MCEBuddy ran twice on each file, once to take an uncompressed .ts and run comskip on it, then drop it in a folder monitored by A’s to convert, then move/rename the converted file; but I’ve wanted it simplified to one program and abandoned that complex approach. Since ffmpeg finalized 4.0, I’ve been trying to get it working with MCEBuddy.
Apparently my problem here was a profile issue? But I’m not an ffmpeg CLI power user and didn’t know how to make a working profile. Swapping the provided copy of ffmpeg with 4.0 was easy enough, but I don’t know what a lot of the x264 options on the ffmpeg-video line actually are, but even getting rid of the x264 options argument on the line didn’t make stable files. Your profile actually does.
If you have an AMD card, try today’s 2.5.1 BETA build, it now support automatic detection of NVidia (CUDA/NvEnc), Intel (QuickSync) and AMD (AMF/VCE) hardware and enables the hardware acceleration automatically.