Beste måten å administrere videoer på skala

I dagens verdensvideoer har det blitt en enkel måte å forklare enhver ide i tillegg til å forstå et hvilket som helst emne. Videoer har vist seg å kreve mer forbrukeroppmerksomhet enn noe annet medium. Folk liker å få tilgang til videoer hvor som helst og når som helst, og det er en utfordring for nye selskaper å ikke bare levere kvalitetsinnhold, men også gi en god seeropplevelse til kundene.

Introduksjon av vårt selskap -

Vi er en plattform av 3 lakh-bekreftede leger, største i landet. Som et firma i rask utvikling eksperimenterer vi mye med produktet og samtidig er vi nøye med å levere kvalitetsprodukt for alle. Nylig har vi gjort det mulig for våre brukere å laste opp videoer av kirurgiske inngrep osv., For å dele sine funn og søke forslag fra sine medleger.

De fleste av brukerne våre, mens du er på farten, har minimumsmottak for raskere internetthastigheter, og dette er en utfordring når de leverer tungt datainnhold som videoer.

Vi fant det ganske nærliggende å bruke HLS-protokollen for videolevering, da den er bredt støttet, utviklet av Apple og brukt av mange store selskaper som Facebook. HLS står for HTTP Live Streaming. Det er en mediastreamingprotokoll for å levere video- og lydinnhold. En mp4-video er delt inn i små segmenter vanligvis på 10 sekunder, og for hvert segment opprettes det også flere videokvalitetssegmenter som kan lastes ned for avspilling basert på tilgjengelig internettbåndbredde.

Så når en spiller spiller en video av HLS-format, kan den be om videosegmentet basert på den tilgjengelige båndbredden og streame videoen uavbrutt og gi brukerne en jevn opplevelse. På det ene øyeblikket kan brukere se en lavoppløsningsvideo, og i neste øyeblikk kan den bytte til høyere definisjon så snart enheten er i området for høyere båndbredde-nettverk.

Nedenfor er oppløsningene vi brukte for vår brukssak bortsett fra den opprinnelige oppløsningen til videoen -

Oppløsninger av video som skal genereres

Utfordringen var å transformere de opplastede videoene i ønsket format, samt generere miniatyrbildet for plassholderen av videoen. Det er mange tjenesteleverandører som tilbyr videotransformasjon og levering av innhold, men hovedproblemet er at de er rimelige inntil et visst punkt, og med veksten av selskapet trenger du en løsning som ikke er en belastning for lommen. AWS MediaConvert og S3 er verktøyene vi velger å transformere og levere videomediene våre. Ved å bruke løsningen omtalt nedenfor, er vi i stand til å redusere kostnadene våre med 90 prosent, noe som er ganske viktig for selskaper i alle målestokk. Følg artikkelen hvis du vil vite hvordan vi nullet løsningen.

Innledende tilnærming

I stedet for å bygge en egen løsning bestemte vi oss for å bruke tredjeparts tjenester som Cloudinary passer til vår brukssak. Det gir på fly videotransformasjonstjenesten som virkelig hjalp med å få transformasjonen vi trengte, og total tid det tok var også veldig mindre.

Utviklingen var raskere da vi ikke trenger å bekymre deg for transformasjonen. Man må laste opp videoen, velge transformasjonen som trengs og Cloudinary vil gjøre resten. Opprinnelig var Cloudinary godt innenfor budsjettet vårt, men etter hvert som funksjonen begynte å få mer trekkraft, begynte flere brukere å laste opp videoer. Denne veksten økte mengden vi brukte på Cloudinary, og det var på tide å søke etter andre alternativer.

Våre eksperimenter

For det første testet vi det berømte åpen kildekodebiblioteket - ffmpeg som er i stand til å gjøre videotransformasjonen som vi trengte. Vi hadde to alternativer for å bruke ffmpeg-bibliotek - bruk Cloud Functions eller bruk en av de allerede kjørte VM-forekomstene på GCP (Google Cloud Platform).

Siden hele prosessen fungerer på en on-demand-modell, ble det sistnevnte valget forkastet. Cloud Functions er basert på datamaskin-på-forespørsel modell som betyr at vi vil få ressursene etter behov uten å påvirke våre andre tjenester. Ettersom det er på forespørsel, trenger vi ikke betale kostnaden for serveren når den er inaktiv.

Cloud-funksjoner er veldig enkle å bruke og gir muligheten til å skrive koden på to mest populære språk - node og python. Vi bestemte oss for å gå med python, da vi er komfortable med paradigmet siden bunken vår er på python. Det er veldig enkelt å installere avhengighetene, du må bare nevne den i filen filen.txt, og du er klar.

Vi fikk skriptet som fungerer for skyfunksjon hvor vi først lastet ned videoen fra skylagring, transformerte den i ønsket format og overfører den tilbake til skylagring for streaming.

