Parameter validation failed for command

09Jul2012 Posted by hvassing

Hi,

we have created a new ffmpeg transcode profile, however, the files are never transcoded using this profile as the only message we get is that:

Parameter validation failed for command (COMMAND) (Exception thrown (severity: notice) on line 242, in /usr/share/mediamosa-backend/sites/all/modules/mediamosa/lib/mediamosa_type.class.inc) Partial backtrace: #0 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/rest/mediamosa_rest_call.class.inc(959): mediamosa_type::check('command', 'COMMAND', '-acodec:libfaac...', false, NULL, NULL, NULL) #1 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/rest/mediamosa_rest_call.class.inc(288): mediamosa_rest_call->validate_rest_args(Array) #2 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/rest/mediamosa_rest.class.inc(428): mediamosa_rest_call->process_call() #3 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/response/mediamosa_response.class.inc(111): mediamosa_rest->process_call(Array) #4 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/response/mediamosa_response.class.inc(210): mediamosa_response->process_call(Array) #5 /usr/share/mediamosa-backend/sites/all/modules/mediamosa/mediamosa.module(299): mediamosa_response->process_rest() #6 [internal function]: mediamosa_init() #7 /usr/share/mediamosa-backend/includes/module.inc(819): call_user_func_array('mediamosa_init', Array) #8 /usr/share/mediamosa-backend/includes/common.inc(5021): module_invoke_all('init') #9 /usr/share/mediamosa-backend/includes/bootstrap.inc(2171): _drupal_bootstrap_full() #10 /usr/share/mediamosa-backend/index.php(20): drupal_bootstrap(7) #11 {main}

and

Type: MediaMosa - job scheduler Error (1003) was reponsed during sending TRANSCODE (ID: 174) to server http://mediamosa-backend.uio.no/mediamosa/.

Any thoughts on what might cause this and how to rectify it?

Comments

Can you provide me some

Posted by Robert on July 9th, 2012 - 14:56

Can you provide me some screenshots of the transcode profile settings and what version of MediaMosa you are using?

The location that is being

Posted by hvassing on July 9th, 2012 - 15:06

The location that is being passed and attempted validated is:

http://mediamosa-backend.uio.no/mediamosa//internal/server/jobstart?job_id=178&job_type=TRANSCODE&mediafile_src=P2lZIadgUegsGRRTfemuWAni&tool=ffmpeg&file_extension=mp4&command=-acodec:libfaac;-ab:256000;-ar:44100;-ac:2;-vcodec:libx264;-vpre:main;-profile:main;-pass:2;-b:1200000;-aspect:16:9;-s:640x360;-vf:'pad=640:360:0:0:black'

No error message is provided of what might be wrong. When looking at the Asset details, the job is set to waiting, and will time out

I've now uploaded a

Posted by hvassing on July 10th, 2012 - 07:56

I've now uploaded a screenshot of the transcode profile settings to http://folk.uio.no/hvassing/edit-mediamosa-transcode-profile.png. We are running MediaMosa 3.2.1 (build 1846).

Whatever might be wrong with the transcode profile settings, the larger issue is that the transcode profile is saved as normal and nothing shows up on the status page either. No error is given about the transcode profile might not validate until one tries to transcode a file with that given profile and nothing happens.

A second issue here is that the profile settings are validated against some criteria that - at least to my knowledge - are not posted anywhere and as such not available for us to test the profile settings against on beforehand. Could you please advice as to what these criteria might be?

Thanks for your feedback. The

Posted by Robert on July 10th, 2012 - 19:59

Thanks for your feedback.

The problem is that the ffmpeg (any tool for that matter) command parameters strings is build as an long string like 'name:value;name:value'. This code has been in MediaMosa since v0.1 and never been touched. Its one of those choices at the start, made by programmers that don't know that this is the worst choice you can make.

The problem is that name and value can never contain ':' or ';' for this to properly work. Now ffmpeg has some values like 16:9 that causes the problem. You suddenly will get; aspect:16:9;name:value. This is however solvable by saying the first ':' is valid. However, its getting worse. ffmpeg v0.10 now also has new command parameters that have ':' in it. So this whole string command line we use internally is really broken.

Okay that was the bad news. The good news is that I've written the unit test that recreates this problem on several layers of the code and already started to re-write the code to handle an url-encoded string instead of the name:value;name:value' version. I'm almost done and once it passes the first checks, Ill release it to Github for you to test. If all goes to plan, you should be able to test it by the end of this week.

For now, the only fix I can offer is not to use aspect 16:9 till the fix is released.

PS: I'm still working on the pgsql patch, which has already become the biggest patch ever for MM. Planned for RC testing MM v3.5 this month.

Thank you for your

Posted by hvassing on July 11th, 2012 - 08:40

Thank you for your reply!

Removing the set aspect ratio certainly helped get things through the system.

Although it's not a permanent fix, adding support for manually entering the ffmpeg-command in the transcode profile would go a long way to fix the problem you mention. See http://mediamosa.org/trac/ticket/559

The transcode profile could either be written in a way suits being passed through vpx-transcode:
-acodec libfaac -ab 256000 -ar 44100 -ac 2 -vcodec libx264 -vpre main -profile main -pass 2 -b 1200000 -s 640x360 -vf 'pad=640:360:0:0:black'

or it could be written as the complete ffmpeg-command with magic words in curly brackets:
ffmpeg {INPUT_FILE} -acodec libfaac -ab 256000 -ar 44100 -ac 2 -vcodec libx264 -profile main -an -pass 1 -b 1200000 -s 640x360 -vf pad=640:360:0:0:black -threads 8 -map 0.0 -an -y {OUTPUT_FILE}

By allowing manually entering the full command that should be passed to ffmpeg as transcode profile, will make for easier debugging as it will allow us to take the transcode profile and simply copy/paste it to run ffmpeg with those particular settings on that particular server. I would also allow us to specify the number of threads (cores) to use per transcoding profile and also for each of the transcoding servers.

I hope this will be considered as it would be of great help

I have discussed this with

Posted by Robert on July 12th, 2012 - 15:56

I have discussed this with the rest of the MediaMosa team, and we do feel its a good idea too. The idea behind the parameters, like it is now, is because we need to protected profiles to become extremely heavy in CPU usage. That is why we have some kind of limitation on the parameters and its ranges. We do have use cases where clients can add own profiles but with some limitations on the ffmpeg options and still be able to be powerful.

If we are going to implement this, to be able to add a complete ffmpeg command line per profile, then we will protected it with extra Drupal role(s), so client apps will be denied this option when needed.

I have put this on my list to-do and I think I'll manage to get it together with this patch for 16:9 problem. I'll let you know as soon I have the patch ready.

The fix for the 16:9 has been

Posted by Robert on July 25th, 2012 - 12:11

The fix for the 16:9 has been merged with master branch on Github (build 1888 or higher); git://github.com/mediamosa/mediamosa.git

I've completly rewitten the old encoding code, it can now handle any parameter or value pair for command line tools.

I'm still working on your ffmpeg command line option...