Audio and video gradually go out of sync
northmedia1 at the.forthnet.gr
Wed Apr 20 08:33:13 PDT 2016
On Wed Apr 20 08:34:34 BST 2016, Nick Payne wrote:
> I used --modes=hlsbest for the download.
> This is the same option as for the other downloads
> which didn't suffer this loss of sync.
In GiP 2.94, that would've fetched hlshd1 (720p, 25FPS, ca. 2400kbps).
FFmpeg is used for the download (and lossless remux to MP4 container).
get_iplayer --pid=b078dl2z --modes=hlshd1 --force --overwrite
and that got me an 807 MiB (48:25) tagged MP4 file - FFmpeg.exe v3.0 (32bit)
was used; File was tried in MPC-BE 1.4.6, MPC-HC 1.7.10, VLC 2.2.2 and
in all players, AV was in sync up to the last second of duration.
So can't reproduce, it is definitely something at your end.
Please do as advised in my previous e-mail:
>> Delete problematic file and redownload manually,
>> at a time of day when your internet speed is the best
For flashhd type:
get_iplayer --pid=b078dl2z --modes=flashhd --force --overwrite
>> verify in the CLI that rtmpdump does not stop;
>> 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...
To update FFmpeg, read towards the end of my recent list post:
> I didn't notice any errors indicated in the console window.
It was an hls tvmode you fetched, so my initial remark applies:
>> (harder to spot those errors while
>> ffmpeg continuously writes output in the command
>> prompt window)
> Does GiP create a log file? I couldn't find one.
Not by default; you'd have to add --verbose (--debug) in
the CLI command and then redirect output to file; for flashhd:
get_iplayer --pid=b078dl2z --modes=flashhd --force --overwrite -v >
I personally do not have any other advice to suggest,
as it doesn't appear (at least to me) that GiP is at fault here...
More information about the get_iplayer