Video Stuff |
---|
Quickstart:
--> Transcode mailing list archive
--> Transcode Action Package
--> Profiling transcode
--> NVrec - transcode info
--> transcode deinterlacer test
--> zoomto transcode Script
--> v4l loopback kernel module hacks
--> MPlayer v4l video out module
<-- Tilmanns Corner
"Video-encoding-junkie? Me? Let me think about it for 25 frames, ehh, one second"
Transcode mailing list archive |
---|
I have put up a searchable mailing list archive of transcode-devel
and transcode-users at http://www.itdp.de
Enjoy!
Profiling transcode |
---|
I profiled transcode-0.6.0rc2,
here are the results for reference. Profiling transcode is a bit tricky because
transcode is a multithreaded application and uses a lot of shared libraries. The
functions from the various import and export modules don't show up in the
profile. To profile the threads, I used the idea from
HOWTO: using gprof with
multithreaded applications
If you don't have the slightest idea howto read the profiles, you may mant to
look at the gprof manual at http://www.gnu.org/manual/gprof-2.9.1/html_mono/gprof.html#SEC11
gprof-orig-rc2.txt:
transcode -V -i matrixbench_mpeg2.mpg -x mpeg2
gprof-j.txt:
transcode -V -i matrixbench_mpeg2.mpg -x mpeg2 -j 128,8
gprof-B-j.txt:
transcode -V -i matrixbench_mpeg2.mpg -x mpeg2 -B 1,2 -j 128,8
gprof-B-j-xvid.txt:
transcode -V -i matrixbench_mpeg2.mpg -x mpeg2 -B 1,2 -j 128,8 -y xvidcvs -o foo.avi -w 800
NVrec - transcode info |
---|
(Jun 26 2002) NVrec moved to http://nvrec.sf.net and got renamed to nvrec. Transcode >= 0.6.0rc2 can deal with it.
(May 23 2002) If you came here looking for the nvrec-RAWrec patch this is for you. As I wrote on transcode-users in this message:
I removed the patch because there is now an official release of NVrec at http://nvrec.sf.net which contains support for transcode. RAWrec has become 'DIVX4rec -o raw://' which has become 'divx4rec -o raw://' and you have to use transcode-0.6.0-pre5. See /docs/import_nvrec.txt in transcodes directory for Changelog and usage.Be sure to disable transcodes autoprobing and YUV mode, an working example command line would be
$ transcode -i /dev/video0 -x nvrec -y xvidcvs,null \ -g 576x432 -V -e 44100,16,2 -J ppcvs="lb tn:64:128:256 dr" \ -H0 -u 100 -o video-foo.avi -m audio-foo.avi |
transcode deinterlacer test |
---|
I've done some testing of deinterlacers available in transcode
The result was produced with this shell script. Note that you'll need convert from the ImageMagick package. The script isn't assumed to be usuable to the public, it is mainly provided here for reference and You are encouraged to read it. The input was a raw captured Y'CbCr stream from my video capture card.
This is a jpg version of the resulting images. For accuracy please download the bzip'd ppm version.
Deinterlacing is always a compromise between speed and quality. So if you have lots of cpu cycles to spend, I would use either -I3 or the smartdeinter filter plugin I ported over from VirtualDub.
zoomto transcode Script |
---|
This script generates -B or -X options for
transcode
You can download the script here
If (for example) you want to transcode a 640x480 video to 384x288 but don't want to use the slow (but high quality) -Z zoom option and you are too lazy to figure out the correct -B values yourself just do
$ ./zoomto.sh 640x480 384x288 -B 6,8 |
$ ./zoomto 643x480 384x288 -j 0,2,0,1 -B 6,8 |
If your input size is a multiple of desired output the script now outputs
a -r option (instead of -B) since its faster than -B
$ ./zoomto.sh 768x512 256x256 -r 2,3 |
The -j and -Y options generated always align to the nearest n*32 boundary. This means they can be negative (adding black bars). A full featured example:
$ ./zoomto.sh 702x512 638x475 -j 0,-1,0,-1 -B 1,2 -Y 3,1,2,1 |
v4l loopback kernel module hacks |
---|
Disclaimer: I just hacked on vloopback, I did not write it. But since the Author http://motion.technolust.cx/vloopback/index.html (dead site) doesn't has responded to my mails I am providing the patches here. So if you use code from here, mail me god@tibit.org not him.
NEW (2003-11-06)
The project moved from the technolust site to sourceforge, you'll find updated version at http://motion.sourceforge.net and the module at http://motion.sourceforge.net/vloopback/
Fixed a few things in the 0.90 version of this module, especially the
dev_offset insmod parameter and the zero copy mode. Also be more tolerant
to applications who send uninitialized structures.
I tested on a SMP x86 box with 2.4.19 and devfs so your mileage may vary.
Read the unified diff output here: patch-vloopback-0.90
Fetch the gzipped tar file here: vloopback-0.90-tibit.tar.gz
mplayer vo_v4lw module |
---|
Patch to mplayer-0.90pre6 is vo_v4l-patch-04-09-2002.p1
Quick v4lw loopback howto:
* get the vloopback kernel module from http://motion.technolust.cx/vloopback/index.html or (alternative) my hacked version from this site
- if using my version, you don't need to specify dev_offset.
- untar and compile it
tar xzf vloopback-VERSION.tar.gz && cd vloopback-VERSION make- load the vloopback module
insmod vloopback.o dev_offset=2 pipes=1
- Make the devices accessible
chmod og+rw /dev/v4l/video2 chmod og+rw /dev/v4l/video3
- eventually you have to recompile mplayer to let it see that it can talk v4l.
./configure --enable-v4lwto be sure
- start mplayer
mplayer -vo v4lw movie.avi
- start xawtv, with size parameter
xawtv -c /dev/v4l/video3 -geometry 800x600
- done. easy, isn't it.
NOTES:
- avicap doesn't work yet.
I got mp1e to work with a my hacked vloopback.o,
you need to specify the exact size.
- no scaling of video output is possible right now.
- be sure to insmod vloopback with a dev_offset appropriate
for your system. If you have a real grabber card (eg. a bttv
which is at /dev/v4l/video0) you _HAVE_ to use at least a
dev_offset=1 or you'll crash your kernel.
- I am on devfs, if you're not you have to use /dev/video2
instead of /dev/v4l/video2 and may have to create the
devices manually.
Eg. for video2: mknod c 81 2 /dev/video2
- mplayer will tell you the v4lw output device from which you
have to read.
Performance:
System: 2 * 1GHz Intel PIII (Coppermine) #SMP
MPEG1 at 768x576:
mplayer CPU Usage ca. 35%, xawtv 11%
Divx at 512x384:
mplayer CPU Usage ca. 20%, xawtv 10%