Log in

View Full Version : RealVideo 9 Information Thread Discussion


Pages : [1] 2 3 4 5 6 7 8 9 10 11 12

atracus
13th December 2002, 21:40
@karl,

my 2 cents for thanking you for your tenacity and for the politness of your above-enclosed remark in this forum.

My personal standpoint is that RV9 is by far the best format for movies' backup presently available on the net, both in terms of envisable lifespan for the future and of perceivable video'n'sound quality.

I'm glad to keep on reading you here, please take into account that your effort is precious and valuable for some of us - for me, at least ;)

sincerely,

[atx]

midiguy
14th December 2002, 20:36
from my experience, RV9 does too much pre-processing and can often remove many details in your movie. This may be ideal for lower bitrate encodes but for stuff with higher bitrates it may not be the best. but I guess if you are encoding something like, say, A Simpsons episode, yes, RV9 probably would be very good for something like that. Unless there is a way to disable its pre-processing?

karl_lillevold
14th December 2002, 23:21
atracus, thanks for your feedback!

midiguy:
Originally posted by midiguy
from my experience, RV9 does too much pre-processing and can often remove many details in your movie. This may be ideal for lower bitrate encodes but for stuff with higher bitrates it may not be the best. but I guess if you are encoding something like, say, A Simpsons episode, yes, RV9 probably would be very good for something like that. Unless there is a way to disable its pre-processing?
Alas, like I posted in another thread, there is no pre-processing in RV9 unless you choose the Low or High noise filters. As opposed to MPEG-4 based methods, RV9 has no ringing and mosquito noise - that's sometimes perceived as lack of detail. Still, I am very interested in the settings you used when you observed this, source material, encoder version, and how you play back the resulting file (OS, player, video card), LCD, TV out?. Maybe there's a problem with one or more of these that we need to fix. Certain older video cards (Matrox G200 in particular) does not know how to interpolate with high quality.

In fact, let me ask everybody for feedback on how to reproduce RV9 lack of detail and perceived softness for higher bitrates.

It's just not something I see myself and I have plenty of high bitrate demos that look awesome with every single detail visible. I usually play back on a computer CRT at 1400x1050 with an ATI or nVidia card, or a 15" Eizo LCD, no sharpening, or color adjustments in RealOne.

For encoding, I rarely use any pre-filters, unless the source is grainy, and I use VBR 2-pass with a max bitrate set at about 2.1 times the average bitrate, and a 25 second buffer. This prevents too many bits from being spent in the very high action scenes, where you can't see all the details anyway, and lets you spend more bits in slow scenes, where you need them more.

So please provide details, so I can investigate. Then again, I have a preference for no ringing around edges, so that may be part of it, but based on some reports, I think there must be more to it.

^^-+I4004+-^^
15th December 2002, 14:59
>from my experience, RV9 does too much pre-processing and can often remove many details in your movie.


i too disagree there:rv9 has the best overall quality on
lower bitrate ( i used rv9 on cca 450kbit and get some awesome
results ! )

as i'm a guy that like my videos sharp i can tell ya that rv9 at
such bitrates is THE BEST i've seen so far!
even subtitles and station logo's look mighty sharp
rumours that xvid will give sharper image are false if you ask me!
also xvid (same as divx) don't have ANY place in such lo-bitrate
environment!

it's PLAIN FUNNY(!) when i read marcfd's "xvid
is the best codec from 250kbit upwards....."
xvid(same as divx) looks like SH*T on that bitrate and rm9 is much better there.....
he obviously didn't tried rm9

BUT,enough of praise of rv9,i have playback
problem:on monitor everything is OK,but on tv-out
i get framedrops (jerky playback)
(cel600+tnt2card&bt869 tv-out chip)

so i was wondering,karl,if this issue can be adressed?

