What is the --mode= command for R3 high quality aac streams please

[richard]

bat guano wrote:
> 
> 
> ----------------------------------------
>> Date: Sat, 14 May 2011 09:42:50 +0100
>> From: get_iplayer at cjnash.com
>> To: batguano999 at hotmail.com
>> CC: roadcone at gmx.com; get_iplayer at lists.infradead.org
>> Subject: Re: What is the --mode= command for R3 high quality aac 
>> streams please
>>
>> bat guano wrote:
>>>
>>> ----------------------------------------
>>>> Date: Fri, 13 May 2011 22:07:30 +0100
>>>> From: clivebuc at gmail.com
>>>> To: get_iplayer at lists.infradead.org
>>>> Subject: Re: What is the --mode= command for R3 high quality aac
>>>> streams please
>>>>
>>>>
>>>>
>>>> On 13/05/2011 21:44, bat guano wrote:
>>>>>
>>>>> ----------------------------------------
>>>>>> Date: Fri, 13 May 2011 20:25:56 +0100
>>>>>> From: clivebuc at gmail.com
>>>>>> To: get_iplayer at lists.infradead.org
>>>>>> Subject: What is the --mode= command for R3 high quality aac
>>>>>> streams please
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> It seems that R3 is broadcasting 320K aac streams for their
>>>>>> evening live
>>>>>> concerts. Can anyone guide me as to the correct --mode=?? switch
>>>>>> to
>>>>>> secure those streams please?
>>>>>>
>>>>>> Thank you.
>>>
>>>>>> Clive
>>>>> Hi
>>>>> It was mentioned in an email some months ago.
>>>>> I can't find the email now, but this is the command to download
>>>>> the 320Kbps aac stream in an flv container:-
>>>>>
>>>>> get_iplayer --get --type=liveradio
"http://www.bbc.co.uk/mediaselector/4/gtis/?server=cp60703.live.edgefcs.net&identifier=Special_Event1_UK@s6485&kind=akamai&application=live"
>>>>>
>>>> Thanks for the replay batguano - I can see this is to access the
>>>>> live
>>>> stream (which I have never tried but now I know how). What I was
>>>> after
>>>> is the mode to d/l the file later. My default mode is 
>>>> --mode=flashaac
>>>> for R4 and R4Ex but that gets me 128K - is there a 320K equivalent
>>>> please?
>>>>
>>>> Thanks.
>>>>
>>>> Clive
>>> Hi
>>> I don't think that the Radio 3 'listen again' shows are available in
>>> 320Kbps format... but maybe I'm wrong.
>>> See if someone else corrects me.
>>>
>>> By the way, when using my previous command to download the live 
>>> 320Kbps stream, it gives me better results if I include:-
>>> --rtmp-liveradio-opts --live
>>> in the command.
>>> Like this:-
>>> get_iplayer --get --type=liveradio --rtmp-liveradio-opts --live
"http://www.bbc.co.uk/mediaselector/4/gtis/?server=cp60703.live.edgefcs.net&identifier=Special_Event1_UK@s6485&kind=akamai&application=live"
>>>
>>>
>> Can you say a little more about what kind of better results you get
>> when
>> you use this option?
>>
>> Simon
>>>
> *** > 
> Can you say a little more about what kind of better results you get 
> when
> you use this option?
> Simon
> *** >
> 
> Hi Simon
> If I don't use '--rtmp-liveradio-opts --live', when I come to unpack 
> the flv with FFmpeg it "sometimes" gives errors.
> Like this:-
> ffmpeg -i foo.flv -acodec copy foo.aac
> [adts @ 0x9f432e0] Application provided invalid, non monotonically 
> increasing dts to muxer in stream 0: 4973220 >= 4971150
> 
> When this happens, I've tried using absf but it doesn't seem to cure 
> it.
> Like this:-
> ffmpeg -i foo.flv -acodec copy -absf aac_adtstoasc foo.aac
> 
> Using '--rtmp-liveradio-opts --live' adds '--live' to the command for
> RTMPDump.
> 
> I've come across this before when downloading other (non BBC) streams
> with RTMPDump.
> 
> For live streams (and sometimes even for non-live streams) RTMPDump 
> tries to download too fast.
> Then it trips up, then it tries to resume.
> So it produces weird timestamps.
> Using '--live' option with RTMPDump will prevent this.
> 

For information:

I found the '--rtmp-liveradio-opts --live' option doesn't always prevent
invalid timestamps, although it helps prevent it. 

More details here:

http://ffmpeg.org/pipermail/ffmpeg-user/2011-June/001323.html

If you get the error 'invalid, non monotonically increasing dts to muxer
in stream' I found a workaround. Details here:

http://ffmpeg.org/pipermail/ffmpeg-user/2011-June/001342.html