Amateur Video Production Using Free Software and Linux

How to digitize analog video sources for storage and manipulation on a computer.

In 1999 I purchased my first DVD player. My wife and I had a small collection of VHS tapes containing videos that we wanted to view using our new purchase. Furthermore, optical media is very convenient and stable, and the idea of storing our video collection on CD-R discs was very attractive to us. What followed was a very indepth investigation that has flourished into an interesting hobby. In this article, I cover how to digitize analog video sources for storage and manipulation on a computer, tools for editing video on a computer and some options for publishing digital videos. One publishing option I present is storage in the video CD (VCD) format, which is compatible with many DVD players. All of these steps are performed using free software.

I am a software developer, not a video producer, so please bear with me as you read this article.

Digitization

The first obstacle I encountered in my work to convert my videos was how to digitize the analog VHS tapes. Because I wanted to convert standard analog video tapes, IEEE 1394 (Apple calls this interface FireWire; Sony calls it i.LINK), though extremely powerful, defines a purely digital interface and would not suffice. Instead, I decided to purchase a video capture card. Many vendors produce these cards, which take standard analog video streams and digitize them for storage or display on a computer. I bought Hauppauge WinTV PCI video capture card that works nicely with Linux for around $80 US. Incidentally, the Linux driver framework for video capture cards is named Video4Linux.

There are a few important considerations to make when purchasing a video capture card, though they are becoming less relevant as the speed of computers continues to increase. Because capturing video from most analog sources must occur in real time, writing raw video to disk requires a very fast hard drive. In my experience, even a 10,000 RPM SCSI drive has difficulty storing raw 24-bit video with a resolution of 640 x 480 and a frame rate of 23.9 frames/second. Think about it: around 30 frames per second, 640 x 480 = 307,200 pixels per frame, and each pixel is 24 bits. In order to store uncompressed video of this quality, a hard drive needs to write 2.21 x 108 bits, or around 26MB every second!

Don't run out and buy an expensive high-speed disk array quite yet—an alternative exists. Compressing the raw video before writing it to disk shifts some work away from the hard disk. Compression can be done either by a dedicated processor, shifting work to video capture card compression hardware, or in software, shifting work to the system's CPU. Since my system has two 1,000MHz CPUs, my cheap Hauppauge card, which lacks compression hardware, performs just fine. If your computer's CPU is a little slower, it may make more sense to invest in a video capture card with hardware compression capabilities and save a relatively expensive CPU upgrade for later.

Capturing raw or losslessly compressed video is ideal for editing purposes, but capturing using a carefully chosen lossy technique such as MJPEG, which stores each frame using JPEG still image compression, is a realistic compromise. JPEG compression can be performed relatively quickly in software. In addition, many hardware video compressors output MJPEG.

Even when compressing a video stream before writing it, hard disk speed is important in digitizing video. It follows that the filesystem used is a large factor in performance. I have experimented with the ext2, ReiserFS and XFS filesystems. My experience is that capturing video to an XFS filesystem generally outperforms capturing to ext2- or ReiserFS-formatted disks. XFS has the additional benefit over ext2 of being a journaling filesystem.

Andrew Morton's low-latency kernel patch also seems to help the digitization process. I find that with Andrew's patch I am able to perform minor tasks on my computer while capturing video without losing too many frames.

As I am from the United States, I am interested in using the National Television System Committee analog video format (NTSC). Many Europeans may be more interested in PAL, which has similar properties. If you live elsewhere, a little research will reveal the analog video format used in your region. My VHS tapes are encoded using NTSC. NTSC has a range of acceptable resolutions and frame rates; when capturing from a VHS source I generally capture 640 x 480 frames at a rate of 23.976 frames/second. Though VCDs, being digital, don't have a video norm such as NTSC, DVD players generally use the frame rate that a VCD contains to decide what type of analog signal they will send to the television to which they are connected. For example, if I encode VCDs at 25 frames/second, my DVD player outputs a PAL signal that looks distorted on my NTSC television. If I encode the same video stream at 23.976 frames/second, a valid NTSC frame rate, my DVD player outputs an NTSC signal to my television.

