Log in

View Full Version : DGMPGDec 1.4.0 Final!


Pages : 1 2 3 [4] 5 6 7

Guest
16th June 2005, 13:55
DGDecode seems to output YV12 by default for MPEG 1. Is it intended behaviour? Yes. Do you think it shouldn't be?

If it is, does using upconv=true result in original YUY2 or is it the upsampled version? I don't know what you mean by "original YUY2".

Marius-the-Mad
16th June 2005, 14:08
:eek: Sorry. It was my impression that MPEG 1 used YUY2 instead of YV12. I thought it would be nice to have it in YUY2 by default.

Again, sorry if I'm confusing things.

Cyberia
16th June 2005, 14:14
Without YV12toRGB24() do we still need the TVScale option in DGIndex?

Guest
16th June 2005, 14:19
Can anyone give a reason why LumaFilter() should not be dropped altogether since the Avisynth native filter ColorYUV() is more capable?

ARDA
16th June 2005, 14:24
Originally Posted by neuron2
I've duplicated this and it is a bad problem. I'm not sure I like the way you've fixed it. I have to think about it.
I agree with both affirmation


Originally Posted by ARDA
By now is an easy solution but I'm not sure if it is the best
Row loops will be here till SeparateFields could be modified.

Also, if you could report your issues in the development thread prior to the release candidates appearing, it would be appreciated

You're right my apologizes next time I'll just upload that parts of code I think
could be usefull.

But I hope you understand after looking at the sources that I've used such filter as exercise for many other things.

Your mate
ARDA

ARDA
16th June 2005, 14:55
Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.

ARDA

Guest
16th June 2005, 16:15
It was my impression that MPEG 1 used YUY2 instead of YV12. Oh, I see your point now. MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).

Guest
16th June 2005, 16:20
Just one with the optimizations I've done the difference in perfomance would be giant.
Obviously in those functions with similar results.
That could be a simple reason if speed is important in some cases.
OK, thanks.

Marius-the-Mad
16th June 2005, 16:46
MPEG2 supports 4:2:0 and 4:2:2, but MPEG1 supports only 4:2:0. Even if it had 4:2:2 it could be handled in the same way as MPEG2 (leaving aside chroma siting).Thank you for the explanation. :) I have to remember that.

SeeMoreDigital
16th June 2005, 17:58
Hi Donald,

Earlier today approached mpucoder about with the following suggestion: -Hi mpucoder,

Would it be possible to increase the range of the of the "Delay" settings [of MuxMan]. The current range is between -300ms to +300ms.

Earlier today I used DGIndex to de-mux 5No clips (with different run times) from within the same .VOB file and obtained audio streams at -320, -160, -448ms, -224 and -288.

However, when I used MuxMan to re-mux the -448 .AC3 stream to the .M2V stream, it was sadly out by miles Followed by my second post: -...I often receive "Show Reel" DVD's from people within the media industry that contain multiple short clips of their work - TV/cinema commercials mostly, pop promos, short films and the like...

A typical TV/cinema commercial can run anything from between 10 to 90 seconds and usually a DVD arrives on my door step with several clips running one after another, burned into one .VOB and with no chapter breaks!

What I currently do is use DVD Decrypter to drag the .VOB file(s) onto my PC and then DGIndex to separate and select the start and end points for each clip.... But this creates individual de-muxed clips with very different audio delays!

If the delays are no greater than -300 to +300ms I can correct them perfectly with MuxMan... but not, if the are outside of those limits
To which mpucoder replied: -...this is caused by not de-multiplexing the audio properly. When extracting elementary streams, does it not make sense to extract the streams in sync? That is, to extract the audio that corresponds to the video. Why not go here [your DGIndex thread] and ask for a fix to the problem.

