[MPlayer-users] Re: Some remaining problems w/ multimedia on Linux

[The Wanderer]

Reshat Sabiq wrote:

> The Wanderer <inverseparadox <at> comcast.net> writes:
> 
>>> 2. mplayerplug-in doesn't appear to support seeking (left-right
>>> arrows don't have any effect).
>> 
>> That would be because (unless I've misunderstood how mplayerplug-in
>> operates) it's playing a stream, not a file, and seeking is not
>> possible in streamed data.
> 
> It's possible on Windows. The fact that it isn't in Linux apps slows
> down Linux adoption.
> 
> Watching hockey episodes like 
> mms://a1564.v16532f.c16532.g.vm.akamaistream.net/7/1564/16532/v0001/nhl.download.akamai.com/16532/wm.nhl.na-central/20052006/02/0349/IH_NHL_2005_2006_349_2_700K_continuous.wmv
> frequently leaves one wanting to repeat last few seconds.
> 
> It appears this simply isn't possible for streams on Linux, which
> means more power to Windows.

...I was under the impression that "streamed data" meant "data which is
sent purely sequentially", i.e., that it was *inherently* not possible
to get at any other data than what was specifically sent to you. If it
is possible to tell the server "send me data from such-and-such a
different point", then you can start the stream from a different place;
if you cache the already-played data somewhere, then you can of course
seek back into it. That, however, is not "seeking in streamed data", and
it is not how MPlayer currently does things. Whether or not a patch to
change behaviour would be accepted I don't know.

>>> Of course there's sporadic crashing related to seeking even in
>>> mplayer, and mplayer seeking isn't very friendly (especiall from
>>> the UI), but that is kinda tolerable.
>> 
>> Sporadic crashing related to seeking? What are you talking about?
>> Have you sent in bug reports? For that matter, what version are you
>> using?
> 
> I don't think i can reproduce it at will. But it has happened to me
> w/ some DVDs as well.

That's not the kind of information I was asking for... I meant more
like, what kind of crash? How is it triggered? What are the error
messages? Details, please.

(Okay, you went into a little bit more detail in your next mail. I'll
respond there.)

> MPlayer dev-CVS--4.0.2

That's not a valid version number; the relevant information would go
between the two adjacent hyphens. Whoever created the package you're
using did something wrong.

Try with the latest CVS and see if anything is different.

>>> My guess is that somebody has to contribute that code to the
>>> plug-in, correct? Can anything else be done in the meantime?
>> 
>> Sure, something can be done - exactly what I always do anyway:
>> download the file to your local system before playing it. This has
>> the additional advantages of completely avoiding buffering issues
>> and permitting you to control when your screen (in the case of
>> "fullscreen by default") and/or your audio (in any case) are taken
>> over by the stream involved. (It has the disadvantage of requiring
>> an additional step first, but I find the trade-off to be worth it.)
> 
> That additional step makes it very inconvenient to review say 10 game
> summaries every day.

<shrug> I don't find it too awkward to use to grab and watch several
trailers in sequence when I want to do that; it's less convenient than
the pure "play in browser window" form, but I don't like that anyway.

If the problem is the difficulty of obtaining the URL to grab for
downloading, then that's a different matter.

> The only plausible option appears to be enriching mplayer-plugin w/
> extra options like: play standalone, and store to disk and play
> standalone.

Well, if you want that done, take it to the mplayerplug-in people; they
aren't here, at least not as far as I know.

>>> 3. mplayerplug-in stops video play-back about 5 seconds before
>>> the end of the stream (almost always in the videos i've watched),
>>> and audio play back around 1 (maybe 2) seconds before the end
>>> (apparently only sometimes).
>> 
>> If true, this is most likely a bug in mplayerplug-in (which is not
>> part of MPlayer, and so is not developed here). Might I inquire how
>> you know where the end of the stream is, to be able to tell that
>> mplayerplug-in is stopping too soon?
> 
> Alas, i used Windows to verify that.

Right, I had halfway guessed as much.

>>> 4. mplayerplug-in URL copy cannot be pasted into gnome-terminal
>>> using Shift+insert, and one has to right-click and do Paste.
>> 
>> I don't quite understand what you're trying to do here
> 
> I use to play the clip standalone, as i can't even control volume
> from mplayer-plugin.

Yes, I gathered that part. I don't understand what you're trying do do
in the process, though. I infer that it is possible to tell
mplayerplug-in "Copy the URL of this file to the clipboard", but I don't
know what gnome-terminal is (a terminal emulator? but in that case, why
does it support a context menu, never mind a Paste operation? and what
command would you be trying to use, after having pasted it?), and I
don't know what Shift-insert would be supposed to do. I do all my
pasting with either Ctrl-v or "highlight and middle-click".

>>> 5. the killer: DRM'ed streams. ;)
>> 
>> My understanding is that these are intentionally not supported -
>> both for "we don't want to get sued/arrested" legal reasons, and
>> because we don't want to provide support to those who want to put
>> media under DRM.
> 
> Ignoring DRM'ed media is a wrong choice. Some people have to pay for
> content, like mediazone last year w/ hockey world championship.
> 
> This content is then exclusively offered by those people. Ignoring
> DRM, means people must have Windows if they wanna view it, like i did
> last year.

And it also means that if the providers want to get access to that part
of the potential viewing market, they have to not use DRM. That is a
philosophical choice on the part of at least one developer.

> The same is likely to happen in this year's Olympics.
> 
> I don't think it's illegal to support DRM on Linux, even if not thru
> official means.

Circumventing the copy protection involved far enough to play it
certainly would violate the DMCA, unless I'm very much mistaken.

> I paid full-access fee for last year's world championship, and it is
> my right, as far as i am concerned, to be able to view that content
> on non-Windows computers.

But the MPlayer developers have not been given the necessary information
on the DRM format(s) and the ways of playing the video within, and
attempting to obtain that information would (again) probably violate the
DMCA.

> I even wonder if MS could be sued for tying people's hands up. There
> must be some non-OS-specific way of doing DRM.

Microsoft isn't the problem in this case. The problem is that only
people who are willing to keep it sufficiently secret (and, most likely,
pay sufficient amounts of money) are going to get legal access to the
DRM decryption methods; without those, the content cannot be played.
Even getting illegal access and then using the resulting information
could get the developers sued.

> Although i do understand that it is likely to exclude open-source
> apps as well. Still, it would be a step forward.

In the eyes of those who think that such restrictions on the use of
content are a bad idea, it would be a step backward.

>> You would do well to go to the mplayerplug-in development lists,
>> then - it is not part of MPlayer, and is not handled here. See
>> http://lists.sourceforge.net/lists/listinfo/mplayerplug-in-devel
>> for more details.
> 
> I'll put it on my to-do list.

It'd certainly do you more good than posting about the problem here...

(Incidentally: please put blank lines between your paragraphs, for
improved readability and so that they do not get combined into one
paragraph when rewrapped as part of a reply. I've done it manually here,
but it's awkward and inconvenient.)

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.