Minimises number of frames sent to decoder by keeping track of which …

[Multihuntr]

…frames are actually needed, and halting once all frames required have been sent.

I won't be offended if this is rejected: just thought I'd present it as a possible modification. I think this should be fine in any case I can think of (and it works for my videos), but maybe there's something I don't know?

[jaredcasper]

I'm going to have to do some more testing/research on this one. My current concern is in the case where one of the frames that I want to get references a frame in the future... say my gop is 1, 2, 3, 4, 5 and I just want 1, 2, 3 but frame 2/3 could use information from frame 5 instead of just 1. Most encoders would put it in as 1, 5, 2, 3, 4, but I believe that isn't required and the in-order version is a valid gop and would not work with the changed code. I'll leave this open as I could be wrong though. :)

Sorry again for the delay in getting to all of your PRs, they are very much appreciated, it's just been a crazy summer for me.

[Multihuntr]

Haha, no problems, I was a little worried that they wouldn't be looked at. I don't know if you disappear forever, you see.

I don't think your test case would fail. Here's how the logic works in my head:

Desired frames: [1, 2, 3], got_frame: [0, 0, 0]
Send: 1, got_frame: [1, 0, 0]
Send: 5, got_frame: [1, 0, 0]
Send: 2, got_frame: [1, 1, 0]
Send: 3, got_frame: [1, 1, 1]
Halt. (Didn't send 4)

If you could be certain that it never back-tracked, a simple counter would suffice (decrement each time a frame is sent).

(I considered bit-hacking, but if you requested a sequence longer than 32 frames it would fail)

[jaredcasper]

Right, it would work in that case, but what if 2/3 use info from 5, but frame 5 comes after them in the bitstream? I think frame 5 will usually come before 2/3 if it is needed, but it doesn't have to and won't always.

[Multihuntr]

I might have misunderstood what this function does, then. Doesn't this send frames to the decoder in decode order? It's not in presentation order, so is there another kind of ordering going on here?

Or maybe I'm misunderstanding how decode order works? I assumed it meant that the order in which you get packets is the order in which you can get complete, full frames out.

[jaredcasper]

The function sends frames to the decoder in the order that they are contained in the file. I was under the assumption that file order doesn't necessarily need to be an order such that all frames referenced have already been presented, but now I'm thinking you may be right, that they are always going to be in the right order. I haven't been able to find many definitive answers out there and the actual standard is pretty dense. My time to work on this right now is a bit limited but I'll keep looking into this...

[Multihuntr]

Yeah, I've had to try to figure all this about video encoding out for this as well. All I've can definitively say about video encoding/decoding is that it's much messier and less standardised than I thought it was. Even in the H264, there's so much variation and code that doesn't work. Like how the .mp4 seek function in Libav/ffmpeg/whatever_library_it_is ignores the BACKWARD flag and just seeks to the nearest keyframe, but the .mkv one doesn't. That's a bug, but I don't even know where I can report it because it's such a mess of libraries and versions.

Also, it's things like http://www.bretl.com/mpeghtml/reorder.HTM that imply to me that the decoding order is the same as the bitstream order.