Quick Seeking in a MPEG file

[dinesh]

Hi,
I am using the libmpeg2 library (VC++) for developing a MPEG viewer/player.
I was just wondering if anyone knows a good way of doing a
seek to a specified point in a MPEG1/2 system file. One way is
seeking the SCR and PTS and seeking the 0x000001b3 -> 0x000001b8 -> 0x00000100 headers in that order. But given a file and specified time, it would take a while before I reach the desired point,using the above approach.
I have tried creating a index of timestamps and it works. But I want to avoid this step too.
Trying to guess the file position based on timestamp would not be proper for VBR files.
Would someone be able to give a better/quicker method or approach?

Another question is related to seeking within a MPEG Video stream.
How do I seek to a specific frame number instantly (well almost - without having to count frames from the beginning )?

Thanks in advance,
Regards
Dinesh

[Guest]

You have to make a best guess and then use a binary search to home in.

MPEG does not carry a global frame number so there is no alternative to counting. *IF* there is a PTS for every picture (as there is for some satellite streams), you could use that coupled with the method of the first paragraph.

Avisynth filters that allow random access, such as mpeg2dec, use pre-built GOP index tables and count from the beginning of a GOP. Some other tools build their own indices when the file is loaded.

[dinesh]

Thanks for the response, neuron2. I guess thats the way even Directshow does it.
Thanks.

[fccHandler]

Originally posted by neuron2
MPEG does not carry a global frame number so there is no alternative to counting. *IF* there is a PTS for every picture (as there is for some satellite streams), you could use that coupled with the method of the first paragraph.
If you parse the beginning of the stream and derive the PTS for the first frame, then in theory you can jump into the middle of the stream and calculate the exact frame number at any location relative to the first frame. Any frames which lack an explicit PTS can be derived from a nearby frame which does have a PTS, because the spec requires them every 0.7 seconds at least.

In practice it's a lot more complex than it sounds, because of the packetized nature of the video stream, and the out-of-order frame coding. To date I've never been able to write anything that can do it, but it's definitely on my wish list.

Furthermore, if you can parse the end of the file and derive the PTS of the last frame, then you should be able to derive the total number of frames without the need to count them. Maybe a solution for the mysterious missing frames of DVD2AVI?

[dinesh]

Just a thought.
Getting the last PTS to determine the length of the stream may not work on some streams (particularly vobs - say some video_ts.vob). PTS gets reset within the stream. Looks like we still have to run thru the whole stream and analyze it.

[Guest]

Originally posted by dinesh
Just a thought.
Getting the last PTS to determine the length of the stream may not work on some streams (particularly vobs - say some video_ts.vob). PTS gets reset within the stream. Looks like we still have to run thru the whole stream and analyze it. Good point.

[Guest]

Originally posted by fccHandler
Maybe a solution for the mysterious missing frames of DVD2AVI? I just posted a solution to that. :) Please see the thread in the DVD2AVI forum.

[fccHandler]

Originally posted by dinesh
PTS gets reset within the stream.
Really? I've not seen this, but I don't doubt that it's possible. (There goes my theory...) :(

Originally posted by neuron2
I just posted a solution to that. :)
Thanks! Though I've never encountered the missing frames problem myself (I'm not much of a DVD ripper), it's nice to have a fixed version just in case. ;)

[jfcarbel]

neuron- can you elaborate more on the below statement, that is how are these pre-built GOP tables calulated and what other types of indices are built by other tools.

>>Avisynth filters that allow random access, such as mpeg2dec, use pre-built GOP index tables and count from the beginning of a GOP. Some other tools build their own indices when the file is loaded

Also, when we talk about quick seeking, do we mean when using a slider control to scan thru the movie as it displays frames quickly from the DVD? I like the way the DVDShrink is so responsive to the video preview slider, more so than other apps. At the beginning of a load DVD, DVDShrink shows its scanning the DVD frames and it says analyzing the DVD. Is it most likely that he is building one of these indices you talk about? And is it for the reason of quick seeking via a slider for the video preview.

I am new to this all and would greatly appreciate your thoughts.

[Guest]

