VP6 Codec Released! (was: this one is for doom9)

[SeeMoreDigital]

For all those who may have missed it.

In response to a question posted by Sagitaire, below is a statement from On2Tech regarding 2pass VBR encoding with VP6: -
Originally posted by On2Tech
Please be patient with us. We'll have a new codec for you to try shortly. The overall Quality and SSIM, and VQM measurements you got were bad for VP6 due to a set of bugs in the VP6 two pass compressor. I'm sorry we released it with these bugs. Unfortunately our own tests weren't adequete in the two pass arena. Your compressions revealed what our own tests failed to. Thanks.

The measurements I posted were with an almost fixed codec ( not the one you can download on On2's site). On the Harry Potter clip I got results that are better than real. My audience file in rmfactory only differed from yours in that I shot for 600000 instead of 580000). If you like I'll try again with 580000. ( I copied the audience file from your last compression test), though its kind of a moot point. My numbers won't mean much until everyone can verify them (probably after our thanksgiving break).

Visibly the results with the fixed codec were massively better than the version you produced. I'd like to post the clip, but company policy means we can't distribute anything that we don't have explicit rights to use "even trailers"..

In your version VP6 produced a couple of really terrible sections ( because we missed a keyframe, and didn't clamp q enough). You can check your VP6 clip for yourself. Open it up in Virtual dub and watch for the K that indicates keyframes. You'll find 20 or so missed keyframes.

You'll also see that our two pass datarate control wasn't very two pass. Due to another bug we effectively ended up shooting for a much flatter datarate. This meant that the PSNR was spikey which is bad for overall PSNR.

Note: You would have gotten somewhat better results out of VP6 by using a max quantizer of 15 instead of 40; but you shouldn't have to know that. The two pass compressor should handle things like that. Plus the other bugs (missing keyframes, and keyframes that were 10 db better and 20 times the size of subsequent frames etc) still would have resulted in VP6 encodings that were sub par and noticeably worse than Real.

NOTE: The effect of these bugs was very material dependent. A full movie wouldn't have had nearly as many missed keyframes ( the bug had to do with how close they were together). Plus big Keyframes don't hurt so much when their spread apart.

Again Thank you for including VP6 in your comparison! We now have a better codec because you did.
I'm sure glad there is an official explanation as to why the 2pass encodes that I, and others had generated did not live up to expectations!

I think it's fair to say that once this anomaly is corrected. On2's codec will be outstanding.

Cheers

[Bandung]

Not too many people in this forum are interested in low bandwidth encoding (ie for streaming or for playback on PDA's like pocket pc 200x). But with the quality that VP6 produces for low bandwidth, it is an ideal decoder for PDA players. A port of the VP3 codec was done for the Pocket MVP player. My question is this, are you ON2Tech interested in assisting with or producing a port of your VP6 decoder to this player as well?

[Bulletproof]

I tried some more testing with the codec and came to a similar conclusion. It seems no matter how high you set the datarate, the quality will not match to that of other MPEG-4 codecs. I have found that it will still drop details even when trying a "almost lossless" datarate. Also, when using the decoder most people probably set it to use "Best PSNR" or "Automatic", this just uses a whole bunch of post-processing, you just have to use "Fastest" setting which will totally disable the post-processing (which still shows loss of detail at high datarates vs MPEG-4). I will say though that the codec works pretty well at bitrates of ~300kbps, how well it stacks up against other lowbitrate encoders is another story and out of my interest.

[On2Tech]

Originally posted by Bulletproof
I tried some more testing with the codec and came to a similar conclusion. It seems no matter how high you set the datarate, the quality will not match to that of other MPEG-4 codecs. I have found that it will still drop details even when trying a "almost lossless" datarate. Also, when using the decoder most people probably set it to use "Best PSNR" or "Automatic", this just uses a whole bunch of post-processing, you just have to use "Fastest" setting which will totally disable the post-processing (which still shows loss of detail at high datarates vs MPEG-4). I will say though that the codec works pretty well at bitrates of ~300kbps, how well it stacks up against other lowbitrate encoders is another story and out of my interest.

VP6 has no loop filter; with no deblocking at all VP6 loses about .5 db psnr and looks blocky. The deblocker invariable adds to the quality of output. The deblocker is the only post processing that is on with Best-psnr selected.

As to loss of detail: Can you please post an example clip along with settings you used? Its possible the bugs listed with the two pass compressor are hurting your tests as well. I'd suggest you try lowering the max quantizer parameter and try clips with keyframes that are typically further away than 16 frames ( the bug I suggested) until we repost.

[On2Tech]

Originally posted by Bandung
Not too many people in this forum are interested in low bandwidth encoding (ie for streaming or for playback on PDA's like pocket pc 200x). But with the quality that VP6 produces for low bandwidth, it is an ideal decoder for PDA players. A port of the VP3 codec was done for the Pocket MVP player. My question is this, are you ON2Tech interested in assisting with or producing a port of your VP6 decoder to this player as well?

I'll bet we are. I'll pass the information on to others in the company and get back to you via private message...

[Bulletproof]

Originally posted by On2Tech
VP6 has no loop filter; with no deblocking at all VP6 loses about .5 db psnr and looks blocky. The deblocker invariable adds to the quality of output. The deblocker is the only post processing that is on with Best-psnr selected.

As to loss of detail: Can you please post an example clip along with settings you used? Its possible the bugs listed with the two pass compressor are hurting your tests as well. I'd suggest you try lowering the max quantizer parameter and try clips with keyframes that are typically further away than 16 frames ( the bug I suggested) until we repost.

I don't have the video readily available that I used for the test right now, but I'll describe it to you. Basically it was a scene where the camera was panning and chasing the front view of a car, while in the background there was very tall grass blowing in the wind. The original video was in very good quality and was downsized to 640x352 (25fps) using Neutral Bicubic mode. I set the datarate to 200k/s and set the minimum and maximum quantizers to 2, none of the extra options were selected. I also did the encode with the keyframes at 120 and 250 frames apart. One pass best quality mode was selected. When viewing the encode the tall grass in the background had its detail significantly decreased and the video looked overall blurry. When I set the video to Best PSNR or Automatic it would make the grass look like a giant green splotch. When trying the video in XviD with none of the extra settings, just plain vanilla XviD at quantizer 2, you can just see that the video overall looks more like the original and the grass looked sharp and overall the video was sharper. Now this wasn't a test for compression, this was just to see overall how much detail was retained.

I have also noticed that with VP6 the quantizers can be bought much further up with less degradation. I noticed that setting the minimum quantizer to 10 is nothing like XviD's quantizer 10. The temporal resampling may be helpful for 60fps video where the eye cannot easily notice the frame drops, and the spatial resampler sometimes works well, however I really couldn't get total control over those two options because I haven't studied them enough to really understand how they work.

To be fair I will post up screenshots for visual comparison when the newer build is out. Personally I do not trust PSNR, especially with two examples that I have expierenced: The video simply does not look better with "Better PSNR" selected when decoding, and when I had made a special quantizer matrix for XviD it actually makes the PSNR drop, but upon visual inspection there is an obvious increase in detail.

[Sagittaire]

@ Bulletproof

Try with SSIM or VQM ... there are psycho video quality test ...

[On2Tech]

Originally posted by Bulletproof
I don't have the video readily available that I used for the test right now, but I'll describe it to you. Basically it was a scene where the camera was panning and chasing the front view of a car, while in the background there was very tall grass blowing in the wind. The original video was in very good quality and was downsized to 640x352 (25fps) using Neutral Bicubic mode. I set the datarate to 200k/s and set the minimum and maximum quantizers to 2, none of the extra options were selected. I also did the encode with the keyframes at 120 and 250 frames apart. One pass best quality mode was selected. When viewing the encode the tall grass in the background had its detail significantly decreased and the video looked overall blurry. When I set the video to Best PSNR or Automatic it would make the grass look like a giant green splotch. When trying the video in XviD with none of the extra settings, just plain vanilla XviD at quantizer 2, you can just see that the video overall looks more like the original and the grass looked sharp and overall the video was sharper. Now this wasn't a test for compression, this was just to see overall how much detail was retained.

I have also noticed that with VP6 the quantizers can be bought much further up with less degradation. I noticed that setting the minimum quantizer to 10 is nothing like XviD's quantizer 10. The temporal resampling may be helpful for 60fps video where the eye cannot easily notice the frame drops, and the spatial resampler sometimes works well, however I really couldn't get total control over those two options because I haven't studied them enough to really understand how they work.

To be fair I will post up screenshots for visual comparison when the newer build is out. Personally I do not trust PSNR, especially with two examples that I have expierenced: The video simply does not look better with "Better PSNR" selected when decoding, and when I had made a special quantizer matrix for XviD it actually makes the PSNR drop, but upon visual inspection there is an obvious increase in detail.

I'd appreciate anything you can show, at Q's of 2 VP6 should have excellent quality, and the deblocker should be basically off ( even without the best PSNR setting). So what you are describing sounds very odd. I'll double check the code next week and repost.

[slavickas]

2 On2Tech:
can you give more details about differences between profiles, i encoded few videos at constant quantizer and files are nearly identical in size, i thought vp61 should be at least few percents better

and second q, one guy on winamp forum asked is any chance of encoding vp6 on k6-2, he said vp6 encoding requires sse(i have duron so can't comment on this)

[Jaques]

I am anxiously awaiting the fix for VP6, but in the meantime I'll ask a question. Are you going to do any optimizations for x86-64?

[On2Tech]

Originally posted by slavickas
2 On2Tech:
can you give more details about differences between profiles, i encoded few videos at constant quantizer and files are nearly identical in size, i thought vp61 should be at least few percents better

and second q, one guy on winamp forum asked is any chance of encoding vp6 on k6-2, he said vp6 encoding requires sse(i have duron so can't comment on this)

VP60 is basically a slightly simplified version of the VP61 bitstream. It shuts off quarter pixel motion estimation, a couple of prediction filters, and adaptive subpixel motion estimation. Other than that it is identical to VP61. The effect is major on some lower-res sharp clips, but on full d1 movies (or higher) its hard to see a big difference.

VP6 should work on any intel clone processor ( there is a fallback c implementation of every function). We have optimized VP6 for use on mmx machines, p3 machines and p4 machines. This means that we ahve 4 versions of a lot of functions. If anyone finds a machine it won't work on please let us know....

[On2Tech]

Originally posted by Jaques
I am anxiously awaiting the fix for VP6, but in the meantime I'll ask a question. Are you going to do any optimizations for x86-64?

Its not high on our current to do list but this may change if a paying customer requests us to do so.

However, we have done some work on newer Intel machines ( we got some help in this arena from Intel). Ie. our next release will probably support things like hyperthreading, and prescott instructions.

[SeeMoreDigital]

Hi On2Tech,

With regard to the comments you made about 2 pass encoding!

Do you have a date planned for an updated version of the codec?

Cheers

[Bulletproof]

On2Tech, do you know if changing the decoding method within control panel reflects what is used during the decoding process in VirtualDub? Cause it seems like when you view a file in VirtualDub that the deblocker is always on and this may have been what messed up my visual testing. On another note, I've been looking frame-to-frame using VirtualDub and noticed that in the VP6 video that some colors are completely dropped or totally off that don't represent the original video. Now it isn't very drastic, but you can definitely tell that some colors are gone from the video. Again, I'm just testing here and it's possible the decoder isn't working the way I want it to in VirtualDub, maybe the deblocker is blurring out the color.

[On2Tech]

Originally posted by Bulletproof
On2Tech, do you know if changing the decoding method within control panel reflects what is used during the decoding process in VirtualDub? Cause it seems like when you view a file in VirtualDub that the deblocker is always on and this may have been what messed up my visual testing. On another note, I've been looking frame-to-frame using VirtualDub and noticed that in the VP6 video that some colors are completely dropped or totally off that don't represent the original video. Now it isn't very drastic, but you can definitely tell that some colors are gone from the video. Again, I'm just testing here and it's possible the decoder isn't working the way I want it to in VirtualDub, maybe the deblocker is blurring out the color.

Virtualdub uses the vfw codec instead of the directshow codec. The vfw codec doesn't use the settings dialog instead it uses registry entries found under :

HKEY_LOCAL_MACHINE\SOFTWARE\ON2 Technologies\VFW Encoder/Decoder Settings\VP61

create two strings ( if they don't exist already)

strCPUFree = set to 0 to disable auto detection of what post processing to use and to enable the next setting

strPostProcessingLevel = set to 0 for nothing and to 4 for deblocking but no deringing (best psnr)

As to the color's I'm a bit at a loss. Most of our comparisons show we are far better in U and V than other codecs. In fact we may actually have gotten better quality by spending fewer bits on U and V than we do now.

Its also possible that our internal color conversion from YV12 to RGB24 is inaccurate or that it doesn't match the color conversion used to get it into YUV color space ( if any ).

[Bulletproof]

EDIT: Seems like images wont show up without clicking on the links, I posted images the same way in XviD forum and they show. Maybe a special rule for this part of the forum?

Ok that registry setting definitely helped. I can definitely say now that VP6 is a competitor now. I did a quick test with XviD 1.0 and VP6. Here's the settings:

Video Data
----------
640x480 29.970 FPS, 2:40.72 Duration


VP6 Settings
------------
Data Rate: 168 KB/s
Key Frame Interval: 999999
One Pass - Best Quality
Local File Playback (VBR)
Noise Reduction: 0
Auto Keyframe: ON
Max. Frames between keyframes: 300

Undershoot: 100%
Adjust Quantizer: 2-31
Temporal Resampling: OFF
Spatial Resampling: OFF

XviD Settings
-------------
Target Bitrate (kbps): 1344 (Equiv. of 168KB/s)

Profile: Unrestricted
Quantization: H.263
Adaptive Quantization: ON
Interlacing: OFF
Quarterpel: ON
Global Motion Compensation: ON
Reduced Resolution: OFF
BVOPs: ON
Max. Consecutive B-Frames: 1
Quantizer Ratio: 1.50
Quantizer Offset: 1.00
Packed Bitstream: OFF
Closed GOV: ON

Encoding Type: Single Pass
Reaction Delay Factor: 16
Averaging Period: 100
Smoother: 100

Chroma Optimizer: ON

Motion Search Precision: 6 - Ultra High
VHQ Mode: 4 - Wide Search
Chroma Motion: ON
Frame Drop Ratio: 0
Max. I-Frame Interval: 300
Min. I-Frame Interval: 1
Cartoon Mode: OFF

Min. & Max. I, P, B Quantizer: 2-31
Trellis Quantization: ON


FINAL FILE SIZES:
VP6.AVI - 28,889,088
XVID.AVI - 26,650,624


Now, VP6 handled quite well in some situations while XviD handled better than it in others and vice versa. I would say they are almost Neck-and-Neck, BUT you have to consider the fact that the XviD file came out 2 megs less than the VP6 file and and possibly extra bits could be used to totally edge out the VP6 file if you wanted the filesizes to be exactly the same. Either way they both perform quite well.


How I judged the XviD winners:

1. Look at the jumping monsters feet, also look at the ninja's leg.

2. Blocky all around shadows, even eyelashes and eyebrow blocky in the VP6 frame, the XviD frame does not exhibit this.

3. Samurai's Face is blocky, arm in action is blocky, his chainmail type armor is completely gone in the VP6 frame, you can still see it in the XviD frame.


How I judged the VP6 winners:

1. Overall the frame is blocky in XviD while it seems smooth and clean in the VP6 frame.

2. Non-moving gradient inside the logo is blocky and the "3" part of the logo which has a moving flame in it is blocky with the XviD frame. VP6 frame exhibits none of this.

3. Jumping ninja is all blocky and the samurais in the background are blocky in the XviD frame, The VP6 frame here looks alot better but however you can notice a weird "matrix" like pattern of squares in the background of the VP6 frame to the right of the ninja in the background which is supposed to represent a wall. Even still though, the VP6 frame looks better.



Winning XviD frames:

(XVID)
http://www.gamevids.net/xvid1.PNG

(VP6)
http://www.gamevids.net/vp61.PNG

(XVID)
http://www.gamevids.net/xvid2.PNG

(VP6)
http://www.gamevids.net/vp62.PNG

(XVID)
http://www.gamevids.net/xvid3.PNG

(VP6)
http://www.gamevids.net/vp63.PNG


Winning VP6 Frames:

(XVID)
http://www.gamevids.net/xvid4.PNG

(VP6)
http://www.gamevids.net/vp64.PNG

(XVID)
http://www.gamevids.net/xvid5.PNG

(VP6)
http://www.gamevids.net/vp65.PNG

(XVID)
http://www.gamevids.net/xvid6.PNG

(VP6)
http://www.gamevids.net/vp66.PNG

[On2Tech]

Originally posted by Bulletproof
EDIT: Seems like images wont show up without clicking on the links, I posted images the same way in XviD forum and they show. Maybe a special rule for this part of the forum?

Ok that registry setting definitely helped. I can definitely say now that VP6 is a competitor now. I did a quick test with XviD 1.0 and VP6. Here's the settings:



Some of your PNG files look suspiciously like VP6 missed marking a keyframe.

Can you please check whether the VP6 clip missed placing keyframes at cut scenes ( ie you can look for the K in the status bar via virtual dub)? If not can you get me a copy of the avi clip ( I'll pm you with a place to put it if necessary).

Missed keyframes is one of the bugs in the codec that we're fixing. It produces some blocky frames even at high datarates.

Internally VP6 has a parameter similar to XVID's Min. I-Frame Interval. We had this set to 16! This meant we missed a lot of keyframes in short trailer like clips.

If this is in fact the case in your clip I think you'll find the new VP6 to be greatly improved..

[trbarry]

If this is in fact the case in your clip I think you'll find the new VP6 to be greatly improved.

Do you mean a newer version has been posted or are you referring to something that will be out soon. I just checked yesterday since I was installing VP6 on a new machine and didn't see anything new.

- Tom

[Bulletproof]

Originally posted by On2Tech
Some of your PNG files look suspiciously like VP6 missed marking a keyframe.

Can you please check whether the VP6 clip missed placing keyframes at cut scenes ( ie you can look for the K in the status bar via virtual dub)? If not can you get me a copy of the avi clip ( I'll pm you with a place to put it if necessary).

Missed keyframes is one of the bugs in the codec that we're fixing. It produces some blocky frames even at high datarates.

Internally VP6 has a parameter similar to XVID's Min. I-Frame Interval. We had this set to 16! This meant we missed a lot of keyframes in short trailer like clips.

If this is in fact the case in your clip I think you'll find the new VP6 to be greatly improved..

Ok I took a look using Virtualdub and it did insert the keyframes at almost every scene change, however there were some spots I did find where a keyframe should've been inserted. One thing I noticed is that on a scene change where a keyframe was not inserted the keyframe was inserted late into the scene, but the immediate proceeding frames had worse quality, should not the frames nearest the keyframe have good quality? If you want me to post an example of this I can do that also.

[plonk420]

Originally posted by Bandung
Not too many people in this forum are interested in low bandwidth encoding (ie for streaming or for playback on PDA's like pocket pc 200x). But with the quality that VP6 produces for low bandwidth, it is an ideal decoder for PDA players. A port of the VP3 codec was done for the Pocket MVP player. My question is this, are you ON2Tech interested in assisting with or producing a port of your VP6 decoder to this player as well?

oops, i thought you were about to talk about low bandwidth encoding in a negative light and was about to go off on you ^_~. this stuff fascinates the shit out of me. i've been playing with this more than i ever played with WMV9, which also blew my mind (which was probably due to my inablility to figure out multipass divx encoding, leading to total crap divx encodes).

i posted some encodes that completely amazed me on newsgroups, alt.binaries.pictures.leek if anyone was interested. and yeah, i love music videos ^_^

[On2Tech]

Originally posted by trbarry
Do you mean a newer version has been posted or are you referring to something that will be out soon. I just checked yesterday since I was installing VP6 on a new machine and didn't see anything new.

- Tom

Nothing new yet. I'll post here when we are ready to put it out.

[On2Tech]

Originally posted by Bulletproof
Ok I took a look using Virtualdub and it did insert the keyframes at almost every scene change, however there were some spots I did find where a keyframe should've been inserted. One thing I noticed is that on a scene change where a keyframe was not inserted the keyframe was inserted late into the scene, but the immediate proceeding frames had worse quality, should not the frames nearest the keyframe have good quality? If you want me to post an example of this I can do that also.

Thanks for checking. Were any of the frames you showed ( particularly the blocky frames) frames that were missed keyframes or frames near a missed key frame?

Not sure why a frame preceding a keyframe would have bad quality but I suspect that they are related to the same bug. I suggest we just try again with a new version of the codec that will be coming soon.

[Bulletproof]

Originally posted by On2Tech
Thanks for checking. Were any of the frames you showed ( particularly the blocky frames) frames that were missed keyframes or frames near a missed key frame?

Not sure why a frame preceding a keyframe would have bad quality but I suspect that they are related to the same bug. I suggest we just try again with a new version of the codec that will be coming soon.

Yes one of the frames was missing a keyframe at its scene change in those pics. Perhaps since the keyframe was inserted late it just inserted it at a point with very bad reference data for the next P-frames, so I guess a keyframe inserted at the right point is better than a keyframe closer to a P-frame.

[trbarry]

I encoded a 45 minute HDTV clip at a resolution of 1440x608 with one pass best quality CBR.

It seems to look & play fine (but slowly) in Virtualdubmod but if I try to play it in Zoomplayer or WME it will immediately cause the player or even the machine to hang. It will even hang Graphedit the moment I drop it in.

Is that resolution over some limit for VP6?

- Tom

[SeeMoreDigital]

Originally posted by trbarry
I encoded a 45 minute HDTV clip at a resolution of 1440x608 with one pass best quality CBR.

Is that resolution over some limit for VP6?

- Tom Hi Tom,

Can I ask how you arrived at your image frame size?

It sounds like you are encoding from an 720i/p 'true 16:9 frame' source - You lucky man!

If that's the case then I would have thought the following 'true frame' image pixel frame sizes would apply: -
1.77:1 = 1280 x 720
1.85:1 = 1280 x 692 (688 to nearest 16th pixel)
2.35:1 = 1280 x 544

I'm assuming that a typical 2.35:1 image is not 'pulled down' when watching 720i/p broadcasts!

Cheers

[trbarry]

Can I ask how you arrived at your image frame size?

SeeMoreDigital -

It was a 1920x1080i movie, UnComb'd & Decimated to 1080p@24. After cropping obvious black bars and edge garbage it appeared to be about 2.40:1. Scaling to a 1440 width that gave me 1440x608 after rounding up to the nearest 16.

I was trying to make an excellent show piece sample encoding of what VP6 could do with a 3 hour HDTV movie on a DVD-9 dual layer red laser DVD (using 2 DVD-R's).

But I can't play the darn thing. :(

- Tom

edit: BTW, If it really had been a 720p movie they usually would have used whatever x:x pulldown to expand it to 60 FPS. Most stations just do that by duplicating frames for some reason, not even using repeat flags.

[SeeMoreDigital]

Originally posted by trbarry
SeeMoreDigital -

It was a 1920x1080i movie, UnComb'd & Decimated to 1080p@24. After cropping obvious black bars and edge garbage it appeared to be about 2.40:1. Scaling to a 1440 width that gave me 1440x608 after rounding up to the nearest 16. Wow, if that's the case then you could also have used: -
1.77:1 = 1920 x 1080 (1088 to nearest 16th pixel)
1.85:1 = 1920 x 1040
2.35:1 = 1920 x 816
2.40:1 = 1920 x 800

But this would involve using even more pixels!!

Originally posted by trbarry
I was trying to make an excellent show piece sample encoding of what VP6 could do with a 3 hour HDTV movie on a DVD-9 dual layer red laser DVD (using 2 DVD-R's).

But I can't play the darn thing. :( Personally I've not encoded with VP6 using any more than 576 vertical pixels. But I would have thought it should work. Even DivX and XviD work quite well upto 720 vertical pixels!

I guess it's still WMV9 or RV9 for HD stuff up to 1080 vertical pixels!

Cheers

[trbarry]

Personally I've not encoded with VP6 using any more than 576 vertical pixels. But I would have thought it should work. Even DivX and XviD work quite well upto 720 vertical pixels!

I guess it's still WMV9 or RV9 for HD stuff up to 1080 vertical pixels!

Rarely do I encode HDTV at more than 1280x720 (usually Xvid) and sometimes I just use 1/4 res 960x544 because it encodes so much faster. But I've had decent results with my other VP6 CBR testing (including VP6 1280x720p) and I wanted to take advantage of 2 full DVD-R's this time. So I thought I'd push it up to a 1440 width for the small amount of extra detail that might be there.

- Tom

[trbarry]

An update on my problem above. If I just keep my patience and my hands off the keyboard it will actually start playing after about 90 seconds. I guess that resolution and 850 KBps is just a bit too much for my 2.4 Ghz P4. It only plays at about 18 fps.

I'm going to re-re-encode at 1280x544 and 750 KBps to see what happens.

- Tom

[SeeMoreDigital]

Originally posted by trbarry
An update on my problem above. If I just keep my patience and my hands off the keyboard it will actually start playing after about 90 seconds. I guess that resolution and 850 KBps is just a bit too much for my 2.4 Ghz P4. It only plays at about 18 fps.

I'm going to re-re-encode at 1280x544 and 750 KBps to see what happens.

- Tom Cool.

I would like to think that a 2.4 P4 could generate more than 18fps!

If you think the source is 2.40:1 you could try 1280x528 (533 exact)!

Good luck Tom and let us know how you get on please.

Cheers

[On2Tech]

Originally posted by trbarry
An update on my problem above. If I just keep my patience and my hands off the keyboard it will actually start playing after about 90 seconds. I guess that resolution and 850 KBps is just a bit too much for my 2.4 Ghz P4. It only plays at about 18 fps.

I'm going to re-re-encode at 1280x544 and 750 KBps to see what happens.

- Tom

It seems strange that you'd have trouble playing back 1280x544 on a 2.4ghz pc ( unless you can't support a yv12 overlay of that size). We've done quite a few 8 megabit 1920x1080 on a 1.7 ghz P4( with no post processing) for one of our customers.

We are still optimizing the codec on the pc and may have something that works faster soon.

Nonetheless you may want to try VP60 ( simplified profile). I doubt you'll see a big quality difference at that frame size, but you may see a big improvement in playback speed.

[SeeMoreDigital]

Jeez,

That's good to know. Thanks for the info On2Tech.

Cheers

[trbarry]

It seems strange that you'd have trouble playing back 1280x544 on a 2.4ghz pc ( unless you can't support a yv12 overlay of that size). We've done quite a few 8 megabit 1920x1080 on a 1.7 ghz P4( with no post processing) for one of our customers.

On2Tech -

Thanks.

I am running Win/Me with a Radeon LE card. With that combination I've never managed to get native YV12 display support. The hardware claims it support YV12 overlay it but on any filter graph there always appears to be a path through YUY2 for some reason, with any codec. I gave up on that months ago. I realize that really pigs things out but don't know how to change it.

But it is really good to hear about 8 mbps 1920x1080 on a machine slower (supposedly) than mine.


Nonetheless you may want to try VP60 ( simplified profile). I doubt you'll see a big quality difference at that frame size, but you may see a big improvement in playback speed.


Now THAT is useful information! I've stated here many times that with HDTV rez clips the limiting factor is often the playback speed and not saving the last nickel on disk space. That's why I've stuck with CBR. Effectively I'm "streaming" through my video card and any large bit rate peaks would just end up being stutters and pauses.

So I'll try it again with VP60. I already have all post processing turned off in the control panel but maybe this will help a bit more.

- Tom

[Bulletproof]

I did a test of my own with some of my HD material, I tried encoding a 1920x1080i file using VP6 Advanced profile, datarate set to 8mbits and interlaced mode on. The actual encoding speed was below 1fps with fast compress on. Playback speed reported by the video renderer was only 15fps. My system is a P4 3.0ghz w/ Hyperthreading, DDR400 RAM, Radeon 9800 PRO. The video also had a big green line under it when playing it (which is not in the original).

[trbarry]

VP60 does seem to be a bit faster on playback. I lowered the resolution to 1280x544 and the bit rate to 750 KBps and it more or less plays at full speed. But with software ac3 decoding I get progressive sound sync problems as it still cannot quite keep up on my 2.4 Ghz P4.

But at least with VP60 it starts almost immediately. The delay in starting VP61 playback seems to be proportional to the size of the file. It takes over 4 MINUTES to start playing a 4 GB file on VP61.

My previous testing of VP61 720p material (my standard) had been at lower bit rates and I had not noticed any particular problems. But it appears to me that VP6x must (like in streaming) calculate how much material it is going to have to buffer ahead of time, at least in some situations. This is a problem for HDTV playback.

At the same bit rate and even a 1440x608 resolution I can play back Xvid with no problems. Maybe I need a better graphics card or drivers or something to get pass thru YV12 support.

- Tom

[plonk420]

Originally posted by On2Tech
We are still optimizing the codec on the pc and may have something that works faster soon.

does this mean it's coming out for other platforms as well? or am i reading too much into this? ^_^

[plonk420]

Originally posted by trbarry
VP60 does seem to be a bit faster on playback. I lowered the resolution to 1280x544 and the bit rate to 750 KBps and it more or less plays at full speed. But with software ac3 decoding I get progressive sound sync problems as it still cannot quite keep up on my 2.4 Ghz P4.

what are you using for the container file? AVI, OGM, MKV? i've heard MKV is advanced in some aspects, i'd think it'd have better syncing or whatnot, but i could be completely wrong...

[trbarry]

what are you using for the container file? AVI, OGM, MKV? i've heard MKV is advanced in some aspects, i'd think it'd have better syncing or whatnot, but i could be completely wrong...

I'm using AVI. But I suspect the sync problems are just insufficient CPU. I can temporarily fix them just by pausing it.

- Tom

[plonk420]

Originally posted by trbarry
I'm using AVI. But I suspect the sync problems are just insufficient CPU. I can temporarily fix them just by pausing it.

you should try MKV just for grins .. should be a simple demux and remux with the disgustingly easy (compared to learning 2 pass encoding for the first time) mkvmerge gui

http://www.bunkus.org/videotools/mkvtoolnix/

with help

http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html

i started using the MKV container after i had problems muxing VP6 and AAC-HE into an AVI and did some research between OGM and MKV and sided with MKV...

[SpaceV]

I know that the VP6 can be decoded by several
DSP chips. Since I heard that Philips and other Cos are
working on MPEG4 encoder chips, I was wondering if
ON2 is pushing that as well. I would like to see
an EVD recorder recording / compressing 720x480 and HDTV 720p in realtime on a DSP chip. Will we see that in the future and when ?
Thanks.

[On2Tech]

I've discovered, that the files we produced that played 8 megabits 1920x1080 on a 1.7 ghz P4 used a non released profile. I've been able to duplicate your speed problems with the codec as released.

We hope to address these speed issues in a future release.

[On2Tech]

Originally posted by SpaceV
I know that the VP6 can be decoded by several
DSP chips. Since I heard that Philips and other Cos are
working on MPEG4 encoder chips, I was wondering if
ON2 is pushing that as well. I would like to see
an EVD recorder recording / compressing 720x480 and HDTV 720p in realtime on a DSP chip. Will we see that in the future and when ?
Thanks.

As you may know we have a long standing relationship with a few chip manufacturers ( you can read about these in our press releases). In addition we've demonstrated 720p playback on a 400mhz equator chip to some of our partners,

Phillips:
http://www.macreport.net/featured/ONT/pr052003.asp

TI and Equator:
http://news.moneycentral.msn.com/ticker/sigdev.asp?Symbol=ont

I'm sorry but I can't reveal anything more about On2's part in EVD than what you can in our press releases:

http://biz.yahoo.com/djus/031118/0840000874_2.html

[SpaceV]

Thanks for your answer but I am not quite satisfied.

I know about the PLAYBACK capabilities of DSP chips
but if I am not completely wrong, realtime HD encoding takes
way more processing power than decoding.

So outside from EVD, the question: is ON2 working with
DSP companies to implement realtime ENCODING VP6 HD and 480p/i ?
When would those be available?

Thanks

[SeeMoreDigital]

Wow,

Yet another codec to appear on the Philips Nexperia (http://www.semiconductors.philips.com/products/nexperia/media_processing/pnx1500/index.html)processors!

No doubt this processor will not be cheap!

Cheers

[trbarry]

I've discovered, that the files we produced that played 8 megabits 1920x1080 on a 1.7 ghz P4 used a non released profile. I've been able to duplicate your speed problems with the codec as released.

We hope to address these speed issues in a future release.


Thanks. That will certainly be an important improvement for VP6/HD.

I'll be looking forward to it.

- Tom

[On2Tech]

Originally posted by SpaceV
Thanks for your answer but I am not quite satisfied.

I know about the PLAYBACK capabilities of DSP chips
but if I am not completely wrong, realtime HD encoding takes
way more processing power than decoding.

So outside from EVD, the question: is ON2 working with
DSP companies to implement realtime ENCODING VP6 HD and 480p/i ?
When would those be available?

Thanks

Sorry I didn't answer your question; unfortunately I can't. All I can do when asked questions regarding the future or even just future plans of the company is to point to our current press releases.

[SeeMoreDigital]

Originally posted by On2Tech
Sorry I didn't answer your question; unfortunately I can't. All I can do when asked questions regarding the future or even just future plans of the company is to point to our current press releases. It's a company secret then!

[Bulletproof]

One suggestion I have is if you could make that registry entry you gave me the default decoding mode when the DirectShow codec is not used, or at least make the control panel option also reflect changes on the other decoder as well.

[SeeMoreDigital]

I just thoght you would like to know.

But as of yesterday I am now able to view encodes generated by your codec on my TV/monitor via my Xcard!

And very nice they look too!

Cheers

[On2Tech]

Originally posted by SeeMoreDigital
I just thoght you would like to know.

But as of yesterday I am now able to view encodes generated by your codec on my TV/monitor via my Xcard!

And very nice they look too!

Cheers

Glad to hear it. We'll have a new version shortly. I think you'll find its two pass mode "greatly" improved.