Does RV9 Codec Support's YV12 Video Stream? (@karl_lillevold) only, system, future, posted

andy

Hello

Does RV9 Codec Support's YV12 Video Stream? (As a Source and Target)

If the answer is NOgt; Then is there any Plans to Implement this In A future Release of RV Codec?
Thanks

Originally posted by Ramirez
Does RV9 Codec Support's YV12 Video Stream? (As a Source and Target)

If the answer is NOgt; Then is there any Plans to Implement this In A future Release of RV Codec?

Answer in 2 parts.

YV12 as source: yes, but only if you have VFW codec on your system for this format.  It is not very common as a source format, and none of my capture devices support it. However, the codec's native format is I420 (or IYUV), which is YV12 with U and V flipped, which is more common.  You may have VIDC.IYUV = iyuv_32.dll on your system (if you have WinXP), which is capable of both decoding and encoding to IYUV, in case you want to try.  It is this format which encodes the fastest with RealVideo.  Next are YUY2 and UYVY, the two most common YUV capture formats, which are converted without going via RGB.  Other formats, incl YV12, will go via RGB.  It would be easy to handle YV12 fast as well, so if this is a problem, let us know, but for now, stick with I420 (IYUV), YUY2, or UYVY for the fastest possible encoding.
reference: fccyuv.htm

YV12 as target: I am not sure what you mean here, but if you mean sending YV12 to the video card, then the answer is yes.  For ATI cards, we convert to YV12 from I420 (very quick conversion), and ATI cards will then display YV12 natively.  For nVidia we choose YUY2 (or UYVY - I don't have an nVidia card readily available to check).  For Matrox it might be I420 directly.   In all these cases, there is very little overhead.   In case you meant something else, please clarify.

quote:
--------------------------------------------
12 as target: I am not sure what you mean here
--------------------------------------------
what I actually meant is: does the RV9 Codec support AviSynth v2.5 alpha witch support YV12 stream output lt;IN TERMS OF DVD CONVERSION ONLYgt;
this quote came from wonderful Sticky By Wilbert.
quote:
-------------------------------------------------------------------
7.What will be the main advantages? (Of using YV12 Color Space)
- Speed increase:
That depends entirely on the external plugging whether they will have YV12 support or not. Speed increases like 25-35 percent are expected. Of course there will only be a large speed increase if both your source and target are in YV12, for example in DVD to DivX/Xvid conversions.
--------------------------------------------------------------------
This is exactly what I've meant when I wrote YV12 as a Target.
(I should be more specific next time, sorry for that)

Thanks a lot for you Patience

).  It's not hard (flip U and V), we just did not realize the usefulness, and well, it hasn't really been useful before Avisynth YV12  Thanks for the pointer.

I would have recommended you get the source and submit a patch to the helix community, but it will take just a little while longer before our DirectShow reader is open-sourced. It has the problem of needing to include windows header files  and is currently distributed in binary form.

It has the problem of needing to include windows header files  and is currently distributed in binary form.

If that is a problem, I believe Milan re-implemented enough of the DirectShow API to avoid requiring any quot;windows header filesquot; in ffdshow.

Perhaps you could acquire permission to relicense the code in question.

-h

Originally posted by karl_lillevold
It sounds like we need YV12 as a supported input format for helix producer

I should add that YV12 will work just fine as input format right now as long as you have a VfW codec on your system for YV12.  The problem is that a double color conversion YV12-gt;RGB-gt;I420 will take place, which of course slows down the process significantly.Originally posted by -h
If that is a problem, I believe Milan re-implemented enough of the DirectShow API to avoid requiring any quot;windows header filesquot; in ffdshow. Perhaps you could acquire permission to relicense the code in question.

With regards to the source for the DirectShow filter, it will be available shortly, but I am not sure through which process, with regards to implementation or header files.

For those who have signed up at helixcommunity you can now check the status of this issue at
froms--producersdk.helixcommunity.o...w_bug.cgi?id=3
If you think this is an important feature to add, you can even vote for it.

I have checked in fix for the lack of native YV12 support for input files to producer.   It will be available with the next binary release of helix producer, or when the ds reader source code is made available.  In the meantime, please convert to YUY2 as the last step in your AVISynth 2.5 script.  Inside producer, YUY2 is directly converted to I420 without going via RGB.

Hi
Great News!
Waiting until YV12 Capable Producer will become available
So maybe then we'll see some REAL speed improvements here
Because… Well, it's a bit slow right now.
(The Quality is Great Though  )
In the mean time I'll stick with Avisynth2.0x
((a few of my favorite Avisynth filters are not YV12 Compatible
yet.but this is just another story))

