[filehandling] add explicit "profile" attribute to audio/video Previews

[eins78]

for Previews with media_type: audio and video

---

currently:

# config

zencoder_audio_output_formats_defaults:
 - {audio_codec: 'vorbis', skip_video: true}
 - {audio_codec: 'mp3', skip_video: true}

# DB
media_files:
  - id: mf1
previews:
  - id: p1, codec: mp3, media_file: mf1
  - id: p2, codec: vorbis, media_file: mf1

new:

# config

zencoder_audio_output_formats:
 vorbis: {audio_codec: 'vorbis', skip_video: true}
 mp3: {audio_codec: 'mp3', skip_video: true}

# DB
media_files:
  - id: mf1
previews:
  - id: p1, conversion_profile: mp3, media_file: mf1
  - id: p2, conversion_profile: vorbis, media_file: mf1

There was already an attribute added which relates to the codec,
so to keep it simple we can rely on the following rules:

1. The content of the existing configs won't change, just their structure (a map)
2. The key of each config in the map will be the same as the "codec"
   (Because multiple configs with same config are not supported yet, we can safely assume this.)

---

questions:

Name of the attribute? conversion_profile? preview_profile? madek_preview_profile?
(Note that this is conceptually the same attribute as the thumbnail attr for Previews with media_type image, but we don't have to change that)

---

tasks

• deploy: change config for audio, video (array to map)

• DB: migration audio

  • add conversion_profile attribute to previews
  • set conversion_profile attribute for existing previews
    (find profile according to the "codec" prop, "id" of profile is the key of config in the map)
  • remove persisted codec (we use profile instead)

• DB: migration videos

  • add conversion_profile attribute to previews
  • set conversion_profile attribute for existing previews
    (find profile according to the "codec" prop, "id" of profile is the key of config in the map)

• DB: migration zencoder_jobs ???

• admin/webapp

  • use new config name and format
  • adjust the filtering etc in mediafiles controller

[eins78]

@michalpodlecki I made it even simpler: You can rely that the new key will be the same as the codec so we can reuse the migration you already did – it's basically renaming the attribute if I am not mistaken.

[michalpodlecki]

@eins78 yes, renaming would be enough.

[eins78]

@michalpodlecki small addition: if you have to adapt all places that use that config anyhow, it's a good oppertunity to change that confusing name (minus _defaults).

[michalpodlecki]

@eins78 I agree 👍