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

[Michael Niedermayer]

On Wed, Jun 30, 2010 at 09:28:47PM +0200, Michael Niedermayer wrote:
> On Wed, Jun 30, 2010 at 10:50:12AM +0100, M?ns Rullg?rd wrote:
> > Kostya Shishkov <kostya.shishkov at gmail.com> writes:
> > 
> > > 2010/6/30 M?ns Rullg?rd <mans at mansr.com>:
> > >> Kostya Shishkov <kostya.shishkov at gmail.com> writes:
> > >>
> > >>> On 30 June 2010 11:13, Alexander Strange <astrange at ithinksw.com> wrote:
> > >>>>
> > >>>> On Jun 30, 2010, at 2:09 AM, Mans Rullgard wrote:
> > >>>>
> > >>>>> From: Cory Fields <theuni-nospam- at xbmc.org>
> > >>>>
> > >>>> Is there a sample for this one, or do all rmvb files have obviously
> > >>>> bad times?
> > >>>
> > >>> All of them. IIRC this patch was discussed for several times without any real
> > >>> conclusion (you know how eager Buffering Inc provides specs on RMVB). I'm
> > >>> inclined to believe that patch is OK, so unless Ronald objects, apply it.
> > >>
> > >> The patch is correct as such, but it's not the full solution. ?It only
> > >> fixes the reported framerate. ?All the video timestamps are still
> > >> messed up.
> > >
> > > Well, we can do the same way as in FFmbc - parse video frame headers
> > > for real timestamps, at least RV3/4 have it in its headers and looks
> > > like RV2 also does.
> > 
> > FWIW, ffmpeg -fflags +nofillin works wonderfully on these files...
> 
> its all a question on how one defines wonderfully, the timestamps are as
> wrong as without that.
> That is with Blade2_640_1Mbps.rm which is what i had locally laying around
> and without this patch, ill look at the case with the patch in a moment

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

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.
-------------- 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/20100630/f68de873/attachment.pgp>