Windows 7 has same flaw as Windows NT 3.1

[JohnnyMalaria]

as such i wouldn't expect any flaws found in kernel version 3.51.1025.1 to be present in kernel version 6.1.7600.16385.

That would require all the code to be rewritten from the ground up and all the compilers etc. Do you seriously expect any software vendor to redevelop their development tools? Would you create new assembler code for C string functions for each new major OS release? That's not how PLEs work. Indeed, some known issues are deliberately kept because legacy software would break. One example is in Video for Windows. There is a bug that limits the maximum file size to 2GB (because of a signed compare instead of unsigned in the VfW dll). Fixing the bug would break many NLEs etc.

my understanding is that Win 7 uses the same amount of resources that Vista did, which is what one would expect. Vista, and as a consequence Win 7, was significantly better threaded than XP, the more threads a piece of software launches the more ram it requires and the more cpu resources, i don't see how Win 7 could improve on this unless it was less threaded than Vista.

Well, your understanding is incomplete. Read up on the scheduling and affinity changes introduced in 6.1.

[deadrats]

@ocgw

do you have any proof whatsoever that win 7 uses less resources than vista and if so by what metric are you measuring resource usage? idle ram used? virtual memory used? lower cpu usage?

if win 7 is just vista sp3, as you said, then why would it use less resources and an even better question is why would you pay full purchase price for a service pack that should have been offered for free?

[deadrats]

That would require all the code to be rewritten from the ground up and all the compilers etc. Do you seriously expect any software vendor to redevelop their development tools? Would you create new assembler code for C string functions for each new major OS release? That's not how PLEs work. Indeed, some known issues are deliberately kept because legacy software would break. One example is in Video for Windows. There is a bug that limits the maximum file size to 2GB (because of a signed compare instead of unsigned in the VfW dll). Fixing the bug would break many NLEs etc.

i expect a developer to continuously improve and update their development tools for 2 reasons:

1) you can only improve your apps so much if you don't improve your development tools.

2) and the biggest reason i expect them to improve their tools is because the same tools they use to create their software, such as word, windows and their compilers they also sell to the general public, i remember being given a full retail copy of visual c (as a gift) when i was in college and the handbook that came with it, in the first couple of pages, had a passage that said:

"did you know we created visual c using visual c?" , a line i just had to chuckle at, i knew what they meant but it still sounded absurd.

furthermore it is absurd to claim that "some known issues are deliberately kept because legacy software would break", you are basically implying that the app in question actually relies on a bug in the OS, i submit to you that if that in fact is the case both the OS and the app in question should be junked immediately, a bug in the OS should be an impediment to an app working properly not aid it nor should fixing the bug prevent the app from functioning.

as far as the bug in vfw that you refer to i am not aware of any limitation on size, in fact i just had to go and test your claim and encoded a 6 gig avi using mp3 audio and the vfw x264 build and it encoded and plays back just fine.

i tried to google "vfw 2 gig bug" (and variations thereof) but all i could find was links back to your post and a couple of obtuse references dating back to 1999 about certain software having that limitations with updates that it had been fixed and the only current (circa 2008/2009) references relate to adobe's software having a similar bug that limits file sizes to 2 gigs when using a vfw codec, but every indication points to it being an adobe bug exclusively and not something wrong with the vfw framework.

Read up on the scheduling and affinity changes introduced in 6.1.

i know all about "core parking", i read every article on it the moment it was announced, it has nothing to do with reducing resource usage, it was a bone thrown to intel by microsoft:

http://www.tomshardware.com/reviews/intel-core-i5,2410-8.html

as you can see all it does is benefit the nehalem architecture by allowing it to use less power at idle but it also allows the processor to ramp up the turbo boost speeds faster, which in theory should result in a very slight performance edge under full load but also causes more juice to be used.

but for ocgw say that "it isn't a huge resource hog like Vista was", come on, stop the madness.

maybe i've gotten a bit spoiled by linux, which despite having it's issues, the open source community seems to be way more responsive about bugs than microsoft (or apple for that matter), a bug is found, it gets fixed asap, the compilers are constantly being updated and there is no way a bug in the linux kernel from 17 years ago would still exist today.

from a performance perspective, some of the better prepared distros run like stink on a monkey and the bsd variants in many ways point to where windows should be going. i remember installing and testing pc-bsd and thinking to myself that microsoft should buy that company and build vista on top of that, port dx and the whole win api so that it runs on top of bsd (they could have looked at the WINE project for guidance), used the project looking glass 3d desktop and called it a day, they would have had a nice, compact, clean, fast, modular OS that they could improve in parts as they see fit, it would be secure, virus writers wouldn't have experience writing malware for it so it would have that added benefit, it would have the powerful shell scripting for administration and since most of the code would be lgpl they wouldn't even need to release any of the enhancements they made to the code back to the open source community.

alas, we got vista, then win 7, in about a year to 18 months we'll have win 8, then win 9 and if microsoft has their way, as has been their stated vision since the internet's inception, we'll eventually all be using "dumb terminals" that run skeleton OSes, that connect to centralized servers where the software we lease resides (i'm sure you have heard of the whole "the internet is the computer" business plan).

[TJohns]

If you check 'bb' response here (http://forum.doom9.org/archive/index.php/t-49164.html) you see that the 2GB limit is a restriction in the original AVI 1.0 specifications ... the OpenDML extension has since overcome this, and with most software you may not even know which it's creating!

Trev

[ocgw]

@ocgw

do you have any proof whatsoever that win 7 uses less resources than vista and if so by what metric are you measuring resource usage? idle ram used? virtual memory used? lower cpu usage?

if win 7 is just vista sp3, as you said, then why would it use less resources and an even better question is why would you pay full purchase price for a service pack that should have been offered for free?

metric?? lol how about actual real life experience young man, getting dozens of friends, family and co-workers slow azz Vista PC's performing (as opposed to "pie in the sky" theories)

1. I have read that Windows 7 assigns less resources by default, the the proof is Windows 7 will run smoothly on almost any PC down to even PIII's w/ 1GB of memory, try that w/ Vista

irl example: My daughter came back home from school, daughter's PC had Vista, a P4 and 1/2 a gig of ram it was excruciating slow, I added to her PC a 1GB stick of ram and it was a little better but it still sucked balls, I loaded Windows 7 on it w/ no other change and it is now fast and responsive

2. The "Vista Service Pack 3" uses less resources because it has performance tweaks to do so

3. I never paid one slim dime for Windows 7, I was given Windows 7 Ultimate "Signature Edition" for free by MS

4. I personally never chose to use Vista on any of my personal PC's because all my PC's are tweaked for maximum performance, I migrated my entire home network from XP to Win 7, and if anyone has Vista and it is working for them I don't recommend paying to upgrade

I do recommend new PC buyers and Vista computer owners w/ marginal hardware to upgrade to 7

I have met ppl like you that will give a 1000 page disertation proving that the sky is black, but when we look up it is still looks blue

ocgw

peace

[deadrats]

If you check 'bb' response here (http://forum.doom9.org/archive/index.php/t-49164.html) you see that the 2GB limit is a restriction in the original AVI 1.0 specifications ... the OpenDML extension has since overcome this, and with most software you may not even know which it's creating!

thanks for the link, so it looks like the old avi container has a 2gig file size limit (which has since been corrected), but that has nothing to do with the vfw framework, johnny claims there's a bug in the the vfw dll that limits the file size to 2 gigs when using a vfw codec, which i'm assuming implies irrespective of the container used, i can find no such bug, closest i see is adobe premiere having a 2 gig issue, which means that premiere is a giant piece of crap if it's still using old avi 1.0 containers.

maybe johnny will expand on his claims...

[JohnnyMalaria]

VfW, not DirectShow. I can assure you that for the AVI 1.0 specs, the bug remains. I'm not refering to codecs, I'm refering to the VfW file i/o library functions. I know this from a private conversation with the person who devised and led the development DirectShow when he worked for MS.

[JohnnyMalaria]

[quote="deadrats"]i expect a developer to continuously improve and update their development tools for 2 reasons
[\quote]

You don't understand "continuous improvement", obviously. All of your preaching is about how continuous improvement rather than ground-up redevelopment is the root of all MS evil.

[deadrats]

I have read that Windows 7 assigns less resources by default, the the proof is Windows 7 will run smoothly on almost any PC down to even PIII's w/ 1GB of memory, try that w/ Vista

i suggest you expand your reading a bit, here's the recommended specs for vista and win 7:

http://www.microsoft.com/windows/windows-vista/get/system-requirements.aspx

note that microsoft recommends a minimum of 512mb of ram for vista home basic

http://www.microsoft.com/windows/windows-7/get/system-requirements.aspx

note that the lowest recommendation for win 7 is 1 gig of ram.

by the way, you managed to install win 7 on a P3? that's impressive, just not as impressive as installing vista with just 256mb ram:

http://www.youtube.com/watch?v=IiCZtluZIyY&feature=related

or how about vista with just 48 mb ram using vmware:

http://www.youtube.com/watch?v=aDj7TMfAt68&feature=related

how about vista on an 850mhz P3:

http://www.youtube.com/watch?v=s-QviwKKNL4&feature=related

I have met ppl like you that will give a 1000 page disertation proving that the sky is black, but when we look up it is still looks blue

have i not mentioned a couple of hundred times that one of my majors in college was physics? you should know better than to make a say something like that to me.

you're lucky that the afc championship game is about to start in a couple of minutes but rest assured the sky itself has no color, not in the way a car has color:

http://www.sciencemadesimple.com/sky_blue.html

predictions:

afc - colts

nfc - vikings

[deadrats]

VfW, not DirectShow. I can assure you that for the AVI 1.0 specs, the bug remains. I'm not refering to codecs, I'm refering to the VfW file i/o library functions. I know this from a private conversation with the person who devised and led the development DirectShow when he worked for MS.

i realize that i may not be the world's foremost video expert but your statements are contradictory, first you claim that the bug is in the vfw dll, specifically the i/o functions, which i'm assuming refers to the reading and writing of files, then you say that the bug relates to the avi 1.0 spec, which jives with the link the other poster provided, which means that it's a bug in the old avi container.

now i will admit i haven't actually worked with vfw.dll, but i'm assuming that a vfw compatible codec, such as xvid or some builds of x264 or divx, basically invoke vfw.dll to handle the stream reading/writing duties as the file is being processed, and it's vfw.dll that actually places that multiplexes the audio and video streams into one container. i'm also assuming that when this is attempted with an avi 1.0 container, that said read/write operations fail.

if the above is correct, then i fail to see how you can claim it's a vfw bug, especially since the bug disappears once you use a different container, like later iterations of avi, mkv, mp4 or ogm.

i also fail to see how this would "break" a NLE or an encoder if it was fixed, if anything it would add new functionality to the NLE, regardless of whatever any ex-direct show developer may claim (if he no longer works for microsoft it may be because he used to make silly statements like that).

[deadrats]

[quote="JohnnyMalaria"]

i expect a developer to continuously improve and update their development tools for 2 reasons[\quote]

You don't understand "continuous improvement", obviously. All of your preaching is about how continuous improvement rather than ground-up redevelopment is the root of all MS evil.

"continuous improvement" refers to sticking with something when it's basically fine; a perfect example would be updating DX with newer SIMD instructions as they become available on cpu's, in order to get maximum speed (which microsoft doesn't do) and "continuous improvement" also refers to cleaning house and starting all over when you have something that's fundamentally flawed, a perfect example is the NT kernel, which evidently still resides within win 7.

basically i expect a developer to fix what can be fixed and replace what can't be fixed, i don't think that's too unreasonable, especially when said company expects you to spend a couple of hundred bucks per license every time they come up with a supposedly new OS, which it's starting to look like microsoft has decided they don't have enough billions and will continue pushing out "new" revisions every 18 months or so.

i wonder how long such a business model can be sustained before people say enough is enough and just stop upgrading their OS?

[ocgw]

I have read that Windows 7 assigns less resources by default, the the proof is Windows 7 will run smoothly on almost any PC down to even PIII's w/ 1GB of memory, try that w/ Vista

i suggest you expand your reading a bit, here's the recommended specs for vista and win 7:

http://www.microsoft.com/windows/windows-vista/get/system-requirements.aspx

note that microsoft recommends a minimum of 512mb of ram for vista home basic

http://www.microsoft.com/windows/windows-7/get/system-requirements.aspx

note that the lowest recommendation for win 7 is 1 gig of ram.

by the way, you managed to install win 7 on a P3? that's impressive, just not as impressive as installing vista with just 256mb ram:

http://www.youtube.com/watch?v=IiCZtluZIyY&feature=related

or how about vista with just 48 mb ram using vmware:

http://www.youtube.com/watch?v=aDj7TMfAt68&feature=related

how about vista on an 850mhz P3:

http://www.youtube.com/watch?v=s-QviwKKNL4&feature=related

I have met ppl like you that will give a 1000 page disertation proving that the sky is black, but when we look up it is still looks blue

have i not mentioned a couple of hundred times that one of my majors in college was physics? you should know better than to make a say something like that to me.

you're lucky that the afc championship game is about to start in a couple of minutes but rest assured the sky itself has no color, not in the way a car has color:

http://www.sciencemadesimple.com/sky_blue.html

predictions:

afc - colts

nfc - vikings

thx for proving my point about you for me, the forum and the whole wide world to see, we all know all about the sky color thing

off course the sky according to conventional wisdom technically doesn't have color, but who cares as long as the background in my picture is blue, I am just saying you are the kind that will go on about it ad naseum

then again things only have color because we perceive them to have color because they reflect that wavelenght of light, if we perceive the sky to be blue then it is blue, space is black

You forgot who you are talking to, a man that builds, sells and repairs PC's irl instead of "going off" solely on what I read off the interweb, and making wild postulations

you are overeducated and underskilled, you have just enough knowlege to be dangerous and w/o real world experience or wisdom you just come off as foolish

ocgw

peace

[JohnnyMalaria]

i wonder how long such a business model can be sustained before people say enough is enough and just stop upgrading their OS?

Pretty damn long. Longer than if they issue a completely new OS every bat of an eyelid. And, for MS, the client versions of Windows aren't a major part of their business model anyway. Even then, most consumer clients are obtained via the OEM route so the issue of upgrading is of minor concern. I'll leave you to do the background reading on that.

[JohnnyMalaria]

VfW, not DirectShow. I can assure you that for the AVI 1.0 specs, the bug remains. I'm not refering to codecs, I'm refering to the VfW file i/o library functions. I know this from a private conversation with the person who devised and led the development DirectShow when he worked for MS.

i realize that i may not be the world's foremost video expert but your statements are contradictory, first you claim that the bug is in the vfw dll, specifically the i/o functions, which i'm assuming refers to the reading and writing of files, then you say that the bug relates to the avi 1.0 spec, which jives with the link the other poster provided, which means that it's a bug in the old avi container.

now i will admit i haven't actually worked with vfw.dll, but i'm assuming that a vfw compatible codec, such as xvid or some builds of x264 or divx, basically invoke vfw.dll to handle the stream reading/writing duties as the file is being processed, and it's vfw.dll that actually places that multiplexes the audio and video streams into one container. i'm also assuming that when this is attempted with an avi 1.0 container, that said read/write operations fail.

if the above is correct, then i fail to see how you can claim it's a vfw bug, especially since the bug disappears once you use a different container, like later iterations of avi, mkv, mp4 or ogm.

i also fail to see how this would "break" a NLE or an encoder if it was fixed, if anything it would add new functionality to the NLE, regardless of whatever any ex-direct show developer may claim (if he no longer works for microsoft it may be because he used to make silly statements like that).

Codecs have nothing to do with file i/o. VfW is a framework that includes file i/o. The person I spoke to was the inventor of DirectShow not just a "developer". He left MS because he relocated from WA to a different part of the world.

[deadrats]

You forgot who you are talking to, a man that builds, sells and repairs PC's irl instead of "going off" solely on what I read off the interweb, and making wild postulations

you are overeducated and underskilled, you have just enough knowlege to be dangerous and w/o real world experience or wisdom you just come off as foolish

1) i'm going to ignore your comments with regard to color primarily because i have learned from experience that when i try to explain any scientific principle to someone that lacks the appropriate scientific background, it can be a very frustrating experience, so believe anything you want about the sky.

2) any chimp can build, repair and sell pc's, it doesn't mean you know squat about computer architectures and OS design, as you have repeatedly prove most effectively.

here's a video of a monkey upgrading a video card, i would venture to bet that you both have roughly equivalent levels of general computer knowledge:

http://blogs.amd.com/how-to/2010/01/13/how-to-install-a-graphics-card/

[deadrats]

Codecs have nothing to do with file i/o. VfW is a framework that includes file i/o. The person I spoke to was the inventor of DirectShow not just a "developer". He left MS because he relocated from WA to a different part of the world.

i think he may have been deported for not knowing what he was doing. codecs have nothing to do with file i/o?!? what do you think handles the writing of the outputted file and the reading of the inputted file if vfw isn't used?

because i wanted to make sure that i was correct i downloaded the source for x264, which included the source for both the vfw and non-vfw variants of x264.

in the c file that has the comment:

codec.c: vfw x264 encoder

a quick look through the pre-processor directives we see the following:

#include "x264vfw.h"

#include <stdio.h> /* debug only */
#include <io.h>

#define X264_MAX(a,b) ( (a)>(b) ? (a) : (b) )
#define X264_MIN(a,b) ( (a)<(b) ? (a) : (b) )

that's it.

in the c file that has the comment:

x264: h264 encoder

we see the following pre-processor directives:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <math.h>

#ifdef __WIN32__
#include <windows.h>
#define pthread_t HANDLE
#define pthread_create(t,u,f,d) *(t)=CreateThread(NULL,0,f,d,0,NULL)
#define pthread_join(t,s) { WaitForSingleObject(t,INFINITE); \
CloseHandle(t); }
#define HAVE_PTHREAD 1

#elif defined(SYS_BEOS)
#include <kernel/OS.h>
#define pthread_t thread_id
#define pthread_create(t,u,f,d) { *(t)=spawn_thread(f,"",10,d); \
resume_thread(*(t)); }
#define pthread_join(t,s) wait_for_thread(t,(long*)s)
#define HAVE_PTHREAD 1

#elif HAVE_PTHREAD
#include <pthread.h>
#endif

#include "common/common.h"
#include "common/cpu.h"

#include "set.h"
#include "analyse.h"
#include "ratecontrol.h"
#include "macroblock.h"

#if VISUALIZE
#include "common/visualize.h"
#endif

//#define DEBUG_MB_TYPE
//#define DEBUG_DUMP_FRAME
//#define DEBUG_BENCHMARK

#ifdef DEBUG_BENCHMARK
static int64_t i_mtime_encode_frame = 0;
static int64_t i_mtime_analyse = 0;
static int64_t i_mtime_encode = 0;
static int64_t i_mtime_write = 0;
static int64_t i_mtime_filter = 0;
#define TIMER_START( d ) \
{ \
int64_t d##start = x264_mdate();

#define TIMER_STOP( d ) \
d += x264_mdate() - d##start;\
}
#else
#define TIMER_START( d )
#define TIMER_STOP( d )
#endif

