[FFmpeg-devel] Maintainership question

[Nicolas George]

Le quintidi 25 pluvi?se, an CCXIX, M?ns Rullg?rd a ?crit?:
> There is no such thing as a "codec timestamp".

There this in lavc since a long time:

    /**\
     * presentation timestamp in time_base units (time when frame should be shown to user)\
     * If AV_NOPTS_VALUE then frame_rate = 1/time_base will be assumed.\
     * - encoding: MUST be set by user.\
     * - decoding: Set by libavcodec.\
     */\
    int64_t pts;\

Do you imply it should not be there?

> There is no mess if implemented properly.

"Mess" was not not the proper word. Things are complex. Not only because
they are implemented improperly but because it has to deal with dozens of
codecs and formats that each do things slightly differently.

A library is just the place to implement things properly. Could you bother
to tell us what you think would be a proper implementation?

> Formats like MPEG with sparse timestamps cause trouble for such heuristics.

Such as? Or: what kind of algorithm would you recommend that would work
better?

> Pick any mkv file from samples.ffmpeg.org

I picked this one, since I was sure that there would be B-frames in H.264:
http://samples.mplayerhq.hu/V-codecs/h264/hellsing-h264-blocking.mkv
I extracted the PTS with both mkvinfo and ffprobe, and they all agree.

Could you be a little more accurate please?

> There are two classes of bad timestamps: wrong and impossible.  Wrong
> timestamps simply cause bad A/V sync or similar, while impossible could
> be for example non-increasing or otherwise inconsistent.  The former
> cannot be detected automatically.

Of course.

>				     In the latter case, the proper
> treatment depends on the reason for the timestamps being bad in the
> first place.  If random data corruption is the cause, simply discarding
> outliers tends to work well.  In other cases, a reversal of the error
> may be possible if there is a known pattern to the error.  In all cases,
> recovery of accurate timestamps is impeded by a dumb heuristic tampering
> with them first.

The heuristic is not _tampering_ with them: it puts its result in an
additional field. To use this field in the simple case or to give the user
all the knobs and controls to fix broken files is the application
developer's choice.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110214/fe5f9426/attachment.pgp>