Determining movie length from .d2v

[SansGrip]

I did a few searches but didn't come up with anything. Perhaps I was using the wrong keywords.

Anyway, I was wondering how one would go about discovering the movie length (in seconds or frames or whatever) from the .d2v file itself.

Also, is the frame_rate value always actual rate * 1000?

[Nic]

Hi Sansgrip,

Its been discussed in the development forum a couple of times. the numbers ( all the 0's 1's 2's & 3's ) correspond to the rff & tff flags. If the number is 1 or 3 then it will have the repeat field flag.

As MPUDecoder suggests, counting all the numbers up but count the 1's & 3's as 1.5 would be pretty accurate.
(or count it in fields i.e. each 0 or 2 would be 2 fields and every 1 or 3 would be 3 fields & divide by two at the end)

(the two numbers before the series of trf flags are the lba (the file offset divided by 2048) & the file number (if using multiple files)

Hope thats some use :)

Cheers,
-Nic

ps
A bit of messy code taken from my rewrite of dvd2avi:

int rff = info->display_picture->nb_fields-2;
int tff = ((info->display_picture->flags & PIC_FLAG_TOP_FIELD_FIRST) == PIC_FLAG_TOP_FIELD_FIRST);
int trf = (tff << 1) + rff;


The trf is the number stored in the d2v file.

pps
Yes the frame rate is always * 1000 to make it an integer in d2v script

[SansGrip]

Its been discussed in the development forum a couple of times.

Ack, didn't think of that forum :rolleyes:.

As MPUDecoder suggests, counting all the numbers up but count the 1's & 3's as 1.5 would be pretty accurate.
(or count it in fields i.e. each 0 or 2 would be 2 fields and every 1 or 3 would be 3 fields & divide by two at the end)

I figured it would involve something like this. I think I'll go with the latter and keep it all ints.

Hope thats some use :)

Perfect, thanks :).

[SansGrip]

As MPUDecoder suggests, counting all the numbers up but count the 1's & 3's as 1.5 would be pretty accurate.

Alas, it isn't. With my test material, which is 98% forced film, mpeg2dec via Avisynth reports 137,356 frames. This method gives me 171,698.

Counting all the flags gives me a pretty close approximation, though, with 137,652. Incidentally, this seems to be the same approach FitCD uses, since its "stream length" estimation is out by an identical amount when you convert that to hours/mins/secs.

While this close is probably good enough, will the algorithm fail on interlaced material? Would I be able to get a closer figure by calling mpeg2dec? How does mpeg2dec calculate the frame count -- by checking the vobs?

Edit: Alternatively, could I get the same information through the VFAPI interface? I've never checked that stuff out, but the thought just popped into my head so I thought I'd ask ;).

(the two numbers before the series of trf flags are the lba (the file offset divided by 2048) & the file number (if using multiple files)

From what I can see there are three numbers before the flags, with the third being in hex...?

[trbarry]

Alas, it isn't. With my test material, which is 98% forced film, mpeg2dec via Avisynth reports 137,356 frames. This method gives me 171,698.

But which number do you want? The MPEG2DEC number is probably 20% lower reflecting the fields you told it to drop by turning on Force Film in DVD2AVI to decimate properly to 24 fps.

- Tom

[Nic]

Yes Tom is correct I think....

The other number is almost always 7 & just means its an I Frame. Until a 9 is called meaning end of file...

-Nic

[SansGrip]

But which number do you want? The MPEG2DEC number is probably 20% lower reflecting the fields you told it to drop by turning on Force Film in DVD2AVI to decimate properly to 24 fps.

Mmm, good point :).

So if I use the count-the-fields method, and force film is disabled, then frames = fields / 2. If force film is on, then frames = fields / 2.5.

This works on the figures I gave, which fills me with joy :D, except it's out by two frames:

343396 / 2.5 = 137358.4

(Avisynth reports 137356). Did I read somewhere that you have to subtract 2 from the final count, for some reason?

[SansGrip]

Just an update for anyone searching on this topic in future...

I obtained an exact (i.e. matches what Avisynth reports via mpeg2dec) frame count with the following method:

1) Extract Field_Operation value
2) Count the field flags using the method Nic described above
3) frames = fields / 2
4) If Field_Operation is 1 (force film mode), frames = frames * 0.8
5) frames = frames - 2

I'm still not sure why the final step is necessary, but the FitCD source does it too (even though it actually counts the frames incorrectly, which is why it's always out by a few seconds with NTSC forced film material).

[Nic]

Vlad had mentioned that step before too...strange huh? Glad you got there in the end :) So you going to let us in on why you needed it ? ;)

Cheers,
-Nic

[SansGrip]

Vlad had mentioned that step before too...strange huh?

Very. Bug in DVD2AVI?

So you going to let us in on why you needed it ? ;)

