0

I am writing some unit-tests for a software that does some work with videos. To do so, I need a programmatically generated video file that is both small and legitimate in that it is actually a sensible video from the point of view of a codec.

An idea that came to mind was to produce a video of a single frame of a solid color. I have tried that in Apple Motion. However, the file still ended up being about 8KBs. That is not so big, but I am wondering if one can do better.

Do you have any advice on how? I would be happy with MP4 container.

To give you an example of what I may be after, here is a list of HEX codes that produces a small but valid .PNG image:

png_hex = ['\x89', 'P', 'N', 'G', '\r', '\n', '\x1a', '\n', '\x00',
           '\x00', '\x00', '\r', 'I', 'H', 'D', 'R', '\x00',
           '\x00', '\x00', '\x01', '\x00', '\x00', '\x00', '\x01',
           '\x08', '\x02', '\x00', '\x00', '\x00', '\x90',
           'w', 'S', '\xde', '\x00', '\x00', '\x00', '\x06', 'b', 'K',
           'G', 'D', '\x00', '\x00', '\x00', '\x00',
           '\x00', '\x00', '\xf9', 'C', '\xbb', '\x7f', '\x00', '\x00',
           '\x00', '\t', 'p', 'H', 'Y', 's', '\x00',
           '\x00', '\x0e', '\xc3', '\x00', '\x00', '\x0e', '\xc3',
           '\x01', '\xc7', 'o', '\xa8', 'd', '\x00', '\x00',
           '\x00', '\x07', 't', 'I', 'M', 'E', '\x07', '\xe0', '\x05',
           '\r', '\x08', '%', '/', '\xad', '+', 'Z',
           '\x89', '\x00', '\x00', '\x00', '\x0c', 'I', 'D', 'A', 'T',
           '\x08', '\xd7', 'c', '\xf8', '\xff', '\xff',
           '?', '\x00', '\x05', '\xfe', '\x02', '\xfe', '\xdc', '\xcc',
           'Y', '\xe7', '\x00', '\x00', '\x00', '\x00',
           'I', 'E', 'N', 'D', '\xae', 'B', '`', '\x82']
| improve this question | |
  • 1
    This almost sounds like a job for code golf. codegolf.stackexchange.com – stib Nov 12 '19 at 17:20
  • I am familiar with code golf and even played some. How do you reckon this is a good fit? :-) – MadPhysicist Nov 12 '19 at 21:34
  • Well if you consider writing a h.264 file could be considered writing code—it's a piece of code that gets rendered to produce an image, juts like a piece of html gets rendered to produce a web page. Maybe a stretch, and I don't know how many golfers would be familiar with the intricacies of h.264, but it's trying to produce the smallest valid piece of code. – stib Nov 12 '19 at 23:43
2

A one frame H264 stream would have to consist of an intra-coded frame, so there is a size floor in effect.

This ffmpeg command produces a 1.7 kiB file

ffmpeg -f lavfi -i color=blue:s=1280x720 -vframes 1 out.mp4

You can save ~200 bytes by lowering the resolution.

| improve this answer | |
  • Out of interest, why blue? – stib Nov 12 '19 at 17:21
  • No reason in particular. – Gyan Nov 12 '19 at 17:52
  • I tested it and found that if you use white instead you save 6 bytes. – stib Nov 12 '19 at 23:46
  • There's a lot of plain text in the header, e.g. there's a copyright notice and a URL H.264/MPEG-4 AVC codec - Copyleft 2003-2019 - http://www.videolan.org/x264.html. I tried just yeeting it out with a text editor but the resultant file wouldn't play. I'd say you could optimise it a bit more by studying the mp4 file format more than I have time to do: xhelmboyx.tripod.com/formats/mp4-layout.txt – stib Nov 13 '19 at 0:07
  • 1
    That's not MP4 data, but SEI unit inserted by the x264 encoder. Yeah, that could be filtered out. I wasn't trying to absolutely optimize the size. – Gyan Nov 13 '19 at 5:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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