Ik ben onlangs begonnen met het gebruik van MCEBuddy.
Ik probeer een deel van mijn videobibliotheek naar x265 te converteren om ruimte te besparen.
Sommige geconverteerde video’s hebben een lagere bitsnelheid dan het origineel en nemen ongeveer 25% minder ruimte in, terwijl andere video’s een hogere bitsnelheid hebben dan het origineel en ongeveer 25% meer ruimte innemen.
Weet iemand waarom sommige video’s met hetzelfde profiel lager zijn en andere hoger dan het origineel, en/of hoe ik dat kan voorkomen?
Zijn de oorspronkelijke resoluties hetzelfde? De x265-encoder werkt op een schaal van zeer verliesgevend tot placebo-verliesgevend en wordt niet echt ingesteld via een “bitrate”-instelling.
Ik doe hetzelfde met OTA-opnames en heb twee profielen, één voor HD-opnames en één voor SD-opnames. Voor de HD-opnames kan ik het profiel lossiger instellen (bijv. 25 tot 27) dan bij de SD-opnames (20-25).
Als ik achteraf transcoding doe, gebruik ik Handbrake met een vergelijkbare selectie van een aangepast profiel. Ik gebruik ook een recente nightly build van Handbrake.
Ik ga nog (op een dag) tijd besteden aan Custom Cuts of de MCEBuddy-commandline om bestanden opnieuw te verwerken zonder transcoding, alleen om de metadata van de shows te “vernieuwen”, aangezien MCEBuddy alles in de MKV-container verwerkt, en ik heb veel shows van enkele jaren geleden toen de metadata niet zo goed was als nu, met de explosie van streaming en iedereen die op zoek is naar content om te streamen.
Misschien moet ik meerdere profielen maken en op de een of andere manier filteren op resolutie.
Het probleem is dat de bestanden van lagere kwaliteit groter worden, terwijl die van hogere kwaliteit kleiner worden. Als ik de SD-bestanden dus minder verliesarm maak zoals genoemd, wordt het probleem alleen maar erger.
Ik zag dat Handbrake een bitrate-instelling heeft voor x265 (geen idee of het functioneel is of niet).
Als het een parameter is die FFMPEG of Handbrake kan gebruiken, kan @Goose die misschien blootstellen in de GUI (of handmatig doorgeven aan de transcoder-engine).
Het zou waarschijnlijk nuttig zijn om het verhogen van de bitrate voor bronmedia te voorkomen, maar ik weet niet of de bestaande gemiddelde bitrate bekend kan zijn, aangezien het een gemiddelde is en de codecs adaptief zijn.
Dat zou geweldig zijn als er een manier was om te voorkomen dat de bitrate hoger wordt dan de bron.
Als dat in de GUI beschikbaar zou zijn, zou dat voordelig zijn. Het is mogelijk dat je zelfs in de configuratie die parameter kunt toevoegen. Niet zeker.
Je kunt twee (of meer) profielen instellen op basis van de bitrate van je invoermedia en vervolgens handmatig dat profiel selecteren via de opdrachtregel (of alleen dat profiel verwerken als het bestand zich in een bepaalde map bevindt, en het bestand dan verslepen naar de “juiste” map zodat MCEBuddy het juiste profiel toepast).
Als bitrate een metadataveld was dat MCEBuddy kan zien zonder een pass over de gegevens te maken (d.w.z. een groot bestand) om de gemiddelde bitrate te berekenen, dan zou ik bitrate als een variabel veld kunnen toevoegen dat kan worden gebruikt voor filtering, profielselectie of bestandsnaamverwerkingslogica.
Ik wil echter niet dat @Goose steeds nieuwe dingen aan MCEBuddy toevoegt die beter afgehandeld kunnen worden via batch/script- en opdrachtregelverwerking voor deze uitzonderlijke gevallen. Want alles wat hij toevoegt, moet hij onderhouden en uitzoeken hoe hij het geïntegreerd houdt in de UI zonder dat de app volloopt met een miljoen opties of dat hij uiteindelijk een paar mensen moet documenteren en ondersteunen voor eenmalige opties die ergens in de configuraties verstopt zitten. Het is een balans.
Ik begrijp het, maar het lijkt me nuttig voor veel mensen om grotere bestandsgroottes te voorkomen. MCEBuddy kan al de bitrate van het bestand detecteren, dus ik zou denken dat er geen metadataveld of iets specifieks anders nodig is.
Laten we het zo stellen: ik heb ongeveer 4 verschillende profielen opgezet op basis van bitrates om het probleem enigszins op te lossen. Ik weet dat er een bitrate-selectiefilter in het expertinstellingenvenster zit.
Mijn probleem is: stel dat ik een bestand heb met een bitrate van 10.000 en ik heb een selectie voor alles boven de 2.000 en een selectie voor alles boven de 6.000. Hoe kan ik ervoor zorgen dat het alleen de conversietaak voor de >6.000 kbps-bitrate uitvoert in plaats van beide?
Het zou fijn zijn als je een bereikselectie kon doen.
Als ik kan uitzoeken hoe ik het zo kan instellen dat het maar één conversietaak/profiel uitvoert, kan ik het probleem omzeilen en een consistenter conversieproces krijgen zonder dat sommige bestanden groter worden dan het origineel. Het is niet ideaal, maar het zou goed genoeg kunnen werken.
Als ik iets in een configuratiebestand kan wijzigen zodat MCEBuddy dit zou doen, zou dat geweldig zijn, maar ik probeerde handmatig scriptingcommando’s en het plannen van een taak te vermijden, aangezien dat het hele doel/de behoefte aan MCEBuddy voor mij tenietdoet.
U kunt het bestand hernoemen en archiveren/verwijderen na conversie gebruiken om de bestanden te verwerken in aflopende bitrate-profielvolgorde, d.w.z. het 6K-transcodeprofiel en dan het 2K-transcodeprofiel. Als het 6K-transcodeprofiel slaagt, wordt het 10K-bestand verwerkt en bestaat het daarna niet meer, zodat het 2K-transcodeprofiel niet meer kan worden uitgevoerd.
Helaas werkte dat niet zoals bedoeld. Ik kan bevestigen dat het bestand naar de archiefmap is verplaatst, maar op de een of andere manier is het toch twee keer geconverteerd met behulp van 2 verschillende profielen. In de gebeurtenissen wordt echter aangegeven dat het oorspronkelijke bestand exact hetzelfde bestand was.
Heb je het aantal taken dat gelijktijdig wordt verwerkt beperkt tot slechts één?
Als je meerdere taken toestaat, zal het de eerste starten en daarna naar de volgende gaan, en je hebt nodig dat ze opeenvolgend zijn.
Er is geen echt voordeel als je HW-transcodering gebruikt, aangezien de twee (of meer) taken zullen concurreren voor de GPU, en hetzelfde geldt voor de CPU, aangezien de transcodering ook kan worden afgestemd op multi-core gebruik.
Het lijkt erop dat het programma wacht met het verplaatsen van het bestand totdat alle conversietaken voor dat bestand voltooid zijn. Het heeft het drie keer geconverteerd en naar de archiefmap verplaatst. Dat is het enige waar ik aan kan denken; anders zou het het bestand na de eerste keer niet opnieuw kunnen converteren.
Er is ook een “wacht tot laatst benaderd”-parameter. Heb je die op nul gezet of heb je de “bijwerken laatst benaderd”-vlag in je bestandssysteem uitgezet?
Mogelijk moet je de logs of je configuratie uploaden naar @Goose om te bekijken. Het is een FTP-site en de handleiding staat hier op de forums.