Konvertering med v.2.5 & Windows10 vs. med v.2.6 & "Windows 11 Problemer?

Generel support / Spørgsmål
1

Tidligere brugte jeg v.2.5 på Dell med Windows 10. Input-video 4,8 GB, output-video med MP4 normal konvertering: 802 MB.
Nu vil jeg bruge v.2.6.2 Beta på ny Dell med Windows 11. Input-video 4,8 GB, output-video med MP4 Normal konvertering ligger mellem 10-15 GB.
Hvad går galt? Har det noget med comskip at gøre? Skal der opsættes en comskip.ini? Er der en proces, der fungerer anderledes med Windows 11?
Har brug for hjælp. Tak.

Hej,
Min post/email til MCEBuddy/Goose indeholder logfilen og videoen, som jeg med Windows 10 har kunnet konvertere til cirka 82 MB med MP4 Normal, mens de med Windows 11 ender på cirka 10-15 GB, hvilket går helt forkert. MCEBuddy/Goose, venligst svar. Hvad er der galt?
Tak.

2

Jeg har kigget på din logfil (desværre tillader dit OneDrive-link mig ikke at downloade den oprindelige TS-fil). Det ser ud til, at din oprindelige bithastighed er 11 Mbps, mens din endelige bithastighed er 50 Mbps, hvilket forklarer, hvorfor filstørrelsen stiger.

Jeg bemærkede også, at din oprindelige fil er en TS-fil med h.264-indhold, og din endelige fil er en MP4-fil med h.264-indhold også. Så ændrer du i bund og grund containerformaterne (og fjerner reklamer).

Jeg vil anbefale at prøve at bruge MP4 Unprocessed-profilen i stedet for MP4 Normal-profilen. Dette bør løse dit problem med stigende bithastighed og faktisk også give en bedre kvalitet på output-videoen, da den vil bevare den oprindelige videokvalitet, klippe reklamerne ud og give dig en MP4-container.

Hvis du kan uploade den oprindelige videofil til vores server ved hjælp af instruktionerne i linket, kan jeg prøve at genskabe problemet og se, hvorfor bithastigheden stiger.

3

Okay, jeg fik endelig downloadet din video og genskabt opsætningen her. Jeg kan ikke se nogen problemer med output-filstørrelsen her (den er 815 MB efter konvertering).

Når jeg graver dybere i dine logs, tror jeg, jeg kan se kilden til dit problem. Det er din grafikdriver.
Kildenvideoen har mange beskadigede tidsstempler, og loggene er 90 % fyldt med disse fejl:

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

Derefter bemærkede jeg, at grafikdriveren i dine logs ikke kunne håndtere disse video-problemer, og det endte med at duplikere meget af videoundholdet, mens det forsøgte at korrigere for ferene, hvilket forøgede videobitraten til 49 Mbps

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

Hvorimod min test-computer kompenserede ved at droppe de beskadigede videoframes og dermed sænkede bitraten:

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

Det er derfor, du får en meget større fil. Det er din grafikdriver, der er problemet (faktisk er kildenvideoen den egentlige årsag, men den dårlige grafikdriver er grunden til de store filer).

Du har tre muligheder:

  1. Opdatér/nedgradér dine grafikdrivere, hvis du vil bruge hardware-acceleration til at konvertere videoen til en, der ikke er et problem.
  2. Slå hardware-acceleration / GPU-encoding fra i konverteringsopgaveindstillingerne
  3. Se anbefalingen ovenfor til at bruge MP4 Unprocessed-profilen, da du egentlig ikke behøver at konvertere din videoencoding, bare klippe den og skifte containeren fra TS til MP4.
4

Hej Goose,

Tak for din analyse og kommentarer fra 13/11. Jeg har foretaget følgende som reaktion herpå:

  1. Jeg startede forfra og optog flere 1-times videoer på min nye Dell-computer med Windows 11 med min Hauppage HD PVR II-optager: Med HW-acceleration, uden HW-acceleration, opdaterede drivere, TS-fil såvel som MP4-filformat, MP4 Normal vs. MP4 Ubehandlet.

  2. Derefter kørte jeg alle filerne igennem MCEBuddy 2.6, og INGEN af filerne kom ud, som de skulle, dvs. med 4,85 Gb før og cirka 800 Mb efter behandling. Nogle filer var helt nede på 50 Mb, kun med lyd, andre i området 10–20 Gb, alt for højt.

  3. Jeg fandt så min gamle Dell-computer med Windows 10 frem og kørte de samme optagede filer igennem MCEBuddy 2.5, og stort set alle kom ud, som de skulle. Jeg har gjort dette i cirka 10 år.

  4. Tilsyneladende fungerer MCEBuddy 2.6 endnu ikke korrekt med Windows 11 på en standardcomputer (Dell XPS 9230). Hvad kan der gøres?

  5. Ekstra spørgsmål: Hauppage-optageren kan skabe både TS- og MP4-filer (med cirka samme størrelse – cirka 4,85 Gb pr. 1 times video). Når jeg kører MCEBuddy med MP4 Normal, skaber det en fil på cirka 800 Mb, når det behandler korrekt. Er dette en ekstra komprimeringsfunktion i MCEBuddy? MP4-filen, der kommer ud af optageren, er meget større med 4,85 Gb.

  6. Jeg håber stadig at få programmet til at køre ordentligt.

Klaus Franken

5

Kan du vedhæfte dine logs med hardware-acceleration slået fra.

Ja, dette rekomprimerer filen og er velegnet når man konverterer til mpeg4 fra en anden codec (som raw, mpeg2, mpeg1 osv).

6

Hej Goose,

DET SER ENDELIG UD TIL AT VIRKE (konvertering MP4 Normal med Hardware Acceleration med Windows 11 på en ny PC).

Jeg fortsatte med at prøve dusinvis af gange med v.2.5, v.2.6.1 og v.26.2 igen, nye downloads og gentagelser, og i morges virkede v.2.62 med Windows 11 og en ny PC.

HAR DU UDFØRT NY DEBUGGING, ÆNDRINGER ELLER LIGNENDE I SOFTWAREN?

GODT ARBEJDE, FORUDSAT AT DET BLIVER VED MED AT VÆRE SÅDAN.

Klaus Franken

7

Ja, der var et problem med en af encoderne og hardware-kodning, hvor det førte til for mange indsatte frames, hvilket gjorde videostørrelsen overdrevent stor på visse Nvidia-grafikkort. Den seneste opdatering har løst dette.