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. |
28th April 2014, 23:45 | #81 | Link | |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Quote:
Last edited by foxyshadis; 28th April 2014 at 23:48. |
|
29th April 2014, 01:37 | #82 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
Sadly, the AVI Decompressor doesn't seem to pass down the stride info, it always passes biWidth as the real width. Maybe it has compatibility reasons, probably VFW was never meant deal with aligned strides :/ Thanks for the help! Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... Last edited by Ignus2; 29th April 2014 at 01:40. |
|
29th April 2014, 02:06 | #83 | Link |
Angel of Night
Join Date: Nov 2004
Location: Tangled in the silks
Posts: 9,559
|
Do you plan on releasing a DirectShow or Media Foundation codec? You should be able to put all the interfaces within the same dll, too, and it would be handy for some scenarios, like DShow video capture.
|
29th April 2014, 18:03 | #84 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
BTW, can't DShow capture use AVI Compressor filter for compression the same way as AVI Decompressor is used for decompression? Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
|
30th April 2014, 06:24 | #85 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Does VFW in itself do any limitations to Codecs, i mean performance wise etc?
Cause i always read that it's ancient and no good, but as it's always used i can't imagine there to be anything directly wrong with it, except that perhaps it's hard to adapt to stuff, but also hard to replace as it's so common (Like DirectX in the Graphic world). A bit off topic, but as it was mentioned, also i mean to direct this towards Lossless rather then lossy which often has it's own design. |
1st May 2014, 17:10 | #86 | Link | |
Registered User
Join Date: Dec 2005
Posts: 250
|
Quote:
It is easy to develop for VFW and it is widely supported, but basically those are it's only advantages. Greets, I.
__________________
http://magicyuv.com - MagicYUV: a new fast lossless video codec for the 4K and multi-core era... |
|
1st May 2014, 22:54 | #87 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Ah so it has performance issues, not sure how it works, but all in all that doesn't bode to well, especially as VFW is currently as common as anything can be, like mp3 for Music i guess.
Don't even know applications that use other interfaces, though i primary use Virtualdub, and then again i only know how to use VFW. Thanks for telling, hopefully you can add other interface support sometime you think it matters, as the codec itself is probably the main focus as that increases performance/usefulness overall. Edit: Oh also, Lagarith is another lossless codec which you probably know of, and it has some extremely well compression when it comes to Pixelated videos, like old games, where the resolution is low, and even if you increase it, as long as it's "Nearest Neighbor" it still compresses very well. Can MagicYUV do this as well, i doubt it can as it's probably to do with the bitstream or something, but if possible it would be great, else Lagarith itself fit's into that of course. Last edited by zerowalker; 1st May 2014 at 22:57. |
4th May 2014, 03:58 | #88 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Noticed talk about Rec.709 etc and how some want it to go with the width < 720 = Rec.601, so would like to put a suggestion to this.
UT Video Codec has Rec.601/709 separate (it also has it's formats separate, which may be handy), and i find that pretty appropriate, as for example, there is no actual rule that says when it's Rec.601 or 709, you normally just say, "If it's Not HD, than it must be Rec.601", this is in most cases true, but not always. In the TV world, i think that term is always true (may be wrong), but in the PC world it's not, if you record something on the PC (not talking capture cards here), it will always be Rec.709 as far as i know, doesn't matter the resolution. While separate Devices, Webcams, Capture cards etc probably follow the rule more or less. That's why it may be handy to have Rec.709 and Rec.601 separate, if you record on the PC (Gaming etc) you always want Rec.709, and it would be quite messy to always change the settings if you also use Virtualdub, to capture Webcam or other stuff that may use Rec.601. Well, think i went overkill with the wall of text, but hope it makes some sense, at least it does to me;P |
4th May 2014, 12:42 | #90 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Oh, skipped some lines there.
Yes PC is RGB, i meant that when you encode it to YUV Rec.709 produces the correct color. However, i tried MagicYUV after this, and both 601/709 look identical, so this just get's me confused. Pretty sure that all other codecs, at least Lagarith and UT Video produces wrong colors if they are Rec.601 (Lagarith is forced at that). |
4th May 2014, 12:53 | #91 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
It makes sense, but if we have rules, possibility to ovewrite and info is stored in the headers for the decoding stage than there is no need for a separate fourCC.
601/709 looks very similar and on some frames you can't really tell the difference, untill you flip between them. Last edited by kolak; 4th May 2014 at 16:04. |
5th May 2014, 08:32 | #92 | Link |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
It's not like you're implying. If you have RGB you have RGB, there is no "correct" way to convert it to YUV. You're probably referring to the fact that Fraps (a specific codec) converts that RGB to YUV using always 709 when encoding in YUV mode, regardless of resolution. This is true, but it's a Fraps thing, nothing general.
|
5th May 2014, 10:37 | #93 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Hmm, i really don't get it anymore;S
I mean, sorry for a bit off topic, but, let's say i have something that's RGB, anything at all. If both Rec.601/701 is "correct" when downsampling, why does different versions even exist? I thought that Rec.601 is and old version, and Rec.709 is an updated, meaning it contains, more colors or information etc, and then Rec.2020(or what the name was) is the latest and greatest? But if all achieve the same thing, and the information is only there to tell it (Decode it with this and it will look correct), it doesn't make sense to have more than one? Am i missing something here, or can you just skip and use one of them for everything? |
5th May 2014, 18:37 | #94 | Link |
Registered User
Join Date: Sep 2005
Location: Vancouver
Posts: 600
|
Rec.601 and Rec.709 describe slightly different "triangles" in the whole space of all possible colors, and Rec.2020 describes a vastly expanded one (this page has a diagram representing the gamut of 601 vs 709 -- elsewhere you can find ones comparing 709 to 2020). To see a difference between an RGB image correctly matrixed to/from 601 vs 709, I believe you would need to pick one with colors that are encompassed by only one of those two triangles and a display capable of rendering them correctly.
There is a lot of debate about the reasoning behind Rec.709 and whether the benefits outweigh the issues, but 2020 has the clear goal of being able to represent a larger color gamut. Last edited by ChiDragon; 5th May 2014 at 18:41. |
5th May 2014, 20:36 | #95 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
601 was chosen with CRT technology in mind, where 709 for Plasmas/LCDs. Small differences are due to different nature of display technologies.
Rec2020 is very new and currently there is not a single publicly available display which can cover its whole spectrum. |
6th May 2014, 08:10 | #96 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
But if you take an image from your PC, then convert it to YV12 or something.
The Recxxx doesn't even matter, the result will be the same as long as you decode it to RGB with the correct flag. This is what i don't get, they look identical. If the only way to see the differences is playing around with color triangles etc, then that doesn't make any sense, at least when it comes to simple RGB-> YUV. EDIT: Okay actually looked more carefully, there is a difference that is viewable, so forget the "Identical" part. Can't say which one looks best though, both get gradients of different kinds and handle some parts differently, But, i am guessing Rec.709 should be overall better as it's an improved Rec.601? The point of them is to increase the colors right, meaning it get's closer to RGB? Last edited by zerowalker; 6th May 2014 at 08:23. |
6th May 2014, 08:42 | #97 | Link |
4:2:0 hater
Join Date: Apr 2008
Posts: 1,302
|
If you convert RGB to YUV with a specific rec and then back to RGB with the same rec you shouldn't see any significant difference between both RGBs. At least I am yet to meet someone that can tell which matrix was used in a conversion, or that there was a conversion in the first place, when faced with both the original RGB and the properly reconstructed RGB after the RGB->YUV->RGB conversion. If you see significant differences, then you're probably doing something wrong. Use 4:4:4 for comparisons obviously.
|
6th May 2014, 08:48 | #98 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Yeah did that just now, and as said, the only thing that's really different, are dark areas, where gradients show, these parts will alter.
I can't however tell which is right or which is wrong, but it differs, but in bright normal colors, the difference is pretty much non-existent to what i can see. However, as discussed before, though with Lagarith if i remember correctly, it would be interesting to see support for YCoCg, it's an interesting format, however it's never really used. But if my memory serves correctly, it's like YUV but losslessly reversible to RGB, or something along the line? |
6th May 2014, 18:10 | #100 | Link |
Registered User
Join Date: Jul 2011
Posts: 1,121
|
Ah, don't get it fully, but think i at least follow the idea;P
How is Rec.2020 then, some kind of killer or pretty much the same, And will support be added for it in MagicYUV? I know it doesn't exist a real interest except experimentation and enthusiasm, but still it never hurts to be on the edge of things, especially since it aims to be the "4K Lossless era Codec" |
Thread Tools | Search this Thread |
Display Modes | |
|
|