Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Scott R wrote:So when you say 21-22 *minimum*, can you (or others) give me a hard number that you'd suggest when converting a 1080p Blu-ray rip down to 1280 width, with optimal PQ as the goal (I have a 720p front projector, so I'd like it to look as close to the source as possible)?
Will boosting these numbers add significantly to the encoding time? As I mentioned, I believe that last night's encode took about 8 hours.
My suggestion is 19 for 480, 21 for 720, and 23 for 1080. Going lower than these values rarely has an appreciable change in PQ.
Encoding time is largely independent of rate factor.
Scott R wrote:Thanks for the added comments, everyone. I'm still a bit confused, though. You're all providing ranges, rather than a specific number. How are you decided when to use 21 vs 22?
So with this Blu-ray rip, what will moving up from RF 19 to RF 22 bring me? Is this going to result in more detail or in less motion artifacts/macroblocking/etc. FWIW, while I could see the resolution loss between the 1080p .ts source and this 2GB 720p file when standing a few inches from my 52" 1080p LCD TV, I didn't see any motion artifacts/macroblocking, which was a pleasant surprise. But if moving up to RF 22 can result in a little more detail, I'm sure I'd appreciate that when I watch these movies with my projector.
It's a matter of personal preference. Use 22 if you can't see the difference between 21 and 22. A higher rate factor is lower quality.
Inches away from a multi-foot display is a rather abnormal viewing distance. Watch it like you would watch it, not pixel peeping.
OK, thanks. Just to clarify, when you suggest RF 23 for 1080, you're talking about if I want to keep the end result 1080, not if I'm downconverting 1080 down to 720 (in which case I'd use an RF of 21), correct? Because, as I said before, I'm focusing here on the new Apple TV which they're telling us cannot do 1080p.
Now, I think I'm still missing something somewhere, so please bear with me...
TedJ said that using a higher RF number shouldn't change the encoding time, but might increase the filesize. You're saying that encoding time is independent of RF (consistent with TedJ), but state that a lower number yields (possibly) better quality. Well, if both you and TedJ are correct, a lower number (e.g., 19) *could* yield better quality at smaller filesizes, and not take any additional encoding time. So why then wouldn't I want to use a lower number? The only way this makes sense to me is if lower RF numbers yield (possibly) higher quality (which both of you said), but at the cost of *larger* filesizes (which is the opposite of what TedJ seemed to be stating).
And I think I've asked this before, but I don't believe it's been directly answered...am I correct in choosing the High Profile setting and only changing the width (to 1280) and the RF settings, or are there other settings that I would benefit from tweaking? I *do* want to keep a 5.1 audio track for the benefit of the one room with a 5.1 A/V receiver, but also want to maintain compatibility with the other rooms in my house which will be hooked up via HDMI directly to a TV and will just be using the TV's stereo speakers (I'd also like to be able to maintain compatibility with the iPhone 4). Beyond that, and as I've stated previously, I am not particularly concerned if filesizes are large, but I do want to maintain the best PQ possible for my 720p projection setup.
Scott R wrote:OK, thanks. Just to clarify, when you suggest RF 23 for 1080, you're talking about if I want to keep the end result 1080, not if I'm downconverting 1080 down to 720 (in which case I'd use an RF of 21), correct? Because, as I said before, I'm focusing here on the new Apple TV which they're telling us cannot do 1080p.
Now, I think I'm still missing something somewhere, so please bear with me...
TedJ said that using a higher RF number shouldn't change the encoding time, but might increase the filesize. You're saying that encoding time is independent of RF (consistent with TedJ), but state that a lower number yields (possibly) better quality. Well, if both you and TedJ are correct, a lower number (e.g., 19) *could* yield better quality at smaller filesizes, and not take any additional encoding time. So why then wouldn't I want to use a lower number? The only way this makes sense to me is if lower RF numbers yield (possibly) higher quality (which both of you said), but at the cost of *larger* filesizes (which is the opposite of what TedJ seemed to be stating).
And I think I've asked this before, but I don't believe it's been directly answered...am I correct in choosing the High Profile setting and only changing the width (to 1280) and the RF settings, or are there other settings that I would benefit from tweaking? I *do* want to keep a 5.1 audio track for the benefit of the one room with a 5.1 A/V receiver, but also want to maintain compatibility with the other rooms in my house which will be hooked up via HDMI directly to a TV and will just be using the TV's stereo speakers (I'd also like to be able to maintain compatibility with the iPhone 4). Beyond that, and as I've stated previously, I am not particularly concerned if filesizes are large, but I do want to maintain the best PQ possible for my 720p projection setup.
If you lower RF value, quality increases (on a non-linear scale) and file size increases.
As I'm adventurous, I've started encoding some test filesfor the upcoming AppleTV revision from a few Bluray sources. I started with the High Profile x264 advanced settings, set RF to 21, use custom anamorphic (mod4) to resize to 1280x720, and no video filters, increase DPL2 track to 320kbps and DRC to 1.5, add any commentary tracks (DPL2 with 160kbps and DRC=1.5). So far, it has produced some amazing-looking encodes that will kill the current generation AppleTV... I'm hopeful the new model will stream these without issue.
Scott R wrote:OK, thanks. Just to clarify, when you suggest RF 23 for 1080, you're talking about if I want to keep the end result 1080, not if I'm downconverting 1080 down to 720 (in which case I'd use an RF of 21), correct? Because, as I said before, I'm focusing here on the new Apple TV which they're telling us cannot do 1080p.
Yes, I'm talking about output. I don't really care what your input is. Well it kind of matters but only when it sucks.
Scott R wrote:TedJ said that using a higher RF number shouldn't change the encoding time, but might increase the filesize. You're saying that encoding time is independent of RF (consistent with TedJ), but state that a lower number yields (possibly) better quality. Well, if both you and TedJ are correct, a lower number (e.g., 19) *could* yield better quality at smaller filesizes, and not take any additional encoding time. So why then wouldn't I want to use a lower number? The only way this makes sense to me is if lower RF numbers yield (possibly) higher quality (which both of you said), but at the cost of *larger* filesizes (which is the opposite of what TedJ seemed to be stating).
You misunderstood TedJ. Part of the problem is the ambiguity with the word boosting. A lower RF makes the file bigger and the quality better. Rule of thumb is 6 points to double or halve the filesize.
Scott R wrote:And I think I've asked this before, but I don't believe it's been directly answered...am I correct in choosing the High Profile setting and only changing the width (to 1280) and the RF settings, or are there other settings that I would benefit from tweaking? I *do* want to keep a 5.1 audio track for the benefit of the one room with a 5.1 A/V receiver, but also want to maintain compatibility with the other rooms in my house which will be hooked up via HDMI directly to a TV and will just be using the TV's stereo speakers (I'd also like to be able to maintain compatibility with the iPhone 4). Beyond that, and as I've stated previously, I am not particularly concerned if filesizes are large, but I do want to maintain the best PQ possible for my 720p projection setup.
You can disable the filters (decomb and deinterlace default on with the High Profile preset) if you know your BRs are progressive.
You can get smaller files/higher quality (it's a trade off with rate factor) with more x264 analysis options at the expense of slower encoding.
If you're serious about "best PQ possible" buy an HTPC and keep the BR rips. If not, please stop saying that.
mduell wrote:If you're serious about "best PQ possible" buy an HTPC and keep the BR rips. If not, please stop saying that.
The entire context of this thread (see subject line) is converting Blu-rays to a format compatible with the new Apple TV. So when I say "best PQ possible" I mean the best PQ possible in a format that is compatible with the new aTV. That means that I'm willing to deal with longer encoding times or larger filesizes if the settings eek out extra PQ improvements, but a requirement is that it be compatible with the new aTV. In the course of my experimentation, I hope to determine whether the end result is going to offer the PQ that I can be satisfied with. When I keep pointing out that I want the "best PQ possible" my intent is to not have my time wasted by trying out settings that someone has suggested who has different end goals in mind (e.g., smaller filesizes, compatibility with the old aTV, etc.), and where those settings will provide a lower level of PQ than Handbrake and the new aTV are capable of. Because if I try out settings such as these and then end up with a file which offers PQ that I'm not happy with, I may wrongly deduce that the Handbrake and/or the new aTV aren't capable of providing PQ that will please me, when in fact the problem may have simply been that I was suggested settings to use that would produce a lower quality end result.
Hopefully all of that rambling has helped to clarify what I'm after.
FWIW, I'm already familiar with what an HTPC can do. I bought two Acer Revo nettops which can play raw ripped Blu-ray 1080p files quite well. I'm presently debating whether I'm willing to give up perfect Blu-ray rips for the cost and feature advantages that the new aTV brings to the table. The answer to that will depend on whether the process of downconverting Blu-ray rips to an aTV compatible format is relatively painless and if the end result still looks good on my 720p projector. Based on what I've seen so far with my one test rip, I would say that I think I can be happy with the end result PQ-wise, and the filesize savings will be a nice bonus, since I'll be able to fit more movies on my hard drive and more easily bring a couple "along for the ride" on my iPhone 4 when traveling.
OK, so I did a couple more encodes of my movie since the last post. Just to recap, my first test was a 720p RF19 encode and *I think* it took about 8 hours with my AMD 3800+ and 2GB of RAM (which is immediately depleted, thereby using virtual RAM - ouch!). The resulting file was about 2.1GB and I was very happy with the PQ. So, here are my new findings (along with some new questions)...
1) For my first new encode I decided to try encoding to 1080p. After some Googling, I couldn't find any hits where someone asked (or answered) the question of whether a 1080 file could be played on an iPhone 4. So I figured I'd try it out myself. I changed the RF setting, but forgot to write down what I used. I think it might have been RF21. The file encoded fine, but took a good deal longer than my first run (13 hours). The resulting filesize was about 2.8GB. Because my primary goal was to try to get it to work on the iPhone 4, importing it into iTunes and copying it over to my iPhone 4 was my primary goal. The first part went fine, but when trying to copy it to my iPhone 4, iTunes gave me an error that it wasn't compatible (or something like that). Well, I guess that answers that (except that it doesn't truly answer whether the iPhone 4 is *capable* of playing it - rather, it just answers whether or not the iPhone 4 supports it out of the box). Today, I took another look at this file on my HTPC and discovered that the brightness appeared to be cranked up a bit compared to the original uncompressed 1080p .ts file. And I should note that my first rip (a 720p RF19 file) had brightness that was very, very close to the original .ts file, but this new 1080p rip was considerably brighter. Any ideas why?
2) My next encode was another 720p file. I followed a couple of different users' advice in this thread and used RF16 along with turning off both detelecine and decomb. The first thing I noticed was that the encode seemed shorter. Remember that I screwed up and didn't record the encode times of my first 720p RF19 encode, but I *think* it was about 8 hours. This time, it only took 6.5 hours. The resulting filesize was about 3GB. That's nearly 50% bigger than my original 720p RF19 encode, but it's actually what I might consider to be more reasonable (i.e., how can an 18GB original file be compressed all the way down to 2.1GB and still look good?!?!?! - and yet it did). So then I did a head-to-head of my RF19 vs RF16 (with no filters). I was hoping to see a tiny bit more added detail (or something) with the RF16 file, but what hit me initially was that the brightness was too high again. Yes, the brightness seemed to match the 1080p encode, but did not match the original file (my RF19 rip did seem to match the original file's brightness level). The boosted brightness made it difficult to A/B compare the two, since the added brightness revealed subtle details in darker scenes, while losing detail in bright scenes.
So based on my tests thus far, I like the encode times of the RF16 encode, and don't mind the added filesize (3GB still seems too small, IMO), but I'm unhappy that the brightness level on this encode didn't seem to match the original .ts file. Any ideas what could be going on? My original thought was that the decomb or detelecine might be to blame, but the 1080p RF21 encode has the same brightness issue and I didn't touch the filter settings when I did that encode.
Could the RF settings be to blame? That doesn't seem to make sense, since my 1080p encode had a *highe*r RF setting than my original 720p encode, and my second 720p encode had a *lower* RF setting, yet both of those files had similar over-brightness, while the original file and the RF19 720p encode had similar brightness levels.
Scott R wrote:OK, so I did a couple more encodes of my movie since the last post. Just to recap, my first test was a 720p RF19 encode and *I think* it took about 8 hours with my AMD 3800+ and 2GB of RAM (which is immediately depleted, thereby using virtual RAM - ouch!). The resulting file was about 2.1GB and I was very happy with the PQ. So, here are my new findings (along with some new questions)...
1) For my first new encode I decided to try encoding to 1080p. After some Googling, I couldn't find any hits where someone asked (or answered) the question of whether a 1080 file could be played on an iPhone 4. So I figured I'd try it out myself. I changed the RF setting, but forgot to write down what I used. I think it might have been RF21. The file encoded fine, but took a good deal longer than my first run (13 hours). The resulting filesize was about 2.8GB. Because my primary goal was to try to get it to work on the iPhone 4, importing it into iTunes and copying it over to my iPhone 4 was my primary goal. The first part went fine, but when trying to copy it to my iPhone 4, iTunes gave me an error that it wasn't compatible (or something like that). Well, I guess that answers that (except that it doesn't truly answer whether the iPhone 4 is *capable* of playing it - rather, it just answers whether or not the iPhone 4 supports it out of the box). Today, I took another look at this file on my HTPC and discovered that the brightness appeared to be cranked up a bit compared to the original uncompressed 1080p .ts file. And I should note that my first rip (a 720p RF19 file) had brightness that was very, very close to the original .ts file, but this new 1080p rip was considerably brighter. Any ideas why?
2) My next encode was another 720p file. I followed a couple of different users' advice in this thread and used RF16 along with turning off both detelecine and decomb. The first thing I noticed was that the encode seemed shorter. Remember that I screwed up and didn't record the encode times of my first 720p RF19 encode, but I *think* it was about 8 hours. This time, it only took 6.5 hours. The resulting filesize was about 3GB. That's nearly 50% bigger than my original 720p RF19 encode, but it's actually what I might consider to be more reasonable (i.e., how can an 18GB original file be compressed all the way down to 2.1GB and still look good?!?!?! - and yet it did). So then I did a head-to-head of my RF19 vs RF16 (with no filters). I was hoping to see a tiny bit more added detail (or something) with the RF16 file, but what hit me initially was that the brightness was too high again. Yes, the brightness seemed to match the 1080p encode, but did not match the original file (my RF19 rip did seem to match the original file's brightness level). The boosted brightness made it difficult to A/B compare the two, since the added brightness revealed subtle details in darker scenes, while losing detail in bright scenes.
So based on my tests thus far, I like the encode times of the RF16 encode, and don't mind the added filesize (3GB still seems too small, IMO), but I'm unhappy that the brightness level on this encode didn't seem to match the original .ts file. Any ideas what could be going on? My original thought was that the decomb or detelecine might be to blame, but the 1080p RF21 encode has the same brightness issue and I didn't touch the filter settings when I did that encode.
Could the RF settings be to blame? That doesn't seem to make sense, since my 1080p encode had a *highe*r RF setting than my original 720p encode, and my second 720p encode had a *lower* RF setting, yet both of those files had similar over-brightness, while the original file and the RF19 720p encode had similar brightness levels.
Encode time can be influenced by a lot of things. As far as I can tell, there hasn't been one activity log submitted in this thread, so we really have nothing to go on for knowing specifically what Handbrake was doing during an encode.
You've had numerous people with 1,000+ posts tell you the recommended range for encoding HD content for AppleTV is 20-23, yet you decide to listen to the person with 8 posts that simply writes one sentence and says he uses rf16 with no discussion as to why they suggest that. While I'm not saying we're right 100% of the time, we tend to have quite a bit of experience with testing various settings for different platforms. Of course, in the end it's up to you and drive space is pretty cheap nowadays. But you're throwing away a lot of bits for very little/no gain.
On the other hand, I've seen some pretty crappy screenshots from an RF 22 720p encode (by my standards anyway). It does depend on how much fine detail and grain you intend to keep, and on the compressibility of the source itself.
nightstrm wrote:You've had numerous people with 1,000+ posts tell you the recommended range for encoding HD content for AppleTV is 20-23, yet you decide to listen to the person with 8 posts that simply writes one sentence and says he uses rf16 with no discussion as to why they suggest that. While I'm not saying we're right 100% of the time, we tend to have quite a bit of experience with testing various settings for different platforms. Of course, in the end it's up to you and drive space is pretty cheap nowadays. But you're throwing away a lot of bits for very little/no gain.
What do you mean by "throwing away a lot of bits"? What I've read from the experts here is that lowering the RF number "theoretically" increases the quality, but that after a point of doing so the increase becomes minimal/negligible while the filesize increases more significantly. So using a lower number shouldn't be "throwing away" any bits. Using a higher RF number would be "throwing away" bits. Again, what am I understanding?
I created a test sample using RF16 because someone who took the time to reply to this thread suggested it. I also used the RF21 (or thereabouts) number when doing a 1080p encode, because a couple of people replying to this thread (1,000+ post experts I guess) recommended that. And I'm not done testing other numbers/settings.
My apologies if any of the experts here are offended by me going down this apparently well-traveled path again, but the fact of the matter is that the advice given has been unspecific (e.g., use 21-22 for 720p - well, which is it, 21 or 22, or am I supposed to use some other criteria not provided to determine when to use 21 and when to use 22?), and the reasons given for why not to use a lower number has often been conflicting. And when I ask specific follow-up questions, I don't get specific answers. And as I've mentioned a couple of times already, I'm sure that everyone's needs are different. I don't know if some of the experts providing their recommendations are watching their encodes on a front-projection (or very close to a large flat screen), or if having the smallest filesize is a primary goal of theirs, and they're therefore willing to sacrifice some quality to get the filesize down, when they can't perceive any difference in PQ when viewed at a normal seating distance on a 32" LCD TV.
Scott R wrote:What do you mean by "throwing away a lot of bits"? What I've read from the experts here is that lowering the RF number "theoretically" increases the quality, but that after a point of doing so the increase becomes minimal/negligible while the filesize increases more significantly. So using a lower number shouldn't be "throwing away" any bits. Using a higher RF number would be "throwing away" bits. Again, what am I understanding?
I believe he means "throw away" as in "waste bits".
Rodeo wrote:I believe he means "throw away" as in "waste bits".
Which, from a practical standpoint, would mean increasing the filesize with no real tangible benefit, right? If so I can appreciate that, except that my RF16 encode also seemed to take less time than my RF19 encode. I did turn off the two filters that were defaulted on with the high profile preset, so perhaps turning off the filters deserves the credit for decreasing the encoding time?
dynaflash wrote:I'll say it. rf 16 on a blu ray source is both stupid and idiotic for even the new appletv. Done. 'nuff said.
'nuff said? Not IMO. Can you explain *why*? Because it's a waste of disk space since it will produce an overly large file? 1TB drives are inexpensive and my RF16 encode was a mere 3GB. If it's because you don't think it will work on the new Apple TV, then that shouldn't be a problem, because it plays fine on my iPhone 4. If it's because it won't produce any better quality than a higher RF value (which you didn't provide any recommendations for), then I can appreciate that reasoning. But if it saves on processing time that helps to offset that.
I think there's some confusion here as well with people perhaps recommending settings based on compatibility with the old Apple TV? Per the title of this thread, I don't care that much about backward compatibility with the old Apple TV. I realize that the new Apple TV isn't out yet, but I think it's reasonable to assume that the iPhone 4 and iPad are good gauges for which RF settings will be compatible with the new Apple TV, since they're all using the same A4 CPU/GPU.
That said, perhaps I'm jumping the gun by even thinking that we can have a reasonable discussion about what the ideal settings for the new Apple TV might be until it's been released. In the mean time, I'll continue to plug along with some testing of my own, and once the new aTV is released and I get a hold of one, I'll post back with my findings and we can all compare notes again then.
This would have been an unusual source then or you did something else with your settings that is reducing the size significantly that you haven't told us about. I don't see an activity log. Did I miss it? Animation and movies that are mostly CG can encode down to very small sizes. A movie like 'The Hurt Locker' on the other hand would come out to 30G or more at RF16. At RF 16, some movies will be larger after transcoding than the original.
The advice we normally give is to start with a high RF number (say 28) where you can definitely see loss of quality from the original. Encode clips with progressively smaller RF numbers till the resulting visual quality is acceptable to you in the target viewing environment. Use that RF on all encodes.
Rodeo wrote:I believe he means "throw away" as in "waste bits".
Which, from a practical standpoint, would mean increasing the filesize with no real tangible benefit, right? If so I can appreciate that, except that my RF16 encode also seemed to take less time than my RF19 encode. I did turn off the two filters that were defaulted on with the high profile preset, so perhaps turning off the filters deserves the credit for decreasing the encoding time?
Higher bitrate -> (slightly) longer encodes (especially if CABAC is enabled). So yes, the filters have a speed hit.
Scott R wrote:Which, from a practical standpoint, would mean increasing the filesize with no real tangible benefit, right? If so I can appreciate that, except that my RF16 encode also seemed to take less time than my RF19 encode. I did turn off the two filters that were defaulted on with the high profile preset, so perhaps turning off the filters deserves the credit for decreasing the encoding time?
Yes, that is likely why the RF19 encode took longer.
The fact of the matter is, until we have the new AppleTV, all we can do is speculate as to how well it will stream high profile content. The current AppleTV struggled, especially with HD material. We definitely hope using a much newer codebase and hardware will resolve these issues, and it looks like we'll know for sure next week.
This would have been an unusual source then or you did something else with your settings that is reducing the size significantly that you haven't told us about. I don't see an activity log. Did I miss it? Animation and movies that are mostly CG can encode down to very small sizes. A movie like 'The Hurt Locker' on the other hand would come out to 30G or more at RF16. At RF 16, some movies will be larger after transcoding than the original.
Hmm...I thought I had replied earlier, but I guess not. The movie I've been testing with is Monsters vs Aliens. I'm kicking off an encode of a live action (non-CG) movie now, using nightstrm's "adventurous" settings.
nightstrm wrote:As I'm adventurous, I've started encoding some test filesfor the upcoming AppleTV revision from a few Bluray sources. I started with the High Profile x264 advanced settings, set RF to 21, use custom anamorphic (mod4) to resize to 1280x720, and no video filters, increase DPL2 track to 320kbps and DRC to 1.5, add any commentary tracks (DPL2 with 160kbps and DRC=1.5). So far, it has produced some amazing-looking encodes that will kill the current generation AppleTV... I'm hopeful the new model will stream these without issue.
I'd be curious to know more about these "adventurous" setttings. I completed an encode of a live action movie (Kick-Ass) using these exact settings. It took about 8 hours, the resulting filesize is only 1.8GB, and I can play it back on my iPhone 4 without a problem (and it looks great there). I haven't had a chance yet to try it out on my cmputer hooked up to my 52" LCD TV, so I haven't inspected it in detail yet.
Can you break down some of the specific settings you (and I) used? For example, we used custom anamorphic (MOD4). In what way is this different/better than the default setting when using High Profile?
Well, none of my files played perfectly smoothly on my brand new aTV. I was not expecting the 1080p file I made to play at all, so some dropped frames there doesn't surprise or bother me, but the 720p issues came as a surprise and a big disappointment.
Part of me wants to hope that perhaps this will be fixed in an a future aTV firmware update. I say this because these 720p files appear to play back perfectly on my iPhone 4. The screen on that is so small that it's possible that I'm missing a dropped frame / stutter, but I'm holding it up to my face and I think they're playing fine on that. On my aTV, I can't watch even 20 seconds of video without a glitch/stutter/frame drop of some sort. It's subtle enough that my wife might never notice it, and the audio appears to be unaffected.
I don't believe the problem is network-related. I tried it via 802.11n and direct ethernet but, more importantly, I also waited for the movie to load completely to the aTV's buffer and if I rewind and play back a scene, I'll still get the dropped frames.
The issues are also not in the source file, because they play fine on my HTPC (and, as I already mentioned, appear to play fine on my iPhone 4) and the dropped frames don't happen in the same spots every time. I worry that the problem could be due to insufficient RAM. The aTV, iPad, and next-gen iPod Touch all have 256MB, while my iPhone 4 has 512MB. I don't have access to an iPad or iPod Touch, so I can't test my m4v's on those.
Last night I kicked off yet another Handbrake encode of my main test movie. This time I used the Apple TV (old) profile, but changed the width to 1280 and RF to 21. I'll see if that plays without issues.
If there are any others here who have had a chance to play 720p encodes on the new aTV and have are nit-picky about dropped frames, please let me know how things are going for you.
The network should be a non-issue. I don't believe that I mentioned this in my last post in this thread (I did mention it in another thread in these forums), but part of my testing includes waiting for the movie to completely load into the aTV's on-board storage, so once that's complete, I should think that any network issues would be taken out of the equation. Here's my latest update...
Last night I re-encoded my movie yet again, but this time used the old Apple TV setting. I did change the RF slider to 21 and set the video width to 1280. All other options were left as-is (again, this is using a recent nightly build of Handbrake). I tried that encode this morning but am still having the same playback issues.
I then went and played another HD movie trailer (for Alpha and Omega). I watched it very carefully and don't believe I saw any playback issues. I then tried the HD Avatar trailer again. Of note, both trailers streamed without needing to rebuffer this time (Avatar had paused midway through to catch up on the buffer both times I tried it last night), so either Apple's servers were getting hammered last night or my cable modem's downstream was slower last night than it was this morning. Back to the subject....the Avatar trailer appeared to play back perfectly smooth, with no "judder" issues.
So based on this *very* limited bit of testing, it seems like Apple's streaming HD content is not experiencing any "judder" issues, but my encodes are. But my encodes are also not displaying "judder" issues when played on my Acer Revo nettop or on my iPhone 4. Hopefully a lot of other people will run into this issue and complain loudly and Apple will manage to fix it in a firmware update. Or perhaps the Handbrake team will need to tweak something on their end or provide further guidance on how some of the settings should be configured when doing an encode to make the video more "compatible" with the new aTV. I'm wondering, could this be a 24 vs 23.97 type of issue, or (I think related to that) the fact that the aTV sends a 720 60Hz signal to the TV and the source material was 23.97 or 24?
FWIW, the test file is Monsters vs Aliens, sourced from a Blu-ray ripped to a .ts file. The scene to watch closely and spot this problem is the very opening scene where the camera pans across the universe and through a meteor/asteroid belt, eventually centering the camera on a planet which then explodes. If you can make it through that entire sequence perfectly smoothly I'm jealous and want to know what encode settings you're using.
nightstrm wrote:As I'm adventurous, I've started encoding some test filesfor the upcoming AppleTV revision from a few Bluray sources. I started with the High Profile x264 advanced settings, set RF to 21, use custom anamorphic (mod4) to resize to 1280x720, and no video filters, increase DPL2 track to 320kbps and DRC to 1.5, add any commentary tracks (DPL2 with 160kbps and DRC=1.5). So far, it has produced some amazing-looking encodes that will kill the current generation AppleTV... I'm hopeful the new model will stream these without issue.
I'd be curious to know more about these "adventurous" setttings. I completed an encode of a live action movie (Kick-Ass) using these exact settings. It took about 8 hours, the resulting filesize is only 1.8GB, and I can play it back on my iPhone 4 without a problem (and it looks great there). I haven't had a chance yet to try it out on my cmputer hooked up to my 52" LCD TV, so I haven't inspected it in detail yet.
Can you break down some of the specific settings you (and I) used? For example, we used custom anamorphic (MOD4). In what way is this different/better than the default setting when using High Profile?
Scott
The settings are "adventurous" compared to what the AppleTV v1 could reliably stream (especially in terms of HD). I use custom anamorphic for the same benefit that we see with SD DVDs (read about it here: http://trac.handbrake.fr/wiki/AnamorphicGuide), but I think this benefit is now lost as the new AppleTV does not have a 1080p output mode. So far, all of my encodes have streamed perfectly via 802.11n 5GHz and the settings I discussed above (trying RF values as low as 18).
Yes, it could output 1080p, just not decode it. From what I understand, there was some question as to exactly what it was doing to output the picture to 1080p though, so the benefits of custom anamorphic may not have applied there either.
