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 27th June 2015, 21:25   #361  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@De-M-on
I am not talking about the normal NLE's here, I am talking about real Workstations based on Ingest Systems, not comparable with Adobe or other typical NLE candidates. These Guys work in Hollywood for the "big ones", other for big Film Studios and Company's around the World transferring and coding Material, do I need to say more ?

@Ignus2
Again, the Tests where NOT done with VirtualDub, my Colleagues monitored the same behavior on their Workstations, leave VirtualDub out at this time. Somewhere must be a Field-Bug if HuffYUV does it right and MagicYUV and UtVideo don't, right ?

So, let's cool down and I ask my Friends if they have a detailed Report and if so I publish it here, okay ? Maybe this clears this Mystery, Deal ?

Cheers
Mick
Mick is offline   Reply With Quote
Old 27th June 2015, 21:35   #362  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Mick View Post
@Ignus2
Again, the Tests where NOT done with VirtualDub, my Colleagues monitored the same behavior on their Workstations, leave VirtualDub out at this time. Somewhere must be a Field-Bug if HuffYUV does it right and MagicYUV and UtVideo don't, right ?

So, let's cool down and I ask my Friends if they have a detailed Report and if so I publish it here, okay ? Maybe this clears this Mystery, Deal ?
It probably won't unless you thoroughly understand what the real problem is (reverse field dominance and field swap) and are willing to invest the time to investigate it.

EDIT:
Again: the codecs cannot by their nature affect field dominance. So the problem you see is beyond the codecs.
Also, I think it's simply not professional to make claims (like this is faster than that) and then not being able to present supporting reports/evidence to back it up.

Greets,
I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 27th June 2015 at 21:42.
Ignus2 is offline   Reply With Quote
Old 28th June 2015, 04:24   #363  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,181
Quote:
Originally Posted by Mick View Post
@Ignus2,
HuffYUV offers a Option to switch the Field Order if it got upside down. I don't know either why HuffYUV works with both Field Orders but it is Important because there was never a real standard for this, besides PAL/NTSC SD DV that is always BFF and PAL/NTSC HD which always uses TFF.
"At the mouth of two or three witnesses...."

http://forum.videohelp.com/threads/2...=1#post1379263

Quote:

"HuffYUV encodes interlaced and progressive frames exactly the same. So it doesn't need to know if the frames are interlaced or progressive. The "swap fields" option is only there to correct a bug where some old cards captured with the scanlines swapped -- it isn't to be used to specify field order"

Plain enough.
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 28th June 2015 at 04:35.
WorBry is offline   Reply With Quote
Old 28th June 2015, 12:20   #364  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
Quote:
Originally Posted by Mick View Post
"MagicYUV" and "UtVideo" are good lossless Codecs, no doubt, but "HuffYUV" still rules for SD/HD/UHD Content and "Lagarith" for SD with YV12. Many Colleagues of mine around the World in Mastering Labs tested MagicYUV and UtVideo with the result that they stay with HuffYUV (CCESP Patch 0.2.5/MT and 2.1.1 64 Bit). They found MagicYUV and UtVideo "interesting" but not for professional use for Mastering.

In Short:
MagicYUV and UtVideo can get painfully slow on decompression if Dolby Surround, Digital (5.1) or DTS is added. Encoding with MagicYUV and UtVideo can end in a "freeze" for several Seconds if 2K is used and both freeze fast with higher Resolutions than 4K. Tested on 32/64 Bit Hig-End Systems and 32/64 Bit Codec Versions.

With HuffYUV never a Problem and BTW, HuffYUV uses much less CPU than all the other lossless Codecs while encoding/decoding Videos. (32/64 Bit Versions)

Here you can compare yourself:

Codec Setups:
https://yadi.sk/d/9NzZJc3Hcumhx

Test Videos: (A short Sequence with kind permission of PolyGram)
https://yadi.sk/d/X5r8s7HVcurL6

The Test Videos are in NTSC SD DV with BFF (Bottom Field First). You will notice that HuffYUV has the best Field Separation and is clearer than Lagarith. MagicYUV and UtVideo could not handle this Field Order, only TFF (Top Field First).

TFF = Odd/Upper Field first
BFF= Even/Lower Field first

Please note that the Videos have the same Sequence/Length and uses the same Settings inside the NLE to get a reliable Result for comparison.

The "To-do" List for MagicYuV and UtVideo:
The "Chroma" Problem
The Gamma Problem with QuickTime (Win uses 2.2, MAC 1.8)
The Field Order Problem (only the "Top Field" is considered)
Both Codecs don't support RAW-VBI
Dual Image 3D not well supported

UtVideo: v210 leaves a Black/Green Screen and stutters inside professional NLE's with a YCbCr Card and plays only the first 10 Frames before the Playback freezes inside the NLE's.

I do believe that both, MagicYUV and UtVideo can be a excellent choice if some Issues are finally fixed by the Authors.

@Ignus: You still have unread PN's, please read, just trying to help, okay ?

Cheers
Mick

Your problem is that your are trying to use codecs in ingest systems, which were never tested with them. This is most likely to have many problems. Just stick with uncompressed capture or get something which is tested if you want reliability. You are trying to match some legacy/quite strict systems with custom made codecs. If you want this than talk to Drastic- they can make you proper integration in MediaNXS. You mentioned Cinegy- it's enough that their system doesn't support pixel format which magicyuv requests, so if there is a need for some conversion (and this conversion is not optimised) you end up with big penalty in speed. Talk to Cinegy. Problem with pro systems is that they are very limited, but this is due to reasons. If there is one bit more open than don't expect it to work perfectly with all codecs out there. Maybe Cinegy did some work to make HuffYUV working well. Cinegy won't talk to magicyuv directly but through e.g. vfw. This is not what you want in pro system.
MagicYUV is veeeeery fast and you can easily build 4K ingest system on low spec machine, but this requires proper integration on low level (over SDK)- not over QT or vfw/diretcshow.
MagicYUV is the only codec which can natively take 10bit YUV/RGB based pixel formats used by BlackMagic and AJA cards and compressed them. This is 100% reliable and than the same can be done on the decoding stage, so you end up with 100% same data. Any problems with field order, chroma conversion etc are bit different story.

Pro companies don't touch these sort of codecs- they work with DPXs, v210 etc, so not sure who are your colleagues around the world. Sometimes they use compressed formats, mainly ProRes these days, but this is over properly integrate systems, so they never end up with problems like yours.
If you really want to use losses codecs try talking to James at Drastic or with someone at Cinegy.

Last edited by kolak; 28th June 2015 at 13:40.
kolak is offline   Reply With Quote
Old 29th June 2015, 21:23   #365  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@WorBry
Quote:
"HuffYUV encodes interlaced and progressive frames exactly the same. So it doesn't need to know if the frames are interlaced or progressive. The "swap fields" option is only there to correct a bug where some old cards captured with the scanlines swapped -- it isn't to be used to specify field order"