#define NALU_OVERHEAD 5 // startcode + NAL type costs 5 bytes per frame

i included the non stream related directives for the sake of completeness, but as we can see the codec most certainly does handle I/O if vfw isn't used, in fact the x264 developers recommend that people avoid using the vfx x264 variant because they claim it's deprecated, i personally find vfw codecs useful because it lets me use x264 with apps like virtual dub and tmpg express, but from a programming standpoint i prefer non-vfw codecs because i'm from the school of thought that an app should be as self contained as possible, it should require an end user to install additional software in order for it to work.

but that's just me.

[JohnnyMalaria]

Anyone can cut and paste stuff they have no clue about. A codec transforms data - it doesn't do any file i/o. The appropriate framework does that (VfW, DirectShow etc). Some libraries may appear has codecs and offer additional functionality.

When you have written VfW and DS codecs along with bespoke file i/o modules, developed and sold corresponding applications then I might bother to read your nonsense.

[ocgw]

You forgot who you are talking to, a man that builds, sells and repairs PC's irl instead of "going off" solely on what I read off the interweb, and making wild postulations

you are overeducated and underskilled, you have just enough knowlege to be dangerous and w/o real world experience or wisdom you just come off as foolish

1) i'm going to ignore your comments with regard to color primarily because i have learned from experience that when i try to explain any scientific principle to someone that lacks the appropriate scientific background, it can be a very frustrating experience, so believe anything you want about the sky.

