DGMPGDec 1.0.12 released!

[quinn]

Not a big thing - but when using CLI mode, there doesn't seem to be a way to get the avs file. I find that feature quite handy, from a lazy point of view!
Thanks

[len0x]

Say you have a file to (auto)open which contains "-TN" in it. It gets picked up correctly, but as it is an option for audio track then actual -TN option is not picked up correctly. Shouldn't anything between "[...]" not be considered an command line options?
(dunno how easy to fix this though)

[Cyberia]

Originally posted by Nic
@neuron2: Is the source code for the latest version available anywhere for download? Just want to check how easy it is to add decryption code as a plugin...

Cheers,
-Nic

Nic, the 1.3.0 source code is available, and it did have an option for using the OpenDVD decrypting plugin. However, Don removed that ability to be 'street legal'.

[Guest]

Originally posted by Nic
@neuron2: Is the source code for the latest version available anywhere for download? Just want to check how easy it is to add decryption code as a plugin...
Hi Nic. I'll upload the code for 1.0.6 tomorrow.

[dtv_user]

Hi neuron2;

Don I was wondering how DGIndex gets it's time stamps from the ATSC streams.

I know if you strip the null packets from the streams some ATSC capture boards have trouble playing back the strams through their internal decoders.

How are the time stamps allotted in multiple PID ATSC streams?

I was wondering if this might causing be some of the delay issues we are seeing.

Thank you

dtv_user

[Nic]

@neuron2: Cool :) , actually, no rush. Think I've come up with a solution... (going to globally hook CreateFile and ReadFile so can do decryption on a global basis)

[dtv_user]

Hi neuron2;

Don the question I was trying to get to on my last post is how does the mux rate affect time stamps?

Dvd mux rate is lower than most ATSC streams and does this affect the constant you are using for converting the time stamps?

Also some of my time stamps appear to be negative numbers, is this a factor in math operations.

Thank you
dtv_user

[Guest]

Originally posted by dtv_user
Don the question I was trying to get to on my last post is how does the mux rate affect time stamps?

Dvd mux rate is lower than most ATSC streams and does this affect the constant you are using for converting the time stamps?

Also some of my time stamps appear to be negative numbers, is this a factor in math operations. I don't have the answers yet on your questions. I am still investigating this whole area. Thank you for pointing out these possibly relevant considerations.

Regarding the negative timestamps. That is not correct. I'd appreciate you posting a link to a short transport stream fragment that produces this effect.

[dtv_user]

@neuron2

Don I am internet deprived in my area and only have access to 28.8k dialup connection - almost impossible to upload and clips wortwhile.
I could send you a CD by snail mail if required.

The clips I have are recorded seinfeld show from Orlando Florida area WB18 station.

They definitely show negative time stamps in status window when saving D2V file.

I was wondering if the PCR value show be adjusted because we are demuxing these streams from a ATSC muxed stream of about 19.3 mps mux rate.

Thank you
dtv_user

[Guest]

Originally posted by dtv_user
I was wondering if the PCR value show be adjusted because we are demuxing these streams from a ATSC muxed stream of about 19.3 mps mux rate. It's more likely that I have a signed integer somewhere where I should have unsigned. If I can't find one I'll ask you to mail the stream. Thanks.

[dtv_user]

@neuron2

Don I don't think it is anything particular to your version as the time stamps also show up negative in Nic's version of DVD2Avi with transport streams.

I just recorded some more clips this morning from this same WB18 station and they are also negative time stamps.

I have 2 different capturing cards and 1 settop box with firewire, I think the capturing program probably has a lot to do with the stream format.

My accessdtv card used to have non-standard packet headers with the orginal drivers that came with the card. (0x47 & non-standard 0x72 & 0x29) This was some kind of copy protection scheme they were using to make it hard to decode streams.I read this in Ben Cooley's bcdmux.cpp program source code.He also notes accessdtv files are not packet aligned if this helps any.

Thanks again
dtv_user

[dtv_user]

@neuron2

Don I just reinstalled the fusionII card I have but removed because I didn't like.

The captures with this card on the same WB18 station don't have the negative time stamps like the accessdtv card does.

