ffdshow development

[athos]

Originally posted by Andy2222
What compiler options and compiler did u used for the 09/2003 version wich seems to be the fastest from your compiles?
I used gcc with -O3 (from cygwin) for the gcc stuff (libmplayer, libavcodec and libmpeg2 i think) and then ICL 7.1 for the rest (except TomsMoComp which i cant get to compile with ICL) using /O3 /QawK or something like that (ie, optional use of cpu-specific optimizations/instructions such as mmx).

I compared compiling libavcodec with gcc and icl (7.0 i think it was) and gcc was much faster, but i think this was due to icl not compiling the asm stuff, but instead using c versions. Is this what you are looking at? It would be nice to be able to compile everything using the same compiler. if possible the choice would be gcc, in the spirit of open source ;)
Originally posted by Andy2222
PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.
Unfortunately not, but i have this script that supposedly converts the other way, perhaps this would help for something?
http://athos.leffe.dnsalias.com/makevcgen.txt

[Andy2222]

Nah the gcc for mplayer libavcodec is realy needed thats clear. No im meaning if i simple compile the ffdshow project without even changing the gcc dll's (mplayer/libav) using ICL 8.0 vs VC6.0 the VC 6.0 compile runns up to 40% faster compared to my ICL output..? Thats realy strange. I just deleted all switches and use simple O2 or O3 for ICL and the icl version is 30% slower..?

Maybe its a 8.0 Problem i will try reinstall the 7.1 version.
Since there is that much diff. in the compiles i realy expect some speed boost by fully using gcc. Im just comparing against your 9-11/2003 versions and the VC compile is already 10% faster. I cant belive that my old VC 6.0 tops an ICL 7.1 compile....
Need to rewrite the asm stuff for gcc since without it will be crappy slow.

I already checked the whole code for special _MSV_VER preprocessor instructions but just some uint64 stuff showed up so icl 8 and vc6 use 100% the same input to compile.

i just uninstalled icl 8 and installed 7.1 and have nearly the same results..? What CPU u have im using a AMD XP. Maybe its those fast_memcopy (from the libirc.lib) stuff wich dont work well on AMD CPU'S. But i cant see why since the XP also have SSE...

[athos]

Im using a P4.

I read somewhere that ICL 7.1 and 8.0 produces identical results when going for IA32 platform. I think most of the news is in IA64 and possibly SSE3 support. I'm not sure about this though. Also, if I remember correctly, Avery Lee (Virtual Dub) said that he thought the output of ICL was much better than VC's "pessimizations" (his words). Again, I might remember wrong.

It is very surprising that VC6 compiles are faster. Did you try VC7.1? I have avoided it because of the need for extra dlls, but perhaps there is a speed difference?

[Stux]

Originally posted by Blight
Andy, there is also AR information saved into XVID streams now, if ffdshow could pass that info down the line using the VIDEOINFOHEADER2 structure, that would make ffdshow the only decoder other than the nero one that could handle anamorphic xvid content (I think).

I'm fairly certain the 3ivx decoder can handle the anamorphic encodes too ;)

[Andy2222]

Originally posted by athos
Im using a P4.

I read somewhere that ICL 7.1 and 8.0 produces identical results when going for IA32 platform. I think most of the news is in IA64 and possibly SSE3 support. I'm not sure about this though. Also, if I remember correctly, Avery Lee (Virtual Dub) said that he thought the output of ICL was much better than VC's "pessimizations" (his words). Again, I might remember wrong.

It is very surprising that VC6 compiles are faster. Did you try VC7.1? I have avoided it because of the need for extra dlls, but perhaps there is a speed difference?

I dont want use VC7.1 since i mainly use VC6 for overall compatibility reason's. Still cant belive that VC6 tops ICL 8/7.1 for other projects i try use Bloodsheds DEV-C++ with gcc.
There is also a thread in the intel forum wich is related to speed problems of the intel compiler, seems some other users have this problem too. Maybe the intel compiler try to over "optimize" the inline ASM code? Im guessing that code is already optimzed by hand. In gcc u can prevent this with __asm volatile (...);

