Just wondering what is preventing the Apple TV from streaming larger than 4 GB files. If iTunes get HD quality files, then will ATV be upgradeable?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Why can't ATV stream over 4 GB files?
- Thread starter princealfie
- Start date
- Sort by reaction score
Guess it must be to do with the actual units specs, probably can't handle anything that large for some reason even though it's just streaming the content? Maybe its the bit rate that could be too high or something?
But I thought that the graphics card in the ATV kicked butt?
depends on whose butt it belongs to.
anyway, I doubt graphic card is the key to the problem.
No. You can use larger files. But FAT32 has that limit. And Apple TV has to work with Windows. I don't know why it would be FAT32 since it doesn't matter over the network.
This is a bug in iTunes, not just the Apple TV.
Try streaming that 4+GB file to another Mac using iTunes... it won't work. This bug has been around since 7.1, and 7.0.2 couldn't stream files larger than 2GB. Apple is aware of the issue, but who knows when the fix will be available. It will likely require both an iTunes update, and an AppleTV update, but it is a software bug, so an update is a realistic possibility.
Try streaming that 4+GB file to another Mac using iTunes... it won't work. This bug has been around since 7.1, and 7.0.2 couldn't stream files larger than 2GB. Apple is aware of the issue, but who knows when the fix will be available. It will likely require both an iTunes update, and an AppleTV update, but it is a software bug, so an update is a realistic possibility.
The processor is 32 bit and has a 4gb file size limit. It needs a ZFS for Pentium upgrade.
Rocketman
No it doesn't. HFS+ handles files larger than 4GB, and so does Quicktime. As stated above, this is an iTunes bug that Apple is aware of. (I filed the bug myself)
Is this truly a "bug" or is just a hold-over from code (QuickTime?) originally written using 32-bit pointers/variables?
Quicktime can play the file, as can iTunes. You try to stream it, and it doesn't work. iTunes bug... streaming protocols shouldn't be having this sort of arbitrary limit in the first place.
Now, you do have a point, as it is related to the limit of 32-bit pointers/addressing. This limit creates the bugs where iTunes can't tag a large file, and Quicktime can't export a large movie file (depending on the file format, ironically... DV has no issues, while anything that needs flattening like a MOV or MP4 doesn't work). But writing to files has a lot of ways to get around the limit, so 32-bit is not an excuse, because it is possible to do it... ffmpeg does it, for example. Heck, Apple even wrote the guidelines on how to deal with files larger than 4GB on the Mac.
But, the core of the matter is that it should work. Because it doesn't work, it is a bug or a code defect. Where I work, any /new/ behavior is a feature change, or a new feature. Any unexpected behavior or limit in an existing feature is a bug.
Quicktime doesn't serve files, so that is a loaded question. You need something that can stream the files as a server before you can say if the client can stream it.
iTunes can read and play the file. If you can read the file, you can stream it. Streamed data isn't like reading pointers, as addressing should not be absolute. When streaming content, you tell the server, "Okay, next packet", or "Gimme what you sent 5 packets back", or "Skip the next 5 packets and gimme what is after that". You don't say "Gimmie packet #5" unless you are planning for failure. So, 32-bit limitations should not apply, and even if they do, a prototcol should /really/ not be using byte addresses, and instead talking packets. If it is talking packets, then the limit would be larger than 4GB.
The behavior I have seen with iTunes is that a large file (>4GB) will attempt to play on the client, but the server won't send data, and the attempt to play the file over the network times out. That to me tells me the server is doing something bad.
Quicktime doesn't serve files, so that is a loaded question. You need something that can stream the files as a server before you can say if the client can stream it.
Yes, I realize that, but can Apple's Darwin (open source) or QuickTime Streaming Server/QTSS (commercial) streaming servers stream a >4GB file?
Just wondering if this bug extends beyond iTunes...
Yes, I realize that, but can Apple's Darwin (open source) or QuickTime Streaming Server/QTSS (commercial) streaming servers stream a >4GB file?
Just wondering if this bug extends beyond iTunes...
Haven't tried... but if it does exist there too, then it is coincidence. iTunes uses a different protocol to stream, AFAIK.
Yeah, I realize that. But often times internal variables or fields were defined as being 32-bit wide (max) back in the days before 64-bit long int's or pointers were available. MySQL's key_buffer variable is one such example that cropped up a while back...
iTunes uses the QuickTime API tho', doesn't it? (I don't know... just asking... I assumed it did...) The QuickTime API was originally written before HFS+ and large file support existed, and the QuickTime API is still 32-bit, although the QTKit framework is 64-bit.
Quicktime doesn't serve files, so that is a loaded question. You need something that can stream the files as a server before you can say if the client can stream it.
iTunes can read and play the file. If you can read the file, you can stream it. Streamed data isn't like reading pointers, as addressing should not be absolute. When streaming content, you tell the server, "Okay, next packet", or "Gimme what you sent 5 packets back", or "Skip the next 5 packets and gimme what is after that". You don't say "Gimmie packet #5" unless you are planning for failure. So, 32-bit limitations should not apply, and even if they do, a prototcol should /really/ not be using byte addresses, and instead talking packets. If it is talking packets, then the limit would be larger than 4GB.
The behavior I have seen with iTunes is that a large file (>4GB) will attempt to play on the client, but the server won't send data, and the attempt to play the file over the network times out. That to me tells me the server is doing something bad.
Man, you are hilarious... streaming eh?
Man, you are hilarious... streaming eh?
Yep. Streaming. QuickTime technologies include: streaming and according to Apple, QuickTime technology "empowers the development of innovative software such as iTunes, iMovie and Final Cut Pro..." Per Wikipedia, "FairPlay is a digital rights management (DRM) technology created by Apple Inc., built in to the QuickTime multimedia technology and used by the iPod, iTunes, and the iTunes Store. ... While the iTunes jukebox remains the most popular method to buy and play FairPlay-protected files, the actual decoding is performed by Apple's QuickTime."
The Quicktime API is still 32-bit, but files aren't accessed using byte addresses (at least when reading with the exception of MPEG-2 formats, and some critical file formats do the right thing while writing as well, such as DV and a few others).
For example, the Quicktime and MPEG-4 file format are both made in such a way that the concept of a pointer doesn't exist when dealing with the file. You only deal with field lengths. So when you read the file, you read how long the next nugget of data is, which lets you skip around the file pretty effectively. The only reason a 4GB file limit comes into play is when you are writing the file, and use absolute, rather than relative, seeking when writing the file.
(My streaming comment was originally trying to point out that there is no streaming app built into OS X to try against, and there is no 'one Quicktime streaming server implementation to rule them all'... you pretty much have to author your own streaming server)
As for streaming, if we assume that iTunes uses something similar to RTSP for the actual stream, then 32-bit isn't an issue here, either. Addresses are described using time stamps, (0:00:00.00 being the start of the movie). And as Quicktime can arbitrarily jump to a particular timecode in a 5GB movie... RTSP isn't a limitation here either. It is simply that iTunes has a bug where a programmer assumed there was a 32-bit limit on the filesize somewhere
EDIT: I think I figured out what the bug is related to... DAAP, unlike RTSP, does use byte ranges in the streaming packet requests. The good news is that this byte range in DAAP is a string, so the protocol itself has no built-in limit. The downside is that this means that iTunes either needs to:
1) use 64-bit addresses, and 64-bit APIs (not an option, per se)
2) use 64-bit addresses (which is possible on 32-bit systems, via the long long C integer type), and use relative file addressing when running on 32-bit systems to get around the 4GB limit with absolute addressing when reading the file.
That sounds logical. You may have nailed the source of the problem. It does seem logical that DAAP, or some new variation on DAAP, is likely the protocol used to stream to the (stock) Apple TV client.
I did come across a reference to a 4GB limit for QuickTime MPEG-2 files
DAAP is used for iTunes streaming all the way up to iTunes 7, and adding a new handshake for the PIN (to trust the host) is not a huge deal.
There are a couple reasons for that... the spec for MPEG-2 program streams doesn't allow for files larger than 4GB (IIRC). Either that, or I am losing it.
My only question is why would you be streaming a 4GB video to the 
TV? Just curious.
EDIT: Of course, we could be talking Lord of the Rings: The extended edition. Just thought of that.
TV? Just curious.EDIT: Of course, we could be talking Lord of the Rings: The extended edition. Just thought of that.
