MagicYUV - a new fast lossless video codec

[nekosama]

Fixed the problem by swapping avisource with ffmpegsource2, found out that avisource can bug out with big files.

[zerowalker]

How big?

[nekosama]

5.2 GB, 704x450, not 'that' big though it seems like the only logical cause till something new pops up.

[zerowalker]

Indeed not that big.
I can easily have 300gb of Video without issue.
Something must be wrong on your end, probably some complications, mismatching etc.

[the_weirdo]

Fixed the problem by swapping avisource with ffmpegsource2, found out that avisource can bug out with big files.

Wait, I don't think FFMS2 can decode MagicYUV sources, at least by now. Your avi may not be a MagicYUV encode then.

[Sparktank]

I've used SD resolution with MagicYUV as an intermediate without problems.
>30GB for lossless intermediates and no issues.

[nekosama]

Yes my bad the_weirdo, made an x264 lossless in the meantime and mistook it for magicyuv. Though it's still the same problem with trying to filter a magic yuv source with avisource input.

[foxyshadis]

Indeed not that big.
I can easily have 300gb of Video without issue.
Something must be wrong on your end, probably some complications, mismatching etc.

He's got to be using Avisynth 2.5. 2.6 has lots of fixes for 4+ GB AVI files.

nekosama, try updating to 2.6a5.

[De-M-oN]

He's got to be using Avisynth 2.5. 2.6 has lots of fixes for 4+ GB AVI files.

I could load with 2.5 avis with similar sizes too though.

[zerowalker]

Have you been able to test something with GPU acceleration, HSA etc?
We talked about it before and know you were interested in it, so wondered if you have had any chance to test it, or some ideas?

Thanks

[Ignus2]

Have you been able to test something with GPU acceleration, HSA etc?
We talked about it before and know you were interested in it, so wondered if you have had any chance to test it, or some ideas?

Thanks

Hehe, well, I'd love to, but time doesn't permit :-/
Also, I don't yet have hardware to develop on, so that's also an obstacle.
It's still something for the future to try out.

Greets,
I.

[zerowalker]

Ah, well was expecting that. Not by any means saying you Should have done it by now, but asking doesn't hurt;P

Just that you have the interest in it is a good thing, as i myself find it an interesting approach, as it holds some hope.

Well will have to see what happens in the future when you got the time,will and hardware to do any sort of testing;)!

Thanks

[Mick]

Hi there,
i downloaded RC5 and 1.0 for my Win2K Pro System and the Configuration Tool for the Codecs simply Reports the Error Message "Function not supported" and quits. The MagicYUV Codec in Versions RC5/1.0 is about 20 Frames slower (!) with a higher CPU (28-35 % more) load than the RC4 that caused no trouble with Win2K Pro (SP4). Sure, i could step up to another OS but i don't want that for several reasons, so let's leave that Discussion out right now.

Typical CPU load in Virtualub (Encoding 4K YUY2) with W2K/XP:
HuffYuv -> between 15 to 35 %
Lagarith -> between 40 to 65 %
UtVideo -> between 48 to 70 %
MagicYUV -> between 28 to 40 % (RC4), 62 to 88 % (RC5/1.0)

Resolution: 4K PAL at 25 Fps with PCM Audio, 1:1 Interleaved

Note: The CPU load is about the same on a Win7 64 Bit System.

Decoding/Playback 4K PAL Windowed/Full Screen:
HuffYuv -> fluent and stable Frame rate (+)
Lagarith -> stutters, drops Frame rate down (-)
UtVideo -> almost fluent, drops down to about 20 Fps (-)
MagicYUV -> fluent, drops occasionally down few frames (+)

Note: The Playback was the same on W2K/XP/Win7 (32/64 Bit) with Intel, ATI, NVidia and Matrox Boards

Legend:
(+) -> Audio in Sync with Video
(-) -> Audio out of Sync with Video

Further, "VideoPad" from NCH rejects to load AVI's encoded with MagicYUV, regardless of the settings and FourCC's used.

You can find the Software here and test it yourself:
http://www.nchsoftware.com/videopad/index.html

Further, if the "UtVideo" Codec is also installed on W2K (SP4)/XP (SP3), then MagicYUV seem to "stutter" at Resolutions over 4K encoding/decoding Video. I noticed this with the UtVideo Codec Version 13.3.1 and believe it's the included DMO Module from UtVideo that causes Problems. When UtVideo is removed from the System, everything is back to normal with MagicYUV. Plus, MagicYUV co-exists fine with Lagarith and HuffYuv without any Problems.

Speaking of UtVideo/VirtualDub and "v210" 10 Bit: Both produce Videos that can not (!) be played on OptiBase, AJA/Kona or DVS I/O Boards. The only Codec so far is the Drastic Codec that fully conforms to the Industrial standard and Definition for 10 Bit. So, if you plan to develop in this "10 Bit Playground", chances are that it won't work with professional Equipment.

Example:
A Colleague of mine encoded 3 TB of Material with UtVideo's v210 Codec to save space and has to start all over again now because the Files can not be used on such Systems he made them for, even if the UtVideo Codec is installed on those Systems. On a DVS HD Station, only the first 3 Frames can be loaded, the rest is green without Sound and takes awfully long to load.

In VirtualDub, no Problems with Intel, ATI, NVidia and Matrox Boards and the "v210" Codec from UtVideo. also, the UtVideo v210 Codec is painfully slow for encoding with a super high CPU load on all Cores, nothing I can recommend at this point.

You can find "UtVideo" here:
http://umezawa.dyndns.info/archive/utvideo/

Still not solved:
MagicYUV RC4 still reports "RGB24" to other Codecs with VirtualDub (Version 1.6.19 - 1.10.4) no matter how the Settings are with the "Fast Re-compress" and "Normal Re-compress" Modes. HuffYuv and Lagarith use the Color-space they encoded (YV12/YUY2) the Video with.

Interlaced Mode with MagicYUV only takes the TFF (Top Field First) which is the same for all HD Modes, but in SD Resolutions for NTSC with BFF (Bottom Field First) the Image is distorted.

I work a lot with PAL, SECAM and NTSC Material from all over the World, only HuffYuv took the Fields correctly while UtVideo suffers the same Problem like MagicYUV with the TFF only and Lagarith does not handle Interlaced as well as HuffYuv.

To give you a brief Overview about Field Orders:
PAL SD/D1/HD -> Top Field First / Upper Field First
PAL SD DV -> Bottom Field First / Lower Field first
NTSC D1/HD -> Top Field First / Upper Field First
NTSC SD DV -> Bottom Field First / Lower Field First
SECAM -> same as PAL SD/D1/HD

I hope this was helpful to you. Take care :)

Cheers

Mick

[De-M-oN]

MagicYUV RC4 still reports "RGB24" to other Codecs

Sorry cant agree you with this

http://abload.de/img/unbenannt154rzuxg.png

[Mick]

Hi De-M-oN,
well, MagicYUV certainly behaves with "Top Field First" with my Typhoon Board switched to NTSC. When I select "BFF" everything is fine but MagicYUV encodes to "TFF". Your Screenshot shows "Parity: Bottom Field First", makes me wonder because the Filter for my Typhoon let's me choose the Field Order and sets it according to the Video standard, never failed me so far.

