Hi!

Wolfram Gloger wrote:

>>Maybe we should go one step further and disable the ffmpeg muxers now.
>>Or at least mark them as deprecated.
> 
> 
> Please don't!  I've been using them exclusively with dvbcut and will
> work on them again in the very near future (sorry for taking so long,
> I've been busy with other projects).  I plan to add Teletext subtitle
> support, in particular.
> 
> And I'd like once again to speak up against removing ffmpeg libraries.
> There is IMHO no good alternative and in particular not something
> anywhere near as fast -- although admittedly the recoding
> _performance_ doesn't matter much for dvbcut in its current form,
> because it encodes just a few pictures; but that could change,
> f.e. when recoding a complete movie to fit on a DVD
> (wouldn't that be a "low-hanging fruit" nice new feature?).

Recoding a complete movie is not dvbcut's job. But as I already
mentioned, we could add a post-proceessing hook that allows dvbcut to
start arbitrary programs and pass the export file to them (preferably
via a pipe). That is, you can use any program you like (and different
users tend to like different programs).

> ffmpeg has come a long way since the sources were imported into
> dvbcut.

Maybe. But the one thing they haven't managed to provide is a stable and
well-documented official release. Quoting the homepage: "If you are
looking for a formal release, stop now, there are none. Maybe we will
have some in the future, but don't hold your breath."

Well, I certainly won't hold my breath. But I don't want to work with
software that is permanently under construction either. Therefore,
ffmpeg is not an option for me. In particular since it may cause
problems like the one we just had with r31.

> For one thing, it is no longer necessary to change Makefiles
> or remove source code to get the libraries smaller.  You could
> configure a very lean set of libraries for dvbcut quite easily.  In my
> experience, ffmpeg is generally well maintained and bugs get fixed
> rather fast.  DVB support is unfortunately not a very high priority
> IMO but I'm working on that.
> 
> BTW: if you would remove ffmpeg just because of NIH, you would also
> have to abandon the use of mplayer or at least use mplayer w/o the
> ffmpeg libs..  :-)

NIH?

Mplayer is a different beast. First of all, it's an *external*
dependency. Actually, dvbcut will work fine without it - you'll only
lose the ability to play portions of the stream. Besides that, it might
be possible to use another player if the interface were more generic. Or
integrate a simple minimal player into dvbcut - almost everything we
need is already there: We decode audio and video streams, play audio and
display single video frames within dvbcut. Playing video streams is just
one small step from there.

Besides that, calling an external player will become quite a hairy task
once we support concatenation of multiple input files. Currently,
mplayer reads directly from the (single) input file. In order to support
multiple files properly, dvbcut will probably have to glue the data
together and send it to mplayer. An internal player might be easier to
implement.

On the other hand, that may require a substantial design change.
Currently, the program works in a rather old-fashioned way. Most
functions work with long loops that read, process and write (or display)
data until they're finished. Besides that, dvbcut is inherently
single-threaded. That is, it won't benefit from the now popular
multi-core machines at all. When you're navigating in the stream, for
example, it could start prefetching and decoding frames in the
background. Or maybe allow you to start working while it's still
building the index.

-- 
Michael "Tired" Riepe <[EMAIL PROTECTED]>
X-Tired: Each morning I get up I die a little

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
DVBCUT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-user

Reply via email to