> It is possible that Live555 is using the POSIX layer in a way that
> particularly annoys Cygwin, but I'd say the burden is on you to prove that,
> given that the library performs well on every other POSIXy OS.
>
> Cygwin tries very hard to be as minimal a layer between your program and the
>
On 2/19/2014 05:12, Martínez Contador, Daniel [ELIMCO] (CA) wrote:
The overuse happens with binaries from CYGWIN, but not with MINGW.
So you changed the development platform, but you blame Live555?
Science says that if you change one variable and the behavior changes,
chances are that the thi
> testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears
> the session.
> The overuse happens with binaries from CYGWIN, but not with MINGW.
I wasn't able to reproduce this on either MacOS X or FreeBSD.
If you find a bug, please let us know.
Ross Finlayson
Live Networks, Inc.
ht
> It seems “AD 70” are missing ?
Finally! An issue with our software (rather than VLC :-)
There was a bug in the way in which our code (and thus "openRTSP") received the
H.265/RTP stream.
I've just installed a new version - 2014.02.19 - that fixes this. Thanks for
the report.
Ross Finlayso
Hi Ross,
I guess the problem is deeper.
Modifying the start code of the first IDR frame of surfing.265 from 00 00 01 to
00 00 00 01, but it does not solve the problem.
The result file still contain an IDR frame :
00 00 00 01 26 01 C8 D7 0D 55 E5
But the original file start with an ID
testMPEG4VideoStreamer.exe starts overusing the CPU when a player tears
the session.
The overuse happens with binaries from CYGWIN, but not with MINGW.
In my setup, testMPEG4VideoStreamer, just launched, uses <1% from CPU.
When a client connects (I'm using VLC) the CPU consumption remains
stable.
Okay, that makes more sense, it was the partition boundary splitting which
I was referring to and not the blocks, please excuse my misuse of terms.
I assume the codec on the receiving end would be able to handle the missing
partitions using the error concealment method already built into the codec
> Yes I was referring to the packing of VP8 payloads as done in the referenced
> draft. If that is already implemented and used automatically the problem must
> lie elsewhere as I am using the VP8VideoRTPSink class as you are referring
> to.
> As I understand the payload packing it should split
Ross,
Yes I was referring to the packing of VP8 payloads as done in the
referenced draft. If that is already implemented and used automatically the
problem must lie elsewhere as I am using the VP8VideoRTPSink class as you
are referring to.
As I understand the payload packing it should split the fra
> I am testing with my own live555 based server and openRTSP as the client.
> I would therefore like to apply packetization in order to limit the influence
> of transmission errors. Is there any support for packetization with VP8 video
> streaming such as what google suggests in
> http://tools.i
Hi
I'm currently working with live555 and really appreciate the software,
thank you.
I currently have the video streaming up and running but as I am streaming
over udp on a wifi link I have a significant packet loss.
This causes more failed than successfull frames without packetization and
effectiv
11 matches
Mail list logo
