VP6 improvements wanted inquire within.. [Archive]

virus

13th January 2004, 08:03

It's difficult to comment on a video format which is "secret" :)
I don't even know if VP6 is meant to produce MPEG-4 output or if you can break free and try new directions... (that would be great :cool: )
In no particular order:

1) support for bidirectional encoding
2) a "discard first pass" option may be useful
3) faster 2nd pass, but not at the cost of quality
4) the ability to choose between 2 or more quant matrices for low, mid, and high bitrates (maybe in 2-pass the codec can even figure out automatically which is the better... mmmh, sounds difficult :))
5) user's guide in PDF format (richer & more x-platform than DOCs...)
6) something like DivX's EKG tool, without the need for a 3rd pass

Sirber

13th January 2004, 13:40

1) a sticky post in Karl's style in this forum :D

C0mPr355

13th January 2004, 20:37

sirber: I totally agree ;)

as for the rest keep em coming...all great suggestions :)

Bulletproof

13th January 2004, 21:23

1) 2-pass rate control needs work.

2) Does the Undershoot contradict the 2-pass controls? What happens if you have it so the max bitrate you can use is 200% but your undershoot is set to 90% ? And does the undershoot work on all scenes or only high bitrate ones?

3) Not sure what "Up Watermark" is for here is the description in your DOC:

"Up Watermark. If the encoder is already compressing a smaller frame size than the input, this is the percentage that will allow the encoder to move up to a higher internal frame size."

On the spatial resampling description it says this:

"At playback time, the decompressed frames are restored to the frame size of the movie."

So what exactly does it mean when it says "a higher internal frame size" ?

4) I don't know if this is possible, but adding information to be used for post-processing in the AVI upon decoding. So some people may prefer to use no post-processing and some may decide to use light post-processing, and this information is saved in the .AVI and used by the decoder.

5) Motion based encoding mode, yes I know Nandub had this but it still comes in sort of handy. Normally a person would just cap the bitrate so that it can't use such a low bitrate for scenes in the Min Section dialog. But think how many bits are wasted here because one particular scene didn't do good with a low bitrate, now you have to cap off the rest of the movie and lose those saved bits. If you could just define bits to be used by motion then you won't have that problem. And I don't mean "High motion" and "Low motion", I mean much more specific than that, like a dialog where motion is defined by numbers, for example: 5-10% motion use 200kbps etc.

6) Option to choose whether you want bits to be taken in low light/dark scenes or if you want extra bits to be given in these scenes.

C0mPr355

14th January 2004, 17:29

Ok first of all the spatial and temporal resampling watermarks still refer to the buffer, max buffer, etc. When you have spatial resampling on we know that it dynamically resizes the video internally for compression (this has nothing to do with the output of the video as that should play back at the output size specified). Now If you have SR checked and the buffer drops below 35% (default) your video internally will be downsized to 320x240 (as an example). From there it is easier for the compressor to meet the buffer requirements for streaming playback and compress the clip at the same time. However, if the clip's buffer is able to exceed or meet the Up Watermark % then the clip will be internally resized back to its original intended compression size (640x480, 480x272, etc.). Again, this has nothing to do with output resolution, but upon playback you will be able to notice the upscaling effects in those affected SR sections because of the smaller internal compression size (jaggy edges, blurrier image, etc). Obviously this really is not advantageous to a half D1 or full D1 compressed image, but it can be good for something that is smaller than that and at a low bitrate.

I hope that helps.

IvS

15th January 2004, 03:08

Originally posted by Sirber
Speed isn't that important, quality is :)
To me speed is DEFINITELY included in "quality", not just visual quality. If speed didn't matter "that much" to anyone then people wouldn't optimize their code for speed so much and users would be unhappy + unable to do things with certain codecs such as capture video. Luckily developers understand how very important speed (performence) is and not just visual quality.

So add my vote for speed and less PR propaganda.

Kef71

15th January 2004, 11:00

My take on it. ;)

Three operating modes:

1. CBR – Constant bit-rate

This mode is intended for streaming over the internet and the rate controller tries to strictly keep the intended bit-rate.

2. ABR Average bit-rate (With optional n-Pass)

This mode is intended for storing movies and the rate controller varies the bit-rate to try to maximize visual quality. The rate controller still tries to keep the average bit-rate as close to the intended as possible. There should also be parameters on how much the rate controller is allowed to over/under shoot the desired bit-rate (in %) and the size of the rate-control buffer (1-60 sec.). An optional n-Pass should be available to improve quality as well.

3. VBR Variable bit-rate

This mode is intended for those who need constant quality, for example video editing, and you just define the quality using a quantizer value.

---

• forward prediction
• b-frame threshold
• max number of following b-frames (1-3)
• customizable quantizer matrixes
• cropping
• resizing (bilinear, bicubic, precise bilinear, precise bicubic & lanczos)
• option for noise reduction before/after resize (cropping always comes first!)