heheh sure. I wrote a GUI wrapper for the "file size prediction" method (http://www.kvcd.net/forum/viewtopic.php?t=1294) developed over at the KVCD forums, whereby you use SelectRangeEvery to pull out 100 one-second-long samples over the entire movie then encode at various CQ settings to determine a good value for your desired target size. Turns out much quicker and nearly as accurate as n-pass.

I wanted the GUI to extract running time information from the source material, hence needed to parse .d2v files. It also has a wizard to help find the correct CQ setting, which usually gets very close after three-to-five iterations.

If anyone's interested you can read the thread (http://www.kvcd.net/forum/viewtopic.php?t=1729) :).

[Black Hole]

@ALL:

Well, it's been discused sometimes in Doom9 forums that DVD2AVI had an error because it doesn't generate the full length and misses some (always 2 ??) frames at the end of the D2V file. This could lead to a serious problem when we want to recreate seamless video scenes from a DVD motion menu, in order to recompress them with a lower bitrate. As CCE or TMPGEnc cannot decompress MPEG-2 video themselves, we must use frame servers like AviSynth and mpeg2dec with a D2V feed.

The problem comes when we need exact and accurate frames, since the last 2 frames of a main movie may be skipped, but not when we join sources or make seamless action menus.

For example, let's suppose I rip a full menu VOB (VIDEO_TS.VOB or VTS_01_0.VOB) and generate a D2V file out of it. Then I use VOBrator to accurately split each VOB ID, taking the different menus apart. If I generate D2V files out of every single cell, and compare them to the bigger D2V file generated before, you can easily spot the difference.

I made a test by cutting 30 seconds of video in Maestro, making a chapter poing every 6 seconds, thus making a cell every 150 frames (PAL 25 fps). I generated several MPV files with 1,2 or 3 cells, provided I knew the exact number of frames. This time DVD2AVI generated different files that were off by 1 frame (unless '9' marker isn't just an EOF and it does mean the 'last' one) ... but when I loaded a pass-through AVS script into VirtualDub, mpeg2dec.dll was just providing 147/297/447 frames instead of 150/300/450 !!!

I can achieve the very same results with IfoEdit parser. If I extract GOP structure for TMPGEnc to import, it includes the full scheme of the last GOP, while DVD2AVI does not.

It looks like DVD2AVI misses the last frame and MPEG2DEC misses the other 2 frames, but I can be wrong. My test just shows 3 frames off, but I cannot check where do they went to (/dev/null) since I haven't tested another MPEG-2 decoder. Maybe I could test MPEG2DEC2.DLL or MPEG2DEC3.DLL ... Has anyone checked these kind of behaviours?

Looks like a typical error in the exit condition of a parsing loop because of a bad EOF check ... or maybe I'm just saying nonsenses because I don't have the source code ... but the questions are: where is the problem? will anyone fix this? Nic? ;)

Greetings.

[trbarry]

(unless '9' marker isn't just an EOF and it does mean the 'last' one

I was already wondering about this because of the Avisynth forum thread today about MPEG2DECx bugs. I haven't confirmed yet that DVD2AVI is off but it sure does look like MPEG2DECx drops either 2 or 3 fields. Maybe the '9' is really just supposed to be a flag with 0x08 turned on? Is it always 9 or is it sometimes 8 or 10 (x'A'?)

- Tom

[Nic]

It actually comes down (I think) to the way dvd2avi reorders the frames. I wrote a d2v creator that found each frame & used the temporal reference to reorder the pictures. This worked fine mostly apart from at the end of file(s)...

Never could work out exactly why the normal dvd2avi missed the odd frame or two off at the end but it did as far as I could tell (one time im sure it missed off a whole I Frame, but I cant remember exactly)

In the end I used maven's code that does it exactly the same way as DVD2AVI. Ill post my code for both methods of creation if it will help anyone (or just wait till I release the new dvd2avi_nic, which shouldnt be too far away)

Cheers,
-Nic

ps
Thats not to say that mpeg2dec isnt clipping two frames off the end...I still havent checked that yet.

[unkown]

Hi everybody!

I was searching for a method to compute m2v file length and I found this thread,started reading but I lost myself between frames and fields.First of all,where are located the rff & tff flags in a m2v file?I know where bitrate and framerate are,but not these ones.

Thanx

[hakko504]

Originally posted by unkown
Hi everybody!

I was searching for a method to compute m2v file length and I found this thread,started reading but I lost myself between frames and fields.First of all,where are located the rff & tff flags in a m2v file?I know where bitrate and framerate are,but not these ones.

Thanx You'll find those embedded with every frame (which consists of two fields, one top and one bottom) in the stream. The easiest way to get hold of them is to open the M2V in DVD2AVI, save a project file, and look inside the project file. Then look at the DVD2AVI FAQ Q08 (http://forum.doom9.org/showthread.php?s=&threadid=59272) for interpretation of the D2V file.

[unkown]

Hi hakko504!

I found that by counting every picture header secuence (0x00000100) in a m2v I get the number or frames (a 'great discovering',isn't it :D ).But sometimes it is not accurate for measuring the length in frames of the file (that must be you all were talking about IFRAMES,BFRAMES,...I begin to understand) but,let's suppose that my file pointer is over the picture header (0x00000100):where is the bit or bits that tell me that picture's type (I,B,P...)? I know that the correspondence is the following IFRAME=1,PFRAME=2,BFRAME=3,DFRAME=4 but I ignore where to find this value in the bits of the file.

Thanx and sorry for this stupid questions!

[Guest]

Your questions about MPEG-2 syntax are answered in the MPEG-2 video specification. It is available at my web site (see below) in the Library section.

[unkown]

Thank you neuron2! I searched the whole web looking for MPEG2 specifications and fields,and it is not easy to retrieve any information about MPEG2 video files.I will have a look to your web site. Bye and thanks again!