In the past used v.2.5 on Dell with Windows 10. Input video 4.8 Gb, output video with MP4 normal conversion: 802 Mb.
Now want to use v.2.6.2 Beta with new Dell with Windows 11. Input video 4.8 Gb, output video with MP4 Normal conversion anywhere from 10 - 15 Gb.
What is going wrong? To do with comskip? Does it need a setup of an comskip.ini? Any process that is working differently with Windows 11?
Need Help. Thanks.
My post/email to MCEBuddy/Goose contains the log file and the video, which with Windows 10, I have been able to convert to about 82 Mg with MP4 Normal, while with Windows 11 they are coming out to about 10 -15 Gb, which is totally in the wrong direction. MCEBuddy/Goose please respond. What’s wrong?
I had a look at your log file (unfortunately your onedrive link isn’t allowing me to download the original TS file). It appears that your original bitrate is 11Mbps where as your final bitrate is 50Mbps which explains why the file size is increasing.
I also noticed that your original file is a TS file with h.264 content and your final file is a MP4 file with h.264 content also. So essentially you’re changing the container formats (and removing commercials).
I would recommend try using the MP4 Unprocessed profile instead of the MP4 Normal profile. This should solve your issue of bitrate increasing and also actually provide a better quality output video as it’ll retain the original quality video, cut out the commercials and give you a MP4 container.
If you can upload the original video file to our server using the instructions in the link then I can try to replicate the issue and see why the bitrate is increasing.
Okay I was able to finally download your video and replicate the setup here. I’m not seeing any issue with the output filesize here (it’s 815MB after conversion).
Digging deeper into your logs I think I see the source of your issue. It’s your graphics driver.
The source video you have has many corrupted timestamps on it and the logs are 90% full of these errors:
2023-11-10T08:05:27 MCEBuddy.AppWrapper.Handbrake → [h264_qsv @ 0000000004b60380] A decode call did not consume any data
2023-11-10T08:05:27 MCEBuddy.AppWrapper.Handbrake → [NULL @ 00000000083b1080] missing picture in access unit
Then I noticed that in your logs the graphics driver was not able to handle these video issues and it ended up duplicating a lot of the video content while trying to correct for the errors that ended up increasing the video bitrate to 49Mbps
Thanks for your analysis and comments of 11/13. I performed the following in response:
I started from scratch and created several captures of 1 hour videos on my new Dell computer with Windows 11 with my Hauppage HD PVR II capture device: With HW acceleration, without HW acceleration, updating drivers, Ts file as well as MP4 file format, MP4 Normal vs. MP4 Unprocessed.
Then I ran all of the files thru MCEBuddy 2.6 and NONE of the files came out the way they were supposed to, i.e., with 4.85 Gb before and about 800 Mb after processing. Some files were as low as 50 Mb, with only audio showing, others in the 10 – 20 Gb range, way too high.
I then dug out my old Dell computer with Windows 10 and ran the same captured files through MCEBuddy 2.5 and, essentially, all came out OK, where they should have been. I have been doing this for some 10 years.
Apparently, MCEBuddy 2.6 is not working correctly yet with Windows 11 on a standard computer (Dell XPS 9230). What can be done?
Additional Question: The Hauppage capture device can create both TS and MP4 files (of about the same size – about 4.85 Gb per 1 hour video). When I run MCEBuddy with MP4 Normal, it creates a file of about 800 Mb when it is processing correctly. Is this an additional compression function in MCEBuddy? The MP4 file coming out of the capture device is much larger at 4.85 Gb.
I am still hoping to get the program running properly.
Yes there was an issue with one of the encoders and hardware encoding where it would cause too many frames inserted which would make the video size excessively large on some Nvidia graphics cards. The latest update fixed that.