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

[Michael Niedermayer]

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

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100701/da5324f6/attachment.pgp>