even on lores it's poor performance on tv-out...
( i'm using tv-tool as a tv-out software, and all other .avi stuff
works nice..even much higher res' )

cheers

Ivo

polle
15th December 2002, 15:11
strange those playback problems with RV9, I work also with Tv-tool and nvidia tnt2 32mb (on XP with athlon 600Mhz and 512 Mb of RAM).
Also movies with higher bitrate in RV9 play well.

atracus
15th December 2002, 20:31
RV9 makes good movies, too, not just anime.

I encoded LotR1 on 3 CD's, audio was atrac@176K Surround, video bitrate was .... just use your math to get the number, let's say in the range of 1500-1600 Kbps, what I call "high bitrate".

Well, quality was awesome (no jerky noise / ringing / shadow effects on pans, and all the nicies we've got used to see with MPEG4 derivatives, including XviD, Qt/Sorenson3Pro, DivX, WMV9), and audio was absolutely flawless as well.

I played it all for just 2 times, once on my monitor and the second time on TV-out; no pb at all on my "old" ATI-AIW Radeon (800x600 TV-out). For those interested, CPU is Amd 1GHz on VIA Chipset - I should get it changed soon (3GHz's call for action!).

If you are still doubtful / skeptical, just do your personal tests and compare; there's always something yet to be discovered, and I'm pretty sure there are hidden pro's and con's still to be explored and pointed out.


have fun

[atx]

Ramirez
15th December 2002, 21:14
Originally posted by ^^-+I4004+-^^
>

BUT,enough of praise of rv9,i have playback
problem:on monitor everything is OK,but on tv-out
i get framedrops (jerky playback)
(cel600+tnt2card&bt869 tv-out chip)

so i was wondering,karl,if this issue can be adressed?


Its sounds like you need ReClock (http://forum.doom9.org/showthread.php?s=&threadid=39887&highlight=reclock)

karl_lillevold
16th December 2002, 04:55
Originally posted by ^^-+I4004+-^^
as i'm a guy that like my videos sharp i can tell ya that rv9 at
such bitrates is THE BEST i've seen so far!

problem:on monitor everything is OK,but on tv-out
i get framedrops (jerky playback)
(cel600+tnt2card&bt869 tv-out chip)
so i was wondering,karl,if this issue can be adressed?

Thanks for your RV9 feedback! I am sorry, but I don't know what this TV out problem could be. It sounds like the video card goes out of overlay mode for TV out. Then you would experience the problem you mention. I am sure you have the latest nVidia drivers installed. I will ask our renderer guy, but can not promise an answer.

midiguy
16th December 2002, 17:51
One time, I encoded the first episode of cowboy bebop. One of the scenes, when a character uses the eye drops, the screen turns red, and there is a noise effect (there is suppose to be this noise effect, it is a special effect). But qwhen I play back that scene, the noise looks really smooth and blurry and soft and overall pretty ugly. now, if you say there is no pre-processing with RV9, then it must be realone player's post-processing detecting this special effect as video noise and blurring it to hell. I can't show a sample of what I Am talking aboutr though (no longer have the source or the copy). but is there a way to disable real player's post-processing? or atleast control its post-processing level? (much like you can with mpeg-4 directshow decodecs such as ffdshow or DivX). That would be a really good feature, and that may be responsible for the perceived softness and lack of detail that people are getting.

sorry about my spelling/grammar, I'm tired :o


*edit* forgot to mention, Cowboy Bebop is an anime that uses a lot of CG

*edit* one more question. what is the best tool right now to use to encode Realmedia 9 content? AutoRV9? Helix Producer Pro?

Dark-Cracker
16th December 2002, 19:19
objectively, autorv9 :D :D :D

^^-+I4004+-^^
16th December 2002, 19:27
@Ramirez

"ReClock is a DirectShow filter that will help to get rid of most causes of jerky DIVX/MPEG playback"


_where did i said that i have avi/mpeg plb problems?


@karl

i have dual-boot win98/2k so i'll check if win98 will play it
better ( it's different tv-out program there.ie. not tvtool )
i think you might be right that overlay doesn't kick in for some
reason....
[ if i see improvement then i'll report here...if not,then i'm not saying anythng.that way you'll know problem still exists...i'll test it by tomorrow..i'll also check ROne settings concerning playback.. ]

cheers_

^^-+I4004+-^^
16th December 2002, 19:44
Originally posted by Dark-Cracker
objectively, autorv9 :D :D :D

DC,you didn't paid any attention to the people that deal with
.avi files.....why is this so?

[although i won't complain: avs,helix basic & xml notepad get me where
i wan't.......]

31 Flavas
16th December 2002, 20:08
Originally posted by midiguy
I can't show a sample of what I Am talking aboutr though (no longer have the source or the copy). but is there a way to disable real player's post-processing? or atleast control its post-processing level? Hm... I own the cb bebop dvds. I'll encoded this episode and see what I get.

karl_lillevold
16th December 2002, 21:36
Originally posted by midiguy
One time, I encoded the first episode of cowboy bebop. One of the scenes, when a character uses the eye drops, the screen turns red, and there is a noise effect (there is suppose to be this noise effect, it is a special effect). But qwhen I play back that scene, the noise looks really smooth and blurry and soft and overall pretty ugly. now, if you say there is no pre-processing with RV9, then it must be realone player's post-processing detecting this special effect as video noise and blurring it to hell.

Noise is almost impossible to compress, so I think what happened was that the bitrate spiked so much during this scene, that it blew the bit reservoir, causing the encoder to increase quantization so much it blurred the video too much. For typical bitrates, when I use VBR with max bitrate a little over 2X average bitrate, and 25 second buffer, I have not really seen this happen, but can't remember any scenes like this either. There is no adjustable post-processing in RV9, so I think the problem occured on the encoder side.
With regards to encoding tools, AutoRV9 uses Helix Producer as its back-end, but it is a great help in automating the process.

karl_lillevold
16th December 2002, 21:47
Originally posted by Dark-Cracker
objectively, autorv9 :D :D :D
Great tool, but just one feature I'd wish for (actually, four, but three of them can be done if the first feature is added.

After all options and files saved, create batch file (.bat) that can be edited before starting the process.

With this feature one could do the following by editing the command line parameters in the batch file and possibly AVS scripts.

Run Besweet with 48kHz output, and possibly skip besweet 2-pass normalization and use producer's audio gain feature instead. This would speed it up the audio conversion process. Producer accepts 48 kHZ input.
Anamorphic encoding (see separate thread - requires producer pro feature)
YV12 / AVISynth 2.5. AutoRV9 requires AVISynth 2.0x. but with the feature above, one could use 2.0x for the setup, then switch to 2.5 before running the batch file.

midiguy
16th December 2002, 22:14
Originally posted by karl_lillevold
Noise is almost impossible to compress, so I think what happened was that the bitrate spiked so much during this scene, that it blew the bit reservoir, causing the encoder to increase quantization so much it blurred the video too much. For typical bitrates, when I use VBR with max bitrate a little over 2X average bitrate, and 25 second buffer, I have not really seen this happen, but can't remember any scenes like this either. There is no adjustable post-processing in RV9, so I think the problem occured on the encoder side.
With regards to encoding tools, AutoRV9 uses Helix Producer as its back-end, but it is a great help in automating the process.

will do, thanks. I'll have to get a good source to test with.

also, in autoRV9, it has options for "normal video" "smooth video" and "sharpest video".. I always use sharpest, but what exactly does puitting it on normal or smooth do? does it pre-process the source?

Ramirez
16th December 2002, 22:34
Originally posted by ^^-+I4004+-^^
@Ramirez
_where did i said that i have avi/mpeg plb problems?

Obviously --<<NOWHERE! >>--
I've simply overlooked that part of you post.
No need to put me in a front of the fireing squad though.

karl_lillevold
16th December 2002, 22:35
Originally posted by midiguy
also, in autoRV9, it has options for "normal video" "smooth video" and "sharpest video".. I always use sharpest, but what exactly does puitting it on normal or smooth do? does it pre-process the source?
Glad you asked. That's always been a confusing option, because it affects a few non-documented internal parameters. It was designed mainly for low bitrates, and is the trade-off in the encoder between frame rate and quality/sharpness. So 'sharpest' would be better quality/sharper but skip more frames. There is no pre-filtering. For VBR and higher bitrates, the 'normal' vs 'sharpest' will have very little effect, if any. However, the 'smooth' setting has the following effect: If you choose 'smooth', the encoder will operate in HHR mode (half-horizontal resolution) for video sizes larger than 640x320. HHR means to resample and encode at half the width, and have the player scale back on playback. This looks very smooth, but is a good trade-off for very low bitrates, relative to video size. I rarely use it though. HHR in RealVideo was more common in the past, when 'normal' would use HHR the way 'smooth' does now. We probably should make HHR a separate option.

midiguy
17th December 2002, 01:01
hi. I just encoded a quick clip from some footage from a DVD camcorder that I filmed with. Settings were:

Resolution: 320 x 240
framerate: 30 fps
buffer: 25
other thing: 10


resized from 704 x 480 (4:3 aspect) to 320 x 240 using neutral bicubic resize filter.

average bitrate: 400
max bitrate: 800

look at his face in the video, has the nasty blur effect. and look at those bricks!
I also tested it by cutting the framerate in half to 15 fps, and using the same settings for the bitrate and the rest. even though each frame got double the bits (cause of 1/2 frame rate), the blurring was still just as much there. that is why I think it has to be the realone player's postprocessing.. what could be responsible for this?

clip here:

http://home.primus.ca/~shanecaplan/test.rar

download link above.

*edit* the above clip is @ 30 fps, but I did the 15 fps version so I could see if it was a bitrate problem (each frame gets double the bits). the 15 fps is not included in the archivem but I can assure you that it was JUST as blurry.

karl_lillevold
17th December 2002, 01:17
nice test clip. and very hard. the detailed noise like texture and camera motion make this clip very hard. Also, since the clip is so short (27 seconds), VBR won't help much, since our rate control will set the quantizer fairly high to achieve 400 kbps average. In fact, the codec uses only 2 seconds of the 25 second buffer. Perhaps you could argue that it should have used more, but the over-riding parameter is the average bitrate. And, since the filtering is tied to the quantizer, there will be blurring. Without filtering there would have been blocking artifacts. It's a trade-off.

I don't have the source, so I can't compare to other codecs, but I would imagine they would have tough time as well -- just make sure they don't overspend bits, and the resulting filesize is equal or close to equal. Anything else would not be fair..

midiguy
17th December 2002, 02:06
so from what you have seen, is there any way to make this test clip not look so blurry and spongey?

midiguy
17th December 2002, 02:10
Originally posted by karl_lillevold
Without filtering there would have been blocking artifacts. It's a trade-off.
so then you are saying it does filter if it needs to? is "filtering" the same as pre-processing?

karl_lillevold
17th December 2002, 02:26
Originally posted by midiguy
so from what you have seen, is there any way to make this test clip not look so blurry and spongey?
No, I am sorry, not until the next version of RealVideo. The way the post-filtering is designed makes it non-adjustable. This design is part of why RV9 works so well, but a dis-advantage is that it's non-adjustable. We spent a lot of time tuning it, and doing taste tests, to avoid any more blurriness than needed, but at the same time have no blockiness. Users really don't like blockiness.

Note that if this difficult clip had been part of a longer sequence, with both easier and harder sections, the VBR would have made this hard section look better.

Originally posted by midiguy
so then you are saying it does filter if it needs to? is "filtering" the same as pre-processing?
no, there's no pre-processing.

RadicalEd
17th December 2002, 02:53
so its true that the post processing is indeed built into the codec and not just the doings of the RealOne player?

midiguy
17th December 2002, 07:01
Originally posted by RadicalEd
so its true that the post processing is indeed built into the codec and not just the doings of the RealOne player?

The way I see it, it has to be one of two possibilities:

1) Post-processing is built into the codec and has nothing to do with the actual Realone Player

2) Post-processing is not built into the codec and is the doing of the Realone Player --- it just can't be adjusted or tuned at all.

:sly:

midiguy
17th December 2002, 07:04
by the way: good to hear that it is just the post-processing. It would be really awesome if you could change the levels of post-processing, perhaps have 6 or so levels, and the lowest level would turn off post-processing. maybe something like how ffdshow's post-processing format is set up? maybe have the 6 levels as presets for beginners, and then have an "advanced" button or whatever where people that want to go further into it can fine tune the post-processing from all angles... and maybe have an "auto detect" mode or whatever, where the player will try detecting the *best* level of post-processing for a particular clip (kinda like how it is now?)

^^-+I4004+-^^
17th December 2002, 15:25
so it looks like it's tvtool (and/or win2k) issue.....

midiguy
17th December 2002, 23:57
Originally posted by karl_lillevold
No, I am sorry, not until the next version of RealVideo. The way the post-filtering is designed makes it non-adjustable. This design is part of why RV9 works so well, but a dis-advantage is that it's non-adjustable. We spent a lot of time tuning it, and doing taste tests, to avoid any more blurriness than needed, but at the same time have no blockiness. Users really don't like blockiness.
are you saying that the next version of the RealOne Player will allow you to change the post-processing level??? I missed that little tidbit earlier. could there also be a setting to turn it off completely? that would be awesome!

also, the post-processing for that little test clip I encoded is WAY too much for my tastes.. I would rather see a few blocks and maybe some noise than anything that blurry and soft. Sometimes there are clips like that that need to be encoded, and that do not have the benefit of "easy" parts to the sequence. that is why I tihnk makign the post-processing configurable would really make a big difference and really start shit up in the video compression community :sly: :cool: :cool:

karl_lillevold
18th December 2002, 00:11
I will be far away from Seattle until Dec 30th. I will be online once in a while, but can't promise any long and detailed posts. Happy Holidays to everyone!

Dark-Cracker
18th December 2002, 00:49
hi,

i will try to add the support of the .avi file for input. :)
it normaly will add the joblist on the v1.3 :)
for anamorphic and besweet i am not sure , i must find documentation.

and for the yv12 input i will wait producer add the support because for the moment only yuy2 was supported.

normaly added in v1.3 :

- compressibility test
- besweet more options.
- job list.
- internal subtitle
(perhaps yv12 support)
-fix bug : italic in subtitle, 4/3 smil file) .

Bye

midiguy
18th December 2002, 04:33
dark-cracker, your tool rules!! keep up the good work!

only one thing:

auto-crop never works for me.. it always cuts out too much into the picture, or completely misses the black bars. but I can just do a manual crop and be okay.

Valky
20th December 2002, 00:56
Same thing here. Great tool and only thing that doesn't work flawlessly is this auto-crop.

For me it leaves those black-bars, but that isn't so big issue.

Dark-Cracker
21st December 2002, 18:40
hi,

yes the autocrop seems not always work i think this problem will be solve in the next version :) thank u for the bug report.

Bye, and mery chrismas, and happy new year :) .

