[FFmpeg-devel] libschroedinger FFmpeg bug

[Anuradha Suraparaju]

On Fri, 2008-05-16 at 12:06 +0200, Michael Niedermayer wrote:
> On Fri, May 16, 2008 at 04:16:34PM +1000, Anuradha Suraparaju wrote:
> > Hi
> > 
> > On Fri, 2008-05-16 at 00:58 +0200, Diego Biurrun wrote:
> > > Hello Anuradha,
> > > 
> > > maybe you can have a look at the following bug:
> > > 
> > > http://roundup.mplayerhq.hu/roundup/ffmpeg/issue453
> > > 
> > > Somebody is having trouble encoding with libschroedinger.
> > 
> > I looked into this and there are two problems:
> > 
> > 1. There is no fourcc code for CODEC_ID_DIRAC in riff.c. So even if we a
> > successfully wrap libschroedinger in AVI, we won't be able to play it
> > back.
> > 
> > 2. The second problem is to do with presentation time stamps. For frame
> > data, libschroedinger uses the frame number is display order as the pts
> > (it assumes a fixed frame rate input). However, libschroedinger also
> > returns some  non-frame data - e.g Sequence headers, padding data,
> > auxiliary data as separate packets. These data do not have a pts
> > associated with them hence the 'non monotone timestamps' error.
> > 
> > I looked at the code for MPEG4 encoding and it appears that, correct me
> > if I am wrong,  the GOP header (the sequence header in Dirac is similar
> > to this) in prepended to the encoder picture data and not as a separate
> > packet. Is this the way to solve the pts problem? i.e. prepend all
> > non-picture data to an encoded picture.
> 
> There are 2 things
> 1. global headers which can be stored in extradata/extradata_size
> 2. frames
> 
> 1. must not change ever and applies to the whole video
> 2. each frame must have a unique pts and unique and montone dts
>    The demuxer will try its best to handle missing dts/pts but there
>    is no such concept as a frame with no dts/pts on the muxer side.
> 
> This is not avi specific but also applies to .mp4 .mov and many other
> containers. Besides it conceptually makes sense to require sane dts/pts.
> 
> Prepending whatever headers apply to the current frame but not to the
> whole video would seem like the best solution, yes ...

Can a pts be associated with non-frame data i.e. sequence headers,
auxiliary data, end of sequence data as long as it monotonous? This is
because Dirac and Schro can generate different types of "extra data". So
can they be treated as frames with no actual picture data but with
header information?

> 
> [...]
> 

Regards,
Anuradha