XBMC with Gstreamer can't decode mpeg2 properly

Here is the xbmc.log while playing the video from the screenshot.

Raybuntu, could you check which of these mpeg2 clips play properly in totem? Interlaced clips will be problematic in xbmc (there is so shader to render interlaced content to a surface). But what you describe sounds like it could be multiple different issues and it would be useful to isolate which issues are with xbmc vs. which issues are codec problems..

Raybuntu, could you please attach a small piece of clip, it will be helpful to identify the cause.

@Rob Clark: Totem plays them even worse! I can't see anything because of the blur. I can attach a photo too later. I don't really think that the clips are interlaced since I watch them on my HTPC without deinterlace filter and they look fine. But I also figured there might be multiple problems.

@Kan HU: I'm not really sure because of the copyright! I could just dd 5-6MB of the clips and send them by email. Just give me your email or send me one (my address can be found in my launchpad profile). You could also just recreate it by dumping a clip from a DVD by:

mplayer dvd://n -v -dumpstream -dumpfile filename.vob

where "n" is the number of the track found with lsdvd.
I saw that problem in all the dumps I tried.

if you can reproduce the issue w/ first few seconds of clip, that would be useful.. I have a relatively big collection of clips that we test h264/mpeg4 with, but by comparision no so many mpeg2 clips.

I created 2 clips about 6MB and 7-9s long. First video is with the hanging, out of sync and pseudo interlacing issues. 2nd clip is with only the 1/3 blurry screen issue. Both tested on the Pandaboard ES. I can send them by mail!?

Maybe off topic but I also saw some issues with the Sintel movie. But that's not mpeg2.
With that file: http://mirrorblender.top-ix.org/movies/sintel-2048-surround.mp4

I have some update on this issue. I did an dist-upgrade today and got some gstreamer updates from tiomap-dev release ppa along with the kernel 3.1.0-1282-omap4. Looks like the heavy cpu load is gone. Means all the pseudo interlaced is gone. But it now looks like the screen is split (see attached photo). Then I flashed back to ubuntu's generic kernel and the issues came back. Maybe this is a kernel or driver issue?

That screenshot, it looks like the video is actually interlaced. I suspect you were using somehow the sw decoder before, and it might have been doing de-interlacing.

Maybe it would be possible to use a shader to de-interlace in xbmc.. it would certainly not be perfect (because it would be happening after scaling), but I think I think that would be the best we could do on omap4. In practice it should look the same as interlaced content in totem.. ie. mostly ok, but maybe some artifacts if you look closely with things like thin horizontal lines.

Yeah I figured that they are interlaced. The Problem is I'm really not using any SW deinterlacing. I can actually reproduce it. If I flash the Kernel back to ubuntu's generic I have the previous issue. If I flash to tiomap-dev's kernel I see this issue. I don't really see why!

Yeah this horizontal lines will be a problem for me. I'm trying to find a nice reencoding without losing any visible quality and then I'll try to deinterlace them.

In screenshot003.png the error is clearly in the upscaling from SD to display resolution. The 720x576 input image has been scaled uniformly to height 1080 resulting in a width of 1350 pixels. Beyond horizontal position 1350, the last pixel has been replicated to fill the line up to 1920 pixels.

The same problem is present in screenshot006.png with the addition of the image being repeated twice vertically at half height. The top and bottom halves of this image are almost identical pixel for pixel, which suggests they are from the same source image, not a top/bottom interlaced pair or similar (unless the video has *no* motion at all between frames; a test with a high-motion scene would clarify this). Possibly a single field has been repeated twice, although the presense of black borders suggests a film source, which is typically not encoded with interlacing.

Without access to the actual files being played, I cannot speculate further. Also, is this using hardware or software decoding?

If you install gstreamer-plugins-ugly package, there a mpeg2dec also has rank as same as ducatimpeg2 decoder and got some artifact for mpeg2 clips.
If you use totem, you can run "export GST_DEBUG=GST_ELEMENT_FACTORY:3" before run totem from the terminal, to see the actually plugin using. If it using hw acclerate on omap it should using a "ducatimpeg2dec" .
And you can send the small clip to <email address hidden>. I can check it for you.

can reproduce with xbmc 2:11.0~git20120207.1fef727-0ubuntu1~ppa1~oneiric~linaro5

I have checked and confirmed the XBMC use omap gst-ducati-mpeg2dec for decoding.

playback the clip with totem is ok (slow but the video is ok, I will check my image), so I think it should be problem in the XBMC video render(gles),

rob, do you have any comments?

I know the xbmc rendering does not support interlaced.. I'm not sure if there is a way to handle interlaced w/ a different shader? There might also be some cropping issue, which I guess is also related to interlaced (or at least only seems to happen w/ mpeg2?).

Fwiw, in totem we are not using gles2 to render, so de-interlacing is happening a different way (basically by splitting the blit in two and doubling the destination stride). But I don't really know how to do that w/ gles2+eglImage path.

rob,
so you mean the ducatimpeg2dec will output fields buffer which can be processed by the default sink but can not be processed by the gles render?
if so, how it can be distinguished? different caps?

yup.. it will have interlaced=true in the caps. But in the gles/render code I'm not entirely sure what to do with that.

(That unfortunately isn't really enough to know *how* the interlaced fields are laid out.. in case of ducatimpeg2dec it would be top/bottom.. IIRC gst 0.11 was going to have some improved caps to let the videosink know the layout in a more generic way)

talked with rob, there's maybe a easy solution to just render one field for this case, I'll try to figure it out.

patch attached, resolved this by only render top filed for interlaced buffer on omap4

Latest XBMC Eden with the patch is available in overlay.