[plugh]

Xbox autodetect is a background process that tries to find other xbox's on your network - automates ftp sharing between them, I believe...

You could try disabling it and see if that improves your playback statistics. (I haven't benchmarked that one, so this is just a guess - I just turn everything off)

Xlink Kai support is under "My Programs" settings.

I have no idea as to your other issues - all those function work fine for me. Perhaps you are seeing oddities like 'brutal did on his system - he ended up reinstalling xbmc with clean settings and all his various problems went away...

[ultrabrutal]

Whats the status? I now have recorded my first HD TS mpeg2. It's split in 2gb files and needs truncating before encoding. It has 5.1 sound

[plugh]

What a long strange trip it's been...

Well, I ended up creating an instrumented mplayer.dll that logs a summary of dropped frames, which allowed me to focus in on those problem sequences.

With this in hand, I started a systematic investigation into the xvid "vbv" mechanism, attempting to derive appropriate values for xbox / xbmc.

In the process, I've discovered a number of, let's call them "issues", in the xvid codec related to the vbv implimentation. This led to ALSO adding instrumentation to the codec so I could figure out WTF was going on.

For example, I added code that checked the 'vbv compliance' of the codec output - only to discover that between the time when xvid applies it's vbv algorithm to the first pass output data and when it actually encodes a frame, it applies a number of other algorithms that very effectively trash the vbv compliance. It appears to be a pretty fundamental design problem...

However, I've made good progress on modifications to the codec which bring it's output back into compliance with the chosen vbv parameters, and things are looking up. I'm still tweaking the code and doing test encodes; once I'm satisfied I'll polish it up and post a binaries kit, perhaps in a week or so.

[Nickman]

[QUOTE=plugh;116781
However, I've made good progress on modifications to the codec which bring it's output back into compliance with the chosen vbv parameters, and things are looking up. I'm still tweaking the code and doing test encodes; once I'm satisfied I'll polish it up and post a binaries kit, perhaps in a week or so.[/quote]

That is f**king great news.
Man i love the time you put into this.
Keep the good work up.

[ultrabrutal]

amazing you are finding errors in xvid codec and even cooler that you bypass the problems making eventually possibly a -xbox switch which gives best possible result for xbox playback

can't wait to test your binary with the ts's I'll record until then

keep it up!

[plugh]

can't wait to test your binary with the ts's I'll record until then

In the meantime you can get started with the toolset, if you haven't already.

Get xvid 1.1.2, virtualdubmod 1.5.10.2, avisynth 2.56, plus plugins (dgmpgdec, decomb, colormatrix, and perhaps degrainmedian) and start figuring out how to put them together and use them with your TS files.

And free up lot's of disk space

[CodeCobalt]

Just my two cents, but can't the actual xbox itself only do 480p? I mean yeah it should be able to play higher, but I believe the hardware capabilities of the xbox is only 480p, so downloading anything higher than that is just a waste as the video quality is being downgraded to 480p regardless of the original content.

[Nickman]

Just my two cents, but can't the actual xbox itself only do 480p? I mean yeah it should be able to play higher, but I believe the hardware capabilities of the xbox is only 480p, so downloading anything higher than that is just a waste as the video quality is being downgraded to 480p regardless of the original content.

The xbox can do 480i/576i/576p(?)/480p/720p/1080i.

[plugh]

Hey 'brutal....

One of the VBV profiles that will be in my codec build has been 'tuned' for smb access. While developing it, I became suspicious that what I was running up against was NOT cpu load exclusively, but network throughput / latency as well. Did some 'back of the envelope' calculations that might be of interest...

Max frame size (typically Keyframes) for my 1280x544 encodes seems to run about 300KB. In order for xbmc to successfully 'do' one of these, it has to read and process it in 1/24th of a second. (There is some elasticity in practice, but this will illustrate the issue).

For it to read that 300KB in 1/24th of a second
300*1024*8*24 works out to approx 59 million bits per second

That is REALLY pushing things on a 100Mbps ethernet connection. Is it possible? Perhaps, under 'ideal' conditions. Try this test...

Go to 'My Files', browse down through smb to your PC/server, select a good sized file, and use xbmc to copy it to the xbox hard disk. This is a good analog of playing a video - you are using smb to 'pull' the file to the system.

Note the data rate displayed during the copy. On my system, I typically get about 5500KB/sec, which works out to approx 46Mbps.

Hmmm... 46Mbps vs 59Mbps - Houston, we have a problem

However, like I said, there is some elasticity; typically that large keyframe is bounded by much smaller frames, and with the cache logic reading ahead you've got some wiggle room - but not much. A sequence of multiple adjacent large frames probably couldn't load fast enough to keep up with the display rate (a similar problem to using the stock dvd drive). Fortunately, you have *some* control over frame size with the codec (at the cost of quality of course).

Anyway, this illustrates the sort of demands these HD xvid encodes make on the system, and why my primary focus is on playback from the local hard disk.

[plugh]

PS - The above is also why I was asked about alternative streaming methods. SMB really isn't designed for this - ideally you want 'push' streaming, not a 'request/response' protocol like smb. Out of curiosity I tried a quick experiment playing a video via the FTP server built into a NAS drive and saw better performance than using SMB.

Is XBMSP protocol/server 'push', or request/response? How about UPNP? Might be interesting to test http streaming as well...

[ultrabrutal]

hey plugh,

as a dev I find it cool that you are modifying the codec and even finding bugs and ways to get around them streaming profiles sounds cool too!

as to keyframes aren't there only one per second? and there is also the cache, so I don't see why XBMC should ever be short on data to decode. but then again I'm not familiar with how XBMC works or mplayer for that sake.

I'm not sure your smb test is correct. When copying you are also saving on the fragmented Xbox harddrive. My test shows less than 4 mb/sec. However when streaming you do not save on the harddrive. The 100 mbit nic is capable of nearly 11 mb/sec and my PC can read at over 140 mb/sec (HW RAID5). Yes SMB can be a bottleneck and I agree that maybe FTP or UPNP should be used instead since Xbmc supports both and so does lots of NAS'es and PC's (if setup). FTP gives me almost 50% more than smb in my test.
XBMSP is not an option in my book since it's not supported by NAS'es.

[plugh]

as to keyframes aren't there only one per second?

Yes, (unless there are rapid 'scene changes') but that was just an example - it is quite possible to get sequences of large P-frames

When copying you are also saving on the fragmented Xbox harddrive. My test shows less than 4 mb/sec. However when streaming you do not save on the harddrive.

So you believe that your hard disk throughput is lower than Ethernet, and is a bottleneck? [/quote] FTP gives me almost 50% more than smb in my test.[/quote] So hard disk WASN'T the bottleneck... and 50% more translates to 6MB/sec? so 63Mbps vs the 59Mbps needed in the example I posted...

The point of my post was simply to illustrate the issues, and your quick tests confirm my point - smb 'streaming' sucks at this level, and 100Mbps ethernet
starts to become an issue at these video frame sizes and peak bitrates.

[ultrabrutal]

even with ftp copying the harddrive is used. I believe there is no bottleneck with ethernet only. 100 mbit is enough for 5 hd streams (18-20 mbit per stream) in theory - saving them to disk is another story.
The bitrate of your encode (Timemachine 4 gb) is much lower than even a single layer DVD (4.36 gb) which Xbmc streams fine over SMB - even a dual layer DVD is fine.
I do not see any problems with throughput since we have a cache to take care of providing a sequence of large P-frames if needed for a while. The decoder has the frames in memory and don't have to wait for every single frame 24 times a second.
If throughput was a problem I think the stockharddrive will be a bigger bottleneck if it's only possible to read at a low bitrate caused by old 5400 rpm drive with heavy fragmentation. In this case I think a defragmented stateoftheart PC/NAS harddrive will be no bottleneck, then there is the ethernet, which ofcourse uses some IO (which the local harddrive does too), however it should be possible for it to get close to 11 mb/sec.

A 8 mb cache in XBMC will hold 27 large 300 kb frames at once. Back in the 90ies when I fiddled with DVD encoding I only saw one big frame per second and when scenes changed, the rest only held the difference.

So maybe your right in the CPU not being the bottleneck. Perhaps it's the harddrive in your Xbox which reads too slowly because of fragmentation or whatever. Ofcourse this could easily be tested comparing the same vid over SMB and FTP streaming. If the problem is gone there, the harddrive was the bottleneck. If the problem is worse, then maybe you're right.

Maybe it's just XBMC's diskaccess which is slow? With Avalaunch and boostmode (FTP enchancement) you would often see speeds over 10 mb/sec.

I hope you figure it out. Keep up the good work

[plugh]

Might as well post what I have, seems stable enough...

Let's try one of those hosting services; links good for 21 days...

xvid-112-xbmc.zip 330KB at http://www.mytempdir.com/1090890
mplayer-xbmc201-logdrops.zip 2.5MB at http://www.mytempdir.com/1090883

All modified sources included with the dll files.
Please read the included changelog.txt files.

Enjoy!

[ultrabrutal]

Cool

I managed to edit my TS files (split in 2 gb chunks) in to one AC3 and a MPV. Movie running about 1.48 at coming in at little over 14 gb.
I tried using MeGUI to build a avisynth script but with little success. Was wondering if you could give us some clues as to what you do to build the script (probably by hand). How yours look and why.
MeGUI did help me to cut the black borders from the frame which there is no need for encoding with xvid.

Here is my stream info:

File Name: D:\TS\06-11-25 - CANAL_ HD - Blade Trinity.VLST
File Size: 20815330672 ( 19.39 GB )
Program Duration: 02:29:03.19 (edited to 00:01:28.06 - 01:50:50.05)
File Type: TS Stream
Encoding: MPEG 2
Video stream Id: 512 (x200)
Encoding Dimensions: 1920 x 1080
Display Size: 1920 x 1080
Aspect Ratio: 16/9
Frame Rate: 25.00 FPS
Bit Rate: 17.500 Mbps
VBV_Buffer: 976 KB
Profile: Main/High
Progressive: Prog or Int
Chroma: 4:2:0
Audio Format: Layer 2
Audio Stream Id: 640 (x280)
Audio Bit Rate: 256 Kbps
Audio Sampling Rate: 48000 Hz

Intra Quant Matrix
8 16 43 70 106 115 133 178
16 16 70 88 115 133 178 205
43 70 106 115 133 178 178 214
70 70 106 115 133 178 205 232
70 106 115 133 160 187 232 255
106 115 133 160 187 232 255 255
106 115 133 178 214 255 255 255
115 133 187 214 255 255 255 255

Non-intra Quant Matrix
16 25 34 43 52 61 70 79
25 34 43 52 61 70 79 88
34 43 52 61 70 79 88 97
43 52 61 70 79 88 106 115
52 61 70 79 97 106 115 124
61 70 79 88 106 115 124 142
70 79 88 106 115 124 142 151
79 88 97 115 124 142 151 169

NB! This info was grabbed while using 2 channel. I redid my edit with AC3 (5.1) but didn't take a new info.

tnx