This Statement is simply wrong because HuffYUV considers more than 288 Lines as Interlaced. For Progressive Content like 1280x720 this needs to be set to 720 instead of 288. Did you ever read the Codec Description ? And the "Swap Field" option is for broken Capture Drivers ONLY (!) that use the Field Order upside-down. Checking this Option corrects this behavior.

Quote:
"At the mouth of two or three witnesses...."

This Statement is simply sad, very sad, no further comment....

@kolak
I use the Drastic YCbCr Codecs now for a long time and i know the Guys at Drastic and Cinegy well, don't worry about that.

Quote:
"Pro companies don't touch these sort of codecs- they work with DPXs, v210 etc, so not sure who are your colleagues around the world."

I use RAW (Uncompressed) just like my Colleagues and it is irrelevant here who my Friends are, they lift the Leg with the Big Guys, are well known, often credited in Movies and I certainly don't publish their Names here. Some use lossless Codecs for different purposes. No hard feelings, okay ?

@Ignus2
Quote:
"It probably won't unless you thoroughly understand what the real problem is (reverse field dominance and field swap) and are willing to invest the time to investigate it. Again: the codecs cannot by their nature affect field dominance. So the problem you see is beyond the codecs."

I do understand the Problem very well and the Solution to it, don't worry. The Codecs can't AFFECT (!) the Field Order, right, but the AVI Container does. I suggest you get the Whitepapers for the AVI Container Format where everything is clearly defined and explained.

AVI1 (VfW) does NOT save the Field Order and is limited to 2GB, AVI2 (OpenDML) DOES save the Field Order and I work and transfer with OpenDML and my Capture Module from Cinegy uses this Information written in the AVI2 Header.

Quote:
"Also, I think it's simply not professional to make claims (like this is faster than that) and then not being able to present supporting reports/evidence to back it up."

Okay, now read closely: This is something what my Colleagues and me monitored. I've spent hours on the Phone, my Workstation and invested my Money and my Time being apart from my Family trying to help you to share what I found out.

And now you're sort of saying that I am a stupid Idiot ? Well let me tell you that I am doing this for a long Time for major Company's and TV Stations around the Globe, I am not a "newbie" in this Field and if this is your way of saying "thank you", well bless you too.

Go on, keep ignoring facts and be happy to have the "fastest" codec around but I am out at this point. I thought Doom9 was different, until today. I've sent you everything backed up with Links to the Web in your PN, many times and most of them you never read. I suggest you don't ask for help or suggestions next time you work on a Project like "MagicYUV".

And once again: It was NEVER my Intention to make "MagicYUV" or "UtVideo" look bad ! Both Codecs have a great potential but still have some problems I wanted to share with you and other Users, that is all and I hope we are clear on this now ! This Chapter is closed for me and I am not willing to invest anything any further because I have plenty other Things to do.

Case closed.

Mick
Mick is offline   Reply With Quote
Old 29th June 2015, 22:14   #366  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
I've done 1000s of DVDs and 100s of Blu-ray projects using lossless codec as an intermediate format, so I agree with you that there are different needs. You just have to understand your workflow and make sure it's robust. This what you complaining is not directly related to codec itself. You have to understand this.
kolak is offline   Reply With Quote
Old 29th June 2015, 22:33   #367  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@kolak
I am not "complaining" about the Codecs "MagicYUV" or "UtVideo", you got me wrong in this aspect, I was trying to help because "MagicYUV" and "UtVideo" can be very good alternatives to other lossless Codecs for certain purposes when needed, once the little things are fixed. A robust Workflow ? Oh yes, very important and underestimated by many

Cheers

Mick
Mick is offline   Reply With Quote
Old 29th June 2015, 22:57   #368  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Mick View Post
@WorBry
Quote:
"HuffYUV encodes interlaced and progressive frames exactly the same. So it doesn't need to know if the frames are interlaced or progressive. The "swap fields" option is only there to correct a bug where some old cards captured with the scanlines swapped -- it isn't to be used to specify field order"

This Statement is simply wrong because HuffYUV considers more than 288 Lines as Interlaced. For Progressive Content like 1280x720 this needs to be set to 720 instead of 288. Did you ever read the Codec Description ?
No, WorBry's statement is correct, if there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not.
Make a test encode or read the codec source code if you have doubts.

Quote:
Originally Posted by Mick View Post
And now you're sort of saying that I am a stupid Idiot ?
I haven't said that, so don't put words in my mouth that I didn't say.

Quote:
Originally Posted by Mick View Post
Go on, keep ignoring facts and be happy to have the "fastest" codec around but I am out at this point. I thought Doom9 was different, until today. I've sent you everything backed up with Links to the Web in your PN, many times and most of them you never read. I suggest you don't ask for help or suggestions next time you work on a Project like "MagicYUV".
I get plenty of help from other people here on doom9 who are truly willing and meaning to help.
Still awaiting your facts though...

Quote:
Originally Posted by Mick View Post
Case closed.
The best thing to do when you run out of arguments...

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 30th June 2015, 20:43   #369  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Ignus2
I wrote:
"And now you're sort of saying that I am a stupid Idiot ?"

Your reply:
"I haven't said that, so don't put words in my mouth that I didn't say."

Right, you did not say that but reading between the Lines of your replies it comes over like that to me. Correct me if I am wrong in this, okay ?

You wrote: (About HuffYUV Swap Field)
"No, WorBry's statement is correct, if there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not."

Wrong, please read for yourself:

HuffYUV Documentation:

Field Threshold
When I added the YUY2 stuff described above, I discovered a hardcoded threshold that will trigger progressive or field based compression. Something that was not acceptable, as NTSC has a threshold of 240, Progressive Frames have none at all. I simply added another entry in huffyu.ini and added a way to edit it in the configuration dialog. You can change the value to any number between 1 and 16384.

If you're processing NTSC video, you should set it to 240, so that material with more than 240 lines will use interlaced compression. For PAL the original value of 288 is right.

If you are doing progressive material, setting it to 480 or 576 lines will compress even video at this resolution progressive. This should result in better compression.

If you set this option correctly you will get properly separated fields, if not, your fields will be blended, or you will have lower quality.

Swap fields on decompress
Some capture drivers are broken and get the field order backwards. If you're stuck with one of these, you can compensate by checking this option--proving once again that two wrongs make a right.
Source: HuffYUV Documentation

I wrote:
"Case closed."

You wrote:
"The best thing to do when you run out of arguments..."

Well, I don't have "Arguments" but some facts from some Whitepapers:

Raw VBI (Whitepaper)

Raw Video Data Output:
The vertical blank interval (VBI) data processor (VDP) slices various data services like wide screen signaling (WSS) to the hardware and compressor.