Like I stated earlier the files probably have a lot to do with how they are captured.

Thanks again
dtv_user

[Guest]

@dtv_user

It should never show a negative PTS, no matter how it is captured!

[Guest]

Here's a point release for Zep:

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

I added error checking and graceful termination for when the last picture is incomplete. It (hopefully) no longer crashes VirtualDub on exit. So you shouldn't need to use a Trim(), although you may still want to, since that last coded frame (which might not be last in display order!) probably won't look very good.


__________________
Donald Graft
Filters for Avisynth and VirtualDub
http://neuron2.net

[Zep]

Originally posted by neuron2
Here's a point release for Zep:

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

I added error checking and graceful termination for when the last picture is incomplete. It (hopefully) no longer crashes VirtualDub on exit. So you shouldn't need to use a Trim(), although you may still want to, since that last coded frame (which might not be last in display order!) probably won't look very good.


__________________
Donald Graft
Filters for Avisynth and VirtualDub
http://neuron2.net


YES!!! I will test ASAP


the audio sync problem is a time waster but is easy to offset and sync it up later
but coming home from work only to find the end of pass 1 crashed well...


GRRRRRR........



yes i will still use trim if there is a chance the last frame might not be last
in display order. As long as no crash though I'm happy :D


A huge


Thanks!

[dtv_user]

@neuron2

Don could you explain how audio offset is derived for us?

I see in your source code the expression (AudioPTS-VideoPTS)/90
and was wondering how the constant 90 came into play.

Thanks for your help
dtv_user

[dtv_user]

@neuron2;

Don I removed the /90 and chaned output variables in your getbit file that prints the delay in the file name to check varibles being used.

sprintf(szBuffer, "%s AC3 T%02d %sch %dKbps DELAY %daudio %dvideo.ac3", szOutput,AC3_Track+1,AC3ModeDash[ac3[AC3_Track].mode],AC3Rate[ac3[AC3_Track].rate], AudioPTS, VideoPTS);

Maybe I'm crazy and doing something wrong, but I'm getting negative numbers here.

Check it out
dtv_user

[Guest]

Originally posted by dtv_user
I see in your source code the expression (AudioPTS-VideoPTS)/90
and was wondering how the constant 90 came into play. PTS timestamps are in units of 90 kHz, so dividing by 90 normalizes to milliseconds.

[dtv_user]

@neuron2

Don is my basic math logic flawed or is (AudioPTS - VideoPTS) indicating we would be adjusting video delay whereas (VideoPTS - AudioPTS) we would be adjusting audio delay?

With DVDs the delay was small and maybe not noticed whereas some of the ATSC streams have larger difference in the time stamps.

Has this been a misunderstanding from the beginning with Jackei's program indicating DELAY but not indicating what was being delayed?

Still searching
dtv_user

[Guest]

Presentation units with lower PTS numbers play earlier. So, if (AudioPTS - VideoPTS) is negative, that indicates that audio is playing early and should be delayed. Thus, (AudioPTS - VideoPTS) is the audio adjustment with negative meaning delay and positive meaning advance. If you wanted to view it as the video adjustment with opposite signs, you can do that. :)

Presentation units with lower PTS numbers play earlier because their time to play is reached earlier.

BTW, you have the source code for 1.3.0. That has some signed variables for PTS that have been corrected in DGIndex 1.0.7. Are you getting negative PTS values with the latter?

[dtv_user]

@neuron2

Don 107 gets rid of the negative time stamps display in the status window.

Would you have a link to source code so I could download?

Thanks in advance
dtv_user

[Guest]

I'll post the source code tonight.

[dtv_user]

@neuron2

Don I think I now understand what you are saying about audio delay.

If DgIndex shows a minus DELAY this means I should actually add
audio frames to the audio file.

I was under the impression if it was minus I should cut audio frames.

Thanks for your great insight
dtv_user

[Zep]

Originally posted by neuron2
Here's a point release for Zep:

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

I added error checking and graceful termination for when the last picture is incomplete. It (hopefully) no longer crashes VirtualDub on exit. So you shouldn't need to use a Trim(), although you may still want to, since that last coded frame (which might not be last in display order!) probably won't look very good.
[/url]

