FFmpeg 0.5 (diskuse)

[petr_p]

Opět kódujeme kodeky?

[David Watzke]

Abych pravdu řekl, taky mi to přišlo divný, ale říkal jsem si, že vývojáři FFmpegu by to mohli vědět nejlíp. Co tam teda má bejt, "formátů"?

[petr_p]

To nic, stejným bludem „trpí“ vývojáři Gnashe a já jsem při jeho lokalizaci taky trpěl (bohužel doslova).

Doporučuji se držet „(kompresního) formátu“.

[8an]

Stálo by za upozornění, že je to první stabilní vydání po více než 3 letech (od 0.4.8).

[David Watzke]

Díky, doplněno. Tuhle informaci jsem nějak nemohl najít.

[Espinosa]

No né, oni zase začali u ffmpegu verzovat? To je překvapení, měl jsem za to, že vývojáři upustili od takového "přežitku" jako versioning management a nechali tuhle nudnou práci na distribucích a distributorech. Což mělo neblahé následky v tom, že každá distribuce si vzala snapshot ze SVN v jiný okamžik. Je to zárodek něčeho stálejšího?

[GeBu]

Co je lepší? FFmpeg nebo mpeg2enc (z MJPEG) pro převod do mpeg2 - výroba klasického DVD?

[Grunt]

Porovnání. Ale bůh ví jak je to staré.

[GeBu]

Hodně: Last edited July 7, 2006 9:00 am by tarazed.ligo.caltech.edu

[Grunt]

Přílohy:

• ffmpeg_1.png (279286 bytů)
• ffmpeg_2.png (320333 bytů)
• mjpeg_1.png (305476 bytů)
• mjpeg_2.png (323616 bytů)

Tak jsem se pár dnů trápil a výsledek? Těžko říct. Je to 3600kbps. Druhý soubor má jinší framerate a celkový rozdíl video dat je 290kB.

[David Watzke]

Podle mě to vyjde na stejno, tak bych se rozhodoval pohle toho, co je rychlejší. Co je rychlejší?

[Grunt]

Podle mě to vyjde na stejno.

Máš recht:

$ /opt/ffmpeg/bin/ffmpeg -t 120 -i Videa/The.Matrix.1999.1080p.HDDVD.x264-ESiR.mkv -pass 1 -vcodec mpeg2video -s 720x298 -b 1024k -acodec copy Matrix.nut
$ /opt/ffmpeg/bin/ffmpeg -t 120 -i Videa/The.Matrix.1999.1080p.HDDVD.x264-ESiR.mkv -pass 2 -vcodec mpeg2video -s 720x298 -b 1024k -acodec copy Matrix.nut
$ /opt/ffmpeg/bin/ffmpeg -t 120 -i Videa/The.Matrix.1999.1080p.HDDVD.x264-ESiR.mkv -vcodec rawvideo -s 720x298 -f yuv4mpegpipe - | mpeg2enc -v 0 -M 2 -f 9 -E 20 -b 2048 -R 2 -o Matrix.mpg
$ /opt/ffmpeg/bin/ffmpeg -i Matrix.nut -i Matrix.mpg -vcodec copy -acodec copy -f mpegts Matrix_trunk.ts -vcodec copy -newvideo
$ /opt/mplayer/bin/mplayer -vo xv -ao alsa Matrix_trunk.ts -y 298 -fs -fixed-vo
$ /opt/mplayer/bin/mplayer -dumpvideo Matrix.nut && mv stream.dump ffmpeg
$ /opt/mplayer/bin/mplayer -dumpvideo Matrix.mpg && mv stream.dump mjpegtools
$ ls -l mjpeg ffmpeg
-rw-r--r-- 1 petrvlasic petrvlasic 15304039 2009-03-11 23:14 ffmpeg
-rw-r--r-- 1 petrvlasic petrvlasic 18297590 2009-03-11 23:14 mjpegtools

Pustil jsem to, přepínal pomocí "_", ale rozdíl okem nerozpoznatelný. Pro jistotu jsem do toho ještě narval mjpeg abych měl jistotu, že to funguje. Provedl jsem srovnání i v GIMPu. Když se to zvětší a přepíná se to, tak je vidět, že mjpegtools na rovných plochách kóduje i šum (je ale dost možné, že má ffmpeg prostě lepší odšumovací filtr), takže je asi opravdu trošičku lepší(je to vidět i na velikostech těch png screenshotů), ale nic co by běžné oko rozpoznalo a snad bych řekl, že i kvůli redukci šumu je na tom ffmpeg lépe subjektivně. Můžu ještě uložit rozdílové obrázky, pokud bude zájem.

Co je rychlejší?

Nechce se mi to kódovat do RAWu, takže jen v ryhclosti:

mjpegtools
real    7m42.896s
user    8m15.907s
sys     0m8.581s 

ffmpeg
real    6m38.586s
user    6m5.271s
sys     0m3.268s

[Mandarinka]

Žádný odšumovací filtr by neměl být použit, pokud to výsledně nespecifikujete. Nižší úroveň šumu tedy podle mě ukazuje na kvantizaci (nebo jak se tomu nadává; zkrátka ty encoder decisions) přímo v enkodéru. Nižší haldina šumu by tak vlastně mohl poukazovat na celkově nižší kompresní schopnost, protože šum je náročnější a nejmíň důležitý, je tedy nejdřív zkrouhnut. Pokud tedy enkódované video má stejnou vizuální kvalitu (je dobré porovnat při zvětšení 2X) ale o něco víc šumu, může to znamenat že máte lepší enkodér :)

 

Jinak pokud máte funkční wine ak doporučuju na porovnávání zkusit funkci "Interleave" v avisynth 2.5

[Grunt]

Tak se omlouvám oběma programům za špatně provedený test. Oba programy mají mnoho voleb, které mohou výsledky ovlivnit a ve výchozím stavu nejsou nijak zohledněny.(z,B. ani jeden do obrazu necpe B-rámce). Přes víkend budu štelovat a uvidím k čemu se došteluju.

[GeBu]

Těším se na výsledky.

[GeBu]

Autor DVD Flicku si myslí, že je mezi nimi rozdíl: www.dvdflick.net/forums/viewtopic.php

[Jouda]

Funguje dobre vice vlaknove dekodovani H.264? V popisu je "H.264 PAFF and CQM support, plus slice-based multithreaded decodin"

[Grunt]

Dnešní SVN verze:

[h264 @ 0x9894380]Cannot parallelize deblocking type 1, decoding such frames in sequential order

Mám pocit, že více-vláknovým dekódováním se zabývá mt branch a v tom to jede určitě.

[Kvakor]

Mozna se v nejblizsi dobe dockame i finalni verze MPlayeru, posledni RC je uz docela stare a nejnovejsi verze jsou jenom v SVN.

[Mandarinka]

Finální určitě ne :) Bude to spíš snapshot se snahou opravit předtím nějaké chyby... Aby verze v distrech nebyla tak zoufale neaktuální.

[Ladislav Hagara]

V některých distribucích lze instalovat přímo SVN verzi.

 

# gaze DETAILS ffmpeg-svn

           SPELL=ffmpeg-svn
if test "$FFMPEG_SVN_AUTOUPDATE" = "y"; then
         VERSION=$(date +%Y%m%d)
else
         VERSION=svn
fi
  FORCE_DOWNLOAD=on
          SOURCE=$SPELL.tar.bz2
SOURCE_DIRECTORY=$BUILD_DIRECTORY/$SPELL
   SOURCE_URL[0]=svn://svn.mplayerhq.hu/ffmpeg/trunk:$SPELL