first asm problems solved

[dapipa]

Originally posted by Andy2222
What is already fixed?
aspect ratio and overlay not working/connecting correct

hi!can you post your(compiled)fixed version of ffdshow for download?i know,it's not completely fixed up yet,but i'd just like to check it out,because my only problem with builds after 20030523 was the buggy KEEP ORIGINAL ASPECT RATIO thing...pretty please with sugarlumps on top:)

[Andy2222]

@dapipa just give me 1 or 2 more days i just finished to rewrite all the damm inline asembler stuff last night, so the gcc compiler can parse that code. Now i just have to fix all the local declared variables since AT&T syntax dont allow this. Im grabbing some food now and will fix that after im refreshed :)

If im lucky the linker will find all stuff and give ma a ffdshow.ax file :)

[gigatron]

So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

Edit: nm just found it, I wonder what's new heh. The last one I got was from sourceforge..

[Andy2222]

Originally posted by gigatron
So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

Edit: nm just found it, I wonder what's new heh. The last one I got was from sourceforge..

the 05/2003 version is the latest official wich Mitka released all later versions base on the as "none stable" declared cvs tree. I dont think those version's are not stable but have some bug's. Thats the reason im working on those code atm, since Mitka dont have much time anymore to check and fix the cvs code.

The most improved stuff compared to 2002 or 05/2003 version is the denoise3D filter wich gives realy nice results. Also the rezise filter was much updated. The other changes are related to the audio filter and vfw stuff. I like the new version's cause of many assembler and MMX/3dnow/SSE code included for better speed. Also in the latest version the ASM yv12 convert code from avisynth comes handy.

[bond]

Andy,
if you still have enough motivation you maybe also want to have a look on the automatic resizing with anamorphic encodes in avi and mp4 (matroska already works, dunno about ogm)

the 3ivx guys found a way on how to store the ar info in avi and mp4 to make their decoder (with overlay mixer2) automatically resize such encodes, this would be great if it would also work in ffdshow, if possible :)
i think shitowax or stux wrote a description about how they do it in the xvid forum

keep up the great work :)

[Andy2222]

Hmm im no video guru, i also dont know codec internals very well. Is those anamorphic AR stored in the movie header?
I know how ffdshow handels the rezise AR, it just use videoheader2 if overlay is working and hand the x,y from the rezise settings and AR settings from org. Video over to the overlay. The overlay than calcs other stuff. So if we assume there is a special AR already in the xvid header ffdshow just need use that AR for videoheader2 right? In rezise mode it also just need to pass the org. header AR (not the pixel AR) over. Is that how those ana thing work?

Light me up with a bit more detailed stuff.

[Koepi]

We tried that stuff in xvid dshow ;)

The moment you handle out the conection in the graph you can set the info in the header - but you don't have access to the bitstream yet. So the container demuxer (and thus the container) must hold the AR info.

DShow sucks. Setting the correct AR afterwards (after having info from the bitstream itself) does _not_ work.

Maybe i'm totally wrong, some DShow experts please jump in here - i would be glad if ffdshow (and xvid dshow ;) ) could set the AR for the overlay from the bitstream data itself (well, it's kinda possible - you have to use the resolution you set at the start and _downscale_(!) the video internally - that's how i.e. Nero does it...).

Regards
Koepi

[Andy2222]

hehe fast post's!

@Koepi the latest cvs xvid use a simple/slow .c version as postprocessor. Is there a plan to update this versions with a asm/mmx2 version? In the old versions or at least in nic's old xvid releases there was a mmx/asm version?
Main problem with nic's was the crappy dering, deblock worked fine, better than mplayer's. U maybe have a updated mmx versions from nic somewhere?

[arno]

Originally posted by Andy2222
hehe fast post's!