Digital media streams found on a computer are generally stored as a wrapping format containing one or more audio and video tracks. Examples of wrapping formats are AVI and QuickTime. QuickTime has the advantage of being well defined by Apple, supported on Linux and able to store video streams much larger than 4GB. Within the wrapping format, different compression techniques such as MJPEG, OpenDivX, Ogg Vorbis and MPEG audio may be used. These compression/decompression techniques are often called codecs. Wrapping formats such as QuickTime also can contain storage-intensive raw digital audio and video.

I have found that streamer, part of the xawtv package, performs the digitization task nicely. Using streamer, my system can capture 640 x 480 video at a frame rate of 23.976 frames/second from my video capture card and compress it in real time to an MJPEG encoded QuickTime before writing it to disk.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

KARI

.<br>.'s picture

Please click here to sign in or register

Anonymous's picture

Anyone here that can help me with transcoding a pal divx to an ntsc vcd? I am using mjpegtools and transcode but there's no way I can synchronize the sound and video..
All replies greately appreciated!
George

Re: transcode pal to ntsc

Anonymous's picture

Sorry it took nearly a year to reply :^}
... am having a similar problem myself. Pulled down a TeleSync of a theatrical release that was posted as a set of AVI files. This is leading me into the learning curve of transcode. Google may be your friend but transcode will get the work done for you on a linux machine. I have been referring to a number of websites and will likely finally learn the ins and outs of telecine, 3:2 pulldown, and likely a few other topics b4 the nite is out. Check out AUTHORING PC MEDIA TO DVD USING THE LINUX OPERATING SYSTEM Not my site, turned it up in a google search. Purports to be a kickstart guide to authoring DVD-R using only linux open-source tools. The stuff concerning transcode and mjpegtool's mplex applies liberally to authoring VCD. And there is some specific advice about transcoding from PAL to NTSC. Transcode has some command line options specifically geared to changing PAL content into NTSC compliant content. The Doom9 site though geared toward 32bit Windows users has lots of sound advice concerning general knowledge one needs to take into account when authoring DVD and/or VCD discs.

From the first site I mention: Encoding the movies
Know or find out what TV format you will be using.
For most of Europe & Australia, use PAL.
For America (and others?), use NTSC.
[the following command line will output NTSC regardless of the input --ed note ]
For NTSC:

transcode -i matrix.mpg -V -y mpeg -F d -Z 352x240 --export_fps 29.970 --export_asr 2 -E 48000 -b 224 -o matrix

================================================

the first option "-i matrix.mpg" defines the input ==> the file we want to make VCD compliant
the next option "-V" from the manpage ==>

use YV12/I420 as internal video codec [off].
This is usually much faster than RGB processing but some import modules may not support this format. Always use this option when possible.

apparently this sets up a condition that transcode knows about internally and w/o setting this option it is off by default
the "-y mpeg" tells transcode to use the Mpeg 1/2 export module and the immediately following "-F d" tells it to make the file DVD compliant. We'll change this to "-F v" for VCD compliant content
Now for setting up the NTSC parts
"-Z 352x240" sets up the proper size -- PAL is 352x288 for VCDs
"--export_fps 29.970" so the intermediate files we are writing have the proper frame rate for NTSC
and now let's set the aspect ratio (4/3 for US tv) with "--export_asr 2" would be "1" for 1 to 1, commonly used for stuff that will only be viewed on (S)VGA PC screens 3 for 16:9 aka widescreen format, those DVD movies with black bars top and bottom of the screen on your "typical" television
Last but certainly not least, set the audio
first we'll change "-E 48000" to "-E 44100" VCD spec expects 44.1kHz sampling. You can successfully author VCD at 48k but I think a lot of standalone players won't play them.
"-b 224" tells transcode to ensure the audio is carried in a stream with a bitrate of 224kb/s the specification standard for VCD 1.0, 1.1, and 2.0Once again, you can author outside of this but your standalone player probably won't play well.

Hope that gets somebody started in the right direction,
masked frog

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

In the examples:
lav2yuv +n -n 2 -d 3 foo.mov
lav2yuv does not have a -n or -d OPTIONS.
it does not complain about the +n but it is not in the OPTIONS either.

And where do you find out if you have divice 0,4,0 or what you have?

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

cdrdao scanbus

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

to find the device use cdrecord:

cdrecord --scanbus

Find your CD writer in the output

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Hi,

I see that many people miss a lot about software around and what you can do with digital video.

For those who are interesting in standards, just look to