Most Material i get is the NTSC 4.43 BFF Format. Which one was yours ? NTSC M ? PAL N (PAL NTSC Playback) ?

Your Screenshot shows "YUY2", but why is RGB24 reported from MagicYUV to XviD and x264 in VirtualDub while HuffYuv reports with the same Settings YUY2 ? I really tried all the Settings in MagicYUV but still the Output is RGB24. And yes, under "Color Depth" I chosen for Output "Same as Input" which is YUY2. What are your Settings in VirtualDub ? Maybe I've overseen something.

Cheers

Mick

[De-M-oN]

My video is progressive. The information is given at 6th line : FieldBased (Seperated) Video: NO

My video is a game recording. I recorded with DXTory.

It is a simple progressive 30fps video.

[Ignus2]

Hi there,
i downloaded RC5 and 1.0 for my Win2K Pro System and the Configuration Tool for the Codecs simply Reports the Error Message "Function not supported" and quits.

That's possible. The minimum supported OS is Windows XP, the fact that it worked with anything below that was pure luck. Sorry.

The MagicYUV Codec in Versions RC5/1.0 is about 20 Frames slower (!) with a higher CPU (28-35 % more) load than the RC4 that caused no trouble with Win2K Pro (SP4). Sure, i could step up to another OS but i don't want that for several reasons, so let's leave that Discussion out right now.

There has been no change algorithm-wise between RC4 and RC5/1.0, so the cause is something else here.

Most of the time the encoded data is not what people think it is. So for example people think it's YUY2, but actually it is RGB. That could explain why it is slower (or why the file is bigger).
The next release (in the coming days) will include an icon in the notification area, which will show exactly what is being decompressed into what format and resolution etc.

Until then, to be sure that you really encoded YUY2, select YUV 4:2:2 for "Accepted colorspace" in the codec config dialog before encoding. That way the codec will reject everything that is not YUV 4:2:2 when encoding.

Further, "VideoPad" from NCH rejects to load AVI's encoded with MagicYUV, regardless of the settings and FourCC's used.

You can find the Software here and test it yourself:
http://www.nchsoftware.com/videopad/index.html

I tried the software, and it loads MagicYUV encoded files perfectly for me.

Further, if the "UtVideo" Codec is also installed on W2K (SP4)/XP (SP3), then MagicYUV seem to "stutter" at Resolutions over 4K encoding/decoding Video. I noticed this with the UtVideo Codec Version 13.3.1 and believe it's the included DMO Module from UtVideo that causes Problems. When UtVideo is removed from the System, everything is back to normal with MagicYUV. Plus, MagicYUV co-exists fine with Lagarith and HuffYuv without any Problems.

That can happen. I also noticed, that the UtVideo DMO sometimes gets inserted to do needless colorspace conversion or even encode to Ut and then back (!) for no reason.

Speaking of UtVideo/VirtualDub and "v210" 10 Bit: Both produce Videos that can not (!) be played on OptiBase, AJA/Kona or DVS I/O Boards. The only Codec so far is the Drastic Codec that fully conforms to the Industrial standard and Definition for 10 Bit. So, if you plan to develop in this "10 Bit Playground", chances are that it won't work with professional Equipment.

The raw v210 AVI produced by the latest (!) VirtualDub conforms to the v210 spec (it was buggy with earlier VDub though!).
I also had someone test my codec with v210, and it played back fine.
But we can discuss/test more about this if you want.

Still not solved:
MagicYUV RC4 still reports "RGB24" to other Codecs with VirtualDub (Version 1.6.19 - 1.10.4) no matter how the Settings are with the "Fast Re-compress" and "Normal Re-compress" Modes. HuffYuv and Lagarith use the Color-space they encoded (YV12/YUY2) the Video with.

MagicYUV does the same, it reports the colorspace that was encoded. If it always reports RGB (despite all conversion options disabled in the "Decompression Settings"), then the encoded data has to be RGB.


Interlaced Mode with MagicYUV only takes the TFF (Top Field First) which is the same for all HD Modes, but in SD Resolutions for NTSC with BFF (Bottom Field First) the Image is distorted.

Yes, the codec assumes TFF for now.
There is actually no way of knowing if the input is TFF or BFF, but I can include an option for the encoder settings.
What I would like to know is what to do on the decoder side? So for example if I encode BFF, should I also output BFF when decoding? Or always TFF, regardless of the what was encoded (so to swap the fields)? I would need some help with this.

Thanks for the comments. The next release will have the notification icon, so you can check the colorspace, until then use the "Accepted Colorspace" option. Also, if we can get to it, I can get the TFF/BFF be included as well.

Greets,
I.

[zerowalker]

I would like the Encoder to have that Option of choosing TFF or BFF (it's kinda a must, if you use that feature to play interlaced video).
How to do it, well either swap fields like you said or do it the normal way. Do what's most efficient as the end result is the same:)

Thanks

[ChiDragon]

Alright, here's a stupid question: why does an intra-only lossless codec care whether the material is TFF or BFF?

[zerowalker]

To be able to decode and deinterlace on playback, i think?

[Ignus2]

OMG. That would make for a great "lossless" codec... ;)

The only real use case I could think of is to be able to always output TFF (or always BFF) by knowing what kind the input was (and swap accordingly).

Greets,
I.

[Mick]

Hi Ignus2,
to answer some of your replies:

"VideoPad":
It chokes on Files larger than 4 GB with MagicYUV and saving a MagicYUV encoded Video from VideoPad back to MagicYUV does not work all the time. I have a older version here which causes a lot of Problems with Videos encoded with MagicYUV and maybe this is fixed now in the newer Version of VideoPad. But MagicYUV is not alone, UtVideo causes the same Problems with VideoPad while HuffYuv and Lagarith work fine. I do believe it's because of the missing Interpretation of MagicYUV and UtVideo in the FFMpeg Libraries that VideoPad uses, but, that's only a guess of mine at this point.

"v210" Issue:
I tried loading v210 Videos on a DVS and AJA System, no chance with a very long loading period until the Error Message came up. With the Drastic Codecs the Videos are loaded with a blink of an Eye on PC, Workstation or Broadcast Systems. The Reason is that "v210" is a YCbCr Format and VirtualDub (1.10.4) saves it with a RGB Header so the Decoder is initiated for RGB Conversation on the Output.

The default is to stay in YCbCr, not to convert up to RGB. The UtVideo v210 (UQY2) does the same thing like VirtualDub and even if UtVideo is installed, "v210" (UQY2) can not be used on real Workstations or Broadcast Systems. Sure, PC is fine, but Workstations or Broadcast Systems, no chance with the UtVideo/VirtualDub v210 Format. The Format definition for "v210" and other 10 Bit Formats do not use any YCbCr to RGB conversations.

But this is another Story and we should talk about this in a new Thread, okay ? For now the fact stays, both v210 don't work with YCbCr Boards while the 8 Bit (4:2:2) Formats from VirtualDub and UtVideo cause no Problems, only with 10 Bit "v210".

