From: Dan Dennedy <dan@de...> - 2007-10-30 04:18:53
On Monday 29 October 2007, Ruslan Popov wrote:
> Hello, Dan.
> I've been watching for the development of Kdenlive/MLt a quite long time.
Then, you will notice that MLT, while active, is not very active. :-(
> But I don't see any changes in DV timecode support.
It really bothers me that I don't have good API documentation, unit test,
debugging aids, and a methodology that includes profiling. I am still trying
to fix things rather than add. I consider mlt_profile a fix of sorts. Lately,
I have been working on a fix for a regression it introduced. That regression
highlights a design problem that also requires "fixing," but I really need to
get on the above before addressing it.
> This part is very important for me.
> If you can't spend a time to repair this feature, can you point me into MLT
> source code which is responsible for exported timecode? --
Basically, everything in MLT goes to uncompressed and then may be encoded on
output. There are two things to address. The first is to pass through
unmodified DV frames. The second is to store the timecode and recording
date/time as metadata properties on the frames requiring encoding.
Regarding pass through, since the libdv producer should be considered
deprecated, the ffmpeg avformat producer should put the raw DV onto each
frame as a property. That part is not hard for DV and perhaps can be
generalized for non-temporal comressed video. Then, the framework needs to be
able tell the consumer if a particular frame is "dirty." That does not exist
and is non-trivial. Lastly, the consumer uses the frame's raw DV if not
dirty, and compresses it otherwise. I'm not sure how easy or obvious it is to
switch between compressing and inserting raw stream data with the ffmpeg API.
Regarding the metadata, ffmpeg's dv demuxer/decoder does not extract this
metatdata. So, something needs to be added to supplement it. You could use
libdv as a filter to parse the raw DV on the frame and apply properties.
Likewise, on dirty frames, we need to write the metadata into the DV frame
created by ffmpeg. Currently, consumer_avformat has libavformat handling all
the encoding and file I/O in a coupled manner. I am not sure what problems
may arise in trying to decouple encoding and muxing in order to do some
stream post-processing. Finally, if a dirty frame was rendered from more than
one source video, there needs to be a rule or policy over whose frame's
metadata gets priority and propogated.
You could simplify some of this by using purely libdv, but libdv's video codec
is not nearly as good as ffmpeg's. Well, those are some of the things I have
been thinking about on this topic.
Get latest updates about Open Source Projects, Conferences and News.