Ubuntu
xine-lib package

Xine bug with Motion JPEG codec.

Bug #93076 reported by Major Andras
4
Affects Status Importance Assigned to Milestone
xine-lib
Fix Released
Medium
xine-lib (Baltix)
New
Undecided
Unassigned
xine-lib (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: libxine1

I have a HP Photosmart 735 digital camera. Every video what I make this camera will be played bugy by xine.
I tested it by totem-xine, gxine, xine-ui. The result is same every xine base player. Other players (mplayer, totem-gstreamer) play my video files perfectly. I made a test video, you can download from here:

http://web.t-online.hu/majorandras/HPIM1411.AVI

ProblemType: Bug
Architecture: i386
Date: Sat Mar 17 14:17:25 2007
DistroRelease: Ubuntu 7.04
Uname: Linux andras-desktop 2.6.20-11-generic #2 SMP Thu Mar 15 08:03:07 UTC 2007 i686 GNU/Linux

Related branches

lp:ubuntu/karmic/xine-lib

CVE References

Revision history for this message
Major Andras (majorandras) wrote :
Revision history for this message
Major Andras (majorandras) wrote :
Revision history for this message
Major Andras (majorandras) wrote :

I changed to package to libxine1, because this is the correct name in the gutsy repository.
The problem is exists in gutsy-beta too.

Revision history for this message
Major Andras (majorandras) wrote :

I changed back to xine-lib. sorry ...
Any idea for solution ?

Revision history for this message
Gert Kulyk (gkulyk) wrote :

I can confirm the behavior using the file mentioned in description. Mplayer plays the file without any problems, xine-based players show errors.

Changed in xine-lib:
status: New → Confirmed
Revision history for this message
Gert Kulyk (gkulyk) wrote :

When starting xine (forgot to mention: using gutsy) from command-line, you'll get the following output:

[mjpeg @ 0xb6475ac8]only 8 bits/component accepted
[mjpeg @ 0xb6475ac8]only 8 bits/component accepted
[mjpeg @ 0xb6475ac8]huffman table decode error
[mjpeg @ 0xb6475ac8]decode_sos: invalid len (11568)
[mjpeg @ 0xb6475ac8]mjpeg: unsupported coding type (c9)
[mjpeg @ 0xb6475ac8]mjpeg: unsupported coding type (c6)
[mjpeg @ 0xb6475ac8]picture size invalid (41983x40969)
[mjpeg @ 0xb6475ac8]mjpeg: unsupported coding type (cf)
[mjpeg @ 0xb6475ac8]decode_sos: invalid len (40027)
[mjpeg @ 0xb6475ac8]mjpeg: unsupported coding type (c1)

Maybe the other players are simply not caring about minor errors in the video? This may be due to the fact, that mplayer is using an internal ffmpeg-copy and gstreamer0.10-ffmpeg, too, which are different from the system-wide one.

Revision history for this message
In , Mantas Kriaučiūnas (mantas) wrote :

Created an attachment (id=45)
Screenshot, showing the bug in xine frontends

I'm forwarding this important bug from https://launchpad.net/bugs/93076

Lots of videos, encoded with MJPEG (Motion JPEG) codec is played incorrectly by video players, using libxine.
I tested it by totem-xine, gxine, xine-ui. The result is same every xine base player. Other players (mplayer, totem-gstreamer) play my video files perfectly.

You can see this bug by opening http://web.t-online.hu/majorandras/HPIM1411.AVI (you can attach this file to this bugreport, it's only ~2 Mb size) with any xine frontend (I've tested with gxine ver. 0.5.901 and Totem-xine 2.22.1).

Latest xine-lib version, I've found this problem is 1.1.11.1 . I'm almost 100% sure, that this bug also exists in 1.1.12, as I didn't found anything in changelog about fixing MJPEG problems...
I'm attaching screenshot, showing the bug in xine frontends, taken from https://launchpad.net/bugs/93076

Bug Watch Updater (bug-watch-updater)
Changed in xine-lib:
status: Unknown → New
Revision history for this message
In , Darren Salt (dsalt) wrote :

Fixed in hg (for 1.1.12.1) for the given sample file.

If you have any which still cause problems, attach them or links to them to this bug report.

Bug Watch Updater (bug-watch-updater)
Changed in xine-lib:
status: New → Fix Released
Revision history for this message
Reinhard Tartler (siretart) wrote :

according to the upstream bugtracker, this has been fixed in intrepid, which ships 1.1.12

Changed in xine-lib:
status: Confirmed → Fix Released
Revision history for this message
Reinhard Tartler (siretart) wrote :

Oh, I'm sorry, I mislooked. fix will be included in next upload.

Changed in xine-lib:
status: Fix Released → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package xine-lib - 1.1.14-1ubuntu1

---------------
xine-lib (1.1.14-1ubuntu1) intrepid; urgency=low

  * merge from debian unstable. Remaining changes:
    - disable the jack plugin
      in libxine1-bin to make dapper->hardy upgrades work (LP #203605)
    - Modify Maintainer value to match the DebianMaintainerField
      specification.
  * New upstream fixes:
    - playback of MJPEG files LP: #93076
    - CVE-2008-1878 LP: #235904
    - CVE-2008-1686 LP: #218652
  * remove Replaces: libxine-main1 (<< 1.1.2+repacked1-0ubuntu1). We don't
    support upgrades from dapper/feisty anymore.

xine-lib (1.1.14-1) unstable; urgency=low

  * The "beat the freeze" release.
  * New upstream release.
    - All patches in 1.1.12-2 are present upstream.
    - MIME types added. (Closes: #472869)
  * Build-depend on libmagick9-dev | libmagick-dev | libmagickwand-dev.
  * Build-depend on ghostscript | gs | gs-gpl.

 -- Reinhard Tartler <email address hidden> Tue, 08 Jul 2008 22:35:48 +0200

Changed in xine-lib:
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in xine-lib:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.