Ok Thanks, It's not the answer I wanted but It's what I expected.
I guess even if I could configure the server in this way the client
support might not be great anyway.
On 08/20/2015 03:53 PM, Ross Finlayson wrote:
The RTSP spec allows a server to provide multiple transport options
for a sing
s that the library
doesn't support this either? but openRTSP does support explicitly
requesting a multicast stream.
Help appreciated,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Hi Ross,
Yes I understand that it is an issue with VLC and not with Live555.
I'm not asking for any changes to the Live555 library.
I am asking whether it is possible to configure my Live555 RTSP server
to ignore the case of stream names in URL's as a workaround for the VLC
problem because we
imlpementation which ignores case. But is this likely to break anything
else in the library that uses the HashTable class or is there an easier
way to achieve what I want?
Thanks,
Robert Smith.
___
live-devel mailing list
live-devel@lists.l
It's 001
On 03/27/2015 07:11 PM, Gilles Chanteperdrix wrote:
On Thu, Mar 26, 2015 at 02:32:32PM +0100, Robert Smith wrote:
Ok, but I use this with other encoders too, it's only the embedded platform
where the parsing cost is so critical. I think it shouldn't be a big deal
2015 at 02:42:29PM +0100, Robert Smith wrote:
Thanks,
I'm not sure what sort of constraints I can put on the number of slices so I
probably can't get away with short circuiting the parsing as nicely as you
do, but from memory our code for finding the start codes steps byte by byte
so you
ignificant
improvement.
I would need to search for three byte start codes though, I haven't
analysed the output of the TI encoder but I have had other encoders
outputting three start byte start codes.
On 03/23/2015 08:06 PM, Gilles Chanteperdrix wrote:
On Mon, Mar 23, 2015 at 10:52:46A
Hi Gilles,
How were you extracting the NALU's from the frames provided by the
encoder? Were you using the H264VideoFramer class?
I'm aware that we're not going to see anything from TI and their SDK is
still an 'alpha' release.
Ross, I appreciate the support you provide, I hope my experienc
This would still depend on a constant frame rate though? I can't
guarantee that the source or encoder won't drop frames so it needs to be
robust against that.
Besides, my encoder has options for VUI but the documentation states
that these parameters are ignored.
On 03/19/2015 10:47 AM, Ross
s the H264VideoStreamFramer to handle discrete
frame input in Annex B format somehow.
On 03/11/2015 01:54 PM, Robert Smith wrote:
I've got this working now, I think my problem was conceptually
treating the byte stream as a series of frames instead of as a
continuous stream.
Having loo
boost mutex with a scoped_lock when
I needed to protect, It implements cross platform the best avail on a
platform.
On Tue, Mar 17, 2015 at 9:07 AM, Robert Smith <mailto:sm...@cognitec.com>> wrote:
Ok, I will implement my own TaskScheduler class, but operations
that read-modify-
Ok, I will implement my own TaskScheduler class, but operations that
read-modify-write memory are not atomic with multiple processors/cores.
I guess the large portion of users these days will be using multicore
x86 processors.
I asked this question on stackoverflow and the responses support th
Now that I've had the time to look into it I've figured out what it was.
I'm compiling with -DWIN32_LEAN_AND_MEAN which causes #include
to be excluded from Windows.h (amonst other things).
ole2.h #includes and objbase.h #includes
So presumably noone else has compiled with -DWIN32_LEAN_AND_M
Maybe it's atomic on a single core CPU but it's not going to be safe
with multicore CPU's.
Having thought about it some more, I don't think it's enough to just
protect calls to triggerEvent() because 'fTriggersAwaitingHandling' is
still modified by BasicTaskScheduler::SingleStep().
I'm not j
ing it just means that stdlib.h has been included by another
header.
Robert Smith.
On 03/16/2015 11:08 AM, Ross Finlayson wrote:
But I don't think it's unreasonable for files to include the headers
that define the symbols they use so maybe worth adding stdlib.h to
the files that need
plementation of triggerEvent() can be thread
safe, e.g, the last line:
fTriggersAwaitingHandling |= eventTriggerId;
must load, modify and store the value at fTriggersAwaitingHandling and
this won't be atomic.
Regards,
Robert Smith.
___
live-devel mai
ny Number :
03428325
*From:*live-devel [mailto:live-devel-boun...@ns.live555.com] *On
Behalf Of *Robert Smith
*Sent:* 12 March 2015 13:29
*To:* LIVE555 Streaming Media - development & use
*Subject:* Re: [Live-devel] Windows build - undefined symbols
Ok it's probably my and issue wit
ding on or being
included by other VC++ headers.
On 03/12/2015 11:29 AM, Ross Finlayson wrote:
On Mar 12, 2015, at 11:22 PM, Robert Smith <mailto:sm...@cognitec.com>> wrote:
The following files need to include the or header:
UsageEnvironment/UsageEnvironment.cpp
liveMedia/RTSPCo
The following files need to include the or header:
UsageEnvironment/UsageEnvironment.cpp
liveMedia/RTSPCommon.cpp
testProgs/testMP3Streamer.cpp
Otherwise building with VC++ complains about undefined symbols.
___
live-devel mailing list
live-devel@l
I've got this working now, I think my problem was conceptually treating
the byte stream as a series of frames instead of as a continuous stream.
Having looked at the ByteStreamMemoryBufferSource class it makes a lot
more sense now.
On 03/11/2015 10:10 AM, Robert Smith wrote:
Fi
t of image corruption with multiple slices enabled.
I haven't had time to look into the problem deeper but using a single
slice was a quick and easy solution.
Thanks,
Robert Smith.
On 03/10/2015 01:49 AM, Ross Finlayson wrote:
The encoder unfortunately only supplies frames in Annex B
runcate frames with the
H264VideoFramer because in this case the StreamParser is always able to
ask for numBytesNeeded which could be much less than the actual frame
size, It doesn't take into account that zero means unlimited.
Thanks,
Robert Smith.
___
n the actual frame size,
It doesn't take into account that zero means unlimited.
Thanks,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
h less than the actual frame
size, It doesn't take into account that zero means unlimited.
Thanks,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
modifications to our legacy code.
Shouldn't RTCP automatically re-synchronise this anyway?
Regards,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
FramedSource*,
the Framer object cleans up the FramesSource object in it's destructor.
Regards,
Robert Smith
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
g difference for me today.
Regards,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
g
reuseFirstSource = True would mean that I could use a single source object.
I've obviously misunderstood the instructions in the FAQ so it would be
great if you could point me in the right direction.
Regards,
Robert Smith.
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
28 matches
Mail list logo
