[Ffmpeg-devel] Re: [PATCH] seeking in GXF

Baptiste Coudurier baptiste.coudurier
Mon Jul 31 18:40:03 CEST 2006


Hi

Reimar D?ffinger wrote:
> Hello,
> On Mon, Jul 31, 2006 at 03:05:04PM +0200, Baptiste Coudurier wrote:
>> I think st->time_base might need a check for 0. I get floating point
>> exception on sample without fps track tag.
> 
> See (and test) attached version, it now leaves the timebase at the
> default if it can't find anything better. This of course results in
> horribly incorrect timestamps.
> Thus, it now also reads the UMF packet, which must be always present in
> conforming files. If you find the use of ff_log2_tab weird, well, that's
> because each possible fps value corresponds to one bit. Which means you
> could set multiple fps values, which would horribly break timestamps...
> I decided to got the quick-and-dirty way, this is only a fallback
> anyway.
> I will apply if you don't come over any problems with your files on this
> version.

Those values are constant flags defined in the specs IIRC, a table
(frame_rate, flag) could be used.

I now have weird time base for DV: it seems mplayer plays them twice
speed. You can create DV in gxf files with ffmpeg muxer if you want to
test.

IMHO best way to compute time base if FPS track tag does not exist is to
check UMF media description sample rate field.

>> Btw, I think there is also a problem with last audio packet, which might
>> not contain 32768 samples in uncompressed: last field in MEDIA_PKT will
>> be less and that must be taken into account while reading. Atm I can
>> hear glitches on last packet, I'll look at it
> 
> I think this is already marked in line 482 of the current code, the
> "NOTE:...". But if you can _hear_ glitches this means that the last packet
> has been filled up with some (almost) random crap, right? If the ffmpeg
> muxer creates such files, it might be a good idea to "fix" there as well.
> 

Well, if by fixing you mean memset to 0. I sure can do that. But it is
not required by the specs.

I have samples which I did not created with that problem. Specs
explicitly says that last field must be taken into account, especially
for audio packets since packets shall be exactly 32768 samples in size.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
SMARTJOG S.A.                                    http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
Phone: +33 1 49966312




More information about the ffmpeg-devel mailing list