[FFmpeg-devel] [PATCH] Fill unspecified AVCodec long_name fields
Tue Apr 29 09:34:21 CEST 2008
On Tue, Apr 29, 2008 at 12:12:29AM +0200, Stefano Sabatini wrote:
> On date Monday 2008-04-28 12:14:47 +0200, Diego Biurrun encoded:
> > On Mon, Apr 28, 2008 at 09:08:54AM +0200, Stefano Sabatini wrote:
> > > On date Monday 2008-04-28 00:40:32 +0200, Diego Biurrun encoded:
> > > >
> > > > Next bunch applied, could you please update again?
> > >
> > > Yes, new patch attached.
> > Another part applied, comments below.
And there went the next batch...
> > > --- libavcodec/bmp.c (revision 13009)
> > > +++ libavcodec/bmp.c (working copy)
> > > @@ -257,5 +257,6 @@
> > > bmp_decode_end,
> > > - bmp_decode_frame
> > > + bmp_decode_frame,
> > > + .long_name = "BMP image",
> > Hmmmm
> Well I'm somehow unsatisfied with it too, but I can't find nothing
> better, maybe something like:
> Microsoft BMP (BitMaP) image
I somehow dislike adding "image" everywhere, but I cannot say that I
have a good alternative. Thus I will probably go with your suggestions.
> > > --- libavcodec/h264.c (revision 13009)
> > > +++ libavcodec/h264.c (working copy)
> > > @@ -8087,6 +8087,7 @@
> > > .flush= flush_dpb,
> > > + .long_name = "H.264 / AVC / MPEG-4 part 10",
> > I think it is MPEG-4 AVC.
> As Loren also said, I think these names are more or less equivalent,
> AVC is often used without any reference to MPEG-4, but I don't know do
> as you prefer.
I had never heard of just "AVC" without "MPEG-4", I committed with both
> > > --- libavcodec/huffyuv.c (revision 13009)
> > > +++ libavcodec/huffyuv.c (working copy)
> > > @@ -1444,7 +1444,8 @@
> > > - NULL
> > > + NULL,
> > > + .long_name = "Huffyuv",
> > The multimedia wiki calls this HuffYUV :)
> I changed it from "HuffYUV" to "Huffyuv" after Loren suggested to use:
> "FFmpeg's Variant of Huffyuv", also the link to the official web page:
> use consistently Huffyuv instead of HuffYUV, while according to
> wikipedia both version are correct, so I'd suggest to leave it as it
> is or maybe to change it to:
> Huffyuv / HuffYUV
I think I would prefer the latter then.
> > > --- libavcodec/mpeg12.c (revision 13009)
> > > +++ libavcodec/mpeg12.c (working copy)
> > > @@ -2442,6 +2442,7 @@
> > > .flush= ff_mpeg_flush,
> > > + .long_name= "MPEG-1 video",
> > I would say s/video//, same below.
> I think "MPEG-1 video" is better than "MPEG-1 alone", this is why MPEG-1
> is a standard which covers many parts, the same for MPEG-2 video.
> > > --- libavcodec/tiertexseqv.c (revision 13009)
> > > +++ libavcodec/tiertexseqv.c (working copy)
> > > @@ -227,4 +227,5 @@
> > > CODEC_CAP_DR1,
> > > + .long_name = "Tiertex Limited SEQ Video",
> > Hmm, the multimedia wiki lists this as simply "SEQ".
> Hmmm.. sorry for nitpicking but I prefer leave it as is(but downcasing
> the "Video" part), I prefer to give more informations rather than
> less, again no strong opinion.
> > > --- libavcodec/tta.c (revision 13009)
> > > +++ libavcodec/tta.c (working copy)
> > > @@ -443,4 +443,5 @@
> > > tta_decode_frame,
> > > + .long_name = "TTA (The Lossless True Audio)",
> > I think this is just "True Audio".
Well, then change it :)
> > > --- libavcodec/vmnc.c (revision 13009)
> > > +++ libavcodec/vmnc.c (working copy)
> > > @@ -517,6 +517,7 @@
> > > decode_end,
> > > - decode_frame
> > > + decode_frame,
> > > + .long_name = "VMware Screen Codec",
> > The multimedia Wiki calls this VMware Video.
> When in doubt use both forms ;-), for example:
> VMware Screen Codec / VMware Video
> the first one seems more reasonable to me (VMware screeN Codec), and
> is already used by xine (for example check:
> http://xine-lib.alioth.debian.org/patches-1.2/extra_codecs ).
> > > --- libavcodec/vqavideo.c (revision 13009)
> > > +++ libavcodec/vqavideo.c (working copy)
> > > @@ -616,4 +616,5 @@
> > > CODEC_CAP_DR1,
> > > + .long_name = "Westwood Studios VQA Video",
> > The multimedia wiki says: "VQA stands for Vector Quantized Animation and
> > is a FMV format used in a number of computer games by Westwood Studios."
> What about:
> "Westwood Studios VQA (Vector Quantized Animation) video"
OK, but I think we can leave out the "video" here.
> Sorry for the nitpicking, I'm putting in the attached patch my
> preferred choices, I leave the final choice to you/other codec
Please be so kind and send in the next, hopefully final, update, I'll
More information about the ffmpeg-devel