[FFmpeg-devel] Patch for "non monotone timestamp" error

Diep Ho DHo
Thu Aug 7 17:25:38 CEST 2008


> -----Original Message-----
> From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
> bounces at mplayerhq.hu] On Behalf Of Michael Niedermayer
> Sent: jeudi 7 ao?t 2008 13:07
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Patch for "non monotone timestamp" error
> 
> On Thu, Aug 07, 2008 at 12:04:54PM +0200, Diep Ho wrote:
> > > -----Original Message-----
> > > From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
> > > bounces at mplayerhq.hu] On Behalf Of Michael Niedermayer
> > > Sent: mardi 5 ao?t 2008 22:39
> > > To: FFmpeg development discussions and patches
> > > Subject: Re: [FFmpeg-devel] Patch for "non monotone timestamp"
> error
> > >
> > > On Tue, Aug 05, 2008 at 05:45:59PM +0200, Diep Ho wrote:
> > > > > -----Original Message-----
> > > > > From: ffmpeg-devel-bounces at mplayerhq.hu [mailto:ffmpeg-devel-
> > >
> > > Ive fixed the encoder so it will fail with an error message if
> > > someone tries to encode low delay mpeg1
> >
> > OK. I have to accept that, unfortunately.
> >
> > Just do me a favor to clarify this: "If in a MPEG1 file, every packet
> has PTS == DTS then this file is not a valid Mpeg1 video file?"
> 
> read the specification

>From my understanding, these files are valid. And they should be correctly read. 

I argue here that the following test in utils.c (compute_pkt_fields) is inadequate:

    if (delay &&
        pc && pc->pict_type != FF_B_TYPE)
        presentation_delayed = 1

Would it be something like the following patch? Idea is that the presentation is delayed when we end up with the pattern BP or BI. Otherwise, the presentation is not delayed. 

Index: libavcodec/parser.c
===================================================================
--- libavcodec/parser.c	(revision 14487)
+++ libavcodec/parser.c	(working copy)
@@ -73,6 +73,7 @@
     }
     s->fetch_timestamp=1;
     s->pict_type = FF_I_TYPE;
+    s->last_pict_type = FF_I_TYPE;
     return s;
 }
 
Index: libavcodec/vp3_parser.c
===================================================================
--- libavcodec/vp3_parser.c	(revision 14487)
+++ libavcodec/vp3_parser.c	(working copy)
@@ -25,6 +25,7 @@
                            const uint8_t **poutbuf, int *poutbuf_size,
                            const uint8_t *buf, int buf_size)
 {
+    s->last_pict_type = s->pict_type;
     if(avctx->codec_id == CODEC_ID_THEORA)
         s->pict_type= (buf[0]&0x40) ? FF_P_TYPE : FF_I_TYPE;
     else
Index: libavcodec/mpegvideo_parser.c
===================================================================
--- libavcodec/mpegvideo_parser.c	(revision 14487)
+++ libavcodec/mpegvideo_parser.c	(working copy)
@@ -47,6 +47,7 @@
             ff_fetch_timestamp(s, buf-buf_start-4, 1);
 
             if (bytes_left >= 2) {
+                s->last_pict_type = s->pict_type;
                 s->pict_type = (buf[1] >> 3) & 7;
             }
             break;
Index: libavcodec/mpeg4video_parser.c
===================================================================
--- libavcodec/mpeg4video_parser.c	(revision 14487)
+++ libavcodec/mpeg4video_parser.c	(working copy)
@@ -85,6 +85,7 @@
     if (s->width) {
         avcodec_set_dimensions(avctx, s->width, s->height);
     }
+    s1->last_pict_type = s->pict_type;
     s1->pict_type= s->pict_type;
     pc->first_picture = 0;
     return ret;
Index: libavcodec/avcodec.h
===================================================================
--- libavcodec/avcodec.h	(revision 14487)
+++ libavcodec/avcodec.h	(working copy)
@@ -2850,6 +2850,7 @@
     int64_t next_frame_offset; /* offset of the next frame */
     /* video info */
     int pict_type; /* XXX: Put it back in AVCodecContext. */
+    int last_pict_type; 
     int repeat_pict; /* XXX: Put it back in AVCodecContext. */
     int64_t pts;     /* pts of the current frame */
     int64_t dts;     /* dts of the current frame */
Index: libavformat/utils.c
===================================================================
--- libavformat/utils.c	(revision 14487)
+++ libavformat/utils.c	(working copy)
@@ -792,7 +792,7 @@
     /* XXX: need has_b_frame, but cannot get it if the codec is
         not initialized */
     if (delay &&
-        pc && pc->pict_type != FF_B_TYPE)
+        pc && pc->pict_type != FF_B_TYPE && pc->last_pict_type == FF_B_TYPE)
         presentation_delayed = 1;
     /* This may be redundant, but it should not hurt. */
     if(pkt->dts != AV_NOPTS_VALUE && pkt->pts != AV_NOPTS_VALUE && pkt->pts > pkt->dts)




I made a regression test. And what it gives me looks like this:

ret: 0 st: 0 dts:0.000000 pts:0.000000 pos:9216 size:9779 flags:1
 ret: 0 st:-1 ts:-1.000000 flags:0
-ret: 0 st: 0 dts:0.000000 pts:-102481911520608.625000 pos:9216 size:9779 flags:1
+ret: 0 st: 0 dts:0.000000 pts:0.000000 pos:9216 size:9779 flags:1
 ret: 0 st:-1 ts:1.894167 flags:1
-ret: 0 st: 0 dts:1.440000 pts:-102481911520608.625000 pos:135509 size:11796 flags:1
+ret: 0 st: 0 dts:1.440000 pts:1.440000 pos:135509 size:11796 flags:1
 ret: 0 st: 0 ts:0.788333 flags:0
-ret: 0 st: 0 dts:0.960000 pts:-102481911520608.625000 pos:86934 size:10792 flags:1
+ret: 0 st: 0 dts:0.960000 pts:0.960000 pos:86934 size:10792 flags:1
 ret:-1 st: 0 ts:-0.317500 flags:1
 ret:-1 st:-1 ts:2.576668 flags:0
...........

Does it mean that some wrong pts has been fixed with that patch?

dho
-------------- next part --------------
A non-text attachment was scrubbed...
Name: presentationdelay.patch
Type: application/octet-stream
Size: 2851 bytes
Desc: presentationdelay.patch
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080807/618d874e/attachment.obj>



More information about the ffmpeg-devel mailing list