[MPlayer-cygwin] The stand-alone player hack.

[Reinier Zwitserloot]

> This sounds interesting if implemented cleanly.  But why didn't you just
> add a -eb or -endbyte option?
>
> Read DOCS/tech/patches.txt and send us a patch.
>
> Diego

Well, as far as I can see, -sb (and any future -eb) only work on one
file, whereas mplayer does support playlists. That's my main reason
for ignoring the -sb parameter.

The @pos: code is reasonably clean I guess. The run-as-standalone
thing is a lot less clean and very specifically win32. Then again,
it's really small too. It's all in one place, all in mplayer.c's main
code. The @pos: stuff is smeared out across stream_file.c and
stream.h, and possibly stream.c, can't remember offhand. I also
haven't expanded any documentation or command line help about it,
either.

I'll read the patch rules and publish them for your perusal later this week.

>
> haha! thats a neat idea! and on windows it might actually work! on linux
> or other os it might have trouble because not everyone has -vo xv or etc..
>

Windows is also the platform with a large slew of no admin-rights
clueless users, and there's absolutely nothing you can do on a vanilla
2000 or XP install save WMV which is bogged down by bunches of patents
and such as far as I'm aware. Even flash movies don't work because
windows does not come with flash 7 installed, not even a new Windows
XP Service Pack 2 release. Most, but not all OEMs add it as an
afterthought to the default kit, but you can't rely on this.
Installing flash 7, any sort of codec, or Quicktime7 (That new H.264
stuff is extremely decent, beats the pants off of XviD, but that's
neither here nor there) all require admin rights, something I'd rather
not assume my users have.

Hence I'm not too bothered that this only works in Windows. In theory
it would not be very difficult to port it to mac OSX and linux; for
linux there's binreloc, and OSX's application deployment system is a
dream. Doing something like this can be done by just adding the video
to the stand-alone player's resource data instead of appending it to
the executable.

> this feature would work with an mplayer config next to mplayer, to add
> more options? how do you create such mplayer files?
> cat mplayer file1>mplayer.exe?

under windows, you can create them like this, works from DOS 1.0 as
far as I'm aware:

COPY /B mplayer-appendmode.exe+myvideo.ogg standalone_player.exe

My files are on a linux server and anytime I want to make one of these
exes for download, I do this:

cat mplayer-appendmode.exe myvideo.ogg >standalone_player.exe and that
works fine as well (though you have to compile that
mplayer-appendmode.exe on a windows machine and then upload it).

Right now the command line it assumes for you is hardcoded, though in
practice I don't know what else you'd need. Possibly you may want to
modify the title and not default to fullscreen, I guess. But as I am
specifically shooting for an easy to use (ie: just copy-with-append,
no recompilation neccessary per file) I don't have a good solution for
specifying what options you want. Possibly by appending some sort of
textfile first, THEN the video data, but that's beyond my very limited
C abilities.

>
> maybe a way to reverse such thing would be good too (or maybe -dumpstream
> can do it).

dumpstream can do it. I could probably work out how to add an option
that detaches the attached video, as all it would take is copying
itself to a file, minus the first X bytes.

But, as the saying goes, I've scratched my itch, so someone else's
turn. I'll try and get this into the main trunk so I don't have to
repatch everytime you guys come up with another fine improvement I'd
love to have.

 -- Reinier Zwitserloot