search

delight-im / MovieContentFilter

Watch movies with the freedom (not) to filter
https://www.moviecontentfilter.com/
GNU Affero General Public License v3.0
143 stars 10 forks source link

Why a new filter format? #10

Closed bmaupin closed 7 years ago

bmaupin commented 7 years ago

I'm interested in creating some filters and I'm reviewing my options. I see there are a handful of formats (EDL, M3U, XSPF) as well as MCF. I found the document for the MCF specification, but I don't see any explanation as to why I would want to use it over any of the others, or why a new format was needed in the first place (<insert obligatory reference to https://xkcd.com/927/ >). Is this information available somewhere?

Thanks!

ocram commented 7 years ago

Thanks for your question!

The answer is actually quite simple: XSPF and M3U aren't filter formats. They're playlist formats. So what they do, or what they have originally been intended to do, is something entirely different. EDL, then, certainly is some kind of filter format, but an incredibly simple and basic one. None of these formats do everything that we need. (So the comic does not apply, by the way.)

EDL cannot block video only, for example. And every EDL file is necessarily one that has been customized for one specific viewer. It contains a fixed plan of what to block and what to show. It cannot be adjusted with preferences. So EDL is always something that has to be compiled for one specific viewer by a service that does just that. We do that.

Worse, XSPF and M3U cannot block anything, since they're playlist formats, where you usually don't want to hide or mute anything, but just play everything that is in your list. But since you can split a movie into any number of virtual pieces and play them back while skipping some, it is easy to work around the missing support for blocking both video and audio at the same time. Now how do you block video only, or audio only? Turns out that you can't. But if you target VLC player only, you can, using some custom extensions that VLC provides. Again, how do you adjust the filters with your custom preferences? You can't. You need a service that compiles these files specifically for you. We do that.

So what is the MCF format? MCF has been created specifically for the purposes of this project and for the task of filtering content in movies and TV shows. It can hold much more information that is relevant for us. But in order to avoid the problem of missing support in media players for this new format that is only used by this single project, we provide compiled XSPF, M3U and EDL files that do most of what we want. Until we have some plugins for media players or browsers, that will be how filters are applied when you want to view a filtered movie or TV show.

The MCF format can contain all the data that is relevant for filtering video and audio. That means everybody can filter media files, adjusted to their personal preferences, with a single MCF file, because it contains everything. XSPF, M3U and EDL will never be able to do that. The ultimate goal is that you can adjust your preferences – which you currently do on our website – right in your media player and use the same MCF file that everybody else uses – or perhaps none at all, since all data can be fetched via an API instead of you having to import filter files manually. Again, we need plugins for that. In the meantime, XSPF, M3U and EDL will help us a lot.

By the way, you create filters once via our website, without deciding for any specific format, and afterwards, you will be able to export into any of those four formats. At least, that's one way to do it. You certainly can write your filters by typing the filter markup manually.

This information has indeed not been available anywhere. Sorry! But now it's here, at least :)

Hope that helps! Will be happy to answer follow-up questions.

bmaupin commented 7 years ago

Perfect, that's exactly what I was looking for.

I'll probably create filters by hand for the time being since I'm too lazy to sign up for another site. Speaking of which, why is a login required to download filters? Personally, I'd love to see them in git that way we can have history, pull requests, etc. But I know that's not very user friendly for most people and you'd lose features like comments, annotations, voting, etc.

I do have a few questions regarding the spec itself:

Thanks!

ocram commented 7 years ago

I'll probably create filters by hand for the time being since I'm too lazy to sign up for another site.

I understand the reluctance when it comes to signing up for another account at just another website. Sorry for that! However, everything that can easily be offered without registration is viewable to the public. For everything else, the quick sign up really pays off in no time.

You can view the specification, browse movies and TV shows, view individual annotations, etc. But when it comes to contributing content, authentication is required for obvious reasons, just as with virtually any website. We don't want spam. We don't want abuse. We don't want deliberately wrong content. And we want to be able to judge, and some time later probably reward, users who continuously make good contributions.

