![]() One with the real type, or fallback to the wildcard. So every browser should either get the first ![]() ![]() Some research suggests that a) with only 1 real file and b) any of them having no type, it might make most sense to just leave off type completely (and only have one source) - it isn't doing anything useful for the browser because the standard behaviour just says to skip any with known-incompatible types. I think the worst case with no type that might be hit here is that the browser could decide to download the entire file on load to figure out the format and duration, rather than starting with byte-range requests, but this is easy to test and unlikely (I'd expect any sane one to always request chunks). I don't think anything should try and download the file twice unless it is a complete clownshoes implementation that probably has multiple other serious bugs wasting bandwidth. My knowledge is centred around broadcast video / IPTV (UDP multicast) rather than HTML5 video, but that seems fairly reasonable. You're almost certainly safe just faking it to video/mp4 though. This is almost certainly a Chrome bug, because the file is really a QTFF container - so Chrome has code to parse and play it in the MP4 pipeline (it is very, very similar to the MP4 container), but is missing the mime type registration to hook it up to the MP4 pipeline. I think, e.g., most blogs nowadays just work by uploading to YouTube (which can transcode into multiple formats and do other sophisticated things) and embedding the video from YouTube.Ĭom. : T14:12:11-0700 I made some effort to Google this and found a bit of evidence of users running into a similar situation and using the workaround above (e.g., see here) but nothing in the way of concrete guidance.Īnother place to look might be other software which embeds user-uploaded video, but I'm not sure offhand which pieces of software would be good to look at. Hopefully that yields a greater understanding and more confidence in an approach. Look at available tools for inspecting the contents of video files.Identify exactly what's going on with that file.Learn how video file formats actually work.I suspect ffmpeg or similar has some command like ffmpeg -explain-what-this-is movie.mov but I'd prefer not to require installs to install ffmpeg (although maybe this isn't the end of the world).Īlso ffmpeg is super illegal thought crime full of forbidden and completely unlicensed prime numbers or something, maybe?īasically, I'm currently pretty far out of my depth on understanding video container/codec formats and the tools available to interact with them, so I have very low confidence that I can predict how much damage various changes will cause. I'm also not sure how to detect that a given file is an MP4 video file, or if this video file even is MP4 - Quicktime Player reports it as "H.264" but I think all video files are basically 30-40 levels of container formats wrapped in one another and that this may be a H.264-encoded video stream inside an MP4 container inside a Quicktime container - or may not be. if ( $type = 'video/quicktime' ) īut there's no easy way to tell how much collateral damage this might cause (does it cause other browsers to not play these videos, or other videos?), and the cure might be worse than the disease. Trick Chrome into playing certain videos.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |