AVI choppiness

[quarnster]

At this stage this one requires changing just a single character in the source code and doing lots of testing with avi files to figure out a pattern. If you can build the sources, you can help.

In xbmc/cores/dvdplayer/DVDDemuxers/DVDDemuxFFmpeg.cpp around line 767 I added an "#ifndef HAS_INTEL_SMD" block to disable that code for this project. This made some AVI's that previously played back choppily now play back very smooth, however I later discovered that some other AVI's now play back very choppy and that re-enabling this code made it smooth again.

To disable the code use:

#ifndef HAS_INTEL_SMD

and to enable it use:

#ifdef HAS_INTEL_SMD

Get it? It's a single character change!

Now the task is to figure out what the AVI's that get smooth with the code enabled have in common and what the AVI's that get smooth with the code disabled have in common.

Once we figure that out it should hopefully be as simple as detecting whether the code should be enabled or not at runtime. Slightly more skill is needed for that, but someone needs to do the first steps first before it can be fixed proper.

[ghost]

I gather this is 657a6f5
I have just compiled this but unsure whether I got all the changes from the git.
Can you give me some guidance please?, I did this in the build directory..

git pull
git stash
git pull
git stash pop
cmake ..
make shares
make
make dist

[quarnster]

Add in these after cmake .. to make sure everything is synced up.

make refresh
touch ../../../configure

[ghost]

Testing the choppy avi's (mpeg4 xvid 420p), I have noticed the ones which are worse are 25fps.
I will try your change to the code to see if it gets better and report back here.

[ghost]

I can confirm that the code change has made a vast improvement
Do you require me to test other things?

[quarnster]

Nah, I'm sure the community will complain if something breaks ;)

[ghost]

I have yet to find a choppy avi with it enabled. I will let you know if I do.
*Edit, just found one, going to test with it disabled...

Ok this one plays fine with it disabled, I will find out what the difference is.

[ghost]

Enabled this video plays smooth

Video
ID/String : 0
Format : MPEG-4 Visual
Format_Profile : Advanced Simple@L5
Format_Settings_BVOP/String : 4
Format_Settings_QPel/String : No
Format_Settings_GMC/String : No warppoints
Format_Settings_Matrix/String : Default (H.263)
MuxingMode : Packed bitstream
CodecID : XVID
CodecID/Hint : XviD
Duration/String : 1h 39mn
BitRate/String : 864 Kbps
Width/String : 656 pixels
Height/String : 272 pixels
DisplayAspectRatio/String : 2.40:1
FrameRate/String : 25.000 fps
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bits
ScanType/String : Progressive
Compression_Mode/String : Lossy
Bits-(Pixel*Frame) : 0.194
StreamSize/String : 618 MiB (88%)
Encoded_Library/String : XviD 64

And this one goes choppy..

Video
ID/String : 0
Format : MPEG-4 Visual
Format_Profile : Advanced Simple@L5
Format_Settings_BVOP/String : 4
Format_Settings_QPel/String : No
Format_Settings_GMC/String : warppoint0
Format_Settings_Matrix/String : Custom
CodecID : XVID
CodecID/Hint : XviD
Duration/String : 1h 57mn
BitRate/String : 2196 Kbps
Width/String : 720 pixel3
Height/String : 304 pixel2
DisplayAspectRatio/String : 2.35:1
FrameRate/String : 23.976 fps2
ColorSpace : YUV
ChromaSubsampling : 4:2:0
BitDepth/String : 8 bit3
ScanType/String : Progressive
Compression_Mode/String : Lossy
Bits-(Pixel*Frame) : 0.418
StreamSize/String : 1.81 GiB (83%)
Encoded_Library/String : XviD 1.2.1 (UTC 2008-12-04)

Then vice versa disabled.

[quarnster]

To completely solve this issue, rather than an autodetect feature it might be better to just have a checkbox in the videosettings so that it can manually be changed per video.

[ghost]

https://github.com/Annres/secret-dubstep.wiki.git

[julius02]

Files that I have that have "packed bitstream" enabled are choppy. Files that have no "packed bitstream" play back perfectly. This is using "xbmc13.alpha11.boxeebox2013.12.16.early_alpha2_b453696"

[ghost]

If there is anything you know that can be done please let us know regarding the packed bitstream. Perhaps we need something adding.

[devilstrike]

Is thats even used those days? my latest xvid/divx/avi was 7years ago, so i will see go to h264 and all works with beter picture en beter compression.

[ghost]

Absolutely right in what your saying there devilstrike, but many people have archives of older films that may not have the original to re rip to h264.

I did a bit of research and the packed bitstream issue within xbmc has been identified and is on going (no solution yet).

[julius02]

seems odd that boxee box can play these files back flawlessly (original stock firmware); I thought boxee box was a "version" of xbmc...

[quarnster]

FWIW, I don't have time to test anything right now but there's a field "divx_packed" in libavcodec/mpegvideo.h that might be possible to use to detect this.

[quarnster]

Hmm, see I never commented on this, but I did try to get to the divx_packed property. However it was not available as the SMD codec was used for decoding so the ffmpeg codec was never initialized and thus divx_packed can't be used.

The SMD codec or some other code should be able to mimic the code used by ffmpeg to set the divx_packed property though.

Another way to solve this issue would be to query the videorenderer for dropped frames and frames out of order and see if those numbers stop slipping when toggling the mode. Haven't had a chance to try that out yet, and don't know when I will. Just suggesting if someone has the time and wants to look into that.

[julius02]

Can't find a file called "libavcodec/mpegvideo.h" on the usb stick with xbmc on??

[devilstrike]

@julius02 h files are source files and yu dont find that on your usb stick, only on pc whene making a xbmc build.

[quarnster]

Btw, this issue is referred to elsewhere as the bad b-frame issue, and can be fixed in the video file by re-building the index (quick!) with correct frame type.

I don't remember the exact commandline I used, but avidemux can do it with something like avidemux_cli --rebuild-index --force-b-frame --load input.avi.

[cadesalaberry]

👍 Thanks @quarnster, I had similar issues on vlc, and could not get a clean explanation. I guess the best solution would be to fix the avi files instead of trying to overload the CPU.

Quoted from your link:

1. requires 2x as much CPU to decode unless the player has some decoded picture que to compenate the 2,0,2,0 style frame decoding per frame.

[Simenson4]

Just a observation i did today,

While playing a .avi video it did have 4-6 FPS all the time. (By clicking on "O" button to see video details) while it read from metadata it should be 23.9 FPS.

14:05:22 T:3021036432 NOTICE: fps: 23.976024, pwidth: 768, pheight: 432, dwidth: 768, dheight: 432
14:05:22 T:3021036432 DEBUG: OutputPicture - change configuration. 768x432. framerate: 23.98. format: ISMD
14:08:20 T:3021036432 DEBUG: CalcFrameRate counted 1000 frames without being able to calculate the framerate, giving up

Traced the CalcFrameRate to:
https://github.com/quarnster/boxeebox-xbmc/blob/ae1fb71409c9a63bfbc362a13064210cf9888cb4/xbmc/cores/dvdplayer/DVDPlayerVideo.h
https://github.com/quarnster/boxeebox-xbmc/blob/ae1fb71409c9a63bfbc362a13064210cf9888cb4/xbmc/cores/dvdplayer/DVDPlayerVideo.cpp

Thought the framerate not being calculated might be a cause of choppy AVI playback. Solution might be "Set metadata fps if CalcFrameRate fails"

While on another avi video it played smoothly. But then it didn't show that "CalcFrameRate" giving up message.

Just a theory and might be completely off track. Actual developers here might say if this is on track to something or not.