[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