Having a separate setting for unconditionally disabling all wireless communication would be helpful. The other stuff you mention can be separate settings if it is useful to have them. (A setting to unconditionally all disable wired connections is less important since you can just avoid connecting it.)
I had found that VLC does not play a MPEG-TS file very well (although it recognizes the file and plays it, it does not work very well); converting it to another format first, will cause it to play better, in my experience.
Sometimes I would want to convert from MPEG-TS H.264 to DVD video format, or other conversions, so there are reasons to do so. However, once I had got desynchronized audio, and I don't know if that is because of the original source, because of the conversion, or because some segments have not been recorded. (Also, it could not retain the EIA-608 captions, but that seems to be a limitation with FFmpeg, rather than something I did.)
If you disable CSS as well then it works. (This is true of some web pages that allegedly require JavaScripts, while others will not work with JavaScripts disabled whether or not you disable CSS as well.)
If it is made to allow C codes to be combined with VB6 codes easily, and a FOSS version of VB6 (and the other components it might use) is made available on ReactOS (and Wine, and it would also run on Windows as well), then it might be better than using web technologies (and is probably better is a lot of ways). (There are still many problems with it, although it would avoid many problems too.)
I think it is helpful to have settings that you can change, although the default settings should probably match those intended by whoever made the movie or TV show that you are watching, according to the specification of the video format. (The same applies to audio, etc.)
This way, you should not need to change them unless you want nonstandard settings for whatever reason.
I agree that the viewer should change the settings if they want different settings than the film maker intended, although it also makes sense to have a option (not mandatory) to use the settings that the film maker intended (if these settings are known) in case you do not want to specify your own settings. (The same would apply to audio, web pages, etc.)
Sure. I’m all for having that as an option, or even the default. That’s a good starting place for most people. I think what I most object to is the pretentiousness I read into the quote:
> Whatever you do, do not switch anything on ‘vivid’ because it’s gonna turn on all the worst offenders. It’s gonna destroy the color, and it’s not the filmmaker’s intent.
I’m interested in trying the filmmaker’s intent, like I’ll try the chef’s dinner before adding salt because it’ll probably be wonderful. But if I think the meal still needs salt, or my TV needs more brightness or contrast, I’ll add it. And even if the filmmaker or chef thinks I’m ruining their masterpiece, if I like it better that way, that’s how I’ll enjoy it.
And I’m very serious about the accessibility bit. My vision is great, but I need more contrast now than I did when I was 20. Maybe me turning up the brightness and contrast, or adding salt, lets me perceive the vision or taste the meal the same way as the director or chef does.
I thought there is such a thing (although probably some TV sets do not have) as "film maker mode" to do it according to the film maker's intention (although I don't know all of the details, so I do even know how well it would work). "Dolby Vision Movie Dark" is something that I had not heard of.
(However, modern TV sets are often filled with enough other junk that maybe you will not want all of these things anyways)
Downloading over HTTPS does not help with that (although it can prevent spies from seeing what files you are downloading) unless you can independently verify the server's keys. The certificate is intended to do this but the way that standard certificate authorities work will only verify the domain name, and has some other limitations. TLS does have other benefits, but it does a different thing. Using only TLS to verify the packages is not very good, especially with the existing public certificate authorities.
If you only need a specific version and you already know what that one is, then using a cryptographic hash will be a better way to verify packages, although that only applies for one specific version of one specific package. So, using an encrypted protocol (HTTPS or any other one) alone will not help, although it will help in combination with other things; you will need to do other things as well, to improve the security.
reply