Plugin to load VOB / Mpeg2 directly

[Jacquers]

Hi,

Is there a plugin to load vob / mpeg2 directly?
I need something that will load quickly without the need for a d2v file. It's basically just for preview purposes. For encoding I'm still going to use d2v & MpegSource.

Here's what I have already tried:

- DirectShowSource: it chokes on big vob files, especially if you apply autocrop.

- Mpeg2Source("movie.d2v"), and it works well, except I'm looking for a quick preview.

- LoadVFAPIplugin("c:\name_plugin","VOBsource")
VOBsource("d:\filename.vob") - also takes long to create gop list.

- MpegDecoder.dll: also needs to create d2v before showing...

I think I have seen a plugin on neuron2's site, but it was experimental, and couldnt find dl link.

Any ideas?

[Guest]

If you are going to use Mpeg2Source() for encoding anyway, what is the problem with just generating the D2V file, as you are going to need to do that anyway?

A plugin has to support the GetFrame(n) method, where n is the frame number. How do you propose to implement this without an index?

[Jacquers]

I'm working on a small GUI for myself, just for fun, but who knows where it may end up...

Was looking for a quick preview option to load it before starting the whole encoding process & maybe seeing how crop will turn out. Creating the d2v file takes too long for a quick preview, but is the best way for encoding.

[Guest]

I don't know of any Avisynth plugin that does what you want. One could be made that is not frame accurate but guesses the right place to start decoding in the stream. But to do even that you'd need to at least know how many frames there are in the stream. Then you could implement GetFrame(n) by calculating the index into the stream and decoding one frame starting there:

index = (n * total_stream_size) / number_of_frames

The problem is that you have to parse the entire stream first to determine the number of frames. So you might as well generate the index first.

[Jacquers]

Thx, was afraid that that was going to be your answer.

Didnt you or someone else write an experimental VobSource plugin once that could load vob directly?

[Guest]

No, because it can't be done (unless you have some brilliant idea that I have missed).

You're not taking on board my technical point.

There's no way to implement GetFrame(n) without parsing the whole file. An Avisynth filter must implement GetFrame(n).

If this were possible, it would have been done long ago.

[Jacquers]

Ok, was being hopeful... Thanx for your time in explaining

[Jacquers]

Wait,

