Recherche avancée

Sur d’autres sites (4260)

• How to use FFmpeg compression methods in our own C project ?

  29 février 2016, par Sir DrinksCoffeeALot

  I’m currently working on compressing video data on one port and sending it to another port where the data will be decompressed. I would like to try LZW compression method. I’m using pretty old and outdated FFmpeg build (only .h, .lib, .dll files). Problem is that i don’t have any headers to include to get access to LZW encoder and decoder.

  Idea is to open video file, split it into frames, compress them using one of the methods and send them to some remote location where they will be decompressed and concencated into video file.

• Is there a way to pipe input video into ffmpeg ?

  31 janvier 2019, par Joe Williams

  ffmpeg -f avfoundation -i "1:0" -vf "crop=1920:1080:0:0" -pix_fmt yuv420p -y -r 30 -c:a aac -b:a 128k -f flv rtmp://RTMP_SERVER:RTMP_PORT/STREAM_KEY

  Hello guys, the above command works pretty well. It records the audio/video of the computer. But what I want to do is pipe a repeating video or image(png/jpeg/gif), so that there is no live video feed from the computer, but just the image on the stream with the audio.

  How would you go about doing this ?

  Also, if you know any programming interfaces that can do this same thing, please give suggestions. Because I would rather not use a CLI.

• ffmpeg dash/hls wrong timestamp when using mp4, -ss, and -copyts

  6 décembre 2019, par user2114284

  I have noticed some inconsistencies with the output timestamp when using ffmpeg with the dash/hls muxers with mp4, -ss, and -coptyts and I am wondering if it is a bug or if I am just misunderstanding something about how ffmpeg is supposed to work.

  Here I seek 15 seconds in the input and use the copyts argument to copy the input timestamp :

  However, when checking the output with ffprobe, it shows the timestamps starting at 30 seconds, double what I would expect :

  ffmpeg -ss 15 -i big_buck_bunny_720p_10mb.mkv -to 30 -copyts -acodec aac -vcodec libx264 -f hls -hls_time 2 -hls_init_time 2 -hls_list_size 0 -hls_segment_type fmp4 out.m3u8
  
  
  
  cat init.mp4 out0.m4s | ffprobe -show_frames -pretty -
  
  
  
  [FRAME]
  
  media_type=video
  
  stream_index=0
  
  key_frame=1
  
  pkt_pts=384000
  
  pkt_pts_time=0:00:30.000000
  
  pkt_dts=384000
  
  pkt_dts_time=0:00:30.000000
  
  best_effort_timestamp=384000
  
  best_effort_timestamp_time=0:00:30.000000
  
  ...

  If I switch the hls_segment_type to mpegts, the timestamp shows around 15 seconds which I would expect :

  ffmpeg -ss 15 -i big_buck_bunny_720p_10mb.mkv -to 30 -copyts -acodec aac -vcodec libx264 -f hls -hls_time 2 -hls_init_time 2 -hls_list_size 0 -hls_segment_type mpegts out.m3u8
  
  
  
  ffprobe -i out0.ts -show_frames -pretty
  
  
  
  [FRAME]
  
  media_type=audio
  
  stream_index=1
  
  key_frame=1
  
  pkt_pts=1474080
  
  pkt_pts_time=0:00:16.378667
  
  pkt_dts=1474080
  
  pkt_dts_time=0:00:16.378667
  
  best_effort_timestamp=1474080
  
  best_effort_timestamp_time=0:00:16.378667
  
  ...

  I also see the timestamp being doubled when using -ss, -copyts, and mp4 with the dash muxer. Similarly, the dash muxer seems to output the correct timestamps when switched to webm.

  I have seen the same results with several different input files. Am I misunderstanding something about how ffmpeg works, or is this a bug somewhere in the mp4 segmenting ?