> 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().
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
