[MPlayer-dev-eng] [PATCH] enable vobsub in mencoder

[compn]

On Wed, 30 Sep 2009 03:59:44 -0400, Dani Church wrote:
>On Wed, Sep 30, 2009 at 03:24, Reimar Döffinger
><Reimar.Doeffinger at gmx.de> wrote:
>> I assume this is a copy from mplayer.c.
>> While some people would like to just let mencoder rot, I think this
>> really needs to be made into a common function that mplayer and mencoder
>> share, otherwise at least one of them will become broken rather soon.
>
>It's mostly a copy, yes.  The one in mplayer.c has a few additional
>lines dealing with mplayer-specific functionality, though, and I'm not
>at all familiar enough with the codebase to do any refactoring.  This
>was about a two-hour dive job, which I mainly did because apparently
>this issue has been bouncing around the mplayer-users list since at
>least 2004.

there was a patch in 2005, but it just duplicates code.
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=188

i'd like to get this mencoder subtitle patch for ass subs in too:
http://oss.netfarm.it/mplayer/patches/sm_ass_mencoder_embedfonts.diff
if anyone wants to work on mencoder ;)

>  If I were going to take a serious look into it, I'd
>probably say that mplayer.c and mencoder.c should be about a tenth the
>size they currently are, and should only deal with parsing and
>validating command-line options.  In fact, it would make a lot of

probably.

>sense to me to turn it into a multi-call binary.  After all, mplayer

its been suggested before. i cant remember if anyone successfully made
it.

>and mencoder perform basically the same function: they demux and
>decode one or more media files and then output one or more media
>streams using various output methods.  Why not allow mplayer to do
>real-time encoding of a video/audio stream while playing it back for

i wonder how hard this will be. mplayer's -vo yuv4mpeg and -dumpstream
both do not allow user to watch video at the same time.

>the user?  That'd be great when capturing from a video device, rather
>than having to use some weird combination of -dumpstream and multiple
>mplayer/mencoder processes.  Why not allow mencoder to pop up a
>thumbnail window that allows the user to see where in the video the
>encoding process is?  The only thing that's preventing these is that
>the code for mplayer and mencoder are so divergent.

mencoder video output is an old wish too.

>Sorry, I ramble.  Anyway, yes, I agree, the code should be shared, but
>the same can be said for a lot of the code in those two files.

patches welcome. its best to ask which route to take before
starting. or maybe even work on a public repo so devs can track
progress... that way design flaws can be found more easily.

-compn