Recherche avancée

Sur d’autres sites (5551)

• How to extract time-accurate video segments with ffmpeg ?

  25 mai 2016, par Jim Miller

  This is not a particularly new question area around here, but I’ve tried what’s been suggested there without much luck. So, my story :

  I’ve got a hunk of 15 seconds of straight-from-the-camera.mov video out of which I want to extract a specific chunk, which I can identify by start time and stop time, in seconds. I started by trying to do what I’ll call a "copy extraction" : to get seconds 9 to 12,

  ffmpeg -i test.mov -vcodec copy -acodec copy -ss 9 -to 12 test-copy.mov

  This was a not-bad start, but there are some black frames at the beginning and end of the clip, which I can’t have — it has to be a clean edit from the original. So, I tried recoding the original into a new, trimmed clip :

  ffmpeg -i test.mov -ss 00:00:09 -t 00:00:03 test-out.mov

  This is better, but not quite : There are no longer any black frames at the beginning of the clip, but they’re still there at the end.

  After some more browsing and reading, I then suspected that the problem is that ffmpeg is having trouble finding the proper points because of a lack of keyframes in the original video. So I recoded the original video to (presumably) add keyframes, in a couple of different ways. Since I want to be able to pick video at boundaries of a second ("from 9 seconds to 12 seconds"), I tried, copying various suggestions around the web,

  ffmpeg -i test.mov -force_key_frames "expr:gte(t, n_forced)" test-forced.mp4

  and

  ffmpeg -i test.mov -g 1 test-g-inserted.mp4

  (I built these as mp4’s based on some comments about an mp4 container being needed to support the keyframe search, but I’m honestly just hacking here.) I then tried the extraction as before, but on these new videos that presumably now have keyframes in them. No luck — both seem to be about the same ; the start is OK but there are still black frames at the end. (FWIW, both test-forced.mp4 and test-g-inserted.mp4 also have trailing black frames.)

  So : I’m still stuck, and would like to not be. Any insights out there as to what I’m doing wrong ? I feel like I’m close, but I really need to get rid of those trailing black frames....

• Insert still frames into H.264 video stream

  7 juillet 2021, par Bassinator

  I'm building an application that receives video packets which are encoded as H.264 from Microsoft Teams - I get one packet for each frame of video. Specifications of the packet contents are given here. For every packet I receive, I write the byte contents of the data[] buffer to a file. This resulting file is a playable H.264 encoded video.

  


  I'm trying to handle the scenario of syncing the audio and video streams from a Teams meeting, and inserting a still frame PNG as a "filler" when nobody has their camera on.

  


  I used the following FFMPEG command to generate n number of seconds of H.264 video from the filler frame :

  


  ffmpeg -loop 1 -i video_filler_frame.png -framerate 30 -c:v libx264 -t 2 -vf scale=1920:1080 C:\Code\temp\out.mp4


  


  This generates an MP4 file (H.264 encoded) - as a test in my code, I tried to read the contents of that generated file as a byte array and append them to the video file.

  


  However, this doesn't appear to work. I'm guessing this is because there is some kind of header or other metadata that prevents us from doing the simple solution of just appending the bytes of the next frame.

  


  My question is, how can I achieve what I am trying to do ? I'd like to splice in n number of frames as I am writing the individual packet contents to the file. In other words, for example, consider the following sequence :

  


  

  • Write packets of video to the file

  


  • My code determines that filler frames are needed at some point in this process

    

    • Insert needed number of filler frames to the file

    


    


  


  • Continue writing packets of video as they come in

  


  


• Anomalie #3750 : Itérateur JSON, erreur de compilation lorsque la source contient &

  8 octobre 2018, par placido .

  J’avais fait le ticket au départ, notamment parce que le message de debug de compilation partait complètement en vrille, ce qui semble trahir un cas de remontée d’erreur pas bien géré.
  Pour le reste on a qu’à dire que cette page fera office de précis de documentation pour les urls de ressources JSON avec ’&’.

  Donc oui, on peut sans doute fermer.