Multimedia :: future of mplayer extensions

After 2 years I finally got around to downloading mplayer-1.0pre8cvs.uci, mainly to have mencoder in the same package and not need to load mesa3d to use it.  Overall, very nice job, WDef.  I did notice that the audio does not play on some of the files that work with mplayer-xfree86.tar.gz (now converted to mplayer.uci on my box), and -vo sdl doesn't seem to be supported for fullscreen without XFree/Xorg. These may be simply configuration issues that I have yet to work out.  But it brings me to the point of this post...

There are at least four different versions of mplayer in the repository, all likely to have different features and behaviors.  It might be good for the community if those of us who have the interest and ability to work together to create a single mplayer package (or two...uci & unc) which includes all possible functionality supported by DSL

I haven't used the 1.0rc1try3 mplayer.tar.gz mainly because I believe it should be a single package, and I don't care to mix *.tar.gz with *.dsl.  But if its features are complete as can be, maybe we should work to improve that particular package and consider removing the older ones from the repository.

Are there any thoughts/disagreements on this? Please throw in your opinions.

On an off-topic note, thanks roberts for an old post that helped me get mplayer working in the Linux console:
rm  /dev/fb0  #remove symlink
mknod /dev/fb0 c 29 0 #original is not useable by anyone but root
usermod -G staff,dialout,fax,voice,cdrom,floppy,tape,sudo,audio,dip,video,games,users,usb,tty dsl
(I had already added dsl to the tty group for using mc subshells, so the usermod command has a double helping of usefulness)

Another problem with my old mplayer uci is that is was not compiled with alsa support.  I might have tried but it didn't work or something.  If you are trying it again, please post which formats didn't play for future reference.  I don't know if I ever tried -vo sdl but I will. I personally prefer one or two big ucis to a bunch of little things to load,  but whatever floats your boat.

I do have a WIP uci upgrade to the mplayer uci that's been sitting complete on my harddrive, which also contains a lot of other stuff and extra support (so quite big), including transcode again,  together with another uci containing a bunch of dvd building applications, which points at the libs in the other.  I'd have to check to see what's actually in there.

Both work, and I do use them (have copied dvds, re-encoded etc with good results also) not tested across different audio formats etc though.  x264 support in mencoder would not compile in back then, which annoyed me, though the x264 binary did build ok iirc.  That could have been an issue with the particular svn sources at the time, or probably the older compiler back then, or perhaps anon found some trick to this. The WIP could do with updating again, at least for mplayer, arguably less critically for the libs.   But with a bit of prodding ... after a morning's recompiling it'd be updated and could be posted for testing.

Happy to collaborate of course, logistics might be difficult unless we put the lot on a webshare or svn or something and work that way.    The sources to all that are quite big.

Or if we can get anon involved, we could start a thread where we post our build steps and problems as these occur.  Open to suggestions.  I do remember for example I had an awful time with ffmpeg for eg in the WIP.

The issue of different versions in the repo brings up a bigger issue - the need for an "archive" section of the repo.  Perhaps old versions of extensions that have been supereded should go in the "archive" section so they are still accessible but out of the "mainline" repo.

please post which formats didn't play for future reference.

Quicktime/MOV file format detected.
VIDEO:  [SVQ1]  320x240  24bpp  15.000 fps    0.0 kbps ( 0.0 kbyte/s)
Clip info:
encoder: Encoded with Cleaner 5
Opening audio decoder: [qtaudio] QuickTime Audio Decoder
Win32 LoadLibrary failed to load: QuickTime.qts, /usr/lib/win32/QuickTime.qts, /usr/local/lib/win32/QuickTime.qts
failed loading QuickTime.qts
ADecoder preinit failed :(
ADecoder init failed :(
Cannot find codec for audio format 0x706C6351.

I don't remember what the other was, but I wouldn't be surprised if it were another proprietary format. It's possible that my version of mplayer shouldn't legally be supporting these formats, but I don't really know or care very much.

Your mplayer does also play some files that I couldn't play before, such as some improperly-created avis I was messing around with (direct stream copies)

As far as the collaboration, I wasn't specifically suggesting multiple people putting the package together, but that they/we work together on ideas and testing more so than we would in the typical smaller, simpler extensions.  Personally I have no intention of working directly on any large files, since it annoys the heck out of me to upload them.  I just though more input during the creation stage rather than only after the extension has been built would produce a better package that does more for more users.

I just finished downloading Xorg uci, so -vo sdl is probably not going to be needed here, but I would think it *should* be available seeing that DSL aready has SDL.  With that and the Quicktime issue, I wonder if the codecs were built into the application itself.  I included the codecs when building mplayer, but did not include them with the package.

From a search, codecs-QT.uci seems to have it.  There used to be a codecpak extension in mydsl but I guess it was removed... (still on some old mirrors though)
codecs-QT.uci seems to have it.
Thanks.  I'll probably try that soon.  This is precisely the sort of thing I'm hoping to address with this thread, by the way.  It makes no sense to me to have a codecs-QT.uci.  How many people install a media player with the intention of supporting only a portion of the available popular formats?  I'm guessing zero.  So why not have all the codecs either included with mplayer or combined into a single codecs package? It would be particularly convenient with the uci format because you're not wasting the ram you'd do with dsl/tar format and you need only one codecs directory.

Next Page...
original here.