Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
13th January 2011, 01:36 | #221 | Link | |
Banned
Join Date: Oct 2010
Posts: 119
|
Quote:
yes, some studios and directors use a soft lens, but some studios shoot exclusively with sony's RED, i have a 720p encode of "the devil in misses jones, resurrected" that is so clear you would think you are standing there as it's being shot. feel free to download the japanese version of the software, and if you can figure out how to use it, conduct your own tests: http://tmpgenc.pegasys-inc.com/ja/product/tvmw5.html |
|
13th January 2011, 01:39 | #222 | Link | |
Registered User
Join Date: Nov 2007
Posts: 240
|
Quote:
|
|
13th January 2011, 01:46 | #223 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
And if you don't agree with the guy doesn't mean you have to attack him. Try to be a better person, even though he might not be. Present your evidence in a more scientific objective manner and you will be more convicing than you have been thus far. Quote:
As mentioned there were problems with - the settings used (CBR?, main profile? ) - other filters (you're testing ENCODERS, don't complicate matters by testing resizing or audio) . Mug Funky had a good suggestion, just use x264.exe - source quality. Here people are mentioning blu-ray this , blu-ray that, but a 8Mb/s 1080p source isn't going to test much. Your average retail blu-ray would be ~20-30Mb/s - ideally, a range of bitrate encodes and different settings would be tested (so you could test max quality, or speed at a given quality etc...) . People have different requirements. Some people want every single bit of compression or top quality at any speed. Some people want speed over quality etc.... At least it's better than Anandtech's single frame resized screenshot. Thanks for sharing the results so far |
||
13th January 2011, 01:51 | #225 | Link | |||
Registered User
Join Date: Dec 2005
Posts: 1,460
|
Quote:
Quote:
Quote:
As I have stated with my preferred settings my 720p encodes from Blu Ray usually come out smaller than 4 Mbps. I arrived at my settings by testing the presets to figure out what speed I'm comfortable with and then selected a CRF that delivers adequate quality with those settings. With my settings details are kept well and I do not notice artifacts at all during normal viewing. You might have a different opinion on what constitutes adequate quality or encoding speed, but have no justification to call other people retards because of their choices on something that essentially comes down to personal preference. By the way, the source you selected was itself encoded with x264 (r1292). While the encode isn't too bad, there is some blocking which isn't surprising since a high detail underwater shot is a complex source to begin with. If you want a high detail uncompressed source Parkjoy is always nice. Last edited by nurbs; 13th January 2011 at 01:53. |
|||
13th January 2011, 01:57 | #226 | Link | |
Registered User
Join Date: Mar 2005
Location: Finland
Posts: 2,641
|
Quote:
|
|
13th January 2011, 02:28 | #227 | Link | |
Banned
Join Date: Oct 2010
Posts: 119
|
Quote:
it drives me up the wall, it really does. as far as this test is concerned, yes, it's by no means conclusive or decisive, but choosing a front end package like tmpg express does allow for uniformity in testing: 1) it allows all 3 encoders to be used with the exact same resize filter, and down rezing is a very common approach when transcoding video, as people try to maximize final quality and/or target a particular device. 2) using the x264 encoder that comes with tmpg express is very valid because it's the first and only commercially licensed application of the encoder, it standardizes results by eliminating any inconsistencies introduced by compilation options, compiler used or modifications to the source or command line parameters introduced by the person building the executable. furthermore, it's the only version that puts a dime in DS pocket, it's the only one you have to pay for and thus it's the standard by which other versions should be compared. 3) it standardizes the decoder used, using a different front end would invariably result in using a different decoder, thus skewing the results. 4) when the english version is released i plan on doing extensive testing and posting the results. Last edited by deadrats; 13th January 2011 at 02:40. |
|
13th January 2011, 02:32 | #228 | Link | |
Banned
Join Date: Oct 2010
Posts: 119
|
Quote:
from a mathematical point of view, it's just plain silly. |
|
13th January 2011, 02:50 | #229 | Link | |||||
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
But what does that dismissing "that technology" have to do with "his software". They are different encoders included in the same GUI. Also, just because some commercial software decides to include an encoder (of any origin) , indicates nothing. You've stated this a couple times already, and I don't see the point you're trying to make Quote:
2nd just because some consumer grade software includes an encoder proves.... what ? For example , have you seen the "great quality" (I'm being sarcatic for non native english speakers here) of Sony Vegas AVC ? Just because a commercial software decides to include several encoders, do they all have to be good ? or all have to be bad? I don't see the relationship here? Quote:
This basic science 101. You cannot come to the conclusion that x encoder performs (such and such) when you start to include other variables. For example, there may be bottlenecks introduced. If you're doing this type of testing, your conclusions are only valid for that specific scenario. Be careful how you phrase you conclusion. Quote:
For example, TMPG converts to RGB for all encodes (at least older versions did), this results in slower encoding, lower quality than if you would have stayed in the same colorspace Quote:
|
|||||
13th January 2011, 02:59 | #230 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quote:
(Do I really need to post screens? Look at --just e.g.-- 0:38-0:45, the fish in the background. CUDA is truncating fishs into two halfs, and that sort of things!) Sidenote, not relevant, but ... the first time I played the first sample, when the first oceanground appeared on the screen, I immediately saw .... YADIF, or s'th with similar edge-interpolation, has been used to deinterlace the original recording. How can people use such deinterlacing and NOT notice the unnatural "vectorization" of textures...? :cry: :cry: :cry: @ deadrats Related to speed, may i ask what are the specifications of the PC you did the encodings with? It's a quadcore? Just wondering, you noted it took 13:35 for the x264 encode. I did an encode with Hybrid (which uses standard x264, resizing through mencoder, audio encoding via aften) on my i7-860 (@2.8=stock), with the same x264 settings as used by tmpgenc (derived from stream metadata). The whole process took 4:30. It doesn't matter for the relative speeds, from one encoder to the next. But the absolute speeds in your test seem to be somewhat (s)low...
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
|
13th January 2011, 03:05 | #231 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
He said AMD setup, but didn't say if it was overclocked or stock Quote:
|
||
13th January 2011, 03:22 | #232 | Link |
Banned
Join Date: Oct 2010
Posts: 119
|
just did 2 more test encodes, for source i replicated the very commonly used x264 hd benchmark found here:
http://www.techarp.com/showarticle.aspx?artno=520 i used the included mpeg-2 source, 30 sec duration, 3950 kb/s, 23.97fps, 720p, 384 kb/s audio and transcoded using both the x264 and the cuda encoder (again japanese version of tmpg express 5), ac3 audio 128 kb/s, mkv, 720p, 23.97, main, 4.1, 3950 kb/s (looked through the testing script, same bit rate, level and profile settings), x264 took 1:20 to finish the encode, cuda took 31 seconds, i for one see no difference between the two encodes: cuda http://www.mediafire.com/?evnfks434d28wij x264 http://www.mediafire.com/?n6gd0gqraadw2bn Last edited by deadrats; 13th January 2011 at 03:25. |
13th January 2011, 03:32 | #233 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
deadrats,
[edit] I wrote this before your latest post, havent even looked at the current test [/edit] Thanks for sharing your results. It looks like the defaults in TMPGEnc are quite poorly chosen. They're difficult to compare with because of the advertising it burns into the video while still in trial mode. I think any comparison at this point involving TMPGEnc is basically invalid because of this factor. Once they release the English version, maybe someone will buy it and we can have an honest look without their logo screwing up our compression tests By the way, 4mbps average is not "low bitrate" for 720p at all, in my opinion - especially if there are no obnoxious restrictions like short GOPs, tight VBV values / CBR etc. Sure, it may not produce results that are 100% transparent (for sources that actually require keeping 1080p for full details), but it can look QUITE good. 4mbps 1080p is more challenging, and should separate the wheat from the chaff when it comes to encoders! The source you chose is a bit suboptimal for testing in my opinion. As someone else mentioned, it was actually encoded by x264 originally! It also has some compression artifacts, though it's not HORRIBLE quality. Next time we do some testing with TMPGenc, hopefully some good challenging source will be chosen. Parkjoy has been mentioned several times, though honestly any good true BluRay source would be a good choice. Baraka is a personal favorite of mine, as is Avatar. Anyway, let's all not read too much into the test. I'd agree all those clips look pretty good. On a personal note, everyone please watch your tone. We don't tolerate personal attacks here. Rule 4: Be nice to each other and respect the moderator. Profanity and insults will not be tolerated. If you have a problem with another member turn to the respective moderator and if the moderator can't help you send a private message to Doom9. Everyone has their bias, but there's no "cult of x264". I'll admit I tend to be biased towards it, but that's only because I've literally never seen anything that can beat it. If something out there does a better job for a certain case, I'm all over it. Transcoding for sync is a very interesting goal. 1) Here, you don't REALLY care how big an output is, provided it's not TOOOOO big, since you will probably watch it once or twice then throw it away. 2) You DO want it to transcode as quickly as possible, and you DO want it to look good. 3) In x264 to achieve this goal when syncing for my iPhone, I use (for HP@3.1) --preset superfast --tune film --crf 18 --vbv-maxrate 17500 --vbv-bufsize 17500. Maybe ultrafast if I'm feeling masochistic. It's certainly possible to do this VERY quickly with a CUDA encoder. I'm sure with a 1080p H.264 source, the decode / scaling becomes the bottleneck rather quickly. Presumably x264 properly fed with a threaded decoder and scaler would run very quickly as well, by comparison. It's hard to say without having access to the proper software. We shall see! Derek
__________________
These are all my personal statements, not those of my employer :) |
13th January 2011, 03:44 | #234 | Link | |
x264
Join Date: Dec 2009
Location: Serbia
Posts: 50
|
Use stupid settings and make excuse like , tmpg express is in japanese ....
If u cant use tmpg in proper way then don`t do test like his becosue they tell nothing Quote:
Yea , big percent of sources is like 8mb/s +1 Last edited by weasel_; 13th January 2011 at 03:50. |
|
13th January 2011, 03:47 | #235 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Quote:
__________________
all my compares are riddles so please try to decipher them yourselves :) It is about Time Join the Revolution NOW before it is to Late ! http://forum.doom9.org/showthread.php?t=168004 Last edited by CruNcher; 13th January 2011 at 03:50. |
|
13th January 2011, 03:59 | #236 | Link |
Registered User
Join Date: Apr 2009
Posts: 478
|
Wake me up when TMPGenc v5 English is out. I might indeed be getting a Core i7-2600K and thus can give Quick Sync a whirl for all of you.
EDIT: Oh wait, I'm getting a P67 motherboard. So I can't use Quick Sync. Damn you Intel. What's wrong with you? |
13th January 2011, 04:11 | #237 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quote:
(Do the flip-flop!) no need to compare x264 with CUDA. However - if someone is concluding "CUDA and x264 look same good", then it makes me wonder ...
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
|
13th January 2011, 10:56 | #238 | Link | |
User of free A/V tools
Join Date: Jul 2006
Location: SK
Posts: 826
|
Quote:
deadrats is obviously right here: CUDA encoder is at least twice as good as x264 because everybody can see that there are twice as many fish in the background as they were in the source! Case closed, the winner had been picked objectively. |
|
14th January 2011, 00:48 | #239 | Link | |
Banned
Join Date: Oct 2010
Posts: 119
|
Quote:
what i did say was there was little to no perceptible difference quality wise and that if one was to use a sane bit rate any differences would disappear. considering SD dvd uses a video bit rate of 9800 kb/s (for professionally encoded dvd), with only 720x480 pixels per frame (yes, they use mpeg-2), using just 3.7 mb/s for 1280x720 pixels is absurd, as is using 8 mb/s for 1920x1080 pixels, i don't care what compression standard or encoder settings are used. consider this, if you bought a membership to a site that allowed you to download hd tv shows or movies (like an itunes) and you found out that their hd was 720p @ 3.7 mb/s, would you be happy? how about if you hired someone to professionally record your wedding or other similar event and supply BD to all the guests, and then you found out that the BD's were encoded at 4mb/s 720p or 8 mb/s 1080p and he said "oh, i encoded it with x264, so that's plenty of bit rate", would you pay him or force feed him the BD's? how about if you want to capture the super bowl, are you going to capture at the highest bit rate your capture card is capable of or are you going to use x264 and stick with 720p @ < 4 mb/s? as DS pointed out in his guide using too little bit rate and concluding that one encoder is better than another is stupid and counts as cheating. lastly, i noticed no one commented on the media sdk encode, which is ultimately the topic of this thread and comparison. |
|
Tags |
media engine, x.264 |
Thread Tools | Search this Thread |
Display Modes | |
|
|