Weird playback in XBOX Media Centre with Staxrip and X264

[batfink]

Hi, i posted this the other day in the Staxrip forum..It might be a strange X264 bug..I'm not really sure
http://forum.doom9.org/showthread.php?p=871258#post871258

Anyway, since then i've managed to replicate it in smaller files (10 meg)
.
http://web.newsguy.com/batfink/SG1-901-528x288-X264-516.mp4
(this one is 528x288 created using X264 -516)

http://web.newsguy.com/batfink/SG1-901-528x288-X264-558.mp4
(This one is 528x288 created using X264 -558 (latest)

http://web.newsguy.com/batfink/SG1-901-560x304-x264-516.mp4
(560x304 created using X264 -516 - Working)

Both of the lower resolution clips 528x288 exhibit the weird speed up on XBMC at time frame 1:32

The Higher resolution clip 560x304 plays perfectly. All 3 clips are from the exact same source..All the settings are exactly the same except for the resolution.

Now i know its not a bitrate problem cause if it was, it would show up in the higher resolution clip.

Has anybody else ever had this happen before..I've looked through the XBMC threads here and most deal with the stuttering you get from frame loss..this is not the case

[Sharktooth]

The problem is the limited CPU of the xbox.
There are just some movies that wants faster CPUs.
The bitrate distribuition comes into play also. Where are peaks in bitrate the CPU "suffers"... and problems may appear.
Or maybe it's a bug in XBMC splitter/decoder ;)
Does that speedup happen on a PC? If not, then blame XBMC.

[batfink]

No, its not a CPU problem.
No its not a bitrate problem.

If it was, then the problem would appear on the Higher Resolution clip.

These were encoded using Constant Quality therefore when you increase the Resolution, the Bitrate is increased to maintain picture quality..Therefore any kind of bitrate shortage would appear in all the clips...

This is not stuttering like you would expect to get from bitrate shortages..The picture will corrupt for a fraction of a second and then suddenly the framerate will jump to 40-50 fps.

A bitrate shortage will not cause this reaction.

Its definitely something to do with XBMC and X264..They play back fine on the computer and Mencoder's LAVC codec at the same resolution produces no problems (although i couldnt get Mencoder to produce quality even close to X264)

Ps, i can encode the same clip at a much lower bitrate and it will still go crazy...As long as its in 528x288...change the resolution to higher or lower and that glitch vanishes

They dont play back like that on the computer..but i dont use Mplayer to play things on the computer...I use Media Player Classic...For all i know it could show the glitch if played back with Mplayer in Windows or Linux..

Did you D/L one of the faulty clips..What do you use to playback H264 clips

[nm]

No problem playing them back with MPlayer here.

[Sharktooth]

If the h.264 stream plays ok with the many decoders available on the PC (including the reference decoder) then it's a XBMC issue.
XBMC is based on mplayer but remember the XBMC guys have optimized a lot of stuff to make it faster... maybe the problem lies in some weird optimizations.
AFAIK x264 produces standard compliant streams.

[Cyberace]

There are no H.264 optimizations in XBMC's MPlayer code that Team-XBMC made themself, XBMC still uses 'old' MPlater 1.0-pre6 (with a slighter never libavcodecs update from FFmpeg), so latest MPlayer CVS on www.mplayerhq.hu does have some slight speed advantages over the older MPlayer version in XBMC. MPlayer in XBMC will probebely be updated in XBMC within a few months time, as they are in a feature freeze now and won't do such updates until after XBMC 2.0.0 been released.

[Sharktooth]

Are you sure? IIRC I've read the XBMC libavcodec was optimized for the xbox...

[bond]

SG1-901-528x288-X264-558.mp4 looks fine structure wise

[batfink]

Hmmm, ok.
So currently it just seems to be XBMC hating these Stargates (Season 8 amd 9) in the resolution of 528x288.

I havent fully experimented yet..I suppose the next thing to try would be a different H264 encoder (not Mencoder) and see if the problem is still there.

Its not a major issue really..its more of an idle curiosity as to why its doing it.

Whats funny is, i have encoded other things in 528x288 with no problems.


Ok, on a totally different topic..i have a friend thats just got himself a new puter with an AMD X2 3800 in it. He's interested in learning how to rip DVD's and encode them into H264 format.

I'm going to go around there and teach him how to use Staxrip...Since he's got a Dual Core machine (lucky S.O.B.), Do i need to use a special version of X264 thats optimised for Dual core operations or will they all just autodetect that the CPU has both cores and use them.

I'm currently using this one
http://x264.nl/
http://mirror01.x264.nl/x264/revision558/x264-558-install.exe

Does this one support Dual Core ?

[Cyberace]

Are you sure? IIRC I've read the XBMC libavcodec was optimized for the xbox...Yes, I'm sure. Ask in the official XBMC forum and you will get the same reply.

[eLupus]

it's not more optimised than standard lavc/lavf.. however as stated before, our version is abit old. also the mp4 demuxer isn't really the greatest in either mplayer nor lavf. you can try forcing lavf as demuxer instead of mplayer's if you want by creating a standard mplayer configuration file for that clip. this would probably solve that specific clip (but might break others :)

filename.mp4.conf
with only the line
demuxer=35

cheers

[bond]

also the mp4 demuxer isn't really the greatest in either mplayer nor lavf. you can try forcing lavf as demuxer instead of mplayer's if you want by creating a standard mplayer configuration file for that clip. this would probably solve that specific clip (but might break others :)hm what problems do you know with ffmpeg's and mplayer's mp4 demuxers? i dont know any problems with them with spec compliant mp4 files

[eLupus]

one issue i could think of on the top of my head for the mplayer demuxer is that some mp4's with different set display area from coded frame size, chop of large parts of the display on output. I've sent a bug report about the issue to their mailing list, but there was never any complete solution. if fixed for that sample, other samples broke if I remember correctly. I suppose this could be a nonconforming sample, but still. lavf didn't have any issues with that file.

the lavf demuxer i can't think of any specific issue right now, but from my experience it has been less reliable than the mplayer one. so we don't use it as the standard demuxer for mp4's. thou i've not tested latest cvs lavf for a while now, so I suppose I was abit too quick to say it had issues.

[bond]

one issue i could think of on the top of my head for the mplayer demuxer is that some mp4's with different set display area from coded frame size, chop of large parts of the display on output. I've sent a bug report about the issue to their mailing list, but there was never any complete solution. if fixed for that sample, other samples broke if I remember correctly. I suppose this could be a nonconforming sample, but still. lavf didn't have any issues with that file.hm, what produces such files? do you have a sample for me to try?

[eLupus]

http://samples.mplayerhq.hu/MPEG-4/wrong-size/
ftp://samples.mplayerhq.hu/MPlayer/samples/MPEG-4/wrong-size/

try it with -demuxer lavf and without and you'll see what i mean.

i think they where generated with som sony vc something camera.

<edit> odd, there sample repo, seems too give me access denied errors. </edit>

[bond]

http://samples.mplayerhq.hu/MPEG-4/wrong-size/

try it with -demuxer lavf and without and you'll see what i mean.thx, but i cant download from there :/

[eLupus]

http://www.badongo.com/file/1421428

[bond]

http://www.badongo.com/file/1421428thx, as i thought its a borked file

on the container level 320x240 is signalled, altough the stream is 640x480

this kinda looks like a borked muxer is to blame here

[eLupus]

could be.. but what strikes me is the exact half res that the container signals. almost feels like there might be some shift that should be applied to the given size.
also, why should the container override what the encoded framesize on playback? it's always a question of what to trust i suppose, container or codec. when it comes to fps, container seems the best bet, but in this case it'd be better to ignore the framesize. then again some files mov files have container set differently just to crop the encoded source (ex. heights that isn't aligned to 16), so i suppose the demuxer should be trusted.

lavf does get it right thou, and i'm assuming it isn't really decoding the video stream to figure it out.

[bond]

lets look at the specs, cause if you ask who to trust, i have to answer: "the specs"

for the track header atom it says:
width and height specify the track's visual presentation size as fixed-point 16.16 values. These need not be the same as the pixel dimensions of the images, which is documented in the sample description(s); all images in the sequence are scaled to this size, before any overall transformation of the track represented by the matrix. The pixel dimensions of the images are the default values.so the player should only display the size define here. in your file this is 320x240

mplayer does that, so mplayer is doing everything fine and ffmpeg is wrong


now lets look at the image sizes documented in the mentioned sample description atom:

width and height are the maximum visual width and height of the stream described by this sample description, in pixelsso this carries the video stream size, which is in your case 640x480

in your file there is a 320x240 stored tough so your sample file is simply borked


so i would assume the following:
1) the filewriter creating your sample was simply borked writing a wrong stsd atom
2) mplayer is correct displaying only 320x240 as the tkhd simply says so
3) ffmpeg propably simply ignores the width/height settings of the container and shows the streams simply as they are (and is therefore not 100% following the specs)

[eLupus]

<quote>all images in the sequence are scaled to this size, before any overall transformation of the track represented by the matrix.</quote>

notice it says scaled, not croped. ie the video should be downscaled to the given size, using bilinear (or other scaling). it should not like it is doing, only display top left corner given those sizes.

[eLupus]

in other word, its more of a way to adjust aspect ratio than anything else.

[bond]

indeed, both mplayer and ffmpeg are wrong

still we shouldnt forget that in reality this isnt really used anywhere

[Drachir]

<quote>all images in the sequence are scaled to this size, before any overall transformation of the track represented by the matrix.</quote>

notice it says scaled, not croped. ie the video should be downscaled to the given size, using bilinear (or other scaling). it should not like it is doing, only display top left corner given those sizes.

But in ISO/IEC 14496-14 (MP4 file format) this values shall be set to the pixel dimensions of the visual stream.


In MPEG-4 both visual and aural composition are done using the BIFS system. Therefore structures marked as “template” in the ISO Base Media Format which pertain to composition, including fields such as matrices, layers, graphics modes (and their opcolors), volumes, and balance values, from the MovieHeaderBox and TrackHeaderBox, are all set to their default values in the file format. These fields do not define visual or audio composition in MPEG-4; in MPEG-4, the BIFS system defines the composition.
The fields width and height in the VisualSampleEntry and in the Track Header Box shall be set to the pixel dimensions of the visual stream.