Interlaced:
The normal behavior is, that if you encoded with "TFF" then the Video is decoded the same way, "TFF" and vice versa. Even if all HD Formats for PAL/NTSC are now TFF, in SD Resolutions you end up with a garbled content because the Field Order is wrong. Including a Option here would really solve this Problem. The classic SD DV Format for PAL/NTSC is such a candidate, which is always "BFF".

I still don't know how, but HuffYuv encodes/decodes with the correct Field Order, no matter if it's PAL/SECAM or NTSC. I checked the settings again and my VCR's use BFF for NTSC and TFF for PAL/SECAM. NTSC is only using TFF for D1 and PAL D1 when selected. When I select DV for PAL/NTSC then both are "BFF", fully conforming to the standards.

But there is also a "evil" Trap: Some simple USB Devices always use "BFF" because they are shipped with the NTSC Standard where other "better" USB Devices change the Field Order according to the Standard used. In other Words, if the User does not know the Field Order of the Device, it ends up to a "Trial and Error" thing.

The second "evil" Trap is the VCR used for Playback. Some VCR's switch the Field Order if the norm changes, others don't. Good example are simple European VCR's with NTSC Playback. With those VCR's the Field Order is not changed and the NTSC Video is played back as "PAL 60", a mix of PAL and NTSC with "TFF". More professional VCR's from JVC, Panasonic or Sony switch the Field Order for NTSC to "BFF" and back to "TFF" for PAL/SECAM.

Same as my Multi-Format Typhoon Board and AVP Video Mixer, the Field Order changes to the right Order and uses NTSC 4.43, not PAL 60 or NTSC-M. Again, HuffYuv encodes the YUY2 Materials with the right Field Order without changing anything. If it's not in the Source code, then it must be my Typhoon Board that takes care of this and would explain, why MagicYUV Material is distorted with NTSC and BFF if it only encodes "TFF" like UtVideo. BTW, NTSC with BFF is also distorted with UtVideo so you're not alone with this Problem, okay ;)

The "RGB" Output:
I am sure that it's not RGB and really YUY2 so that can be excluded. Plus, HuffYuv and Lagarith decode in YUY2 to Xvid (1.3.2) and x264 with no Problem. AviSynth reports YUY2 with HuffYuv and Lagarith when the Captures are opened with a Script where MagicYUV reports RGB24 with AviSynth (2.5.8). I never use RGB, only YUY2 and occasionally I420 or YV12 to avoid any color conversation.

So, that's quite a bit of Information for you and i hope this was helpful to you. Anyway, MagicYUV is a great Codec and i never seen a perfect Take-Off from a new Codec and it's normal that it takes some time until everything is how it should be.

Take care and keep up that great work, okay ? :)

Cheers

Mick

@ChiDragon
It also costs Quality by skipping one Filed or blending (De-interlace) them if the Source is interlaced, even with Lossless Intra-Frame Codecs. As you can't play any Lossless encoded Material on a DVD/BluRay you need to encode them to the final Format which is, right, interlaced, at least 90 % of it and would mean that you would have to either go down to a progressive resolution or re-interlace the Material with a huge loss of quality.

In Mastering Studios the default Rule is to uphold the Quality:
If it's interlaced, leave it interlaced.
If you used a Lossless Codec, stay with it until the Master is saved.
When the Lossless Master is done, then (!) encode it to the final Format.

[Ignus2]

Thanks for the detailed answer.

First of all, it would be best if you could send me a sample MagicYUV-compressed file, which reports RGB despite being compressed YUY2 for me to take a look at it.

The same goes for the interlaced thing. Can you send me a raw uncompressed sample, and the same encoded with HuffYUV and MagicYUV to show the problem?

There really is no other way for me to fix the problem, as I cannot reproduce it.

Greets,
I.

[Mick]

Hi Ignus2,
you can reproduce it very easy: Open VirtualDub and make a Capture. Once with the Option "Swap Fields" disabled and one with the "Swap Field" Option enabled, of course with MagicYUV as a compressor.

I look for a short Sequence that i can upload here that is not critical because i transfer Material from Company's and Broadcast Stations around the World and is meant for Archives, not for being used for Samples. I have a look and upload a short Clip in the next Days, okay ? It will be with MagicYUV RC4, just to let you know.

BTW, why did you change the minimum OS that for the newer Versions of MagicYUV ? Was there a specail reason for it ?

I can do that with the 2 Versions, HuffYuv and MagicYuv, but then you would need the HuffYuv Version i use, which is the 2.1.1 CCESP Patch 0.2.5 I attached to this post. I don't know if the installer will work on your System. Plus, the versions of HuffYuv included in ffdshow work differently to this version.

Cheers

Mick

[Ignus2]

Hi Ignus2,
you can reproduce it very easy: Open VirtualDub and make a Capture. Once with the Option "Swap Fields" disabled and one with the "Swap Field" Option enabled, of course with MagicYUV as a compressor.

Well, I have no capture card, so I cannot make a capture :)


I look for a short Sequence that i can upload here that is not critical because i transfer Material from Company's and Broadcast Stations around the World and is meant for Archives, not for being used for Samples. I have a look and upload a short Clip in the next Days, okay ? It will be with MagicYUV RC4, just to let you know.

I'm most interested in the YUY2 reported as RGB situation. You don't have any YUY2 material on your machine by chance?

BTW, why did you change the minimum OS that for the newer Versions of MagicYUV ? Was there a specail reason for it ?

Who said I changed? It was WinXP from the beginning (take a look at the homepage, I never mentioned Win2K) :)
Again, the fact that it worked with anything below WinXP was pure chance!

Greets,
I.

[Mick]

Hi Ignus2,
no Capture Card ? No Problem :) Open VirtualDub (1.10.4) and select under "Tools" the "Create Test Video" Option and scroll down the List to the one with "Top Field First" and afterwards the other one for "Bottom Field First".

Use MagicYUV as a Compressor and under "Color Depth" choose "4:2:2 YUY2" (YUVY) Color space instead of "Same as Input". This will give you a short Test clip which does the same like a Capture. As i wrote before, I look up some YUY2 Material and upload it here soon for you. You see, the Material I have is not meant for the Public at this point and is owned by the Company's or Broadcasters I do the Transfer for. Plus, I would violate my Contracts if I would load up something that's not mine.

Again, when I have a good Moment with Time, then I either make a short Clip or look up something that's not causing me any trouble about Copyrights, okay ? :)

Not to forget the Mystery: Why does HuffYuv and Lagarith report "YUY2" in the "Fast recompress" and "Normal recompress" Modes in VirtualDub to XviD (1.3.2) while MagicYUV reports "RGB24" to XviD with the same settings ? I tried Lagarith with YV12 and XviD compressed to YV12, just like the YUY2 Videos before.

And, if i was "lucky" with the RC4 on Win2K, which is also really meant for XP, could that be the Reason why MagicYUV reports RGB24 instead of YUY2 ? I doubt it from my point of view at this time because the RC4 Release never caused any Errors under Win2K (SP4) and worked fine.

Cheers

Mick

[Ignus2]

OK, the sooner you send the files, the sooner I can make the new release :)


Not to forget the Mystery: Why does HuffYuv and Lagarith report "YUY2" in the "Fast recompress" and "Normal recompress" Modes in VirtualDub to XviD (1.3.2) while MagicYUV reports "RGB24" to XviD with the same settings ?

I need a MagicYUV-compressed file which exhibits this behavior for you, otherwise I cannot answer this question, as it works correctly for me (and others as well), ie. reports the originally encoded colorspace correctly (YUY2 in case it was YUY2, etc.).


And, if i was "lucky" with the RC4 on Win2K, which is also really meant for XP, could that be the Reason why MagicYUV reports RGB24 instead of YUY2 ?

No. There has been no change regarding the algorithms and colorspace reporting between RC4 and RC5/1.0.

Greets,
I.

[kolak]

Hi Ignus2,
to answer some of your replies:


"v210" Issue:
I tried loading v210 Videos on a DVS and AJA System, no chance with a very long loading period until the Error Message came up. With the Drastic Codecs the Videos are loaded with a blink of an Eye on PC, Workstation or Broadcast Systems. The Reason is that "v210" is a YCbCr Format and VirtualDub (1.10.4) saves it with a RGB Header so the Decoder is initiated for RGB Conversation on the Output.

The default is to stay in YCbCr, not to convert up to RGB. The UtVideo v210 (UQY2) does the same thing like VirtualDub and even if UtVideo is installed, "v210" (UQY2) can not be used on real Workstations or Broadcast Systems. Sure, PC is fine, but Workstations or Broadcast Systems, no chance with the UtVideo/VirtualDub v210 Format. The Format definition for "v210" and other 10 Bit Formats do not use any YCbCr to RGB conversations.

But this is another Story and we should talk about this in a new Thread, okay ? For now the fact stays, both v210 don't work with YCbCr Boards while the 8 Bit (4:2:2) Formats from VirtualDub and UtVideo cause no Problems, only with 10 Bit "v210".



MagicYUV 10bit output was tested with many software- AE, Premiere, Edius, Nuke etc and it worked fine.

MagicYUV decoder output has been also tested directly with BM diretchsow filters and this also worked fine for v210 (also r210 format).

If you use Vdub to save v210 than set Color Depth (input/ output) to 10bit uncompressed and maybe later change fourcc so it's the same as AJA codec sets.

Aja control room won't load files which are not supported and magicyuv is definitely one of them. If you have AJA directshow filters installed than you can build a chain in graphedit and play 10bit magicyuv files (v210 or R10k) diretcly to AJA, like I have done to BM card. This should work fine.

If you want to capture directly to magicyuv at 10bit (422 or 444) with BM or AJA than this maybe possible soon :)
Please note that not many software can read 10bit from a codec through vfw or directshow, so 10bit pipe needs to be done through SDK or other ways.

You can always use vapoursynth to read magicyuv files and present them as fake uncompressed avi files through vsfs and these should work with eg. AJA control room.

[ChiDragon]

@ChiDragon
It also costs Quality by skipping one Filed or blending (De-interlace) them if the Source is interlaced, even with Lossless Intra-Frame Codecs.
I never mentioned deinterlacing. I was asking how the codec could care about field order.

My understanding is that the Interlaced modes of Huffyuv, Ut Video, and MagicYUV function like SeparateFields() -> compress / decompress -> Weave(). In that case, knowing the field order would be important if inter-frame compression were done. But since it isn't, it makes no difference if the assumed field order is wrong. All that matters is that the same assumption has to be made throughout.

Again, HuffYuv encodes the YUY2 Materials with the right Field Order without changing anything. If it's not in the Source code, then it must be my Typhoon Board that takes care of this
AVI has no way of flagging field order, so I think it must be your board.

[kolak]

AVI has no way of flagging field order, so I think it must be your board.

Yes, at leas no standard way.
Some manufactures do implement it using private AVI headers, but this is not a "standard" way. For example GV Edius software uses its own flagging and it works as long as you stay in Edius software (same for timecode).

[Mick]

@Kolak
thanks for the Information about v210 and just found out today that the AJA/Kona QuickTime for Windows Codecs decode v210 Videos from VirtualDub. The AJA/Kona QuickTime for Windows Codecs transform the YCbCr Source to RGB24 and save in RGB24 with a QuickTime Pro version.

I use the Drastic YCbCr Codecs for VfW and QuickTime. These Codecs stay in YCbCr and don't transform to RGB24 just like the Optibase and VideoPump Codecs, which is the normal behavior for YCbCr Systems. The Videos from VirtualDub (1.10.4) can't be played with the Drastic or OptiBase Codecs, not even with QuickTime. I don't know the Blackmagic Codecs and after reading your Reply, i do believe they work the same Way, YCbCr up to RGB, just like the AJA/Kona QuickTime Codecs do.

On the DVS HD Station and OptiBase Systems, which are pure YCbCr Systems, such Videos can't be used that where saved with the VirtualDub v210 Format while the Drastic and OptiBase v210 encoded Videos load instantly, even on the older AJA/Kona Systems.

So, one obviously has to make a difference here between Systems that only use YCbCr and others that always transform to RGB. I only work with YCbCr and pass that Material back to the Clients, unless they ordered a MPEG-2/MPEG-4 or Lossless Format after the transfer.

And the UtVideo v210 (UQY2) Codec does not work either with a installed UtVideo Codec Suite, only the other 8 Bit Formats from UtVideo. A Colleague of mine tested this for me on his DVS System and leaves the Question to me: Does one "really" need 10 Bit Codecs if the Format is going so many different Directions ? One Side says "YCbCr stays YCbCr" while the other Side says "YCbCr transforms to RGB".

I mean, one of the most used Formats in Mastering Labs is I420 12 Bit RAW (4:2:0) only because MPEG-2 and H264 see this as the default Standard and is most recommended to prevent unnecessary Color Transitions. Many Cameras use the same Color Space for MP4 and MTS Recordings and Color Transitions are not Lossless and can cost a lot of Image Quality.

If a Client of mine wants a 4:2:2 or 4:2:0 Format, then i stay with it until the end, means from Capture/Transfer over Editing to rendering the Final after Grading. If the Client wants a Lossless Format, HuffYuv for Example, then i stay with HuffYuv until the end of the Transfer, same with other Formats. MPEG-2/MPEG-4 comes at the very end, when the Master is finished and only if the Client wants a MPEG-2/MPEG-4 encoded Version.

This is one of the Basic Rules to uphold the Quality:
- Never change the Format until you're done.
- Never change the Codec.
- Once compressed, always compressed.
- Once Interlaced, always Interlaced.

@ChiDragon
You're right, it's my Typhoon Board that sets the correct Field Order when i change the TV Norm and HuffYuv encodes it that Way. But, why does MagicYUV have trouble with it ? "Ignus2" wrote, that MagicYUV is only conforming to HD Field Orders and they are all "Top Field First" for PAL and NTSC now. I still use Win2K Pro (SP4) and the last MagicYUV version that worked for me is RC4.

