The existing code assumed that the first frame received by the decklink
output would always be PTS zero.  However if running in other timing
modes than the default of CBR, items such as frame dropping at the
beginning may result in starting at a non-zero PTS.

For example, in our setup because we discard probing data and run
with "-vsync 2" the first video frame scheduled to the decklink
output will have a PTS around 170.  Scheduling frames too far into
the future will either fail or cause a backlog of frames scheduled
far enough into the future that the entire pipeline will stall.

Issue can be reproduced with the following command-line:

./ffmpeg -copyts -i foo.ts -f decklink -vcodec v210 -ac 2  'DeckLink Duo (4)'

Keep track of the PTS of the first frame received, so that when
we enable start playback we can provide that value to the decklink
driver.

Thanks to Marton Balint for review and suggestion to use
AV_NOPTS_VALUE rather than zero for the initial value.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>