baddbill
22nd December 2002, 20:32
Dark Cracker any idea when AutoRV9 v1.3 will be ready? The comp test seams to be almost a neccessity. I'm really looking forward to encoding with RV9.

Thanks,
Bill

Dark-Cracker
22nd December 2002, 21:05
hi,

i must first finish the autodub version 1.7 before working on the next release of autorv9, i think perhaps in 3 or 4 week, a beta of the 1.3 will be publish.

Bye.

Sgt_Strider
23rd December 2002, 04:28
I'm a noob to encoding and while browsing realnetwork's home page about real video 9, I came upon a very important info; "Same quality at half the bitrate of mpeg-4". When using gknot, there is an option displaying your average bitrate when you select either the divx3 or divx5 codec in the codec area. For example, let's say my average bitrate is 1608 kbit/s, does that mean when entering my average bitrate into the helix producer 804kbit/s and I'll still get the same quality?????

31 Flavas
23rd December 2002, 06:44
Originally posted by Sgt_Strider

For example, let's say my average bitrate is 1608 kbit/s, does that mean when entering my average bitrate into the helix producer 804kbit/s and I'll still get the same quality????? Do your own tests and get your own opinion on it.

But, i've done encoding myself and have seen compairison clips of xvid vs rv9 (both at same bitrate) and the rv9 clip was very obviously the better clip.

