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...Originally Posted by PuzZLeR
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.
+ Reply to Thread
Results 31 to 60 of 203
-
-
Originally Posted by themaster1
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.Last edited by sanlyn; 22nd Mar 2014 at 03:35.
-
Originally Posted by jagabo
Originally Posted by manono -
Originally Posted by kazyn
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. -
Originally Posted by deadrats
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. -
Originally Posted by poisondeathray
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. -
-
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. -
Originally Posted by dphirschler
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.Read my blog here.
-
Originally Posted by jagabo
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. -
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.
Code:FFMpegSource2("test-720p.mpg") AssumeFPS(24000,1001) ColorMatrix("Rec.601->Rec.709")
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 -
Originally Posted by 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.
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. -
Originally Posted by deadrats
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... -
I agree with poisondeathray -- if you want to test encoders you should eliminate all the other variables. No resizing, no deblocking, etc.
-
Originally Posted by poisondeathray
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.
Originally Posted by poisondeathray
Originally Posted by poisondeathray -
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.
-
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.
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 -
@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? -
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 -
Originally Posted by kazynI think,therefore i am a hamster.
-
Originally Posted by poisondeathray
i think we may have to simply take jagabo's advice... -
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
-
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. -
Originally Posted by jagabo
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 -
Originally Posted by poisondeathray
Originally Posted by poisondeathray
Originally Posted by poisondeathray
Originally Posted by 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. -
Originally Posted by jagabo
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? -
Originally Posted by jagabo
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 -
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.
Similar Threads
-
High Quality Encoding AVI -> MPEG2
By vl0001 in forum MacReplies: 2Last Post: 21st Jan 2012, 08:40 -
Encoding WAV and M2V to AVI [high quality]
By duudo in forum Newbie / General discussionsReplies: 2Last Post: 28th Feb 2009, 05:57 -
Tutorial on encoding for YouTube high quality - feedback requested
By webvideopro in forum Video Streaming DownloadingReplies: 8Last Post: 24th Sep 2008, 08:19 -
h264 and xvid encoding for: near-lossless and high quality ?
By vhelp in forum Video ConversionReplies: 10Last Post: 14th Sep 2008, 15:31 -
Encoding RM to AVI (high Quality)
By hzgg2 in forum Video ConversionReplies: 2Last Post: 22nd Apr 2008, 14:11