The following transcript was generated by AI and may contain inaccuracies.
Sam: Hello everyone, and welcome to today’s Amped Podcast episode. Today, we’re going to be taking a look at how new features are developed. I’m Sam Abbot, and I’m joined today by two of my esteemed colleagues.
Emi: I’m Emi Polito. I’m a forensic video analyst here at Amped Software. Great to be here with everyone.
Andrea: Hi there. Great to be here. I’m Andrea Frisina. I’m a technical support specialist and trainer at Amped.
Sam: I’m a forensic video analyst and a software tester. Here at Amped, we’re very fortunate that we have a very close connection with our users. Whenever we are developing our software or thinking of new features to go into the software, those ideas normally stem from our users, and that’s what we want to focus on today: to give you an insight into how your feedback influences the development of our software.
So I wanted to start off with where users’ ideas first appear, and I’ll pass over to one of my colleagues to go through where that first idea for a new feature comes from.
Emi: Well, I can start by saying, Sam, that I’m in a very privileged position, in that I am a user myself.
Mainly of Amped FIVE, but over the years I’ve also had a good go at Amped Replay, Amped Authenticate, and Amped DVRConv, which are our other products. So when I’m doing casework, something might pop up in my head and make me think, “If only we had this feature, how beneficial it would be for other users.”
When that happens, I’m usually straight onto our internal channel to discuss it with our hybrids team, which is a team of forensic experts who act as a bridge between our developers and our commercial people. And then the conversation starts.
I can give you a few examples. One I really recall was when I was building a timeline in Amped FIVE. A timeline is a compilation of different clips that we put together to show the trier of fact – the jury or the judge – the sequence of events across different cameras or different sources.
In Amped FIVE, this requires a combination of different chains, and also the use of a selector field so that you can top and tail these clips. So of course it can be done, but I thought, wouldn’t it be cool if we could have keyboard shortcuts to top and tail our clips, so it resembles a video editor a little more?
Sam: Right.
Emi: So that’s just one example, and I’m sure we’ll have many more. Andrea will talk a bit more about how users ask us for things, but usually in my case it’s me who comes up with ideas that we then discuss with others.
Sam: And just to pick up on that point, I think it’s a very unique aspect of Amped, and a very fortunate one, that a lot of the people employed here are still expert users of the software.
So we have that direct link to what casework needs, and we continue to follow the development of this industry and what’s needed in the courtroom.
Emi: I totally agree with you 100%. I think it’s so important that in our company we have a group of people who were not only users themselves, but who can also relate to our users’ needs.
Sam: Exactly.
Emi: Because we understand exactly where they’re coming from.
Andrea: Yeah, I definitely agree with that. I come from a different perspective because, as you know, I’m not a user myself. I don’t do casework with our products. Nevertheless, I use the products a lot, and I see how users use them.
Many of our features actually come from an original idea or input from end users or trainees, who might suggest something during training or through our support channels. Also, while I’m using the product for tech support, or when I’m explaining things in training, I might come up with specific needs that are then translated and fed into our internal channels to our devs.
So we’ve come up either with small ideas for specific tools, or with larger ideas on how to improve workflows, which might involve adding several smaller tools or filters to our products. It’s nice that we have such a variety of users, both inside the company and outside it, and most of them come from different backgrounds.
Some of them are beginners and some are very advanced users, and you get different kinds of input from both. They’re different, but neither is better or worse. In my opinion, beginners are just as likely to come up with very interesting suggestions as experienced users.
Sam: Definitely, I think that’s a really good point. When you’ve been using the product for a long time, the creativity for new ideas tends to fall off. When you get a new pair of eyes looking at the software, that’s when a lot of good ideas come out.
Andrea: Definitely. Some of the most ingenious and original ideas actually came from what we’d call newbies: people who were just starting out with FIVE or Authenticate, maybe on their first training course. Those people might have used different products before, so they had a completely different perspective from ours.
Sam: So we’ve looked at ideas coming from an ex-user and expert use case, and also from training. But there are also different ways people can give us ideas, and I want to get that out there for users who might not be aware how easily they can contact us. Let’s quickly mention those other channels.
That way, if users have an idea they want to see in the software, they’ll know it’s very easy to get in touch.
Emi: Oh, absolutely. I think we’re in a very privileged position at Amped Software because we’re an independent company, and we have a direct line of communication with our users.
As you mentioned, there are several channels our users can use to get in touch. Of course, face-to-face interaction is always great. You and me, Sam, here in the UK, and sometimes you, Andrea, go out and see our users at conferences and trade shows, and that’s a very good source of ideas.
It gives us an opportunity to catch up. But we also have a variety of social media platforms. I find Discord to be a really good source of information. We have a Discord server that’s open only to our users and staff, and within it we have one channel where users can go and ask us for new features.
I really like that at Christmas time we have one particular user who always says, “Christmas is coming, I’d like Santa to bring me a present. Can we have presets in FIVE? Can we have concatenation? Can we have whatever?” That gives us the opportunity to sit down, see whether other users have come up with the same idea, and say to ourselves, “This is an opportunity to develop this.”
Then of course we have other social media platforms like LinkedIn and YouTube, but I’d say those are more for consuming content such as tutorials or educational material. Discord is definitely a good informal way to ask us about features.
And then, Fris, you may want to elaborate on this a little, we have our formal support channel where we get more formal requests.
Andrea: Sure, I’ll definitely add a couple of things. I’d say it’s almost impossible not to reach us. We are very easy to get hold of.
Emi already mentioned the support channel. That’s our main official channel for support requests, and by “support request” I mean pretty much anything related to the products. The typical approach is that users just need to drop us an email. We’ll evaluate it and reply, and we really are open to any kind of request.
It could be a bug, it could be a feature request, or it could just be a question. We reply to general questions too, even ones not strictly related to the products, as long as they pertain to the type of work that we do.
Emi: Yeah.
Andrea: So that’s definitely a major channel of communication.
I’d add training to that, of course. Training is a huge input for us. It’s a moment in which we teach trainees, but also a moment in which we learn a lot from them. We have private training sessions where we’re really able to see how a specific agency works and what their actual workflows are. And we run open classes where we can see how officers from all over the world work and the different strategies they use, so we learn a lot from that as well.
Sam: Perfect. So we get all these ideas from our users from different areas, and there are a lot of them. Then we get to the stage of discussing them within the company, and I think one of the important first steps, which I want our users to know about, is how we differentiate between an isolated issue that a single user is having and a market trend that multiple people are expressing.
How would you explain to users how that happens? Actually, before we get into that, I just want to say that even if it is an isolated issue, nearly every single individual comment gets recorded in our internal database.
Emi: Yes, Sam, I was just going to get to that point.
We all work in different departments and we have different ways of getting feedback from our users, so we need a central point where we can collect this information. At Amped, we use an internal ticketing system based on GitHub, where we can record things like interactions with our users or, in this case, feature requests. That way we record the data, and our product management team and development team can also look at the content.
To the point you made about isolated feature requests: there may be a single request from one user that makes me sit down and think, “That’s a pretty cool idea. Why didn’t we think of that?”
But of course, if a feature request gets asked repeatedly, it will get noticed at some point, because we have a central point to collect the information and we can see exactly how many users are asking for something. For example, the Writing Queue, which is a very cool feature we introduced recently in Amped FIVE, gives you the ability to batch write videos.
That saves people a lot of time when they have lots of chains to output to video, and it was asked for a million times, I’d say. Of course, our users also need to understand that certain feature requests, although very valuable, may take a long time to develop. That’s not because we have a slow development team, but because there are certain things in the core of our code that we need to look at before we even start implementing a feature.
Sam: Definitely. Part of it as well is that we have a huge backlog, because we take everything into consideration. I think on GitHub at the moment we’ve got around 7,000 open tickets.
Emi: Yeah.
Sam: And that’s why it’s important to identify the trends, so that we can begin to prioritise.
Emi: Sure. I don’t think it’s an unusual situation for a software company to have a backlog like that. But you’re right, we need some sort of prioritisation. Another thing I’d like our users to know is that we get together quite often: once a week, every Monday afternoon.
We call it the hybrids meeting. The reason we call ourselves the hybrids is that we act as intermediaries between people with feelings, who take care of the marketing, sales, and commercial aspects of the company, and whom we call the humans, and people with no feelings but a lot of code in their heads – our developers.
So we get together every Monday afternoon and discuss a lot of things, among them feature requests from ourselves and from our users.
Andrea: Sure. I’ve worked in other companies, and that hybrids meeting is a really peculiar kind of meeting.
I’d call it an arguing session, because mostly we argue about these topics. As you said, Sam, we gather input from all these channels and we have thousands of requests. Some of them are very reasonable, and others we don’t agree with for various reasons.
Quite often we don’t agree with each other either, and deciding what to implement and what not to requires quite a long discussion. Regarding trends, we definitely have a wide variety of semi-random requests, and those are fairly easy to approve or reject.
But when it comes to trends, it becomes a little trickier. First of all, you have to wait quite a while – at least months – to understand where a trend is going. Then you have a lot of discussion in the hybrids meetings Emi mentioned, to understand whether this is really a trend we want to follow.
And usually, if we’re dealing with a trend of requests, the solution won’t just be a simple little new feature, but something slightly larger – maybe more than one feature working together. So it’s a really nice moment, that Monday afternoon, to discuss and brainstorm. It’s a beautiful moment in a company, I think.
Sam: Yes, definitely. And building on something you just said: when we get that first idea from a user, it’s very easy for the user to ask for the world.
So while we’re discussing the idea, we need to find the balance between how powerful it’s going to be, how simple it’s going to be for the developers to create, and how intuitive it’s going to be for the user. I’d like some insight from you both on how we strike that balance and how we drill that initial huge idea down into something the user is going to benefit from in the end.
Emi: I totally agree, we need to get the balance right. What I think we should add as well is that we deal with users who work in forensics. So we need to make sure that our features are not only powerful and intuitive and all the things you mentioned, but also forensically sound.
That’s one of our top priorities, and perhaps that’s why we have a group of people like ourselves who are users. Our boss calls us the “ex-coppers,” although I myself have never been a police officer – I worked in law enforcement – and you, Sam, I think, worked in the military.
It’s important that we think about features, or the development of features, that could potentially create problems for forensic soundness.
I’ll give you an example. I remember when we were discussing giving users the ability to extract a timestamp when converting videos in DVRConv. Of course, we can do this in FIVE, because FIVE has its own playback system, which can control things like frame rate and playback speed based on the timestamps we extract from the files.
But with DVRConv, some users asked us, “We want to be able to convert videos and then play them in an outside player like VLC, but also have the timestamp available.” Because we couldn’t control the playback of that video outside of our products, we found that if we extracted the timestamps, we couldn’t control the synchronisation of that timestamp with the video.
So although it was a very exciting, very powerful, and much-requested feature, in that instance we decided to put it on hold, because we were concerned about safety for our users.
Sam: Yeah.
Andrea: I’d say most of these discussions come down to constraints.
We have to evaluate the constraints and the cost-benefit ratio of implementing something. There are the usual constraints that all software companies have, like speed, as you mentioned, and ease of use, which is extremely important. When you come up with an idea, you might create a wonderful tool that’s very complex to use without realising it, because you made it. But a new user would find it very difficult.
On top of those, we have forensic soundness, which is a constraint that companies making general-purpose software don’t have. So that’s a very important thing for us. We might say no to users – and we do say no to users if that’s the appropriate thing to do. The one thing we make sure of is that we explain why we decided not to go ahead with that feature request.
I think that’s an important moment for us, because in that case support explains to the user why we made that decision. Because we explain the reason, we make the user who requested it aware of the issues with that request. So it’s an educational moment, I would say.
Sam: I think as well, when we accept a new feature and decide it’s a great idea, we go to the developers internally and see whether they have any constraints on the development side.
Andrea: And they do most of the time.
Sam: Most of the time, yeah. And I think our biggest downfall is that we don’t speak robot. We often give them a spec, and they’ll create it to the letter. But things we thought would be obvious as users, we didn’t tell them. That’s where the next stage comes in, which is where it comes to me: testing.
Emi: Yes.
Sam: I think a lot of making a feature intuitive for our users comes from that testing stage, which is a really important part of the growth of a new feature.
Emi: I absolutely agree. I just want to mention a few things about this, and then maybe ask you, Sam, as a tester, how the testing stage progresses.
But regarding the initial planning, where obviously we have to get the development team involved at some stage, I really like the fact that for major features we have a dedicated meeting – we call it a focus meeting – where we get together with the main developer who’s going to be assigned to that feature.
At this stage, the feature request has been accepted and approved. We’ve realised that it’s in our users’ interest, and in our interest, to start developing the feature. So one or two developers, depending on how big the feature is, get assigned to the project.
Then we have the focus meeting, which I think – I hope you agree – really helps us understand that some things we might ask for may be complicated from a development point of view. That’s the opportunity to say, “If this is going to take too long, maybe we can do this instead.”
For our users it won’t make much difference, but from a development point of view it might be much more practical. We did this, for example, with the new Assisted Redaction function in Replay, which was such a massive project. We obviously had a focus meeting with the main developers.
This project was really interesting from a company point of view, because we had an integration team that took care of integrating the model into the software, and an AI team that looked at the training side of Assisted Redaction.
I’d also like to mention how I personally approach this. I don’t do it so much anymore, mainly because I’m currently focused on other areas. But when we have a feature and we’ve decided all the main points, I start looking at how it’s going to look. I use Photoshop for that – and please don’t tell Spready that I use Photoshop, otherwise he’ll kill me!
It’s just so I can add buttons and show where they sit in the interface, so the developers have a reference point to work from, certainly in terms of the graphical user interface. Of course, this has to be approved by everybody else first, and for major features like Assisted Redaction it’s more of a group decision.
But that’s how I like to approach it. Then, of course, after that comes the testing stage. Sam, do you want to explain a bit about how that works? I understand there are different tiers of testing.
Sam: Yeah, sure. Within the company we’ve got two – well, three – stages of testing. First, the developers do their own tests as they’re creating the feature. Then it gets passed to our level one testers, who are colleagues in my team.
Emi: What does level one entail?
Sam: Level one testing is that first, initial check: making sure that if you press a button, it does what it’s supposed to do.
So you’re doing the “buttonology” of the feature, making sure everything is working as it should, but you’re not really looking at it from a forensic point of view or a workflow point of view at this point. That’s when we go to level two.
Emi: So you’re just making sure the feature on its own is working as intended.
Sam: Exactly. Then, once that testing is complete, it goes to level two testing, and that’s when you really start looking at it as a workflow.
Emi: And this is the area you’re most involved with at the moment.
Sam: Yes. This is what I do most of my day, every day.
Emi: You love it, right?
Sam: I absolutely love it. It’s my chance to break stuff. It’s only the software, but I like to try to break stuff.
Emi: I’m sorry to interrupt you, and then you can carry on, but I think our viewers need to know that if there’s one person who can manage to break the software, it’s Sam. He’s got that reputation, and I think that’s what makes him the perfect candidate for the job.
Andrea: Just don’t let him test your car.
Sam: I think you have to be a special type of person to be good at testing.
Emi: Totally.
Sam: But not in a good way. You have to be quite twisted.
Emi: I think a lot of people underestimate how important the testing phase is, and how easily things can go unnoticed until it’s too late.
Sam: Yeah, and a really good example of this was variable frame rate writing.
We recently added the ability to write out videos with a variable frame rate, which is really important for our users and had been requested for a long time. Once I started testing it, I found something that had been missed by the developers, by level one testing, and by us in not being able to anticipate it: the rest of the software’s framework wasn’t yet ready to understand variable frame rates.
So we had to start testing all the other aspects of the software and changing simple things like Range Select to make sure it understood that it was now looking at variable frame rates.
Emi: That’s right, I remember. I think that’s a very good point, because when we were going through that stage, the idea that variable frame rate might affect something like frame selection didn’t even occur to me.
And I guess that’s what level two testing is, right? Establishing how that feature can affect a user’s workflow.
Sam: Exactly. I normally break the testing down so that I first look at the feature in isolation, then I look at it as part of a workflow, and then I look at it as if a chimpanzee were using it, doing some really random stuff, to see whether it’s going to break the software in any way.
I think that’s actually a crucial part, because you can easily use something incorrectly, and what we don’t want is for that to crash the software or lock people out of their project. So even though it seems like a random test to do, it’s actually quite an important part.
Andrea: I find this very fascinating, because I’d say we do almost the opposite. I’m not a tester at all – I don’t do any testing, basically. In my day-to-day job doing tech support and training, I’m mostly reacting to problems that users have found, or trying to make things work during training. You do the opposite, right? You try to break things.
And I think that requires quite a bit of creativity. You need to get very creative and find new ways to break stuff. That brings me to a question for you: doing that kind of work, you also deal quite a lot with the user interface. So there’s a bit of UX design in the work you do as well, right? Which is something I don’t do at all.
Sam: I’d say most of the GUI updates our users may have seen recently are down to our colleague Simone, who’s brilliant at looking at the software in a different way and updating it.
So he definitely deserves the credit there, not me. The way I’ve influenced changes is more about making sure the data is represented accurately. For example, things like the file information can vary as we adjust the chain of filters, so it’s about continuously making sure that’s always accurate for our users, and keeping that forensic soundness.
Emi: Andrea, I wanted to ask you something, because you’re on the support side. When a user first requests a feature through support, we start the process we’ve just been talking about. Is it down to you and your team to make sure the user is kept updated on progress?
And how do you monitor that stage? We have so many users, so it must be difficult to keep track of all the requests.
Andrea: Where do I start? We do track everything, yes. Our users normally have an account on our tech support portal, so we know who they are.
When they reach out, we create a support ticket for that specific request, whatever it may be, and we categorise it. We have several categories: bugs, feature requests, general questions, and issues not strictly related to the product – for example, with the support portal itself.
Then the support colleague evaluates the issue and does some testing if necessary, trying to replicate it. That’s the main part: replicating what the user is actually experiencing, which might be very easy or might take days. Then we pass that information to other departments – mostly the developers – after we’ve discussed it at the hybrids meeting you mentioned.
Emi: Sure.
Andrea: When there are updates, our devs update us, and then we get back to the user. The update might just be a heads-up on the status of the support request, or it might be the final update: “We’ve decided to implement this feature. It’s been implemented in the beta and will likely come out in one of the next official releases.” Or it could be, “We’ve decided not to implement this feature.”
Sam: That’s great. Sorry, I was just going to–
Emi: No, sorry – it’s just that Andrea mentioned the beta, and I think this would be a good opportunity to explain to our users exactly what an alpha stage or a beta stage is.
At Amped Software we also have a release candidate stage, right, where we’re hopefully almost ready to release, although sometimes, of course, we notice problems. Sam, maybe you’d be a good person to explain how this works.
Sam: Sure. In software development, we have different branches of the software throughout the development stage.
Once we’ve gathered the ideas of what we want to put into the next release, the developers start developing them in the alpha branch. For FIVE, say, we might typically have 60 new tickets going into it, which will be a mix of features and, unfortunately, bugs, like any software company.
Emi: They’re inevitable, right?
Sam: Yes. But we keep on top of them – that’s the important thing. Those get fixed in the alpha branch. The reason we do it in a separate branch is that we don’t want to contaminate other parts of the software development with things that are experimental or still in development.
Emi: Right. So am I right to assume that we don’t share alpha builds with our customers?
Sam: Exactly. Then, once we’ve finalised what’s eventually going to be released in the next update, those changes get transferred to the beta branch. Here we’re going into the testing stage again.
This is where it gets passed to our level one testers, and then eventually to the level two testers. Once that testing stage is done and we’re happy it’s good to go, we create the release candidate, which is the final stage before we release the product update to our users.
Emi: And do I understand correctly that when we have a release candidate, developers can still continue working on the alpha and beta builds in parallel, for future versions of FIVE? The branches can be kept separate?
Sam: Exactly. Because we release quite a lot of updates per year, we’ll have some developers working on features that might not be coming out for the next 12 months.
Andrea: Sure.
Sam: So they continue developing in a separate branch, while the most recent updates go into the upcoming release.
Emi: Understood. I also wanted to ask you – since you’re probably the first, or one of the first, people to do proper level two testing of a feature – do you ever find yourself thinking a feature is going to be relatively easy to test, because it’s not a big feature, and you’ll be able to do it in a day or a couple of days? And then at some stage in that period you think, “Maybe I underestimated this, and there are more problems than I thought”? How do you tackle that?
Sam: Almost every time there’s a new feature, I probably underestimate the effort it will take to test it, because it’s hard to understand initially how it’s going to interact with the rest of the software. It’s only once you get your hands on the product that you can start connecting the dots: “This could potentially affect this, this, and this.”
Emi: Yeah.
Sam: I think the main thing is to keep a solid structure to the testing, so you minimise the chances of missing something during that stage.
Emi: And during this process, is there ever a situation where you might be perceived to over-worry about something?
For example, you might be checking forensic soundness, and a developer might think, “That’s not that much of a problem.” How do you deal with different expectations between the testing team and the development team?
Sam: I think there’s always going to be a bit of a language barrier between a forensic point of view and a development point of view.
Emi: Oh, okay – so not language as in people from different countries, but more like perspective. Right.
Sam: Yeah. I normally get to a point where, if I’ve not found an issue for a good couple of days, that’s when I start backing off. But I will more than likely over-test everything, and I know I do, for good and for bad.
I think it’s something that’s required, because I know that as a user, I would hate to use a product that could then compromise me in court, for example. It’s not like software such as Photoshop, where you can get away with releasing a bug. A bug for us could have real consequences for our users.
Emi: I agree. We mentioned this before: that added duty to make sure our features are forensically valid. You need a person who perseveres, doesn’t get frustrated, and is extremely patient with the testing phase.
So I’m glad we found one! But what I’d also say is that when I was a bit more involved in testing, I found that Amped FIVE gives you a lot of tools to actually check things.
Sam: Yeah.
Emi: For example, I remember when we were testing the new, or potential new, use of the GPU – the graphics processing unit – to write out our videos. I used the Video Mixer, which is a very versatile Link filter, to compare pixel similarity between original videos and written-out videos.
It was only by doing that during that stage that I realised – and it then became a collective effort – that one specific setting was causing a huge difference between the original and the written-out video. If I hadn’t used that tool in FIVE, I would never have been able to find that.
Sam: Yeah, and I think that’s part of why FIVE is so powerful. Something a lot of users forget – especially those who used it a long time ago and haven’t touched it for a while – is that it’s not just an enhancement piece of software.
Emi: Good point.
Sam: It’s got the analytical tools that users need to analyse video, and those same tools are what I use to test, to make sure everything’s working as it should.
Emi: So FIVE becomes your testing tool?
Sam: Exactly.
Emi: That’s so interesting. I find that incredible.
Sam: Since we’ve been talking about bugs: training isn’t only one of the areas where a lot of feature requests come from. When bugs do slip through, they also often surface in training.
So I’d love to talk a bit about what we do when, unfortunately, a bug does come out, and it’s normally picked up, I’d say, in training.
Andrea: I’d say either in support or training. I’ve pretty much already explained the procedure for support: a user reaches out and describes the bug, and we try to replicate it.
When a bug comes up in training, that’s a different context and a different situation. I’ve been training for a few years now, and at the very beginning of my journey as a trainer, I was a bit embarrassed when a bug came up in training.
Now, I wouldn’t say I’m happy about it, obviously, but it’s a natural part of teaching, I’d say. And it’s also a very useful moment for us, because we’ve got ten people using the software in ways that might be slightly different from the way I’m used to.
So they’re more likely to find bugs than we are, right? Whenever bugs come up during training, I make sure I share them with the whole class, so everyone is aware that we’ve found a bug. We take good notes and jot down what the bug was, and then once again we reach out internally, discuss it, try to fix it as soon as possible, and notify the user who found it. So it’s also an interesting moment for discussion.
Sam: I think a good point to address here is that when we find a bug, externally or internally, after a product has been released, we very quickly assess its severity, and we have different categories for that. The one our users are probably most interested in is whether forensic soundness is compromised.
In that situation, we do something called a maintenance release. Some bugs that aren’t going to harm our users we may hold over until the next product release. But for anything severe that could cause harm, we notify our users immediately.
We fix it immediately and send out a maintenance release to get that bug out of the software. I think that’s an important part as well.
Andrea: Definitely. We know that the people we meet – trainees, people at events, people who reach out through support – might not be experts.
They might have just started out with the software, but they do care about the forensic approach.
Sam: Yes.
Andrea: Because that’s what they do on a daily basis. So that’s the main thing for us. We do notify them, and a maintenance release is a way for us to reach out to users and let them know right away that they should update.
Emi: I wanted to… Oh, go on, Sam, did you want to say something?
Sam: I was going to move on to closing remarks, so if you want to–
Emi: Oh, okay. Well, before we do that, I wanted to discuss a very hot topic: AI. Maybe we can give our users a view on our stance on AI, both for feature requests and for things like using AI to help with coding and development.
It’s interesting because at the moment we’re here in Trieste for our annual meeting, and we were discussing this very topic internally today. So we wanted to give our users a bit of an overview of our stance. We’ve already released Assisted Redaction in Replay, which uses a machine learning model.
We stress that, in this instance, it’s a very valuable tool that can save a lot of time. But we always tell our users that they are ultimately responsible for checking the output of this filter, and that they have the tools to make manual corrections very easily.
But what about other feature requests that might involve AI? What’s your position on it? I’m asking both of you.
Sam: Sure. I’ll start with the company’s position, which I think is a good standpoint. For FIVE, we have no AI in FIVE, and we never will – I say never…
Emi: Never say never, Sam! The CEO may change his mind.
Sam: But we don’t do it in FIVE.
Emi: And for a good reason, right?
Sam: Yeah. So if any feature requests come in asking for AI in FIVE, at the moment we’re going to say no.
Emi: Sure. And what about other things that might help, for example, with the investigation and triage side of video? Say, AI tools that might help find particular elements or types of people in long video clips?
Andrea: Of course, we know the official position of the company, but we’re not against AI. We have applied some AI tools in other products, like Authenticate.
In those scenarios, we decided they would be useful tools to help investigators make up their own minds. I think that’s the whole point. We don’t want to provide answers; we want to provide analysis tools – I’m talking about Authenticate here, at least.
Then users need to make up their own minds, using all the information provided by the tools, including AI-based tools, and decide whether that information leads them in one direction or another. We’re open to anything, I’d say. Just today we discussed possible applications of AI in our products extensively.
But given the particular industry we work in, we should be very cautious, and that’s what we do. We are being very cautious.
Sam: For me, you have to fight fire with fire. You’re going to come across a lot of AI in investigations, and the only real way to tackle that, especially as it becomes more sophisticated, is to adopt AI to fight it as well.
It’s always going to be a cat-and-mouse game.
Emi: But I think Andrea made a very interesting point, and I totally agree: we may offer some AI tools to assist with certain aspects of a video forensic workflow – for example, authentication and the detection of deepfakes. But we’ll always say to our users, “Yes, you have this tool and it can be helpful, but there are also many other tools that use more traditional methods of authentication, like shadow analysis or geometric analysis. Go and use them all.”
The more you use, the more robust your evidence is going to be. So if, for whatever reason, the AI filter makes an error – and we’re honest that it can happen – you still have other methodologies that contribute to the robustness of the evidence.
Andrea: Definitely. An analogy I sometimes use when I train people in Authenticate is the blood test analogy – I don’t know if I’ve shared it with you already. When you go to a clinic and get your blood work done, the results won’t say, “You’re in great shape.” They’ll just provide a list of objective findings.
Emi: Yeah.
Andrea: With actual units of measurement. Then you have to go to a doctor, a practitioner, to evaluate them. That person will have been trained in the profession and will be able to understand the results, put all those little pieces of information together, and draw a conclusion. That’s what we try to explain to users when they use Authenticate, but it’s a more general approach too.
Sam: I’m going to steal that analogy. That’s great.
Andrea: I’ll let you know how much I want for it! So we want users to be aware of the tools they’re using, regardless of whether they’re AI-based or not. They should take from each tool the results it provides, within its limitations, and then draw their own conclusions.
That’s our stance, I’d say. I don’t know if you agree.
Emi: That’s great. Perfect. Thanks for sharing, guys.
Sam: I wanted to finish by saying that, as a company, we’re extremely grateful to have the user base that we do. You drive the development of the software and help improve it. I hope our users are aware that they have that influence and that relationship with us, that we really appreciate it, and that it makes the company a better place.
Emi: I totally agree. We really wouldn’t be in this position if it weren’t for our users. As I said at the beginning, we’re extremely fortunate to have a direct line of communication with our users. We have a great relationship, and long may it continue.
Andrea: On my side, I’ve always considered myself not really a people person.
I have to say that since I started working at Amped, that’s changed a bit. Being able to interact with users and people who actually use our products, in support and training, has been extremely enriching. I’d say most of what I’ve learned, I learned from users, not from colleagues.
Well, also from colleagues – with the exception of Emi, of course! No, I’m joking. I’ve learned a ton from Emi. But mostly from users. And once again, beginners and experienced users can all teach you something, for sure.
Sam: Perfect. Thank you both for joining me.
Emi: Thanks for having us.
Sam: And thank you to the users for watching. I hope you enjoy the rest of the podcast series. Make sure to subscribe to our YouTube channel and check out the other podcast episodes on Spotify.
Emi: And remember that you can subscribe to future episodes of this series. And of course, don’t forget our blog – you’ll find a lot of valuable information there, especially about software updates.
Andrea: We also have a Discord channel you can join. There’s a very vibrant community of users who help each other with cases, questions, and ideas in general.
Sometimes we chip in, but mostly the community is self-sufficient – I don’t know if that’s the correct expression in English! So it’s a very good place to learn from other people.
Emi: And if you’d like to receive news automatically, just sign up for our newsletter. It’s on our main website, where you can find all the information.
Sam: Great. Thank you, Emi. Thank you, Fris. Until next time, take care.
Emi: Thank you, guys. See you next time.