vcdhelp.com

For instance PAL VCD:

Video: 1150 kbit/sec, MPEG-1 352 x 288 pixels, 25 frames/second

Audio: 224 kbit/sec MPEG-1 Layer2

NTSC VCD:

Video: 1150 kbit/sec MPEG-1, 352 x 240 pixels, 29,97 frames/second

or 23,976 frames/second NTSC Film

Audio: 224 kbit/sec MPEG-1 Layer2

For those who want grab video for instance from digital camcoder

there is an excellent dvgrab project

http://www.schirmacher.de/arne/dvgrab/index_e.html

For those who need to convert from one digital format to another (mpeg1,2 avi, divx, xvid, QuickTime etc.) there is transcode

http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/

Welcome to free digital world,

V.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

This is not a direct reply to the aboce mail, but more a problme with using streamer to capture video

Here my problem, expres in a mail sent to the xawtv author as well:

Hello,

I read the article from http://www.linuxjournal.com/article.php?sid=5817 about capturing video, I did install all the required packages, but I cannot get any valuable video file from xawtv streamer program. However, I did get good video from my camescope composite output in the xawtv Xwindow, but I cannot stream it to a file :-(, audio works fine apparently .

Here I use a command partly modified from the article mentioned above (I use PAL, and default /dev/video0)

[root@localhost /usr/local/jehan/xawtv/bin]

$ ./streamer -t 0:10 -s 352x240 -r 24 -f jpeg -F stereo -b 64 -o foo.mov -p 2

neither audio nor video format specified/found

why this messge ?

$ streamer -t 0:30 -o movie.mov -f jpeg -F mono16

neither audio nor video format specified/found

again an other example from man streamer . I did use correct option though !, Am I missing something ?

Now a command that seems to do something, I get the audio but only one video Image, not a film ! :-(

[root@localhost /usr/local/jehan/xawtv/bin]

$ ./streamer -t 0:10 -s 352x240 -r 24 -o movie.avi -f mjpeg -F stereo

avi / video: MJPEG (AVI) / audio: 16bit stereo (LE)

oss: warning: got sample rate 44101 (asked for 44100)

rate: queueing frame twice (3)], a/v: -0.02s [0]

rate: queueing frame twice (2)], a/v: -0.03s [0]

v4l: waiting for a free buffer], a/v: -0.02s [0]

rate: queueing frame twice (4)

v4l: waiting for a free buffer], a/v: -0.06s [-1]

rate: queueing frame twice (4)

v4l: waiting for a free buffer], a/v: -0.06s [-1]

rate: queueing frame twice (4)

v4l: waiting for a free buffer], a/v: -0.06s [-1]

rate: queueing frame twice (3)

v4l: waiting for a free buffer], a/v: -0.03s [0]

rate: queueing frame twice (3)

....

....

$ file movie.avi

movie.avi: RIFF (little-endian) data, AVI

$ ./pia movie.avi

