PDA

View Full Version : d2v files created by MPEGDecoder.dll !


Atlantis
21st January 2003, 23:49
I was testing Nic’s MPEGDecoder.dll and MPEG2DEC.dll
The d2v files I got were these:
------------------------------------
This created by MPEGDecoder.dll and the ff option:

DVD2AVIProjectFile
1
9 Video.m2v

Stream_Type=0,0,0
iDCT_Algorithm=1
YUVRGB_Scale=1
Luminance=128,0
Picture_Size=0,0,0,0,0,0
Field_Operation=1
Frame_Rate=29970
Location=0,0,0,55F6

7 0 0 2 3 0 1 2 3 0
...
-----------------------------------
and this made by DVD2AVI:

DVD2AVIProjectFile
1
17 I:\Test\Video.m2v

Stream_Type=0,0,0
iDCT_Algorithm=2
YUVRGB_Scale=1
Luminance=128,0
Picture_Size=0,0,0,0,0,0
Field_Operation=1
Frame_Rate=23976
Location=0,0,0,55F6

7 0 0 2 3 0 1 2 3 0
...
--------------------------
The rest of the files are identical. They both play fine and correctly. I want to understand why? Because Nic’s file has Frame_Rate=29970 and still plays at the correct speed of 23.976. What are the differences between iDCT_Algorithm=1 and 2?

Nic
22nd January 2003, 13:49
Doh! Forget to set the Frame_Rate down, I didnt think I needed to. the iDCT will effect the MPEG2DEC (1 = MMX 2 = SSEMMX). Both these are easy to correct ill put out a little update soon, but im taking some time off from coding...

...off to watch raging speed horn play tonight. So ill probably be intensive care for a while ;)

-Nic

HarryM
22nd January 2003, 14:48
Originally posted by Nic
Doh! Forget to set the Frame_Rate down, I didnt think I needed to. the iDCT will effect the MPEG2DEC (1 = MMX 2 = SSEMMX). Both these are easy to correct ill put out a little update soon, but im taking some time off from coding...

...off to watch raging speed horn play tonight. So ill probably be intensive care for a while ;)

-Nic

Hi Nic,

Can you implement into your MpegDecoder 'crop' feature like trbarry's mpeg2dec2? I think, that for 2,35:1 movies is speedup 0,5% - 1%.

Your decoder is devil fast..., it's good... :devil:

Atlantis
22nd January 2003, 15:29
Doh! Forget to set the Frame_Rate down, I didnt think I needed to.
If it should not be at 2997, why does it still work correctly? I tried both DLLs and both d2v(s) and both played a 1 min clip for 1 min.

Also I encoded a test into hufyuv codec and the result is that Nic’s DLL gives bigger files. I don’t know if it's details or artifacts but it gives more dots around the dark areas.

Atlantis
22nd January 2003, 16:03
http://perso.club-internet.fr/willow/Temp_Compare.jpg
I have added a comparison picture. The original picture is captured by PowerDVD and I don’t know how accurate it is but the other two give good comparison because they are both captured by VirtualDub and go through the same software(s).

As you can see Nic’s DLL gives more little dots that makes the resulted decoded video bigger.

trbarry
22nd January 2003, 16:20
Can you implement into your MpegDecoder 'crop' feature like trbarry's mpeg2dec2? I think, that for 2,35:1 movies is speedup 0,5% - 1%.

MPEG2DEC2 does get a speedup from cropping first. But I think most of that is probably by doing the color conversion functions on a smaller amount of data. If that's the case then much of the cropping speedup would be lost (unneeded) if we go to YV12 where we don't have to do those functions at all.

There would still be a small speedup by copying a smaller buffer, but maybe trivial in most cases.

- Tom

SILICON
22nd January 2003, 18:40
Another idea for speedup the decoding.

Before decode a Block test the value of DC. If the value is low (a black block) don´t decode this block, and put all pixels of this block to cero.

¿is a silly idea?

Note: The movies have a lot of black blocks

trbarry
22nd January 2003, 20:37
The most effective speedup right now might be to put some assembler into the short dequant routines. That's what -h keeps pestering us about and he's probably right. I took a brief look at it but haven't done anything yet.

- Tom

WarpEnterprises
22nd January 2003, 21:34
Why do you all spent so much effort on speed of the decoder?
I can't imagine a situation where the decoder speed is a relevant fraction of the whole filtering/reencoding/... process.

trbarry
22nd January 2003, 21:39
I was using a trial copy of Intel Vtune back when I was tuning the DVD2AVI P4 support. At that time it appeared that just about half of the cpu time was spent in DVD2AVI (no filters) and half in Xvid.

That's enough to tune.

- Tom

-h
22nd January 2003, 22:10
Has anyone tested recent builds of libmpeg2? I dare say speed improvements have been made. I was impressed by some of the math, particularly the MMX averaging of two bytes ((a+b+1)/2) without resorting to unpacking into words.

Personally I want to write an MPEG-1/MPEG-2 encoder/decoder from scratch some day, with scalability, D-VOPs and the whole nine yards of both specs thrown in. I've written a fair bit of the assembly and code outline already, but have no idea when it could be put together into anything usable. Probably 2004 knowing me :)

-h

Nic
23rd January 2003, 10:33
@WarpEnterprise: I know what you mean, but it does make a difference and when some people are encoding at very low fps, just one fps faster is enough to keep them happy (if not doing any filtering it can make quite a difference, probably even more so on SMP systems(?))

@-h: the version I use is pretty much the most recent, I follow the libmpeg2 dev list quite carefully, theres been new asm code added recently thats sped things up, but may also be causing those little dots seen. So ill try adding XviD's iDCT for the next version, as thats tried and tested :) but I think it will have already been fixed.
libmpeg2's code is really good & Michel's really nice & helpful, but its a pain to use if you want to pay attention to the rf flag (as you cant get access to individual fields using the normal API :( )

@Atlantis: Thanks alot for that pic! Its nice that someone took some proper time to point out the problem :) Ill release a new version on monday (im out all weekend) and if you could do the same test quick and report back that would be great :)

@Silicon: Unfortunatly black is very rarely _black_ if you know what I mean :)

Cheers,
-Nic

-h
23rd January 2003, 20:00
Yeah one thing that troubles me (API-wise) is how to handle occasions when the displayed FPS != coded FPS. I suppose you could supply different behaviours at initialisation - return_displayed (performs telecine internally when needed, makes returning frame-specific vars a bit tricky) or return_coded (signals caller with pseudo-interrupt when stream changes from 24fps telecined to 29.97 NTSC, much cleaner IMHO).

There are some odd things I'm noticing - decoding frames with field-coding are supposed to be returned interlaced, but decoding field-picture-based frames is supposed to return two subsequent images stacked atop each other.

Ah well, I guess things will be clearer in a month or two when I can focus on it better.

-h