DGMPGDec 1.0.12 released!

[Guest]

As the Zep meister said, we use the file extension to know when to use transport stream parsing. An alternative would be to force the user to set a menu option. What is the consensus out there?

Project X knows he always has transport files, so the issue does not arise for him.

[buzzqw]

Could be helpfull and option in open (or auto add) as: OPEN AS : TS or mpeg1 or mpeg2 or Vob...

Thanks anyway Neuron2

BHH

[Guest]

That's a great idea. Provide a way to override the extension (or lack thereof). Thanks for suggesting it.

[Zep]

Originally posted by neuron2
As the Zep meister said, we use the file extension to know when to use transport stream parsing. An alternative would be to force the user to set a menu option. What is the consensus out there?

Project X knows he always has transport files, so the issue does not arise for him.


Can you autodetect? If not I say setting a menu option
to as an example for me that ALL files are .tp would be
great.


for buzzqw he would set .ts


A menu with all supported types/extensions would also show
everyone that vauble info at a glance. (sure it is in the docs
but right in the app would be great too and solve this problem )

[Guest]

Version 1.0.4 adds MPEG audio demuxing for transport streams.

BTW, I am now interested in getting audio delay detection as good as I can. So, if anyone has any quirks to report in this regard, I'd appreciate your streams for analysis.

BTW2, I found some transport streams never send any video PTS. In such cases, or if the calculated delay is greater than 5 seconds, I suppress the delay calculation from the filename. If you don't see a DELAY figure in your filename, that means I was unable to calculate a reliable one.

BTW3, I found a stream that carried a PAT but no PMT! In such cases, I cannot determine what audio type to decode with on the specified PID, so I just try MPEG audio. This may change to allow manual specification in such cases, but I don't think this is a widespread issue.

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

@CruNcher

I've solved the problems with PVA audio, so you should be seeing support for that soon. :)

[Zep]

Originally posted by neuron2
Version 1.0.4 adds MPEG audio demuxing for transport streams.

BTW, I am now interested in getting audio delay detection as good as I can. So, if anyone has any quirks to report in this regard, I'd appreciate your streams for analysis.




much needed :D


So far sync is off 90% of the time for me.
the AC3 delay value is always way off.
and the decode to wav same problem.

it is fine when the cards app plays the .ts but
for encoding via d2v the audio is always early for me.

around 500ms to 800ms 90% of the time (but it has been as high as 1500ms)


I never get audio that plays late.



Originally posted by neuron2

BTW2, I found some transport streams never send any video PTS. In such cases, or if the calculated delay is greater than 5 seconds, I suppress the delay calculation from the filename. If you don't see a DELAY figure in your filename, that means I was unable to calculate a reliable one.




wow nice gonna DL this sucker right now

[Guest]

@Zep

Please provide test streams for any delay problems you find.

[V_ICE]

Thanks for your great work neuron2. Here is another test stream:
http://demod.dvico.com/hdtv/Australia_1.tp

[Zep]

Originally posted by neuron2
@Zep

Please provide test streams for any delay problems you find.

I'll send more


but everyone i sent you thus far except the ABC stream
has that problem


i will send a clip now


thx

UPDATE: sending 23 meg clip that was about 700ms early on audio.
(well at least that is what i had to offset in VDub to get
it in sync. it does play in sync with the app that came with
myHD card though so something along the chain to encoding
is off on my PC)

[Guest]

Umm, Zep.

When you send me a clip for AV testing there has to be some synced content so I can tell when the sync is right. What am I going to do with a voice-over?

You know, like someone talking where you can see the lips moving. Thanks.

Also, please name streams you refer to. I get a lot of stuff and I can't remember everything you sent me. I mean I still have them in my streams directory, but which came from you???

[JasonFly]

I aslo had problems with delay(only once on 10 d2v files created, and delay was approximately 1700 ms) and it was with decodefix1.30.I haven't tested with the latest version(since 1.30), does any change has been made to delay detection since this version?
I have 20 other d2v waiting with different delays from whath they were with an old DVD2AVI1.77 version.What has been change to make them different? Does changing the d2v fileformat since this ersion can affect the delay value?

