Recherche avancée

Sur d’autres sites (872)

• Extended client ownership of MediaCodec encoder output buffers for RTMP streaming

  13 février 2014, par dbro

  Background :

  I've connected Android's MediaCodec to FFmpeg for muxing a variety of formats not supported by MediaMuxer, including rtmp:// output via a .flv container. Such streaming muxers require longer, unpredictable ownership of MediaCodec's output buffers, as they may perform networking I/O on any packet processing step. For my video stream, I'm using MediaCodec configured for Surface input. To decouple muxing from encoding, I queue MediaCodec's ByteBuffer output buffers to my muxer via a Handler.

  All works splendidly if I mux the .flv output to file, rather than rtmp endpoint.

  Problem :

  When muxing to rtmp://... endpoint I notice my streaming application begins to block on calls to eglSwapBuffers(mEGLDisplay, mEncodingEGLSurface) at dequeueOutputBuffer() once I'm retaining even a few MediaCodec output buffers in my muxing queue as MediaCodec seems to be locked to only 4 output buffers.

  Any tricks to avoid copying all encoder output returned by MediaCodec#dequeueOutputBuffers and immediately calling releaseOutputBuffer(...) ?

  The full source of my project is available on Github. Specifically, see :

  • AndroidEncoder.java : Abstract Encoder class with shared behavior between Audio and Video encoders : mainly drainEncoder(). Writes data to a Muxer instance.
  • FFmpegMuxer.java : Implements Muxer
  • CameraEncoder.java. Sends camera frames to an AndroidEncoder subclass configured for Video encoding.

  Systrace

  

  Here's some systrace output streaming 720p @ 2Mbps video to Zencoder.

  Solved

  Copying then releasing the MediaCodec encoder output ByteBuffers as soon as they're available solves the issue without significantly affecting performance. I recycle the ByteBuffer copies in an ArrayDeque<bytebuffer></bytebuffer> for each muxer track, which limits the number of allocations.

• How can I split an RTSP stream so that I can both save it to files and apply a motion detection client ? (e.g. ffmpeg, motion)

  1er septembre 2022, par Pat Niemeyer

  I’ve been using "motion" successfully to read an rtsp stream and save motion triggered events.

  


  motion -c motion.conf # config file has the rtsp url and other params


  


  However I’d like to both save the full stream and analyze for motion in this way. I know that I can capture the stream to files with ffmpeg something like this :

  


  ffmpeg -i rtsp://mystream -vcodec copy -acodec copy -map 0 -f segment -segment_time 300 -segment_format mp4 "ffmpeg_capture-%03d.mp4"


  


  Is there is a way to split / duplicate the rtsp stream (perhaps using ffmpeg again) so that I can have both motion and ffmpeg processes looking at it simultaneously ? Alternately is there some option on motion that I’m missing that would automatically save both the raw video and the motion segments ?

  


• How to "filter" a file through command line before apache sends it to client ?

  1er septembre 2020, par Timothe Jahan

  I have large collection of video files which are available on our website.
For each video we have multiple quality and language, so in order to save space we store only 1 file, which contains all audio and video tracks.

  


  Our streaming server can handle these multitrack files in order to serve only the useful part to each user, but we also make them available for download through the apache web server.
Currently, when a user request a file (certain quality, certain language), we first create a temporary file with only his needs, and give him for download.
I would like to remove this intermediate step and extract on the fly.
Extraction can be done by ffmpeg, but I need to have apache "pipe" the file through ffmpeg before sending the bytes out. Do you have any way of doing this.

  


  example :

  


  


  Filename_multi.mp4 [SD,HD,fr,en,ru]
User request : Filename_HD_fr.mp4 [HD,fr]
Apache fetch the file Filename_multi.mp4 and pipe it through an ffmpeg command and send the bytes as > they are encoded, not waiting for the end.

  


  


  Note this is on linux, and the ffmpeg part is not a problem.

  


  Thx
Timothé