[eLupus]

yes that makes complete sense. it says pixel dimension.. so in essence it only encodes the aspect of a pixel. ie it need not be set to the actual size of the stream. it should only be used to calculate scaling for the contained pixels. so in our example, no scaling need to take place as it encodes that pixel dimension is square (same w/h as the actual data)

[Drachir]

yes that makes complete sense. it says pixel dimension.. so in essence it only encodes the aspect of a pixel. ie it need not be set to the actual size of the stream. it should only be used to calculate scaling for the contained pixels. so in our example, no scaling need to take place as it encodes that pixel dimension is square (same w/h as the actual data)

No, I think your interpretation is wrong. It says pixel dimension -> the dimension with the unit in pixel. There is nothing written about aspect ratio. So this values shall be set to the actual size of the stream.

[eLupus]

even if you do interpret it like that, the other statement about it said, that the actual coded size should be scaled to the given size for output or further processing.

your quote is ambiguous, since pixel dimension is in my eye's the dimensions of the actual pixel, not the full frame. also abit hard to tell what is meant with visual stream. it could mean the final output, ie what should be visual to the user.

interestingly enough a google on VisualSampleEntry turned out this thread
http://forum.doom9.org/showthread.php?t=114711

where atleast one of the post indicate it's the aspec ratio, thou not pixel ratio.

[eLupus]

i know I might be wrong on this, but i went ahead and bumped the thread on mplayer-users about the issue

[bond]

either way the file is borked as the video is 640x480 tough the stsd says 320x240

[Drachir]

In ISO/IEC 14496-14 (MP4 file format) it is done the way I abovementioned to be compatible with the "Qicktime file format" and ISO/IEC 14496-12 (ISO base media file format).

Any further manipulation of the visual stream ins done with BIFS.


In MPEG-4 both visual and aural composition are done using the BIFS system. Therefore structures marked as “template” in the ISO Base Media Format which pertain to composition, including fields such as matrices, layers, graphics modes (and their opcolors), volumes, and balance values, from the MovieHeaderBox and TrackHeaderBox, are all set to their default values in the file format. These fields do not define visual or audio composition in MPEG-4; in MPEG-4, the BIFS system defines the composition.The fields width and height in the VisualSampleEntry and in the Track Header Box shall be set to the pixel dimensions of the visual stream.


A visual stream can be MPEG 4 ASP,H.264,JPEG or MPEG 2 Video ...

Most players around don't support BIFS. But if the values are set the way I mentioned this is not a problem.