And if there are de-multiplexers that do this properly, my apologies for not mentioning them - feel free to speak up. (If you require reading all the posts please look here (herehttp://forum.doom9.org/showthread.php?p=673237#post673237))

I wonder, is this a DGIndex problem or an I going about this entire exercise the wrong way?


Regards

Guest
16th June 2005, 19:51
@SeeMoreDigital

If mpucoder is serious about his point that the demuxer should take care of this, then he should not have a delay adjustment at all! If he has one, it should cover the range of delays typically encountered.

All other tools that I know of do not have this limitation on delay adjustment, e.g., VirtualDub, Avisynth, TMPGEnc, etc.

It is on the development list already to produce no-delay audio files (within the limits of frame granularity). I'll start experimenting with it, but it won't be in 1.4.0. A workaround for you is 3rd-party delay correctors, such as AC3DelayCorrector.

Why is it such a big deal for mpucoder to widen his range a little?

Cyberia
16th June 2005, 20:17
TVScale in DGIndex is needed for VFAPI isn't it? I may have answered my own question.

SeeMoreDigital
16th June 2005, 20:35
Why is it such a big deal for mpucoder to widen his range a little?I dunno, maybe mpucoder is having a bad day!

I have to say, I'm using DGIndex and MuxMan almost every day now and to be honest although I'm not 100% familiar with every facet of their individual functionality, I don't consider myself as a novice!

As a matter of interest, what "delay" range would you consider as being useful?


Cheers

mpucoder
16th June 2005, 20:57
Not having a bad day, as said in this post (http://forum.doom9.org/showthread.php?p=673272#post673272) the inaccuracy not only causes excess audio at the start, but also a premature end. And nothing but the demuxer can fix that (unless you
concatenate the next cell's audio). So it's better to fix this in the demuxers.

Also MuxMan 0.14f is the last of 0.14, 0.15 features are frozen (nothing but bug fixes) and 0.16 will have the ability to set start/stop points within source streams, making the delay setting redundant for negative delay.

I didn't want the delay setting at all, but it was put in as a concession, with a range of plus/minus 300ms. That range is more than enough for dropped frames, anything higher indicates a problem in the demux.

stephanV
16th June 2005, 21:16
@neuron2

As a matter of interest, how do you tend to "fix" this delay? By padding or removing frames from the audio stream? If so, I kindly request to at least leave the option open to keep the delay. :)

SeeMoreDigital
16th June 2005, 22:29
Personally speaking when it comes to setting, plus/minus audio delays I would rather it to be measured by the frame rather than millisecond ;)

That said, I think it will be a while yet before every de-muxer will be able to offer perfectly synced de-muxed streams, so it would be a great shame to drop this implementation in MuxMan altogether (always useful to have a backup plan).

Thankfully all the Mpeg de-muxers I've tried so far highlight the delay time, making it easier to re-sync the streams in MuxMan.


Cheers

Guest
16th June 2005, 23:23
As a matter of interest, how do you intend to "fix" this delay? By padding or removing frames from the audio stream? If so, I kindly request to at least leave the option open to keep the delay. Yes, of course you'll be able to choose to correct or not. I'm not sure how I'll do it yet. Either the audio or the video could be changed. The former has the complication of lots of different audio types. The latter has the complication of orphaned reference frames, etc.

kikounet
17th June 2005, 10:00
To SeeMoreDigital.
Sorry to be so curious,
What I currently do is use DVD Decrypter to drag the .VOB file(s) onto my PC and then DGIndex to separate and select the start and end points for each clip.... But this creates individual de-muxed clips with very different audio delays!
Why don't you ask DVD Decrypter to do the demux and separation by CELL ID? :confused:

SeeMoreDigital
17th June 2005, 12:06
To SeeMoreDigital.
Sorry to be so curious,

Why don't you ask DVD Decrypter to do the demux and separation by CELL ID? :confused:You may well ask ;)

Here's the file structure of a typical DVD I receive: -

http://img298.echo.cx/img298/9262/disclayout1wm.png

As you can see, this DVD only has a total run time of 7 min 32 sec and yet it has 2No VTS segments. The first segment contains 2No chapters with 19No and 2No Cells respectively. The second segment contains 1No chapter with 7No Cells....

If you ripped all these separately you would end up with this lot: -

http://img298.echo.cx/img298/2439/cellidlist7gz.png

By the way, this disc only contains 10No TV commercials: -

1No Alton Towers - RITA
1No Coca-Cola - Bring me Sunshine
2No Peugeot - Man Hair / Woman Fantasy
2No INPES Passive Smoking - Marie / Luke
1No HSBC Bank - Careful German Driver
3No AM/PM Stores - It's 3:30 / Student Driver / Commitment


Cheers

Guest
18th June 2005, 16:24
Here is 1.4.0 RC2. The changes from RC1 are as follows:

* Replaced the buggy LumaFilter() with a new, optimized LumaYV12() filter by ARDA. Thank you for your contribution, ARDA! The DGDecode manual was updated appropriately.

* Minor GUI cosmetic changes in DGIndex.

* The integrated ParseD2V and FixD2v functions now reject obsolete D2V files (ones with earlier D2V format).

http://neuron2.net/dgmpgdec/dgmpgdec140rc2.zip

bbouchaib2002
18th June 2005, 18:05
Thank you very match for your work ;)

