Jeg brugte den ældre gratis version og bemærkede, at alle 1080i TS-optagelser fra Plex var meget hakkelige/jittery, når de blev konverteret til mp4 eller MKV (stammen hvert par frame). Jeg prøvede at reducere outputtet til 720p, men jeg får de samme resultater. Jeg har nu købt den nyeste MCEBuddy-version og har stadig dette problem. Er der en indstilling eller profil, jeg skal bruge for at forhindre dette i at ske? Alle 720p-kilder konverteres fra .ts til mp4 uden problemer.
Tak
Prøv at lege med indstillingen Detect and optimize video quality i konverteringsopgaveindstillingerne. Den er beregnet til at hjælpe med interlaced video.
Det var som standard, og jeg lod det være markeret… hvis jeg encoder 1080i-kilden .ts med Handbrake, ser jeg ikke rystelser/tøven i den resulterende fil.
Prøv at markere Skip remuxing-indstillingen på ekspertindstillinger-siden for konverteringsopgaven. Det burde give filen direkte til handbrake, hvis du bruger MP4-profilen.
Det vil jeg prøve. Tak for svarene.
Virker lidt glattere, men der er stadig framesej, når kameraet panorerer… nogen andre idéer?
Tjek din profil og se, om den bruger handbrake, og hvilke parametre der anvendes. Prøv at eksperimentere med indstillingen Detect and optimize video quality og indstillingen Skip cropping.
Jeg oplever præcis det samme problem med konvertering af interlaced .ts-filer – fandt du nogensinde en løsning på det?
Det gjorde jeg ikke, men det jeg opdagede var, at de kildefiler, som Plex gemmer fra HDHomerun, ikke er korrekte. Hvis jeg ser de frisk optagede filer (som ikke bliver transkodet) for 1080i-programmer (CBS eller NBC), er de rystede, som om de-interlaceren ikke fungerer korrekt. Jeg har bare lært at leve med det indtil videre.
Tak for dit hurtige svar. Det ser ud til, at enheder som eller lignende 4K Fire TV-sticks (selv min Nvidia Shield Cube) ikke håndterer interlaceret video særlig godt – i nogle tilfælde slet ikke. Jeg vil prøve at ændre decomb-indstillingen i MCEBuddy HandBrake og se, om det hjælper. Hvis det gør, giver jeg dig besked.
Hej, tak for dit forslag. Jeg er sikker på, jeg har skiftet dette før, og det har ikke gjort nogen mærkbar forskel. Jeg vil måske opsætte en ordentlig test og se, om det gør en forskel.
Ok, jeg tror jeg måske har fundet en løsning. Du kan dog ikke konvertere de allerede konverterede filer igen. Så de problemfiler, jeg har i mit bibliotek, kunne jeg ikke bruge til testen – de originale optagelser blev slettet efter konverteringen. Jeg var nødt til at finde og optage en problemfil, hvilket har taget lidt tid. Jeg fandt ud af, at problemet er meget tydeligt på nogle panoreringer i scener.
Den profil, jeg har brugt, er HDHomeRun H.264. Den vælger først HandBrake til konverteringen. Jeg er sikker på, at hvis du bruger en anden profil, kan du gøre det samme. (Luk McBuddy først, før du foretager ændringer)
Jeg ændrede profiles.config med WordPad til decomb=bob og trykkede gem
(C:\Program Files\MCEBuddy2x\config)
Det er meget hårdt for CPU’en – min tidligere konvertering brugte 99 % GPU og næsten ingen CPU. BOB bruger 99 % GPU og 75 % CPU. Det næsten fordobler også filstørrelsen. Det er dog sammenligneligt med størrelsen på en nativ progressiv optagelse, konverteret gennem MCEBuddy med den samme profil uden bob.
Tiden vil vise… Hvis du har lyst til at lave ændringen, så lad mig høre, hvordan det går.
Jeg kan bekræfte, at indstilling af decomb til BOB har løst problemet for mig 
(har lige haft tid til at lege med et nyligt/nyt regelmæssigt problemprogram)
Håber det gør det samme for dig 
*hmm, efter nærmere eftertanke giver forskellige enheder og spillere forskellige resultater. (Det virkede for den kombination af spiller og enhed, der fik mig til at søge her i første omgang)
Hvor satte du det? Jeg har ikke en decomb-indstilling i MCEBuddy.
