[FFmpeg-devel] [PATCH] lavf: F3M spec, muxer, demuxer and tools. (WIP)
nicolas.george at normalesup.org
Thu Aug 16 11:09:27 CEST 2012
Le nonidi 29 thermidor, an CCXX, Michael Niedermayer a écrit :
> iam not reviewing the design because if i want to
> improve some container format, i would work on nut and i think
> others similarly should concentrate their efforts on making nut the
> best design instead of spliting the effort between f3m, nut and ffm
I really do not think it split effort, because I believe that the objectives
of NUT and the format I am trying to design are too different, and NUT can
not be made to achieve both. But maybe am I wrong and you can correct me and
point me in the right direction.
Imagine the following scenario: we have recording.nut, 6 giga-octets,
3 hours, we want to extract from it movie.nut, 4 giga-octets, 2 hours. With
the following constraints:
1. Creating movie.nut should take less than 20 seconds (just reading _or_
writing the data on the hardware I have in mind would take 80).
2. movie.nut should not require more than ~300 mega-octets of additional
3. Removing recording.nut at a later time should free ~2 giga-octets of disk
Constraints 1+2 could be achieved using some kind of edit-decision-list, but
constraint 3 defeats that.
Do you think it could be invented on top of NUT without basically inventing
a new format?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel