Recherche avancée

Sur d’autres sites (5874)

• avformat/mpeg : Remove secondary packet for reading VobSub

  8 octobre 2019, par Andreas Rheinhardt

  avformat/mpeg : Remove secondary packet for reading VobSub
  When vobsub_read_packet() reads a packet, it uses a dedicated AVPacket
  
  to get the subtitle timing and position from an FFDemuxSubtitlesQueue
  
  (which has been filled with this data during reading the idx file in
  
  vobsub_read_header) ; afterwards the actual subtitle data is read into
  
  the packet destined for output and the timing and position are copied
  
  to this packet. Afterwards, the local packet is unreferenced.
  This can be simplified : Simply use the output packet to get the timing
  
  and position from the FFDemuxSubtitlesQueue. The packet's size will be
  
  zero afterwards, so that it can be directly used to read the actual
  
  subtitle data. This makes copying the packet fields as well as
  
  unreferencing the local packet unecessary and also removes an instance
  
  of usage of sizeof(AVPacket) in libavformat.
  The only difference is that the returned packet will already be flagged
  
  as a keyframe. This currently only happens in compute_pkt_fields().
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/mpeg.c

• avformat/oggparseogm : Check available data before reading global header

  11 avril 2017, par Michael Niedermayer

  avformat/oggparseogm : Check available data before reading global header
  Fixes use of uninitialized data
  Found-by : Thomas Guilbert <tguilbert@google.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/oggparseogm.c

• Proper reading of MP3 file disrupted by ID3 tags

  3 septembre 2016, par PookyFan

  My semestral project is due this Thursday and I have major problem with reading MP3 file (the project is about sound analysis, don’t ask my what exactly is it about and why I’m doing it so late).

  First, I read first 10 bytes to check for ID3 tags. If they’re present, I’ll just skip to the first MP3 header - or at least that’s the big idea. Here is how I count ID3 tag size :

  if (inbuf[0] == 'I' && inbuf[1] == 'D' && inbuf[2] == '3') //inbuf contains first 10 bytes from file
  
  {
  
      int size = inbuf[3] * 2097152 + inbuf[4] * 16384 + inbuf[5] * 128 + inbuf[6]; //Will change to binary shifts later
  
      //Do something else with it - skip rest of ID3 tags etc
  
  }

  It works ok for files without ID3 tags and for some files with them, but for some other files ffmpeg (which I use for decoding) returns "no header" error, which means it didn’t catch MP3 header correctly. I know that since if I remove ID3 from that .mp3 file (with Winamp for example), no errors occur. The conclusion is that size count algorithm isn’t always valid.

  So the question is : how do I get to know how big exactly is entire ID3 part of the .mp3 file (all possible tags, album picture and whatever) ? I’m looking for it everywhere but I just keep finding this algorithm I posted above. Sometimes also something about some 10 bytes footer I need to take into account, but it seems it frequently gets more than 10 bytes for it to eventually catch proper MP3 frame.