Recherche avancée

Sur d’autres sites (10833)

• lavc/rawdec : Use AV_PIX_FMT_PAL8 for raw 1 bpp video in AVI

  28 janvier 2016, par Mats Peterson

  lavc/rawdec : Use AV_PIX_FMT_PAL8 for raw 1 bpp video in AVI
   From
  
  https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
  "If biCompression equals BI_RGB and the bitmap uses 8 bpp or less, the
  
  bitmap has a color table immediatelly following the BITMAPINFOHEADER
  
  structure. The color table consists of an array of RGBQUAD values. The
  
  size of the array is given by the biClrUsed member. If biClrUsed is
  
  zero, the array contains the maximum number of colors for the given
  
  bitdepth ; that is, 2^biBitCount colors."
  Nothing about "monochrome" here. Unfortunately, pal8 to monow conversion
  
  seems a bit flaky, but that’s another story.
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavcodec/raw.c
  • [DH] tests/ref/vsynth/vsynth1-bpp1
  • [DH] tests/ref/vsynth/vsynth2-bpp1
  • [DH] tests/ref/vsynth/vsynth3-bpp1
  • [DH] tests/ref/vsynth/vsynth_lena-bpp1

• avformat/riffenc : don't force WAVEFORMATEXTENSIBLE for flt/dbl LPCM

  21 décembre 2023, par Gyan Doshi

  avformat/riffenc : don't force WAVEFORMATEXTENSIBLE for flt/dbl LPCM
  2c2a167ca7 forced WAVEFORMATEXTENSIBLE for all LPCM streams with greater
  
  than 16 bits per sample. However, WAVEFORMATEX allows IEEE Float samples
  
  or any depth where raw depth == coded depth, see Remarks section at
  
  https://learn.microsoft.com/en-us/windows/win32/api/mmreg/ns-mmreg-waveformatex
  
  and samples M1F1-float32-AFsp, M1F1-float64-AFsp at
  
  https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html
  There are hardware devices and likely software players requiring float samples
  
  that fail to qualify files with WAVEFORMATEXTENSIBLE headers.
  

  • [DH] libavformat/riffenc.c
  • [DH] tests/ref/acodec/pcm-f32le
  • [DH] tests/ref/acodec/pcm-f64le
  • [DH] tests/ref/seek/acodec-pcm-f32le
  • [DH] tests/ref/seek/acodec-pcm-f64le

• Need help on handling MPEG4V1 data

  14 septembre 2011, par Gediminas

  I'm in situation where I need to get a chunk of MPEG4V1 (Microsoft MPEG-4 VKI
  Codec V1) data located in the beginning of a packet (that was sent by some DVR unit).

  Packet structure looks something like this :

  • Compressed MPEG4 data.
  • Long integer - Number of events and tripwires.
  • Long integer - Number of events.
  • Event - Event's sequence.
  • Long integer - Number of tripwires.
  • Tripwire - Tripwires sequence.
  • Long integer - Cyclical redundant code (CRC).

  So there is no indication of how to know where does the MPEG4 data ends (Or is there ?),
  and from where should I start reading this additional data like "Number of events and tripwires" and etc...

  I uploaded two packet's so you could see how the actual data looks like :
  recvData1.txt,
  recvData2.txt.

  I've tried to decode those packets using FFmpeg library with avcodec_decode_video function and by removing byte by byte from the end of my recvData buffer in a hope for any results,
  but FFmpeg just allways returned with an error messages like this :

  "[msmpeg4v1 @ 038865a0] invalid startcode",
  "[msmpeg4v1 @ 038865a0] header damaged".

  I'm not that good specialist on knowing of how does the MPEG4 works from the inside,
  but judging by the error messages it's clearly seen that I'm missing some data for decoding at the start of the buffer.

  So I'm not sure of what part / kind of MPEG data I'm getting here..
  Maybe it's some kind of MPEG's "frame" data with it's "end" indication or something ?

  I've even compared the start of my recvData buffer to some of MPEG4V1 encoded video files I found on the net "http://www.trekmania.net/clips/video_clips4.htm" to check if the start of my buffer really contains the MPEG data ..and not some kind of DVR vendor specific stuff..

  And I noticed that there are about 20bytes of data
  (at the start of my packet data, and in .avi files right after about 180bytes..)
  that looks like some kind of header or something..

  Please check this image : "http://ggodis.gamedev.lt/stackOverflow/recvData.jpg"

  Maybe someone knows what this part of MPEG4V1 data represents ?

  P.S. ..I've checked the CRC values for my received packets and they were correct..