Elephants Dream SD (360p) challenge [Archive]

Inventive Software

13th August 2007, 11:29

Not to dig at the HD challenges going on, but I have the lossless 360p source, cause it's all I can handle at the moment until I get my new laptop PSU, and I intend to make good use of it. :D

So far, the little tests I've done involved encoding just the video to: DivX, Xvid, WMV8 (included because it's apparantly the last generation of MS MPEG-4 codecs that fly through encoding, but need high bitrates), WMV9 AP, x264 AVC and VP7. 2 pass settings were used, and the target bitrate was 1 Mbit, with a 5 Mbit peak bitrate. Defaults were used for most codecs. All the codecs bar WMV8 performed great (though I think I mis-set the peak bitrate on DivX and Xvid, so may have to re-encode them to check), so I did some quick calculations on plausible target bitrates.

Sagittaire in the 1080p challenge thread is targetting 18, 12, and 6 Mbit bitrates for MPEG-2, AVC, and VC-1. 6 Mbit I thought was a real challenging bitrate for 1080p, so I worked out the relative bitrate difference between the SD 360p source and the HD 1080p source.

The way I calculated the difference was to see how many 360p sources would fit in a 1080p source. I didn't do an AviSynth script, since that would almost certainly kill my computer! But... (this is all theory, but works out coshure in the real world), when you double the resolution of 640x360, you get: 1280x720. However, because we're working with 4 sides (think squares / rectangles / quadrangles / whatever you call it) when you double the resolution, you double the width and height, therefore you can fit 4 of the 640x360 in the 1280x720 space. Now, we can't double it again, since that's too big for 1080p, but we go back to 640x360 and multiply it by 3. This gives us 1920x1080. Bingo, our 1080p resolution. There are now 9 640x360 images in our 1920x1080 image.

1 Mbit I found was quite easy for the codecs to encode, and no wonder. 9 Mbit on an HD source is easy for both ASP, VC-1 and AVC codecs to encode. Even VP7 could tackle that with no problems. So my next target is to halve the bitrate, and encode at 500 kbits.

This is where I need the codec settings, since I'm sure what I'm using is almost completely wrong (especially in the VC-1 case). WMV8 gets thrown out of the window cause it'll be crap (preliminary tests told me this!). So (basically) I need settings suggestions for: DivX, Xvid, x264, WMV9 AP, and VP7. Please. ;) Target bitrate is 500 kbits/sec.

Dark Shikari

13th August 2007, 15:28

x264?

--subme 7 --no-fast-pskip --me umh --deblock -1:-1 --b-pyramid --weightb --bime --trellis 2 (only use trellis 2 on second pass) --ref 6 (--ref 16 if you want to be crazy) --threads auto --thread-input --mixed-refs --bframe 16 --partitions all --8x8dct --progress

If you feel like wasting tons of CPU time, use my modified x264 build (http://www.mediafire.com/?4dotcwznuy1) (singlethreaded only) and it will beat out the regular x264 build by a decent amount in terms of SSIM metric, which you can see in the 1080p HD test.

CruNcher

13th August 2007, 15:36

im not sure if this is the correct way to compare codecs shouldn't we compare everything @ alone first and so for example left the ratecontroll aside and do a raw I,P comparision first and latter B and then ratecontroll ? also to get an idea of the Visual Quality (and maybe even find bugs this way) for every of those 3 at @ constant quant so also checking the complete quant range and Decoding Efficiency without a ratecontroll involved sure it will be a massive testing (also taking bitrate into account and even different samples), and dont forget Vp7 doesn't use b-frames @ all gives it an decoding (complexity) advance over the others so just to compare codecs in the full form i think that's a easy way but wrong (especialy ratecontrolls are improved fast these days but the basics not so fast ;) )

So yes what i really suggest is to start @ 0 for every encoder (and passing 3 tests SSIM,PSNR and blind test) and work the way up (this will be a massive amount of data we would get about every encoder and indeed very time consumeing i did something similiar based on PSNR with XviD lab (automated aproach) (blind testing was done by myself here on doom9) and alot of different possible codec tools in different situations and this way indeed found some bugs in XviD) so 1 encoder @ the time and maybe even first try different encoders from different standards and compare them against from 0 (and then chose the best overal winner from the (PSNR,SSIM and Blind test) and then compare it against the other winner from the other standard (jesus that would be really massive) 24 hour 7 days a week testing for several weeks (especialy if you would also seperatae HD/SD with different samples for every Encoder) (sure most probably the results would be outdated for every new update) so if this takes a half year for every encoder you could for sure improve them in that time also at least report alot of bugs :P.

Inventive Software

13th August 2007, 16:03

shon3i

13th August 2007, 16:12

Very good idea indeed :) I thinked to do some thing, but i don't have time.

Inventive Software, i agree with you about codec choice, but i think we can include Ateme Digitral Serie Encoder AVC (not Nero Recode), Elecard Converter Studio AVC. Can you provide me source i can make encodes with this two encoders @ 500kbps :)

Dark Shikari

13th August 2007, 16:18

I forgot to mention some things.... I don't give a flying **** about metrics. :D They're numbers, and can't account for the (in)accuracy of human eyesight. I will be uploading the encoded videos online soon so you's can all view them at your leisure. PNG screenshots of certain frames and areas are of course obligatory. :)

EDIT: Thanks for the command line Dark Shikari. I wasn't aware of the --trellis 2 switch only being useful on 2nd pass, so thanks, and may save some time on 1st pass. :) What's the difference between your build and Cef's build that I use currently?

CruNcher: Can you see a fault with wanting to compare codecs visually (not with numbers) at a target bitrate? In theory, all the codecs I picked can hit that target, so let's have them attack it and see. ;)
--trellis 2 on the first pass is very bad as it can destroy visual quality. If you're really looking for visual quality, adaptive quantization might not be a bad idea either!

If you're using human visual quality instead of metrics, I might also suggest you avoid --trellis 2 altogether.

My build uses a different motion search metric that is completely unoptimized at the moment but is tuned for SSIM metric, which is well-correlated with human perception, which hopefully means that it looks better to the human eye, too.

For the encoding, I don't see why one should use a Constant Quantizer--we're testing each of the codecs as a whole, and that includes their ratecontrol aspects.

Inventive Software

13th August 2007, 16:20

Source is Elephants Dream lossless, 360p. http://media.xiph.org/ED. AviSynth script:
ImageReader("%05.png",1,15691)

(Off the top of my very bad head).

I have chosen just one implementation of AVC and VC-1 because at the moment it's a casual test, and I'm not playing about with others that I'm unfamiliar with. They also (IIRC) aren't free. DivX and Xvid are quite different in their philosophies, so they are both included (DivX is faster than Xvid).

Golgot13

13th August 2007, 16:28

I forgot to mention some things.... I don't give a flying **** about metrics. :D They're numbers, and can't account for the (in)accuracy of human eyesight.

Can you provide me source i can make encodes with this two encoders @ 500kbps

