[fly2thesun]

I'm still experiencing choppy playback of mjpeg avi files with XBMC on ATV2 (running 4.3).

It's not unbearably bad, but still noticeable, maybe 0.1~0.5 seconds of stopped video/audio ( and video/audio stutter independently of each other.. I tried various audio/video sync options.. ), every couple of seconds. It's been always like that from at least 10.0.7 through recent nightlies.

Media info is here. Is this a particularly burdensome video format to decode?

---------------------------------------------------------------
Format : AVI
Format/Info : Audio Video Interleave
File size : 15.2 MiB
Duration : 16s 933ms
Overall bit rate : 7 546 Kbps
Mastered date : WED OCT 07 19:48:56 2009
Writing application : CanonMVI06

Video
ID : 0
Format : JPEG
Codec ID : MJPG
Duration : 16s 933ms
Bit rate : 7 455 Kbps
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate : 15.000 fps
Color space : YUV
Compression mode : Lossy
Bits/(Pixel*Frame) : 1.618
Stream size : 15.0 MiB (99%)

Audio
ID : 1
Format : PCM
Format settings, Sign : Unsigned
Codec ID : 1
Codec ID/Hint : Microsoft
Duration : 16s 933ms
Bit rate mode : Constant
Bit rate : 88.2 Kbps
Channel(s) : 1 channel
Sampling rate : 11.024 KHz
Bit depth : 8 bits
Stream size : 182 KiB (1%)
Interleave, duration : 996 ms (14.94 video frames)
Interleave, preload duration : 1000 ms
----------------------------------------------------

I've uploaded part of the XBMC.log..

http://pastebin.com/9wRZYCSk

I see a lot of "avcodec_decode_video didn't consume the full packet", "Detected refreshrate:" and "CDVDPlayerAudio:: Discontinuity" messages. Not sure if they mean anything.

[g-off]

mjpeg is hard work because it is like a stack of jpegs shown one after another. There is no compression between frames. That is why the bitrate is so high for a comparatively low resolution.

Why this is a problem now and why it wasn't before is a mystery. The discontinutity errors appear when the device is running out of grunt to fetch data and after decoding it.

[fly2thesun]

Well, it has not been quite a big problem, although some loss of frames/audio was apparent.. It was ever so slight.. Not too big of a complaint. It has been always like that since I began toying with XBMC and ATV2 in May 2011. Maybe I should just accept it as ATV2 hardware limitation.

But it seems that a new problem popped up, since my last nightly from 10/09.

Today I tried nightlies from 11/09, 11/13, and 11/19.. They all show a new symptom of buffering for about 4 seconds at around 10 second mark. After that buffering, audio and video goes out of sync ( usually audio first ). This new problem is indeed quite annoying, and probably not due to ATV2 hardware limitation, as nightlies up to early October didn't show that.

I wonder if it's related to this problem..

http://forum.xbmc.org/showthread.php?tid=115015

And I uploaded a new xmbc.log from 11/19 f8d48da build. The log is filled with "didn't consume the full packet" messages. The playback buffered for about 3~4 secs at 10 seconds into playing (probably at 15:29:11 or 15:29:13). "CRenderManager::FlipPage" and "CDVDMessageQueue(audio)::Get" messages at 15:29:13 are new warnings that I didn't see with older nightlies.

http://pastebin.com/Z6gi1MXQ

[fly2thesun]

Can someone kindly upload the nightly from 20111108 somewhere?

As I have this annoying buffering issue with 11/09, 11/13, and 11/19 nightlies, but not on 10/09 build,

I want to pinpoint exactly when the problem was introduced, and I'm kind of suspecting it first happened on 11/09, which is why I'd like to try 11/08 build.

[virtuallysafe]

Hi Fly2thesun,

Please find xbmc-20111108-b499c47-master-atv2.deb at the following:

http://www.mediafire.com/?2m4g6vprcy4i76o

[fly2thesun]

Thank you so much for the upload..

Comparing 11/08 vs. 11/13 and 11/19 ( I found that I somehow lost 11/09 build along the way..), the later builds definitely buffer much often. But 11/08 did also buffer from time to time, although much less often.. Maybe ATV2 is just too slow.

But a bigger problem with 11/13 and 11/19 builds is that audio and video seem to go out of sync during buffering. That is, when buffering happens, video pauses immediately but audio continues for 1~3 seconds, which is very noticeable.

I guess at this point it really sounds like this issue (http://forum.xbmc.org/showthread.php?tid=115015 ), including hpnas's comment on 11/20 that "sometimes the audio comes out of the freeze but the picture remains frozen".

[virtuallysafe]

Hi Guys,

Not that it adds any value, however, for context up until this issue I have been a habitual nightly installer, installing immediately after compilation. Since 20111108-b499c47 I have remained a habitual nightly installer, however, have immediately rolled back to 20111108-b499c47. I look forward to a fix.

[fly2thesun]

Please disregard my comment below.
I found the last 1sec or so audio being lost on 11/08 nightly, but no such problem on 11/23 nightly.

------- Disregard ---------------------------------------------
Apart from the new symptom since 11/08 nightly,

I concluded that MJPEG playback is never going to be smooth on ATV2. The hardware's just too slow.

So I decided to convert all my MJPEG files to ATV2s' favorite format, H.264. Now I can watch them smoothly, but while I was carefully checking for any quality problems from the conversion, I noticed another problem, which is..

1 second or so before the end of a video file, the audio abruptly stops (silent) but the video continues. Basically, the last 1 second of audio is lost.
. I didn't notice it before, because it was obscured by all the stuttering and buffering.

It's not an issue with the conversion, as I tried 3 different programs for the conversion, all of them showing same symptom with XBMC on ATV2. And the same files play fine in MPC-HC on my windows machine. And I also noticed a lot of the AVI files from Canon cameras and the MOV files from iPhone camera show the same issue on XBMC. Not every file shows it. Some do and some don't. But ones that show the problem do it every time.
---------Disregard ---------------------------------------------------------