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

[Zuxy Meng]

2010/7/1 Kostya Shishkov <kostya.shishkov at gmail.com>:
> 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.

Any update for this nasty problem?

-- 
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6