H.264 pre-processing on the TV server

[kellizer2]

Excuse my ignorance, but why can't the TV server undertake Pre-Processing on the H.264 transmission prior to being streamed to clients?
From reading up on the issue - the H.264 codec is cpu intensive as it compresses large volumes of data into smaller packets thus taking large volume of processing power to decompress - if the transmission was processed (or partly processed) on the server then part processed (but large data stream) could then be passed to the clients for the final rendering.


The reason that I ask is that the TV server could potentially take the brunt of the processing while watch HDTV thus leaving the clients to be not as powerful (thus not as expensive, noisy etc). If this was possible, then I could even us a mac mini as the main client in my living room and watch HDTV!

Does this make sense - and theoretically, is the above concept possible?

Many Thanks,

Ian.

 

[knutinh]

Basically, any video codec consists of transforming video pixels into a more flexible format, reducing the presicion, then encoding the remaining information as a smallest possible bit-stream.

I have never heard of splitting the decoding process up into parts like you are suggesting. First, the initial stage of a decoder is unpacking data, nor something you would usually like to do prior to a local ethernet/wlan connection. Second, there is a feedbackloop where old decoded frames are stored for future prediction. This means that a "desentralized" decoder would have to transmit large amounts of data bidirectionally.

In addition, debugging a single monolithic decoder for any compliant (and noncompliant) streams is some work. Doing the same for a splitted thing, possibly handling several different standards.... Ugh


I think what you are asking for is a tv-server transcoder that will transcode bandwith-efficient h264 to cpu-efficient MPEG2 (or even M-JPG). I dunno any numbers, but it is conceivable that a tv-server could decode any stream, do resizing/samplerateconversion/etc, and encode the result in a new format that is optimised for cpu-use instead of bandwidth use.

This all depends on local network being sufficiently fast, and MPEG2 delivering better picture than h264 for a fixed cpu-cycle count (h264 clearly delivers better picture for a fixed bit-count). I cannot guarantee neither

-k

 

[kellizer2]

Please let me give you a background to the question. I would really like to have HDTV in the lounge but not have a dual core processor that is normally required to process the codec. Doing research, it seems that you are not going to get a slick, quiet HTPC that can also handle the H.264 codec.

Also, your not going to be-able get/build a htpc system as slick as the MAC MINI, but going with a mac mini would eliminate the possibility of HDTV now, or in the future.

So, I be racking my brain for alternatives, one is to offset the processing to the server - thus allowing for CPU efficient processing on the client. another could be to allow for a hardware implementation of the processing of the codec (http://www.pbs.org/cringely/pulpit/2007/pulpit_20070308_001806.html) - but this implementation if true, would never make it across to the windows platform, as Apple do not really condone the use of the windows platform of the mac platform let alone support proprietary hardware on the windows platform.

I can't think of any workable alternatives that would give me the set-up described.

 

[flokel]

Being equipped with an intel core duo the mac mini should be able to play .h264 files,
shouldn't it?

 

[knutinh]

I do believe that slick, low-noise hd-capable HTPCs are possible. Especially as long as you stick to "broadcast" HD 720p/1080i h264/MPEG2 at medium bitrates.

BluRay h264 disks at 1080p24 with bitrates peaking at >41mbps is probably more work. Even there, a core2 duo 6600 with somthing like an nvidia 8600 graphics card is probably going to rock with the proper playback software. And this setup can b put into a reasonably slim, quiet box.

-k