Thanks for the response.
Well, the rabbit hole got deeper as I actually hard coded (as a hack,
obviously) the SR reports to always report 0 for the octet and packet
count. That did nothing. So my theory was proven to be incorrect. I'm going
to update the server code and try that.
We're talking wi
> I copy below two links of the test which I have done. Maybe you have a better
> idea of what kind of mistake we are doing.
>
> https://drive.google.com/file/d/0B0rFtoVWa4g0VWFNb3luYUhoMmM/view?usp=sharing
>
> https://drive.google.com/file/d/0B0rFtoVWa4g0MzZDLXFjUEZFdW8/view?usp=sharing
OK, bu
One more thing: As always, make sure that you’re using the latest version of
the code (2016.04.01); see
http://live555.com/liveMedia/faq.html#latest-version
I’m at a loss to understand what could be causing this problem; it definitely
appears to be a bug of some sort in your ‘Android Pho
2016-04-19 16:19 GMT-03:00 Ross Finlayson :
>> We have a video subsession, which works fine streaming H.264 video
frames.
>> We added another subsession for audio, we return as you suggested our
>> own framed source subclass.
>>
>> The interesting thing is if we NOT ADD the video subsession to the
...sorry, I missed that you asked about audio exclusively as well. Yes, the
issue persists even when it's audio only.
On Wed, Apr 20, 2016 at 9:42 AM Ben Rush wrote:
> Ross,
>
> Thanks for your response. Here are your answers:
>
> 1) Any client that we've tested thus far continues to connect and
Ross,
Thanks for your response. Here are your answers:
1) Any client that we've tested thus far continues to connect and stream
without issue after the Android phone connects, or after any other client
connects. This is strictly the ONLY client we've seen to have ANY problems
like this.
2) Comme
