2

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.

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"
    }
Improve this question
29
  • 1
    I just missed the aws detail. Are you transcoding the videos using AWS Elastic Transcoder? 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.
    – Duvrai
    Mar 12, 2016 at 7:10
  • 1
    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. threatpost.com/…
    – Hans Meiser
    Mar 12, 2016 at 16:41
  • 1
    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. bitcodin.com/blog/2015/02/…
    – Hans Meiser
    Mar 13, 2016 at 22:19
  • 1
    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.
    – Gyan
    Dec 6, 2016 at 5:33
  • 1
    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.
    – Gyan
    Dec 6, 2016 at 17:27

1 Answer 1

Reset to default
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.

Improve this answer
3
  • Thx, but just tried it and the "format_long_name": "QuickTime / MOV", remains
    – GDP
    Mar 11, 2016 at 22:09
  • 1
    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"?
    – Hans Meiser
    Mar 13, 2016 at 22:31
  • You are almost exactly right.
    – Duvrai
    Mar 13, 2016 at 22:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.