Ik heb een conversietaak waarbij ik OTA-opnames converteer naar een maximale breedte van 720p. In wezen creëer ik een geoptimaliseerde versie voor Plex.
De conversies vinden plaats, maar niet altijd in 720p. Meestal is de uiteindelijke versie nog steeds 1080p.
Ik heb een log geüpload van een conversie die correct werkte en een versie die niet correct werkte. Er wordt in de logs vermeld (zelfs in die van degenen die niet werken) dat de maximale breedte 720 zou moeten zijn, maar het komt uiteindelijk niet zo uit.
Oh ja, het lijkt erop dat ik het verprutst heb – MAAR ik wil dat MCEBuddy een 1280×720-versie maakt. Dus ik heb 720 ingevoerd terwijl ik eigenlijk 1280 als breedte had moeten opgeven.
Zelfs dan: als ik 720 invul, zou het een nog kleinere afmeting moeten opleveren dan ik wil, toch?
Ik ga terug en corrigeer mijn maximale breedte naar 1280 om te zien wat er gebeurt.
Ik kan bevestigen dat de breedtewaarde echt breedte is.
Ik had het verkeerd ingesteld op 720 en zoals vermeld werkt het soms wel en soms niet. Ik ontdekte dat het een show correct converteerde en een video produceerde van 720x406.
Zoals Mike vermeldde, heb ik het verknald, maar het lijkt er nog steeds op dat het systeem soms de maximale breedtewaarde negeert of deze niet correct kan verwerken.
Ik herinnerde me waar ik probeerde te doen wat jij nu probeert, namelijk geforceerd upscalen/downscalen naar een specifieke schermbreedte.
Het zit niet in MCEBuddy. De maximale breedte is bedoeld voor downscalen van een raw mpeg2 OTA 1920x1080i HD-video naar een kleinere afbeelding om betere compressie te krijgen. Ik denk dat opslag nu goedkoper is en dat daarom niet meer echt een issue is. Ook krijg ik geweldige compressie met x265 in plaats van MP4/x264.
Terug naar geforceerde schermgrootte. Het zat in de opties voor Handbrake. Dus wat je zou kunnen doen is extra parameters in je config instellen en Handbrake dwingen de conversies uit te voeren, of het equivalent uitzoeken met FFMPEG (de andere encoder die MCEBuddy gebruikt).
Ik weet dat er hier wat posts zijn van mensen die proberen FFMPEG of Handbrake te forceren en ook anderen die speciale opties naar de encoders willen doorgeven. Dat is wat ik denk dat je hier nodig hebt.
Ik serveer mijn content ook met Plex, maar ik heb alle transcoding uitgeschakeld en stuur de video naar de speler en laat de speler eventuele transcoding doen. Tot nu toe geen problemen met het afspelen van 1280x720p of 1920x1080i (OTA) getranscodeerd naar maximale breedte 1280 (het zal 1920x1080 downscalen, maar dat is altijd geïnterlaced voor mijn TV-zenders). Ik heb nog geen ATSC3.0-tuner om te zien wat er in 4K is of een 4K (UHD)-tv, dus daar nog geen problemen mee.
En met x265 en nVidia 2060 HW-encoding op een oude i5 Haswell (4e generatie), is transcoding geen issue geweest en een show van 1 uur is ongeveer 350MB aan grootte, wat “goed genoeg” is voor OTA HD-content.
MCEBuddy verplaatst het origineel naar de archiefmap en ik plan een taak om alles ouder dan 10 dagen te verwijderen. Op die manier kan ik MCEBuddy handmatig uitvoeren om advertenties te verwijderen met een ander profiel voor alles wat ik in die 10 dagen in volledige resolutie/lage compressie wil houden (maar wel in x265 natuurlijk).
Afspelen werkt prima op mobiel en VLC op PC en zelfs op mijn Tivo Roamio OTA via de Tivo Plex-app.
Bedankt voor de logs. In degene die faalt zie ik dat de video corrupt is, waardoor Handbrake mislukt en vervolgens terugvalt op ffmpeg, dat probeert de qsv-graphics driver te gebruiken om de video te herschalen, maar dat lukt niet. Kun je ook de originele video uploaden die faalt (Late show) zodat we die kunnen analyseren en kunnen zien hoe we het kunnen oplossen.
We hebben een update uitgebracht naar BETA 2.5.7 die het probleem zou moeten oplossen. Probeer de 2.5.7 bèta-build van vandaag en als dat niet werkt, hebben we een kopie nodig van de video die de fout veroorzaakt om deze verder te analyseren.
