[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Original]
Re: [MPlayer-users] regressions & requests
On Sat, Dec 04, 2004 at 02:44:48PM +0100, Oswald Buddenhagen wrote:
> i'm recording from tv with mencoder. mpeg4+mp3, both vbr. as mencoder
> uses a quite uncommon way of ensuring a-v sync, it is also about the
> only tool capable of re-muxing (cutting, merging) the files without
> making a mess of the a-v sync. however, there are a few problems, some
> of which are regressions:
> - merging became totally impossible. even the ugly "cat & remux" hack
> doesn't work any more, as the rest of the stream is ignored after the
> first part.
it does, you just need to do it right. try -noidx or -forceidx...
> and my request for mencoder accepting multiple input files went
> without _any_ reaction ...
because it can't be done without a large rewrite, which is needed
anyway because mencoder sucks.
> - when re-muxing a file that has no index (or -noidx is specified), the
> index of the new avi points to non-i-frames. this leads to very
> "interesting" effects.
> - -ss & -endpos need the option to specify an exact frame. specifying a
> frame with a timestamp is both cumbersome and imprecise (no floats,
working with frame numbers is impossible unless you want to count
frames from the beginning of the file, and even then stupid because
framerate is not necessarily fixed. what you meant to say is that
everything should work in a time unit linked with the source video
(which would be frames for fixed-fps files) rather than always using
seconds, and i agree totally.
but it's irrelevant right now since you can only seek to keyframes and
since mencoder is hopelessly broken in many other ways.
> - feature request: when the encoder detects black (or, more generically,
> uniformly colored and possibly dark) frames, automatically make the
> first frame in such a series an i-frame. this would help cutting
> commercials on stations that do soft-blends.
mencoder is really not the tool you want for tv capture...
> now some blueSkyDreams stuff:
> - auto-crop while encoding.
> the usefullness of this for tv recording should be obvious.
> i suppose it is not possible to create avis with changing dimensions,
> so a prerequisite for this would be an auto-chunking feature (another
> old request of mine that went without _any_ reaction ...).
we don't work for you. if you really want people to attend to your
requests, offer them money or cola or something. (not me though, i'm
not interested in doing this stuff anyway..)
> - auto-enable-deinterlacer while encoding.
> conditionally enable a preselected deinterlacer depending on whether
> the input is detected to be interlaced.
good luck... it's easier to make a program to predict the outcome of a
presidential election than to tell whether video is interlaced or
> both the auto-crop and auto-enable-deinterlacer should operate on a
> per-show basis, but obviously this is practically impossible to
> detect. consequently the detections should be done at key frames. the
> encoding needs to be held up a few frames until the detection is done.
> the cost of doing casual detections should be by far smaller than
> deinterlacing and encoding full-size all the time.
nope, cost of doing detection is many many times greater than
deinterlacing. in fact, it would be faster to encoder each file both
deinterlaced and as-is, than to reliably detect whether to deinterlace
> - mencoder could support suspend & resume triggered from the outside,
> prolly via some signals (USR1 and USR2 maybe). that would ease the
> integration with tools like the german commercial cutting service
submit a patch if you like. same goes for all the stuff you're
requesting. either submit patches, or hire someone else to code it for
you... that's the way free software works.
> btw, TomsMoComp (the amazing deinterlacer, you know ;) is now even in
> transcode. for an experienced mplayer hacker it should be a matter of
> minutes to integrate it ...
maybe so, but i'm not interested in tv capture.
MPlayer-users mailing list