[FFmpeg-devel] Format for fast extraction (was: [PATCH] Dynamic plugins loading)
Tue Nov 2 22:09:17 CET 2010
Le duodi 12 brumaire, an CCXIX, Michael Niedermayer a ?crit?:
> ffmpeg -i blah /dev/stdout | split ...
And what do I do with the files produces by split? I can do nothing useful
with them without concatenating them again. I need to be able to play them
as a single file.
What I need, and what my custom format allows, is this:
(1) I have "recording.xxx", 6?Go, I can "mplayer recording.xxx" and play it
absolutely normally, including seeking.
(2) I can extract (using timestamps I found with any suitable interface) two
parts "program1.xxx" and "program2.xxx", 2?Go each.
(3) I can "mplayer programN.xxx" to check that nothing is wrong, and play
them absolutely normally, including seeking.
(4) I can then remove recording.xxx.
With the following requirements:
(A) Step (2) must be fast. Copying 2?Go of data for each extraction is not
(B) Step (4) must give me back the disk space corresponding to the parts of
the video I do not keep.
(C) (optionally) During step (3), disk space should not grow to much, actual
data should be mostly shared between recording.xxx and programN.xxx.
Actually, (C) is probably a direct consequence of (A).
It would be acceptable if recording.xxx was destroyed while creating
Condition (B) excludes having programN.xxx being just an edit list around
recording.xxx. In fact, since Unix does not allow splitting a file nor
truncating its beginning, conditions (A) and (B) pretty much imply that
recording.xxx must actually be a set of small files.
Which leaves the question: How do I make them appear as a single, seekable,
video, to ffmpeg / ffplay / mplayer?
I see three options:
(1) Use any concatenable, headerless format, and use something like FUSE to
make the small files appear as a single big file.
(2) Use any concatenable, headerless format, and design a custom URLProtocol
that virtually concatenates files.
(3) Design a format and the corresponding AVInputFormat.
I hesitated a lot between all three options, but in the end I chose (3).
Now, recording.ivd is in fact a directory with a single file "index" holding
the global headers and an index for seeks, and numbered files that hold the
actual payload with a simple header format.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel