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 29th May 2014, 15:37   #141  |  Link
Ghostlamer
Registered User
 
Join Date: Aug 2009
Posts: 25
Ignus2, could you add an option, something like this "forced decoding YUV 4.0.0, 4:2:0, 4:2:2, 4:4:4 as RGB".
There are non-linear video editors that support YUV 4.0.0, 4:2:0, 4:2:2, but convert it to rgb(on the fly), do it not very correctly, resulting in slightly incorrect brightness and color output.
Converting videos to RGB, takes up more space and time.
Forced codec decoding in RGB, in most cases will work around this problem.
Input will be RGB, and the editors will not make any color conversions.
But make it disabled by default.
Thanks.

Last edited by Ghostlamer; 29th May 2014 at 16:23.
Ghostlamer is offline   Reply With Quote
Old 29th May 2014, 21:53   #142  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Ghostlamer View Post
Ignus2, could you add an option, something like this "forced decoding YUV 4.0.0, 4:2:0, 4:2:2, 4:4:4 as RGB".
There are non-linear video editors that support YUV 4.0.0, 4:2:0, 4:2:2, but convert it to rgb(on the fly), do it not very correctly, resulting in slightly incorrect brightness and color output.
Converting videos to RGB, takes up more space and time.
Forced codec decoding in RGB, in most cases will work around this problem.
Input will be RGB, and the editors will not make any color conversions.
But make it disabled by default.
Thanks.
So instead of the NLE software, you want the codec to do the conversion, always? The reason being NLE software do it incorrectly?

So this means, you want to be able to disable decompressing into native format. Or something like "Always suggest RGB when decoding"?

So if I understand correctly, you want to store material compressed always as YUV 4:x:x but edit it in RGB?

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 29th May 2014, 23:02   #143  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Isn't this already available since you added the "Avisynth Fix"?
zerowalker is offline   Reply With Quote
Old 29th May 2014, 23:18   #144  |  Link
Ghostlamer
Registered User
 
Join Date: Aug 2009
Posts: 25
Quote:
So instead of the NLE software, you want the codec to do the conversion, always?
So this means, you want to be able to disable decompressing into native format. Or something like "Always suggest RGB when decoding"?
So if I understand correctly, you want to store material compressed always as YUV 4:x:x but edit it in RGB?
Yes, that's right.
To force the output was always RGB.
Just most nonlinear editors make conversion from YUV 4:x:x to RGB in realtime(even when the codec RGB options enabled), if the source is not the RGB.
And do it in different ways, some better some worse..

Last edited by Ghostlamer; 29th May 2014 at 23:27.
Ghostlamer is offline   Reply With Quote
Old 29th May 2014, 23:20   #145  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by zerowalker View Post
Isn't this already available since you added the "Avisynth Fix"?
No, as it currently prevents upsampling only, but you cannot disable decoding to native format of what was compressed (i.e. cannot prevent lossless decompression without conversion).

What Ghostlamer needs is the opposite: to prevent decoding into native format and allow only upsampling/conversion.

Whether this scenario makes sense for a lossless codec is another question

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 29th May 2014, 23:37   #146  |  Link
Ghostlamer
Registered User
 
Join Date: Aug 2009
Posts: 25
Certainly at the codec level it will be more correct than in the editors.

Quote:
What Ghostlamer needs is the opposite: to prevent decoding into native format and allow only upsampling/conversion.
Make it optional.

Сurrent decoding options:
For player - 1, 2.
Video editing software (Magix Video Pro X6) - useless.

Last edited by Ghostlamer; 30th May 2014 at 00:33.
Ghostlamer is offline   Reply With Quote
Old 30th May 2014, 00:34   #147  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by Ghostlamer View Post
Certainly at the codec level it will be more correct than in the editors.


Make it optional.

Сurrent decoding options:
For player - 1, 2. http://simplest-image-hosting.net/
Video editing software - useless.
It would be quite funny making it non-optional, that would basically defeat the purpose of the codec

The Decompression settings currently refer to conversions only, so decoding to the native format (ex. to YV12 from compressed 4:2:0) is currently always possible.

Maybe I'll add the settings to the next release.

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 May 2014, 00:39   #148  |  Link
Ghostlamer
Registered User
 
Join Date: Aug 2009
Posts: 25
Quote:
Maybe I'll add the settings to the next release.
Thanks.
Ghostlamer is offline   Reply With Quote
Old 31st May 2014, 15:27   #149  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,181
Hey Ignus,

