[MPlayer-dev-eng] MPlayer and MEncoder in single binary (was: [RFC] Advertising Slave mode)

[Oded Shimon]

On Wed, Aug 24, 2005 at 05:34:30PM +0200, Ivo wrote:
> On Wednesday 24 August 2005 15:16, Rich Felker wrote:
> > On Wed, Aug 24, 2005 at 08:36:43AM +0200, Benjamin Zores wrote:
> > > > This brings up the issue that was brought up regarding x264's
> > > > visualization
> > > > - it would mean MEncoder would depend on X and several other stuff...
> > >
> > > well, it will depends on libvo depencies right ?
> > > not necesserally to X in no vo using X has been compiled.

Actually, I was just making an example here with the x264 stuff.. My point 
was, if you make mencoder/mplayer single binary, mencoder will depend on 
all of libvo's dependancies!

> > No, it does not use libvo. It uses its own direct X access because
> > it's stupid..
> 
> Yes, that's stupid. If mplayer/mencoder ever becomes one binary and support 
> for visualization is added, it should be handled by mencoder itself and 
> x264 should be compiled without its stupid X stuff. My previous comment on 
> the subject (the split at the end of the video filter chain) was nonsense 
> btw, because by then the video isn't encoded yet, so you won't see the 
> artifacts introduced by the encoding. The split should go inbetween the 
> encoder and the muxer. One way goes to the muxer as normal and the other 
> goes to a decoder and a libvo output module. That way, you could compile 
> mplayer/mencoder with just libaa support and use that for visualization of 
> the encoding process :-)

The only way to make it "really" good is by changing the encoders - the 
encoders DO know the picture WITH the artifacts, it's not even overhead, 
because they need it to calculate the next frame.. This would ofcourse be 
totally ungeneric, and near impossible because there's a clear seperation 
between the encoders (ffmpeg) and mplayer...

Maybe a neat new feature for ffmpeg would be the ability to give it a 
function pointer to call for each frame with the artifacted frame.. for 
encoders which support it...
It's doable, and sane. I think. Should I try that?...

- ods15