@Koepi the latest cvs xvid use a simple/slow .c version as postprocessor. Is there a plan to update this versions with a asm/mmx2 version? In the old versions or at least in nic's old xvid releases there was a mmx/asm version?
Main problem with nic's was the crappy dering, deblock worked fine, better than mplayer's. U maybe have a updated mmx versions from nic somewhere?

What I especially dislike about the XviD decoder filter is the fact that it doesn't have automatic postprocessing like ffdshow has.

One other important comment is: Why not join hands and make 1 solution. Now it's like 2 people are reinventing the wheel: the XviD decoder developer(s) (Koepi?) and the ffdshow developer(s).

[LigH]

Originally posted by gigatron
So what's the latest version? Where can one get it? I have like a 2002 version lol been two years uuh hehe :)

The last version I have in my mirror was from 2004-01-13; unfortunately, I absolutely don't remember where I 'stole' it from. ;) -- Can anyone remind me?

http://www.ligh.de/software/mirrors.phtml

[Andy2222]

Originally posted by LigH
The last version I have in my mirror was from 2004-01-13; unfortunately, I absolutely don't remember where I 'stole' it from. ;) -- Can anyone remind me?

http://www.ligh.de/software/mirrors.phtml

u got it from this thread :) some pages before but this version has some speed problems, since the dll's arnt compiled with gcc and dont use any mmx/3dnow asm code. I dont recommend to host this 2004 version.

[LigH]

Thanks! As soon as someone makes a new and optimized version available, I will exchange it. Currently, the speed seems for me to be around equal to the XviD 1.0-RC1 decoder: 640x288 pixels is just a little too much for a Duron-800 with Deblocking and Grain (Film effect) with both decoders.

[Blight]

I made some changes to ZP so that it can sorta intercept AR changes in files on the fly (as the decoder calls for a mediatype change). I wouldn't recommend it though, there are all sort of unreliable stuff in it, it'd be for the best if the AR was pre-known. Maybe just patch some sort of tagging system over AVI. Or use the comment field in the AVI header ... dirty though.

[shitowax]

3ivx puts the VOL header in the codec private space in both .avi and .mp4 (never tried it but I bet it would work in OGM and MKV as well) and retrieve it at connection time in DShow... 3ivx way is completly container independant as it should be ;)

Originally posted by Koepi
Maybe i'm totally wrong, some DShow experts please jump in here - i would be glad if ffdshow (and xvid dshow ;) ) could set the AR for the overlay from the bitstream data itself (well, it's kinda possible - you have to use the resolution you set at the start and _downscale_(!) the video internally - that's how i.e. Nero does it...).Koepi

[Koepi]

Blight:

hm, that souns interesting, we didn't try something like that yet :-)

Use a flag "stream available" and after graph building, wen the first VOL is available, get the AR info, modify videoinfoheader2 accordingly and send a "media_type changed" message down the input pin.

Should it be as simple as that? Can a dshow filter do that or does it need the graph-building application?

Thanks for the hint! :)

Regards
Koepi

[Smiff]

i find 2004-01-13 very much slower than 2003-11-28 if postprocessing (mplayer) enabled on a Duron 1.2Ghz - is this normal?

edit: yes i'm thinking from Andy2222's reply above it is. it's just weird that this build got posted on softpedia as their pick of the week etc.. no offense, heh Andy great to have someone working on ffdshow! keep it up m8 :)

this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).

[dimzon]

Originally posted by Smiff
this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).

IMHO AR has no one advantage but it add some incompatibility...
I am not using non 1:1 pixel ratio encodes

[athos]

