Categorieën
Exporteren verloopt zeer moeizaam
LighScan op 23 januari 2012 #
Hoi beste OMT'ers
Ik heb een relatief simpele vraag denk ik: is er voor mij een mogelijkheid om de wachttijd te verkorten die nodig is om films te exporteren naar een ander formaat?
Iets meer uitleg:
Ik gebruik het programma "Submerge" (waar ik sinds vandaag een licentie op heb) om een ondertiteling te "hardcoden" in de film. Met dit programma heb ik redelijk wat mogelijkheden, waaronder de grootte van de ondertiteling en dergelijke. Ook de interface is netjes en overzichtelijk, tot zover geen klachten dus!
Om de film vervolgens te exporteren naar een ander formaat, is een ander verhaal. "Normaal gezien" zou de wachttijd ongeveer hetzelfde moeten zijn als de speelduur van de film, maar dat is bij duidelijk niet het geval. Ik moet mijn Mac'je maar liefst 12 uur laten aanstaan (ik heb nu nog 8 uur te gaan).
Dat lijkt mij wel héél erg lang, vooral ook omdat mijn Macje best wel up-to-date is (het betreft een MacBook Pro 15-inch 2.0Ghz Early 2011).
Dat moet toch sneller kunnen, niet? 
Geavanceerde details:
Originele (bron)bestand:
.mp4 container (H.264), file size 1.47Gb, external .srt, 48.000Khz stereo audio AAC 5.1, 1280x544 resolution, 01h47m25s length, 2096kbits/sec
Dit probeer ik te verkrijgen:
.mp4 container (mpeg-4 basic), file size 1.47Gb (een schatting), ondertiteling hardcoded, 48.000Khz stereo audio AAC 5.1, 1280x720 HD resolutie, speelduur is hetzelfde, 2097 kbits/sec
LighScan op 23 januari 2012 #
Bedankt voor je reactie! Dat helpt me zeker al vooruit, omdat ik dat best is kan proberen dan!
Wat ik me wel afvraag is het volgende: de containers zijn beide hetzelfde (.mp4), maar bij de ene stond toch duidelijk H.264 (zoals jij al aanwijst), maar bij het doel heb ik voor mpeg-4 gekozen. Of komt dat uiteindelijk toch op hetzelfde neer?
Overigens neemt het proces meestal zo'n 99 tot 108% in beslag, maar loopt mijn Mac niet merkbaar trager. :
unSOUND op 23 januari 2012 #
H.264 en MPEG-4 zijn verwant aan elkaar, en kunnen in dezelfde container. Maar H.264 heeft meer opties qua codering om meer kwaliteit in dezelfde bitrate te proppen.
Het decoden van H.264 gebruikt dus meestal maar één core. Wat ik in zulke gevallen meestal doe, is meerdere films tegelijk exporteren. Heb ik maar één film, dan kan ik de film opknippen in meerdere stukken, en die tegelijk exporteren. Deb ik bijvoorbeeld 8 cores, knip ik 2 films op in 3 stukken, zodat 6 cores aan het rekenen zijn, en de overige 2 laat ik onbelast zodat ik met andere zaken door kan gaan.
LighScan op 23 januari 2012 #
Ik heb het ondertussen al een aantal keer geannuleerd (desnoods moet ik hem die uren maar laten doen deze nacht).
Helaas zijn andere formaten/codecs niet sneller hoor. 
Ik heb al .mov (dv-indeling), .dv, .mov (mpeg-4), .mov (H.264) geprobeerd (meer formaten/codecs heb ik niet echt ter beschikking).
unSOUND op 23 januari 2012 #
LighScan - op 23 januari 2012Helaas zijn andere formaten/codecs niet sneller hoor.
Je hebt me niet goed begrepen denk ik. Het komt bij jou dus doordat de BRON een H.264 bestand is, en het uitpakken daarvan kan maar met 1 core. Dus hoe je het doelbestand codeert maakt dan niet uit.
Maar heb je een MPEG2 of WMV bestand als BRON, zal het coderen wel over meerdere cores gaan als je exporteert naar MPEG4 of H.264.
Overigens moet je ook uitkijken, want je bent nu de verhouding van de film ook aan het veranderen ( hoogte van 544 naar 720 ), wat de film ook niet goede komt en extra rekenwerkt vereist. Ikzelf codeer H.264 eigenlijk nooit opnieuw, meestal is het ook niet nodig, tenzij je dus een ondertitel wilt inbranden. Bij Engelstalige films doe ik dat al nooit ( mijn Engels is vaak beter dan dat van de tieners die de vertaling maken ). En de codering die de film heeft is vaak al speelbaar op de iPad / iPhone, het gaat puur om de audio, en die is met een paar tellen omgezet.
LighScan op 23 januari 2012 #
Bedankt unSOUND, dat heeft de oorzaak voor mij veel duidelijker gemaakt! In dit geval zit er niet veel anders op dan hem maar een nachtje door te laten werken.
Overigens ook bedankt voor de tip over de verhoudingen, ik heb een nieuw proces in gang gezet waarbij de oorspronkelijke verhoudingen gerespecteerd blijven.
Voor mezelf doe ik dat ook nooit, mijn Engels is (gelukkig) ook meer dan voldoende om films zonder ondertiteling te bekijken. Deze film is echter een, al zeg ik het zelf, "oldtimer", ik had geluk dat ik die nog kon vinden (in de winkel verkopen ze die al heel lang niet meer), en is bestemd voor mijn oma (vandaar de ondertiteling). 
Qmagic op 23 januari 2012 #
Het inbranden van de ondertitels kost (zeker bij HD) nog eens extra veel tijd boven de normale conversie. Je zou kunnen overwegen om een hardware usb-stick van Elgato te gaan gebruiken (wat ook door submerge ondersteund wordt). Deze hardware encoder is echter niet goedkoop (€100): Elgato Turbo.264 HD.
unSOUND op 24 januari 2012 #
Qmagic - op 23 januari 2012Het inbranden van de ondertitels kost (zeker bij HD) nog eens extra veel tijd boven de normale conversie.
Vreemd, die ervaring deel ik eigenlijk niet. Heb laatst nog een paar filmpjes tegelijk gedaan, zowel met als zonder ondertiteling, en ze gingen eigenlijk allemaal even snel ( of langzaam 
)
Qmagic op 24 januari 2012 #
Als ik roadmovie gebruik (vergelijkbaar met submerge) en een 720p mkv bestand met srt gebruik, is het met ondertitel inbranden 12 fps en zonder ondertitel inbranden 20 fps. (het is wel een oudere versie van roadmovie).
Ik heb net ook even de demo van de nieuwste submerge versie gedownload, 42 fps zonder ondertitels en 20 fps met ondertitels inbranden (incl. gebruik met Turbo.264 HD).
42 fps of 20 fps is toch een groot verschil.
LighScan op 24 januari 2012 #
Aangezien dit iets uitzonderlijk is ga ik zo'n dure aanschaf niet maken, maar ik ben wel blij met de reacties die ik op dit topic heb gekregen, nu weet ik tenminste dat dit niet zo abnormaal is.
@unSOUND: dat is een goeike! 
Advertentie
Je kunt alleen reageren met een gratis OMT account.
Log in of registreer.
Inloggen
Over dit topic
Gestart op 23 januari 2012 door LighScan
Laatste reactie door LighScan