[MPlayer-users] Quicktime playback on MPlayer/Linux -- Some videos play in ultra-slow-motion?

[Terry Linford]

Hi,

I just discovered & installed MPlayer app & plugin on OpenSuse 11. My
browser is Firefox.

After having fought with 'other options', with MPlayer, just about all
of my problems with viewing vids have been resolved! :-)

One strange issue with Quicktime.

I've set up to view QT with MPlayer embedded. And for most QT vids,
it seems to work as expected.

But on some, I see vid in slow-motion.

For example, @ the Apple trailer site, viewing non-HD trailers for,

(1) http://www.apple.com/trailers/wb/terminatorsalvation/
(2) http://www.apple.com/trailers/magnolia/humboldtcounty/

On OSX, with Safari, both trailers play correctly -- both audio & video.

On MPlayer/Linux, the TerminatorSalvation/(1) trailer plays OK.

But the HumboldtCounty/(2) plays audio fine, but video plays as if its
in ultra slow motion, and completely out-of-sync with audio. Its also
really difficult to interrupt the playback ... I have to click on
'stop' a bunch of times to cancel.

Is this problem because of MPlayer settings? I'm a little confused,
because it works on one, but not the other.

Thanks for any help.

Terry

[Masaru Nomiya]

Hello,

In the Message;

Subject : [MPlayer-users] Quicktime playback on MPlayer/Linux -- Some videos play in ultra-slow-motion?
Message-ID : <***@mail.gmail.com>
Date & Time: Sun, 31 Aug 2008 07:51:43 -0700

[Terry] == "Terry Linford" <***@gmail.com> has written:

Terry> For example, @ the Apple trailer site, viewing non-HD trailers for,

Terry> (1) http://www.apple.com/trailers/wb/terminatorsalvation/
Terry> (2) http://www.apple.com/trailers/magnolia/humboldtcounty/

Terry> On OSX, with Safari, both trailers play correctly -- both audio & video.

Terry> On MPlayer/Linux, the TerminatorSalvation/(1) trailer plays OK.

It's same for me.

Terry> But the HumboldtCounty/(2) plays audio fine, but video plays as if its
Terry> in ultra slow motion, and completely out-of-sync with audio. Its also
Terry> really difficult to interrupt the playback ... I have to click on
Terry> 'stop' a bunch of times to cancel.

Yes, MPlayer works fine for me.

Terry> Is this problem because of MPlayer settings? I'm a little confused,
Terry> because it works on one, but not the other.

Which revision of MPlayer are you using?

Mine is;

MPlayer dev-SVN-r27504-4.3 (C) 2000-2008 MPlayer Team
CPU: Dual-Core AMD Opteron(tm) Processor 2224 SE (Family: 15, Model: 65,
Stepping: 3)

on OpenSUSE 11.0.

Regards,

---
Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp

"Bill! You married with Computers.
Not with Me!"
"No..., with money."

[Terry Linford]

Hi,

Post by Masaru Nomiya
Which revision of MPlayer are you using?
Mine is;
MPlayer dev-SVN-r27504-4.3 (C) 2000-2008 MPlayer Team
CPU: Dual-Core AMD Opteron(tm) Processor 2224 SE (Family: 15, Model: 65,
Stepping: 3)
on OpenSUSE 11.0.

I've installed the MPlayer version 1.0 rc2 from the repo I found
searching @ http://packages.opensuse-community.org,

http://packman.iu-bremen.de/suse/11.0
MPlayer (1.0rc2) Multimedia Player

This is also the same I found from the MPlayer site, referenced at
http://packman.links2linux.org/package/128

I've installed the right version for my CPU, for the i586 architecture.

So, mostly everything /else/ works with the installed MPLayer. Just
this weird Quicktime slo-mo behavior for just /some/ movies.

Terry

[Charles philip Chan]

Post by Terry Linford
But the HumboldtCounty/(2) plays audio fine, but video plays as if its
in ultra slow motion, and completely out-of-sync with audio. Its also
really difficult to interrupt the playback ... I have to click on
'stop' a bunch of times to cancel.

Are you using Packman? Complain to them. I am using a self compiled
current svn verion (dev-SVN-r27498-4.2.1) and the trailer plays fine.

Charles

[Terry Linford]

Rather than entertaining the knee-jerk 'complain to them',
its-someone-elses-problem recommendation, I think it would be useful
to learn from knowledgeable application folks *here* what the root
cause might be.


Terry

[Charles philip Chan]

Post by Terry Linford
Rather than entertaining the knee-jerk 'complain to them',
its-someone-elses-problem recommendation, I think it would be useful
to learn from knowledgeable application folks *here* what the root
cause might be.

The root cause is that the Packman version is too old. When I say
complain to them, what I mean is to ask the packager to upgrade.

Also, this list really only supports recent svn versions.

Charles

[Masaru Nomiya]

Hello,

In the Message;

Subject : Re: [MPlayer-users] Quicktime playback on MPlayer/Linux -- Some videos play in ultra-slow-motion?
Message-ID : <***@mail.gmail.com>
Date & Time: Sun, 31 Aug 2008 09:04:29 -0700

[Terry] == "Terry Linford" <***@gmail.com> has written:

Terry> Rather than entertaining the knee-jerk 'complain to them',
Terry> its-someone-elses-problem recommendation, I think it would be useful
Terry> to learn from knowledgeable application folks *here* what the root
Terry> cause might be.

Ok, Terry.

Please show the message by doing this;

$ mplayer -v http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov

PS, Packman's MPlayer IS built with it's specific patch. Maybe. You don't
know this.

Regards, and Good Night,

