>OK, try adding the following, after the call to "fread()" (line 138)
>in "ByteStreamFileSource.cpp":
> if (fFrameSize == 0) {
> handleClosure(this);
> return;
> }
>
>Please let us know if that works for you. (If so, I'll add it to the
>next source code
HI..
For Playing Multiple channels in testMPEG1or2AudioVideoStreamer
application , I created multiple instances of serverMediaSession. But the
server is streaming one file after another...it is not streaming all the
files(channels) simultaneously. So the clients cannot play all the
channels sim
When I try to run testMPEG4VideoStreamer, I am getting the following
errors continuously..
MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit 1 not set!
MPEG4VideoStreamParser::analyzeVOLHeader(): vop_time_increment_resolution
is
zero!
MPEG4VideoStreamParser::analyzeVOLHeader(): marker_bit
Peter,
Thanks for the report. Yes, you're correct that the current code is
buggy - it should not be doing more than one potentially blocking
socket read inside the read handler (because the second and
subsequent reads might, indeed, block). It seems a bit strange that
a client would behave i
As an application programmer, when would I want to specify
playTimePerFrame to ByteStreamFileSource?
When you are streaming directly from a file, by reading/streaming one
fixed-size chunk of data at a time. This happens for many simple
audio codecs (although not for more complex audio codecs
> Q: What is ByteStreamFileSource::fPlayTimePerFrame for?
>
> It's used to implement the (optional) "playTimePerFrame" parameter
> in "ByteStreamFileSource::createNew()".
> --
Yes, I did look at the code for this, but I don't understand what
"playTimePerFrame" actually does. Does it request t
In live555 release 0.18 (1st July 2007), I have occassional found that
the server can "appear" to lock up when streaming RTP over TCP. After
much analysis I think I have traced the problem to the tcpReaderHandler
method in RTP_Interface.cpp.
Specifically lines 332 to 337
do {
if (readSoc
>but we haven't! in first mail I have explained why.
>
>This is because we check for EOF only before reading!
>
>Then we read next time, we before check for EOF,
>but there's no EOF state and we try to read,
>and of course we read 0 bytes, but now we have EOF state =)
OK, try adding the following,
but we haven't! in first mail I have explained why.
This is because we check for EOF only before reading!
Then we read next time, we before check for EOF,
but there's no EOF state and we try to read,
and of course we read 0 bytes, but now we have EOF state =)
and it's handled not here, as it s
>\For example I have file with size 6011488 bytes.
>6011488 = 4568*1316=4568*(7*188) <--it's correct transport stream file,
>but then we read last portion of this file:
> fFrameSize = fread(fTo, 1, fMaxSize, fFid);
>we read exactly 1316 bytes, the file is no longer left bytes!!!
>but also we
Ok, I agree with you in that case. But that about first case?
Sometimes it's happens =)
For example I have file with size 6011488 bytes.
6011488 = 4568*1316=4568*(7*188) <--it's correct transport stream file,
but then we read last portion of this file:
fFrameSize = fread(fTo, 1, fMaxSize,
>1. usually fMaxSize = (7*188)=1316 and then in file remain in exact 1316
>unreaded bytes,
> then EOF don't happens
>2. if in file remain little then 188 bytes (TS packet) EOF dont't
>happens too
The size of all Transport Stream files should be a multiple of 188
bytes. If you have a Transpo
Then one file is over, ByteStreamFileSource switch us to another file,
for this purpoise it has method:
"void ByteStreamMultiFileSource::onSourceClosure1() {
// This routine was called because the currently-read source was
closed
// (probably due to EOF). Close this source down,
Is there any congestion control in liveMedia?
No. The IETF has recently defined RTP/AVPCC - a congestion
controlled variant of the basic RTP profile - but we do not currently
implement this.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/__
Hi, everyone
Is there any congestion control in liveMedia? I haven't found yet.
Ben
ruru605
2007-09-10
BEGIN:VCARD
VERSION:2.1
N:ÖÜ;Èæ
FN:ÖÜ Èæ
NICKNAME:Ben
ORG:kut
NOTE;ENCODING=QUOTED-PRINTABLE:??
EMAIL;PREF;INTERNET:[EMAIL PROTECTED]
EMAIL;INTERNET:[EMAIL PROTECTED]
REV:20070910T144215Z
15 matches
Mail list logo
