Recherche avancée

Sur d’autres sites (6980)

• Round number of bits read to next byte

  4 décembre 2014, par watwat2014

  I have a header that can be any number of bits, and there is a variable called ByteAlign that’s calculated by subtracting the current file position from the file position at the beginning of the file, the point of this variable is to pad the header to the next complete byte. so if the header is taking up 57 bits, the ByteAlign variable needs to be 7 bits in length to pad the header to 64 bits total, or 8 bytes.

  Solutions that don’t work :

  Variable % 8 - 8, the result is the answer, but negative.

  8 % Variable ; this is completely inaccurate, and gives answers like 29, which is blatantly wrong, the largest number it should be is 7.

  how exactly do I do this ?

• How can I use ffmpeg's swscale to convert from NV12 to RGB32 ?

  22 avril 2013, par Asik

  Say I have an NV12 frame in memory as an array of bytes. I know :

  • its Width and Height
  • its Stride (total width of a line including padding), which is the same for Y and UV components as per NV12 specification
  • I know where Y begins, U begins at Y + (Stride * Height), and V begins at U + 1 (interleaved with U).

  Now this is what I have so far :

  SwsContext* context = sws_getContext(frameWidth, frameHeight, AV_PIX_FMT_NV12, frameWidth, frameHeight, AV_PIX_FMT_RGB32, 0, nullptr, nullptr, nullptr);
  
  sws_scale(context, 

  So I don't know what the parameters to sws_scale should be :

  • srcSlice : a pointer to the array of bytes ? It should apparently be a
    pointer to a pointer, but what I have is just a single-dimensional
    array of bytes.
  • srcStride : apparently expects an array of strides, but I have just one stride for the entire file. Should I pass an array with just
    one element ?
  • srcSliceY : an offset to the first byte I guess ? Should be 0 then.
  • srcSliceH : the frame height I guess
  • dst : once again, pointer to a pointer, but my destination output is actually just another array of bytes...
  • dstStride : Width * 4 I guess ?

  Any help appreciated.

• h.264 video in mp4 container jumps when played in VLC

  30 avril 2013, par Jayanth Nayak

  I have H.264 video and AAC audio generated in Andriod phone recieved wirelessly using SIP protocol and muxed using FFMPEG APIs, The generated mp4 when played through VLC or other player is never in Sync.
  when I see the time bar of Video, it skips after a certain duration.

  For example :
  in a video of 20s, the time bar seeks upto 14s properly, then it jumps to 18s and finishes at 20. The audio plays properly.

  I have following questions :

  1. Is PTS DTS calculations really required for muxing WITHOUT Encoding ? :

  we used

  PTS = (90000 * (1/FPS) * FrameNumber) - although this did not work :(

  currently FFMPEG is taking care of it internally.

  ---

  1. Why the video jumps ? is it because of less number of frames or wrong PTS values or something else ?

  ---

  1. For the following cases although There is jump, I am getting a good AV sync
     -15,20,25 FPS qCIF & AAC Audio

     But for 15 & 20 FPS of qVGA & VGA the audio lags by 0.5 seconds and for 25 FPS, the Video is just playing fast.
     thus why is there a delay for qVGA and VGA but not present for qCIF ? any dependency of Resolution on Time Stamp (PTS) calculation ??

     Analysis of 25 FPS Video showed that there are enough number of frames for 10s but the total time for the video shown by VLC is 14s. Why is this so ? and again, this video also jumps from 9s to 13s.