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 10th October 2014, 22:49   #241  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Quote:
Originally Posted by Mick View Post

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

Cheers

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

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

Last edited by kolak; 10th October 2014 at 23:01.
kolak is offline   Reply With Quote
Old 10th October 2014, 23:37   #242  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Kolak
I mainly work with Interlaced Content for my Clients, but you can see this now yourself, just download the Videos then you see what i mean Anyway, normally this should not matter, but somehow it does with MagicYUV. All Settings for Capturing and saving the two Videos where exactly the same. Plus, why should I write something that is not true ? I'm just trying to help the Author of MagicYUV and it's obvious that there is a Problem when it comes to NTSC with BFF instead of TFF. And yes, My NLE triggers the right Field Order with HuffYuv but not with MagicYUV and when i set the Field Order manually for MagicYUV, then the Image is still distorted and Jitters on Playback. I get the same distortion and Jitter if i set HuffYuv to the wrong field order and no, i don't want RGB when i work with YCbCr. Thanks anyway for your informative Reply's

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

->Wetransfer Link expired<-

Cheers

Mick

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

Last edited by Mick; 20th October 2014 at 21:37. Reason: Download Link expired
Mick is offline   Reply With Quote
Old 11th October 2014, 00:14   #243  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Do I have to login?
There are no files there.
Put it on https://www.wetransfer.com and share download link.

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

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

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

You can also compare them in avisynth:

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

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

Last edited by kolak; 11th October 2014 at 00:22.
kolak is offline   Reply With Quote
Old 11th October 2014, 00:19   #244  |  Link
Sparktank
47.952fps@71.928Hz
 
Sparktank's Avatar
 
Join Date: Mar 2011
Posts: 878
Quote:
Originally Posted by Mick View Post
P.S.: Just checked the Link and worked.
Not that I'm interested in checking the files out, just the link.

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

What I see. (click to open in new tab in full size)
__________________
Win10 (x64) build 17134 | GPU Caps Viewer 1.40.1.0
NVIDIA GeForce GT 1030 (GP108) 2047MB/GDDR5 | (R417.22)
NTSC | DVD: R1 | BD: A

Last edited by Sparktank; 11th October 2014 at 00:19. Reason: reduced pic size
Sparktank is offline   Reply With Quote
Old 11th October 2014, 00:47   #245  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Kolak
No, you don't have to Login Yes, i can set the Field Order manually in my NLE, for Import, Capture, Playback and Export. I made the Captures with VirtualDub (1.10.4) directly from my VCR, not with my NLE without any Filters or other modifications. Many thanks for the Hint with "Wetransfer" I uploaded the Files there.

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

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

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

Cheers

Mick

Last edited by Mick; 20th October 2014 at 21:36. Reason: Download Link expired
Mick is offline   Reply With Quote
Old 11th October 2014, 05:46   #246  |  Link
ChiDragon
Registered User
 
ChiDragon's Avatar
 
Join Date: Sep 2005
Location: Vancouver
Posts: 610
Well, I see the problem in your sample. But if I recompress your Huffyuv file with MagicYUV in Interlaced mode, there is no difference between them. Win2K issue?