so far so good. Four test clips encoded, no crash but it will take
about 10 tests to be sure because unlike the audio problem
which happens 90% of the time. The crash problem was more like
25% of the time since the last frame is good more often than not.

So far though me VERY pleased :D


great work DG! thanks!

[Guest]

Originally posted by dtv_user
Would you have a link to source code so I could download? Source code for 1.0.7 now available:

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

[tedgo]

I have a little problem with the newest 1.0.7-Build:
When creating a project from VOB's, VirtualDubMOD sometimes freezes during encoding the last 1 to 3 frames!
This "Bug" (?) happened in 2 from 6 projects i've tested now.
Returning to DGMPGDec 1.0.6 solved the problem and the projects created with 1.0.7 works fine now. So it must be a problem of the recently made changes.

[Guest]

Can you cut the end of the final VOB and make it available for inspection. VOB splitter is one option.

[Zep]

Originally posted by neuron2
Here's a point release for Zep:

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

[/url]


sending you some streams now that DGindex has major problems with


Auto pid dection fails (might be other problems but
I haven't had a chance to take a close look yet)


the pids are in decimal


VIDEO MPEG2(pid=512)...AUDIO LPCM(pid=650) SUB DVx(pid=650) PROGRAM N. 0

VIDEO MPEG2(pid=519)...AUDIO MP2(pid=720) NO SUBS (yet)! PROGRAM N. 0

[tedgo]

Originally posted by neuron2
Can you cut the end of the final VOB and make it available for inspection. VOB splitter is one option.
Sorry, but i only have a 56k-modem and no webspace and i don't know, how to make it available for you :( .
But i noticed that this problem occured only with interlaced PAL-Material detected as NTSC-FILM 100% (as a matter of course not set to "Forced FILM") by DGIndex from the DGMPGDec 1.0.7-Package until now.
'Cos it is possible to create a d2v-project with 1.0.7 from such VOB's, which is playable and decodeable with 1.0.6, i suspects the DGDecode.dll included in DGMPGDec 1.0.7 causing the problem. Are there any changes in it since 1.0.6?

[len0x]

Originally posted by tedgo
I have a little problem with the newest 1.0.7-Build:
When creating a project from VOB's, VirtualDubMOD sometimes freezes during encoding the last 1 to 3 frames!
This "Bug" (?) happened in 2 from 6 projects i've tested now.
Returning to DGMPGDec 1.0.6 solved the problem and the projects created with 1.0.7 works fine now. So it must be a problem of the recently made changes.

Confirmed - it happened to every single encode I did so far...

Don, one of the sample sources is that TS Faith Hill clip provided by Wilbert, if I'm not mistaken.

[tedgo]

Ouch!
Now i tested a normal PAL-Video-Trailer and got the same problem!:(
So it's not only a problem with interlaced PAL-Material.

[aketon]

I've got the same problem with the new verion 1.07! Virtualdub and avs2avi are freezing at the last few frames!:scared:

[len0x]

It seem to be a bit of a hassle to deal with TS from CLI as GUI for instance autodetects that its a TS based on extension and CLI only deals with TS if you supply PIDs, otherwise you get garbled output. Is it possible to consider input files as TS in case a known extension used?

[Guest]

Originally posted by len0x
Confirmed - it happened to every single encode I did so far...

Don, one of the sample sources is that TS Faith Hill clip provided by Wilbert, if I'm not mistaken. I cannot recreate any failure with this clip. Please reconfirm it and explain exactly what you are doing to create a hang, the version of all tools used, etc.

Folks, I need a stream that causes it. Somebody please provide one.

[Guest]

OK, I've found a VOB that causes it!

Very strange. I'll get right on it.

I'll also add raw PID detection as I am seeing more streams without PAT/PMT tables. That's the cause of your problem, Zep.

Please stick with 1.0.6 until I get this sorted out.

[len0x]

Originally posted by neuron2

I'll also add raw PID detection as I am seeing more streams without PAT/PMT tables.

Btw, is DGTable app is in synch with the code from DGIndex? (as I'm planning to use DGTable).

[Guest]

Originally posted by len0x
Btw, is DGTable app is in synch with the code from DGIndex? (as I'm planning to use DGTable). Yes. But you may want to wait for the raw PID detection.

I've fixed the hanging problem. I'm going to add raw PID detection and make your CLI change and then make a release later today.

[len0x]

Originally posted by neuron2
Yes. But you may want to wait for the raw PID detection.


Indeed, I do :)

Originally posted by neuron2
I've fixed the hanging problem. I'm going to add raw PID detection and make your CLI change and then make a release later today.

Sounds great! 10x!

[Guest]

Version 1.0.8 is released as follows:

* Fixes hangs at end of stream.

* Using CLI, transport parsing is now enabled based on the file extension as for GUI loading.

* DGIndex now has a raw PID detection capability (no CL version yet).

* Transport Stream Notes document updated.

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

[Guest]

Originally posted by len0x
Indeed, I do :)
I've not added raw to DGTable (it's not a table!). How would that be useful to you to have a CL version of the raw detection?

[len0x]

Originally posted by neuron2
I've not added raw to DGTable (it's not a table!). How would that be useful to you to have a CL version of the raw detection?