(sorry if I'm wrong, just trying to learn here)

So you say if I could have exact number of frames beforehand it would be possible to make such a plugin? I could get the # of frames from another info app and pass it as parameter? Then what you said in #4 could work? Coz I could compute # of frames with info from MediaInfo etc.

[Guest]

Yes, but it would not be frame accurate. If your script asks the filter for (say) frame 95, you would get a frame close to that one, but not necessarily exactly frame 95.

Just for fun I tried MediaInfo on a VOB. It didn't give me the number of frames but it did give me the playing time: 596 hours! (which is obviously wrong).

You could get the first PTS and the last PTS from the stream and get the playing time by differencing them (assuming the PTS is continuous throughout, which is often not the case). Then you could multiply the time by the frame rate to get the number of frames.

Gspot, however, estimated the number of frames to within 1 frame! I don't know what approach Gspot is using, but I suspect it must use the PTS values.

Finally, you'll have to allow for pulldown, which is going to complicate things immensely. You're going to have to parse the file (or at least some of it) to know if pulldown is present. Gotcha!

[Dark-Cracker]

you could perhaps look in the mpeg2lib project it allow to display a mpeg2 frame, this should be more speed than trying to use an avisynth filter.

PS : which programmation language do you use ?

hope this help.
++

[Jacquers]

I'm using C#. Basically I was just hoping to get a quick preview & autocrop before going to the actual encoding process, but looks like I'll have to take the long route after all...

[hanfrunz]

if don't remember wrong, there once was a discussion here about a filter, that creates the index file in the constructor. You have to wait a few seconds 'till it starts playing, but you don't need to start another app to create the index.

hanfrunz

[Wilbert]

if don't remember wrong, there once was a discussion here about a filter, that creates the index file in the constructor. You have to wait a few seconds 'till it starts playing, but you don't need to start another app to create the index.
Are you refering to MPEGDecoder?

[actionman133]

No, because it can't be done (unless you have some brilliant idea that I have missed).

You're not taking on board my technical point.

There's no way to implement GetFrame(n) without parsing the whole file. An Avisynth filter must implement GetFrame(n).

If this were possible, it would have been done long ago.

So Neuron2, I take it that your DGIndex (which *is* capable of instant access without an index) can't be used with GetFrame (n)... sorry if the answer is obvious, but my coding experience is limited to user-defined script functions...

[Guest]

DGIndex works like this...

When the track bar is moved to a new position, the position is X and the trackbar entire width is W. So you then position to this offset in the stream:

offset = (X * total_stream_size) / W

Then you decode and display one frame starting from that offset.

Compare that to the idea I gave above for implementing GetFrame(n):

index = (n * total_stream_size) / number_of_frames

Both of these methods are NOT frame accurate. In DGIndex, there is no way to seek to and display a given frame number. (You could step frames one-by-one from the beginning but that is equivalent to parsing the entire file up to the desired frame.)

[Squished]

So Neuron2, I take it that your DGIndex (which *is* capable of instant access without an index) can't be used with GetFrame (n)... sorry if the answer is obvious, but my coding experience is limited to user-defined script functions...

I think you and Neuron2 are coming at this from totally different perspectives. You want an easy way to jump to *roughly* the right time in a movie, and Neuron2 is trying to get across the fact that... well... you can't without indexing. You might get close 80% of the time, but the other 20% you will be nowhere near where you think you should be. Using byte position would be good enough, for say, thumbnailing a movie, but not much else.

Most VOBs these days are VBR, so say you have a movie that has a little action in the beginning, but has a LOT of action toward the end. More bits are expended toward the end.

If you jump into the middle of the VOB based on byte count, you won't be in the middle of the movie time-wise. You will be more toward the end than the middle.

Nevermind the issue that MPEG doesn't store frames in sequential order, timestamps are rarely correct across an entire VOB, and, ohh gawd, telecine flags.

You could probably get within 15 frames (1 GOP) +/- by parsing the IFO though.

[actionman133]

Well I figured DGIndex was frame accurate (my assumption). I was thinking that somehow DGIndex's "perfect" access method somehow unavailable or incompatible with AVISynth. However, since neither are, then my whole point is invalid.

lesson learnt. :cool:

[Mug Funky]

wasn't there an MPEGsource by nic that sort of fudged it? it was in no way frame accurate, but would be fine if played from the beginning (if you supplied an argument that stated how many frames there were).

[unskinnyboy]

Indeed (download page (http://nic.dnsalias.com/mpegdecoder.html)). But like Mug Funky said, it has issues with frame accuracy (especially with MPEG-1).

This is perhaps what Jacquers was looking for, since it doesn't need a d2v file. It will create one on the fly and use it. But note that when decoding NTSC films, it used to decode as if force film was always on. Don't think this was ever fixed. (at least not as of v2.03 since this is a documented bug. Check the documentation).

[Guest]

>since it doesn't need a d2v file. It will create one on the fly and use it

Duh. If it doesn't need an index, why does it create one and use it? :)

There's no advantage to it because the OP does not want to wait for an index to be created. Otherwise, he'd just generate one with DGIndex.

[unskinnyboy]

>since it doesn't need a d2v file. It will create one on the fly and use it

Duh. If it doesn't need an index, why does it create one and use it? :)

Sorry if I wasn't clear. What I meant to say was that, it doesn't need a previously made index.

You could do an MPEGSource("myfile.d2v") or an MPEGSource("myfile.vob"). In the case of the former, it would work just like MPEG2Source. In the case of the latter, it would check for a myfile.d2v in the source directory. If found, it would use that and if not, it will create one and use it.

There's no advantage to it because the OP does not want to wait for an index to be created. Otherwise, he'd just generate one with DGIndex.
Oh, ok, then there is no point. Some amount of waiting is inevitable. :-/

[actionman133]

Sorry to go off on a tangent here, but I'm curious. Does this also mean that all of our DVD players (hardware and software alike) also cannot guarantee frame accuracy? Do they just guesstimate their position if you were to seek a new spot in the timeline?

[Guest]

You never ask a DVD player to go to frame N. You do have navigatable points that are defined in the IFO file. For software players with timelines, they use the DGIndex-like method.

[actionman133]

Thanks neuron2, I understand it better now.

[IanB]

For streams with reliable PTS data, we could take the approach used by DirectShowSource(convertfps=true).

i.e. PTS[n] = PTS[0] + n / FrameRate
Then binary chop the file looking for close to PTS[n] then roll forward in the GOP until the frame with the best "timecode" for frame N.

And of course as the stream is decoded an index could be built on the fly so any reseeking could in fact be exact.

Other options to steal from DSS could be Seek=False or SeekZero=True.