Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer
On Sat, Aug 30, 2014 at 9:41 PM, Marcus Johnson wrote: > If you don't mind me asking, what is DTS? because when I hear it I think of > the DTS audio codec, but I know it's obviously not that, and googling DTS > in the codec context won't get me anywhere. DTS = decoding time stamp PTS = presentation time stamp See http://stackoverflow.com/questions/6044330/ffmpeg-c-what-are-pts-and-dts-what-does-this-code-block-do-in-ffmpeg-c Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer
If you don't mind me asking, what is DTS? because when I hear it I think of the DTS audio codec, but I know it's obviously not that, and googling DTS in the codec context won't get me anywhere. On Sat, Aug 30, 2014 at 6:33 PM, wm4 wrote: > On Sat, 30 Aug 2014 18:16:27 -0400 > Marcus Johnson wrote: > > > Here's a PGS subtitle sample from Eac3to: > > https://dl.dropboxusercontent.com/u/52358991/English.zip > > > > Thanks! > > The DTS fields in this one are all 0 too. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer
On Sat, 30 Aug 2014 18:16:27 -0400 Marcus Johnson wrote: > Here's a PGS subtitle sample from Eac3to: > https://dl.dropboxusercontent.com/u/52358991/English.zip > Thanks! The DTS fields in this one are all 0 too. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer
Here's a PGS subtitle sample from Eac3to:
https://dl.dropboxusercontent.com/u/52358991/English.zip
On Sat, Aug 30, 2014 at 9:38 AM, wm4 wrote:
> ---
> Reverse engineered by looking at Petri Hintukainen's muxer patch, and
> also the mkvmerge sources. Tested with files extracted by mkvextract
> only (does someone have better samples?). No idea if a parser would be
> required for correct remuxing, but at least for decoding with lavc it
> probably isn't be needed, going by how pgssubdec.c is structured.
>
> At least files produced by mkvextract have the DTS always set to 0.
> I don't know whether 0 means "invalid value", or whether DTS should
> just always be discarded. (Actually setting the 0 DTS breaks seeking.)
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/supdec.c | 92
>
> 3 files changed, 94 insertions(+)
> create mode 100644 libavformat/supdec.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3d124fb..b4965fe 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -405,6 +405,7 @@ OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
> OBJS-$(CONFIG_STR_DEMUXER) += psxstr.o
> OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
> OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
> +OBJS-$(CONFIG_SUP_DEMUXER) += supdec.o
> OBJS-$(CONFIG_SWF_DEMUXER) += swfdec.o swf.o
> OBJS-$(CONFIG_SWF_MUXER) += swfenc.o swf.o
> OBJS-$(CONFIG_TAK_DEMUXER) += takdec.o apetag.o img2.o
> rawdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 8f70c4b..e6c0e5f 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -280,6 +280,7 @@ void av_register_all(void)
> REGISTER_DEMUXER (STR, str);
> REGISTER_DEMUXER (SUBVIEWER1, subviewer1);
> REGISTER_DEMUXER (SUBVIEWER,subviewer);
> +REGISTER_DEMUXER (SUP, sup);
> REGISTER_MUXDEMUX(SWF, swf);
> REGISTER_DEMUXER (TAK, tak);
> REGISTER_MUXER (TEE, tee);
> diff --git a/libavformat/supdec.c b/libavformat/supdec.c
> new file mode 100644
> index 000..1938b06
> --- /dev/null
> +++ b/libavformat/supdec.c
> @@ -0,0 +1,92 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "avformat.h"
> +#include "internal.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#define SUP_PGS_MAGIC 0x5047 /* "PG", big endian */
> +
> +static int sup_read_header(AVFormatContext *s)
> +{
> +AVStream *st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +st->codec->codec_type = AVMEDIA_TYPE_SUBTITLE;
> +st->codec->codec_id = AV_CODEC_ID_HDMV_PGS_SUBTITLE;
> +avpriv_set_pts_info(st, 32, 1, 9);
> +
> +return 0;
> +}
> +
> +static int sup_read_packet(struct AVFormatContext *s, AVPacket *pkt)
> +{
> +char tmp[3];
> +size_t len;
> +int64_t pts, pos;
> +int ret;
> +
> +pos = avio_tell(s->pb);
> +
> +if (avio_rb16(s->pb) != SUP_PGS_MAGIC)
> +return avio_feof(s->pb) ? AVERROR_EOF : AVERROR_INVALIDDATA;
> +
> +pts = avio_rb32(s->pb);
> +avio_rb32(s->pb); /* discard DTS (usually 0, and useless) */
> +
> +// The packet-size is stored as part of the packet.
> +if ((ret = avio_read(s->pb, tmp, 3)) < 0)
> +return ret;
> +
> +len = AV_RB16(tmp + 1);
> +
> +if ((ret = av_new_packet(pkt, len + 3)) < 0)
> +return ret;
> +
> +memcpy(pkt->data, tmp, 3);
> +
> +if ((ret = avio_read(s->pb, pkt->data + 3, len)) < 0) {
> +av_free_packet(pkt);
> +return ret;
> +}
> +
> +pkt->stream_index = 0;
> +pkt->flags |= AV_PKT_FLAG_KEY;
> +pkt->pos = pos;
> +pkt->pts = pts;
> +
> +return 0;
> +}
> +
> +static int sup_probe(AVProbeData *p)
> +{
> +if (p->buf_size < 2 || memcmp(p->buf, "PG", 2))
> +return 0;
> +return AVPROBE_SCORE_EXTENSION;
> +}
> +
> +AVInputFormat ff_sup_demuxer = {
> +.name = "sup",
> +.long_name = NULL_IF_CONFIG_SMALL("raw HDMV Pres
Re: [FFmpeg-devel] [PATCH 1/6] fft: add ff_ prefix to some global arrays.
On Sat, Aug 30, 2014 at 04:43:39PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/fft_init_table.c | 4 ++-- > libavcodec/fft_table.h | 4 ++-- > libavcodec/fft_template.c | 12 ++-- > libavcodec/mips/fft_mips.c | 8 > 4 files changed, 14 insertions(+), 14 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/6] ac3dec_fixed: add missing "static const".
On Sat, Aug 30, 2014 at 04:43:44PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/ac3dec_fixed.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/6] sipr16kdata.h: add forgotten const.
On Sat, Aug 30, 2014 at 04:43:41PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/sipr16kdata.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.
On Sat, Aug 30, 2014 at 04:43:42PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavfilter/vf_blackdetect.c| 2 +- > libavfilter/vf_lenscorrection.c | 2 +- > libavfilter/vf_signalstats.c| 2 +- > libavfilter/vf_tinterlace.c | 2 +- > 4 files changed, 4 insertions(+), 4 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 3 "Rare item" - "Common item with rare defect or maybe just a lie" "Professional" - "'Toy' made in china, not functional except as doorstop" "Experts will know" - "The seller hopes you are not an expert" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing "static const".
On 30.08.2014, at 21:50, Clément Bœsch wrote:
> On Sat, Aug 30, 2014 at 04:36:57PM +0200, Reimar Döffinger wrote:
>> On Fri, Aug 29, 2014 at 09:29:46PM +0200, Clément Bœsch wrote:
>>> On Fri, Aug 29, 2014 at 06:34:52PM +0200, Reimar Döffinger wrote:
Signed-off-by: Reimar Döffinger
---
libavutil/hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/hash.c b/libavutil/hash.c
index 773f29e..979fdd9 100644
--- a/libavutil/hash.c
+++ b/libavutil/hash.c
@@ -63,7 +63,7 @@ typedef struct AVHashContext {
struct {
const char *name;
int size;
-} hashdesc[] = {
+} static const hashdesc[] = {
[MD5] = {"MD5", 16},
[MURMUR3] = {"murmur3", 16},
[RIPEMD128] = {"RIPEMD128", 16},
>>>
>>> shouldn't that be static const struct { } hashdesc[] = { ... }
>>>
>>> as in static const foo[] = { ... };
>>
>> Reason I prefer this one is that if the struct becomes
>> large it because very non-obvious that the array actually is
>> "static const".
>> It also is much harder to check/filter with grep.
>> So for practical reasons I think it is better to place it here,
>> or alternatively to name the struct and split them...
>> But mostly I care about having it in .rodata, everything else
>> I'm willing to adapt to what others prefer.
>
> I'm mostly concerned about consistency. Except the one you added in
> drawtext, this form is never used:
Hm, ok. I'll change it then.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing "static const".
On Sat, Aug 30, 2014 at 12:58:35PM -0700, Timothy Gu wrote: > On Aug 30, 2014 7:37 AM, "Reimar Döffinger" > wrote: > > > But mostly I care about having it in .rodata, everything else > > I'm willing to adapt to what others prefer. > > What are the gains for using .rodata instead of .data? It is read-only. Which means at least 1) It is shared between all processes using the library 2) It cannot be overwritten, accidentally or as part of an exploit Maybe other things I can't think of right now. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Include content of the news article in the website RSS
On 2014-08-28 07:23 -0700, Timothy Gu wrote: > On Thu, Aug 28, 2014 at 7:26 AM, Alexander Strasser wrote: > > Hi! > > > > On 2014-05-23 00:28 +0200, Alexander Strasser wrote: > >> On 2014-05-11 01:37 +0200, Gerion Entrup wrote: > >> > Am Donnerstag 01 Mai 2014, 23:48:29 schrieb Alexander Strasser: > >> > > alternative. What do you and/or others think of it? > >> > > > >> > > Besides validation I couldn't yet properly test what feed > >> > > readers make of it. So please forgive me if it causes obvious > >> > > problems with your reader. > >> > (As said offline already) My reader works with it. > > > > My patch still works I think. I would like to commit it, > > though it won't be flexible enough to add much other stuff > > that needs more elaborate logic. I want to apply it, because > > it is a neat feature to have now. > > Good to hear you are still working on this. > > > Any objections to this? > > LGTM from me, assuming it is tested and works. I slightly prefer your > patch over Gerion's, but both are OK. Thanks. Pushed mine. Alexander > > > > In the not-so-short term I intend to widen security checks > > for the repo on the server to other files than just the Makefile. > > I already started this work, but need to fix one known problem > > before I can put it to work on the server. > > Yes, that would be much better. The awk and sed hack is getting too > cumbersome. Or we could just change the server host. pgp8gLTQw62yO.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing "static const".
On Aug 30, 2014 7:37 AM, "Reimar Döffinger" wrote: > But mostly I care about having it in .rodata, everything else > I'm willing to adapt to what others prefer. What are the gains for using .rodata instead of .data? Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing "static const".
On Sat, Aug 30, 2014 at 04:36:57PM +0200, Reimar Döffinger wrote:
> On Fri, Aug 29, 2014 at 09:29:46PM +0200, Clément Bœsch wrote:
> > On Fri, Aug 29, 2014 at 06:34:52PM +0200, Reimar Döffinger wrote:
> > > Signed-off-by: Reimar Döffinger
> > > ---
> > > libavutil/hash.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavutil/hash.c b/libavutil/hash.c
> > > index 773f29e..979fdd9 100644
> > > --- a/libavutil/hash.c
> > > +++ b/libavutil/hash.c
> > > @@ -63,7 +63,7 @@ typedef struct AVHashContext {
> > > struct {
> > > const char *name;
> > > int size;
> > > -} hashdesc[] = {
> > > +} static const hashdesc[] = {
> > > [MD5] = {"MD5", 16},
> > > [MURMUR3] = {"murmur3", 16},
> > > [RIPEMD128] = {"RIPEMD128", 16},
> >
> > shouldn't that be static const struct { } hashdesc[] = { ... }
> >
> > as in static const foo[] = { ... };
>
> Reason I prefer this one is that if the struct becomes
> large it because very non-obvious that the array actually is
> "static const".
> It also is much harder to check/filter with grep.
> So for practical reasons I think it is better to place it here,
> or alternatively to name the struct and split them...
> But mostly I care about having it in .rodata, everything else
> I'm willing to adapt to what others prefer.
I'm mostly concerned about consistency. Except the one you added in
drawtext, this form is never used:
[~/src/ffmpeg]☭ git grep 'static const struct {'
libavcodec/aacps.c:static const struct {
libavcodec/aacsbr.c:static const struct {
libavcodec/dirac.c:static const struct {
libavcodec/dirac.c:static const struct {
libavcodec/indeo4.c:static const struct {
libavcodec/jacosubdec.c:static const struct {
libavcodec/libschroedinger.h:static const struct {
libavcodec/mace.c:static const struct {
libavcodec/svq3.c:static const struct {
libavcodec/twinvq_data.h:static const struct {
libavcodec/vorbis_enc_data.h:static const struct {
libavcodec/vorbis_enc_data.h:static const struct {
libavcodec/vp9.c:static const struct {
libavcodec/webvttdec.c:static const struct {
libavdevice/v4l.c:static const struct {
libavfilter/avf_showspectrum.c:static const struct {
libavfilter/vf_curves.c:static const struct {
libavfilter/vf_mp.c:static const struct {
libavfilter/vf_signalstats.c:static const struct {
libavformat/gxfenc.c:static const struct {
libavformat/mov_chan.c:static const struct {
libavformat/movenc.c:static const struct {
libavformat/mxf.c:static const struct {
libavformat/mxfenc.c:static const struct {
libavformat/rtp.c:static const struct {
libavformat/utils.c:static const struct {
libavutil/channel_layout.c:static const struct {
libavutil/cpu.c:static const struct {
libavutil/eval.c:static const struct {
[~/src/ffmpeg]☭ git grep '} static const'
libavfilter/vf_drawtext.c:} static const ft_errors[] =
[~/src/ffmpeg]☭
--
Clément B.
pgpWl839lazpB.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On Sat, 30 Aug 2014 19:58:11 +0200 Reimar Döffinger wrote: > On 30.08.2014, at 19:46, Reimar Döffinger wrote: > > On 30.08.2014, at 19:01, wm4 wrote: > >> > >> but still I wonder why you'd optimize > >> for binary size, in exchange for higher RAM usage. What is your > >> motivation for doing this? > > > > The only higher RAM usage would be when you actually use H.264, and it > > would be from the two additional lines of code. > > When you are not using H.264 the RAM usage (with some caveats on what the > > linker does) will be several 100 bytes lower. > > Small amendment: I missed that Linux seems to use copy-on-write for the data > section. > This means that the first 512 bytes of the table could in theory end up being > shared. You'd have to be lucky enough that they just end up on a different > page than the rest of the array. At the same time, the extra RAM usage when > H.264 is not used would be once per system, not per process. > I still wouldn't count it as using "more RAM", especially considering not all > OSes handle this as nicely as Linux, but it makes it a bit more borderline. OK... never mind then. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On 30.08.2014, at 19:46, Reimar Döffinger wrote: > On 30.08.2014, at 19:01, wm4 wrote: >> >> but still I wonder why you'd optimize >> for binary size, in exchange for higher RAM usage. What is your >> motivation for doing this? > > The only higher RAM usage would be when you actually use H.264, and it would > be from the two additional lines of code. > When you are not using H.264 the RAM usage (with some caveats on what the > linker does) will be several 100 bytes lower. Small amendment: I missed that Linux seems to use copy-on-write for the data section. This means that the first 512 bytes of the table could in theory end up being shared. You'd have to be lucky enough that they just end up on a different page than the rest of the array. At the same time, the extra RAM usage when H.264 is not used would be once per system, not per process. I still wouldn't count it as using "more RAM", especially considering not all OSes handle this as nicely as Linux, but it makes it a bit more borderline. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On 30.08.2014, at 19:01, wm4 wrote:
> On Sat, 30 Aug 2014 18:41:52 +0200
> Reimar Döffinger wrote:
>
>> On 30.08.2014, at 18:29, Reimar Döffinger wrote:
>>> On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
On Sat, 30 Aug 2014 18:18:41 +0200
Reimar Döffinger wrote:
> Moves it from .data to .bss, slightly reducing binary size.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavcodec/cabac.c | 26 --
> 1 file changed, 4 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> index 65579d8..803c81c 100644
> --- a/libavcodec/cabac.c
> +++ b/libavcodec/cabac.c
> @@ -32,28 +32,7 @@
> #include "cabac.h"
> #include "cabac_functions.h"
>
> -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
> - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> -};
> +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
>
> static const uint8_t lps_range[64][4]= {
> {128,176,208,240}, {128,167,197,227}, {128,158,187,216},
> {123,150,178,205},
> @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
>if (initialized)
>return;
>
> +for (i = 0; i < 512; i++)
> +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
> +
>for(i=0; i<64; i++){
>for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
> save
>ff_h264_lps_range[j*2*64+2*i+0]=
Doesn't this make library safety issues worse, instead of improving it?
>>>
>>> Why would it make anything even a slightest bit worse than it is now?
>>> Also, it makes it easier to make this hardcoded, which I think solves
>>> your concern?
>>
>> Just to be clear since it's not obvious: the lines just below what I added
>> initialise the second half of the array.
>> I just added that the first half is initialised in the same place.
>
> I have no strong feelings about it, but adding even more global mutable
> state feels wrong. Yes, I know there are many places like this etc.,
> so your patch is pretty innocent,
I don't consider it more mutable state, as said the array already is
initialised at runtime.
Though I guess it would be more if you count by-wise (though mutable is still
kind of the wrong word, not changing it doesn't make it const)
> but still I wonder why you'd optimize
> for binary size, in exchange for higher RAM usage. What is your
> motivation for doing this?
The only higher RAM usage would be when you actually use H.264, and it would be
from the two additional lines of code.
When you are not using H.264 the RAM usage (with some caveats on what the
linker does) will be several 100 bytes lower.
My motivation for it is that I see _no advantage whatsoever_ speaking for the
current code, and a few ones, including code clarify speaking for my code.
Though the biggest one maybe being that I want to move it to tablegen and
wanted to clean up the code first.
Sorry, but to me the current code is just "obviously stupid" (no offense
meant), I so far don't really understand what your concerns are with a change
like that (moving things from .data - not .rodata - to .bss)...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert
On Sat, Aug 30, 2014 at 08:19:37PM +0400, Dmitry Volyntsev wrote:
> To understand the problem one needs to see the original code around
> and to think what would happen if from time to time while capturing
> condition (s->frame_size > 0 && buf.bytesused != s->frame_size)
> happens to be true (this is not critical error so capturing would
> continue). It is obvious that eventually buffers_queued would become <
> 1.
why is this condition true, what are these mismatching buffers ?
>
> static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
> {
> ...
> if (buf.index >= s->buffers) {
> av_log(ctx, AV_LOG_ERROR, "Invalid buffer index received.\n");
>
> return AVERROR(EINVAL);
> }
>
> avpriv_atomic_int_add_and_fetch(&s->buffers_queued, -1);
> // always keep at least one buffer queued
> av_assert0(avpriv_atomic_int_get(&s->buffers_queued) >= 1);
>
> if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
>av_log(ctx, AV_LOG_ERROR,
>"The v4l2 frame is %d bytes, but %d bytes are expected\n",
>buf.bytesused, s->frame_size);
> return AVERROR_INVALIDDATA;
>
> }
>
> So my solution: we should make all checks here before decrementing
> buffers_queued
>
> On Wed, Aug 27, 2014 at 1:20 AM, Michael Niedermayer wrote:
> > On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
> >> From: Dmitry Volyntsev
> >>
> >> s->buffers_queued constantly decremented and not incremented
> >> in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
> >> condition (caught on long run capture of Logitech C310)
> >
> > can you explain why this happens ? where do this misatching
> > bufs come from ?
> > why is droping them correct ?
> >
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Dictatorship naturally arises out of democracy, and the most aggravated
> > form of tyranny and slavery out of the most extreme liberty. -- Plato
>
>
>
> --
> Be happy,
> Best regards,
> Dmitry Volyntsev
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On Sat, 30 Aug 2014 18:41:52 +0200
Reimar Döffinger wrote:
> On 30.08.2014, at 18:29, Reimar Döffinger wrote:
> > On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
> >> On Sat, 30 Aug 2014 18:18:41 +0200
> >> Reimar Döffinger wrote:
> >>
> >>> Moves it from .data to .bss, slightly reducing binary size.
> >>>
> >>> Signed-off-by: Reimar Döffinger
> >>> ---
> >>> libavcodec/cabac.c | 26 --
> >>> 1 file changed, 4 insertions(+), 22 deletions(-)
> >>>
> >>> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> >>> index 65579d8..803c81c 100644
> >>> --- a/libavcodec/cabac.c
> >>> +++ b/libavcodec/cabac.c
> >>> @@ -32,28 +32,7 @@
> >>> #include "cabac.h"
> >>> #include "cabac_functions.h"
> >>>
> >>> -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> >>> - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
> >>> - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
> >>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> >>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> >>> -};
> >>> +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
> >>>
> >>> static const uint8_t lps_range[64][4]= {
> >>> {128,176,208,240}, {128,167,197,227}, {128,158,187,216},
> >>> {123,150,178,205},
> >>> @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
> >>> if (initialized)
> >>> return;
> >>>
> >>> +for (i = 0; i < 512; i++)
> >>> +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
> >>> +
> >>> for(i=0; i<64; i++){
> >>> for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
> >>> save
> >>> ff_h264_lps_range[j*2*64+2*i+0]=
> >>
> >> Doesn't this make library safety issues worse, instead of improving it?
> >
> > Why would it make anything even a slightest bit worse than it is now?
> > Also, it makes it easier to make this hardcoded, which I think solves
> > your concern?
>
> Just to be clear since it's not obvious: the lines just below what I added
> initialise the second half of the array.
> I just added that the first half is initialised in the same place.
I have no strong feelings about it, but adding even more global mutable
state feels wrong. Yes, I know there are many places like this etc.,
so your patch is pretty innocent, but still I wonder why you'd optimize
for binary size, in exchange for higher RAM usage. What is your
motivation for doing this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On 30.08.2014, at 18:29, Reimar Döffinger wrote:
> On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
>> On Sat, 30 Aug 2014 18:18:41 +0200
>> Reimar Döffinger wrote:
>>
>>> Moves it from .data to .bss, slightly reducing binary size.
>>>
>>> Signed-off-by: Reimar Döffinger
>>> ---
>>> libavcodec/cabac.c | 26 --
>>> 1 file changed, 4 insertions(+), 22 deletions(-)
>>>
>>> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
>>> index 65579d8..803c81c 100644
>>> --- a/libavcodec/cabac.c
>>> +++ b/libavcodec/cabac.c
>>> @@ -32,28 +32,7 @@
>>> #include "cabac.h"
>>> #include "cabac_functions.h"
>>>
>>> -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
>>> - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
>>> - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
>>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
>>> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
>>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
>>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
>>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
>>> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
>>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>>> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
>>> -};
>>> +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
>>>
>>> static const uint8_t lps_range[64][4]= {
>>> {128,176,208,240}, {128,167,197,227}, {128,158,187,216}, {123,150,178,205},
>>> @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
>>> if (initialized)
>>> return;
>>>
>>> +for (i = 0; i < 512; i++)
>>> +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
>>> +
>>> for(i=0; i<64; i++){
>>> for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
>>> save
>>> ff_h264_lps_range[j*2*64+2*i+0]=
>>
>> Doesn't this make library safety issues worse, instead of improving it?
>
> Why would it make anything even a slightest bit worse than it is now?
> Also, it makes it easier to make this hardcoded, which I think solves
> your concern?
Just to be clear since it's not obvious: the lines just below what I added
initialise the second half of the array.
I just added that the first half is initialised in the same place.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On Sat, Aug 30, 2014 at 06:20:56PM +0200, wm4 wrote:
> On Sat, 30 Aug 2014 18:18:41 +0200
> Reimar Döffinger wrote:
>
> > Moves it from .data to .bss, slightly reducing binary size.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavcodec/cabac.c | 26 --
> > 1 file changed, 4 insertions(+), 22 deletions(-)
> >
> > diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> > index 65579d8..803c81c 100644
> > --- a/libavcodec/cabac.c
> > +++ b/libavcodec/cabac.c
> > @@ -32,28 +32,7 @@
> > #include "cabac.h"
> > #include "cabac_functions.h"
> >
> > -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> > - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
> > - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
> > - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> > - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> > - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> > - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> > - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> > - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> > - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> > - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> > - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> > - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> > -};
> > +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
> >
> > static const uint8_t lps_range[64][4]= {
> > {128,176,208,240}, {128,167,197,227}, {128,158,187,216}, {123,150,178,205},
> > @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
> > if (initialized)
> > return;
> >
> > +for (i = 0; i < 512; i++)
> > +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
> > +
> > for(i=0; i<64; i++){
> > for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
> > save
> > ff_h264_lps_range[j*2*64+2*i+0]=
>
> Doesn't this make library safety issues worse, instead of improving it?
Why would it make anything even a slightest bit worse than it is now?
Also, it makes it easier to make this hardcoded, which I think solves
your concern?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
On Sat, 30 Aug 2014 18:18:41 +0200
Reimar Döffinger wrote:
> Moves it from .data to .bss, slightly reducing binary size.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavcodec/cabac.c | 26 --
> 1 file changed, 4 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
> index 65579d8..803c81c 100644
> --- a/libavcodec/cabac.c
> +++ b/libavcodec/cabac.c
> @@ -32,28 +32,7 @@
> #include "cabac.h"
> #include "cabac_functions.h"
>
> -uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
> - 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
> - 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> - 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> - 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
> -};
> +uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
>
> static const uint8_t lps_range[64][4]= {
> {128,176,208,240}, {128,167,197,227}, {128,158,187,216}, {123,150,178,205},
> @@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
> if (initialized)
> return;
>
> +for (i = 0; i < 512; i++)
> +ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
> +
> for(i=0; i<64; i++){
> for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we
> save
> ff_h264_lps_range[j*2*64+2*i+0]=
Doesn't this make library safety issues worse, instead of improving it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavdevice/v4l2: fix of crash caused by assert
To understand the problem one needs to see the original code around
and to think what would happen if from time to time while capturing
condition (s->frame_size > 0 && buf.bytesused != s->frame_size)
happens to be true (this is not critical error so capturing would
continue). It is obvious that eventually buffers_queued would become <
1.
static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
{
...
if (buf.index >= s->buffers) {
av_log(ctx, AV_LOG_ERROR, "Invalid buffer index received.\n");
return AVERROR(EINVAL);
}
avpriv_atomic_int_add_and_fetch(&s->buffers_queued, -1);
// always keep at least one buffer queued
av_assert0(avpriv_atomic_int_get(&s->buffers_queued) >= 1);
if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
av_log(ctx, AV_LOG_ERROR,
"The v4l2 frame is %d bytes, but %d bytes are expected\n",
buf.bytesused, s->frame_size);
return AVERROR_INVALIDDATA;
}
So my solution: we should make all checks here before decrementing
buffers_queued
On Wed, Aug 27, 2014 at 1:20 AM, Michael Niedermayer wrote:
> On Wed, Aug 13, 2014 at 07:04:01PM +0400, Dmitry Volyntsev wrote:
>> From: Dmitry Volyntsev
>>
>> s->buffers_queued constantly decremented and not incremented
>> in case of (s->frame_size > 0 && buf.bytesused != s->frame_size)
>> condition (caught on long run capture of Logitech C310)
>
> can you explain why this happens ? where do this misatching
> bufs come from ?
> why is droping them correct ?
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Dictatorship naturally arises out of democracy, and the most aggravated
> form of tyranny and slavery out of the most extreme liberty. -- Plato
--
Be happy,
Best regards,
Dmitry Volyntsev
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cabac: initialize all of ff_h264_cabac_tables programmatically.
Moves it from .data to .bss, slightly reducing binary size.
Signed-off-by: Reimar Döffinger
---
libavcodec/cabac.c | 26 --
1 file changed, 4 insertions(+), 22 deletions(-)
diff --git a/libavcodec/cabac.c b/libavcodec/cabac.c
index 65579d8..803c81c 100644
--- a/libavcodec/cabac.c
+++ b/libavcodec/cabac.c
@@ -32,28 +32,7 @@
#include "cabac.h"
#include "cabac_functions.h"
-uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63] = {
- 9,8,7,7,6,6,6,6,5,5,5,5,5,5,5,5,
- 4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,4,
- 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
- 3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,3,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,2,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
- 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
-};
+uint8_t ff_h264_cabac_tables[512 + 4*2*64 + 4*64 + 63];
static const uint8_t lps_range[64][4]= {
{128,176,208,240}, {128,167,197,227}, {128,158,187,216}, {123,150,178,205},
@@ -143,6 +122,9 @@ void ff_init_cabac_states(void)
if (initialized)
return;
+for (i = 0; i < 512; i++)
+ff_h264_norm_shift[i] = i ? 8 - av_log2(i) : 9;
+
for(i=0; i<64; i++){
for(j=0; j<4; j++){ //FIXME check if this is worth the 1 shift we save
ff_h264_lps_range[j*2*64+2*i+0]=
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add av_cold to table generation functions.
On Sat, Aug 30, 2014 at 06:00:43PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/aac_tablegen.h | 2 +- > libavcodec/aacps_tablegen.h| 4 ++-- > libavcodec/aacsbr_tablegen.h | 2 +- > libavcodec/cbrt_tablegen.h | 3 ++- > libavcodec/dv_tablegen.h | 3 ++- > libavcodec/motionpixels_tablegen.h | 7 --- > libavcodec/mpegaudio_tablegen.h| 3 ++- > 7 files changed, 14 insertions(+), 10 deletions(-) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] WMA: add "const" to avoid warnings with hardcoded tables.
On Sat, Aug 30, 2014 at 06:00:20PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/wma.h | 2 +- > libavcodec/wmaprodec.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.
On Sat, Aug 30, 2014 at 05:55:39PM +0200, Paul B Mahol wrote: > On 8/30/14, Reimar Doeffinger wrote: > > Signed-off-by: Reimar Doeffinger > > --- > > libavdevice/xv.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > lgtm Thanks, pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add av_cold to table generation functions.
Signed-off-by: Reimar Döffinger
---
libavcodec/aac_tablegen.h | 2 +-
libavcodec/aacps_tablegen.h| 4 ++--
libavcodec/aacsbr_tablegen.h | 2 +-
libavcodec/cbrt_tablegen.h | 3 ++-
libavcodec/dv_tablegen.h | 3 ++-
libavcodec/motionpixels_tablegen.h | 7 ---
libavcodec/mpegaudio_tablegen.h| 3 ++-
7 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
index 1c19a15..bf71e59 100644
--- a/libavcodec/aac_tablegen.h
+++ b/libavcodec/aac_tablegen.h
@@ -31,7 +31,7 @@
#include "libavutil/mathematics.h"
float ff_aac_pow2sf_tab[428];
-void ff_aac_tableinit(void)
+av_cold void ff_aac_tableinit(void)
{
int i;
for (i = 0; i < 428; i++)
diff --git a/libavcodec/aacps_tablegen.h b/libavcodec/aacps_tablegen.h
index 9df38ff..ca1112d 100644
--- a/libavcodec/aacps_tablegen.h
+++ b/libavcodec/aacps_tablegen.h
@@ -70,7 +70,7 @@ static const float g2_Q4[] = {
0.16486303567403f, 0.23279856662996f, 0.25f
};
-static void make_filters_from_proto(float (*filter)[8][2], const float *proto,
int bands)
+static av_cold void make_filters_from_proto(float (*filter)[8][2], const float
*proto, int bands)
{
int q, n;
for (q = 0; q < bands; q++) {
@@ -82,7 +82,7 @@ static void make_filters_from_proto(float (*filter)[8][2],
const float *proto, i
}
}
-static void ps_tableinit(void)
+static av_cold void ps_tableinit(void)
{
static const float ipdopd_sin[] = { 0, M_SQRT1_2, 1, M_SQRT1_2, 0,
-M_SQRT1_2, -1, -M_SQRT1_2 };
static const float ipdopd_cos[] = { 1, M_SQRT1_2, 0, -M_SQRT1_2, -1,
-M_SQRT1_2, 0, M_SQRT1_2 };
diff --git a/libavcodec/aacsbr_tablegen.h b/libavcodec/aacsbr_tablegen.h
index 7b70c26..56fdccc 100644
--- a/libavcodec/aacsbr_tablegen.h
+++ b/libavcodec/aacsbr_tablegen.h
@@ -113,7 +113,7 @@ static DECLARE_ALIGNED(32, float, sbr_qmf_window_us)[640] =
{
0.8537385600,
};
-static void aacsbr_tableinit(void)
+static av_cold void aacsbr_tableinit(void)
{
int n;
for (n = 1; n < 320; n++)
diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
index 0db64fc..d8c77c2 100644
--- a/libavcodec/cbrt_tablegen.h
+++ b/libavcodec/cbrt_tablegen.h
@@ -25,6 +25,7 @@
#include
#include
+#include "libavutil/attributes.h"
#if CONFIG_HARDCODED_TABLES
#define cbrt_tableinit()
@@ -32,7 +33,7 @@
#else
static uint32_t cbrt_tab[1 << 13];
-static void cbrt_tableinit(void)
+static av_cold void cbrt_tableinit(void)
{
if (!cbrt_tab[(1<<13) - 1]) {
int i;
diff --git a/libavcodec/dv_tablegen.h b/libavcodec/dv_tablegen.h
index c04b802..cc6605b 100644
--- a/libavcodec/dv_tablegen.h
+++ b/libavcodec/dv_tablegen.h
@@ -24,6 +24,7 @@
#define AVCODEC_DV_TABLEGEN_H
#include
+#include "libavutil/attributes.h"
#include "dvdata.h"
@@ -47,7 +48,7 @@ typedef struct dv_vlc_pair {
#else
static struct dv_vlc_pair dv_vlc_map[DV_VLC_MAP_RUN_SIZE][DV_VLC_MAP_LEV_SIZE];
-static void dv_vlc_map_tableinit(void)
+static av_cold void dv_vlc_map_tableinit(void)
{
int i, j;
for (i = 0; i < NB_DV_VLC - 1; i++) {
diff --git a/libavcodec/motionpixels_tablegen.h
b/libavcodec/motionpixels_tablegen.h
index 8fb840f..4ffe74c 100644
--- a/libavcodec/motionpixels_tablegen.h
+++ b/libavcodec/motionpixels_tablegen.h
@@ -24,6 +24,7 @@
#define AVCODEC_MOTIONPIXELS_TABLEGEN_H
#include
+#include "libavutil/attributes.h"
typedef struct YuvPixel {
int8_t y, v, u;
@@ -49,7 +50,7 @@ static int mp_yuv_to_rgb(int y, int v, int u, int clip_rgb) {
#else
static YuvPixel mp_rgb_yuv_table[1 << 15];
-static void mp_set_zero_yuv(YuvPixel *p)
+static av_cold void mp_set_zero_yuv(YuvPixel *p)
{
int i, j;
@@ -63,7 +64,7 @@ static void mp_set_zero_yuv(YuvPixel *p)
}
}
-static void mp_build_rgb_yuv_table(YuvPixel *p)
+static av_cold void mp_build_rgb_yuv_table(YuvPixel *p)
{
int y, v, u, i;
@@ -81,7 +82,7 @@ static void mp_build_rgb_yuv_table(YuvPixel *p)
mp_set_zero_yuv(p + i * 32);
}
-static void motionpixels_tableinit(void)
+static av_cold void motionpixels_tableinit(void)
{
if (!mp_rgb_yuv_table[0].u)
mp_build_rgb_yuv_table(mp_rgb_yuv_table);
diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
index f9557c9..86b2cd3 100644
--- a/libavcodec/mpegaudio_tablegen.h
+++ b/libavcodec/mpegaudio_tablegen.h
@@ -25,6 +25,7 @@
#include
#include
+#include "libavutil/attributes.h"
#define TABLE_4_3_SIZE (8191 + 16)*4
#if CONFIG_HARDCODED_TABLES
@@ -41,7 +42,7 @@ static float expval_table_float[512][16];
#define FRAC_BITS 23
#define IMDCT_SCALAR 1.759
-static void mpegaudio_tableinit(void)
+static av_cold void mpegaudio_tableinit(void)
{
int i, value, exponent;
for (i = 1; i < TABLE_4_3_SIZE; i++) {
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] WMA: add "const" to avoid warnings with hardcoded tables.
Signed-off-by: Reimar Döffinger
---
libavcodec/wma.h | 2 +-
libavcodec/wmaprodec.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/wma.h b/libavcodec/wma.h
index c4056ec..01244a0 100644
--- a/libavcodec/wma.h
+++ b/libavcodec/wma.h
@@ -115,7 +115,7 @@ typedef struct WMACodecContext {
DECLARE_ALIGNED(32, float, coefs)[MAX_CHANNELS][BLOCK_MAX_SIZE];
DECLARE_ALIGNED(32, FFTSample, output)[BLOCK_MAX_SIZE * 2];
FFTContext mdct_ctx[BLOCK_NB_SIZES];
-float *windows[BLOCK_NB_SIZES];
+const float *windows[BLOCK_NB_SIZES];
/* output buffer for one frame and the last for IMDCT windowing */
DECLARE_ALIGNED(32, float, frame_out)[MAX_CHANNELS][BLOCK_MAX_SIZE * 2];
/* last frame info */
diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index 2f6c485..f45e1fc 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -177,7 +177,7 @@ typedef struct WMAProDecodeCtx {
PutBitContextpb;///< context for filling
the frame_data buffer
FFTContext mdct_ctx[WMAPRO_BLOCK_SIZES]; ///< MDCT context per
block size
DECLARE_ALIGNED(32, float, tmp)[WMAPRO_BLOCK_MAX_SIZE]; ///< IMDCT output
buffer
-float* windows[WMAPRO_BLOCK_SIZES]; ///< windows for the
different block sizes
+const float* windows[WMAPRO_BLOCK_SIZES]; ///< windows for the
different block sizes
/* frame size dependent frame information (set during initialization) */
uint32_t decode_flags; ///< used compression
features
@@ -1055,7 +1055,7 @@ static void wmapro_window(WMAProDecodeCtx *s)
int i;
for (i = 0; i < s->channels_for_cur_subframe; i++) {
int c = s->channel_indexes_for_cur_subframe[i];
-float* window;
+const float* window;
int winlen = s->channel[c].prev_block_len;
float* start = s->channel[c].coeffs - (winlen >> 1);
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.
On 8/30/14, Reimar Doeffinger wrote:
> Signed-off-by: Reimar Doeffinger
> ---
> libavdevice/xv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavdevice/xv.c b/libavdevice/xv.c
> index aeb3e41..c19c15c 100644
> --- a/libavdevice/xv.c
> +++ b/libavdevice/xv.c
> @@ -67,7 +67,7 @@ typedef struct XVTagFormatMap
> enum AVPixelFormat format;
> } XVTagFormatMap;
>
> -static XVTagFormatMap tag_codec_map[] = {
> +static const XVTagFormatMap tag_codec_map[] = {
> { MKTAG('I','4','2','0'), AV_PIX_FMT_YUV420P },
> { MKTAG('U','Y','V','Y'), AV_PIX_FMT_UYVY422 },
> { MKTAG('Y','U','Y','2'), AV_PIX_FMT_YUYV422 },
> @@ -76,7 +76,7 @@ static XVTagFormatMap tag_codec_map[] = {
>
> static int xv_get_tag_from_format(enum AVPixelFormat format)
> {
> -XVTagFormatMap *m = tag_codec_map;
> +const XVTagFormatMap *m = tag_codec_map;
> int i;
> for (i = 0; m->tag; m = &tag_codec_map[++i]) {
> if (m->format == format)
> --
> 2.1.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.
On Sat, Aug 30, 2014 at 08:07:29AM -0700, Timothy Gu wrote: > On Aug 30, 2014 7:44 AM, "Reimar Döffinger" > wrote: > > It's lavfi, not lavf. Fixed locally. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add av_cold to table generation functions.
On Sat, Aug 30, 2014 at 05:35:55PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger Sorry, I sent this by accident. It does not yet compile, will send a fixed version. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add av_cold to table generation functions.
Signed-off-by: Reimar Döffinger
---
libavcodec/aac_tablegen.h | 2 +-
libavcodec/aacps_tablegen.h| 4 ++--
libavcodec/aacsbr_tablegen.h | 2 +-
libavcodec/cbrt_tablegen.h | 2 +-
libavcodec/dv_tablegen.h | 2 +-
libavcodec/motionpixels_tablegen.h | 6 +++---
libavcodec/mpegaudio_tablegen.h| 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavcodec/aac_tablegen.h b/libavcodec/aac_tablegen.h
index 1c19a15..bf71e59 100644
--- a/libavcodec/aac_tablegen.h
+++ b/libavcodec/aac_tablegen.h
@@ -31,7 +31,7 @@
#include "libavutil/mathematics.h"
float ff_aac_pow2sf_tab[428];
-void ff_aac_tableinit(void)
+av_cold void ff_aac_tableinit(void)
{
int i;
for (i = 0; i < 428; i++)
diff --git a/libavcodec/aacps_tablegen.h b/libavcodec/aacps_tablegen.h
index 9df38ff..ca1112d 100644
--- a/libavcodec/aacps_tablegen.h
+++ b/libavcodec/aacps_tablegen.h
@@ -70,7 +70,7 @@ static const float g2_Q4[] = {
0.16486303567403f, 0.23279856662996f, 0.25f
};
-static void make_filters_from_proto(float (*filter)[8][2], const float *proto,
int bands)
+static av_cold void make_filters_from_proto(float (*filter)[8][2], const float
*proto, int bands)
{
int q, n;
for (q = 0; q < bands; q++) {
@@ -82,7 +82,7 @@ static void make_filters_from_proto(float (*filter)[8][2],
const float *proto, i
}
}
-static void ps_tableinit(void)
+static av_cold void ps_tableinit(void)
{
static const float ipdopd_sin[] = { 0, M_SQRT1_2, 1, M_SQRT1_2, 0,
-M_SQRT1_2, -1, -M_SQRT1_2 };
static const float ipdopd_cos[] = { 1, M_SQRT1_2, 0, -M_SQRT1_2, -1,
-M_SQRT1_2, 0, M_SQRT1_2 };
diff --git a/libavcodec/aacsbr_tablegen.h b/libavcodec/aacsbr_tablegen.h
index 104daae..7380e26 100644
--- a/libavcodec/aacsbr_tablegen.h
+++ b/libavcodec/aacsbr_tablegen.h
@@ -116,7 +116,7 @@ static DECLARE_ALIGNED(32, float, sbr_qmf_window_us)[640] =
{
0.8537385600,
};
-static void aacsbr_tableinit(void)
+static av_cold void aacsbr_tableinit(void)
{
int n;
for (n = 1; n < 320; n++)
diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
index 0db64fc..73705e1 100644
--- a/libavcodec/cbrt_tablegen.h
+++ b/libavcodec/cbrt_tablegen.h
@@ -32,7 +32,7 @@
#else
static uint32_t cbrt_tab[1 << 13];
-static void cbrt_tableinit(void)
+static av_cold void cbrt_tableinit(void)
{
if (!cbrt_tab[(1<<13) - 1]) {
int i;
diff --git a/libavcodec/dv_tablegen.h b/libavcodec/dv_tablegen.h
index c04b802..0b83a14 100644
--- a/libavcodec/dv_tablegen.h
+++ b/libavcodec/dv_tablegen.h
@@ -47,7 +47,7 @@ typedef struct dv_vlc_pair {
#else
static struct dv_vlc_pair dv_vlc_map[DV_VLC_MAP_RUN_SIZE][DV_VLC_MAP_LEV_SIZE];
-static void dv_vlc_map_tableinit(void)
+static av_cold void dv_vlc_map_tableinit(void)
{
int i, j;
for (i = 0; i < NB_DV_VLC - 1; i++) {
diff --git a/libavcodec/motionpixels_tablegen.h
b/libavcodec/motionpixels_tablegen.h
index 8fb840f..323914c 100644
--- a/libavcodec/motionpixels_tablegen.h
+++ b/libavcodec/motionpixels_tablegen.h
@@ -49,7 +49,7 @@ static int mp_yuv_to_rgb(int y, int v, int u, int clip_rgb) {
#else
static YuvPixel mp_rgb_yuv_table[1 << 15];
-static void mp_set_zero_yuv(YuvPixel *p)
+static av_cold void mp_set_zero_yuv(YuvPixel *p)
{
int i, j;
@@ -63,7 +63,7 @@ static void mp_set_zero_yuv(YuvPixel *p)
}
}
-static void mp_build_rgb_yuv_table(YuvPixel *p)
+static av_cold void mp_build_rgb_yuv_table(YuvPixel *p)
{
int y, v, u, i;
@@ -81,7 +81,7 @@ static void mp_build_rgb_yuv_table(YuvPixel *p)
mp_set_zero_yuv(p + i * 32);
}
-static void motionpixels_tableinit(void)
+static av_cold void motionpixels_tableinit(void)
{
if (!mp_rgb_yuv_table[0].u)
mp_build_rgb_yuv_table(mp_rgb_yuv_table);
diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
index f9557c9..872cdf3 100644
--- a/libavcodec/mpegaudio_tablegen.h
+++ b/libavcodec/mpegaudio_tablegen.h
@@ -41,7 +41,7 @@ static float expval_table_float[512][16];
#define FRAC_BITS 23
#define IMDCT_SCALAR 1.759
-static void mpegaudio_tableinit(void)
+static av_cold void mpegaudio_tableinit(void)
{
int i, value, exponent;
for (i = 1; i < TABLE_4_3_SIZE; i++) {
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] aacsbr: support hardcoding tables.
For sbr_qmf_window_us there is even a question if it maybe
should be fully hardcoded all the time.
Since half of it is coded, it ends up in .data and not .bss.
Signed-off-by: Reimar Döffinger
---
libavcodec/Makefile | 4 +-
libavcodec/aacsbr.c | 10 +---
libavcodec/aacsbr_tablegen.c | 39 +
libavcodec/aacsbr_tablegen.h | 132 +++
libavcodec/aacsbrdata.h | 86
libavcodec/tableprint.h | 10
6 files changed, 186 insertions(+), 95 deletions(-)
create mode 100644 libavcodec/aacsbr_tablegen.c
create mode 100644 libavcodec/aacsbr_tablegen.h
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8173449..0ed5478 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -871,6 +871,7 @@ TOOLS = fourcc2pixfmt
HOSTPROGS = aac_tablegen\
aacps_tablegen \
+aacsbr_tablegen \
cbrt_tablegen \
cos_tablegen\
dsd_tablegen\
@@ -898,7 +899,7 @@ else
$(SUBDIR)%_tablegen$(HOSTEXESUF): HOSTCFLAGS += -DCONFIG_SMALL=0
endif
-GEN_HEADERS = cbrt_tables.h aacps_tables.h aac_tables.h dsd_tables.h
dv_tables.h \
+GEN_HEADERS = cbrt_tables.h aacps_tables.h aacsbr_tables.h aac_tables.h
dsd_tables.h dv_tables.h \
sinewin_tables.h mpegaudio_tables.h motionpixels_tables.h \
pcm_tables.h qdm2_tables.h
GEN_HEADERS := $(addprefix $(SUBDIR), $(GEN_HEADERS))
@@ -909,6 +910,7 @@ $(GEN_HEADERS): $(SUBDIR)%_tables.h:
$(SUBDIR)%_tablegen$(HOSTEXESUF)
ifdef CONFIG_HARDCODED_TABLES
$(SUBDIR)aacdec.o: $(SUBDIR)cbrt_tables.h
$(SUBDIR)aacps.o: $(SUBDIR)aacps_tables.h
+$(SUBDIR)aacsbr.o: $(SUBDIR)aacsbr_tables.h
$(SUBDIR)aactab.o: $(SUBDIR)aac_tables.h
$(SUBDIR)dsddec.o: $(SUBDIR)dsd_tables.h
$(SUBDIR)dvenc.o: $(SUBDIR)dv_tables.h
diff --git a/libavcodec/aacsbr.c b/libavcodec/aacsbr.c
index 290fb81..f550ead 100644
--- a/libavcodec/aacsbr.c
+++ b/libavcodec/aacsbr.c
@@ -30,6 +30,7 @@
#include "sbr.h"
#include "aacsbr.h"
#include "aacsbrdata.h"
+#include "aacsbr_tablegen.h"
#include "fft.h"
#include "aacps.h"
#include "sbrdsp.h"
@@ -95,7 +96,6 @@ static void aacsbr_func_ptr_init(AACSBRContext *c);
av_cold void ff_aac_sbr_init(void)
{
-int n;
static const struct {
const void *sbr_codes, *sbr_bits;
const unsigned int table_size, elem_size;
@@ -124,13 +124,7 @@ av_cold void ff_aac_sbr_init(void)
SBR_INIT_VLC_STATIC(8, 592);
SBR_INIT_VLC_STATIC(9, 512);
-for (n = 1; n < 320; n++)
-sbr_qmf_window_us[320 + n] = sbr_qmf_window_us[320 - n];
-sbr_qmf_window_us[384] = -sbr_qmf_window_us[384];
-sbr_qmf_window_us[512] = -sbr_qmf_window_us[512];
-
-for (n = 0; n < 320; n++)
-sbr_qmf_window_ds[n] = sbr_qmf_window_us[2*n];
+aacsbr_tableinit();
ff_ps_init();
}
diff --git a/libavcodec/aacsbr_tablegen.c b/libavcodec/aacsbr_tablegen.c
new file mode 100644
index 000..c3c0f0c
--- /dev/null
+++ b/libavcodec/aacsbr_tablegen.c
@@ -0,0 +1,39 @@
+/*
+ * Header file for hardcoded AAC SBR windows
+ *
+ * Copyright (c) 2014 Reimar Döffinger
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#define CONFIG_HARDCODED_TABLES 0
+#include "libavutil/common.h"
+#include "aacsbr_tablegen.h"
+#include "tableprint.h"
+
+int main(void)
+{
+aacsbr_tableinit();
+
+write_fileheader();
+
+WRITE_ARRAY_ALIGNED("static const", 32, float, sbr_qmf_window_ds);
+WRITE_ARRAY_ALIGNED("static const", 32, float, sbr_qmf_window_us);
+
+return 0;
+}
diff --git a/libavcodec/aacsbr_tablegen.h b/libavcodec/aacsbr_tablegen.h
new file mode 100644
index 000..104daae
--- /dev/null
+++ b/libavcodec/aacsbr_tablegen.h
@@ -0,0 +1,132 @@
+/*
+ * Header file for hardcoded AAC SBR windows
+ *
+ * Copyright (c) 2014 Reimar Döffinger
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the t
Re: [FFmpeg-devel] [PATCH 2/6] fft_template: Move variables to where they are used.
On Sat, Aug 30, 2014 at 04:43:40PM +0200, Reimar Döffinger wrote: > Signed-off-by: Reimar Döffinger > --- > libavcodec/fft_template.c | 11 --- > 1 file changed, 4 insertions(+), 7 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.
On Aug 30, 2014 7:44 AM, "Reimar Döffinger" wrote: It's lavfi, not lavf. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] oggdec: fix invalid free on error
On Sat, Aug 30, 2014 at 03:39:15PM +0200, wm4 wrote: > The read_packet callback passes a pointer to a stack-allocated AVPacket. > Attempting to free it with av_free() makes no sense. > --- > Found by looking at the code; there's no sample file. > --- > libavformat/oggdec.c | 1 - > 1 file changed, 1 deletion(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/6] fft: add ff_ prefix to some global arrays.
Signed-off-by: Reimar Döffinger
---
libavcodec/fft_init_table.c | 4 ++--
libavcodec/fft_table.h | 4 ++--
libavcodec/fft_template.c | 12 ++--
libavcodec/mips/fft_mips.c | 8
4 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/fft_init_table.c b/libavcodec/fft_init_table.c
index 4e8b082..4d74f8a 100644
--- a/libavcodec/fft_init_table.c
+++ b/libavcodec/fft_init_table.c
@@ -53,7 +53,7 @@
*/
#include "libavcodec/fft_table.h"
-const int32_t w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
+const int32_t ff_w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
2147483647, 2147481121, 2147473542, 2147460908, 2147443222, 2147420483,
2147392690, 2147359845,
2147321946, 2147278995, 2147230991, 2147177934, 2147119825, 2147056664,
2146988450, 2146915184,
2146836866, 2146753497, 2146665076, 2146571603, 2146473080, 2146369505,
2146260881, 2146147205,
@@ -184,7 +184,7 @@ const int32_t w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
26352928, 23058947, 19764913, 16470832, 13176712,9882561,
6588387,3294197
};
-uint16_t fft_offsets_lut[0x2aab];
+uint16_t ff_fft_offsets_lut[0x2aab];
void ff_fft_lut_init(uint16_t *table, int off, int size, int *index)
{
diff --git a/libavcodec/fft_table.h b/libavcodec/fft_table.h
index 4cd3a45..e5e54b6 100644
--- a/libavcodec/fft_table.h
+++ b/libavcodec/fft_table.h
@@ -59,8 +59,8 @@
#define MAX_LOG2_NFFT 16 //!< Specifies maximum allowed fft size
#define MAX_FFT_SIZE (1 << MAX_LOG2_NFFT)
-extern const int32_t w_tab_sr[];
-extern uint16_t fft_offsets_lut[];
+extern const int32_t ff_w_tab_sr[];
+extern uint16_t ff_fft_offsets_lut[];
void ff_fft_lut_init(uint16_t *table, int off, int size, int *index);
#endif /* AVCODEC_FFT_TABLE_H */
diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 697d1fc..3abf948 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -166,7 +166,7 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int
inverse)
#if FFT_FIXED_32
{
int n=0;
-ff_fft_lut_init(fft_offsets_lut, 0, 1 << 16, &n);
+ff_fft_lut_init(ff_fft_offsets_lut, 0, 1 << 16, &n);
}
#else /* FFT_FIXED_32 */
#if FFT_FLOAT
@@ -236,7 +236,7 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
num_transforms = (0x2aab >> (16 - s->nbits)) | 1;
for (n=0; n> 1) | 1;
for (n=0; n> 1) | 1;
for (n=0; n> 1) | 1;
for (n=0; nhttp://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/6] ac3dec_fixed: add missing "static const".
Signed-off-by: Reimar Döffinger
---
libavcodec/ac3dec_fixed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c
index f36e7b0..4c09de5 100644
--- a/libavcodec/ac3dec_fixed.c
+++ b/libavcodec/ac3dec_fixed.c
@@ -65,7 +65,7 @@ static const uint8_t center_levels[4] = { 4, 5, 6, 5 };
*/
static const uint8_t surround_levels[4] = { 4, 6, 7, 6 };
-int end_freq_inv_tab[8] =
+static const int end_freq_inv_tab[8] =
{
50529027, 44278013, 39403370, 32292987, 27356480, 23729101, 20951060,
18755316
};
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/6] lavf: add const/static const to pix_fmts arrays.
Signed-off-by: Reimar Döffinger
---
libavfilter/vf_blackdetect.c| 2 +-
libavfilter/vf_lenscorrection.c | 2 +-
libavfilter/vf_signalstats.c| 2 +-
libavfilter/vf_tinterlace.c | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_blackdetect.c b/libavfilter/vf_blackdetect.c
index 94af613..87a7a23 100644
--- a/libavfilter/vf_blackdetect.c
+++ b/libavfilter/vf_blackdetect.c
@@ -64,7 +64,7 @@ AVFILTER_DEFINE_CLASS(blackdetect);
#define YUVJ_FORMATS \
AV_PIX_FMT_YUVJ411P, AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P,
AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ440P
-static enum AVPixelFormat yuvj_formats[] = {
+static const enum AVPixelFormat yuvj_formats[] = {
YUVJ_FORMATS, AV_PIX_FMT_NONE
};
diff --git a/libavfilter/vf_lenscorrection.c b/libavfilter/vf_lenscorrection.c
index 58184b0..9fb1424 100644
--- a/libavfilter/vf_lenscorrection.c
+++ b/libavfilter/vf_lenscorrection.c
@@ -98,7 +98,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, int
job, int nb_jobs)
static int query_formats(AVFilterContext *ctx)
{
-static enum AVPixelFormat pix_fmts[] = {
+static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_YUV410P,
AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUVJ420P,
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index 263de23..53f7401 100644
--- a/libavfilter/vf_signalstats.c
+++ b/libavfilter/vf_signalstats.c
@@ -94,7 +94,7 @@ static av_cold void uninit(AVFilterContext *ctx)
static int query_formats(AVFilterContext *ctx)
{
// TODO: add more
-enum AVPixelFormat pix_fmts[] = {
+static const enum AVPixelFormat pix_fmts[] = {
AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P,
AV_PIX_FMT_YUV411P,
AV_PIX_FMT_NONE
};
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index 3ebb971..6bc55b5 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -80,7 +80,7 @@ AVFILTER_DEFINE_CLASS(tinterlace);
#define FULL_SCALE_YUVJ_FORMATS \
AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_YUVJ440P
-static enum AVPixelFormat full_scale_yuvj_pix_fmts[] = {
+static const enum AVPixelFormat full_scale_yuvj_pix_fmts[] = {
FULL_SCALE_YUVJ_FORMATS, AV_PIX_FMT_NONE
};
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/6] sipr16kdata.h: add forgotten const.
Signed-off-by: Reimar Döffinger
---
libavcodec/sipr16kdata.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/sipr16kdata.h b/libavcodec/sipr16kdata.h
index 96bf0e9..16a653d 100644
--- a/libavcodec/sipr16kdata.h
+++ b/libavcodec/sipr16kdata.h
@@ -525,7 +525,7 @@ static const float lsf_cb5_16k[128][4] = {
{ 0.124405, 0.009943, -0.148477, -0.205184}
};
-static const float *lsf_codebooks_16k[] = {
+static const float * const lsf_codebooks_16k[] = {
lsf_cb1_16k[0], lsf_cb2_16k[0], lsf_cb3_16k[0], lsf_cb4_16k[0],
lsf_cb5_16k[0]
};
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/6] xv.c: Add missing const to lookup table.
Signed-off-by: Reimar Döffinger
---
libavdevice/xv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavdevice/xv.c b/libavdevice/xv.c
index aeb3e41..c19c15c 100644
--- a/libavdevice/xv.c
+++ b/libavdevice/xv.c
@@ -67,7 +67,7 @@ typedef struct XVTagFormatMap
enum AVPixelFormat format;
} XVTagFormatMap;
-static XVTagFormatMap tag_codec_map[] = {
+static const XVTagFormatMap tag_codec_map[] = {
{ MKTAG('I','4','2','0'), AV_PIX_FMT_YUV420P },
{ MKTAG('U','Y','V','Y'), AV_PIX_FMT_UYVY422 },
{ MKTAG('Y','U','Y','2'), AV_PIX_FMT_YUYV422 },
@@ -76,7 +76,7 @@ static XVTagFormatMap tag_codec_map[] = {
static int xv_get_tag_from_format(enum AVPixelFormat format)
{
-XVTagFormatMap *m = tag_codec_map;
+const XVTagFormatMap *m = tag_codec_map;
int i;
for (i = 0; m->tag; m = &tag_codec_map[++i]) {
if (m->format == format)
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/6] fft_template: Move variables to where they are used.
Signed-off-by: Reimar Döffinger
---
libavcodec/fft_template.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 3abf948..23ea453 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -228,8 +228,6 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
int n4, n2, n34;
FFTSample tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7, tmp8;
FFTComplex *tmpz;
-FFTSample w_re, w_im;
-const FFTSample *w_re_ptr, *w_im_ptr;
const int fft_size = (1 << s->nbits);
int64_t accu;
@@ -322,6 +320,8 @@ static void fft_calc_c(FFTContext *s, FFTComplex *z) {
num_transforms = (num_transforms >> 1) | 1;
for (n=0; n> 31);
--
2.1.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/hash.c: Add missing "static const".
On Fri, Aug 29, 2014 at 09:29:46PM +0200, Clément Bœsch wrote:
> On Fri, Aug 29, 2014 at 06:34:52PM +0200, Reimar Döffinger wrote:
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavutil/hash.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hash.c b/libavutil/hash.c
> > index 773f29e..979fdd9 100644
> > --- a/libavutil/hash.c
> > +++ b/libavutil/hash.c
> > @@ -63,7 +63,7 @@ typedef struct AVHashContext {
> > struct {
> > const char *name;
> > int size;
> > -} hashdesc[] = {
> > +} static const hashdesc[] = {
> > [MD5] = {"MD5", 16},
> > [MURMUR3] = {"murmur3", 16},
> > [RIPEMD128] = {"RIPEMD128", 16},
>
> shouldn't that be static const struct { } hashdesc[] = { ... }
>
> as in static const foo[] = { ... };
Reason I prefer this one is that if the struct becomes
large it because very non-obvious that the array actually is
"static const".
It also is much harder to check/filter with grep.
So for practical reasons I think it is better to place it here,
or alternatively to name the struct and split them...
But mostly I care about having it in .rodata, everything else
I'm willing to adapt to what others prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added synchronous KLV codec ID and mpegts PAT and PMT descriptors as specified in stanag4609 annex C
On Fri, Aug 29, 2014 at 02:24:21PM +0200, paolovergori wrote:
> ---
> libavcodec/avcodec.h| 17 +
> libavcodec/codec_desc.c | 6 ++
> libavformat/mpegts.c| 2 ++
> libavformat/mpegts.h| 1 +
> libavformat/mpegtsenc.c | 27 +++
> 5 files changed, 45 insertions(+), 8 deletions(-)
The changes to the mpegts muxer and demuxer really should be done in separate
patches.
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb1c9ca..99eba82 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -526,14 +526,15 @@ enum AVCodecID {
> /* other specific kind of codecs (generally used for attachments) */
> AV_CODEC_ID_FIRST_UNKNOWN = 0x18000, ///< A dummy ID pointing
> at the start of various fake codecs.
> AV_CODEC_ID_TTF = 0x18000,
> -AV_CODEC_ID_BINTEXT= MKBETAG('B','T','X','T'),
> -AV_CODEC_ID_XBIN = MKBETAG('X','B','I','N'),
> -AV_CODEC_ID_IDF= MKBETAG( 0 ,'I','D','F'),
> -AV_CODEC_ID_OTF= MKBETAG( 0 ,'O','T','F'),
> -AV_CODEC_ID_SMPTE_KLV = MKBETAG('K','L','V','A'),
> -AV_CODEC_ID_DVD_NAV= MKBETAG('D','N','A','V'),
> -AV_CODEC_ID_TIMED_ID3 = MKBETAG('T','I','D','3'),
> -AV_CODEC_ID_BIN_DATA = MKBETAG('D','A','T','A'),
> +AV_CODEC_ID_BINTEXT = MKBETAG('B','T','X','T'),
> +AV_CODEC_ID_XBIN= MKBETAG('X','B','I','N'),
> +AV_CODEC_ID_IDF = MKBETAG( 0 ,'I','D','F'),
> +AV_CODEC_ID_OTF = MKBETAG( 0 ,'O','T','F'),
> +AV_CODEC_ID_SMPTE_KLV = MKBETAG('K','L','V','A'),
> +AV_CODEC_ID_SMPTE_KLV_SYNC = MKBETAG('K','L','V','S'),
> +AV_CODEC_ID_DVD_NAV = MKBETAG('D','N','A','V'),
> +AV_CODEC_ID_TIMED_ID3 = MKBETAG('T','I','D','3'),
> +AV_CODEC_ID_BIN_DATA= MKBETAG('D','A','T','A'),
>
>
> AV_CODEC_ID_PROBE = 0x19000, ///< codec_id is not known (like
> AV_CODEC_ID_NONE) but lavf should attempt to identify it
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 9e9728b..5cad936 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2706,6 +2706,12 @@ static const AVCodecDescriptor codec_descriptors[] = {
> .long_name = NULL_IF_CONFIG_SMALL("SMPTE 336M Key-Length-Value (KLV)
> metadata"),
> },
> {
> +.id= AV_CODEC_ID_SMPTE_KLV_SYNC,
> +.type = AVMEDIA_TYPE_DATA,
> +.name = "klvSync",
> +.long_name = NULL_IF_CONFIG_SMALL("SMPTE 336M Key-Length-Value (KLV)
> synchronous metadata"),
> +},
Is a new CODEC_ID really neccessary here?
The SMPTE 336M KLV data structures are the same regardless of how it is muxed.
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index a118689..6633801 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -694,12 +694,14 @@ static const StreamType REGD_types[] = {
> { MKTAG('D', 'T', 'S', '3'), AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_DTS },
> { MKTAG('H', 'E', 'V', 'C'), AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC },
> { MKTAG('K', 'L', 'V', 'A'), AVMEDIA_TYPE_DATA, AV_CODEC_ID_SMPTE_KLV },
> +{ MKTAG('K', 'L', 'V', 'S'), AVMEDIA_TYPE_DATA,
> AV_CODEC_ID_SMPTE_KLV_SYNC },
What is 'KLVS'? This is not in STANAG 4609.
> { MKTAG('V', 'C', '-', '1'), AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_VC1 },
> { 0 },
> };
> +if (st->codec->codec_id == AV_CODEC_ID_SMPTE_KLV_SYNC) {
Hmm. It looks like you are using the CODEC_ID to decide if the KLV packets
should be muxed synchronously.
IMHO, this should be controlled by an AVOption
add comment here like 'Begin metadata_descriptor'
> +*q++ = 0x26;
> +*q++ = 0x09;
> +*q++ = 0x01;
> +*q++ = 0x00;
this is a 16-bit field. use AV_WB16. Add comment 'metadata_application_format'
> +*q++ = 0xFF;
> +*q++ = 'K';
> +*q++ = 'L';
> +*q++ = 'V';
> +*q++ = 'A';
> +*q++ = 0x00;
> +*q++ = 0x0f;
add comment here 'Begin metadata_std_descriptor'
> +*q++ = 0x27;
> +*q++ = 0x09;
> +*q++ = 0xC0;
> +*q++ = 0x00;
> +*q++ = 0x00;//0x04;
// add comment. what do those 0x00's mean
> +*q++ = 0xC0;
> +*q++ = 0x00;
> +*q++ = 0x00;//0x01;
// add comment
> +*q++ = 0xC0;
> +*q++ = 0x00;
> +*q++ = 0x00;
// add comment
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] oggdec: fix invalid free on error
The read_packet callback passes a pointer to a stack-allocated AVPacket. Attempting to free it with av_free() makes no sense. --- Found by looking at the code; there's no sample file. --- libavformat/oggdec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c index f17393b..8f146e4 100644 --- a/libavformat/oggdec.c +++ b/libavformat/oggdec.c @@ -817,7 +817,6 @@ retry: return psize; fail: av_free_packet(pkt); -av_free(pkt); return AVERROR(ENOMEM); } -- 2.1.0.rc1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add SUP/PGS subtitle demuxer
---
Reverse engineered by looking at Petri Hintukainen's muxer patch, and
also the mkvmerge sources. Tested with files extracted by mkvextract
only (does someone have better samples?). No idea if a parser would be
required for correct remuxing, but at least for decoding with lavc it
probably isn't be needed, going by how pgssubdec.c is structured.
At least files produced by mkvextract have the DTS always set to 0.
I don't know whether 0 means "invalid value", or whether DTS should
just always be discarded. (Actually setting the 0 DTS breaks seeking.)
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/supdec.c | 92
3 files changed, 94 insertions(+)
create mode 100644 libavformat/supdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3d124fb..b4965fe 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -405,6 +405,7 @@ OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
OBJS-$(CONFIG_STR_DEMUXER) += psxstr.o
OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
+OBJS-$(CONFIG_SUP_DEMUXER) += supdec.o
OBJS-$(CONFIG_SWF_DEMUXER) += swfdec.o swf.o
OBJS-$(CONFIG_SWF_MUXER) += swfenc.o swf.o
OBJS-$(CONFIG_TAK_DEMUXER) += takdec.o apetag.o img2.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 8f70c4b..e6c0e5f 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -280,6 +280,7 @@ void av_register_all(void)
REGISTER_DEMUXER (STR, str);
REGISTER_DEMUXER (SUBVIEWER1, subviewer1);
REGISTER_DEMUXER (SUBVIEWER,subviewer);
+REGISTER_DEMUXER (SUP, sup);
REGISTER_MUXDEMUX(SWF, swf);
REGISTER_DEMUXER (TAK, tak);
REGISTER_MUXER (TEE, tee);
diff --git a/libavformat/supdec.c b/libavformat/supdec.c
new file mode 100644
index 000..1938b06
--- /dev/null
+++ b/libavformat/supdec.c
@@ -0,0 +1,92 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define SUP_PGS_MAGIC 0x5047 /* "PG", big endian */
+
+static int sup_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codec->codec_type = AVMEDIA_TYPE_SUBTITLE;
+st->codec->codec_id = AV_CODEC_ID_HDMV_PGS_SUBTITLE;
+avpriv_set_pts_info(st, 32, 1, 9);
+
+return 0;
+}
+
+static int sup_read_packet(struct AVFormatContext *s, AVPacket *pkt)
+{
+char tmp[3];
+size_t len;
+int64_t pts, pos;
+int ret;
+
+pos = avio_tell(s->pb);
+
+if (avio_rb16(s->pb) != SUP_PGS_MAGIC)
+return avio_feof(s->pb) ? AVERROR_EOF : AVERROR_INVALIDDATA;
+
+pts = avio_rb32(s->pb);
+avio_rb32(s->pb); /* discard DTS (usually 0, and useless) */
+
+// The packet-size is stored as part of the packet.
+if ((ret = avio_read(s->pb, tmp, 3)) < 0)
+return ret;
+
+len = AV_RB16(tmp + 1);
+
+if ((ret = av_new_packet(pkt, len + 3)) < 0)
+return ret;
+
+memcpy(pkt->data, tmp, 3);
+
+if ((ret = avio_read(s->pb, pkt->data + 3, len)) < 0) {
+av_free_packet(pkt);
+return ret;
+}
+
+pkt->stream_index = 0;
+pkt->flags |= AV_PKT_FLAG_KEY;
+pkt->pos = pos;
+pkt->pts = pts;
+
+return 0;
+}
+
+static int sup_probe(AVProbeData *p)
+{
+if (p->buf_size < 2 || memcmp(p->buf, "PG", 2))
+return 0;
+return AVPROBE_SCORE_EXTENSION;
+}
+
+AVInputFormat ff_sup_demuxer = {
+.name = "sup",
+.long_name = NULL_IF_CONFIG_SMALL("raw HDMV Presentation Graphic
Stream subtitles"),
+.extensions = "sup",
+.mime_type = "application/x-pgs",
+.read_probe = sup_probe,
+.read_header= sup_read_header,
+.read_packet= sup_read_packet,
+.flags = AVFMT_GENERIC_INDEX,
+};
--
2.1.0.rc1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/li
Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings
Le tridi 13 fructidor, an CCXXII, Stefano Sabatini a écrit : > Unless there is an error in the code, a tail length of 6 bytes should > never be reached. > > > Furthermore, the function is capable of decoding the full UTF-8 range, up to > > (1<<31)-1, and that takes 6 octets. > > There is a separate check in the function: Sorry, I missed the fact that tail_len does not count the initial octet. The assert should be ok then. > I believe overlong encodings are illegal, and thus should be never > accepted. As you wish, a flag can be added later anyway if the default is to reject. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings
On date Saturday 2014-08-30 15:06:14 +0200, Nicolas George encoded: > Le tridi 13 fructidor, an CCXXII, Stefano Sabatini a écrit : > > It is mathematically impossible that the length will be larger than 5. > > Added an assert for that though, alternatively I could add a check. > > In ffprobe, the function is used with values coming directly from the file's > metadata: an assert is not acceptable in this case. Unless there is an error in the code, a tail length of 6 bytes should never be reached. > Furthermore, the function is capable of decoding the full UTF-8 range, up to > (1<<31)-1, and that takes 6 octets. There is a separate check in the function: if (code > 0x10 && !(flags & AV_UTF8_FLAG_ACCEPT_INVALID_BIG_CODES)) ret = AVERROR(EILSEQ); > Also, I suspect checking for overlong encodings could have a flag just like > the other extraneous checks below. I believe overlong encodings are illegal, and thus should be never accepted. -- FFmpeg = Formidable and Free Mastering Political Evil Gorilla ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings
Le tridi 13 fructidor, an CCXXII, Stefano Sabatini a écrit : > It is mathematically impossible that the length will be larger than 5. > Added an assert for that though, alternatively I could add a check. In ffprobe, the function is used with values coming directly from the file's metadata: an assert is not acceptable in this case. Furthermore, the function is capable of decoding the full UTF-8 range, up to (1<<31)-1, and that takes 6 octets. Also, I suspect checking for overlong encodings could have a flag just like the other extraneous checks below. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavu/avstring: check for overlong encodings
On date Friday 2014-08-29 15:57:32 +0200, wm4 encoded:
> On Thu, 28 Aug 2014 17:39:27 +0200
> Stefano Sabatini wrote:
>
> > Fix reopened trac ticket #1163.
> > ---
> > libavutil/avstring.c | 13 -
> > 1 file changed, 12 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/avstring.c b/libavutil/avstring.c
> > index a63fb84..df27d5e 100644
> > --- a/libavutil/avstring.c
> > +++ b/libavutil/avstring.c
> > @@ -331,7 +331,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t
> > **bufp, const uint8_t *buf_end,
> > const uint8_t *p = *bufp;
> > uint32_t top;
> > uint64_t code;
> > -int ret = 0;
> > +int ret = 0, tail_len;
> > +uint32_t overlong_encoding_mins[6] = {
> > +0x, 0x0080, 0x0800, 0x0001, 0x0020,
> > 0x0400,
> > +};
> >
> > if (p >= buf_end)
> > return 0;
> > @@ -346,8 +349,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t
> > **bufp, const uint8_t *buf_end,
> > }
> > top = (code & 128) >> 1;
> >
> > +tail_len = 0;
> > while (code & top) {
> > int tmp;
> > +tail_len++;
> > if (p >= buf_end) {
> > (*bufp) ++;
> > return AVERROR(EILSEQ); /* incomplete sequence */
> > @@ -364,6 +369,12 @@ int av_utf8_decode(int32_t *codep, const uint8_t
> > **bufp, const uint8_t *buf_end,
> > }
> > code &= (top << 1) - 1;
> >
> > +/* check for overlong encodings */
> > +if (code < overlong_encoding_mins[tail_len]) {
> > +ret = AVERROR(EILSEQ);
> > +goto end;
> > +}
> > +
> > if (code >= 1<<31) {
> > ret = AVERROR(EILSEQ); /* out-of-range value */
> > goto end;
>
> Looks ok and simple to me. Is there a guarantee tail_len never
> becomes larger than 5?
It is mathematically impossible that the length will be larger than 5.
Added an assert for that though, alternatively I could add a check.
>
> Also note that libavcodec/utils.c contains the same check (but less
> readable) in utf8_check().
--
FFmpeg = Faithful Fundamentalist Most Power Enhancing Goblin
>From 75db7cc2ea2b7b12e611b7b3fd103aee4f707dde Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Thu, 28 Aug 2014 17:37:27 +0200
Subject: [PATCH] lavu/avstring: check for overlong encodings
Fix reopened trac ticket #1163.
---
libavutil/avstring.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index a63fb84..fd010e4 100644
--- a/libavutil/avstring.c
+++ b/libavutil/avstring.c
@@ -27,6 +27,7 @@
#include "config.h"
#include "common.h"
#include "mem.h"
+#include "avassert.h"
#include "avstring.h"
#include "bprint.h"
@@ -331,7 +332,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
const uint8_t *p = *bufp;
uint32_t top;
uint64_t code;
-int ret = 0;
+int ret = 0, tail_len;
+uint32_t overlong_encoding_mins[6] = {
+0x, 0x0080, 0x0800, 0x0001, 0x0020, 0x0400,
+};
if (p >= buf_end)
return 0;
@@ -346,8 +350,10 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
}
top = (code & 128) >> 1;
+tail_len = 0;
while (code & top) {
int tmp;
+tail_len++;
if (p >= buf_end) {
(*bufp) ++;
return AVERROR(EILSEQ); /* incomplete sequence */
@@ -364,6 +370,13 @@ int av_utf8_decode(int32_t *codep, const uint8_t **bufp, const uint8_t *buf_end,
}
code &= (top << 1) - 1;
+/* check for overlong encodings */
+av_assert0(tail_len <= 5);
+if (code < overlong_encoding_mins[tail_len]) {
+ret = AVERROR(EILSEQ);
+goto end;
+}
+
if (code >= 1<<31) {
ret = AVERROR(EILSEQ); /* out-of-range value */
goto end;
--
1.8.3.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
On Sat, Aug 30, 2014 at 01:13:56PM +0200, Christophe Gisquet wrote: > Hi, > > 2014-08-24 18:56 GMT+02:00 Michael Niedermayer : > > aggree, a PRORES_PROFILE_AUTO seems like a good idea > > with it mismatching profile and pixel format can be errors while > > by default the profile can be selected based on the pixel format > > The attached patch makes it selects either or HQ profile > depending on whether there's an alpha channel. If a profile is > selected that does not have alpha but the input data has alpha, it > warns that it will not encode it. > > Best regards, > -- > Christophe > proresenc_kostya.c | 21 +++-- > 1 file changed, 19 insertions(+), 2 deletions(-) > cf627c08cf26aa889a17ded6b3e9684115eec296 > 0001-proresenc_ks-allow-auto-selecting-profile.patch > From 0b134da9eba4f6f08422d22a1a0428f564fe8f11 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Mon, 18 Aug 2014 11:27:50 +0200 > Subject: [PATCH] proresenc_ks: allow auto-selecting profile > > The user may not know how to select the profile, nor what he needs, in > particular to encode alpha. > > Therefore, use an automatic selection as default, and warn when the > manually selected profile may cause issues. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data types
On Sat, Aug 30, 2014 at 01:31:04PM +0200, Paul B Mahol wrote:
> On 8/30/14, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/vp3data.h | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
> > index 427827b..da31f6d 100644
> > --- a/libavcodec/vp3data.h
> > +++ b/libavcodec/vp3data.h
> > @@ -26,7 +26,7 @@
> >
> > /* these coefficients dequantize intraframe Y plane coefficients
> > * (note: same as JPEG) */
> > -static const int16_t vp31_intra_y_dequant[64] = {
> > +static const int8_t vp31_intra_y_dequant[64] = {
> > 16, 11, 10, 16, 24, 40, 51, 61,
> > 12, 12, 14, 19, 26, 58, 60, 55,
> > 14, 13, 16, 24, 40, 57, 69, 56,
> > @@ -39,7 +39,7 @@ static const int16_t vp31_intra_y_dequant[64] = {
> >
> > /* these coefficients dequantize intraframe C plane coefficients
> > * (note: same as JPEG) */
> > -static const int16_t vp31_intra_c_dequant[64] = {
> > +static const int8_t vp31_intra_c_dequant[64] = {
> > 17, 18, 24, 47, 99, 99, 99, 99,
> > 18, 21, 26, 66, 99, 99, 99, 99,
> > 24, 26, 56, 99, 99, 99, 99, 99,
> > @@ -51,7 +51,7 @@ static const int16_t vp31_intra_c_dequant[64] = {
> > };
> >
> > /* these coefficients dequantize interframe coefficients (all planes) */
> > -static const int16_t vp31_inter_dequant[64] = {
> > +static const int8_t vp31_inter_dequant[64] = {
> > 16, 16, 16, 20, 24, 28, 32, 40,
> > 16, 16, 20, 24, 28, 32, 40, 48,
> > 16, 20, 24, 28, 32, 40, 48, 64,
> > @@ -62,7 +62,7 @@ static const int16_t vp31_inter_dequant[64] = {
> > 40, 48, 64, 64, 64, 96, 128, 128
> > };
> >
> > -static const int16_t vp31_dc_scale_factor[64] = {
> > +static const uint8_t vp31_dc_scale_factor[64] = {
> > 220, 200, 190, 180, 170, 170, 160, 160,
> > 150, 150, 140, 140, 130, 130, 120, 120,
> > 110, 110, 100, 100, 90, 90, 90, 80,
> > @@ -176,7 +176,7 @@ static const uint8_t motion_vector_vlc_table[63][2] = {
> > { 0xFC, 8 }, { 0xFD, 8 }, { 0xFE, 8 }, { 0xFF, 8 }
> > };
> >
> > -static const int motion_vector_table[63] = {
> > +static const int8_t motion_vector_table[63] = {
> > 0, 1, -1,
> > 2, -2,
> > 3, -3,
> > @@ -198,21 +198,21 @@ static const int8_t fixed_motion_vector_table[64] = {
> > };
> >
> > /* only tokens 0..6 indicate eob runs */
> > -static const int eob_run_base[7] = {
> > +static const uint8_t eob_run_base[7] = {
> > 1, 2, 3, 4, 8, 16, 0
> > };
> > -static const int eob_run_get_bits[7] = {
> > +static const uint8_t eob_run_get_bits[7] = {
> > 0, 0, 0, 2, 3, 4, 12
> > };
> >
> > -static const int zero_run_base[32] = {
> > +static const uint8_t zero_run_base[32] = {
> > 0, 0, 0, 0, 0, 0, 0, /* 0..6 are never used */
> > 0, 0, /* 7..8 */
> > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
> > 1, 2, 3, 4, 5, /* 23..27 */
> > 6, 10, 1, 2 /* 28..31 */
> > };
> > -static const int zero_run_get_bits[32] = {
> > +static const uint8_t zero_run_get_bits[32] = {
> > 0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
> > 3, 6, /* 7..8 */
> > 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
> > @@ -220,7 +220,7 @@ static const int zero_run_get_bits[32] = {
> > 2, 3, 0, 1 /* 28..31 */
> > };
> >
> > -static const int coeff_get_bits[32] = {
> > +static const uint8_t coeff_get_bits[32] = {
> > 0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
> > 0, 0, 0, 0, 0, 0, /* 7..12 use constant coeffs */
> > 1, 1, 1, 1, /* 13..16 are constants but still need sign bit
> > */
> > --
> > 1.7.9.5
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> lgtm
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/vp3data: use more compact data types
On 8/30/14, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp3data.h | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/vp3data.h b/libavcodec/vp3data.h
> index 427827b..da31f6d 100644
> --- a/libavcodec/vp3data.h
> +++ b/libavcodec/vp3data.h
> @@ -26,7 +26,7 @@
>
> /* these coefficients dequantize intraframe Y plane coefficients
> * (note: same as JPEG) */
> -static const int16_t vp31_intra_y_dequant[64] = {
> +static const int8_t vp31_intra_y_dequant[64] = {
> 16, 11, 10, 16, 24, 40, 51, 61,
> 12, 12, 14, 19, 26, 58, 60, 55,
> 14, 13, 16, 24, 40, 57, 69, 56,
> @@ -39,7 +39,7 @@ static const int16_t vp31_intra_y_dequant[64] = {
>
> /* these coefficients dequantize intraframe C plane coefficients
> * (note: same as JPEG) */
> -static const int16_t vp31_intra_c_dequant[64] = {
> +static const int8_t vp31_intra_c_dequant[64] = {
> 17, 18, 24, 47, 99, 99, 99, 99,
> 18, 21, 26, 66, 99, 99, 99, 99,
> 24, 26, 56, 99, 99, 99, 99, 99,
> @@ -51,7 +51,7 @@ static const int16_t vp31_intra_c_dequant[64] = {
> };
>
> /* these coefficients dequantize interframe coefficients (all planes) */
> -static const int16_t vp31_inter_dequant[64] = {
> +static const int8_t vp31_inter_dequant[64] = {
> 16, 16, 16, 20, 24, 28, 32, 40,
> 16, 16, 20, 24, 28, 32, 40, 48,
> 16, 20, 24, 28, 32, 40, 48, 64,
> @@ -62,7 +62,7 @@ static const int16_t vp31_inter_dequant[64] = {
> 40, 48, 64, 64, 64, 96, 128, 128
> };
>
> -static const int16_t vp31_dc_scale_factor[64] = {
> +static const uint8_t vp31_dc_scale_factor[64] = {
> 220, 200, 190, 180, 170, 170, 160, 160,
> 150, 150, 140, 140, 130, 130, 120, 120,
> 110, 110, 100, 100, 90, 90, 90, 80,
> @@ -176,7 +176,7 @@ static const uint8_t motion_vector_vlc_table[63][2] = {
> { 0xFC, 8 }, { 0xFD, 8 }, { 0xFE, 8 }, { 0xFF, 8 }
> };
>
> -static const int motion_vector_table[63] = {
> +static const int8_t motion_vector_table[63] = {
> 0, 1, -1,
> 2, -2,
> 3, -3,
> @@ -198,21 +198,21 @@ static const int8_t fixed_motion_vector_table[64] = {
> };
>
> /* only tokens 0..6 indicate eob runs */
> -static const int eob_run_base[7] = {
> +static const uint8_t eob_run_base[7] = {
> 1, 2, 3, 4, 8, 16, 0
> };
> -static const int eob_run_get_bits[7] = {
> +static const uint8_t eob_run_get_bits[7] = {
> 0, 0, 0, 2, 3, 4, 12
> };
>
> -static const int zero_run_base[32] = {
> +static const uint8_t zero_run_base[32] = {
> 0, 0, 0, 0, 0, 0, 0, /* 0..6 are never used */
> 0, 0, /* 7..8 */
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
> 1, 2, 3, 4, 5, /* 23..27 */
> 6, 10, 1, 2 /* 28..31 */
> };
> -static const int zero_run_get_bits[32] = {
> +static const uint8_t zero_run_get_bits[32] = {
> 0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
> 3, 6, /* 7..8 */
> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, /* 9..22 */
> @@ -220,7 +220,7 @@ static const int zero_run_get_bits[32] = {
> 2, 3, 0, 1 /* 28..31 */
> };
>
> -static const int coeff_get_bits[32] = {
> +static const uint8_t coeff_get_bits[32] = {
> 0, 0, 0, 0, 0, 0, 0,/* 0..6 are never used */
> 0, 0, 0, 0, 0, 0, /* 7..12 use constant coeffs */
> 1, 1, 1, 1, /* 13..16 are constants but still need sign bit
> */
> --
> 1.7.9.5
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] [PATCH] proresenc_kostya: warn/reject on incorrect profile
Hi,
2014-08-24 18:56 GMT+02:00 Michael Niedermayer :
> aggree, a PRORES_PROFILE_AUTO seems like a good idea
> with it mismatching profile and pixel format can be errors while
> by default the profile can be selected based on the pixel format
The attached patch makes it selects either or HQ profile
depending on whether there's an alpha channel. If a profile is
selected that does not have alpha but the input data has alpha, it
warns that it will not encode it.
Best regards,
--
Christophe
From 0b134da9eba4f6f08422d22a1a0428f564fe8f11 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Mon, 18 Aug 2014 11:27:50 +0200
Subject: [PATCH] proresenc_ks: allow auto-selecting profile
The user may not know how to select the profile, nor what he needs, in
particular to encode alpha.
Therefore, use an automatic selection as default, and warn when the
manually selected profile may cause issues.
---
libavcodec/proresenc_kostya.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/libavcodec/proresenc_kostya.c b/libavcodec/proresenc_kostya.c
index c30c9c0..cdeb917 100644
--- a/libavcodec/proresenc_kostya.c
+++ b/libavcodec/proresenc_kostya.c
@@ -40,6 +40,7 @@
#define MAX_PLANES 4
enum {
+PRORES_PROFILE_AUTO = -1,
PRORES_PROFILE_PROXY = 0,
PRORES_PROFILE_LT,
PRORES_PROFILE_STANDARD,
@@ -1146,7 +1147,21 @@ static av_cold int encode_init(AVCodecContext *avctx)
"there should be an integer power of two MBs per slice\n");
return AVERROR(EINVAL);
}
+if (ctx->profile == PRORES_PROFILE_AUTO) {
+ctx->profile = av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA
+ ? PRORES_PROFILE_ : PRORES_PROFILE_HQ;
+av_log(avctx, AV_LOG_INFO, "Autoselected %s. It can be overriden "
+ "through -profile option.\n", ctx->profile == PRORES_PROFILE_
+ ? "4:4:4:4 profile because of the alpha channel"
+ : "HQ profile to keep best quality");
+}
if (av_pix_fmt_desc_get(avctx->pix_fmt)->flags & AV_PIX_FMT_FLAG_ALPHA) {
+if (ctx->profile != PRORES_PROFILE_) {
+// force alpha and warn
+av_log(avctx, AV_LOG_WARNING, "Profile selected will not "
+ "encode alpha. Override with -profile if needed.\n");
+ctx->alpha_bits = 0;
+}
if (ctx->alpha_bits & 7) {
av_log(avctx, AV_LOG_ERROR, "alpha bits should be 0, 8 or 16\n");
return AVERROR(EINVAL);
@@ -1280,8 +1295,10 @@ static const AVOption options[] = {
{ "mbs_per_slice", "macroblocks per slice", OFFSET(mbs_per_slice),
AV_OPT_TYPE_INT, { .i64 = 8 }, 1, MAX_MBS_PER_SLICE, VE },
{ "profile", NULL, OFFSET(profile), AV_OPT_TYPE_INT,
-{ .i64 = PRORES_PROFILE_STANDARD },
-PRORES_PROFILE_PROXY, PRORES_PROFILE_, VE, "profile" },
+{ .i64 = PRORES_PROFILE_AUTO },
+PRORES_PROFILE_AUTO, PRORES_PROFILE_, VE, "profile" },
+{ "auto", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_AUTO },
+0, 0, VE, "profile" },
{ "proxy", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_PROXY },
0, 0, VE, "profile" },
{ "lt",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = PRORES_PROFILE_LT },
--
1.9.2.msysgit.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/rtpdec_qt: add cast to silence "discards const qualifier from pointer target type" warning
Signed-off-by: Michael Niedermayer --- libavformat/rtpdec_qt.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/rtpdec_qt.c b/libavformat/rtpdec_qt.c index ee8a48a..58253b6 100644 --- a/libavformat/rtpdec_qt.c +++ b/libavformat/rtpdec_qt.c @@ -71,7 +71,7 @@ static int qt_rtp_parse_packet(AVFormatContext *s, PayloadContext *qt, * http://developer.apple.com/quicktime/icefloe/dispatch026.html */ init_get_bits(&gb, buf, len << 3); -ffio_init_context(&pb, buf, len, 0, NULL, NULL, NULL, NULL); +ffio_init_context(&pb, (uint8_t*)buf, len, 0, NULL, NULL, NULL, NULL); if (len < 4) return AVERROR_INVALIDDATA; -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] delete the old segment file from hls list
On August 30, 2014 8:57:12 AM IST, Steven Liu wrote:
>
>On Aug 28, 2014, at 4:52 AM, Anshul wrote:
>
>> On August 22, 2014 8:01:20 AM IST, Steven Liu
> wrote:
>>> repost new patch:
>>>
>>> when update the hls m3u8 list, the old file is not unlinked
>>> this patch can do this operation
>>> delete the old ts segment which not show in m3u8,
>>> use hls_sync_list.
>>>
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavformat/hlsenc.c | 15 ++-
>>> 1 files changed, 14 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> index 11f1e5b..fc1063e 100644
>>> --- a/libavformat/hlsenc.c
>>> +++ b/libavformat/hlsenc.c
>>> @@ -30,6 +30,10 @@
>>>
>>> #include "avformat.h"
>>> #include "internal.h"
>>> +#if HAVE_UNISTD_H
>>> +#include
>>> +#endif
>>> +
>>>
>>> typedef struct HLSSegment {
>>>char filename[1024];
>>> @@ -50,6 +54,7 @@ typedef struct HLSContext {
>>>float time;// Set by a private option.
>>>int max_nb_segments; // Set by a private option.
>>>int wrap; // Set by a private option.
>>> +int sync_list;
>>>
>>>int64_t recording_time;
>>>int has_video;
>>> @@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
>>> static int hls_append_segment(HLSContext *hls, double duration)
>>> {
>>>HLSSegment *en = av_malloc(sizeof(*en));
>>> +int ret = 0;
>>>
>>>if (!en)
>>>return AVERROR(ENOMEM);
>>> @@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls,
>>> double
>>> duration)
>>> if (hls->max_nb_segments && hls->nb_entries >= hls->max_nb_segments)
>{
>>>en = hls->segments;
>>>hls->segments = en->next;
>>> -av_free(en);
>>> +if (hls->sync_list) {
>>> +ret = unlink(en->filename);
>>> +if (ret < 0) {
>>> +av_log(hls->avf, AV_LOG_WARNING, "remove %s
>failed\n",
>>> en->filename);
>>> +}
>>> +}
>>> +av_free(en);
>>>} else
>>>hls->nb_entries++;
>>>
>>> @@ -340,6 +352,7 @@ static const AVOption options[] = {
>>>{"hls_list_size", "set maximum number of playlist entries",
>>> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
>>> INT_MAX,
>>> E},
>>>{"hls_wrap", "set number after which the index wraps",
>>> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
>>>{"hls_base_url", "url to prepend to each playlist entry",
>>> OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>>> +{"hls_sync_list", "remove old ts segment for sync the file with
>>> the
>>> m3u8 list", OFFSET(sync_list),AV_OPT_TYPE_INT,{.i64 = 0},
>
>>> 0,
>>> INT_MAX, E},
>>>{ NULL },
>>> };
>>>
>>> --
>>> 1.7.1
>>>
>>>
>>>
>>> 2014-08-21 16:51 GMT+08:00 Steven Liu :
>>>
Hi Stefano,
if unistd is not available under Linux,
it will output error message when compile the source code.
[root@testrtmp ffmpeg]# make
CC libavformat/hlsenc.o
libavformat/hlsenc.c: In function ‘hls_append_segment’:
libavformat/hlsenc.c:125: error: implicit declaration of function
>>> ‘unlink’
make: *** [libavformat/hlsenc.o] Error 1
[root@testrtmp ffmpeg]#
the follow is the new patch:
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 11f1e5b..fc1063e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -30,6 +30,10 @@
#include "avformat.h"
#include "internal.h"
+#if HAVE_UNISTD_H
+#include
+#endif
+
typedef struct HLSSegment {
char filename[1024];
@@ -50,6 +54,7 @@ typedef struct HLSContext {
float time;// Set by a private option.
int max_nb_segments; // Set by a private option.
int wrap; // Set by a private option.
+int sync_list;// Set by a private option.
int64_t recording_time;
int has_video;
@@ -96,6 +101,7 @@ static int hls_mux_init(AVFormatContext *s)
static int hls_append_segment(HLSContext *hls, double duration)
{
HLSSegment *en = av_malloc(sizeof(*en));
+ int ret = 0;
if (!en)
return AVERROR(ENOMEM);
@@ -115,7 +121,13 @@ static int hls_append_segment(HLSContext *hls,
>>> double
duration)
if (hls->max_nb_segments && hls->nb_entries >=
>>> hls->max_nb_segments) {
en = hls->segments;
hls->segments = en->next;
-av_free(en);
+if (hls->sync_list) {
+ret = unlink(en->filename);
+if (ret < 0) {
+av_log(hls->avf, AV_LOG_WARNING, "remove %s
>>> failed\n",
en->filename);
+}
+}
+ av_free(en);
} else
hls->nb_entries++;
@@ -340,6 +352,7 @@ static const AVOption o
Re: [FFmpeg-devel] [PATCH] Fix MSVC warnings about possible value truncation.
On Fri, 29 Aug 2014 15:52:25 -0700 Peter Kasting wrote: > On Fri, Aug 29, 2014 at 3:48 PM, Carl Eugen Hoyos wrote: > > > Peter Kasting google.com> writes: > > > > > The attached patch fixes instances of MSVC warning > > > C4244 about possible value truncation (e.g. when > > > assigning double to float or int64_t to int). > > > This warning is currently disabled in Chromium's > > > MSVC build and > > > > > I'm trying to enable it. > > > > Why? > > Did you find an actual issue? > > > Yes, this warning can catch (and has caught, in Chromium) real bugs, where > the compiler automatically truncated a value where the developer did not > intend to do so. In general, places that trigger it are worth being > concerned about. Littering the code with casts doesn't seem like a very good idea. I'd expect it rather to hide bugs than to expose them. For example, it could make a static analyzer with value range analysis stop working, because the casts will basically throw a wrench into its algorithm. > A couple of the places in this patch marked with "!!!" looked like > potential bugs to me. I'm not familiar enough with FFMPEG code to be > certain. This is why I'm asking reviewers not to rubber-stamp the changes > here; even changes that simply make explicit the casts the compiler was > previously doing implicitly may actually be incorrect behavior that should > be fixed. > > PK > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Symbian port
On Fri, Aug 29, 2014 at 01:21:32PM -0800, Lou Logan wrote: [...] > ffmpeg-user is not for help involving forks, scripts, counterfeits, or > other third-party tools. Only FFmpeg tools are supported. Please refrain from such comment. gas-pp is a project mostly (entirely?) maintained by the people from the Libav project, and no FFmpeg developers seems to be actively working on it. We just mirror it here: https://github.com/FFmpeg/gas-preprocessor/commits/master While ffmpeg-devel will not welcome such question, ffmpeg-user is an appropriate place. -- Clément B. pgplvWlW0kQhc.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Clean up if filter initialisation failed
Le tridi 13 fructidor, an CCXXII, Carl Eugen Hoyos a écrit :
> Attached patch fixes a memleak with ffmpeg if the filter initialisation
> fails,
> fixes ticket #3858 for me.
>
> Please review, Carl Eugen
> diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
> index b6dc42f..7acff28 100644
> --- a/ffmpeg_filter.c
> +++ b/ffmpeg_filter.c
> @@ -898,8 +898,11 @@ int configure_filtergraph(FilterGraph *fg)
> init_input_filter(fg, cur);
>
> for (cur = inputs, i = 0; cur; cur = cur->next, i++)
> -if ((ret = configure_input_filter(fg, fg->inputs[i], cur)) < 0)
> +if ((ret = configure_input_filter(fg, fg->inputs[i], cur)) < 0) {
> +avfilter_inout_free(&inputs);
> +avfilter_inout_free(&outputs);
> return ret;
> +}
> avfilter_inout_free(&inputs);
>
> if (!init || simple) {
Looks right.
Please mention in the commit short message that it is about the command-line
tools and not the library; maybe "ffmpeg: clean up if...".
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
