> Out of curiosity, what VLC iPhone 'app' are you using? 'GoodPlayer'? Or
> your own custom iOS app?
Actually, it's an Android application based on the Android port of VLC.
> OK, beforehand you didn't say that this (the server seeing an incoming
> RTCP-over-TCP '$' 'packet' and responding "Me
Hi All,
I also have run into this issue on more than one occasion, with customers
using relatively high latency DSL or cellular modems. I agree it is more
than an annoyance (RTP over RTSP in this case is too unreliable to even use
at all) and any kind of fix or workaround would be greatly appr
Sorry about the non-bugs. I've not used that cast trick to see the value
as a hex number without having to drag in and use manipulators, but I
should have guessed.
This one is, I believe, an actual coding error, in the area of
order-of-evaluation.
In the macro GET_ENCODED_VAL, in VorbisAudioRTPS
> A part of the issue is that e.g. when using VLC on mobile devices as a client
Out of curiosity, what VLC iPhone 'app' are you using? 'GoodPlayer'? Or your
own custom iOS app?
> the user does not know that the attempt to play the stream has failed
OK, beforehand you didn't say that this (th
I actually ran into this very same problem a while back. We had a
customer trying to stream live low frame rate/low bit rate video over a
slow military 3G cellular network and things weren't working, I can't
remember all the details now but either the client or the server was
hanging up because
> Why are there casts to void* here?
Because I want the 'void*' version of "operator<<" to be used, not the 'char*'
version. I.e., I want the value to the right of "<<" to be printed as a %p,
not as a %s
Once again, not all compiler warning messages indicate bugs.
Ross Finlayson
Live Network
I got several complaints from g++ 4.6 while building.
This is the second one I'm reporting - because it looks like the casts are
not needed.
Why are there casts to void* here?
65 if (frameStart[0] != 0 || frameStart[1] != 0) {
66 envir() << "H263plusVideoRTPSink::doSpecialFrameHandli
The frame may be small, so SimpleRTPSink packs several frames into a
single packet. That's right, I wish it to do so. I have nevertheless
troubles to realize, how to make SimpleRTPSink flush its packets in a
time manner, after for example the first frame of a packet has 10ms
overdue time. I
> Perhaps. But is this really a problem worth worrying about? If this happens
> only occasionally (in extreme situations), and merely causes the server to
> send back a > "method not allowed" RTSP response, then is this a major
> problem? It seems to be merely an 'annoyance'.
We are working
> 1) The server could of course be made more robust by detecting the '$' char
> and ignoring such requests.
> Would this work as a quick fix?
Perhaps. But is this really a problem worth worrying about? If this happens
only occasionally (in extreme situations), and merely causes the server to s
> I have subclassed the OnDemandServerMediaSubsession, and have overridden the
> createNewStreamSource and createNewRTPSink functions as the FAQ instructs and
> can successfully receive an MPEG2 Program stream, demux it into an
> MPEG1or2DemuxedElementaryStream and pass data that into an
> H264
> I can give you an address, but I would like to give it only to you
OK, so email the url just to me: finlayson (at) live555.com
> Our company records around 160 live concerts a year (video + audio) and the
> server is dedicated for only the owner of these concerts (musicien, producer,
> cd ed
> I am using SimpleRTPSink with my frame source (based on FramedSource).
By this I hope you mean "a subclass of FramedSource".
> The frame may be small, so SimpleRTPSink packs several frames into a single
> packet. That's right, I wish it to do so. I have nevertheless troubles to
> realize, ho
I can give you an address, but I would like to give it only to you because
our dedicated server is only for bands, producers.
So from I prefer not to send this link on a public area as is this mailing
list, just because the files it contains are not dedicated for public
streaming, because
> If I put the cursor before (let's say 30 minutes) , VLC plays it well and the
> streaming continues to be ok, even after 31:06.
>
> I suppose there is a trouble about seeking in the file when the time
> requested is above 31:06...
Yes, it seems so. Once again, please post (the URL of) an ex
I just compiled and tested live555MediaServer.
I stream some wav audio files, they are 48khz 24 bits.
Every thing is working perfect ! but with long files with VLC when I move
the cursor around 31:06 (minutes) or more I get a sound like with/pink
noise.
If I put the cursor before (let's s
Hi people,
I am using SimpleRTPSink with my frame source (based on FramedSource). The
frame may be small, so SimpleRTPSink packs several frames into a single
packet. That's right, I wish it to do so. I have nevertheless troubles to
realize, how to make SimpleRTPSink flush its packets in a t
Good afternoon Ross,
I have updated to the latest version of the code, have read the FAQ and
have studied the included code samples. I am having some trouble within
my rtsp server code (based on the provided source code) which creates
subsessions on demand. These subsessions could be file sources
Hi Ross,We've run into a new issue using RTP over RTSP mode over Edge and
really slow wireless connections.
This happens in our client application (that was based on openRTSP) as well as
in VLC, which
also uses live555.
In the case where the TCP connection is really slow, it can happen that t
>> complains about the following statement:
>>
>> result = *(float*)&resultAsUnsigned;
No, this compiler warning message does not indicate a bug in the code.
"resultAsUnsigned" is a 4-byte value that stores a 'float'; it is not an
unsigned value that gets converted to a float.
>> This li
20 matches
Mail list logo