DGMPGDec 1.2.0 RC5

[Guest]

Originally posted by bob0r
Is it possible to sync the .mpa file with DGMPGDec?
It's on the development list but has a low priority. Is it so hard to set the offset in nandub?

[Guest]

@zeus163

Up to a couple hundred meg is fine. I don't care where or how you get the file. All I care about is that I can duplicate your issue using it. Please put it up there soon so I can work on it when I get home.

[Guest]

@cw_uk

The information is all the same, but is more readable. I didn't print the VOB cell id either, because I think it is useless for what DGParse is used for.

[Guest]

@zeus163

I was hoping to work on this tonight. Any chance?

I'd really like to release 1.2.0, but can't while your issue is hanging fire.

[zeus163]

Its got another 45 minutes or so. The clip is 150 megs or so and FlashFXP shows that I'm at 53% complete.

I'm sorry it took so long to get to this. Since the grandparents were watching the kids tonight, it was date night for an early Valentines. As soon as I got home I got to this.

I also included a text file with some info for you. If you have any questions there is an email in there you can use.

I hope this gets there soon enough!

[Guest]

Thank you, zeus163. I'll get right on it.

[Guest]

@zeus163

That sure was an interesting issue. Your stream is extremely weird but you did uncover a real problem. The stream now has a home in the "Weird" subdirectory of my test file suite. :)

Your stream has no GOP headers, at all! That's legal of course. But the stream also doesn't use the temporal reference field properly.

I try to get the temporal reference of the first I frame. But now I realize that it should be the first I frame after a GOP header, because the GOP header resets the temporal reference to 0. So I do that now. Also, if there is no GOP header, I then do not use the temporal reference adjustment in the delay calculation.

While this gives me a delay of -404ms now for your stream, I'm still concerned that your stream does not use the temporal reference field properly, i.e., it doesn't increment for each frame in display order until reset by a GOP header, as required by the MPEG2 spec. And it has large values like 0x268. That won't throw me off, unless a GOP header comes along and the next I frame has a bad temporal reference. I do check for the value to be reasonable (less than 18), and I don't use it if it isn't. The worst thing that can happen is that the delay value given is wrong or absent, but this will occur only for illegal streams.

I'll put up an RC4 shortly with this change.

[loni_blues]

I know the difference in audio delay between tracks demuxed with FF and those without it is really small, but which value should we trust for muxing?
Regards

[Guest]

Originally posted by loni_blues
I know the difference in audio delay between tracks demuxed with FF and those without it is really small, but which value should we trust for muxing?
Regards There is no difference in RC4. I was using the FF adjusted frame rate when I should have been using the MPEG2 encoded frame rate. :)

Thank you for pointing out that issue.

[Guest]

Here's RC4. The only change is to the delay calculation as described. I also included the 1.2.0 DGVfapi.vfp.

http://neuron2.net/fixd2v/dgmpgdec120rc4.zip

I sure would like to release this today or tomorrow. ;)

[loni_blues]

I am getting audio delays of -66ms in 2 tracks demuxed from the same vob with rc4 when I used to get different values of 0ms and 66ms with rc3 and no ff. Is this to be expected?

[zeus163]

I'm glad that my weird stream was of some help. I seem to recall that somebody once wrote streams with no GOP headers can't be opened properly in Project X. Which would explain why I couldn't open that stream up in that program or open it up properly to cut out commercials. I now think that several HD stations that I receive send out their streams without any GOP headers. But with your work, I should be able to handle that problem now. Thanks for taking the time to look at that file I sent you. I appreciate it.

I will try the latest version out today when I do another cap from the same station. I'm going to guess that the stream will have no GOP headers as well.

thanks!

[Guest]

Originally posted by loni_blues
I am getting audio delays of -66ms in 2 tracks demuxed from the same vob with rc4 when I used to get different values of 0ms and 66ms with rc3 and no ff. Is this to be expected? Without seeing the stream, I can't tell you what is expected. Do the delays appear correct?

You know where my FTP server is. Hint, hint.

[zeus163]

@neuron2

I ran RC4 on the complete .ts file that I started with. I used the delay value that it came up with on the .ac3 file and it worked perfectly when I muxed it back with the encoded file.

Thanks a bunch!

[Guest]

@zeus163

You're welcome. Thank you for the feedback. It makes it all worth while for me.

[Guest]

Originally posted by zeus163
I seem to recall that somebody once wrote streams with no GOP headers can't be opened properly in Project X. Which would explain why I couldn't open that stream up in that program or open it up properly to cut out commercials. I now think that several HD stations that I receive send out their streams without any GOP headers. Interesting. Fortunately for us, DGIndex spits out a new "GOP line" at each I frame, otherwise the limit of 499 pictures would have killed us. The real limit is 499 frames between I frames.

[Boulder]

Hi Don,

I just tested RC4 and noticed that the delay is incorrect for my MPEG2 -captures. The delay reported for the original clip was -124ms, in earlier versions it's -44ms. The delay for the cut sample file (see below) is -80ms but it's still way off.