These services are acquired by programming the VDP to enable a standard(s) in the VBI. The results are stored in a FIFO and/or registers. (ITU-R BT 601)

Available VBI lines are from line 6 to line 27 of both field 1 and field 2. Theoretically, each line can be any VBI mode because the VDP processes VBI data in a line by line. When changing modes, the VDP must allow the current transaction to complete through the delays of the VDP before switching the line mode registerís contents. It must also complete the loading of the line mode registers before the next line starts processing.

This format is also used to store any VBI data into the FIFO. The size of FIFO is 512 bytes.

Sliced VBI data can be output as ancillary data in the video stream in ITU-R BT.656 mode. VBI data is output during the horizontal blanking period following the line from which the data was retrieved.

Raw VBI Synchronization Signals
Non-data stream embedded syncs are provided via the following signals:
VSYNC (vertical sync)
FID/VLK (field indicator or vertical lock indicator)
GPCL/VBLK (general-purpose IO or vertical blanking indicator)
PALI/HLK (PAL switch indicator or horizontal lock indicator)
HSYN (horizontal sync)
AVID (active video indicator)

In hardware, VSYN, FID, PALI, and VBLK are software set and double buffered to an independent programmable SCLK pixel count. This allows any possible alignment to the internal pixel count and line count.
Sources: Texas Instruments Whitepaper, Phillips Whitepaper, Empia Whitepaper


AVI2 (OpenDML Whitepaper)

60 Fields Per Second vs. 30 Frames Per Second; or 24 Frames Per Second For Film:
Professional Video Applications require the ability to sequence individual fields of the video data for certain playback rates and video effects. For example, in order to do a slow motion effect, it is not sufficient to just repeat the frames; the fields must be individually repeated.

For example, as sequence of fields in a file numbered 123456... should be played at half speed as 11223344... rather than 12123434.... As such, the individual fields should be accessible. AVI2 requires that frames are stored per data chunk.

The extended AVI2 format allows access to individual fields. In addition, the format will allow for storage of 24 frame based files, such that file readers can properly convert between 24 frame-based data storage and 25 or 30 frame PAL and NTSC playback.

AVI2 Field Index Chunk:
The AVI2 Field Index Chunk is the same as the Standard Index Chunk except that it contains the locations of each field in the frame.

The AVI2 spec lists that heights less than 288 are for single frames (one chunk) and greater than 288 are for interleaved fields (interlaced frames).

The biHeight parameter refers to the raw height of the frame (interleaved or not). OpenDML codecs that operate in field by field modes will be passed this value divided by 2 to get the field height.

AVI2 Field Indexing:
In order to support field accurate indexing while still retaining AVI compatibility, the video data must be stored one frame per ##dc Ďmovií chunk, while an index must be present that gives the locations of both fields (if they exist) within the frame. Applications could then use field-based codecs to perform field-based effects (e.g., slow motion, etc.).

Improved AVI2 Tombstone and Header Information:
Professional video applications need extended information such as starting timecode and reel ID to be contained inside the AVI2 file along with more advanced information such as the location of timecode discontinuities, wide screen, etc.
Sources: Matrox Whitepaper, Microsoft Whitepaper, Empia Whitepaper


You wrote:
"Still awaiting your facts though..."

Here are some more facts:

I've spend the past hours on the Telephone conferencing with my Guys and noted down that what they found out about MagicYUV and UtVideo. They authorized me to publish the following Information, not the rest, sorry, but there are confidential rules.

Source Format:
YCbCr 4:2:2 YUY2 16 Bit Uncompressed
Video: NTSC 4.43, 29.970 Fps at 720x480 with BFF
Audio: 48.000 Hz, 16 Bit, Stereo, PCM
Source: S-VHS via Y/C (BNC)

Export with MagicYUV and UtVideo, no FX, BFF, same as source.
Input Monitor: YUY2 (Source)
Output Monitor: YUY2 (MagicYUV/UtVideo)
CPU Load: Average at 45-62 % for both Codecs (8 Threads)

Re-Import MagicYUV/UtVideo Video to Timeline, same Setup:
Input Monitor: UYVY with TFF (!), not BFF
Playout Monitor to VTR: UYVY, TFF (!)
Original Source to VTR: YUY2, BFF

I420, IYUV: MagicYUV decodes them as UYVY, NOT I420/IYUV,TFF (!)
YV12: MagicYUV/UtVideo decode this at UYVY, NOT YV12, TFF (!)

Export with HuffYUV/Lagarith, same setup:
HuffYUV/Lagarith decode YUY2 back to YUY2 with BFF.
Lagarith decodes YV12 back to YV12 with BFF.
CPU Load with HuffYUV (MT): around 9-20 % (8 Threads)
CPU Load with Lagarith: around 55-72 % (8 Threads)

My Guys verified this behavior with VirtualDub (1.10) on a Win7 Ultimate (64 Bit) using "Fast recompress" using YCbCr (no Codec) with the 64 Bit versions of MagicYUV/UtVideo.

Result: Saved as UYVY with UtVideo and MagicYUV instead of I420,IYUV,YV12 or YUY2 with TFF instead of BFF. Lagarith decoded as YV12/YUY2 with BFF and HuffYUV (2.1.1 64 Bit) as YUY2 with BFF. All tests where done with the same setup, frame rate and resolution, same conditions on all codecs for Import and Export.

So, fact is: MagicYUV and UtVideo unify to UYVY on the Output rather than decoding the source Color Space with TFF, not BFF which brings me to this Section.

Section "UYVY is the SAME as YUY2"

VirtualDub Help says:
4:2:2 YCbCr (UYVY)
This is a format which uses the YCbCr color space (luma, chroma-blue, chroma-red), which is closer to the way color images are perceived by the human brain. It averages only 16 bits per pixel with similar perceptual quality to 24-bit RGB by only storing color information at half horizontal resolution, producing slight color bleeding but only taking two-thirds as much space.

This format, as do all other YCbCr formats listed below, encodes luminance (Y) with a range of [16, 235] and chroma (Cb/Cr, or U/V), with a range of [16, 240].

UYVY is accepted directly by many video codecs. Since many video codecs internally use color spaces similar to YCbCr, using this format with video codecs can speed up rendering.

4:2:2 YCbCr (YUY2) (!)
This is the same as 4:2:2 YCbCr (UYVY), except for a shuffling of data bytes. It has the same quality and performance advantages as UYVY.

Correction
(!) = This is NOT WRONG ! Sorry, my fault.

Microsoft says:
The YCbCr YUY2 format uses a slightly different byte order for data and chroma compared to the YCbCr UYVY format. All trans-codes between YUY2 and UYVY are done with a new chroma byte and data order which results in no losses in quality over time BUT TO RGB if done too often, even if both formats are very similar.
Source: Microsoft YUV Format Whitepaper

