[FFmpeg-devel] [PATCH 27/28] fixed: wrong fps for rmvb files (patch by taxigps)

[Vladimir Pantelic]

Michael Niedermayer wrote:

> no luck.
> The timestamps are wrong with and without patch with and without nofillin
>
> thus it seems the timestamps must already be wrong when they leave the demuxer
>
> also, a quick way to test timestamps is ffplay
> it displays 2 numbers that represent the number of out of order dts and
> out of ordeder pts after reordering by the decoder.
> But even ignoring ffplay, the timestamps from the demuxer look very
> unevenly spaced

AFAIK that is how RM muxes B-frames, they get a timestamp of "last frame + 1",
then the decoder has to create the proper timestamps after decoding.

something like:

	decode_rv( ...., out, ... );
	if( out->frame_type == B_FRAME ) {
		// RV B-frames have no real timestamps, they need to be calculated..
		int diff = out->curTR - out->fwdTR;
		if( diff < 0 )
			diff += 8192;
				
		out->time = ref_time + diff;
	} else {
		ref_time = out->time;
	}


libavcodec/rv34.c has this:

#define GET_PTS_DIFF(a, b) ((a - b + 8192) & 0x1FFF)

/**
  * Calculate motion vector component that should be added for direct blocks.
  */
static int calc_add_mv(RV34DecContext *r, int dir, int val)
{
     int refdist = GET_PTS_DIFF(r->next_pts, r->last_pts);
     int dist = dir ? -GET_PTS_DIFF(r->next_pts, r->cur_pts) : GET_PTS_DIFF(r->cur_pts, r->last_pts);
     int mul;

     if(!refdist) return 0;
     mul = (dist << 14) / refdist;
     return (val * mul + 0x2000) >> 14;
}

so these values are there (r->next_pts, r->cur_pts), just not used for timestamps it seems