plays me just one image !? not a film !?. gmplayer does the same :-(.

At the same time of that lattest capture I get this in /var/log/messages:

Jan 3 14:49:43 localhost kernel: rivatv: V4L: Requested IOCTL (0x80585600) not

implemented

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 0

Jan 3 14:49:43 localhost kernel: rivatv: V4L: Requested IOCTL (0x80685600) not

implemented

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 0

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCGCAP

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCGCHAN

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCGCHAN

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCSCHAN: 0

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_INPUT: video channel input 1

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_NORM: PAL

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 9

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_GET_STATUS = 0x083 -> GOOD INTERLACED NLPF:312 50Hz PAL

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCSCHAN: 0

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_INPUT: video channel input 1

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_NORM: NTSC

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 9

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_GET_STATUS = 0x0aa -> BAD INTERLACED NLPF:312 50Hz NTSC

Jan 3 14:49:43 localhost kernel: rivatv: VIDIOCSCHAN: 0

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_INPUT: video channel input 1

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_SET_NORM: SECAM

Jan 3 14:49:43 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 9

Jan 3 14:49:44 localhost kernel: VPX32XX: DECODER_GET_STATUS = 0x0a2 -> BAD INTERLACED NLPF:312 50Hz SECAM

Jan 3 14:49:44 localhost kernel: rivatv: VIDIOCSCHAN: 0

Jan 3 14:49:46 localhost kernel: VPX32XX: DECODER_SET_INPUT: video channel input 1

Jan 3 14:49:46 localhost kernel: VPX32XX: DECODER_SET_NORM: AUTO 50Hz 083 PAL-B 0a3 0ab

Jan 3 14:49:47 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 9

Jan 3 14:49:47 localhost kernel: VPX32XX: DECODER_GET_STATUS = 0x083 -> GOOD INTERLACED NLPF:312 50Hz PAL

Jan 3 14:49:48 localhost kernel: rivatv: VIDIOCSCHAN: 0

Jan 3 14:49:48 localhost kernel: VPX32XX: DECODER_SET_INPUT: video channel input 1

Jan 3 14:49:49 localhost kernel: VPX32XX: DECODER_SET_NORM: AUTO 50Hz 083 PAL-B 0a3 0ab

Jan 3 14:49:49 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 9

Jan 3 14:49:50 localhost kernel: VPX32XX: DECODER_GET_STATUS = 0x083 -> GOOD INTERLACED NLPF:312 50Hz PAL

Jan 3 14:49:50 localhost kernel: rivatv: V4L: Requested IOCTL (0x800476C6) not

implemented

Jan 3 14:49:50 localhost kernel: rivatv: VIDIOCGFBUF: 0x0 (0 bits, 0 bpl) @ 0xD6000000

Jan 3 14:49:50 localhost kernel: rivatv: VIDIOCGPICT

Jan 3 14:49:50 localhost kernel: rivatv: VIDIOCGMBUF

Jan 3 14:49:51 localhost kernel: rivatv: MMAP buffer available in user space (3240 kb)

Jan 3 14:49:51 localhost kernel: rivatv: VIDIOCGCAP

Jan 3 14:49:51 localhost kernel: rivatv: VIDIOCGCAP

Jan 3 14:49:51 localhost kernel: rivatv: capture resolution changed: 352x240 -> 64x32

Jan 3 14:49:51 localhost kernel: rivatv: configured port: 64x32 -> 88x32 (88x32)

Jan 3 14:49:51 localhost kernel: rivatv: starting video capture

Jan 3 14:49:51 localhost kernel: rivatv: VIDIOCGCAP

Jan 3 14:49:52 localhost kernel: rivatv: capture resolution changed: 64x32 -> 352x240

Jan 3 14:49:52 localhost kernel: rivatv: stopping video capture

Jan 3 14:49:52 localhost kernel: rivatv: configured port: 352x240 -> 360x240 (352x240)

Jan 3 14:49:52 localhost kernel: rivatv: starting video capture

Jan 3 14:49:52 localhost kernel: VPX32XX: DECODER_ENABLE_OUTPUT: 0

Jan 3 14:49:52 localhost kernel: rivatv: stopping video capture

There might be something wrong, but where ?

I use rivaTV module to capture

$ cat /proc/driver/rivatv

RIVA-TNT2

Model: Elsa Erazor III Pro Video

Architecture: NV4 (NV5)

Access: Control [0xd4000000-0xd4ffffff]

FB [0xd6000000-0xd7ffffff]

Interrupts: 488 out of 64822 (DMA: 0, Overlay: 1, Missing: 64333)

Device: available

VideoDecoder: vpx32xx

Tuner: unavailable

AudioDecoder: unavailable

AudioProcessor: unavailable

$ uname -a

Linux localhost.localdomain 2.4.18-17.8.0custom #1 Sun Dec 22 23:50:23 CET 2002

i686 i686 i386 GNU/Linux

$ cat /etc/redhat-release

Red Hat Linux release 8.0 (Psyche)

RPMS:

mjpegtools-1.6.0-1

xawtv-3.74-4 ( or latest xawtv-3.82 when using ./streamer ...)

$ lspci

00:0f.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 08)

01:00.0 VGA compatible controller: nVidia Corporation NV5 [Riva TnT2] (rev 15)

Thanks for your help.

BTW, is there a mailing list, forum somewhere about all this ?

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

hello,

