[FFmpeg-devel] [PATCH] common ID3v2 support for all formats

Kostya kostya.shishkov
Sat Oct 2 10:31:12 CEST 2010


On Fri, Oct 01, 2010 at 11:27:36PM +0200, Michael Niedermayer wrote:
> On Fri, Oct 01, 2010 at 08:21:07PM +0200, Reimar D?ffinger wrote:
> > Hello,
> > considering issue 2258 I think it is a valid conclusion that people
> > will prepend a ID3v2 header to anything that can't run aways fast enough
> > (and then give it a .mp3 extension...).
> > So I propose attached patch that moves that parsing to common code.
> > Note that is assume that due to buffering the ID3 parsing attempt
> > will not cause any issues even on non-seekable input.
> > Note that I have no idea WTF the mpc demuxer code is doing there,
> > my conclusion was that it should be safe to just throw it all away,
> > but I'm not 100% sure I don't miss some subtlety.
> > Mostly unrelated, but one issue with this whole ID3 handling is
> > that AFAICT it will use the file-specific metadata conversion
> > instead of using always the ID3 one.
> 
> >  aacdec.c  |    5 -----
> >  flacdec.c |   14 --------------
> >  mp3.c     |    4 ----
> >  mpc.c     |   34 ++++------------------------------
> >  tta.c     |    8 --------
> >  utils.c   |   16 ++++++++++++++--
> >  6 files changed, 18 insertions(+), 63 deletions(-)
> > 5cc1b70fabc75686a99488dd8c63693412e67935  id3v2.diff
> 
> iam ok with this if its tested and the mpc maintainer confirms the change is
> ok

IIRC, MPC demuxer was written before proper ID3vX handling for many
formats and since it's common to prepend ID3 data to  actual audio,
demuxer should try to skip it before probing or demuxing. Unfortunately,
MPC samples with ID3 I had were left in Ukraine, so I can't readily test
it. Yet it looks ok and if it doesn't break regular MPC decoding apply
it.
 
> [...]
> -- 
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB



More information about the ffmpeg-devel mailing list