During the development of my Rust crate that can be used to write AviSynth+ plugins, these questions came up. Please don't hesitate to answer only a subset of questions at a time, if need be. I'll keep commenting out questions that were already answered to keep things clear (ideally, always quote me).
How should a filter react when another filter's GetFrame() method returns a null pointer PVideoFrame? I experienced process crashes when returning a null pointer PVideoFrame myself. When a filter implementation in a third-party Rust plugin yields a frame with incorrect metrics (width, height, color format), I already block the frame and deliver a frame with an error text message instead. I could also yield such a message frame to a Rust plugin when a third-party C++ plugin yields a null pointer PVideoFrame, if you don't have a better idea about how to handle this. When I'd do that, I'd like to write a reference to the plugin or plugin function onto the frame, however. For this, I'd need a function to, e.g., get the .avs script function name that's associated with the IClip. Is that realistic? Are you willing to implement this?
May VideoInfo::image_type validly and meaningfully contain IT_BFF or IT_TFF when the IT_FIELDBASED bit is 0? For frame-based clips, are the IT_BFF/IT_TFF flags read by AviSynth+, or may they validly and meaningfully be read by plugins? If yes, why is GetParity() documented as working with frame-based clips? Wouldn't that be two sources for the same piece of information? If no, please document in avisynth.h for VideoInfo::image_type that, if IT_FIELDBASED isn't set, the other bits are ignored.
Can the return values from IClip::GetParity() be derived from VideoInfo::image_type? If not, why?
What's the enum defining CS_MPEG2_CHROMA_PLACEMENT, CS_YUY2_CHROMA_PLACEMENT, CS_TOPLEFT_CHROMA_PLACEMENT etc. about? Is it this? The large comment in struct VideoInfo says: Other YV12 specific (not used?) C 20-22 Chroma Placement values 0-4 see CS_xxx_CHROMA_PLACEMENT. So, it's currently always irrelevant? How can it become relevant, because the color format constants must not change, right? Adding another VideoInfo member, as with image_type?
During the development of my Rust crate that can be used to write AviSynth+ plugins, these questions came up. Please don't hesitate to answer only a subset of questions at a time, if need be. I'll keep commenting out questions that were already answered to keep things clear (ideally, always quote me).
GetFrame()method returns a null pointerPVideoFrame? I experienced process crashes when returning a null pointerPVideoFramemyself. When a filter implementation in a third-party Rust plugin yields a frame with incorrect metrics (width, height, color format), I already block the frame and deliver a frame with an error text message instead. I could also yield such a message frame to a Rust plugin when a third-party C++ plugin yields a null pointerPVideoFrame, if you don't have a better idea about how to handle this. When I'd do that, I'd like to write a reference to the plugin or plugin function onto the frame, however. For this, I'd need a function to, e.g., get the .avs script function name that's associated with theIClip. Is that realistic? Are you willing to implement this?May
VideoInfo::image_typevalidly and meaningfully containIT_BFForIT_TFFwhen theIT_FIELDBASEDbit is0? For frame-based clips, are theIT_BFF/IT_TFFflags read by AviSynth+, or may they validly and meaningfully be read by plugins? If yes, why isGetParity()documented as working with frame-based clips? Wouldn't that be two sources for the same piece of information? If no, please document inavisynth.hforVideoInfo::image_typethat, ifIT_FIELDBASEDisn't set, the other bits are ignored.Can the return values from
IClip::GetParity()be derived fromVideoInfo::image_type? If not, why?What's the enum defining
CS_MPEG2_CHROMA_PLACEMENT,CS_YUY2_CHROMA_PLACEMENT,CS_TOPLEFT_CHROMA_PLACEMENTetc. about? Is it this? The large comment instruct VideoInfosays:Other YV12 specific (not used?) C 20-22 Chroma Placement values 0-4 see CS_xxx_CHROMA_PLACEMENT. So, it's currently always irrelevant? How can it become relevant, because the color format constants must not change, right? Adding anotherVideoInfomember, as withimage_type?