XBMC with Gstreamer can't decode mpeg2 properly

Bug #923888 reported by Raybuntu on 2012-01-30
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Linaro Multimedia WG project
Fix Released
Kan HU
Linaro Ubuntu
Avik Sil

Bug Description


I installed XBMC along with gst from your overlay ppa on my Pandaboard ES. So far everything works smooth (h264, mpeg4). Even 1080p works good.
The only issue I have is while playing mpeq2 videos. I have some VOB's (DVD backups with mplayer dumpfile) that I can play with my PC with official XBMC 11 (ffmpeg), but on my Pandaboard I have a lot of frame drops and audio is out of sync. Video looks interlaced even though it shouldn't be (deinterlacing doesn't help). In some files 1/3 of the right screen is totally blurry (See attached screenshot). Also as you can see in the attached screeny the CPU usage goes up to 100% which I haven't seen in any h264 1080p video yet.

Btw. drm polling is turned off

Raybuntu (raybuntu) wrote :
Raybuntu (raybuntu) wrote :

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

Tom Gall (tom-gall) on 2012-02-01
Changed in linaro-multimedia-project:
importance: Undecided → Medium
assignee: nobody → Kan HU (kanhu)
Rob Clark (rob-ti) wrote :

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..

Kan HU (kanhu) wrote :

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

Raybuntu (raybuntu) wrote :

@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.

Rob Clark (rob-ti) wrote :

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.

Raybuntu (raybuntu) wrote :

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

Raybuntu (raybuntu) wrote :

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?

Rob Clark (rob-ti) wrote :

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.

Raybuntu (raybuntu) wrote :

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.

Mans Rullgard (mansr) wrote :

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?

Kan HU (kanhu) wrote :

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.

Kan HU (kanhu) wrote :

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?

Rob Clark (rob-ti) wrote :

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.

Kan HU (kanhu) wrote :

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?

Rob Clark (rob-ti) wrote :

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)

Kan HU (kanhu) wrote :

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

Kan HU (kanhu) wrote :

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

Kan HU (kanhu) on 2012-03-21
Changed in linaro-multimedia-project:
status: New → Fix Committed
Kan HU (kanhu) on 2012-03-22
Changed in linaro-multimedia-project:
milestone: none → 2012.03
Kan HU (kanhu) on 2012-03-22
Changed in linaro-multimedia-project:
status: Fix Committed → Fix Released
Changed in linaro-ubuntu:
status: New → In Progress
importance: Undecided → Medium
assignee: nobody → Avik Sil (aviksil)
milestone: none → 12.03
Avik Sil (aviksil) wrote :

Latest XBMC Eden with the patch is available in overlay.

Changed in linaro-ubuntu:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers