[Live-devel] RTSP client and SiliconDust HDHomeRun Prime

[Yaobing Deng]

 > On Jun 26, 2013, at 8:24 AM, Yaobing Deng <yaobing at jriver.com 
<http://lists.live555.com/mailman/listinfo/live-devel>> wrote:
 >>/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.
 >
/> Remember that under the terms of the (L)GPL, you are therefore 
legally required to make your 'kludge' available to all customers of your
 > application. A much better solution, therefore, is to get 
'SiliconDust' to fix their buggy, non-standards-compliant hardware 
(e.g., via a firmware
 > upgrade). Then, you won't need to make (and therefore won't need to 
distribute with your own product) any changes to the "LIVE555
 > Streaming
 > Media" code. Ross Finlayson Live Networks, Inc. http://www.live555.com/

Thanks for the reminder about the GPL.  I do have that in mind when I 
replied your last message (and sorry for forgetting to fix the subject 
line).  Would it not be sufficient by making my changes public on this 
developer mailing list (as I attempted in my previous reply)?

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().


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20130626/735ed790/attachment-0001.html>