Some small feature requests for mencoder
Hi, first a short overview of the problem I'm having: I'm one of the primary organizers of breakpoint (http://breakpoint.untergrund.net), an annual demoscene party (real-time art festival if you want :) in Germany. We have several demo competitions and have gotten entries running on basically anything that executes code over the years. There's no way to collect a lot of these devices to a video projector, and besides it would be a major hassle to reconnect everything again and again during a competition, so we make videos where we can (usually DV for anything we capture ourselves). We also have seminars, liveacts and other events, which are also taped; so in the end we end up with lots of raw DV material (around 1.5TB last year) that have to be encoded. We did this manually last year (a major pain, I don't think I have to explain further) and plan to do it semi-automatically this year, with a small encoding farm together with a short python app that distributes encoding jobs to machines on that farm. This is where mencoder enters the scene. We have a lot of captures from machines like C64s and Amigas that tend to do things like 1pixel/frame scrollers. mencoder with yadif/mcdeint gives *by far* the best results among everything we've tested on those captures, so we want to use it, BUT: (and here's the actual problem, sorry for the long intro ;) It seems that yadif needs to buffer about 3 frames before it can start working (not surprising given the way it works). During that time, it simply seems to return junk frames with a timestamp of 0 (or whatever). No problem in mplayer, but in mencoder, it means that there's a few too many frames, which is not only annoying (each encoded video starts with 3 green frames), it also means there are too many frames in the data stream, so mencoder later drops 3 frames to get back in sync again. In short, it would be really great if there's a way to work around that, but I haven't been able to figure out how to do so (even after intensive lecture of the man page ;), and it would be great if someone has a solution. Thanks in advance! -Fabian "ryg/farbrausch" Giesen Breakpoint organizing team
Hello, On Wed, Feb 28, 2007 at 08:48:15PM +0100, Fabian Giesen wrote:
It seems that yadif needs to buffer about 3 frames before it can start working (not surprising given the way it works). [...]
Hmm... You did try latest SVN? I think there was something applied that was supposed to fix it. Yep, here it is: "r22134 | michael | 2007-02-05 01:46:53 +0100 (Mon, 05 Feb 2007) | 2 lines skip first (green) frame" I didn't check if it actually works though. Greetings, Reimar Döffinger
Hmm... You did try latest SVN? I think there was something applied that was supposed to fix it.
Ah, got me, the version I tried was from January.
Yep, here it is: "r22134 | michael | 2007-02-05 01:46:53 +0100 (Mon, 05 Feb 2007) | 2 lines
skip first (green) frame"
I didn't check if it actually works though.
"Somewhat". I don't get 3 green frames anymore, but just one green line on the top of the first frame of the deinterlaced output, which is definitely an improvement :) More seriously, I got an assertion failure right in the first sequence I tested: "Assertion failed: iscore >= 0, file snow.c, line 2169" I tried to get a minimal reproduce, this is what I came up with: Command line: mencoder -fps 50 -ovc xvid -xvidencopts bitrate=4000 -vf \ yadif=3:1,mcdeint=0:1:10,softskip -o tbl_deilace_cut.avi \ tbl_ilace_cut.avi The video is available at: http://farbrausch.de/~fg/reproduce/tbl_ilace_cut.avi This is about as short as I could get it (may still work if you cut off the first 1 or 2 frames of that, but not much more). mplayer+libavformat/libavcodec are both the current svn versions as of Feb 28 2007, 8:00pm (GMT+1), i.e. a few hours ago. Platform is win32/mingw32 with gcc 3.4.5. Hope that helps. Kind regards, -Fabian "ryg/farbrausch" Giesen
participants (2)
-
Fabian Giesen -
Reimar Döffinger