I talked about this with my Guys as well and they totally agree that this is a total misbehavior of MagicYUV and UtVideo. "Lossless" means something else to me. They also downloaded the most recent Versions of MagicYUV and UtVideo and made no changes in the result.

The best results where made with MagicYUV and UtVideo using UYVY as a Source with TFF, but for NTSC Archives not really useable. They also said that all Options for "RGB Output" where disabled on all Codecs because it's a YCbCr Input/Output setup.

So, before you go up the Wall, these are just facts, nothing else, okay ? I have nothing against you or the Author of UtVideo nor I am trying to make MagicYUV ot UtVideo look bad, but there are some serious Bugs that are responsible for this behavior.

Plus, HuffYUV and Lagarith work as expected and don't change the Color Space on the decoding part nor the Field Order under the same (!) conditions, they decode that what they been fed with including the correct Field order. Why they work with the right Field order and Color Space, I don't know.

Here you have it, all you need and please share this with the Author of UtVideo because all these things are important if both of you want your Projects to work. I wish you both a big Mountain of Luck. This is all I can do at this end and hope you find out why the Codecs behave this way.

Over and out.

Mick

P.S.: They also downloaded my Samples I linked here as well. They verified that my Samples behave exact the same Way like their own Samples.

Last edited by Mick; 4th July 2015 at 15:58.
Mick is offline   Reply With Quote
Old 30th June 2015, 21:47   #370  |  Link
vivan
/人 ◕ ‿‿ ◕ 人\
 
Join Date: May 2011
Location: Russia
Posts: 649
Quote:
Originally Posted by Mick View Post
Microsoft says:
The YCbCr YUY2 format uses a slightly different byte order for data and chroma compared to the YCbCr UYVY format. All trans-codes between YUY2 and UYVY are done with a new chroma byte and data order which results in slight losses in quality over time if done too often, even if both formats are very similar.
Source: Microsoft YUV Format Whitepaper
Wow, this is golden. Apparently moving bytes too much destroys them!

P.s. jesus christ, learn how to quote.
vivan is offline   Reply With Quote
Old 30th June 2015, 21:56   #371  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,864
@Mick -
I'm sure everyone appreciates that you're trying to add feedback to improve the software, but those are mostly observations, not facts. Facts are independently verifiable.

It looks like a problem or incompatibility with your hardware card and software setup - this is almost certain

When used properly, the both magic yuv and ut video are bit for bit lossless . This is easy to prove and independenly verifiable over "n" generations (That is a fact, not obseration. ) . Many people can independently verify that

You can interpret the field order as you want in most software. Or is that your issue ?

It's definitely a software issue because your software is upscaling the chroma on I420 . With other software it decodes correctly. Some NLE's actually hand off RGB from UT or magicyuv from YUV input, so it's not only your software that is a problem, other titles can have issues as well

If you cannot name the software used due to NDA concerns , or if it's in-house software title not much anyone can do to help





Do you have a link to the MS whitepaper ? There is no quailty loss between YUY2 and UYVY conversions. The original whitepaper from 2002 said nothing of the sort. I can find no reference about quality loss either. Test it yourself as I have, over "n" iterations there is no loss if you do it properly.

