View Full Version : x264 MKV's Look Horrible on New TV
hello_hello
26th January 2012, 22:27
Couldn't help myself. I ran a quick 720p encode on "Original File-001" using CRF20. I'm getting the same color banding as well. I tried it at 720p using Xvid. It produces the same banding, only worse.
Maybe someone should PM Dark Shikari to see if they can entice him back to the thread to take a look. It's definitely not something I've experienced in any of my encodes yet (least not that I've noticed) so maybe there's something peculiar to some types of video which the encoders don't like.
Edit: Also tried an encode of "Original File-003" and getting the same results as you are.
smok3
26th January 2012, 22:32
playing around with Original File-001:
10 bit 420 encode does look decent (regarding lack of blocking on dithered gradients), snap:
http://shrani.si/t/3U/Fi/jDWR6lZ/original-file-00110bit26.jpg (http://shrani.si/?3U/Fi/jDWR6lZ/original-file-00110bit26.png)
and download:
http://www.mediafire.com/?lm3obrj9eycnzio
i just used:
-preset medium -tune film -crf 21 -threads 0
But of course that wont play everywhere. Btw, are "tune" modes working in 10 bit version at all?
----
I have also did various test with 8 bit version, try crf1 -preset medium -tune grain for example and observe violet chroma dance at 16s (that is, besides megahuge filesize).
p.s. using ffmpeg on OS X in all tests.
hello_hello
27th January 2012, 05:41
I've sent Dark Shikari a PM asking him to return to the thread if he can. It'll be interesting to get a comment from an x264 developer regarding shanndogg's sample. Hopefully we'll hear from him.
hello_hello
27th January 2012, 18:49
playing around with Original File-001:
10 bit 420 encode does look decent (regarding lack of blocking on dithered gradients)
i just used:
-preset medium -tune film -crf 21 -threads 0
Well the 10 bit version still doesn't eliminate all the banding, or blocking, however I should refer to it, but it's certainly a huge improvement over the 8 bit version.
That's the first time I've even tried to play a 10 bit encode. When you say it won't play anywhere, where is it likely to play? Obviously I could convince the PC to use ffdshow and played it fine, but the media player in my TV spat it out while the Sony Bluray player (god bless it) at least played it even if it looked like a mess. Hardware players..... sigh....
smok3
27th January 2012, 19:04
not really following the state of 10bitnes, so not sure what exactly will play this.
However i did check some other movies (pretty much anything has a room scene with vigneted wall, done in post or light setup) and none has even a single scene that would look as problematic as this one, so i guess its a pretty lonely problem, a killer sample if you wish.
hello_hello
27th January 2012, 19:52
That's why I was surprised when this issue came up. I have seen a similar thing in other people's encodes before and just put it down to odd encoder settings or some type of "user error". This is the first time I've experienced it myself. What's odd is it's not just the "wall scene". The guy's dark jacket in the first scene doesn't encode well, and there's some sort of banding on the woman's back at the 11 second mark. Xvid is no better (actually worse).
I've also rechecked a couple of encodes and can't find anything even resembling the problem here. It'd be interesting to at least learn the "why", even if there's no solution.
hello_hello
27th January 2012, 20:22
Well guess what?? It appears not to be the encoder's fault.
I guess largely due to the fact I have no idea what I'm doing, I tried a few different experiments (Original File-001). First I tried using ffdshow to convert the video to RGB and getting the encoder to encode it. Same result. Next I tried using VirtualDubMod to convert it to an uncompressed AVI (via DirectShow again). And there it was. All the artifacts, banding etc which are preset in the encodes also appear when the video is saved as an uncompressed AVI. Encoding it just makes it worse.
Why? Well if I am correct.... it's over my head. But maybe it's a start. Although if the problem is being introduced when decoding, why does the original video display none of the problems when you simply play it?
Edit: Okay, so thinking about it more I went back to the original sample and had a close look again. While it's not obvious, all of the "faults" we're seeing in the encodes seem to actually be present in the source, only to a much lesser degree. There is "banding" on the wall/door behind the couple in the bed, for example. You'd kind of assume a transparent encode wouldn't make it any worse, but I'm still thinking it's not the encoder's fault as the uncompressed AVI version looks far worse than the source. Someone more clever than I am will have to explain why.
Anyway, I might do something different now, like actually watch a video for a change.....
shanndogg
27th January 2012, 21:05
What would bother me more than anything is the shot of the vehicle from above where the camera rotates, and as the CRF value increases the scenery is more likely to "wobble", mainly at 720p. If that single shot was my one and only benchmark, I'll confess at 1080p I'd not go higher than CRF 20 and at 720p I'd probably not go higher than CRF 18.
I checked out your files and agree completely with your assessment. Crazy, I never saw something like that wobble before.
observe violet chroma dance at 16s (that is, besides megahuge filesize).
Damn, I wish I knew what that meant!
However i did check some other movies (pretty much anything has a room scene with vigneted wall, done in post or light setup) and none has even a single scene that would look as problematic as this one, so i guess its a pretty lonely problem, a killer sample if you wish.
I tried to watch a bunch of my previous encodes again and agree with the statement that this particular sample is unique, but there are others I have seen like this. Why some sources cause the problem more than others is beyond me.
Luckily, from the suggestions and help given here, I have been able to determine that if I encode from now on at 1080p CRF18 or better, I do not see the problems anymore (i.e. the encodes once again become at or near transparent). Thus, the main purpose of my post has been solved and I thank everyone for their help!
To follow up: I was able to view the last few tests of 7ekno's suggestion with a 720p CRF 17 and 1080p CRF 18 both with veryslow, tune film, AQ 1.15, and no DCT decimate. The 720p was much better than previous attempts, but I still saw problem areas at my normal viewing distance. Because of this, 720p is out for me. The 1080p was slightly better than just using veryslow and tune film, which was slightly better than medium (default) preset CRF18. File sizes were 4.2GB for default CRF18, 4.3GB adding veryslow and tune film, and 5.0GB adding AQ1.15 and no DCT decimate. I would say the slight difference veryslow and tune film made was worth it, but I am still trying to decide if I should add AQ1.15 and no DCT decimate.
hello_hello has been kicking ass with his tests and I am curious to see if there is any resolution to this potential decoder/encoder issue.
nibus
28th January 2012, 04:14
If you use the default --veryslow profile, you will want to manually specify the reference frames for 1080p if you want to retain DXVA compatibility. For 1920x1080 the maximum reference frames is 4, for 1920x816/800 the max is 5. This will also significantly speed up encoding.
x264 always has the hardest time with keeping details in grainy/dark/gradient areas. It can be a real trick to get it to keep it, but in general there are a few things I use: --no-dct-decimate, raising --psy-rd to around 1.10-1.20, and lowering the CRF to 17 or lower if needed. For AQ I wouldn't recommend over .8 for most 1080p material, as the details in the scenes will look less sharp. --psy-rd and a low CRF is really where it's at for retaining those fine gradient details.
edit:
also, the higher the --me, --subme, and --merange values the better results you'll have (obviously). --me umh --subme 11 is pretty effective at retaining this detail. Obviously the very best would be the placebo --me tesa --subme 11, but the difference is very small and the speed decrease is large.
Setting --merange to 24 or higher can also help with the faster moving grainy areas, but it will also significantly decrease encoding speed. I would recommend trying --me umh --subme 10/11 --merange 24 and see how that does as far as speed and quality.
QuantumRand
30th January 2012, 12:44
Great news! Thanks largely to your guys' help, I've figured out my problem. It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV. On my laptop (which is my main/faster computer and where I fiddle with the encoding settings), the banding would still show up (bright LCD monitor settings), but I could see the different quality settings making a difference. On my TV, the quality settings (and even upping the average bitrate to 8000kbps) made zero difference.
I haven't narrowed down which setting was the culpret quite yet (probably "Edge-enhancement"), but I'm going to try different settings to see. Also, I'll have to re-try various quality settings on my encodes to see just how bad the banding is with the right CCC settings (I was using a 7000kbps sample when I found out what was going on).
I'm not sure if this will help Shanndogg out, since his (her?) source already has banding problems to begin with, but it's worth looking into your driver settings just to make sure.
Edit: Interestingly, it was the "De-noise" setting that did it. All the other settings didn't seem to affect the banding in a negative way.
Atak_Snajpera
30th January 2012, 13:03
I always disable everything in CCC
EDGE-Enhancement - OFF
De-Noise - OFF
Dynamic Contrast - OFF
hello_hello
30th January 2012, 13:20
Great news! Thanks largely to your guys' help, I've figured out my problem. It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV.
Ahhhhhh..... I wonder why ATI seems to enable all that stuff by default while Nvidia doesn't. Having an Nvida card it never occurred to me to consider the video card might be the culprit.
Now we just need an explanation as to why shanndogg's sample doesn't even convert to uncompressed video well. Maybe someone clever will still come among.....
QuantumRand
30th January 2012, 13:27
Ahhhhhh..... I wonder why ATI seems to enable all that stuff by default while Nvidia doesn't. Having an Nvida card it never occurred to me to consider the video card might be the culprit.
Now we just need an explanation as to why shanndogg's sample doesn't even convert to uncompressed video well. Maybe someone clever will still come among.....
Well, in ATI's defense, I'm the one who turned them on. It was a long while back and I had completely forgotten about it, but turning them on helped immensely for SD content at the time.
QuantumRand
30th January 2012, 13:44
Hey Shanndogg, what is the source you pulled your movie from, if you don't mind my asking? 1080p Blu-Ray? Also, what method did you use to chop it into those clips?
When I experimented with your Original File-001, I was able to compress it relatively well without any sort of banding on the walls; however, the refrigerator was an entirely different story. When I looked at your original file, the banding on the refrigerator was actually quite apparent, which is why I'm asking about your source and your remuxing methods.
Lastly, I don't recall if you've mentioned this already, but what are your target results for your encodes? For example, I'm trying to turn my Blu-rays into 720p movies around 5GB (1080p and ~8GB for the more exciting ones).
shanndogg
30th January 2012, 20:27
It was all due to the ATI Catalyst Control Center. For whatever reason, settings in the CCC were exaggerating the banding on my TV.
So this looks like it falls into a calibration issue where CCC was "un-calibrating" your TV so the issue was amplified. Whereas, it is usually hidden in the unseen dark areas as it should be.
Hey Shanndogg, what is the source you pulled your movie from, if you don't mind my asking? 1080p Blu-Ray? Also, what method did you use to chop it into those clips?
When I experimented with your Original File-001, I was able to compress it relatively well without any sort of banding on the walls; however, the refrigerator was an entirely different story.
Lastly, I don't recall if you've mentioned this already, but what are your target results for your encodes? For example, I'm trying to turn my Blu-rays into 720p movies around 5GB (1080p and ~8GB for the more exciting ones).
You are correct on the original source and I used mkvToolnix to cut out the short samples. Click the "Global" tab and there is a box you can select to "enable splitting." Then just choose the size, duration, etc. as to how you want to split it and make sure you select the correct number of max files.
Out of curiosity, what settings did you use when you use when experimenting on Original File-001?
I don't have a specific target result in mind, just what ever looks transparent or near transparent to the source. With the Sharp TV that happened to be 720p CRF20 default settings which put files between 2-5gb. With the Panasonic it is now 1080p CRF18 veryslow, tune film which puts files between 6-13+gb (I've only done a couple so far).
hello_hello
31st January 2012, 03:40
shanndogg,
I'd still like to know what it is about your sample that's "different". Why it doesn't convert to uncompressed AVI well but you can still get acceptable results with a low enough CRF value, I just don't understand. Thinking about it though, I only tried converting it to uncompressed AVI at 720p so maybe resizing the video has a fair bit to do with it? It still seems somewhat odd though...
Ghitulescu
31st January 2012, 08:49
So this looks like it falls into a calibration issue where CCC was "un-calibrating" your TV so the issue was amplified. Whereas, it is usually hidden in the unseen dark areas as it should be.
No, it's not the calibration - it's the black level (or PC vs. TV levels). Some TVs have it disabled from factory, some don't, some have specific inputs for PCs.
On the computer side, one also has the possibility to select the levels in the drivers' settings.
On my first answer I thought you're watching them using a HW player, which by default uses the TV levels, on a TV with PC levels deactivated (normal case). My mistake.
"Blacker than black" levels will cause the issues you noticed.
QuantumRand
31st January 2012, 12:41
Out of curiosity, what settings did you use when you use when experimenting on Original File-001?
I don't have a specific target result in mind, just what ever looks transparent or near transparent to the source. With the Sharp TV that happened to be 720p CRF20 default settings which put files between 2-5gb. With the Panasonic it is now 1080p CRF18 veryslow, tune film which puts files between 6-13+gb (I've only done a couple so far).
The best 720p result I got was with a CRF of 16. The settings I used are pretty much the VerySlow settings with the Film tuning. CRF 16 was pretty much transparent compared to the source. There was still banding, but it was only a tiny bit worse than the source's.
From what I've seen, CRF16 is still enough to get your file sizes down to around 5GB for the typical 720p movie. I personally like to do my 720p transcodes at CRF17, and I'll go as low as 16 for the movies that have issues. But I also think that I have a pickier eye for detail than most.
For my favorite movies, I'll keep them in 1080p and use a CRF of 18 or 19. The Dark Knight, for example, compressed down to 7GB at 1080p and CRF19, and it's a 2.5 hour long movie.
Your clip is almost entirely transparent with the source if I transcode it at 1080p with a CRF of 18 (19 exaggerates the banding slightly more).
In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.
Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.
ramicio
31st January 2012, 15:07
It's called copping. When backing up their own stuff, some people prefer full 16:9 with black bars, and some people prefer to crop. It's in no way an indication of "piracy".
hello_hello
31st January 2012, 22:17
In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.
I don't know.... it depends on how large the audio stream is too, but my CRF 20 720p encodes range between 2.5 and 5 GB. Dark Night (just for reference) is 3.3GB. Obviously it's not hard to compress.
Up until this thread I've been perfectly happy with the quality and don't seem to have lost much detail.... but then this thread and problem samples came along....
Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.
I know the movie is one hour, 30 minutes long but don't recall how large the original video is.
diogen
1st February 2012, 00:31
In my (very limited) experience, if you're squeezing a full-length 720p movie into files smaller than 4GB, you're probably losing a lot of detail.From my just as limited experience you need about 1GB/hour to get a transparent DVD encode and 4GB/hour for a BD.
Video only, 1080p, 2.35. Error bars +/- 20%.
It takes more for a full 16:9.
Diogen.
nibus
1st February 2012, 01:01
Bitrate requirements are much more film specific. Toy Story in 1080p could be done in <4gb while Transformers needs 15-20.
hello_hello
1st February 2012, 05:06
No, it's not the calibration - it's the black level (or PC vs. TV levels). Some TVs have it disabled from factory, some don't, some have specific inputs for PCs.
On the computer side, one also has the possibility to select the levels in the drivers' settings.
No, it's not the calibration. That's why shanndogg described it as the ATI card "un-calibrating" the TV.
It's probably not TV vs PC levels either, or I'm sure QuantumRand would have mentioned the levels changing. According to QuantumRand it was simply the noise filter making the banding look worse.
Why is ramicio talking about cropping and piracy? Did he post in the wrong thread or am I missing something?
shanndogg
1st February 2012, 09:28
I'd still like to know what it is about your sample that's "different".
So would I, but until I hear otherwise I am just going to take it as some films (or just scenes within films) aren't authored that great (as seen in my example) and require higher settings than other films. That's why I was trying to find a good base. Of course, many of my encodes will probably be overkill now, but I would rather loose a little space than have poor quality.
Just out of curiosity, how long is the entire movie, and how big is the original source? I only ask because I have yet to come across a Blu-ray that had noticeable banding like this one.
Thanks for the info Quantum- glad to see your findings match up with mine. The orginal is an hour and 30 minutes as hello_hello mentioned and is around 17.5gb.
diogen
1st February 2012, 17:20
Bitrate requirements are much more film specific.Very much so.
Animated features are generally much more compressable.
Older movies with lots of grain are the worst.
I could not make anything remotely decent (with smaller sizes) out of the Dollars trilogy of Eastwood.
Diogen.
hello_hello
1st February 2012, 19:13
So would I, but until I hear otherwise I am just going to take it as some films (or just scenes within films) aren't authored that great (as seen in my example) and require higher settings than other films. That's why I was trying to find a good base. Of course, many of my encodes will probably be overkill now, but I would rather loose a little space than have poor quality.
There's probably nothing else you can do unless the reason they require higher settings is discovered, but I still think there's something else going on and it's not just that the encoder requires a higher quality setting to get it correct. If it was just the encoder your sample would convert to uncompressed AVI and look fine, but it doesn't.
Very much so.
Animated features are generally much more compressable.
Older movies with lots of grain are the worst.
I could not make anything remotely decent (with smaller sizes) out of the Dollars trilogy of Eastwood.
Which is why, as a general rule, I find the practice of file size based encoding somewhat hard to understand.
Ghitulescu
2nd February 2012, 09:59
Which is why, as a general rule, I find the practice of file size based encoding somewhat hard to understand.
That is EXACTLY the argument/answer given when asked why they reencode :) :p ;)
QuantumRand
2nd February 2012, 12:18
Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?
I can't imagine ABR would be very useful without two-pass encoding, but with the Turbo First-Pass, the total encoding time is fairly tolerable. Plus from what I've seen, turbo first-pass didn't have that huge of an effect on file size.
I've found that a 720p backup with an ABR around 5000kbps gives a pretty consistent ~2.2GB/hour. And at 5000kbps, you can use the Normal preset and Turbo First-Pass and still get the same file size while still maintaining essentially transparent quality as you would with 16CRF. Turbo First-Pass, Normal preset takes like 25% longer than CRF16 on VerySlow but you get the same quality results. The file size is typically larger, but always consistent.
diogen
2nd February 2012, 15:30
Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?I think all those different methods of encoding have more of an historical significance than anything else.
When the hidef optical media was introduced - HD DVD and BD - the encoding workflow has changed.
With DVDs it was a hardware box with one dial - bitrate.
That took care of DVD creation (at least most of it).
With HD/BD this process became manual.
And since the players were limited in horsepower, there was a need to limit complexity of the encode.
So it became a 2-pass automatic encode with manual tuning afterwards.
All this is moot by now.
BD is the sole hidef optical standard for 4 years. H.264 has improved quite a bit.
Some of those improvement are withing the BD standard, some - outside.
The silicon running in those players - hardware or software - are 5+ times faster. Even more so with PC playback (GPU assistance).
Diogen.
hello_hello
2nd February 2012, 15:59
That is EXACTLY the argument/answer given when asked why they reencode
When "they" are asked why "they" re-encode (who are they?) the answer given is they find the practice of file size based encoding hard to understand?
What on earth are you talking about?
sneaker_ger
2nd February 2012, 22:03
Just out of curiosity, is there anything inherently bad about Target Average Bitrate encoding, other than it taking a long time?
No, two pass encoding is totally fine. Single pass ABR on the other hand has lower quality than CRF and two pass.
Plus from what I've seen, turbo first-pass didn't have that huge of an effect on file size.
What else did you expect? ABR (both single and two pass) aims for a defined bitrate, so not having "that huge of an effect on file size" is totally meaningless in these modes.
I've found that a 720p backup with an ABR around 5000kbps gives a pretty consistent ~2.2GB/hour.
Again: what else did you expect?
1h * 5000 kbit/s = 60s*60*5000kbit/s = 18,000,000 kbit ~= 2.2 GB
And at 5000kbps, you can use the Normal preset and Turbo First-Pass and still get the same file size while still maintaining essentially transparent quality as you would with 16CRF. Turbo First-Pass, Normal preset takes like 25% longer than CRF16 on VerySlow but you get the same quality results. The file size is typically larger, but always consistent.
Frankly put, you're not making any sense. Don't use fast first pass if you only want to do only a single pass, use a faster preset instead.
smok3
2nd February 2012, 23:20
how would this work (staring at libvpx docs):
-crf 21 -max-rate 5000 -preset variable-reencode-with-slower-preset-if-bitrate-limit-is-reached:else:lower-the-crf-and-tell-that-to-the-user ?
QuantumRand
3rd February 2012, 01:51
Frankly put, you're not making any sense. Don't use fast first pass if you only want to do only a single pass, use a faster preset instead.
I guess what I was getting at is that CRF mode seems to reduce the bitrate a little too much in some spots, exaggerating imperfections. This means you have to lower the CRF to points where the majority of the movie doesn't benefit, or you have to waste time experimenting with different CRF levels.
Assuming it actually does act this way, going the ABR route could avoid degraded quality in those situations, sacrificing some compression, but with a calculable result. But like I've said, I'm pretty new to the transcoding game, so I'm just making guesses.
Asmodian
3rd February 2012, 02:21
This means you have to lower the CRF to points where the majority of the movie doesn't benefit, or you have to waste time experimenting with different CRF levels.
Assuming it actually does act this way, going the ABR route could avoid degraded quality in those situations, sacrificing some compression, but with a calculable result. But like I've said, I'm pretty new to the transcoding game, so I'm just making guesses.
This is an odd assumption, if some regions need a little more bitrate and lowering CRF "wastes" bits on regions that don't need it going ABR will make this even worse; it isn't as good at moving bits to where they are needed.
I think you want to play with psy settings and aq-strength instead of dropping crf.
hello_hello
3rd February 2012, 03:03
QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC. I thought being a TV sending it TV levels would be correct, and the picture certainly looked fine to me, but after changing the levels and then adjusting the brightness to get it roughly back to where it was (I haven't tried to calibrate it properly yet) I had a look at the encodes I made of your samples again.
Most of the problems I could see before I can now no longer see because the dark areas are darker. Even the shot from above where the camera slowly turns and I said it appears to wobble..... the difference now between 1080p CRF 16 and 720p CRF 20 is fairly minimal. Not enough to really notice unless I compare the two. Even the scene of the sky where the blocking looked really obvious, well at 720p CRF 20 I can still see it if I look for it but during the process of watching a movie I'm not sure it's anything which would jump out at me.
shanndogg's samples are still a different matter. The darker areas now look pretty good but the banding in the lighter areas and the problem with dancing pixels is still something I can see fairly easily and still something which seems to get worse when encoding.
QuantumRand
3rd February 2012, 05:18
QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC. I thought being a TV sending it TV levels would be correct, and the picture certainly looked fine to me, but after changing the levels and then adjusting the brightness to get it roughly back to where it was (I haven't tried to calibrate it properly yet) I had a look at the encodes I made of your samples again.
Most of the problems I could see before I can now no longer see because the dark areas are darker. Even the shot from above where the camera slowly turns and I said it appears to wobble..... the difference now between 1080p CRF 16 and 720p CRF 20 is fairly minimal. Not enough to really notice unless I compare the two. Even the scene of the sky where the blocking looked really obvious, well at 720p CRF 20 I can still see it if I look for it but during the process of watching a movie I'm not sure it's anything which would jump out at me.
shanndogg's samples are still a different matter. The darker areas now look pretty good but the banding in the lighter areas and the problem with dancing pixels is still something I can see fairly easily and still something which seems to get worse when encoding.
My issues with the banding were solved when I disabled the De-Noise feature in the Catalyst Control Center. CRF 17 did a good job compressing everything down, and the problem areas, while still visible, are certainly tolerable in a normal watching scenario. I'm happy with the result, especially since I don't think Thor is worth that much of my time, lol.
But like you said Shanndogg's issues are a different matter. The source itself has the banding issues. I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.
Maybe the TV's motion enhancement is screwing with things? Since I have my TV connected to my PC, I have all of the extra features turned off since the computer is capable of handling all of that better anyway.
Ghitulescu
3rd February 2012, 08:52
I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.
A TV is not calibrated using uncompressed sources. It is calibrated using special patterns and methods to single out each element, then tune it accordingly.
Maybe the TV's motion enhancement is screwing with things? Since I have my TV connected to my PC, I have all of the extra features turned off since the computer is capable of handling all of that better anyway.
The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget. With the notable exceptions of masochists and pros (who are anyway paid to do this, like it or not), nobody likes to fiddle the settings for each movie, show or whatever programme they watch. They also pay more for the TVs incorporating them, only to find out (if :)) that the image is better without them activated.
hello_hello
3rd February 2012, 09:13
But like you said Shanndogg's issues are a different matter. The source itself has the banding issues. I think what he (she?) needs to do is focus on optimize the display settings, since the old TV didn't have the issue. I'd use the uncompressed sample as a guide for tuning in the settings to the best possible.
I still don't think shanndogg's issues are related to calibration. I can see the banding on my PC monitor and I can see it on the TV both before and after changing the levels. It may be his old TV was hiding the problem somehow, or had some sort of built in deblocking or debanding which masked the problem. My TV has a digital noise filter and an mpeg noise filter and although I've not been able to determine exactly what they filter, one of them did reduce the blocking on a poor quality AVI I was using for testing. However when using the PC I have them turned off and they're set to "low" for the Bluray player.
And of course there's still the question as to why when converting his sample to uncompressed RGB, it makes the banding a lot worse. That doesn't make sense to me.
hello_hello
3rd February 2012, 09:38
The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget. With the notable exceptions of masochists and pros (who are anyway paid to do this, like it or not), nobody likes to fiddle the settings for each movie, show or whatever programme they watch. They also pay more for the TVs incorporating them, only to find out (if ) that the image is better without them activated.
Just to clarify....
Is it the stupid people who pay more for a TV with extra features which they then happily set and forget while somehow still managing to discover the image looks better without them, or is it the non-stupid people paying paying more for TVs with "extra features" they're not going to use so they can be even less happy about fiddling with the settings for every movie? :)
Ghitulescu
3rd February 2012, 09:50
The first category. It's the power of marketing.
7ekno
3rd February 2012, 11:12
7ekno - what profile do you use?
I use WDTV Lives and HTPCs, so not restrained to profile (yes, I have extensively tested my settings on a WDTV Live with level 5.1 and 5.0 profiles!) ...
Also note that I stated I degrained first before using those settings (so filesize is naturally reduced from degraining) ...
Personally I would use:
- Crop & Spline36 resize to 720p (or leave as 1080p)
- MCTemporalDenoise(settings="low", enhance=true)
Then encode with my previous settings (for 720p):
--crf 17 --tune film --preset veryslow --no-dct-decimate --aq-strength 1.15
Here is how I would have done the 720p versions:
http://www.teknosrealm.com/examples/001_720p.mkv
http://www.teknosrealm.com/examples/003_720p.mkv
7ek
Didée
3rd February 2012, 18:22
The "extra features" are there for stupid people (sorry) that are more than happy to set them once and forget.
According to your tunnel vision, I'm in the category of "stupid people", too. :)
To keep it compact, here's a wall-of-text:
The strongest point, to me, indeed is the motion interpolation feature. I would not want to miss it from my TV anymore. Note that I do not, repeat: NOT like "soap opera" effects. But the problem is that it's not possible to really reproduce the so-called "film look" on any modern flatpanel display. Not without the help of additional "tools". Yes, film look is intended to show a kinda "rough" motion (and I like it.) But if you have e.g. a panning scene with a house front running through the frame, you are NOT supposed to see double- or, more likely, even triple- or quadrouple-contours on wall corners, windows,etc. But that's exactly what you get without motion interpolation. Necessarily, it can not be any other way. If each picture "stands" for 40 ms, but the eye is continuously moving as it is tracking any image feature, you necessarily get motion blur on the eye's retina. (And worse, it's even inverse motion blur, that is building up "backwards" during the integration time of one frame. But this gets a bit too far for this thread.) Is it so that self-conceived videophilists have "declared" such artifacts as being "the" film-look? To me, this simply is an optical artifact that should not be.... - Granted, I'm not sure how "all the various manufacturers" individually implement the feature. Anyhow, on my TV (Samsung) there is a rather fine-granulated control over the strength of the motion interpolation feature, and at low settings it does a mostly splendid job at reducing retina-motion-blur, while leaving the "rough" film look mostly intact.
Ghitulescu
3rd February 2012, 19:21
[QUOTE=Didée;1555695]According to your tunnel vision, I'm in the category of "stupid people", too. :)/QUOTE]
Not at all, I like it too to have this kind of setting. But it should work correctly.
Unfortunately the one that decides what "improvements" are implemented and which not, is someone with the rot pencil, that listen more the marketing dept. than the engineering one. The customer['s opinion] doesn't count, if he doesn't buy, just lower a bit the prices and he will. Eventually. Because he has no real alternatives, or they cost way too much.
ramicio
3rd February 2012, 20:24
A film is NOT intended to show a rough motion. It was the limits of film reacting to light almost a century ago, and we haven't left it yet. If film was invented today, we would be going with hundreds of FPS and no one would say boo about the smooth motion looking too realistic. If you want your old movies to be choppy, then fine, but I don't think new movies should still suffer from it. They're new, and they should look new. By your logic, movie audio should just be mono so we know it's a movie, yet we strive to realism in the sound. But oh no!...once you get into specs on the picture, it's taboo to be new.
hello_hello
3rd February 2012, 20:43
Unfortunately the one that decides what "improvements" are implemented and which not, is someone with the rot pencil, that listen more the marketing dept. than the engineering one. The customer['s opinion] doesn't count, if he doesn't buy, just lower a bit the prices and he will. Eventually. Because he has no real alternatives, or they cost way too much.
The nothing like following up a post of silly generalizations with another one even sillier.
Sure the marketing department can do it's job well, but have you heard of competition? Is a manufacturer going to ignore the engineering department when they announce they've found a way to do feature X better than everyone else if they think it'll help them sell more TVs? And yes of course new features are generally added to the more expensive models first, but it doesn't mean they can't trickle down to be included as standard on the average smart phone in a few years time.
I don't know who ramicio is arguing against. Who said film shouldn't be allowed to use higher frame rates?
Ghitulescu
3rd February 2012, 20:58
Sure the marketing department can do it's job well, but have you heard of competition? Is a manufacturer going to ignore the engineering department when they announce they've found a way to do feature X better than everyone else if they think it'll help them sell more TVs? And yes of course new features are generally added to the more expensive models first, but it doesn't mean they can't trickle down to be included as standard on the average smart phone in a few years time.
There is no competition, my dear.
Or maybe who against whom? JVC versus Technics versus National versus Panasonic versus whatever-subsidiary-Matsushita-corp might have? Or maybe between the 101 companies Harman-Kardon fully owns?
Or maybe the 5 bigs in cellphone technology suddenly began to compete, ending a 20 years period of cartell-dealings?
There is definitively competition in electric toothbrushes industry, yes! But, no, wait, Philips sold everything except medical and lighting, no way... :) gosh, I almost found one ... :)
Didée
3rd February 2012, 21:02
I don't know who ramicio is arguing against.
The "who" is not important. Important is the "against". :D
hello_hello
3rd February 2012, 21:13
There is no competition, my dear.
No..... at least not for offering generalizations and confabulations
shanndogg
7th February 2012, 23:23
QuantumRand,
For the sake of full disclosure I discovered, due to participating in another thread, I'd been sending the wrong levels to the TV from my PC.
After reading your post and the other thread about black levels, I went and reexamined all of my settings and found something interesting:
The Boxee Box which plays my MKVs was outputting RGB Low (16-235). On another site for the Panasonic VT30 series, it was indicated to have your Bluray player output YCbCr 4:2:2 (this is what I have my Bluray player set to). So I tried setting the Boxee Box to output YUV 4:2:2 (I assume it's the same as the Bluray player YCbCr?). Guess what? The original 720p file that looked really bad to me know looked way better... almost transparent and definitely acceptable. The 1080p's still looked better, but I could probably live with the 720p. Does this make sense?
Previously, I had the Bluray player and Boxee both outputting RGB low to the Sharp LCD and never had a problem. I remember I tried YCbCr on the bluray before with the Sharp, but it caused a weird flickering in the letterboxed portion of Blurays/DVDs.
Now, with the Panasonic, it looks like I need 4:2:2. I tried 4:4:4 but couldn't tell an immediate difference. With the difference so big between RGB and 4:2:2 on the Panasonic, I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?
Asmodian
8th February 2012, 00:13
Now, with the Panasonic, it looks like I need 4:2:2. I tried 4:4:4 but couldn't tell an immediate difference. With the difference so big between RGB and 4:2:2 on the Panasonic, I am wondering how the hell are you supposed to know what to use (RBG low/high, 4:2:2, 4:4:4) for which source/display?
4:2:2 = low bandwidth 4:4:4. 4:4:4 is just better and doesn't change anything vs 4:2:2. Not that you can tell and your source content is almost surly 4:2:0 anyway but I wouldn't do much testing of 4:2:2 vs 4:4:4.
RGB low/high is one of those terrible names. Is RGB low = 16-235 or 0-255? I assume low = 16-235 because if you just switch back and forth between 16-235 and 0-255 using 16-235 looks darker.
EDIT: This is wrong! 0-255 looks darker (expanding 16-127 to 0 to 127 streaches more values into the "darker" range, 128-235 -> 128-255 does the same, makeing bright seens brighter but this is less noticable)
Anyway the YCbCr spaces (i.e. 4:4:4) allow your TV to do the conversion to RGB while if you set RGB out you need to pick the right one (16-235 for normal blurays etc.). How your TV does the convertion from YCbCr to RGB is up to it.
vBulletin® v3.8.11, Copyright ©2000-2025, vBulletin Solutions Inc.