ffmpeg, xine, gxine disaster

I'm really puzzled.

In Puppy 4.1.2 I used ffmpeg version 2007-20-07, xine-lib 1.1.8 and gxine 0.5.9, the same as used right at the start of the Puppy4 series. These versions were compiled for 4.0.0 back in November 2007. Prior to releasing 4.1.2 I compiled later versions, ffmpeg 2008-07031 and xine-lib 1.1.14. I also tested gxine 0.5.903 -- all three were a disappointment, so I stayed with what works.

Since then, I have tried a couple more times, the most recent today, and each time it gets worse. In the case of ffmpeg/xine-lib, I don't know which of the two is to "blame".

I built Jaunty Puppy alpha5 (463) with the same ffmpeg/xine-lib/gxine as used in Puppy 4.1.2, and it works nicely.

The Ubuntu packages gave various problems, but I didn't try for very long.

Today I compiled ffmpeg 0.5, xine-lib 1.1.16.2 and gxine 0.5.903 on Jaunty Puppy, and got so many errors.... No sound, hardly any of the video files played, gxine crashes at the drop of a hat. There's no error about the lack of sound, just that there's no sound.

The thing is, I configured ffmpeg and xine-lib sensibly, based on years of experience with compiling these packages. Something has been going downhill, I don't know whether it is one of those two or both.

I have a special directory with a test-suite of audio and video files, and the ffmpeg/xine-lib from Puppy4 handles all of them nicely. These include Real Media (RM), Windows Media (WMV) and FLV and AVI files.

I recall back when I was developing 4.1.2 and compiled later packages as mentioned above, one of the video formats played but had severely deteriorated video, another had chopped-up sound. I don't recall which media. I think also there was one or two of my files that no longer played. I was disappointed at the time and rolled back.

Weird that with my latest compile the situation has got worse, not better.

Right now I have booted Jaunty Puppy alpha5 with 'pfix=ram' so as to avoid the upgrades in the 'pup_save' file, and and ah, everything plays so nicely. Nor does Gxine crash.

Latest ffmpeg, old xine-lib
I have tried an experiment. Running my "pristine" alpha5, I manually installed ffmpeg 0.5 and created library-file symlinks so that xine-lib will use the new ffmpeg. I don't expect this mismatch to work perfectly, but it might give an indication which package is to blame.

I started Gxine, hey my first Real Media file plays, with sound! Tried a Windows Media video, no video, garbled sound. An FLV file, no video but got sound. The later two were trying to use ffmpeg.

Old ffmpeg, latest xine-lib
Have rebooted, again with 'pfix=ram' to get a pristine alpha5. This time I manually installed the latest xine-lib and created library symlinks accordingly. Again, I don't expect too much from the mismatch but it might give an indication.

Dejavu! I played a Real Media video and got video fine, but sound was chopped and not understandable. This brought back a memory -- I watched this same video back prior to pup 4.1.2 when I was trying the upgraded ffmpeg/xine-lib -- exactly the same fault! This is the same Real Media file that I tried with the reverse combination (latest ffmpeg, old xine-lib) which played perfectly. So, a very strong indication that xine-lib is the culprit.

Tried the same WMV file as before, this time xine-lib gave an engine error that 'wmvdmod.dll' is missing. Hmm, I got this earlier today when testing both latest ffmpeg and xine-lib. They should have everything needed to play a WMV. Anyway, I have installed 'wmvdmod.dll' -- now it plays, get video but no sound. Tried same FLV as previous test, get audio but no video.

Conclusions
Trying those old/new combinations of ffmpeg/xine-lib has not produced a clear culprit.

It has left me in a situation where I might have to abondon both packages. I suppose that I could try xine-lib with its own builtin ffmpeg ...yeah, for the sake of completeness I had better do that.

Latest xine-lib, ffmpeg compiled internally
This is xine-lib 1.1.16.2. It's compiling right now...

The Real Media file... get video, no sound. The Windows Media file, get video, no sound. The FLV file, get video, no sound.

Very interesting!

I rebooted and got audio back. Somehow it had got killed. The old 0.5.9 Gxine was unstable with this new xine-lib, so I also installed Gxine 0.5.903.

The '2barks.au' plays. Then tried to play the Real Media file, gxine hung. Tried the Real Media file, it started to play, with sound and video, but Gxine crashed with:

gxine: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.0.

...I was getting the same crashes before with gxine 0.5.903.

It's interesting that compiling ffmpeg internally fixed the video. It seems to indicate that the xine-lib developers have neglected to test configuring with ffmpeg externally.

Another thing that Gxine has done with all older versions right up to the latest -- choose to play a video or audio file and Gxine first seeks the optical drive and reads what's there. Totally unnecessary and causes a big delay before the file plays. Amazing that they never fixed that.

Next step... compile mplayer.

---

Comments

vlc media player
Username: arm-arch
Hello Barry ! How about using the vlc media player. For me it works better as every player and has all codecs included. Plugins for Seamonkey and Firefox exist too.

Major annoyances and bugs in Puppy
Username: happypuppy
""Another thing that Gxine has done with all older versions right up to the latest -- choose to play a video or audio file and Gxine first seeks the optical drive and reads what's there. Totally unnecessary and causes a big delay before the file plays. Amazing that they never fixed that." I hate that bug - it's one of the most annoying things in Puppy. Another (even worse) bug is with Pmount: (especially if you're booting from a frugal install started with the GRUB bootloader): When starting Pmount,it first scans the optical drives 2 or 3 times before the UI appears on the screen. This can take up to 20 seconds ! Extremely annoying. Is there any way to fix this issue? And,finally, why isn't there an option to mount drives read-only and/or with no atime in Pmount? Mounting without atime reduces disk wear dramatically, and mouinting read-only ensures no accidental modification / damage to an NTFS partition that you use just for reading (streaming) of data.

xine-lib-1.1.16.3
Username: coolpup
"latest version http://sourceforge.net/project/showfiles.php?group_id=9655&package_id=9732

Tags: woof