Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > New and alternative video codecs

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th October 2014, 22:20   #221  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 6th October 2014, 22:42   #222  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
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.

Last edited by Mick; 6th October 2014 at 22:58. Reason: Included Reply to User "ChiDragon"
Mick is offline   Reply With Quote
Old 6th October 2014, 22:54   #223  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 6th October 2014, 23:15   #224  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
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
Attached Files
File Type: zip HuffYUV.zip (72.5 KB, 20 views)
Mick is offline   Reply With Quote
Old 6th October 2014, 23:30   #225  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Mick View Post
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

Quote:
Originally Posted by Mick View Post
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?

Quote:
Originally Posted by Mick View Post
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 7th October 2014 at 07:56.
Ignus2 is offline   Reply With Quote
Old 7th October 2014, 22:06   #226  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
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
Mick is offline   Reply With Quote
Old 7th October 2014, 22:33   #227  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
OK, the sooner you send the files, the sooner I can make the new release

Quote:
Originally Posted by Mick View Post
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.).

Quote:
Originally Posted by Mick View Post
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 8th October 2014, 15:29   #228  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,346
Quote:
Originally Posted by Mick View Post
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.

Last edited by kolak; 8th October 2014 at 17:18.
kolak is offline   Reply With Quote
Old 8th October 2014, 18:04   #229  |  Link
ChiDragon
Registered User
 
ChiDragon's Avatar
 
Join Date: Sep 2005
Location: Vancouver
Posts: 610
Quote:
Originally Posted by Mick View Post
@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.

Quote:
Originally Posted by Mick View Post
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.
ChiDragon is offline   Reply With Quote
Old 8th October 2014, 18:26   #230  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,346
Quote:
Originally Posted by ChiDragon View Post

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).
kolak is offline   Reply With Quote
Old 9th October 2014, 00:34   #231  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@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
Mick is offline   Reply With Quote
Old 9th October 2014, 07:04   #232  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
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.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...
Ignus2 is offline   Reply With Quote
Old 9th October 2014, 09:27   #233  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,346
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 is offline   Reply With Quote
Old 9th October 2014, 10:31   #234  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,346
Quote:
Originally Posted by Mick View Post
@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.

Last edited by kolak; 9th October 2014 at 10:41.
kolak is offline   Reply With Quote
Old 9th October 2014, 22:57   #235  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@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

Last edited by Mick; 9th October 2014 at 23:08.
Mick is offline   Reply With Quote
Old 10th October 2014, 01:23   #236  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,346
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.
kolak is offline   Reply With Quote
Old 10th October 2014, 04:43   #237  |  Link
rec
Registered User
 
Join Date: Oct 2007
Posts: 66
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.
rec is offline   Reply With Quote
Old 10th October 2014, 05:01   #238  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
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.
zerowalker is offline   Reply With Quote
Old 10th October 2014, 22:01   #239  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@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
Attached Images
    
Mick is offline   Reply With Quote
Old 10th October 2014, 22:29   #240  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@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

Last edited by Mick; 10th October 2014 at 23:43.
Mick is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 10:15.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.