Sorry it has been a lot of questions but I'm quite lost with all the different versions of DVD2AVI/DG... that came out.

BTW, thanks for all your work neuron2

[MattO]

neuron2

Re: 'delay detection'

When dealing with .VOB's is the delay value accurate?, or should we rely more on the value reported by DVDDecrypter when using 'stream processing'?

thanks for any info

[Cyberia]

Both of you, read the FAQ! Q17 answers your question.

[len0x]

Originally posted by neuron2
* The Swap Field Order option was removed because it was not functional and doesn't really belong. Also, since it was mutually exclusive with the other field order options, it didn't make much sense to begin with. Use Simon Walters' Reverse Field Dominance filter in your AVS script if you need to reverse the field dominance.


Really? So it never worked then? That's a bummer coz I was running tests based on changing this parameter since the whole community here was sure that it can sometimes fix improper mastered PAL DVDs which appear to be interlaced but with that option switched on - not...

[CruNcher]

@CruNcher

I've solved the problems with PVA audio, so you should be seeing support for that soon.



GReat keep it going :D

[Zep]

Originally posted by neuron2
Umm, Zep.

When you send me a clip for AV testing there has to be some synced content so I can tell when the sync is right. What am I going to do with a voice-over?

You know, like someone talking where you can see the lips moving. Thanks.

Also, please name streams you refer to. I get a lot of stuff and I can't remember everything you sent me. I mean I still have them in my streams directory, but which came from you???

the girl in the car goes uuuhhhh once loud and strong and clear.
It is PERFECT for syncing since sound comes out on an uuuhhh
instantly.

but ok I will have to make a clip now and test it in VDub to see how far off.
I sent that one because I already did the work and knew it was 700ms off.

as for clips

i didn't see any from me on the server and i do not remember the file names.
i will make a new clip that is way off and send that.


The streams have time stamps to keep audio and video in sync.
I mean HDTV watching i get drops now and then like say lightning
strike near by and for 1 second give or take video and audio drop
I get a blocky mess as it rebuilds then everything syncs back up
even though 60 frames worth of data was lost. There is a very good
syncing method being used in the wrapper around the mpeg 2 and
AC3 streams. That is what i was hoping you would look into because
if that is in sync then you do not even need to see lips on screen to try
and judge it for yourself which is hard to do and you could be off by
200ms and it still looks ok. So many times i get the audio close
and i'm not sure if i'm 100ms early or late hahah This is also why i like
to sync to door slams and stuff like that. Some people even leave their
mouth open even though sound stopped coming out!

just watch people yell "HEY!" on screen! they all leave their mouth open
after sound stops coming out :D

(try that one yourself LOL)

[Cyberia]

@zep - Your kidding, right? I can usually eyeball delays to about 10ms if I have a good clip.

[Guest]

Originally posted by len0x
Really? So it never worked then? It never worked with any DG version. Because I re-wrote the pulldown processing and didn't allow for it.

That's a bummer coz I was running tests based on changing this parameter since the whole community here was sure that it can sometimes fix improper mastered PAL DVDs which appear to be interlaced but with that option switched on - not... That doesn't make any sense to me. Can you supply such a clip for my analysis?

[CruNcher]

Neuron2 i have also such *.vobs that showing in the preview in DGindex that they are interlaced but aren't.

If you could give me a upload addy i upload one of those false recognized VOBs

[Guest]

Originally posted by Zep
the girl in the car goes uuuhhhh once loud and strong and clear.
It is PERFECT for syncing since sound comes out on an uuuhhh
instantly. There is no mouth movement with the uh, so I cannot assess the correct sync. Now if you have the crack of a ball hitting a bat, that is ideal. But there are many frames where the uh could have started. You know?

