Recherche avancée

Sur d’autres sites (9831)

• Best way to stream FFMPEG conversion to HTML5 video element ?

  4 août 2021, par SamTheFam

  Context

  


  Me and my friend are currently working on a media player desktop application using Electron (which implements website code into a desktop application). For the video element we are using the HTML5 video element, and loading a video from the user's local machine. Most browsers only support MP4, OGG, and WebM (Mozilla Specification), but we would like to support more formats to make it applicable to more users. For this reason, we decided to use the FFMPEG video converter. As FFMPEG takes some time to convert videos, we would like to have a streaming implementation that converts the video while playing the HTML5 video.

  


  The Problem

  


  The problem is that we cannot figure out the best way to stream our video whilst it is converting to another format. The primary issue is that we are unsure how we can implement skipping in the video, where we convert that specfic point if skipped to.

  


  For further clarification of the issue, if a user provided a .mkv file, we would start the FFMPEG conversion to .mp4, and would convert enough for the video to start playing. While the video is being watched, FFMPEG would continue converting before the user has reached that point in the video. If a user wanted to skip through the video, we would need a way to fast-forward the conversion to a specific point in the video, thus allowing the user to watch that section of the video, if it has not already been converted.

  


  Ideally we would like the conversion to be faster than the playback of the video, but if this has a cost in quality, we would prefer to make it optional to the end user.

  


  The first solution that came to our heads was to convert small sections of the video, and produce many small (3-5 second) videos, that would be loaded into the video element respectively. The issue here is that the video element takes quite a lot of time to load new source files and as a result make an awful user experience, with the video going black every x seconds.

  


  Another possible solution we stumbled accross was mentioned here. If we were to implement this, we would start a HTTP server on the user's local machine. The issue we had with this is that it could be a rather bloated solution and could be tedious to maintain. Along with this, it would likely slow down the start time for the application, and the runtime as well.

  


  Thank you in advance, we look forward to your responses.

  


• Bootstrapping an AI UGC system — video generation is expensive, APIs are limiting, and I need help navigating it all [closed]

  24 juin, par Barack _ Ouma

  I’m building a solo AI-powered UGC (User-Generated Content) platform — something that automates the creation of short-form content using AI avatars, voices, visuals, and scripts. But I’ve hit a wall with video generation and API limitations.

  


  So far, I’ve integrated TTS and voice cloning (using ElevenLabs), and I’ve gotten image generation working. But video generation (especially talking avatars) has been a nightmare — both financially and technically.

  


  🛠️ Features I’m trying to build :

  


  AI avatars (face + lip-syncing)
Script generation (LLM-driven)
Image generation
Video composition

  


  I’m trying to build an AI faceless content creation automtion platform alternative to Makeugc.com or Reelfarm.org or postbridge.com — just trying to create a working pipeline for automated content.

  


  ❌ Challenges so far :

  


  Services like D-ID, Synthesia, Magic Hour, and Luma are either paywalled, have no trials, or are very expensive.

  


  D-ID does support avatar creation, but you need to pay upfront to even access those features. There's no easy/free entry point.

  


  Tools like Google Veo 3 are powerful but clearly not accessible for indie builders.
I’ve looked into open-source models like WAN 2.1, CogVideo, etc., but I have no clue how to run them or what infra is needed.

  


  Now I’m torn between buying my own GPU or renting compute power to self-host these models.

  


  💸 Cost is a huge blocker

  


  I’ve been looking through Replicate’s pricing, and while some models (especially image gen) are manageable, video models get expensive fast. Even GPU rental rates stack up quickly, especially if you’re testing often or experimenting with pipelines. Plus, idle time billing doesn’t help.

  


  💭 What I could really use help with :

  


  Has anyone successfully stitched together APIs (voice, avatar, video) into a working UGC pipeline ?

  


  Should I use separate services (e.g. ElevenLabs + Synthesia + WAN) or try to host my own end-to-end system ?

  


  Is it cheaper (long term) to buy a used GPU like a 4090 and run things locally ? Or better to rent compute short-term ?

  


  Any open-source solutions that are beginner-friendly or have minimal setup ?
Any existing frameworks or wrappers for UGC media pipelines that make all this easier ?

  


  I’ve spent weeks researching, testing APIs, and hitting walls — and while I’ve learned a lot, I’d really appreciate any guidance from folks who’ve been here before.
Thanks in advance 🙏

  


  And good luck to everyone else trying to build with AI on a budget — this stuff isn’t as plug-and-play as it looks on launch videos 💀

  


• avformat/rtsp : Send mode=record instead of mode=receive in Transport header

  15 janvier 2024, par Paul Orlyk

  avformat/rtsp : Send mode=record instead of mode=receive in Transport header
  Fixes server compatibility issues with rtspclientsink GStreamer plugin.
  >From specification :
  
  RFC 7826 "Real-Time Streaming Protocol Version 2.0" (https://datatracker.ietf.org/doc/html/rfc7826), section 18.54 :
  
     mode : The mode parameter indicates the methods to be supported for
  
           this session.  The currently defined valid value is "PLAY".  If
  
           not provided, the default is "PLAY".  The "RECORD" value was
  
           defined in RFC 2326 ; in this specification, it is unspecified
  
           but reserved.  RECORD and other values may be specified in the
  
           future.
  
  RFC 2326 "Real Time Streaming Protocol (RTSP)" (https://datatracker.ietf.org/doc/html/rfc2326), section 12.39 :
  
     mode :
  
            The mode parameter indicates the methods to be supported for
  
            this session. Valid values are PLAY and RECORD. If not
  
            provided, the default is PLAY.
  mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp : Add listen mode'.
  For comparison, Wowza was used to push RTSP stream to. Both GStreamer and FFmpeg had no issues.
  
  Here is the capture of Wowza responding to SETUP request :
  
  200 OK
  
  CSeq : 3
  
  Server : Wowza Streaming Engine 4.8.26+4 build20231212155517
  
  Cache-Control : no-cache
  
  Expires : Mon, 15 Jan 2024 19:40:31 GMT
  
  Transport : RTP/AVP/UDP ;unicast ;client_port=11640-11641 ;mode=record ;source=172.17.0.2 ;server_port=6976-6977
  
  Date : Mon, 15 Jan 2024 19:40:31 GMT
  
  Session : 1401457689 ;timeout=60
  Test setup :
  
      Server : ffmpeg -loglevel trace -y -rtsp_flags listen -i rtsp ://0.0.0.0:30800/live.stream t.mp4
  
      FFmpeg client : ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v libx264 -f rtsp rtsp ://127.0.0.1:30800/live.stream
  
      GStreamer client : gst-launch-1.0 videotestsrc is-live=true pattern=smpte ! queue ! videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay font-desc="Sans, 84" halignment=center valignment=center ! queue ! videoconvert ! tee name=t t. ! x264enc bitrate=9000 pass=cbr speed-preset=ultrafast byte-stream=false key-int-max=15 threads=1 ! video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc ! voaacenc ! queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink location=rtsp ://localhost:30800/live.stream
  Test results :
  
  modified FFmpeg client -> stock server : ok
  
  stock FFmpeg client    -> modified server : ok
  
  modified FFmpeg client -> modified server : ok
  
  GStreamer client       -> modified server : ok
  Signed-off-by : Paul Orlyk <paul.orlyk@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtspdec.c