Originally posted by Smiff
this AR stuff.. how important is it? is anyone using non 1:1 pixel ratio encodes, and what for? (i'm curious).
you are aware that most retail dvd's (if cinema movies anyway) nowadays have anamorphic picture, so a 1:1 pixel encode would result in an anamorphic mpeg-4 (for example) video stream?

[Smiff]

Originally posted by athos
you are aware that most retail dvd's (if cinema movies anyway) nowadays have anamorphic picture, so a 1:1 pixel encode would result in an anamorphic mpeg-4 (for example) video stream?

right.. people want to do full res. copies of dvds? fair enough. i always resize & drop some lines when encoding to mpeg4 (so i effectively un-anamorphify it) like most people do, i guess you don't have to, for high bitrate mpeg4 (high being relative of course). ok good answer thanks :) sorry to go OT i'll stop now and get back on it.

[Andy2222]

mhh question: I found a 3ivx rip from dvd on my hdd and the movie plays wrong if i use ffdshow without overlay. The movie seems encoded in sucha anamorphic thinggi. If i use my fixed version with working overlay zoomplayer gets the correct AR from ffdshow and plays just fine.

I checked it in graphedit here are the datas:
Thats what the 3ivx decoder outputs:
Major Type: Video - Sub Type: YV12 - Format: YV12 712x360, 12 bits,
Aspect Ratio: 28480x11880,
Interlace format: Frames
rcSrc=(0,0,712,360)
rcDst=(0,0,712,360)

and thats what my ffdshow hand's to the overlay:
YV12 712x360, 12 bits,
Aspect Ratio: 28480x11880,
Interlace format: Frames
rcSrc=(0,0,712,360)
rcDst=(0,0,712,360)

now i just wonder what we all talking about? Since this also work in the 05/2003 version already? Do i miss something here?

[bond]

Originally posted by Andy2222
I found a 3ivx rip from dvd on my hdd and the movie plays wrong if i use ffdshow without overlay.hm the overlay mixer option has to always be ticked to get aspect ratio correction working (it uses overlay mixer2 in the filter graph)

The movie seems encoded in sucha anamorphic thinggi. If i use my fixed version with working overlay zoomplayer gets the correct AR from ffdshow and plays just fine.i dunno what zp does, but i think such a feature shouldnt depend on the player used
did you try it in graphedit?

[Andy2222]

yes in graphedit it worked too. So what we talk about if that thing is already working with overlay and vmr7/9 ? I dont think some1 here plays with the plain old render without overlay? So i dotn understand the discussion here realy.

[bond]

so in 3ivx encoded anamorphic encodes get resized automatically in ffdshow already (also if in avi)?
that would be news to me

[Andy2222]

ups was not a avi was a .mp4 file. :) Btw are we talking about raw mode or we talk about using libavcodec to decode 3ivx stuff and than gets out the real AR?

[bond]

i am talking about using libav :)

yep using raw (which means the 3ivx decoder is added in the graph) already works with .mp4, would be great if it could also work in ffdshow directly

[Andy2222]

oki some bad news btw, just usng the .intel_syntax directive for gcc and inline asm code dont work. The main problem are all those local C variables, i cant just declare them global this will break the code... I started to manualy rewrite the code to AT&T syntax but have some little understanding problems. Maybe some1 can help me a bit.

an example, here the org. Intel syntax:
__asm {
mov esi, [srcp]
mov edi, [dst]

mov eax,[esi]
mov ebx,[esi+4]
mov ecx,[esi+8]
mov edx,0
jmp yloop_test
align 16
yloop:
mov edx,0 // x counter
jmp xloop_test
align 16
xloop:
mov edx, src_pitch_uv2
movq mm6, [add_ones]
.......
xloop_test:
cmp edx,[src_rowsize]
mov x,edx
jl xloop
mov edi, dst
mov eax,[esi]
mov ebx,[esi+4]
mov ecx,[esi+8]

mov edx,skipnext
cmp edx,1
je dont_skip
add edi,[dst_pitch]
add eax,[src_pitch]
add ebx,[src_pitch_uv]
add ecx,[src_pitch_uv]
mov [skipnext],1
jmp yloop // Never out of loop, if not skip
align 16
dont_skip:
add edi,[dst_pitch4]
add eax,[src_pitch4]
add ebx,[src_pitch_uv2]
add ecx,[src_pitch_uv2]
mov [skipnext],0
mov edx, [y]
mov [esi],eax
mov [esi+4],ebx
mov [esi+8],ecx
mov [dst],edi
add edx, 4

yloop_test:
cmp edx,[height]
mov [y],edx
jl yloop
sfence
emms }


