[FFmpeg-devel] [PATCH] lavf: Make id3v1_create_tag a lavf internal function

[Michael Niedermayer]

On Sat, Jul 13, 2013 at 05:32:40PM -0300, James Almer wrote:
> On 13/07/13 5:23 PM, Paul B Mahol wrote:
> > On 7/13/13, James Almer <jamrial at gmail.com> wrote:
> >> On 13/07/13 4:29 PM, Paul B Mahol wrote:
> >>> On 7/13/13, James Almer <jamrial at gmail.com> wrote:
> >>>> There are more containers than just mp3 with support for id3v1,
> >>>> and we currently have muxer for at least one of them
> >>>>
> >>>> Signed-off-by: James Almer <jamrial at gmail.com>
> >>>> ---
> >>>>  libavformat/Makefile   |  3 ++-
> >>>>  libavformat/id3v1.h    |  6 +++++
> >>>>  libavformat/id3v1enc.c | 73
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  libavformat/mp3enc.c   | 52 ++++-------------------------------
> >>>>  4 files changed, 86 insertions(+), 48 deletions(-)
> >>>>  create mode 100644 libavformat/id3v1enc.c
> >>>>
> >>>
> >>> What other muxer(s) are going to use this?
> >>
> >> ADTS is one. I was planning to add an avoption for it after the APE tag one
> >> is
> >> committed, or i can send an updated patch adding both at the same time
> >> instead.
> > 
> > I see no reason to support both matadata tags, pick best one.
> > 
> >>
> >> Then there's apparently tta, musepack and wavpack that also support it.
> > 
> > There is no musepack muxer for good reason.
> > 
> > Wavpack muxer have ape tags and its enough.
> > 
> > I really see no reason to support id3v1 for cases where better option exist.
> > 
> > So I really do not see valid reason why this should be commited.
> 

> I personally thought having the option was a good idea. I wouldn't be surprised if some 
> players can't read Ape tags but can read id3v1 instead.

i wouldnt be surprised either. But iam curious if anyone knows a
specific example of such player ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130714/666669b6/attachment.asc>