[FFmpeg-devel] [PATCH] flv set pts

Michael Niedermayer michaelni
Fri Nov 14 18:36:58 CET 2008


On Thu, Nov 13, 2008 at 07:51:05PM -0800, Baptiste Coudurier wrote:
> Michael Niedermayer wrote:
> > On Tue, Sep 30, 2008 at 01:02:53PM -0700, Baptiste Coudurier wrote:
> >> Michael Niedermayer wrote:
> >>> On Tue, Sep 30, 2008 at 12:00:59PM -0700, Baptiste Coudurier wrote:
> >>>> Michael Niedermayer wrote:
> >>>>> On Tue, Sep 30, 2008 at 11:28:45AM -0700, Baptiste Coudurier wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Michael Niedermayer wrote:
> >>>>>>> On Mon, Sep 29, 2008 at 07:56:17PM -0700, Baptiste Coudurier wrote:
> >>>>>>>> Baptiste Coudurier wrote:
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> $subject.
> >>>>>>>>>
> >>>>>>>> Scratch old patch, this one should be correct.
> >>>>>>> can you post some example input&output pts & dts values for some file
> >>>>>>> with b frames.
> >>>>>>> I suspicion would be that the patch is not completely correct but this
> >>>>>>> should be more obvious from a list of timestamps and frame types.
> >>>>>>>
> >>>>>> Well, I didn't find any having < 0 cts yet, however it has been said
> >>>>>> that cts is signed like in .mov, so code is assuming that.
> >>>>>>
> >>>>>> Files generated by FFmpeg does not have < 0 cts.
> >>>>>>
> >>>>>> Patch is doing the same as the .mov demuxer excepts that we cannot know
> >>>>>> in advance while we can in .mov, though it misses has_b_frames = 1, I
> >>>>>> can see, not harmful though.
> >>>>>>
> >>>>>> What do you think could be wrong ? I'll try to find a file in the mean time.
> >>>>> Well
> >>>>> if we take as example normal mpeg2 style IPB then
> >>>>>         IPBBPBB
> >>>>> dts:    0123456
> >>>>> pts:    1423756
> >>>>> would be correct
> >>>>>
> >>>>> now if dts where increased by one:
> >>>>>
> >>>>>         IPBBPBB
> >>>>> dts:    1234567
> >>>>> pts:    1423756
> >>>>>
> >>>>> then this would be wrong, and not only the ones for the B frames
> >>>>> would be wrong but all would be. That is for example if the I frame
> >>>>> is feeded at time 1 into the decoder then it will be output at time 2 not 1.
> >>>>>
> >>>> Humm of course yes, and in your situation, cts will be -1 for the third
> >>>> frame to achieve dts 3 and pts 2, I don't see what you mean, the check
> >>>> is indeed for cts < 0.
> >>> well, i think the demuxer would output:
> >>>
> >>> dts:    12-----
> >>> pts:    1423756
> >>>
> >>> but this is wrong for the first 2 frames
> >>>
> >> Yes, that is true, what can we do about that ?
> >> It's sad not to set pts for correct files, what do you suggest ?
> > 
> > iam fine with the patch if it also prints some warning that the past
> > timestamps might have been wrong
> 
> Patch updated.

ok if it passes regressions and has been tested with a h264 flv or 2
[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- 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/20081114/5b4037df/attachment.pgp>



More information about the ffmpeg-devel mailing list