Announcement

**Dr Mordrid** · 27 November 2001, 07:41

Most MJPegs are very similar in their disk space requirements vs. quality. The main differences are special features; fourCC options, OpenDML support, quality settings etc. etc.

I've pretty much settled on PICVideo because it is so fast, delivers very high quality and has very low resource requirements.

As for a codec with better compression and high enough quality for editing, I don't think there is one that meets both requirements.

HuffYUV delivers higher quality, but with twice the file size. Great for those of us with big RAID's, but not as useful for more than short sequences for those with small video drives. Still, it's a must to have for those "special" cases.

MPEG-2 is temporally compressed and therefore difficult to edit without hardware support (as in the RT-2000). It's also difficult to capture MPEG with high quality. Because of these issues MPEG-2 is better used as a distribution format created from high quality uncompressed or MJPeg sources.

DV doesn't produce much smaller files and has the color space issue to deal with. Because of this it also has a reduced dynamic range, which can cause artifact problems all by itself. Think of it as MJPeg Light.

DivX/WM etc. are distribution formats and not useful for editing.

Uppance: now you know why PICVideo is on every system I have and my RAID is 240 gigs and growing.

Dr. Mordrid

**pogue2002** · 27 November 2001, 08:57

Do these codecs other than Matrox support the cutlist feature? This is a nice feature on the Matrox MJPEG when you have a slow CPU (less rendering).

**AndrewDV** · 27 November 2001, 09:06

240GB! Now that's some nice real estate! Know where I can get a good price on those drives?

Talking about PIC MJPEG, what type of settings do you use? In general, I do not go much beyond the default settings. It is really nice and simple.

For the most part, I crank the Q to 20. Have you noticed much of a difference in Q settings beyond the 17-18 range with PIC MJPEG? From what I can tell, the difference is almost unnoticeable. There does tend to be a very minor stuter with the high Q settings and high motion.

The setting I wonder about is the capturing of 2 fields. Yes, I know 2 fields for 480 caps, but it is fun to experiment. I compared captures with that option on and off, but noticed no difference. I was hoping it would have done some type of deinterlacing. Again, I get some odd interlacing-like stuters with high motion (playback is done through G400-TV)

After playing around with DV, I really like how much more bright colors "seem" to be. It would be great if I could get MJPEG caps to look as vibrant. Do you think setting the color space to 4:4:4 would help at all?

BTW, I talked to some folks from Pegasus at a developer's conference. When I asked them about the next version of the MJPEG codec, they gave me the impression it is not going to get anything major soon.

**Dr Mordrid** · 27 November 2001, 10:40

My 240 gig video "drive" is what's called a RAID level 0 array, otherwise known as a "striped array". This is done using a RAID card (Promise Fasttrak TX4) hooked up to four 60g drives. It merges these drives into a single virtual drive that's 4 times as large as a single drive of the type used plus it's almost 4x as fast as a single drive.

Ex: my RAID array benchmarks as being able to capture at 90+ megs/second (as if any capture card needs that much) and can play back video at over 100 mb/s. The most useful for me is the 100 mb/s reads. Handy for previewing image sequences at high resolutions.

Also handy is the fact that this performance overkill virtually stops dropped frames during capture or playback due to system hiccups. If I didn't act to prevent them ahead of time I'd still get a drop now and then in analog captures due to a bad synch pulse in the video signal itself.

This doesn't happen because I now routinely use a video signal processor (Elite Video BVP-4+) between the cam and capture board to clean the signal up and rebuild the synch and colorburst signals. It also gets used for outputting projects to VHS so that the signal is as clean and strong as possible.

====

If you're editing in MSPro of any stripe it has its own cutlist driver that cuts in if one for your card isn't called by ulead32.ini. It works at least as good as Matrox's. In fact, I think it's better.

====

I usually use Q=20 in PICVideo, 4:2:2, field if more than 240 lines and leave the lumance/chromance alone if the output is destined for inclusion in an MJPeg project.

Stutters in high motion may be a throughput problem in your setup. This could be as simple as having not much throughput overkill in your video drive or as complex as a high latency device on the PCI bus hogging things up.