So we have here around 10 local variables (x,y,height....) Now i need define those for extended at&t syntax

___asm___(

......

: //output
: //input
: //clobber
)
So do i just define all variables as "m" and output as "=m" and in the code i use the %0-%10 macros? Problem is i understand simple examples with values loaded in registers and i realy like the at&t now over intel. But how i handle all those local C variables? Is there a way to tell GAS to load the variables for me and i can keep the org. C names in the asm code? Problem is with 10 variables i get wussy to rewrite all to %0-%10....

any tips?

[sprit]

Originally posted by Andy2222
Is there a way to tell GAS to load the variables for me and i can keep the org. C names in the asm code? Problem is with 10 variables i get wussy to rewrite all to %0-%10.... Have you looked at named operands? From info gcc -> C extensions -> Extended asm:As of GCC version 3.1, it is also possible to specify input and output operands using symbolic names which can be referenced within the assembler code. These names are specified inside square brackets preceding the constraint string, and can be referenced inside the assembler code using `%[NAME]' instead of a percentage sign followed by the operand number. Using named operands the above example could look like:
asm ("fsinx %[angle],%[output]"
: [output] "=f" (result)
: [angle] "f" (angle));
By using '.intel_syntax noprefix', you shouldn't even have to add the %'s before variables and registers (I haven't tried it with named operands).

[Andy2222]

ah cool thx this might help

[athos]

Originally posted by Smiff
right.. people want to do full res. copies of dvds? fair enough. i always resize & drop some lines when encoding to mpeg4 (so i effectively un-anamorphify it) like most people do, i guess you don't have to, for high bitrate mpeg4 (high being relative of course). ok good answer thanks :) sorry to go OT i'll stop now and get back on it.

sorry, mate. my bad. of course you most often resize the video when doing dvd -> mpeg4 conversion, and when you do that you might as well "un-anamorphify" it like you say. i dont know what i was thinking. i was cranky because of too little sleep, but now ive got my 4 hour afternoon nap ;)

still it might be a nice feature to have in some cases.

[Blight]

If you have DirectShow set to maintain the AR automatically (either through VMR9 or through Overlay), the changes should work instantly if a filter changes the videoinfoheader2 structure (see graphedit).

However, when the player itself controls the AR, this is a bit more complex. With VMR9, you need to intercept a message and then recalculate the AR, with Overlay, I only have an MPEG2 file to test this with, but some decoders throw an undocumented command to change the resolution.

Someone wants to post a small AVI file for testing?

[Andy2222]

puhh good news, i finaly managed to get ffdshow with gcc compiled and linked. After spending 3 day's in assembler and gcc forums. I had to learn the hard way that gcc 3.3.x and also the linker in binutils 2.14 have some troubles and i need manualy select files for gcc 3.2 and 3.3 and use the 2.13 linker to pass by all those crazy errors in the wonderfull unix world...

To get to the point the new gcc compile seems to be 10-30% faster than the latest 09-11/2003 version. It's also 10-15% faster than my fastest intel or VC6 compile. So cheer UNIX power :)

(30% is in cpu intensive filters wich use simple c++ code, no big boost for the filters wich use asm optimized code already. For example the denoise3d filter is plain c++ code and i noticed a nice speed boost there 10-20%)

If i have some time today i just need fix an error in the yv12_conversion code, since atm it crash my compile to use yv12. Seems i have to review my rewritten ASM code for bugs...

This time i dont give an ETA, to many things can still be very time consuming if something is not working, since i converted all inline asm code to unix syntax. Maybe there are more errors i realy hope not.

[BoNz1]

Andy2222, I don't want to make more work but have you updated the ffmpeg? There are a number of important fixes there that would be nice in a new build for example the decoding fix for packed bitstream. If it isn't too much trouble it might be nice to have the latest up to date version of ffmpeg.

[Andy2222]

um ... u maybe know the files? If those fixes are inside of function's without changing the return types. I can simple do a comparsion beetwen old and new code. If i have to add function's/classes or bigger stuff i will pass for now.

[athos]

Andy and others: Perhaps we should open a new project, ffdshow-mod, on sourceforge? When and if milan "returns" we could merge the both projects? I am a member of the original project, but I dont have write permissions to the CVS, and anyway I think milan wants control of what goes in the CVS.

About the ffmpeg update, I will have a look at it and see if I can figure out how to update it, so Andy can concentrate on the asm stuff which is totally out of my league.

[dimzon]

Originally posted by athos
Andy and others: Perhaps we should open a new project, ffdshow-mod, on sourceforge? When and if milan "returns" we could merge the both projects? I am a member of the original project, but I dont have write permissions to the CVS, and anyway I think milan wants control of what goes in the CVS.
Nice idea!

Just a little suggestion - move from dynamic libraries (libavcodec.dll, libmpeg2_ff.dll, libmplayer.dll, TomsMoComp_ff.dll) to static libraries. I think it must decrease resulting package size and make it more solid...

And there are "Configure" entry point in ffdshow.ax - it's calling convention is different from DllRegisterServer, please fix it(make same as DllRegisterServer) too :)

[bond]

before starting a new project maybe you should contact milan if he has nothing against joining the exisiting project!
you can also ask trbarry, who is around on doom9, for cvs access

[hellfred]

Originally posted by Andy2222

PS: u know a tool to convert dsw/dsp files to unix makefiles or at least convert the windows makefile for nmake to teh unix version? Im tired of rewriting and changing makefiles.

Did you have a look at the MinGW Utilities?
(http://sourceforge.net/project/shownotes.php?release_id=158859)

dsw2mak: Microsoft Developer Studio workspace (DSW) to Makefile converter

Maybe that will help. I have never used it.

hellfred

[Andy2222]

Originally posted by hellfred
Did you have a look at the MinGW Utilities?
(http://sourceforge.net/project/shownotes.php?release_id=158859)

dsw2mak: Microsoft Developer Studio workspace (DSW) to Makefile converter

Maybe that will help. I have never used it.

hellfred

rofl im using mingw for linking the final objects (cygwin suck, it always mix the cygwin and mingw c libs) but i never RTFM :) damm im still a windows dude, if there is no icon to click i wont find anything. Thx for the hint, to bad i already made the needed changes manualy. But will be handy to know for upcoming stuff.

[Andy2222]

Originally posted by athos
Andy and others: Perhaps we should open a new project, ffdshow-mod, on sourceforge? When and if milan "returns" we could merge the both projects? I am a member of the original project, but I dont have write permissions to the CVS, and anyway I think milan wants control of what goes in the CVS.

About the ffmpeg update, I will have a look at it and see if I can figure out how to update it, so Andy can concentrate on the asm stuff which is totally out of my league.

I just compared some of the ffmpeg files with the latest cvs, it seems nothing big changed just some more support for audio and some video codec's.
If i understand it right ffdshow just use those dll->call in the Tlibavcodec.cpp, and that file dont look very complicated so mainly u have to figure out what new dll-> calls (or renamed) are in the actual ffmpeg and implement them in the Tlibavacodec.cpp.

PS: For the sourceforeg thing, would be cool we just have to open a new branch in the ffdshow cvs so nothing get mixed. But since i could not find a way to write some working preprocessor macros for keeping the old intel syntax asm and convert them to unix style on the fly i realy did some changes to the code wich milan "might" not like and now its also impossible to use VC6 or intel compiler to compile my version. Since there is still Dev-C++ wich use gcc and the new gcc version is faster i dont see a problem but i think milan would like to keep those changes seperated from his version.

[Andy2222]

mhh maybe some1 know how assembler output templates work in gcc?

Problem:

inline void dummy()
{
__asm__ __volatile__("
push %eax
jmp jump
jump:
pop %eax"
);
}

int main()
{
dummy();
dummy();
}

Compiling with -S shows the fact that gcc just copies the asm block twice
in the main and so, the "jump" label is defined twice, wich resluts in a compiler error.

So there are those output templates, i think the "%=" will do the job, can some help me here, is this correct?
inline void dummy()
{
__asm__ __volatile__("
push %eax
jmp jump%=
jump%=:
pop %eax"
);
}
As far as i read %= output a unique number wich is generated new in every instance of the asm code. (i realy start to hate at&t syntax, since the org. intel code dont had to worry about multiple calls...)

problem solved, just 2 hours of using the www, seems the %= is working.

[bond]

Originally posted by Andy2222
i realy did some changes to the code wich milan "might" not likeits pretty easy in cvs to use exactly the same folders, etc... as the last "official" code, but still keep them seperated

it works via tagging. have a look at the drop-down menu at the bottom here (http://cvs.sourceforge.net/viewcvs.py/ffdshow/ffdshow/)
someone could tag the latest "official" sources as "milan_latest" or so and after that simply add andy's changes to the cvs
that way you can use the same structures as milan, dont mess the cvs and his latest stuff would be still available

[Andy2222]

common dudes some1 here must have been used inline asm yet?

i keep posting here, dont know special asm forums...:

thats the intel syntax line
"mov edx, src_pitch_uv2" //src_pitch_uv2 is a local c variable

it load's the pointer to src_pitch_uv2 in edx

thats my at&t line
"movl $%[src_pitch_uv2],%%edx"
:
:[src_pitch_uv2] "g" (src_pitch_uv2) //reference to src_pitch_uv2, and "g" means let the compiler choose a register to store.
:"%edx"

and i get a asm error: "Error: junk `(%esp)' after expression"
seems the $%[src_pitch_uv2] is not working
also
"movl (%[src_pitch_uv2]),%%edx"
is not working.
Maybe its cause i load the value of src_pitch_uv2 in [src_pitch_uv2] as reference and not the pointer or is something wrong in the line?