Some of these features are already present, but I think you should make the interface a bit “clearer”. As it is now it’s not completely clear (for the average Joe that is) how to get VBR as an example...

Kef

justin

15th January 2004, 19:01

slower h264 like encoding mode :eek:

Taktaal

18th January 2004, 17:17

Linux binaries so you can play VP6 movies on the xbox to the TV

Maximus_G

19th January 2004, 05:10

On2:
Thank you for the VP6, i'm not using DivX anymore :)

And the wish list:

1. For me, it is preferrable to have an ability to insert keyframes at some desired place. In particular, it is needed in order to cut big AVIs as wanted. For example, when i need to fit a multiple-Gb file in several CDs, and there are very long no-keyframe sequences.
Maybe this option would look like an additional encoding Mode. Without real reencoding, just direct stream copying and placing keyframes at the points specified by the user in a text box.

2. When specifying bitrate, we are able to put integer values only. See, the only real advantage of putting kbit/s versus kbytes/s is that we can tell the codec to use 8 time more precise value. So, for those of us who like Precision in a paranoidal way :p it would be nice to specify decimals or kbits.

3. Some utility that could treat first-pass results. First of all, the codec does not always achieve the desired bitrate. For example, i encode my home video at 257 kbytes/s so i can fit 45 minutes of AVI in 701Mbytes. When i use this value with VP6, it gives me about 260-262 kbytes/s. So i have to lower encoding value to approx. 252 +- something. Maybe, after the first pass we can already see what bitrate there would be? So we could adjust second pass bitrate value?

And the last, and the least.
There is an automatic keyframe insertion algorythm now. I think it would be nice to implement a scene-change-threshold keyframe insertion mode. So we could make fast-moving parts look even better.

yedo1

19th January 2004, 12:04

I am not professional of video encoding like other Doom9 members.I think the setting menu of VP6 is difficult to understand for an ordinary person compared with other rival codecs.If On2 want to promote their codec to the ordinary PC users like WMV or DivX. It need to chenge setting menu more easy.

I have question about configuration. at "advanced" tab "datarate control" we can set watarmark value(%).
What is 100% or 0% mean? I guess 100% is target datarate.Is it correct?

Another question is about streaming parameter.I use VP6 for NSV video streaming.I think thiss section is important for me.
Here I can set peak bitrate.But I did set target datarate at outside of codec.I can't understand why I need set twice.
I've used WMV and RM. neither have bitrate setting at once.I made NSVs at 100% of peak bitrate.
But On2 suggestted in his document peak bitrate should be 80-90%.
Please tell me If I set 100% of peak bitrate,Do I cause some trouble to streaming?

GolovachLena

19th January 2004, 16:23

Some stats-reader would be nice. Also i'd be glad to see (and control them of course) "zones" like in Xvid 1.0

GolovachLena

19th January 2004, 16:24

Oh, i almost forgot it...
Plese, make brightness/gamma controls in decoder!! Please, please!!!

Maximus_G

20th January 2004, 01:09

Originally posted by yedo1
I am not professional of video encoding like other Doom9 members.I think the setting menu of VP6 is difficult to understand for an ordinary person compared with other rival codecs.If On2 want to promote their codec to the ordinary PC users like WMV or DivX. It need to chenge setting menu more easy.
I guess that's simple - either you choose to go to "advanced" tab, or you just don't, and use predefined settings.

I have question about configuration. at "advanced" tab "datarate control" we can set watarmark value(%).
What is 100% or 0% mean?
Look up at the previous page of this thread:
C0mPr355:
Ok first of all the spatial and temporal resampling watermarks still refer to the buffer, max buffer, etc. When you have spatial resampling on we know that it dynamically resizes the video internally for compression (this has nothing to do with the output of the video as that should play back at the output size specified). Now If you have SR checked and the buffer drops below 35% (default) your video internally will be downsized to 320x240 (as an example). From there it is easier for the compressor to meet the buffer requirements for streaming playback and compress the clip at the same time. However, if the clip's buffer is able to exceed or meet the Up Watermark % then the clip will be internally resized back to its original intended compression size (640x480, 480x272, etc.). Again, this has nothing to do with output resolution, but upon playback you will be able to notice the upscaling effects in those affected SR sections because of the smaller internal compression size (jaggy edges, blurrier image, etc). Obviously this really is not advantageous to a half D1 or full D1 compressed image, but it can be good for something that is smaller than that and at a low bitrate.

I hope that helps.

Maximus_G

22nd January 2004, 01:03

Speaking of the utility that could analyse first-pass results.
One more thing that could be useful. There are not so few cases when we need to encode video aiming not at the target file size, but trying to achieve the desired video quality. Sometimes we want it to be nearly perfect, and sometimes - less or more lossy (when we put it on web). So there should be a way to choose bitrate in a quality-based style.

