Quoting Alex 'CAVE' Cernat <[EMAIL PROTECTED]>: > 1. in afara de mplayer si transcode, mai exista si altceva pe piatza > ?
Yeap. Gramezi. mjpegtools e un proiect interesant. Seamana cu celelalte doua... dar nu prea seamana. :-) Sa ma explic, printr-o comparatie: - mencoder e pentru geeks care vor sa converteasca diverse formate arbitrare in diverse alte formate arbitrare in timpul liber, avind ca si calitate majora flexibilitatea si versatilitatea. - transcode e tot cam p-acolo, ceva mai putin flexibil pentru userul normal, dar ca arhitectura e mai flexibil (si mai deschis): clustere + multithreading (niste nemtzi plictisitzi au ripuit pe un SGI Origin 3000 cu 128 de procesoare un DVD in vreo cinci minute :-O sau cam asa ceva), permite pluginuri (chiar si binare) 3rd party, preview while transcoding (cu driver XVideo incorporat), etc. - mjpegtools, dupa cum ii arata numele, e focalizat pe formatul MJPEG si similare, care sint formate video pro si semipro. Stie si alte formate, ce-i drept, nu doar MPEG si MJPEG. E clar mai putin flexibil ca celelalte, si nu prea e genul de aplicatie pentru omu' de pe strada, dar daca lucrezi in primul rind cu MPEG, in special faze gen calitate buna la rezolutii mari (regim de studio video), cu placi de captura high-end and stuff like that, atunci e mai bun. Ce-i drept, e cam lent, dar nu viteza e ce vor ei. http://mjpeg.sourceforge.net/ Spre exemplu, e folosit optional de transcode ca plugin high-quality pentru output MPEG, merge mai bine (ca si calitate + standards compliance) ca si codecurile interne. Uite ca-l foloseste si omu' de pe strada. :-) Ah, da, uite o aplicatie "normala" pentru mjpegtools: e scula preferata, in clipa de fata, pentru generat streamuri MPEG2 DVD-compliant pe Linux. De asemenea - Cinelerra, Kino si Avidemux stiu sa transcodeze (_cred_ ca toate stiu) intre diversele formate pe care le suporta. Sint mai mult aplicatii GUI decit transcodere "bare bones", dar sint scule faine, fiecare in felul ei. http://heroinewarrior.com/cinelerra.php3 http://kino.schirmacher.de/ http://avidemux.sourceforge.net/ Pe urma, din Xine incearca sa se desprinda o "creanga", in stadiu inca pre-alfa, care vrea sa devina un fel de Cinelerra, dar bazat pe engine-ul xine. Se cheama Enix. http://enix.berlios.de/ Well, poate nu chiar ca Cinelerra, ci mai degraba ca un mutant Xine-Cinelerra-transcode: de la primul ia modelul "biblioteca threaded + frontenduri multiple", de la al doilea versatilitatea GUI-ului si caracterul de scula GUI completa gen "Final Cut Pro versiune open source" (ho! am exagerat si eu un pic; ce, n-am voie? :-D), de la ultimul arhitectura modulara. Oricum, nu e gata inca pentru end-useri. De asemenea, sa uitam GStreamer, care urmeaza sa devina fundatia multimedia pentru Gnome, atunci cind va deveni suficient de stabil (e foarte aproape de momentul ala, e deja utilizabil stand-alone). Ca idee, e un fel de "xine + enix on steroids", adica o biblioteca de functii multimedia la care poti linka aplicatii arbitrare (frontenduri specializate, sau chiar orice aplicatie la intimplare), ca sa le conferi abilitati multimedia (player, encoder, video pipe, etc.), dar are in plus fata de Xine chestii de streaming si pipelining. Stiu sigur ca exista deja playere bazate pe GStreamer, nu sint sigur daca exista si encodere (desi ar cam trebui). http://www.gstreamer.net/ Din cite am auzit, ceva similar intentioneaza KDE sa faca cu Xine (atita doar ca probabil functiile de pipe vor fi furnizate de arts sau ceva de genul asta). > 2. fiind obisnuit mult prea mult cu mencoderul (si chiar foarte > multumit > de el), cine imi poate zice si mie (sa fie cunoscator al > transcode-ului, > ofc), cum s-ar traduce urmatoarea comanda ? > > -ovc lavc -lavcopts vcodec=msmpeg4:vbitrate=$2:vhq:keyint=250 \ > -oac mp3lame -lameopts cbr:br=192:q=9 \ > -noskip -sws 2 -ofps 23.976 \ > -vop scale=640:480 -o "$out" "$in" Holy shoot! Urasc sa traduc dintr-o limba in alta, cind nici una nu e romana. :-/ Nu garantez pentru ceea ce urmeaza. Daca parametrii urmatori iti belesc HDD-ul, iti omoara ciinele si-ti dau foc la casa, e doar vina ta: -i "$in" -o "$out" \ -H 10 \ # autoprobe 10 MBytes -Z 640x480 \ # equiv "-sws 2 -vop scale" -f 24,1 \ # equiv "-ofps 23.976" -b 192,0,0 \ # equiv -oac... -w $2 \ # equiv vbitrate=$2 -y ffmpeg # lame ar trebui sa fie implicit vhq e implicit keyint=250 - de ce asa mare? Daca vrei neaparat, poti sa-l adaugi asa: -y ffmpeg=keyint=250, insa default-ul ar trebui sa fie ok. Daca lame nu merge implicit, adauga-l asa: ",lame" dupa ffmpeg (sau dupa optiunile la ffmpeg, daca e vreuna). Vezi in fisierele text care vin cu transcode ca e un document numit export_ffmpeg.txt, care are toate optiunile. Mai poti adauga ca optiuni transcode generale: -V ca sa lucreze in spatiu YUV (mai rapid), dar uneori unele module se supara --print_status 20 ca sa printeze info in xterm doar o data la 20 de frame-uri (sa nu manince CPU degeaba la fiecare frame) Mai poti incerca, evident, conversie in doi pasi, etc. Daca ai nevoie sa prelucrezi rezultatul dupa conversie, vezi utilitarele avi* si tc* care vin pe linga transcode. Dupa parerea mea, "-sws 2" (mencoder-ish) respectiv "-Z" (transcod-ish) nu se justifica atita vreme cit atit sursa cit si destinatia, ambele simultan, nu sint high-quality (bitrate si marime a imaginii foarte mari, gen DVD sau chiar HDTV). Cita vreme nu pornesti de la DVD/HDTV quality si nu ajungi tot acolo, -Z nu aduce cistiguri prea vizibile, in special daca vizionezi pe (HD)TV nu pe computer. (O sa bat cimpii putin...) Mie mi s-a intimplat chiar o chestie foarte ne-intuitiva de vreo doua ori: am vazut ca scalarea high-quality _mareste_ cerintele de bitrate in streamul destinatie, in unele cazuri; ca rezultat, fisierul final arata _mai_prost_ cu -Z (-sws 2) decit cu -B. Efectul a fost mai pronuntat cind am aplicat un filtru de antialias, indiferent daca am scalat cu -Z sau -B. A trebuit sa aplic un filtru trece-jos (-J smooth) ca sa-si revina, dar atunci s-au cam dus naibii detaliile. E adevarat ca erau cazuri cam extreme (destinatie DivX/XviD/ffmpeg cu bitrate nu prea stralucit, cam vreo 700kbps, la vreo 0.27 bits/pixel, sursa MPEG2 DVD-quality dar capturata de pe o pelicula cam semipro spre amator, cu granularitate maricica), dar totusi... Pentru cazuri normale, -B merge mult mai repede si arata practic la fel. Are o sintaxa mai ciudata, in sensul ca trebuie sa specifici diferenta de marime intre sursa si destinatie, nu direct marimea destinatiei. Nici diferenta nu e specificata explicit :-) ci in multipli de 8, 16 sau 32. Exemplu: -B 9,15,16 Inseamna: creeaza o imagine care e cu 9x16 pixeli mai mica pe verticala decit originalul, si cu 15x16 pixeli mai mica pe orizontala. Motivul pentru sintaxa ciudata e ca -B e un rescaler rapid, targetat pe codecuri care nu suporta prea bine decit multipli de 8, 16 sau 32 (de fapt, 8 nu e suportat de prea multe, 16 e mai sigur; DivX merge sigur cu 16) si vrea sa te _forteze_ sa pui multipli. Ok, hai sa ma opresc aicea, ca mai am si alte treburi. :-) > ( folosita pentru a trasforma din svcd in divx3 ) Bleah. Cind convertesti o balega intr-un rahat rezultatul nu miroase in nici un caz a profiterol. :[EMAIL PROTECTED] Baga niste filtre (-J), sa mai tai din zgomotul ala nashpa de cuantizare SVCD. Vezi dnr si smooth. > nu ma deranjeaza nici divx4 sau 5, atata timp cand merge seek-ul si > pe > winblows (cu mencoder si divx de linux se ducea in barci cand era > vorba > de cautare, de asta am ajuns la lavc, cu care se misca super pe > ambele > platforme) Sa nu fie oare mai degraba problema de container (AVI) decit de codec (DivX)? De asemenea, mai vezi si XviD, care are chestii comune atit cu divx.com cit si cu lavc. <sigh> RLUG, aceasta gaura neagra a timpului meu liber... :-( -- Florin Andrei http://florin.myip.org/ ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/
