[Bug]: contentType field on /v1/ffmpeg/compose endpoint is ignored (file always has application/octet-stream)

[Rayvox]

Describe the bug

When using the /v1/ffmpeg/compose endpoint, I include "contentType": "video/mp4" in the output object as specified in the official documentation. However, the resulting file uploaded to DigitalOcean Spaces always has a Content-Type of application/octet-stream instead of video/mp4.

Forgive me if I've completely missed something in the setup or docs, but is this a known issue?
Is there a workaround for ensuring the correct Content-Type is set on Spaces uploads via this endpoint?
Can this be fixed so that the toolkit respects the contentType field as documented?

Reproduction Steps

Submit a valid /v1/ffmpeg/compose request, including the following output object:

{
  "options": [
    { "option": "-f", "argument": "mp4" },
    { "option": "-c:v", "argument": "libx264" },
    { "option": "-c:a", "argument": "aac" }
  ],
  "contentType": "video/mp4"
}

Inspect the file in DigitalOcean Spaces after processing.
The file is always set to application/octet-stream as its Content-Type.

Expected behavior

The file should have the correct MIME type (video/mp4) when "contentType": "video/mp4" is set in the output object. Even if no mime is specified, the output in the bucket should adopt the correct mime, but currently it is always octet-stream.

Screenshots and relevant files

Platform

Digital Ocean

Would you like to work on this issue?

None

Checklist

• I have searched the open issues for duplicates.
• I have shown the entire traceback, if possible.

Additional Context

• I have tested with and without the contentType field; the result is the same.
• The Spaces upload is performed by the toolkit as part of the compose operation.
• Even the thumbnail which is outputting a .jpg adopts the octet-stream.

[arturmeinzer]

I have the same issue with Minio self-hosted. A solution would be appreciated.

[Rayvox]

I have the same issue with Minio self-hosted. A solution would be appreciated.

Not a permanent fix by any means, but I wrote a little Python script that I call immediately after the file is created via the Python endpoint. It basically replaces the mime by replacing the file with itself with the correct types. You can use this as a workaround for now:

import boto3

s3 = boto3.client(
    's3',
    endpoint_url='[YOUR SPACES ENDPOINT]',
    aws_access_key_id='[YOUR ACCESS KEY]',
    aws_secret_access_key='[YOUR SECRET ACCESS KEY]',
    region_name='us-east-1'
)

bucket = '[YOUR BUCKET NAME]'
key = '[YOUR FILE KEY]'

s3.copy_object(
    Bucket=bucket,
    CopySource={'Bucket': bucket, 'Key': key},
    Key=key,
    MetadataDirective='REPLACE',
    ContentType='video/mp4',
    ACL='public-read'
)

print('Content-Type updated to video/mp4')

(I'm sure the script can probably be written better, but this is what I got for now).
Just wire up the placeholders with the info coming from the return of the FFMPEG endpoint.

Then in n8n I'm converting the script into a JSON String and sending it with the Python endpoint with this body:

{
  "code": {{ $json.python.toJsonString() }},
  "timeout": 60,
  "id": "[SOME ID HERE]"
}

It's near enough instant and works reasonably well. I'd just prefer if the bug was fixed from the file creation as opposed to having to use a workaround.

[askb]

I've the same issue, any upload (using compose / thumbnail API's etc) to the nca-toolkit service creates object metadata on the S3/miniio as "binary/octet-stream" which is incorrect, and the content-type mime type get ignored. Would be good to get this fixed.

File Name:
a87bdca1-2a86-4823-aac4-99308d49f0d9_captioned.mp4
Directory:
nca-toolkit
File Extension:
mp4
Mime Type:
binary/octet-stream
File Size:
1.83 MB

An alternative solution is to change the mime-type with a code node:

const binaryData = items[0].binary;
const binaryKey = Object.keys(binaryData)[0];

// Force video/mp4 MIME type
binaryData[binaryKey].mimeType = 'video/mp4';

return [{
  json: items[0].json,
  binary: {
    data: binaryData[binaryKey]
  }
}];

[hamchowderr]

Hi I just want to comment that this is actually default behavior from the Toolkit (and many other platforms). I thought it was an error as well but AI can be very misleading. I have tested and used on Supabase and Spaces on Digital Ocean. The file type is specified on the file but because there are no headers it does not "upload" the traditional way. Nonetheless it does not affect anything, you just need to add oclet-stream as mime-type in the platform you are using. You can even take it a step further and "copy" that data to update it, but it will still have oclet-stream along with any other file type. @askb @Rayvox @arturmeinzer. I hope this helps.