It's been a while since I tested Magic-YUV, not since those early tests with your pre-release versions in fact. But I'm happy to report that version 1.0rc2 now works very well with my AVCHD and HDV camcorder clips in the NLE I use - Corel VideoStudio Pro x6.

VSPx6 is still only 32-bit and performs edit transformations in RGB colorspace. As such, any compatible third party vfw codecs need to be able to convert from and to RGB. It's pretty useless for 'native editing' of AVCHD and HDV, but the 'smart rendering' feature works well with intra-frame intermediate formats and the program has very good MT process support.

My current practice is to pre-transcode the source clips to the intermediate format via AVISynth using a suitable frame-indexing decoder (DGIndex/Dec for HDV MPEG-2 and now DGIndex/DecIM for AVCHD). VDub is set for Fast Recompress so Magic YUV should be receiving YV12 input anyway, but as a precaution (perhaps unnecessary) I've configured Magic YUV with the Input Colorspace set to YUV 4:2:0 and the Mode Conversion set likewise.

The transcodes look fine and play very well. UTVideo is also fast, but playing the files in MPC-HC, there's always a bit of stutter and unresolved offset delay. The Magic YUV encodes play very smoothly and the initial sync delay resolves very quickly. I haven't done any repeat comparative metric testing with this version but the fast decompress rate definitely shows.

So, then I load the Magic YUV (avi) encodes in VSPx6 and set the edit Project to use Magic YUV as the timeline format. You might re-call that when I tried to do this with the pre-release versions, VSPx6 always crashed and would only work if I installed an intermediary transform codec like the YUVFilters pack. Now, no such problems provided the Magic YUV input colorspace is set to Auto or RGB. Set to anything else and VSPx6 complains for lack of a suitable compressor. I have the Mode (conversion) set to YUV 4:2:0.

So configured, the Magic YUV encodes edit very smoothly on my PC at least (6-core AMD FX600 CPU) and it looks like the 'smart rendering' is working fine i.e. when set to render out in the same format as the Project (or the format of the 'first clip') it only re-encodes those frames affected by an an applied edit effect/transform and copies the unaffected frames. Unfortunately there's no 'Smart Render' analysis feature to show that definitely, but it looks to be the case just looking at the rendering progress bar.

All in all, very impressive. I'd been using UTVideo or Cineform until now (each have their pros/cons), but I could see myself using Magic YUV; I assume it's bug free?

So, great work, and no doubt assisted by the valuable feedback of those who could contribute more useful insight and advice than I.

Cheers
__________________
Nostalgia's not what it used to be

Last edited by WorBry; 2nd June 2014 at 17:39.
WorBry is offline   Reply With Quote
Old 3rd June 2014, 15:07   #150  |  Link
Gravitator
Registered User
 
Join Date: May 2014
Posts: 170
Hi!
Can we expect a higher compression? Or two passes > sample
Gravitator is offline   Reply With Quote
Old 10th June 2014, 01:12   #151  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Quote:
Originally Posted by Gravitator View Post
Hi!
Can we expect a higher compression? Or two passes > sample
higher compression can most likely be made one way or the other while keeping the performance. It would probably be quite minimal though as the huge optimizations has probably been made already.

2 passes is probably not something for this kind of codec, which is made for speed in both encoding and decoding (especially decoding), and i think the increase in compression efficiency is probably not worth it during these kind of works.

I personally however, would probably want it if it can decrease the size by at least 5%, while keeping the same decoding speed.

