search

mpv-player / mpv

🎥 Command line video player
https://mpv.io
Other
28.14k stars 2.89k forks source link

early access to frame props in vo_vapoursynth #1026

Closed bjin closed 10 years ago

bjin commented 10 years ago

I'm using the vapoursynth video filter, and in some scenario I need the pixel aspect ratio in scripts. The problem is that the _SARNum and _SARDen properties are embedded into frame node instead of video node. To the best of my knowledge, it's only accessible via FrameEval-like functions in scripts and it's inefficient I think. The critical shortcoming is that these frame properties can be accessible only after video output format was determined (video_in.get_frame(0) leads to dead lock), but in some cases video output format might depend on these properties (for example a PAR-aware upscale scripts).

While vapoursynth considering all the frame properties being "variable" among frames by default, some of these properties like _SARNum/Den _ColorRange/Space and _Field are actually constant in mpv. So I think it's reasonable to provide these properties globally to scripts for early accessing.

With a brief glance at the code, I think there are several workarounds:

  1. Allow accessing frames from upperstream of the filter chain during filter creation stage by implementing a general frame buffering mechanism in vf system.
  2. add video_in_dh video_in_csp scripts variables(like video_in) for fields from mp_image_params
  3. add video_in_dummyframe scripts variable returning a dummy frame with frame properties which are constant for all frames.

I think the first approach is rather complicated, and I prefer the third one myself. For the latter two approaches, I think I'm able to provide patches.

ghost commented 10 years ago

(video_in.get_frame(0) leads to dead lock)

That seems strange, although I don't know exactly when it's called. If it's inside vsscript_evaluateFile(), then yeah, it will deadlock, because the function will never return, because the output node doesn't return frames before initialization is completed. This could probably be fixed by running initialization in a thread, but I'm not sure if I want to go there.

some of these properties like _SARNum/Den _ColorRange/Space and _Field are actually constant in mpv.

That is right. In mpv, filters are completely reinitialized when any frame properties change.

  1. Allow accessing frames from upperstream of the filter chain during filter creation stage by implementing a general frame buffering mechanism in vf system.

Huh? There's already enough buffering going on, especially in vf_vapoursynth, which uses a buffer queue for input to translate the mpv push filter API to vapoursynth's pull API.

  1. add video_in_dh video_in_csp scripts variables(like video_in) for fields from mp_image_params

Sounds reasonable and simple.

  1. add video_in_dummyframe scripts variable returning a dummy frame with frame properties which are constant for all frames.

Sounds a bit weird. Why a dummy frame?

bjin commented 10 years ago

Huh? There's already enough buffering going on, especially in vf_vapoursynth, which uses a buffer queue for input to translate the mpv push filter API to vapoursynth's pull API.

Sorry I didn't make it clear, by buffering I mean memorizing all frames which were passed during filter chain creation stage, so these frames can be used later. I admit it's a pretty stupid idea.

Sounds reasonable and simple.

Okay, then I will probably take this.