Recherche avancée

Sur d’autres sites (4527)

• Set "start" field to 0 in mp3 with ffmpeg

  11 juin 2020, par TomatoCo

  I'm trying to change the bitrate and sample rate of an MP3 to match another to try and stop a small audio glitch from occurring when some game tries to play it. I've got the sample rate and bitrate right where I want them, but I can't get the "start" portion of

  



    Duration: 00:03:33.81, start: 0.025057, bitrate: 196 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 196 kb/s


  



  to go to 0, like the mp3 I'm trying to replace. The target looks like :

  



    Duration: 00:06:47.59, start: 0.000000, bitrate: 196 kb/s
    Stream #0:0: Audio: mp3, 44100 Hz, stereo, fltp, 196 kb/s


  



  I've tried a variety of silenceremove filters and -ss flags to try and trim it, but I can't get rid of that "start" field. Google is failing me. What args am I looking for ?

  


• How to find the offset by which the each video must be delayed to sync them perfectly ?

  19 janvier 2023, par PirateApp

  

  


  Let me explain my use case a bit here

  


  


  • We are 4 of us playing the same game

    


  


  • 3 of us recording mkv using OBS studio at 60 fps, 4th guy recording with some other tool at 30 fps

    


  


  • Each mission starts at a cutscene and ends with a cutscene

    


  


  • I would like to create a video like the image you see above starting at ending at the same points but the intermediate stuff is basically what each player is doing in the game

    


  


  • Currently, I follow a process slightly complicated to achieve this and was wondering if there is an easier way to do this

    


  


  • My current process

    


  


  • Take a screenshot from one of the videos of the cutscene

    


  


  


  Run a search for this screen inside the other videos using the command below

  


  ffmpeg 
  -i "video1.mkv"
  -r 1
  -loop 1
  -i 1.png
  -an -filter_complex "blend=difference:shortest=1,blackframe=90:32"
  -f null -


  


  


  • It gives me a result like this in each video

    


    [Parsed_blackframe_1 @ 0x600000c9c000] frame:263438 pblack:91 pts:4390633 t:4390.633000 type:P last_keyframe:263400

    


  


  


  Use the start time from each of the results to create a split screen video using the command below

  


  ffmpeg 
  -i first.mkv
  -i second.mkv
  -i third.mkv
  -i fourth.mp4
  -filter_complex " 
    nullsrc=size=640x360 [base];
    [0:v] trim=start=35.567,setpts=PTS-STARTPTS, scale=320x180 [upperleft]; 
    [1:v] trim=start=21.567,setpts=PTS-STARTPTS, scale=320x180 [upperright];
    [2:v] trim=start=41.233,setpts=PTS-STARTPTS, scale=320x180 [lowerleft]; 
    [3:v] trim=start=142.933333,setpts=PTS-STARTPTS, scale=320x180 [lowerright];
    [0:a] atrim=start=35.567,asetpts=PTS-STARTPTS [outa]; [base][upperleft] overlay=shortest=1 [tmp1];


  


  


  • As you can see, it is a complex process and depends completely a lot on what image I am capturing. Sometimes, I find out that stuff is still slightly off in the beginning or end because the images dont match a 100%. My guess is that the frame rate is different for each video not to mention 3 of them are mkv inputs and one is an mp4 input

    


  


  • Is there a better way to get the offset by how much each video should be moved to sync them perfectly ?

    


  


  • The only way that I can think of is to take 1 video

    


  


  • Take a starting timestamp and an ending timestamp, say with a total duration of 30s

    


  


  • Take the second video

    


  


  • Start from 0 to 30s and compare the frames in both videos, set a score

    


  


  • start from 0.001 to 30.001 and compare the frames, set a score

    


  


  • start from 0.002 to 30.002 and compare the frames, set a score

    


  


  • Basically increment the second video by 0.001 second each time and find out the part with the highest score

    


  


  • Any better way of doing this ? I need to run this on 100s if not 1000s of videos

    


  


  


• Google’s YouTube Uses FFmpeg

  9 février 2011, par Multimedia Mike — General

  Controversy arose last week when Google accused Microsoft of stealing search engine results for their Bing search engine. It was a pretty novel sting operation and Google did a good job of visually illustrating their side of the story on their official blog.

  This reminds me of the fact that Google’s YouTube video hosting site uses FFmpeg for converting videos. Not that this is in the same league as the search engine shenanigans (it’s perfectly legit to use FFmpeg in this capacity, but to my knowledge, Google/YouTube has never confirmed FFmpeg usage), but I thought I would revisit this item and illustrate it with screenshots. This is not new information— I first empirically tested this fact 4 years ago. However, a lot of people wonder how exactly I can identify FFmpeg on the backend when I claim that I’ve written code that helps power YouTube.

  Short Answer
  How do I know YouTube uses FFmpeg to convert multimedia ? Because :

  1. FFmpeg can decode a number of impossibly obscure multimedia formats using code I wrote
  2. YouTube can transcode many of the same formats
  3. I screwed up when I wrote the code to support some of these weird formats
  4. My mistakes are still present when YouTube transcodes certain fringe formats

  Longer Answer (With Pictures !)
  Let’s take a video format named RoQ, developed by noted game designer Graeme Devine. Originated for use in the FMV-heavy game The 11th Hour, the format eventually found its way into the Quake 3 engine as well as many games derived from the same technology.

  Dr. Tim Ferguson reverse engineered the format (though it would later be open sourced along with the rest of the Q3 engine). I wrote a RoQ playback system for FFmpeg, and I messed up in doing so. I believe my coding error helps demonstrate the case I’m trying to make here.

  Observe what happened when I pushed the jk02.roq sample through YouTube in my original experiment 4 years ago :

  
  
  

  Do you see how the canyon walls bleed into the sky ? That’s not supposed to happen. FFmpeg doesn’t do that anymore but I was able to go back into the source code history to find when it did do that :

  
  
  

  Academic Answer
  FFmpeg fixed this bug in June of 2007 (thanks to Eric Lasota). The problem had to do with premature colorspace conversion in my original decoder.

  Leftovers
  I tried uploading the video again to see if the problem persists in YouTube’s transcoder. First bit of trivia : YouTube detects when you have uploaded the same video twice and rejects the subsequent attempts. So I created a double concatenation of the video and uploaded it. The problem is gone, illustrating that the backend is actually using a newer version of FFmpeg. This surprises me for somewhat esoteric reasons.

  Here’s another interesting bit of trivia for those who don’t do a lot of YouTube uploading— YouTube reports format details when you upload a video :

  
  
  

  So, yep, RoQ format. And you can wager that this will prompt me to go back through the litany of unusual formats that FFmpeg supports to see how YouTube responds.