high quality mpeg-2 encoding

[manono]

... but if you care at all about quality use multi-pass VBR encoding. Either that or go for 1-pass quantizer encodes, but then you'll lose all control over the final file size.

I'm assuming you're using CCE? I agree with VBR. Using 1-pass Q does give very good results too, but I've noticed, with my eyes at least, plugging that same exact resulting bitrate you got from Q into a VBR encode afterwards and, with maybe 3 passes or so, re-encoding that same source gives better results on the more complex scenes.

I don't find CCE's Q as good a scheme as similarly with DivX, Xvid or x264 which do use one pass very effectively. (Or maybe it's an MPEG-2 thing in general, don't know.)

If you're using certain Q-specific settings for CCE that achieve results just as good as VBR (at similar bitrate) I'd love to know. I love one-pass and don't care for the no-control final bitrate if the results are optimal to the quality I ask for.

Yes, CCE. I haven't done any comparison tests of the kind you describe. Let me see, do I have any settings different for the CQ encodes than from the regular multi-pass encodes? I'll check the templates...

Nope, exactly the same, except I usually confine my CQ encodes to any extras I might want to keep, and then use the remaining room for the main movie. Therefore the quantizer matrix I use for the extras is a much lower quality one than the ones I might choose to use for the movie.

[jagabo]

Keep in mind deadrats was using 4000 kbps constant bitrate encoding.

[sanlyn]

4000kbps and you're happy? Strange.
I'm familiar with tmpgenc , though not the latest version and i would not use its video noise reduction filter but maybe they've improved it..

To get quality, encode in 2pass, maximum around 9000kbps.

I agree. The latest TMPGenc is no match for earlier versions. The noise filter that comes with their encoders is a simple blurring filter that does more harm than good; overused, it can make 1080p source look like 2nd-rate VHS.

As for birate: even at high birates, the later encoders have poor motion handling. Even with poor quality VHS, after cleanup in Vdub or Avisynth I get excellent results from VHS at VBR of 4500 min/7000 max, and on playback the bitrate seldom exceeds 6500. Increasing the max bitrate gave me little improvement except on really difficult material. Of coursed I'm mindful of the fact that VHS doesn't have much detail to begin with. I've also used 8000 or less for AVI captures from HDTV. Shooting up to 9000 didn't seem to accomplish much, unless the target is a 50"-plus tv.

[manono]

Keep in mind deadrats was using 4000 kbps constant bitrate encoding.

Who were you addressing? I think we're all aware he's using CBR encoding.

It's the CBR encoding that's ruining your encodes. Always use VBR for something like this.

https://forum.videohelp.com/topic371339.html#1993502

[deadrats]

(If you decided to use H264, use x264 for christ sakes and learn them encoder options).

i know there are some in here that will consider what i am about to say heresy but i personally don't find x264 all that impressive. over the years i have seen hundreds of encodes from blu-ray rips done with x264 and for the most part i find the encodes to be of mediocre quality at best, the only encodes i have ever seen that looked good were from a "scene group" that used a custom matrix, all other encodes the color saturation seemed off, the encode wasn't crisp.

my own encodes, using either avidemux with the built in x264 or the x264 vfw with tmpg express, with all the options for quality maxed out (perhaps my understanding of the options is lacking) resulted in worse results than when i did the same encodes using xvid and choosing the "hi def" profile or with divx and choosing the "insane quality" setting.

my personal feeling is that if x264 was anywhere near as good as it's proponents make it out to be then the studios would be using it for there own blu-ray encodes rather then spending $1000 per seat on apple's h264, $40000 per seat on panasonic's h264 or $70000 per seat on CCE's h264 encoders.

hell, i defy anyone to show me any encode done with x264 that looks as good as the following trailers, encoded with either apple's h264 or divx's h264:

http://www.divx.com/en/downloads/divx-7-showcase

http://www.apple.com/trailers/

as for your advise regarding video denoising, after some thought i realized you are right, i don't know what i was thinking, the source is extremely crisp with no noise so what the hell was i trying to denoise? my original thinking was that in down-scaling the video i would be introducing noise to the final output but the more i think about it the more i come to the conclusion that my reasoning was faulty.

