[FFmpeg-devel] [PATCH] Ogg Theora granules confused by spec

[Henrik Gulbrandsen]

On Fri, 2008-04-18 at 09:55 +0200, Diego Biurrun wrote:
> On Fri, Apr 18, 2008 at 12:37:45AM -0700, Baptiste Coudurier wrote:
> > 
> > Henrik Gulbrandsen wrote:
> > > The last paragraph in section A.2.3 ("Granule position") of Appendix A
> > > in the current Theora specification states the following:
> > > 
> > > -------------------------------------------------------------------------------
> > > Prior to bitstream version 3.2.1, data packets were marked by a granulepos
> > > derived from the index of the frame being decoded, rather than the count. That
> > > is they marked the beginning of the display interval of a frame rather than the
> > > end. Such streams have the VREV field of the identification header set to `0'
> > > instead of `1'. They can be interpreted according to the description above by
> > > adding 1 to the more signification field of the split granulepos when VREV is
> > > less than 1.
> > > -------------------------------------------------------------------------------
> > > 
> > > I must admit that this is badly worded and confused me when I read it
> > > the first time, but I still think the current FFmpeg implementation in
> > > libavformat/oggenc.c interprets the spec a bit too literally. 
> > 
> > In specs, there should be no place for interpretation IMHO.
> > 
> > > I doubt the intention of its author was to turn the third part of the version
> > > field (the version revision) into a generic flag field for the future.
> > 
> > IMHO specs writers must really take care and think before writing such 
> > statements.
> 
> There is a better solution IMO: Get in contact with the spec writers and
> ask them to clarify the spec.
> 
> Diego

Good idea!

I've sent an email, so we'll see what the next spec version says.

On Fri, 2008-04-18 at 00:37 -0700, Baptiste Coudurier wrote:
> We will see when 3.3.0 comes, specs will change, and code will be 
> updated, or version will bump at 3.3.1 and there will be no problem at 
> all. No need to clutter more code like it is already.

The problem with that approach is of course that there would be a period
from the release of 3.3.0 till someone notices the problem and corrects
the granule position offset. Through that period, FFmpeg would be buggy,
and my point of view is that software shouldn't have bugs...

/Henrik