Converting with v.2.5 & Windows10 vs. with v.2.6 & "Windows 11 Issues?

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.

Hello,
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?
Thanks.

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

2023-11-10T08:05:59 MCEBuddy.AppWrapper.Handbrake → [08:05:59] mux: track 0, 159273 frames, 16304021784 bytes, 49059.44 kbps, fifo 1024
2023-11-10T08:05:59 MCEBuddy.AppWrapper.Handbrake → [08:05:59] mux: video bitrate error, +15477179768 bytes

Where as on my test machine, my driver was compensating by dropping the corrupted video frames and thereby reduced the bitrate:

2023-11-13T16:50:28 MCEBuddy.AppWrapper.Handbrake → [16:50:28] mux: track 0, 159273 frames, 814012086 bytes, 2449.39 kbps, fifo 2048
2023-11-13T16:50:28 MCEBuddy.AppWrapper.Handbrake → [16:50:28] mux: video bitrate error, -12829930 bytes

That’s why you’re getting a much larger file. It’s your graphics driver that the problem (well actually the source video is the root cause but the bad graphics driver is the reason for the big files).

You have 3 options here:

  1. Update/downgrade your graphics drivers if you want to use hardware acceleration to convert the video to one that’s not a problem.
  2. Turn off hardware acceleration / gpu encoding in the conversion task settings
  3. See the recommendation above to use the MP4 Unprocessed profile since you really don’t need to convert your videos encoding, just cut them and the change the container from TS to MP4.

Hello Goose,

Thanks for your analysis and comments of 11/13. I performed the following in response:

  1. 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.

  2. 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.

  3. 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.

  4. Apparently, MCEBuddy 2.6 is not working correctly yet with Windows 11 on a standard computer (Dell XPS 9230). What can be done?

  5. 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.

  6. I am still hoping to get the program running properly.

Klaus Franken

Can you attach your logs with hardware acceleration turned off.

Yes, this recompresses the file and is suitable when converting to mpeg4 from another codec (like raw, mpeg2, mpeg1 etc).

Hello Goose,

IT FINALLY LOOKS LIKE IT IS WORKING (conversion MP4 Normal with Hardware Acceleration with Windows 11 on a new PC).

I kept trying dozens of times with v.2.5, v.2.6.1, and v.26.2 again, new downloads, and redoing, and this morning v.2.62 with Windows 11 and a new PC is working.

DID YOU PERFORM ANY NEW DEBUGGING, CHANGING, ETC. WITH THE SOFTWARE?

GOOD JOB, ASSUMING IT STAYS THAT WAY.

Klaus Franken

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.