--hls-liveradio-opts

[Vangelis forthnet]

On Mon Dec 15 21:00:46 GMT 2014, dinkypumpkin wrote:

> --hls-liveradio-opts only applies to ffmpeg output, not input,

Thank you for looking into this; I get it now!
The ffmpeg options (and their respective values) that are input
via the --hls-liveradio-opts GiP option are treated by GiP as
FFmpeg output only options, thus when GiP is formulating the
FFmpeg HLS download command, it's placing all those options
after the -i option; so even if I include input options like -re,
-headers, -user-agent, -cookies etc., these will be ignored by FFmpeg!
 However, if an FFmpeg output option existed whose value was
enclosed in double quotes, then again the GiP code would've failed,
due to wrong parsing in this step:

push @cmdopts, ( split /\s+/, $opt->{'hls'.$prog->{type}.'opts'} );

> I've amended the help text accordingly.

Thanks; I'm not seeing any feedback on the list or Support forum
regarding the HLS modes; they may prove quite handy once
the RTMP streams start vanishing...

> I may remove those options before next release.

Please, don't!
--hls-liveradio-opts="-loglevel info"
allows me to monitor the ffmpeg download progress;
--ffmpeg-liveradio-opts="-loglevel info"
prints ffmpeg info during the remux to MP4 container.
Without either of these, all I see is an increasing
(hopefully) file size...

As far as my original issue is concerned, I'll let you know
that I solved it by taking a first shot at writing some code
(via aping yours, of course, so am much obliged!).

I created a new option, called:

--hls-headers-liveradio-opts

 & amended the code inside "package Streamer::hls"
to take it into account. I have attached a manual
patch guide that can be applied with an editor to get_iplayer.pl
commit git-9819c03 and all succeeding it that integrate
support for HLS liveradio streams.

On Linux, you can type:

--hls-headers-liveradio-opts 'X-Forwarded-For: 31.3.xxx.xxx\r\n'

and a fairly recent ffmpeg binary should pick this up (not tested).
On Windows however, the FFmpeg binary fails because of this bug:

https://ffmpeg.org/pipermail/ffmpeg-user/2013-July/016528.html
https://trac.ffmpeg.org/ticket/3268

I have patched source file http.c of FFmpeg-2.5 and successfully
compiled a win32 binary that can accept via windows command line
this input option:

-headers "X-Forwarded-For: 31.3.xxx.xxx"

Manual patch file attached.

If I employ this patched FFmpeg-2.5 in GiP, I type:

--hls-headers-liveradio-opts "X-Forwarded-For: 31.3.xxx.xxx"

and the FFmpeg binary works as expected.
Using this GiP command:

get_iplayer -p [UK http proxy 
details] --type=liveradio --pid=bbc_radio_three --modes=hlsaachigh --hls-headers-liveradio-opts="X-Forwarded-For: 
[UK IPv4]"
--hls-liveradio-opts="-loglevel info" --ffmpeg-liveradio-opts="-loglevel 
info" --force --stop 120

with the patched FFmpeg binary
gives access to the otherwise geo(b)locked 192kbps Radio 3 HLS stream...
My UK friends, do not be mad at me; I just wanted to prove that it can be 
done...
I doubt the average GiP (overseas) user will go at such great lengths to 
listen to
high quality Radio 3...

Merry Christmas. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HLS_headers.patch
Type: application/octet-stream
Size: 1701 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/get_iplayer/attachments/20141216/e6729093/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http.c.patch
Type: application/octet-stream
Size: 629 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/get_iplayer/attachments/20141216/e6729093/attachment-0001.obj>