I had problems (previous mail) with capturing video, but since I moved from v4l to V4l2, my rivaTV driver (http://rivatv.sourceforge.net/) works fine.

Now here's what happens

$ ../xawtv/bin/streamer -b 64 -t 20:00 -s 352x240 -n pal -r 25 -j 80 -o

test2.avi -f mjpeg -F stereo

then I create the video.mpg and audio.mp2 as describe in your aticle and finaly:

$ mplex -f 1 test2_audio.mp2 test2_video.mpg -V -o test2.mpg

++ WARN: [mplex] Stream e0: data will arrive too late sent(SCR)=228082800 required(DTS)=227722500

++ WARN: [mplex] Video e0: buf= 44799 frame=060710 sector=00157677

++ WARN: [mplex] Audio c0: buf= 4096 frame=096836 sector=00031079

++ WARN: [mplex] Padding : sector=00001281

**ERROR: [mplex] Too many frame drops -exiting

Only after running few seconds it crashes :-( with the above error message.

Have an idea of what is wrong ? I don't know where to search , streamer,lav2yuv, yuvscaler, mpeg2enc, lav2wav, or mplex ?

I check about streamer, because in streamer -h they showed examples with -s 352x240, but for me PAL in 352x288 !? so I used the following command , and here I get :

$ ../xawtv/bin/streamer -b 64 -t 0:10 -s 352x288 -n pal -r 25 -j 80 -o

test2.avi -f mjpeg -F stereo

rate: queueing frame twice (3)], a/v: -0.07s [-1]

rate: queueing frame twice (2)], a/v: -0.06s [-1]

rate: queueing frame twice (3)], a/v: -0.05s [-1]

...

I don't know where to start to debug this .

Thanks

PS: could you also recommend me a forum/mailing list regarding these subjects.

im wondering why 640x480?

Anonymous's picture

Im just wondering why you capture at 640x480? The optimal NTSC setting is 720x486 and PAL setting 720x576. And the fps should be around 25 for PAL and around 30 for NTSC. Otherwise nice article, im a "to become video editor" thats been wondering about the tools for linux, now i got some answers. Keep up the good work!

Re: im wondering why 640x480?

Anonymous's picture

640x480 is a good resolution to capture a frame, assuming square pixels. Computers have square pixels.

NTSC only has 720 pixels per line if you are not assuming square pixels.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

I wonder, what software did he use for recording the video and compressing it into MJPEG in realtime ?

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

You can do that with B2000 or even xawtv

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

look @ Mainactor

http://www.mainactor.com

no for amateurs ;)

Bas

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Very interesiting article!
I have not tested streamer, but I have tested several
other grabber programs like dvr and I even tried grabbing
with Cinelerra. I compiled the source at sourceforge and
it works. I have a Nvidia based card and I use the RivaTV video4linux driver. The (1) CPU is a 1.4 Athlon. UDMA100 disks.
Still I have problems getting good size and high framerate from the card. 320x240 25 fps is good, but going to 400x300 I can only get around 12 fps. This are numbers that has been reported by people on internet haveing slower computers than mine (ok, not using rivatv, could be the bottleneck?).
I will continue to look for the bottleneck and understand the
process of grabbing in more detail. Any hints are welcomed.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

If you are using an older distribution of linux (say Redhat 6.2 or older) you may need to set certain parameters using hdparm for your system to take advantage of your ATA100 harddisk.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

I totally appreciate the clarity of your article: to the point, with relevant details on hardware and software, and with potential pitfalls.

Thanks!

I bought a Mac b/c I "got lazy" (had no time to experiment) and needed to do this kind of stuff (and it works like a charm on the Mac!). I might have continued on Linux (on this one particular project) had I read more articles like this. It might be time go back and experiment...

Joaquin

joaquintrigueros@yahoo.com

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Interesting device: http://www.dazzle.com/products/hw_bridge.html

It takes in analog video+audio and turns it into a DV stream on firewire, just as you'd get from a DV camcorder. It also goes the other way, from DV/firewire to analog out. I've not seen or used this device, but it's probably worth a look.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Dazzle DV bridge works great under linux, however, you do need dvgrab or Kino

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Were you able to get your dazzle to work on Linux?
When I first purchased mine, it came with drivers and software for microsoft but nothing for Linux. it seemed to work fine until the usb port blew out on my microsoft box.
Since then I've been checking out information on it to see how it worked on Linux.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Has someone picked up broadcast 2000? It's so far a dead product, and I've seen a lot of oddish codec issues when rendering effects.

