View Single Post
Old 6th October 2014, 11:25   #217  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 250
Quote:
Originally Posted by Mick View Post
Hi there,
i downloaded RC5 and 1.0 for my Win2K Pro System and the Configuration Tool for the Codecs simply Reports the Error Message "Function not supported" and quits.
That's possible. The minimum supported OS is Windows XP, the fact that it worked with anything below that was pure luck. Sorry.

Quote:
Originally Posted by Mick View Post
The MagicYUV Codec in Versions RC5/1.0 is about 20 Frames slower (!) with a higher CPU (28-35 % more) load than the RC4 that caused no trouble with Win2K Pro (SP4). Sure, i could step up to another OS but i don't want that for several reasons, so let's leave that Discussion out right now.
There has been no change algorithm-wise between RC4 and RC5/1.0, so the cause is something else here.

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

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

Quote:
Originally Posted by Mick View Post
Further, "VideoPad" from NCH rejects to load AVI's encoded with MagicYUV, regardless of the settings and FourCC's used.

You can find the Software here and test it yourself:
http://www.nchsoftware.com/videopad/index.html
I tried the software, and it loads MagicYUV encoded files perfectly for me.

Quote:
Originally Posted by Mick View Post
Further, if the "UtVideo" Codec is also installed on W2K (SP4)/XP (SP3), then MagicYUV seem to "stutter" at Resolutions over 4K encoding/decoding Video. I noticed this with the UtVideo Codec Version 13.3.1 and believe it's the included DMO Module from UtVideo that causes Problems. When UtVideo is removed from the System, everything is back to normal with MagicYUV. Plus, MagicYUV co-exists fine with Lagarith and HuffYuv without any Problems.
That can happen. I also noticed, that the UtVideo DMO sometimes gets inserted to do needless colorspace conversion or even encode to Ut and then back (!) for no reason.

Quote:
Originally Posted by Mick View Post
Speaking of UtVideo/VirtualDub and "v210" 10 Bit: Both produce Videos that can not (!) be played on OptiBase, AJA/Kona or DVS I/O Boards. The only Codec so far is the Drastic Codec that fully conforms to the Industrial standard and Definition for 10 Bit. So, if you plan to develop in this "10 Bit Playground", chances are that it won't work with professional Equipment.
The raw v210 AVI produced by the latest (!) VirtualDub conforms to the v210 spec (it was buggy with earlier VDub though!).
I also had someone test my codec with v210, and it played back fine.
But we can discuss/test more about this if you want.

Quote:
Originally Posted by Mick View Post
Still not solved:
MagicYUV RC4 still reports "RGB24" to other Codecs with VirtualDub (Version 1.6.19 - 1.10.4) no matter how the Settings are with the "Fast Re-compress" and "Normal Re-compress" Modes. HuffYuv and Lagarith use the Color-space they encoded (YV12/YUY2) the Video with.
MagicYUV does the same, it reports the colorspace that was encoded. If it always reports RGB (despite all conversion options disabled in the "Decompression Settings"), then the encoded data has to be RGB.

Quote:
Originally Posted by Mick View Post
Interlaced Mode with MagicYUV only takes the TFF (Top Field First) which is the same for all HD Modes, but in SD Resolutions for NTSC with BFF (Bottom Field First) the Image is distorted.
Yes, the codec assumes TFF for now.
There is actually no way of knowing if the input is TFF or BFF, but I can include an option for the encoder settings.
What I would like to know is what to do on the decoder side? So for example if I encode BFF, should I also output BFF when decoding? Or always TFF, regardless of the what was encoded (so to swap the fields)? I would need some help with this.

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

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