Very good quality at 10000+ kbps

[zambelli]

Analyzing the video with the MSU Quality tool and comparing the SSIM index numbers should probably give some insight into the differences between the various codecs at such high bitrates.

[Valeron]

here you guys blame VC-1 too much just because it's from MS....

technically speaking, can anyone confirm WMV AP is a good enough implementation to show the protential of VC-1?

so, no comparison should never come to a conclusion that VC-1 doesn't stand a chance when face the modern codecs.

simply take a glance at WMV AP, they don't even have adaptive B frames encoder implementation....(which is a very basic feature for mature modern encoder)

how can you consider such an implementation as equivalent to VC-1?

[quake74]

Even xvid looks better than WMV/VC-1...

Are we sure that the wmv above is VC-1? For one, mplayer can play it, and the fourcc is wmv3 and not wvc1 or whatever it should be.

[Sharktooth]

@Valeron: The stickies are there for a reason...
http://forum.doom9.org/showthread.php?t=111275

WMV9-AP is the MS implementation of VC-1.
Can we move on now?

Thanks.

[Valeron]

@Sharktooth:
imho, they don't have a good VC-1 implementation, VC-1 is not bad

that's my conclusion, i don't want to argue anymore.

bye

[Sharktooth]

@Valeron: I have been always quite specific in this regard. I call WMV/VC-1 or WMV9/VC-1 or WMV9-AP/VC-1 the MS implementation just to make it clear i was referring to it and not to the VC-1 standard.
So i always criticized the MS VC-1 implementation not the VC-1 standard (apart a single post where i said VC-1 and WMV9-AP are all hype and no facts... but that is ACTUALLY the truth).
You can verify that in everything i posted in this thread.
Next time please read carefully (and maybe 2 or more times).

[mpgxsvcd]

All right this thread has really digressed so I will attempt to bring it back on topic. The original poster just wanted to come as close to lossless as possible while coming as close to 10 mb/sec as possible. The question is what codecs are capable of this. The fact is that most new codecs can do this easily. Heck even MPG2 can get some outstanding SD results at 10 mb/sec.

Now I digress also.
As bit rates start dropping that is where the codecs start faltering. Now everyone knows that I have been a huge supporter of the wmv9 format. I have tested it every way possible and it is a good codec. However, I am starting to come to the same conclusion as “Sharktooth”. I can’t believe I just said that! Now I think I have tested the codec much more than “Sharktooth” but I think he is right when he said “However if VC-1 is able reach THIS quality (encoded by Sagittaire at 1250kbps) at the same bitrate i will admit it maybe can be a valid alternative to h.264... but that will never happen”. I have tried everything including some settings that seriously alter the video in an attempt to get the codec to look as good as that sample. I just could not get close to that quality at those bit rates. I could probably do something like 1.5 times those bit rates but 1250 kbps for 720p is just stupid. I still wonder if that file is reporting its correct size but it looks legit enough to me. I really wanted WMV9 to be competitive but I just have not been able to do it. Now this doesn’t mean that I have given up on it or that I will switch to one of the H.264 variants. Yes they provide better compression. However, wmv has some huge benefits to me. Namely the fact that you can stream it to almost every PC in the world with a simple AUTOMATIC download and it doesn’t require a super computer to decode it. However, as far as quality at a given bit rate, I think it is just not there yet. I think this advanced profile should have been released about 2 years ago. Then it would have been more in line with the other codecs at the time. Microsoft better step the codec up if they really expect people to use it. I have given it my best effort. Please let me know if you find some miracle setting that makes this codec competitive. If any of the Microsoft guys can provide a superior sample or show me what I am doing wrong then please do.

[Sharktooth]

What i tried to make everyone understand (even the original poster) is he can use every codec (from mpeg-2 on) to obtain the results he wants.
What i was trying to prove is he doesnt need that bitrate to obtain the results he wants coz there are codecs capable of doing it at much lower bitrates (including WMV9/VC-1, xvid, divx, x264/h.264, vp6, vp7, etc) but the best choice at this time would be h.264 due to its high efficiency and quality.