Quote:
Originally Posted by rec View Post
Files encoded with MagicYUV don't show thumbnails in Windows.
Mine do on Win7 x64 (and Huffyuv files don't, for me).
ChiDragon is offline   Reply With Quote
Old 11th October 2014, 13:48   #247  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
There are some capture problems with your files. Are they captured from DV or digibeta? They are 480, shouldn't they be 486?

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

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

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

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

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

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

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

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

Last edited by kolak; 11th October 2014 at 14:16.
kolak is offline   Reply With Quote
Old 11th October 2014, 15:26   #248  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Thanks for the videos. I would have needed raw uncompressed YUY2 too as reference. Can you capture that as well?

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

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

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

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

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

Greets,
I.

P.S.: @Mick: Some questions out of interest: Why do you have RGBA compression enabled and decompression as YUV 4:4:4 all enabled? Do you have special need for these? As normally turning these on just cause trouble.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era...

Last edited by Ignus2; 11th October 2014 at 15:28.
Ignus2 is offline   Reply With Quote
Old 11th October 2014, 16:47   #249  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Field order swapping may be related to specific capture device- huffyuv has a special setting which allows to swap fields.

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

Last edited by kolak; 11th October 2014 at 16:50.
kolak is offline   Reply With Quote
Old 11th October 2014, 22:20   #250  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@ChiDragon
The HuffYuv Capture is how it comes from my VCR's, BFF for NTSC, that's why MagicYUV compresses it fine but also makes me wonder. Why does it not work that Way with a direct Capture to MagicYUV or UtVideo without being distorted ?

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers

Mick

Last edited by Mick; 11th October 2014 at 22:59.
Mick is offline   Reply With Quote
Old 11th October 2014, 23:36   #251  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Do you have swap fields option ticked in huffyuv codec?

None of the lossless codecs will alter incoming video- it encodes what it gets and this will stay lossless.
In your case issues is before data hits codec. Problem is between app and codec, something goes wrong as there is even shift in the video. Yet again, this is not really magicyuv problem. Maybe huffyuv people made special work around it, so it works fine.

Last edited by kolak; 11th October 2014 at 23:40.
kolak is offline   Reply With Quote
Old 12th October 2014, 01:08   #252  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Kolak
I used the Settings for HuffYuv as seen in the Screen Shot i posted, means, no "Swap Fields" Option enabled. I even tried VirtualDub-MPEG2 1.6.19 (ffcHandler) instead of VirtualDub 1.10.4, same Result. I agree, normally this should not happen but it does somehow and the only Software involved is VirtualDub, the Capture Devices and the Codecs, that's all i used for the Samples, no funny Codec Packs installed that could mess up something.

Win2K, XP, Win7, all with MagicYUV RC4 and UtVideo 13.3.1 along with VirtualDub gives the same results with NTSC and BFF Input, not just for me, for others too like my Friend in Florida who had the same Problem with MagicYUV. As i wrote earlier, i really don't know where the Problem could be and maybe Ben Roudiak Gould has a Routine in HuffYuv that takes care of this Situation when BFF is used on the Input.

So i ask you, where could be the Problem between VirtualDub, the different Capture Devices and the Codecs ? I practically grew up with VirtualDub but this is the first Time that i see a Codec behave like this. If it would be a Problem along with a exotic Software with funny Interfaces, yes, but VirtualDub ?

I did notice in VirtualDub 1.9/1.10 that some Filters handle the Field Order wrong. In the Manual it says for Example that "Field Order A" (Now TFF) handles the EVEN Field (Lower Field) under "Preview-Options", which is wrong, it handles the ODD Field (Upper Field) and "Field Order B" (now BFF) the ODD Field (Upper Field) but really is the EVEN Field (Bottom Field) for Interlaced Preview Mode.

VDub Manual "Field Order A" = Even Field, Truth: Odd Field (TFF)
VDub Manual "Field Order B" = Odd Field, Truth: Even Field (BFF)

This is also the case for the new Interlace Filter, Odd/Even Field is the other Way around. You can verify that easily with a proper DV Encoded Video which is always BFF for PAL and NTSC, for a long Time a reliable Standard. Load it in VirtualDub and select the Preview Option to "Weave TFF" and let it play in VirtualDub, afterwards to "Weave BFF" and you see the difference.

So, is it possible that there is a Error about the Fields in VirtualDub when using the Capture Mode ? And if so: For how long, if i get the same Result with Version 1.6.19 ? On the other hand, if there "is" a Error in the Field Order in VirtualDub, how come no one ever saw or noticed it before ? Millions of Users use VirtualDub since it came out and I'm the first one to discover this ? You must agree, that would be very strange, don't you think so ?

Going by Occam's Rule:
"The principle in philosophy and science that assumptions introduced to explain a thing must not be multiplied beyond necessity, and hence the simplest of several hypotheses is always the best in accounting for unexplained facts."

Or Occam's Razor:
"A rule in science and philosophy stating that entities should not be multiplied needlessly. This rule is interpreted to mean that the simplest of two or more competing theories is preferable and that an explanation for unknown phenomena should first be attempted in terms of what is already known. Occam's razor is named after the deviser of the rule, English philosopher and theologian William of Ockham (1285?-1349?)."

Source:
http://www.thefreedictionary.com/Occam%E2%80%99s+Rule

So, we all must ask ourselves at this point: Could it be that VirtualDub causes this Problem, that no one ever noticed before besides me, or the Codecs MagicYUV and UtVideo ? If it would be just me with this Problem, yes, could be something wrong with my Setup and VirtualDub and the Codecs are Innocent, but others too ? Same Problem with different OSes, Machines, Setup's and other Capture Devices ? Coincidence ?

Quote Kolak:
"None of the lossless codecs will alter incoming video- it encodes what it gets and this will stay lossless. In your case issues is before data hits codec. Problem is between app and codec, something goes wrong as there is even shift in the video."
Quote end

I agree with you and you're right, it should not happen, but somehow it does, can't explain why and how but you saw that yourself with the Samples i linked to the Forum.

Anyway, this whole thing is a Mystery for me as all the other captures I've done in all these Years with VirtualDub worked fine without any Problems and maybe it's because i mainly used HuffYuv the whole time. At this Point i really don't know what it could be and really puzzles me.

Cheers

Mick

Last edited by Mick; 12th October 2014 at 01:38.
Mick is offline   Reply With Quote
Old 12th October 2014, 02:07   #253  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Try this:

http://www.videohelp.com/tools/Stoik-Video-Capture

just to check something else.


I don't rate Vdub as a reliable capture tool. It's great tool, but Iam not sure about capture module.
My another simple advice is to capture DV as is ( no recompression) and than convert it to other codec. With todays PC it takes not much time. This way should be way more reliable.

Last edited by kolak; 12th October 2014 at 02:32.
kolak is offline   Reply With Quote
Old 19th October 2014, 13:34   #254  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Sorry being absent, was quite busy this week.

My suggestion would also be to try another capture program, anything else than VDub, and see what happens. I would also be interested in raw YUY2 capture.

About the compressed YUY2 being decoded as RGB always situation: do you have a sample which demonstrates this behaviour for you? I'd like to look at that as well.

About Win2k: The problem is that Win2k is missing a lot of Windows API functions that are needed to avoid the DLL shutdown deadlocks that was discovered after RC4, among other things. That OS is simply just too old.

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 19th October 2014, 21:08   #255  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Kolak
I knew the Stoik Capture Tool and stopped using that a long time ago because it's not very reliable in keeping the Audio in Sync with the Video, but thanks anyway

@Ignus
About the RGB Output:
When i loaded a MagicYUV Capture in VirtualDub and selected the "Fast recompress" Mode with XviD as a Target Codec, no matter which VirtualDub Version (1.6.19 to 1.10.4), showed "RGB888" as a Target Format for XviD instead of YUY2. Same thing with a HuffYuv encoded File in VirtualDub, but shows "YUY2" as a target Format for XviD, not "RGB888".

By looking in the File Details Description of a XviD Video in the Windows Explorer, encoded with MagicYUV the XviD File says "24 Bit" while a HuffYuv/Lagarith encoded Video to XviD shows "16 Bit" under Color Depth.

I also tried the YUV Capture Module from MoviePack Pro using YUY2 for NTSC 4.43, saved in RAW YUY2 (!), opened that Capture in VirtualDub, used "Fast recompress", selected once the HuffYuv Codec, then the MagicYUV Codec. Result: Same distortion in the Image with MagicYUV while HuffYuv was clean.

The Capture Settings where:
Resolution: 720x480
Format: NTSC 4.43
Frame Rate: 29.97 Fps
Color Space: YUY2 4:2:2 16 Bit Uncompressed
Interlaced: Yes
Field Order: Bottom Field First (Lower Field / Even Field First)
Audio: 48.000 kHz, 16 Bit Stereo PCM
A/V Interleave: 1:1 (Every 1 Frame)

Same Settings with the simple Microsoft "Amcap" Tool, no difference. As soon as MagicYUV or UtVideo is used for Material that is NOT captured "TFF", then you get the Result that I made available where HuffYuv encodes the capture correct. I compared a direct re-compress with VirtualDub from the HuffYuv encoded Sample to YUY2, same as the Capture, no difference between RAW YUY2 and re-encoded from HuffYuv.

Note:
I tried the Multithreaded Version of HuffYuv (huffyuv_mt.dll), perfect, just like the HuffYuv CCESP Patch 0.2.5 that i use. Further: Lagarith (Version 1.3.23 for Win2K) also keeps track of the correct Field Order. Lagarith is one of the derivative Codecs of the HuffYuv Source Code.

About Win2K:
Yes, it's old, not the newest, but works fine and reliable for me what i can't say from the 2 Years I tried XP, nothing but Trouble and Problems with it. Booting Win2K is a matter of 20 seconds and my Machine is up and running, ready to go. With XP i went down to the Kitchen, made some fresh Coffee and when i came back after about 5 minutes it was just about done. No thanks, no need for a OS like that. BTW: The Win XP (SP2) came from the Dell Support, "optimized" for my Workstation and the later Dell update CD for SP3 made things even worse.

Further, Dell, who customized the Workstation for my needs, strongly recommended Win2K for being far more stable, faster and reliable. Guess what, they where right. Plus, for my kind of work i need something that does not hang every 5 Minutes. And yes, i even tried Win7, skipped the "fat" Vista and "Playtool" 8. A alternative ? Certainly not for me and takes even longer until everything is ready, far away from a RTOS like Win2K.

I refuse to work with a OS that takes several hours for a 1 Hour Documentation when Win2K does exactly the same thing in 12 Minutes. My Family would kill me if i spend my Time with watching for Hours the Screen until it's done. And my Clients would look for somebody else if i tell them that they get the Material back in 2 Weeks instead of a couple of Days.

Win2K works for me without any Problems, stable, reliable, fast, without Blue Screens or System hangs and nothing on this Planet will make me change to another Windows OS. If it works for you and all the others, that's fine with me, it did not work for me. But please, let's leave this excursus about OSes and hope you understand why i stick with Win2K, okay ?

Just to let you know: For the moment I uninstalled MagicYUV and UtVideo from my System because of this Problem. MagicYUV and UtVideo are real great Codecs, but still seem to have some Problems and HuffYuv served me reliably well over the Years without any Problems. I really hope you and the Author of UtVideo can find the Problem what's causing this.

So, there is nothing i can do any more from my end to help you solve this Problem, I wrote and described you everything that I know and observed. Still, don't give up, sometimes it's those small simple things that can cause a big Headache filled with Question marks

Cheers

Mick
Mick is offline   Reply With Quote
Old 19th October 2014, 22:11   #256  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Now this is very interesting.
Could you send that raw YUY2 sample as well? I would be really interested and would like to try it on my machine to see the issue, and that would help a LOT, as I might have a chance to reproduce the problem on my machine.

Also, can you send the sample which reports RGB888 to xvid?

Quote:
So, there is nothing i can do any more from my end to help you solve this Problem, I wrote and described you everything that I know and observed. Still, don't give up, sometimes it's those small simple things that can cause a big Headache filled with Question marks
You can
By sending the raw YUY2 sample and the other MagicYUV compressed sample which reports RGB888, that would allow me at least a chance to fix the problem.
I do not have any sort of capture hardware, so without those samples, it is simply impossible.

So, if you have a little more time, I would really appreciate those samples.

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 19th October 2014, 23:14   #257  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
And another thing. Invest money into proper capture tool.
I would suggest GrassValley Edius.
There is 30 days fully working demo.
kolak is offline   Reply With Quote
Old 20th October 2014, 21:31   #258  |  Link
Mick
Registered User
 
Mick's Avatar
 
Join Date: Nov 2013
Location: France
Posts: 52
@Kolak
i have a very good Capture Module with my Movie Pack Pro from Aist Cinegy that keeps everything in perfect Sync, including the access to all the Settings for all TV Norms. Edius is nice but not that what I need for my Work. Thanks anyway for the Tip

Plus, I really don't think that it's a VirtualDub Capture Problem. I tried it again with the Stoik Capture Tool, the Microsoft WMV9 Amcap (original, not the commercial AMCAP), the Debut Capture Tool from NCH Software, the Logitech Capture Program and the NeroVision Capture Module (Nero Suite), all resulted with the same Field Order in NTSC 4.43 (BFF), no difference for I420, YUY2, YV12, UYVY or other Colorspaces.

I even tested Paul Glaga's "CaptureFlux" Tool without any difference what so ever:
http://paul.glagla.free.fr/index_en.htm

Other Tools tested: Grabshow, Video View, Syntech, Empia and QSonic Capture Tools, no difference, means from my point of view that VirtualDub works fine what capturing concerns.

All Capture tests with the different Tools where done once with the native Windows YUV Codecs without the Drastic YCbCr Codecs and once again with the Drastic YCbCr Codecs installed, no difference, just to exclude that the Drastic YCbCr Codecs might be the Problem, but they are not. All NTSC 4.43 captures where BFF conforming to the norm with all Tools.

@Ignus
You already have a MagicYUV File that Reports RGB24 (RGB888) to XviD: The Sample you downloaded Since I tried MagicYUV, all Files reported RGB24 (RGB888) to XviD, never YUY2, regardless what Output Settings i used in the MagicYUV Config. Again, I left the Video Input at "Auto Detect" and the Video Output at "Same as Input", trying it with "Fast recompress" and "Normal recompress".

HuffYuv/HuffYuv_MT and Lagarith always reported in both recompress modes YUY2 to Xvid where MagicYUV and UtVideo always reported RGB24 (RGB888) to Xvid. A Win2K Issue ? No, because i tried the same thing with a small short Video on a Laptop with XP (SP3) using HuffYuv, Lagarith, MagicYUV and UtVideo, same result like under Win2K. HuffYuv/Lagarith reported YUY2 to Xvid, MagicYUV/UtVideo reported RGB24 (RGB888) to XviD.

And the RAW YUY2 ? It's really simple, open the HuffYuv Sample you downloaded in VirtualDub, select YUY2 for Output and use under Compression "Uncompressed YCbCr/RGB". This is the same as any other RAW YUY2 File that I would upload, verified with a uncompressed NTSC 4.43 Capture, both RAW YUY2 where exactly the same.

If you do really, really need another RAW YUY2 Sample, then I see when I get down to it and upload it via "Wetransfer", okay ? But this Time without Sound and in 640x480 instead of 720x480 to keep the Size down a bit. Would 10 seconds be enough ?

I really hope this helped you a bit further. BTW, did you or anybody else inform the Author of UtVideo about this Field Problem ?

Cheers

Mick

Last edited by Mick; 20th October 2014 at 22:49.
Mick is offline   Reply With Quote
Old 21st October 2014, 02:49   #259  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
I don't see the problems you mention. The MagicYUV file gets correctly reported as YUV 4:2:2. I get the following log for Fast Recompress of the MagicYUV file you sent with 32 bit VirtualDub to XVID:

Code:
[*] AVI: Opening file "E:\_vid\bugreport\MagyTest.avi"
[*] Beginning dub operation.
[i] Dub: Fast recompress mode started with format: UYVY.
MagicYUV can decode compressed YUV 4:2:2 to both YUY2 or UYVY, whichever is requested.

For Normal Recompress with output set to "Same as decompression format" and input to "Autodetect" I get this for MagicYUV:

Code:
[*] AVI: Opening file "E:\_vid\bugreport\MagyTest.avi"
[*] Beginning dub operation.
[i] Dub: Recompressing using format: RGB888.
and this for HuffYUV:

Code:
[*] AVI: Opening file "E:\_vid\bugreport\HfyuTest.avi"
[*] Beginning dub operation.
[i] Dub: Recompressing using format: RGB888.
So in Normal Recompress BOTH report RGB. In Fast Recompress BOTH report YUV correctly.

I also tried to create the raw YUY2 file from HuffYUV. It looks correct. I then compressed the raw YUY2 file with MagicYUV: it also looks correct, moreover compared with Avisynth it is bit-by-bit identical to the HuffYUV encode.

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

Last edited by Ignus2; 21st October 2014 at 03:07.
Ignus2 is offline   Reply With Quote
Old 21st October 2014, 16:19   #260  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,344
Don't trust Vdub blindly.
Set color depth as desired instead of hoping it that everything will work as needed.
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 07:14.


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