We could do it this way:

1. Look at video and roughly estimate the appropriate bit-per-pixel value, then calculate the corresponding bitrate.

2. Make first pass.

3. a. Use the utility that would read the first-pass results and calculate an overall complexity of the video. I presume that we can bind this parameter with the bit-per-pixel value of the videostream.

3. b. So, when we know the complexity value, we are able to calculate the bitrate that would give us the 100% quality.

3. c. Knowing the quality/bitrate dependency curve of the VP6 (it's exponential, right?), we calculate the bitrate respectively to the quality desired.

4. And then we adjust the second-pass bitrate.

It's kinda quality-based AND two-pass. Would be great :)

---

On2, PLEASE respond :)

On2Tech

22nd January 2004, 01:22

Originally posted by Maximus_G
Speaking of the utility that could analyse first-pass results.
One more thing that could be useful. There are not so few cases when we need to encode video aiming not at the target file size, but trying to achieve the desired video quality. Sometimes we want it to be nearly perfect, and sometimes - less or more lossy (when we put it on web). So there should be a way to choose bitrate in a quality-based style.

We could do it this way:

1. Look at video and roughly estimate the appropriate bit-per-pixel value, then calculate the corresponding bitrate.

2. Make first pass.

3. a. Use the utility that would read the first-pass results and calculate an overall complexity of the video. I presume that we can bind this parameter with the bit-per-pixel value of the videostream.

3. b. So, when we know the complexity value, we are able to calculate the bitrate that would give us the 100% quality.

3. c. Knowing the quality/bitrate dependency curve of the VP6 (it's exponential, right?), we calculate the bitrate respectively to the quality desired.

4. And then we adjust the second-pass bitrate.

It's kinda quality-based AND two-pass. Would be great :)

---

On2, PLEASE respond :)

You are essentially describing what we do in the two pass right now. Problem is the estimate of complexity doesn't translate to an estimate of frame quality; nor for that matter do constant quantizers.

One way to insure truly constant quality might be to allow a person to pass in a required quality ( for example in decibels if you are using PSNR). The compressor would then pick whatever quantizer was necessary to equal or exceed that quality ( in this case PSNR). This can actually done in 1 pass mode. In two pass mode you might then be able to estimate the best constant quality (PSNR) achievable at a given bitrate...

Whether truly constant quality is actually desireable is another issue all together....

On2Tech

22nd January 2004, 01:37

Originally posted by virus
It's difficult to comment on a video format which is "secret" :)
I don't even know if VP6 is meant to produce MPEG-4 output or if you can break free and try new directions... (that would be great :cool: )
In no particular order:

1) support for bidirectional encoding
2) a "discard first pass" option may be useful
3) faster 2nd pass, but not at the cost of quality
4) the ability to choose between 2 or more quant matrices for low, mid, and high bitrates (maybe in 2-pass the codec can even figure out automatically which is the better... mmmh, sounds difficult :))
5) user's guide in PDF format (richer & more x-platform than DOCs...)
6) something like DivX's EKG tool, without the need for a 3rd pass

VP6 is not an MPEG-4 output. It is purely proprietary.
Thanks for the suggestions.

1) B-frames cost a lot on decode plus add a frame delay which is dependent upon the number of B frames used. We've avoided them thus far.

2) We'll try and get that one in the next version.

3) Faster first pass is actually easier. Already you have 2 options on the second pass ( best-quality) and good quality I think the difference in visual quality isn't all that much. Give it a try.

4) I think your asking for sharper output particularly at higher datarates. We hear that loud and clear. We're working on that now.

5)I'll pass on the request about PDF but what do you think of HTML? That' a bit easier for us?

6) Haven't thought about this one much but we'll look into it.

On2Tech

22nd January 2004, 01:39

Originally posted by GolovachLena
Oh, i almost forgot it...
Plese, make brightness/gamma controls in decoder!! Please, please!!!

Nice idea, but right now its low on our priority list. perhaps in the meantime you can use something like ffdshow ?

On2Tech

22nd January 2004, 01:42

Originally posted by SeeMoreDigital
Being able to enter kbps values instead KBps values would be helpful.

And is there any reason why you can't enter the bitrate in the application itself?

Anamorphic flagging, using a similar system to the one that the new XviD codec uses, would be nice too!

Cheers

I understand the request. XVID, DIVX and WM9 all seem to accept datarate on their internal dialogs rather than through the standard vfw interface. Its certainly doable. We're considering that move.

Our only source of hesitation : we have a bunch of clients, and internal applications who depend on passing the datarate to the codec in the way it is now.

On2Tech

22nd January 2004, 01:49

Originally posted by SocketA
More / Better interlace options.

With this I mean, that the way VP6 de-interlace right now is bad (it blends the 2 fields together).
In fast moving videos (like music videos), it just get too blury.

