Xbox One (Durango) Technical hardware investigation

Status
Not open for further replies.
Nope. But what other use is there for it? Media is already compressed. Short of steaming media from console to mobile-connected PC, recompressing in HEVC makes little sense. The image also shows what I guess is the XB1 storefront on two PCs (implied desktop and laptop). Can anyone confirm that?

2 of the things mentioned with regards to XBO steaming to PC are games and live TV (one of their examples is being able to stream live TV to your PC while someone on the XBO is playing a game).

But again, I don't really see why you would need H.265 for that when H.264 should be just fine, even over most people's wireless connections.

Regards,
SB
 
on the DVR side of things I was thinking about recording. Saving on space but keeping up quality. Even with external drive support people seem to be filling them up quickly. So not essential but would be a big plus.

streaming over net would benefit from h265 if ever they decide to go there.
 
Who knows. The same asinine reasons AMD have only just confirmed PS4'd DSP is based on TrueAudio? Why wait to reveal that?
Huh? This was known end of 2013. In fact I can't find anything more recent! And also it was decidedly unclear if it was a full fat TrueAudio or just parts of it. I believe this was discussed at length in the Console Audio Tech thread.
 
Huh? This was known end of 2013. In fact I can't find anything more recent! And also it was decidedly unclear if it was a full fat TrueAudio or just parts of it. I believe this was discussed at length in the Console Audio Tech thread.
I must have missed it!
 
on the DVR side of things I was thinking about recording. Saving on space but keeping up quality. Even with external drive support people seem to be filling them up quickly. So not essential but would be a big plus.

streaming over net would benefit from h265 if ever they decide to go there.
Encoding TV may not be such a bad idea either, especially if MS wants to go forward with this streaming TV to your devices bit. Whatever saves on bandwidth makes certain things more accessible in the near future.
 
if they do implement DVR functionality I wouldn't be surprised if they give the option of recording different levels of quality. Could be that transcoding/reencoding once to h265 would still be better than h264 at medium/low settings.
I don't see that link really proving anything apart from you wouldn't want to do it 100's of times. (which you wouldn't be doing)
 
Last edited:
How about a relevant comparison instead of a completely exaggerated one? This reminds me of the various scientific tests - we gave rats 1000x the recommended daily allowance of x / irradiated them with 1000x the amount of radiation from a mobile and they died, proving x / mobiles is bad!
Lol forgot about that. Is OTA encoded?
Yep, and the most sensible option seems to be just dumping the compressed video stream and then streaming that directly. this came up in one of our older discussions on HDD and recording overhead, although no idea. IIRC there was actually a reason why a straight dump of the OTA broadcast wasn't possible, but I don't recall why and may be remembering that wrong.

However, H.265 is still pretty redundant in that case. It'll save HDD space but at considerable cost, unless the (imagined) hardware encoder is trivially cheap. XB1 supports external storage so HDD space isn't a primary concern. It'll also save bandwidth where BW doesn't particularly need to be saved unless the intention is streaming to remote locations maybe.

It seems hard to me to accept that the engineers in 2011/2012 decided to implement a cutting edge codec that may change before it sees use for a feature that might see action, maybe, in limited cases of streaming content they didn't know what. If we're to take the AMD slide at face value, maybe we're talking about a new XB1 SKU with DVR functionality, the fables STB oft rumoured?
 
Yep, and the most sensible option seems to be just dumping the compressed video stream and then streaming that directly. this came up in one of our older discussions on HDD and recording overhead, although no idea. IIRC there was actually a reason why a straight dump of the OTA broadcast wasn't possible, but I don't recall why and may be remembering that wrong.

I'm not an expert but I recall digital transmissions are encoded in a packeted format like MPEG-TS and MTS suitable only for broadcast. There's no index (so no scrubbing should you dump a bitstream and want to FF/RW) and quite often the stream will contain multiple programmes. I guess this is why DVRs will decode the stream then re-encode for it for saving to HDD.

It'll take a very long time for H.265 to displace H.264 because the latter is now ubiquitous. H.265 is essential if you have to encode/decode 8K video or if bandwidth is an unsolvable limitation. Decent 4K video is still rarer than yeti shit! ;)
 
So the image doesn't show anything XB1 running on PC? Even more reason to doubt it.
The image sort of sucks. It reads Xbox One to PC. Not Xbox to PC: which would have been a dead confirm for your point.

In any event I liked your previous assumption on another possible SKU, or just some sort of DVR capability (in which GPU/CPU resources) can be leveraged to record TV for later.
 
One question for everyone: we've been discussing compressing a specific source into HVEC all this time up till now.

But the question is about whether HVEC is being used for game streaming from Xbox to PC. Which we postulate is only possible with fixed function encoder. I want to ask the following:

Is it possible to have the game write to a compressed buffer directly in the render pipeline? So that no conversion is required for game steaming?
 
Well there is still this third esram block and the unidentified things next to the cpu cores ... but i think we will never know what those are good for
 
I'm not an expert but I recall digital transmissions are encoded in a packeted format like MPEG-TS and MTS suitable only for broadcast. There's no index (so no scrubbing should you dump a bitstream and want to FF/RW) and quite often the stream will contain multiple programmes. I guess this is why DVRs will decode the stream then re-encode for it for saving to HDD.

The container isn't that big of an issue. The stream has to integrate details of what it contains as viewers are typically joining it mid-stream when they tune to the channel. You can parse this information along with the total file size to determine the duration, etc. It just makes all of that stuff a little slower than it would be with a proper index in the file header. Multi-program streams are typically handled by a simple remux.

The main reason to decode/re-encode is smaller file size.
 
One question for everyone: we've been discussing compressing a specific source into HVEC all this time up till now.

But the question is about whether HVEC is being used for game streaming from Xbox to PC. Which we postulate is only possible with fixed function encoder. I want to ask the following:

Is it possible to have the game write to a compressed buffer directly in the render pipeline? So that no conversion is required for game steaming?

Compressed to HEVC? This wouldn't save any processing. HEVC encoding (and to a lesser extent decoding) is processor intensive. There's no way around throwing major compute resources or dedicated silicon at it. And if not HEVC, it seems a waste of engineering resources to not just use the dedicated H.264 encoder that *is* present.
 
You can parse this information along with the total file size to determine the duration, etc. It just makes all of that stuff a little slower than it would be with a proper index in the file header.
It's not a little slower, it's a metric tonne slower because to show video as your dragging the scrubbing bar, it's not just reading a few frames to display a preview frame it's having to read, in most cases, several seconds of proceeding frames. It's runs like dogshit even with a fast SSD. Indices for video aren't there for fun ;)
 
Status
Not open for further replies.
Back
Top