I used dgindex specialy to encode my ts files (recorded by dreambox satellite receiver) to divx.

But since version 1.3.1beta5 (unil 1.4.0RC2) I can not read my ts files.
The program hangs and do noting after choosing the ts file and clicking on OK.

What happend for the recent releases ?

Guest
18th June 2005, 18:35
Thank you very match for your work ;)

I used dgindex specialy to encode my ts files (recorded by dreambox satellite receiver) to divx.

But since version 1.3.1beta5 (unil 1.4.0RC2) I can not read my ts files.
The program hangs and do noting after choosing the ts file and clicking on OK.

What happend for the recent releases ? Please upload a test file to my ftp server and notify me here of its file name. With the test file I'll be able to quickly resolve your problem. Thank you.

Also, it would be appreciated if you did not wait for a release candidate to report your issues!

bbouchaib2002
18th June 2005, 23:31
it would be appreciated if you did not wait for a release candidate to report your issues!

Excuse me, I have not encode any thing from a while, and when I test the last version yesterday, it do no work for me an I download the previous versions one after one untile v1.3.1b4 that work.

I have make some tests today and this is what I have discover :

When I open a file from my local drive it work, but if I open it directly from its original location (the hdd of dreambox shared with samba) it not work.

with 1.3.1b4 no problems, I always open files directly from \\192.168.0.3\Harddisk\movie\ (I prefer because files are very big)


Have you change the manner of opening files between 1.3.1b4 and 1.3.1b5 ?

Guest
19th June 2005, 00:19
There's been no change to file opening. Please explain exactly what you mean by "it not work". Is there an error popup? What do you see?

bbouchaib2002
19th June 2005, 10:18
No there is no popup, when I add the file in the "file list", and after I press the "OK" button, 2 things can happends after :
1- in 90 % of cases, it return to the main interface and the "stream" menu is disabled and nothing happend after (as if I just open the program)
2- in the others cases it return to the main interface and the "stream" menu is enabled, but if I click on it the program hangs and I have to kill it.

Guest
19th June 2005, 19:18
Version 1.4.0 RC 3 fixes the problem with opening across the network, as reported by bbouchaib2002. I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps. :)

http://neuron2.net/dgmpgdec/dgmpgdec140rc3.zip

Could this be the winner?

iNFO-DVD
19th June 2005, 20:02
Let me be really cheeky and ask you what's the chance of you changing something before this goes final.....

Due to the use of the "[" and "]" to parse your filename in the CLI we can not use them symbols in a path and/or filename.

What's the chances of changing them to "<" and ">" because this issue would never arise again because you can't use "<" and ">" in a filename/path anyway.

