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. |
29th May 2014, 15:37 | #141 | Link |
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. |
29th May 2014, 21:53 | #142 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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... |
|
29th May 2014, 23:18 | #144 | Link | |
Registered User
Join Date: Aug 2009
Posts: 25
|
Quote:
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. |
|
29th May 2014, 23:20 | #145 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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... |
|
29th May 2014, 23:37 | #146 | Link | |
Registered User
Join Date: Aug 2009
Posts: 25
|
Certainly at the codec level it will be more correct than in the editors.
Quote:
С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. |
|
30th May 2014, 00:34 | #147 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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... |
|
31st May 2014, 15:27 | #149 | Link |
Registered User
Join Date: Jan 2004
Location: Here, there and everywhere
Posts: 1,197
|
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. |
10th June 2014, 01:12 | #151 | Link | |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Quote:
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). |
|
10th June 2014, 08:18 | #152 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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.
|
10th June 2014, 20:54 | #153 | Link | |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Quote:
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. |
|
12th June 2014, 02:41 | #154 | Link |
Registered User
Join Date: Dec 2005
Posts: 250
|
Sorry for being absent, I have been busy with personal matters.
In the meantime, MagicYUV 1.0rc3 is out: Link. This release includes:
@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. |
12th June 2014, 02:57 | #156 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
So chances are low. Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
|
12th June 2014, 03:01 | #157 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
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. |
12th June 2014, 03:14 | #158 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|