I'm not that familiar with transport streams yet, but do they mostly have 1 audio stream or not? I'm sort of in need of preseting a user with a choice of what to process (in some form), so having raw detection in DGTable would be real plus.

But for a start CLI raw mode would be nice as well.

*Edit* Btw deadlock is indeed fixed with 1.0.8!

[len0x]

Ok, I've played around with raw PID detection and it works very nice!
Ideally when launched from CLI this option should set Video and Audio PIDs to the first found (Can you tell if that's a video or audio PID? - at the moment DGIndex only shows ID without other info).

[len0x]

I'm looking at that Faith Hill clip (1920x1088) and it seems to me that its perfect widescreen source, which has AR 1:1 (or may be 4:3 actually in terms of DDGIndex value). But it gets written into D2V as 16:9 which means anamorphic source (and therefore width has to be streched by 1.33). Is this improper mastering of TS source or DGIndex issue?

[Guest]

Originally posted by len0x
I'm looking at that Faith Hill clip (1920x1088) and it seems to me that its perfect widescreen source, which has AR 1:1 (or may be 4:3 actually in terms of DDGIndex value). But it gets written into D2V as 16:9 which means anamorphic source (and therefore width has to be streched by 1.33). Is this improper mastering of TS source or DGIndex issue? Lenny, don't you read the ISO specs? :p

That field is the Display Aspect Ratio (DAR). To get the SAR, use:

SAR = DAR * (height/width)

So, for FaithHill10.ts

SAR = (16/9) * (1080/1920) = 1

Quod erat demonstrandum. :D

ISO specs are on-line at my web site in the Library section, if you ever need any light reading.

I suppose you'd like the SAR displayed and recorded as well, huh?

[len0x]

Originally posted by neuron2

So, for FaithHill10.ts
SAR = (16/9) * (1080/1920) = 1
Quod erat demonstrandum. :D

Now I remember. :)
This brings me to another request - can you store dimensions of the source in D2V file? That would solve all my problems!

[Guest]

Originally posted by len0x
Now I remember. :)
This brings me to another request - can you store dimensions of the source in D2V file? That would solve all my problems! For you, anything! It will be in the next version.

[len0x]

Originally posted by neuron2
For you, anything! It will be in the next version.

Thanks a lot! Only because of DG tools I'm moving into TS area with AutoGK :)

[Guest]

Here, len, try out 1.0.9. It has Picture_Size now. The old Picture_Size is now called Clipping. :)

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

[len0x]

Originally posted by neuron2
Here, len, try out 1.0.9. It has Picture_Size now. The old Picture_Size is now called Clipping. :)


Great, I'll have a go with it.

P.S. Call me Tony :)

[zettai]

hmmm does 1.0.9 we're tangibly close to having unsampling support or is that wishful thinking? :)

[btw, great work so far... I can't really help out as I have no knowledge of transport streams]