I'm sure this would be very quick for you to do and the only downside I can see would be programs would need to change the way they call DGIndex slightly but that's not a problem because they would have to change their programs slightly anyway because of the updated D2V format.

I hope you can please do this..... you'll be my biggest hero :)

SeeMoreDigital
19th June 2005, 20:13
... I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps. :)

...Could this be the winner?Errrrm!

Would it be possible to add a frame counter... at some time. Or would this be too much like "very hard" work?


Cheers

Backwoods
19th June 2005, 20:13
Another day and another upgrade, awesome thank you.

Also if you remember a month or so ago there was a problem with my captured M2T files. They would freeze up the program for a bit then run, then the error was supposed to be fix, it wasn't. In these latest betas, no problems what so ever.

Just thought I'd run that by you. Thanks again.


EDIT: spelling (program -> problem, duh)

Guest
19th June 2005, 20:17
What's the chances of changing them to "<" and ">" because this issue would never arise again because you can't use "<" and ">" in a filename/path anyway. Not possible. The DOS shell interprets them as redirection.

Actually, the [ and ] may be totally superfluous anyway. I'll look into it.

Would it be possible to add a frame counter... at some time. Or would this be too much like "very hard" work? There's one in the Info dialog already. Are you asking for something else? If so, be specific.

Also if you remember a month or so ago there was a program with my captured M2T files. They would freeze up the program for a bit then run, then the error was supposed to be fix, it wasn't. In these latest betas, no problems what so ever. Great. Thanks for the feedback.

@all

Stop with the new feature requests at RC time, people, or you'll make me mad. :) I mean, we've had like 15 betas leading up to this. That's what betas are for.

SeeMoreDigital
19th June 2005, 20:49
There's one in the Info dialog already. Are you asking for something else? If so, be specific.I apologise in advance if I've missed something but when I use the seek option to set start and end points, many details in the "Information" panel disappears: -

http://img78.echo.cx/img78/4017/dgindexframeseeking0bn.png


Cheers

iNFO-DVD
19th June 2005, 21:42
Not possible. The DOS shell interprets them as redirection.Oh OK, how about one of the others: \ / : * ? |
Actually, the [ and ] may be totally superfluous anyway. I'll look into it.I hope so, I know it probably sounds quite trivial but it is quite important to me.

gizmau
19th June 2005, 21:55
[QUOTE=iNFO-DVD]Oh OK, how about one of the others: \ / : * ? |
QUOTE]

\ and : are used for paths, / introduces parameters, * and ? are wildcards, | is used for pipe - i hope i remembered right :rolleyes:

iNFO-DVD
19th June 2005, 22:01
Well there must be something... Or drop the "[" and "]" altogether, how about "{" and "}"?

Cyberia
19th June 2005, 22:18
@INFO-DVD - I have already answered this question for you in the Development thread! Let me quote:Your only option would be to use the -BF([filelist]) option. I just tested it with [ ] in filenames and it does work fine.


As other people here have said, the characters you mention are illegal because they are used as functional characters.

Changing them to a { } doen't solve the problem. Then someone using {} will complain. There is only ONE possibility:

Don, would it be possible to use quotes " to delimit the file name, since thats what DOS uses also?

iNFO-DVD
19th June 2005, 22:38
yes I read your quote though that's hardly ideal, I didn't want to mess about making/using yet another batch/list of files......

I wonder why the "[" and "]" were used in the first place by DVD2AVI in the CLI? Like you say, you'd think it would be just the 'normal' name in quotes....

SCIF
20th June 2005, 02:17
At first page www.doom9.org wrote "DGMPGDec 1.40 RC4 fixes a problem opening files across the network. It also contains rudimentary playback speed control." Is it misprint?

Selur
20th June 2005, 06:01
typo, doom9 ment rc3 ;)
1.4.0 Release Candidate 3
Version 1.4.0 RC 3 fixes the problem with opening across the network, as reported by bbouchaib2002. I also added a rudimentary playback speed control, for people with very fast machines and who don't like watching their previews race by at 170 fps.