Edit: Oh yea, don't forget, at the present time rv9 is the only one that can do anamorphic encoding. hehe :)

Tommy Carrot
24th December 2002, 01:28
Originally posted by Sgt_Strider
I'm a noob to encoding and while browsing realnetwork's home page about real video 9, I came upon a very important info; "Same quality at half the bitrate of mpeg-4". When using gknot, there is an option displaying your average bitrate when you select either the divx3 or divx5 codec in the codec area. For example, let's say my average bitrate is 1608 kbit/s, does that mean when entering my average bitrate into the helix producer 804kbit/s and I'll still get the same quality?????

I would't say that.

The fact is, RV9 is definetaly better at low bitrates, but it is incapable to give dvd quality. It smooths out the details even in 2cd rips.

^^-+I4004+-^^
24th December 2002, 02:02
and mpeg2 doesn't smooth?
have you ever compared nice clean PAL
tv signal with mpeg2 as seen in dvd player?
and you still take mpeg2 as a reference?
i regard dvd (mpeg2 stream) as less sharp than analog
PAL.......(yes i have seen quite a few decent dvd players in action...)
EVERY and ANY codec smooths.......that's why it's called
lossy compression.....(mpeg1,2,4 or rm...)
(sure,i would love to burn and watch my huff capturings...but..)

