Thread: Avisynth+
View Single Post
Old 31st October 2017, 16:26   #3699  |  Link
TheFluff
Excessively jovial fellow
 
Join Date: Jun 2004
Location: rude
Posts: 1,100
Continuing the discussion from here, let's talk about those nasty memory offsets again.

In avisynth.h from 2.6:
Code:
size_t (VideoFrameBuffer::*GetDataSize)() const;
Code:
size_t (VideoFrame::*GetOffset)(int plane) const;
Code:
class VideoFrameBuffer {
  BYTE* const data;
  const size_t data_size;
  (...)
  protected:
    VideoFrameBuffer(size_t size);
  (...)
  public:
    size_t GetDataSize() const AVS_BakedCode( return AVS_LinkCall(GetDataSize)() )
Code:
class VideoFrame {
  (...)
  const size_t offset;
  const int pitch, row_size, height;
  const size_t offsetU, offsetV; // U&V offsets are from top of picture.
  (...)
  VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height);
  VideoFrame(VideoFrameBuffer* _vfb, size_t _offset, int _pitch, int _row_size, int _height,
             size_t _offsetU, size_t _offsetV, int _pitchUV, int _row_sizeUV, int _heightUV);

  void* operator new(size_t size);

  // generally you shouldn't use these three
  (...)
  size_t GetOffset(int plane=0) const AVS_BakedCode( return AVS_LinkCall(GetOffset)(plane) )
In Avs+ all these size_t's are (32-bit signed) int instead. In Avisynth it doesn't really matter in practice because a frame is always allocated as one big chunk of memory, and nobody really has any use for more than 2^31 bytes of vfb. If you ever wanted to stop doing this though and use one individual pointer per plane like VS does, this won't fly because you can't reliably stuff a 64-bit pointer in a 32-bit integer, and it's generally bad coding practice to not use size_t (or ptrdiff_t) for these things.

Way back in the day ultim claimed that he didn't want to follow IanB's lead and switch to size_t because it'd break a number of completely irrelevant plugins (that would have been trivial to recompile). I didn't realize it at the time, but I'm pretty sure that in practice, he was wrong even on the technical aspect. If you look at these functions above, the only one that conceivably might end up getting called by plugins in reality is VideoFrame::GetOffset(), and I'm 99% sure that its return value just gets passed in a register and zero-extended, so as long as you keep passing the same old less-than-2^31 offsets, everything will keep working just fine (but most plugins just use GetRead/WritePtr). New VideoFrames and VFB's are only constructed by env->NewVideoFrame, so changing the signature of the VideoFrame constructor shouldn't be an issue.

Last edited by TheFluff; 31st October 2017 at 16:36.
TheFluff is offline