[poisondeathray]

hell, i defy anyone to show me any encode done with x264 that looks as good as the following trailers, encoded with either apple's h264 or divx's h264:

http://www.divx.com/en/downloads/divx-7-showcase

http://www.apple.com/trailers/

ok...this is coming from the guy who thinks 4Mb/s MPEG2 looks good LOL

1) Apple movie trailers average around 9-11Mb/s , and only use AVC Main profile. They are about "medium" quality if you compare it to the same title on blu-ray. Apple AVC is not compatible with the high profile, and consistently generate worse encodes than even DivX or Mainconcept h.264 encoders.

2) You should be comparing the same generation. i.e. Master=> Apple Trailer , not Master=>Apple Trailer=> some other 2nd generation encode. This make more of an "apples to apples comparison"

3) Divx h.264 generates lower quality than x264 for the trade off of compatiblity and "DivX HD certification", even the people at Divx say this. If you don't believe me, look at the Doom9 forums at the DivX v2 encoder beta testing thread. If you've ever used the Divx h.264 encoder, you would know how rudimentary it is.

4) Many blu-ray sources are not good quality. They have been pre-filtered with low pass, or were bad transfers. As a result, and "rip" would look even worse.

5) One big reason why studios wouldn't/can't use x264 is that it doesn't use slices (yet). Blu-ray High profile 4.1 requires this for compatibility. Although the majority of SAPs will play x264 authored discs perfectly fine, it's still not 100% compatible. The replication houses would reject it.

I dare you to use decent settings, with the same source, comparing x264, Apple compressor, and Divx h.264 encoder, then come back and we can discuss it.

[deadrats]

I dare you to use decent settings, with the same source, comparing x264, Apple compressor, and Divx h.264 encoder, then come back and we can discuss it.

your dare is accepted and all can participate, if they so desire. download the x264 HD benchmark:

http://www.techarp.com/showarticle.aspx?artno=520

in the folder 'test' you will find a 720P mpeg-2 named, appropriately enough, test-720p, that will be our source.

your task, should you choose to accept it, is to produce the highest quality 960x540 transcode you can, using any codec you you desire.

we'll upload the results to something like mega upload and let the forum decide for themselves.

are you up for it?

edit: let's limit the video bitrate to 3 mb/s and the audio to 128 kb/s.

edit 2: we're going to have to find something else to use as source, the test mpg that comes with the benchmark is causing mpeg streamclip and badaboom to report errors about the video stream and even tmpg express chokes on it when i try and transcode it to certain file types.

[dphirschler]

People can argue all day about which encoder is the best. I still stand by TmpgEnc even though it is slow (compared to the others). I've been using it for years and love it. I tried out HC and it failed to give me the same quality and its encodes were unpredictable in size.


Darryl

[jagabo]

I recommend adding a standard color chart to make it easier to judge color and levels shifts. For example the Belle Nuit charts:

http://www.belle-nuit.com/testchart.html

The suggested test clip doesn't indicate the colorspace used but since it's high definition MPEG 2 I would assume rec.709. Here's a 1 second Belle Nuit clip that can easily be appended to the test clip (1280x720, 23.976 fps, MPEG 2, rec-709):

bn720.m2v

Note the color resolution bars are pretty useless after MPEG encoding.

[guns1inger]

People can argue all day about which encoder is the best. I still stand by TmpgEnc even though it is slow (compared to the others). I've been using it for years and love it. I tried out HC and it failed to give me the same quality and its encodes were unpredictable in size.


Darryl

The old Tmpgenc 2.5 encoder was OK, but glacially slow. Subsequent versions got faster, but at the expense of quality and options. And faster is used here as a relative term. They are still far slower than some of the competition. I have never been impressed with the encoder in tmpgenc 3 or 4 for quality.

HCEnc has always produced good quality encodes with predictable file sizes. I have never had an issue with it not doing as it was supposed to.

[deadrats]

