Transcoding live streams question

[Vangelis forthnet]

On Thu Jun 4 11:02:28 BST 2015, John Warburton wrote:

> I remove the default ffmpeg recoding for live streams.
> (snip)
> because picture quality suffers and the CPU is exercised more.

This is called on-the-fly recoding, and it's a CPU intensive process...
Low end devices can't cope well, see:

https://github.com/get-iplayer/get_iplayer/wiki/release291#caveats-1
[quote]
This requires more system resources than merely copying streams over the 
network.
...If your system lacks the necessary horsepower, you may find glitches or 
gaps
[/quote]

> (1) am I neglecting a command-line option to do this,

Am afraid you're not!

> (2) is there a reason for this recoding that has escaped me?

The HLS streamer class was added in GiP initially in late Nov 2014,
as a means to bring back live TV; the beeb had previously removed
the online resources GiP depended upon to generate the live TV
RTMP streams (themselves killed off some time later...).

http://git.infradead.org/get_iplayer.git/commit/9819c0337d5998906d6b6ea6b2d85f74dbb348ea
[quote]
Live TV HLS streams must be re-encoded because
pts/dts differences will kill ffmpeg.
[/quote]
Also, from the wiki link I referenced above:
[quote]
The live TV streams are re-encoded during download
due to problems with timestamp discontinuities in the video stream.
[/quote]

The "will kill ffmpeg" bit is indeed true on Win32 (my OS)
for ffmpeg versions older than the 2.5 branch;
I did conduct some tests back then, trying
the Limelight CDN for BBC One (London), using the command:

ffmpeg -re -i 
http://vs-hds-uk-live.bbcfmt.vo.llnwd.net/pool_5/live/bbc_one_london/bbc_one_london.isml/bbc_one_london-audio_1=128000-video=1374000.m3u8 - 
t 60 -c:v copy -c:a copy -bsf:a aac_adtstoasc bbc1live.mp4

and these are my findings:
FFmpeg
1.2.11:
pts (3600) < dts (7200) in stream 0
av_interleaved_write_frame(): Invalid argument
NO DOWNLOAD

2.2.11:
[mp4 @ 00f5e820] Invalid DTS: 7200 PTS: 3600 in output stream 0:0
[mp4 @ 00f5e820] Application provided invalid, non monotonically increasing 
dts
to muxer in stream 0: 3600 >= NOPTS
av_interleaved_write_frame(): Invalid argument
NO DOWNLOAD

2.4.4:
[mp4 @ 00b6ee60] Invalid DTS: 7200 PTS: 3600 in output stream 0:0
[mp4 @ 00b6ee60] Application provided invalid, non monotonically increasing 
dts
to muxer in stream 0: 3600 >= NOPTS
av_interleaved_write_frame(): Invalid argument
NO DOWNLOAD

2.5.x
[mpegts @ 05829ee0] Invalid DTS: 5310000 PTS: 5306400 in output stream 0:0, 
replacing by guess
SUCCESSFUL  DOWNLOAD,
but the command prompt window is littered
with a constant display of the above warning -
I had to add "-loglevel 16" to the command
and the 1min recording completed successfully
with negligible CPU usage...(~ 10 %).
(Please read a related post of mine here:
http://lists.infradead.org/pipermail/get_iplayer/2015-March/007414.html).

So, if a current (fresh) build of ffmpeg is used,
GiP could be modified to not use recoding
for the live TV streams (over AppleHLS).
However, the latest Win setup still fetches FFmpeg 2.2.3!

Hope you got your answer.
Regards.