2) any chimp can build, repair and sell pc's, it doesn't mean you know squat about computer architectures and OS design, as you have repeatedly prove most effectively.

here's a video of a monkey upgrading a video card, i would venture to bet that you both have roughly equivalent levels of general computer knowledge:

http://blogs.amd.com/how-to/2010/01/13/how-to-install-a-graphics-card/

Tell me what exactly makes that man in that video a "monkey"? Could it be delusions of grandeur?

All jokes aside, you really are some "piece of work"

ocgw

peace

[JohnnyMalaria]

Regarding VfW, 2GB, bug etc...

The original RIFF specification uses unsigned longs for addressing for the various structures which is the origin of the 4GB file size limit.

The implementation of Video for Windows (which is a framework that uses RIFFs) erroneously uses signed longs in the function headers which imposes a 2GB file size limit. VfW exposes COM interfaces that also use signed longs. It is a golden rule of COM that once published an interface definition cannot be changed. MS mistakenly used the wrong data type and could not fix it without introducing a newer but distinctly separate version of the library. To fix the existing library would risk breaking any existing applications that use the library for obvious reasons. The advent of ActiveMovie/DirectShow provided the opportunity to resolve the issue.

[deadrats]

Anyone can cut and paste stuff they have no clue about. A codec transforms data - it doesn't do any file i/o. The appropriate framework does that (VfW, DirectShow etc). Some libraries may appear has codecs and offer additional functionality.

When you have written VfW and DS codecs along with bespoke file i/o modules, developed and sold corresponding applications then I might bother to read your nonsense.

nonsense? you consider the source code to one of the most popular codecs nonsense? that's what i like about open source software, when someone like you makes a most idiotic statement it's quite easy to debunk it, just show the code.

here's a question for you genius, how do you think the audio/video streams get read/written from/to the hard disk if the codec in question doesn't use a proprietary framework? if you are such an expert, explain to me how non-vfw, non-direct show codecs, like the standard x264 version, handle input/output.

how do audio/video streams get read from/written to on OS X? on linux? on solaris? on unix?

just because you are a windows "programmer" that has to rely on an api/dedicated framework to handle I/O doesn't mean that every programmer out there is as half-assed.

the code is out there so that you can learn, accept it, ignore it, i couldn't care less, but if you're going to continue to make one dumb statement after another at least do it on a topic that it's not that easy for me to prove you wrong.

[deadrats]

Tell me what exactly makes that man in that video a "monkey"? Could it be delusions of grandeur?

