Page 1 of 1
Proposal for groovy snippet bindings
Posted: 04 Sep 2019, 11:05
by devster
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?
Re: Proposal for groovy snippet bindings
Posted: 05 Sep 2019, 04:20
by rednoah
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.
Re: Proposal for groovy snippet bindings
Posted: 05 Sep 2019, 07:57
by devster
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).
Re: Proposal for groovy snippet bindings
Posted: 05 Sep 2019, 09:52
by rednoah
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.
Re: Proposal for groovy snippet bindings
Posted: 05 Sep 2019, 10:58
by devster
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).