at the bitrate,rm9 is THE BEST,ie. try to make decent(!)
mpeg2 on 2 cdr's for 2h movie.......

Tommy Carrot
24th December 2002, 03:53
Originally posted by ^^-+I4004+-^^
and mpeg2 doesn't smooth?
have you ever compared nice clean PAL
tv signal with mpeg2 as seen in dvd player?
and you still take mpeg2 as a reference?
i regard dvd (mpeg2 stream) as less sharp than analog
PAL.......(yes i have seen quite a few decent dvd players in action...)
EVERY and ANY codec smooths.......that's why it's called
lossy compression.....(mpeg1,2,4 or rm...)
(sure,i would love to burn and watch my huff capturings...but..)

at the bitrate,rm9 is THE BEST,ie. try to make decent(!)
mpeg2 on 2 cdr's for 2h movie.......

No! I'm talking about Mpeg4 Advanced simple profile ofkoz. With about 1500 kbit, it's quite often gives at first sight identical result to the original. (Not always ofkoz, but often). RV9 blurs the picture at all bitrates. There is no 'same as the original' feeling.

This is all about target audiences. Realvideo has been created for streaming. Why would anybody want to stream at 1500-2000 kbit? It was optimized to <500-600 kbit, and it is very good at there.

midiguy
24th December 2002, 05:12
the blurring that you are seeing with real media clips is done by the built in post-processing of the REALPLAYER. the "blurryness" is not actually in the video file. Apparently, in the next version of the Realone player, it will allow us to configure the post-processing. also, the realone player, as it is now, tries to automatically detect a good post-processing level, so I would have to disagrtee with that even at very high bitrates RV9 is "blurry". try encoding a clip at, say, 2500 kbps. it will be a very sharp image. the realone player only post-processes like crazy when it detects too much video noise or pixelation, or not even. yes, it is WAY too harsh, but that is only because the real PLAYER was designed too play STREAMING media where more post-processing might be needed to clean up the clip. real networks is starting to understand that they could also support high quality high bitrate video, so future improvments in their player is inevitable the way I see it.