Cu Selur

Guest
20th June 2005, 13:04
when I use the seek option to set start and end points, many details in the "Information" panel disappears The information panel is fully populated only during a preview operation.

With the current architecture there's no way to tell you the frame number corresponding to a trackbar position.

What is it exactly that you are trying to achieve and why?

Guest
20th June 2005, 14:02
I wonder why the "[" and "]" were used in the first place by DVD2AVI in the CLI? Like you say, you'd think it would be just the 'normal' name in quotes.... Actually, even quotes are not needed, because the string is adequately delimited by the = and the following space, comma, or EOL. So, I made a version that accepts the syntax with or without the [] delimiters. I want to test it a bit better before letting you have it.

iNFO-DVD
20th June 2005, 14:24
cool, look forward to the release. :)

SeeMoreDigital
20th June 2005, 14:34
What is it exactly that you are trying to achieve and why?I've been using DGIndex for cutting out clips of Mpeg2 video (and audio), directly from DVD sources (ie: no ripping to the HDD first).

For future disc examination purposes I like to make notes on the DVD's inlay card, where the start and end frames are for each clip.

Also, after compiling a quantity of clips (in their elementary stream form) I can calculate where the start and end frame points are for each clip and create a text file which I can load into MuxMan.... granted, there are other ways I can obtain the frame information... I just thought it may be useful.

As a test, yesterday, I did made DVB-T capture from a music video channel. I was able to use DGIndex to cut out several music video's of interest. And after re-syncing the audio I used MuxMan to create an 4GB DVD with chapter points for each music video.


Cheers

Guest
20th June 2005, 16:16
cool, look forward to the release. Oops, Cyberia reminded me that a space can be part of a filename or path, so my approach won't work. I'll see if I can get quotes working.

Guest
20th June 2005, 17:59
We can't use quotes, because the DOS shell strips them. We could escape them by doing \" but that's silly.

I'm going to add a new option -SD for Set Delimiter.

Then you can do:

-SD=! -IF=!file1.vob,file2.vob! -OF=!clip!

The default will be [ and ] for backward compatibility.

kikounet
21st June 2005, 08:57
Oops, Cyberia reminded me that a space can be part of a filename or path, so my approach won't work. I'll see if I can get quotes working. Don't you realize that charachters '[' and ']' can too be part of a filename ?

iNFO-DVD
21st June 2005, 11:27
Ummm Yes, that's the whole point....

Teegedeck
21st June 2005, 14:02
Hm, RC3 seems to crash on this VOB.

http://img201.echo.cx/img201/2793/dgindexerror29hd.th.png (http://img201.echo.cx/my.php?image=dgindexerror29hd.png)

http://img201.echo.cx/img201/640/dgindexerror1ml.th.png (http://img201.echo.cx/my.php?image=dgindexerror1ml.png)

An old DGIndex version I still have on my HD doesn't seem to have a problem with it:

http://img201.echo.cx/img201/4007/dgindex10127dn.th.png (http://img201.echo.cx/my.php?image=dgindex10127dn.png)

Guest
21st June 2005, 14:08
Hm, RC3 seems to crash on this VOB. Please upload the first part of the VOB to my FTP server and tell me the filename here. You can put up to several hundred MBytes, or only as much as is needed to show the problem, i.e., working in 1.0.12 but not in 1.4.0. Thank you.

Teegedeck
21st June 2005, 14:22
In progress. Thanks for always promptly reacting to stuff like that. :)

Edit: Ah, filename: kumonomukou.vob

Teegedeck
21st June 2005, 14:38
I hope you don't mind that it is almost 1 GB (889 MB). But I only know how to get parts from a VOB with MPEG2Cut; and that 'repairs' the file as a result. Just close the connection if you think it better.

Edit: Just got '550 Can't check for file existence' and transfer starts anew. Pure-FTPd is not always fun, is it?

Edit: OK, several times the same error; aborting.