I recommend adding a standard color chart to make it easier to judge color and levels shifts. For example the Belle Nuit charts:

http://www.belle-nuit.com/testchart.html

The suggested test clip doesn't indicate the colorspace used but since it's high definition MPEG 2 I would assume rec.709. Here's a 1 second Belle Nuit clip that can easily be appended to the test clip (1280x720, 23.976 fps, MPEG 2, rec-709):

bn720.m2v

Note the color resolution bars are pretty useless after MPEG encoding.

the test clip i suggested seems to have some major problems, not sure what encoder was used to create it but nearly every app i try to transcode it with seems to choke on either the video or audio portions.

what i really want to use is a demo panasonic put out a while ago, a 1080i mpeg-2 really high quality clip that features a hot chick with a tasteful bikini scene, the file name is [PIONEER][HDTV][1080i]Pioneer_HDTV_Demo and a google search brings up links to torrents where it can be downloaded but i can't find an official panasonic link.

if anyone has a suggestion for a really high quality mpeg-2 trailer or demo that we can use as source it would be greatly appreciated.

[poisondeathray]

This thread has sort of gone off the original topic, but hey what thread ever stays on topic ?

Your test clip works fine with encoders who accept avs scripts e.g.

FFMpegSource2("test-720p.mpg")
AssumeFPS(24000,1001)
ColorMatrix("Rec.601->Rec.709")

And I already did x264 and divx h.264 1280x720 @ 4Mbps, but it looks like you are looking for another source clip. If you want me to upload the encoded clips just shout, but there is a representative frame grab below.

Pay attention to the detail and grain retention, especially in the traps/shoulders and face of the x264 encode. This "smoothness" in the divx h.264 framegrab is characteristic of Mainconcept based h.264 encoders (like divx h.264, and TMPGenc, and basically any NLE), and if you search I've posted dozens of samples before and commented on this in the past

Can I ask why your "new source" has to be a mpeg2 source?

Can I suggest in your "mini-test" to provide consistent "rules" ie. no resizing or processing filters or at least specify exactly which algorithm. e.g. if you had resized to 950x540, this complicates matters if someone used lanczos vs. bilinear , for example. Also, I don't think audio is necessary for a visual quality test...

techarp.zip

[deadrats]

This thread has sort of gone off the original topic, but hey what thread ever stays on topic ?

Your test clip works fine with encoders who accept avs scripts e.g.

FFMpegSource2("test-720p.mpg")
AssumeFPS(24000,1001)
ColorMatrix("Rec.601->Rec.709")

And I already did x264 and divx h.264 1280x720 @ 4Mbps, but it looks like you are looking for another source clip. If you want me to upload the encoded clips just shout, but there is a representative frame grab below.

Pay attention to the detail and grain retention, especially in the traps/shoulders and face of the x264 encode. This "smoothness" in the divx h.264 framegrab is characteristic of Mainconcept based h.264 encoders (like divx h.264, and TMPGenc, and basically any NLE), and if you search I've posted dozens of samples before and commented on this in the past

Can I ask why your "new source" has to be a mpeg2 source?

Can I suggest in your "mini-test" to provide consistent "rules" ie. no resizing or processing filters or at least specify exactly which algorithm. e.g. if you had resized to 950x540, this complicates matters if someone used lanczos vs. bilinear , for example. Also, I don't think audio is necessary for a visual quality test...

techarp.zip

1) absolutely, upload your test encodes, i'd like to see them.

2) the reason i want to start with a really high quality mpeg-2 source is because a) most tv captures are done to mpeg-2, especially most of the HDTV captures i have ever seen are always captured to 1080i and then re-sized and transcoded to 720p, b) mpeg-2 is a less compressed format than mpeg-4 asp or avc or vc-1 and as such it makes sense to me that the only true test would be going from a less compressed source to a more compressed output, c) resizing represents a more realistic scenario for the average user, i.e. few people take a 1080p blu-ray rip and convert it to a 1080p target, more often than not they are transcoding to reduce the amount of storrage space needed for a file and thus reduce size along with bit rate to maintain quality, and finally any codec, even ms-mpeg4 v1 from years ago can easily maintain quality of no resizing is done, but add resizing and de-interlacing to the mix and watch how many codecs will choke.