For me that is still the Riddle, why the captures with HuffYuv are clean and have the right Field Order while MagicYUV gives me a distorted and noisy Image with "Bottom Field First" Field Orders with NTSC 4.43 Formats. Don't get me wrong, i really like MagicYUV, great Codec, stable, reliable and fast, but at lower SD NTSC Resolutions not usable, only for Progressive Content, but no Client demanded Progressive Transfers so far.

I have to deal with Material from all over the World, all kinds of TV Norms where not even NTSC is a reliable "Bottom Field First" (DV/D1) Candidate and if a Client demands a "Lossless" Transfer, then I give them the Choice between HuffYuv and Lagarith. Those Clients either take HuffYuv or RAW YCbCr, Lagarith only occasionally. I would like to offer them MagicYUV too, but I simply can't at this point because the Image is distorted, even if those Videos are played back on other Systems with "Normal" Video Boards like Intel, ATI, NVidia and Matrox on newer Windows Versions.

So, somehow there must be a difference between HuffYuv and MagicYUV when it comes to Interlaced Material and how it's encoded internally because UtVideo suffers the same Symptoms and Problems like MagicYUV. Sure, i could load those captures with MagicYUV in VirtualDub and reverse the Field Order and encode it again with MagicYUV but, this makes it even worse, tried that already and did not solve the Problem.

@Ignus2
A Friend of mine tried MagicYUV (Final 1.0) with Windows 8.1 64 Bit and a USB Grabber who wants to Capture some of his old VHS Family Tapes, all NTSC. Result was, that he had the same Problem with MagicYUV because of the "Bottom Field First" from his VCR (Hitachi with S-Video) and VirtualDub (1.10.4). The Image was distorted and came clean when he used the De-Interlace Filter in VirtualDub during the Capture.

He gave me these Specs from the Manual for his USB Grabber over the Phone:
Resolution: 720x480 (Maximum)
Frame Rate: 29.970 Fps
Aspect Ratio: 4:3
Field Order: Bottom Field First
Color Space: YUY2 or I420 (Other not available)
Composite Video: Yes
S-Video: Yes
Audio: 48.000 kHz, 16 Bit, Stereo, PCM (Maximum)

His Idea was to capture the Tapes with a Lossless Codec to encode those later, after editing them, to a nice DVD for the Family. After I told him that Progressive Material works only on BluRays in HD well, he made the first captures in RAW YUY2, later in I420 upon my recommendation for a MPEG-2 DVD as he does not want a BluRay. HuffYuv still has no reliable Installer for 64 Bit Systems, Lagarith did not work for some Reason on his System, and ffDShow he found to "confusing" to use. Knowing he would have the same Problems with UtVideo, i did not mention UtVideo because it would have caused the same Problems.

So, i do believe it's a good Idea to include a Option for the Field Order in MagicYUV because there are many like my Friend in Florida out there that want to save the Family Moments for the digital Future. And at this Point I have a "Bullet Proof" Idea:

Why don't you include Profiles for SD Resolutions with the correct Field Order ? For Example, SD DV at 720x480 (NTSC) and DV at 720x576 (PAL), both with a fixed "Bottom Field First" ? All the User needs to do is to select the SD Resolution he wants and the correct Field Order is automatically set. HD is always "Top Field First", it's just some SD Resolutions that cause Problems when the Source is Interlaced and the User wants to save it Interlaced.

Just a Idea and in case you want to use it: It's free, okay ? ;)

Cheers

Mick

[Ignus2]

From the codec point of view, TFF or BFF doesn't make any difference at all. If we don't take in-codec conversions into account (true lossless mode), then whatever came into the codec as input when compressing, the output on decompressing will be EXACTLY the same.

That is why I don't understand what you experience by certain codecs getting the field order right, others wrong. None of the codecs have any way to know about the field order in VFW. But even if they did, it would make no difference at all, as they would still output exactly what they got (I refer to lossless codecs here).

Again, samples would help here, raw yuy2 material, compressed with both huffyuv, and magicyuv, and show where it is wrong or distorted.
And while we are at samples, don't forget the "always RGB reported" sample too.

I tried the VDub test videos, both TFF/BFF encoded with huffyuv(ccesp)/magicyuv/utvideo, then used avisynth to Compare() them, and the decompressed output from all of them were bit-equal (for the given TFF or BFF case).

Greets,
I.

[kolak]

The problem is not raw data, but container headers.
Codec has nothing to do with it, but application which saves avi file.
As it was said, avi has no standard way of storing field order, so it's all pure luck.

Maybe field order could be stored in 'codec data' same as matrix and than maybe it could work, thought I am not sure as reading software reads container data, not deep codec data.
It's all down to old avi container which is quite limited in this area ( same as it does not store timecode).

[kolak]

@Kolak
thanks for the Information about v210 and just found out today that the AJA/Kona QuickTime for Windows Codecs decode v210 Videos from VirtualDub. The AJA/Kona QuickTime for Windows Codecs transform the YCbCr Source to RGB24 and save in RGB24 with a QuickTime Pro version.

I use the Drastic YCbCr Codecs for VfW and QuickTime. These Codecs stay in YCbCr and don't transform to RGB24 just like the Optibase and VideoPump Codecs, which is the normal behavior for YCbCr Systems. The Videos from VirtualDub (1.10.4) can't be played with the Drastic or OptiBase Codecs, not even with QuickTime. I don't know the Blackmagic Codecs and after reading your Reply, i do believe they work the same Way, YCbCr up to RGB, just like the AJA/Kona QuickTime Codecs do.

On the DVS HD Station and OptiBase Systems, which are pure YCbCr Systems, such Videos can't be used that where saved with the VirtualDub v210 Format while the Drastic and OptiBase v210 encoded Videos load instantly, even on the older AJA/Kona Systems.

So, one obviously has to make a difference here between Systems that only use YCbCr and others that always transform to RGB. I only work with YCbCr and pass that Material back to the Clients, unless they ordered a MPEG-2/MPEG-4 or Lossless Format after the transfer.

And the UtVideo v210 (UQY2) Codec does not work either with a installed UtVideo Codec Suite, only the other 8 Bit Formats from UtVideo. A Colleague of mine tested this for me on his DVS System and leaves the Question to me: Does one "really" need 10 Bit Codecs if the Format is going so many different Directions ? One Side says "YCbCr stays YCbCr" while the other Side says "YCbCr transforms to RGB".

I mean, one of the most used Formats in Mastering Labs is I420 12 Bit RAW (4:2:0) only because MPEG-2 and H264 see this as the default Standard and is most recommended to prevent unnecessary Color Transitions. Many Cameras use the same Color Space for MP4 and MTS Recordings and Color Transitions are not Lossless and can cost a lot of Image Quality.

If a Client of mine wants a 4:2:2 or 4:2:0 Format, then i stay with it until the end, means from Capture/Transfer over Editing to rendering the Final after Grading. If the Client wants a Lossless Format, HuffYuv for Example, then i stay with HuffYuv until the end of the Transfer, same with other Formats. MPEG-2/MPEG-4 comes at the very end, when the Master is finished and only if the Client wants a MPEG-2/MPEG-4 encoded Version.

