We’ve updated the process and way we create our .mp4 files that are shown on video pages on archive.org
It’s a much cleaner/clearer process, namely:
We opted to ditch ffpreset files in favor of command-line argument 100% equivalents. It seems a bit easier for someone reading the task log of their item, trying to see what we did.
We no longer need qt-faststart step and dropped it. we use the cmd-line modern ffmpeg “-movflags faststart”
Entire processing is now done 100% with ffmpeg, in the standard “2-pass” mode
As before, this derivative plays in modern html5 video tag compatible browsers, plays in flash plugin within browsers, and works on all iOS devices. it also makes sure the “moov atom” is at the front of the file, so browsers can playback before downloading the entire file, etc.)
Here is an example (you would tailor especially the “scale=640:480” depending on source aspect ratio and desired output size; change or drop altogether the “-r 20” option (the source was 20 fps, so we make the dest 20 fps); tailor the bitrate args to taste):
For those video oriented of you who inspect our _files.xml directly, or use a metadata API (JSON) for items, you’ll likely be pleased to know that for all new items, as well as items that update (eg: review posted, metadata changes, rederives), that:
we now detect and stamp into each video file fields for
length (duration in seconds)
here is an example file listing (in JSON results) demonstrating:
we will even attempt to “correct” the width in the case of “anamorphic” videos (eg: the pixels are “rectangular” and not “square”) to the scaled width in square pixel terms (like the one above)
You’d want to adjust the “scale=WIDTH:HEIGHT” accordingly, as well as the “-r FRAMES-PER-SECOND” related args, to your source video.
I made a small patch to allow *both* bitrate target *and* quality level for theora in ffmpeg, after comparing the other popular tool “ffmpeg2theora” code with the libtheoraenc.c inside ffmpeg. It may not be necessary, but I believe I saw *slightly* better quality coming out of theora/thusnelda ogg video. For what it’s worth, my minor patch is here: http://archive.org/~tracey/downloads/patches/ffmpeg-theora.patch
The way we compile ffmpeg (ubuntu/linux) is here. (Alt MacOS version here )
(Edited post above after I removed this step) It’s *quite* odd, I realize to have ffmpeg transcode both the audio/video together, only to split/demux them back out temporarily. However, for some videos, the “oggz-comment” step would wipe out the first video keyframe and cause unplayability in chrome (and the expected visual artifacts for things that could play it). So, we split, comment the audio track, then re-stitch it back together.
We know there will be a few minor breaks here and there especially from some third-party applications that might not handle “301 Moved Temporarily” redirects (if you have something flash-based that needs http://www.archive.org/crossdomain.xml we caught that breakage and that url still works now (that is, it can be either requested either with or without the lead “www.” as an exception now). We’re happy to work with anyone having issues — feel free to reply to this post and let us know.
Best wishes, and now go spend those four characters saved on something fun 😉
We have thoroughly tested a newer and simpler way to create h.264 derivatives!
Changes you’ll notice:
More pixels! previously 320 x 240 goes to 640 x 480 pixels
Slightly higher video bitrate — from about 512kb/s to about 700kb/s bitrate
Switching from mp4creator container maker to ffmpeg container + qt-faststart
Less back-end commands to make high-quality derivative
Nice things about this derivative (similar to prior derivative):
Plays in adobe flash plugin
Plays on all versions of iphone and ipad
Starts quickly, nearly instant seeking even to unbuffered areas of the video
Here’s a sample of how we do it with just 3 simple commands. (We do/you should adjust “-r” argument appropriately to your video’s frames-per-second. We also adjust the “640” in the “-vf scale” argument to be appropriate for the video’s *actual* aspect ratio, etc. So for example, the 640 might become 852 for 16:9 widescreen video. Although for our .mp4 specific derivative and playback ability on iPhone (1st gen and thus all versions), we would actually downrez that to 640×360).