Blending 2 fields together is the worst way of 'de-interlacing' I know.

Option 1 : Make it drop one of the fields

Option 2 : Make the video 2x the frame rate (the best way).

To understand why I would like the 2nd option take a good look at :

http://www.100fps.com

That guy knows what he's talking about :)

Thank for the suggestions. Unfortunately raising the frame rate in a vfw codec is a bit difficult. Doing so in an application that plays back interlaced clips is not however.

Perhaps in the future we could provide 2 deinterlacing options ( drop a field ) and blend? In our testing we found that we generally preferred the blend option over the jagged lines we got when dropping a field..

Sirber

22nd January 2004, 02:04

Originally posted by On2Tech
Our only source of hesitation : we have a bunch of clients, and internal applications who depend on passing the datarate to the codec in the way it is now. You can use both I think, if VFW is not use, ust the one in the codec :D

On2Tech

22nd January 2004, 02:54

Originally posted by Bulletproof
1) 2-pass rate control needs work.
Any suggestions?

2) Does the Undershoot contradict the 2-pass controls? What happens if you have it so the max bitrate you can use is 200% but your undershoot is set to 90% ? And does the undershoot work on all scenes or only high bitrate ones?

Undershoot tells the codec to target a bitrate less than the current datarate target ( decided by the difficulty of the section), unless the estimated buffer is full. If the buffer is full this parameter does nothing. It is less relevant in two pass mode.

3) Not sure what "Up Watermark" is for here is the description in your DOC:

"Up Watermark. If the encoder is already compressing a smaller frame size than the input, this is the percentage that will allow the encoder to move up to a higher internal frame size."

On the spatial resampling description it says this:

"At playback time, the decompressed frames are restored to the frame size of the movie."

So what exactly does it mean when it says "a higher internal frame size" ?

When the option to allow spatial resampling is on VP6 can resize the frame to a smaller size as a datarate conrol. ( eg it can resize to 480x480 when given 640x480 source). A higher internal frame size is thus a frame size in between the small one we are currently encoding and the input frame size.

4) I don't know if this is possible, but adding information to be used for post-processing in the AVI upon decoding. So some people may prefer to use no post-processing and some may decide to use light post-processing, and this information is saved in the .AVI and used by the decoder.

Yes it is possible, but I think its somewhat clunky. You'd have to store this information at each keyframe in case someone carves up the avi file..

5) Motion based encoding mode, yes I know Nandub had this but it still comes in sort of handy. Normally a person would just cap the bitrate so that it can't use such a low bitrate for scenes in the Min Section dialog. But think how many bits are wasted here because one particular scene didn't do good with a low bitrate, now you have to cap off the rest of the movie and lose those saved bits. If you could just define bits to be used by motion then you won't have that problem. And I don't mean "High motion" and "Low motion", I mean much more specific than that, like a dialog where motion is defined by numbers, for example: 5-10% motion use 200kbps etc.

Its an interesting idea. In two pass mode the bitrate allocated to a section is allocated proportionate to the section's complexity. The variability parameter is used to determine how proportionate it is. Rather than do this we could allow a user to specify datarates for different complexity ranges as you suggest. This would make things a bit more configurable but would make configuring the codec quite a bit harder. Have you tried the variability parameter?

6) Option to choose whether you want bits to be taken in low light/dark scenes or if you want extra bits to be given in these scenes.

I think really low contrast dark scenes get short changed by our current complexity measure. We can do a better job. Thanks for pointing it out.

On2Tech

22nd January 2004, 03:01

1. For me, it is preferrable to have an ability to insert keyframes at some desired place. In particular, it is needed in order to cut big AVIs as wanted. For example, when i need to fit a multiple-Gb file in several CDs, and there are very long no-keyframe sequences.
Maybe this option would look like an additional encoding Mode. Without real reencoding, just direct stream copying and placing keyframes at the points specified by the user in a text box.

Are you using virtual dub? If so you can specify frames to make keyframes in virtual dub by marking them.

3. Some utility that could treat first-pass results. First of all, the codec does not always achieve the desired bitrate. For example, i encode my home video at 257 kbytes/s so i can fit 45 minutes of AVI in 701Mbytes. When i use this value with VP6, it gives me about 260-262 kbytes/s. So i have to lower encoding value to approx. 252 +- something. Maybe, after the first pass we can already see what bitrate there would be? So we could adjust second pass bitrate value?

I understand. Perhaps we've been a bit to aggressive in our datarate control. We'll look into it.

[/QUOTE]
And the last, and the least.
There is an automatic keyframe insertion algorythm now. I think it would be nice to implement a scene-change-threshold keyframe insertion mode. So we could make fast-moving parts look even better. [/B][/QUOTE]
Are you suggesting that we throw more keyframes in a fast moving scene?

On2Tech

22nd January 2004, 03:12

