server based file size "change" on x264 file

[infante]

I have an unusual situation.
We have a crazy workflow that has us doing the following:

1. We encode a video file at the local level using x264. The result is a local copy of "file #1."
2. File #1 is uploaded to a linux based server
3. File #1 is duplicated on the server. Result is File #1 and File #2.
4. File #1 and File #2 are transferred via ftp server to another destination.

Now here is the crazy part. File #1 and File #2 cannot be the same exact size or the destination server will not accept the file. They need to be slightly different. It has been suggested to add a second of black space to the end of the video, but this would entail encoding a second video locally and uploading two files versus one (these are large files so we want to avoid extra work). Server based processing is more efficient here.

I would really appreciate a suggestion on how I can use a command based server script to make the two files slightly different in size after they are duplicated on the server.

Is their a command based process (or alternatively a software that can be run on Linux) that will change a file size without re-encoding the entire file as we don't want to unnecessarily re-encode a video?

Thanks for indulging me on a crazy situation!

[CarlEdman]

In what container are you producing the x264 output?

If it is mp4 or mkv, you can easily alter the file size by setting or unsetting any number of meta-data options using the free, generally available, linux-compatible tagging software.

If it is raw 264, surely there must be some tools that mix up the exact file contents without reencoding and while leaving the output unaltered. Not having had any need for such tools yet, I've not looked them up.

Out of curiosity, what induced such crazy behavior by that server?

[infante]

Thanks.
We are encoding to an MP4 container. Metadata injection was my first thought in adding a "benign" change and I did try a test using TMPGENC. I encoded without any metadata at first and the second test was with same settings but including metadata. And both were the identical size. Maybe TMPGENC inserts "null characters"??

regarding the reason, we are dealing with a unique situation involving youtube servers... sorry to be vague...

[CarlEdman]

Some MP4 encoders leave some effectively "blank" space for MP4 data, so that some fields can be set simply by writing data to a few blocks, rather than having to rewrite the whole file. However, that is pretty limited and obviously can't work with larger metadata.

Have you tried setting, for example, MP4 long-descs or adding cover art? The mp4v2 tools will do that for you and work under pretty much any OS. https://code.google.com/p/mp4v2/

[kabelbrand]

You could add another null byte at the end of the file, e.g.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

006606D0 D7 5A AE BA EB AD D7 5D 75 D6 EF BE FA EB AE BA ×Z®ºë.×]uÖï¾ú뮺
006606E0 EB AE BC 00 00 00 37 66 72 65 65 49 73 6F 4D 65 뮼...7freeIsoMe
006606F0 64 69 61 20 46 69 6C 65 20 50 72 6F 64 75 63 65 dia File Produce
00660700 64 20 77 69 74 68 20 47 50 41 43 20 30 2E 35 2E d with GPAC 0.5.
00660710 30 2D 72 65 76 34 30 36 35 00 00 0-rev4065..

[Asmodian]

Or maybe mux in a subtitle track with only one blank subtitle defined?

[LoRd_MuldeR]

You could add another null byte at the end of the file, e.g.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F

006606D0 D7 5A AE BA EB AD D7 5D 75 D6 EF BE FA EB AE BA ×Z®ºë.×]uÖï¾ú뮺
006606E0 EB AE BC 00 00 00 37 66 72 65 65 49 73 6F 4D 65 뮼...7freeIsoMe
006606F0 64 69 61 20 46 69 6C 65 20 50 72 6F 64 75 63 65 dia File Produce
00660700 64 20 77 69 74 68 20 47 50 41 43 20 30 2E 35 2E d with GPAC 0.5.
00660710 30 2D 72 65 76 34 30 36 35 00 00 0-rev4065..

Do not append additional bytes to a MP4 file after the last atom/box. Some MP4 parsers (don't want to name any names here) will fail horribly :scared:

Apparently some MP4 parsers work like:
while(not at EOF)
{
if(numberOfRemainingBytesInFile < 8)
makeApplicationCrash();

if(nextBytes(8) not_equal validMp4AtomHeader)
makeApplicationCrash();

if(typeOfNextAtom is someUnknownType)
makeApplicationCrash();

readNextAtom();
}

...and that's regardless of whether FTYP, MOOV and MDAT have all been found and processed correctly already. It just goes on and on.

[Selur]

one could remux using mp4box and an additional tag to the file,..