Originally posted by jfcarbel
How are these pre-built GOP tables calculated and what other types of indices are built by other tools.I can tell you only about what DVD2AVI does. It opens the file and parses it according to MPEG2 syntax. Whenever an I frame is encountered, the file offset is recorded. A list of digits is also recorded, with one digit per frame. The digits specify the TFF and RFF flags for the frame. This recording I am describing is in fact the D2V file contents, which are well documented elsewhere in this forum. This parsing and recording process is lengthy.

When MPEG2DEC3 (or any other utility that reads the D2V file) decodes the file, it first reads the D2V file and builds an internal table. This process is fast. Then when a request is made to navigate to a particular frame, the table is consulted to determine a file offset to move to using _lseek. I've described in the DVD2AVI forum which frame has to be initially seeked to to ensure that the requested frame is decodable. Finally, MPEG decoding is started and when the requested frame is decoded, it is returned by the filter.

In linear mode, when the frame requested is one higher than the last request, a much simpler method is used for speed: just decode and return the next frame in the stream.

The RFF flags seriously complicate navigation, because you no longer have a one-to-one relationship between encoded frames and displayed frames.

You can find code for all of this at my website.

A final note: For VOBs, an I frame corresponds to the start of a new GOP. So you will see people talking about GOPs instead of I frames in the context of the indexing. But it is really I frames that are indexed.

Also, when we talk about quick seeking, do we mean when using a slider control to scan thru the movie as it displays frames quickly from the DVD? Sure. Any time you want to quickly obtain a given frame, the issue arises.

I like the way the DVDShrink is so responsive to the video preview slider, more so than other apps. At the beginning of a load DVD, DVDShrink shows its scanning the DVD frames and it says analyzing the DVD. Is it most likely that he is building one of these indices you talk about? And is it for the reason of quick seeking via a slider for the video preview.Yes, it is building the I frame access table.

DVD2AVI is as responsive, but it can navigate only to a subset (I am told it is 500 frames maximum) of the I frames in the movie. That is something that could be improved without too much effort.

[jfcarbel]

neuron - thanks for your help. I think I have just about understood what I need to with a few reaffirming questions.

So the slider in DVD2AVI functions as an index into your GOP index table (ie d2v file) which returns an I-Frame for the current position of the slider, thus playback and rendering is quick and responsive since the decoder can quickly uncompress the I-Frame without having to look forward at other frames. Is this correct?

I noticed in many Directshow demos that the slider is sluggish and frames are not instantly rendered, so I have a feeling it is just seeking to a point in the DVD rather than displaying only I-frames. I guess this is neccessary since they don't want to have the user wait a minute before scanning the VOB streams for all the I-Frames.

I think I am getting this all now. DVD2AVI builds an I frame index because if say I requested frame 6 and this is a P-Frame, then the encoder has to now find the I-Frame before that frame and then it needs to look at all the frames in between to actually decode it since each P-Frame just registers its differences from the previous P-Frame. This takes time and would slow the display down to where it would seem unresponsive (which is what DirectShow seeking seems to do).

Here is where I am confused. When I scroll forward in DVD2AVI it moves at either 15 frames or 30 frames each depending if I am using arrow keys or sliders. At first I thought is was just a fixed number that DVD2AVI used, but maybe that is wrong. If it is displaying the actual frame number of the stream than this could be different based on the size of the GOP determined by the encoder who setup the GOP settings.

Are the numbers just because this certain movie has a new GOP occuring every 15 frames. So could it be possible that when I am seeking another movie in DVD2AVI that I could see it move 8 frames each? Also an I-Frame could be manually inserted at points to help encoding complex scenes. So is it also correct to say that I could be skipping along at 15 frames each and then at certain points I may notice that change to maybe ony 6 breifly and then go back to 15 frames?

Or is DVD2AVI just display the I-Frame number that it is on in its display window?

Also why does it take so long to create a D2V file, I know it is recording the frame flags but does that add that much to the processing time? The reason I ask is because DVDShrinks analyze only takes about a minute or 2 for a full DVD and DVD2AVI takes alot more time than that. Could DVDShrink be using a different way to get the I-frame locations or is it pretty much a standard scan of the stream?

I don't think this can be accomplished in DirectShow even if I have a pre-built I-Frame index because DirectShow only allows me to seek forward in number of seconds or HH:MM:SS.Frame. I would assume I would need to be able to move to an I-Frame and the only sure way to do that would be to move to an exact stream position like LBA. Or can I build a D2V file with a frame number in addition to the LBA, but how would I seek to the exact frame a hybrid would contain 29.97 along with 24fps? I noticed your ParseD2V spits out frame numbers. Does it do this by counting those frame flags? With this way could I assume you would count the right number even for hybrids?

[Guest]

Originally posted by jfcarbel
So the slider in DVD2AVI functions as an index into your GOP index table (ie d2v file) which returns an I-Frame for the current position of the slider, thus playback and rendering is quick and responsive since the decoder can quickly uncompress the I-Frame without having to look forward at other frames. Is this correct? More or less. I haven't yet looked at the slider/navigation code but I have been told that the slider has a fixed number of increments, i.e., 500, so it can't access every I frame in the clip if there are more than 500 of them. This area of DVD2AVI could be improved.

I noticed in many Directshow demos that the slider is sluggish and frames are not instantly rendered, so I have a feeling it is just seeking to a point in the DVD rather than displaying only I-frames. I guess this is neccessary since they don't want to have the user wait a minute before scanning the VOB streams for all the I-Frames.It's an implementation decision. When do you want the user to have to wait?

I think I am getting this all now. DVD2AVI builds an I frame index because if say I requested frame 6 and this is a P-Frame, then the encoder has to now find the I-Frame before that frame and then it needs to look at all the frames in between to actually decode it since each P-Frame just registers its differences from the previous P-Frame. This takes time and would slow the display down to where it would seem unresponsive (which is what DirectShow seeking seems to do).Actually, once you can find the GOP start, the actual decoding of any frame in the GOP is pretty quick, even if you have to decode the entire GOP. The speedup comes just from knowing where to seek in the file without having to parse it from the beginning.

Are the numbers just because this certain movie has a new GOP occuring every 15 frames. So could it be possible that when I am seeking another movie in DVD2AVI that I could see it move 8 frames each? Also an I-Frame could be manually inserted at points to help encoding complex scenes. So is it also correct to say that I could be skipping along at 15 frames each and then at certain points I may notice that change to maybe ony 6 breifly and then go back to 15 frames? Yes, GOPs can be of different sizes. Remember, though, the point made above about the fixed number of increments on the slider. This complicates things.

Also why does it take so long to create a D2V file, I know it is recording the frame flags but does that add that much to the processing time? The reason I ask is because DVDShrinks analyze only takes about a minute or 2 for a full DVD and DVD2AVI takes alot more time than that. Could DVDShrink be using a different way to get the I-frame locations or is it pretty much a standard scan of the stream? That is a very good question that I am looking at now. I had noticed that it seemed longer than it needed to be, but your relative timing figures really motivate me now. Thank you for pointing it out. :)

how would I seek to the exact frame a hybrid would contain 29.97 along with 24fps? You have to use the TFF/RFF flags to build a mapping between the requested display frame number and the encoded frame number. Source code for this is available at my website.

I noticed your ParseD2V spits out frame numbers. Does it do this by counting those frame flags? With this way could I assume you would count the right number even for hybrids? Correct.

[jfcarbel]

This looks interesting Moonlight/Elecards player and decoder reads an index stream that they create. I tried there demo program that creates the index and it is also as fast as DVDShrink. Below is an excerpt from their site. Neuron - Maybe this info can give you some hints and they also offer an SDK with a ND agreement for eval.