(The author is most likely to correct if i have said anything that's incorrect here).
zerowalker is offline   Reply With Quote
Old 10th June 2014, 08:18   #152  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,394
I think you are correct- any compression improvements while keeping speed will be in region 5, best 10%. Quite often this is a huge effort and all what you get is this 5%. I think magyuv is really good with speed ratio/compression.
kolak is offline   Reply With Quote
Old 10th June 2014, 20:54   #153  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Quote:
Originally Posted by kolak View Post
I think you are correct- any compression improvements while keeping speed will be in region 5, best 10%. Quite often this is a huge effort and all what you get is this 5%. I think magyuv is really good with speed ratio/compression.
Agree, MagicYUV is doing extremely well, it's competing at UT Video Codec, it's in the middle of the compression choices of the 2 settings (compress for decoding/size or something like that).

Which in itself is very nice, and clearly acceptable in lossless format sizes.

Decoding speed is in a different league, it's extremely fast, especially in cases were it usually is slower (much noise,grain etc).

I don't really see any "Real" reason for it to be smaller, faster is another story, there isn't a thing as too fast, but it's currently clearly enough for what it's supposed to do.


However if you need more speed, the author has shown interest in AMD Kaveri, which is a hybrid CPU and GPU, which could increase the performance, as it decreases overhead and such, how much however is another story, and we will have to wait till/if he decides to do this work.
zerowalker is offline   Reply With Quote
Old 12th June 2014, 02:41   #154  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Sorry for being absent, I have been busy with personal matters.

In the meantime, MagicYUV 1.0rc3 is out: Link.

This release includes:
  • Option to suggest RGB first on output when decoding in the Decompression Settings (as requested by Ghostlamer).
  • Fix for RGBA encoding which was completely broken. An option was added to the encoder dialog, see the tooltip on how to use it.
  • Fix for a very rare crash-bug when decoding. Newly encoded videos will have it fixed.
  • Support for some new fourccs (2vuy, HDYC, IYUV).

@WorBry Thanks and sorry for the late answer. Nice to hear that the codec finally works with the software you use All insights and testing is welcome. I really missed RGBA testing though, I accidentally found someone having problems on a German forum, and I only began investigating after that.

@Gravitator Not in the near future. It is hard to improve compression ratio without slowing down the codec, especially if we want to keep it intra-only (making it inter is also non-trivial). So for the foreseeable future, it will remain as it is.

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

Last edited by Ignus2; 12th June 2014 at 03:20.
Ignus2 is offline   Reply With Quote
Old 12th June 2014, 02:51   #155  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Quote:
Fix for a very rare crash-bug. Newly encoded videos will have it fixed.
Could you please explain this?

Does videos that are previously encoded contain a bug which causes or crash when decoded or what;S?
zerowalker is offline   Reply With Quote
Old 12th June 2014, 02:57   #156  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by zerowalker View Post
Could you please explain this?

Does videos that are previously encoded contain a bug which causes or crash when decoded or what;S?
Basically yes, it MIGHT happen. Actually, it was there since the launch of the codec since February (and even years before, ever since the codec started to take shape), but even I encountered it only once so far with a combination of software AND material (YUV with alpha format converted to RGBA).

So chances are low.

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 12th June 2014, 03:01   #157  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Okay so i don't have to worry about my current files having a chance of being corrupt?
It's basically, a crash MAY occur if conditions are met, but at the same time if you redo it, it may not crash? (Or is it constant?).

And well what i have is simply YV12 YV16/YUY2 YV24 or RGB, have no memory of ever using YUV with Alpha, didn't even know it had that option.
zerowalker is offline   Reply With Quote
Old 12th June 2014, 03:14   #158  |  Link
Ignus2
Registered User
 
Join Date: Dec 2005
Posts: 249
Quote:
Originally Posted by zerowalker View Post
Okay so i don't have to worry about my current files having a chance of being corrupt?
It's basically, a crash MAY occur if conditions are met, but at the same time if you redo it, it may not crash? (Or is it constant?).

And well what i have is simply YV12 YV16/YUY2 YV24 or RGB, have no memory of ever using YUV with Alpha, didn't even know it had that option.
It's constant, not sporadic. For example, I had it happen for one specific frame of one specific file in a specific format with After Effects, while VDub and Media Player Classic and all my test tools were fine with the same file.

Furthermore, some clarification: Any file encoded with any release before 1.0 final is reached should be considered corrupt in one way or another, not specifically because of this bug but because it is beta software and as such, bugs may be present, even ones that I'm not aware of. This is a general thing for all software not being reached 1.0 stable status.

Anyway, if your files open now correctly in VDub, why worry?

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

Last edited by Ignus2; 12th June 2014 at 03:19.
Ignus2 is offline   Reply With Quote
Old 12th June 2014, 04:26   #159  |  Link
zerowalker
Registered User
 
Join Date: Jul 2011
Posts: 1,100
Okay that explains it

Thanks
zerowalker is offline   Reply With Quote
Old 12th June 2014, 17:24   #160  |  Link
WorBry
Registered User
 
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,181
Quote:
Originally Posted by Ignus2 View Post
@WorBry Thanks and sorry for the late answer.
No problem
__________________
Nostalgia's not what it used to be
WorBry 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 21:17.


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