Force square pixels (DAR=SAR)

[flossy83]

I can consider introducing a hidden option to always output DAR as SAR.

This would be much appreciated, for purpose of backwards compatibility with scripts.

In that case we might put something like SquarePixels = true in avisynth_filter.ini and force the legacy behaviour.

[CrendKing]

Just to make sure, you want the output DAR to be the same as the output SAR, not the input SAR, correctly? For instance, if your script resize a 720x576 video to 1024x576, you want the output DAR to be changed to 16:9, regardless of the original input DAR, right?

[CrendKing]

Also just FYI, the RFPs _SARNum and _SARDen are about the source frames. Even you use the option, they won't be 1:1. But I believe you can overwrite them to whatever you need in the script.

[flossy83]

Thank you, that is working as I had hoped.

Unfortunately the framecounter thing is a still dealbreaker for me as I'm using it for a few things. eg. with TDecimate I'm using override file to flag certain frame ranges to be handled as "video" instead of "film" , such as the intro sequence to TV shows which contain multiple cadences, so I just flag the whole intro frame range as "video" to handle mixed cadences better.

Are we absolutely sure there is no way to somehow get timecode info from upstream? Maybe some other hack/bodge way of getting it from the media player? Like maybe the WinTitle contains it or something? Maybe only for certain media players? I'm using MPC-HC, maybe it has some interface to get time code? "Where there's a will, there's a way" :D

[CrendKing]

Are we absolutely sure there is no way to somehow get timecode info from upstream?

IMediaSeeking can provide time information of the current playback position and video duration, but there is no way to convert the time to absolute frame number, since each frame's duration could be variable. You can only get precise frame number by counting from frame 0.

---

Since you mention that you are blocked by this frame counter requirement, which is a no-go, may I revert the ForceSquarePixels option? I'd rather not release a feature that nobody uses.

[flossy83]

Hmm... so the issue with frame counter precision also happens in standalone Avisynth:

DirectShow(): "DirectShow video decoders are not required to support frame-accurate seeking. In most cases seeking will work, but on some it might not"

FFmpegSource2(): "May be frame accurate on good days"

It seems that LWlibavVideoSource is the only frame-accurate one: "Parsing all frames is very important for frame accurate seek. "

In testing I did notice that DirectShow() was off by a few frames (it uses LAV Video Splitter/Decoder since that is highest merit on my system). But this wasn't a deal-breaker for me as it just meant my intro sequence was processed for a few extra frames.

Looking at the link it seems there is...

IMediaSeeking::GetCurrentPosition: "The returned value is expressed in units of the current time format. To determine the current time format, call the GetTimeFormat method"

IMediaSeeking::GetTimeFormat: "The GetTimeFormat method retrieves the time format that is currently being used for seek operations...See Time Format GUIDs"

Time Format GUID's: "TIME_FORMAT_FRAME = video frames"

IMediaSeeking::SetTimeFormat: "The SetTimeFormat method sets the time format for subsequent seek operations."

Well, it's your project and I don't want to pressure you, so the decision is yours.

[CrendKing]

Again, AviSynth requests frames in order. When you seek in the video player, from AviSynth's perspective it is a completely new stream, starting from frame 0. Unless there is some mapping mechanism between virtual frame number (the frame number we are using right now) and actual frame number in file (which we can estimate with IMediaSeeking) introduced in AviSynth, this is not possible.

[CrendKing]

FYI, since you won't use the ForceSquarePixels option, I have retracted the commit. Let me know if I misunderstood you.