[MPlayer-cygwin] Any interest in a hack I made?

Reinier Zwitserloot surial at gmail.com
Thu Oct 20 05:45:52 CEST 2005


I've made the following hack to mplayer. It's definitely not the
cleanest code (I'm not a C programmer) but it works, and I've come up
with some nifty uses for it:

 hack #1: Allows specifying start and end  byte position within a
file. Useful for, amongst other things, using mplayer as a backend for
playing video files embedded inside another, larger, data file.

Usage:

mplayer mybigcontainer.dat at pos:1234:5678

will act exactly the same as if trying to play a file that's been
created by extracting all bytes in mybigcontainer.dat from byte
position 1234 to byteposition 5678.

it 'beats' the -sb parameter by also allowing specification of an end
position, and as it works on a per-playlist-entry basis, you can
specify different positions on different playlist items. Seeking
through such bounded files works just the same as if you actually
extracted the specified range to a separate file.

the endposition is optional; if it omitted, the end of the file is assumed.

 hack #2: by setting 'AUTO_PLAY_SELF', mplayer compiles with the
following 'feature':

 if no command line is detected, assume that the command line reads:

-fs -autosync 30 -framedrop c:\absolute\path\to\mplayer.exe at pos:10597045

This allows you to append any video file onto mplayer.exe and thus
obtain a 'stand alone player', that will run it's own internal video
file when invoked without parameters.

Problems with these hacks:

hack #1 has been tested on mac osx and windows XP and seems to work
fine on both machines.

hack #2 is currently windows only (I don't really know how to obtain
the path to your own executable in some sort of OS independent way;
currently it uses GetModuleFileName, but that's a windows function. At
least the code that does it is layered away in an #ifdef
AUTO_PLAY_SELF and #ifdef WIN32 block. Also, there's the problem of
determining the filesize of the resulting app. I guess a different
method could possibly be used to determine the end of the EXE without
making a test compile just to get the magic number, but I wouldn't
know how.

Still, I thought the video that contains its own player, that will
probably work on just about any windows-based machine that has the CPU
clout to play video in the first place, even without admin rights and
no codecs or anything, would prove to be extremely useful. It
certainly helps me out as it allows to distribute XviD based video to
people without the codec and without admin rights (and without
knowledge of how to use a command line video player like mplayer).

If this kind of thing sounds like something that should make it into
mplayer's codebase, I'll set up some diffs and mail them to the
appropriate people (though for hack 2 I'll need a hint as to how to
figure out where the executable stops and the appended video starts.
Possibly a post-compile operation that hacks the EXE by finding a
unique 64-bit number and hex-editing it to the size of mplayer.exe -
that's about as far as my guesses go on this one.

 --Reinier Zwitserloot




More information about the MPlayer-cygwin mailing list