| Author |
Message |
Tobia Quantrill
Guest
|
 Posted:
Fri Oct 15, 2004 12:38 pm Post subject:
Indexing |
|
|
I have one problem and one question.
First, the problem:
I have a wmv file - one video stream (720x576 - PAL), and one audio stream
(48kHz, 16 bit, stereo), 8Mbits. Entire file size is slightly over 6GB. File
is properly indexed by frame number, so I can use SetRangeByFrame() function
while reading with sync reader. I've tried several trim-in and trim-out
positions with SetRangeByFrame() function, and most of them work fine. But,
on certain trim-in and trim-out values, something bad happens. After calling
SetRangeByFrame() while retrieving the first frame (GetNextSample()), HDD is
very busy for a few seconds, after that virtual memory usage jumps to 2GB,
and starts to decrease by 1MB per second. I didn't wait for it to reach the
0, I just terminated the entire process.
Can anybody tell me why is that happening??
And, the question is:
In order to be able to seek on a frame, one has to index the wmv file, while
direct show can retrieve any frame from non-indexed file. Why is that so?
thank you...
|
|
| Back to top |
|
 |
Chris P. [MVP]
Guest
|
| Posted:
Fri Oct 15, 2004 5:46 pm Post subject:
Re: Indexing |
|
|
Tobia Quantrill wrote:
| Quote: | I have one problem and one question.
First, the problem:
I have a wmv file - one video stream (720x576 - PAL), and one audio
stream (48kHz, 16 bit, stereo), 8Mbits. Entire file size is slightly
over 6GB. File is properly indexed by frame number, so I can use
SetRangeByFrame() function while reading with sync reader. I've tried
several trim-in and trim-out positions with SetRangeByFrame()
function, and most of them work fine. But, on certain trim-in and
trim-out values, something bad happens. After calling
SetRangeByFrame() while retrieving the first frame (GetNextSample()),
HDD is very busy for a few seconds, after that virtual memory usage
jumps to 2GB, and starts to decrease by 1MB per second. I didn't wait
for it to reach the 0, I just terminated the entire process.
Can anybody tell me why is that happening??
And, the question is:
In order to be able to seek on a frame, one has to index the wmv
file, while direct show can retrieve any frame from non-indexed file.
Why is that so?
|
I've seen the above problem when the audio and video stream go out of sync,
or one of the streams (i.e. audio) is not quite right. I wasn't working
with files quite that big, but with files of a few hundred meg of compressed
video seeking would take anywhere from 5 to 60 seconds and cause a spike in
CPU and memory usage and file IO went sky high. It appeared as though the
source filter had resorted to a sequential read because the pointer in the
index didn't land in the correct location.
DirectShow cannot seek on a non-indexed wmv file. At least it never worked
when I tried it. |
|
| Back to top |
|
|
Tobia Quantrill
Guest
|
| Posted:
Sat Oct 16, 2004 6:21 pm Post subject:
Re: Indexing |
|
|
"Chris P. [MVP]" <msdn@chrisnet.net> wrote in message
news:%23rpxA1rsEHA.2128@TK2MSFTNGP11.phx.gbl...
| Quote: | Tobia Quantrill wrote:
I have one problem and one question.
First, the problem:
I have a wmv file - one video stream (720x576 - PAL), and one audio
stream (48kHz, 16 bit, stereo), 8Mbits. Entire file size is slightly
over 6GB. File is properly indexed by frame number, so I can use
SetRangeByFrame() function while reading with sync reader. I've tried
several trim-in and trim-out positions with SetRangeByFrame()
function, and most of them work fine. But, on certain trim-in and
trim-out values, something bad happens. After calling
SetRangeByFrame() while retrieving the first frame (GetNextSample()),
HDD is very busy for a few seconds, after that virtual memory usage
jumps to 2GB, and starts to decrease by 1MB per second. I didn't wait
for it to reach the 0, I just terminated the entire process.
Can anybody tell me why is that happening??
And, the question is:
In order to be able to seek on a frame, one has to index the wmv
file, while direct show can retrieve any frame from non-indexed file.
Why is that so?
I've seen the above problem when the audio and video stream go out of
sync,
or one of the streams (i.e. audio) is not quite right. I wasn't working
with files quite that big, but with files of a few hundred meg of
compressed
video seeking would take anywhere from 5 to 60 seconds and cause a spike
in
CPU and memory usage and file IO went sky high. It appeared as though the
source filter had resorted to a sequential read because the pointer in the
index didn't land in the correct location.
|
The A/V sync is ok in the whole file, and retrieving the first frame
(GetNextSample()) after SetRangeByFrame() is instantaneous in the whole
file, except for some trim-in and trim-out positions, when GetNextSample()
blocks and as I said, virtual memory usage jumps to 2GB.
You mentioned filters here. I don't use DirectShow at all - too much
overhead for my kind of application, and I don't know if DS is reliable for
24h usage.
Anyway, I guess there is a bug in WMF library for indexing, although I might
be wrong.
| Quote: | DirectShow cannot seek on a non-indexed wmv file. At least it never
worked
when I tried it.
|
I tried that. File wasn't indexed by frame number or timecode, and I was
able to retrieve any frame. Hm, you said that it never worked for you - I'll
try it again, just to be shore.
|
|
| Back to top |
|
|
Chris P. [MVP]
Guest
|
| Posted:
Sun Oct 17, 2004 5:52 am Post subject:
Re: Indexing |
|
|
Tobia Quantrill wrote:
| Quote: |
The A/V sync is ok in the whole file, and retrieving the first frame
(GetNextSample()) after SetRangeByFrame() is instantaneous in the
whole file, except for some trim-in and trim-out positions, when
GetNextSample() blocks and as I said, virtual memory usage jumps to
2GB.
|
Could be a bug.
| Quote: | You mentioned filters here. I don't use DirectShow at all - too much
overhead for my kind of application, and I don't know if DS is
reliable for 24h usage.
Anyway, I guess there is a bug in WMF library for indexing, although
I might be wrong.
|
DS is as reliable as the filters that are running in the graph. We have DS
apps that run 24/7 without any issue.
| Quote: | DirectShow cannot seek on a non-indexed wmv file. At least it never
worked when I tried it.
I tried that. File wasn't indexed by frame number or timecode, and I
was able to retrieve any frame. Hm, you said that it never worked for
you - I'll try it again, just to be shore.
|
Could be a difference using the WMF library directly. We created some files
using WMF but playback always using DS. DS didn't let us seek until the
file was indexed, and this was also apparent from other DS players, perhaps
WMF has some tricks for frame access of a non-indexed file but me thinks it
would be slow on large files. What is the actual stored format of the video
data?
-Chris |
|
| Back to top |
|
|
Tobia Quantrill
Guest
|
| Posted:
Mon Oct 18, 2004 11:15 am Post subject:
Re: Indexing |
|
|
"Chris P. [MVP]" <msdn@chrisnet.net> wrote in message
news:OLU9iv%23sEHA.1308@tk2msftngp13.phx.gbl...
| Quote: | Tobia Quantrill wrote:
The A/V sync is ok in the whole file, and retrieving the first frame
(GetNextSample()) after SetRangeByFrame() is instantaneous in the
whole file, except for some trim-in and trim-out positions, when
GetNextSample() blocks and as I said, virtual memory usage jumps to
2GB.
Could be a bug.
You mentioned filters here. I don't use DirectShow at all - too much
overhead for my kind of application, and I don't know if DS is
reliable for 24h usage.
Anyway, I guess there is a bug in WMF library for indexing, although
I might be wrong.
DS is as reliable as the filters that are running in the graph. We have
DS
apps that run 24/7 without any issue.
DirectShow cannot seek on a non-indexed wmv file. At least it never
worked when I tried it.
I tried that. File wasn't indexed by frame number or timecode, and I
was able to retrieve any frame. Hm, you said that it never worked for
you - I'll try it again, just to be shore.
Could be a difference using the WMF library directly. We created some
files
using WMF but playback always using DS. DS didn't let us seek until the
file was indexed, and this was also apparent from other DS players,
perhaps
WMF has some tricks for frame access of a non-indexed file but me thinks
it
would be slow on large files. What is the actual stored format of the
video
data?
|
720x576, 25fps, codec - Windows Media Video 9 Professional at 8Mbps |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in