Video materials are being transcoded down

[kirkkwang]

Currently, when adding a video, the derivative is being produced at a 240p resolution. Audio derivatives are less noticeable but worth asking the clients to verify.

relavant message from Rob in Cal State Slack channel

The original should still be preserved but a derivative is what is being shown. This happens as part of the derivative process in the actor stack. You can enable / disable it and set the path in config/initialzers/hyrax.rb. Getting ffmpeg compiled exactly right is often challenging. See https://github.com/samvera/hyrax/blob/main/documentation/legacyREADME.md#transcoding for some info about that. We’re using a pretty well vetted configuration in ansible to get that done on the prod servers. The actual config options for it are found here: https://github.com/samvera/hydra-derivatives/blob/568a15a4dc664759fe28e59257c89d5adaac1dc2/lib/hydra/derivatives/processors/video/config.rb#L58 The are pretty tiny for sure.

Testing

• [ ] Create an Attachment with a video, something 1920x1080 should do, like this sample
  • [ ] Make sure to add http://pcdm.org/use#IntermediateFile for its RDF type otherwise derivatives will be skipped
• [ ] Observe that the video looks good and not super low resolution

[kirkkwang]

must have closed it by accident

[kirkkwang]

https://github.com/scientist-softserv/atla_digitial_library/blob/main/app/services/hyrax/file_set_derivatives_service.rb#L89

[kirkkwang]

Used the solution from ATLA but it isn't working, looks like file_set.width and height isn't being set

[DiemBTran]

This passes SoftServ QA: See attached screenshots.

tested on:

• 1920x1080 video: https://dc.utk-hyku-staging.notch8.cloud/concern/attachments/0ae79560-105a-492e-baf4-7284c98d0b48?locale=en
• vertical video: https://dc.utk-hyku-staging.notch8.cloud/concern/attachments/7b9c4b91-ed11-41a4-a036-ecc270ac5bc6?locale=en

Testing

• [x] Create an Attachment with a video, something 1920x1080 should do, like this sample
  • [x] Make sure to add http://pcdm.org/use#IntermediateFile for its RDF type otherwise derivatives will be skipped
• [x] Observe that the video looks good and not super low resolution
  click to expand

[markpbaggett]

Hey @kirkkwang,

Quick question about this one. I've added a few video objects from our repository, but none of them seem to play in UV.

You can see examples here and here.

My assumption is these are not working because they are getting transcoded down. My question: since we have to migrate preservation videos and an access copy since the latter sometimes has had a ton of editing, can we just not generate a derivative for the access copy (http://pcdm.org/use#IntermediateFile) and serve it as is in the player. Everything will also have a http://pcdm.org/use#PreservationFile that goes along with it.

We rarely do A/V work in house, and when we do we hire specialists. Because of this, our projects always come to us with a preservation file and an access copy (derivative that may or may not have had extra editing done to it).

Let me know what you think, if you have questions, or if I'm missing some of what is being asked.

Best, Mark

[kirkkwang]

Thanks for the heads up @markpbaggett. I just want to make sure things are documented here as well even though we spoke. It's looking like the videos are just taking a long time to process. Not sure what happened to your first try of it though 🤷🏼 but the second one, as of when i'm writing this, is still churning.

I am curious if you can try on our QA tenant on production and see if it'll be faster because production has more resources dedicated for processing than staging. That's the current hypothesis anyway, throw more resources at it and hopefully it'll go faster. If that doesn't work then we need to dig a little deeper.

[markpbaggett]

@kirkkwang yep, will try. I'm assuming that the hyrax-iiif-av gem is already on the qa tenant, but mentioning in case it's not.

[markpbaggett]

@kirkkwang I think this one looks good:

https://dc.utk-hyku-staging.notch8.cloud/concern/attachments/132ae996-0db8-402d-b450-5095a9b14b6b

Let's move this one forward.

[markpbaggett]

@kirkkwang per our meeting on december 20, 2022, i'm moving this one to Done. we will review again once we get to importing a/v.