home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
MediaPortal 1 Talk
H.264 pre-processing on the TV server
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="knutinh" data-source="post: 138002" data-attributes="member: 14776"><p>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.</p><p></p><p>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.</p><p></p><p>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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p></p><p>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.</p><p></p><p>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 <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile :)" loading="lazy" data-shortname=":)" /></p><p></p><p>-k</p></blockquote><p></p>
[QUOTE="knutinh, post: 138002, member: 14776"] 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 [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
MediaPortal 1 Talk
H.264 pre-processing on the TV server
Contact us
RSS
Top
Bottom