Audio and video gradually go out of sync

[Vangelis forthnet]

On Tue Apr 19 23:00:46 BST 2016, Nick Payne wrote:

> but the audio and video on the Day 3 program
> gradually get out of sync as the program progresses -
> they're in sync at the start, but by the end
> of the 50 minutes of the program, the audio is
> about half a dozen seconds in advance of the video.
> (snip)
> At the moment, I don't know whether this is a problem
> with the GiP processing at my end
> or with the download from the BBC.
> Using GiP 2.94 on Windows.

Hi Nick,
am afraid more info is needed...
On what tvmode downloaded have you experienced
the gradual loss of AV sync?
Was it a flash mode (flashhd, flashvhigh etc.)
or a hls one (hlshd, hlsvhigh etc.)?

For flash modes, the actual downloading is
done by rtmpdump; maybe it timed out and
resumed (possibly more than once), resulting
in an FLV file with corrupt timestamps;
while at the remuxing stage that follows
ffmpeg tries its best, it may have been unable
to completely fix the wrong timestamps, resulting
in an MP4 file with issues such as the one you describe.

If it was a hls tvmode you recorded, then again
at the downloading process ffmpeg might've timed-out
on some fragments (harder to spot those errors while
ffmpeg continuously writes output in the command
prompt window), this again would have resulted in
a .ts file with corrupt timestamps not fully fixed in
the remuxing process to the final MP4 file...

Both flash and hls tvmodes require a robust connection
during download for best results...

FWIW, I did some tests:
1. On the iPlayer site itself,

http://www.bbc.co.uk/iplayer/episode/b078dl2z/snooker-world-championship-highlights-2016-day-3

the programme plays fine all through its end.
Of course, in Firefox with Adobe Flash the
AdobeHDS streams are being delivered
(from right-clicking on Flash):

b078dl1m / programme / b078dl2z
1700kbps | HDS (mf_akamai_uk_hds) | b078dl1m | 960x540

those are not supported in GiP, but it's a good indication
regardless, as all encodes come from same original source
(exceptions may apply, but it's rare...).
I moved the slider to 46:32/48:25, and audio
was still in sync with video.

2. Flashvhigh tvmode was downloaded (via rtmpdump).
No interruption was observed during download,
end MP4 file was played back using MPC-BE;
again, AV sync was maintained right from the start
all through to the duration's end.

So it must be something at your end...
Delete problematic file and redownload manually,
at a time of day when your internet speed
is the best - verify in the CLI that rtmpdump
does not stop; if the default CDN is causing you grief,
try the alternate one (sadly, there's only one CDN
now for flashhd, but two still exist for the other flashtvmodes...).

You can also try hls tvmodes, e.g. --tvmode=hlshd.
(or hlsvhigh) to get rtmpdump out of the equasion.
It's a long shot, but perhaps you could also update
your FFmpeg binary - GiP 2.94 came with FFmpeg 2.2.3,
we're now up to version 3.0.1; maybe significant
improvements were introduced in both AppleHLS
downloading and MP4 container remuxing...

Kind regards,
Vangelis.