Iamp;rsquo;ve got a few questions about using avisynth.h ...
What is the correct way to access the current frame number? Is vi.num_frames the right value to look at? GetSequenceNumber()?
Is vi.field_based a reliable indicator of whether the material is interlaced? With interlaced material, is vi.height the height of the frame or the field? And is there a way to distinguish the top field?
Is there a way to determine the video format (NTSC/PAL/SECAM, compressed, etc.)?
Iamp;rsquo;m currently handling memory cleanup in the video filter destructor. (I may be gettings some terminology wrong, here amp;mdash; Iamp;rsquo;ve never used C++ before.) Is that a reasonable place to do so? Or would it be better to make use of ShutdownFunc or AtExit?
Thanks!
The current frame number is passed as a parameter to GetFrame().
Yes, use the constructor to get the memory and the destructor to free it.
Isnamp;rsquo;t GetFrame()s n relative to the current frame? So the current frame is always 0, which isnamp;rsquo;t very informative.
What Iamp;rsquo;m looking for is the absolute frame number amp;mdash; i.e., what position in the video is the current frame? My intention is to check whether the current frame is contiguous with the last one which showed up.
Never mind amp;mdash; it is the absolute frame number.
My intention is to check whether the current frame is contiguous with the last one which showed up.
AFAIK the current frame will always be contiguous with the last one because the current frame is always 1 more than the last one.
The filter before yours will end up delivering its frames sequentially regardless of how it obtained them in the the 1st place.
I hope I've got this right
regards
Simon
@siwalters
gt;the current frame is always 1 more than the last one
That is not correct. If you go into (for example) VirtualDub and use the Edit window to goto frame 20 followed by goto frame 30, the filter chain will receive requests for 20 followed by 30. In other words, random access is possible.
Sorry - I was in linear thinking mode
Simon
Yay amp;mdash; Thanks to neuron2 for the tip about frame numbers. PeachSmoother can now act much more reasonably when jumping within a clip.
Does anyone know about my questions on interlace, too? GetParity() is about as close as I can find -- is TRUE or FALSE for it supposed to return whether the field is top?
PS: Ooh amp;mdash; Iamp;rsquo;m a senior, now.
Got it amp;mdash; The field/frame system is described in the docs for the existing filters which deal with interlace.
Is vi.field_based a reliable indicator of whether the material is interlaced? With interlaced material, is vi.height the height of the frame or the field? And is there a way to distinguish the top field?
Lindsey -
I missed these questions before somehow. And I'm not sure of the answers, but that won't stop me here.
I don't think vi.field_based is completely reliable because filters like my deinterlace/IVTC do not know to set it to frame based when deinterlacing.
I think vi.height is always the frame heigth.
And the GetParity() returns its best guess but is not set correctly from some codecs. To be honest I thought it was always wrong until someone pointed out that MPEG2DEC.dll seems to usually set it correctly. But this is why many of my own filters make people tell with a parm, though I may add an additional value that says to trust whatever Avisynth currently thinks it is.
I recently posted a filter function to make it easier to explore this. Search the last month for TopFirst.
edit: here
- Tom
Thanks for clearing that up amp;mdash; though it would be nicer if it were perfectly reliable.
Hereamp;rsquo;s another question which has come up amp;mdash; Is there an easy way to write a string to the output, or to otherwise display a (changing) result?
Hmm... Itamp;rsquo;s possible to call another filter from a filter, isnamp;rsquo;t it? Is the Subtitle filter the best way to show text?
).
Just include info.h and you'll be able to use :
void DrawString(PVideoFrame amp;dst, int x, int y, const char *s) It's easier to use and it's GPL
Thanks! Thatamp;rsquo;s exactly what I was looking for.
... writing down as upcoming feature for 2.5
Decomb supports two ways of outputting strings: 1) the one mentioned by sh0dan, and 2) OutputDebugString() in conjunction with the DebugView utility. The latter allows for capturing the output into a file, while the former is more convenient to use for simple tweaking. |