It's clear @500kbps we will not need metric to compare codec (VC1 vs H264).
VC1 is adapted to high bitrate (need low CPU than H264 with CABAC option).

And about Ateme software and Elecard, all people can test himself the result
because the software are not free (about Ateme software it's the CLI version ?).

CruNcher

13th August 2007, 16:42

Inventive you should also add Nero Digital ASP (Ateme) and 3ivx they should also have improved over the years (but sure this makes it even more complex then it allready is, especialy if i think from the "from zero idea" and don't forget libavcodec) :P

For me it looks like this

Low Bitrate Contenders High Bitrate Contenders
H.264,Vp7,RV10,AVS,VC-1,XVD Mpeg-1 (still questionable),Mpeg-2,SP/ASP,H.264,VC-1,VP7,RV10,AVS,XVD

The same look & feel (not taking into account how much Detail they preserve or compression efficiency just the look & feel based on Technology they use)

Generations:

1st/4th: Snow,Dirac,Rududu,Loco,BergWave (a not so complete new look and feel more like Indeo 4.1/5.1,VDO) jep a big Comeback you could say ;) and it will blast big time :D
1st: Mpeg-1,Mpeg-2
2nd: SP/ASP,WMV8,XVD (look a little different to Mpeg-1/2 but not like the next Generation Codecs it's in between those with PP it goes more into the next Generation look & feel)
3rd: H.264,VP7,RV9/10,AVS,VC-1 (introduced a new look & feel)

shon3i

13th August 2007, 16:43

because the software are not free (about Ateme software it's the CLI version ?).OK, i realise that but i think to test AVC codec's in same time :)

About ateme, isn't cli, but is more detailed than nero recode, it have open gop, VBR (CRF), ABR, CBR, 2Pass, CQM, Lossless, AQ, Pulldown, ability to set different number of references frames indepedently for P and B frames and much more

EDIT: The main reason why i was to include Ateme and Elecard is their AQ's both have exellent solutions comparing to x264 AQ. AQ can help much on 500kbps.

akupenguin

13th August 2007, 21:32

--trellis 2 on the first pass is very bad as it can destroy visual quality.
Got some evidence to back that up?
My theoretical knowledge of how it works says that the only effect that any option can have on the first pass is to modify frame types or bits-per-qp. Trellis isn't used during frame type decision (no quantization at all is needed there), and trellis-2 vs trellis-1 makes very little difference to bits-per-qp. For that matter, trellis-2 only affects RDO, and I (and most other people who've posted their options here) usually don't use RDO on the first pass.
Granted, I haven't specifically tested the effects of trellis-2 on 2pass. I don't think I've ever encoded anything with trellis-2 enabled on the first pass, because I know that it can't make any difference. But please prove me wrong.

microchip8

13th August 2007, 21:49

Interesting read, akupenguin. I aways use trellis=2 for both the first and second pass, however on the first pass I use turbo=2. Does the turbo option disable trellis?

Dark Shikari

13th August 2007, 22:14

Got some evidence to back that up?
My theoretical knowledge of how it works says that the only effect that any option can have on the first pass is to modify frame types or bits-per-qp. Trellis isn't used during frame type decision (no quantization at all is needed there), and trellis-2 vs trellis-1 makes very little difference to bits-per-qp. For that matter, trellis-2 only affects RDO, and I (and most other people who've posted their options here) usually don't use RDO on the first pass.
Granted, I haven't specifically tested the effects of trellis-2 on 2pass. I don't think I've ever encoded anything with trellis-2 enabled on the first pass, because I know that it can't make any difference. But please prove me wrong.
I've always read that --trellis 2 is bad for the first pass. I haven't seen any proof, just echoing what I've seen passed around as advice.

In terms of visual quality, I also have seen (especially in the Trellis/AQ thread) that the degradation caused by Trellis-2 can require more AQ to make up for it visually, to the point where one loses efficiency.

Sagittaire

14th August 2007, 00:26

I've always read that --trellis 2 is bad for the first pass. I haven't seen any proof, just echoing what I've seen passed around as advice.

In terms of visual quality, I also have seen (especially in the Trellis/AQ thread) that the degradation caused by Trellis-2 can require more AQ to make up for it visually, to the point where one loses efficiency.

In first pass you write only stat for second pass. Use exactly the same setting for first and second is certainly little better for prediction.

IgorC

14th August 2007, 02:27

benwaggoner

14th August 2007, 04:18

Are you using WMCmd.vbs or Windows Media Encoder for the Windows Media version?

Also, what rate control model are you looking at (CBR, VBR, and with what buffer sizes)?

360p and these bitrates are interesting examples for streaming, and hence a CBR encoding shootout might be interesting.

I get a little frustrated by all the codec tests that use unbound peaks, which really isn't feasible for most real-world content, and doesn't provide real-world stresses on the rate control.

benwaggoner

14th August 2007, 04:36

Following up, for optimized visual appearance with WMV9-AP with this content, I recommend you use these registry keys:

DQuant: I and P frames
DQuant Method: Regular
Perceptual Method: Off
In-Loop Filter: On
Overlap Filter: On
Motion Search Level: Luma + True Chroma
Motion Search Range: Adaptive
Motion Match Method: Adaptive
B-Frame Number: 1
(if 1-pass encode) Lookahead=16
(if don't care much about encode time) Thread Number: 1

It's possible that 2 B-frames might be better at that frame size and bitrate; I haven't tried.

More broadly, you want to use Complexity 4/80. For VBR, use the unconstrained mode unless you're constraining the other codecs. For CBR streaming, use 2-pass, and an 8-second buffer is optimal for Advanced Fast Start from Windows Media Services.

Keyframe every 10 sec is probably a good default at this bitrate.

Inventive Software

14th August 2007, 11:21

Thank you benwaggoner, I was planning on using either one (WMcmd.vbs or WME) that I have encoding suggestions for, so I'll try at first with WME and those registry settings. I am constraining the other codecs to 5 Mbits, so I'll set that peak. It *should* be more than enough for all the codecs, so we'll see. ;)

CBR is interesting, I might try that later on, when this is all finished. :)

Inventive Software

14th August 2007, 11:23

ED source isn't real movie but digital anime.
What if to use one of QT 1080p trailers. Choose one with high bitrate like 11-12 mbps and with high texture and filmgrain.
If Resize it with sharp resizer like Lancsoz4 to 360/480p it would be lossless stuff for this kind of resolution.

No it wouldn't. ;)

Those trailers are not indicative of "normal" sources. Trailers usually have fast-moving action sequences, with lots of fades. They're not suitable for what I'm trying. ED is free and a reasonable challenge for all codecs. ;)

zambelli

14th August 2007, 12:03

Those trailers are not indicative of "normal" sources. Trailers usually have fast-moving action sequences, with lots of fades. They're not suitable for what I'm trying. ED is free and a reasonable challenge for all codecs. ;)
I don't know, I think ED is a little bit too easy. You might want to consider adding artificial grain to it with TrBarry's or FoxyShadis' AddGrain() plugin and then scaling it down. I think it'll make for a slightly more interesting source.

