I hadn't when he asked, but have since noticed it on last Thursday
night's _This Week_ downloaded on Friday. I adjusted the syncing
between the audio and video streams within the file to fix with
something like
ffmpeg -itsoffset 0.4 -i foo.mp4 -i foo.mp4 \
-map 0:1 -map 1:0 -c copy new-foo.mp4
IOW, have ffmpeg read the same file twice, taking the audio from one,
and the video from another, copying them into a new file, so no
transcoding, but with an "input time offset" applied to one of them of
0.4 s. The corrective delay is found through experimentation and adding
a `-to 00:00:30' after the `-c copy' helps that by quickly producing
just a 30 s snippet of programme to check.
No, I don't know how to get the get_iplayer GUI to do this. :-)
The 'old' recording of HIGNFY has the sound starting somewhere in the
middle of the continuity announcement before the programme itself starts.
The video starts with the programme titles. The 'new' recording, with no
offset, starts with the programme titles - i.e. the video is the same
for both recordings, it is the audio that is different.
Is there perhaps some automated up-loading that takes place by the beeb,
on a timed basis, which is eventually edited by someone to correct to
the start of the programme?
If that is the case, it may be possible to compare audio & video length
after downloading? My concern is that this appears to be something that
can happen at random times, and give random offsets - and means either
not using hq audio, or having to check each download.
_______________________________________________
get_iplayer mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/get_iplayer
