FFprobe outputs nonsense DTS/PTS for streams with reordered frames

[dbuitenh]

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

[dbuitenh]

Full output of ffprobe.

[Carl Eugen Hoyos]

Is this not reproducible with ffmpeg?

[dbuitenh]

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

[Michael Niedermayer]

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.

[dbuitenh]

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!

[Michael Niedermayer]

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

[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.

[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#aa52951f35ec9e303d3dfeb4b3e44248a77

"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.

[Michael Niedermayer]

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)

[dbuitenh]

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.

[Michael Niedermayer]

Please dont randomly close tickets