Capping Full PAL with ffdshow MJPEG

[Kayaker]

I've capped Full PAL 768x576 with ffdshow MJPEG in Quality 100% and got some strange problems with chroma.

For example, if I did a SeparateFields() and look closely each field, there were some fields were the chroma of one field seems to be off 1 frame ( after or before )
This was strange.

Anyone has seen this behaviour ?

I can't cap in HuffYUV o Lagarith because the huge disk space ( only compress 2.5 o 3 times ) while MJPEG compression is about between 8 and 10 times.

Any suggestion regarding a almost lossless _FREE_ capture codec with good compression ratio ?

Like ffdshow MJPEG for example.

Thanx a lot.

[GodofaGap]

I haven't really noticed any mismatches with ffdshows MJPEG. Do you have a screenshot?

You could try a DV codec like Cedocida, although you will have to do the resizing after capturing then, and you have a little less chroma information. Although that's not really a problem when you convert to a an end-format later. Depending on what you want to do MPEG4 codecs with interlaced support at q1 or q2 are not half bad either.

[Kayaker]

I'll clean up those MJPEG codec and recap again to reproduce the chroma field offset problem and post again a sample.

There are strange things going on.

For example capping and then opening with AviSource() I get U and V swapped. If I open with DirectShow() source or directly the AVI with VirtualDub get U & V right.
I'll cap and upload samples soon If somebody is willing to take a look at them.


I'll take a look a Cedocida.
Why do you say that I'll have less chroma information with Cedocida ? It's supposed to work with YUY2 input and output.

BTW, I've noticed some blocking capturing directly with MPEG-4 codecs, and my CPU is pretty old, I don't think it'll handle a CPU intensive codec.

[GodofaGap]

I'll clean up those MJPEG codec and recap again to reproduce the chroma field offset problem and post again a sample.

There are strange things going on.

For example capping and then opening with AviSource() I get U and V swapped. If I open with DirectShow() source or directly the AVI with VirtualDub get U & V right.
I'll cap and upload samples soon If somebody is willing to take a look at them.
I remember U and V swapping from very old versions of ffvfw... are you using the latest version of ffdshow-tryouts? I certainly don't have swapped chroma channels with avisource.

I'll take a look a Cedocida.
Why do you say that I'll have less chroma information with Cedocida ? It's supposed to work with YUY2 input and output.
That's true, but PAL DV is 4:2:0 internally (like MPEG4) and NTSC DV is 4:1:1 internally (like, well, nothing else really).

BTW, I've noticed some blocking capturing directly with MPEG-4 codecs, and my CPU is pretty old, I don't think it'll handle a CPU intensive codec.
The MPEG4 codec from ffdshow with a small keyframe interval (15 to 25) and Q2 produces quite acceptable results for me (not worse than MJPEG). But then I can run it in 2 threads, which helps a bunch of course. I suppose when your processor can't handle it, it's out regardless of quality.

[Kayaker]

Yes, I'm using latest (or so) ffdshow 1960.

But gotta clean up some codecs, and try again.
This U V swapped thing must be some problematic vfw codec.

Problem is that you can't see the real used filter chain in VfW like you can with DS filters.
I'll debug it easily that way. AviSource() uses internal AVI splitter and external VfW codecs based on fourcc right ?

Pretty clear your other explanations.
I'll test and post back soon.

One last, what about ArithYuv (not tested yet) ? I suppose the downside will be a low compression ratio.

[GodofaGap]

Yes, I'm using latest (or so) ffdshow 1960.

But gotta clean up some codecs, and try again.
This U V swapped thing must be some problematic vfw codec.

Problem is that you can't see the real used filter chain in VfW like you can with DS filters.
I'll debug it easily that way. AviSource() uses internal AVI splitter and external VfW codecs based on fourcc right ?
Avisource is basically copied from VirtualDub. You can check with VirtualDub what decompressor is being used by opening the file directly in there and open the file info dialog.

One last, what about ArithYuv (not tested yet) ? I suppose the downside will be a low compression ratio.
It's tested here: http://www.compression.ru/video/codec_comparison/lossless_codecs_2007_en.html

For analog capturing you don't have to expect anything better than a 3:1 ratio if you go lossless. And that's a positive estimate.

[Kayaker]

You're right. Gotta forget lossless or by new hard drives.

And go for some "almost lossles artifact free not so CPU intensive".

I was missing your tip of lowing the keyframe interval with Xvid, maybe that's the secret.
And the CPU maybe will be at 75 % if I tweak parameters a little bit for faster speed...

Any other suggestion with Xvid ? I , P and B frames ? No B-frames maybe ?
fixed quantisizer Q=2 ?

[GodofaGap]

I haven't used XviD in a long time so you will have to fiddle a little with it yourself. I don't use b-frames with ffdshow's MPEG4, but I don't really remember from the top of my head if that was for quality or speed concerns. I guess in XviD VHQ should definately be turned off. Q2 is good yes.

[Kayaker]

Maybe the problem was that encoder ffdshow MJPEG option

Input - Assume interlaced if heigh > 288

I have it checked ( it seemed the most logical setting, like same setting of HuffYUV ) as I'm capping interlaced.
But I'm suspecting I got something wrong.

[GodofaGap]

That's just a generic ffdshow option. AFAIK MJPEG is always 4:2:2 and that doesn't need specific interlaced flagging.

[Kayaker]

Wouldn't it be greyed out if it didn't apply ?

I remember seeing and option 4:1:1 in Morgan MJPEG codec.
Don't know if it's legal or not.

who knows ... well thanks a lots for the tips. I'll test and post back.

[GodofaGap]

Wouldn't it be greyed out if it didn't apply ?
It's not greyed out for any codec, even not for those that do not support interlaced flagging (e.g. DivX 3, MPEG1, uncompressed).

I remember seeing and option 4:1:1 in Morgan MJPEG codec.
Don't know if it's legal or not.

I don't doubt it is difficult to hack support for different colorspaces in, but I don't think it's officially allowed.

[Kayaker]

I've made some test again yesterday.
I don't understand. I must have something wrong.

My capture drivers, my capture program or I'm doing something wrong.

There are blended fields, this is OK and is because a crappy NTSC -> PAL conversion.
I can live with that.

The problem is with that chroma shifted one field. after or before.

Any advice would be appreciated.

The only things that work perfect with chroma are :

1 - capping with Huffyuv

2 - capping with Morgan MJPEG and decoding ALSO with Morgan MJPEG ( with another mjpeg codec there are problems ) and in this case use DirectShowSource(). if I use AviSource() I get U and V swapped.

Here are the samples (tiny upload), explanation inside.

Sample1 (http://s000.tinyupload.com/index.php?file_id=03494852429296260724)
Sample2 (http://s000.tinyupload.com/index.php?file_id=06271854130862444337)
Sample3 (http://s000.tinyupload.com/index.php?file_id=97341835262563466790)
Sample4 (http://s000.tinyupload.com/index.php?file_id=07349027726150063929)
Sample5 (http://s000.tinyupload.com/index.php?file_id=00555164516318060984)

[GodofaGap]

Whoa. No, I definitely don't see that happening with MJPEG here.

In sample1 (huffyuv) there seems to be chroma mismatching too (field 26 and 30 for example), so I don't think it is related to MJPEG perse.

EDIT: I must admit I don't capture cartoons, and seems to be very visibile there. There's an episode of the simpsons being broadcasted today so I'll capture that and see what happens.

[Kayaker]

I suppose that can be a FOX broadcasting problem.

I don't see any mismatched chroma fields with Huffyuv in other channels.
At least not so many like with other codecs.

Anyway I got something terribly wrong someplace, gotta find what it is...

BTW, the local channel broadcasts The Simpsons perfectly without any blended fields.
FOX broadcasts blended fields and with lot of MPEG blockiness in movement scenes.

[GodofaGap]

At least Comedy Central here doesn't make as much of a mess of the NTSC->PAL conversion as Fox. :cool:

I checked the Simpsons capture, and I could find one frame with a chroma mismatch, but that's so sporadically that it's hard to blame ffdshow on it. If it really was the codec, I'd expect it to go wrong all the time.

[Kayaker]

I guess I've fixed it.

I've cleaned and reinstalled other capture card drivers AND with ffdshow MJPEG checked the assume interlaced if height > 288.

I guess that option affects somehow. For example the invert picture checkbock, does exactly that. So it works.

Almost all the cartoon I've tested here have blended fields and some aberrations from NTSC -> PAL conversion.

The only strnge thing left is if I cap with DS Morgan MJPEG then I MUST use DirectShowSource() else I get U and V swapped.
Strange because it's supposedly the same codec, capped with directshow and decoded with VfW.

[nbarzgar]

@Kayaker
I have captured a lot of MJPEG material in my time and I remember VERY well, how much headache Morgan's MJPEG caused - exactly the same problem: U and V swapped!

There is a filter in Avisynth you may try: SwapUV(), use it directly after AviSource, if you are set on using it.

(Short discussion here: http://forum.videohelp.com/topic263747.html )

Should your first post indicate that at your place PAL-system is standard/you capture PAL usually, try uninstalling Morgan MJPEG completely and installing PicVideo MJPEG instead. It is geared towards PAL more than Morgan's is, results might turn out to be more satisfying even.
But you should not have BOTH installed, either the one or the other, might cause problems otherwise. :cool:

EDIT: Look here (http://www.doom9.org/capture/capturing_vdub.html#cap_codec) for hints on codec settings, right beneath Huffyuv settings, PicVideo is dealt with. EDIT.

Don't know, if you need the help at this time, but - good luck anyway!

[pandy]

try to use Virtual VCR + ffdshow - personally use with leadtek winfast2000 and it is ok (i use 720x576, huffyuv, YUY2, P4 3Ghz) - btw change quality from 100% to the fixed quantization ratio =2

[Kayaker]

@nbarzgar

Sure, I always need help :)
Decodigo with MORGAN M-JPEG I've used SwapUV() with AviSource() or directly DirectShowSource() to get U & V right.
But it's a relief to hear it's not a problem of my configuration.
I'll test PicVideo soon.

@pandy

I use Fly 2000 TV. Because I have a LifeView 3000 with chipset Philips SAA 7133 and that's the only program that can capture audio directly from the card thru PCI ( without soundcard ) and the quality is a LOT better.

The problem with Huffyuv is the disk space.
I need something almost lossless with more compression ratio.
Sometimes I need to record a lot of things in the weekend when I travel and don't have time to encode to Xvid.

You say quantizer = 2 is better than Quality 100 % ?
I've tried both but haven't paid much attention to the differences.

[Kayaker]

That Pegasus PICVideo seems very good.

Not actually tested but it has so many options that's gotta be good.