[FFmpeg-devel] [PATCH] lavf: F3M spec, muxer, demuxer and tools. (WIP)

Michael Niedermayer michaelni at gmx.at
Thu Aug 16 18:30:51 CEST 2012


On Thu, Aug 16, 2012 at 11:09:27AM +0200, Nicolas George wrote:
> 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
>    disk space.
> 
> 3. Removing recording.nut at a later time should free ~2 giga-octets of disk
>    space.
> 
> 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?

sounds to me that what you want is basically a playlist with automatic
removial of unreferenced parts. The underlaying storage format for the
parts could be nut. That is multiple nut files that are referenced by
some kind of playlist


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120816/010242be/attachment.asc>


More information about the ffmpeg-devel mailing list