Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="_=_NextPart_001_01CA475C.703F5916"
We've been using the 2008.09. 1220313600 of live55 and everythings
been dandy. We upgraded to 2009.09.04 1252022400 and seem to have a
problem with a darwin
Thus my question : while fast forwarding an H264 file should I only
stream key frames ?
Yes, I think that's the only way to do this (without
decoding/rencoding the video).
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel
We use MJPEG over RTP to send on demand hi resolution still images along
side our video which is lower res H.264.
Is there an extension to the MJPEG standard that allows JPEG over 2k x
2k? If so we'd be interested in implementing it.
Matt S.
Cristiano Belloni wrote:
Ross Finlayson wrote:
Som
Hi,
I have made a H264 media server and the input is encoded frames directed
coming from the hardware encoder, not from a file.
I can successfully receive the H264 stream from openRTSP command tool and
store the received stream into a file.
The VLC player also can play the stored the file smoothly
Dear Ross,
I have developed a RTSP streaming server that supports H264 and M4V-ES and I
am now trying to implement Trick Play functionalities.
In order to support fast forward and reverse play, I have understood that I
need to work with "scale".
For a scale = 2.0, I have understood that I need to
We've been using the 2008.09. 1220313600 of live55 and everythings been
dandy. We upgraded to 2009.09.04 1252022400 and seem to have a problem
with a darwin server. When we place the sdp file that is created with
the live555 from 2009.09.04 1252022400 we can not connect to the
stream on our dar
Because I am a jackeroo,so many questions(may be too sample)are diffcult for me
to solve.At present I want to change the stream of MPEG1or2,to add some bits
into the data segment of extension & user data.which part should I modify? and
how to replace the primary RTP source with the modified RTP
Ross Finlayson wrote:
Someday we will support RTP header extensions (though not necessarily
this particular application of them (see above)).
More generally, though, I'm curious about why people are still
interested in JPEG-over-RTP, especially with very large JPEG images.
JPEG is a *terrible