zambelli

14th August 2007, 12:11

What is the criteria for this encoding challenge? Metrics? Blind test? Popular poll?

500 kbps for 640x360 is pretty difficult, I think. 750 kbps might be more appropriate. Also, 5 Mbps peak might be a little overkill. That's 10 times the size of your average. That'be like encoding HD at 15 Mbps with a 150 Mbps peak. :) If you're going to use a peak that high, I think you might as well just go unconstrained.

Also, make sure you decide ahead of time whether you're going to be including decoder post-processing in the comparison - it's a pretty integral part of the coDEC experience at low bitrates.

Golgot13

14th August 2007, 12:25

What is the criteria for this encoding challenge? Metrics? Blind test? Popular poll?

500 kbps for 640x360 is pretty difficult, I think.

Me, I think 500kbps is good, today lot of people have access at web with ADSL 512kbps.
I prefer lower bitrate than 500kps, because with specific custom matrix in High Profil
H264 encoder can make some nice picture (I saw some H264 broadcast video and audio at 700kbps from live source!!!).

Inventive Software

14th August 2007, 12:47

zambelli

14th August 2007, 12:58

The criteria is just simply to see which codec can produce the best picture at said average bitrate. It's not necessarily a blind test, but if fanboys start spouting how one codec is better than the other, I'll post screenies that ARE blind. You've been warned. ;)
I think blind tests are a good idea. In fact, my tired mind is thinking it'd be cool to write some server side code that extracted random frames from encoded videos and posted them on a website for people to rank. :) Consider this scenario: you write an Avisynth script that interleaves source video and compressed videos A, B and C. An ASP or PHP page generates a random frame number, then seeks to that position in the Avisynth script and saves the 4 frames to disk as PNGs, and finally posts them to the web page for visitors to rank in terms of quality. Enough visitors trigger this process - and you've got yourself some nice stats. :D
@zambelli: You think a lower peak would do well? Bear in mind that SD content usually has quite a wider range for the bitrate than HD content does (think backing up your DVD to CD). Suggest a nicer peak bitrate, I was thinking probably 2 Mbps.
I just meant to say that if you're going to have such a high peak, you might as well just remove the peak constraint all together.

Golgot13

14th August 2007, 13:25

The criteria is just simply to see which codec can produce the best picture at said average bitrate. It's not necessarily a blind test, but if fanboys start spouting how one codec is better than the other, I'll post screenies that ARE blind. You've been warned. ;).

:D so some people think I support H264 ? =>
Yes and no, I'm support and will support the best codec on specific use only.
I prefer WM9 than DiVX or I prefer h263 that "RealPlayer" format on nokia phone, WM9 for VoD on web,.....

About the screen picture, it will be nice if the people don't know which picture come from which codec
to be sure we judge the visual quality only. And it will be important that the colour, contrast, brightness
are exactly same (no post/pre process before encoding)

Dark Shikari

14th August 2007, 14:34

Lower bitrates are good for subjective tests because its much easier to distinguish between varying quality using only the eyes.

IgorC

14th August 2007, 16:58

It will be usefull to include vp6 codec since its web popularity and it has higher metric score comparing to ASP and VC-1 at low bitrate.

http://forum.doom9.org/showthread.php?t=90784
It's 2 years old test. Some codecs like VP7 and x264 were improved but it's pretty the same situation nowdays.

btw on2 is starting to support H.264 http://www.on2.com/company/news-room/press-releases/?id=411

benwaggoner

15th August 2007, 07:30

No one else likes my CBR encoding for streaming suggestion?

That said, 1 Mbps would be a more typical data rate for a streaming encode for SD.

Inventive Software

15th August 2007, 12:15

CBR is interesting, I might try that later on, when this is all finished. :)

I never said I'd rule it out totally. VP7, VC-1 support CBR, and both the ASP codecs I *THINK* support CBR, so this could be interesting.

1 Mbps for CBR streaming, 500 Kbits for VBR (constrained or unconstrained) sound OK? ;)

benwaggoner

16th August 2007, 01:48

I never said I'd rule it out totally. VP7, VC-1 support CBR, and both the ASP codecs I *THINK* support CBR, so this could be interesting.

1 Mbps for CBR streaming, 500 Kbits for VBR (constrained or unconstrained) sound OK? ;)
Yes, those are both interesting?

Should we cap the peak rate for the VBR? A good device peak could be 1.5 Mbps over 4 seconds.

Inventive Software

17th August 2007, 11:47

I had a fair amount of spare time yesterday, so set about encoding using benwaggoner's suggested registry settings within WME, with the one exception of using 2 B-frames. I used VBR unconstrained, with a bitrate of 500 Kbps. It took about 6 hours cause my computer's so slow. The result has been uploaded.

http://rapidshare.com/files/49519412/ED_VC-1_500_Kbit.wmv

@benwaggoner, zambelli (or those in the know for VC-1): the resulting encode didn't do too badly for the blocks, it's watchable, however the credits are, to put it mildly, bloody awful! When the credits aren't scrolling upwards, and are just some letters put on the screen, they look frankly dire. Is there a way of increasing the quality of that so that it's better?

Sagittaire

17th August 2007, 13:40

benwaggoner

17th August 2007, 18:04

Inventive Software

18th August 2007, 17:12

Sooooo.... what did I do wrong if any? I used them settings, and I got said result. In theory, that shouldn't happen, especially with unconstrained VBR.

I'm trying H.264 with both unconstrained and 1.5 Mbps peak bitrate to see the difference. Hopefully, all things equal and ordered, I'll have those files before I go on holiday, but it's unlikely. 10 days working holiday at a festival. Wish me luck! :)

Inventive Software

8th September 2007, 13:03

OK, I did that 500 Kbits VC-1 encode again, same settings (unconstrained VBR 2-pass), but with 1 B-Frame. The encode looked a LOT better in the credits. I'll upload later on. Perhaps it's a WMV9 or VC-1 quirk. :p

EDIT: VC-1 with 1 B-frame: http://rapidshare.com/files/54237006/Elephants_Dream_500_Kbit_1_B_Frame.wmv

zambelli

10th September 2007, 02:37

You might want to give Adaptive Dead Zone (-v_percopt 2) a try too. It might soften some of the texture detail, but it ought to reduce blocking in smooth areas.

Inventive Software

11th September 2007, 13:46

Seems 2 B-frames really isn't the way to go. So that's that one sorted. :)

ADZ at level 1 seemed to help a little bit, but would it help to go a bit further?

benwaggoner

11th September 2007, 14:44

Seems 2 B-frames really isn't the way to go. So that's that one sorted. :)

ADZ at level 1 seemed to help a little bit, but would it help to go a bit further?
Give it a shot - ADZ 1 is the default, but more sometimes helps. It's hard to predict when it does help, though.

