Recherche avancée

Sur d’autres sites (4458)

• avcodec/omx : Zero packet padding

  29 avril 2021, par Andreas Rheinhardt

  avcodec/omx : Zero packet padding
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/omx.c

• fixing (with ffmpeg) the chrominance position on a video after capturing

  23 mai 2016, par APLU

  I’m trying to convert some video from VHS to digital using an (old) video capture card (and obviously an old VHS player). Due to the input from my video capture card and the output available from the VHS, I have no other choice than capture with an S-Video cable to a computer.

  Almost everything works except a little mis-synchronization between chroma and luma which do not happen on TV.

  For example, in the original video, I have something like that :
  

  After capturing the video looks like this :
  

  As you may see, there is a little desynchronization of the chroma with the luma channel (I will say about 10 lines errors).

  I’m capturing with ffmpeg on a Linux system with the following commands :

  $ v4lctl setnorm PAL-BG

  $ v4lctl setinput S-video

  $ ffmpeg -y -f alsa -ac 2 -i pulse -f video4linux2 -i /dev/video0 -c:a pcm_s16le -vcodec rawvideo -t $duration -r 25 -loglevel error -stats /tmp/tmp.mkv

  I tried other input norm in v4l, tried an other VHS player, tried an other conversion cable from SCART to S-Video but it didn’t change anything,

  My question is simple : is there a way to fix this with a post-processing video filter in ffmpeg ?

  I already looked at the long list of video filter available in ffmpeg but I didn’t find anything.

  Also, please note I can’t apply filter during the capture commands (old capture cards, old cpu, ..), this is why I capture in rawvideo and native audio. When the capture is done I convert the video/audio into h264/vorbis, at this step I can apply as much as audio/video filtering needed (even if it include extracting chroma & luma to new files, fixing and merging again).

  Thanks !

• Slow audio-video sync drift when merging wav and mp4 with ffmpeg

  30 mai 2016, par charlie80

  I have an mp4 file with only a single video stream (no audio) and a wav audio file that I would like to add to the video using ffmpeg. The audio and the video have been recorded simultaneously during a conference, the former from a mixer output on a PC and the latter from a digital videocamera.

  I am using this ffmpeg command :

  ffmpeg -i incontro3.mp4 -itsoffset 18.39 -i audio_mix.wav -c:v copy -c:a aac final-video.mp4

  where I’m using the -itsoffset 18.39 option since I know that 18.39s is the video-audio delay.

  The problem I’m experiencing is that in the output file, while the audio is perfectly in sync with the video at the beginning, it slowly drifts out of sync during the movie.

  The output if ffprobe on the video file is :

  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'incontro3.mp4':
  
    Metadata:
  
      major_brand     : isom
  
      minor_version   : 512
  
      compatible_brands: isomiso2avc1mp41
  
      encoder         : Lavf57.25.100
  
    Duration: 00:47:22.56, start: 0.000000, bitrate: 888 kb/s
  
      Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 886 kb/s, 25 fps, 25 tbr, 12800 tbn (default)
  
      Metadata:
  
        handler_name    : VideoHandler

  and the ffprobe output for the audio file is :

  Input #0, wav, from 'audio_mix.wav':
  
    Metadata:
  
      track           : 5
  
      encoder         : Lavf57.25.100
  
    Duration: 00:46:32.20, bitrate: 1411 kb/s
  
      Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 44100 Hz, 2 channels, s16, 1411 kb/s

  I’m using the latest ffmpeg Zeranoe windows build git-9591ca7 (2016-05-25).

  Thanks in anticipation for any help/ideas !

  ---

  UPDATE 1 : It looks like the problem is upstream the video-audio merging, and could be in the concatenation and conversion of the MTS files generated by the video camera into the mp4 video. I will follow up as I make any progress in understanding...

  ---

  UPDATE 2 : The problem is not in the initial merging of the MTS files generated by the camera. Or, at least, it occurs identically if I merge them with cat or with ffmpeg -f concat

  ---

  UPDATE 3 : Following @Mulvya’s suggestion, I observed that the drift rate is constant (at least as far as I can tell judging by eye). I also tried to superimpose the A/V tracks with another software, and the drift is exactly the same, thereby ruling out ffmpeg as culprit. My (bad) feeling is that the issue could be related to the internal clocks of the digital video camera and the laptop used for audio recording running at slightly different rates (see here the report of an identical issue I just found).