[FFmpeg-soc] [soc]: r532 - matroska/matroskaenc.c
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:
>>> 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
>>> 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?
>> 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
> 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.
More information about the FFmpeg-soc