Why a new filter format? #10
Comments
|
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. |
|
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! |
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.
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.
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.
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.
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.
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.
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.
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.
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 |
I tried the website, and it's a good start, but I had a lot of issues:
I get that, but I still think it'd be nice to be able to download the raw filter without having to log in.
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.
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: Thanks for your patience with all my questions. I think this is a great project and I'm really interested in its success! |
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.
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.
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.
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.
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.
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).
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.
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.
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?
Agreed, again. We should probably support comments in other areas of the files as well.
|
Yes, I'm actually quite impressed that so much can be done through the web interface.
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.
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.
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 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: So I tried typing in some different values and I got the same result.
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
So to go back to my previous example: Would it look like this?: Thanks! |
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.
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.
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 #11.
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.
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.
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.
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: #12
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
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.
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'd favor a possibility to delete individual annotations over a preview screen. Let's track the former here: #13
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.
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.
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.
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. |
A couple other I think would be helpful:
Yes, so the options for adding comment support to MCF would be limited to what's available in the WebVTT spec, correct? Thanks! |
|
Thanks!
Yes, correct, but that should still give us enough room to implement what we need. What about this? 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 ( What do you think?
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. |
I think it looks great!
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
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! |
|
Yes, 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 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? |
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
|
|
The specification does now support versioning (da01b4f). 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 (057eec6). 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 (9264843). 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 (1c65584) and will even be hidden completely (06554ab) for exports to MCF which removes all possible causes for confusion there. That's why now the format is requested first (926c35a), and if it's MCF, no other input is required. Further, the class for MCF exports now follows the latest version of the specification (5b2aeca), supporting the new metadata. When downloading filters from the public website in MCF format, they will all have metadata now (d0185d1). These changes should address several points we discussed here. |
|
Thanks, I appreciate it all your work! |
|
@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. |
|
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. |
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!
The text was updated successfully, but these errors were encountered: