FFmpeg Mplayer VLC - News & Howtos

[andrew.46]

Thanks telperion, x264 now builds fine with opencl. Now to test it out

[andrew.46]

I have a cutting edge CPU but a reasonably ordinary GPU:

With --opencl:

andrew@skamandros~/media/videos$ time \
> x264 --threads 0 --opencl \
>      --bitrate 800 --preset faster \
>      --tune film -o test_1.mkv Decay_2012_1080p_HQ.avi
lavf [info]: 1920x960p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTS 450 
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1306  Avg QP:26.55  size: 24994                           
x264 [info]: frame P:63991 Avg QP:31.17  size:  5491
x264 [info]: frame B:44200 Avg QP:33.48  size:  1514
x264 [info]: consecutive B-frames: 44.8%  3.0%  3.8% 48.5%
x264 [info]: mb I  I16..4: 33.6% 63.1%  3.2%
x264 [info]: mb P  I16..4:  8.1% 12.3%  0.0%  P16..4: 12.3%  1.5%  0.2%  0.0%  0.0%    skip:65.6%
x264 [info]: mb B  I16..4:  0.7%  1.0%  0.0%  B16..8:  8.1%  0.4%  0.0%  direct: 1.7%  skip:88.0%  L0:46.5% L1:52.2% BI: 1.3%
x264 [info]: final ratefactor: 33.17
x264 [info]: 8x8 transform intra:60.3% inter:84.7%
x264 [info]: coded y,uvDC,uvAC intra: 20.4% 15.4% 0.2% inter: 1.2% 0.6% 0.0%
x264 [info]: i16 v,h,dc,p: 53% 25% 12%  9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 18% 50%  2%  1%  2%  1%  2%  2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 27% 13%  5%  6%  5%  7%  6%  5%
x264 [info]: i8c dc,h,v,p: 78% 10% 11%  0%
x264 [info]: Weighted P-Frames: Y:2.2% UV:1.3%
x264 [info]: ref P L0: 73.0% 27.0%
x264 [info]: ref B L0: 80.4% 19.6%
x264 [info]: ref B L1: 94.0%  6.0%
x264 [info]: kb/s:789.90

encoded 109497 frames, 79.11 fps, 789.90 kb/s

real	23m4.248s
user	107m11.544s
sys	8m34.957s
andrew@skamandros~/media/videos$

and without --opencl:

andrew@skamandros~/media/videos$ time \
> x264 --threads 0 \
>      --bitrate 800 --preset faster \
>      --tune film -o test_2.mkv Decay_2012_1080p_HQ.avi
lavf [info]: 1920x960p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
x264 [info]: profile High, level 4.0
x264 [info]: frame I:1342  Avg QP:27.09  size: 24026                           
x264 [info]: frame P:82588 Avg QP:31.67  size:  4766
x264 [info]: frame B:25567 Avg QP:32.14  size:   990
x264 [info]: consecutive B-frames: 68.0%  2.3%  1.2% 28.5%
x264 [info]: mb I  I16..4: 35.1% 61.8%  3.0%
x264 [info]: mb P  I16..4:  6.8%  9.9%  0.0%  P16..4: 12.1%  1.4%  0.2%  0.0%  0.0%    skip:69.5%
x264 [info]: mb B  I16..4:  0.5%  0.7%  0.0%  B16..8:  5.0%  0.2%  0.0%  direct: 0.9%  skip:92.7%  L0:46.3% L1:52.1% BI: 1.5%
x264 [info]: final ratefactor: 33.15
x264 [info]: 8x8 transform intra:59.6% inter:82.0%
x264 [info]: coded y,uvDC,uvAC intra: 19.9% 15.2% 0.2% inter: 1.2% 0.6% 0.0%
x264 [info]: i16 v,h,dc,p: 53% 26% 12%  9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 22% 18% 51%  2%  1%  2%  1%  2%  2%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 28% 13%  5%  6%  6%  7%  5%  6%
x264 [info]: i8c dc,h,v,p: 79% 10% 11%  0%
x264 [info]: Weighted P-Frames: Y:1.7% UV:1.0%
x264 [info]: ref P L0: 74.5% 25.5%
x264 [info]: ref B L0: 77.6% 22.4%
x264 [info]: ref B L1: 93.8%  6.2%
x264 [info]: kb/s:790.38

encoded 109497 frames, 102.35 fps, 790.38 kb/s

real	17m49.945s
user	119m35.897s
sys	0m25.827s
andrew@skamandros~/media/videos$

Now to interpret these results.....

[telperion]

I have a cutting edge CPU but a reasonably ordinary GPU:

With --opencl:

andrew@skamandros~/media/videos$ time \
> x264 --threads 0 --opencl \
>      --bitrate 800 --preset faster \
>      --tune film -o test_1.mkv Decay_2012_1080p_HQ.avi
lavf [info]: 1920x960p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
x264 [info]: OpenCL acceleration enabled with NVIDIA Corporation GeForce GTS 450 
x264 [info]: Compiling OpenCL kernels...
x264 [info]: profile High, level 4.0

encoded 109497 frames, 79.11 fps, 789.90 kb/s

real	23m4.248s
user	107m11.544s
sys	8m34.957s
andrew@skamandros~/media/videos$

and without --opencl:

andrew@skamandros~/media/videos$ time \
> x264 --threads 0 \
>      --bitrate 800 --preset faster \
>      --tune film -o test_2.mkv Decay_2012_1080p_HQ.avi
lavf [info]: 1920x960p 1:1 @ 24000/1001 fps (vfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
x264 [info]: profile High, level 4.0


encoded 109497 frames, 102.35 fps, 790.38 kb/s

real	17m49.945s
user	119m35.897s
sys	0m25.827s
andrew@skamandros~/media/videos$

Now to interpret these results.....

it seems that with a multicore cpu (I have a Q8300) there is no advantage to using OpenCL, and even disadvantages ...

[scottro]

I'm going to post my own howto, which covers doing various things with ffmpeg (and mencoder), in the hope it helps someone.

http://home.roadrunner.com/~computertaijutsu/dvds.html

Even though it's more RH and offshoots oriented, most of it will work out of the box on Ubuntu.

[andrew.46]

I'm going to post my own howto, which covers doing various things with ffmpeg (and mencoder), in the hope it helps someone.

A lot of work in there . A small quibble though: is this completely true:

Most current distributions actually use the more modern genisoimage.

I have personally used mkisofs for many years with absolutely zero issues at all, mind you I am loathe to reignite the war between Debian and Jörg Schilling...

[andrew.46]

With the reopening of the Tutorials section on these Forums I have updated my vlc guide for Raring Ringtail and here it is:

Howto: Compile the development version of vlc under the latest Ubuntu release
http://ubuntuforums.org/showthread.php?t=2141949

It feels good to be 'back in the saddle'

[scottro]

@andrew.46, I don't want to reignite that fire either. As I said it is mostly based on RH based distros, but it seems to be the case with Fedora and Ubuntu, as well as #!Crunchbang.

If you are using mkisofs on Ubuntu, please try running mkisofs -version and see what you get.

However, that particular issue that I had, with files over 4 GB, was on CentOS, which is based on RHEL, therefore, uses older packages. It might just be that the CentOS version (and this was CentOS 5.x) was the one with the problem, and if Mr. Schilling has made newer versions of mkisofs, it's no longer a problem.

EDIT

I've changed the wording, to indicate that my issue was with CentOS 5.x, and that I've heard, but untested by me, that current mkisofs also gives no problem, however, most RH and Debian based distros use genisoimage. As I said, I too, have no wish to reignate fires, so I left out all reasons behind the changes, and also reworded it to indicate that the only problem I had was with a CentOS 5.x mkisoimage.

Thanks for the information, I actually, to my chagrin, hadn't realized that this was part of the cdrtools controversy, and of course, I should have realized that.

[andrew.46]

Well to tell the truth I do my burning on Slackware . So my version of mkisofs is:

andrew@skamandros~$ mkisofs --version
mkisofs 3.01a13 (x86_64-unknown-linux-gnu) Copyright (C) 1993-1997 Eric Youngdale (C) 1997-2013 Joerg Schilling

I believe at the moment the current limitation for ISO-9660 is 8TB. The man pages for mkisofs state:

       ISO-9660/JOLIET/UDF filesystems are limited to a maximum size of 8 TB.  The maxi-
       mum size of a single file is 8 TB (single files in UDF are currently  limited  to
       aprox.  200 GB).   If yo like to have files larger than 2 GB, you need to specify
       -iso-level 3 or above.  If a HFS hybrid is created, the  maximum  file  size  for
       files in the HFS hybrid is 2 GB in any case.

But certainly it is difficult to get mkisofs running under Ubuntu and it looks like the PPA that was a decent way of doing this has been neglected of late .

[scottro]

A quick google indicates that the version used in CentOS 5.x was mkisofs 2.x. Also, to be clear, the problem wasn't consistent, and not a problem with video files, only some data files. At any rate, I learned something today, so many thanks. (And the article has been edited a bit, which is good, as otherwise, it might have--completely unintentionally--reignited the old fight.)

[FakeOutdoorsman]

ffplay trick of the day:

ffplay input.txt

Text file to video:

ffmpeg -chars_per_frame 200 -i input.txt output.mkv

Random junk to video:

ffplay -f tty -chars_per_frame 200 /dev/urandom
ffmpeg -f tty -chars_per_frame 200 -i /dev/urandom -t 10 output.mkv

Show FFmpeg Changelog via http (stolen from ubitux in #ffmpeg-devel)

ffplay -chars_per_frame 200 -f tty 'http://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=Changelog;hb=HEAD'