The high motion causes this because MJPeg has no fixed data rate like MPEG or DV have. It floats according to the content of each frame. What you're setting with the Q is actually the compression ratio and not a real data "rate". As such, even when set for Q=20 a given frame with nothing going on may only be a few kbytes in size while one with fast motion & lots of details may easily run over 100 kbytes.

The sudden boost in data rate caused by such a change can easily trip up an unoptimized system.

====

For you Euros out there: references to DV in the following pertain to NTSC DV which has a 4:1:1 colorspace. Of course PAL DV has a 4:2:0 colorspace; the benefits/disadvantages of which will have to wait for another day

The only time I mess with the lumance/chromance settings is if I'm editing HuffYUV or MJPeg captures and want to export them for use in a DV project. Then I up the lumance a few points so it more closely matches that of DV footage.

There isn't a 4:4:4 colorspace setting in PICVideo. DV's colorspace is just 4:1:1, markedly reduced from the norm for analog (4:2:2), but it has a higher proportion of lumance vs. chromance in its signal. This does contribute heavily to the difference in "look" you noted.

Unfortunately what's been done to the chromance portion of the DV signal is to reduce its linear resolution. In normal 4:2:2 footage the color resolution in a 720 wide frame is 360 (each color value being spread over 2 horizontal pixels). With DV this color resolution is only 180 (each color value being spread over 4 horizontal pixels).

This is the root of DV's difficulties in compositing effects, titles etc. With the color samples spread out so much vs. the lumance the colors often bleed from the overlay to the background and vice-versa. This creates rather ugly block artifacts around the overlay. Compositing these same effects in 4:2:2 footage, however, gives much better results and is why we're discussing HuffYUV and MJPeg in the first place.

The following are some pix I compiled from a site documenting how compositing differs between 4:2:2 analog vs. 4:1:1 DV. The composite was done as a bluescreen with a cloudy sky background. I think it speaks for itself;

Note the marked reduction in quality in the U and V channels (chromance) vs. the Y channel (lumance). Ugly....

====

Even though a 4:1:1 setting is available in PICVideo you don't want to match DV's colorspace because it'll complicate compositing effects and defeat the whole purpose of using PICVideo for effects shots. Go with the max on both Q and colorspace (Q=20, 4:2:2), but just adjust the lumance up a few points to compensate for the difference in "look". After a few tries you'll find a specific lumance setting that works for your specific cams footage.

Every now and then you may also have to adjust the chromance a bit as well to get a good MJPeg/DV match, but this should be done only if a lumance adjustment isn't enough. Which way the chromance has to go, up or down, is also something you'll have to determine for your specific cam.

====

My reference to 4:4:4:4 is because my RT-2000 upsamples its DV footage in order to overcome DV's problems with compositing effects. RT-2000 DV footage is treated as a 32 bit DV clip with a 4:4:4:4 RGBA colorspace, with the "A" being an alpha channel built into the video footage. It works great with the RT's 4:4:4:4 RGBA compositing engine.

The aim is the same as using high quality HuffYUV or MJPeg clips for inclusion in DV projects; the higher quality compositing of effects. The methodology is different with the RT-2000 going for hardware vs. the software methodology we have been discussing. It's also more than a bit simpler to use since everything transparent to the user with a device like the RT-2000.

====

There is already a new version of JPEG itself, JPEG2000. You just KNOW someone will come up with a video codec based on it.

Dr. Mordrid

**paulw** · 27 November 2001, 12:22

Has any one in the PAL world used the PIC codec successfully?? I currently use Morgan V3 as I found that the PIC kept giving me non supported format errors in PAL format. 704 x 576.

**pogue2002** · 27 November 2001, 12:27

Sorry Doc, but can you explain more about the cutlist function:

If you're editing in MSPro of any stripe it has its own cutlist driver that cuts in if one for your card isn't called by
ulead32.ini. It works at least as good as Matrox's. In fact, I think it's better.

Thanks.

**Fred H** · 27 November 2001, 13:42

Has any one in the PAL world used the PIC codec successfully?? I currently use Morgan V3 as I found that the PIC kept giving me non supported format errors in PAL format. 704 x 576.

Yes I do, PIC Video MJPEG 704x576 PAL, (Sweden) but for showing them on TV I must deinterlace the clips for smoother & flickerfree motion. I also use MSP 6.0 for edit, and TmpgEnc for SVCD 480x576 PAL.

