DGMPGDec 1.5.3 Final

[karl_lillevold]

Very good - thanks!

It is very understandable why it crashes then. I will cut away the beginning as well. Perhaps it was cut right at the transition between a commercial and normal content.

Yes, other streams works just fine. There should be no need to write special cases for this.

Btw, I could have probably figured it out with dgindex source code myself. I will try to complete the compilation, but I am having some trouble with the one asm file requiring ml.exe. I will edit this post once I gain access on my build system, which is out of reach right now, or edit the source code so perhaps this code is not needed.

Thanks!
Karl.

[Guest]

ml.exe is readily available. PM me if you want me to point you to it.

[karl_lillevold]

Yes, the problem is not availability of ml.exe, but which version to use. I get various errors in idctmmx.asm, and have not found an ml.exe version that works.

My latest attempt was with "Microsoft (R) Macro Assembler Version 6.14.8444".

1> Assembling: idctmmx.asm
1>idctmmx.asm(1120) : error A2008: syntax error : xmm
1> DCT_8_INV_ROW_1_s2(2): Macro Called From
1> idctmmx.asm(1120): Main Line Code

ml 8.00.50727.762:

1> Assembling: idctmmx.asm
1>idctmmx.asm(52) : error A2008: syntax error : TEXTEQU
1>idctmmx.asm(1120) : error A2070: invalid instruction operands
1> DCT_8_INV_ROW_1_s2(5): Macro Called From
1>  idctmmx.asm(1120): Main Line Code

ml 6.11d:

1> Assembling: idctmmx.asm
1>idctmmx.asm(795) : error A2070: invalid instruction operands
1> movq(5): Macro Called From
1>  DCT_8_INV_ROW_1(2): Macro Called From
1>   idctmmx.asm(795): Main Line Code

For the older ML versions I have iammx.inc and iaxmm.inc.

I would appreciate if you could point me in the direction of the right ml version.

Thanks,
Karl.

[Guest]

Do you have VC++ 6, Visual Studio 2005 Express, or what?

[karl_lillevold]

VS 2005. The full version, not express.

[Guest]

You need version 6.15 (mine is 6.15.8803). Most people get it from the VC processor pack. You can find it on the web. Let me know if you have any problems finding it. I tested it with VS 2005 Pro and it works fine for assembling idctmmx.asm.

[karl_lillevold]

Thanks, Don! I believe I have the VC proc pack somewhere on one of my older systems, too. I just did not think to try that version.

[morphinapg]

I get "Couldn't open input file in HIDE mode. Exiting" with every file I try to open in Hide mode. I use DGindex in my ASXGui encoder. RC2 worked fine. Should I go back to RC2 or is there a way to fix this?

[Guest]

Please give me your exact CLI line. The syntax is more stringently checked, especially the = signs must all be present,especially with -IF=[...]. I'll test it in the meantime.

EDIT: Yup, it works fine and it fails as you say if I leave the = sign out for -IF=[...]

[morphinapg]

Originally Posted by neuron2

Please give me your exact CLI line. The syntax is more stringently checked, especially the = signs must all be present,especially with -IF=[...]. I'll test it in the meantime.

EDIT: Yup, it works fine and it fails as you say if I leave the = sign out for -IF=[...]

Yeah, that fixed it, thanks

[Guest]

Great! Thank you for putting the issue on the record here, as others may be unaware of the parsing change.

[tre31]

neuron2 ok, did some more testing regarding the previous colormatrix/colorimetry issues (no hints) that I had. dgindex v.1.48 does parse it correctly and the proper values are being reported (hence why I said it used too work as its an old version).

v.1.48:
Colorimetry: ITU-R BT.709

v.1.49b4
Colorimetry: ITU-R BT.709

v.1.49b14
Colorimetry: ITU-R BT.709

v.1.49b17
Colorimetry: Unknown

v.1.49:
Colorimetry: Unknown

v.1.50b2:
Colorimetry: Unknown