sorry about spelling/grammatical errors, I'm tired.

p.s.: what the hell is "ofkoz"? does it mean "of coarse"?

iwod
24th December 2002, 06:31
I know MPC could play RM.. but does MPC has post processing build in as well??

baddbill
24th December 2002, 20:24
Hi guys, I'm a somewhat newbie so take my opinion with a grain of salt. I've made about 40 or 50 encodes with Gordian Knot and divx5 and just made my first two encodes with AutoRV9. All I can say is wow! The AutoRV9 encodes in my opinion are far superior to anything I have been able to get with divx. The colors are closer to the original, the lighting is more natural and the detail is higher.

My first two encodes with AutoRV9 were The Waterboy and Can't Hardly Wait. I encoded both movies so each would fit on a 900 meg CD. This turned out to be 1280 bits for Can't Hardly Wait and 1500 bits for The Waterboy. I chose these two movies because they are at opposite extremes for compressability.

Can't Hardly Wait compresses very easily so it is easy to get a good encode of it with divx. The divx encode was with pro features of B frames and Psy. enhancements to normal. This resulted in a 76% comp test result at 576x320 with a sharp resize filter. I encoded the AutoRV9 copy at the same resolution. The divx encode looked good but suffered from the regular divx drawbacks. Edges where fuzzy and there was a general lack of detail. The RV9 encode looks wonderful. In almost every scene there is more detail in faces, clothes and background. The lighting is closer to the original and the colors are what they should be. When comparing the two encodes next to eachother I noticed that the divx encode had a greenish tint to it that wasn't in the original. Because the divx encode was of such high quality the comparison was close but the RV9 encode was clearly better.