By the way, I have to discourage you from writing MCF filters by hand, unfortunately, in case you tried that. While I'm convinced that the MCF format is quite good (though not perfect (yet), of course!) for the purposes of content filtering in movies and TV shows, the tools are just not there, yet. Our website can write MCF, but it does not read it. Why should it? Since there are no other projects using that format, interoperability isn't a concern yet. And most users won't write MCF manually, anyway, so the development time is better spent working on other features.

If you care about your time, the sign up is extremely quick and writing the filters is hard enough to justify the registration right during the creation of the first filter. It will pay off.

If you care about privacy, the service is open source, as you see, and it requires only your email address and a password that is stored as a strong hash (bcrypt), which you can verify.

Speaking of which, why is a login required to download filters?

Downloaded filters are always customized, and the preferences that are used for customization are stored in your account. So that's why we require sign up before download.

We did the first prototype without sign up, login and accounts -- just a server-less application using HTML and JavaScript. But the major motivation behind the re-write as a server-side application was that we can make features much more convenient. The biggest pain point was collaboration, of course.

Personally, I'd love to see them in git that way we can have history, pull requests, etc. But I know that's not very user friendly for most people and you'd lose features like comments, annotations, voting, etc.

Exactly. Agreed, that would be useful for (some) developers. That solution would probably be quite clean as well. But we want to address everybody, not just developers, and not just developers using Git.

Apart from that, we can have all those features (versioning, "pull requests", etc.) without Git. We can implement this in the application.

I looked for the spec in git and found it here: https://github.com/delight-im/MovieContentFilter/blob/master/Website/views/specification.html. Is this the official source? In particular it'd be nice to see changes between versions.

The official version is the result of that view, actually, which is here: https://www.moviecontentfilter.com/specification

For now, there is only one version, so no need to show changes yet. But we will definitely think about versioning when the time has come. Probably, we'll just archive the HTML of the old versions, somehow.

Any plans for a tool to verify the validity of an MCF file? Having the spec written down is essential, but a tool could eliminate errors due to misinterpretation.

You are right. But again, given that nobody really needs to write MCF manually (yet), the development time is better spent in other parts of the service.

Does MCF support WebVTT comments? I think they'd be helpful to annotate filter files at a high level (as opposed to at the filter level)

Not at the moment. Could you describe the use case for this more clearly? Perhaps this is indeed something that we should consider, but right now, I don't really see why we need this. What do you want to describe in the comments, specifically?

One problem I've encountered already is that, when the screen goes black and/or audio is muted, you want to know what happens (roughly), nevertheless. So a short description like "Someone is brutally killed", shown on the black screen, would be helpful perhaps. But that introduces new problems: Maybe you need this description adjusted to the audience (e.g. age level) as well. And even more important: This would need translation or internationalization, whereas the other features of the filter do not.

especially since there can be so many variations of the source video based on how it was transcoded, etc.

There should be none, ideally. When it comes to different speeds, starts or ends of the material, the service does already account for that. When it comes to different cuts, we encourage users to use the "uncut" or "canonical" versions of the film, since cutting is what can be done using this project. No need to use a softened version as your source material. The only alternative probably is storing different versions as different films in the database.

As I've played with this a little bit, it seems there's one missing piece and I'm not quite sure how to handle it. I'd imagine watching a filtered video could be quite a choppy experience if scenes are being abruptly skipped and so on. It would be nice for there to be a way to filter scenes surrounding undesired content so that the video plays seamlessly for the viewer. One idea I have would be to filter for a smooth viewing experience and then to annotate the actual timing of the content

That's correct. This is absolutely a major issue that we should keep in mind and discuss going forward. But for now, we decided that having films with undesired scenes cut is a great first step. Optimizing for a more seamless viewing experience may be a good second step.

A second idea would be to use overlapping filters

