Quote:
|
Originally Posted by squid_80
What I don't understand is why mmio and avifile will quite happily read over the 2gb boundary, but hurk if you seek past it then attempt to read.
|
There are no special read calls for huge files. All the kernel calls like ReadFile, _lread, _hread just read the next sequential data so they just don't know or care when you cross a 2gb boundary.
However doing a seek on huge files is a pain. All the old calls like _lseek have signed 32 bit args so they "hurk" as you say. Interestingly relative mode seeking seems to work, so I guess the mm/av code must all use absolute mode seeking. Even the modern call SetFilePointer is a pain to drive for huge files access. So a lot of slack code just ignores the high order 32 bit pointer arg and so you are stuck in a 2 gb world still. The avi code is certainly old enough to be using _lseek or a slack implementation of SetFilePointer. And M$ want to disown AVI and do everything in their nasty proprietory ASF format, so I guess they see 2gb as a lever.
If you are serious about doing a reimport of the VDub code please check it into the avisynth_2_6 CVS branch. If it is low fuss enough we can retrofit it to the 2.5.7 base. From what you are saying and from what I am seeing breaking the 2gb barrier is well out of scope for a bug fix release, it's going to be a major step with lots of testing and bugs.