The Waterboy is very difficult to compress and therefor it was very difficult for me to get a good encode of it with divx. I tried different resolutions with different resize filters and finally decided on a comp test of 67% at 512x272 with a neutral resize filter. The results were OK but not great. The RV9 encode at the same resolution was far superior. Once again colors where closer to the original without a greenish tint to them. Lighting was more natural and detail was obviously superior. There is one scene in the movie where The Waterboy walks into his mother house. It is a very difficult scene because of the detail in the livingroom. With divx this scene looked horrible. With RV9 this scene looks very nice, not perfect, but far superior to divx.

I hope this helps people. In my opinion RV9 is the way to go.

Bill

midiguy
25th December 2002, 03:28
yes, unfortuantely, MPC has the post-processing built in as well. to make a correction to my earlier post, I beleive that it is the real video DECODER doing the post-processing, and not the real player. I think the post-processing is built into the decoder itself. I know that the actual file has NO pre-processing built into it, so the blrryness you see has to be coming from the decoder or player. I tihnk it would be coming from the decoder because the blurryness even exists when you play your file with MPC (so that counts real player out). but I think that the post-processing is disabled or is very light if your clip was encoded at a high bitrate. I've only seen this "blurryness" only SOMETIMES with low bitrate encodes usually less than 600 kbits. and once again, I've heard that in the next version, you will be able to control the post-processing,. and not only that, the API is coming out soon I beleive. once it is out, developers should esaily be able to make something to control the post-processing levels of the decoder. other things that could be possible would be to be able to import real media files in, say, virtualdub, or possibly even encode right out of virtualdub or a similar editor. good things are coming!

Rash
31st December 2002, 17:17
Karl, I'm sorry what I'm saying may sound stupid but why don't you guys distribute the Helix Producer for free?

You know you have a lot of good competitors which are free (even WM9!). I'm not saying open source, just a "non-basic" version for free.

I got really interested in Helix Technology, but I'd still rather use free ones. :(

karl_lillevold
31st December 2002, 17:30
Originally posted by Rash
Karl, I'm sorry what I'm saying may sound stupid but why don't you guys distribute the Helix Producer for free
That's a good idea, and exactly what the price is right now (free). Go to https://helix-producer.helixcommunity.org/. Pre-compiled binaries are now available as well, so you no longer have to build it from source/binary codecs.

Sign up, agree to the license, and the binary EULA, and get 9.1 Milestone 1 (2002-Dec-16), command line app. This has the exact same features as the GUI. You can use AutoRV9 as a GUI front-end if you like. There may be other GUI front-ends as well. I know at least one was created when RV9 was first released in alpha release, as a command line encoder only.

Latexxx
1st January 2003, 14:05
Talking about my gui?
I tested it. it also works with new Helix Producer. One question: Does the binary version support yv12 encoding or do have to build it by myself to get it working?

karl_lillevold
1st January 2003, 17:03
Originally posted by Latexxx
Talking about my gui?
I tested it. it also works with new Helix Producer. One question: Does the binary version support yv12 encoding or do have to build it by myself to get it working?
Ah, yes. Excellent! I have added your tool to the first post (RV9 Info) in this thread.

The Helix Producer M1 build works fine with YV12, but there may be a ~20% loss in encoding speed unless you convert to YUY2 as the last step in the AVS script. With YUY2 conversion, the loss is ~5%.
I think they plan on building M2 (Milestone 2) this Friday, with YV12 no-extra-color-conversion support *)

*) Still has to swap chroma planes (U and V) to get from YV12 to I420. I would like to remove even this step and swap pointers inside the codec instead, but have not had time. I measured the potential speed improvement though, and it's really really minor.

Rash
2nd January 2003, 01:46
Originally posted by karl_lillevold
That's a good idea, and exactly what the price is right now (free). Go to https://helix-producer.helixcommunity.org/. Pre-compiled binaries are now available as well, so you no longer have to build it from source/binary codecs.

Thanks Karl ;)

Wilbert
3rd January 2003, 13:03
Sign up, agree to the license, and the binary EULA, and get 9.1 Milestone 1 (2002-Dec-16), command line app. This has the exact same features as the GUI. You can use AutoRV9 as a GUI front-end if you like. There may be other GUI front-ends as well. I know at least one was created when RV9 was first released in alpha release, as a command line encoder only.
I've done this. I have a login and a password, but if I click on "binaries" I got the message "Your account does not have the "Project Document - View" permission needed for you to access the page you requested in the distribution project (...)"

How do I get the binaries?