Originally posted by yedo1

I have question about configuration. at "advanced" tab "datarate control" we can set watarmark value(%).
What is 100% or 0% mean? I guess 100% is target datarate.Is it correct?

Here I can set peak bitrate.But I did set target datarate at outside of codec.I can't understand why I need set twice.
I've used WMV and RM. neither have bitrate setting at once.I made NSVs at 100% of peak bitrate.
But On2 suggestted in his document peak bitrate should be 80-90%.
Please tell me If I set 100% of peak bitrate,Do I cause some trouble to streaming? [/B]

Peak Bitrate: some of our customers told us that while they can actually stream to each client at datarates of 1 megabit they actually don't want the average datarate to exceed 500 kilobits. When you use a peak bitrate of 200 percent and a target of 500 kilobits you say that the buffering constraints must be met as though the file is being streamed at 1 megabit but that we should target 500 kilobits over all. I doubt you need this functionality. Leave it set at 100%.

I think that the document talks about setting 80-90% for undershoot percentage. That number is recommended so that we attempt to save some bits in order to keep the quality high in difficult sections.

On2Tech

22nd January 2004, 03:18

Originally posted by justin
slower h264 like encoding mode :eek:

The h264 reference code has an extremely slow (RDOPT) mode ( made even slower by performing hadamard transform). VP6 does something equivalent to RDOPT in best quality mode. We don't go to quite the same extremes, because we determined that the benefits of going to the same extreme was minimal and the cost exponential.

Selur

22nd January 2004, 08:41

optional gpu support would be nice ;)
(I like the idea of my graphic card helping my cpu during encoding)

Cu Selur

eltoder

22nd January 2004, 09:39

I also wish ability to specify bitrate in codec GUI (and in kilobits per second), faster speed of the second pass (in Best Quality mode it's too slow for me, but Good Quality is also slow, but I guess you're doing your best here anyway :)) and better two-pass rate control (it usually gives me 1-2% over/undersized files).

Also it's not very clear for me what CBR/VBR switch does in two-pass mode.

Thank you for your hard work :)

-Eugene

On2Tech

22nd January 2004, 14:01

Originally posted by Sirber
You can use both I think, if VFW is not use, ust the one in the codec :D

There is no way to know whether or not people have typed a datarate in the virtual dub box when the configure window is open. In affect you'd be forced to let people type in both and work it out at compression time.

I think a registry setting that allows you to pick between the two modes will work better.

virus

22nd January 2004, 14:19

Originally posted by On2Tech
VP6 is not an MPEG-4 output. It is purely proprietary.

OK, that's great :cool:
I had the impression your codec was quite different from the others.
You can do better than MPEG-4, you know. Research is important.

1) B-frames cost a lot on decode plus add a frame delay which is dependent upon the number of B frames used. We've avoided them thus far.

yes, the delay is bad. I was only assuming that B-frames can increase VP6's performance in compressibility. If you find out different ways to improve, just don't use B-frames :)

3) Faster first pass is actually easier. Already you have 2 options on the second pass (best-quality) and good quality. I think the difference in visual quality isn't all that much. Give it a try.

I'm happy with the quality of "Best quality" mode, and I usually look for the best mode available. Anyway, don't change your RC algorithm for speed. Just try with some optimizations (some nasty programming tricks, lookup tables, compiler switches, everything :D). Maybe you can buy something. I'm not asking for a new encoder mode. If you had to change something, focus on how to hit the target size precisely. VP6-BQ is a bit slow, but not that slow :)

5)I'll pass on the request about PDF but what do you think of HTML? That' a bit easier for us?

Well, PDF is a single file while HTML w/ some images is not, but when you have all the htmls/gifs/jpegs in a separate directory under the main installation dir, well, there should be no problem.
BTW, I'm really surprised you use DOCs... don't you state in your white paper that you are battling with Microsoft? :D :D :D

thx for your answers :)
cheers
virus

bond

22nd January 2004, 18:09

Originally posted by virus
OK, that's great :cool:
You can do better than MPEG-4, you know. Research is important.well even better than a proprieatary format would have been if vp6 would have been h.264 (which is mpeg-4 too btw) compliant :D

but following standards is not that "in" in the media business _atm_ it seems :rolleyes:

virus

22nd January 2004, 22:37

Originally posted by bond
well even better than a proprieatary format would have been if vp6 would have been h.264 (which is mpeg-4 too btw) compliant :D