[arno]

Originally posted by Andy2222
common dudes some1 here must have been used inline asm yet?

i keep posting here, dont know special asm forums...:

thats the intel syntax line
"mov edx, src_pitch_uv2" //src_pitch_uv2 is a local c variable

it load's the pointer to src_pitch_uv2 in edx

thats my at&t line
"movl $%[src_pitch_uv2],%%edx"
:
:[src_pitch_uv2] "g" (src_pitch_uv2) //reference to src_pitch_uv2, and "g" means let the compiler choose a register to store.
:"%edx"

and i get a asm error: "Error: junk `(%esp)' after expression"
seems the $%[src_pitch_uv2] is not working
also
"movl (%[src_pitch_uv2]),%%edx"
is not working.
Maybe its cause i load the value of src_pitch_uv2 in [src_pitch_uv2] as reference and not the pointer or is something wrong in the line?

Maybe this works (long time since I used x86 assembly, so don't bleem me if I'm wrong ;-)):

"movl src_pitch_uv2,%%edx" or maybe even "movl (src_pitch_uv2),%%edx"

But as I don't really understand what you're doing (whether you're doing a dword ptr [] or just a value load) it could also be:

"movl $src_pitch_uv2,%%edx" or maybe even "movl ($src_pitch_uv2),%%edx"

Using % is, as far as I recall exclusively for registers.

I could be completely wrong here, if you're not able to fix it with this help I will have to get my old books out of the dust and have a closer at it for you (as I'm really eager to help you build a brand new ffdshow release ;-))....

[Andy2222]

solved

[Andy2222]

oki seems i found a fix/solution, something was messed up with my clobber and input output registers... Seems the code is working now. Heading over to the next file with asm code :)

PS: i never noticed that using libavcodec vs org. xvid decoder is sucha speed diff. libavcodec is 50% faster than using xvid and ffdshow in raw mode? I tryed latest beta (sse/mmx compile) and the old nic and koepi all perform pretty poor (PP was disabled) compared to libavcodec :)