Comments on: Some Thoughts on 1080p

By: younker

younker — Wed, 31 Dec 2008 03:24:09 +0000

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.

By: Gamester17

Gamester17 — Mon, 24 Mar 2008 20:30:50 +0000

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.

By: H264

H264 — Mon, 24 Mar 2008 12:47:42 +0000

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?

By: Magnusjt

Magnusjt — Mon, 24 Mar 2008 09:41:02 +0000

well done, guy

By: dj

dj — Mon, 24 Mar 2008 00:56:24 +0000

Interesting find?

http://www.corecodec.com/forums/index.php?topic=711.msg5063#msg5063

By: LaLocaChica

LaLocaChica — Tue, 11 Mar 2008 08:22:06 +0000

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

By: elan

elan — Tue, 11 Mar 2008 03:10:00 +0000

@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.

By: jonny_eh

jonny_eh — Tue, 11 Mar 2008 02:47:07 +0000

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.

By: bask3tkase

bask3tkase — Mon, 10 Mar 2008 23:58:22 +0000

@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.

By: Tomato

Tomato — Mon, 10 Mar 2008 20:14:04 +0000

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?