AFAIK, H.264 is still not finalized (or maybe they've just completed it, don't know for sure).
I really don't know if/when this standard will be of any practical use. Probably, when it will spread and became fully supported (2005? 2006? 2007? if ever ;)) we will end up with an "old" standard, superseded by newer compression schemes. I really don't know why so many people look at MPEG-4 Part 10 as the definitive video codec :confused:
Methods for achieving better compression have been known for ages (e.g. vector quantization), you just need to find the right approximations or you'll end up with a codec that needs a week for a 30-seconds clip :eek:
IMHO H.264 is not worth the wait... too much complexity added to the encoder, to get little returns. I think something different has to be tried. "Adaptation" is a magic word, for example. Just think how many good ideas (like modulated quantizers in XviD) have been discarded because they're not MPEG-4 compliant.
As time and research go on, that "MPEG-4 compliant" brand, which now means "excellence", can turn into a burden.

but following standards is not that "in" in the media business _atm_ it seems :rolleyes:

maybe it's just me, maybe I'm wrong, but all those patents on MPEG-4 make me think of this standard as a "media business" almost as much as VP6... :(
As an enthusiast I'm interested in newer and free standards, but as a "customer" I really don't care about them. Just take my clips and squeeze them as much as possible, in reasonable time. The average end user knows almost nothing about H.264 and similar.

bond

22nd January 2004, 23:10

ok you convinced me
open standards are bad things cause
- they take a long time till they are widely used
- they limit the usable coding technology
- their coding technology is outdated at that moment already

damn you are right, now that i think about it again, i realise that i always had the feeling in the last years that using xvid/mpeg-4 was a bad idea/outputted lower quality than possible/was outdated technology... :D

hm, but wait these 3 points are also there for proprieatary formats :D

hm, and wait, if on2 would have spent their developing power in developing a h.264 compliant codec (and not a proprieatary format) we would have the maybe first really usable implementation of it and we wouldnt need to wait anymore
[maybe also with good speeds, i doubt that you or i ever saw an example of what a tuned h.264 codec could reach speedwise
and with more than only "little returns"
totally untuned encoders (maybe based on the reference software) arent really usable for comparisons]

but they didnt...

btw aac (also mpeg-4) was talked about for a long time, but when apple and ahead jumped on it it started to become popular (and is still the state of the art)
and at least i prefer it over a proprieatary closed format like wma9

it doesnt need much till an open standard gets used (in fact it needs exactly the same as if developing a closed format codec ;) )

damn again this open standard vs. closed format discussion

Sirber

22nd January 2004, 23:20

open or close, only quality matters :D

stax76

22nd January 2004, 23:20

many applications like DVX and Gordian Knot setup codecs with the registry with strings and dword's, there is no other way without knowing the structure of the codec settings which isn't helpful because the structure changes often. Also for such applications it's important the bitrate is entered in the main dialog and users are used kbps from DivX. DivX and XviD are most of the time nicely to use by such applications. I wish codecs would care better about beginners and lazy folks with things like online help, tooltips, warn messages, proven conceps, HIG, standards etc. Is there a way to encode and decode on Linux machines?

bond

22nd January 2004, 23:25

Originally posted by Sirber
open or close, only quality mattersyeah exactly

and i have to admit vp6 provides not bad quality :D

but if someone badmouths mpeg-4 i cant hold myself back ;)

virus

22nd January 2004, 23:55

@bond:

I don't want to start a flame, seriously.
You have your opinions, I have my opinions :)
You're happy with H.264, I'm happy with VP6.
I don't know why you mentioned XviD, which is MPEG-4 Part 2 anyway (long time finalized) and is very different from H.264 Best Profile (no CABAC, no RDOpt, no Hadamard, and so on)
You think MPEG-4 is an "open standard", I think it is not so "open" (patents ;)).
I really hope you will be happy with fine-tuned, optimized H.264 codecs when they will be ready. My opinion is that you will be a bit disappointed. The guys over at On2 already demonstrated better performance at least on some clips. Even XviD may be a better choice if speed matters. But this may change in the future.
I don't believe in "closed" nor "open".
They're all trying to earn some $$$ I think ;)
I believe in research, both for open or closed formats.
Moving forward, that's it. And I think international standardization processes are way too long... so a lot of "forums" are popping out (made by corporations which don't want a truly open standard made in 3 years, but a "semi-open" standard made in 1 year)

don't be in anger and be happy with MPEG-4 :)

cheers :)
virus

(BTW: AAC is included in MPEG-4, but I think it was developed for MPEG-2 (early 90s...), since mp3 is MPEG-1. But we're totally off-topic here :))

Sirber

23rd January 2004, 00:39

@Virus

are you happy with Real Video? ;) :D

virus

23rd January 2004, 00:46

Originally posted by Sirber
are you happy with Real Video? ;) :D

please forgive me... I don't use RV for my encodings :) :D :D

Assault

23rd January 2004, 15:26

Sorry for being a little bit OT.