That is what i was hoping you would look into because
if that is in sync then you do not even need to see lips on screen to try and judge it for yourself which is hard to do and you could be off by 200ms and it still looks ok. Sorry Sir, but you are confused. The stream can be encoded wrong such that PTS values are picked up correctly and the delay calculated correctly by DGIndex, but the result isn't correct. So, the delay value can be wrong either because I calculate wrong, or because the encode is wrong. The only way to distinguish them is to have the visual check. And I use the TMPGE audio gap adjust that shows the waveform of the audio, so I am not guessing! With a clear audio-video event, I can check it to one millisecond resolution.

So, please try to provide clips that have clear audio-video events that can be correlated. Talking with lip movement is good. Bat cracks are the best. Thank you.

Just to be clear, I am looking for clips that, when you apply the DELAY correction that DGIndex gives you, are still noticably out of sync. Note that if you get a -DELAY then in VDub you use a -DELAY correction, but in TMPGE, you have to change the sign when you set the audio gap adjust.

[Guest]

Originally posted by CruNcher
Neuron2 i have also such *.vobs that showing in the preview in DGindex that they are interlaced but aren't. That field just shows the value of the progressive/interlaced MPEG syntax field. Often, progressive frames are encoded as interlaced. It is a common mastering error. It is not a DGIndex problem.

[Guest]

Originally posted by JasonFly
I aslo had problems with delay(only once on 10 d2v files created, and delay was approximately 1700 ms) and it was with decodefix1.30.I haven't tested with the latest version(since 1.30), does any change has been made to delay detection since this version?
I have 20 other d2v waiting with different delays from whath they were with an old DVD2AVI1.77 version.What has been change to make them different? Does changing the d2v fileformat since this ersion can affect the delay value?
Yes, the delay calculation has been changed and some bugs fixed. It's not the D2V format version that is relevant but rather the DGIndex executable that demuxs the audio and puts the delay in the filename.

I suggest going ahead with 1.0.4 and let me know if you run into any issues. Thank you.

[Guest]

Originally posted by MattO
When dealing with .VOB's is the delay value accurate?, or should we rely more on the value reported by DVDDecrypter when using 'stream processing'? It all hangs on how you interpret the ISO specs. According to my reading DGMPGDec is accurate. Can you show otherwise?

[NeOff]

When I demux a stream from a file with an open GOP at the beginning, I am not given a delay value, unless I set the start point to another location. not sure if this is a possible bug or not, just thought Id inform.

example:
- open, save project - results in no given delay
- open, right arrow, mark as start, save project - returns delay

[Guest]

Thanks. Actually, the problem arises when the first PTS in the stream is audio and not video. But I know how to fix it.

[len0x]

Originally posted by neuron2
That doesn't make any sense to me. Can you supply such a clip for
my analysis?

It seem to be quite rare case but look what I found: http://forum.doom9.org/showthread.php?s=&threadid=49092
Looks like you were a part of that discussion already :)

P.S. this topic is also covered in famous tutorial by Hakko (PAL section): http://www.doom9.org/ivtc-tut.htm

[Zep]

Originally posted by Cyberia
@zep - Your kidding, right? I can usually eyeball delays to about 10ms if I have a good clip.

A 24 FPS HDTV clip means you are not even reaching 10ms visual accuracy.
24 FPS is just OVER 40ms. :D

You can't sync perfectly when the audio falls in between frames you do not
have and it becomes a slight guessing and opinion game if someone talking
on screen is in perfect sync at 10ms levels. Lets not forget what looks in
perfect sync to you may not to someone else at 10ms levels.

Basically you are claiming if i gave you a clip you could tell on one viewing
it was 10ms off. Unless you did an audio walk and keep nudging 10ms until
you go past then start back the other way i just can't see anyone getting
that kind of accuracy on one viewing with 24FPS/40ms HDTV clips. Heck
even an audio walk i doubt you could be 100% sure if a clip is only 10ms off.

[Cyberia]

Originally posted by Zep
A 24 FPS HDTV clip means you are not even reaching 10ms visual accuracy.
24 FPS is just OVER 40ms. :D

You can't sync perfectly when the audio falls in between frames you do not
have and it becomes a slight guessing and opinion game if someone talking
on screen is in perfect sync at 10ms levels. Lets not forget what looks in
perfect sync to you may not to someone else at 10ms levels.