This is one of the Basic Rules to uphold the Quality:
- Never change the Format until you're done.
- Never change the Codec.
- Once compressed, always compressed.
- Once Interlaced, always Interlaced.


Why don't you include Profiles for SD Resolutions with the correct Field Order ? For Example, SD DV at 720x480 (NTSC) and DV at 720x576 (PAL), both with a fixed "Bottom Field First" ? All the User needs to do is to select the SD Resolution he wants and the correct Field Order is automatically set. HD is always "Top Field First", it's just some SD Resolutions that cause Problems when the Source is Interlaced and the User wants to save it Interlaced.

Just a Idea and in case you want to use it: It's free, okay ? ;)

Cheers

Mick

Well- if you want to use any v210 codec just to have data decoded to 8bit (YUYV or RGB) than there is no point to have this 10bit in first place. Idea of v210 is that reading application plugs in into raw 10bit data, so there is no need for codec. BM, AJA, Drastic codecs exist only to enable people to play v210 files in "home" users players. For professional use you want applications which read this 10bit data directly/natively.
And yes, if you want this to be decodec to 8bit, than use codec which stays in YUV- going to RGB is bad.

MagicYUV 10bit data will be decoded back to v210 (or r210/R10k) depending if the source was 10bit 422 or 444. There is no colorspace conversion for 10bit implemented as far as I know, so you will never get 10bit decoded to RGB data (at least not now).

Your idea about presets for SD with predefined field order probably won't work.
When you drag avi file to eg. Premiere it looks for header informations (container info not actual codec) which it does understand and one of them is field order. Adobe uses its own flagging (different then eg. GrassValey) for avis, so when you use avi files from some other software than Premiere this info does not exist. Premiere will assume some field order (maybe the one which project is set to). You can overwrite it in file properties and this is what you should always check- if source file is interpreted properly. Avis are poor with metadata, as there is no standard for storing all these additional information eg. filed order, timecode etc. This information is a container info set by the writing application, not actual codec data. FFmpeg was/is also famous for not flagging ProRes MOV files as interlaced (and some other metadata), but yet again this is not a ProRes codec problem, but ffmpeg (MOV headers). Ffmbc, which is used by BBC has this fixed :)

Ingus2 can add this info into "codec data" based on user choice, but I'm not sure if this will help.

Solution is simple (well not for magicyuv)- use MOV or MXF container which have standard ways of storing all metadata, so all software can understand and read it properly, This is the difference between broadcast solutions and "home" solutions. Broadcast app will rather always set these metadata and that's why 75% of them use MOV or MXF as containers. AVI is not used much at all because of poor metadata support and problematic support for higher bit depths.

[Mick]

@Ignus2
i did not forget about the Samples, just very busy at this point, that's why i haven't done it yet. Very interesting about your comparison of HuffYuv/MagicYUV and UtVideo. Well, if they are "Bit Identical", even with Interlaced Material, where could be the Problem ? My Typhoon uses a "Strict Header" for the AVI's and switches the Drastic Codecs from Top Field to Bottom Field for NTSC Material and back to Top Field for PAL/SECAM. Could that have something to do with it why MagicYUV and UtVideo cause such Problems ?

The native Windows Codecs for I420, IYUV, UYVY, YUY2 and YVYU use a DE-interlacing Routine to Weave both Fields together on Playback because they where designed for PC use. The Drastic Codecs don't and stay Interlaced, what i can control on my connected Sony Multi-Norm Television Set and my other Monitors.

@Kolak
The Drastic Codecs offer v210, 012v and auv2 for 10 Bit YCbCr for Compression and Decompression along with all the other 8 Bit Formats for VfW and QuickTime for Windows, means, i can setup my Board for 10 Bit and capture or transfer this way without any transcoding. But so far no Client wanted 10 Bit, only 8 Bit 4:2:2 or 8 Bit 4:2.0 in YCbCr for the Transfer or Lossless HuffYuv/Lagarith and very seldom Motion JPEG 2000. I don't know the Black Magic Codecs and never tried them, only the ones from AJA for QuickTime which transcode under QuickTime for Windows YCbCr to RGB24 and from that what i've been reading the Black Magic do the same thing.

About my "SD Presets" Idea:
Makes Sense what you wrote and was just a Idea. If the Lossless Codecs are Bit Identical, no matter if TFF or BFF is used, then it makes no sense in offering such Option. As i wrote earlier, my Typhoon uses a "Strict Header" for the AVI's and i can Imagine that has something to do with it. My Aist/Cinegy Moviepack Pro works the same Way like Adobe, at least from my Time back with Premiere 6.5, and correctly reads the Field Order from Transfers or Captures from my Board.

About AVI/MOV/MXF Containers:
I only have 3 Clients that demand YCbCr MOV Files, all the others are always asking for AVI, believe it or not. We are talking about Company's and TV Stations from around the World, big and small ones, not any private "John or Jane Doe" in the Neighborhood. Further, almost all Clients want the Captures or Transfers on Hard Disk in YCbCr or Lossless. I even have some, that wanted the Transfers in 2GB Slices but no one ever wanted MXF, makes me wonder.

Anyway, up to this Day, never a Reclamation or complain from any of my Clients because they tell me what and how they want it and that's what they get back along with the Material they send me via Parcel Service.

I know that AVI is not the "Ideal" Container Format but the Clients demand for AVI's is still very high and plays the major Role. My best guess at this point is, that they do the Rest themselves when i send them the Hard Drives back. One thing they all have in common: They want the best Quality, either YCbCr or Lossless. Going by that, I do believe that the AVI Container is not so easily replaced by better ones in the near Future.

Cheers

Mick

[kolak]

Sorry, but you are the first person who talks about avis used in broadcast.
I don't mind avi, as long as headers info is passed between apps.
MOV has its own problems also ( some very annoying), where MXF can be over complicated.
When I worked at DVD/BD authoring house my workflow was setup over avisynth and avis, but it was very different compared to other places. Every delivery related to broadcast was never done with avi files. Now I work for big VFX house and it's the same- no one asks about avi as delivery option. It's all done as DPX, v210 Mov, ProRes, AVC-I 100 or legacy SD 50mbit mpeg2.

V210 and 012V is the same thing. It's about little v big endian coding.

[rec]

Hello Ignus2,

I tested MagicYUV and it's great! I love it. I do have a request, though. Files encoded with MagicYUV don't show thumbnails in Windows. Is there any solution for this problem? Suggestion: Some third party thumbnail generators work via FFMPEG. Have you considered getting the FFMPEG people to incorporate MagivYUV? I know they did it with UT.

Thanks again for this great codec.

[zerowalker]

He is at some point from my understanding. But it's going to be some kind of closed source release that they can work with.

[Mick]

@Kolak
i can only tell you what my Clients demand when they send me Material along with the Paperwork (Technical Riders) and that's AVI. Maybe it's because it's mostly SD Material from Tapes that I get.