IMO it isn't right to think that a closed format(like VP6) means automatically good quality and vice versa. I like VP6 but it isn't better than XviD (yes the old MPEG-4 Part 2 ;))IMHO.
I just encoded the old LOTR I Trailer with both VP6 and XviD and although the quality is very similar I like the XviD encode a little bit more. Without any PP it has LESS blocks (believe it or not) but a little bit more mosquito noise than the VP6 encode. Furthermore the XviD encode is a little bit more detailed. When watching the encodes with PP enabled it's very hard to see any artefacts at all.
I used a bitrate of 600kb and a resolution of 560x256 (I use Matroska. So the AR gets corrected during playback). (For those of you who are interested: that means a compressibility of 48% for the XviD encode.)

Assault

stax76

23rd January 2004, 15:47

I'm not sure Sirber meant explicit picture quality since he seem to be fascinated by high compression ratios. XviD quality is not that great if you don't have more than one CD for your LOTR

Assault

23rd January 2004, 16:56

@ Dolemite

Oh my post wasn't directed to Sirber bur rather to virus. :) I had the impression that virus equated (is that the right word?) closed formats with good quality and open formats with bad quality. So I just wanted to make clear that this isn't the case in my opinion. :p

Assault

virus

23rd January 2004, 18:39

Originally posted by Assault
I had the impression that virus equated (is that the right word?) closed formats with good quality and open formats with bad quality. So I just wanted to make clear that this isn't the case in my opinion.

I never stated that "VP6 is better than XviD", we were talking about H.264 which, despite being MPEG-4 as XviD, is so different you can call them two different standards (Part 10 introduces a lot of changes over Part 2).
I respect your opinion: it's up to you to decide which codec works best for you. A couple of weeks ago I posted a comparison VP6/XviD in the VP6 6.1.0.2 release thread, stating clearly that VP6 seems better to me under 0.2 bpp, but it's not so detailed at higher rates, because XviD's MPEG quantization keeps more detail... On2 is working on this issue just now. I even posted a list of VP6's "flaws"... :)
I never talked about "open formats with bad quality" too. When usable, optimized H.264 implementations will be ready, I don't expect them to be "bad quality", absolutely. I expect great quality but a very slow encoder (there are a lot of research papers studying H.264 complexity). Why not to try a different road to achieve that "great quality", even if it is not standard-compliant? This is what I think. Just wanted to clarify this point ;)

cheers :)
virus

Assault

23rd January 2004, 19:08

Originally posted by virus
Why not to try a different road to achieve that "great quality", even if it is not standard-compliant?

Big companies like Microsoft and Real develop proprietary standards since a few years! But did it pay off? What's the result until now? There is no proprietary codec that clearly outperforms the old MPEG-4 Part 2 based XviD (IMO). I sometimes wonder what quality would be possible if such companies developed H.264 instead. ;)

Assault

bond

23rd January 2004, 19:26

Originally posted by Assault
Big companies like Microsoft and Real develop proprietary standards since a few years!yep and they have exactly the same "problem" as any open standard, which is caused by the so called "backwards compatibility"

after on2 fixed the specs of vp6 they cant really change it anymore without breaking backwards compatibility
meaning according to what virus meant about open standards, it has the same problem with being outdated after some time (and it takes lots of time till a format gets widely used)

I sometimes wonder what quality would be possible if such companies developed H.264 insteadyep thats what i also thought about ... real and on2 deciding to produce a real h.264 compliant codec and not proprieatary formats

look at what a really highly tuned codec, like nero digital, can reach speedwise with mpeg-4 part2, its fantastic
if nero would reduce the speed only a little bit to be able to get more sharpness, it would be still one of the fastest codecs out there

and now imagine a tuned h.264 codec, yeah :D

i think we are now in a transition time, similar to the betamax vs. vhs time, digital coding is becoming a big market in the future, in the long run only one format will succeed and there is a lot of money to earn for a company if their proprieatary format wins (simply look how m$ is pushing their crappy wma9 format as a mp3 successor, tough its prooven that it provides lower quality than aac or vorbis)

lets ensure that the winning format is an open standard, usable for everyone and everywhere!

MfA

23rd January 2004, 19:59

Apart from RV all the major codecs will be open standards soon.

virus

23rd January 2004, 20:11

Originally posted by bond
lets ensure that the winning format is an open standard, usable for everyone and everywhere!

OK, OK, agreed, you're right! :rolleyes:
You won. I'm not so ingenuous to discuss a topic anymore with one of this forum moderators ;)
Are you happy now? You bashed one of those stupid newbies who badmouths your beloved standard :D
Let's repeat together:
"Lets ensure that the winning format is an open standard, usable for everyone and everywhere: Ogg Theora!" ;) :D :D
(sorry, this is the only free, open video standard I know of... btw it's based on VP3, released open-source by the devilish On2 Technologies, the same company which is "using their developing power" to develop their crappy non-H.264 codec :D)

goodbye :rolleyes:
virus

slavickas

23rd January 2004, 20:43

Originally posted by Assault
Big companies like Microsoft and Real develop proprietary standards since a few years! But did it pay off? What's the result until now? There is no proprietary codec that clearly outperforms the old MPEG-4 Part 2 based XviD (IMO). I sometimes wonder what quality would be possible if such companies developed H.264 instead. ;)

Assault

Try xvid in low bitrate cbr scenario and You will see that XviD isn't such wonderful, (but for dvd rips probably it's best imo)

Sirber

23rd January 2004, 23:00

RealVideo and WMV first purpose was streaming, and it paid off :)

SeeMoreDigital

23rd January 2004, 23:44

Originally posted by slavickas
Try xvid in low bitrate cbr scenario and You will see that XviD isn't such wonderful, (but for dvd rips probably it's best imo) I've just finished generating a whole of 720x480/576 encode tests, all from the same 2.35:1 PAR DVD source, using an 2pass bitrate of 1000kbps!

RealMedia10 looked the best overall (but still a bit too flat for my taste). But WMV9 came in at a close second!

When you do the same test again, cropping and resizing to 640x272, WMV9 does not fair as well as DivX or XviD.

For me, I find it quite interesting to see how well a codec works when encoding at 720x480/576 image pixel frame sizes!

Originally posted by Sirber
RealVideo and WMV first purpose was streaming, and it paid off Worked for Apple/QuickTime too!

Cheers

DevilsChild

24th January 2004, 01:03

What is this obsession with video standards? If it plays on an IBM compatible PC, it's fine with me. It's not like anyone uses this stuff outside of a PC environment. The DVD Forum isn't going to use MPEG-4 for the next generation DVD's. Just what is so great about standardizing video compression?

The most important things for a PC-based video codec are quality/speed/ease of use. End of story.

stax76

24th January 2004, 01:25

to me standard would be practical, would make things easier, I like easy things

bond

24th January 2004, 03:23

virus
dont put things in my mouth i didnt say

Originally posted by virus
"Lets ensure that the winning format is an open standard, usable for everyone and everywhere: Ogg Theora!"yeah from this point of view (!) ogg (audio and video) is the best thing available
it is as open as mpeg-4 but surely more "free" than mpeg-4 as there are no patents you have to pay for (at least thats the case for vorbis)

Sirber

24th January 2004, 06:42

free or not free, here's the real thing we need:

- free codec for home uses, with no fee or licence to pay for.

With:

- Great quality
- Great speed
- Great GUI to handle it

soon Surreal UI will rulz the world, for RV10 and XviD!!! :D

[note: was written with almost no brain vaculty]

SeeMoreDigital

24th January 2004, 14:30

Originally posted by Sirber
free or not free, here's the real thing we need:

- free codec for home uses, with no fee or licence to pay for.

With:

- Great quality
- Great speed
- Great GUI to handle it

soon Surreal UI will rulz the world, for RV10 and XviD!!! :D

[note: was written with almost no brain vaculty] Sirber my friend.

If you want to bring peace to everybody here, you are also going to have to incorporate, WMV9, VP6 and DivX into Surreal UI......

That will keep you busy for a few hours more ;)

Cheers

bond

24th January 2004, 14:56

Originally posted by SeeMoreDigital
If you want to bring peace to everybody here, you are also going to have to incorporate, WMV9who wants wmv9 here? :D

Sirber

24th January 2004, 15:14

Surreal UI will have RV10/9/8, XviD, VP6 and maybe later FFMPWG. I don't want to include WMV9 nor DIVX.

WMV9:
1) Micro$oft technology
2) VCM (not VFW)

DIVX:
1) Pro version not "free": gathor or warez
2) XviD beats the basic version

But, if these compagnies really wants to have their codecs in Surreal UI, my paypal account is ... :D

stax76

24th January 2004, 15:38

"2) VCM (not VFW)"

what's the difference?

"1) Pro version not "free": gathor or warez"

firewall should be running on every PC so where is the problem?

it's great you want to include all the features in Surreal UI but I wouldn't underestimate the work required for doing it right. If you don't know how to do this already I suggest to make a generic design and put no codec specific code in your program, use a eval function instead (in .NET it's easy to make a eval function using compiler services, in Delphi there are probably ways as well)

Sirber

24th January 2004, 15:52

Originally posted by Dolemite
"2) VCM (not VFW)"

what's the difference?there is a bug with VCM and bitrate
"1) Pro version not "free": gathor or warez"

firewall should be running on every PC so where is the problem??almost no end user run firewalls, also, I don't like to have "adwares" installed.

it's great you want to include all the features in Surreal UI but I wouldn't underestimate the work required for doing it right. If you don't know how to do this already I suggest to make a generic design and put no codec specific code in your program, use a eval function instead (in .NET it's easy to make a eval function using compiler services, in Delphi there are probably ways as well) There is 3 back-end I will use:
1) Helix Producer
2) avs2avi
and 3) FFMPEG

I built the setting system to be easy to update and manage, so I can virtually add any codec.