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

[Ivo]

On Wednesday 24 August 2005 19:31, Oded Shimon wrote:
> 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!

I don't see any problem there. I've never heard of anybody only building 
mencoder and not mplayer at the same time. Or are there?

Still, libvo will only have that much dependencies as there are libs etc. 
available on the system. If the mplayer/mencoder binary is created on a 
headless server with no fb/x11/aa/whatever libs/support available, libvo 
will be as good as empty and mplayer will be useless and mencoder will 
still have no visualization support (by lack of any vo :) ).

> 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...

Is this true for all encoders? I can imagine some encoders don't have a full 
image with decoding artifacts present. IIRC for example I and P frames are 
saved (with artifacts) because they are referenced, but B-frames are not. 
They aren't even created.

> 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?...

I don't know enough about ffmpeg to really comment on that, but I suppose it 
could be done if it's sure beforehand that all artifacted frames are really 
available to the encoder. Or maybe it can generate the artifacted frame if 
it's asked for by this function call and it wasn't available inside anyway. 
I think you better ask the ffmpeg guys :-)

--Ivo