as a matter of fact i think i just thought of the perfect test, follow the link:

http://www.microsoft.com/windows/windowsmedia/musicandvideo/hdvideo/contentshowcase.aspx

and download the 1080 'taxi 3' demo, and let's agree on a target resolution of 1280x720, 4 mb/s for the video, 256 kb/s for the audio, microsoft's vc-1 is notoriously difficult to transcode to other formats, primarily because it's so highly compressed, this clip is extremely crisp, with lots of fast action shots and vibrant colors, any weaknesses of the target codec will be readily apparent.

it's getting kind of late right now, but tomorrow i will transcode the test clip to divx (insane profile), mpeg-2, divx h264, nero's digital and digital avc, x264, xvid and i will upload all the results, all the settings will be maxed out with goal being maximum quality.

as i said, everyone is free to try it out themselves and upload the results.

[poisondeathray]

2) the reason i want to start with a really high quality mpeg-2 source is because a) most tv captures are done to mpeg-2, especially most of the HDTV captures i have ever seen are always captured to 1080i and then re-sized and transcoded to 720p, b) mpeg-2 is a less compressed format than mpeg-4 asp or avc or vc-1 and as such it makes sense to me that the only true test would be going from a less compressed source to a more compressed output, c) resizing represents a more realistic scenario for the average user, i.e. few people take a 1080p blu-ray rip and convert it to a 1080p target, more often than not they are transcoding to reduce the amount of storrage space needed for a file and thus reduce size along with bit rate to maintain quality, and finally any codec, even ms-mpeg4 v1 from years ago can easily maintain quality of no resizing is done, but add resizing and de-interlacing to the mix and watch how many codecs will choke.

There is a bit of misunderstanding in your logic. If the source is decompressed to the same image bit for bit, it doesn't matter what the codec is. When you feed it to the encoder , the encoder "sees" the same image. It doesn't matter if a source is a "more compressed" or "less compressed" format, what matters is the actual quality of original source

Resizing is realistic, as I said earlier you should define rules like no preprocessing e.g. sharpening, and use a consistent resizing algorithm, or you have no idea what you are testing. This is basic scientific method 101, reduce the variables to the one you are testing. Just like your choice of deinterlacers has a huge impact, if you're not consistent in your testing , your methods are not transparent, and your results not reproducible, your results are meaningless...

I think our defintions of "good quality" are very different. I would disagree that "taxi3" is a high quality clip. There's is pixellation already in the source. It's 1920x1080 @ 8Mbps 24p , doesn't exactly scream quality...

[jagabo]

I agree with poisondeathray -- if you want to test encoders you should eliminate all the other variables. No resizing, no deblocking, etc.

[deadrats]

There is a bit of misunderstanding in your logic. If the source is decompressed to the same image bit for bit, it doesn't matter what the codec is. When you feed it to the encoder , the encoder "sees" the same image. It doesn't matter if a source is a "more compressed" or "less compressed" format, what matters is the actual quality of original source

the problem is that no 2 codecs COmpress and DECompress to the same image bit for bit, if they did then there wouldn't be any need for this test nor would there be any difference in encode and play back quality between different codecs.

furthermore, regarding source compression, it matters a bunch whether the source is more or less compressed, if we start with source that has no compression or uses lossless compression then we will get the highest quality encode because none of the data has been discarded, if we go with mpeg-2, because it uses a less efficient encoding algorithm, less data is discarded during it's creation and thus we have a source with more of the original data present.

as we move up the compression scale we find that less and less of the original data remains and thus starting with that as our source means that we have less of the original data, as compared to mpeg-2, for us to play with.

that is why if we start with a 720x480 xvid at 3mb/s and try to transcode it to a 3mb/s 720x480 mpeg-2 the results are almost always crappy, requiring filters to tray and get good results.

