[FFmpeg-devel] libschroedinger FFmpeg bug

[Michael Niedermayer]

On Mon, May 19, 2008 at 03:37:33PM +1000, Anuradha Suraparaju wrote:
> 
> 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?

no
You can prepend these sequence headers and others before keyframes.
Putting them in their own frame with their own unique pts/dts will not work.

A keyframe should be decodeable on its own with just extradata. Spliting the
sequence headers off would violate that. Also in some containers like AVI
PTS/DTS are not explicitly stored, instead each frames increases the
timestamp by 1. Having more than the real frames will not work at all there.
And in containers like MPEG-PS/TS it would be a true nightmare if the
sequence headers where considered a frame on their own. That is because
PTS/DTS are not stored for each frame and calculating the missing PTS/DTS
is hard enough with just real frames.

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080519/aca53846/attachment.pgp>