> On Feb 4, 2018, at 11:32 PM, Maksym Zhmak wrote:
>
> I have some problem with playing video in trick-play mode from live555 RTSP
> server.
> It happens when I try to reverse-play TS file with MPEG-4 part 10 (H.264)
> video encoded - picture freezes and stands still for many seconds.
>
> I
I have some problem with playing video in trick-play mode from live555 RTSP
server.
It happens when I try to reverse-play TS file with MPEG-4 part 10 (H.264) video
encoded - picture freezes and stands still for many seconds.
I tried on many files, including sample you provide on your site -
b
>> Boolean
>> MPEG2TransportStreamIndexFile::seekToIndexRecord(unsigned long
>> indexRecordNumber) {
>>if (!openFid()) return False;
>>
>>if (indexRecordNumber == fCurrentIndexRecordNum) return True; // we're
>> already there
>>
>>if (SeekFile64(fF
>Boolean
> MPEG2TransportStreamIndexFile::seekToIndexRecord(unsigned long
> indexRecordNumber) {
> if (!openFid()) return False;
>
> if (indexRecordNumber == fCurrentIndexRecordNum) return True; // we're
> already there
>
> if (SeekFile64(fFid, (
Today I analyse the .tsx file’s generation logical. Here is my founding:
1. In MPEG2TransportStreamIndexFile.hh
#define INDEX_RECORD_SIZE 11
2. In MPEG2TransportStreamIndexFile.cpp
238 Boolean MPEG2TransportStreamIndexFile::seekToIndexRecord(unsigned long
indexRecordNumber) {
2
m] On Behalf Of
Ross Finlayson
Sent: Saturday, May 17, 2014 2:41 AM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] Trick play
We have been checking the trick play with the Live555 Server. We found that
when doing the FFW or REW, The PID values of the stream id, PMT
> We have been checking the trick play with the Live555 Server. We found that
> when doing the FFW or REW, The PID values of the stream id, PMT and Video
> Elementary Stream are changed to different values.
Strictly speaking, the trick play mechanism isn't 'changing' the PID, because
it's not r
Hi Ross,
We have been checking the trick play with the Live555 Server. We found that
when doing the FFW or REW, The PID values of the stream id, PMT and Video
Elementary Stream are changed to different values.
Do we need to change the same. Can we revert it to the original PID values.
> The main reason I didn't blame Cisco's VSM server right away is because
> reverse play works in Cisco's player that comes with the server (which
> however doesn't use RTSP).
If the client's "PLAY" request is valid - which it probably is - then if the
server doesn't do what you requested, then
Whenever I supply a negative scale value to the Play-function it always
plays forward. The speed is correct, but I've never been able to play in
reverse.
Don't forget to also specify a non-zero 'start time', so that the server
knows where to start reverse-play from.
Thanks, I do that. I
>> Whenever I supply a negative scale value to the Play-function it always
>> plays forward. The speed is correct, but I've never been able to play in
>> reverse.
>
> Don't forget to also specify a non-zero 'start time', so that the server
> knows where to start reverse-play from.
Or, alternat
> Whenever I supply a negative scale value to the Play-function it always plays
> forward. The speed is correct, but I've never been able to play in reverse.
Don't forget to also specify a non-zero 'start time', so that the server knows
where to start reverse-play from.
>
> It might be some
Can someone confirm if reverse play works fine?
Whenever I supply a negative scale value to the Play-function it always
plays forward. The speed is correct, but I've never been able to play in
reverse.
It might be some RTSP fluke with the Cisco VSM server we're using, but
wanted to verify i
> I am writing a proxy for VOD servers. I am using the Live 555 server for
> testing. The version I have is about 1 year old. How can I tell, from the
> source code, what version I have?
See http://www.live555.com/liveMedia/faq.html#latest-version
As noted in the FAQ, only the latest version
I am writing a proxy for VOD servers. I am using the Live 555 server for
testing. The version I have is about 1 year old. How can I tell, from the
source code, what version I have? If I say play range npt=30-60 at scale 1 it
works. If I say play range npt=30-60 at scale 2 it goes way beyond
> I'm having a problem when trying to trick play from mkv files produced by
> ffmpeg in that I cannot seek in them. I don't seem to be able to play back
> webm files at all (at least, VLC doesn't like them).
OK, so your first task should be to find out (perhaps using a VLC mailing list)
why VL
Hi there:
I'm trying to use live media server to stream out video, captured live
from an HD camera, but streamed on demand starting at an arbitrary
point. My plan is to use dvgrab (in linux) to grab the firewire HDV
stream, pipe it into ffmpeg and transcode to a file that can be streamed
by
> We assume there *is* some bad consequence, since the code probably wasn't
> written for no reason. Which client does this hack break?
The intention of the code is to make sure that the server's state
(specifically, its record of where in the stream it is) is accurate, so that a
subsequent RT
If you use live555MediaServer to stream MPEG-2 in a TS to an Enseo
HD2000 STB, pause and resume works fine as long as you haven't used the
indexer to build .tsx files, or you disable trick play handling in
MPEG2TransportFileServerMediaSubsession::pauseStream():
void MPEG2TransportFileServerMe
Hi.
Any news on h.264 trick play? I am sure that many would be happy to see any
progress on this.
Thanks
On Tue, Dec 14, 2010 at 11:36 AM, Ross Finlayson wrote:
> 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-backwa
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
Hi Ross,
I'm working on the trick play support for a ts file with h264 video. I
changed the method parseFrame of the class
MPEG2IFrameIndexFromTransportStream. Do you think this is enough or I need
to change the server-side implementation of seeking and fast forwarding
capabilities? I have the ts
l-boun...@ns.live555.com
[mailto:live-devel-boun...@ns.live555.com] On Behalf Of Vincenzo Terracciano
Sent: lundi 29 novembre 2010 16:32
To: live-de...@ns.live555.com
Subject: [Live-devel] TRICK PLAY H264
Hello,
i need to support trick play of a H264 ts files in my Audio/Video
distribution system. So
Hello,
i need to support trick play of a H264 ts files in my Audio/Video
distribution system. Somebody can help me?
Best regards.
--
ITS S.p.A.
Vincenzo Terracciano,
Via Terragneta 90, 80058 Torre Annunziata(NA)
+39 081 53
1/can you please let me know when you plan to support trick play on
MPEG4 and possibly WM9 streams ?
No.
2/Do you plan some pre-encryptor in future to deliver VOD assets ?
No.
--
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/___
live-
Dear Sir,
1/can you please let me know when you plan to support trick play on MPEG4
and possibly WM9 streams ?
2/Do you plan some pre-encryptor in future to deliver VOD assets ?
http://www.live555.com/mediaServer/#trick-play
'Trick play' functionality
The server supports RTSP 'trick play' o
The file is parsable for I frames and actually the indexing works.
The index file (.tsx) is approximately the same size as the clear
.tsx file and the stream captured during trick play testing seems to
be about the right size but looks like it does not have the
transport stream scramble codes s
The file is parsable for I frames and actually the indexing works. The index
file (.tsx) is approximately the same size as the clear .tsx file and the
stream captured during trick play testing seems to be about the right size but
looks like it does not have the transport stream scramble codes se
'Trick play' on Transport Streams works by extracting video I-frames
from the data, and streaming those only. To do this, the indexing
mechanism has to first parse the MPEG video data within the Transport
Stream, to figure out where the data for each I-frame begins and ends.
Therefore, if the
Trick play of clear streams by re-pidding
video to 0xe0 (as suggested in other posts) works OK for a number of MPEG2
transport streams we have been testing with.
I am interested in trick play of scrambled/encrypted content as produced by
typical conditional access or DRM systems.
Normal playou
Thanks Ross. I appreciate the sample.
-Andrew
- Original Message
From: Ross Finlayson <[EMAIL PROTECTED]>
To: LIVE555 Streaming Media - development & use <[EMAIL PROTECTED]>
Sent: Wednesday, July 18, 2007 9:29:45 PM
Subject: Re: [Live-devel] trick play errors - po
>Mainly, what I'm saying is that the live555 trick play code may be
>correct, and VLC just can't handle the generated ts streams properly
Note that the following Transort Stream file
http://www.live555.com/osbournes.ts
works OK (indexing and trick play). So you might want to check to
se
>Mainly, what I'm saying is that the live555 trick play code may be
>correct, and VLC just can't handle the generated ts streams properly
Maybe, but note that Transport Stream files from other sources don't
seem to have this problem. If your hypothesis is correct, then there
is something speci
Ross,
I am not sure of this, however I think this may be the problem with the trick
play. I don't know if this helps or not, but just wanted to alert you to this.
What seems to be happening is that when I play the dvd2.ts file the PCR is
advancing beyond the PTS of frames to be displayed by VLC
>*** MPEG2TransportStreamFromESSource.cpp 2007-07-01 11:16:05.0 +0200
>--- MPEG2TransportStreamFromESSource.cpp.new 2007-07-06
>18:45:01.0 +0200
>***
>*** 251,256
>--- 251,258
>
> fInputBufferBytesAvailable += frameSize;
>
>+ fParent.fPresentationTime =
2007/7/6, Ross Finlayson <[EMAIL PROTECTED]>:
>Hi everyone,
>
>I have a problem in trick play mode to play a TS resource by an RTSP
>session ...
>
>I have modified openRTSP to send PLAY with scale = 2.0
Are you using the latest version of the code (version 2007.07.01)?
That version fixed a bug
>Hi everyone,
>
>I have a problem in trick play mode to play a TS resource by an RTSP
>session ...
>
>I have modified openRTSP to send PLAY with scale = 2.0
Are you using the latest version of the code (version 2007.07.01)?
That version fixed a bug specifically related to scale == 2.0
> and I
Hi everyone,
I have a problem in trick play mode to play a TS resource by an RTSP session
...
I have modified openRTSP to send PLAY with scale = 2.0 and I have realized
that timestamps are always the same value
After a deep study I have realized that:
When MPEG2TransportFileServerMediaSub
38 matches
Mail list logo
