Proposal for groovy snippet bindings

All your suggestions, requests and ideas for future development
Post Reply
devster
Posts: 335
Joined: 06 Jun 2017, 22:56

Proposal for groovy snippet bindings

Post by devster » 04 Sep 2019, 11:05

I'll start by saying that the following proposal might be useful for too few users compared to the possible advantage derived, but I believe it's worth arguing in its favour anyway.

It seems to me that a lot of bindings contained in MediaBindingBean which are derived from the file characteristics, are subject to the specific MediaInfo version and updates.
My proposal would then be to remove all "derived" file information bindings from there, such as vf, vc, hd, ..., while keeping high-level bindings such as video, audio and such. The removed bindings would be externalised in groovy snippets.
The way I imagine this working is a groovy snippet bundle similar to the scripts bundle (https://github.com/filebot/scripts/) which could then be updated independently from FileBot, and containing something like: hdr.groovy, hd.groovy, audio.groovy, etc.
The hdr.groovy would run when the {hdr} binding is used, and should always (based on cache) containing the most up-to-date version of the snippet.
It may also be structured in such a way that stuff like af and ac can be calculated for each audio stream.
e.g.

Code: Select all

audio.collect { au ->
	allOf
		{ af(au) }
		{ ac(au) }
	.join(" ")
}.join(" ")
Unfeasible? Useless?
I only work in black and sometimes very, very dark grey. (Batman)

User avatar
rednoah
The Source
Posts: 16827
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Proposal for groovy snippet bindings

Post by rednoah » 05 Sep 2019, 04:20

I'd argue that it's generally not a problem, since FileBot is shipped with a specific version of libmediainfo on most platforms.

The built-in bindings do abstract away underlying differences in libmediainfo, so that {vf} {vc} {hd} {hdr} etc work as best as possible regardless of what version of libmediainfo is being used.
:idea: Please read the FAQ and How to Request Help.

devster
Posts: 335
Joined: 06 Jun 2017, 22:56

Re: Proposal for groovy snippet bindings

Post by devster » 05 Sep 2019, 07:57

Ok, no problem.
However, breaking changes have happened with MediaInfo and they have a relatively regular release schedule.
Any change they implement requires a new version of FB as bindings are defined in a class (I think).
This way would allow faster updates (without upgrading to a beta version of FB) and could be published on GitHub for crowd contribution (while leaving the main logic hidden).
I only work in black and sometimes very, very dark grey. (Batman)

User avatar
rednoah
The Source
Posts: 16827
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: Proposal for groovy snippet bindings

Post by rednoah » 05 Sep 2019, 09:52

Well, the benefit there would be to allow binding updates without FileBot updates, similar to how scripting works. There's obvious security considerations for running remote code with live updates onto existing FileBot installations that need to be considered very carefully (i.e. this also wouldn't be allowed on the Mac App Store due to their remote code policies).

Additionally, lots of extra care would have to be taken to make sure code is always backwards compatible with all versions of FileBot. I don't want to be tied to supporting older versions (i.e. lots of extra testing with every release or change).

If libmediainfo changes significantly, new FileBot code is indeed required, but each FileBot release ships with a specific libmediainfo version, so it's not like things can suddenly break. At worst, a new beta release of FileBot might come with regression issues if libmediainfo is updated but FileBot isn't aware of changes in behaviour yet, but by the time there's a final release, these things are mostly figured out.

If anything, that leads us to continuous rolling updates for all of FileBot, including libmediainfo, embedded JRE, etc. Very difficult to do well cross-platform, and there's probably quite a few users that won't appreciate things changing under the hood without their consent.
:idea: Please read the FAQ and How to Request Help.

devster
Posts: 335
Joined: 06 Jun 2017, 22:56

Re: Proposal for groovy snippet bindings

Post by devster » 05 Sep 2019, 10:58

rednoah wrote:
05 Sep 2019, 09:52
Well, the benefit there would be to allow binding updates without FileBot updates, similar to how scripting works. There's obvious security considerations for running remote code with live updates onto existing FileBot installations that need to be considered very carefully (i.e. this also wouldn't be allowed on the Mac App Store due to their remote code policies).
This is what I meant, and the suggestion would exclusively target bindings which rely on MediaInfo/ffprobe, not series name or title. And as you mentioned, scripting already kind of does this.

This also would mean that no backward compatibility checks would be needed, as long as the files are valid groovy code and FileBot keeps exposing these bindings:

Code: Select all

915        @Define("media")
916        public AssociativeScriptObject getGeneralMediaInfo() {
917                return createMediaInfoBindings(StreamKind.General).get(0);
918        }
919
920        @Define("menu")
921        public AssociativeScriptObject getMenuInfo() {
922                return createMediaInfoBindings(StreamKind.Menu).get(0);
923        }
924
925        @Define("image")
926        public AssociativeScriptObject getImageInfo() {
927                return createMediaInfoBindings(StreamKind.Image).get(0);
928        }
929
930        @Define("video")
931        public List<AssociativeScriptObject> getVideoInfoList() {
932                return createMediaInfoBindings(StreamKind.Video);
933        }
934
935        @Define("audio")
936        public List<AssociativeScriptObject> getAudioInfoList() {
937                return createMediaInfoBindings(StreamKind.Audio);
938        }
939
940        @Define("text")
941        public List<AssociativeScriptObject> getTextInfoList() {
942                return createMediaInfoBindings(StreamKind.Text);
943        }
944
945        @Define("chapters")
946        public List<AssociativeScriptObject> getChaptersInfoList() {
947                return createMediaInfoBindings(StreamKind.Chapters);
948        }
I think it would also allow the use of different libmediainfo (I might wish to upgrade independently from FileBot yes, i realize it's not officially supported).
I only work in black and sometimes very, very dark grey. (Batman)

Post Reply