[Live-devel] live-devel Digest, Vol 116, Issue 18

[Yaobing Deng]

On 6/26/2013 2:15 AM, live-devel-request at ns.live555.com wrote:
> Message: 2
> Date: Tue, 25 Jun 2013 12:38:41 -0700
> From: Ross Finlayson <finlayson at live555.com>
> To: LIVE555 Streaming Media - development & use
> 	<live-devel at ns.live555.com>
> Subject: Re: [Live-devel] RTSP client and SiliconDust HDHomeRun Prime
> Message-ID: <659AE46F-08B4-43AA-86DD-CBD80E2C234B at live555.com>
> Content-Type: text/plain; charset="us-ascii"
>
>> I am using the RTSP client of Live555 in my application. The purpose is to support CableCARD tuners.  I got it working for some devices (such as Ceton InfiniTV) but encountered a problem with SiliconDust's HDHomeRun PRIME.  What I found out (and also confirmed by SiliconDust support) is that the device sends a value of 96 for payload type in the SDP description, like the following,
>>
>> v=0
>> t=0 0
>> a=type:broadcast
>> a=recvonly
>> m=video 0 RTP/AVP 96
>> a=rtpmap:96 MP2T/27000000
>>
>> but when the actual video is streamed, the type is of value 33.
> This is clearly an error in the server (the "SiliconDust's HDHomeRun PRIME").  It is advertising that its RTP packets are using RTP payload format code 96 - which is wrong - and using a RTP timestamp frequency of 27000000 - which is probably also wrong.  (MPEG Transport Stream packets are usually streamed in RTP with a standard RTP timestamp frequency of 90000.)
>
> The server needs to be fixed, because it is advertising a stream that it is not providing.
>
> Instead of these SDP lines:
> 	m=video 0 RTP/AVP 96
> 	a=rtpmap:96 MP2T/27000000
> The server should be fixed so that it sends just:
> 	m=video 0 RTP/AVP 33
> because "33" is a static RTP payload format code, defined specifically to mean: streaming MPEG Transport Stream data at frequency 90000.
> Or, if the server really is using a nonstandard RTP timestamp frequency of 27000000 (which is unlikely, but conceivable), then it should send:
> 	m=video 0 RTP/AVP 33/27000000
>
> Please contact "SiliconDust" to tell them to fix their server, and suggest that - in the future - they use our free RTSP client applications "testRTSPClient" and "openRTSP" to test their RTSP implementation.

Thanks for the reply.

I am contacting SiliconDust, and hoping they will fix the problem soon.

Meanwhile, in order to make their device work in our application (JRiver 
Media Center), we are temporarily ignoring the payload type discrepancy, 
in the following way, until SiliconDust fixes the problem.

We change this block

      // Check the Payload Type.
      if ((unsigned char)((rtpHdr&0x007F0000)>>16)
      != rtpPayloadFormat()) {
        break;
      }

to this

         // Check the Payload Type.
         // Kludge - HDHomeRun Prime advertises the value 96, but sends 
the value 33
         if ((unsigned char)((rtpHdr&0x007F0000)>>16) != 
rtpPayloadFormat() &&
             ((unsigned char)((rtpHdr&0x007F0000)>>16) != 33 || 
rtpPayloadFormat() != 96)) {
             break;
         }

inside function MultiFramedRTPSource::networkReadHandler1().

Thanks again.

Yaobing Deng
JRiver