@Ignus2
Well, you're ready ? Here are the Test clips you wanted with kind permission of Polygram Video for private use only (!). Captured from a Sony VCR with VirtualDub (1.10.4), no Filters, straight once to HuffYuv and again with MagicYUV, means, no Transfer from HuffYuv to MagicYUV for example. In VirtualDub i cut out the same Sequence for both Videos after the Capture and used the "Direct Stream Copy" for Video and compressed the Audio from PCM to MP3. I also included Screen Shots of my Settings for HuffYuv and MagicYUV.

Technical Rider:
Color Space: YUY2
Format: NTSC 4.43
Resolution: 720 x 480
Field Order: Bottom Field First / Lower Field First (Even Field)
Pixel Type: Square
Frame Rate: 29.970 Fps
Audio: 48.000 kHz 16 Bit Stereo (MP3 Compression 192 Kb/Sec)

You have to uncompress the Videos with 7Zip (9.20). The HuffYuv Video is called "HfyuTest.7z" (HfyuTest.avi) and the MagicYUV Video is called "MagyTest.7z" (MagyTest.avi).

Further, to make sure the Drastic YCbCr Codecs are not causing this Problem, i did the same Capture on my Laptop with a PCMIA Capture Card using the native Windows Codecs. The Result was the same so the Drastic Codecs are fine on my Workstation and don't cause this Problem with MagicYUV.

I hope this was helpful to you and now you can see it for yourself what i mean. So, it's obvious that the Field Order does matter, even with Lossless Codecs. ;)

Cheers

Mick

[Mick]

@Ignus
I tried to uploading the two Videos but Doom kicks me out every time and cancels the Upload. I have to look for a File-sharing Server and link them from there to Doom for Download. Both Files are less than 200 MB each. Sorry for that but could not find a Solution for this Problem now.

Cheers

Mick

Correction: Found a Solution. You can find the Download Link in my last Post :)

[kolak]

I hope this was helpful to you and now you can see it for yourself what i mean. So, it's obvious that the Field Order does matter, even with Lossless Codecs. ;)

Cheers

Mick

It doesn't. As long as pixel format is the same as source decoded video will be 100% the same. It can go wrong when your video is stored as yuv, but you want rgb output, but I assume this is not the case here.
Field order is just a metadata. Lossless codec works like zip or rar. Did you care about field order when you zipped your files?

Your issue is not related strictly to codec itself, but more to container and whole workflow. Maybe there is a way of fixing it, but it won't be related to changes in actual encoding algorithm.
Here is atest for you.
Get some interlaced source file, compress to magicyuv keeping original pixel format. Than load both file to eg. Premiere ( we assume codec sends original pixel format), interpreate field order for both and apply difference filter. Do you see any difference?
Yet again, your issue are headers/metadata. It's a seperate issue, but maybe Ingus2 can do something to improve it.

[Mick]

@Kolak
I mainly work with Interlaced Content for my Clients, but you can see this now yourself, just download the Videos then you see what i mean :) Anyway, normally this should not matter, but somehow it does with MagicYUV. All Settings for Capturing and saving the two Videos where exactly the same. Plus, why should I write something that is not true ? I'm just trying to help the Author of MagicYUV and it's obvious that there is a Problem when it comes to NTSC with BFF instead of TFF. And yes, My NLE triggers the right Field Order with HuffYuv but not with MagicYUV and when i set the Field Order manually for MagicYUV, then the Image is still distorted and Jitters on Playback. I get the same distortion and Jitter if i set HuffYuv to the wrong field order and no, i don't want RGB when i work with YCbCr. :) Thanks anyway for your informative Reply's ;)

@Ignus2
Here is the Link to download the 7Zip packed AVI's that I mentioned earlier. If you can find the Problem or the cause, let me know, okay ?

->Wetransfer Link expired<-

Cheers

Mick

P.S.: Just checked the Link and worked. Please note that "Wetransfer" will remove the Videos from the Server in the next 7 Days from Today on, so they won't be available forever.

[kolak]

Do I have to login?
There are no files there.
Put it on https://www.wetransfer.com and share download link.

So you can't set field order manually to have proper playback?

Maybe issue is with the way how data is passed to codec or eg. specific frame size.

Does the data match uncompressed one? If it does than it's some even different issue.

You can also compare them in avisynth:

a=avisource(uncompressed.avi)
b=avisource(magicyuv.avi)
compare(a,b)

Pixel format have to be the same for both files. PSNR should be something like 114dB if they are identical.

[Sparktank]

P.S.: Just checked the Link and worked.

Not that I'm interested in checking the files out, just the link.

It shows up blank on my end.
It probably works for you since you're signed into your own account.

What I see. (click to open in new tab in full size)
http://i.imgur.com/8gWK95Vs.png (http://imgur.com/8gWK95V)

[Mick]

@Kolak
No, you don't have to Login :) Yes, i can set the Field Order manually in my NLE, for Import, Capture, Playback and Export. I made the Captures with VirtualDub (1.10.4) directly from my VCR, not with my NLE without any Filters or other modifications. Many thanks for the Hint with "Wetransfer" :) I uploaded the Files there.

@Sparktank
Sorry, Ge.tt somehow is overloaded at the Moment and a new Link through "Wetransfer" is available now :) Plus, it's no Problem if you want to check the Files out.

@Ignus
The new Link for the Videos:
->Download Link expired<-

Both Files are packed with 7Zip (9.20) so you need to unpack them first befor you can watch them. The Download Link is good for 7 Days from Today on and then deleted according to "Wetransfer", so download them soon :) The Download contains both Videos, about 320 MB total.

Cheers

Mick

[ChiDragon]

Well, I see the problem in your sample. But if I recompress your Huffyuv file with MagicYUV in Interlaced mode, there is no difference between them. Win2K issue?