[imcold]

mpgxsvcd, you don't need a super pc to decode h264/avc ;) in fact, it's not much slower than mpeg4 asp decoding (10-20% ?) - and faster if you enable full post-processing (luma deblock, chroma deblock, dering) f.e. in xvid's decoder (and h264 is already deblocked too, unless in-loop filter was disabled in encoder). My old athlon 1800+ was more than good when decoding AVC clips in DVD resolution.

[zambelli]

Honestly, I don't think WMV9/VC-1 has actually been hyped very much, at least not on Doom9. Most of the "VC-1 vs H.264" debates were battled out over at AVSForum in the context of HD-DVD and BluRay encoding. The points generally brought up were:

1) H.264 is a more complex codec than VC-1 and can potentially achieve better compression ratios with advanced features such as CABAC.
2) Consequently, VC-1 is easier to decode than H.264 and is therefore cheaper to implement in hardware
3) Both codecs achieve similar quality (depending on implementation) at high bitrates and can achieve transparency for HD content in HD-DVD and BluRay.

Personally, I'm not "married" to either codec. I would always choose the one that's best suited for the content and delivery method. Naturally I'm better acquainted with WMV9 because I work on it every day, but I do try to use that knowledge to provide support here and not to try to sell one codec or the other.

The OP has very specific requirements in his case. I think both H.264 and VC-1 are overkill for SD content at 10 Mbps when they could both probably achieve transparency at half that bitrate. If there's plenty bitrate to spare, one might as well go with a lighter codec that's AVI friendly (for editing) and won't require a 2.0GHz machine to decode.

[Djago]

ok, so we are getting back to the idea that, if most codecs are similar at that bitrate, it's better to look at other benefits... If a codec like xxx needs more power to decode than yyy (at same quality), then yyy is better... If xxx is free and yyy is not, xxx is better. A good workflow is important too (I mean, some codecs can be used with some programs, that are more difficult to use, for example, try to do a multipass xvid with canopus). And so on...

[Sharktooth]

MPEG-2 is your friend then. It's lighter than newer codecs, more supported in editing applications and being such an "old" codec, implementations are quite good.
If you look at lower bitrates then h.264 is the choice.

[Sagittaire]

Honestly, I don't think WMV9/VC-1 has actually been hyped very much, at least not on Doom9. Most of the "VC-1 vs H.264" debates were battled out over at AVSForum in the context of HD-DVD and BluRay encoding. The points generally brought up were:

1) H.264 is a more complex codec than VC-1 and can potentially achieve better compression ratios with advanced features such as CABAC.
2) Consequently, VC-1 is easier to decode than H.264 and is therefore cheaper to implement in hardware
3) Both codecs achieve similar quality (depending on implementation) at high bitrates and can achieve transparency for HD content in HD-DVD and BluRay.

Personally, I'm not "married" to either codec. I would always choose the one that's best suited for the content and delivery method. Naturally I'm better acquainted with WMV9 because I work on it every day, but I do try to use that knowledge to provide support here and not to try to sell one codec or the other.

The OP has very specific requirements in his case. I think both H.264 and VC-1 are overkill for SD content at 10 Mbps when they could both probably achieve transparency at half that bitrate. If there's plenty bitrate to spare, one might as well go with a lighter codec that's AVI friendly (for editing) and won't require a 2.0GHz machine to decode.

1) True
2) True
3) True

IMO codec like VC-1 or H264 are simply useless for HD-DVD (15 Go or 30 Go) or BR (25 Go or 50 Go) HD encoding scenario. MPEG2 MP@HL without high vbv restriction is able to make very good work in [15-20] Mbps interval for 1080i/p encoding.

[Isochroma]

Well, I use DivX 6.2.2 with quantizer=1, insane quality, pq=9999, no gmc, no qpel, no b-frames. Right now I'm storing my latest encode: The Phatom of the Opera. Scaled it from 1280x1080 anamorphic to 1360x768 (to fit an LCD). Using above settings, the 2:21 long video uses 19.881 GB in MKV (native mode) with AC3 audio! Original MPEG-2 TS was 11.78 GB. No noise reduction or other processing besides telecide().