i'll take it one step further, i assume you know what GOP stands for (no, not the Grand Old Party, the Group of Pictures), the maximum number of frames for an NTSC complaint mpeg-2's GOP is 18, and said frames are I, B, and P, where I frames are reference frames that contain all available information and can stand alone, P frames contain only the motion compensated difference between the previous I or P frame and B frames are bi-directional frames that contain the difference between the preceding and following I or P frames.

if we had the choice between using an mpeg-2 that was composed entirely of I frames or something like BBIBBPBBPBBPBBPBBP, and assuming enough bit rate had been used to encode the I frame only mpeg-2, we would be infinitely better of using the I frame only source because it had undergone the lesser amount of compression and thus was closer representation of the original source.

Resizing is realistic, as I said earlier you should define rules like no preprocessing e.g. sharpening, and use a consistent resizing algorithm, or you have no idea what you are testing. This is basic scientific method 101, reduce the variables to the one you are testing. Just like your choice of deinterlacers has a huge impact, if you're not consistent in your testing , your methods are not transparent, and your results not reproducible, your results are meaningless...

i almost chuckled when i read the above. i believe i may have mentioned once or couple hundred times that one of my majors in college was physics, as such i am quite familiar with the scientific method, i also have more than a passing understanding of the mathematics behind "the scientific method", in a nutshell it is, for all practical purposes, impossible to eliminate all the variables until you are left with only one test variable, under all but the most simplistic of tests. life isn't defined be single variable linear equations and video encoding algorithms aren't governed by them either.

I think our defintions of "good quality" are very different. I would disagree that "taxi3" is a high quality clip. There's is pixellation already in the source. It's 1920x1080 @ 8Mbps 24p , doesn't exactly scream quality...

ok, then you choose the source that you consider high quality and also choose the parameters of the test.

[jagabo]

Someone take the originally suggested MPEG 2 file (tack my Belle Nuit video onto the end), convert to YUY2, reduce the frame size by half to 960x544 (both mod 16), compress as HuffYUV or Lagarith AVI. That will give about a 200 MB file that can be posted at one of the file transfer sites for everybody to download. Just about every program should be able to handle that as input. It's easy enough to download and install the HuffYUV or Lagarith codec if necessary.

[poisondeathray]

Great, we're on the same page.... sort of

furthermore, regarding source compression, it matters a bunch whether the source is more or less compressed, if we start with source that has no compression or uses lossless compression then we will get the highest quality encode because none of the data has been discarded, if we go with mpeg-2, because it uses a less efficient encoding algorithm, less data is discarded during it's creation and thus we have a source with more of the original data present.

MPEG2 is more lossy with more artifacts than say xvid, or avc. AVC is more compressed and has higher PSNR values at the same bitrate. If you had original source=> MPEG2 @ 8Mbps vs. AVC @ 8Mbps which do you think would have more "quality?" and fewer artifacts? Which one is "more compressed"? e.g. If you had a 50Mbps MPEG2 , but the source was a 16 year old noise vhs transfer would it look good? Even a lossless transfer of a POS is still a POS. My point is the the quality of the input source matters (i.e. the quality of each frame fed to the encoder), more than the source format, eg. choosing say an MPEG2 source vs. something else.

The problem I have with the 8-10Mbps sequence like apple trailers, wmv hd - while they look good, the fine details are gone due to the compression.

are you ok with raw yuv sequences?

if so, the classic parkrun sequence (which many codec testers, universites and developers use for testing), is probably a good one to test, because it's quite taxing for encoders. The 1080p sequence is huge ~1.4GB for 504 frames, so maybe the 720p50 is better for this mini test (still ~700MB)

http://media.xiph.org/ldv/pub/test_sequences/720p/720p50_parkrun_ter.yuv

another classic one is the touhou sequence which is a lossless h.264 of an arcade style video game. This is a very very taxing encode, again very popular in codec testing. It's 640x480 60p 40Mbps lossless h.264 (~130MB)

http://mirror05.x264.nl/Dark/force.php?file=./LosslessTouhou.mkv