Besides, it fails to compile under 3.1 gcc now.=(

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

AFAIK, development halted at Broadcast 2000c.

However, as the article mentions, its successor Cinelerra is very much under active development, and is shaping up rather nicely. I've used it quite a bit for audio editing.

It's a bit of a bugger to compile for dopes like me, but with a little effort, I got her up and running.

Check it out!

garethw

If I remember correctly...

Anonymous's picture

NTSC is 25 frames per sec and PAL is 29.97 fps with resolution of 352x240, not 640x480.

Recording at 640x480 seems to be an overkill. The 352x240 resolution play just fine on TV. If you want better quality, which (you don't get from analogue TV, let alone VHS tape), you can use the Super VCD format which use MPEG2 compression (same as DVD) but a different resolution than DVD. DVD or VCD players will play SVCD just fine.

Re: If I remember correctly...

Anonymous's picture

Sorry, but you don't remember correctly.

NTSC is 29.97 frames per second, where a frame is 640x480.

PAL is 25 frames per second, where a frame is 768x576.

Note that PAL frames are bigger, giving you more pixels, but the tradeoff is a much lower frame rate.

Note also that it is really more complicated than this. Really both standards have two interlaced "fields" per frame, and they are analog waveforms that don't really have pixels as such. And the number of pixels per line will be different if you include the whole scan line, not just the visible part, and different again if you are not using square pixels.

But if you are capturing video, grabbing two fields at a time to make a complete frame, and capturing just the visible part and using square pixels, the above numbers are correct.

I do agree that if you are just planning to make VCDs and delete the captured video files afterward, there is no need to capture at the full 640x480. But perhaps he figured that he will get better quality encoding from 640x480 input files, than he would get from his capture program's quick-and-dirty downsampling done in realtime during capture. Unless there is hardware doing the downsampling, this may be true.

Re: If I remember correctly...

Anonymous's picture

Nop! pal is 25fps. Actually 50 interlaced half pictures (50hz electricity). NTSC is used in usa (60hz ~ 2*29.97) Movies should be shot with 24fps, but are actually 23.97, because it's easier to convert them to 29.97fps (3:2 telecine). Movies are played back 4% faster in europe 23.97 -> 25fps.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

I'll cut some slack - since you say up front you're not a video technician. But, to set the record straight, you mention in a few places of NTSC video being 23.976 frames/second.

This is wrong. I assume you mean 29.976 frames/second. This is NTSC 'drop-frame'. Even though NTSC video is often just called 30 frames/second (non-drop frame) - or 60 fields/sec.

Having said that - a good article! I look forward to decent video (and film) editing and effects tools on linux. The main worry is the hardware driver support (audio and video).

Cheers,

Alastair

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

actually 23fps is right , as it is 29 both are aceptable for ntcs.. 23 is mainly used in vhs (film), where 29 is mainly for broadcasting..

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

I am not a video technician either, but the way I understand it, 29.976 is NTSC from a digital source, and 23.976 is "NTSC Film".

As to how "drop frame" works into this, I have no idea, but it appears to be some sort of NTSC standard. It plays on my DVD player fine.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

23.976 is technically a 'valid' NTSC framerate, but only because it can be properly converted to 29.97 by applying 3:2 pulldown. 29.97 is what your TV shows. Your TV cannot show anything other than 29.97. 23.976 is considered 'film' framerate (movies are shot at 24fps. 23.976 is close enough, and is better suited for NTSC conversion, which is why DVD's use 23.976).

Because of this, capturing NTSC at 23.976 is not really a good idea. Not even if the source is a movie (which was shot on film at 24fps) because the NTSC source (the VHS) will always be 29.97 and you're therefore skipping frames.

The proper way to do this, would be to capture at 29.97 and then if the source was a 24fps film, you can perform IVTC (inverse telecine) which removes the 3:2 pulldown and restores the 24 frames (at a 23.976 framerate). This, you can in turn encode into a VCD using 23.976. Otherwise, stick with 29.97.

I've had great success converting VHS's to VCD and even to SVCD. Granted, the SVCD process takes a lot longer, because you'll have to apply a ton of filters on the source to get a half way decent looking image. But for VHS, VCD is good enough.

Also, using 640x480 for something destined for VCD is overkill. Since NTSC VCD is only 352x240, why capture anything more than that? Besides, you'd save a ton of diskspace this way. A one hour show using mjpeg shouldn't be more than 3-4 GB at 352x240, while the same show at 640x480 and same compression would require approx 12GB.

Still... good article. I myself have been stuck in 'Windows'-land because of a desperate shortage of usable video software for Linux. I use VirtualDub to capture, and TMPGEnc to encode. Both are available for free at www.doom9.org and VirtualDub is Open Source to boot.

Great but how do I use bc2000 with dv?

Anonymous's picture

When I read the title I thought wow, cool I have a dv camcorder and run linux and have been having a tough time getting going with digital video.

I can extract video fine with dvgrab, but kino doesn't let you add soundtracks and bc2000 seems to crash with avi files.

So the second half of the article seems good, but for video production I was thinking it would explain editing video on your computer.

Has anyone got bc2000 working with dv?

Any hints on how to proceed? (maybe convert dv to quicktime???)

thanks

Re: Great but how do I use bc2000 with dv?

mcc's picture

I have been look for ways to use my sony dv camera with linux,
I currently have ~100GB of avi onDVDRAM waiting to be edited and then converted to VCD or DVD's.

An interesting place to start is:

http://www.theorie.physik.uni-goettingen.de/~ostreich/transcode/html/dv....
(It's in english)

I haven't used it yet (only found it 5 minutes ago) but I intend to this weekend.

Re: Great but how do I use bc2000 with dv?

Anonymous's picture

bc2000 and DV AFAICT is a pain - I have been unable to make it work. If you have the DV utils, you should be able to convert your DV avi stream into DV QuickTime, but I have not been able. Alternatively the mjpegtools should be able to do, again, no succes here.

Cinelerra _should_ work, but I think it requires a rather special edition of the libdv files. It is a pain too, IMHO. (Made it compile though).

You may want to test MainActor, although it is not OSS and not ideal.

Kino cvs have a project called "dvscript" that actually can do simple changes to the DV file, but it is a pain to compile, and currently does not work with the libdv cvs. (I have made and submitted a patch to fix this though).

Mads Bondo Dydensborg

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Could this technique be used to convert images from

PAL to NTSC? I am an Englishman who has moved to

NY and have a reasonable number (read 300+) videos.

Could I use this technique to play the PAL video (via

a PAL player, naturally) but record it at 23.976024 frames

and would the resulting VCD play happily as NTSC format?

Your thoughts, please!

Rgds

Stephen

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

first you'll need a PAL VCR and a power converter so you can plug it into the 110V outlet in your house, then you'll probably find that your current TV will display them fine or with some small distortion (flicker due to low refresh rate, some occasional colous shifts from hiccups in the synch of the colour burst signal, standing dot pattern from the spline fliter), if not, then yes, capturing and burning them to CD is another option. If you have a composite video out (read: NTSC) then you can just play them and tape the output too... note that you will probably lose about 16% of the height of the image, since PAL uses about 560 scanlines and NTSC uses about 480, which means the images may seem stretched, if you burn them you can of course change the aspect ratio... ;-)

Yes

Anonymous's picture

I have done just the opposite for a friend this weekend. He has relatives in Thailand, which uses PAL, and had some videos he had taken using an NTSC camcorder. I played his tapes into a capture card using an NTSC vcr and then converted the captured files to PAL format MPEGs and burned VCDs from them. Surprisingly, a PAL VCD will play on my DVD player outputting to an NTSC television and will look fine. (I did not see the distortion mentioned in the article).

I use TMPGenc, a Windows program, for MPEG conversion. I capture to Huffyuv codec using Virtual Dub. None of these programs are available on Linux, so though I prefer Linux I use a dedicated Windows ME computer for video work. I'd love to see a comparison of my Windows programs to their Linux equivalents. One thing I fear I would have to give up is Huffyuv. I creates high quality lossless captures, something MJPEG does not do. Taking MJPEG and compressing it again to MPEG or something else creates a noisy picture.

Re: Amateur Video Production Using Free Software and Linux

Anonymous's picture

Hmm. maybe you can, but I think you're better off with a tv

that accepts ntsc and pal (and possibly secam, and while

you're at it, hdtv).

HDTV Gadgets

Anonymous's picture

Great News !

I am running HDTV shop. I have few interesting gadgets their. Check it out.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState