From Designer 7.7.3, image and application fields have a new property: Media type tag on the Image properties and Application field properties tab respectively.

Previous to Collections 1.11, linked video and audio files displayed broken-link icons in front of records in the Result set and Gallery views (although the files displayed or played fine in the Media Viewer), if no proper thumbnails could be generated, as is the case for audio and video files, or documents for example.
From Collections 1.11 though, if properly set up and if media types are registered together with media references in the records, then for file identifiers without file extension (which could occur when media files are retrieved via the WebAPI or a DAMS), instead of broken-link icons, the following generic icons will display for audio, documents, images and video files. These icons will also be displayed without proper setup or registered media types if the media type can be distilled from the file name extension while still no proper thumbnail can be generated.

So if the registered media files in your application all have a file extension, like .jpg, .doc, .mp3 or .pdf for example, you don't need to change anything to the setup of your image and application fields: Collections 1.11 will automatically notice and recognize the file extension and if it can't create a proper thumbnail image, one of the above icons will be displayed in the Result set and Gallery views instead.

If, on the other hand, most or all of the registered media files in your application do not have a file extension, because they are identifiers for files retrieved from a DAMS, for example, and you would like the above generic icons to be displayed instead of no icon (!) at all when no thumbnails can be generated, then you will need to do some set up, as follows:

The new setup will make sure that whenever a media file is now uploaded to one of these image or application fields in a record in edit mode, the relevant MIME type will be entered in the Media type field automatically: Collections will extract that type from the file extension or from the file itself if it has no extension. The user won't need to touch that value and Collections will use it to display the proper generic media type icon when appropriate but also to prepare the Media Viewer for the proper media type.
The reason for the media type screen field being writable is that if the above setup has been applied to fields in a database which already has data in it, the user must be allowed to enter the appropriate MIME types in this field manually, if desired. (If all MIME types are the same for a particular field, one could use the Collections Search and replace function for a record selection, to enter that MIME type for a lot of records all at once.) Note that a MIME type registered in the media type field will take precedence over any actual file name extension (if present), when Collections determines which media type icon to display.

Valid MIME types can be found on the internet. Common ones can be found here, for example: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Common_types

By the way, an actual thumbnail of an image file of which the MIME type can be determined, will only be generated by Collections if it is one of the HTML5 image types (GIF, PNG, JPEG or SVG). Of other file types, no thumbnail can be generated.

Further note that for one or two customers a <MediaTypeTag> element was introduced and implemented earlier (but never documented) in their settings.xml to do the same thing as the new Media type tag field property, but that setting is now deprecated (because it doesn't work in all situations) and should be replaced by using the new field property.

Using this setting will break compatibility with older versions of Designer and Collections versions older than 1.11.