RealVideo 9 Information Thread Discussion

[marnum]

Thank you, eventually found the right statistics tab (Sometimes I really am with stupid). And what I see there is quite strange (I'm translating the titles into English, so they're probably not correct):

Framerate
--------------------
Coded with: 53027854
Right now: 76852626
Postprocessing: Off

Shown Frames: 58184274
Lost Frames: 109801
Dropped Frames: 1866691

The Numbers change randomly as I push Stop and Play again.

Is this a known bug? New hope comes to my mind that I do not have to throw away my latest 2 (perfect!) encodes...


EDIT:
Ok, maybe this showing incredible framerates is a common bug. I switched off "repeat" and it shows:

Coded with: 30.0 fps
Right now: 30.1 fps
Postprocessing: Off

Shown Frames: 100%
Lost Frames: 0
Dropped Frames: 3

And yes, by then it had jerked 3 times during playback.

[wing1]

I've not noticed this before, because most of my encoding has been bright and colorful scenes, but I've stumbled onto a clip that has mostly dark scenes (black everywhere) and I've noticed that black became darkish grey instead of true black. Furthermore, this is only noticeable when viewing in full screen mode (MPC and RealONe). Is this something has to do with player or encoding?

YV12 encoding is most noticeable, while YUV is a little less.

[Valky]

Originally posted by CaptainCarrot
@valky
Maybe it's a stupid question... but did you check wether your wavefile is correct? Maybe you have an error with that?
For producer command-line options: if you call producer without any options you get a list.
Your command-line could look like:
producer -i <inputfilename> -o <outputfilename> -vm normal -dt -da

This is without audio (-da), since i don't know how to do that.

Hope i could help a little bit.

I guess there is nothing wrong with the audio file, cause I have tried to encode also with the original wav file (which is in the avi-file) too...but now I try with this separate wav file cause I have converted this one into stereo-mode afterwards (cause the original wav-file in avi is in mono-format and I have also reduced some noise in it..).

But like I said..I have also tried with this plain avi-file without any filtering and use that as a source. Of course this X2Real-software puts it through avisynth afterwards, but I can't do nothing to that..
Yet to be honest, I am completely out of ideas here..

I have tried now 5 or was it 6 times now..encoding always stops at the same point..

tonight I'll try one more time with plain avi file without any audio..that should exclude the possibility that there is something wrong with the wav-file..

[Dark-Cracker]

hi,

@karl
it seems there is some change in the codec dll name and now rmeditor was lost :) one poeple have report me an error :

Error: -2147221496 / -2147220520
it probabely a problem of color conversion.but i can't reproduce it problem.

personaly i have an error : -2147220910
it's because the audio codec have change there name and rmeditor.exe was unable to find them.

to solve this problem : rename : atrc3260.dll and cook.dll with :
atrc3260.dll and cook3260.dll and normaly all will work.