zambelli

11th September 2007, 23:42

Increasing the ADZ strength is going to increase the deadzone delta in textured areas more aggressively. To put it differently: higher strength values will require less texture to trigger increases in deadzone, thus possibly also causing a deadzone increase in smooth areas.

Final attempt to translate that to English: if you increase ADZ strength, you're likely to see less detail retained overall.

Inventive Software

12th September 2007, 09:59

My intention was just to increase it to 2.

What I'm trying to (attempt to) do is reduce the blocking, which is reasonably annoying. I'll post the x264 file I encoded later on this afternoon so you can see the difference.

bobololo

12th September 2007, 23:55

I'll post the x264 file I encoded later on this afternoon so you can see the difference.

I'm curious to see how good will x264 be compared to the vc-1 clip you posted. Hehe I could feel like having my hands on that challenge and warming up some pieces of software that are lying around ;)

Inventive Software

13th September 2007, 16:05

Ask and ye shall receive (at least in this unique case! :D). This is the x264 file I encoded.

http://rapidshare.com/files/55384608/Elephants_Dream_AVC_500_Kbits.mp4

bobololo

13th September 2007, 23:34

Ask and ye shall receive (at least in this unique case! :D). This is the x264 file I encoded.

http://rapidshare.com/files/55384608/Elephants_Dream_AVC_500_Kbits.mp4

Pretty nice. It makes life hard for vc-1 which from my point of view is actually quite below... Maybe our MS fellows could jump into the game as well and submit something that would save VC-1 honour ;)

Btw did you those insane settings that Dark Shikari suggested ?

Beside, has anyone tried to produce an equivalent encode with MainConcept ? (I guess there are still improvements to expect among H.264 representatives compared to x264).

Dark Shikari

14th September 2007, 01:35

Pretty nice. It makes life hard for vc-1 which from my point of view is actually quite below... Maybe our MS fellows could jump into the game as well and submit something that would save VC-1 honour ;)

Btw did you those insane settings that Dark Shikari suggested ?

Beside, has anyone tried to produce an equivalent encode with MainConcept ? (I guess there are still improvements to expect among H.264 representatives compared to x264).
Since I made the suggestions in my original post, I've done a number of patches to x264, which I'll try when encoding for this thread once all the patches are compiled and ready:

--me imh (15-25% slower than UMH, about 1-1.3% higher quality)
--hadamard (50% slower with UMH, 60-70% slower with IMH, but up to 2%+ quality gain)
Improved --subme 7, 0.75% quality gain for 2.5% lower speed. Though this one isn't that big of a change, I like it because now --subme 6 to --subme 7 has almost the same gain that --subme 6 has over --subme 5, making it much more worthwhile.
Just posted this one: an ME prepass option, which improves quality about 1% (same as --me imh) for about 10-20% speed loss depending on encoding settings.

Small benefits, but they do add up.

If you really have too much time on your hands, run a --hadamard --me esa encode with the new patches :p

Inventive Software

14th September 2007, 10:18

I'm liking the --subme 7 option. Hadamard and --me imh are not worth the speed slow-down IMHO.;)

Off the top of my very ragged head, these were the settings I used for that encode:

CABAC, 4 Ref frames, mixed refs, 4 B-frames, adaptive b-frames, Inloop deblocker @ 0:0, Analyse all, all the b-frames options, 3 threads, --thread-input, no-fast-pskip, adaptive quantization @ 0.4.

I think you can use a hex editor on the MP4 file if anything I've told you's complete BS. :D

EDIT: I'm doing ANOTHER VC-1 encode with WME9 and WMV Powertoy. Powertoy settings I'll post an image of later.

Inventive Software

14th September 2007, 15:03

New VC-1 encode is on it's way. Powertoy settings were as follows:

http://img513.imageshack.us/img513/6326/wmv9vb6.jpg

2-pass VBR at 500 Kbits. About 2 hours to encode on my laptop. It actually looked quite good, but still wasn't up to H.264, especially in the fades. What could be done to improve that?

Note: I've done more VC-1 encodes than H.264. Doesn't that say enough? ;)

Sharktooth

14th September 2007, 15:13

pwnage...:)

Inventive Software

14th September 2007, 15:23

Absolutely! :D

That VC-1 encode if you're interested: http://rapidshare.com/files/55693442/Elephants_Dream_VC-1_500_Kbits_V3.wmv

Sharktooth

14th September 2007, 15:31

Dark Shikari

14th September 2007, 15:58

yes, i already had a look at it. however we all knew h.264 was way more efficient at lower bitrates, however VC-1 has some more "voice" at high bitrates. at least the h.264 advantage is heavily reduced.
All codecs tend to converge at high bitrates to be honest. Low bitrates is where the codecs really start to shine.

Sharktooth

14th September 2007, 16:02

true, but VC-1 seems to have an edge at high bitrates since the devs paid particular attention in preserving fine details.

Inventive Software

14th September 2007, 16:10

Which is still quite important. ;) This test at 1 Mbit, both VC-1 and H.264 look much the same, only real difference is speed, with WMV9 AP being slower than x264.

And Sharky: I'd have a look at that VC-1 encode again. Seems to be the best VC-1 encode I've done to date on this source at 500 Kbits, but at this bitrate, H.264 wins out, so it seems. I'm waiting on analysis from Ben Waggoner and Zambelli for more suggestions, if they can eek out better quality from WMV9 AP.

Sharktooth

14th September 2007, 16:16

note: the "edge" i was referring to is meant about the bitrate/quality scaling...

bobololo

14th September 2007, 23:28

Since I made the suggestions in my original post, I've done a number of patches to x264, which I'll try when encoding for this thread once all the patches are compiled and ready:

Great, just keep us posted as soon as you can show your results. It'll be a good thing to check for real all your improvements and evaluate how much they visually enhance.

Dark Shikari

14th September 2007, 23:48

Great, just keep us posted as soon as you can show your results. It'll be a good thing to check for real all your improvements and evaluate how much they visually enhance.I'm guessing overall they won't be too noticable; a few % here and a few % there isn't overall that obvious except perhaps at low bitrates.

What would be very noticable would be some sort of new psychovisual options.

benwaggoner

15th September 2007, 05:32

New VC-1 encode is on it's way. Powertoy settings were as follows:
Note that you:

Don't need Lookahead on for 2-pass encodes
Don't need to specify Macroblock Mode Cost (it's set correctly via Complexity)
Don't need to set Motion Vector Cost, since that's set by default.

Also, for this clip, I haven't always seen DQuant and Perceptual Option pay off that well at low bitrates. You might try one or the other.

Inventive Software

15th September 2007, 16:21

OK, time to try the other way round then. ;)

Dark Shikari

16th September 2007, 00:38

x264 encode (http://www.mediafire.com/?fj2chyednxo), 500.51kbps.

commandline:

x264 --bframe 16 --b-pyramid --ref 8 --fpel-cmp satd --me imh --me-prepass --mixed-refs --merange 16 --subme 7 --b-rdo --threads 2 --trellis 2 --bime --weightb --partitions all --direct auto --progress --8x8dct --no-fast-pskip --bitrate 500 --pass 3 -o ED360_IMH.mkv ED360.avs

The comparison of this to VC-1 is night and day.

bobololo

16th September 2007, 17:03

x264 encode (http://www.mediafire.com/?fj2chyednxo), 500.51kbps.

The comparison of this to VC-1 is night and day.

I compared your result to "Inventive Software". By watching very closely (i.e. almost frame by frame) I can observe a little bit more details in yours. Hence good point, your patches actually brought some improvements !

However those improvements are too elusive (at least for my eyes) to provide a feeling of a better details preservation or sharpness when watching the sequence live.

Do you have an idea of how slow is your encode compared to Inventive Software's one (your settings appear insane ;)).

Dark Shikari

16th September 2007, 17:08

I compared your result to "Inventive Software". By watching very closely (i.e. almost frame by frame) I can observe a little bit more details in yours. Hence good point, your patches actually brought some improvements !

However those improvements are too elusive (at least for my eyes) to provide a feeling of a better details preservation or sharpness when watching the sequence live.

Do you have an idea of how slow is your encode compared to Inventive Software's one (your settings appear insane ;)).
Those settings went at about 2.5 FPS on a Core 2 Duo 2Ghz :p

I wasn't trying for speed; if you want a non-insane encode speed, use one of the following (top is slowest, bottom is fastest):

(8-10% better)
--ref 4 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 7 --no-fast-pskip --mixed-refs --me imh --me-prepass --trellis 2

(6-8% better)
--ref 4 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 7 --no-fast-pskip --mixed-refs --me umh --trellis 2

(My favorite for balance of speed/quality)
--ref 3 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 6 --mixed-refs --me hex --trellis 1

(4-5% worse)
--ref 2 --bframes 16 --b-pyramid --weightb --bime --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 5 --mixed-refs --me hex --trellis 1

(7-9% worse)
--bframes 16 --weightb --direct auto --analyse p8x8,b8x8,i8x8,i4x4 --8x8dct --subme 4 --me hex --trellis 1

bobololo

19th September 2007, 00:08

Sharktooth

19th September 2007, 00:49

I see big differences between the x264 and MC encodings.
First, MC is more blocky on the backgrounds but in the same scene it has more foreground details. x264 shows banding in place of blocks.
also the initial fade is handled better by the MC encoder.

zambelli

19th September 2007, 03:45

And Sharky: I'd have a look at that VC-1 encode again. Seems to be the best VC-1 encode I've done to date on this source at 500 Kbits, but at this bitrate, H.264 wins out, so it seems. I'm waiting on analysis from Ben Waggoner and Zambelli for more suggestions, if they can eek out better quality from WMV9 AP.
The Rapidshare page was showing that the download limit had been exceeded so I couldn't download your VC-1 sample, but I did encode a few of my own. Using our new VC-1 Encoder SDK I was able to fix those pesky fades and improve upon many of the gradients and dark areas.

Here's my VC-1 encode: http://www.citizeninsomniac.com/video/ED_360p_500k_eSDK_DQ.wmv

Dquant is definitely necessary for this encode with VC-1 because of all the smooth and dark areas, but striking a reasonable balance between sending all the bits to those areas versus the textured areas is very challenging. Your encode is likely a better compromise (I haven't seen it, but I can guess that based on your encoding settings and my own results), whereas my linked VC-1 encode has a greater bias for smooth areas and gradients. Neither encodes are perfect - I really don't like the amount of blocking and loss of detail that's happening in the textures, regardless of how detailed the smooth areas might look.

x264 encode, 500.51kbps.
I checked out your x264 encode - and it is excellent. Very impressive. Great sharpness and good decisions about where to lose details and where to preserve them in the context of 500k. x264's deblocking really pays off here, too, because it's hard to actually find blocking artifacts in your encode - whereas I wish I could say the same for the VC-1 encode.

There are a few places where VC-1 eSDK does better, such as in the light gradients between #6300 and #7000, but that's not surprising given the previously mentioned VC-1 dquant bias for smooth areas.

BTW, I've noticed a weird artifact that you might want to investigate: check out frames around #3087 and notice there's some strange chroma ghosting to the right of the character wearing the green coat. There are hints of green all over those wires. Not sure where that's coming from.

BTW, I think you might've used the wrong color matrix for the source conversion - your encode looks greener than my source which I converted using Rec601 since this is an SD source. Did you use Rec709?

Dark Shikari

19th September 2007, 04:04

BTW, I've noticed a weird artifact that you might want to investigate: check out frames around #3087 and notice there's some strange chroma ghosting to the right of the character wearing the green coat. There are hints of green all over those wires. Not sure where that's coming from.

BTW, I think you might've used the wrong color matrix for the source conversion - your encode looks greener than my source which I converted using Rec601 since this is an SD source. Did you use Rec709?Yeah, I think I used the wrong color matrix.

The chroma ghosting is very strange, also.

One thing I may try is re-encoding this with my new AQ algorithm--I'm not sure if it'll help at this low a bitrate, but it could decrease blocking even more.

Sergey A. Sablin

19th September 2007, 05:13

As Mainconcept announced their brand new reference encoder. I gave a try and here is the result (ftp://mood.ateme.com/algo/ed360p-mc-vbr-500k.mp4).

To me it's quite hard to make the difference compared to your result.

I used some similar settings (2pass vbr), I selected all "complex" parameters when available and disabled all "fast" options.

did you use any AQ? (I didn't check the encode, otherwise I'd know this)
btw disabling "fasts" mostly has influence on speed, which slows significantly, while quality increase isn't that noticeable. Well you probably know...

btw2 - do you mind to have a try to yours encoder?

Sergey A. Sablin

19th September 2007, 05:56

did you use any AQ? (I didn't check the encode, otherwise I'd know this)

ok, had a look - no AQ, but looks like it is just 2 plain B-frames instead of 3 hierarchical B-frames comparing to x264.

Dark Shikari

19th September 2007, 06:16

ok, had a look - no AQ, but looks like it is just 2 plain B-frames instead of 3 hierarchical B-frames comparing to x264.x264 actually has 16 bframes enabled (my encode) so it can use as much as it wants, basically.

IgorC

19th September 2007, 06:25

MC seemed to me more sharp but also a bit blocky than x264.
I did fast comparing x264 and MC to old Ateme High Profile encoder from 2005 with full settings and psy 2. My visual preference is still to Ateme however it has a lower OPSNR and SSIM2 0.24a with lumimask = true.

Bobololo It would be interesting to see your encoder

Can anybody do ASP encode with Xvid, Divx or Libav to compare it to VC-1? Its pretty seems like VC-1 is still on par with ASP and no chance to be compared with H.264

zambelli Your encode is 510 kbit/s. The target bitrate was 500 kbit/s. 2% isn't much but can make difference.

Sergey A. Sablin

19th September 2007, 06:52

x264 actually has 16 bframes enabled (my encode) so it can use as much as it wants, basically.

I don't think more that 3 b-frames anyhow useful for real life encoding (probably besides anime), that's why I've limit encoder to 3 b-frames at max.

Dark Shikari

19th September 2007, 06:56

I don't think more that 3 b-frames anyhow useful for real life encoding (probably besides anime), that's why I've limit encoder to 3 b-frames at max.In fades more b-frames are useful and so forth, though x264 doesn't have proper fade frame decision yet. Its bad habit to not use 16 bframes IMO in general encoding, because it doesn't slow things down at all to give the encoder the option, and there are cases when it does benefit.

Sergey A. Sablin

19th September 2007, 07:10

In fades more b-frames are useful
correct, but using some b-frames and explicit weighted prediction for at least P-frames even more useful.

Its bad habit to not use 16 bframes IMO in general encoding, because it doesn't slow things down at all to give the encoder the option, and there are cases when it does benefit.
how many B-frames in a row were used in this particular stream in x264 encoding at max?
it won't make any difference in speed using 1 or 100 b-frames as settings are rather insane and as far as I know x264 lowres uses fast decisions to construct pb pattern. using more faster settings one should see a small difference in performance.

shon3i

19th September 2007, 10:46

IMHO Ateme is now golden mean, it have very sharp picture and less blocking than mainconcept and x264. Psy on macroblock in ateme is very good option which make encoding realy free blocking. Mainconcept/Elecard's encoders realy make more sharper and more blocky encode, but that can be soloved with Adaptive Q and negative values for strenght.

CruNcher

19th September 2007, 12:31

yep i can absolutely agree with shon3i my extreme low bitrate HD test shows absolutely stunning visual results, you can really see that tweaking for streaming scenarios (broadcast) really helps overall, and im almost sure that we would also have seen this in the 4th anual MSU test if they would have decided to participate it's really sad.

bobololo

20th September 2007, 00:22

did you use any AQ? (I didn't check the encode, otherwise I'd know this)
btw disabling "fasts" mostly has influence on speed, which slows significantly, while quality increase isn't that noticeable. Well you probably know...

Well I'm absolutely not familiar with MC encoder and all I tried to do was to find what could be the highest quality config without any compromise about the speed in order to match with Dark Shikari encode. Actually I'd strongly suggest you to encode it on you own using the best fitted settings rather than letting me fumbling ;)

btw2 - do you mind to have a try to yours encoder?

I wouldn't be honest if i say no ;) As you can imagine my first objective was to evaluate different H.264 implementations compared to ours. And if I haven't made any comments, it was on purpose. Actually I don't plan to post any streams from us (for many good reasons you can believe me). Hence it would be totally meaningless for me to claim anything without any real material to back my statements.

yep i can absolutely agree with shon3i my extreme low bitrate HD test shows absolutely stunning visual results, you can really see that tweaking for streaming scenarios (broadcast) really helps overall, and im almost sure that we would also have seen this in the 4th anual MSU test if they would have decided to participate it's really sad.

The reason why we haven't taken part to MSU's new round is that their comparison conditions are totally out of scope with regards to the research we led those past years. It wouldn't surprise me if our current version even have lower psnr/ssim than the latest beta while MSU evaluation is based on it. Beside, you all know that we're more and more involved in broadcast encoding. Our encoder consequently has been largely tuned for that usage and unfortunately there were not a single test that could reflect the encoding for the TV: interlaced, CBR, short gop, constrained CPB, strict HRD compliance, etc. And moreover, even I've considerable respect for MSU's initiative and work, I have to admit that I've been a little bit disappointed when after explaining them several times that our encoder would not be well suited for their tests (for the reasons described just before). When I also told them that we'd be very happy to take part to their comparison if it would offer some test cases that match the applications our encoder is designed for. They got back to me saying that "You can take part to the comparison privately, you need to pay xxxx euros and your scores will be removed from the public results" !

DeathTheSheep

23rd September 2007, 03:07

you need to pay xxxx euros and your scores will be removed from the public results
Wow.

Well that puts you in a somewhat awkward situation indeed. :eek:

I was actually wondering if there was a trial/demo/test version of that Mainconcept Reference software somewhere, because I'm a bit surprised by what I saw in the test clip.

Sergey A. Sablin

23rd September 2007, 04:06

Wow.

Well that puts you in a somewhat awkward situation indeed. :eek:

just to make things clearer - what has been offered by Dmitry (and I believe what bobololo said) is that if someone wants to participate, but don't want to publish the results (for any reason), that this is possible with some payment.

I was actually wondering if there was a trial/demo/test version of that Mainconcept Reference software somewhere, because I'm a bit surprised by what I saw in the test clip.

yes, it is - check out the web site.

DeathTheSheep

23rd September 2007, 04:12

You are correct, but it's hard to test a codec's full potential (especially concerning minute quality differences) when there's a huge flickering watermark added to every frame. :rolleyes:

Sergey A. Sablin

23rd September 2007, 04:14

You are correct, but it's hard to test a codec's full potential (especially concerning minute quality differences) when there's a huge flickering watermark added to every frame. :rolleyes:

sure, but anyway better than nothing ;)

DeathTheSheep

23rd September 2007, 04:25

Maybe. ;)

IgorC

23rd September 2007, 16:37

you can try Elecard H.264. It has the same MC encoder but instead of watermark there is 15000 frames limitation.

DeathTheSheep

23rd September 2007, 16:47

On the download page, is it the "Elecard Converter Studio" or "Elecard Mobile Converter"?

Sergey A. Sablin

23rd September 2007, 20:49

On the download page, is it the "Elecard Converter Studio" or "Elecard Mobile Converter"?

the former one.

DeathTheSheep

24th September 2007, 02:28

from elecard website (http://www.elecard.com/products/products-pc/consumer/converter-studio/)
The demo versions have limitations of 15000 frames for conversion, demo period duration of 30 days and logo on the files being encoded.
:rolleyes:

IgorC

24th September 2007, 19:17

Elecard just add the watermark this month. hehehe :p not lucky

DeathTheSheep

24th September 2007, 21:13

The Sheep of DEATH is never lucky!

IgorC

3rd October 2007, 03:52

Yeah, I think I used the wrong color matrix.

The chroma ghosting is very strange, also.

One thing I may try is re-encoding this with my new AQ algorithm--I'm not sure if it'll help at this low a bitrate, but it could decrease blocking even more.
What matrix did you use? It is not bad for this source.
I'm testin here with different color matrices. rec709 is too
red and hard to encode due to artifacts on this color

DeathTheSheep

3rd October 2007, 05:44

Aha! Finally testing out the ol' AQ on low bitrates! Now I'm excited...

zambelli

3rd October 2007, 11:13

What matrix did you use? It is not bad for this source.
I'm testin here with different color matrices. rec709 is too
red and hard to encode due to artifacts on this color
Rec709 is probably not the suitable color matrix for SD 360p. The default Rec.601 matrix should be used for converting the RGB PNG source to YV12 after resizing, IMO.

check

3rd October 2007, 13:55

Rec709 is probably not the suitable color matrix for SD 360p. The default Rec.601 matrix should be used for converting the RGB PNG source to YV12 after resizing, IMO.
When you say less suitable, do you mean it actually impacts compressibility, or simply it's the converting to the wrong colours?

Inventive Software

3rd October 2007, 16:57

@zambelli: Now I'm interested, since mostly it's been a lil off-topic. Currently, the (mostly crude) way of converting the RGB source to YV12 is "ConvertToYV12()" in AviSynth. That's it. With just "ConvertToYV12()", is that using Rec.601 or Rec.709?

IgorC

3rd October 2007, 17:53

It says that default is Rec601 in avisynth doc.

zambelli

3rd October 2007, 19:51

When you say less suitable, do you mean it actually impacts compressibility, or simply it's the converting to the wrong colours?
It's converting to the wrong colors because at sub-SD resolutions most drivers (which end up doing the final YUV-->RGB conversion in playback) will assume BT.601. So if you convert source video to YV12 using BT.709, but the video driver assumes BT.601 in playback - you end up with different colors than you started with.

IgorC

4th October 2007, 16:33

Libav ASP 500.4 kbits (http://www.mediafire.com/?bbugyyxywrh)

mencoder settings 3passes:
mencoder.exe eld_rec601.avs -o pass3_large.m4v -ovc lavc -lavcopts vstrict=1:vpass=3:vbitrate=500:vb_qfactor=1.5:vb_qoffset=0.0:vqcomp=0.75:vmax_b_frames=2:bidir_refine=4:preme=2:dia=-6:predia=-6:mbd=2:precmp=6:cmp=6:subcmp=6:v4mv:mv0:mv0_threshold=0:trell:cbp:qprd:last_pred=3:psnr:vrc_strategy=0 -of rawvideo -ffourcc MP4V

For watching I used ffdshow decoder with high quality settings for postprocessing:
http://img70.imageshack.us/img70/8562/ffdshowtw6.png

I've evaluated zambelli's new SDK VC-1 video ( http://www.citizeninsomniac.com/video/ED_360p_500k_eSDK_DQ.wmv ).

Visually I prefer ASP

zambelli

11th October 2007, 11:23

I've evaluated zambelli's new SDK VC-1 video ( http://www.citizeninsomniac.com/video/ED_360p_500k_eSDK_DQ.wmv ).

Visually I prefer ASP
Any particular scenes or features look better in ASP? I'm not a big fan of this low-bitrate VC-1 quality and I'd love to take such feedback back to the dev team. VC-1 should ideally look better than ASP, if not AVC.

Sharktooth

11th October 2007, 13:20

VC-1 HAS TO look better than ASP and expecially at low bitrates. It's more advanced and there's no reason why it shouldnt. However, the current implementation is not so shining comparing it to current ASP encoders.

IgorC

11th October 2007, 13:57

Any particular scenes or features look better in ASP? I'm not a big fan of this low-bitrate VC-1 quality and I'd love to take such feedback back to the dev team. VC-1 should ideally look better than ASP, if not AVC.

Sorry, zambelli I provided an ASP video as answer to your vc-1 sample encoded by extra new sdk. And ASP looks really better than current vc-1.
Yeah, we've already heard tale about how VC-1 is inferior at low bitrates and how vc-1 shines at high bitrate?
Sorry what is compression all about? What point to use VC-1 at high bitrates when there is MPEG-2?

There isn't only x264.
Don't subestimate H.264 codecs at high bitrates saying how good vc-1 preserve film grain. There is still some advanced commercial H.264 encoders that use psy models to handle filmgrain and misc. details at middle/high bitrates.
VC-1 is perfectly inferior to full featured AVC at all bitrates.

zambelli

11th October 2007, 18:48

Sorry, zambelli I provided an ASP video as answer to your vc-1 sample encoded by extra new sdk. And ASP looks really better than current vc-1.
Yeah, we've already heard tale about how VC-1 is inferior at low bitrates and how vc-1 shines at high bitrate?
Sorry what is compression all about? What point to use VC-1 at high bitrates when there is MPEG-2?
And didn't I just say that Microsoft encoder's low-bitrate quality could use some improvements? I wasn't making any excuses - I was asking for concise feedback. :confused:
Well, thanks for the ASP encoding.

CruNcher

12th October 2007, 05:25

The problem is really to find the right balance (especialy if you go into the HVS direction (psycho)visual optimization without takeing metrics into account) between all the factors that play a role, im doing this since day 1 that im here and it is a very time consumeing process each generation, the're even ways to lower the complexity of the streams (for the decoder) so they are almost on paar with VC-1 complexity and that @ lower bitrate keeping still better quality/speed :) imho Microsoft balanced to much for HD (High Bitrate) and totaly forgot about Low Bitrate (this is really bad for VOD and Mobile usage). Apple Engineers do really great in that direction :) even if people won't belive it here but Quicktime is very well balanced.

Sharktooth

12th October 2007, 15:27

CrapTime has other problems... like slowness (playback and encoding), huge memory footprint, a sh!tload of bugs, standards incompatibilities (partial implementation), etc.

Dark Shikari

12th October 2007, 15:30

Quicktime is very well balanced.Yes, it balances bugginess with a terrible interface, lack of support for standards, and memory bloat.

smok3

29th April 2008, 16:48

i did a quick encode with crf 21, settings and stuff here;
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/ED_huff-x640y352.mp4
(this was cropped to mod16 resolution, the average bitrate comes out as 922 kbps, should be also qt compatible)

if we are not counting the audio part, then this would qualify as 1mbit encode i guess :)

Inventive Software

29th April 2008, 17:19

The stereo audio track can be encoded at 64 Kbps with HE-AAC, so it's a viable distribution for 1 Mbit. However, CRF's a bit of a lottery with bitrates. :)

smok3

29th April 2008, 18:23

ok, so do we count audio or not? (working on the low bitrate vp6 encode ~ 480 kbps - since i just happen to have a one-click preset for that bitrate), honestly to get anything that is possible to watch at this resolution one would need around 700-800 kbps (without audio) - no i couldn't dl the shakiris x264 encode.

edit: vp6 is giving me 1.5 fps on 2nd pass, so maybe tomorrow..., no it speeded up;
----------------
480
vp6 http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/ED_huff-x640y352.flv
x264 http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/ED_huff-480kbps-x640y352.mp4 (very sane settings, fast encoding)

500
vp6 http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/ED_huff-500kbps-x640y352.flv
x264 http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/ED_huff-500kbps-x640y352.mp4 (very sane settings, fast encoding)

edit: premiere cs3 crashed twice (on two different machines) when trying to do 2pass VBR h264 encode, so for me useless..., edit: same happens when trying to get to the h.264 encoder via afterFX, any clues? they don't like huff avi as source for some reason? (what i have is cs3 video bundle, any other, better access to the mc in cs3?)

benwaggoner

1st May 2008, 07:57

Speaking of Elephant's Dream, I was going to take a whack at it with Expression Encoder 2, but it looks like no one is seeding the .torrent anymore for the 1080p.

http://media.xiph.org/ED/ED-1080-png.torrent

If anyone's got the files and the torrent local, I'd appreciate it if you could start seeding it again for a bit.

Sagittaire

1st May 2008, 10:13

http://media.xiph.org/ED/ED-1080-png/

Tagert

1st May 2008, 10:48

Could also download the 1080p version from the creators' homepage :)
http://orange.blender.org/download

Very fast servers :)

smok3

1st May 2008, 10:51

benwaggoner; how about a 360 version first? (you will have plenty less to download as well.)

benwaggoner

1st May 2008, 15:57

benwaggoner; how about a 360 version first? (you will have plenty less to download as well.)
I'll do that as well, although there don't appear to be any seeders for that either at the moment.

smok3

1st May 2008, 16:11

benwaggoner

1st May 2008, 16:24

this
http://media.xiph.org/ED/ED-360-png.tar
or
http://media.xiph.org/ED/ED-360-png/
also
5 channels of uncompressed audio could be found here (although i have used 2ch version in my tests);
http://media.xiph.org/ED/
Okay, here's a question that will reveal that I'm a video guy and a former Mac guy.

How the heck do I programatically download a folder of files from a http:// url? On Mac, I would have used curl from the terminal. Filezilla can only use the ftp URL.

Dark Shikari

1st May 2008, 16:25

Okay, here's a question that will reveal that I'm a video guy and a former Mac guy.

How the heck do I programatically download a folder of files from a http:// url? On Mac, I would have used curl from the terminal. Filezilla can only use the ftp URL.DownThemAll

smok3

1st May 2008, 16:30

wget -r -l 1 -A png http://media.xiph.org/ED/ED-360-png/

benwaggoner

1st May 2008, 16:42

wget -r -l 1 -A png http://media.xiph.org/ED/ED-360-png/

C:\Users\Ben Waggoner>wget
'wget' is not recognized as an internal or external command,
operable program or batch file.

smok3

1st May 2008, 16:45

one place where wget for windows can be found is wackget package, google for wackget.

Dark Shikari

1st May 2008, 17:04

C:\Users\Ben Waggoner>wget
'wget' is not recognized as an internal or external command,
operable program or batch file.That's what you get for not using a modern operating system ;) Even OS X comes with wget these days, I think...

benwaggoner

1st May 2008, 17:10

DownThemAll
Ah, perfect! Working like a champ, thanks.

benwaggoner

1st May 2008, 18:44

So, remind me where we are after the last year:

Do we have a definitive .avs we're all going to use for this?

Also, for 500 Kbps VBR, is that just video, or video + audio?

Anyone done any CBR tests yet?

Inventive Software

1st May 2008, 23:38

I got rid of my lossless PNG source after converting it to RGB Lagarith, mainly because of speed, but also space. I'll do some 1 Mbit CBR encoding with x264, WMV9 AP, and VP7 this weekend.

benwaggoner

2nd May 2008, 00:26

I got rid of my lossless PNG source after converting it to RGB Lagarith, mainly because of speed, but also space. I'll do some 1 Mbit CBR encoding with x264, WMV9 AP, and VP7 this weekend.
Do you still have your .avs file? It' be good for us all to be using the exact same source pixels. I saw a couple variants being posted around, so I'd like to see a definitiive one.

That said, shouldn't you be using YV12 Lagarith, to avoid doing a potentially tool-specific color space conversion?

Dark Shikari

2nd May 2008, 00:29

Do you still have your .avs file? It' be good for us all to be using the exact same source pixels. I saw a couple variants being posted around, so I'd like to see a definitiive one.

That said, shouldn't you be using YV12 Lagarith, to avoid doing a potentially tool-specific color space conversion?The original PNGs were RGB, not YV12, so making YV12 Lagarith would involve a colorspace conversion anyways.

benwaggoner

2nd May 2008, 00:42

The original PNGs were RGB, not YV12, so making YV12 Lagarith would involve a colorspace conversion anyways.
Right, but if we do it in the standard AVISynth script, we'll all get the same color space conversion and don't have to worry about that as a factor in comparing encodes.

Dark Shikari

2nd May 2008, 00:52

Right, but if we do it in the standard AVISynth script, we'll all get the same color space conversion and don't have to worry about that as a factor in comparing encodes.That's exactly what I'm saying; when you source the Lagarith source, you do a ConvertToYV12 in the avisynth script.

benwaggoner

2nd May 2008, 01:04

That's exactly what I'm saying; when you source the Lagarith source, you do a ConvertToYV12 in the avisynth script.
But then we have two AVS scripts - one for .png to RGB, and the other for RGB to YV12. Better to have a single script that goes from .png to YV12 and can be used to build a final colorspace intermediate or be used directly as source.

Dark Shikari

2nd May 2008, 01:10

But then we have two AVS scripts - one for .png to RGB, and the other for RGB to YV12. Better to have a single script that goes from .png to YV12 and can be used to build a final colorspace intermediate or be used directly as source.But the PNGs are RGB, so there is absolutely no conversion involved; the result will be bit-equivalent.

benwaggoner

2nd May 2008, 04:09

But the PNGs are RGB, so there is absolutely no conversion involved; the result will be bit-equivalent.
I'm mainly worried about having a consistent RGB to YV12 conversion method, using Rec. 601, for example.

Inventive Software

2nd May 2008, 08:37

ConvertToYV12() is Rec.601 by default, I think.

smok3

2nd May 2008, 10:33

i have used this to do my intermediate;
this file was 1st converted to huff, using this avisynth:
a=imageSource("r:\ElephantDreams\media.xiph.org\ED\ED-360-png\%05d.png",1,15691,24)
b=wavsource("r:\ElephantDreams\ED-CM-St-16bit.wav")
audiodub(a,b)
crop (0,4,0,-4) # crop height 352

+ converttoyv12() on the next pass.

smok3

2nd May 2008, 10:47

I'm mainly worried about having a consistent RGB to YV12 conversion method, using Rec. 601, for example.
and i'am a bit worried that we will really never see the wmv version at 500 kbits as it seems, that can't talk in favour of MS encoding workflow(s). I mean, com on, i don't expect much, it will probably be worse than vp6 as well, but at least we are on the clear (and honestly, i'am not trying to be evil here).
edit2: ok, here i'am evil;
http://somestuff.org/netFrameworkError.png

p.s. i also did CBR sorenson and CBR vp6 @ 500 kbps (for video), but they were both unwatchable - using adobe flash cs3 encoder thingy.

edit: that boat sample is pretty good, is there a working torrent for the raw footage or edit?