oops, wrong link:

http://www.youtube.com/watch?v=1DPQW0e9ufM

[JohnnyMalaria]

Anyone can cut and paste stuff they have no clue about. A codec transforms data - it doesn't do any file i/o. The appropriate framework does that (VfW, DirectShow etc). Some libraries may appear has codecs and offer additional functionality.

When you have written VfW and DS codecs along with bespoke file i/o modules, developed and sold corresponding applications then I might bother to read your nonsense.

nonsense? you consider the source code to one of the most popular codecs nonsense? that's what i like about open source software, when someone like you makes a most idiotic statement it's quite easy to debunk it, just show the code.

here's a question for you genius, how do you think the audio/video streams get read/written from/to the hard disk if the codec in question doesn't use a proprietary framework? if you are such an expert, explain to me how non-vfw, non-direct show codecs, like the standard x264 version, handle input/output.

how do audio/video streams get read from/written to on OS X? on linux? on solaris? on unix?

just because you are a windows "programmer" that has to rely on an api/dedicated framework to handle I/O doesn't mean that every programmer out there is as half-assed.

the code is out there so that you can learn, accept it, ignore it, i couldn't care less, but if you're going to continue to make one dumb statement after another at least do it on a topic that it's not that easy for me to prove you wrong.

You simply don't understand. I suspect you recently acquired a lexicon of computer terms and simply string them together in an attempt to sound knowledgeable but, instead, reveal remarkable ignorance.

To answer your diatribe: additional support functions. A codec encodes and decodes. It takes input data and transforms them. Where the data come from is irrelevant to the codec. Supporting functions can be provided in the same library to perform file i/o independent of the usual frameworks.

As for the x264 code, it isn't a codec (I'll let you figure out what it is). Linking to stdio.h doesn't mean file i/o takes place. There are other reasons to include stdio.h. And file i/o operations can be used without writing/reading to disk.

EDIT: By your definition, VLC is a codec - do you really believe that?

[deadrats]

You simply don't understand. I suspect you recently acquired a lexicon of computer terms and simply string them together in an attempt to sound knowledgeable but, instead, reveal remarkable ignorance.

To answer your diatribe: additional support functions. A codec encodes and decodes. It takes input data and transforms them. Where the data come from is irrelevant to the codec. Supporting functions can be provided in the same library to perform file i/o independent of the usual frameworks.

As for the x264 code, it isn't a codec (I'll let you figure out what it is). Linking to stdio.h doesn't mean file i/o takes place. There are other reasons to include stdio.h. And file i/o operations can be used without writing/reading to disk.

ROTFLMAO!!! all i have to say is that you have proven to me that no one should ever use any video related app you code, ever.

seriously, i was going to sit here and explain to you everything that is wrong with what you said but i'll just let your posts and my posts speak for themselves, people that have a programming background can decide for themselves which one of us knows what he's talking about and which one is a windows "programmer".

by your logic any compressing/decompressing app, like winrar, winzip, 7zip, doesn't do it's own I/O, all it does is "transform the data", a truly dumb statement.

as for your statement that x264 is not a codec, what can i say, evidently the guys over at doom9 consider it a codec because it won a codec shootout that had:

http://www.doom9.org/index.html?/codecs-final-105-1.htm

[JohnnyMalaria]

You clearly have no idea what a codec is.

Read the big letters on this page.

http://www.videolan.org/developers/x264.html

Time to lock this thread, please.

[HemLok]

You clearly have no idea what a codec is.

Read the big letters on this page.

http://www.videolan.org/developers/x264.html

Time to lock this thread, please.

Unfortunately the use of the term "codec" has become very very sloppily and loosely used over time. Codec... compressor-decoder.... Hmmm... What's missing with x264?

Sadly, yes, this particular point further proves how this thread will continue on its insane path as if there wasn't proof enough already.

[lacywest]

Dogs and cats living together...!

and your point is ... or do I need to post pix of my dogs and cats living together ... LOL