Other commonly used, publically available sources would be CGI animation like Elephant's Tale, and Big Buck Bunny, all which have lossless TGA or YUV sequences free for download. We'd have to decide on the specific frame sequence(s) to use. I'm not sure if you are interested in CGI animation for a test sequence...

http://orange.blender.org/blog/original-lossless-source-available/
http://media.xiph.org/BBB/

The problem with the above suggestions are that they are less representative of "hollywood" style movies, but do tend to show deficiencies in encoders better because they are all lossless and/or raw original data compared to re-encoded blu-ray or trailers.

I recently used a 1080i30 Planet Earth Trailer (~115MB, 1740frames) for testing in another thread, which is a 15Mbps AVC, decent quality source. The problems for your mini test are it's interlaced (would have to set consistent deinterlacing algorithms and/or resizing algorithms and/or source filters or procedures)

http://www.sendspace.com/file/cr48oe

[deadrats]

@poisondeathray

the park run sequence is fine by me, i was going to say the PNG losslessly compressed 1920x1080 but then i realized that just the torrent file is 2.2mb so i can only imagine how big the actual file is.

hopefully none of the apps i plan on testing with will choke on it...

i assume no resizing, no filters, max quality settings, and 3000 kb/s, is that good for you? yes, i know at 720p we should be lots more bit rate but if the bit rate is too high then all the encoders will produce good quality and there won't be as much separation.

so, is 3000 kb/s, constant bit rate good with you?

[poisondeathray]

it's a raw yuv file, are you ok with that? the reason I ask is many encoders won't accept it natively (or any raw sources)...and most will choke. You could use rawsource() in avisynth for example