---
$BLn5\(B $B8-(B mail-to: nomiya @ galaxy.dti.ne.jp

$B!V(Be$B%a!<%k$d7HBSEEOC$KG{$i$l$?<R2q$O!"<+J,<+?H$H8~$-9g$C$?$j!"(B
$B6uA[$K$U$1$C$?$j$9$k<+M3$rC%$&!#!W(B
-- M. Crichton --

[Terry Linford]

Hi,

Post by Masaru Nomiya
Please show the message by doing this;
$ mplayer -v http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov

The output of that command is shown below ...

Post by Masaru Nomiya
PS, Packman's MPlayer IS built with it's specific patch. Maybe. You don't
know this.

Not only don't I know that, I don't even know what that means :-(

Terry

mplayer -v http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov
MPlayer 1.0rc2-openSUSE Linux 11.0 (i686)-Packman-4.3 (C) 2000-2007 MPlayer Team
CPU: Intel Celeron 2/Pentium III Coppermine,Geyserville (Family: 6,
Model: 8, Stepping: 3)
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 0
Compiled with runtime CPU detection.
get_path('codecs.conf') -> '/home/terry/.mplayer/codecs.conf'
Reading /home/terry/.mplayer/codecs.conf: Can't open
'/home/terry/.mplayer/codecs.conf': No such file or directory
Reading /etc/mplayer/codecs.conf: Can't open
'/etc/mplayer/codecs.conf': No such file or directory
Using built-in default codecs.conf.
Configuration: --prefix=/usr --confdir=/etc/mplayer
--datadir=/usr/share/mplayer --libdir=/usr/lib
--with-extralibdir=/usr/lib --mandir=/usr/share/man
--enable-runtime-cpudetection --enable-bl --enable-fbdev --enable-zr
--enable-gui --enable-menu --language=all --enable-xvmc
--with-xvmclib=XvMCW --enable-largefiles --enable-smb
--enable-joystick --enable-radio --enable-radio-capture
--with-dvdnav-config=/usr/src/packages/BUILD/MPlayer-1.0rc2/libdvdnav/ROOT/bin/dvdnav-config
--disable-nemesi --enable-faad-external
--with-extraincdir=/usr/lib/live
--realcodecsdir=/usr/lib/RealPlayer10/codecs
CommandLine: '-v'
'http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov'
init_freetype
Using MMX (with tiny bit MMX2) Optimized OnScreenDisplay
get_path('fonts') -> '/home/terry/.mplayer/fonts'
Using nanosleep() timing
get_path('input.conf') -> '/home/terry/.mplayer/input.conf'
Can't open input config file /home/terry/.mplayer/input.conf: No such
file or directory
Parsing input config file /etc/mplayer/input.conf
Input config file /etc/mplayer/input.conf parsed: 81 binds
Opening joystick device /dev/input/js0
Can't open joystick device /dev/input/js0: No such file or directory
Can't init input joystick
Setting up LIRC support...
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.
get_path('humboldtcounty_h480.mov.conf') ->
'/home/terry/.mplayer/humboldtcounty_h480.mov.conf'

Playing http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov.
get_path('sub/') -> '/home/terry/.mplayer/sub/'
Filename for url is now
http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov
Filename for url is now
http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov
STREAM_HTTP(1), URL:
http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov
Resolving movies.apple.com for AF_INET...
Connecting to server movies.apple.com[209.170.97.75]: 80...
--- HTTP DEBUG HEADER --- START ---
protocol: [HTTP/1.0]
http minor version: [0]
uri: [(null)]
method: [(null)]
status code: [200]
reason phrase: [OK]
body size: [1122]
Fields:
0 - Content-Length: 15541839
1 - Content-Type: video/quicktime
2 - Server: Apache/2.2.8 (Unix)
3 - Last-Modified: Tue, 26 Aug 2008 22:10:34 GMT
4 - ETag: "ed264f-455642c3b0a80"
5 - Cache-Control: max-age=3553
6 - Expires: Sun, 31 Aug 2008 17:41:25 GMT
7 - Date: Sun, 31 Aug 2008 16:42:12 GMT
8 - Connection: close
--- HTTP DEBUG HEADER --- END ---
Content-Type: [video/quicktime]
Content-Length: [15541839]
Cache size set to 320 KBytes
STREAM: [null] http://movies.apple.com/movies/magnolia_pictures/humboldtcounty/humboldtcounty_h480.mov
STREAM: Description: http streaming
STREAM: Author: Bertrand, Albeau, Reimar Doeffinger, Arpi?
STREAM: Comment: plain http
CACHE_PRE_INIT: 0 [0] 0 pre:65536 eof:0
Cache fill: 0.00% (0 bytes)
Checking for MOV
ISO: File Type Major Brand: Original QuickTime
ISO: File Type Minor Version: 537199360
ISO: File Type Compatible Brand #0: qt
ISO: File Type Compatible Brand #1:
ISO: File Type Compatible Brand #2:
ISO: File Type Compatible Brand #3:
MOV: Movie header found!
MOV: 'WIDE' chunk found!
MOV: Movie DATA found!
Quicktime/MOV file format detected.
MOV: Movie header (100 bytes): tscale=2997 dur=426125
--------------
MOV: Track #0:
MOV: Track header!
tkhd len=84 ver=0 flags=0x0 id=1 dur=426125 lay=0 vol=0
MOV: unknown chunk: tapt 60
MOV: unknown chunk: load 16
MOV: Edit atom!
MOV: Edit list table (1 entries) (ver:0,flags:0)
MOV: entry#0: duration: 426125 start time: 0 speed: 1.0x
MOV: Media stream!
MOV: Media header!
MOV: Handler header: mhlr/vide (appl) Apple Video Media Handler
MOV: Media info!
MOV: Video header!
MOV: Handler header: dhlr/alis (appl) Apple Alias Data Handler
MOV: unknown chunk: dinf 28
MOV: Sample info!
MOV: Description list! (cnt:1)
MOV: desc #0: avc1 (135 bytes)
MOV: Sample duration table! (1 blocks)
MOV: unknown chunk: ctts 26848
MOV: unknown chunk: cslg 24
MOV: Syncing samples (keyframes) table! (89 entries) (ver:0,flags:0)
MOV: unknown chunk: stps 12
MOV: unknown chunk: sdtp 3413
MOV: Sample->Chunk mapping table! (569 blocks) (ver:0,flags:0)
MOV: Sample size table! (entries=3409 ss=0) (ver:0,flags:0)
MOV: Chunk offset table! (569 chunks)
MOV track #0: 569 chunks, 3409 samples
pts=426125 scale=2997 time=142.184
EL#0: pts=0 1st_sample=0 frames=3409 (142.184s) pts_offs=0
==> Found video stream: 0
[mov] Video stream found, -vid 0
MOV: AVC decoder configuration record atom (43)!
MOV: avcC version: 1
MOV: avcC profile: 77
MOV: avcC profile compatibility: 64
MOV: avcC level: 21
MOV: avcC nal length size: 4
MOV: avcC number of sequence param sets: 1
MOV: avcC sps 0 have length 20
MOV: avcC number of picture param sets: 1
MOV: avcC pps 0 have length 4
MOV: Found unknown movie atom colr (18)!
Image size: 480 x 272 (24 bpp)
Display size: 480 x 272
Fourcc: avc1 Codec: 'H.264'
--------------
MOV: Track #1:
MOV: Track header!
tkhd len=84 ver=0 flags=0x0 id=2 dur=426125 lay=0 vol=256
MOV: Edit atom!
MOV: Edit list table (1 entries) (ver:0,flags:0)
MOV: entry#0: duration: 426125 start time: 0 speed: 1.0x
MOV: Media stream!
MOV: Media header!
MOV: Handler header: mhlr/soun (appl) Apple Sound Media Handler
MOV: Media info!
MOV: Sound header!
MOV: Handler header: dhlr/alis (appl) Apple Alias Data Handler
MOV: unknown chunk: dinf 28
MOV: Sample info!
MOV: Description list! (cnt:1)
MOV: desc #0: mp4a (151 bytes)
MOV: Sample duration table! (1 blocks)
MOV: Sample->Chunk mapping table! (651 blocks) (ver:0,flags:0)
MOV: Sample size table! (entries=6124 ss=0) (ver:0,flags:0)
MOV: Chunk offset table! (651 chunks)
MOV: unknown chunk: meta 453
MOV track #1: 651 chunks, 6124 samples
pts=6270976 scale=44100 time=142.199
EL#0: pts=0 1st_sample=0 frames=6124 (142.184s) pts_offs=0
==> Found audio stream: 1
[mov] Audio stream found, -aid 1
Audio bits: 16 chans: 2 rate: 44100
Audio header: samp/pack=1024 bytes/pack=1 bytes/frame=2 bytes/samp=2
Audio extra header: len=91 fcc=0x77617665
MOV: Found MPEG4 audio Elementary Stream Descriptor atom (51)!
ESDS MPEG4 version: 0 flags: 0x000000
ESDS MPEG4 ES Descriptor (34Bytes):
-> ESId: 0
-> streamPriority: 0
ESDS MPEG4 Decoder Config Descriptor (20Bytes):
-> objectTypeId: 64
-> streamType: 0x15
-> bufferSizeDB: 0x001800
-> maxBitrate: 96.000kbit/s
-> avgBitrate: 96.000kbit/s
ESDS MPEG4 Decoder Specific Descriptor (2Bytes)
ESDS MPEG4 Sync Layer Config Descriptor (1Bytes)
-> predefined: 2
Fourcc: mp4a
--------------
MOV: Track #2:
MOV: Track header!
tkhd len=84 ver=0 flags=0x0 id=3 dur=426125 lay=0 vol=0
MOV: Edit atom!
MOV: Edit list table (1 entries) (ver:0,flags:0)
MOV: entry#0: duration: 426125 start time: 0 speed: 1.0x
MOV: Media stream!
MOV: Media header!
MOV: Handler header: mhlr/tmcd (appl) Time Code Media Handler
MOV: Media info!
MOV: Generic header!
MOV: Handler header: dhlr/alis (appl) Apple Alias Data Handler
MOV: unknown chunk: dinf 28
MOV: Sample info!
MOV: Description list! (cnt:1)
MOV: desc #0: tmcd (33 bytes)
MOV: Sample duration table! (1 blocks)
MOV: Sample->Chunk mapping table! (1 blocks) (ver:0,flags:0)
==========================================================================
MOV: Chunk offset table! (1 chunks)
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family#2:
1 chunks, 0 samples
pts=426125INFO: libavcodec init OK!4
EL#0: pts=0 1st_sample=0 frames=1Selected video codec: [ffh264] vfm:
ffmpeg (FFmpeg H.264)
Generic track - not completely understood! (id: 2)

==========================================================================
MOV: unknown chunk: meta 1049
==========================================================================
Quicktime Clip Info:
Opening audio decoder: [faad]
AAC (MPEG2/4 Advanced Audio Coding)lers/
Copyright: ? 2008 Magnolia Pictures. All Rights dec_audio: Allocating
4608 bytes for input buffer.
Name: Humboldt County
dec_audio: Allocating 49152 + 65536 =
114688 bytes for output buffer.s) V: #0 (3409 samples)
VIDEO: [avc1] 480x272 24bpp 23.976 fFAAD: Decoder init done (0Bytes)!
[V] filefmt:7 fourcc:0x31637661 size:480x272 fps:23.98
ftime:=0.0417 FAAD: Negotiated samplerate: 44100Hz channels: 2
Clip info:
FAAD: got 96kbit/s
bitrate from MP4 header!pple.com/trailers/
copyright: ? 2008 Magnolia Pictures.AUDIO: 44100 Hz, 2 ch, s16le,
96.0 kbit/6.80% (ratio: 12000->176400)
name: Humboldt County
Selected audio codec: [faad] afm:
faad (FAAD AAC (MPEG-2/MPEG-4 Audio) decoder)
X11 opening display:
==========================================================================:
couldn't open the X11 display ()!
X1Building audio filter chain for 44100Hz/2ch/s16le -> 0Hz/0ch/??...
vo: couldn't open the X11 display ()!
[libaf] Adding filter dummy
VO XOverlay need a subdriver
[dummy] Was reinitialized:
44100Hz/2ch/s16lextended formats. Use -vo gl:nomanyfmts if playback
fails.
[gl] Using 0[dummy] Was reinitialized: 44100Hz/2ch/s16le
X11 opening display: ao2: 44100 Hz
2 chans s16le
vo: couldn't open the X11 display ()!
audio_setup: using '/dev/dsp' dsp device
X11 opening display:
audio_setup:
using '/dev/mixer' mixer device
X11 opening display: audio_setup: using 'pcm' mixer device
vo: couldn't open the X11 display ()!
audio_setup: sample format: s16le (requested: s16le)O_SDL] SDL
initialization failed: No available video device.
usaudio_setup: using 2 channels (requested: 2)
Can't open /dev/fb0: No such file or directoryaudio_setup: using 44100
Hz samplerate (requested: 44100)
[fbdev2] Using device /dev/fb0
audio_setup: frags: 16/16 (4096
bytes/frag) free: 65536uch file or directory
VO: [aa] cannot open /dev/vcsa02 fAO: [oss] 44100Hz 2ch s16le (2 bytes
per sample)

AO: Description: OSS/ioctl audio output

AO: Author: A'rpi
Building audio filter chain for 44100Hz/2ch/s16le ->
44100Hz/2ch/s16le...

[dummy] Was reinitialized: 44100Hz/2ch/s16le

[dummy] Was
reinitialized: 44100Hz/2ch/s16le
Starting playback...

[ffmpeg] aspect_ratio: 0.000000

VDec: vo config request - 480 x 272 (preferred
colorspace: Planar YV12)
Trying filter chain: vo
VDec:
using Planar YV12 as output csp (no 0)

Movie-Aspect is undefined - no
prescaling applied.
VO Config
(480x272->480x272,flags=0,'MPlayer',0x32315659)

VO: [aa] 480x272 => 480x272 Planar YV12

VO: Description:
AAlib
VO: Author: Alban Bedel <***@free.fr> and Folke
Ashberg <***@ashberg.de>

SwScaler: reducing / aligning filtersize 15 ->
16
SwScaler: reducing / aligning filtersize 15 -> 16

SwScaler: reducing / aligning filtersize 15 -> 14

[Phil Rhodes]

Post by Terry Linford
Not only don't I know that, I don't even know what that means :-(

It means they've written custom modifications to the code. This is almost
always necessary regardless of platform because the single biggest problem
Linux has is consistency and standardisation, but it's even more necessary
on Windows or MacOS because they differ more significantly.

The problem with the "compile from SVN" approach is that it exposes you to
all these issues directly. You will probably be glibly told to "type
.configure && make && make install" which will, under theoretically perfect
circumstances, compile a working mplayer executable. Unfortunately,
circumstances that perfect do not exist in anything other than fringe cases
even on Linux and you will end up applying patches and/or hacking the C code
directly.

P

[Terry Linford]

Phil,

Post by Phil Rhodes

Post by Terry Linford
Not only don't I know that, I don't even know what that means :-(

It means they've written custom modifications to the code.

Thanks for explaining. After reading countless -- and so frequently
indignant -- claims of "Linux is ready for the masses" articles, given
my simple (in)experience here, this hardly seems to be the case.

Add to that the inevitable excuse of "you pay for stuff" on Mac or
Windows, and I really understand WHY one pays for things on
Mac/Windows -- They work & your don't have to tolerate such sweeping,
'elitism' @ your 1st bump in the road.

Thanks again.

Terry

[Phil Rhodes]

Post by Terry Linford
Thanks for explaining. After reading countless -- and so frequently
indignant -- claims of "Linux is ready for the masses" articles, given
my simple (in)experience here, this hardly seems to be the case.

Quite so.

At risk of derailing the mplayer users list into an format war, I should
point out that there's nothing I'd like better than to avoid having to pay
the Microsoft tax for vista, but herein lies the biggest political issue
Linux faces. There are too many types, too much disparity, too much elitism,
but that's not the problem. The problem is that these issues are denied. You
(and I, too) are experiencing this.

Screaming "there are no problems" does not cause there to be no problems.

P

[Dominik 'Rathann' Mierzejewski]

Post by Terry Linford
Phil,

Post by Phil Rhodes

Post by Terry Linford
Not only don't I know that, I don't even know what that means :-(

It means they've written custom modifications to the code.

Thanks for explaining. After reading countless -- and so frequently
indignant -- claims of "Linux is ready for the masses" articles, given
my simple (in)experience here, this hardly seems to be the case.
Add to that the inevitable excuse of "you pay for stuff" on Mac or
Windows, and I really understand WHY one pays for things on
Mac/Windows -- They work & your don't have to tolerate such sweeping,

You are both somewhat mistaken. It all depends on the distribution
which you are using. Granted, it is not obvious which of the many
is best for you, but that diversity is the price (some would say:
advantage) of freedom. For legal reasons, MPlayer can't be included
in distributions whose owners operate in the US. OpenSUSE is one
of them. Packman is a third-party add-on software repository for
OpenSUSE, based outside US, so they can provide the package. They've
decided to stick with 1.0rc2 "release" version. We (MPlayer developers)
have no resources to provide support for released versions for longer
than a couple of months due to the pace of development. That is why
you are told to go to your distributor with your problems first. They
are meant to act as intermediaries between users and upstream developers.
There's no ill will on our part, we just don't have the manpower.
If you report a bug against current development source, we can try and
fix it, but if we were to backport patches from it to older releases,
we'd have much less time for development. It is the packager's job to
keep in touch with the developers and update their package in a distro
(or backport patches) on a regular basis. The same thing is done with
many other programs, including the Linux kernel.

I hope that explains the issue a bit.

Regards,
R.

[Terry Linford]

Dominik,

On Sun, Aug 31, 2008 at 11:04 AM, Dominik 'Rathann' Mierzejewski

Post by Dominik 'Rathann' Mierzejewski
I hope that explains the issue a bit.

It's a reasoned and, in contrast to others', polite comment. Thank you.

Still, it doesn't /change/ this user's experience to know this. The
bottom line is, we install a mainstream distro, paying for disks to
support the Linux community, and follow recommendations to install
"X".

When problems arrive, we're thrust into a melee of project politics,
difficult personalities, etc, with each entity pointing the finger
elsewhere. I'm curious -- how far should an "average user" be
expected to go to get a product that works?

It may be the 'best' product out there, but unless it /works/ for the
average/typical user -- which is /not/ a build-it-from-snv developer
-- it shouldn't be touted as such.

A quote from one of the reivews references @ the MPlayer site says it best --

"What should the Linux movie player of your dreams do? It should play
any movie/video that you throw at it. No questions asked—just play.'

I agree. And, I'll choose simply to not use this product as a result,
and don't expect for one single moment that any of these
build-it-yourself-ers care about my decision or experience.

[Reimar Döffinger]

Post by Terry Linford
"What should the Linux movie player of your dreams do? It should play
any movie/video that you throw at it. No questions asked—just play.'
I agree. And, I'll choose simply to not use this product as a result,
and don't expect for one single moment that any of these
build-it-yourself-ers care about my decision or experience.

I am sorry but I think your expectations are way unreasonable, esp.
since some have made comparisons with proprietary companies - so far the
most usable response I have ever gotten from any of those was in
response to an NVidia CUDA but report, and that was basically "it will
be fixed in the next release. And no, we do not know when that will be".
This case basically has this very same answer, but everyone considered
that a rather useless reply and instead told you to use SVN.
And btw. for rc2 you likely will be able to work around this problem with
"-demuxer lavf -correct-pts", though I did not test it (and you will
lose support for mov subtitles with these options).

Greetings,
Reimar Döffinger

[Phil Rhodes]

Post by Reimar Döffinger
I am sorry but I think your expectations are way unreasonable, esp.
since some have made comparisons with proprietary companies

That's who you're competing with.

Get used to it.

P

[Charles philip Chan]

Post by Phil Rhodes
That's who you're competing with.

We are not competing with anyone- I can care less if Linux succeed
commercial. I for one Cherish my software freedom and have done so since
1995 when I moved over to Linux full time.

Charles

[Reimar Döffinger]

Post by Phil Rhodes

Post by Reimar Döffinger
I am sorry but I think your expectations are way unreasonable, esp.
since some have made comparisons with proprietary companies

That's who you're competing with.

Did you actually read what I wrote? I have yet to see a large-ish
proprietary company that is any more helpful than what you get here
without compiling yourself. If you don't want to compile, then don't
do it. You'll only have to wait for someone to provide the binaries,
which you would have to do for any proprietary application.
Either way, I do not see any competition at least for FFmpeg anyway,
so at least for that part, no I do not think "we" are competing with
anyone.

[Terry Linford]

it's an unreasonable expectation for an average-user to not have to
build an application from source?

and this is "one of the best" applications for users' needs?

back to Mac for us.

thanks & goodbye.

[Charles philip Chan]

Post by Terry Linford
it's an unreasonable expectation for an average-user to not have to
build an application from source?

That is why I told you to ask Packman to update their package.

Post by Terry Linford
back to Mac for us.

Great, Have fun in your walled garden.

Charles

[Dominik 'Rathann' Mierzejewski]

Post by Terry Linford
Dominik,
On Sun, Aug 31, 2008 at 11:04 AM, Dominik 'Rathann' Mierzejewski

Post by Dominik 'Rathann' Mierzejewski
I hope that explains the issue a bit.

It's a reasoned and, in contrast to others', polite comment. Thank you.
Still, it doesn't /change/ this user's experience to know this.

I would hope it might change your attitude.

Post by Terry Linford
The
bottom line is, we install a mainstream distro, paying for disks to
support the Linux community, and follow recommendations to install
"X".

Since MPlayer is not officially part of OpenSUSE, you're already
leaving supported environment. I know you just want to play your
movies, but it's not that easy. That's not how this world works,
unfortunately. Well, Ubuntu says it is easy, but their packages are
not so good either, as our experience shows.

Post by Terry Linford
When problems arrive, we're thrust into a melee of project politics,
difficult personalities, etc, with each entity pointing the finger
elsewhere. I'm curious -- how far should an "average user" be
expected to go to get a product that works?
It may be the 'best' product out there, but unless it /works/ for the
average/typical user -- which is /not/ a build-it-from-snv developer
-- it shouldn't be touted as such.

Ah. There lies the misunderstanding. Many open-source developers don't
think of their software as "product". It is simply the software that
they write for themselves and if someone uses it, then power to them.
If they report bugs, all the better. Many of us work on the software
in our free time. I think one of the key differences between commercial
products and open-source software is that the latter invites user
participation in its development. Be it by sending code fixes, reporting
bugs or suggesting new features. While we strive to make it "just work",
it's not possible to test everything in every possible configuration.
So we release what works for us and await bugreports.

Back to your "too old" problem, though - we can't do anything about it.
We can't produce packages for every major distribution out there. And
even if we could, it doesn't make sense. It doesn't scale well, there
are too many versions and hardware combinations. Also, someone would
have to track all that. It's the distributor's job, not ours. So as
I said: all problems should be reported through your distributor first.

Post by Terry Linford
"What should the Linux movie player of your dreams do? It should play
any movie/video that you throw at it. No questions asked—just play.'
I agree. And, I'll choose simply to not use this product as a result,
and don't expect for one single moment that any of these
build-it-yourself-ers care about my decision or experience.

Well, it's too bad if your experience with Packman's package was less
than ideal, but we can't do anything about it, for the reasons explained
earlier. You made a choice when you decided to install OpenSUSE and now
you have to live with the consequences. If you want to blame somebody,
blame Packman's maintainer, Novell and the US legal system.

Regards,
R.

[RC]

On Sun, 31 Aug 2008 11:24:54 -0700

The bottom line is, we install a mainstream distro, paying for disks
to support the Linux community, and follow recommendations to install
"X".
When problems arrive, we're thrust into a melee of project politics,
difficult personalities, etc, with each entity pointing the finger
elsewhere. I'm curious -- how far should an "average user" be
expected to go to get a product that works?

You paid for your distro, you should be complaining to them when
something you need isn't included or isn't fully functional.

The MPlayer project got none of your money, and this is not a mailing
list for the completely uninformed masses.

You will not find anyone here trying to convince you that you, and the
rest of the world, should all use Linux (in fact MPlayer runs on Windows
and Mac OS X, among others).

But I do suggest you consider what kind of support you'd get from Apple
had you complained to them of a similar problem. Having done so with
numerous companies over the years, I can say from experience you would
most likely have been completely ignored, and your problem left
unresolved. If you got any response at all, it would be a simple
form-letter dismissing the problem out of hand, by saying your exact
configuration isn't supported (for whatever trivial reason they can
come up with), or perhaps a blanket suggestion that you reinstall the
entire system, or take it to a service facility and pay them to
investigate the problem (they will tell you they can't do anything about
it, soon after taking your cash). Either way, you would have no
options, and would be indefinitely stuck with the issue, no matter how
"advanced" you may or may not be.

[The Wanderer]

Post by Phil Rhodes

Post by Terry Linford
Not only don't I know that, I don't even know what that means :-(

It means they've written custom modifications to the code. This is
almost always necessary regardless of platform because the single
biggest problem Linux has is consistency and standardisation, but
it's even more necessary on Windows or MacOS because they differ more
significantly.
The problem with the "compile from SVN" approach is that it exposes
you to all these issues directly. You will probably be glibly told to
"type .configure && make && make install" which will, under
theoretically perfect circumstances, compile a working mplayer
executable. Unfortunately, circumstances that perfect do not exist in
anything other than fringe cases even on Linux and you will end up
applying patches and/or hacking the C code directly.

Nonsense.

MPlayer compiled and worked perfectly with no more than that (allowing
for 'su' to gain root privileges for the install step) for me from the
very beginning. The only times it hasn't have been when the SVN tree has
been broken, which is a rare state at least for "mainstream" Linux
(though perhaps more common in other *nix variants and on other OSes).
Even installing a variety of other libraries for additional features -
DVD support, for example - just made the process a little more
complicated; I have never needed to patch MPlayer to be able to compile
it and have it run.

If you are going to claim that circumstances under which that set of
steps don't work are the rule rather than the exception, please provide
evidence to back that up.

[Charles philip Chan]

Post by The Wanderer
MPlayer compiled and worked perfectly with no more than that (allowing
for 'su' to gain root privileges for the install step) for me from the
very beginning.

Very true.

Post by The Wanderer
The only times it hasn't have been when the SVN tree has been broken,
which is a rare state at least for "mainstream" Linux (though perhaps
more common in other *nix variants and on other OSes).

And it usually takes only hours or a day for it to be fixed.

Charles

[Phil Rhodes]

Post by The Wanderer
MPlayer compiled and worked perfectly with no more than that (allowing
for 'su' to gain root privileges for the install step) for me from the
very beginning.

Probably because you take care to ensure that your environment is
practically bit-identical with the developers. For those of us for whom
computers are a means rather than an end, this is not practical, nor is it
reasonable to expect it to be. I suspect your definition of "worked
perfectly" is a bit more flexible than mine; if I have to hack strange
values into obscure text files, manually unpack library source into various
directories, add repositories, obtain files, deploy them by hand - I
consider that "not working perfectly". You may consider it all in a day's
work but you cannot realistically deny that those sorts of tasks are an
inevitable part of more or less every software deployment on Linux and they
are emphatically NOT simple.

Evidence? I could list software and environments I've tried to do this on,
and I'll tell you how that discussion would go. First off, you'd pick on the
more obscure pieces of software, saying things like: "oh, that's just not
very well written, I know the guys who work on that, they're all idiots."
Then you'd blame the distro I was using - "oh, that's just not a very good
distro, it doesn't include X, Y and Z." Then, assuming I had the patience to
humour you and install another, you'd have reasons that wasn't any good
either - "it doesn't include A, B and C? What a waste of space!" Then we'd
move on to ad hominem attacks on me personally, blaming my technical
expertise, and finally, we'd get around to "oh, well, Linux isn't for
everybody", which is of course the point I've been trying to make all along.
I have had this series of discussions so many times with so many people it's
moved through irritating and infurating to just being boring. There is no
interest in solving these problems because according to the people who could
solve them, they do not exist. You guys really do have an excuse for
everything.

The sad fact is that software deployment on Linux is a sick joke, a complete
farce, a barely-alpha-quality disaster zone, and it will remain so whether
you choose to accept it or not.

Look, I'm not blaming you guys, it's a general Linux problem, and the reason
I avoid the platform - but again, claiming these issues do not exist does
not make them go away.

P

[The Wanderer]

Post by Phil Rhodes

Post by The Wanderer
MPlayer compiled and worked perfectly with no more than that
(allowing for 'su' to gain root privileges for the install step)
for me from the very beginning.

Probably because you take care to ensure that your environment is
practically bit-identical with the developers.

Nope. The initial environment was plain-vanilla Debian Sarge (back when
that was stable) and whatever compiler/etc. come with it, plus the
source tree (initially taken from a release tarball, then later on
downloaded via Subversion), and I've updated my compiler and other tools
more or less when the whim took me since then - including one complete
"build a new computer, install the OS and tools from scratch, and copy
the source tree across from the old machine".

Post by Phil Rhodes
For those of us for whom computers are a means rather than an end,
this is not practical, nor is it reasonable to expect it to be. I
suspect your definition of "worked perfectly" is a bit more flexible
than mine; if I have to hack strange values into obscure text files,
manually unpack library source into various directories, add
repositories, obtain files, deploy them by hand - I consider that
"not working perfectly".

Unless you have strange definitions for some of those steps, I have
never had to do any of them to get MPlayer to compile. I believe I said
as much; all it took after downloading the source was that same set of
steps you stated, './configure ; make ; make install'.

Post by Phil Rhodes
You may consider it all in a day's work but you cannot realistically
deny that those sorts of tasks are an inevitable part of more or less
every software deployment on Linux and they are emphatically NOT
simple.

Of course I can deny that. Most software installation I do goes
flawlessly. Where I *have* had problems, it's been in projects other
than MPlayer.

Post by Phil Rhodes
Evidence? I could list software and environments I've tried to do
this on, and I'll tell you how that discussion would go. First off,
you'd pick on the more obscure pieces of software, saying things
like: "oh, that's just not very well written, I know the guys who
work on that, they're all idiots."

I'm talking about MPlayer. There are certainly problems with some
projects; I could point to some which have given me fits in the past.
You started out by bashing MPlayer's compilation and installation,
however, and that's what I was objecting to.

Post by Phil Rhodes
Then you'd blame the distro I was using - "oh, that's just not a very
good distro, it doesn't include X, Y and Z." Then, assuming I had the
patience to humour you and install another, you'd have reasons that
wasn't any good either - "it doesn't include A, B and C? What a waste
of space!"

I'd be unlikely to do either of those things.

Post by Phil Rhodes
Then we'd move on to ad hominem attacks on me personally,

Almost certainly not. When I attack someone personally, it isn't to
attempt to win an argument, it's because I have become convinced that
they really are bad enough to deserve whatever the description may be.

Post by Phil Rhodes
blaming my technical expertise,

I'd just like to note that this would not constitute an ad hominem
attack; it might be inappropriate anyway, that depends on the context,
but it by itself is not an attack.

Post by Phil Rhodes
and finally, we'd get around to "oh, well, Linux isn't for
everybody", which is of course the point I've been trying to make all along.

I doubt I would attempt to use that as an argument.

Post by Phil Rhodes
I have had this series of discussions so many times with so many
people it's moved through irritating and infurating to just being
boring. There is no interest in solving these problems because
according to the people who could solve them, they do not exist. You
guys really do have an excuse for everything.

I'm not even one of the people who could solve them. What I am, in this
particular case, is someone who does not see even a fraction of the
problem you claim exists. My personal experience does not prove that the
problem does not exist, but I am certainly not willing to accept your
bare assertion that it does as constituting proof.

Post by Phil Rhodes
The sad fact is that software deployment on Linux is a sick joke, a
complete farce, a barely-alpha-quality disaster zone, and it will
remain so whether you choose to accept it or not.

This was the case a decade or so ago. It isn't the case now. The
situation may not be ideal yet, and it will likely continue to improve,
but if you're going to make this type of claim you're going to have to
back it up with something other than aggressive assertions.

Post by Phil Rhodes
Look, I'm not blaming you guys, it's a general Linux problem, and the
reason I avoid the platform - but again, claiming these issues do not
exist does not make them go away.

I'm not claiming they don't exist at all. I'm claiming they don't exist
to nearly the extent you say, and barely exist at all in the case of
MPlayer. If you have evidence to refute that, please present it.

[Phil Rhodes]

Nope. The initial environment was plain-vanilla Debian Sarge (back when

Post by The Wanderer
that was stable)

See, this is exactly what I'm talking about. "I used this, when it was OK to
use this, which you... sort of have to just know. Now, I'd probably use
something else, which you also sort of have to just know." Nobody's keeping
track of this. None of this is documented anywhere. None of this is in any
book. It's dark secret knowledge which you have to find out by trial and a
rather large amount of error. Today, X works, and Y doesn't. Tomorrow, who
knows? Who's in charge of all this? Who's responsible for making things
work? Mister Nobody. And thus it doesn't.

Post by The Wanderer
source tree (initially taken from a release tarball, then later on
downloaded via Subversion)

Which you have to get. And unpack. And copy to the right location, or more
to the point, perform the right get-and-unpack-and-copy dance of destruction
for this particular tarball or SVN checkout on this day on this particular
configuration of this particular linux distro with the particular
modifications you or the software engineer or the packager has made, for
each of which any variation involves hacking shell scripts all day and
night, sacrificing a chicken and standing on one leg in a rainstorm.

This is so typical of linux people - you make out that it's simple simply by
ignoring the complicated bits. Compare Windows or Mac experience: download
installer. Run installer. Done.

Post by The Wanderer
This was the case a decade or so ago. It isn't the case now.

God help those who tried to do this a decade ago, if the current situation
is considered -good-.

P

[evert vorster]

We seem to have drifted a little off topic here, but I'll bite.

Post by The Wanderer
Nope. The initial environment was plain-vanilla Debian Sarge (back when

Post by The Wanderer
that was stable)

See, this is exactly what I'm talking about. "I used this, when it was OK to
use this, which you... sort of have to just know. Now, I'd probably use
something else, which you also sort of have to just know." Nobody's keeping
track of this. None of this is documented anywhere. None of this is in any
book. It's dark secret knowledge which you have to find out by trial and a
rather large amount of error. Today, X works, and Y doesn't. Tomorrow, who
knows? Who's in charge of all this? Who's responsible for making things
work? Mister Nobody. And thus it doesn't.

You, actually. If the software you choose to install on your system
does not work, it is nobody's fault but your own.
Be thankful that there are people that are kind enough to share their
hard labor with you for no cost at all.

No, I am not trolling, I am just amazed at just how ungrateful this
reply sounds.

There are companies who supply pre-built software, and support it, but
they charge for this service.

Post by The Wanderer

Post by The Wanderer
source tree (initially taken from a release tarball, then later on
downloaded via Subversion)

Which you have to get. And unpack. And copy to the right location, or more
to the point, perform the right get-and-unpack-and-copy dance of destruction
for this particular tarball or SVN checkout on this day on this particular
configuration of this particular linux distro with the particular
modifications you or the software engineer or the packager has made, for
each of which any variation involves hacking shell scripts all day and
night, sacrificing a chicken and standing on one leg in a rainstorm.
This is so typical of linux people - you make out that it's simple simply by
ignoring the complicated bits. Compare Windows or Mac experience: download
installer. Run installer. Done.

Then discover bug in software... then ... what then?

Post by The Wanderer

Post by The Wanderer
This was the case a decade or so ago. It isn't the case now.

God help those who tried to do this a decade ago, if the current situation
is considered -good-.

As long as software was being developed, there were people willing to
share their work for the betterment of mankind, for free. Then there
was also the group of people who decided to gloss over the complexity
of software development, and just charge you for an end product, which
created a third group of people who just use software but share no
appreciation for the complexity and the amount of man-hours that went
in to creating the software that you like to bash.

Have you ever tried to write even the most simple piece of software?
MPlayer does 99.999% of the work for you, they even spend the time to
make their install scripts detect and optimize the hardware and
software that you use. All you have to do is type three commands, if
you work from source.

-Evert-

[Phil Rhodes]

Get off your high horse; you are presumptive and arrogant. Being a software
engineer does not make you better than everyone else, despite the
all-too-common presumption that it does. This brings me ineluctibly back to
a discussion in the archives of this very mailing list concerning SMPTE
drop-frame timecode, which one of the developers wanted out because he
thought it was "untidy". He was wrong; laughably wrong, so obviously wrong
that it was actively humorous to see it in someone working on a
video-related project, but of course he knew everything about everyone's
technology because he was a software engineer and obviously, they know
absolutely everything about absolutely everything. Good grief...

I am, for the record, an engineer in the film and TV industry.

If the software you choose to install on your system does not work, it is
nobody's
fault but your own. Be thankful that there are people that are kind enough
to
share their hard labor with you for no cost at all.

Yes, yes, you are correctly performing all the tired old cliches of Linux
arguments.

First it was: "It works! It's great!"

Now, having been confronted with how crappy it is, it's: "Oh, uh, well, it
might kinda work, but er, we never said it would, OK!"

I say again: I will happily pay Windows money for a Linux distro with
Windows functionality. It does not exist; there seems to be no desire to
make it exist.

Which is absolutely fine. Nobody's being paid here. And this is perfectly
sensible until people start screaming "ready for the desktop!" or "the
deployment procedure works!". It is not ready for the desktop; the
deployment procedures don't often work. You can have your lovely egalitarian
opensource tree-hugging or you can have successful, usable, high-quality
software; you cannot have both.

Then discover bug in software... then ... what then?

You really didn't want to go there. When was the last checkin to fix the
many, many bugs in the slave mode command system? It will never get fixed,
because it's not "fun to work on", I suspect; and that's fine, that's your
choice, but you can't take that position, then try to hold this piece of
software up as a paragon of virtue. This happens constantly in opensource;
boring-to-implement but essential features are overlooked. There is no
commercial imperative; no revenue stream dependent upon the software's
features or performance.

There is in short no reason to make it work at all - so don't pretend it
does when it so patently doesn't - and not only doesn't work now, but can
probably never be made to work given the hellish political limbo in which
the developers are forced to operate.

So tell me again, all this being the case, why exactly do you bother?

P

[evert vorster]

To all the other readers of this list, please accept my apologies, I
really did not want to go in to a flame war.

Post by Phil Rhodes
Get off your high horse; you are presumptive and arrogant. Being a software
engineer does not make you better than everyone else, despite the

Aah, but I am not a software engineer, I actually do some support for
a linux distrobution, Sorcerer, my spare time. For free. For no other
reason than that I like complex puzzles, and like the satisfaction
that I derive when I get something difficult right. I also derive some
small pleasure from knowing that someone else using said distro will
not have to jump through the same hoops.

Does that make me better than you? No. I just do not complain about
things I get for free, as I fully have the option of returning it for
a full refund.

:)

Post by Phil Rhodes
I am, for the record, an engineer in the film and TV industry.

Which is why I am surprised that you are not using a Mac, as they
reportedly have the lion's share on video software, and pretty good
integration and easy software installation... if you buy from a
vendor. At my job we have some deal with IBM/Red Hat, and we have had
their engineers crawling all over our hardware/software when something
goes wrong. All software needed for us to do our work is installed and
working. Drivers are written and installed as/when we need them.
As you can appreciate, none of this is free, but a whole lot better
than what we could expect of either Mac or MS.

Post by Phil Rhodes
I say again: I will happily pay Windows money for a Linux distro with
Windows functionality. It does not exist; there seems to be no desire to
make it exist.

Then buy one of the top 5 linux distrobutions with full support
contract. Any bugs you discover will be dealt with promptly! It will
even be cheaper than a Windows contract of the same nature.

Post by Phil Rhodes
Which is absolutely fine. Nobody's being paid here. And this is perfectly
sensible until people start screaming "ready for the desktop!" or "the
deployment procedure works!". It is not ready for the desktop; the
deployment procedures don't often work. You can have your lovely egalitarian
opensource tree-hugging or you can have successful, usable, high-quality
software; you cannot have both.

I beg to disagree. My linux box is fully tree-hugging compatible AND
the software is much higher grade software than what you could buy,
even if you had the money. Linux is the only software I run, and have
been using it as my desktop for many years now.

Post by Phil Rhodes
There is in short no reason to make it work at all - so don't pretend it
does when it so patently doesn't - and not only doesn't work now, but can
probably never be made to work given the hellish political limbo in which
the developers are forced to operate.

To be totally honest, I have never never been aware of this bug. I
doubt many users have. So, I guess this must not have been a big
enough itch to scratch? If this bug bothers you so very much, I bet
that there are developers that will gladly take a look at that code
for some renumeration.

Post by Phil Rhodes
So tell me again, all this being the case, why exactly do you bother?

I really enjoy messing with software, and get enjoyment out of fixing
things that are broken.

If Linux annoys you so much, why do you bother?

-Evert-

[The Wanderer]

Post by evert vorster
To all the other readers of this list, please accept my apologies, I
really did not want to go in to a flame war.

Very few people ever do.

I, for the record, am likely to drop this immediately if it reaches the
point of outright flames rather than anything resembling serious
discussion. I'm not sure it's far from that point now, but I'm not
convinced it's there yet.

Post by evert vorster

Post by Phil Rhodes
So tell me again, all this being the case, why exactly do you
bother?

I really enjoy messing with software, and get enjoyment out of fixing
things that are broken.
If Linux annoys you so much, why do you bother?

My understanding is that he doesn't: my understanding is that he tried
it, encountered something approximating the situation he describes, and
abandoned it in disgust. Which is perfectly fine, he's entitled to do
that.

What he's not entitled to do is to then badmouth it and everything to do
with it to other people who don't know any better, and then complain
when people object to that - without even being polite enough to explain
why their reports of a different experience do not apply.

[The Wanderer]

Post by Phil Rhodes
Get off your high horse; you are presumptive and arrogant. Being a software
engineer does not make you better than everyone else, despite the
all-too-common presumption that it does.

No, it doesn't. I am not a software engineer, and am unlikely ever to
be. I am (presently) a computer support technician in a public school
system; I work every day with people who are nearly computer illiterate,
and I don't think of myself as better than them. (I do find it
bewildering that they apparently consciously refuse to believe that most
of what they see me do really isn't that difficult, but that's another
issue entirely.)

This is, however, not about that. This is about your claim that MPlayer
compilation and installation is too complicated to work reliably for the
ordinary user. I have said, and I repeat, that the basic "obtain source
tree ; ./configure ; make ; make install" procedure works flawlessly for
me on every computer I've tried it on, without tweaking or customization
of either the computer or the source tree. Your only response to this
has been to object to having to obtain and unpack the source tree. Since
obtaining and unpacking the source tree is essential to even be able to
run the "./configure ; make ; make install" steps which you said would
fail miserably in less than absolutely perfect circumstances, I do not
see how this constitutes a legitimate counterargument.

Post by Phil Rhodes
I say again: I will happily pay Windows money for a Linux distro with
Windows functionality. It does not exist; there seems to be no desire to
make it exist.

This is getting offtopic, but: have you defined "Windows functionality",
precisely and with detail?

Post by Phil Rhodes
Which is absolutely fine. Nobody's being paid here. And this is perfectly
sensible until people start screaming "ready for the desktop!" or "the
deployment procedure works!". It is not ready for the desktop; the
deployment procedures don't often work. You can have your lovely egalitarian
opensource tree-hugging or you can have successful, usable, high-quality
software; you cannot have both.

Post by evert vorster
Then discover bug in software... then ... what then?

You really didn't want to go there. When was the last checkin to fix the
many, many bugs in the slave mode command system?

What does this have to do with his question?

What do you do when you find a bug in a closed Windows or MacOS program?
What are the chances that it will get fixed, in a timely fashion or
otherwise, and the fix made available to you immediately for free?

In my admittedly somewhat limited experience, the answers are "there is
nothing worth doing" and "virtually nil".

By contrast, when you find a bug in an open-source program (not even
specifically a Linux one), you can report it directly to the people who
write the program, and the chances that it will get fixed in response
are significantly higher than zero; when a fix does get put in place,
that fix is then available to you immediately at no charge.

Whether a particular MPlayer bug or set of bugs has gotten attention is
not relevant to the question of what can be done or can be expected to
happen when a bug is found in a closed program vs. in an open one. (That
said, I don't remember any past mention of the bug(s) you're talking
about, though it's possible that a discussion of them might be where I
remember your name from in the first place...)

Post by Phil Rhodes
So tell me again, all this being the case, why exactly do you bother?

For one thing, not all of that is the case, to nearly the extent you
claim. For another thing, variously because "we like it" and "the effort
and/or other required investment is worth the return to us".

I use (and administer for use by others) Windows at work, with a
smattering of Linux where I can sneak it in. I don't utterly loathe it,
but it's frequently clunky, awkward, and painful to work with.

I use (and administer for myself) Linux at home. I don't absolutely love
it, but I recall no area in which it has been *more* clunky, awkward,
and/or painful than Windows, and most of the time - specifically, in the
user-level areas most people are likely to need to mess with - it's less so.

[The Wanderer]

Post by The Wanderer
This is, however, not about that. This is about your claim that
MPlayer compilation and installation is too complicated to work
reliably for the ordinary user. I have said, and I repeat, that the
basic "obtain source tree ; ./configure ; make ; make install"
procedure works flawlessly for me on every computer I've tried it on,
without tweaking or customization of either the computer or the
source tree. Your only response to this has been to object to having
to obtain and unpack the source tree. Since obtaining and unpacking
the source tree is essential to even be able to run the "./configure
; make ; make install" steps which you said would fail miserably in
less than absolutely perfect circumstances, I do not see how this
constitutes a legitimate counterargument.

Okay, I don't think I expressed that clearly. Let me try again.

You (Phil Rhods) said "'./configure ; make ; make install' will fail
miserably in most cases".

I said "nonsense, it's worked flawlessly for me from the beginning".

You said "this must be because you customized your system to make that
happen".

I said "no, this was on a fresh, unmodified installation of a popular
distribution".

You said "but having to obtain and unpack the source is too hard for
most people".

This last A: seems to me like a non sequitur and B: ignores the fact
that having the source is a prerequisite for the steps which you said
will fail.

Since this is the case, and since what I was initially objecting to is
the claim that those steps will fail in most cases, I am not sure why
you brought up the point in the first place. The only obvious
explanation I can think of is that you are attempting to argue in bad
faith rather than to engage in serious discussion, and I'd rather not
impute those motivations to you without more solid evidence.

[Phil Rhodes]

Post by The Wanderer
I have said, and I repeat, that the
basic "obtain source tree ; ./configure ; make ; make install"
procedure works flawlessly for me on every computer I've tried it on,
without tweaking or customization of either the computer or the
source tree.

All I can say is that this is not my experience; my failure to respond
directly on this point is based on a feeling of: is this guy serious? How
can you take this position when it is so self-evidently not the case? Do you
USE linux?

I can only speak as I find.

My experience of the configure/make/install thing is that you type it in, it
spews out page after page of incomprehensible error messages, and fails. So
you do one command at a time, and spend anything from half an hour to two
days fixing all the problems each one has. During this time you are roundly
derided by the creators of the software - as I am being here - for being
such a dunce as to make this happen, an insult given particular force by the
tendency of Linux people, as here, to pretend that such problems are
impossible and unthinkable and can never happen, as opposed to being
absolutely the norm.

Almost invariably these issues are caused by hardcoded paths or missing
library source (truly, Linux is the only OS in the world under which
absolutely everything is monolithic and you end up needing a gig and a half
of the source code to the universe to create any program whatsoever; then
again, it is so poorly standardised that dynamic linking is pretty much
infeasible). It is my direct experience on the basis of at least several
hundred attempts that the combined first-time success rate of all the
various Linux software deployment strategies (apt, compilation, rpm, etc) is
well down into the single digit percentages, and probably under 5%; a
Windows deployment is probably exactly the inverse. Linux is so bad, so
hopelessly unreliable, so ludicrously abstruse and hard to work with that
it's absolutely laughable and if this is not your experience then we simply
seem to live on different planets, or you are suffering from a politically
selective memory. Call it an "assertion" if you like. I can only report my
experience, and that is what it is. I no longer specify Linux for any task
where I don't know absolutely that the software I need comes preinstalled
with the OS, because as a very practical matter, adding anything else is
entirely in the lap of the gods.

It is not really possible to solve these problems because there is
effectively no standardisation or consistency. The first thing that needs to
happen to Linux is for all but two or three of the distributions to go away
so it's actually possible to get things to conform.

P

[The Wanderer]

Phil Rhodes wrote:

[that the Wanderer wrote:]

Post by Phil Rhodes

I have said, and I repeat, that the basic "obtain source tree ;
./configure ; make ; make install" procedure works flawlessly for
me on every computer I've tried it on, without tweaking or
customization of either the computer or the source tree.

All I can say is that this is not my experience; my failure to
respond directly on this point is based on a feeling of: is this guy
serious? How can you take this position when it is so self-evidently
not the case? Do you USE linux?

For me, this *is* the case. I have used Linux exclusively - except, in
the last two years, as required for work - for more than half a decade
(I think quite a bit longer, but I don't have exact dates), and have
rarely had anything near the kind of experience you are describing as
universal.

I could just as easily ask "how can he take this position when it is so
self-evidently not the case?" about the position you are arguing,
because it is so completely out of line with anything I have experienced
as the norm that I suspect some people would, in my place, accuse you of
simply making things up.

Post by Phil Rhodes
I can only speak as I find.
My experience of the configure/make/install thing is that you type it
in, it spews out page after page of incomprehensible error messages,
and fails.

Question, for clarification: are you counting the compile commands
themselves as "error messages"? Because without that, even in cases
where the compilation fails I find it extremely rare for there to be
multiple pages of error messages.

Or... wait. How long is a "page" here? I run at a fairly high resolution
and compile in a full-screen-size terminal, so my usual page size is 89
lines by 250 columns. If you're compiling from the console or in a
standard-sized (non-resized, non-maximized) terminal, the limit will be
more like 40 lines and 80 columns, which will greatly decrease the
amount which will fit on one page.

Looks like I found an explanation for my own confusion. In that case, my
response is: are you saying that this is your experience with compiling
under Linux in general, or with MPlayer, or with specific other projects?

I do not experience this with MPlayer, which is what we are talking
about. The only times I get compilation failures with MPlayer are when
compiling from a broken SVN tree (which, as I said, is rare), when
compiling with bad configure options (which will not happen with the
standard './configure ; make ; make install' procedure), and when
recompiling after a sufficiently large SVN update but without running
'make distclean' or 'make depend' first (which will not apply to a user
compiling for the initial install).

I do not experience this with compiling under Linux in general, though
the general run of projects seem to have a somewhat lower standard and a
somewhat higher chance of such problems than is the case with MPlayer.

I have experienced approximately this with some specific other projects,
a few of which I have even failed to get to compile at all. The worst of
these have been those which don't provide a configure script, or in a
few cases even a Makefile. This is, however, absolutely not the general
rule for open-source projects in my experience; it is the exception, and
a somewhat unusual exception at that.

Post by Phil Rhodes
So you do one command at a time, and spend anything from half an hour
to two days fixing all the problems each one has.

When I have encountered the need to do "one command at a time" fixes,
which as I say has rarely if ever happened with MPlayer, it almost never
takes even as much as half an hour to fix (and "a couple of minutes" is
much more common); the exceptions are cases where the problems are so
severe that I end up not being able to get it compiled at all, which as
I say are quite rare.

Post by Phil Rhodes
During this time you are roundly derided by the creators of the
software - as I am being here -

You are not being derided here so far as I can see; you are being
disagreed with, and asked to support your position. Also, few if any of
the creators of the software have interposed themselves into this
discussion as yet.

Post by Phil Rhodes
for being such a dunce as to make this happen, an insult given
particular force by the tendency of Linux people, as here, to pretend
that such problems are impossible and unthinkable and can never
happen, as opposed to being absolutely the norm.

I find your description of it as "pretending" that these problems are
not the norm to be insulting. I have tried to avoid insulting or
otherwise attacking you, despite the consistently rude way you have
expressed your views; I would appreciate it if you made a similar effort
to avoid insulting other people.

Post by Phil Rhodes
Almost invariably these issues are caused by hardcoded paths or
missing library source

Are you talking about MPlayer here?

Post by Phil Rhodes
(truly, Linux is the only OS in the world under which absolutely
everything is monolithic and you end up needing a gig and a half of
the source code to the universe to create any program whatsoever;
then again, it is so poorly standardised that dynamic linking is
pretty much infeasible).

I find it difficult to interpret this, coming in this place and in this
context, as anything other than trolling.

Post by Phil Rhodes
It is my direct experience on the basis of at least several hundred
attempts that the combined first-time success rate of all the various
Linux software deployment strategies (apt, compilation, rpm, etc) is
well down into the single digit percentages, and probably under 5%;
a Windows deployment is probably exactly the inverse.

I find this ludicrous. I have had well over 95% success with everything
combined, nearly 100% success with apt, and at least 80% success with
compilation (I don't use RPM). It has rarely if ever taken more than the
trivial "just do it" commands to make it work that well. If you are
indeed seeing this kind of failure rater, I am inclined to think that
either you or your environment must be doing something very wrong.

Post by Phil Rhodes
Linux is so bad, so hopelessly unreliable, so ludicrously abstruse
and hard to work with that it's absolutely laughable and if this is
not your experience then we simply seem to live on different planets,
or you are suffering from a politically selective memory.

I think the answer would be somewhere closer to the former. I would find
the latter to be mildly insulting.

Post by Phil Rhodes
Call it an "assertion" if you like. I can only report my experience,
and that is what it is.

Report it as your experience, and we're fine.

Try to claim that it is the universal truth for everything everywhere,
which is what I see you as having done here, and we have a problem.

Post by Phil Rhodes
I no longer specify Linux for any task where I don't know absolutely
that the software I need comes preinstalled with the OS, because as a
very practical matter, adding anything else is entirely in the lap of
the gods.

If this is the case for you, then either you are exceedingly unlucky, or
you are doing something wrong. I have dozens if not hundreds of
non-preinstalled programs on my current computer, and thousands more are
available for installation at the drop of a hat; I could install any one
of those immediately with virtually zero chance of problems.

Post by Phil Rhodes
It is not really possible to solve these problems because there is
effectively no standardisation or consistency. The first thing that
needs to happen to Linux is for all but two or three of the
distributions to go away so it's actually possible to get things to
conform.

Properly responding to this would take this discussion even further
off-topic than it already is, and I probably don't have the background
to be able to properly argue it anyway.

[The Wanderer]

Post by The Wanderer
Nope. The initial environment was plain-vanilla Debian Sarge (back when

Post by The Wanderer
that was stable)

See, this is exactly what I'm talking about. "I used this, when it
was OK to use this, which you... sort of have to just know.

No, you don't. My point was that this is a plain, unmodified, untweaked
generic system, with no special steps taken. It just worked in that
environment, and it should just work in most environments exactly the
same way. In the vast majority of cases, no special knowledge should be
required.

Post by The Wanderer

Post by The Wanderer
source tree (initially taken from a release tarball, then later on
downloaded via Subversion)

Which you have to get.

Yes, but then you have to "get" the software for any other install too,
don't you?

Post by The Wanderer
And unpack.

True... again, how is this unusual?

Post by The Wanderer
And copy to the right location, or more to the point, perform the
right get-and-unpack-and-copy dance of destruction for this
particular tarball or SVN checkout on this day on this particular
configuration of this particular linux distro with the particular
modifications you or the software engineer or the packager has made,
for each of which any variation involves hacking shell scripts all
day and night, sacrificing a chicken and standing on one leg in a
rainstorm.

Nonsense. Unpacking the tarball in any location should be fine - or, at
worst, simply taking care to extract it in any empty directory (and even
that step isn't required for MPlayer). No special steps should be
necessary.

Post by The Wanderer
This is so typical of linux people - you make out that it's simple
simply by ignoring the complicated bits. Compare Windows or Mac
experience: download installer. Run installer. Done.

You can do that (or even less) successfully on Linux, if you want a
packaged version. It's just that packaged versions aren't going to get
much support, and most of what support they will get is likely to come
from the people who put together the package. But then again, packaged
versions don't (in my experience, and apparently that of other people
whom you appear to have been ignoring) get much support from their
(developers, vendors, et cetera) on other OSes either.

Post by The Wanderer

Post by The Wanderer
This was the case a decade or so ago. It isn't the case now.

God help those who tried to do this a decade ago, if the current
situation is considered -good-.

What I'm trying to say is that the current situation is not nearly as
bad as you make it out to be.

I notice that you have snipped out and ignored all of the previous
places where I either said something to that effect or asked that you
back up your claims with something other than simple assertions. This is
starting to remind me slightly (and probably inaccurately) of the
behaviour of rec.arts.anime.misc's recent "the sky is falling/the
industry is doomed" troll...

[The Wanderer]

Post by Charles philip Chan

Post by Terry Linford
But the HumboldtCounty/(2) plays audio fine, but video plays as if
its in ultra slow motion, and completely out-of-sync with audio.
Its also really difficult to interrupt the playback ... I have to
click on 'stop' a bunch of times to cancel.

Are you using Packman? Complain to them. I am using a self compiled
current svn verion (dev-SVN-r27498-4.2.1) and the trailer plays fine.

Indeed. Very few sources of precompiled, packaged versions get support
here, and IIRC that isn't one of them.

The recommendation of the developers is to be always running the latest
SVN version (or at least within a month or two of that), compiled from
source on the machine which will be running it. The more recent the
version you're running, the better your chances of getting help and the
better the chance that any problems you report will get fixed.

[Phil Rhodes]

Post by The Wanderer
The recommendation of the developers is to be always running the latest
SVN version (or at least within a month or two of that), compiled from
source on the machine which will be running it. The more recent the
version you're running, the better your chances of getting help and the
better the chance that any problems you report will get fixed.

This is a common attitude among open source software engineers, and is the
principal reason why it's reasonable to assume that most opensource software
is effectively unsupported.

The people who make these statements know full well that most mere humans
barely know what SVN is, much less are capable of compiling software from
source, and this becomes nothing more than an excuse not to provide any
support.

What I don't understand is why it's necessary at all. Nobody's -required- to
work on open source or support it. If you don't want to do it just say
"sorry, you're on your own" - the current attitude is just elitist.

P

[Terry Linford]

Hi Phil,

This is a common attitude ...

Clearly and succinctly stated. I couldn't agree more.

1st a Linux user is told over and over to rely on the mainstream
distros. Then, when we do, we're told to upgrade to a
trusted/reliable packager's "improved" versions. Finally, we're told
to build everything ourselves, and that anything OTHER than the
latest-n-greatest-do-it-yourself version is 'unlikely to get support'.

If I ran my business this way, nobody would ever use my products.

Thanks again for your comments. I've got a Mac that works, and I
suppose I'll just use that unitl there's a supported product that a
"normal human" can rely on.

Terry

[Charles philip Chan]

Post by Terry Linford
1st a Linux user is told over and over to rely on the mainstream
distros. Then, when we do, we're told to upgrade to a
trusted/reliable packager's "improved" versions. Finally, we're told
to build everything ourselves, and that anything OTHER than the
latest-n-greatest-do-it-yourself version is 'unlikely to get support'.
If I ran my business this way, nobody would ever use my products.

Bug reports and support questions should first go to the distro you are
using. The big problem for us is with multimedia programs, since most
distros can't include a fully functional version due to legal issues.

http://en.opensuse.org/Restricted_Formats

Your MAC can include all the multimedia program that it wants since it
is a commercial product and you have paid the licensing fees as part of
your purcahse.

Charles