I'd say the delay should be closer to zero for both clips although it's hard to determine. Nevertheless, -124ms and -80ms sound off to my ears, the audio runs too early.

I uploaded a sample clip to my webspace as I couldn't log on to your FTP site.

http://www.saunalahti.fi/sam08/delayclip.mpg

[Guest]

@Boulder

Greetings from the quantum vacuum!

Ha, ha, I had already fixed that in my local build in preparation for release. It gives 0ms for the uploaded clip.

Try this one:

http://neuron2.net/fixd2v/dgmpgdec120rc5.zip

[Boulder]

Thank you, Sir, will try it ASAP:)

The wonders of hybrid NTSC->fieldblended PAL conversion..grr

[Boulder]

A bugreport from elsewhere : the filter BlindPP() doesn't work anymore. When you load a script with BlindPP() in VDub, it just vanishes. Also it probably has the same postprocessing bugs that MPEG2Source() had.

Just thought I'd report it since some people are using it, not me though:)

[Guest]

Woe is me. It fails in the release build but not in the debug build. :(

Back to printf's.

[wolfsoft]

When would vfapi update?

[Guest]

@wolfsoft

I don't understand your question. DGVfapi is in the RC5 zip file.

[quinn]

Using the latest version (RC5) - I have a VOB file that has a 15 second delay on the audio.

DGIndex does not add ANY information about delays in the name of the ac3 file that is extracted.

Using a different vob with 0-second delay, everything is fine...

Same thing happens with RC3.

[Guest]

If it is greater than 5 seconds, DGIndex does not report it, the idea being that something is dreadfully wrong.

[Boulder]

I have one DVD where the delay is really very long, over 8 seconds IIRC. It's Evil Dead, Elite Entertainment's release and the massive delay is on Bruce Campbell's commentary track. I don't know why they didn't just use silence instead:confused:

[len0x]

A user reported normal delay of 23 sec here:
http://forum.doom9.org/showthread.php?s=&threadid=90039

[Guest]

I'll just report whatever it calculates, then.

[len0x]

Those delay calculations seem to be pain in butt, aren't they?

[LigH]

The reason for those huge delays may be:

At the beginning, there is audio only in audio stream 0 (the first, probably english audio stream) during the playback of a publisher trailer (e.g. Columbia TriStar, Warner Bros., ...).

After the end of this trailer, all the other audio streams start where they have to start to achieve synchronity in their respective languages.

I'm not sure why this works at all; maybe at the end of the trailer, a cell command kicks in which switches to the selected audio stream; maybe the player simply plays the first stream as long as there is no audio in the selected one (although I rather doubt that)...

[Spyn]

hi,

why dgindex (1.2.0 RC5) show "interlaced" in "frame type" for a lot of my movies that are not interlaced at all ?

framerate is also wrong for some movies : dgindex show 20 fps but the movie is 25 fps

sorry for english :D

[len0x]

I have a feeling that % of FILM calculation after d2v format was changed is slightly off... I used to rely on that number to calculate total number of frames in D2V and now in some rare cases (haven't traced them yet) I seem to miss the mark somehow. Or may be the way frames are represented has changed? Previously I had to discard first 4 numbers in a D2V line to get number of frames in a GOP (and that always worked OK), now I'm discarding 6. Anything wrong with that?

[Guest]

Originally posted by Spyn
why dgindex (1.2.0 RC5) show "interlaced" in "frame type" for a lot of my movies that are not interlaced at all ? Because that is what the MPEG stream is saying about the frame.

framerate is also wrong for some movies : dgindex show 20 fps but the movie is 25 fps Probably you have force film set inadvertently.

[Guest]

Originally posted by len0x
I have a feeling that % of FILM calculation after d2v format was changed is slightly off... I used to rely on that number to calculate total number of frames in D2V and now in some rare cases (haven't traced them yet) I seem to miss the mark somehow. Or may be the way frames are represented has changed? Previously I had to discard first 4 numbers in a D2V line to get number of frames in a GOP (and that always worked OK), now I'm discarding 6. Anything wrong with that? It hasn't changed.

Yes, you skip the first 6 now.

[Guest]

Originally posted by Boulder
A bugreport from elsewhere : the filter BlindPP() doesn't work anymore. When you load a script with BlindPP() in VDub, it just vanishes. When support for 4:2:2 was added the developer neglected to make the QP_store array big enough for that. I fixed that. I assume you had the problem only with YUY2, because I couldn't make it fail with YV12, and the YV12 code looked fine.

Also it probably has the same postprocessing bugs that MPEG2Source() had. No, because they both call the same functions. The only difference is that BlindPP() creates a quant array out of whole cloth.

I will now close this thread as 1.2.0 has gone final. Thank you very much to all posters who contributed bug reports and suggestions. Your collective perspicacity is an important, nay, indispensible, ingredient in the success of our tools.