Recherche avancée

Sur d’autres sites (5882)

• aacenc_pred : rework the way prediction is done

  29 août 2015, par Rostislav Pehlivanov

  aacenc_pred : rework the way prediction is done
  This commit completely alters the algorithm of prediction.
  
  The original commit which introduced prediction was completely
  
  incorrect to even remotely care about what the actual coefficients
  
  contain or whether any options were enabled. Not my actual fault.
  This commit treats prediction the way the decoder does and expects
  
  to do : like lossy encryption. Everything related to prediction now
  
  happens at the very end but just before quantization and encoding
  
  of coefficients. On the decoder side, prediction happens before
  
  anything has had a chance to even access the coefficients.
  Also the original implementation had problems because it actually
  
  touched the band_type of special bands which already had their
  
  scalefactor indices marked and it’s a wonder the asserion wasn’t
  
  triggered when transmitting those.
  Overall, this now drastically increases audio quality and you should
  
  think about enabling it if you don’t plan on playing anything encoded
  
  on really old low power ultra-embedded devices since they might not
  
  support decoding of prediction or AAC-Main. Though the specifications
  
  were written ages ago and as times change so do the FLOPS.
  Signed-off-by : Rostislav Pehlivanov <atomnuker@gmail.com>
  

  • [DH] libavcodec/aac.h
  • [DH] libavcodec/aaccoder.c
  • [DH] libavcodec/aacenc.c
  • [DH] libavcodec/aacenc.h
  • [DH] libavcodec/aacenc_pred.c
  • [DH] libavcodec/aacenc_pred.h

• ffmpeg replacing audio track with track from another video but different length (sync audio)

  27 août 2019, par Matt

  Background

  I have digitized some old Canon Video8 tapes. I used a SONY Digital8 camera (which is backwards compatible with Video8) to output DV (using it’s inbuilt ADC). The conversion process worked well for the video but the audio came through jumpy/distorted in places. This left me with a problem, was it the Camera or the tape ? So I bought another Samsung Video8 camera (just analog) and using the SONY’s passthrough feature output from the Samsung (Composite & mono audio) into the SONY which output the DV. Much to my delight it worked ! The audio was clear.

  Result

  DV01.avi - Good Video / Crap Audio
  
  DV02.avi - Crap Video / Good Audio

  Ok so obviously what I would like to do is take the video track from DV01 and the audio track from DV02 and join/mux ? them WITHOUT re-encoding.

  Problem 1 : They have different start times so just copying over the audio track will result it not being in sync.

  After some googling I found you can use ffmpeg to take care of this :

  Firstly here is the Video info using : ffmpeg -i DV01.avi

  Input #0, avi, from 'DV01.avi':
  
    Duration: 02:53:06.68, start: 0.000000, bitrate: 28878 kb/s
  
      Stream #0:0: Video: dvvideo, yuv420p, 720x576 [SAR 16:15 DAR 4:3], 25000 kb/s, 25 fps, 25 tbr, 25 tbn, 25 tbc
  
      Stream #0:1: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s
  
      Stream #0:2: Audio: pcm_s16le, 32000 Hz, stereo, s16, 1024 kb/s

  Muxing :

  ffmpeg -itsoffset 4 -i DV01.avi -i DV02.avi -map 0:v -map 1:a -c copy output.avi

  In the example above I am delaying the start of the video 4 seconds (I think ?) This is just an example I haven’t actually tried it as the file sizes are 40Gb !

  So my QUESTION is :

  Given the background above what would be the best way to join/mux the two streams together (without re-encoding) with the audio being in sync. Given that syncing the audio to the video may need millisecond tweaking I don’t believe trial and error is a good idea (I don’t want to tweak it by 10ms then rinse and repeat for a 40Gb file) ?

  I just had a thought, could I say create a 10 second clip (from the start) of each video and use them to find the reference/sync start point then use that when muxing the 40Gb versions ?

  Anyway, you get the idea. Looking for ways to solve this problem. Thanks !

• FFMPEG - local video to UDP streaming to OpenCV - video quality degraded

  6 juin 2021, par user3925023

  my goal is to re-stream local video content / desktop screencasting, to an UDP flow that I need to process on a Python script.

  



  Here is the FFMPEG script that I'm using :

  



  ffmpeg -re -i C:\Users\test\Downloads\out.ts -strict -2 -c:v copy -an -preset slower -tune stillimage -b 11200k -f rawvideo udp://127.0.0.1:5000


  



  And here is the simple Python script supposed to read the stream flow :

  



  import cv2

cap = cv2.VideoCapture('udp://127.0.0.1:5000',cv2.CAP_FFMPEG)
if not cap.isOpened():
    print('VideoCapture not opened')
    exit(-1)
width = cap.get(cv2.CAP_PROP_FRAME_WIDTH)  # float
height = cap.get(cv2.CAP_PROP_FRAME_HEIGHT)  # float
print(str(width))
print(str(height))
while True:
    ret, frame = cap.read()
    imgray = frame[int(round((height/100)*70,0)):int(round((width/100)*42,0)), int(round((height/100)*74,0)):int(round((width/100)*54,0))]
    if not ret:
        print('frame empty')
        break
    cv2.imshow('image', imgray)
    if cv2.waitKey(1)&0XFF == ord('q'):
        break
cap.release()


  



  I'm able to visualize portion of the stream video as expect, but I'm facing lot of issue in video quality degradation, specially video artifact probably due missing packet processing :

  



  

  



  Also these are error log I'm geting from script :

  



  [h264 @ 0000026eb272f280] error while decoding MB 105 66, bytestream -21
[h264 @ 0000026eb2fcb740] error while decoding MB 100 53, bytestream -11
[h264 @ 0000026eb272f280] error while decoding MB 32 22, bytestream -11
[h264 @ 0000026ead9ee300] error while decoding MB 60 20, bytestream -25
[h264 @ 0000026eb27f00c0] error while decoding MB 9 62, bytestream -5
[h264 @ 0000026ead9ee780] error while decoding MB 85 44, bytestream -5
[h264 @ 0000026eb27f0800] error while decoding MB 64 25, bytestream -15
[h264 @ 0000026eb272f280] error while decoding MB 112 23, bytestream -17
[h264 @ 0000026eb2735200] error while decoding MB 30 21, bytestream -7


  



  Actually I don't care about video fluidity,I can also reduce the FPS, important thing is the video quality. Not sure if I'm doing wrong on the scripting python part or if I'm using wrong FFMPEG command.

  



  Many Thanks