Hi,
The latest release(0107) will fail with a SIGSEGV on HTTP live
streaming. It faults at MediaSink::onSourceClosure.
In TCPStreamSink::processBuffer, onSourceClosure is being called twice,
one being called inside the fSource->getNextFrame call, and the other being
called when the source is
On 1/10/2014 13:04, Ross Finlayson wrote:
I'm not planning on making any non-standard, Windows-specific additions
to the code.
If you're immovable on that point, then someone needs to write a .def
file for the DLL, which is *painful* for a large C++ library like
live555: http://msdn.microsoft
I'm not planning on making any non-standard, Windows-specific additions to the
code. Other operating systems have managed to use the "LIVE555 Streaming
Media" as dynamically-linked libraries in their applications - note, for
example, the supplied "config.linux-with-shared-libraries" configurati
Hi Ross,
After trawling through the posts relate to this topic , I found
one which expresses your opinion on using Live555 as a shared library.
(http://lists.live555.com/pipermail/live-devel/2004-July/000955.html) .
Certainly understand the reasoning behind it but then the conu
> Thanks, the fix does work, I am able to stream my live source. But the video
> quality I am getting on other side is quite glitch. Basically I am streaming
> encoded data from ffmpeg’s output packet (AVPacket) but I am suspecting that
> since FFmpeg Gives more than one nal unit in a single AVP
Thanks, the fix does work, I am able to stream my live source. But the video
quality I am getting on other side is quite glitch. Basically I am streaming
encoded data from ffmpeg's output packet (AVPacket) but I am suspecting that
since FFmpeg Gives more than one nal unit in a single AVPacket there
