Archived from the Transloadit support forum. Originally posted on April 1, 2013; details may be outdated, see our docs for current behavior. Original thread
Our company recieved an internal command error when uploading a large video ~200MB. We are using the standard ipad high preset, so the error is entirely on the side of Transloadit even though it only applies to this particular video.
I notice that the process has been terminated externally:
[libx264 @ 0x11efa50] ref P L0: 77.0% 23.0% [libx264 @ 0x11efa50] ref B L0: 87.7% 12.3% [libx264 @ 0x11efa50] ref B L1: 95.0% 5.0% [libx264 @ 0x11efa50] kb/s:1168.98 Received signal 15: terminating.
and that there is a strange warning about the framerate:
Seems stream 1 codec frame rate differs from container frame rate: 120000.00 (120000/1) → 29.97 (30000/1001)
There have been I think two conversions of the video to .mp4 (using Apple’s Quicktime I think) and both of them failed also. I think, however that whatever was peculiar about this video was transferred to the converted videos.
It seems to be attempting to encode to an absurdly large framerate (upto 60 fps). I am attempting to convert the video using FFMPEG first with similar spec and to then try converting with our application. Of course this bug still ought to be looked at and especially why the conversion was ended with an external signal.
It only has happened so far with one video and re conversions of this video. I will try to find out who converted this video and how.
I thought of altering the framerate, but then I noticed that that iPad-High preset already has r: 25 . If it is encoding at 60 fps @ 25, then I doubt that there will be an advantage here.
I think that by converting to another format and then uploading, then it should work. As the video is very large, it is hard to keep attempting new things. I’ll try it if the next approach does not work.
I created a script to import the video from S3 and convert it to iPad-Low, but this assembly (when replayed with the updated template) failed completly (REDACTED - ASSEMBLY_CRASHED). It could be a secondary issue, but not important for us as we don’t do this often.
Obviously the problem is as you have said with FFMpeg and the external signal. Is there a reason why you think that this problem is fixed in a later FFMpeg version?