Audio/Video Out of Sync

Vangelis forthnet northmedia1 at the.forthnet.gr
Thu Aug 18 07:38:47 PDT 2016


On Thu Aug 18 11:39:35 BST 2016, RS wrote:

> hlshd1 is now present but there are errors at
> 4, 9, 10, 15, 16, 17, 33, 34, 36, 43 ...

... Just out of curiosity (and since I'm not a cat),
I just tried:

perl get_iplayer-295.pl --pid=b07p4swg --tvmode=hlshd1 --raw

My download had eight (8) missing segments
(for a ca. 25min programme), precisely the following:

10, 15, 16, 43, 93, 152, 153, 155.

So not exactly the same as yours (???)

I then used ffmpeg (v3.0) to demux (extract)
elementary streams from the MPEG-TS container.

Elementary Video Stream (EVS):

ffmpeg -loglevel 8 -stats -i Video.ts -an -c:v copy -f h264 EVS.264

ffmpeg reported the duration of the video stream to be 25min21sec:

frame=37032 fps=1013 q=-1.0 Lsize=  409012kB time=00:25:21.24 
bitrate=2202.6kbits/s

Elementary Audio Stream (EAS):

ffmpeg -loglevel 8 -stats -i Video.ts -vn -c:a copy -f adts EAS.aac

ffmpeg reported the duration of the audio stream to be 24min41sec:

size=   17374kB time=00:24:41.28 bitrate=  96.1kbits/s

while the duration of the downloaded "RAW" Video.ts file
is reported by MediaInfo (and MPC-HC) to be 00:26:01.

So, as reported elsewhere, it is those inconsistencies between
reported durations of the initial container (I am not sure but
maybe the container duration is set by server data?) and the actual
durations of the truncated (due to missing fragments) elementary
streams that is causing the loss of video/audio sync in the
"one step" remux (change of container format from TS => MP4)
that is occuring in GiP by default...

If I then remux (repackage) the elementary streams to
the MP4 container:

ffmpeg -loglevel 8 -stats -i EVS.264 -i EAS.aac -c copy -bsf:a aac_adtstoasc 
ff-remux.mp4

the end .mp4 file has no loss of sync,
MediaInfo and MPC-HC report the file's
duration to be 00:24:41 (the same as EAS.aac).

Hope the above is useful to someone...

Vangelis. 




More information about the get_iplayer mailing list