[FFmpeg-devel] libschroedinger FFmpeg bug

[Michael Niedermayer]

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 ...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20080516/eb41b6e4/attachment.pgp>