The 2011 MBP refresh / buyers and owner's thread (1 Viewer)

[Ken Chan]

Originally Posted by mattCR :

any Mini DisplayPort display plugs right into the Thunderbolt port. To connect a DisplayPort, DVI, HDMI, or VGA display, just use an existing adapter.

You might say that Thunderbolt has lower max bandwidth than DisplayPort or HDMI; but that may not matter if there's only a DisplayPort device attached -- i.e. higher bandwidth for a "DisplayPort compatibility mode" (I have no idea, just speculating). But even if it is lower, Thunderbolt is supposed to get even faster, so it should be a temporary problem.

 

[DaveF]

Is it 10 GBps or 10 Gbps? (yeah, yeah, what's a factor of 8 among friends?



http://www.engadget.com/2011/02/24/apple-unveils-thunderbolt/

I'm on board: They fixed the problem with USB connectors: Thunderbolt uses an physically asymmetric connector. Nor more spinning the connector round and round wondering which way the rectangle goes in. Kudos for fixing a long-standing, and obviously bad, design decision in USB.

 

[DaveF]

$1200 lateral upgrade from 500 GB hard drive to 512 GB SSD. As I predicted, this is not the year of SSD. Not even Apple can change its astronomical pricing.

 

[mattCR]

Originally Posted by Ken Chan :




You might say that Thunderbolt has lower max bandwidth than DisplayPort or HDMI; but that may not matter if there's only a DisplayPort device attached -- i.e. higher bandwidth for a "DisplayPort compatibility mode" (I have no idea, just speculating). But even if it is lower, Thunderbolt is supposed to get even faster, so it should be a temporary problem.

Yes, it is compatible. Realize, though, that if you use it in DP passthrough mode, which is a cool option, it is not really LightPeak, it's a bit like flipping it over. This is why Apple is using a different design port. I'm not saying anything negative about this, I'm just saying in it's Lightpeak (bridged) mode, it doesn't, if you use one of their adapters it's just a displayport.. anyway. Yes, there will (and has already been proposed) a future Lightpeak at 40GB, Intel just hasn't come up with a way to get there (yet) but it will happen. But while it's a temporary problem for Intel, that's a chipset design issue, so the current implementation as it will ship with these Macbooks is permanently locked at 10. There isn't a "software upgrade' out there for it.


That having been said, it is potentially very cool technology. Apple is going to make it's run based on how well they can attract bridge device makers and items. They will face a lot of market inertia against them, but it will be fun

 

[mattCR]

Intel has updated a Wiki on their product, and it is a change from the LightPeak spec:

http://en.wikipedia.org/wiki/Thunderbolt_%28Intel%29


Because it will allow DisplayPort or Lightpeak to be asynchronously transmitted without a link which means a higher pin out in the connector device, it is not an either-or. This is pretty poorly explained at Apple's website, but makes much more sense. Effectively, you should be able to get a splitter and run both Displayport AND full bandwidth LightPeak. This is a far more interesting change then the way LightPeak's base spec works. It means an external layer to get you to where you want to go, but at least this seems to push back my thought of a protocol over bridge issue. This small change means Displayport chaining can be a multi-point uncompressed per image while LP can also stay uncompressed per connection.. that's a nice little update. This was really crap explained in the announcement, but Engadget and others pressed this and Intel's responses have really clarified this one.

 

[Sam Posten]

Originally Posted by DaveF

$1200 lateral upgrade from 500 GB hard drive to 512 GB SSD. As I predicted, this is not the year of SSD. Not even Apple can change its astronomical pricing.

Yup, you were right, I was waaay wrong.

 

[DaveF]

Pity. Wished you'd been right


Hope for the optimist, but bet with the pessimist

 

[Southpaw]

So I'm pricing out a 15" and can't decide whether to go with the stock Apple SSD or get one after the fact and install myself. Price-wise, it seems fair. $450-$540 for a 256gb depending on if I get the lower 15 or higher 15. I'm seeing prices around that using froogle. Plus, I get the convenience of having it done for me and not messing with re-installs and warranty swapping, etc etc.

I'm just concerned about the quality (or perceived quality) of Apple's SSD....


Any nudging either way???

 

[Southpaw]

Well, went ahead and ordered.

Lower 15 inch / 256GB SSD / Hi res screen

I did not see any BTO message. Wasn't sure if I would or not. Said delivery was between 2/28 - 3/4

 

[Sam Posten]

Originally Posted by DaveF

Pity. Wished you'd been right


Hope for the optimist, but bet with the pessimist

The nice thing about being a pessimist is that for any given prediction you are either right or pleasantly surprised.

 

[Sam Posten]

From Macrumors forums:

First minor benchmark:
2.4 gig 42 minute HD TV episode in mkv encoded to .m4v for itunes using Handbrake:

i7 2.8 gig dual core: 24.38fps average 36 minutes total
i7 2.3 gig quad core: 54.22fps average 16 minutes total

Yikes.

yummay!


Unboxing pics:

http://forums.macrumors.com/showthread.php?t=1102021

 

[DaveF]

How is an encode running slower than real-time (24 fps) encoding faster than real-time? I misunderstand something or that data is wrong.


(42 min * 60 sec/min * 30 frames / sec) / (24.38 frames / sec) / (60 sec / min) = 52 min.

 

[Sam Posten]

It's not pulling it live off the air. It's a pre-captured TV show (a file) off a DVR or something encoded as fast as it can go.

 

[Michael_K_Sr]

Originally Posted by Southpaw

So I'm pricing out a 15" and can't decide whether to go with the stock Apple SSD or get one after the fact and install myself. Price-wise, it seems fair. $450-$540 for a 256gb depending on if I get the lower 15 or higher 15. I'm seeing prices around that using froogle. Plus, I get the convenience of having it done for me and not messing with re-installs and warranty swapping, etc etc.

I'm just concerned about the quality (or perceived quality) of Apple's SSD....


Any nudging either way???

Not sure which SSD's Apple is using in these updated MBP's. I have used one of OWC's Mercury Extreme SSD's and they are wicked fast. However, I'm waiting to see if Apple has started using the notorious Penta Lobe screws on these new machines like they have on the iPhone. If so, it will make it that much harder to upgrade the drive and RAM.

 

[DaveF]

Originally Posted by Sam Posten

It's not pulling it live off the air. It's a pre-captured TV show (a file) off a DVR or something encoded as fast as it can go.

The only way you encode a 42 min show at 24 fps in only 36 min, is if the source file is 20 fps to start. Their timer is wrong, their average speed is wrong, or I don't understand what they're encoding (and it might well be the latter).

 

[Sam Posten]

I'm not sure what you are talking about. It takes about 20 seconds to encode a 6 minute song off of a CD with a fast enough reader. Same thing goes for video. Again this isn't an original recording, it's taking one file format (uncompressed .mkv) and putting it in a new file format, including significant, processor intensive compression (.m4v)

 

[mattCR]

Originally Posted by DaveF




The only way you encode a 42 min show at 24 fps in only 36 min, is if the source file is 20 fps to start. Their timer is wrong, their average speed is wrong, or I don't understand what they're encoding (and it might well be the latter).

How do you figure this? When I use X264 to re-encode shows, the frame rate of the original show is meaningless vs. the number of frames it can compress per second.


For example, if I use X264 settings (which Handbrake is a front end for) taking a 1080i source and converting to 720P, Level 4.1 Profile, at a CQ of 20, I can normally encode at about 22fps.

If I take X264 and I encode a 44 minute show that is SD, and I encode it at SD rate (say 720x480) using Level 3, CQ20, I can generally encode at about 189fps.


The encoding rate has nothing to do with the rate at which it is played back or viewed. It is just telling you how many frames per second the encoder can compress

 

[Sam Posten]

For those that geek over specs, the 2.3 quad has been pretty consistantly hitting over 10k on the www.geekbench.com scoreboards which is pretty badass.


I've decided I'm going to jettison the SSD. As soon as my tax return hits I'm stopping in Delaware on my weekly circuit between NJ and MD =)

 

[DaveF]

Originally Posted by mattCR

How do you figure this? When I use X264 to re-encode shows, the frame rate of the original show is meaningless vs. the number of frames it can compress per second.


For example, if I use X264 settings (which Handbrake is a front end for) taking a 1080i source and converting to 720P, Level 4.1 Profile, at a CQ of 20, I can normally encode at about 22fps.

If I take X264 and I encode a 44 minute show that is SD, and I encode it at SD rate (say 720x480) using Level 3, CQ20, I can generally encode at about 189fps.


The encoding rate has nothing to do with the rate at which it is played back or viewed. It is just telling you how many frames per second the encoder can compress

What I'm saying is the math doesn't make sense.


42 minute show broadcast at 30 fps per second has 75,600 frames to encode. Encoding 75,600 frames at 24 fps will take (54600/24) 3150 seconds, or 53 minutes.

You can't encode faster than real time unless the encode rate is faster than the source's framerate. It's algebra.



Maybe ATSC shows aren't broadcast or recorded onto a DVR at a fixed 30 frames per second, like I thought. Maybe the encoding process for H.264 doesn't produce a fixed framerate either, so that, in effect, a significant number of frames are discarded. Because something like that is necessary to encode a 42 minute show at 24 fps in less than 42 minutes.

Like I said, either the fps report is wrong, the encode time is wrong, or my understanding of broadcast / playback (frames) is wrong. I didn't mean to make a big deal about it; but to a causal observer, the reported performance just doesn't make sense


I may have to go the Handbrake forums to find out what the deal is.

 

[mattCR]

Originally Posted by DaveF




What I'm saying is the math doesn't make sense.


42 minute show broadcast at 30 fps per second has 75,600 frames to encode. Encoding 75,600 frames at 24 fps will take (54600/24) 3150 seconds, or 53 minutes.

You can't encode faster than real time unless the encode rate is faster than the source's framerate. It's algebra.

You're overthinking this. I could ENCODE achieving 240 frames encoded to a new compression level. When you play it back, it is played back at 24fps or 30fps. But during the encode process, the only thing that matters is that each frame is processed on it's own, like a flipbook animation and recompressed. You can recompress as fast as the processor can manage it.

To help this make sense: realize when you re-encode the process is this: a file is split into two. Audio / Video. Audio is then re-encoded (or left alone, your choice) Video is then encoded however you want. The rate at which it encodes is not limited by you watching it, only how fast it can be compressed. This is the same as say, uploading a video to Youtube and having it re-encode it for YouTube, etc. It's just a conversion process that works as fast as your processor allows. Then it is muxed back together at the end into a container.