MPlayer and MEncoder in single binary (was: [RFC] Advertising Slave mode)
On Wed, Aug 24, 2005 at 03:19:41AM +0200, Ivo wrote:
On Tuesday 23 August 2005 23:44, Dominik 'Rathann' Mierzejewski wrote:
A symlink would suffice, with the addition that we could automatically switch on the slave mode if the binary is called mplayer-slave.
Which reminds me of the mplayer/mencoder in one binary patch that was posted a while ago. What happened to that? :) I thought it was a good idea and it also might help with "viewing the output while it's encoding" that somebody asked about. If libvo is in the binary, mencoder could use that while it's also writing to a file. Something like have a split video vf that's added to the normal filter chain. One direction follows the normal encoding path it is doing now, and the other path of the split goes to vf_vo and some libvo output.
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... The idea in general sounds good to me, I'm for it, but the two big problems are - 1. What about windows? You can't (easily) change argv[0] there... 2. The dependencies I just mentioned... Which makes it possibly a good idea to leave this thing as a compile time option, but unfortunately, it means A LOT of nasty #ifdef's in mencoder.c (and mplayer.c ?), and I'd preffer keeping it as is than making those files even uglier than they are... Possibly making a 'common-variables.h' could ease the issue...
Hmm, I just see this goes to -docs and not -dev, but anyway :-))
Fixed :P - ods15
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.
The idea in general sounds good to me, I'm for it, but the two big problems are - 1. What about windows? You can't (easily) change argv[0] there...
that's where we hang with my patch few weeks ago. does anyone has a better idea now ?
Which makes it possibly a good idea to leave this thing as a compile time option, but unfortunately, it means A LOT of nasty #ifdef's in mencoder.c (and mplayer.c ?), and I'd preffer keeping it as is than making those files even uglier than they are... Possibly making a 'common-variables.h' could ease the issue...
that would be a good thing imho if we try to include this patch as i remember having to ifdef a lot of things in mencoder not to include/define things twice. the mplayer.c and mencoder.c files nearly share the same first 200 lines. Ben
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.
No, it does not use libvo. It uses its own direct X access because it's stupid.. Rich
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.
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 :-) --Ivo
On Wednesday 24 August 2005 18:34, Ivo wrote:
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.
It's off by default and not even that useful when switched on, because it requires you to push a key for encoding each frame ;-)
On Wednesday 24 August 2005 19:13, Jan Knutar wrote:
On Wednesday 24 August 2005 18:34, Ivo wrote:
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.
It's off by default and not even that useful when switched on, because it requires you to push a key for encoding each frame ;-)
:))) Who ever thought of that functionality? Because most of the time, you don't want to see how the first few frames look like, but more like about the 100th frame. Some nice way to get RSI :) --Ivo
On Thursday 25 August 2005 05:14, Ivo wrote:
It's off by default and not even that useful when switched on, because it requires you to push a key for encoding each frame ;-)
:))) Who ever thought of that functionality? Because most of the time, you don't want to see how the first few frames look like, but more like about the 100th frame. Some nice way to get RSI :)
It's probably only vaguely useful for x264 developers. Probably also the reason why documenting it became such a huge flamewar :-)
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
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
On Thu, Aug 25, 2005 at 04:30:05AM +0200, Ivo wrote:
On Wednesday 24 August 2005 19:31, Oded Shimon wrote:
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.
Yeah, you're probably right about B frames not being kept, but the rest most likely are (maybe the last P before a I isn't?..), and I think even if this can't be called for EVERY frame, it would be worth it.. if such a thing ever was implemented, I'd want the function only to output once like every 25 times it's called...
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 :-)
I think you got confused by what I meant, I didn't mean to make a function in ffmpeg to CALL, I meant you give ffmpeg a function pointer, and ffmpeg will be the CALLER, whenever it can. I'm gonna put this on TODO list.. it sound interesting... Even if it's only supported lavc mpeg4 and partially, it would still be worth it, there's nothing better than seeing the output of your encode while encoding... - ods15
On Thu, Aug 25, 2005 at 08:35:58AM +0300, Oded Shimon wrote:
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 :-)
I think you got confused by what I meant, I didn't mean to make a function in ffmpeg to CALL, I meant you give ffmpeg a function pointer, and ffmpeg will be the CALLER, whenever it can.
Using callback is nonsense. If this data is available, it can be exported via the codec context. And if it's not you'll just have to decode it yourself anyway. Rich
participants (5)
-
Benjamin Zores -
Ivo -
Jan Knutar -
Oded Shimon -
Rich Felker