Absolutely, you can use multiple filters to work around this. But instead of having different filter groups with overlapping timestamps, we use single filter groups with multiple filters. Anyway, you can use the dispensable category or you can use the actual category with a lower severity.

bmaupin commented 7 years ago

If you care about your time, the sign up is extremely quick and writing the filters is hard enough to justify the registration right during the creation of the first filter. It will pay off.

I tried the website, and it's a good start, but I had a lot of issues:

Downloaded filters are always customized, and the preferences that are used for customization are stored in your account. So that's why we require sign up before download.

I get that, but I still think it'd be nice to be able to download the raw filter without having to log in.

especially since there can be so many variations of the source video based on how it was transcoded, etc.

There should be none, ideally. When it comes to different speeds, starts or ends of the material, the service does already account for that. When it comes to different cuts, we encourage users to use the "uncut" or "canonical" versions of the film, since cutting is what can be done using this project. No need to use a softened version as your source material. The only alternative probably is storing different versions as different films in the database.

I agree that in an ideal world there would be no variations, but of course that isn't the case. It's common for the official release of a film in certain countries to be cut. Often the same film can be released in the same country in different versions (e.g. rated, unrated). It'd be nice to have a way to annotate this in the source file. The only way at the moment to note the differences between filter files would be to change the filename, but I don't think that's reliable.

I guess on the website a new film entry could be created to distinguish between the different releases, but I'd really love to see the filter format itself be able to stand on its own. Of course the site is great, but websites come and go. If the specification is solid it can easily outlast any website.

Additionally, in my opinion comments are needed for the viability of any format. Any time I work with a format that doesn't support them (JSON) it discourages me from using them in the future.

Absolutely, you can use multiple filters to work around this. But instead of having different filter groups with overlapping timestamps, we use single filter groups with multiple filters.

Can you give an example of what this would look like? This is the closest thing I could find but I don't see how it solves this problem:

01:02:31.020 --> 01:02:49.800
fear=low
language=high=audio

Thanks for your patience with all my questions. I think this is a great project and I'm really interested in its success!

ocram commented 7 years ago

I tried the website, and it's a good start, but I had a lot of issues

Thanks, and sorry for those problems!

I know the site isn't perfect yet, but perhaps it never will be, I'm afraid. You can only push web technology so far, and the web is clearly not built for advanced video playback, editing and applying annotations. It's amazing that the web has actually reached a state where you can do these things.

The built-in player only handles certain video formats

You're right. It's a pity! I would even say this is the biggest problem with the web player. Chrome may support more formats than Firefox, depending on the platform, but that's all we get. It's not sufficient, and this is the main reason why we need https://github.com/delight-im/MovieContentFilter/issues/5.

It lacks fine-grained playback controls necessary for correct timing

Could you describe what you'd need here? This sounds like something that could be fixed, perhaps. By the way, this is what slow playback can be used for. There are two buttons to decrease or increase playback speed. You really need slow playback for accurate timing, at least with the current version.

There's no way to edit contributions (you'll probably need to remove what I added)

While adding them in the editor? Something like an "undo" action? Or later, when viewing individual annotations on the website? We probably need the latter anyway. But it may be hard to identify annotations without the video later.

As mentioned on the site, MCF downloads aren't supported

