In het verleden gebruikte ik v.2.5 op een Dell met Windows 10. Invoervideo 4,8 Gb, uitvoervideo met MP4-normale conversie: 802 Mb.
Nu wil ik v.2.6.2 Beta gebruiken op een nieuwe Dell met Windows 11. Invoervideo 4,8 Gb, uitvoervideo met MP4-normale conversie tussen de 10 en 15 Gb.
Wat gaat er fout? Heeft het met comskip te maken? Moet er een comskip.ini worden ingesteld? Is er een proces dat anders werkt met Windows 11?
Hulp nodig. Dank.
Hallo,
Mijn post/e-mail aan MCEBuddy/Goose bevat het logbestand en de video, die ik met Windows 10 met MP4-normaal kon converteren tot ongeveer 82 Mb, terwijl ze met Windows 11 uitkomen op ongeveer 10-15 Gb, wat volledig de verkeerde kant op is. MCEBuddy/Goose, reageer alstublieft. Wat is er mis?
Dank.
Ik heb naar je logbestand gekeken (helaas staat je onedrive-link me niet toe het originele TS-bestand te downloaden). Het lijkt erop dat je oorspronkelijke bitrate 11 Mbps is, terwijl je uiteindelijke bitrate 50 Mbps is, wat verklaart waarom de bestandsgrootte toeneemt.
Ik zag ook dat je originele bestand een TS-bestand is met h.264-content en je uiteindelijke bestand een MP4-bestand is, eveneens met h.264-content. Dus verander je in wezen de containerformats (en verwijder je commercials).
Ik zou aanraden om het MP4 Unprocessed-profiel te gebruiken in plaats van het MP4 Normal-profiel. Dit zou je probleem van een toenemende bitrate moeten oplossen en bovendien een betere kwaliteit video opleveren, aangezien het de originele videokwaliteit behoudt, de commercials eruit knipt en je een MP4-container geeft.
Als je het originele videobestand naar onze server kunt uploaden met behulp van de instructies in de link, dan kan ik proberen het probleem te repliceren en kijken waarom de bitrate toeneemt.
Oké, ik heb je video eindelijk kunnen downloaden en de setup hier gerepliceerd. Ik zie geen probleem met de uitvoerbestandsgrootte (het is 815 MB na conversie).
Als ik dieper in je logs duik, denk ik de oorzaak van je probleem te zien: het is je grafische driver.
De bronevideo bevat veel corrupte timestamps en de logs zitten voor 90% vol met deze fouten:
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
Toen zag ik dat in je logs de grafische driver deze video-problemen niet aan kon en uiteindelijk veel videocontent ging dupliceren terwijl hij de fouten probeerde te corrigeren, waardoor de videobitrate verhoogde tot 49 Mbps
Daarom krijg jij een veel groter bestand. Je grafische driver is het probleem (nou ja, eigenlijk is de bronevideo de hoofdoorzaak, maar de slechte driver zorgt voor die grote bestanden).
Je hebt 3 opties:
Update/downgrade je grafische drivers als je hardware-acceleratie wilt blijven gebruiken om de video te converteren naar eentje zonder problemen.
Schakel hardware-acceleratie / gpu-encoding uit in de conversie-taakinstellingen
Zie de bovenstaande aanbeveling om het MP4 Unprocessed-profiel te gebruiken, want je hoeft je video’s eigenlijk niet te encoderen, alleen maar te knippen en de container van TS naar MP4 te veranderen.
Bedankt voor je analyse en opmerkingen van 13/11. Ik heb het volgende gedaan als reactie:
Ik ben helemaal opnieuw begonnen en heb meerdere opnames gemaakt van 1-uur durende video’s op mijn nieuwe Dell-computer met Windows 11 met mijn Hauppage HD PVR II-opnameapparaat: met hardwareversnelling, zonder hardwareversnelling, drivers bijgewerkt, TS-bestand en MP4-bestandsformaat, MP4 Normaal vs. MP4 Onbewerkt.
Vervolgens heb ik alle bestanden door MCEBuddy 2.6 gehaald en GEEN van de bestanden kwam eruit zoals het hoorde, d.w.z. met 4,85 Gb voor en ongeveer 800 Mb na verwerking. Sommige bestanden waren maar 50 Mb, met alleen audio, andere in de range van 10–20 Gb, veel te groot.
Ik heb toen mijn oude Dell-computer met Windows 10 tevoorschijn gehaald en dezelfde opgenomen bestanden door MCEBuddy 2.5 gehaald en in principe kwamen ze allemaal goed terecht, zoals het hoort. Ik doe dit al ongeveer 10 jaar.
Blijkbaar werkt MCEBuddy 2.6 nog niet correct met Windows 11 op een standaardcomputer (Dell XPS 9230). Wat kan er gedaan worden?
Aanvullende vraag: Het Hauppage-opnameapparaat kan zowel TS- als MP4-bestanden maken (van ongeveer dezelfde grootte – ongeveer 4,85 Gb per 1-uur durende video). Wanneer ik MCEBuddy gebruik met MP4 Normaal, maakt het een bestand van ongeveer 800 Mb als het correct verwerkt. Is dit een extra compressiefunctie in MCEBuddy? Het MP4-bestand dat uit het opnameapparaat komt is veel groter, 4,85 Gb.
Ik hoop nog steeds het programma goed aan de praat te krijgen.
HET LIJKT ER EINDELIJK OP DAT HET WERKT (conversie MP4 Normaal met Hardwareversnelling met Windows 11 op een nieuwe pc).
Ik bleef tientallen keren proberen met v.2.5, v.2.6.1 en opnieuw met v.26.2, nieuwe downloads en opnieuw uitvoeren, en vanochtend werkt v.2.62 met Windows 11 en een nieuwe pc.
HEB JE IETS NIEUWS GEDEBUGD, GEWIJZIGD, ETC. AAN DE SOFTWARE?
Ja, er was een probleem met een van de encoders en hardware-encoding waardoor er te veel frames werden ingevoegd, wat de videogrootte op sommige Nvidia-videokaarten excessief groot maakte. De laatste update heeft dat opgelost.