Answers.Body: <p>You can strip most of the metadata off your files using ffmpeg:</p>
  
  <pre><code>ffmpeg -i oldfile.mp4 -c copy newfile.mp4
  </code></pre>
  
  <p>This will copy the first audio and video streams to a new mp4.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-11T22:09:18.957Z
Answers.Text: Thx, but just tried it and the `"format_long_name": "QuickTime / MOV",` remains
Answers.UserDisplayName: GDP
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T22:31:21.383Z
Answers.Text: Maybe I am wrong but isn't the mp4 container Practically the same as a QuickTime file and therefore thrown into one (meta-data) box with "MOv"?
Answers.UserDisplayName: Hans Meiser
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-13T22:48:41.850Z
Answers.Text: You are almost exactly right.
Answers.UserDisplayName: Duvrai
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-03-11T18:30:28.073Z
Answers.LastActivityDate: 2016-03-11T18:30:28.073Z
Answers.UserDisplayName: Duvrai
Body: <p>I posted this earlier on SuperUser, but realized that this is likely the more appropriate forum for my question.</p>
  
  <p>We have several thousand very large MP4 files that have been encoded over the past decade using Sorenson Squeeze.  Over the past year, there are suddenly a growing number of customers (Universities) with Network/Proxy Server that are suddenly unable to view the videos due to vulnerability described at this link: <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1799" rel="nofollow noreferrer">Apple QuickTime Vulnerability</a>.</p>
  
  <p>Forgive me, I know very little about media and encoding, only that the problem has suddenly started appearing while they view our videos (we use JWPlayer v7 with files hosted at AWS/S3/Cloudfront).</p>
  
  <p>Is there an alternate way of encoding h.264/MP4 that doesn't include any reference or codecs, or whatever it is that flags them as Quicktime files, or some other way to get around this?  </p>
  
  <p><strong>Note:</strong> Our site streams the h.264 MP4 files with JWPlayer - the end users don't open them with Apple Quicktime.</p>
  
  <pre><code>Partial ffmpeg Output for one of the videos in question:
  
  "format": {
      "filename": "c:\\videos\\ABC-123.mp4",
      "nb_streams": 4,
      "nb_programs": 0,
      "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
      "format_long_name": "QuickTime / MOV",
      "start_time": "0.000000",
      "duration": "1632.480000",
      "size": "86937415",
      "bit_rate": "426038",
      "probe_score": 100,
      "tags": {
          "major_brand": "mp42",
          "minor_version": "0",
          "compatible_brands": "mp42isomavc1",
          "creation_time": "2011-07-13 14:02:44",
          "compilation": "0",
          "encoder": "Sorenson Squeeze 5.0"
      }
  </code></pre>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-11T18:24:58.747Z
Comments.Text: Do you know some of the firewall brands that are posing this problem? Do you have a way of testing whether a new file will pass or not?
Comments.UserDisplayName: Duvrai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-11T19:10:34.263Z
Comments.Text: As far as I can tell, the vulnerability relates to the operation of the Apple **Quicktime player** version 7.6.6 or older **on Windows**, not JWPlayer on the web. How have you identified the vulnerability as relevant?
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-11T22:11:21.050Z
Comments.Text: I cannot actually reproduce it, it's all the customers giving us the same report.  Our webserver IS windows, but I don't know what all customer networks are of course.  I know this is vague, but I'm not a media OR network guru so am floundering as such.
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-12T07:10:59.527Z
Comments.Text: I just missed the aws detail. Are you transcoding the videos using [AWS Elastic Transcoder](https://aws.amazon.com/elastictranscoder/)? Do you serve them as a progressive download or streaming? It would also help to have the actual firewall error, the users browser and system version, and your jwplayer embed code.
Comments.UserDisplayName: Duvrai
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-12T16:41:38.770Z
Comments.Text: I think it would be helpful to ask your clients which vulnerability exactly is the triggering their firewalls. A quick Google search coughed up around 3-4 serious exploits in QuickTime over the last couple of years, which seem to use different flaws though. If this happened recently, I assume they are referring to this exploit and not the one you linked, which is from 2010. https://threatpost.com/patched-apple-quicktime-vulnerability-details-disclosed/113570/
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-12T16:51:42.960Z
Comments.Text: In any case I find the demand of the clients a bit strange: they have the vulnerable software installed (or maybe not but their firewall wants to protect their possible outdated QuickTime clients)..  There is nothing malicious in your files.
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-12T17:05:16.250Z
Comments.Text: Also, since you got rtmp in your questions tags, I assume you are using some kind of streaming server? Or are you just doing http pseudo streaming?
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-12T17:14:24.303Z
Comments.Text: They're using our JWPlayer page with RTMP Streaming from AWS Customers are basically saying fix it, or we won't buy it....($10K-$50K orders)
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-13T22:03:05.447Z
Comments.Text: I don't know if AWS can do this or expensive the CPU time would be, but you could always real-time transcode the files to a different format until the clients come to their senses and realize it's their players that have the problem, not your streams.
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-13T22:19:40.957Z
Comments.Text: Or check out this, they claim to be able to Transcode faster than anyone else, also from AWS... I guess your problem should be gone if you had all your files I.e. In WebM or mpeg dash... at least until an exploit triggered with WebM files is found. https://www.bitcodin.com/blog/2015/02/create-mpeg-dash-hls-content-for-amazon-s3-and-cloudfront/
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-13T22:28:16.960Z
Comments.Text: The whole idea is ridiculous though since you would just be working around their weird ideas of security since any video format could be used to trigger a vulnerability in some player and they cannot exclude all of them unless they consider watching videos over the Internet as insecure per se.
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T13:58:41.707Z
Comments.Text: Rencoding might be the only answer, but the last time we did this to MP4 it took almost 2 months to do the whole collection - there are 12000 full length movies involved, so we're looking for alternate solutions.  If it were only a couple of customers, no big deal, but every month we're getting more and more support tickets and canellations due to the problem.
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T14:12:47.427Z
Comments.Text: I think maybe a "legal" solution to this problem is easier to achieve. As the description of the exploits state, the malicious video file needs to be specifically crafted to exploit the vulnerability in the affected players. If your platform is not open to the public and you can assure that no maliciously crafted video file can sneak in to your collection, this should be sufficient as a reassurance for them or not? Then they could Whitelist your service on their firewalls. As far as I see it there is no real alternative, if you search for WebM and exploits, you will also find incidents so I gu
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T14:13:41.567Z
Comments.Text: @Hans, they watch the video on our web page, with JWPlayer - is the QT player even part of the equation?  The manifest of file in the JWP script is being blocked between their browser and our server, (presumably with their proxy server)
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T14:14:22.410Z
Comments.Text: And the same could happen with Mpeg dash, even if there is no reported vulnerability as of now. So next month they could say the will block WebM or mpeg dash as well...
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T14:16:06.123Z
Comments.Text: No! QuickTime player is not part if the process as far as I can see. Are you using jwplayer in flash or html5 mode?
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T18:29:37.883Z
Comments.Text: Default Flash/falback to HTML5 - this is only happening with RTMP
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T19:29:15.827Z
Comments.Text: Then i completely dont understand the clients concern. Apparently internally Safari uses quicktime as the player when using HTML5 video objects, but i guess RTMP means JWPlayer is using flash for playback. Security-wise Adobe Flash is a problem in general, but it doesnt use Quicktime, i am pretty sure about that. So, again, i think the security concerns of your clients are pretty random IMHO... What is the overall size of your collection in h264, just to have an idea how much the transcoding i.e. in bitcodin would be...
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-14T23:17:40.547Z
Comments.Text: I agree with you in general,,,transcoding would be about 30TB, so we're leaving that as a last option, and we;ve still to figure out how to reencode them anyways.  WE can't reproduce it, and the 80 or so major customers are leaving it to us to figure out.  I'm baffled, and they simply want it fixed, or will buy elsewhere (very substantial revenue).  The major fear is that the number of customers in this state keeps growing, and they'll all leave.
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-15T09:53:34.827Z
Comments.Text: I really think you should reach out to a client having these concerns and trying to understand better what it is they fear. I mean are they blocking h264 videos in general? Because potentially every h264 file (or WebM or flv for that matter) can be crafted to exploit a vulnerability. So a service offering non public video collections (like yours seem to be) is actually a secure way to allow videos while the stuff floating around on the Web is potentially dangerous. I mean you could even get different virus scanners and scan your files for exploits if that calms them down
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-15T14:57:54.017Z
Comments.Text: Of course we've done all that....they're schools - no budget to spend time/money helping us identify whatever is blocking the stream, so are just as happy to move to another provider.  It's very frustrating, but thanks :)
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-03-16T09:12:42.757Z
Comments.Text: The thing is: what is another provider going to do about that issue? MP4 (the container) is very closely modeled after the QuickTime file structure. So mediainfo / Ffmpeg will regard it as a mp4 / Mov container. There is nothing anyone can do about it. WebM has known exploits as has FLV (and most probably MPEG dash as well.) so transcoding your stuff will only calm them down until they learn about the other exploits as well. In the meanwhile creating considerable costs  for you. Personally I would move away from using a flash based player though for several reasons, Security only being one.
Comments.UserDisplayName: Hans Meiser
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T05:33:29.593Z
Comments.Text: The CISCO advisory is helpful. It says that the vulnerabiity is linked to exploiting `rnet` boxes in MP4. Those are not a mandatory spec of the MP4 file format. In fact, ffmpeg does not write those, so any MP4 files rewrapped with ffmpeg should be exploit-shielded. If the MP4s are still being flagged then your malware detector has a very broad trigger - maybe it's just looking at the extension.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T17:16:25.983Z
Comments.Text: @Mulvya Well, its not "our" detector...its Universities scattered around the western hemisphere, lol.  We've been using Sorenson Squeeze to do the encoding, but there are a decade worth of legacy files that are in use.  Do you know a way to excluding the rnet boxes when encoding, and/or better yet how to remove them with FFMPEG?
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T17:27:28.730Z
Comments.Text: If you run the command in Duvrai's answer, the output won't have that box because FFmpeg's code has no provision to write it. Assuming that the output isn't then altered by something else, that should be it.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T17:32:48.707Z
Comments.Text: Seems to me I tried that long ago with no luck, but will give it a go again...at least you've answered a question thats been haunting me for several years now - it's the _rnet_ box, now I know what's triggering their detectors!!!
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T18:06:12.687Z
Comments.Text: Can you link to one of the files triggering the error? And the text or screenshot of the specific warning that is thrown.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T19:47:23.140Z
Comments.Text: God I wish it was that easy...wouldn't be here if it was, lol.  Files are on Cloudfront, the Detectors are "God knows where", and its taken me this many years just to get the vague details of the problem from a customer.  But I really, REALLY appreciate the offer.  Maybe one day if I can get those specifics, I'll hunt you down, lol.
Comments.UserDisplayName: GDP
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2016-12-06T19:48:13.577Z
Comments.Text: If you put your suggestions/directions as an answer, I'll certainly accept it!!
Comments.UserDisplayName: GDP
Tags: <streaming><encoding><mp4><h.264><rtmp>
Title: How can I avoid Quicktime Vulnerability with h.264 encoded MP4 files?
UserDisplayName: GDP
ThreadText: # How can I avoid Quicktime Vulnerability with h.264 encoded MP4 files?
  
  (Asked by: username_0 on 2016-03-11)
  
  I posted this earlier on SuperUser, but realized that this is likely the more appropriate forum for my question.
  
  We have several thousand very large MP4 files that have been encoded over the past decade using Sorenson Squeeze. Over the past year, there are suddenly a growing number of customers (Universities) with Network/Proxy Server that are suddenly unable to view the videos due to vulnerability described at this link: [Apple QuickTime Vulnerability](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1799).
  
  Forgive me, I know very little about media and encoding, only that the problem has suddenly started appearing while they view our videos (we use JWPlayer v7 with files hosted at AWS/S3/Cloudfront).
  
  Is there an alternate way of encoding h.264/MP4 that doesn't include any reference or codecs, or whatever it is that flags them as Quicktime files, or some other way to get around this?
  
  **Note:** Our site streams the h.264 MP4 files with JWPlayer - the end users don't open them with Apple Quicktime.
  
  ```
  Partial ffmpeg Output for one of the videos in question:
  
  "format": {
      "filename": "c:\\videos\\ABC-123.mp4",
      "nb_streams": 4,
      "nb_programs": 0,
      "format_name": "mov,mp4,m4a,3gp,3g2,mj2",
      "format_long_name": "QuickTime / MOV",
      "start_time": "0.000000",
      "duration": "1632.480000",
      "size": "86937415",
      "bit_rate": "426038",
      "probe_score": 100,
      "tags": {
          "major_brand": "mp42",
          "minor_version": "0",
          "compatible_brands": "mp42isomavc1",
          "creation_time": "2011-07-13 14:02:44",
          "compilation": "0",
          "encoder": "Sorenson Squeeze 5.0"
      }
  
  ```
  
  **Tags:** streaming, encoding, mp4, h.264, rtmp
  
  > **Comments:**
  > **username_1**: Do you know some of the firewall brands that are posing this problem? Do you have a way of testing whether a new file will pass or not?  
  > **username_2**: As far as I can tell, the vulnerability relates to the operation of the Apple **Quicktime player** version 7.6.6 or older **on Windows**, not JWPlayer on the web. How have you identified the vulnerability as relevant?  
  > **username_0**: I cannot actually reproduce it, it's all the customers giving us the same report.  Our webserver IS windows, but I don't know what all customer networks are of course.  I know this is vague, but I'm not a media OR network guru so am floundering as such.  
  > **username_1**: I just missed the aws detail. Are you transcoding the videos using [AWS Elastic Transcoder](https://aws.amazon.com/elastictranscoder/)? Do you serve them as a progressive download or streaming? It would also help to have the actual firewall error, the users browser and system version, and your jwplayer embed code.  
  > **username_3**: I think it would be helpful to ask your clients which vulnerability exactly is the triggering their firewalls. A quick Google search coughed up around 3-4 serious exploits in QuickTime over the last couple of years, which seem to use different flaws though. If this happened recently, I assume they are referring to this exploit and not the one you linked, which is from 2010. https://threatpost.com/patched-apple-quicktime-vulnerability-details-disclosed/113570/  
  > **username_3**: In any case I find the demand of the clients a bit strange: they have the vulnerable software installed (or maybe not but their firewall wants to protect their possible outdated QuickTime clients)..  There is nothing malicious in your files.  
  > **username_3**: Also, since you got rtmp in your questions tags, I assume you are using some kind of streaming server? Or are you just doing http pseudo streaming?  
  > **username_0**: They're using our JWPlayer page with RTMP Streaming from AWS Customers are basically saying fix it, or we won't buy it....($10K-$50K orders)  
  > **username_3**: I don't know if AWS can do this or expensive the CPU time would be, but you could always real-time transcode the files to a different format until the clients come to their senses and realize it's their players that have the problem, not your streams.  
  > **username_3**: Or check out this, they claim to be able to Transcode faster than anyone else, also from AWS... I guess your problem should be gone if you had all your files I.e. In WebM or mpeg dash... at least until an exploit triggered with WebM files is found. https://www.bitcodin.com/blog/2015/02/create-mpeg-dash-hls-content-for-amazon-s3-and-cloudfront/  
  > **username_3**: The whole idea is ridiculous though since you would just be working around their weird ideas of security since any video format could be used to trigger a vulnerability in some player and they cannot exclude all of them unless they consider watching videos over the Internet as insecure per se.  
  > **username_0**: Rencoding might be the only answer, but the last time we did this to MP4 it took almost 2 months to do the whole collection - there are 12000 full length movies involved, so we're looking for alternate solutions.  If it were only a couple of customers, no big deal, but every month we're getting more and more support tickets and canellations due to the problem.  
  > **username_3**: I think maybe a "legal" solution to this problem is easier to achieve. As the description of the exploits state, the malicious video file needs to be specifically crafted to exploit the vulnerability in the affected players. If your platform is not open to the public and you can assure that no maliciously crafted video file can sneak in to your collection, this should be sufficient as a reassurance for them or not? Then they could Whitelist your service on their firewalls. As far as I see it there is no real alternative, if you search for WebM and exploits, you will also find incidents so I gu  
  > **username_0**: @username_3, they watch the video on our web page, with JWPlayer - is the QT player even part of the equation?  The manifest of file in the JWP script is being blocked between their browser and our server, (presumably with their proxy server)  
  > **username_3**: And the same could happen with Mpeg dash, even if there is no reported vulnerability as of now. So next month they could say the will block WebM or mpeg dash as well...  
  > **username_3**: No! QuickTime player is not part if the process as far as I can see. Are you using jwplayer in flash or html5 mode?  
  > **username_0**: Default Flash/falback to HTML5 - this is only happening with RTMP  
  > **username_3**: Then i completely dont understand the clients concern. Apparently internally Safari uses quicktime as the player when using HTML5 video objects, but i guess RTMP means JWPlayer is using flash for playback. Security-wise Adobe Flash is a problem in general, but it doesnt use Quicktime, i am pretty sure about that. So, again, i think the security concerns of your clients are pretty random IMHO... What is the overall size of your collection in h264, just to have an idea how much the transcoding i.e. in bitcodin would be...  
  > **username_0**: I agree with you in general,,,transcoding would be about 30TB, so we're leaving that as a last option, and we;ve still to figure out how to reencode them anyways.  WE can't reproduce it, and the 80 or so major customers are leaving it to us to figure out.  I'm baffled, and they simply want it fixed, or will buy elsewhere (very substantial revenue).  The major fear is that the number of customers in this state keeps growing, and they'll all leave.  
  > **username_3**: I really think you should reach out to a client having these concerns and trying to understand better what it is they fear. I mean are they blocking h264 videos in general? Because potentially every h264 file (or WebM or flv for that matter) can be crafted to exploit a vulnerability. So a service offering non public video collections (like yours seem to be) is actually a secure way to allow videos while the stuff floating around on the Web is potentially dangerous. I mean you could even get different virus scanners and scan your files for exploits if that calms them down  
  > **username_0**: Of course we've done all that....they're schools - no budget to spend time/money helping us identify whatever is blocking the stream, so are just as happy to move to another provider.  It's very frustrating, but thanks :)  
  > **username_3**: The thing is: what is another provider going to do about that issue? MP4 (the container) is very closely modeled after the QuickTime file structure. So mediainfo / Ffmpeg will regard it as a mp4 / Mov container. There is nothing anyone can do about it. WebM has known exploits as has FLV (and most probably MPEG dash as well.) so transcoding your stuff will only calm them down until they learn about the other exploits as well. In the meanwhile creating considerable costs  for you. Personally I would move away from using a flash based player though for several reasons, Security only being one.  
  > **username_2**: The CISCO advisory is helpful. It says that the vulnerabiity is linked to exploiting `rnet` boxes in MP4. Those are not a mandatory spec of the MP4 file format. In fact, ffmpeg does not write those, so any MP4 files rewrapped with ffmpeg should be exploit-shielded. If the MP4s are still being flagged then your malware detector has a very broad trigger - maybe it's just looking at the extension.  
  > **username_0**: @Mulvya Well, its not "our" detector...its Universities scattered around the western hemisphere, lol.  We've been using Sorenson Squeeze to do the encoding, but there are a decade worth of legacy files that are in use.  Do you know a way to excluding the rnet boxes when encoding, and/or better yet how to remove them with FFMPEG?  
  > **username_2**: If you run the command in username_1's answer, the output won't have that box because FFmpeg's code has no provision to write it. Assuming that the output isn't then altered by something else, that should be it.  
  > **username_0**: Seems to me I tried that long ago with no luck, but will give it a go again...at least you've answered a question thats been haunting me for several years now - it's the _rnet_ box, now I know what's triggering their detectors!!!  
  > **username_2**: Can you link to one of the files triggering the error? And the text or screenshot of the specific warning that is thrown.  
  > **username_0**: God I wish it was that easy...wouldn't be here if it was, lol.  Files are on Cloudfront, the Detectors are "God knows where", and its taken me this many years just to get the vague details of the problem from a customer.  But I really, REALLY appreciate the offer.  Maybe one day if I can get those specifics, I'll hunt you down, lol.  
  > **username_0**: If you put your suggestions/directions as an answer, I'll certainly accept it!!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2016-03-11. Score: 2
  
  You can strip most of the metadata off your files using ffmpeg:
  
  ```
  ffmpeg -i oldfile.mp4 -c copy newfile.mp4
  
  ```
  
  This will copy the first audio and video streams to a new mp4.
  
  > **Comments:**
  > **username_0**: Thx, but just tried it and the `"format_long_name": "QuickTime / MOV",` remains  
  > **username_3**: Maybe I am wrong but isn't the mp4 container Practically the same as a QuickTime file and therefore thrown into one (meta-data) box with "MOv"?  
  > **username_1**: You are almost exactly right.  
  
  ---
  
  