Men det var fangst. Vi lot brukerne våre laste opp videoer opp til 100 MB, og det tok mye tid å håndtere video med skyfunksjonen i den størrelsen, og til slutt avsluttes før de fullførte hele prosessen på grunn av tidsgrensen (540 sekunder). Til forsvaret vårt har vi ikke tenkt på det scenariet tidligere.

Etter å ha undersøkt andre alternativer og mye forskning så AWS MediaConvert lovende ut. Det var vanskelig å jobbe med MediaConvert da det gir mange muligheter for å tilpasse transformasjonen din, og man kan lett gå seg vill i den situasjonen (bortskjemt med valg). Men etter å ha sett oss rundt en stund, fikk vi malen som var nødvendig for ønsket transformasjon. (fest malen)

Hele flyten vår så ut som -

Vi laster opp en video til S3-bøtte som igjen utløser en Lambda-funksjon. I lambda finner vi ut parametrene som kreves som input for MediaConvert ved å bruke ingen ringere enn ffmpeg. Etter å ha beregnet alle parametrene sender vi en forespørsel til AWS MediaConvert om å transformere videoen vår. For å bli varslet om fullføringen av transformasjonen, kan man opprette en cloud watch-hendelse om endring av jobb som er sendt inn i MediaConvert fra ‘fremgang’ til ‘fullført’, som igjen vil utløse en lambda-funksjon. Den utløste lambda-funksjonen kan enten foreta et api-anrop eller gjøre en db-oppdatering basert på gjennomførbarheten til prosjektet ditt.

Kort oppsummert :

AWS-løsningen fungerte som sjarm, og den var veldig rask. Dette kan se ut som mye arbeid, men det er verdt å gjøre hvis du trenger å skalere.

Fordeler med å bruke denne løsningen -

  • Vi bruker S3 til å lagre og levere medieinnholdet vårt som også er veldig skalerbart og rimelig.
  • AWS MediaConvert er veldig raskt og gir funksjonaliteten til å opprettholde flere køer for å sende inn jobber for transformasjon. Så du trenger ikke å bekymre deg for plutselig hopp i forespørsler om å håndtere videoer. Prisingen er også veldig økonomisk, ingen månedlige kostnader, og du må bare betale for tjenestene som brukes.
  • AWS Lambda er basert på Computation on Demand som vi allerede har diskutert ovenfor. Bortsett fra at AWS gir deg litt gratis lambda-påkallelse og CPU-tid for Lambda-funksjon per måned, noe som er veldig bra, og selv når det gjelder bruk utover kostnadsfrie priser, legger det ikke noen belastning på lommen.

Problemer under AWS-distribusjonen:

  • Husk alltid at AWS tilbyr tjenester basert på regionene, bortsett fra få som S3 som er tilgjengelig på globalt nivå. Bruk tjenester i samme region, ellers kan det hende at du ikke kan fange hendelser eller utløse lambda-funksjoner.
  • Gi nødvendig tillatelse til IAM-rollen din for tjenestene du bruker.
  • Som nevnt over, videoopplasting til S3-bøtte utløser en lambda-funksjon der vi fyller ut de nødvendige transformasjonsdetaljene som oppløsningen til de resulterende videoene, bithastigheten, etc., og for disse verdien må du finne metadataene til videoen som er lastet opp som høyde , bredde og bitrate. Du må bruke et videobearbeidelsesbibliotek som ffmpeg for å få disse verdien som ikke er forhåndsinnlastet på containeren vår lambda kjører på mens lambda kjører på en eller flere containere som blir opprettet og slettet på forespørsel som forespørsler.
  • I motsetning til Google Cloud Functions hvor du bare kan legge til biblioteknavnet i krav.txt og de vil håndtere resten, for AWS lambda må du opprette en zip-fil av alle bibliotekene og binærene som brukes i lambda-funksjonen. Etter å ha undersøkt fant vi ut at du kan legge til binærfiler av ffmpeg i / tmp-mappen og bruke den i din funksjon. Besøk her for trinn for å inkludere ffmpeg i banen og for å opprette en lambda-distribusjonspakke.
  • Under testing fant vi ut at videoene som ble skutt på iOS-enheter, ble rotert fra portrett til landskap etter transformasjon (StackOverflow-diskusjon og AWS forum). Årsaken til det er videoopptak på iOS-enhet lagret opprinnelig i liggende modus med et flagg i videometadata som forteller spilleren å rotere video mens han spiller. Mens du gjør transformasjonen går rotasjonsidentifikatoren tapt, og på grunn av den videoen spilles den av i liggende modus og ser ut som rotert.
  • For å overvinne dette først identifiserte vi videoene ved å bruke ffmpeg. Disse videoene har ‘rotasjons’ verdi i ‘Display Matrix’ for videometadataene som kan fås ved hjelp av ffmpeg. Roter deretter videoene basert på rotasjonen som er gitt, og nå har du den roterte videoen som enkelt kan transformeres ved hjelp av teknikken ovenfor.

Hvis du synes denne artikkelen er nyttig, kan du trykke på klappknappen så mange ganger du vil. Ta gjerne kontakt hvis du trenger hjelp i noen trinn som er nevnt over.