Opened 11 years ago

Last modified 11 years ago

#2375 reopened defect

FFprobe outputs nonsense DTS/PTS for streams with reordered frames

Reported by: dbuitenh Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: pts dts mpeg2video
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:

FFprobe outputs PTS/DTS that make no sense on streams with reordered frames, like MPEG-2. You'll notice PTS==DTS, which is IMPOSSIBLE when coded order is not the same as display order. This makes providing PTS and DTS separately entirely useless.

How to reproduce:

% ffprobe -of json -show_frames input.ts > out.json

Attached example output.

Example input here: http://chromashift.org/kyoani_cm_mechagirl.ts

Attachments (1)

out.json.xz (48.8 KB ) - added by dbuitenh 11 years ago.
Full output of ffprobe.

Download all attachments as: .zip

Change History (14)

by dbuitenh, 11 years ago

Attachment: out.json.xz added

Full output of ffprobe.

comment:1 by Carl Eugen Hoyos, 11 years ago

Is this not reproducible with ffmpeg?

comment:2 by dbuitenh, 11 years ago

This bug is about ffprobe's ordered output, not ffmpeg.

comment:3 by Michael Niedermayer, 11 years ago

The 2 timestamps from AVFrame that get printed by ffprobe represent the presentation and decoding time based presentation time of the AVFrame.
That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.
the pkt_dts does not represent the decoding time of the AVPacket that contained the AVFrame.

in reply to:  3 ; comment:4 by dbuitenh, 11 years ago

Replying to michael:

The 2 timestamps from AVFrame that get printed by ffprobe represent the presentation and decoding time based presentation time of the AVFrame.

Calling it "decoding time (dts)", then, is misleading at best, and a straight up lie at worst.

That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.

You should not be using DTS at all for displaying in the first place. That's what PTS is for.

the pkt_dts does not represent the decoding time of the AVPacket that contained the AVFrame.

This is utterly dumb and wildly violates http://en.wikipedia.org/wiki/Principle_of_least_astonishment . The "dts" output isnt even a true dts!

in reply to:  4 ; comment:5 by Michael Niedermayer, 11 years ago

Replying to dbuitenh:

Replying to michael:

That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.

You should not be using DTS at all for displaying in the first place. That's what PTS is for.

"all pts or all dts from the AVPacket input are corrupted", the pts are corrupted (or could be plain unavailable or all 0), its DTS or nothing in such cases

in reply to:  5 ; comment:6 by dbuitenh, 11 years ago

Replying to michael:

Replying to dbuitenh:

Replying to michael:

That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.

You should not be using DTS at all for displaying in the first place. That's what PTS is for.

"all pts or all dts from the AVPacket input are corrupted", the pts are corrupted (or could be plain unavailable or all 0), its DTS or nothing in such cases

That hardy justifies this massive hack, where you completely screw every other non-broken file's DTS into what is not actually a DTS in the first place. That is straight up lying on most files. If they're all corrupt, then fill in the PTS and DTS conditionally. Don't lie about what the DTS is on every other legitimate file. That's ass-backwards behavior.

in reply to:  6 ; comment:7 by dbuitenh, 11 years ago

Replying to dbuitenh:

Replying to michael:

Replying to dbuitenh:

Replying to michael:

That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.

You should not be using DTS at all for displaying in the first place. That's what PTS is for.

"all pts or all dts from the AVPacket input are corrupted", the pts are corrupted (or could be plain unavailable or all 0), its DTS or nothing in such cases

That hardy justifies this massive hack, where you completely screw every other non-broken file's DTS into what is not actually a DTS in the first place. That is straight up lying on most files. If they're all corrupt, then fill in the PTS and DTS conditionally. Don't lie about what the DTS is on every other legitimate file. That's ass-backwards behavior.

I should ALSO note: http://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52951f35ec9e303d3dfeb4b3e44248a

"DTS copied from the AVPacket that triggered returning this frame"

So that's a straight up lie. Also it's named pkt_dts the pkt is FOR PACKET.

Last edited 11 years ago by dbuitenh (previous) (diff)

in reply to:  7 ; comment:8 by Michael Niedermayer, 11 years ago

Replying to dbuitenh:

Replying to dbuitenh:

Replying to michael:

Replying to dbuitenh:

Replying to michael:

That is if either all pts or all dts from the AVPacket input are corrupted then the other value on the AVFrames will be unaffected and can be used for correctly timed display.

You should not be using DTS at all for displaying in the first place. That's what PTS is for.

"all pts or all dts from the AVPacket input are corrupted", the pts are corrupted (or could be plain unavailable or all 0), its DTS or nothing in such cases

That hardy justifies this massive hack, where you completely screw every other non-broken file's DTS into what is not actually a DTS in the first place. That is straight up lying on most files. If they're all corrupt, then fill in the PTS and DTS conditionally. Don't lie about what the DTS is on every other legitimate file. That's ass-backwards behavior.

I should ALSO note: http://ffmpeg.org/doxygen/trunk/structAVFrame.html#aa52951f35ec9e303d3dfeb4b3e44248a

"DTS copied from the AVPacket that triggered returning this frame"

So that's a straight up lie. Also it's named pkt_dts the pkt is FOR PACKET.

Lets take an example:

Packet  PTS      1 4 2 3 7 5 6
Packet  DTS      0 1 2 3 4 5 6
Packet Type      I P B B P B B
                 Decoder here
Frame  Type        I B B P B B
AVFrame pkt_dts:   1 2 3 4 5 6 

You can see that the AVFrame.pkt_dts is the AVPacket dts of the packet that triggered the frame to be returned (in a standard reference decoder)

in reply to:  8 comment:9 by dbuitenh, 11 years ago

Replying to michael:

"DTS copied from the AVPacket that triggered returning this frame"

So that's a straight up lie. Also it's named pkt_dts the pkt is FOR PACKET.

Lets take an example:

Packet  PTS      1 4 2 3 7 5 6
Packet  DTS      0 1 2 3 4 5 6
Packet Type      I P B B P B B
                 Decoder here
Frame  Type        I B B P B B
AVFrame pkt_dts:   1 2 3 4 5 6 

You can see that the AVFrame.pkt_dts is the AVPacket dts of the packet that triggered the frame to be returned (in a standard reference decoder)

This does a splendid job of showing exactly why the current behavior is wrong, confusing, and in stark contrast of what DTS actually is.

It's clear there's no intention of changing it to anything sane, so I'll simply keep this link handy for every time someone runs into this hacky mess, which in my experience, is fairly often.

Good day.

comment:10 by dbuitenh, 11 years ago

Resolution: wontfix
Status: newclosed

comment:11 by Michael Niedermayer, 11 years ago

Resolution: wontfix
Status: closedreopened

Please dont randomly close tickets

comment:12 by Carl Eugen Hoyos, 11 years ago

Keywords: mpeg2video added; ffprobe timestamps mpeg2 removed

comment:13 by Carl Eugen Hoyos, 11 years ago

Component: FFprobeundetermined
Note: See TracTickets for help on using tickets.