[FFmpeg-soc] [soc]: r532 - matroska/matroskaenc.c
Michael Niedermayer
michaelni at gmx.at
Sat Jul 28 11:22:22 CEST 2007
Hi
On Sat, Jul 28, 2007 at 02:47:11AM -0400, David Conrad wrote:
>
> On Jul 25, 2007, at 8:48 PM, Michael Niedermayer wrote:
>
> > Hi
> >
> > On Thu, Jul 26, 2007 at 02:05:33AM +0200, conrad wrote:
> >> Author: conrad
> >> Date: Thu Jul 26 02:05:32 2007
> >> New Revision: 532
> >>
> >> Log:
> >> Write segment UID
> > [...]
> >> @@ -507,6 +510,9 @@ static int mkv_write_header(AVFormatCont
> >> MatroskaMuxContext *mkv = s->priv_data;
> >> ByteIOContext *pb = &s->pb;
> >> offset_t ebml_header, segment_info;
> >> + int i;
> >> +
> >> + av_init_random(av_gettime(), &mkv->rand_state);
> >
> > leaks current time (=security risk ...)
>
> What would be best way to seed the random number generator? All the
> other uses of av_init_random() use a constant, but the purpose of the
> segment UID is to be unique among segments, so that other files can
> refer to it.
well, if so using the current time is not a good idea either, if 2
people start encoding at the same time ...
> Another idea might be to use a SHA-1 hash of the frame
> contents, but that seems like it would slow down muxing a fair bit.
i dont know a solution, finding a good and secure random number is hard
you could use the sha1/crc of just the first frame, but that might be a
all black frame and thus has a fair chance of being identical between
2 movies (if used quantizer and other encoding options match)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/758438f5/attachment.pgp>
More information about the FFmpeg-soc
mailing list