(it seems the error are only some numbers and can't find the appropriate error msg)

Perhaps could u point me a 100% working rmeditor (that can split new .rmvb file without problem, and perhaps with the keyframe problem fixed.

Thank u :)
Bye.

[kilg0r3]

hi dark-cracker,

how is it going with ... ah no, I wont ask this question :D

[karl_lillevold]

@Dark-Cracker:
Re: various rmeditor problems.
Thanks for reporting these problems, which I will forward to the producer team. In the mean-time pls just rename the DLLs causing the problems. With regards to the split-on-keyframe problem, where the start time is exclusive, not inclusive: I am afraid this will probably not be changed, so I think you have to use the work-around we discussed, where you set the start time of the 2nd part just a few milliseconds before the exact time of the keyframe.

[marnum]

@ karl
Have you got an idea what can cause dropped frames when the CPU is at 40%?

[Sirber]

What's your computer? :logfile:

[marnum]

It's a Siemens-Fujitsu Notebook

Athlon XP 2000+ Mobile
512 MB RAM (32 MB shared to graphics chip)
ATI IGP 320M Chipset with graphics chip built-in
60 GB HD
WinXP SP1
MediaPlayers: MPC 6.4 & RealOne, both drop frames, no matter what content or resolution the RV file has

As mentioned before, CPU usage during playback is ~40%. No other codec drops frames. I really got no clue what's wrong. :scared:

PS: What logfile shall I post? :rolleyes:

[midiguy]

Originally posted by karl_lillevold
If it's jitter, we have signficantly improved this, and I may ask for some volunteers to PM me to alpha test a couple of DLLs.
hey, I would LOVE to alpha test some DLLs (I have a matrox g400, and have experienced jitter). When you say "significantly improved", is the jitter noticable anymore? why is there any jitter at all, when with other formats there is none? Was it a *bug* that was fixed, or did you guys just improve your renderer?

thanks!

[karl_lillevold]

Originally posted by wing1
I've not noticed this before, because most of my encoding has been bright and colorful scenes, but I've stumbled onto a clip that has mostly dark scenes (black everywhere) and I've noticed that black became darkish grey instead of true black. Furthermore, this is only noticeable when viewing in full screen mode (MPC and RealONe). Is this something has to do with player or encoding?
Incidentally, I came across a very similar source this weekend. RV9 or Producer do not change black levels, and at high bitrates, these should be represented very well throughout the chain.
So this problem may be due to your video card's overlay surface settings. If your advanced settings have gamma, try to adjust it. Also, how does the original source look when played full-screen?

My nVidia Ti4200 only has brightness, contrast, hue and saturation. I had to adjust saturation way down from default to not get drowned by much too strong colors.

[wing1]

@Karl,

The source's black level looks fine at full screen, hence, I was wondering about the encoded playback. My video card is a generic TNT2 Nvida 64Mb 4xAGP, and it has gamma adjustment on board: I have adjusted that. I also adjusted the monitor's brightness and RGB saturation color using AVISYNTH's function RGB as my standard. However, the blackness level on the playback is still a little lighter when comparing to the source. I am encoding using 1-pass with video bitrate ranging from 768kpbs to 1Mbps (audio bitrate will be additional to the video bitrate). Again yv12 input source showed this problem most aparent while yuy2 helped a little. I have not tested with RGB32 yet.

Another thing that i've noticed is that if the scene has 70% bright colors, the surrounding black level is fine.

[karl_lillevold]

Interesting problem, since RV9 accurately represents black levels from the Producer input to output directly to the video card's overlay surface.

which format is your source? If MPEG-2, maybe AviSynth's mpeg2dec outputs different values than the MPEG-2 decoder used when playing the source normally. I know for instance PowerDVD has some built-in gamma adjustments. Could you try to load your AviSynth script in VirtualDub, choose Direct Stream Copy and save a problematic segment of your source as an actual AVI file (you can try YV12, YUY2, and RGB with conversion functions supplied by AviSynth [ConvertToYUY2 etc]). Then examine how these AVI files look when played back in 1) MPC or any DS based player, 2) RealOne. How are the black levels now?

[karl_lillevold]

@marnum: can you try this?
I know very little about the ATI IGP, so I am not even sure if this is applicable for this card, but can you try the work-around to disable the special ATI video surface described in this thread:
http://www.rage3d.com/board/showthread.php?s=&threadid=33675184

I doubt this will make any difference, but please give it a try.

A couple of questions about your problem:

Do you see any /dropped/ frames for the /jitter test clip/, or does it have to be a clip that loads the CPU to a certain extent?

How regularly do the /dropped/ frames occur?

Thanks!

edit: link corrected

[marnum]

Thanks for replying!

The link you provided doesn't work, but I've found the thread using the search function.

No, I'm afraid this reg key doesn't take any influence - same dropped frames.

>Do you see any /dropped/ frames for the /jitter test clip/,
>or does it have to be a clip that loads the CPU to a certain extent?

Yes, this dropped frames occur with your clip also, it doesn't depend on CPU usage. As mentioned before, the Xvid version of your clip plays perfectly smooth, so I don't think it's jittering.

>How regularly do the /dropped/ frames occur?

They are quite random, though after watching it for several minutes :D it roughly seems as if there were 3 dropped frames every 1/2 second - but not really regular.

[karl_lillevold]

@marnum: oops, link corrected. Thanks for trying out these things. I just needed to know if the dropped frames were all the time, or once in a blue moon, which you answered. Could you please PM me your e-mail address so I can send you an alternative DLL to try, and if that does not help, potentially one that will output some debug information.

[midiguy]

jitter is very real. I just watched the source vob file for this triple x trailer, and then I watched the rv9 encoded version. the vob seems so much smoother and motion is so much better. You don't notice it as much until directly comparing them.

[marnum]

Since my jitter problem is now solved (again many thx @ karl!) I'll turn back to RV9 encoding immediately :)

[wing1]

@karl,

I did some testings as you have suggested, and the source's blackness level are all fine. I look at the encoded's blackness level and I am still seeing the same problem. However, when I reduced the hardware acceleration to the left, all the gamma from the encoded clip came back to normal like the source! (what happened there????). Furthermore, detail levels instantly increased (why is that happening???).

So I am playing with the hardware acceleration settings a little and it seems to behave the best somewhere in the middle point when playing back the encoded clip. This bring me to a quick question regarding the inner-loop filtering function of RV9 decoder: Why does the hardware acceleration change the gamma and detail level if I lower the hardware acceleration? In order for me to capture the screen content of the player, I've to disable the hardware acceleration altogether as well. Is the hardware acceleration somehow related to the inner-loop filtering function of RV9 decoding at all? If so can RV9 decoding be revised so that it will work somewhere in the midpoint of the video card's hardware acceleration point?

[karl_lillevold]

@wing1: Thanks for running those tests. It seems pretty clear this is a problem with your video card's overlay surface, and how it does not accurately represent the video codec's output. The hw accel slider does not affect the codec output. With the hw accel slider all to the left, there is no optimized overlay surface. Also, then we use a fast and simple software resizing for fullscreen playback, that will introduce jaggies, but perhaps give a perceived increase in detail level, even though there are not really any more details.

Thinking back, I used to have a TNT2 once, and I remember it had bad problems with chroma offset with YV12 as the color format for the overlay surface, and we currently use YUY2 on nVidia cards. Still, it sounds like even that has problems.

None of this is related to the RV9 decoding, and I am afraid there is little we can do to improve this. With R1P V.3 there will be a reg key to select the color format of the overlay surface. Maybe this will be useful so you can select the color format that the TNT2 handles best.

[midiguy]

Originally posted by marnum
Since my jitter problem is now solved (again many thx @ karl!) I'll turn back to RV9 encoding immediately :)

Was it those DLLs?? are these the same DLLs that fix the jitter (the ones you were talking about earlier) Karl?? If so, I can't wait until this fix is released. The only things holding me back from using RV9 is the jitter and the excessive post-processing (or maybe excessive in-loop filtering if that is possible).

[iwod]

hi, Karl
few questions.

Does the post procsssing is auto set to different level in different bitrate range? or Is is set at a fixed level at all time?

And a questions.... is a RV9 D Show filter will ever be avalible. Or will RealOne 3 come out soon enough? I am spending as much time encoding as speaking to other people to purvade them to use RealONE. Most of them still have RealPlayer 8 installed on their system!!!

Trying to tell them that you are set this in RealONE brrrrrr is getting very very tiring.... and of coz they are not computer geeks and they don't want to mess with settings and they don't visit doom9.

The whole point of the player is letting other people to play our encoded content.
I could have easily said that all you have to do is download the RealCodec pack. But i still try my best to rebuild the image of Real....

You know destroying takes a matter of secounds and building something takes matter of years.

I hope that direct shown filter will be avalible sometime. Then every player could play real content.

[HomiE FR]

Hi all,

I'm very interested by Real Video 9 (and I did use it many times in the past), but I just have a little problem with the RV9 overhead.

Indeed, I'm trying to do a 175 MB RV9/RA8 96kbps anime episode (21 minutes 35 sec), but I need to know what the overhead in RV9 is. I've seen that AutoRV9 seems to have a good bitrate calculator in it, but my input is not a D2V file, but an AVS script (I have 3 D2V files used in it, start credits, episode and end credits). That's why I can't use this bitrate calculator.

If I knew how the Real Media overhead worked I could reach the right size without problems.
I know that I could probably find it out myself by doing many tests, but I'm a bit lazy, so if anyone here knows what this overhead is (in terms of size, etc.) I would be thankful !

Thanks in advance ! (I hope you can spot my problem)

HomiE FR

[midiguy]

alternatively, you could just load the 3 vobs in DVD2AVI in sequence, one after the other (start credits, then episode, then end credits, use the "ADD" button in DVD2AVI), then you just save one D2V and then you can use autorv9's bitrate calculator now go try it ya little Chicken McNugget.

[HomiE FR]

Thanks midiguy, but I had already thought about this solution. And it is no way in my case : I use many filters (I know that I could do that in AutoRV9 but it won't be as easy and flexible as with Notepad I think (and may be wrong...) ) and moreover I use Textsub.
So there is a problem, cause I have separate subtitles in ass format for the start credits, the episode and the end, which all start at 0 min 0 sec. So using only one D2V would force me to "merge" the different ass files, and it would take time... for each episode I plan to do...

What I ask for (if possible, I don't request anything...) is just a small bitrate calculator which needs :
- final size
- audio codec used (type, flavor and bitrate)
- length of the clip (I can't do that in AutoRV9, I tried this afternoon)
and returns the appropriate (total) bitrate which should be used in the audience.

I believe that many other people could benefit from this kind of tool.
If anyone only knew the formula to calculate this overhead, it would be totally enough for me ! :)

Thanks.

[karl_lillevold]

@HomiE FR: The RM file overhead is about 1.4% but you don't really have to worry about that. All you need is the length of the sum of the clips and your target filesize.

The get the length of the sum of the clips, just open your final .avs script in VirtualDub or mplayerc, and scroll to the last frame. When you know the clip length and the desired filesize, the rest is pretty simple:

bitrate(kbps) = total_filesize_in_kilobits/length_in_seconds
where one kilobit is 1000 bits.

example:
700 MB = 700 * 1024 * 1024 bytes = 734,003,200 bytes = 5872025600 bits = 5872025.6 kilobits

Then, for instance, 2 hours = 7200 seconds:
bitrate = 5872025.6 kilobits / 7200 seconds = 815.56 kbps

Did I miss anything?
This bitrate can be used as the audience target bitrate in Producer.
The hardest part is getting from MB (1024 and byte based) to kilobits (1000 and bit based) ;)

[karl_lillevold]

@iwod:

Almost every method and algorithm in RV9 is adaptive, not only based on bitrate, but everything else in the sequence as well.

I can not say when RealOne V.3 will be out, but I am worried if your friends do not like V.2, it will be hard to convince them to install V.3 as well. Perhaps you should just recommend them to try Media Player Classic and help them enable RV9 playback there, by whichever means you find most convenient...

You know destroying takes a matter of secounds and building something takes matter of years.
Yes, we are painfully aware of that :(

I hope that direct shown filter will be avalible sometime. Then every player could play real content.
I have mentioned how it is difficult to decide to release the codecs as DirectShow filters, but they way you phrased your suggestion, might actually be possible using the released Helix code and APIs: a DirectShow filter to play RealMedia files. Who knows, maybe someone is working on this right now.

[midiguy]

Originally posted by karl_lillevold

I have mentioned how it is difficult to decide to release the codecs as DirectShow filters, but they way you phrased your suggestion, might actually be possible using the released Helix code and APIs: a DirectShow filter to play RealMedia files. Who knows, maybe someone is working on this right now.
you're saying that technically it is possible to make a directshow decoder right now by using the released helix code and APIs?

[Sirber]

Looks like :)

But now I like the way Real is doing. The RM contener is fine and powerfull (with a smile ;) )

Both audio and video codecs work great.

@Karl

Is it possible to specify a minimum quality in VBR mode in Helix Producer?

[edit]

VBR 2-pass in Helix is quite good. In Evangelion, at 350kbps, the bitrate move from 80kbps (quality 66) to 1200kbps (quality 56), and sometimes in a interval on 1 sec!!!!

[HomiE FR]

Thanks Karl :), I thought I knew about the bitrate calculations but maybe I did something wrong last time. I will double-check it.

[kilg0r3]

Originally posted by iwod
The whole point of the player is letting other people to play our encoded content.
Well, just like netscape, the real player is also an advetisement vehicle. This function seems to be pretty difficult to implement into a DSfilter

[gabest]

Originally posted by kilg0r3
Well, just like netscape, the real player is also an advetisement vehicle. This function seems to be pretty difficult to implement into a DSfilter No, not at all. I could imagine some nicely alpha-blended banners on the picture or a woman's voice whispering in the background of the audio :D

[kilg0r3]

Yes gabest YESSS.

No seriously, even now, some advertisements are displayed through an extra app, 'message centre' I believe. This would of course be a possibility. Another possibility is a colaboration with gain, like Divx.

[midiguy]

Originally posted by kilg0r3
Yes gabest YESSS.

No seriously, even now, some advertisements are displayed through an extra app, 'message centre' I believe. This would of course be a possibility. Another possibility is a colaboration with gain, like Divx.

then they should offer a decoder-only directshow filter that doesn't have any adware/spyware, and only the directshow encoder will have the ads.. just a thought..

[31 Flavas]

Originally posted by midiguy
then they should offer a decoder-only directshow filter that doesn't have any adware/spyware, and only the directshow encoder will have the ads.. just a thought.. RealOne player is going to be better behaved, but it's largely going to stay the same; If I am reading Karl's comments correctly. In otherwords, SuperPass isn't going to go away so RealOne isn't going to go away.

Perhaps though maybe down the road Helix Community Player is going to become what everyone will want to use, if a codec or dshow filter isn't made. If it gets spiffed up, I think it could become a great realplayer "lite" with none of the SuperPass extras.

[midiguy]

the ads and crap on the realone player do bother me, but what bothers me most is the current rv9 renderer. As many of you have heard, it does have its problems, especially with certain video cards. These problems have apperently been "significantly imrpoved".. by how much, who knows, the *fixed* decoder hasn't been released yet. But I hope it will be bug-free. Everytime I watch an rv9 movie, I can't stand the bad motion. That is why a directshow codec would be a good idea, because then the directshow renderer will be used and these problems will disappear. Another thing I would like to see is configurable filtering (post-processing, and if it is possible, in-loop filtering). These are the things that are stopping me from using this codec full-time. Right now I just use it for tests and what not, and sometimes for movie trailers. I would really like to use rv9 for my site though (I will soon be releasing films.. "amatuer" films I suppose).

[kilg0r3]

midiguy: These problems have apperently been "significantly imrpoved".. by how much, who knows, the *fixed* decoder hasn't been released yet.

just pm karl, so that he can send you his jitterfix.dlls. then you can see it yourself.

[midiguy]

Originally posted by kilg0r3
just pm karl, so that he can send you his jitterfix.dlls. then you can see it yourself.

