Stepping backwards in an MPEG file
Weeb
but stepping back seems to be an issue. Obviously MPEG was not exactly
tailored to do this, but is there a filter out there that will allow this.
Currently am using SetPositions(..) to step back one frame, but the renderer
only seems to show changes when I step back enough to hit a key frame. I
would expect that the decoder is the responsible one in such a case. Is
there a filter out there that will do this, or do I have to find my own way?
How can this be done?
Jeremy Noring
news:211F4942-AC64-42EE...@microsoft.com...
> Currently am using SetPositions(..) to step back one frame, but the
> renderer
> only seems to show changes when I step back enough to hit a key frame. I
> would expect that the decoder is the responsible one in such a case. Is
> there a filter out there that will do this, or do I have to find my own
> way?
> How can this be done?
There isn't a filter that I know of, and if there were it would have a lot
of performance issues.
Simply put, codecs don't function well backwards. To go backwards, you have
to read in the previous keyframe, read in all of the frames up to the frame
you actually want, and then output that final frame to the video renderer
for display--so to see a single frame, it's possible you'd have to render
tens/hundreds of frames, depending upon your keyframe interval and the
location of the frame you want relative to the previous keyframe.
I ended up reading only keyframes when in reverse, because it's
computationally prohibitive to actually render every single frame going
backwards while using any modern codec.
WMP also only reads keyframes in reverse, if I'm not mistaken.
--
Where am I going?
And why am I in this handbasket?
Dave August
'Backwards' and is used for creating frames in reverse.
Loosely speaking 'B frames' are like 'P frames' going the other way. Most
MPEG editing programs put out B frames for intermediate work, but <sigh>
strip them when you do a 'Final Cut'.
--.- Dave
"Jeremy Noring" <some...@thenet.com> wrote in message
news:eUGKETYi...@TK2MSFTNGP12.phx.gbl...
Alessandro Angeli [MVP::DigitalMedia]
> Correct UNLESS the MPG was written with 'B frames'. The
> 'B' stands for 'Backwards' and is used for creating
> frames in reverse. Loosely speaking 'B frames' are like 'P
> frames' going the
> other way. Most MPEG editing programs put out B frames
> for intermediate work, but <sigh> strip them when you do
> a 'Final Cut'.
You really didn't get the meaning of B-frames. The B,
according to the ISO standard documents, stands for
bidirectionally predicted, that is delta-frames that depends
on *both* a previous and a successive frame (either I or P
frames). The B-frames make reverse playback even harder,
because of their nature, and not easier and are not an
editing feature: either the stream is encoded with them or
not. B-frames are used to lower the required bitrate with
respect to the use of IP-only sequences and not for reverse
playback.
MPEG-only players can play in reverse because the know what
dependencies the IBP sequence has and they usually skip
B-frames and only decode P-frames, since a P-frame does not
require all the intervening frames after the previous
I-frame to be decoded. Genereric playback frameworks like
DirectShow have no such knowledge about the IBP sequence,
since it is very specific of MPEG1/2 and MPEG4/(A)SP withot
GMC, and can thus in no way replicate this MPEG-specific
behavior.
--
// Alessandro Angeli
// MVP :: DigitalMedia
// a dot angeli at psynet dot net
Geraint Davies
It should be possible to do this with SetPositions. The splitter should
jump back to the previous key frame, but the first frame to appear at the
decoder should be the requested frame. It's not exactly efficient,
obviously, but it is possible. If it's not working for you, the filter I
would be suspicious of initially would be the splitter you are using.
G
Gilad Walden
key frame interval is short (for example, a key-frame each 60 frames or
less), the result is quite satisfactory and there is no noticeable
performance problem.
Gilad.
Jeremy Noring
news:exLlhrZ...@TK2MSFTNGP15.phx.gbl...
> Correct UNLESS the MPG was written with 'B frames'. The 'B' stands for
> 'Backwards' and is used for creating frames in reverse.
> Loosely speaking 'B frames' are like 'P frames' going the other way. Most
> MPEG editing programs put out B frames for intermediate work, but <sigh>
> strip them when you do a 'Final Cut'.
Like Alessandro said, B-Frames don't make reverse playback easier--they make
it even more difficult.
If these sort of advanced playback features are required of an application,
I don't think I'd recommend any codec that uses any sort of predictive
frames, since they make seeking, playing in reverse, and editing of video a
royal pain in the butt. Much easier to deal with in a raw format, or some
sort of compression that doesn't involve predictive frames (like MJPEG).
The tradeoff for using an efficient codec is the ease of working with raw
video frames (which don't rely on previous or future frames).
Weeb
"Gilad Walden" wrote:
I was under the impression that I needed to find a decoder that was capable
not a splitter, but I took your advice and started to use the microsoft
MPEG-2 Demultiplexer and it is working somewhat. The problem I have now is
how to know where to seek to. It seems that the filter only supports
TIME_FORMAT_MEDIA_TIME which sounds easy enough, but I can't simply step back
a constant number, it seems like the times vary from frame to frame.
Also, I am using the Sample file source to write a source filter and I can't
get it to connect to the demultiplexer filter, my file seems to work with the
regular file source filter, but not the sample. I know this has been covered
on here before, but I can't find a good answer besides the negotiations don't
work.
Alessandro Angeli [MVP::DigitalMedia]
> I was under the impression that I needed to find a
> decoder that was capable not a splitter,
It's the splitter's task to provide the right frames to the
decoder, the decoder will just decode whatever it is thrown
at it, as lomg as it is valid.
> but I took your
> advice and started to use the microsoft MPEG-2
> Demultiplexer and it is working somewhat. The problem I
> have now is how to know where to seek to. It seems that
> the filter only supports TIME_FORMAT_MEDIA_TIME which
> sounds easy enough, but I can't simply step back a
> constant number, it seems like the times vary from frame
> to frame.
VBR streams can not be reliably seeked into because there is
no relationship between time and byte offsets. You would
need a frame index, but plain MPEG files do not have one.