It is possible to build an index of MPEG file and provide this index to Elecard MPEG2 Demultiplexer. As a result you will get accurate and fast positioining. Download StreamEye (aka Stream Explorer,
http://www.moonlight.co.il/download/) application to see how it works. Indexing samples come with Decoder SDK.

Moonlight MPEG Stream Explorer is based on Moonlight media Index and allows you to display the frames itself, their size, time and position (based on PTS) in the stream, the average bit rate, peak value and declared sequence headers. Moonlight MPEG Stream Explorer, based on index, quickly seeks by frames.

Description
Moonlight MPEG Stream Explorer opens the file, indexes it (or opens already existing index),Index contains the information about frames:
- Type (I frames, B frames, P frames),
- Number,
- Size,
- Offset,
- Time
Index also contains the information about amount of frames, sequence header and GOPs (Group Of Picture).

When opening files containing audio stream, bit rate and the frame size is overstated. Depending on movie bit rate inaccuracy will swing from 1 to 2 percents. For the correct showing it is desirable to explore Video Only MPEGs.

Moonlight MPEG Stream Explorer allows to:

1. Display media stream by frames graphically (I frames, P frames, B frames)
2. Determine the bit rate value in Sequence Header in accordance with the real bit rate value in streams
3. Determine the bit rate peak value and bit rate varies
4. Visually observe the video quality dependency both on a current bit rate within GOP and on a current frame size.
5. Determine the frame location in stream order, in decode order, frame size, frame presentation time STAMP (PTS) and view its picture
6. Account for the minimal, maximal and average frame size in stream.

Deliverables:
Elecard MPEG2 Demultiplexer (DirectShow(r) filter)
Elecard MPEG2 Video Decoder (DirectShow(r) filter)
Moonlight MPEG Indexator (COM)
Moonlight MPEG Index Reader (COM)
Moonlight MPEG Stream Explorer it self application

[jfcarbel]

so it [DVD2AVI] can't access every I frame in the clip if there are more than 500 of themThats odd why not just keep this higher, unless they are doing some buffering then some memory management code needs to be added. I will jump into the code and look at it this week. Also I thought lots of people use DVD2AVI to cut off the credits at the end. If it can only access 500 I-Frames then how do they get to the end of the movie? Unless most movies use less than 500 I-frames.

You have to use the TFF/RFF flags to build a mapping between the requested display frame number and the encoded frame number. Source code for this is available at my websiteWhere on your site is this code? It really intrests me because it seems like a good learning tool to understand the d2v file? I looked in the "Mine" area and could only find the program fixd2v

[Blight]

The most reliable (and as of yet non-existing) DirectShow type decoder could do the following:

At the moment of starting to decode, in the background start building the index file (as you're playing), if someone seeks into a position you already indexed, you use that information. If you don't have the position indexed yet, you do a blind seek (slow and not as accurate).

Right now what seems to be happening is that the directshow filters let the timeline move forward as you're seeking and once they find the position they resume. The thing is, accuracy is screwed up as upto 5-10 seconds may actually pass between the seek position and the point where it actually start showing an image... really bad if you need accurate seeking.

I would like to see someone release a directshow codec based on proper indexing. Or at least a filter that would not keep the timeline moving ahead while trying to find the correct seeking point.

[Guest]

Originally posted by jfcarbel
Thats odd why not just keep this higher, unless they are doing some buffering then some memory management code needs to be added. I will jump into the code and look at it this week. Also I thought lots of people use DVD2AVI to cut off the credits at the end. If it can only access 500 I-Frames then how do they get to the end of the movie? Unless most movies use less than 500 I-frames.It looks like what I was told, or thought I read somewhere, is wrong. Apparently it does have full GOP granularity.

Where on your site is this code? It really intrests me because it seems like a good learning tool to understand the d2v file? I looked in the "Mine" area and could only find the program fixd2v http://neuron2.net/fixd2v/decodefix.html

[DDogg]

Just an observation from a non programmer. Hope nobody minds too much. I just wonder how and why PowerDVD is able to jump around the time-line without hesitation to anywhere in the mpg. No lag, no seeking time to speak of, just seemingly instant playback wherever you click on the time-line, whereas anything else like mplayer, mplayer2, MPC, etc has that huge delay.

[Guest]

VOBs have special data in the stream, such as "navigation packs", that DVD players use. But not all MPEG2 files are VOBs, so pure MPEG2 decoders don't have VOB navigation. It would be interesting to consider enhancing DVD2AVI, et al, to use VOB navigation when it is present in the stream.

[DDogg]

Thanks for the reply and just to be clear I was speaking of playing an CCE re-encoded mpg in PowerDVD. I guess I could understand if it was a VOB, but I have always been surprised that it plays my downcodes so well.

[jfcarbel]

Blight - try Elecard Moonlights DVD Player, it includes a trackbar-like control that allows you to quickly scan thru VOB or mpeg2 streams. It has been the most responsive I have seen of any of the DirectShow based DVD Players. Although, nowhere near as fast as DVD2AVI. Blight - you use the Delphi DSPack for your ZoomPlayer - correct? Did you see my thread for a DVD Programming Toolkit?

DDogg - I have tried PowerDVD and its scanning is not as quick as I would like and it is also probably not very accurate. Most DVD Players like PowerDVD do not offer a trackbar to scan thru the video, rather you are given a control that allows you to click at a specific time on the bar and it starts playing the video at that point. What I am talking about is being able to drag a trackbar/slider back and forth quickly as the video keeps up with it displaying the appropriate frame. To see an example of the type of fast scrolling I want to achieve in DirectShow, look at DVD2AVI. It scrolls the video very fast even without the prebuilt *.d2v index file. The closet I have seen is the Elecard Moonlight DVD Player 2.1

Neuron - just tried DVDShrink again last night and it creates its index even faster than I thought. It was easily under a minute to analyze the DVD. Do you think it is building the index using these VOB only "navigation packs" that you were talking about? Maybe we can ask gnipooldd/ddlooping to ask DVDShrink if he can give us some hints on how he accomplishes this. I know DVDShrink is NOT currently using DirectShow for his video preview, based on what I read in this thread - http://forum.doom9.org/showthread.php?s=&threadid=61530

Neuron - also I noticed that DVD2AVI trackbar is very quick at seeking even without the d2v already built. Does the mpeg2dec3 decoder build some GOP index to allow for this quicking seeking?

I am thinking that a good solution to this problem is maybe a combined DirectShow and mpeg2dec3 video preview window. Where the video and audio could be played using DirectShow. But when the user starts to use the scroll bar, then the video preview is done via the mpeg2dec3 for quick seeking and scanning. Then when the play button is pressed again, DirectShow starts playing from the frame that it gets from where mpeg2dec3 left off at.

The only issue with this is that I need to be able to seek accurately to a frame in Directshow and retrieve the current frame and I am not sure if this is possible or if only some filters support this (Blight?). I would also need to see if I could get the mpeg2dec3 to resize the video correctly if the preview window changes since this code is not built into it.

[Blight]

jfcarbel:
Zoom Player is written in Delphi, but does not use DSPack (too restricting), I do all the DirectShow code directly to the API and not using any pre-built class.

I don't recall a thread about DVD Toolkit.

You can't seek in frames with MPEG2 content under DirectShow, at least not with any decoder I've encountered, they simply don't return a frame rate (since it can be variable) or a frame count. You can only seek to a MS position.

What I would like to see is a DirectShow filter that can acurately seek to an MS position and pauses the timeline till it gets to that position, the fact that the timeline advances as the decoder is searching for the seek position is aweful as it prevents accurate seeking, regardless of the seeking speed. And for some project I'm involved in, I need accurate seeking, even if it takes 2-3 secs to seek.

[Guest]

Originally posted by jfcarbel
Neuron - just tried DVDShrink again last night and it creates its index even faster than I thought. It was easily under a minute to analyze the DVD. Do you think it is building the index using these VOB only "navigation packs" that you were talking about?I don't know yet. I am still investigating.

Neuron - also I noticed that DVD2AVI trackbar is very quick at seeking even without the d2v already built. Does the mpeg2dec3 decoder build some GOP index to allow for this quicker seeking?I do know the answer to this. You're not going to like it. But first, mpeg2dec3 is not involved at all in DVD2AVI's trackbar seeking and decoding. I don't understand why you mentioned that, unless it was just a slip and you meant to say DVD2AVI.

The trackbar has 500 increments. When you move it to a new position, it calculates a file position as follows (it's a little more complicated due to the possibility of multiple files but the basic idea is the same):

position/500 * total stream length in bytes

It then lseeks to that file position (which is very fast) and starts decoding, stopping and displaying the first I frame encountered. That means that with the trackbar, you can display only 500 different I frames, evenly spaced throughout the stream.

With the < and > buttons, however, you can step a GOP at a time. You can see that for a large movie, you have to hit multiple > before the trackbar moves by one increment. You can also try to slide the trackbar by the minimum amount and you see it is much larger than a GOP for large streams.

The idea then is to use the trackbar for gross positioning and the arrow keys for finer navigation. This method is not suitable for random access to a desired frame number. You have to build an index for random access by frame number.

The method may be adaptable to seeking to an MS location, however, because the stream contains timestamps. You could make a gross estimate about file location knowing the length of the stream, and then search around that point looking for the desired timestamp.

Finally, I think this method explains DDogg's observations about PowerDVD.

[Blight]

neuron2:
Now might be a good time for you to make a leap from AVISynth to DirectShow, real-time processing is getting more and more important and your expertese in this field would be much appriciated.

And yeah, finding the nearest timestamp, going backwards till an I-Frame preceding the desired location and then decoding forward till you hit the exact timestamp should be relatively speedy.

Now if only someone write that into a DirectShow filter.

[jfcarbel]

Possible solution for random seeking and quick I-frame scanning of DVD Streams:

It seems what we need is a DirectShow filter that accepts an LBA seek so that we can quickly and randomly jump around the stream. With this type of functionality we could as neuron says build a GOP index which could contain the LBA, timestamp, and frame # of all the I-Frames. Then we could easily use this index to access random frame numbers in an instant.

Would it be possible to just wrapper DVD2AVI's mpeg2dec into a DirectShow filter with an IMediaSeekingInterface that supports a public LBA seek method. I know that someone wrote a DirectShow filter to open a d2v files, but I checked and it does not implement all the Directshow filter interfaces.

From someone who knows more about DirectShow programming, could we implement a LBA seek and still have it play the audio in sync and decode the encrypted VOBs using the DVDNavigator?

I would like to be able to implement a trackbar that would scan instantly back and forth using LBAs while actively displaying the video only. Then when I let go of the trackbar, it begins playing the video and audio at that point. Is it possible to still implement a DirectShow filter to do this?

Basically, on a trackbar event I would pause the playing stream and then seek to LBAs based on the trackbar position and display its nearest I-frame to the DirectShow window. I know a little about DirectShow programming, but could one seek without the stream playing. Maybe we could have two seek methods - one that is an active LBA seek for when the stream is playing and another that would seek a GOP based on a LBA value and just display only that frame to the DirectShow display.

Maybe it is possible to subclass the DVDNavigator and then override or add new new seeking methods. Is this possible to do? I assume the code is unavailable since it decrypts VOBs and its owned by MS.

[gmo]

Hi,

"fast seeking in all kind of mpegs" -> same problem i had while
writing a mpeg video editor. At last i decided to build a
frame index (needed also for frame accurate seeking).
Navigation on such an index is very fast and precise -> best
choise compaired with all other solution.

my coding is for linux only, but the "frame server" part is
standard C++ and may be transfered in a DirectShow filter too.
Building up the index runs with good speed, because scanning
only relevant bytes inside the mpeg files while skipping all
other blocks.

project can be found here:
http://home.arcor.de/gmo18t/lve/

Another linux editor, similar to virtualdub works on index files
(for mpeg) too -> result is a nice and fast navigation, look here:
http://fixounet.free.fr/avidemux/

Another good video editor (for windows) with fast seeking in
mpegs is "Magix Video Studio" - yep, it uses index files...

- GMo -

[jfcarbel]

A DirectShow based preview engine would require DVD Shrink to implement a custom source filter which could deliver decrypted audio/video data to whichever decoders the user has installed. In this case, probably the frame step fwd and bwd buttons would be dropped, but seeking would hopefully be implemented in the same way as current implementation (dvd IFO files contain an index table for each vobu (=GOP) in the VOBS: the current preview engine uses this table for seeking, I don't build a separate index file).

DVD Shrink video decoder is not based on mpeg2dec3 or any other public library. Above is DVDShrinks reply to my question about how he creates a GOP index so quickly. It looks as if he does not create an index but rather uses one stored in the IFO files. This is not a frame index but just a GOP index. I believe that the d2v index created by DVD2AVI is both since it also records the repeat field flags. I am suprised that the DVD specs would not include a frame index in the IFOs to allow for frame accurate seeking. I understand that in the actual stream is a PTS value, which I believe translates to a timestamp. The discussion at top talks about using PTS to do frame accurate seeking, but I was confused by the discussion a bit since I am not all that familiar with this PTS value and its relation to frames.

Also not sure why DVDShrink thinks he needs to drop the frame fwd/bwd buttons, since I think even DirectShow decoders will let you move a frame ahead. Or maybe I am wrong. I just thought the limitation was the ability to seek to a specific frame.

Let me see if I understand this correctly. If we had the frame number of every GOP then we could seek to the nearest frame number in relation to the one we want and then let the decoder seek fwd/bwd XX number of frames to reach our desired frame. This is assuming we have an LBA for each GOP so we can quickly seek to it.

Can someone who is more familiar with IFO files comment where exactly this index table that DVDShrink talks about is stored in the IFOs? Wondering if it stores the LBA values of the GOPs. This way I could use it for my trackbar to quickly scan along the I-frames/GOPs.

[Blight]

I think the whole idea of a directshow mpeg2 decoder is that it does NOT rely on a pre-determined index as most files won't have them. Any index should be created real-time in memory as the file is decoded, as quickly as possible so that it's transparent to the user.

[jfcarbel]

Blight, I noticed ZoomPlayer supports bookmarks. How do you accomplish with DVD? That is what do you use to seek instantly to that point in the DVD and is it frame accurate?

[Blight]

I doubt it's frame accurate. It's done by saving the DVD Navigator filter state (there's some microsoft sample code for doing this) and it's highly touchy (won't work if you switch OS and such).

I'd still like to see a 100% accurate (stop timeline until seek is complete) decoder, even if it's not super fast at doing so. You think you'll be releasing something like that?

[jfcarbel]

I think what you are looking to do is an accurate seek to a frame while the video/audio is still playing - correct?

From what I have read this is not possible with Directshow.

I believe there are 2 options to do a frame accurate seek using DirectShow, someone correct me if I am wrong.

1. While the graph is paused use IMediaSeeking to seek to a specific frame. The DS decoder you use must support frame accurate seeking such as the Elecard filter.

2. Use a pre-built GOP index or for DVDs just parse the IFOs VOBU_ADMAP which contains LBA values for each GOP. I believe the index will also need to keep PTS values and DS timestamp value which can be derived from PTS. Then just do an LBA seek (DS IMediaSeeking by TIME_FORMAT_BYTE - Seeks to a byte in the stream) to the nearest timestamp in the index for the desired frame. That is if frame # can be converted to a DS timestamp. Then decode from the I-frame to the exact frame.

My questions:
Does anyone have a formula to convert PTS value to DirectShow timestamp?
Has anyone used the IMediaSeeking by TIME_FORMAT_BYTE? I could not find any MS examples or good doc on this?

What I want to accomplish I think is different from you:
Bascially I want to do what DVDShrink does, but when the play button is pressed it plays the audio along with the video as well. I want to be able using a trackbar in pause mode to scan instantaneouly thru the only video stream by GOP. Then use the < > buttons to move frame by frame. Then when I hit the play button it resumes playing audio/video from that exact point. I will only be playing mpeg2 streams from a DVD VOBs. I am not sure what I want to do can be
accomplished with DirectShow. I have yet to see a DVD Player based on DirectShow that supports instantaneously scanning via a trackbar. When I looked at the Elecard DVD player it did have options on the GUI interface to switch between it rendering I-frames and all IPB frames, so maybe with this filter I can accomplish what I want. However, to get to know how it works they require you sign an NDA for their commercial SDK.

[Blight]

You can't do that in DirectShow DVD Mode as there are all sort of buffering and commands are queued.

You should be able to play the files in media mode and do accurate seeking...

What "I" want is an MPEG2 decoder with possibly a splitter that will seek accurately (don't need it to be instant, just accurate) and will pause the graph while seeking. This is currently done in AVI seeking, when you seek an AVI file with most of the AVI Codecs, you don't get continued decoding until the seek command completes, the timeline is essentially frozen. This is what I want.