I have two different content types with two different instances of the video field widget. One for audio and one for video using different presets.

I've specified a different set of allowed file types (for upload) on each and in both cases the the helper text only shows a subset of the list I've entered.

Allowed fields for audio in manage fields is set to: wav, ogg, oga, wma, mp3, mp4, flac
Helper text for audio on the node create form: ogg mp3 mp4

Allowed fields for video in manage fields is: mp4, m4v, ogg, avi, mov, wmv, flv, ogv, webm, ts, mpeg, mpg, mkv, rm, mxf, asf
Helper text for video on the noe create form: mp4 m4v ogg avi mov wmv flv ogv webm mpeg mpg mkv rm asf

(missing ts and mxf)

Is the list being sanitised somehow, and from where? Is this a core issue, video module issue, or server/php/mime type issue?

Any clues/help be appreciated.

Thanks

CommentFileSizeAuthor
#1 allowed-files.png28.7 KBTsubo
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Tsubo’s picture

Category: support » bug
Priority: Normal » Major
FileSize
28.7 KB

Done some further tests on this. The Video field is definitely sanitising the allowed file types somehow.

I've created a standard file field and can add whatever extensions I like (as expected), but if I use a Video field some of the extensions get removed. See attached screengrab of a standard file field next to a Video field both should allow wav and m4a...

Video field does not allow either of them.

I've had a look through the module code but can't see where this could be happening.....

Any help?

Tsubo’s picture

Title: Allowed file types not displaying in helper text on node create » Allowed file types for Video field not respected

Changing title to be more accurate.

Jorrit’s picture

I'll update the list of extensions as soon as I have time.

Jorrit’s picture

Status: Active » Fixed

Fixed in 7.x-2.x-dev.

Tsubo’s picture

Thanks as always. You're a star.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

adamtyoung’s picture

Status: Closed (fixed) » Needs work

I am still not able to use wav files after installing the dev version.

adamtyoung’s picture

Status: Needs work » Active
Jorrit’s picture

I've added wav to 7.x-2.x-dev.

MilosL’s picture

I had similar issue with Sony MTS files - video field refused .mts extension and hided it without notice. Directly (command line) executed, ffmpeg decodes it without any problems (is avchd/mpeg4 file).
I'm not sure how for Zencoder, but for ffmpeg makes built-in check against supported input extensions (this causes mysterious disappearance of some added extensions) less sense. FFmpeg can handle nearly all available video files regardless to extension - e.g., if you rename your wav file to mp4, it will be properly recognised and handled even as audio file. On the other hand, if you rename - for example - .txt file to .mov, video field easily creates encoding job - and fails later after encoding is started.
For input validation would be anything like "fileIsDecodable()" function better - similar to "$movie->hasVideo()" or "$movie->hasAudio()" from ffmpeg-php extension.

neorush’s picture

It appears as if the list is sanitized by the array coming from getVideoExtensions() in video.utilities.inc
Adding an extension to the array will allow it to show up in the allowed file extensions list. m2ts is a great example of a file the ffmpeg can handle just fine, but it cannot be uploaded for processing. Here is an example of a fix to add m2ts as an allowed file:

  /**
   * Return our list of video extensions and their associated player.
   */
  public static function getVideoExtensions() {
    return array(
      'divx' => 'video_play_divx',
      'mkv' => 'video_play_divx',
      'mov' => 'video_play_html5',
      '3gp' => 'video_play_quicktime',
      '3g2' => 'video_play_quicktime',
      'mp4' => 'video_play_html5',
      'm4v' => 'video_play_html5',
      'rm' => 'video_play_realmedia',
      'f4v' => 'video_play_flv',
      'flv' => 'video_play_flv',
      'swf' => 'video_play_flash',
      'dir' => 'video_play_dcr',
      'dcr' => 'video_play_dcr',
      'asf' => 'video_play_windowsmedia',
      'wmv' => 'video_play_windowsmedia',
      'avi' => 'video_play_windowsmedia',
      'mpg' => 'video_play_windowsmedia',
      'mpeg' => 'video_play_windowsmedia',
      'ogg' => 'video_play_html5',
      'ogv' => 'video_play_html5',
      'webm' => 'video_play_html5',
      'mp3' => 'video_play_html5',
      'm2ts' => 'video_play_html5',
    );
  }
ñull’s picture

Issue summary: View changes

Wouldn't it be better to give the site administrator control over this? Isn't it overly protective when the software decides what extensions there should be allowed? Isn't it the administrator who knows the appropriate transcoder for the chosen file types? Why take away that control from him/her?

brycefisherfleig’s picture

Hi null,

Thanks for the input here, and I totally agree. At a *minimum*, we should document this sanitizing behavior in the admin forms and possibly `drupal_set_message` an error when unsupported types are entered. Ideally, we'd allow this list to be configurable in the admin form.

I haven't carefully examined the relevant for this feature yet, but given that this function is returning an associative array, it seems like we'd need to figure out a sane strategy for exposing the association between a file extension and a player in the form, and there may be other big effects in other parts of the module. At that point, we're talking about a feature request not a bug report.

I'll keep this issue open to add some indication of this behavior in the admin form and create error messages.

However, I'm opening a new feature request to make this configurable. Please do share your thoughts on how best to do this on #2280739: More configurable allowed file extensions for video field widget.

heshanlk’s picture

Component: Video Field » General
Status: Active » Closed (works as designed)