Recherche avancée

Sur d’autres sites (9555)

• Revision 36037 : s’assurer que la class ffmpeg_movie est disponible sinon cela ne sert pas ...

  9 mars 2010, par kent1@… — Log

  s’assurer que la class ffmpeg_movie est disponible sinon cela ne sert pas à grand chose

• avcodec/libjxldec : fix gamma22 and gamma28 recognition

  18 janvier 2023, par Leo Izen

  avcodec/libjxldec : fix gamma22 and gamma28 recognition
  Gamma 2.2 and Gamma 2.8 are tagged in the file as 0.45455 and 0.35714,
  
  respectively (i.e. 1/2.2 and 1/2.8). Trying to identify them as 2.2 and
  
  2.8 instead of these values will cause the transfer function to not
  
  properly be recognized. This patch fixes this.
  

  • [DH] libavcodec/libjxldec.c

• What would cause video whose position is set and played at a certain millisecond, to not align with a video trimmed to that same millisecond position ?

  2 décembre 2020, par Cha Pa

  I have developed a windows C# application that allows you to cut clips of video that is synched to a transcript.

  


  The application has a video tuner that allows you to adjust the start and stops of the clip in .1, 1, 3 seconds and gives you a short 2 second preview of the start or 2 seconds leading up to the stop as a preview. Then you can cut that video into a small clip by pressing a create clip button.

  


  Because of of the nature of the provider of the videos, these videos are typically Mpeg1 that are over an hour long and are all varying in both in width/height dimensions as well as bitrate. Changing the format is not an option.

  


  My question is this. What would cause the video player to play earlier than where the video is cut using an ffmpeg wrapper ?

  


  I have developed a test version in winform with a mediaplayer control, a version in WPF with a mediacontrol player, and another winform with a vlcwrapper. All of them start early as compared to the ffmpeg cut. All of them start at a slightly different time from each other even though they are all provided the same millisecond time stamp. In fact testing directly with setting command line position to ffplay and vlc, they have slightly different start times when using the same position and both are different then the command line cut of ffmpeg.

  


  The infuriating thing is that when I compare the ffmpegwrapper exports they are dead on with another piece of software's playback preview and clip export. Every video I clip that has a different bitrate or resolution is sightly off to a differing number of milliseconds. One video may be .4 seconds off and another is 1.1. I would assume it was a delay due to the loading of the video and I can async await somehow, or assume it was a problem with the timer, except it starts EARLY not late. All 3 demos are some variation of the code below that grabs start time and end times and calls a timer to stop the video after playing the number of milliseconds calculated between the start and end. Even more peculiar, the shorter the timer, the shorter the start time appears to be off.

  


  Any thoughts on if it is an mpeg1 mpeg2 issue or a bitrate issue I can control to be consistent between videos without re-encoding every video ? Maybe even outside the box ways to put clips to memory stream or play the temp file quickly ?

  


  private void PreviewStartButton_Click(object sender, EventArgs e)
       {
           startPosition = Convert.ToSingle(startBox.Text);
           stopPosition = startPosition + 2; //gives you your 2 second preview of the star
           mediaPlayer.Ctlcontrols.currentPosition = origStartTime;
           mediaPlayer.Ctlcontrols.play();
           StopWmpPlayerTimer();
           StartWmpPlayerTimer();
       }