Basically you are claiming if i gave you a clip you could tell on one viewing
it was 10ms off. Unless you did an audio walk and keep nudging 10ms until
you go past then start back the other way i just can't see anyone getting
that kind of accuracy on one viewing with 24FPS/40ms HDTV clips. Heck
even an audio walk i doubt you could be 100% sure if a clip is only 10ms off.

No, I am walking it back and forth. Finding events in the video that produce a sharp sound and moving the sound back and forth until it feels right. But I am not kidding that I can eyeball a clip to around 10-15 ms after a few tries.

[Zep]

Originally posted by neuron2

Sorry Sir, but you are confused. The stream can be encoded wrong such that PTS values are picked up correctly and the delay calculated correctly by DGIndex, but the result isn't correct. So, the delay value can be wrong either because I calculate wrong, or because the encode is wrong. The only way to distinguish them is to have the visual check. And I use the TMPGE audio gap adjust that shows the waveform of the audio, so I am not guessing! With a clear audio-video event, I can check it to one millisecond resolution.



Of course the stream could be hosed and that is why
i made it a point to tell you it plays fine in ts players
and that drop outs still sync up perfectly in the clips
i sent you.

i also said and i quote


"it is fine when the cards app plays the .ts"


why did you think i mentioned that? :D

Anway...


The ts players are doing SOMETHING DGindex is not and that
was what i was hoping you would look into.


UPDATE: the clip i sent you earlier today plays
perfectly in VLC (VLC plays .ts files) i tested
the clip in VLC on my PC and my mac. So maybe
access to ffmpeg/VLC source code can help figure
out why all these players are in sync but

DGindex --> avisynth ---> VDub (preview or encode)
are so far off


i hope you can figure this one out cause it is the only
grrrr.... i have left with HDTV capping :)



I already Uled a new clip before you even posted
so no need to get into that.

[Zep]

Originally posted by Cyberia
No, I am walking it back and forth. Finding events in the video that produce a sharp sound and moving the sound back and forth until it feels right. But I am not kidding that I can eyeball a clip to around 10-15 ms after a few tries.

ahh well sure i can get real close doing that too (my guess
is around 25ms but closer than that i could never be 100% sure
because what i call sync others may think is off and vise versa)

That is why i brought up audio walking because that was the only
way i could see anyone getting close enough to claim 10ms when
24 FPS is only 40ms.


but that is NOT what i was talking about in the post before
i was talking about the first viewing being way off (700ms)
and adjusting on first try without walking it. :D

[Guest]

@Zep

I don't want to have a debate with you, but the stream does not have a good audio-video event for me to assess the sync. I don't know why you did not respond to this point.

Here it is again in case you care to respond:

"There is no mouth movement with the uh, so I cannot assess the correct sync. Now if you have the crack of a ball hitting a bat, that is ideal. But there are many frames where the uh could have started."

[dtv_user]

Hi neuron2:

Not to throw more full on the fire but I don't understand why Jackei put the audio delay in the file name in the first place rather than extract the audio as it should match with video.

Obviously the players can sync the audio, so the time stamps must be available to be used.

Maybe this would require a second pass of file to extract audio to match with video or some other reason you could enlighten us with.

Just my $.02

Thank you
dtv_user

[Guest]

@dtv_user

I was just wondering the same thing.

When we demux to ES, we lose the timestamps, so if we wish to align things, we would need to delete video frames at the beginning if the audio is late, or add video frames if the audio is early. (Alternatively, we could add/delete audio frames.) But it is not easy to insert/delete frames in an MPEG encoded bitstream.

[dtv_user]

Hi neuron2;

Don I have been capturing ATSC clips with differerent resolutions and from different TV stations, they are all different.

I've been capturing a daily half hour show from WB (Warner Brothers) and the resolution is 1920 X 1080 . I downsize this to 720 X 480 and author to DVD with AC3 audio to archive.

I have a ACCESSDTV computer PCI card and also start my capture 5 minutes early and end 5 minutes late, to get a clean start point.

