RE: AreaDetector stream encoding

["Daykin, Evan via Tech-talk" <tech-talk at aps.anl.gov>]

Thank you for your advice Tom and Andrew!

 

I will keep this in mind. Still not sure if AV1 real-time encoding is even fast enough yet, but I will try and chip away at something as time allows for us.

 

-Evan

From: Cobb, Tom (DLSLtd,RAL,LSCI) <tom.cobb at diamond.ac.uk>
Sent: Wednesday, May 26, 2021 12:01 PM
To: EPICS tech-talk <tech-talk at aps.anl.gov>; Daykin, Evan <daykin at frib.msu.edu>; Mark Rivers <rivers at cars.uchicago.edu>
Subject: Re: AreaDetector stream encoding

 

[EXTERNAL] This email originated from outside of FRIB

Hi Evan,

Has anyone started or tried adapting this to areaDetector?

When I originally did the work with ffmpeg I considered using H.264 instead of MJPG, but it seemed to require fixed framerate, so I went with MJPG as a simpler solution. Also, video support in browsers was limited at the time while MJPG was well supported. Since then, things have moved on a lot, and AV1 appears at first glance to support variable framerate, so it sounds like a better choice.

AOM libraries are available under a combination of BSD 2-Clause and their own copyleft license [3]. Are these compatible with the rest of AreaDetector?

I'm afraid I can't comment on the rest of areaDetector, but the GPL license on ffmpegServer was chosen somewhat arbitrarily. Most of the modules Diamond contributes now are licensed as Apache2 so I have no objections to changing ffmpegServer to Apache2 if this makes things easier and Mark Rivers is happy with this. I can't comment on compatibility with ffmpeg's license as I read their legal page and didn't understand it, this is why ffmpegServer has an install.sh script rather than distributing any ffmpeg code. Again, this was before the days of git, so the whole build process could probably be done better now.

Would anyone else be interested if we were to try and add this functionality?

We're happy with the performance of MJPG at Diamond, but if you were to add AV1 support then we'd be interested in trying it out. Unfortunately, I don't have much time to work on areaDetector modules anymore, but I'm happy to answer any questions you might have about the history of ffmpegServer.

 

Thanks,

Tom

 

 

 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Daykin, Evan via Tech-talk <tech-talk at aps.anl.gov>
Sent: 26 May 2021 16:13
To: EPICS tech-talk <tech-talk at aps.anl.gov>
Subject: AreaDetector stream encoding

 

Hello tech talk,

 

We are having issues with network saturation when too many clients are viewing too many simultaneous acquisitions on our 7 GigE cameras. We are currently serving the images via MJPG using AreaDetector’s ffmpeg stream. I recognize H.264/265 is probably not possible due to licensing, but I think it could be possible to instead encode our video using AV1 [1][2] if we use relatively low framerates.

 

1.       Has anyone started or tried adapting this to areaDetector?

2.       AOM libraries are available under a combination of BSD 2-Clause and their own copyleft license [3]. Are these compatible with the rest of AreaDetector?

3.       Would anyone else be interested if we were to try and add this functionality?

 

Cheers,

Evan

 

[1] https://aomedia.org/av1-features/

[2] https://trac.ffmpeg.org/wiki/Encode/AV1

[3] https://aomedia.org/license/patent-license/

 

 

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom