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

David Conrad umovimus at gmail.com
Sat Jul 28 22:23:45 CEST 2007


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.

-David



More information about the FFmpeg-soc mailing list