and you mean 3000kbps average bitrate right? not "constant bit rate" ? I know from experience (I've looked at all these clips before), that is quite low for this clip but it would show the difference more dramatically. Technically you should be doing multiple encodes at different bitrate ranges, but I know it's just a mini test

[johns0]

I wouldn't agree with many people here saying 4000kb isn't good for very many sources, I would say it's good for almost all. Why sacrifice time vs quality that makes no sense to me (If you decided to use H264, use x264 for christ sakes and learn them encoder options).

Try encoding a very fast moving scene with high details in 4000kbps cbr then you will see why its best to use 4000 vbr,with very slow moving movies with no action then 4000kbps might suffice.

[deadrats]

it's a raw yuv file, are you ok with that? the reason I ask is many encoders won't accept it natively (or any raw sources)...and most will choke. You could use rawsource() in avisynth for example

and you mean 3000kbps average bitrate right? not "constant bit rate" ? I know from experience (I've looked at all these clips before), that is quite low for this clip but it would show the difference more dramatically. Technically you should be doing multiple encodes at different bitrate ranges, but I know it's just a mini test

the problem is that i plan on testing with numerous apps, like mpeg streamclip and badaboom and they don't accept avisynth scripts as a source file.

i think we may have to simply take jagabo's advice...

[poisondeathray]

deadrats - ok give me a few days and I whip something up like a lagarith encode with the test chart - it might be big in filesize - but I'll try to keep it reasonable. I think you can get ~2-3x compression is possible the raw yuv sequences. I'd prefer not to resize or use the initial test clip

[jagabo]

You don't really need to have HD frame sizes to test the encoders. Just use smaller frames and lower bitrates. The issues will be the same.

If you want to use the parkrun YUV clips that won't work with AviSynth scripts you can encode them losslessly into an AVI file with VirtualDub in Fast Recompress mode and Lagarith in YV12 mode.

A quick test encode with Lagarith at the original frame size came out at 422 MB. The AviSynth script to read the source was:

RawSource("720p50_parkrun_ter.yuv", width=1280, height=720, pixel_type="YV12")

There were a few blank gray frames at the start and end. Trimming those away left 414 MB.

[poisondeathray]

You don't really need to have HD frame sizes to test the encoders. Just use smaller frames and lower bitrates. The issues will be the same.

If you want to use the parkrun YUV clips you can encode them losslessly into an AVI file with VirtualDub in Fast Recompress mode and Lagarith in YV12 mode.

Yep, that's mostly true, the difference on the smaller dimension clips is often the grain and fine detail gets squashed and isn't evident even on the lossless resized input compared to it's HD counterpart

I've actually tested all these clips on various encoders /settings/frame sizes/ bitrates. I'm pretty confident that I know what the results will be. I think I've posted a few comparisons in this forum before

I'm happy just using a set .avs script for everyone to generate their own lagarith encode as input, but not everyone is comfortable with avisynth

It might be a bug on my system, but I had to use I420 as the pixel type, as for some reason the colors were inverted using YV12. Jagabo are you seeing the same thing?

RAWSource("720p50_parkrun_ter.yuv",width=1280,heig ht=720,pixel_type="I420")

And here's another classic clip that we both were looking for jagabo a while back for deinterlace testing, the "stockholm" clip
http://media.xiph.org/ldv/pub/test_sequences/1080i/1080i25_stockholm_ter.yuv

[jagabo]

the difference on the smaller dimension clips is often the grain and fine detail gets squashed and isn't evident even on the lossless resized input compared to it's HD counterpart

You can always use crops instead of resizing.

I've actually tested all these clips on various encoders /settings/frame sizes/ bitrates. I'm pretty confident that I know what the results will be.

I haven't done any test but I'm pretty sure I know what the results are going to be too!

And here's one clip that we both were looking for jagabo a while back for deinterlace testing, the "stockholm" clip
http://media.xiph.org/ldv/pub/test_sequences/1080i/1080i25_stockholm_ter.yuv

My hero! Downloading now.

It might be a bug on my system, but I had to use I420 as the pixel type, as for some reason the colors were inverted using YV12. Jagabo are you seeing the same thing?

RAWSource("720p50_parkrun_ter.yuv",width=1280,heig ht=720,pixel_type="I420")

YV12 and I420 both look weird. But I420 looks closer. The snow(?) is bluish but that's better than pink! I guess it's a matter of whether you like pink snow or blue snow!

The biggest problem with the parkrun video is that there's no dark areas. On the other hand the earlier MPEG 2 file was mostly sepia tones. But at least it had a wider variety of shots.

[poisondeathray]

The biggest problem with the parkrun video is that there's no dark areas. On the other hand the earlier MPEG 2 file was mostly sepia tones. But at least it had a wider variety of shots.

Indeed, dark areas are exactly where encoders without VAQ tend to be very weak.

I only suggested "parkrun" because it's one of those classic clips used in published (and unpublished) reviews

But it's going to be hard to find a suitable test clip that has everything represented, which is why several test clips are usually used from different genres/sources on larger scale testing

Any other ideas?

[jagabo]

deadrats' original MPEG 2 recommendation (including my 1 second Belle Nuit chart) was about 135 MB converted to YUY2, shrunken to 960x544 (LanczosResize), and compressed with Lagarith (YUY2 mode) in AVI .

[poisondeathray]

deadrats' original MPEG 2 recommendation (including my 1 second Belle Nuit chart) was about 135 MB converted to YUY2, shrunken to 960x544 (LanczosResize), and compressed with Lagarith (YUY2 mode) in AVI .

Sounds suitable for this little test.

This is probably too big for most folks, but Ben Waggoner (Doom9 mod) obtained permission from Dreamworks to post the studio version of The Island trailer for testing. It's a better sample in terms of film grain & detail and what you would typically find on the better blu-ray transfers. This would more clearly separate better encoders from worse encoders. It's what Apple would use to encode their trailers. Unfortunately it's a huge lagarith file, there are 45x50Mb pieces you can put together with hjsplit.
http://cid-bee3c9ac9541c85b.skydrive.live.com/browse.aspx/.Public/The%20Island%20Trailer

[jagabo]

Another thing I don't like about trailers is the quick shots. It's hard to see anything with 1/2 second long shots, except for loss of details in still frames. But with still frames you miss the creepy crawly posterization artifacts that can only be seen in animated shots.

But if you guys want, I'll upload the Vote trailer so you can start testing.