The time stamps are weird numbers like -5 hours which is probably keyed off some master clock the station uses.

The delay in DVD2Avi (Nic's) and your versions are negative numbers like -481 and such. I have to actually use a positive offset like 1281 to sync audio.

I don't have any way to upload clips to you as my connection is only 31200 on my best days.

I've messed with audio sync quite a bit and one of the problems with saving AC3 audio is the delay number is misleading. AC3 audio for my use needs to be cut on a even frame with 0B 77 header at the start of frame.

People talk about cutting audio to ths ms but most programs I have tried round the AC3 cut to a audio frame start.

I have been loading my audio and video into Mpeg2Schnitt and changing the audio offset to sync,set my starting and ending points, cutting commercials and then saving cut points. Clips can be played in Mpeg2Schnitt to adjust the audio before cutting.

I have made a table of ms verses frame start points so I can control the cut points on AC3 frame header start code (0B 77)and not letting the program round off my offsets.I work in AC3 frame offsets rather then ms.

The request I have from you is to maybe have a way to show video and audio time stamps in the status box when setting starting cut point with slider in DGindex.

If you could have a way to test for alignment of audio frame start header (0B 77) and I frame maybe this could allow for better audio sync.


Sorry for the long post.

dtv_user

[bot]

Any chance of renaming the project to something that looks more similar to dvd2avi? With the combination of DVD2AVIdg and MPEG2DEC3dg, how about dvd3avi?

Apologies if you find this suggestion dumb or offensive.

[zettai]

The program no longer makes avi files, so having any name with AVI in it is just confusing.

[bot]

Ah. (I need more disc space before I can try it). I was just finding DGMPGDec difficult to look for when I'm browsing my directories. Many consonants does not make for good erconomics. But it's a matter of habit too.

[Guest]

I've released Version 1.0.5 as follows:

* Fixed a small bug in random access. If your stream has leading B frames in display order (the infamous GOP warning popup), and you navigate to one of those frames followed by another jump less than 8 frames forward, you'll get the wrong frame.

* The transport parser was not properly parsing video with stream IDs of 0xe8-0xef. The PTS was not being captured although the video ES was delivered, resulting in no audio delay being reported.

* The capability was added to demux audio from audio-only transport streams. To do it, set your video PID to 0.

* A document containing notes on transport stream decoding was added.

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

[dtv_user]

Hi neuron2;

Glad to see your working on audio Don.

I've demuxed the WB(Warner Brother) streams I mentioned earlier with quite a few different demuxers with varing results.

I've used bbdmux, xport, projectx, xmuxer, others and DGIndex.

Bbmux returns the most number of frames and with the clip I am using DGIdex was 49 AC3 frames later from the start of audio.

Projectx gave the best audio sync with these frames using Mpeg2Schmitt to test play after resizing video to 720 x 480. Mpeg2Schmitt won't play the 1920 x 1080 with in sync on my 2.6 P4 PC.

Bbmux returned too many audio frames from the clip and was 17 audio frames out of sync.

It's suprising how different demuxers return different number of frame from the start of clip.

Bbdmux 1.9 doesn't start on a valid AC3 start header (0B 77) when demuxing a transport stream, all the others seem to start with a proper header.

Xmuxer will try to cut the audio to sync with video when it demuxes and works good on my PBS 704 X 480 transport streams.

Keep searching, The truth is out there somewhere.

Thanks again

dtv_user

[Guest]

Point release to add fix that allows TMPGE 3 to open D2V files directly. Also changes the icon for DGIndex.

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

[BruceL]

@neuron2
Thank you for the new updates!
Just curious, is there a reason you achieved a zip of version 105 inside the 106 zip?

[gnr]

i dont get it. which one i should use, i mean which one is latest for encoding dvd to avi for gknot to make avs file? dvd2avidg 1.3.0 (decodefix130.zip) or dgindex 1.0.5 (dgmpgdec105.zip)

[Cyberia]

DGMPGDec v1.0.6 is the latest

[Zep]

Originally posted by neuron2
@Zep

I don't want to have a debate with you, but the stream does not have a good audio-video event for me to assess the sync. I don't know why you did not respond to this point.




i did respond. DG this is the second time i wrote something
and you didn't read it.

First i said and I qoute

"ok I will have to make a clip now and test it in VDub to see how far off.
I sent that one because I already did the work and knew it was 700ms off."



then in my NEXT post i said and I quote


"I already Uled a new clip before you even posted
so no need to get into that."



didn't you read that? i said "no need to get into that"
because there isn't and i do not want to debate this
and made a new clip for you. That second clip has been
on your server for a LONG time.


You really have me scratching my head on all this
because I did as you asked and made a clip like you
said you wanted and ULed it over 24 hours ago. :D




Originally posted by neuron2
Here it is again in case you care to respond:

"There is no mouth movement with the uh, so I cannot assess the correct sync. Now if you have the crack of a ball hitting a bat, that is ideal. But there are many frames where the uh could have started." [/B]


what are you talking about? the second clip i uploaded
has lots of talking just like you asked for.


it on you server callled

about700ms.earlyaudio.tp


it is a JUDGE talking and I chose the clip of him saying

"FAULT" since the hard F sound on that word is easy to sync too
lips wise. REAL EASY.


so what is wrong with that clip? Have you looked at it yet?
Is that one ok?

[Guest]

Originally posted by Zep
"I already Uled a new clip before you even posted
so no need to get into that." I read it as no need to get into that new clip.

Sorry. I will look at your new clip right away.

[Guest]

@Zep

I sampled your stream at various points and looked at the PTS values for adjacent audio and video packets carrying PTS. They consistently showed an adjustment of -376, which is what DGIndex reported. But actually encoding in either Vdub or TMPGE required ~+700 as you reported, so something is fishy.

It's possible that the capture application is offsetting the PTS of the video to allow for audio buffering in their player application. Buffering is required to make sync adjustments during playback. You say VLC plays it OK too. I'll look at VLC. Is the source code available?

[Trahald]

http://www.videolan.org/vlc/download-sources.html

[Guest]

Originally posted by BruceL
Just curious, is there a reason you achieved a zip of version 105 inside the 106 zip? Sure! I forgot to delete the previous zip from the "Distribute" directory. Thanks for pointing it out. I fixed the zip so people don't have to download more than they need.

[Zep]

Originally posted by neuron2
@Zep

I sampled your stream at various points and looked at the PTS values for adjacent audio and video packets carrying PTS. They consistently showed an adjustment of -376, which is what DGIndex reported. But actually encoding in either Vdub or TMPGE required ~+700 as you reported, so something is fishy.


yes very fishy. that is a 1076 swing from -367 to ~+700 which is HUGE.

is the -376 (in this example) being applied to wav decode and down mix?
(just curious since no delay is in file name when i save a wav)


Originally posted by neuron2
It's possible that the capture application is offsetting the PTS of the video to allow for audio buffering in their player application. Buffering is required to make sync adjustments during playback. You say VLC plays it OK too. I'll look at VLC. Is the source code available? [/B]

I thought of that and that is why I decided to test it with OTHER .ts players
and why I tested it with VLC to make sure the app that came with my card didn't do something strange.
ALL play it back perfectly.

I also thought it would not be a true .ts file if they messed with the standards and
i could not believe they would mess around like that and that was the second reason
i tested in other .ts players and VLC etc...

BTW - it is not VDub. When I drop the avs on media classic or WMP or bsplayer
I get the problem too. So it does appear to be in DGindex ---> avisynth chain

yes the VLC and ffmpeg source is available. it is an open project based on ffmpeg.
VLC is really a GUI wrapper project around the ffmpeg core.

http://www.videolan.org/vlc/download-sources.html
http://sourceforge.net/projects/ffmpeg/


IMHO VLC and mPlayer are the best 2 players for NOT needing any codecs installed
because both use lib52/ffmpeg cores to encode/decode (sorta like ffdshow i guess)


This has been the biggest problem i see everyone posting about in HDTV forums.
You figure this one out and many .ts cappers are gonna be very happy :)

[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