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

[Kostya Shishkov]

On 1 July 2010 12:25, Michael Niedermayer <michaelni at gmx.at> wrote:
> On Thu, Jul 01, 2010 at 09:11:00AM +0200, Kostya Shishkov wrote:
>> 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?
>
> if its easy and works, yes.
> if not, we at least should avoid setting nonsense pts for b frames

for RV3 it's "skip 12 bits, read 13 bits of timestamp"
for RV4 it's "skip 13 bits, read 13 bits of timestamp"
for RV2 - you should know
for RV1 - looks like we're out of luck

And at least for RV 3/4 those timestamps look correct.

> [...]
> --
> Michael ? ? GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB