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

Kostya Shishkov kostya.shishkov
Thu Jul 1 09:11:00 CEST 2010


On 1 July 2010 08:39, Vladimir Pantelic <pan at nt.tu-darmstadt.de> wrote:
> 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

Those values are not _packet_ information (32-bit timestamp there),
they are extracted from frame header (and, obviously, only 13 bits long).
As I've mentioned in my previous mail to this thread, FFmbc extracts
them from codec data and uses for PTS, should we do the same?



More information about the ffmpeg-devel mailing list