(okay im just going to go way off for a request to Realnetworks (also to karl_lillevold) that we'll not see for at least 4 years to come)
Is there any chance that realnetworks will make an avi CODEC?

Is there any chance that realnetworks will make an avi CODEC?

The VfW API is very simple.  Depending on Real's video API, I could probably bang something together this afternoon.

Of course, that projection is subject to my normal deadline behaviour, so expect it in a month.

-h

go -h go!!!!

Karl, could you outline exactly what my licensing obligations would be?

I haven't gotten through the licenses yet (and so haven't seen the distribution), but I wanted to either statically link my DriverProc() code to the encoding/decoding libs (in which case I'd be subject to the license, whose conditions stipulate that to distribute the DLL my web page would need user/pass authentication), or dynamically link it against binaries that I assume the user has downloaded from Real after completing the license agreement, and leaving my code BSD'ed or some such (though I would have to use Real's header files, opening up the rather odd licensing terms, or reimplement the headers from scratch).

-h

Originally posted by Ramirez
Waiting until YV12 Capable Producer will become available
So maybe then we'll see some REAL speed improvements here
Because… Well, it's a bit slow right now.
(The Quality is Great Though )

I am now encoding with helix producer, a new directshow reader (rids3290.dll - not yet available), AVISynth 2.5, and YV12 all the way. VTune shows that 50% of the CPU time is spent RV9 encoding in producer, 10% in AVISynth 2.5 (crop, bicubic resize), 10% in mpeg2dec3, 10% ntoskrnl, the rest in various modules.   

By the way, when I timed RV9 vs XviD encoding speed, not including any filters or color conversions (native codec format input), XviD was about 30% faster.  RV9 is ~ 2-2.5  times faster than WM9 (beta) though

) lately. Instead of adding a VfW interface we could have done a UCI wrapper for RV9 and been using it from VirtualdubMod in AVI and OGM ( if Tobias would adapt his filters that is ), later maybe matroska also ....

Originally posted by -h

The VfW API is very simple.  Depending on Real's video API, I could probably bang something together this afternoon.

I just wanted to express my deep gratitude for taking up this project -h, I've been eager to see what could be done with Real's opensource stuff ever since it was announced and I'm really glad its finally gonna be taken advantage of  
I still think the #1 deterrent from people using Real is the inability to have it stored in whatever container they want and played back in any player they want. Of course, stuff like vfw and dshow filters take care of the problem pretty easily (on windows at least).
I'd personally be cranking out tools by now if it weren't for the fact that I'm only in my first year of visual basic

Originally posted by karl_lillevold
I am now encoding with helix producer, a new directshow reader (rids3290.dll - not yet available), AVISynth 2.5, and YV12 all the way. VTune shows that 50% of the CPU time is spent RV9 encoding in producer, 10% in AVISynth 2.5 (crop, bicubic resize), 10% in mpeg2dec3, 10% ntoskrnl, the rest in various modules.   Is there any speed/quality gain when comparing between original RV-codec And the one that you're using for you tests?

BTW: about CPU utilization gt;gt; it's about time to implement
Some CPU utilization control in producer (exactly like AVISYNTH does)
Sure the encode will take longer but,not everybody can afford a monster P43000/HT machine.
P.S
Is that possible to make latest (compiled)
Dev- builds of producer available to the  members?
Oh well.. I think that I already know the answer for that.

Originally posted by Ramirez
Is there any speed/quality gain when comparing between original RV-codec
And the one that you're using for you tests? (Or is it to soon to talk about
Any gain because you are obviously need some time for optimization.
Correct me if I'm wrong though.)
BTW: about CPU utilization gt;gt; it's about time to implement
Some CPU utilization control in producer (exactly like AVISYNTH does)
Sure the encode will take longer but, not everybody can afford a monster
P43000/HT machine.
P.S
Is that possible to make latest (compiled)
Dev- builds of producer available to the  members?
Oh well.. I think that I already know the answer for that.  

Lots of questions.  Some answers:
There's no gain in quality with direct YV12, and to be fair, most of the speed-up comes from having YV12 throughout the pipeline in AVISynth, and not from the YV12 fix above.  I ran a bunch of measurements, and found about 10% speedup using YV12 for all steps on my home P3 550MHz (time to upgrade!), instead of converting to YUY2 as the first step in the AVISynth script.  I actually had a hard time measuring any improvement from the little fix discussed above, so I would just recommend to start using YV12 right away.  Maybe the error I discovered was so recent that YV12 in fact works just fine in released producer versions.  So try out YV12 right away, no need for any upgrades.  You could measure the speed difference with YV12 vs ConvertToYUY2 as the last step in your script...

Regarding dev builds:  that's one of the great things about helix -- changes are available the minute they are checked in by the developer.  However, for the directshow reader  you will have to have some patience, until we work out the header file issues and the source becomes available.

I don't quite understand your CPU utilization question..  If you run producer quot;below normal priorityquot; it won't affect your system too much.  Maybe I just don't know AVISynth well enough to know which feature this is.

). It's not hard (flip U and V), we just did not realize the usefulness, and well, it hasn't really been useful before Avisynth YV12. Thanks for the pointer.

Any news? The helix producer which can be downloaded, does it support YV12 already?

Originally posted by Wilbert
Any news? The helix producer which can be downloaded, does it support YV12 already?

Yes, it works just fine in all released producers, but there may be a minor performance problem in one version - specifically the first helix community source code release.  

I ran tests with the latest *released* version before the Helix community source code release and was not able to measure any improvement from my fix, so I think the only version with the problem is the first helix community release.  

I would suggest you try with and without ConvertToYUY2 as the last step in your AVISynth 2.5 script, and see which works better for you.  On my system, it was just slightly faster without the YUY2 conversion.