thanks, did. I was under the impression that he would let us know when to PM him :confused:

anyways,I have to go get a froster
http://www.froster.ca

bye.

[Sirber]

Originally posted by Sirber
@Karl

Is it possible to specify a minimum quality in VBR mode in Helix Producer?


Any idea?

It would be great to control the monimum quality for VBR 2-pass encoding. I hate sometimes when the codec cut too much bits, on from-divx animes.

[karl_lillevold]

VBR minimum quality is a good idea. In fact, we are in the process of adding more parameters that can be tuned. We just added a new interface to producer/codec such that it is possible to set codec options directly in the xml job file, without those options needing producer support, or producer updates, when we decide to change the codec. This will make it much easier for us to experiment with various codec options, and among other things, we could add an option for minimum quality without it being an "official producer option". Maybe it will be included in the next Milestone ;) Thanks!

[Sirber]

Thanks to you :)

I have a little question: Is it possible to put Helix Producer (cmd line) 9.2m1 in Helix Producer Plus 9 (The GUI)?

[karl_lillevold]

Originally posted by midiguy
why is there any jitter at all, when with other formats there is none? Was it a *bug* that was fixed, or did you guys just improve your renderer?
There are 2 reasons for jitter:
1) the clip frame rate does not match the refresh rate of the monitor. This is impossible to correct, unless the user changes the refresh rate to an exact multiple of the clip frame rate. However, certain improvements can be made such that the round off error is minimized.

however, more importantly
2) the accuracy of the operating system timer determines when your thread can decide to blit to the screen... In WinXP and Win2K this defaults to 10 ms, which is not good enough. However, there is a was to adjust this programatically, which for instance a DirectShow renderer does.

This setting is global for the system, so for this reason, did you know that in some cases, one way to improve the jitter without any DLL fixes, is to have a DirectShow player minimized while playing your RV9 clip...? This may or may not work, so don't shoot me if it does not.

We have also made some other improvements, both OS and video adapter specific, since both OS's and adapter manufacturers like to do things their own way. For the OS, it's the timing and thread scheduling, for the video adapters, it's the functionality and APIs that tend to differ.

