I have a WDTV Live. When it originally came out it had a problem with colorimetry but I forget exactly what it was. Eventually an updated firmware did the most sensible thing: If the colorimetry is flagged it obeys the flag. If it's not flagged it defaults to rec.601 for SD, rec.709 for HD. I don't recall exactly what resolution is the point at which it changes.
Try StreamFab Downloader and download from Netflix, Amazon, Youtube! Or Try DVDFab and copy Blu-rays! or rip iTunes movies!
+ Reply to Thread
Results 91 to 114 of 114
Thread
-
-
I just got around to reading the thread in question. I assume you didn't read it all given you used it as an example of another poster finding CRF inferior to 2 pass, but Makaveli84 said himself:
"Anyways, CRF is more than suitable most of the time, but in some cases, when editing and applying effects on videos, I'd like to achieve the best possible quality, even for single frames.
But even for that, I am unconvinced that 2-pass always yields better quality."
http://forum.doom9.org/showpost.php?p=1590055&postcount=29
Personally it sounds to me more like Makaveli84 was doing the frame by frame comparison thing and seeing the small compression differences we all do. -
Yes. He does go on to say in the same post that he can see a difference at normal playback speed too, but only after 'tuning' himself to spot it in frame-by-frame viewing, so his case is probably different from mine where the differences are blatantly obvious (to me anyway) at normal playback speed, with CRF needing to produce a significantly larger file than 2-pass to reach the same level of transparency when going apples-for-apples with all other settings being equal when using MeGUI.
As there's nothing I can do here to fix the problem (changing GUIs or x264 versions makes no difference), I've given up for now anyway. I'll run the exact same test on the i5 laptop I have occasional access to next time it's available to see if it's a CPU-specific problem, although I'll have to bring the files home with me to check them on this decent monitor as the diabolical panel accompanied by the awful Intel HD graphics implementation on the lappy manages to hide pretty much everything. -
I have noticed that some h.264 decoders are better than others. On my Core i5 system I get very ugly artifacts (deblocking isn't working correctly, obvious keyframe pumping) with DXVA decoding by MPCHC's internal h.264 DXVA decoder, even with sources that are easily within DXVA specs. It happens with both CRF and 2-pass encodings. If anything, the artifacts are worse with 2-pass. When using CoreAVC's DXVA decoding, or with software decoding, the video is much cleaner.
-
And I'm finding, though I may be wrong (h.264 settings and all, I'm no expert there), that if you really want small file size xvid may actually be better. It's kind of "softer edged", if that's the right expression. Maybe not technically better but more forgiving of problems / artifacts you get with low bit rate.
-
No, x264 is better than Xvid at small sizes (low bitrates). Especially since most Xvid/Divx decoders don't deblock.
-
Like I said, I could be wrong. I really don't know all the options.
-
What differences are you seeing in video playback? The popular free media players (and ffdshow) all seem to use libavcodec as their decoding engine, or they're based on ffmpeg.
I'm not saying some players don't work better than others. I'm just wondering what makes mplayer better. I couldn't find any definite info on it. Does smplayer support DXVA? -
I asked a while back but you never said which CPU you're using.
If you've got some samples you can upload of CRF vs 2 pass using MeGUI, including the source, I'd be keen to have a look. Plus if you can upload a section of the source video and the samples were encoded using MeGUI's default settings, it shouldn't be too hard for me to run the same encodes to see if I get the same results at the same CRF value and 2 pass bitrate. That's something we've still not done..... run the same encodes using the same source to see if we get the same results. If I'm still not seeing quality differences I can then upload my encodes of the samples to see if you still do.
I still have your CRF25 vs 2 pass samples on my hard drive (the Firefly encodes) and with a fresh look 2 pass is definitely a little better, but we're still talking about an average bitrate difference of 120Kbps for a 15 second video, which is nothing to be ignored. I'm not sure I could see any differences if I disabled DXVA.
While I don't have the source to compare them to it does appear to me your 1333Kbps 2 pass MediaCoder preset did a pretty average job of it anyway. I'd be intereset to see what the same section of video would look like encoded using CRF 20 or CRF 18 and what sort of bitrates you'd end up with, because the 2 pass encode isn't anything I'd be overly excited about. Hopefully it's just a result of using a poor quality source rather than the 2 pass encode being poor quality.
That's something else looking at your samples made me ponder over when it comes to using a one size fits all average bitrate. If you were to encode a video using your preset, the bits would be shared around where they're needed etc, but what if you split the video in two and encoded each half the same way? And what if the first half was full of static scenes while the second full of action? Wouldn't using the same average bitrate each time cause the video as a whole to be compressed differently to how it'd be compressed if you encoded it one half at a time?
Anyway, if you've got a sample we can both use as a source for encoding......
Is that Firefly DVD interlaced or progressive? Because I'd be thinking seriously about looking at the de-interlacing being used as it seems to be reasonably awful. Lots of jagged lines where there shouldn't be any. The Captain's shirt color is generally the most obvious example.Last edited by hello_hello; 16th Sep 2012 at 18:38.
-
It just occurred to me (after reading your post) I was involved in a similar discussion at doom9 a fair while back. The person with the encoding problem was complaining about artifacts in one particular scene and uploaded a sample of the source. If memory serves me correctly I ran a couple of encodes and uploaded a few screenshots. As a result the original poster changed media players and the problem went away.
I'll have to try to find the thread later as I can't remember which player they were using originally (it was quite a while ago), although I think they switched to MPC-HC, but issues caused by playback probably shouldn't be dismissed. Mind you if CRF and 2 pass are basically the same quality wise, you'd assume if a player makes a mess of one it'd make a similar mess of the other, but I guess anything's possible. If DXVA is being used, disabling it and comparing how video looks on playback might be one place to start. -
I decided to upload a few samples. This is from the tests I mentioned earlier where I took a full Blu-ray rip, trimmed out a 5000 frame section, Cropped black borders, reduced the frame size to 1280x544, and saved as lossless Lagarith AVI (YV12). That gave me a high quality source to start with.
First a decent quality encoding about like I would normally make:
Code:x264.exe --preset=slow --keyint=250 --ref=4 --bframes=3 --crf=18 --aq-mode=2 --aq-strength=1.8 --sar=1:1 --output x264-crf18.mkv lag.avs
Code:x264.exe --preset=slow --crf=25 --psy-rd 1.0:0.2 --output x264-crf25.mkv lag.avs
Code:x264.exe --preset=slow --psy-rd=1.0:0.2 --pass=1 --output x264-2pass.mkv lag.avs x264.exe --preset=slow --psy-rd=1.0:0.2 --pass=2 --bitrate=880 --output x264-2pass.mkv lag.avs
-
Well I haven't had a chance for a serious look yet, but after a few quick runs.....
Xvid: Obviously a disaster in places.
CRF18: It looked very good. I could see a few things in the earlier, harder to compress scenes where I wondered if I was seeing the results of compression but only minor things, and not having seen the source it's hard to know what's been introduced due to encoding.
CRF25 & 2 pass: Well I'm going to go out on a limb here and say watching the video I think CRF looks better. I'll have to come back to those ones but a few quick plays gave me the impression the CRF version was more "fluid". I can't put my finger on it yet as stopping on a few identical frames I wasn't seeing huge differences, but when the videos were playing I think the CRF version had less (what I call) compression "wobble" and for some reason the blocking seemed less obvious than it was when watching the 2 pass encode. As I said that's more a first impression than anything else. I'll definitely revisit those two. I might find some audio to mux into them so reclock can do it's thing so I know it's not the frame rate effecting the "fluidity".
Slipster's psy-rd settings aren't far from the defaults. Is the difference noticeable? On the other hand, you certainly give aq-strength a fairly decent nudge. -
When I examine them frame-by-frame I can see differences but sometimes one looks better, sometimes the other. The same is true with realtime playback. In the end, the results are close enough that I wouldn't worry about it and just use CRF because it's faster and I know what the quality will be before I encode.
I don't know exactly how all MediaCoder's settings translate into x264 switches. For example, Slipsters' link showed:
Code:<node key="videoenc.x264.aq_strength">Strong</node>
You can use MediaInfo to see all the individual x264 options used during the encoding. Unfortunately, Slipster never posted any video samples.
That particular video has a lot of noise in the dark shots. The high aq-strength helps retain that noise and prevent obvious posterization artifacts in those shots. It costs more bitrate (in CRF encoding) though -- 40 percent more in this clip.
When I compare videos frame-by-frame I usually use a script like this:
Code:v0=AviSource("lag.avs").Subtitle("source") v1=ffVideoSource("x264-crf18.mkv").Subtitle("crf") v2=ffVideoSource("x264-2pass.mkv").Subtitle("2pass") Interleave(v0,v1,v2,v0)
-
I'd agree the CRF25 encode and the 2 pass encode are pretty much the same quality, and even if you could pick one over the other realistically it's probably irrelevant given you're not going to encode using that high a CRF value. I wouldn't anyway. There was something about the CRF version though.... I haven't got back to them yet so maybe my eyes were just playing tricks.
Slipster did post a couple of samples earlier on. His encoder settings are below.
Best as I could work out at the time, his preset is pretty much the x264 defaults, using Preset Slower and Tune Film. I'm fairly sure using Tune Film changes Psy-trellis strength to 0.15, Tune Grain takes it to 0.25, so I guess his Psy-trellis of 0.2 sits on the fence between them. Aside from that I'm not sure if I found any other differences, although I didn't look super hard, but now you've mentioned it I checked and it seems he's almost with you on AQ "--aq-mode=2 --aq-strength=1.5". I get when using CRF encoding, increasing --aq-strength potentially increases the bitrate by a fair degree, I'm just not sure what effect it'd have when you're using a fixed average bitrate.
From his sample:
Code:x264 core 125 r2208 d9d2288 Encoding settings : cabac=1 / ref=8 / deblock=1:-1:-1 / analyse=0x3:0x133 / me=umh / subme=10 / psy=1 / psy_rd=1.00:0.20 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-3 / threads=3 / lookahead_threads=1 / sliced_threads=0 / nr=100 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=8 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=50 / intra_refresh=0 / rc_lookahead=60 / rc=abr / mbtree=1 / bitrate=1333 / ratetol=1.0 / qcomp=0.70 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=5000 / vbv_bufsize=5000 / nal_hrd=none / ip_ratio=1.40 / aq=2:1.50
-
This is more like --preset very slow --ref 8 --deblock -1:-1 --scenecut 50 --vbv-maxrate 5000 --vbv-bufsize 5000 --psy-rd 1:0.2 --aq-mode 2 --aq-strength 1.5
(because subme is 10, merange is 24, bframes 8 , this suggests "very slow")
What stands out here is 1pass ABR , nr=100
IMO, the nr is questionable - for lowish bitrate encodes it can be helpful, but I think you would get better results controlling the nr with filtering
1pass ABR? I though this was a 2pass vs. CRF thread ?? or maybe this was from another test ?
I get when using CRF encoding, increasing --aq-strength potentially increases the bitrate by a fair degree, I'm just not sure what effect it'd have when you're using a fixed average bitrate.
But using higher aq strengths will take bits away from edges. If bitrate is constrained (such as when you use 1pass ABR, 2pass bitrate or CRF with VBV constraints) , then you will notice deterioration in those areas. Edges will look more ratty and you will see artifacts there. So it's basically a trade off and a balancing act . Yes, you will improve things like dark areas, gradients, but other areas will look worse . With unconstrained CRF encoding, the bitrate balloons up to compensateLast edited by poisondeathray; 17th Sep 2012 at 10:25.
-
Yeah, you're right. I guess I remembered fairly not right.
What stands out for me is the "original noise as part of the source is part of the source" lecture I was given at one stage. Had I noticed the nr setting at the time......
I missed that too. Of course I can't check the post as it's been deleted, but I thought the two encodes at the time were CRF25 vs 2 pass, but maybe he switched to ABR instead without telling.... I guess he must have. The actual name of the file Slipster uploaded, and from which the encoder settings came, is "VTS_01_2-2-pass1333.mkv". Does that mean he cheated?
I'm pretty sure I can see the ratty edges effect in the samples Slipster uploaded. I put most of it down to crappy de-interlacing (I mentioned that a few posts ago), but now I'm not so sure. -
I don' t know, it seems some posts were deleted
Here's an idea - why don't you just do some more tests instead of going on a "witch hunt"
Since nobody seems to know what mediacoder is doing (in terms of preprocessing) and how commands are passsed since there is no log - it shouldn't really be used for testing purposes IMO. Unless you know EXACTLY what it's doing, the results cannot be generalized to make conclusions or fuel hypothesis on what x264 is doing - There are too many confounding variables
(There are other reasons to avoid mediacoder, but they are more "political" - it violates GPL and distributes some things "illegally"has been placed on the ffmpeg "hall of shame", and does other things like "calling home")
If you don't want to use the CLI - Megui is fine, because a log is generated and it lists everything that's passed, even pre-processing steps like avisynth scripts and filters . As long as your process is transparent, documented and repeatable then that helps with the validity of the testingLast edited by poisondeathray; 17th Sep 2012 at 11:06.
-
Maybe it wouldn't be seen as a witch hunt if one of the original participants was still participating and hadn't deleted most of his posts, but jagabo and I both ran further tests of our own a few days ago. See post #74 for mine. jagabo provided links to his latest test encodes a few posts ago. The rest is a continuation of the discussion, some of which involves particular x264 settings recommended by someone who uploaded samples (now deleted) and who happens to use MediaCoder.
-
As invariably happens I now found myself confused by the world......
I was just playing around with some of x264's options in view of running a few test encodes myself, but there's one thing I haven't quite got my head around. According to MeGUI's x264 configuration (and after running a couple of quick test encodes and looking at the encoder settings it seems correct):
Default: deblock=1:0:0, psy_rd=1.00:0.00, aq=1:1.00
Tune Film: deblock=1:-1:-1, psy_rd=1.00:0.15, aq=1:1.00
Tune Animation: deblock=1:1:1, psy_rd=0.40:0.00, aq=1:0.60
Tune Grain: deblock=1:-2:-2, psy_rd=1.00:0.25, aq=1:0.50, no-dct-decimate
If aq-strength helps retain noise etc (and I'm not saying it doesn't) what's the logic behind "Tune Grain" decreasing it rather than increasing it? As "Tune Animation" decreases aq-strength by an almost identical amount it seems counter-intuitive to me, given I assume the objective of "Tune Grain" is pretty much to retain noise.
no-dct-decimate? Have you experimented with it? I'm going to run a few test encodes myself using the default Tune presets and then with adjusting aq-strength manually so I'll be interested to see what the differences are. -
-
Your settings are normally dependent on your crf range or bitrate range. Someone put a hypothesis that the percieved 2pass better quality observations were more easily observed in lower bitrate/ higher quantizer ranges
For example, if the goal was lower bitate encodes (e.g. crf 25-26 something like that ) it wouldn't make sense to use grain retaining settings (and you wouldn't do that in real life either). It would actually make more sense as an encoding strategy to denoise, improve compressibility . Obviously a noisy or grainy source will be impossible to compress with high quantizers
no-dct-decimate? Have you experimented with it? I'm going to run a few test encodes myself using the default Tune presets and then with adjusting aq-strength manually so I'll be interested to see what the differences are. -
I ran some comparison encodes using a source video (720p) which is quite high quality and has some fine background noise (film grain?). CRF18 (2.5 minute) encodes using the veryslow speed preset. I really need to upgrade this PC if I'm going to be using slower encoder settings. Plodding along at around 5fps isn't fun.
The section of video in question wouldn't be overly hard to compress as such. I was just interested to see what would happen to the fine noise. No resizing or filtering etc involved. And for Slipster.... I compared them using the HDMI connected PC.
(The first two as a quality starting point)
CRF16, Medium: 124.0MB
CRF16, VerySlow: 118.8MB
All CRF18, VerySlow
Defaults: 73.2MB
Deblock -3:-3: 74.9MB
Psy-Trellis Strength 0.20: 84.7MB
AQ mode 1, AQ Strength 1.8: 124.5MB
AQ mode 2, AQ Strength 1.8: 125.4MB
Psy-Trellis Strength 0.20, AQ mode 2, AQ Strength 1.8: 137.0MB
Tune Film (includes Psy-Trellis Strength 0.15): 82.9MB
Tune Film, AQ mode 2, AQ Strength 1.8: 134.9MB
Tune Grain (includes Psy-Trellis Strength 0.25): 102.4MB
Tune Grain, AQ mode 2, AQ Strength 1.8: 183.3MB
Seems to disprove my previous assumption it's the deblock setting which increases the file size when using Tune Film/Grain. I guess the resulting increase in Psy-Trellis Strength is responsible for most of it.
CRF16 medium speed preset and CRF16 veryslow would probably require bionic eyes to pick which is which. The differences between CRF16 medium & CRF18 veryslow (defaults) were fairly minor, even frame by frame. I had to compare them to the source to pick which was "better". Naturally CRF16 was. Often I couldn't see anything but tiny differences between CRF16 and the source video, even in the background noise.
To actually start looking more closely I had to switch MPC-HC to a sharper resizer. Then I compared the source video very closely to three encodes and I'd rate them for accuracy in this order:
CRF16, medium speed (blurred some of the fine detail by a very, very, very, very tiny amount) 124.0MB
CRF18, veryslow, AQ mode 2, AQ Strength 1.8 ("sharpened" some of the noise by a very, very, very, very tiny amount) 125.4MB
CRF18, veryslow, Tune Grain, AQ mode 2, AQ Strength 1.8 (most of the time when comparing this to the source frame by frame I virtually couldn't tell them apart) 183.3MB
So after all that if I was to pick an encoding method for this video it'd be either CRF16 or CRF18 using x264's defaults, or maybe CRF18 with Tune Film (I haven't compared every encode pixel for pixel yet). Compared to CRF16, "CRF18, AQ mode 2, AQ Strength 1.8" produced an almost identical file size with the former blurring some fine detail ever so slightly, and the second sharpening it ever so slightly. Adding Tune Grain to the mix seemed to result in the most accurate encode, but not worth the 50% file size increase (or around 2.5x compared to CRF18 defaults). I'd probably defy anyone to pick which of these encodes was which at normal viewing distance anyway. This was sit close to the TV, use a sharper resizer, nitpick over very minor differences stuff. And I can't emphasis that enough. These were frame by frame, almost pixel by pixel comparisons.
If there's any weird CRF encoding anomalies going on I'm definitely not seeing them. For me, a low enough CRF value produces an encode which is almost identical to the source, no matter which frame I look at.
Next encoding tests..... probably not for a day or so because I still want to look at some of today's encodes more closely and I've been staring at the TV for so long now I have no idea what I'm looking at any more.... I'll pick something hard to compress and maybe the results will be different.
I'll be interested to see when it comes to harder to compress video, if encoder "tweaking" in preference to using a lower CRF value will scale to a similar degree as far as file sizes go. One of the arguments for tweaking instead of using a lower CRF value is over an entire encode it won't effect the over-all file size as much etc, but given the source video I used wouldn't be hard to compress I'm fairly skeptical.Last edited by hello_hello; 19th Sep 2012 at 15:14.
-
I'd possibly be willing to consider that's not an impossible hypothesis.
Agreed.
I forgot to throw it into my encoding mix. At this point, I'm more than happy to take your word for it anyway. I'm fairly over staring at the TV screen from a few feet away at the moment.
Similar Threads
-
Question about Bit Rate and Quality
By T375 in forum Newbie / General discussionsReplies: 4Last Post: 20th Sep 2010, 09:31 -
Bit Rate Vs Quality
By kashif71 in forum Video ConversionReplies: 20Last Post: 21st May 2010, 00:19 -
How to achieve the maximum bit rate in variable bit rate mode ?
By Sxn in forum Newbie / General discussionsReplies: 42Last Post: 3rd Dec 2009, 12:53 -
Which video format has the best about everything ( quality, bit rate...) !?
By coxanhvn in forum Newbie / General discussionsReplies: 17Last Post: 3rd Sep 2008, 21:02 -
Is higher bit rate = better quality??
By imdaman in forum DVD RippingReplies: 5Last Post: 13th Sep 2007, 07:37