[FFmpeg-devel] Format for fast extraction (was: [PATCH] Dynamic plugins loading)

[Nicolas George]

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
    acceptable.

(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
programN.xxx.

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.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101102/5c9eebc3/attachment.pgp>