Recherche avancée

Sur d’autres sites (8804)

• avformat/movenc, segafilmenc : Remove unnecessary avio_tell()

  16 janvier 2020, par Andreas Rheinhardt

  avformat/movenc, segafilmenc : Remove unnecessary avio_tell()
  When the faststart option for the mov/mp4 muxer is used, the current
  
  position (i.e. the size of the already written data pre-shifting) was
  
  evaluated twice : First in an initialization and then again later,
  
  overwriting the first value without having ever touched it. So remove
  
  the initialization.
  Also, the clone of this code in the Sega FILM muxer behaves the same and
  
  has been treated the same.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/segafilmenc.c

• feed raw yuv frame to ffmpeg with timestamp

  30 août 2014, par hawk_with_wind

  I’ve trying pipe audio and video raw data to ffmpeg and push realtime stream through RTSP protocol on android.
  the command-line is look like this

  "ffmpeg -re -f image2pipe -vcodec mjpeg -i "+vpipepath
  
  + " -f s16le -acodec pcm_s16le -ar 8000 -ac 1 -i - "
  
  + " -vcodec libx264 "
  
  + " -preset slow -pix_fmt yuv420p -crf 30 -s 160x120 -r 6 -tune film "
  
  + " -g 6 -keyint_min 6 -bf 16 -b_strategy 1 "
  
  + " -acodec libopus -ac 1 -ar 48000 -b:a 80k -vbr on -frame_duration 20 "
  
  + " -compression_level 10 -application voip -packet_loss 20 "
  
  + " -f rtsp rtsp://remote-rtsp-server/live.sdp";

  I’m using libx264 for video codec and libopus for audio codec.
  the yuv frames are feed through a named pipe created by mkfifo, the pcm frames are feed through stdin.

  It works, and I can fetch and play the stream by ffplay. But there is serverely audio/video sync issue. Audio is 5 10 seconds later than video.
  I guess the problem is both yuv frame and pcm frame doesn’t have any timestamp on them. FFmpeg add timestamp when it feed with the data. but audio/video capture thread is impossible to run at the same rate.
  Is there a way to add timestamp to each raw data frame ? (something like PST/DST ?)

  the way I used was from this thread :
  Android Camera Capture using FFmpeg

• Color shift when encoding DNxHD QuickTime Video [closed]

  13 mai 2013, par Yani

  I have been tasked with developing the Editorial submission pipeline for an animated feature film project. Our studio is based on Windows 7 and the Editing team is using Avid Media Composer. We have decided to go with the "fast import" approach for bringing media into Avid. My tools take some frames and encode DNxHD QuickTime videos from them, then we write out an ALE document to assist with the batch importing of the delivery content. We call it the "fast import" approach because Avid only has to change the video container from MOV to MXF and it doesn't have to do any real encoding which is usually the time consuming part.

  I have tried comparing DNxHD QuickTime videos encoded using FFmpeg, RVIO and Nuke. The color in each video is different but the only one that matches the video created by importing frames directly into the Avid is the video generated by Nuke. I have heard the color shift may be caused by the way the Apple QuickTime libraries manage color on the Windows platform, is this true ? If so, how is Nuke able to produce the correct output ? Also, is there any way I can produce the correct output using FFmpeg or RVIO ?