So hopefully that can help you narrow it down, its quite obvious that something changed between 1.49b14 - 1.49b17 that affects recognising the correct colorimetry within the mpeg2 stream as the stream does have colorimetry, and I can pretty much assume that whatever changed is affecting all dvb channels within Australia (as I haven't seen colorimetry since 1.49b14 when processing).

here's the sample (3.8mb) so you can draw your own conclusions...
http://rapidshare.com/files/10293796...TV.AU.m2v.html

I really hope you can solve this problem.
(sorry I took so long, just had other things going on...)

[tre31]

Originally Posted by tre31

neuron2 ok, did some more testing

I hope you still have all the old versions in source otherwise it'll be somewhat troublesome, but at least I've given you as much idea as what I have on the issue this time...

[Guest]

I've fixed it. It will be in the RC4 release (not the informal performance testing one).

[opieant]

Is it possible to add an option to produce a type-1 timecode file for mkvmerge for variable frame rate input files? DGIndex is already tracking transitions between "film" and "video" modes so I imagine this can be done pretty easily and accurately.

The type-1 format generally starts with:

# timecode format v1
Assume 29.970030

The first line is a comment that happens to specify the format, is checked by mkvmerge, and is therefore required. The "Assume" line has the default frame rate.

The remaining lines in the file specify frame ranges and the actual frame rate, such as

0,571,23.976024

where frames 0 through 571 (inclusive) are at 23.976024 FPS. The next line would begin with the next frame number that has a frame rate other than the default. If a single frame has a different frame rate, that frame number is used as the start and end frame number:

2435,2435,30.0

Frame rates may be integers or floating-point numbers. If a range of frames is skipped over, the default rate will be used.

Thanks

[Guest]

Not possible unless you do it yourself. Write a utility to generate it from the D2V file.

[opieant]

Don: I already started looking into this possibility but ran into a problem. The D2V file doesn't contain the frame rate info from the sequence headers, just one frame rate at the beginning, so this can't be done based on the D2V file alone unless I'm missing something major.

It may be possible to calculate the picture durations accurately from the flag data, in which case I can generate a type-2 mkv timecode file (specifying every picture's presentation time). I'll look into this further. At a glance it seems like one necessary flag is missing, but I haven't picked apart this type of data in ages so I'll review the standard tomorrow.

FYI, I already tried to use the "timestamps" logging feature in DGIndex to get the PTS values but I discovered that not all pictures and GOPs are showing up in that log file. I can provide a sample input if you're interested in looking into this issue.

Thanks for your help

[plugh]

A minor usability request:

Video menu has "HD Display" mode. (Thanks)
However when using the cropping filter, I can't switch mode.

So I have to (for example) switch to 'Top Left', invoke the cropping filter, set top and left, exit the filter, switch mode to 'Bottom Right', re-invoke the filter, set bottom and right.

It gets the job done, but is cumbersome.

[Zep]

Originally Posted by neuron2

I've been looking for streams like that, which allegedly mess up sync. Feel free to upload one of those.

I know I still need to get you a sample that does this but I have only capped 2 480i and no 1080i since that post. 720p basically is all I seem to cap lol. So why am I posting this? Well the one 480i had no field transitions and the other had just 2. Not enough for me to notice if sync was off or not but I did notice the frame count was different by 1 frame when I compared the 2 d2v's and why I am posting now to ask you....

Is that is normal behavior? ( The length of the fixed d2v had 1 more frame than the non fixed and the audio was 41ms shorter than video. The NON fixed one was the exact same length for video and audio )


This week I'm gonna cap some 480i stuff just for you in search of an out of sync one so I can send you a good sample.

thanks

[Zep]

Oh almost forgot. In that same 480i there appears to be a dimension change and DGindex content would change size during preview and what was there before the change stays on the very right side while the new content previews (the DGindex window stays the same size. only the content area changes. looks like it goes from 704 x 480 to 512 x 480)

I never saw that happen before. I would send it but I deleted it by mistake and it was not recoverable. This is another reason why I'm gonna find you some samples this week instead of waiting for a random cap to have problems.



Thanks