Files encoded with MagicYUV don't show thumbnails in Windows.
Mine do on Win7 x64 (and Huffyuv files don't, for me).

[kolak]

There are some capture problems with your files. Are they captured from DV or digibeta? They are 480, shouldn't they be 486?

One is upper field, other is lower, but this is not the real problem.
If you interpret huffyuv as lower and magicyuv as upper than fields are aligned, but there is 2 pixels vertical shift. Even after this shift is adjusted videos still don't match 100%. It there are cropping going on at some point in your capture chain? Is it a crop from 486?

At the moment answer is (if huffyuv matches DV or uncompressed capture): magicyuv does not work with your capture solution.
How was it captured? Why video is shifted vertically? Magicyuv will losslessy compress whatever it gets on input, so something is happening before video hits codec.

If you feed magicyuv with correct input data than it won't do anything to it and in this case filed order is just a metadata and can be manually changed.

I don't see any field info stored in neither of them and when I drag files to Edius than they are both interpreted as Lower Field, as per projects settings. Because Edius does not see any info about field order which it can understand it applies order set in project settings, so both files behave exactly the same.

There may be soon professional capture solution which will work with BM, AJA and some other cards with direct capture to magicyuv (including 10bit). It won't be based on vfw or diretchsow, as these are not very reliable technologies and not used in pro solutions.

I don't know what to suggest- try other way of capturing when using magicyuv? Fact that huffyuv works fine (if it really does) does not mean solution is reliable. Your problem does not really prove any problem with magicyuv codec itself, but it does not mean that there is no problem at all neither.

Ingus2: what does happen if magicyuv get file with eg.483 height and it's in YUY2 mode? Is it passed as is?

ps. I can't register 32bit huffyuv codec (64bit is fine), anyone knows why?

[Ignus2]

Thanks for the videos. I would have needed raw uncompressed YUY2 too as reference. Can you capture that as well?

This way I can only tell, that the input for the two codecs was different. The codec compresses what it gets, and neither huffyuv, nor magicyuv does any shifting around to the fields by default.

So this way I can only say, that most certainly the two cases are not equal, the codecs get different data. The question really is why?

Also: I looked at the fields with VirtualDub deinterlace filter and used "Duplicate fields" and "Double Framerate TFF/BFF" then single stepped and verified the following:
- The huffyuv coded sample is BFF and spatially correct
- The magicyuv coded sample is indeed TFF (the top field is really the first TEMPORALLY!) but spatially incorrect, the fields are swapped.

I'll do some more analysis of them in the evening.

@kolak: 483 height YUY2 passed as-is, just like anything else. If interlaced is ticked however, it is rejected (cannot compress). Only even height material is accepted as interlaced.

Greets,
I.

P.S.: @Mick: Some questions out of interest: Why do you have RGBA compression enabled and decompression as YUV 4:4:4 all enabled? Do you have special need for these? As normally turning these on just cause trouble.

[kolak]

Field order swapping may be related to specific capture device- huffyuv has a special setting which allows to swap fields.

There is clearly some issues between capture hardware/software and codec. That's why for pro use you need verified and more closed solutions which don't break because, eg you have installed ffdshow filter :)

[Mick]

@ChiDragon
The HuffYuv Capture is how it comes from my VCR's, BFF for NTSC, that's why MagicYUV compresses it fine but also makes me wonder. Why does it not work that Way with a direct Capture to MagicYUV or UtVideo without being distorted ?

The MagicYUV Capture is TFF on Playback instead of BFF and my VCR's use BFF for NTSC 4.43 and from what I understand, TFF is the default Field Order for MagicYUV and UtVideo because all Interlaced HD Material is now TFF, no matter what TV Norm. Somehow HuffYuv encodes this different to MagicYUV and UtVideo, how, I don't know at this point.

It can't be a Win2K Issue because the same thing happened with XP (SP3, 32 Bit) and Win7 (64 Bit). My Friend in Florida reported the same Problem to me over the Phone when he asked me for my advise, also NTSC from a Hitachi VCR with S-Video and changing the Input from S-Video to Composite did not change anything either with his KWorld USB Grabber.

@Kolak
I used 720 x 480 without Scaling or Cropping conforming to the NTSC DV Standard except instead of "Non Square" i used "Square" Pixel for the Capture because "Non Square" would only be Important for a straight DV Capture with Firewire (IEEE 1394 or iLink). D1 NTSC 720 x 486 I only use with my Capture Module from my NLE and only if demanded. Plus, some 486 Material can be TFF instead of BFF, the Aurora Igniter D1 Board is such a Candidate that uses TFF for D1 NTSC.

The Material was Captured from a VCR (S-VHS) and S-Video. I tried my Sony's, JVC's and Panasonic's, all the same. Then i used a PCMIA Capture Card and a older USB Grabber on my Laptop, just to make sure that it's not my Typhoon Board. Further, i used the default native Windows Codecs and VirtualDub (1.10.4) to exclude that the Drastic YCbCr Codecs might be responsible for this and I'm glad to say they're not.

Using the Composite Input did not make a difference, except a lower Quality. Again, this was a straight Capture, twice the same, directly once to HuffYuv and once again to MagicYUV, no Filters, straight from the VCR's to the Devices to the Codecs, no Mixing Console. I used the Direct Show Drivers for the Devices and checked it back by using the WDM Capture Interface in VirtualDub, no difference, same result. Plus i tried the same Setup with the UtVideo ULY2 Codec (13.3.1) and the captures where the same like MagicYUV, distorted with Jitter.

I used the same Settings for both Codecs in VirtualDub and after both captures, i opened them in VirtualDub, selected the same Sequence in both captures and saved them via "Direct Stream Copy" from VirtualDub to the final Files i Uploaded to "Wetransfer". BTW: Thanks for the helpful Tip ;) Only the Audio was compressed from PCM to MP3 to save some Space, the rest is untouched and is really as it came from the Capture from the VCR for both Files. "ffdshow", "Matroska", "Haali", "Morgan" or other additional Filters are not installed on my Systems, so this can be excluded as well ;)

@Ignus
I left the Settings for MagicYUV to their defaults, except "Interlaced" and "RGBA". Disabling the "YUV 4:4:4" and the "RGBA" Options never changed anything, never caused any Problems when left on and when i load the Captures or Transfers in my NLE, then i often use Titling that uses the Alpha Channel for Blending, would not work without this Option enabled and always worked with HuffYuv.

I can upload some pure YUY2 but I would have to shorten it a bit and leave the Audio out, if you don't mind, to keep it "downloadable" to a reasonable Size. Anyway, i make it available again over "Wetransfer" soon, not today because last Night was long enough :)

So, from my Point of View i can exclude:
- My Typhoon Board and Workstation because it was the same on my Laptop with Intel Chipset and Graphics
- The Drastic YCbCr Codecs because i used the default native Windows Codecs from DirectX9 (latest Version 904)
- My Aist/Cinegy MoviePack Pro because I did not use it and used VitrualDub for capturing/saving the Samples
- The Direct Show and WDM Drivers, same Result
- My VCR's because the Image did not change by changing them
- My PCMIA or other USB Grabbers, same Image
- Even with my old Dazzle DVC100, same thing
- Changing the Resolution from 720 x 480 down to 704 x 480 or 640 x 480 had also no effect, same thing
- Same Result with other Devices from AFA, Empia, Typhoon, QSonic, Logitech and SynTech

I really hope this was helpful to you and could you please notify the Author of "UtVideo" that his Codec has the exact same Problem like MagicYUV ? Believe me, I tested really hard to exclude everything that could cause this Problem and at this point, i really don't know what it could be. All I know is, that HuffYuv does it right, why and how I don't know.

Again, as long as the Field Order is TFF for PAL/SECAM and Interlaced HD Resolutions, MagicYUV and UtVideo work fine, just like HuffYuv, but as soon as the Content is BFF on the Input the Problem arises with MagicYUV and UtVideo while HuffYuv stays "clean".

Ignus2, keep that great work up because MagicYUV is really a very good Codec and hope you find the Problem, so hang in there and have another look in the Source Code, maybe you overseen something ;) So, that's all what I can do from my end and as I was "lucky" with RC4 I won't benefit from a new Release that fixes this Problem, which is okay, don't worry, I can live with it and I'm glad to help you out :)

@All
Many thanks to all of you for the fantastic Reply's in this Thread :)

Cheers

Mick