Fred H
SM6JNA

**AndrewDV** · 28 November 2001, 10:38

Hi,

I thought everyone would be interested in this statement. It is from the readme file for MainConcept's MJPEG codec.

<b>
<hr>
The CODEC includes a realtime M-JPEG encoder for Win32, we included
several big improvements for doing realtime M-JPEG capturing. We think
that we are now the fastest M-JPEG Codec out there, we can encode
640*480 in 30 fps on an P-II 300Mhz. New is the Zoran support which
enables Zoran based MJPEG cards to playback AVIs coded with this codec.
<hr>
</b>

I have some free time coming up soon, so I may have to give this one a go.

BTW, does anyone else have both a WinTV and a G400-TV? Just doing some 'eye ball' tests, the YUY2+PIC MJPEG captures with the G400-TV look a bit blurry. The ones from the WinTV have a tiny bit more crispness. Of course, the G400-TV YUY2 can cap in Win2K at 704x480 while the WinTV has a ceiling of 640x480 (that is upsetting, because it can easily do 720x480 in Win98).

Thanks

**Indiana** · 28 November 2001, 13:07

Originally posted by paulw
Has any one in the PAL world used the PIC codec successfully?? I currently use Morgan V3 as I found that the PIC kept giving me non supported format errors in PAL format. 704 x 576.

Yes, I do. No problems here, although I normally use 768x576. Interlaced video works fine here as well and does in fact look better (smoother) than deinterlaced ones on TV. Deinterlacing is only good for playback on computer monitors.

**Indiana** · 28 November 2001, 13:11

Originally posted by AndrewDV

BTW, does anyone else have both a WinTV and a G400-TV? Just doing some 'eye ball' tests, the YUY2+PIC MJPEG captures with the G400-TV look a bit blurry. The ones from the WinTV have a tiny bit more crispness. Of course, the G400-TV YUY2 can cap in Win2K at 704x480 while the WinTV has a ceiling of 640x480 (that is upsetting, because it can easily do 720x480 in Win98).

Thanks

I can capture YUY2 in 768x576 in Win2k with my WinTV. Maybe this depends on the used driver-version?

**Dr Mordrid** · 28 November 2001, 13:52

pogue2002;

cutlist is a feature that allows MSPro to do smart rendering. This means it can do a timeline preview without rendering anything but the changes. If the changes have already been rendered to preview files then no render needs to take place at all. This is a VERY nice feature.

With Matrox cards there is a cutlist module built into the capture drivers that is called from MSPro's ulead32.ini script. In some driver versions this is called icutlist.dll and in others it's called MCLPlugin.dll. In either case this entry can be commented out (using a ; before it disables the command) whereupon MSPro will use it's own cutlist driver.

MSPro's cutlist driver is OpenDML compatable and Matrox's is not. Therefore it's frequently better to use MSPros, especially when you may be exporting with codecs like PICVideo or DV type 1 that can use the extra functionality to create > 2 gig files.

Dr. Mordrid

**AndrewDV** · 28 November 2001, 15:30

Originally posted by Indiana

I can cpature YUY2 in 768x576 in Win2k with my WinTV. Maybe this depends on the used driver-version?

That's really positive news. I have not really read people having success with that. If you don't mind, can you tell me the following:

-WinTV model
-Driver version
-Capture software/version

Thank you

**Indiana** · 29 November 2001, 10:01

You'll have to wait 'till tomorrow for this, since I'm at the RSNA in Chicago at the moment and so can't check the version numbers.
However it's a "WinTV Radio" (I believe this is called WinTV FM" in the US), the capture software I use is Virtual Dub in the newest version (however this doesn't have anything to do with the ability to capture full PAL res, cause I'm able to do that with Hauppauges util as well). For the driver version, I'll have to look, but it's the VFW one and NOT the WDM - maybe this makes a difference.
Or maybe it's a PAL vs. NTSC issue?

**Indiana** · 1 December 2001, 18:47

O.K., a bit late, but still here it is:

Driver version:

And this window shows the selectable sizes in the video format dialog of any capture program:

Announcement

Which MJPEG codec works for you?

Which MJPEG codec works for you?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment