The bulk of the index could be written to a temp file as the video
portion of the file is filled and then attached to the end of the AVI /
QT file along with any of the other index information that may be
required to wrap the raw index. I know, more to manage and potential
problems with partial
One thing that should be taken into account. The memory allocated by
AVIFileIndex for index grows as video is being received and
recorded, because index section should be added to the very end of
AVI file, just before closure. Although size of index data is very
small comparing to video data, i
I would disagree that decoding SDP config bits is not needed for
streaming at all.
For example, Axis 240S and 240Q video servers *do not* provide
"x-dimensions" parameter in their SDP (or other similar parameters
like "cliprect" or "framesize"). Thus, LIVE555 is not aware about
video resoluti
Re: [Live-devel] MPEG-4 Visual configuration bits in SDPHello Ross,
I would disagree that decoding SDP config bits is not needed for streaming at
all.
For example, Axis 240S and 240Q video servers *do not* provide "x-dimensions"
parameter in their SDP (or other similar parameters like "cliprect
I have implemented some functionality related to AVI indecies in
AVIFileSink class. It is yet pretty basic. But after all, it feets
my needs for the video recording. If you (or somebody else) likes I
can share the source code here.
Thanks. Yes, please send us your new "AVIFileSink.cpp" and
"
Re: [Live-devel] key frames (I-frames) in the recorded AVIHello Ross,
I have implemented some functionality related to AVI indecies in AVIFileSink
class. It is yet pretty basic. But after all, it feets my needs for the video
recording. If you (or somebody else) likes I can share the source code
1) Is there any VideoLAN independent patch that I can apply to Live555 source
tree in order to connect to a Kasenna Mediabase server with openRTSP?
No.
For many years (at least 6), our RTSP client implementation included
a gross hack to accommodate Kasenna's non-standard bastardization of
the
The time period between the stream stopping and consequent recover
is exactly 35:47.50 with a variance less than 10 msecs and this goes
forever.
Could you know any action that could be causing this behavior (so
deterministic) in my linux system?
This time is almost exactly 0x8000, when exp
Ross,
The time period between the stream stopping and consequent recover is exactly
35:47.50 with a variance less than 10 msecs and this goes forever.
Could you know any action that could be causing this behavior (so
deterministic) in my linux system?
In my previous post I think didn't understa
Hi all,
I'm aware that many discussions have already been done around this subject, but
unfortunately I still have many doubts, that's why I'm asking for help here.
I'm developing an application, based on Live555, of course, that should be able
to receive and play multicast streams from a Kasenna
Here's the stack trace:
H264VideoDiscreteFramer::doGetNextFrame() at
H264VideoDiscreteFramer.cpp:35 0x804fbba
InputESSourceRecord::askForNewData() at
MPEG2TransportStreamFromESSource.cpp:191 0x8050e7c
MPEG2TransportStreamFromESSource::awaitNewBuffer() at
MPEG2TransportStreamFromESSource.cpp:13
Ross,
Thank you for the fast feedback.
After doing some more tests it seems the video stream recovers from the
blocking after a call to AlarmHandler::handleTimeout().
Here's the stack trace:
H264VideoDiscreteFramer::doGetNextFrame() at H264VideoDiscreteFramer.cpp:35
0x804fbba
InputESSourceReco
Hi,
You should know that VC and MinGW use incompatible library format.
FFMpeg is C library this allows interoperability between VC and MinGW
(as it is with kernel32.dll and ntdll.dll). Moreover AFAIK FFMpeg
doesn't support VC (neither has plans to).
With C++ things different. As I mentioned,
I'm using Live555 to send H.264 ES video over Transport Stream using
MPEG2TransportStreamFromESSource but the video stream blocks for >20
minutes in every hour or so.
The goal is to deliver a live video stream using an H.264 video
encoder as the source, initial tests showed that Transport Stream
I may be taking a look at this over the Christmas/New Year break.
I'm not sure yet, but there might end up having to be a
non-backwards-compatible change to the index file format in order to
accommodate both kinds of Transport Stream file (MPEG-2 and H.264).
--
Ross Finlayson
Live Networks, In
When I trigger the triggerEvent() from my separate thread
(DirectShow Input pi Thread), I see that it's being catch by the
BasicTaskScheduler::SingleStep, Thinking that the way to work with
the UsageEnvironment is in the old fusion way -
env->taskScheduler().doEventLoop().
Whiteout using the
16 matches
Mail list logo
