On 8/20/2012 8:27 PM, Sid Price wrote:
As I asked, do you know of a tool I could use
to convert the test files I have been supplied with to plain PCM
Try http://sox.sf.net/
I don't see your format on the codec page[*] but it's too easy not to
just try it. If you don't have it installed, it'
Ross,
I completely understand. As I asked, do you know of a tool I could use to
convert the test files I have been supplied with to plain PCM (format 1).
This is part of a proof on concept so I do not have to play the WAV files as
they are. They can be re-encoded.
Thanks,
Sid.
From: li
> I have built to new code and run into an issue with my test WAV file no
> longer playing. Your new WAV parser is rejecting the WAV file because of the
> audio format entry which is 0x0012 which is said to be “Videologic Mediaspace
> ADPCM”.
We have never been able to stream WAV files that use
Ross,
I have built to new code and run into an issue with my test WAV file no
longer playing. Your new WAV parser is rejecting the WAV file because of the
audio format entry which is 0x0012 which is said to be "Videologic
Mediaspace ADPCM". I am not terribly familiar with codecs so do you know
> Now the live555 server can stream out from encoder with unicast udp/tcp
> or multicast respectively.
>
> But my problem is that how to build rtsp server supports TCP and
> Mulitcast at the same.
I presume you mean that you want some clients to receive a RTP-over-TCP stream,
and
Dear experts,
I have read some of the FAQs and mail list.
Thank you for your effort.
Now the live555 server can stream out from encoder with unicast
udp/tcp or multicast respectively.
But my problem is that how to build rtsp server supports TCP and
Mulitcast at the same.
> - The absolute timestamp I ask for doesn't match what I receive, Many hours
> off, but at least it's consistent.
>
> For what it’s worth, this sounds like it could potentially be a time zone
> issue. I’ve run into issues in the past where some of the routines I used
> interpreted my UTC tim
- The absolute timestamp I ask for doesn't match what I receive, Many hours
off, but at least it's consistent.
For what it's worth, this sounds like it could potentially be a time zone
issue. I've run into issues in the past where some of the routines I used
interpreted my UTC timestamp as a t
> The functionality works ok when using the Cisco Active X control, but I get
> the exact same issue when sending RTSP commands manually via a telnet client
> (which is expected, just confirming liveMedia doesn't introduce anything).
OK, so it should be easy to figure out what RTSP commands the
FYI, the latest version (2012.08.20) of the "LIVE555 Streaming Media" code
adds optional RTSP server and RTSP client support for streams that are
indexed by 'absolute' time - i.e., using strings of the form
"MMDDTHHMMSSZ" or "MMDDTHHMMSS.Z".
Ross Finlayson
Ross, Thank you very muc
Thank you very much Ross, your ongoing support is much appreciated,
Sid.
From: live-devel-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson
Sent: Monday, August 20, 2012 1:44 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel
hi, i open VLC's debug message and get below log from VCL:
packetizer_h264 warning: waiting for SPS/PPS
packetizer_h264 warning: waiting for SPS/PPS
packetizer_h264 warning: waiting for SPS/PPS
packetizer_h264 warning: waiting for SPS/PPS
packetizer_h264 warning: waiting for SPS/PPS
packetize
> After doing some testing with openRTSP and looking through the code it
> appears like "Absolute Time" is currently not supported for RTSP streams.
> I.e. I can't specify a specific time that the stream should seek to, e.g.
> Range: clock=20120629T07.00Z, all according to paragraph 3.7 at
FYI, I've now installed a new version (2012.08.20) of the "LIVE555 Streaming
Media" code that updates the "BasicTaskScheduler" class to add an optional
"maxSchedulerGranularity" parameter to "BasicTaskScheduler::createNew()". (The
default value is the same as before: 1 - i.e., 10 ms.)
If y
14 matches
Mail list logo
