ultrabrutal Wrote:Why should smb out of the window for 1280x688? Because smb takes too much CPU power away for decoding? Then bitrate must be lowered and blocks might appear. Only tests will tell really.
Uh, it's the other way around - because 1280x688 may demand all available xbox cpu resources, leaving none for smb or software audio or ... And what is the point of encoding hi-res blocks?
Quote:Vertical resolution is much more important than horizontal when taking visual image quality for the eye. This can also be seen with 37" and 42" plasmas which has 1024x768 resolution. They won't benefit from the extra resolution.
Maybe some of the horizontal resolution could be scaled away. I know it's not ideal but we don't even have the option of true 1:1 pixel mapping without HDMI. We can only output an analog signal anyways.
As I said in earlier posts, anamorphic encodes will likely be needed in that case - though I continue to discover ways to eliminate overhead and refine encoding parameters, so eventually, once I finish my 2.35's, then the 2.20:1, and the 2.00:1, who knows?
Quote:I really think cutting smb requirement would be sad.
Not to be snide, but as I've stated it isn't *my* requirement. However, if I can accomodate it with the encodes I am doing for myself and am sharing, I will do so (and am doing so with the next encode, even though it means doubling my testing time).
I want to use my xbox to watch HD. Based upon some experimentation I convinced myself it could be done, within limits. I'm now exploring those limits, sharing findings as I go, and applying them. Others are free to build upon my findings and generate encodes that meet *their* requirements, if my encodes don't.
Quote:Regarding your next encode I see it no different than two 1:30 hour movies at 4 gb each - same as Time Machine basicly. Bitrate should be about the same unless ofcourse it has 5.1 audio? 
I think your should look at the other resolutions now also to gain a greater overview than just concentration on one size.
Yes, it has 5.1 audio. Average video bitrate is ~6300kbps vs ~5600kbps for the 1st clip. Quality is Exceptional. And this one presented an entirely differant set of encoding challenges to the first one (which I'll probably reencode and test based upon what I've learned from the second one).
Quote:Regarding PS. I think most will use smb, some upnp (more in the future), virtually none using xbmsp. So I'd be good with just smb support or streeching it to upnp if it's more demanding than smb is.
The point was that someone might take it upon themselves to contribute by DOing this testing and sharing the results. You never know what you will find until you actually TEST something (like my findings about the info window, or about rar file playback).
Edit mplayer.conf, add "benchmark=1"
Create/edit advancedsetting.xml, set loglevel 1
Play file; extract benchmark times from xbmc.log
Repeat, changing one 'thing' at a time
Quote:btw how much time does it take to encode 1.5 hours? I wish I had access to some HD channels.
Depends on the source material, what (if any) filters you apply, and xvid encoding options. On my 1.8Ghz AMD, the encode I am currently working on took ~15 hours 1st pass, and ~25 hours second pass (and there have been several of each). And then of course there is testing time - in this case ~3 hours per test times multiple test cases for each encode. At the moment I'm completing a series of 2nd pass encodes (25 hours each) that span the range of vbv values I've tentatively settled on in order to further study their effect on quant distribution and xbox playablility. Results so far are reinforcing my belief that vbv parameters, while usable, are far from ideal for constraining decoder load.
(I've been toying with the idea of building an mplayer.dll that would log the frame numbers of dropped frames. Not only would it make it easier to study the problem, perhaps this info could be fed into the encoding process. ie do a 'Full quality' 1st pass, then play the file on xbox, identifying specific problem areas. Somehow feed this info into 2nd pass encode adjusting the specific problem areas rather than all 'high bitrate' or 'large framesize' areas)
Oh, and my transport stream source is the net - I don't do the captures myself, I've downloaded all of them...