However, based on the feedback I have received, it seems the jitter improvements we have done work pretty well. Thanks for all the help and feedback so far.

The only remaining problem is the algorithm to deal with the "roll-over" or rounding problem, when the timing is not accurate (OS problem) combined with the framerate vs screen refresh rate. Every so often you have to 'roll-over' to the next refresh interval, and any timing in-accuracies causes some 'flutter' back and forth just when it's time to skip one interval. hard to explain late one friday night..but anyway. DS might still have the edge right there, hopefully we'll get some more improvements in. I will use your feedback to try to convince the right people it's needed. Some are worried about breaking something, if we try to add some "radical"=new improvement

[karl_lillevold]

Originally posted by Sirber
I have a little question: Is it possible to put Helix Producer (cmd line) 9.2m1 in Helix Producer Plus 9 (The GUI)?
It is possible to replace the codecs without much trouble, I think I already posted instructions how to do that (for RV9, delete rv403260.dll, erv43260.dll, then take erv4.dll from latest Milestone, rename it rv403260.dll, put it where the old codecs were). This is not guaranteed to work, but may in most cases. You will then not get the the new producer/codec interface I just mentioned, because this requires one more DLL.

With regards to other functionality, it is more complicated, since interfaces in many cases have changed. I simply don't know the answer, but I understand your concern, since the GUI is nice to have, and at the same time you would like the improvements in the latest cmd line utils.

One thing you can do is set up your encoding in the old GUI, and save a job file. Then make the edits you need for instance for minimum VBR, and use this as input to the new cmd line Milestone. This should be possible, I think.

[kilg0r3]

1.
Tried the dlls today. And, the rmvb
jitter-test file
now plays as good as the avi.

2.
I ran into another problem, when encoding a scene from VIDOCQ in
anamorophic format at about 1300Kbit/s. It is really difficult to describe. The macroblocks seem to be wavering, or, it seems that the motion in two macroblocks is not the same while it should be
because the are representing different
parts of the same thing. Erm, well, you
see ... I'll upöoad a snippet of the clip to .here (http://www.uni-koeln.de/~a0597/shiver.rar).

[Sirber]

I saw what you meant... I only saw it one time, when I replayed it it was gone.

It's the first time I see a RIP at almort 1024x. Quality is great, a little blury in backgrounds, but overal quality is great.

[karl_lillevold]

nice quality!

I don't see any problems, but I think I know what might be happening with those 'wavering' macroblocks ; i don't know the speed of your CPU, but since this clip is higher resolution than average, combined with potential extra load due to resizing (your video card should do that job though), maybe the decoder is slightly running out of CPU cycles. In that case it might try to scale back quality with certain steps we call CPU scalability, instead of skipping frames. One of these might cause this effect. Please try to experiment with the regkeys below:

=== snip ===
Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Software\RealNetworks\RealMediaSDK\6.0\Preferences\RV9]
"NoCPUScalability"=dword:00000000
"NoFullDecode"=dword:00000000
=== snip ===
Copy and paste everything within the 'snip' lines into a new file called rv9.reg. Double-click on this file to enter the values into the registry. You can edit the values in the reg file before double-clicking or manually afterwards with regedit).

If you set 'NoCPUScalability' to 1, the decoder will not scale back, but then frames might be skipped if the CPU load is too high.
If you want to force on the effect I think you are seeing, try to set 'NoFullDecode' to 1 and 'NoCPUScalability' to 0.
When I do this, I see these kind of wavering macroblocks, due to NoFullDecode being in effect.

Let me know how this works.

[Sirber]

When I watched the clip the first time, I had Helix Producer running in background. The second time, it was still running, but maybe Windows buffered it all in RAM, so I didn't saw the wavething macroblocks.

[midiguy]

I tried to play the clip, but my p3 600 mhz w/ 128 mb sd ram cannot play such a high resolution properly without eating all my resources. so it skipped frames and ditched like crazy. looked more like a still photo slide show. anyways, the forground quality looked good, but the background looked rather blurry, but still acceptable. can't tell you about the macro block problem though, I simply could not play the thing.

[karl_lillevold]

the backgound is blurry because the camera is focusing on the foreground. The faces look razor sharp :cool:

[Sirber]

You've got a point :)

I can't wait to try AutoRV9 1.3 with anatrucmachinchouette. :D