[FFmpeg-cvslog] r23302 - trunk/libavformat/oggenc.c

Reimar Döffinger Reimar.Doeffinger
Tue May 25 21:07:02 CEST 2010


On Mon, May 24, 2010 at 11:32:37PM -0700, Baptiste Coudurier wrote:
> On 5/24/10 11:10 PM, Reimar D?ffinger wrote:
> >On Mon, May 24, 2010 at 05:35:39PM -0700, Baptiste Coudurier wrote:
> >>>>    "Whole pages are taken in order
> >>>>    from multiple logical bitstreams multiplexed at the page level.  The
> >>>>    logical bitstreams are identified by a unique serial number in the
> >>>>    header of each page of the physical bitstream.  This unique serial
> >>>>    number is created randomly and does not have any connection to the
> >>>>    content or encoder of the logical bitstream it represents."
> >>>
> >>>0, 1, 2, 3 is a perfectly valid random sequence.  If the intent is to
> >>>disallow consecutive numbers, the spec should say so.  As is, this
> >>>code is nothing but obfuscation and abuse.  If you insist, use a
> >>>proper PRNG, but stop torturing av_get_random_seed.  This may be your
> >>>code, but not even you may misuse other functions.
> >>>
> >>
> >>Well, I've created av_get_random_seed after michael's request.
> >>Michael suggested me to use get_random_seed to create the UMID for
> >>MXF and said it _was_ enough. I don't see why it wouldn't for OGG.
> >
> >AFAIK the UMID is supposed to be unique "globally" if possible, and
> >there are somewhat good arguments for it, but adding this amount of
> >code that has several potential issues without any justification seems
> >silly to me.
> 
> Huh? without any justification ? Read the whole thread before speaking.

The specification, if you refer to that, gives no reason.
And "created randomly" is not something that can be implemented sensibly,
because it is too unspecific.
It does not say if it really needs to be random (e.g. you better measure
some quantum effects, what the Linux kernel does may just barely be enough)
or even the most stupid PRNG would do.
In particular what M?ns was referring to, it is not unclear if a PRNG with
the same start sequence would be ok, or just going one step further and
numbering them through.
The next thing that is unclear is what kind of distribution the random number
generator should have.
If there is no need for it to be uniform, the "potentially infinite"
loop could be avoided (though I haven't thought of a really nice way yet).



More information about the ffmpeg-cvslog mailing list