(Technically, there is no "transcoding" between YUY2 and UYVY . The term is used loosely now, but transcoding, by definition involves requantizing DCT coefficients at a lower precision to save bits. It's always lossy process.)

Last edited by poisondeathray; 30th June 2015 at 22:01.
poisondeathray is offline   Reply With Quote
Old 1st July 2015, 03:39   #372  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Mick View Post
Right, you did not say that but reading between the Lines of your replies it comes over like that to me. Correct me if I am wrong in this, okay ?
You are wrong in this.
However there are many things you are getting wrong and are confused about. This is not stupidity. But you should consider the possibility that you are wrong about things. Others have also began pointing this out in your messages.
This is not a problem.
However, there are things others know better than you, even though you have many years of experience. So don't stick to your guns, take a step back and try to see where you are wrong.

Quote:
Originally Posted by Mick View Post
You wrote: (About HuffYUV Swap Field)
"No, WorBry's statement is correct, if there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not."

Wrong, please read for yourself:

HuffYUV Documentation:
...
There is no need to read the docs, as I can read the source code as well. What I have said is:
"If there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not."
Which is verifiable by reading the HuffYUV sources. HuffYUV does no blending of fields whatsoever if you give it YUY2 and ask YUY2 back. It will give you back the same result if you encode and decode in the same colorspace whether interlaced encoding is turned on or not.
You can verify this by doing an encode-decode cycle with both settings and check the result.

Quote:
Originally Posted by Mick View Post
If you set this option correctly you will get properly separated fields, if not, your fields will be blended, or you will have lower quality.
This statement is in effect ONLY if HuffYUV does color-space conversion, for example when decoding compressed YUY2 data as RGB or compressing RGB as YUY2.

Quote:
Originally Posted by Mick View Post
Raw VBI (Whitepaper)
...
Again: neither HuffYUV, MagicYUV or UT codecs' VFW versions don't have any sort of ability to access VBI information. This is again verifiable by source code and the fact that VFW simply has no way of feeding this info to the codecs.

Quote:
Originally Posted by Mick View Post
AVI2 (OpenDML Whitepaper)
...
What you quoted, unfortunately has no additional information to the problem at hand.

Quote:
Originally Posted by Mick View Post
...
So, fact is: MagicYUV and UtVideo unify to UYVY on the Output rather than decoding the source Color Space with TFF, not BFF which brings me to this Section.
This is an observation, not a fact. The codecs output a format what they are asked to output by the application. They can also propose a format, but ultimately it is the application which decides what to ask from the codec. In your case, the app asks for UYVY for whatever reason.
Also, the big difference in the CPU load clearly indicates, that there is some color-space conversion (or something else) going on in the background. This is the source of all problems, but unfortunately, it originates from someplace else than the codecs.
Again: the codecs do what they are asked to do.

Quote:
Originally Posted by Mick View Post
Microsoft says:
The YCbCr YUY2 format uses a slightly different byte order for data and chroma compared to the YCbCr UYVY format. All trans-codes between YUY2 and UYVY are done with a new chroma byte and data order which results in slight losses in quality over time if done too often, even if both formats are very similar.
Source: Microsoft YUV Format Whitepaper
I don't know what whitepaper is this, and I'm sorry to say this, but this is just plain stupid.
Do a google search on "UYVY vs YUY2" and you'll find out for yourself.

Quote:
Originally Posted by Mick View Post
So, before you go up the Wall, these are just facts, nothing else, okay ? I have nothing against you or the Author of UtVideo nor I am trying to make MagicYUV ot UtVideo look bad, but there are some serious Bugs that are responsible for this behavior.
And these bugs are most certainly in the setup (which I would very much like to find out as well), and not in the codecs.

Quote:
Originally Posted by Mick View Post
Plus, HuffYUV and Lagarith work as expected and don't change the Color Space on the decoding part nor the Field Order under the same (!) conditions, they decode that what they been fed with including the correct Field order. Why they work with the right Field order and Color Space, I don't know.
Again, MagicYUV and UT also don't change colorspace unless they are asked to do so.
BTW: MagicYUV specifically has options to prevent conversions on the output ("Decompression settings"). Disable all the checkboxes there, and there will be no conversions, apart from the lossless byte/plane-swapping variants.

I'm a bit tired now, so sorry if I forgot to reflect on something.

Greets,
I.

P.S.: The next version of MagicYUV will have logging support, so then we'll be able to see what it gets and what it is asked to output.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 1st July 2015 at 22:51.
Ignus2 is offline   Reply With Quote
Old 1st July 2015, 10:20   #373  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
Mick, as said before- it's all down to your specific setup and not much to do with codecs itself.

Lossless codec in the proper/best case scenario takes data as is (in on of the supported pixel formats: YUY2, v210 etc), compresses it and that's it. Because it's lossless compression when you decompress it (to the same pixel format which it was compressed from) than result is always 100% the same as source data! It's the same as zipping file.

Your software/hardware is responsible for proper field order interpretation and this is outside of the codec.

This is why I said talk to Drastic/Cinegy. They can do proper magicyuv implementation, so whole transcoding chain can be done at cards native pixel formats (magicyuv support all needed ones) and whole chain will be robust.

VBI is past and again- has nothing to do with codec itself. Still used by old payout systems, but in most cases it's not needed anymore (can be blank). It's basically unsupported in new capture cards: AJA, BM etc.

Not sure why you can't understand that problem is not inside magicyuv or utvideo, but in the integration between your ingest system and codecs.

Last edited by kolak; 1st July 2015 at 10:23.
kolak is offline   Reply With Quote
Old 1st July 2015, 22:56   #374  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
Did you say that you have 45-62% CPU load on realtime encoding to magicyuv for NTSC on 8 core system?
Or is it during export?
Realtime encode or playback for NTSC on 8 threads system should have <5% CPU load, not 50% (or your system is ancient).
kolak is offline   Reply With Quote
Old 3rd July 2015, 21:50   #375  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Ignus2
I am glad that we cleared this point between us so no hard feelings, okay ?

About HuffYUV: Sorry, but we are talking about different things here, so let me try to clarify this to you.

Your Quote about Interlaced:
"If there is no in-codec color-space conversion involved, you get back the same result whether interlaced encoding is turned on or not."

HuffYUV Documentation:
"Field Threshold
When I added the YUY2 stuff described above, I discovered a hardcoded threshold that will trigger progressive or field based compression. Something that was not acceptable, as NTSC has a threshold of 240, Progressive Frames have none at all. I simply added another entry in huffyu.ini and added a way to edit it in the configuration dialog. You can change the value to any number between 1 and 16384.

If you're processing NTSC video, you should set it to 240, so that material with more than 240 lines will use interlaced compression. For PAL the original value of 288 is right.

If you are doing progressive material, setting it to 480 or 576 lines will compress even video at this resolution progressive. This should result in better compression.

And this is the same behavior in AVI2 OpenDML:
"The AVI2 spec lists that heights less than 288 are for single frames (one chunk) and greater than 288 are for interleaved fields (interlaced frames)."

Sometime reading a Documentation can help

Correction about UYVY vs YUY2: I WAS WRONG, Sorry ! What I posted related to converting UYVY/YUY2 Footage to RGB and back to UYVY/YUY2 which was later described in the Whitepaper and I've overseen, so, sorry for that. There are no losses converting between UYVY to YUY2 and back. Again, sorry, my fault.

Here is a interesting Link about YUV Formats from Microsoft:
https://msdn.microsoft.com/en-us/lib...=vs.85%29.aspx

About RawVBI where you wrote:
"Again: neither HuffYUV, MagicYUV or UT codecs' VFW versions don't have any sort of ability to access VBI information. This is again verifiable by source code and the fact that VFW simply has no way of feeding this info to the codecs."

Well, I use AVI2 (OpenDML, and NOT AVI1 VfW because OpenDML offers the implementation for this. The Codecs don't "access" the Information, the Signals are transferred WITH the Codecs and placed in the AVI2 OpenDML Header, it's a big difference. You see, I use a Play-In/Play out Ingest System that works in Real Time from Tape to Disk or direct to the Timeline with Synchronization (LE/NLE) and then out to Disk or Tape.

Remember the good old Days of DV and Firewire ?

I give you and the others here a rough Idea of what I mainly do: Many Company's and TV-Stations around the World send me, for example Tapes (VHS) that never made it on DVD which they want to sell now as a DVD or for their Archives on Disk, TV-Stations send me their S-VHS Archives via Courier/Parcel Service to preserve them for the Digital Century in the Format they want. I have to deal with all kinds of Material and TV-Norms from all over the World from different Country's.

I transfer, edit and master the Audio/Video Material for them and a Courier/Parcel Service picks the Tapes along with the Disks or DVD's up when I'm done, depends on the Client and what they ordered. So you see, I depend very much on proper synchronization and all my Multiform Decks offer this, that's why I still use RawVBI along with the other Signals involved. Even on VHS/S-VHS the Wide Screen Flag (WSS) exists and many have been distributed and sold with it.

And you're right, these are observations and experiences of my Colleagues and me but still can't be simply wiped of the Table or ignored.

@kolak
You wrote:
"Not sure why you can't understand that problem is not inside magicyuv or utvideo, but in the integration between your ingest system and codecs."

and poisondethray wrote:
"I'm sure everyone appreciates that you're trying to add feedback to improve the software, but those are mostly observations, not facts. Facts are independently verifiable.

It looks like a problem or incompatibility with your hardware card and software setup - this is almost certain"

Thanks for the Tip Guys, you where right because I took a look in the Cinegy Manual and the Section for "Supported Codecs". Now guess what I found there:

"There is no support for a free-form codec selection for AVI export except the ones listed below."

HuffYUV is on the List and with Lagarith I got "lucky" because Lagarith is not on the List, but works fine.

@kolak
You wrote:
"Mick, as said before- it's all down to your specific setup and not much to do with codecs itself."

I understand that and know how lossless Codecs work, but there are some things that really puzzle me because I really like MagicYUV and UtVideo and observed some things I can't find a solution or Answer for. The only thing I found out was, disabling RawVBI with MagicYUV and UtVideo solves the Problem of their strange behavior compared to HuffYUV and Lagarith. But since RawVBI is no longer supported since Vista, it's obvious that this never came up and no one noticed.

RawVBI on:
MagicYUV = TFF with NTSC (SD)
UtVideo = TFF with NTSC (SD)
HuffYUV = BFF with NTSC (SD)
Lagarith = BFF with NTSC (SD)

RawVBI off:
MagicYUV = BFF with NTSC (SD)
UtVideo = BFF with NTSC (SD)
HuffYUV = BFF with NTSC (SD)
Lagarith = BFF with NTSC (SD)

With "RawVBI off" the Image was a bit softer with MagicYUV and UtVideo compared to HuffYUV and Lagarith where HuffYUV has the best Field separation and sharper Image compared to Lagarith. All Tests where done with the same (!) Footage and Conditions/Settings for Export to Disk.

Then you wrote:
"Lossless codec in the proper/best case scenario takes data as is (in on of the supported pixel formats: YUY2, v210 etc), compresses it and that's it. Because it's lossless compression when you decompress it (to the same pixel format which it was compressed from) than result is always 100% the same as source data!"

Right, but that does not happen with MagicYUV and UtVideo. Here is what we observed:

YUY2 is decoded as UYVY with MagicYUV (all decoding options off) and UtVideo, basically the same, no loss but still, HuffYUV and Lagarith decode to YUY2.

I420/IYUV is decoded to YV12 by MagicYUV and not as I420/IYUV. Here is a swap in the planar color space. YV12 is decoded as UYVY with UtVideo, means, up-sampled from 4:2:0 to 4:2:2 where Lagarith decodes YV12 if the source was YV12. v210 is decoded as RGB and not as YCbCr, same with VirtualDub exporting a Video with uncompressed v210. UtVideo and VirtualDub show on some Systems a Black Screen, on others a Green Screen before they hang after a long pause.

MagicYUV and UtVideo negotiate with other Codecs (Xvid/x264vfw) UYVY, even if I420/IYUV/YV12/YUY2 was used as a source to compress the Video (fast recompress) while HuffYUV uses YUY2 and Lagarith YUY2/YV12.

All this also happens on any "normal" System (Win7 x86/x64) with VirtualDub (1.6 to 1.10) or other Consumer/Semi-Pro/Pro NLE's installed, not just on our Systems because we tried that too with RAW 4:2:2/4:2:0 Videos to be sure The Drastic Codecs are innocent because this happens with the native Windows Codecs too (I420/IYUV/UYVY/YUY2) and using the native Intel I420/IYUV Codec results in a RGB24 Output and Playback.

And the high CPU Load ? No Idea but it's the truth. Here are some Images a Colleague from Germany provided me with and is about the same what we saw on our Systems. The Source was a 5 Minute 4K Footage on a Win7 x64 Ultimate System. "Green" is the CPU Load, "Red" the Kernel Load on the Diagrams (7 Images), you can download the File "CPU-Load.7z" here:

http://ge.tt/2N8ZQhJ2/v/0?c

"HY" is HuffYUV (MT), "MY" is MagicYUV, "UT" is UtVideo and Image 07 is the CPU-Load of the Input Uncompressed. "Enc" means "Encoding" and "Dec" means "Decoding". He also said that these are the absolute MAXIMUM Measurements he monitored, depending on Movement, taking off that maximum about 20-30 percent gives you a good average Overview of the CPU Load. The Diagrams only show 2 of 8 Threads used because the other Threads had the same CPU Load as the first two.

@All
So, this is really all I can do to help and hope it helps to figure out the strange behavior of MagicYUV and UtVideo. And again, I really think that MagicYUV and UtVideo are great codecs and I am not trying to make them look bad because this is not the case at all, just trying to help, nothing else. I also would like to thank everybody here in this Thread for their patience, tips and helpful thoughts.

Cheers
Mick

P.S.: It's way to hot at the moment here in France... Puuhhh...

Last edited by Mick; 4th July 2015 at 15:52.
Mick is offline   Reply With Quote
Old 4th July 2015, 00:53   #376  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
You are getting closer and more and more confirms that problem is integration between Cinegy and codecs (not tested/optimised).

Vdub has no problems at all with magicyuv or utvideo. If you set correct pixel format in Vdub settings than it will talk to both codecs through YUY2 or even v210. If you see RGB it means that you have wrong (most likeky default) settings. If your source is magicyuv (encoded from v210) and you see black/green picture in Vdub than you have wrong setting in decompression format (magicyuv has no internal conversion between 10 and 8bit). It has to be set to v210.
Both magicyuv and utvideo work very well in Edius NLE if files were encoded as 422 YUV. This is because Edius engine 'likes' YUY2 pixel format. Many software will ask codec to provide RGB, so you end up with conversion.

Magicyuv 25p 4K playback through v210 pixel format directly to madVR renderer in mediaplayer classic was using <20% of 6 cores 3.2 GHz E5 Xeon (HP Z420). SD files play at tiny CPU load on such a machine. Key point is to avoid any pixel format conversion. Ideally in pro solutions you want direct integration through codec SDK, not over WIN system vfw etc.

UYVY and YUY2 are “the same“ and conversion between them is trivial, so even if you see this, it's 100% lossless and fast. There is NO picture quality difference whatsoever, so if you see leess sharp footage than there are some serious problems with decoding chain.

As I said- write to Cinegy, so maybe they can debug and add proper support for magicyuv/utvideo.
If you want to test pure speed of the codec use tool provided by Ignus2 on his website. Most NLEs etc. will give totally inaccurate results.

Last edited by kolak; 4th July 2015 at 01:13.
kolak is offline   Reply With Quote
Old 4th July 2015, 01:25   #377  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,864
Quote:
Originally Posted by Mick View Post



Then you wrote:
"Lossless codec in the proper/best case scenario takes data as is (in on of the supported pixel formats: YUY2, v210 etc), compresses it and that's it. Because it's lossless compression when you decompress it (to the same pixel format which it was compressed from) than result is always 100% the same as source data!"

Right, but that does not happen with MagicYUV and UtVideo. Here is what we observed:

YUY2 is decoded as UYVY with MagicYUV (all decoding options off) and UtVideo, basically the same, no loss but still, HuffYUV and Lagarith decode to YUY2.

I420/IYUV is decoded to YV12 by MagicYUV and not as I420/IYUV. Here is a swap in the planar color space. YV12 is decoded as UYVY with UtVideo, means, up-sampled from 4:2:0 to 4:2:2 where Lagarith decodes YV12 if the source was YV12. v210 is decoded as RGB and not as YCbCr, same with VirtualDub exporting a Video with uncompressed v210. UtVideo and VirtualDub show on some Systems a Black Screen, on others a Green Screen before they hang after a long pause.

MagicYUV and UtVideo negotiate with other Codecs (Xvid/x264vfw) UYVY, even if I420/IYUV/YV12/YUY2 was used as a source to compress the Video (fast recompress) while HuffYUV uses YUY2 and Lagarith YUY2/YV12.

All this also happens on any "normal" System (Win7 x86/x64) with VirtualDub (1.6 to 1.10) or other Consumer/Semi-Pro/Pro NLE's installed, not just on our Systems because we tried that too with RAW 4:2:2/4:2:0 Videos to be sure The Drastic Codecs are innocent because this happens with the native Windows Codecs too (I420/IYUV/UYVY/YUY2) and using the native Intel I420/IYUV Codec results in a RGB24 Output and Playback.
Thanks for reporting back and providing more info

It's true, not all codecs will decompress to the identical input pixel arrangement, but it does not matter. This is true for all codecs, not just ut video and magicyuv. You can change it to whatever pixel arrangement you want, e.g if you start with YUY2 , and a certain decoder or application decodes to UYVY, or Y422, or UYNV, or HDYC, or YVYU , etc.. - if doesn't matter what arrangement you use (ie. 4:2:2 is 4:2:2, it doens't matter if it's planar or packed or what order - this has no effect on quality) . There is no loss if you convert between them correctly - that was already discussed. Huffyuv is no different here - for example, if you give it HDYC, it won't give you HDYC back. I think it would be a lot of work to keep track of all possible input/output pixel arrangements

There are some circumstances where a certain fourcc is desireable - in the case of certain host applications, there are "preferred" fourcc's and pixel arrangements which get preferential treatment and pass through, but this is slightly off topic

However, your UT video observation is cause for worry , because an up or downsample would cause quality loss. Also, if UYVY is always used to negotiate with other codecs, that would also cause quality loss from any 4:2:0 input. If it were true, then the decoded output would be detected as different than the original (ie. NOT lossess) by any method e.g. PSNR, SSIM, Amplifie, Difference or Subtract testing etc... I think this might be related to some workflow issues on your end, because I cannot reproduce it. I just tested it (again). (And if you think about it, someone would have reported especially the 4:2:0 case, because codecs like ut, magicyuv are used by thousands of non professional users as well. )
poisondeathray is offline   Reply With Quote
Old 4th July 2015, 15:47   #378  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@kolak
I never said that VirtualDub has Problems with MagicYUV or UtVideo, I was relating to the Ingest Systems only. And v210 was only tested with UtVideo and the Uncompressed Output from VirtualDub using v210, not with MagicYUV. Loading these Files with v210 from UtVideo or VirtualDub to the Timeline to the Ingest System, THEN comes either a "Black" or "Green" Screen after a long Pause before everything hangs. Using the Drastic Codec with v210 is no Problem. I get back with the Guys at Cinegy and let you all know here how it turned out and what they said, okay ?

One thing was discovered: Installing the AJA QuickTime Codecs enables the Import to the Timeline with Ingest Systems using the QuickTime Interface when importing v210 from VirtualDub. But: Instead of v210 YCbCr it's converted to RGB24 and is not as fluent as v210 YCbCr, not the best Solution but works.

@poisondeathray
You should be able to verify that. Here is what we tried:
New Win7, no NLE's, just VirtualDub 1.10 along with Xvid (1.3.2) and x264vfw (Version 41), HuffYUV, Lagarith, MagicYUV and UtVideo, nothing else, means no extra Filter etc.. Then we imported a RAW 4:2:0 (I420/IYUV/YV12) and a RAW 4:2:2 (UYVY/YUY2) Video in VirtualDub. After loading the Video in VirtualDub, we selected "fast recompress", left PCM Audio with "Direct Stream copy" and selected Xvid first, then x264.

The result was that Xvid and x264vfw used the Source Color space that was given by the RAW Files and decoded it like that on the Ingest System, means, I420/IYUV/YV12/UYVY/YUY2 was decoded correctly, same with x264vfw.

Now we fed MagicYUV with I420/IYUV and opened the MagicYUV Video in a new Instance of VirtualDub. Same setup with RAW to Xvid but instead of I420/IYUV MagicYUV decoded as YV12 to Xivd and x264vfw. We fed UtVideo with a Raw YV12 Video and opened a new Instance of VirtualDub, same thing, but UtVideo used UYVY for Xvid and x264vfw instead of YV12. The compressed Raw Sources with UYVY/YUY2 where both decoded by MagicYUV and UtVideo as UYVY to Xvid and x264vfw.

HuffYUV used YUY2 for decoding and Lagarith used YUY2 and YV12 for decoding to Xvid and x264vfw. So the "as is" does not seem to work as expected with MagicYUV or UtVideo. We even tried different Systems with ATI, NVidia and Intel Graphics, no change. Changing the decoding Options in MagicYUV made no difference.

The only thing we noticed that, if all Options are enabled in the Decoding Setting, MagicYUV even uses RGB24 instead of UYVY (all Decoding Options off).

BTW: With x264vfw I also got "lucky" because it's also not on the Cinegy List, only Xvid.

There is no doubt at all that MagicYUV and UtVideo are great codecs and "professional", that word can be seen in different Ways because I've seen "professionals" that had absolutely no Clue of what they are doing. It's not a matter if someone uses these Codecs as a "pro" or not, the result counts, nothing else.

Then you wrote:
"Huffyuv is no different here - for example, if you give it HDYC, it won't give you HDYC back."

I heard rumors that there is a patched HuffYUV for HDYC floating around, based on the CCESP Patch 0.2.5, don't know if it works or solves this.

You wrote:
"There are some circumstances where a certain fourcc is desireable..."

I prefer the FourCC that was used and noticed for example, when exporting as MPEG-2 (DVD) with 4:2:2 instead of 4:2:0 it's slightly slower than staying in 4:2:0 Color Space. When I have do to Color Corrections and they're done in 4:2:0 like the transferred Source, you get a complete different result if you do the Color Corrections in 4:2:2 to be exported to Disk.

If a Client wants MPEG on the Disk, i use 4:2:0 for the cleanest encoding. If a Client wants it as a Archive, then I use YUY2/2vuy or v210 for the Disk. Some Clients request HuffYUV, others Motion JPEG or JPEG 2000 but the majority either RAW YCbCr or HuffYUV.

But maybe it's just me because I would like to see the Color Space used on the Output like it was processed with. There are Limits if you convert 4:2:0 to 4:2:2 or vice versa and my Goal is to keep the Quality at it's best because my Clients expect that from me.

@All
My Attachment is still not "approved" ? No Problem, here is the external Link where you can download the Images from my Colleague from Germany:

CPU-Load.7z:
http://ge.tt/2N8ZQhJ2/v/0?c

You all take care and happy "sweating" with this Heat Many thanks for the responsive and informative Posts.

Cheers
Mick

Last edited by Mick; 4th July 2015 at 16:28.
Mick is offline   Reply With Quote
Old 4th July 2015, 18:41   #379  |  Link
poisondeathray
Registered User
 
Join Date: Sep 2007
Posts: 3,864
Quote:
Originally Posted by Mick View Post


@poisondeathray
You should be able to verify that. Here is what we tried:
New Win7, no NLE's, just VirtualDub 1.10 along with Xvid (1.3.2) and x264vfw (Version 41), HuffYUV, Lagarith, MagicYUV and UtVideo, nothing else, means no extra Filter etc.. Then we imported a RAW 4:2:0 (I420/IYUV/YV12) and a RAW 4:2:2 (UYVY/YUY2) Video in VirtualDub. After loading the Video in VirtualDub, we selected "fast recompress", left PCM Audio with "Direct Stream copy" and selected Xvid first, then x264.

The result was that Xvid and x264vfw used the Source Color space that was given by the RAW Files and decoded it like that on the Ingest System, means, I420/IYUV/YV12/UYVY/YUY2 was decoded correctly, same with x264vfw.

Now we fed MagicYUV with I420/IYUV and opened the MagicYUV Video in a new Instance of VirtualDub. Same setup with RAW to Xvid but instead of I420/IYUV MagicYUV decoded as YV12 to Xivd and x264vfw. We fed UtVideo with a Raw YV12 Video and opened a new Instance of VirtualDub, same thing, but UtVideo used UYVY for Xvid and x264vfw instead of YV12. The compressed Raw Sources with UYVY/YUY2 where both decoded by MagicYUV and UtVideo as UYVY to Xvid and x264vfw.

HuffYUV used YUY2 for decoding and Lagarith used YUY2 and YV12 for decoding to Xvid and x264vfw. So the "as is" does not seem to work as expected with MagicYUV or UtVideo. We even tried different Systems with ATI, NVidia and Intel Graphics, no change. Changing the decoding Options in MagicYUV made no difference.

The only thing we noticed that, if all Options are enabled in the Decoding Setting, MagicYUV even uses RGB24 instead of UYVY (all Decoding Options off).


How are you making those determinations of what color model/ pixel arrangements are being output exactly? . Let's just take 1 case at a time. It seems the UT Video 4:2:0 is the one that is causing you problems, because upsampling would cause quality loss if your observation was correct.

I'm saying the output lossless x264vfw (4:2:0) from utvideo (4:2:0) input is the same (no quality loss, as determined by those various methods mentioned earliy), and the decoded utvideo is the same as input uncompressed 4:2:0 . By logic , the original uncompressed 4:2:0 is the same as x264vfw, but testing them directly also confirms that.

When you have uncompressed 4:2:0 input loaded directly, check what vdub file=>file information says . Repeat at each stage

The end result is what is important, I think you might either be misreading the output pixel formats, or something else in your workflow is causing the problem. Or test the decoded input and output files directly. If they are not the same using one of the methods mentioned earlier then something else is wrong with your workflow

(I dislike using the way you are using the term "RAW" here. RAW has a different meaning in the professional world - RAW is a term usually reserved for undebayered sensor data. It's completely different than what you are using)


Quote:
Then you wrote:
"Huffyuv is no different here - for example, if you give it HDYC, it won't give you HDYC back."

I heard rumors that there is a patched HuffYUV for HDYC floating around, based on the CCESP Patch 0.2.5, don't know if it works or solves this.
Yes, there are specific builds, the HDYC was just an example to illustrate the point. What if I started with and needed "YV16"? There are many more configurations for each pixel type... The point is you don't want to install 121 different huffyuv or "codec xyz" versions .


Quote:
You wrote:
"There are some circumstances where a certain fourcc is desireable..."

I prefer the FourCC that was used and noticed for example, when exporting as MPEG-2 (DVD) with 4:2:2 instead of 4:2:0 it's slightly slower than staying in 4:2:0 Color Space. When I have do to Color Corrections and they're done in 4:2:0 like the transferred Source, you get a complete different result if you do the Color Corrections in 4:2:2 to be exported to Disk.

Of course you stay in the original color sampling and color model. That is NOT the same thing as using different pixel arangements for the same color sampling and color model

If you downsample chroma or convert to some other color model like RGB - of course there is quality loss - we are not talking about that . There is no quality loss between UYVY and YUY2 for example - we already covered that! Because they are both 4:2:2 . If you converted to IYUV (4:2:0) of course there would be loss incurred. Similarly , there is no loss when starting with and converting between YV12 or IYUV or NV12 or I420 because they are all 4:2:0

Last edited by poisondeathray; 4th July 2015 at 18:54.
poisondeathray is offline   Reply With Quote
Old 4th July 2015, 20:47   #380  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
Quote:
Originally Posted by Mick View Post
@kolak
I never said that VirtualDub has Problems with MagicYUV or UtVideo, I was relating to the Ingest Systems only. And v210 was only tested with UtVideo and the Uncompressed Output from VirtualDub using v210, not with MagicYUV. Loading these Files with v210 from UtVideo or VirtualDub to the Timeline to the Ingest System, THEN comes either a "Black" or "Green" Screen after a long Pause before everything hangs. Using the Drastic Codec with v210 is no Problem. I get back with the Guys at Cinegy and let you all know here how it turned out and what they said, okay ?

One thing was discovered: Installing the AJA QuickTime Codecs enables the Import to the Timeline with Ingest Systems using the QuickTime Interface when importing v210 from VirtualDub. But: Instead of v210 YCbCr it's converted to RGB24 and is not as fluent as v210 YCbCr, not the best Solution but works.

Cheers
Mick
This is exactly what you don't want to happen- v210 being decoded to RGB. It breakes whole point of having v210 in the beginning.

Magicyuv won't convert any of the 10bit formats to 8bit and this is done 'sort of' on purpose. If your software can't established vfw pipe over v210 pixel format (which is case for 95% software) than you will have black/green video or crash. For some software it will work and than you have clean 10bit chain (like Vdub, madVR renderer). By installing codecs which convert 10bit to 8bit you are making your system unpredictable and worthless.
Installing Drastic or BM/AJA codec to make v210 (or 10bit magicyuv/utvideo) working is 'vary bad' and it actually tells you that your pipe is only 8bit. What you want is your software to be able to accept v210 pixel format after magicyuv/utvideo decoder natively, so pipe stays 'native'.
Problem is that almost not a single software can accept v210 on decoding pin over vfw. You will be more lucky with MOV, but this has its own problems also.
Yet again- you need a proper integration between the app and codec on SDK level not through vfw/directshow/QT etc. If you think you will have perfect integration over vfw etc between some custom codec and app than think twice. If you want the same for 10bit+, than you may forget, as this is basically guaranteed not to work without proper integration. If you keep instaling 'other' codecs: Drastic, ffdshow, etc than this veeeeery bad idea and not the way to get reliable workflow.

Last edited by kolak; 4th July 2015 at 21:01.
kolak 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 04:16.


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