+ Top FAQs with Plex - for more help please check the WIKI.
- How do I add internet video such as TED, YouTube, CNET etc?
- Internet sources are added using the App Store found in the Applications menu. See the following screencast for more info. vimeo.com/3315184
- One of the plug-ins has stopped working.
- If a plug-in stops working, it’s likely that the structure of the site changed. This doesn’t happen very frequently with most sites, but it’s a definite possibility. When this occurs, an entity we call the “Campfire Robot” springs into action automatically and tracks us down to let us know, and shortly thereafter we can push an update. As such, if a site stops working, the best thing to do is to check the App Store for updates. If you have automatic updates turned on, check your install history to see if an update got installed while you were getting coffee.
- I don’t see the Applications Menu Item.
- If you previously used v5 of Plex we suggest deleting the folder called Plex found in ~/Library/Application Support/. Many things have changed and a fresh install will ensure the best performance with Plex.
- How do I make Movies and TV Shows show up in their respective areas with poster art, plot info, etc?
- View this screencast for more info vimeo.com/2758185
Some Thoughts on 1080p
After reading John’s excellent post over here, I got to thinking about 1080p content (or “difficult” content, really) and how we might be able to better handle it. To begin, let’s go over the numbers:
- A typical uncompressed 1080p frame takes up 3 MB (megabytes). This is full resolution for the Y plane, and subsampled U and V planes.
- This means that a single second of uncompressed video (24p) takes up almost 73 MB.
That’s a huge amount of bandwidth, compared to the compressed video. An episode of Lost I’m watching right now is hovering around 8 Mbps, which is 1 MB/sec. This is a pretty impressive compression ratio, and there also a few possibly interesting takeaways from it:
- Streaming uncompressed 1080p content over Gigabit Ethernet is theoretically possible, but only just barely.
- Streaming uncompressed 1080p content off a typical hard drive is theoretically possible, but again, only just barely and only in “best case scenarios”.
Most of the problems we run into playing 1080p video content have to do with two the combination of two things:
- The existence of bursts of high bit-rate frame sequences (some only a second or two long, some 10s of seconds).
- The fact that we do real-time decoding, so if a frame is late, we drop it.
So here are some random ideas that were running through my head as I woke up this morning:
- Decode buffer: Disk buffers work to smooth out arrival jitter in data from the disk, so we don’t we have a decode buffer to smooth out arrival jitter in the decoded frames? That way, if we run into a frame sequence where we would get behind, we can simply empty frames from the decode buffer. Since the CPU is usually ahead, we could simply decode as fast as we can, and accumulate some number of pre-decoded frames (in RAM). To keep 2 seconds of decoded frames would cost about 150MB of RAM, which is chump change these days. And even if we pre-filled the buffer before playing, the pre-roll delay would only be increased by at *most* 2 seconds.
- Grid computing: Harness the power of your idle computers and have them decoding frames for you. The problem is the extreme bandwidth of the decoded frames, as mentioned. But perhaps apply some high quality MPEG-2 compression, and it becomes much more manageable. Presumably they could decode sequences between keyframes.
- Sidecar Preprocessing: Since MPEG-2 is easier to decompress, why not simply run a preprocessor over H.264 files? Any spots that are higher than a specified bitrate would be pre-decoded, encoded to high quality MPEG-2, and then stored in a “sidecar”, alongside the original media. Imagine “Planet.Earth.01.mkv” and then “Planet.Earth.01.mkv.sidecar.00:02:01-00:02:40.mpeg2″ (assuming the sidecars start and end on second boundaries). The sidecar format could be anything appropriate, and it wouldn’t have to store audio or other metadata (e.g. subtitles). Best of all, they could be whacked at any point or recomputed.
EDIT: Of course, the sidecar media could also just be lower bit-rate H.264, that way ffmpeg wouldn’t need to be any the wiser.
Hope you’re all having a great weekend.
24 comments24 Comments so far
Leave a reply
Side car sounds like a great idea. Do container formats support something like this?
If you do sidecar, you probably don’t need decode buffer, at the expense of disk space.
Interesting.
Just like to throw out there that my 2.0Ghz Core Duo (not C2D) plays EVERYTHING i throw at it short of the “bird scene”. So i guess thats good to know for the prospective Core 2 Duo mac mini buyers. My machine is an iMac so the video card is a x1600 256Mb, would that help at all?
I have 3 movies that don’tplay atallinXBMC
kung fu hustle
the matrix
300
all 720p,all by ESiR.
anyone got any ideas why?
@steve jobs: I expected more from you, Steve. Without knowing more (Does it crash? Just not play? What does the log say? Where can we download samples of these videos?) I can’t help out more.
Are you proposing to keep the decode buffer in the graphic RAM or the system RAM? I think the benefit of keeping it the graphic RAM is that you do not have to copy from the system RAM to the graphic RAM, the downside is if you plan on using a 150MB decode buffer then you really have to have a graphic-controller with 256MB of RAM dedicated to to be able to take advantage of this, most modern graphic-controller have this or let you assign system RAM to be used dedicated for graphics. In any case this does sound like an interesting idea if you could get the audio and video to always stay in sync with a system like this.
I do not like the grid computing nor the sidecar ideas even though that is kind of used today by some systems, for example TwonkeyMedia and Nero which transcode 1080p video on a fast computer then transcodes it to 720p before sending it to the media extender, also the DivX Connect decodes on the computer and send to the media extender.
Would not your time be better spent trying to figure out if any of the decoding processes could be offloaded to the GPU with GLSL shaders and optimizing the video decoders via new Streaming SIMD Extensions (SSE) which modern GPUs and CPUs support?
@DeepThoughts: It doesn’t matter what RAM we’re using, although I think video RAM is silly. We can decode AND move data from system RAM, so we can certainly just move it.
The sidecar idea is not simple transcoding, which does of course suck. It’s bitrate driven partial transcoding, which lets you see the video in HIGHER quality than you otherwise would be able to, and only for the sections that you can’t “natively” decode.
My time is spent doing the things I know how to do. I have no clue how to write complex signal processing code in SSE3. Besides, the advantage of a decode buffer is that it allow perfect playback of problem areas beyond the “means” of the processor. If you simply optimize the code, you’ll still be screwed when a REALLY hard section comes along and you’re trying to decode it in real time.
The infamous “bird scene” is a worst case scenario, and I’d rather see development time go towards improving the overall experience for most/all cases rather than focus on very content-specific problems.
The underlying problem is simply a lack of CPU power. The new Penryn CPUs (which should be showing up in the Mac Mini any day now) support SSE4, which I would assume ffmpeg would be able to take advantage of shortly. By the end of 2008, all Penryn and later processors should be able to handle whatever is thrown at them, so this problem will be short-lived anyway.
Grid computing will require separate functionality on the streaming machine (which means probably needing to support multiple operating systems, since I bet that a lot of people use Linux for their fileservers)–I’m not sure that this is the direction I’d want to see things move (though it’s not my project, obviously.)
Sidecar is an interesting idea, since the processing could be done ahead of time on the Mini (let’s face it, everyone’s probably running this on a Mini, right?) The trick would be getting it to be seamless. If you can manage that, it sounds like a neat addition (and something you might try getting into the trunk of XBMC.)
I’m hoping that the new Penryn CPUs are compatible with the Mini so that we can just drop them in, but regardless, I hope that OSXBMC development won’t only target these new CPUs. I haven’t had a chance to mess with it much, as I don’t have a Mini yet (I was waiting for downmixing support to buy one) but there are going to be a lot of people with the older Minis.
sancho:
I can’t imagine that the new Penryn CPUs will be socket-M compatible, considering that even the last iterations of the standard core2duo were themselves not socket-M.
Is there something I don’t know about Penryn that makes you think it will be drop-in compatible with an existing core2duo Mac Mini ?
confirmed… penryn is socket-P and your existing Mac Mini is socket-M, so if you want a penryn Mini you will have to wait for apple to release it…
@Brandon: You’re missing the point of the “decode buffer” method. Right now, decoding in real-time, any optimizations you do affect the *peak* bitrate you can handle (because you have to be able to decode every frame in less than 1/24 of a second).
If we had a decode buffer, the peak bitrate we could handle could jump up tremendously, because (let’s imagine), while the processor crunched away on a few hard frames, the player would smoothly display the already decoded ones that were in the buffer.
So when decoding in real-time, your optimizations push up the peak a bit, but it’s a hard ceiling. With frame buffering you can handle huge peaks (assuming they’re short).
Cool, I was under the impression ffmpeg already used a decode buffer to some extent? I guess it is just a file buffer though. The Xbox version certainly could use a decoded buffer, but that pesky 64MB of RAM is a problem.
I am still waiting for Netflix to deliver the first of the Planet Earth discs. I look forward to seeing how the PS3 handles this “bird scene”!
Yeah XBMC currently only has a file-buffer which only deals with harddrive, DVD-ROM drive, and more importantly network latencies, that is why adding a decode-buffer could make a lot of sense.
It would not be possible to have a decode-buffer on the Xbox though because of the 64MB RAM limitations, but it should be possible on the OS X, Linux and Windows versions of XBMC.
Since XBMC is so memory efficient anyway, dedicating 128MB or even 256MB of RAM to a decode-buffer should not be a problem if your computer has a total of 1024MB of RAM or more, right?
Maybe the decode-buffer could be user-configurable in the XBMC GUI settings, like the current file-buffer is.
I’ve just stumbled upon XBMC after getting accustomed to a bunch of half-solutions on my MacBook…
The buffer idea sounds absolutely fantastic. My MacBook seems to handle most 1080p stuff well except for when there is, of course, some quick action or lots of little moving detail. Any boost to get it over the bitrate hump with 1080p content would be wonderful.
The sidecar idea I’m not so sure of because a) I’d prefer to maintain video quality first, if possible, and b) I presume I’d have to wait for the sidecar files to be generated, right?
Anyways, great work…
I am no computer expert, but it seems that a lot of people are misunderstanding the sidecar idea. Either that, or I’m stupid.
Here is my concept of how it works:
1. You press play on your file.
2. The file starts playing.
3. The code at the same time does a quick scan through the file bitrate.
4. High bitrate sections are identified. (i.e. sections where a frame can’t be processed in real time)
5. These sections are assigned for intensive work, and the completed work is stored separately in a ’sidecar’.
(your video is still playing while all this is happening)
6. When the file which is playing gets to an high bitrate section, instead of dropping frames or dropping down to a lower quality, the pre-processed segment is used instead, to maintain image quality.
7. That’s it!
A lovely use of the dual core principle. If you’ve got two cores, use em!
The only problem is with files with high bitrate frames right at the start, but most files start with black frames or credits. In the worst case, a pause of a few seconds before starting might be needed.
Am I right?
@Tomato, I assumed it would need a one-time pass before playback happens only because I, again assuming, there would not be the luxury of using an entire second core to do the work since this issue emerges from a lack of CPU cycles.
Of course, I as well am not a computer expert…
Also, sidecar plausibility aside, buffering the frames at faster-than-real-time to memory for later playback seems to be more elegant and flexible to me in that it could protect smooth playback from many causes of lag – CPU, disk, network, etc – that can happen at any moment.
The decode buffer sounds like the simplest solution with the most chance of success, with the smallest side effect.
Possible implementations:
1) Just have a setting in the GUI where you can set the size of the decode buffer.
2) Have XBMC increase the size of the buffer by a certain amount each time a frame is dropped, up to a maximum size.
3) 2 would have the problem of encountering dropped frames before the buffer kicks in, so maybe a smarter algorithm based on CPU usage can be made to guess if a buffer will be needed. i.e. if the first CPU core is maxed out, assume that a 3 second buffer will be needed, 4) Combination of 2+3. Use the 3 algorithm, and if frames drop use 2 as well.
@Brandon: Yeah, just a file buffer, a decode buffer would be implemented at a higher layer.
@Tomato and bask3tkase: I was deliberately vague about the implementation of the Sidecar method, but I had been assuming that a preprocessing pass would be necessary. That would be the easiest way to ensure that the video was prepped and could handle random seeks, etc. Note that it might not take more than a minute or five to run, and could even be implemented as part of the download postprocessing, i.e. par, unrar, sidecar. Hey, it even rhymes!
@jonny_eh: I believe the decode buffer would be fairly easy to implement, and give a big win in common cases. Even going from 100 dropped frames in a 1080p movie to 0 would be awesome, because that means that 2-3 scenes that looked “messed up” would now be perfect.
if I could I would look at the decode buffer idea first
since that would be cross-portable you could get developers of the other XBMC platforms to help you out or at least bounce ideas with them 
Interesting find?
http://www.corecodec.com/forums/index.php?topic=711.msg5063#msg5063
well done, guy
Mac OS X users maybe have some hope, Accelerator kernel module for RadeonHD cards:
$strings ATIRadeonX2000 | grep UVD
ATIUVD
UVD related register dump begins
UVD*:
UVD_RLC_CONTROL: %x
UVD_CONFIG: %x
and so on…
According to some info in X2000 VA bundle, Apple has ATIHDVADriver bundle, which maybe intended to allow apps utilize ATI UVD (Universal Video Decoder) Video Technology functions, it is not public it seems.
But how to activate and use that in FFmpeg and XBMC?
I really like the idea of having a decode buffer (and the existing file-system buffer), hope that you can make that happen Elan, and that your implementation will be portable to across the other XBMC platforms as well
…hope that you can prioritize looking deeper into this cencept
I for one would not mind ’sacrificing’ up-to 256MB of RAM for such a decode buffer, as long your computer have 2GB or more of total memory then then that should not be a problem.
Now I use Plex 0.7.5 to play some 1080p x264 movies on my macbook pro 2,0 with an external 1080p HDTV, but there are some frames dropped during the playback, the video card is mobile x1600 with 128M RAM, but I think maybe the decorder is not effient enough to decode the videos, so it is better to make a large decode buffer and pre-decode it.