I used to be a big believer in Noise Reduction, but now I think noise is cool! DVD+Rs are so dirt cheap now that it is economical to keep everything. NR smears the vague parts of the image too much. Hopefully better NR algorithms will be created in the near future; particularly inspiring are recent efforts in this area such as NLmeans, frfun, and the benchmark fft3d.

Similar results could probably be achieved with x264, but it would be slower encoding and have much higher CPU usage on decoding due to the extreme bitrate.

[foxyshadis]

x264 wouldn't be slower than divx's insane, heh, unless you used the hardcore settings that are pointless that high, nor would decoding be slower without 8x8 and cabac. Insane is an odd setting though, since you probably double your encoding time just to save a half a gig or so; insane, like xvid's vhq, is made to work best on denoised sources. *shrug* Whatever works.

[Isochroma]

You're probably correct for the encoding part. However, decoding is an entirely different matter. H.264 at more than 10mbps average bitrate (not peak) would probably bring most machines to their knees. There's no point in using AVC for such high bitrates unless you're an HD broadcaster trying to cram lots of channels into a small bandwidth.

[foxyshadis]

Heh, ever tested? In 264, I turned off 8x8dct, deblocking, and cabac, motion search hex/4, keyint to 100; xvid keyint to 100, motion search 5/1, EHR matrix. Both are ABR 10000kbps.

x264 reference

x264.exe --bitrate 10000 --level 4.1 --keyint 100 --min-keyint 18 --ref 3 --mixed-refs --nf --no-cabac --subme 4 --analyse p8x8,b8x8,i4x4 --qpmin 15 --qpmax 40 --vbv-maxrate 25000 --threads 2 --thread-input --progress --no-dct-decimate --no-psnr --output "x264-10000k-test.mkv" "final.avs"


avisynth script

#source is 832x468 detailed animation, so end is 1664x936
addgrainc(8,1)
lanczosresize(width*2,height*2)
addgrainc(8,1)
trim(5255,5505)+trim(5855,6055)+trim(6305,6555)+ \
trim(6955,7055)+trim(7155,7305)


xvid encodes in neglegible time (avs to null ran at the same speed - 5fps - as using xvid on average) while x264 ran at 3.5fps.

My results with a null renderer:
xvid ff ~ User: 17s, kernel: 0s, total: 17s, real: 17s, fps: 55.8, dfps: 54.8
x264 ff ~ User: 21s, kernel: 0s, total: 21s, real: 21s, fps: 44.3, dfps: 43.7
x264 core ~ User: 1s, kernel: 0s, total: 1s, real: 10s, fps: 505.1, dfps: 92.9
When you add VMR9 dfps drops to 50,40,and 60 respectively.

Turning inloop on kills avc playback, as does cabac, as suspected. Surprisingly, turning on --8x8dct and i8x8 makes zero playback difference.

They look pretty much identical, though xvid might be said to hide the grain a little less... but it's hard to tell without resorting to screenshots.

I'd upload but they're 50M each and that's a lot to prove a point when it's not hard to make your own, plus I'm not sure if I'm allowed. ^^;

[Didée]

One question hasn't been asked yet. And since I started barking here (http://forum.doom9.org/showthread.php?p=841860#post841860), we should put it:

The "Why" question.

Up to now, we now of Djago's encoding scenario:

- maximum quality at 10k bitrate (fit ~100min onto a DVD)
- "720x576x24bits, 25fps, interlaced... a standard broadcast PAL footage"

What I'm asking myself is, are you doing any more editing and/or filtering to the source, or none at all? Because,

- IF any filtering is done, then optimization in this part probably is way, WAY more important than the question of which codec to use at such high bitrates.

- If NO filtering or editing more complicated than simple cutting&splicing is done, then the answer is simple:
Then you should not use *any* codec, and should not do any rceompression, but just keep the original stream. In this case, any reencoding will only degrade quality, and the original stream already has "the best possible" quality.

[Djago]

The "Why" question.

Up to now, we now of Djago's encoding scenario:

- maximum quality at 10k bitrate (fit ~100min onto a DVD)

Shouln't be ~60'? :confused:

- "720x576x24bits, 25fps, interlaced... a standard broadcast PAL footage"

What I'm asking myself is, are you doing any more editing and/or filtering to the source, or none at all? Because,

- IF any filtering is done, then optimization in this part probably is way, WAY more important than the question of which codec to use at such high bitrates.

Maybe I will, maybe not. I don't know a priori. What do you mean by "optimization in this part"?


- If NO filtering or editing more complicated than simple cutting&splicing is done, then the answer is simple:
Then you should not use *any* codec, and should not do any rceompression, but just keep the original stream. In this case, any reencoding will only degrade quality, and the original stream already has "the best possible" quality.

With respect to reencoding/recompression, the point is that the premise of the topic is to fit 1 hour in a DVD-R, so compression is a MUST in this topic.
I won't debate as it's done elsewhere about the price/convenience of DV tapes (or any other media for storing). I read LOTS of places where the thread goes to hell/flame wars/off topic/so on because opinions respect to those kind of things (we can see here some examples of this). So, I prefer to sacrifice some details for the sake of results. As details are needed (really needed in order to advance) they can be stated, but this is done only when the premises aren't violated

[Didée]

Ooops, you were indeed talking about 60min to DVD-R, not 100min ... sorry.

But then, even more: a one-hour PAL broadcast (SD) should already fit on a DVD-R ... with lots of empty space at the end.With respect to reencoding/recompression, the point is that the premise of the topic is to fit 1 hour in a DVD-R, so compression is a MUST in this topic.
I strongly doubt your recorded broadcast is beyond 10mbps. Those SD PAL streams I grab from satellite usually are 1.5GB~2GB per hour. Currently, the SD PAL broadcast of the FIFA world cup is transmitted at 4GB per 90min.
(You surely don't want to take a 2GB broadcast and recompress it to 4.3 GB, just for fun and just to fill-up the DVD. This still will lose quality, there's nothing to gain by doing so.)

So it seems that, in contrary, compression is a NO-NO in this topic. Unless you give evidence that it should.

What do you mean by "optimization in this part"?
We already concluded that regarding visual quality, the codec hardly matters at these bitrates.
However if you decide that the source could benefit from some filtering (noise reduction, removal of compression artefacts, whatever), then it's the question how exactly to do this filtering. It surely makes no sense to perform a two-weeks encoding with the toppest-notch encoder at its insanest and slowest settings, if the encoder is fed with the output of a cheap+fast+crappy filter.

If, however, filtering is NOT needed, you could have put the darn file already 1000 times on some DVDs ...


I won't debate as [...] I read LOTS of places where the thread goes to hell/flame wars/off topic/so on because opinions respect to those kind of things
To ease you: I'm a helper, not a flamer. :)

So, I prefer to sacrifice some details for the sake of results.
Purely theoretical discussions always endanger that the discussion will run in the wrong direction. Concentrating on some isolated aspects is not good, if other aspects - perhaps being more important even - are disregarded.

What counts in the end is the result that you're getting, and how satisfied you are with it.
... And that was all of my point: I had the impression that this discussion was running away from, or at least not pointing directly to, the most important point: the maximum of quality that you, Djago, will get in the end. Simply because reaching of this goal also depends on many conditions that you did not mention so far.

[foxyshadis]

Yes, but I thought all this got sorted out on the first page. (Mpeg2 (dvd conformant or not), mjpeg, mpeg4 asp if adventurous.) Since then it's all been hashing out details or way off topic. I'd presume it's common sense that there's no point in re-encoding (larger!) if the filtering is going to be fast and sloppy.

If you want to find out how badly mpeg2 mangles your video, just run a normal encode through hc or quenc, with whatever settings you'd use (one pass, moderate speed, cbr 9500?). Then import it back into the avisynth, use stackhorizontal or interleave on a particularly action-y scene, and check it out. Chances are you'll end up with quite mild artifacting that won't be visible in any way on playback, so you'll have the best of both worlds: A playable, editable, and archivable video.