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.

$ 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

The script also calculates fitting -j options if the input size is not a multiple of 32. Same is true for -Y if output size is not a multiple of 32

$ ./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

   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-v4lw

- 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%

Top

© 2003 Tilmann Bitterberg, tilmann@bitterberg.de