[FFmpeg-soc] [soc]: r532 - matroska/matroskaenc.c

Michael Niedermayer michaelni at gmx.at
Sat Jul 28 23:56:54 CEST 2007


Hi

On Sat, Jul 28, 2007 at 04:23:45PM -0400, David Conrad wrote:
> On Jul 28, 2007, at 3:10 PM, Michael Niedermayer wrote:
> 
> > On Sat, Jul 28, 2007 at 09:03:42PM +0300, Kostya wrote:
> >> On Sat, Jul 28, 2007 at 07:09:44PM +0200, Michael Niedermayer wrote:
> >>> Hi
> >>>
> >>> On Sat, Jul 28, 2007 at 05:43:03PM +0300, Kostya wrote:
> >>
> >>> 3/5 are just a md5/sha1 of a string AFAIK which was already  
> >>> suggested
> >>> 4   is just a random number (with which we are back to square 1  
> >>> just that we
> >>>     now can call it UUID)
> >>>
> >>>
> >>> what about this?
> >>> /dev/zero
> >>
> >> The best seed is lower bits of timestamp, especially in  
> >> nanoseconds - it's
> >> very random and you can't restore anything useful from it.
> >
> > we need a _PORTABLE_ solution! me have no millisec precission timer  
> > let alone
> > micro or nano
> > if portability wasnt an issue we could just use /dev/random
> >
> > simply using a constant seed is the obvious solution
> >
> > why would a file need a random/unique id anyway?, especially if  
> > all? muxers
> > create these "random" ids with a 32bit seed from the current time
> > a 32bit seed means 1 collission in ~64000 files (assuming the 32bit  
> > seeds
> > are really random)
> > using srand(time(0)) you get 1 second precission, and this will likely
> > cause additional colissions ...
> 
> mkvmerge uses UuidCreate() on Windows and reads from /dev/urandom on  
> *nix, with a fallback to rand() if either fails (seeded by  
> GetTickCount() on Windows or gettimeofday() on *nix.)
> 
> The unique ID can be used by a couple of elements (PrevUID, NextUID,  
> and ChapterSegmentUID) to refer to a segment in a different file (or  
> the same file, there can be more than one segment per file) to create  
> a playlist of segments.
> 
> I don't think it's necessary to try for a completely unique ID, the  
> SHA-1 hash of a couple of frames would be enough imo, given how  
> infrequently these options are used (I'll implement this shortly if  
> there are no objections.) I just didn't want every segment UID to be  
> identical unless the user requests it via bitexact.

no objections ...
though maybe a crc or adler32 checksum would be a better option
as they are faster

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20070728/7d2be1be/attachment.pgp>


More information about the FFmpeg-soc mailing list