Make best effort to get a PTS

[mikeboers]

Should we put in the effort to capture PTSes earlier in the decoding process so that we are more likely to have them at all?

See the dranger.com tutorial.

[markreidvfx]

In summary "The pts of a frame is the pts of the first packet needed to decode it."
Way back when we started and I was messing around with seeking, I remember already implementing decoding in a similar fashion to that tutorial.
Before passing the frame and packet to decode, I stored the packet pts and dts (in a struct) in AVCodecContext.opaque and set AVFrame.opaque to it when AVCodecContext.get_buffer is called. Then recover it from the frames as you get them. I had to reimplement AVCodecContext.get_buffer and AVCodecContext.release_buffer. I abandon it because av_frame_get_best_effort_timestamp just seems to work. get_buffer and release_buffer are now depreciated I'm not sure what to do.

[markreidvfx]

oh, we can just us get_buffer2 instead. :p

[markreidvfx]

The tutorial stores the pts in a global variable, I stored the packet pts and dts in AVCodecContext.opaque instead.

[mikeboers]

I just wish we had some definitive proof that this wouldn't blow up in our face, you know?

[markreidvfx]

I notice you pulled in from stuff from my dranger branch, I'm still not sure if going that way is correct. I've only briefly tested it using that frame_seek_example.py example on various footage with timecode burnt in and it occasionally wasn't correct, but we're as guess_correct was. (could be just my example code) but anyways Its really easy to revert back to best_guess if its a problem.

[mikeboers]

I just wanted to merge the huge tangle of branches that was developing. It was, perhaps, a little hasty, but I wanted to do it before it got crazy out of hand (by having them all diverge so much from each other that there would be lots of resistance to merge them).

It will be very easy to revert back, so I'll leave it for the time being (because I do want to go in that direction, and the machinery you put in place is nice to have anyways).

[mikeboers]

I think the thing to do is not revert it, but to put it in there as yet another way to get a pts. Then you have all of the control to pick the raw pts of your choice, and the one floating point time that we think is likely to be the one.

[mikeboers]

I think I've sorted this out. My conclusion is that Dranger's tutorial is dangerously out of date.

AVFrame.pkt_pts is copied from the packet for us automatically, and seems to be exactly what we need. D'oh!

[mikeboers]

Yup. I'm going to go with that. Simple and clean. =]