They should be available. Actually, they should be grayed-out (because they're not useful for the average user) but selectable, nonetheless. That may be bad UX, of course.

I tried downloading the filter for Ex Machina and the times were way off (99 hours, for example)

Can we investigate this specific issue? What annotations were off, in which format? Seems like it would be a simple fix. It may also just be a misunderstanding, or based on wrong input times when downloading the filter (start time and end time).

I get that, but I still think it'd be nice to be able to download the raw filter without having to log in.

Since the MCF format does contain everything, there's no customization needed, so we could indeed offer that format without sign up or login, as far as I can see.

I agree that in an ideal world there would be no variations, but of course that isn't the case. It's common for the official release of a film in certain countries to be cut. Often the same film can be released in the same country in different versions (e.g. rated, unrated).

As I said, there's probably no technical solution to this. Users are encouraged to use the "most complete" or "canonical" version. This is included in the help text shown before you contribute. But apart from that, we'll probably need separate film entries.

I guess on the website a new film entry could be created to distinguish between the different releases, but I'd really love to see the filter format itself be able to stand on its own. Of course the site is great, but websites come and go. If the specification is solid it can easily outlast any website.

Couldn't agree more, we should definitely do this. Thanks!

So what do you suggest? A comment on the file level describing the film's title and version?

Additionally, in my opinion comments are needed for the viability of any format. Any time I work with a format that doesn't support them (JSON) it discourages me from using them in the future.

Agreed, again. We should probably support comments in other areas of the files as well.

Can you give an example of what this would look like? This is the closest thing I could find but I don't see how it solves this problem

01:02:31.020 --> 01:02:49.800
fear=low
language=high=audio

01:02:49.800 --> 01:02:57.520
fear=medium
language=high=audio

01:02:57.520 --> 01:03:02.520
fear=high
bmaupin commented 7 years ago

I know the site isn't perfect yet, but perhaps it never will be, I'm afraid. You can only push web technology so far, and the web is clearly not built for advanced video playback, editing and applying annotations. It's amazing that the web has actually reached a state where you can do these things.

Yes, I'm actually quite impressed that so much can be done through the web interface.

Could you describe what you'd need here? This sounds like something that could be fixed, perhaps. By the way, this is what slow playback can be used for. There are two buttons to decrease or increase playback speed. You really need slow playback for accurate timing, at least with the current version.

With filters like these, I think accuracy is key. Features like being able to move forward/backward one frame at a time or jump to a specific spot in a video are indispensable, and keyboard shortcuts help speed things up. And of course support for more formats is nice. For me this is where the ability to upload filters would be appreciated. Then writers of filters could use their preferred tools to create them since there are already so many full-featured video manipulation tools. This could even reduce the need to have all of these features in the website.

I guess I see it as a tradeoff: have a good-enough solution built into the website, and rather than spending the development time making it on par with existing tools, spend that time adding some basic filter import functionality for users who prefer to use more advanced tools.

However, I understand the ability to upload filters would add a lot of work because the logic for filter validation would need to be included, and I'm sure not many would be writing them by hand. If even the ability to seek to a specific time was included, that would at least make the process of uploading existing filters easier.

To give a concrete example, I have a very small number of filters that I'd previously written. Discovering the MCF format was great because it gives me a way to document them in a standard way so others can use them too. But to add them to the website I'd effectively have to redo the work of finding the exact spots in the videos by hand with less capable tools. No offense intended--I reiterate that I'm quite impressed with what the website is able to do.

You're right. It's a pity! I would even say this is the biggest problem with the web player. Chrome may support more formats than Firefox, depending on the platform, but that's all we get. It's not sufficient, and this is the main reason why we need #5.

Even VLC lacks features like going back one frame or seeking to a specific time, but I know the Jump to time (Previous frame) plugin provides it, even if it is a bit kludgy to use. At least it'd be an improvement.

While adding them in the editor? Something like an "undo" action? Or later, when viewing individual annotations on the website? We probably need the latter anyway. But it may be hard to identify annotations without the video later.

I made a bogus addition yesterday without realizing I wouldn't be able to remove it after the fact. Something along the lines of a preview screen that shows pending submissions before submitting them might help.

Can we investigate this specific issue? What annotations were off, in which format? Seems like it would be a simple fix. It may also just be a misunderstanding, or based on wrong input times when downloading the filter (start time and end time).

I was trying to do the least effort to download the MCF file, so after clicking Download filter, I clicked the sample start/end times which filled them in for me, and then chose MCF and downloaded the filter. It looks like the real issue is that the start/end times weren't used in the resulting filter:

START 00:00:00.000
END 99:59:59.999

So I tried typing in some different values and I got the same result.

So what do you suggest? A comment on the file level describing the film's title and version?

I can provide some suggestions if you'd really like but to be honest I'm not too picky with how it's implemented. I saw WebVTT supports comments through the NOTE syntax, and being a subset of WebVTT I'm guessing it'd need to be something compatible with it.

But instead of having different filter groups with overlapping timestamps, we use single filter groups with multiple filters.

So to go back to my previous example:

00:00:06.075 --> 00:00:10.500
dispensable # Viewer friendly cut

00:00:08.000 --> 00:00:09.975
violence=high # Actual undesired content

Would it look like this?:

00:00:06.075 --> 00:00:08.000
dispensable

00:00:08.000 --> 00:00:09.975
dispensable
violence=high

00:00:09.975 --> 00:00:10.500
dispensable

Thanks!

ocram commented 7 years ago

With filters like these, I think accuracy is key.

I agree. If you can't annotate with sub-second accuracy, it's useless. But the real question is how much precision you need after all.

Features like being able to move forward/backward one frame at a time or jump to a specific spot in a video are indispensable

Regarding the first point, I'd disagree. If you can have annotations that are accurate up to 0.1 seconds, that's fine, I'd say. In practice, you will never really need more. And when it comes to scaling (for different lengths or speeds) that's probably all we can get, anyway. Slow playback can be really helpful and good enough for most practical needs. Nevertheless, I don't think we even have to decide on this one. There's nothing in the specification or overall project that prevents us from having accuracy up to a single frame – except for the web editor, which is not good enough, as we've agreed already.

and keyboard shortcuts help speed things up

Right, keyboard shortcuts have not been implemented yet. But that would be a quick addition, once we have decided which shortcuts to support. Let's track this in https://github.com/delight-im/MovieContentFilter/issues/11.

And of course support for more formats is nice.

This is really something where we can only hope and wait for browser vendors to improve support. Alternatively, we need native software, e.g. said VLC plugin.

For me this is where the ability to upload filters would be appreciated. Then writers of filters could use their preferred tools to create them since there are already so many full-featured video manipulation tools.

Of course, there are lots of great tools for video manipulation. But none of those support the MCF format. If they did, or if support could be added, that would absoutely something that could get priority over the web-based editor. But without direct MCF support, writing the MCF files (manually) is tedious and error-prone.

This could even reduce the need to have all of these features in the website.

I don't think this is true. In order to appeal to the "average user", and to support them, which we definitely want, we will always need those features in an easily accessible way.

However, I understand the ability to upload filters would add a lot of work because the logic for filter validation would need to be included, and I'm sure not many would be writing them by hand.

This won't even be that much work. Compared with all the other features that have been added, this will be a moderate amount of work. The only reason it hasn't already been done is really that the audience for this feature is quite small. Anyway, let's track this here: https://github.com/delight-im/MovieContentFilter/issues/12

If even the ability to seek to a specific time was included

In Firefox, you can just right-click the video and choose "Show controls". That makes the timeline show up, among other features. In Chrome, that can be done in a similar way, probably. As a last resort, you can always right-click the video and edit the DOM by adding a controls attribute to the <video> element. We could even make this the default if it's useful that way. It has not been made the default so far because the additional controls add more clutter.

But to add them to the website I'd effectively have to redo the work of finding the exact spots in the videos by hand with less capable tools. No offense intended--I reiterate that I'm quite impressed with what the website is able to do.

Agreed, the import would be useful here and should be included soon. Again, the motivation for not including it so far has been that writing an MCF file manually in order to import it on the website so that you can finally export the data as an MCF file again didn't make that much sense, given that there's an editor. That changes, of course, if one doesn't want to use the editor.

Even VLC lacks features like going back one frame or seeking to a specific time, but I know the Jump to time (Previous frame) plugin provides it, even if it is a bit kludgy to use. At least it'd be an improvement.

VLC supports almost every format available, is free (even open source) and available on most platforms, so that would be a great start. If you can recommend any other video manipulation tools, why shouldn't we develop plugins for multiple tools. But right now, we have none. And, by the way, VLC supports really slow playback as well, which is quite helpful already.

I made a bogus addition yesterday without realizing I wouldn't be able to remove it after the fact. Something along the lines of a preview screen that shows pending submissions before submitting them might help.

I'd favor a possibility to delete individual annotations over a preview screen. Let's track the former here: https://github.com/delight-im/MovieContentFilter/issues/13

START 00:00:00.000 END 99:59:59.999

Sorry, now I remember the reason for this. This had been done so that you can store all data in the MCF format with maximum precision. The timings are scaled up before they're rounded or truncated. This isn't really an issue because these representations are equivalent, given that the reference times (which you cited here) are stored in the file as well.

But for easier reading (by humans), we should indeed let users scale the MCF timings during export, just as you tried to do.

So what do you suggest? A comment on the file level describing the film's title and version?

I can provide some suggestions if you'd really like but to be honest I'm not too picky with how it's implemented.

I'd really like to have "type" (movie, series or episode), "title", "year", and optionally "season number" and "episode number in season". Just to have some structured data in the MCF file -- which is already available in the database, so why discard the structure and lose that information. We can add an additional comment field for other information that doesn't fit in the fields above.

and being a subset of WebVTT I'm guessing it'd need to be something compatible with it

It's a subset, not a superset, so MCF doesn't support everything that WebVTT does, but rather a specific selection of the features that is useful in our context.

00:00:06.075 --> 00:00:08.000 dispensable

00:00:08.000 --> 00:00:09.975 dispensable violence=high

00:00:09.975 --> 00:00:10.500 dispensable

Exactly! Hope that makes sense, at least a little bit. While it's harder to write (for humans), it's easier to read and process for both humans and machines.

bmaupin commented 7 years ago

I'd really like to have "type" (movie, series or episode), "title", "year", and optionally "season number" and "episode number in season". Just to have some structured data in the MCF file -- which is already available in the database, so why discard the structure and lose that information. We can add an additional comment field for other information that doesn't fit in the fields above.

A couple other I think would be helpful:

It's a subset, not a superset, so MCF doesn't support everything that WebVTT does, but rather a specific selection of the features that is useful in our context.

Yes, so the options for adding comment support to MCF would be limited to what's available in the WebVTT spec, correct?

Thanks!

ocram commented 7 years ago

Thanks!

Yes, so the options for adding comment support to MCF would be limited to what's available in the WebVTT spec, correct?

Yes, correct, but that should still give us enough room to implement what we need.

What about this?

WEBVTT MovieContentFilter 1.1.0

NOTE
TITLE Ozymandias
SOURCE https://www.moviecontentfilter.com/works/abcdef
TYPE episode
YEAR 2013
IMDB http://www.imdb.com/title/tt2301451/
SEASON 5
EPISODE 14

NOTE
START 00:00:04.020
END 01:24:00.100

The first and the third paragraph are what we have today. The one in between could be the new syntax added in a new version of the specification. Any of the entries (TITLE through EPISODE) would be optional.

What do you think?

A way to add notes for the film start/stop timestamps. I've noticed in a lot of films the title, credits, etc tend to be blended into the actual movie content. Since the accuracy of these affects the accuracy when it comes to scaling, a way to annotate these would be nice in the cases where it's not clear.

This is a really significant point. But I think that we should agree on a "global" solution for all entries throughout the entire project instead of "local" solutions that vary from entry to entry.

bmaupin commented 7 years ago

What do you think?

I think it looks great!

SOURCE is for the filter itself, not the video, correct?

The only other addition to the metadata section I think could be helpful would be a freeform line for an additional note, e.g. "North American release" etc. Or maybe instead of a generic note, something like RELEASE or VERSION. At any rate, that's the only other thing I can think of that might be helpful.

This is a really significant point. But I think that we should agree on a "global" solution for all entries throughout the entire project instead of "local" solutions that vary from entry to entry.

Yeah, that does sound a lot better. I really like the current spec, so maybe even just some extra guidelines for those situations that aren't so clear-cut.

Thanks!

ocram commented 7 years ago

Yes, SOURCE was intended to be the source of the filter, not the source of the video/audio. It really is ambiguous. What about DETAILS (Details about what? In what form?), FILTER (How does this describe the filter? What is it?), URL (What does this point to?) or MCF instead? Among those, I would probably prefer the latter, just because is the least ambiguous. But perhaps there's a better keyword.

Some place to put notes on the specific release is probably valuable as well, as you said. So let's add that and use the RELEASE keyword which should not be ambiguous but pretty clear.

Since a place to put custom notes or comments is always worth including, let's still add such a field, although the release information now has its own place. All these fields are optional, anyway.

So what about this updated set of fields then?

WEBVTT MovieContentFilter 1.1.0

NOTE
TITLE Ozymandias
YEAR 2013
TYPE episode
SEASON 5
EPISODE 14
MCF https://www.moviecontentfilter.com/works/abcdef
IMDB http://www.imdb.com/title/tt2301451/
RELEASE North America
COMMENT Some custom notes …

NOTE
START 00:00:04.020
END 01:24:00.100
bmaupin commented 7 years ago

But perhaps there's a better keyword.

Yeah, that's a tough one. They're all a bit ambiguous, but I can't think of anything better. I think out of the 5 suggestions you made I actually like SOURCE the best. I was able to guess what it was after all :)

RELEASE and COMMENT are perfect. Thanks!

ocram commented 7 years ago

The specification does now support versioning (https://github.com/delight-im/MovieContentFilter/commit/da01b4fe80cffa61780431531d427eaf1848096a). This is available in a convenient form on the public website. You can easily switch between single versions there. Though there's no diff – if you really need one, just diff the HTML of the pages with other tools.

There's a new version of the specification, namely version 1.1.0, which supports the metadata that we discussed (https://github.com/delight-im/MovieContentFilter/commit/057eec67a5394fa5c285e97073a1f59062587e03).

On each movie or TV show's download page, there was a grayed-out "MCF" option before. It was grayed-out to emphasize that the MCF format is not really useful today, unlike the other formats. But graying out usually means something is inactive or disabled, so that was bad UX. Thus, the "MCF" option shows up as a normal option now (https://github.com/delight-im/MovieContentFilter/commit/9264843c10cb2f5a7ef04c9db62ba897b1e30535).

Apart from that, you found out that the times requested for synchronization are not actually used for exports in the MCF format. So now they're not required anymore (https://github.com/delight-im/MovieContentFilter/commit/1c65584c2403483199b547f208c61c406767eda2) and will even be hidden completely (https://github.com/delight-im/MovieContentFilter/commit/06554ab270a00951140657658e5165c134067e98) for exports to MCF which removes all possible causes for confusion there. That's why now the format is requested first (https://github.com/delight-im/MovieContentFilter/commit/926c35a3fc4ccabf4bc3ba7c1e6f10edc960f448), and if it's MCF, no other input is required.

Further, the class for MCF exports now follows the latest version of the specification (https://github.com/delight-im/MovieContentFilter/commit/5b2aeca3a6df7eb8939d0ce8d7f90cf4792085f3), supporting the new metadata. When downloading filters from the public website in MCF format, they will all have metadata now (https://github.com/delight-im/MovieContentFilter/commit/d0185d14f324e53d9b9d792df9b83a2543becfa1).

These changes should address several points we discussed here.

bmaupin commented 7 years ago

Thanks, I appreciate it all your work!

ocram commented 7 years ago

@bmaupin Thanks again for your extremely valuable feedback and all the insights! As you can see above, several points have already been addressed and a few others are tracked in new issues and will be addressed in the future.

ocram commented 6 years ago

There’s news concerning keyboard shortcuts and seeking to frames now. I’m sure we should implement both and pretty confident we’ll do so.