No idea where the DecklinkAPIDispatch.cpp comes from on Windows,
but this should still work. Will just become a problem once we
use other parts of the API.
When dealing with random-access content (such as files), we initially
search for the last PCR in order to figure out duration and to handle
other position estimation such as those used in seeking.
Previously, the code looking for that last PCR would search in the last
640kB of the file going forward, and stop at the first PCR encountered.
The problem with that was two-fold:
* It wouldn't really be the last PCR (it would be the first one within
those last 640kB. In case of VBR files, this would put off duration
and seek code slightly.
* It would fail on files with bitrates higher than 52Mbit/s (not common)
Instead this patch modifies that code by:
* Scanning over the last 2048kB (allows to cope with streams up to 160Mbit/s)
* Starts by the end of the file, going over chunks of 300 MPEG-TS packets
* Doesn't stop at the first PCR detected in a chunk, but instead records all
of them, and only stop searching if there was "at least" one PCR within
that chunk
This should improve duration reporting and seeking operations on VBR files
https://bugzilla.gnome.org/show_bug.cgi?id=708532
Using NSApp directly seems to confuse something, as the compiler
was expecting an id<NSFileManagerDelegate>. Switched to using
[NSApplication sharedApplication], and specified the delegate
protocol on the window class as well.
Similar to https://bugzilla.gnome.org/show_bug.cgi?id=738740
Check if the stream is live before checking if it is EOS as a live
stream might be considered EOS when it just needs to wait for a manifest
update to proceed with the next fragments
During flushing seeks the flushing flow return will propagate up to the
source element and all pads are going to have the flushing flag set.
So before restarting also remove that flag together with the EOS one.
We don't do that when pushing the flush stop event because our event
handler for the proxypad will drop all events.
Otherwise we're going to starve other elements if the decklink clock
is slower than the pipeline clock, or starts much later.
Of course this will still cause problems if the decklink clock and ours are
completely out of sync, or running at a very different rate. But this at least
works better now.
If we just count the frames and calculate timestamps from that, all frames
will arrive late in the sink as we have a live source here. Instead take
the pipeline clock at capture time as reference.
We have to handle the callback object a bit different:
a) it needs a virtual destructor
b) we need to set the callback to NULL when we're done with the output
c) create a new one every time
https://bugzilla.gnome.org/show_bug.cgi?id=740616
