Re: [FFmpeg-devel] [PATCH 2/2] Move AVSubtitle from lavc to lavu
On Sun, 14 Dec 2014 16:47:44 +0100 Clément Bœsch wrote: > --- > doc/APIchanges | 5 +++ > libavcodec/avcodec.h | 63 +++--- > libavcodec/utils.c | 29 +++--- > libavcodec/version.h | 3 ++ > libavutil/Makefile | 2 + > libavutil/subtitle.c | 62 + > libavutil/subtitle.h | 107 > +++ > 7 files changed, 191 insertions(+), 80 deletions(-) > create mode 100644 libavutil/subtitle.c > create mode 100644 libavutil/subtitle.h > > diff --git a/doc/APIchanges b/doc/APIchanges > index ba7eae1..989794a 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -15,6 +15,11 @@ libavutil: 2014-08-09 > > API changes, most recent first: > > +2014-12-xx - xxx - lavc 56.16.100 / lavu 54.17.100 - lavc/avcodec.h > lavu/picture.h > + Move AVSubtitle definition from libavcodec to libavutil and add > + av_subtitle_*() functions which should be used instead of stack allocation > + and the now deprecated avsubtitle_free(). > + "should"? Can this requirement be lifted/delayed until there's actually a reason to do so? At that point, the struct should probably be renamed, to avoid turning valid code into subtly broken code merely by adding API compatible implementation details. > 2014-12-xx - xxx - lavc 56.15.100 / lavu 54.16.100 - lavc/avcodec.h > lavu/picture.h >Move AVPicture definition from libavcodec to libavutil. This should be >transparent API and ABI wise. > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h > index 2c1918d..6ded06b 100644 > --- a/libavcodec/avcodec.h > +++ b/libavcodec/avcodec.h > @@ -40,6 +40,7 @@ > #include "libavutil/picture.h" > #include "libavutil/pixfmt.h" > #include "libavutil/rational.h" > +#include "libavutil/subtitle.h" > > #include "version.h" > > @@ -3149,8 +3150,6 @@ typedef struct AVProfile { > > typedef struct AVCodecDefault AVCodecDefault; > > -struct AVSubtitle; > - > /** > * AVCodec. > */ > @@ -3401,61 +3400,6 @@ typedef struct AVHWAccel { > * @} > */ > > -enum AVSubtitleType { > -SUBTITLE_NONE, > - > -SUBTITLE_BITMAP,///< A bitmap, pict will be set > - > -/** > - * Plain text, the text field must be set by the decoder and is > - * authoritative. ass and pict fields may contain approximations. > - */ > -SUBTITLE_TEXT, > - > -/** > - * Formatted text, the ass field must be set by the decoder and is > - * authoritative. pict and text fields may contain approximations. > - */ > -SUBTITLE_ASS, > -}; > - > -#define AV_SUBTITLE_FLAG_FORCED 0x0001 > - > -typedef struct AVSubtitleRect { > -int x; ///< top left corner of pict, undefined when pict is not > set > -int y; ///< top left corner of pict, undefined when pict is not > set > -int w; ///< widthof pict, undefined when pict is not > set > -int h; ///< height of pict, undefined when pict is not > set > -int nb_colors; ///< number of colors in pict, undefined when pict is not > set > - > -/** > - * data+linesize for the bitmap of this subtitle. > - * can be set for text/ass as well once they are rendered > - */ > -AVPicture pict; > -enum AVSubtitleType type; > - > -char *text; ///< 0 terminated plain UTF-8 text > - > -/** > - * 0 terminated ASS/SSA compatible event line. > - * The presentation of this is unaffected by the other values in this > - * struct. > - */ > -char *ass; > - > -int flags; > -} AVSubtitleRect; > - > -typedef struct AVSubtitle { > -uint16_t format; /* 0 = graphics */ > -uint32_t start_display_time; /* relative to packet pts, in ms */ > -uint32_t end_display_time; /* relative to packet pts, in ms */ > -unsigned num_rects; > -AVSubtitleRect **rects; > -int64_t pts;///< Same as packet pts, in AV_TIME_BASE > -} AVSubtitle; > - > /** > * If c is NULL, returns the first registered codec, > * if c is non-NULL, returns the next registered codec after c, > @@ -3652,12 +3596,17 @@ int avcodec_open2(AVCodecContext *avctx, const > AVCodec *codec, AVDictionary **op > */ > int avcodec_close(AVCodecContext *avctx); > > +#if FF_API_AVSUBTITLE > /** > * Free all allocated data in the given subtitle struct. > + * @deprecated use av_subtitle_*() functions (the immediate equivalent of > + * avsubtitle_free() is av_subtitle_clear()) > * > * @param sub AVSubtitle to free. > */ > +attribute_deprecated > void avsubtitle_free(AVSubtitle *sub); > +#endif > > /** > * @} > diff --git a/libavcodec/utils.c b/libavcodec/utils.c > index db79b67..dc0c1ec 100644 > --- a/libavcodec/utils.c > +++ b/libavcodec/utils.c > @@ -39,6 +39,7 @@ > #include "libavutil/pixdesc.h" > #include "libavutil/imgutils.h" > #include "libavutil/samplefmt.h" > +#include "libavutil/subtitle.h" > #incl
Re: [FFmpeg-devel] [PATCH 2/2] Move AVSubtitle from lavc to lavu
On Mon, Dec 15, 2014 at 10:23:33AM +0100, wm4 wrote: > On Sun, 14 Dec 2014 16:47:44 +0100 > Clément Bœsch wrote: > > > --- > > doc/APIchanges | 5 +++ > > libavcodec/avcodec.h | 63 +++--- > > libavcodec/utils.c | 29 +++--- > > libavcodec/version.h | 3 ++ > > libavutil/Makefile | 2 + > > libavutil/subtitle.c | 62 + > > libavutil/subtitle.h | 107 > > +++ > > 7 files changed, 191 insertions(+), 80 deletions(-) > > create mode 100644 libavutil/subtitle.c > > create mode 100644 libavutil/subtitle.h > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > index ba7eae1..989794a 100644 > > --- a/doc/APIchanges > > +++ b/doc/APIchanges > > @@ -15,6 +15,11 @@ libavutil: 2014-08-09 > > > > API changes, most recent first: > > > > +2014-12-xx - xxx - lavc 56.16.100 / lavu 54.17.100 - lavc/avcodec.h > > lavu/picture.h > > + Move AVSubtitle definition from libavcodec to libavutil and add > > + av_subtitle_*() functions which should be used instead of stack > > allocation > > + and the now deprecated avsubtitle_free(). > > + > > "should"? > > Can this requirement be lifted/delayed until there's actually a reason > to do so? The structure is unchanged for now, so yeah it's "should" (as a prevention for the future). I don't plan to add a field that soon, but it's highly recommended. Maybe I can change the "should" into "must" and saying that for now it has no impact, but will in the future. > At that point, the struct should probably be renamed, to > avoid turning valid code into subtly broken code merely by adding API > compatible implementation details. There are actually 2 changes in this code, and maybe I should split. But basically the addition of the functions is kind of unrelated to the move. It's just a security for us for later, when we will be willing to add a field (if we ever do). We should have created these functions a long time ago, but the fact that AVSubtitle actually belong into libavutil prevented us from doing it: basically, if we had added these helpers, the move to libavutil would have been way more complicated (moving a structure definition is way easier than moving a structure definition AND its functions). [...] -- Clément B. pgpj3ghzFfVGU.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Move AVSubtitle from lavc to lavu
On Mon, 15 Dec 2014 10:38:01 +0100 Clément Bœsch wrote: > On Mon, Dec 15, 2014 at 10:23:33AM +0100, wm4 wrote: > > On Sun, 14 Dec 2014 16:47:44 +0100 > > Clément Bœsch wrote: > > > > > --- > > > doc/APIchanges | 5 +++ > > > libavcodec/avcodec.h | 63 +++--- > > > libavcodec/utils.c | 29 +++--- > > > libavcodec/version.h | 3 ++ > > > libavutil/Makefile | 2 + > > > libavutil/subtitle.c | 62 + > > > libavutil/subtitle.h | 107 > > > +++ > > > 7 files changed, 191 insertions(+), 80 deletions(-) > > > create mode 100644 libavutil/subtitle.c > > > create mode 100644 libavutil/subtitle.h > > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > > index ba7eae1..989794a 100644 > > > --- a/doc/APIchanges > > > +++ b/doc/APIchanges > > > @@ -15,6 +15,11 @@ libavutil: 2014-08-09 > > > > > > API changes, most recent first: > > > > > > +2014-12-xx - xxx - lavc 56.16.100 / lavu 54.17.100 - lavc/avcodec.h > > > lavu/picture.h > > > + Move AVSubtitle definition from libavcodec to libavutil and add > > > + av_subtitle_*() functions which should be used instead of stack > > > allocation > > > + and the now deprecated avsubtitle_free(). > > > + > > > > "should"? > > > > Can this requirement be lifted/delayed until there's actually a reason > > to do so? > > The structure is unchanged for now, so yeah it's "should" (as a prevention > for the future). I don't plan to add a field that soon, but it's highly > recommended. Maybe I can change the "should" into "must" and saying that > for now it has no impact, but will in the future. > > > At that point, the struct should probably be renamed, to > > avoid turning valid code into subtly broken code merely by adding API > > compatible implementation details. > > There are actually 2 changes in this code, and maybe I should split. But > basically the addition of the functions is kind of unrelated to the move. > It's just a security for us for later, when we will be willing to add a > field (if we ever do). > > We should have created these functions a long time ago, but the fact that > AVSubtitle actually belong into libavutil prevented us from doing it: > basically, if we had added these helpers, the move to libavutil would have > been way more complicated (moving a structure definition is way easier > than moving a structure definition AND its functions). > > [...] > My point is: barely anyone (applications) will notice this API change. It will go unnoticed, or there will be no perceived need to update the code. And then when you actually extend this stuff, you will start breaking application code that worked before. This is how it always goes. Even ffmpeg.org still links tutorials based on ancient practices that over time became invalid, but everyone keeps doing it because it still appears to work (but crashes in slightly different situations). So I think such "implicit" changes should be avoided. If the API breaks, make sure applications using the old assumptions won't compile. (There are various ways to achieve this goal; I'm just saying that it should be a goal.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] wavdec: RIFX file format support
This fixes ticket #1978. From: Thomas Volkert --- Changelog | 1 + libavformat/act.c | 2 +- libavformat/asfdec.c | 2 +- libavformat/avidec.c | 2 +- libavformat/dxa.c | 2 +- libavformat/matroskadec.c | 2 +- libavformat/mlvdec.c | 2 +- libavformat/mov.c | 2 +- libavformat/riff.h| 2 +- libavformat/riffdec.c | 20 -- libavformat/version.h | 2 +- libavformat/wavdec.c | 53 +-- libavformat/wtvdec.c | 2 +- libavformat/xwma.c| 2 +- 14 files changed, 67 insertions(+), 29 deletions(-) diff --git a/Changelog b/Changelog index 4c122c4..20341d3 100644 --- a/Changelog +++ b/Changelog @@ -3,6 +3,7 @@ releases are sorted from youngest to oldest. version : - nvenc encoder +- RIFX format for *.wav files version 2.5: diff --git a/libavformat/act.c b/libavformat/act.c index 3f223d5..7b6b840 100644 --- a/libavformat/act.c +++ b/libavformat/act.c @@ -75,7 +75,7 @@ static int read_header(AVFormatContext *s) avio_skip(pb, 16); size=avio_rl32(pb); -ff_get_wav_header(pb, st->codec, size); +ff_get_wav_header(pb, st->codec, size, 0); /* 8000Hz (Fine-rec) file format has 10 bytes long diff --git a/libavformat/asfdec.c b/libavformat/asfdec.c index 7f7bb4d..79a255f 100644 --- a/libavformat/asfdec.c +++ b/libavformat/asfdec.c @@ -423,7 +423,7 @@ static int asf_read_stream_properties(AVFormatContext *s, int64_t size) st->codec->codec_type = type; if (type == AVMEDIA_TYPE_AUDIO) { -int ret = ff_get_wav_header(pb, st->codec, type_specific_size); +int ret = ff_get_wav_header(pb, st->codec, type_specific_size, 0); if (ret < 0) return ret; if (is_dvr_ms_audio) { diff --git a/libavformat/avidec.c b/libavformat/avidec.c index a8318ff..a6ef76b 100644 --- a/libavformat/avidec.c +++ b/libavformat/avidec.c @@ -794,7 +794,7 @@ static int avi_read_header(AVFormatContext *s) //avio_skip(pb, size - 5 * 4); break; case AVMEDIA_TYPE_AUDIO: -ret = ff_get_wav_header(pb, st->codec, size); +ret = ff_get_wav_header(pb, st->codec, size, 0); if (ret < 0) return ret; ast->dshow_block_align = st->codec->block_align; diff --git a/libavformat/dxa.c b/libavformat/dxa.c index 6ad1c9f..9da2ffd 100644 --- a/libavformat/dxa.c +++ b/libavformat/dxa.c @@ -106,7 +106,7 @@ static int dxa_read_header(AVFormatContext *s) ast = avformat_new_stream(s, NULL); if (!ast) return AVERROR(ENOMEM); -ret = ff_get_wav_header(pb, ast->codec, fsize); +ret = ff_get_wav_header(pb, ast->codec, fsize, 0); if (ret < 0) return ret; if (ast->codec->sample_rate > 0) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index 9c476c1..bdc9c5f 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -1715,7 +1715,7 @@ static int matroska_parse_tracks(AVFormatContext *s) ffio_init_context(&b, track->codec_priv.data, track->codec_priv.size, 0, NULL, NULL, NULL, NULL); -ret = ff_get_wav_header(&b, st->codec, track->codec_priv.size); +ret = ff_get_wav_header(&b, st->codec, track->codec_priv.size, 0); if (ret < 0) return ret; codec_id = st->codec->codec_id; diff --git a/libavformat/mlvdec.c b/libavformat/mlvdec.c index 17bdb17..06ea7b3 100644 --- a/libavformat/mlvdec.c +++ b/libavformat/mlvdec.c @@ -142,7 +142,7 @@ static int scan_file(AVFormatContext *avctx, AVStream *vst, AVStream *ast, int f vst->codec->codec_tag = MKTAG('B', 'I', 'T', 16); size -= 164; } else if (ast && type == MKTAG('W', 'A', 'V', 'I') && size >= 16) { -ret = ff_get_wav_header(pb, ast->codec, 16); +ret = ff_get_wav_header(pb, ast->codec, 16, 0); if (ret < 0) return ret; size -= 16; diff --git a/libavformat/mov.c b/libavformat/mov.c index 939296a..6357b79 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -714,7 +714,7 @@ static int mov_read_wfex(MOVContext *c, AVIOContext *pb, MOVAtom atom) return 0; st = c->fc->streams[c->fc->nb_streams-1]; -if ((ret = ff_get_wav_header(pb, st->codec, atom.size)) < 0) +if ((ret = ff_get_wav_header(pb, st->codec, atom.size, 0)) < 0) av_log(c->fc, AV_LOG_WARNING, "get_wav_header failed\n"); return ret; diff --git a/libavformat/riff.h b/libavformat/riff.h index e925634..15b07a6 100644 --- a/libavformat/riff.h +++ b/libavformat/riff.h @@ -62,7 +62,7 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc, const AVCodecTag *t int ff_put_wav_header(AVIO
Re: [FFmpeg-devel] [PATCH] wavdec: RIFX file format support
Thomas Volkert gmx.net> writes: > +#include This will hopefully be unneeded. > codec->sample_rate = avio_rl32(pb); > codec->bit_rate= avio_rl32(pb) * 8; > codec->block_align = avio_rl16(pb); > +if (big_endian) { > +id = ntohs(id); > +codec->channels= ntohs(codec->channels); > +codec->sample_rate = ntohl(codec->sample_rate); > +codec->bit_rate= ntohl(codec->bit_rate / 8) * 8; > +codec->block_align = ntohs(codec->block_align); > +} Instead please do: if (big_endian) { id = avio_rb32(pb); codec->channels = avio_rb32(pb); ... } else { id = avio_rl32(pb); ... } If you do not reindent the little endian block, the patch gets much easier to read. > +if(!big_endian) > +codec->bits_per_coded_sample = avio_rl16(pb); > +else > +codec->bits_per_coded_sample = ntohs(avio_rl16(pb)); avio_rb32(pb) and please add braces around if - else blocks. > if (size >= 18) { /* We're obviously dealing with WAVEFORMATEX */ > +if (big_endian) > +avpriv_report_missing_feature(codec, > "WAVEFORMATEX support for RIFX files\n"); Is this sufficient, no further error handling needed? > +if (!big_endian) > +return avio_rl32(pb); > +else > +return ntohl(avio_rl32(pb)); avio_rb32() and braces. > -if (!memcmp(p->buf, "RIFF", 4)) > +if ((!memcmp(p->buf, "RIFF", 4)) || (!memcmp(p->buf, "RIFX", 4))) Maybe I misread but this looks like too many parentheses. > -int rf64; > +int rf64 = 0; Should be unneeded. > -/* check RIFF header */ > -tag = avio_rl32(pb); nit: You could not remove the variable and do a switch (tag) below to make the patch smaller. (Smaller patch == easier review, both now and in the future) > +wav->rifx = 0; Should be unneeded. One line looked to me as if it contained a tab, use tools/patcheck to check your patch before submitting. Thank you! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
arwa arif gmail.com> writes: > > > +DECLARE_ALIGNED (8, uint64_t, ff_MM_FIX_0_541196100)= > > > FIX64(0.541196100, 14); > > > +DECLARE_ALIGNED (8, uint64_t, ff_MM_FIX_0_707106781)= > > > FIX64(0.707106781, 14); > > > > these 2 conflict with the existing fspp filter, they > > should be removed from one to avoid that conflict > > > > If I try to remove this, I am getting compilation errors. Do not remove them from your new file, but replace them in libmpcodecs/vf_fspp.c with extern declarations: extern uint64_t ff_MM_FIX_0_707106781; Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Move AVSubtitle from lavc to lavu
On Mon, Dec 15, 2014 at 10:49:47AM +0100, wm4 wrote: > On Mon, 15 Dec 2014 10:38:01 +0100 > Clément Bœsch wrote: > > > On Mon, Dec 15, 2014 at 10:23:33AM +0100, wm4 wrote: > > > On Sun, 14 Dec 2014 16:47:44 +0100 > > > Clément Bœsch wrote: > > > > > > > --- > > > > doc/APIchanges | 5 +++ > > > > libavcodec/avcodec.h | 63 +++--- > > > > libavcodec/utils.c | 29 +++--- > > > > libavcodec/version.h | 3 ++ > > > > libavutil/Makefile | 2 + > > > > libavutil/subtitle.c | 62 + > > > > libavutil/subtitle.h | 107 > > > > +++ > > > > 7 files changed, 191 insertions(+), 80 deletions(-) > > > > create mode 100644 libavutil/subtitle.c > > > > create mode 100644 libavutil/subtitle.h > > > > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > > > index ba7eae1..989794a 100644 > > > > --- a/doc/APIchanges > > > > +++ b/doc/APIchanges > > > > @@ -15,6 +15,11 @@ libavutil: 2014-08-09 > > > > > > > > API changes, most recent first: > > > > > > > > +2014-12-xx - xxx - lavc 56.16.100 / lavu 54.17.100 - > > > > lavc/avcodec.h lavu/picture.h > > > > + Move AVSubtitle definition from libavcodec to libavutil and add > > > > + av_subtitle_*() functions which should be used instead of stack > > > > allocation > > > > + and the now deprecated avsubtitle_free(). > > > > + > > > > > > "should"? > > > > > > Can this requirement be lifted/delayed until there's actually a reason > > > to do so? > > > > The structure is unchanged for now, so yeah it's "should" (as a prevention > > for the future). I don't plan to add a field that soon, but it's highly > > recommended. Maybe I can change the "should" into "must" and saying that > > for now it has no impact, but will in the future. > > > > > At that point, the struct should probably be renamed, to > > > avoid turning valid code into subtly broken code merely by adding API > > > compatible implementation details. > > > > There are actually 2 changes in this code, and maybe I should split. But > > basically the addition of the functions is kind of unrelated to the move. > > It's just a security for us for later, when we will be willing to add a > > field (if we ever do). > > > > We should have created these functions a long time ago, but the fact that > > AVSubtitle actually belong into libavutil prevented us from doing it: > > basically, if we had added these helpers, the move to libavutil would have > > been way more complicated (moving a structure definition is way easier > > than moving a structure definition AND its functions). > > > > [...] > > > > My point is: barely anyone (applications) will notice this API change. > It will go unnoticed, or there will be no perceived need to update the > code. And then when you actually extend this stuff, you will start > breaking application code that worked before. What do you suggest to make people notice the API change? Currently AVSubtitle has one single function, which I deprecated. So you think we should introduce a AVSubtitle2 into libavutil instead? I don't like that that much TBH, especially since it will require me to name the new functions av_subtitle2_* to make it consistent. [...] -- Clément B. pgpJJ3OY1BFc_.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] wavdec: RIFX file format support
On 12/15/2014 11:24 AM, Carl Eugen Hoyos wrote: Thomas Volkert gmx.net> writes: +#include This will hopefully be unneeded. Okay, this will simplify the patch. if (size >= 18) { /* We're obviously dealing with WAVEFORMATEX */ +if (big_endian) +avpriv_report_missing_feature(codec, "WAVEFORMATEX support for RIFX files\n"); Is this sufficient, no further error handling needed? I do not have an example file in RIFX format with WAVEFORMATEX. So, I concentrated on the usual file format. The sent patch does not influence the usual RIFF decoder but it extends it by a first support for big endian values. Maybe someone else can extend my patch with support for WAVEFORMATEX in the future. -if (!memcmp(p->buf, "RIFF", 4)) +if ((!memcmp(p->buf, "RIFF", 4)) || (!memcmp(p->buf, "RIFX", 4))) Maybe I misread but this looks like too many parentheses. The compiler would not accept the following construction: "if (!memcmp(p->buf, "RIFF", 4)) || (!memcmp(p->buf, "RIFX", 4))" -int rf64; +int rf64 = 0; Should be unneeded. In the previous version of the code, the variable rf64 was initialized in every case by the following: "rf64 = tag == MKTAG('R', 'F', '6', '4');" I simplified the code and replaced this with a default value, which gets overwritten, if the file header has RF64 format -/* check RIFF header */ -tag = avio_rl32(pb); nit: You could not remove the variable and do a switch (tag) below to make the patch smaller. (Smaller patch == easier review, both now and in the future) The variable "tag" is initialized by "size = next_tag(pb, &tag, wav->rifx);" before the following switch-case. +wav->rifx = 0; Should be unneeded. Okay, we can rely on the zero-initialization of the WAVDemuxContext structure. Best regards, Thomas. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] wavdec: RIFX file format support
Thomas Volkert gmx.net> writes: > >>if (size >= 18) { /* We're obviously dealing with WAVEFORMATEX > >> +if (big_endian) > >> +avpriv_report_missing_feature(codec, > >> "WAVEFORMATEX support for RIFX files\n"); > > Is this sufficient, no further error handling needed? > > I do not have an example file in RIFX format with > WAVEFORMATEX. So, I concentrated on the usual > file format. What I meant was: If this message is printed, shouldn't you return AVERROR_INVALIDDATA or AVERROR_PATCHWELCOME? > >> +if ((!memcmp(p->buf, "RIFF", 4)) || (!memcmp(p->buf, "RIFX", 4))) > > Maybe I misread but this looks like too many parentheses. > > The compiler would not accept the following construction: > "if (!memcmp(p->buf, "RIFF", 4)) || (!memcmp(p->buf, "RIFX", 4))" What about the following? if (!memcmp(p->buf, "RIFF", 4) || !memcmp(p->buf, "RIFX", 4)) > >> -int rf64; > >> +int rf64 = 0; > > Should be unneeded. > > In the previous version of the code, the variable > rf64 was initialized in every case by the following: > "rf64 = tag == MKTAG('R', 'F', '6', '4');" > I simplified the code and replaced this with a > default value, which gets overwritten, if the file > header has RF64 format My comment was wrong. > >> -/* check RIFF header */ > >> -tag = avio_rl32(pb); > > nit: You could not remove the variable and do a switch (tag) > > below to make the patch smaller. > > (Smaller patch == easier review, both now and in the future) > > The variable "tag" is initialized by > "size = next_tag(pb, &tag, wav->rifx);" before the > following switch-case. That's not how I read the code in question but I may miss something. > >> +wav->rifx = 0; > > Should be unneeded. > > Okay, we can rely on the zero-initialization of > the WAVDemuxContext structure. Yes, please do rely on the initialization. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] wavdec: RIFX file format support
On Mon, 15 Dec 2014 11:10:08 +0100 Thomas Volkert wrote: > +if (big_endian) { > +id = ntohs(id); > +codec->channels= ntohs(codec->channels); > +codec->sample_rate = ntohl(codec->sample_rate); > +codec->bit_rate= ntohl(codec->bit_rate / 8) * 8; > +codec->block_align = ntohs(codec->block_align); > +} there are other ways of converting BE to LE than ntoh* (sorry , i dont know which functions in ffmpeg do it, i am no programmer) -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] Move AVSubtitle from lavc to lavu
On Mon, 15 Dec 2014 11:38:58 +0100 Clément Bœsch wrote: > On Mon, Dec 15, 2014 at 10:49:47AM +0100, wm4 wrote: > > On Mon, 15 Dec 2014 10:38:01 +0100 > > Clément Bœsch wrote: > > > > > On Mon, Dec 15, 2014 at 10:23:33AM +0100, wm4 wrote: > > > > On Sun, 14 Dec 2014 16:47:44 +0100 > > > > Clément Bœsch wrote: > > > > > > > > > --- > > > > > doc/APIchanges | 5 +++ > > > > > libavcodec/avcodec.h | 63 +++--- > > > > > libavcodec/utils.c | 29 +++--- > > > > > libavcodec/version.h | 3 ++ > > > > > libavutil/Makefile | 2 + > > > > > libavutil/subtitle.c | 62 + > > > > > libavutil/subtitle.h | 107 > > > > > +++ > > > > > 7 files changed, 191 insertions(+), 80 deletions(-) > > > > > create mode 100644 libavutil/subtitle.c > > > > > create mode 100644 libavutil/subtitle.h > > > > > > > > > > diff --git a/doc/APIchanges b/doc/APIchanges > > > > > index ba7eae1..989794a 100644 > > > > > --- a/doc/APIchanges > > > > > +++ b/doc/APIchanges > > > > > @@ -15,6 +15,11 @@ libavutil: 2014-08-09 > > > > > > > > > > API changes, most recent first: > > > > > > > > > > +2014-12-xx - xxx - lavc 56.16.100 / lavu 54.17.100 - > > > > > lavc/avcodec.h lavu/picture.h > > > > > + Move AVSubtitle definition from libavcodec to libavutil and add > > > > > + av_subtitle_*() functions which should be used instead of stack > > > > > allocation > > > > > + and the now deprecated avsubtitle_free(). > > > > > + > > > > > > > > "should"? > > > > > > > > Can this requirement be lifted/delayed until there's actually a reason > > > > to do so? > > > > > > The structure is unchanged for now, so yeah it's "should" (as a prevention > > > for the future). I don't plan to add a field that soon, but it's highly > > > recommended. Maybe I can change the "should" into "must" and saying that > > > for now it has no impact, but will in the future. > > > > > > > At that point, the struct should probably be renamed, to > > > > avoid turning valid code into subtly broken code merely by adding API > > > > compatible implementation details. > > > > > > There are actually 2 changes in this code, and maybe I should split. But > > > basically the addition of the functions is kind of unrelated to the move. > > > It's just a security for us for later, when we will be willing to add a > > > field (if we ever do). > > > > > > We should have created these functions a long time ago, but the fact that > > > AVSubtitle actually belong into libavutil prevented us from doing it: > > > basically, if we had added these helpers, the move to libavutil would have > > > been way more complicated (moving a structure definition is way easier > > > than moving a structure definition AND its functions). > > > > > > [...] > > > > > > > My point is: barely anyone (applications) will notice this API change. > > It will go unnoticed, or there will be no perceived need to update the > > code. And then when you actually extend this stuff, you will start > > breaking application code that worked before. > > What do you suggest to make people notice the API change? Currently > AVSubtitle has one single function, which I deprecated. That could be ok. You can't use the current API without using avsubtitle_free(). (Although I'd still prefer something more "explicit".) The deprecated function must be completely removed as soon as using the new functions is mandatory. > So you think we should introduce a AVSubtitle2 into libavutil instead? I > don't like that that much TBH, especially since it will require me to name > the new functions av_subtitle2_* to make it consistent. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/alsa-audio-common: dont crash while closing not opened device
Le quintidi 25 frimaire, an CCXXIII, Lukasz Marek a écrit : > snd_pcm_close() doesn't handle NULL correctly. > > Signed-off-by: Lukasz Marek > --- > libavdevice/alsa-audio-common.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) I think it is ok, but can you explain the code path that leads to it? 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] lavfi: Port fspp to FFmpeg
Updated the patch. There was a comment in the original filter that mul_thrmat is faster in c. So, should mul_thrmat_mmx be included or not? From ad30ab016a4f2d98e9e979c1cebf3d950d10c156 Mon Sep 17 00:00:00 2001 From: Arwa Arif Date: Sun, 14 Dec 2014 12:03:31 +0530 Subject: [PATCH] Port fspp to FFmpeg --- doc/filters.texi | 24 + libavfilter/Makefile |1 + libavfilter/allfilters.c |1 + libavfilter/libmpcodecs/vf_fspp.c |4 +- libavfilter/version.h |2 +- libavfilter/vf_fspp.c | 395 +++ libavfilter/vf_fspp.h | 352 ++ libavfilter/x86/Makefile |1 + libavfilter/x86/vf_fspp.c | 1391 + 9 files changed, 2168 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_fspp.c create mode 100644 libavfilter/vf_fspp.h create mode 100644 libavfilter/x86/vf_fspp.c diff --git a/doc/filters.texi b/doc/filters.texi index 882caa0..eefc507 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -4997,6 +4997,30 @@ frei0r=perspective:0.2/0.2|0.8/0.2 For more information, see @url{http://frei0r.dyne.org} +@section fspp + +Faster version of the simple postprocessing filter - @ref{spp}. + +The filter accepts the following options: + +@table @option +@item quality +Set quality. This option defines the number of levels for averaging. It accepts +an integer in the range 0-5. If set to @code{0}, the filter will have no +effect. A value of @code{5} means the higher quality. For each increment of +that value the speed drops by a factor of approximately 2. Default value is +@code{4}. + +@item qp +Force a constant quantization parameter. If not set, the filter will use the QP +from the video stream (if available). + +@item use_bframe_qp +Enable the use of the QP from the B-Frames if set to @code{1}. Using this +option may cause flicker since the B-Frames have often larger QP. Default is +@code{0} (not enabled). +@end table + @section geq The filter accepts the following options: diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 6b7291e..8c523b4 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -125,6 +125,7 @@ OBJS-$(CONFIG_FRAMESTEP_FILTER) += vf_framestep.o OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o OBJS-$(CONFIG_FRAMEPACK_FILTER) += vf_framepack.o OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o +OBJS-$(CONFIG_FSPP_FILTER) += vf_fspp.o OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o dualinput.o framesync.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index adb86be..4a915c7 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -141,6 +141,7 @@ void avfilter_register_all(void) REGISTER_FILTER(FRAMEPACK, framepack, vf); REGISTER_FILTER(FRAMESTEP, framestep, vf); REGISTER_FILTER(FREI0R, frei0r, vf); +REGISTER_FILTER(FSPP, fspp, vf); REGISTER_FILTER(GEQ,geq,vf); REGISTER_FILTER(GRADFUN,gradfun,vf); REGISTER_FILTER(HALDCLUT, haldclut, vf); diff --git a/libavfilter/libmpcodecs/vf_fspp.c b/libavfilter/libmpcodecs/vf_fspp.c index d457859..3a80dc2 100644 --- a/libavfilter/libmpcodecs/vf_fspp.c +++ b/libavfilter/libmpcodecs/vf_fspp.c @@ -710,8 +710,8 @@ const vf_info_t ff_vf_info_fspp = { #if HAVE_MMX_INLINE DECLARE_ASM_CONST(8, uint64_t, MM_FIX_0_382683433)=FIX64(0.382683433, 14); -DECLARE_ALIGNED(8, uint64_t, ff_MM_FIX_0_541196100)=FIX64(0.541196100, 14); -DECLARE_ALIGNED(8, uint64_t, ff_MM_FIX_0_707106781)=FIX64(0.707106781, 14); +extern uint64_t ff_MM_FIX_0_707106781; +extern uint64_t ff_MM_FIX_0_541196100; DECLARE_ASM_CONST(8, uint64_t, MM_FIX_1_306562965)=FIX64(1.306562965, 14); DECLARE_ASM_CONST(8, uint64_t, MM_FIX_1_414213562_A)=FIX64(1.414213562, 14); diff --git a/libavfilter/version.h b/libavfilter/version.h index 4bd18f3..22e3706 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -31,7 +31,7 @@ #define LIBAVFILTER_VERSION_MAJOR 5 #define LIBAVFILTER_VERSION_MINOR 2 -#define LIBAVFILTER_VERSION_MICRO 104 +#define LIBAVFILTER_VERSION_MICRO 105 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ LIBAVFILTER_VERSION_MINOR, \ diff --git a/libavfilter/vf_fspp.c b/libavfilter/vf_fspp.c new file mode 100644 index 000..0163e87 --- /dev/null +++ b/libavfilter/vf_fspp.c @@ -0,0 +1,395 @@ +/* + * Copyright (c) 2003 Michael Niedermayer + * Copyright (C) 2005 Nikolaj Poroshin + * Copyright (c) 2014 Arwa Arif + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or modify + * it under the terms of the GN
Re: [FFmpeg-devel] [PATCH] configure: create the tests directory like the doc directory
On Sun, Dec 14, 2014 at 11:34:08PM -0800, Dave Yeo wrote: > On 12/14/14 07:42 PM, Michael Niedermayer wrote: > >This fixes an issue where the tests directory is not created for out of tree > >builds before its needed > > > >Signed-off-by: Michael Niedermayer > >--- > > configure |1 + > > 1 file changed, 1 insertion(+) > > > >diff --git a/configure b/configure > >index 0ec1a7c..3328026 100755 > >--- a/configure > >+++ b/configure > >@@ -5722,6 +5722,7 @@ enabled getenv || echo "#define getenv(x) NULL" >> > >$TMPH > > > > > > mkdir -p doc > >+mkdir -p tests > > echo "@c auto-generated by configure" > doc/config.texi > > > > print_config ARCH_ "$config_files" $ARCH_LIST > > > > Works fine here applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/alsa-audio-common: dont crash while closing not opened device
On 15 December 2014 at 13:05, Nicolas George wrote: > > Le quintidi 25 frimaire, an CCXXIII, Lukasz Marek a écrit : > > snd_pcm_close() doesn't handle NULL correctly. > > > > Signed-off-by: Lukasz Marek > > --- > > libavdevice/alsa-audio-common.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > I think it is ok, but can you explain the code path that leads to it? > for example ffmpeg -f alsa -i -f alsa aaa would crash if ffmpeg tried to close alsa after open fail. It doesn't so it doesn't occur. This commit also make safe to call close function twice on the same context ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/alsa-audio-common: dont crash while closing not opened device
Le quintidi 25 frimaire, an CCXXIII, Lukasz Marek a écrit : > for example > ffmpeg -f alsa -i -f alsa aaa > would crash if ffmpeg tried to close alsa after open fail. It doesn't so it > doesn't occur. > > This commit also make safe to call close function twice on the same context In that case, I am not sure if that is such a good idea. Applications should not be calling av_write_trailer() on unopened contexts, it is not a benign operation like free(). But I will not insist on it. 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] cmdutils: dont call read_header before listing devices
On Mon, Dec 15, 2014 at 12:36:49AM +0100, Lukasz Marek wrote: > On 15.12.2014 00:33, Lukasz Marek wrote: > >List device callback must be able to return valid list without opening > >device. > >This callback should return input values for open function, not vice-versa. > >Read header funtion is very likey to fail without proper configuration > >provided. > > > >Signed-off-by: Lukasz Marek > >--- > > cmdutils.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > >diff --git a/cmdutils.c b/cmdutils.c > >index 06ce5d5..51fd777 100644 > >--- a/cmdutils.c > >+++ b/cmdutils.c > >@@ -2069,9 +2069,8 @@ static int print_device_sources(AVInputFormat *fmt, > >AVDictionary *opts) > > goto fail; > > } > > > >-/* TODO: avformat_open_input calls read_header callback which is not > >necessary. > >- Function like avformat_alloc_output_context2 for input could > >be helpful here. */ > > av_dict_copy(&tmp_opts, opts, 0); > >+dev->flags |= AVFMT_FLAG_PRIV_OPT; > > if ((ret = avformat_open_input(&dev, NULL, fmt, &tmp_opts)) < 0) { > > printf("Cannot open device: %s.\n", fmt->name); > > goto fail; > > > > I forgot to amend. Updated patch attached. > cmdutils.c |8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > 8d012a5193b0440717f89d920661913ef160e674 > 0001-cmdutils-dont-call-read_header-before-listing-device.patch > From 332bb7456c498518ea72dfdaa0e8c3e76d383f21 Mon Sep 17 00:00:00 2001 > From: Lukasz Marek > Date: Mon, 15 Dec 2014 00:31:42 +0100 > Subject: [PATCH] cmdutils: dont call read_header before listing devices > > List device callback must be able to return valid list without opening device. > This callback should return input values for open function, not vice-versa. > Read header funtion is very likey to fail without proper configuration > provided. should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
arwa arif gmail.com> writes: > There was a comment in the original filter that > mul_thrmat is faster in c. So, should > mul_thrmat_mmx be included or not? Ideally, you would test yourself what is faster. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
On Mon, Dec 15, 2014 at 06:20:36PM +0530, arwa arif wrote: > Updated the patch. There was a comment in the original filter that > mul_thrmat is faster in c. So, should mul_thrmat_mmx be included or not? i dont know that code, where was that comment ? you could benchamrk it though by enclosing the code in START_TIMER / STOP_TIMER("some text") and comparing their speed [...] > +static int filter_frame(AVFilterLink *inlink, AVFrame *in) > +{ > +AVFilterContext *ctx = inlink->dst; > +FSPPContext *fspp = ctx->priv; > +AVFilterLink *outlink = ctx->outputs[0]; > +AVFrame *out = in; > + > +int qp_stride = 0; > +uint8_t *qp_table = NULL; > + > +/* if we are not in a constant user quantizer mode and we don't want to > use > + * the quantizers from the B-frames (B-frames often have a higher QP), we > + * need to save the qp table from the last non B-frame; this is what the > + * following code block does */ > +if (!fspp->qp) { > +qp_table = av_frame_get_qp_table(in, &qp_stride, &fspp->qscale_type); > + > +if (qp_table && !fspp->use_bframe_qp && in->pict_type != > AV_PICTURE_TYPE_B) { > +int w, h; > + > +/* if the qp stride is not set, it means the QP are only defined > on > + * a line basis */ > +if (!qp_stride) { > +w = FF_CEIL_RSHIFT(inlink->w, 4); > +h = 1; > +} else { > +w = FF_CEIL_RSHIFT(qp_stride, 4); > +h = FF_CEIL_RSHIFT(inlink->h, 4); > +} > +av_assert0(w * h <= fspp->non_b_qp_alloc_size); this assert fails with a simple ./ffplay matrixbench_mpeg2.mpg -vf fspp [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/concatdec: Handle NOPTS start_time
Fixes Ticket3598 Signed-off-by: Michael Niedermayer --- libavformat/concatdec.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c index a2584d7..253951a 100644 --- a/libavformat/concatdec.c +++ b/libavformat/concatdec.c @@ -512,9 +512,14 @@ static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt) av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base), av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base)); -delta = av_rescale_q(cat->cur_file->start_time - cat->avf->start_time, - AV_TIME_BASE_Q, - cat->avf->streams[pkt->stream_index]->time_base); +if (cat->avf->start_time == AV_NOPTS_VALUE) +delta = av_rescale_q(cat->cur_file->start_time, + AV_TIME_BASE_Q, + cat->avf->streams[pkt->stream_index]->time_base); +else +delta = av_rescale_q(cat->cur_file->start_time - cat->avf->start_time, + AV_TIME_BASE_Q, + cat->avf->streams[pkt->stream_index]->time_base); if (pkt->pts != AV_NOPTS_VALUE) pkt->pts += delta; if (pkt->dts != AV_NOPTS_VALUE) -- 1.7.9.5 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/avdct: support >8bit per sample dcts
On Fri, Dec 12, 2014 at 04:53:58PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/avdct.c |3 +++ > libavcodec/avdct.h |2 ++ > 2 files changed, 5 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_spp: support 10bit per sample
On Fri, Dec 12, 2014 at 04:53:59PM +0100, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_spp.c | 89 > -- > 1 file changed, 71 insertions(+), 18 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
This patch seems to be working. Sorry for the previous one. From 97d90c5a1a8c10a1b19a5250c90d02fb74e79735 Mon Sep 17 00:00:00 2001 From: Arwa Arif Date: Sun, 14 Dec 2014 12:03:31 +0530 Subject: [PATCH] Port fspp to FFmpeg --- doc/filters.texi | 24 + libavfilter/Makefile |1 + libavfilter/allfilters.c |1 + libavfilter/libmpcodecs/vf_fspp.c |4 +- libavfilter/version.h |2 +- libavfilter/vf_fspp.c | 400 +++ libavfilter/vf_fspp.h | 352 ++ libavfilter/x86/Makefile |1 + libavfilter/x86/vf_fspp.c | 1391 + 9 files changed, 2173 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_fspp.c create mode 100644 libavfilter/vf_fspp.h create mode 100644 libavfilter/x86/vf_fspp.c diff --git a/doc/filters.texi b/doc/filters.texi index 882caa0..eefc507 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -4997,6 +4997,30 @@ frei0r=perspective:0.2/0.2|0.8/0.2 For more information, see @url{http://frei0r.dyne.org} +@section fspp + +Faster version of the simple postprocessing filter - @ref{spp}. + +The filter accepts the following options: + +@table @option +@item quality +Set quality. This option defines the number of levels for averaging. It accepts +an integer in the range 0-5. If set to @code{0}, the filter will have no +effect. A value of @code{5} means the higher quality. For each increment of +that value the speed drops by a factor of approximately 2. Default value is +@code{4}. + +@item qp +Force a constant quantization parameter. If not set, the filter will use the QP +from the video stream (if available). + +@item use_bframe_qp +Enable the use of the QP from the B-Frames if set to @code{1}. Using this +option may cause flicker since the B-Frames have often larger QP. Default is +@code{0} (not enabled). +@end table + @section geq The filter accepts the following options: diff --git a/libavfilter/Makefile b/libavfilter/Makefile index 6b7291e..8c523b4 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -125,6 +125,7 @@ OBJS-$(CONFIG_FRAMESTEP_FILTER) += vf_framestep.o OBJS-$(CONFIG_FPS_FILTER)+= vf_fps.o OBJS-$(CONFIG_FRAMEPACK_FILTER) += vf_framepack.o OBJS-$(CONFIG_FREI0R_FILTER) += vf_frei0r.o +OBJS-$(CONFIG_FSPP_FILTER) += vf_fspp.o OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o dualinput.o framesync.o diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index adb86be..4a915c7 100644 --- a/libavfilter/allfilters.c +++ b/libavfilter/allfilters.c @@ -141,6 +141,7 @@ void avfilter_register_all(void) REGISTER_FILTER(FRAMEPACK, framepack, vf); REGISTER_FILTER(FRAMESTEP, framestep, vf); REGISTER_FILTER(FREI0R, frei0r, vf); +REGISTER_FILTER(FSPP, fspp, vf); REGISTER_FILTER(GEQ,geq,vf); REGISTER_FILTER(GRADFUN,gradfun,vf); REGISTER_FILTER(HALDCLUT, haldclut, vf); diff --git a/libavfilter/libmpcodecs/vf_fspp.c b/libavfilter/libmpcodecs/vf_fspp.c index d457859..3a80dc2 100644 --- a/libavfilter/libmpcodecs/vf_fspp.c +++ b/libavfilter/libmpcodecs/vf_fspp.c @@ -710,8 +710,8 @@ const vf_info_t ff_vf_info_fspp = { #if HAVE_MMX_INLINE DECLARE_ASM_CONST(8, uint64_t, MM_FIX_0_382683433)=FIX64(0.382683433, 14); -DECLARE_ALIGNED(8, uint64_t, ff_MM_FIX_0_541196100)=FIX64(0.541196100, 14); -DECLARE_ALIGNED(8, uint64_t, ff_MM_FIX_0_707106781)=FIX64(0.707106781, 14); +extern uint64_t ff_MM_FIX_0_707106781; +extern uint64_t ff_MM_FIX_0_541196100; DECLARE_ASM_CONST(8, uint64_t, MM_FIX_1_306562965)=FIX64(1.306562965, 14); DECLARE_ASM_CONST(8, uint64_t, MM_FIX_1_414213562_A)=FIX64(1.414213562, 14); diff --git a/libavfilter/version.h b/libavfilter/version.h index 4bd18f3..22e3706 100644 --- a/libavfilter/version.h +++ b/libavfilter/version.h @@ -31,7 +31,7 @@ #define LIBAVFILTER_VERSION_MAJOR 5 #define LIBAVFILTER_VERSION_MINOR 2 -#define LIBAVFILTER_VERSION_MICRO 104 +#define LIBAVFILTER_VERSION_MICRO 105 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \ LIBAVFILTER_VERSION_MINOR, \ diff --git a/libavfilter/vf_fspp.c b/libavfilter/vf_fspp.c new file mode 100644 index 000..50bd46b --- /dev/null +++ b/libavfilter/vf_fspp.c @@ -0,0 +1,400 @@ +/* + * Copyright (c) 2003 Michael Niedermayer + * Copyright (C) 2005 Nikolaj Poroshin + * Copyright (c) 2014 Arwa Arif + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; eithe
Re: [FFmpeg-devel] [PATCH] avformat/concatdec: Handle NOPTS start_time
Le quintidi 25 frimaire, an CCXXIII, Michael Niedermayer a écrit : > Lines: 36 > > Fixes Ticket3598 > > Signed-off-by: Michael Niedermayer > --- > libavformat/concatdec.c | 11 --- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c > index a2584d7..253951a 100644 > --- a/libavformat/concatdec.c > +++ b/libavformat/concatdec.c > @@ -512,9 +512,14 @@ static int concat_read_packet(AVFormatContext *avf, > AVPacket *pkt) > av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base), > av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base)); > > -delta = av_rescale_q(cat->cur_file->start_time - cat->avf->start_time, > - AV_TIME_BASE_Q, > - cat->avf->streams[pkt->stream_index]->time_base); > +if (cat->avf->start_time == AV_NOPTS_VALUE) > +delta = av_rescale_q(cat->cur_file->start_time, > + AV_TIME_BASE_Q, > + > cat->avf->streams[pkt->stream_index]->time_base); > +else > +delta = av_rescale_q(cat->cur_file->start_time - > cat->avf->start_time, > + AV_TIME_BASE_Q, > + > cat->avf->streams[pkt->stream_index]->time_base); > if (pkt->pts != AV_NOPTS_VALUE) > pkt->pts += delta; > if (pkt->dts != AV_NOPTS_VALUE) I am ok in principle, but I like it better written like [PATCH 1/2]: less code duplication, less changed lines. Also, I wonder if there is any disadvantage in [PATCH 2/2], which would fix this particular problem too. Please feel free to apply your version or any of my patches without waiting for me, but beware, neither was tested beyond a run of FATE, as I have little time right now. Regards, -- Nicolas George From 5379ff7c282b79dc455cf75f650655cf2da2d469 Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Mon, 15 Dec 2014 18:42:41 +0100 Subject: [PATCH 1/2] lavf/concatdec: handle NOPTS start_time. Fix trac ticket #3598. Signed-off-by: Nicolas George --- libavformat/concatdec.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c index a2584d7..e109524 100644 --- a/libavformat/concatdec.c +++ b/libavformat/concatdec.c @@ -478,7 +478,7 @@ static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt) { ConcatContext *cat = avf->priv_data; int ret; -int64_t delta; +int64_t file_start_time, delta; ConcatStream *cs; AVStream *st; @@ -512,7 +512,10 @@ static int concat_read_packet(AVFormatContext *avf, AVPacket *pkt) av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base), av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base)); -delta = av_rescale_q(cat->cur_file->start_time - cat->avf->start_time, +file_start_time = cat->avf->start_time; +if (file_start_time == AV_NOPTS_VALUE) +file_start_time = 0; +delta = av_rescale_q(cat->cur_file->start_time - file_start_time, AV_TIME_BASE_Q, cat->avf->streams[pkt->stream_index]->time_base); if (pkt->pts != AV_NOPTS_VALUE) -- 2.1.3 From 4d06c29ea18a7a7d43a7b13f370cdec3e90724d6 Mon Sep 17 00:00:00 2001 From: Nicolas George Date: Mon, 15 Dec 2014 18:45:44 +0100 Subject: [PATCH 2/2] lavf/wavdec: set start_time to 0. Signed-off-by: Nicolas George --- libavformat/wavdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c index 9c4e2df..f775ca9 100644 --- a/libavformat/wavdec.c +++ b/libavformat/wavdec.c @@ -136,6 +136,7 @@ static int wav_parse_fmt_tag(AVFormatContext *s, int64_t size, AVStream **st) (*st)->need_parsing = AVSTREAM_PARSE_FULL_RAW; avpriv_set_pts_info(*st, 64, 1, (*st)->codec->sample_rate); +(*st)->start_time = 0; return 0; } -- 2.1.3 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
arwa arif gmail.com> writes: > + * it under the terms of the GNU General Public License The configure part is missing that makes sure the filter is only compiled when --enable-gpl was used. > +DECLARE_ALIGNED(32, static const uint8_t, dither)[8][8] = { > +{ 0, 48, 12, 60, 3, 51, 15, 63, }, This does not belong in a header, only the declaration should be there, the actual data should be in a c file. Same for column_fidct_c(), row_idct_c() and row_fdct_c(). > +#if HAVE_MMX_INLINE I believe you can remove this line twice and just do (below): if (HAVE_MMX_INLINE && cpu_flags & AV_CPU_FLAG_MMX) { FFmpeg absolutely relies on dead code elimination. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/concatdec: Handle NOPTS start_time
On Mon, Dec 15, 2014 at 06:53:19PM +0100, Nicolas George wrote: > Le quintidi 25 frimaire, an CCXXIII, Michael Niedermayer a écrit : > > Lines: 36 > > > > Fixes Ticket3598 > > > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/concatdec.c | 11 --- > > 1 file changed, 8 insertions(+), 3 deletions(-) > > > > diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c > > index a2584d7..253951a 100644 > > --- a/libavformat/concatdec.c > > +++ b/libavformat/concatdec.c > > @@ -512,9 +512,14 @@ static int concat_read_packet(AVFormatContext *avf, > > AVPacket *pkt) > > av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base), > > av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base)); > > > > -delta = av_rescale_q(cat->cur_file->start_time - cat->avf->start_time, > > - AV_TIME_BASE_Q, > > - cat->avf->streams[pkt->stream_index]->time_base); > > +if (cat->avf->start_time == AV_NOPTS_VALUE) > > +delta = av_rescale_q(cat->cur_file->start_time, > > + AV_TIME_BASE_Q, > > + > > cat->avf->streams[pkt->stream_index]->time_base); > > +else > > +delta = av_rescale_q(cat->cur_file->start_time - > > cat->avf->start_time, > > + AV_TIME_BASE_Q, > > + > > cat->avf->streams[pkt->stream_index]->time_base); > > if (pkt->pts != AV_NOPTS_VALUE) > > pkt->pts += delta; > > if (pkt->dts != AV_NOPTS_VALUE) > > I am ok in principle, but I like it better written like [PATCH 1/2]: less > code duplication, less changed lines. applied > > Also, I wonder if there is any disadvantage in [PATCH 2/2], which would fix > this particular problem too. dunno thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] snow_dwt: Don't try and free members of non-existent arrays
If allocation fails earlier on, and thd next frame is processed, the slice buffer could be left in a state where line and data_stack have already been freed, or are otherwise null pointers. Signed-off-by: Derek Buitenhuis --- libavcodec/snow_dwt.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/libavcodec/snow_dwt.c b/libavcodec/snow_dwt.c index 5b890e0..986a6b9 100644 --- a/libavcodec/snow_dwt.c +++ b/libavcodec/snow_dwt.c @@ -91,6 +91,10 @@ void ff_slice_buffer_release(slice_buffer *buf, int line) void ff_slice_buffer_flush(slice_buffer *buf) { int i; + +if (!buf->line) +return; + for (i = 0; i < buf->line_count; i++) if (buf->line[i]) ff_slice_buffer_release(buf, i); @@ -101,8 +105,9 @@ void ff_slice_buffer_destroy(slice_buffer *buf) int i; ff_slice_buffer_flush(buf); -for (i = buf->data_count - 1; i >= 0; i--) -av_freep(&buf->data_stack[i]); +if (buf->data_stack) +for (i = buf->data_count - 1; i >= 0; i--) +av_freep(&buf->data_stack[i]); av_freep(&buf->data_stack); av_freep(&buf->line); } -- 2.1.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: added HLS encryption
On 12/12/14, 9:57 PM, "Michael Niedermayer" wrote: >combining the random seed with a LFG seems a bit odd >i would out of principle use something stronger, though i dont know >what the exact scenarios are this is intended to prevent, so maybe >its fine Yes, this is a good point. I will resubmit the patch with the IV optionally specified as part of the ³key_info_file² and leave IV generation outside of ffmpeg. Let me know you would like this done differently. Thanks, Christian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: added HLS encryption
Added HLS encryption with -hls_key_info_file option. The first line of key_info_file specifies the key URI for the playlist. The second line specifies the path to the file containing the encryption key. An optional third line specifies an IV to use instead of the segment number. Changes to key_info_file will be reflected in segment encryption along with an entry in the playlist for the new key URI and IV. Signed-off-by: Christian Suloway --- doc/muxers.texi | 9 ++ libavformat/hlsenc.c | 235 +-- 2 files changed, 238 insertions(+), 6 deletions(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index a1264d2..f2ecf8b 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -263,6 +263,15 @@ ffmpeg in.nut -hls_segment_filename 'file%03d.ts' out.m3u8 This example will produce the playlist, @file{out.m3u8}, and segment files: @file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc. +@item hls_key_info_file @var{file} +Use in the information in @var{file} for segment encryption. The first line of +@var{file} specifies the key URI for the playlist. The second line specifies +the path to the file containing the encryption key as a single packed array of +16 octets in binary format. The optional third line specifies a hexidecimal +string for the initialization vector (IV) to be used instead of the segment +number. Changes to @var{file} will result in segment encryption with the new +key/IV and an entry in the playlist for the new key URI/IV. + @item hls_flags single_file If this flag is set, the muxer will store all segments in a single MPEG-TS file, and will use byte ranges in the playlist. HLS playlists generated with diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 7645065..f62675e 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -37,12 +37,18 @@ #include "internal.h" #include "os_support.h" +#define BLOCKSIZE 16 + typedef struct HLSSegment { char filename[1024]; double duration; /* in seconds */ int64_t pos; int64_t size; +char *key_uri; +char *iv_string; +int attribute_iv; + struct HLSSegment *next; } HLSSegment; @@ -86,9 +92,23 @@ typedef struct HLSContext { char *format_options_str; AVDictionary *format_options; +char *key_info_file; +char *key_file; +char *key_uri; +char *key_string; +char *iv_string; +int attribute_iv; + AVIOContext *pb; } HLSContext; +static void hls_free_segment(HLSSegment *en) +{ + av_freep(&en->key_uri); + av_freep(&en->iv_string); + av_freep(&en); +} + static int hls_delete_old_segments(HLSContext *hls) { HLSSegment *segment, *previous_segment = NULL; @@ -145,7 +165,7 @@ static int hls_delete_old_segments(HLSContext *hls) { av_free(path); previous_segment = segment; segment = previous_segment->next; -av_free(previous_segment); +hls_free_segment(previous_segment); } fail: @@ -154,6 +174,134 @@ fail: return ret; } +static int hls_encryption_start(HLSContext *hls) +{ + +int ret = 0, i; +AVIOContext *pb = NULL, *dyn_buf = NULL; +uint8_t buf[1024], *tmp = NULL, *key = NULL, *iv = NULL; +char *p, *tstr, *saveptr = NULL, *key_string = NULL, *iv_string = NULL; + +if ((ret = avio_open(&pb, hls->key_info_file, AVIO_FLAG_READ)) < 0) { +av_log(hls, AV_LOG_ERROR, "error opening key info file %s\n", + hls->key_info_file); +goto fail; +} + +ret = avio_open_dyn_buf(&dyn_buf); +if (ret < 0) { +avio_closep(&pb); +goto fail; +} + +while ((ret = avio_read(pb, buf, sizeof(buf))) > 0) +avio_write(dyn_buf, buf, ret); +avio_closep(&pb); +if (ret != AVERROR_EOF && ret < 0) { +avio_close_dyn_buf(dyn_buf, &tmp); +goto fail; +} + +avio_w8(dyn_buf, 0); +if ((ret = avio_close_dyn_buf(dyn_buf, &tmp)) < 0) +goto fail; + +p = tmp; +if (!(tstr = av_strtok(p, "\n", &saveptr)) || !*tstr) { +av_log(hls, AV_LOG_ERROR, "no key URI specified in key info file %s\n", + hls->key_info_file); +ret = AVERROR(EINVAL); +goto fail; +} +av_free(hls->key_uri); +hls->key_uri = av_strdup(tstr); +if (!hls->key_uri) { +ret = AVERROR(ENOMEM); +goto fail; +} + +if (!(tstr = av_strtok(NULL, "\n", &saveptr)) || !*tstr) { +av_log(hls, AV_LOG_ERROR, "no key file specified in key info file %s\n", + hls->key_info_file); +ret = AVERROR(EINVAL); +goto fail; +} +av_free(hls->key_file); +hls->key_file = av_strdup(tstr); +if (!hls->key_file) { +ret = AVERROR(ENOMEM); +goto fail; +} + +if (tstr = av_strtok(NULL, "\n", &saveptr)) { +if (ff_hex_to_data(NULL, tstr) != BLOCKSIZE) { +av_log(hls, AV_LOG_ERROR, "invalid length fo
[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix hls_write_trailer() on hls_start() failure
Close segment I/O context and append segment in hls_write_trailer() only when segment I/O context is allocated. Signed-off-by: Christian Suloway --- libavformat/hlsenc.c | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 79f3a23..7645065 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -449,7 +449,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt) av_opt_set(hls->avf->priv_data, "mpegts_flags", "resend_headers", 0); hls->number++; } else { -avio_close(oc->pb); +avio_closep(&oc->pb); ret = hls_start(s); } @@ -474,10 +474,12 @@ static int hls_write_trailer(struct AVFormatContext *s) AVFormatContext *oc = hls->avf; av_write_trailer(oc); -hls->size = avio_tell(hls->avf->pb) - hls->start_pos; -avio_closep(&oc->pb); +if (oc->pb) { +hls->size = avio_tell(hls->avf->pb) - hls->start_pos; +avio_closep(&oc->pb); +hls_append_segment(hls, hls->duration, hls->start_pos, hls->size); +} av_free(hls->basename); -hls_append_segment(hls, hls->duration, hls->start_pos, hls->size); avformat_free_context(oc); hls->avf = NULL; hls_window(s, 1); -- 1.9.3 (Apple Git-50) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
On Mon, Dec 15, 2014 at 10:55:26PM +0530, arwa arif wrote: > This patch seems to be working. Sorry for the previous one. > doc/filters.texi | 24 > libavfilter/Makefile |1 > libavfilter/allfilters.c |1 > libavfilter/libmpcodecs/vf_fspp.c |4 > libavfilter/version.h |2 > libavfilter/vf_fspp.c | 400 ++ > libavfilter/vf_fspp.h | 352 + > libavfilter/x86/Makefile |1 > libavfilter/x86/vf_fspp.c | 1391 > ++ > 9 files changed, 2173 insertions(+), 3 deletions(-) > d945d17d2227a2628acbcba387267734c3914841 0001-Port-fspp-to-FFmpeg.patch > From 97d90c5a1a8c10a1b19a5250c90d02fb74e79735 Mon Sep 17 00:00:00 2001 > From: Arwa Arif > Date: Sun, 14 Dec 2014 12:03:31 +0530 > Subject: [PATCH] Port fspp to FFmpeg [...] > +if (fspp->log2_count && !ctx->is_disabled) { > +if (!fspp->use_bframe_qp && fspp->non_b_qp_table) > +qp_table = fspp->non_b_qp_table; > + > +if (qp_table || fspp->qp) { > + > +/* get a new frame if in-place is not possible or if the > dimensions > + * are not multiple of 8 */ > +if (!av_frame_is_writable(in) || (inlink->w & 7) || (inlink->h & > 7)) { > +const int aligned_w = FFALIGN(inlink->w, 8); > +const int aligned_h = FFALIGN(inlink->h, 8); > + > +out = ff_get_video_buffer(outlink, aligned_w, aligned_h); > +if (!out) { > +av_frame_free(&in); > +return AVERROR(ENOMEM); > +} > +av_frame_copy_props(out, in); > +out->width = in->width; > +out->height = in->height; > +} > + > +filter(fspp , out->data[0] , in->data[0] , out->linesize[0] , > in->linesize[0] , > + inlink->w , inlink->h , qp_table , qp_stride , 1); > +filter(fspp , out->data[1] , in->data[1] , out->linesize[1] , > in->linesize[1] , > + inlink->w , inlink->h , qp_table , qp_stride , 0); > +filter(fspp , out->data[2] , in->data[2] , out->linesize[2] , > in->linesize[2] , > + inlink->w , inlink->h , qp_table , qp_stride , 0); the 2 chroma planes are smaller than luma, thus "inlink->w , inlink->h" is wrong for them you can calculate the sizes of the chroma plane with log2_chroma_w and log2_chroma_h from av_pix_fmt_desc_get() see similar code in other filters [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] How to make the link.exe as MSVC's link
Hi All, I want to make MSVC build ffmpeg more easily. There is a problem, if we launch msys.bat which in mingw enviroment, the link.exe in msys will conflict with link.exe in MSVC. So I try to change the configure like this msvc) # Check whether the current MSVC version needs the C99 converter. # From MSVC 2013 (compiler major version 18) onwards, it does actually # support enough of C99 to build ffmpeg. Default to the new # behaviour if the regexp was unable to match anything, since this # successfully parses the version number of existing supported # versions that require the converter (MSVC 2010 and 2012). cl_major_ver=$(cl 2>&1 | sed -n 's/.*Version \([[:digit:]]\{1,\}\)\..*/\1/p') if [ -z "$cl_major_ver" ] || [ $cl_major_ver -ge 18 ]; then cc_default="cl" ld_default="/c/Program Files (x86)/Microsoft Visual Studio 12.0/VC/BIN/link.exe" else cc_default="c99wrap cl" ld_default="link" fi “VC/BIN/link.exe” only be used in X86, if it is x64 or arm, the path is different. But I found that, the cl and link.exe is in the same folder, so is there any way to get the cl path, and then modify the path with link’s path. Thanks all. Best regards, Jesse Sent from Windows Mail ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] How to make the link.exe as MSVC's link
On 12/16/2014 12:39 AM, Jesse Jiang wrote: > Hi All, > > > I want to make MSVC build ffmpeg more easily. There is a problem, if we > launch msys.bat which in mingw enviroment, the link.exe in msys will conflict > with link.exe in MSVC. This is covered in the documentation: http://ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows Look under notes. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] How to make the link.exe as MSVC's link
I know, but I want make it more easly. It will confusuon the beginer. Sent from Surface From: Derek Buitenhuis Sent: Tuesday, December 16, 2014 12:06 PM To: FFmpeg development discussions and patches On 12/16/2014 12:39 AM, Jesse Jiang wrote: > Hi All, > > > I want to make MSVC build ffmpeg more easily. There is a problem, if we > launch msys.bat which in mingw enviroment, the link.exe in msys will conflict > with link.exe in MSVC. This is covered in the documentation: http://ffmpeg.org/platform.html#Microsoft-Visual-C_002b_002b-or-Intel-C_002b_002b-Compiler-for-Windows Look under notes. - Derek ___ 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] snow_dwt: Don't try and free members of non-existent arrays
On Mon, Dec 15, 2014 at 10:57:28PM +, Derek Buitenhuis wrote: > If allocation fails earlier on, and thd next frame is processed, > the slice buffer could be left in a state where line and data_stack > have already been freed, or are otherwise null pointers. > > Signed-off-by: Derek Buitenhuis > --- > libavcodec/snow_dwt.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fix hls_write_trailer() on hls_start() failure
On Mon, Dec 15, 2014 at 06:10:46PM -0600, Christian Suloway wrote: > Close segment I/O context and append segment in hls_write_trailer() only > when segment I/O context is allocated. > > Signed-off-by: Christian Suloway > --- > libavformat/hlsenc.c | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] Move AVPicture definition from lavc to lavu
On Sun, Dec 14, 2014 at 04:47:43PM +0100, Clément Bœsch wrote: > This is necessary before moving AVSubtitle* structures. > --- > doc/APIchanges | 4 > libavcodec/avcodec.h | 25 ++--- > libavcodec/version.h | 2 +- > libavutil/Makefile | 1 + > libavutil/picture.h | 37 + > libavutil/version.h | 2 +- > 6 files changed, 46 insertions(+), 25 deletions(-) > create mode 100644 libavutil/picture.h LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi: Port fspp to FFmpeg
On Tue, Dec 16, 2014 at 6:06 AM, Michael Niedermayer wrote: > > On Mon, Dec 15, 2014 at 10:55:26PM +0530, arwa arif wrote: > > This patch seems to be working. Sorry for the previous one. > > > doc/filters.texi | 24 > > libavfilter/Makefile |1 > > libavfilter/allfilters.c |1 > > libavfilter/libmpcodecs/vf_fspp.c |4 > > libavfilter/version.h |2 > > libavfilter/vf_fspp.c | 400 ++ > > libavfilter/vf_fspp.h | 352 + > > libavfilter/x86/Makefile |1 > > libavfilter/x86/vf_fspp.c | 1391 > ++ > > 9 files changed, 2173 insertions(+), 3 deletions(-) > > d945d17d2227a2628acbcba387267734c3914841 0001-Port-fspp-to-FFmpeg.patch > > From 97d90c5a1a8c10a1b19a5250c90d02fb74e79735 Mon Sep 17 00:00:00 2001 > > From: Arwa Arif > > Date: Sun, 14 Dec 2014 12:03:31 +0530 > > Subject: [PATCH] Port fspp to FFmpeg > > [...] > > +if (fspp->log2_count && !ctx->is_disabled) { > > +if (!fspp->use_bframe_qp && fspp->non_b_qp_table) > > +qp_table = fspp->non_b_qp_table; > > + > > +if (qp_table || fspp->qp) { > > + > > +/* get a new frame if in-place is not possible or if the > dimensions > > + * are not multiple of 8 */ > > +if (!av_frame_is_writable(in) || (inlink->w & 7) || > (inlink->h & 7)) { > > +const int aligned_w = FFALIGN(inlink->w, 8); > > +const int aligned_h = FFALIGN(inlink->h, 8); > > + > > +out = ff_get_video_buffer(outlink, aligned_w, > aligned_h); > > +if (!out) { > > +av_frame_free(&in); > > +return AVERROR(ENOMEM); > > +} > > +av_frame_copy_props(out, in); > > +out->width = in->width; > > +out->height = in->height; > > +} > > + > > > +filter(fspp , out->data[0] , in->data[0] , out->linesize[0] > , in->linesize[0] , > > + inlink->w , inlink->h , qp_table , qp_stride , 1); > > > +filter(fspp , out->data[1] , in->data[1] , out->linesize[1] > , in->linesize[1] , > > + inlink->w , inlink->h , qp_table , qp_stride , 0); > > +filter(fspp , out->data[2] , in->data[2] , out->linesize[2] > , in->linesize[2] , > > + inlink->w , inlink->h , qp_table , qp_stride , 0); > > the 2 chroma planes are smaller than luma, thus > "inlink->w , inlink->h" is wrong for them > > you can calculate the sizes of the chroma plane with > log2_chroma_w and log2_chroma_h from av_pix_fmt_desc_get() > see similar code in other filters > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No human being will ever know the Truth, for even if they happen to say it > by chance, they would not even known they had done so. -- Xenophanes > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > From d17fd6e84ee1d20d498975f8de26fe963e2baa57 Mon Sep 17 00:00:00 2001 From: Arwa Arif Date: Sun, 14 Dec 2014 12:03:31 +0530 Subject: [PATCH] Port fspp to FFmpeg --- configure |1 + doc/filters.texi | 24 + libavfilter/Makefile |1 + libavfilter/allfilters.c |1 + libavfilter/libmpcodecs/vf_fspp.c |4 +- libavfilter/version.h |2 +- libavfilter/vf_fspp.c | 662 ++ libavfilter/vf_fspp.h | 95 +++ libavfilter/x86/Makefile |1 + libavfilter/x86/vf_fspp.c | 1397 + 10 files changed, 2185 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_fspp.c create mode 100644 libavfilter/vf_fspp.h create mode 100644 libavfilter/x86/vf_fspp.c diff --git a/configure b/configure index e37285a..29f5534 100755 --- a/configure +++ b/configure @@ -2575,6 +2575,7 @@ ebur128_filter_deps="gpl" flite_filter_deps="libflite" frei0r_filter_deps="frei0r dlopen" frei0r_src_filter_deps="frei0r dlopen" +fspp_filter_deps="gpl" geq_filter_deps="gpl" histeq_filter_deps="gpl" hqdn3d_filter_deps="gpl" diff --git a/doc/filters.texi b/doc/filters.texi index 882caa0..eefc507 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -4997,6 +4997,30 @@ frei0r=perspective:0.2/0.2|0.8/0.2 For more information, see @url{http://frei0r.dyne.org} +@section fspp + +Faster version of the simple postprocessing filter - @ref{spp}. + +The filter accepts the following options: + +@table @option +@item quality +Set quality. This option defines the number of levels for averaging. It accepts +an integer in the range 0-5. If set to @code{0}, the filter will have no +effect. A value of @code{5} means the higher quality. For each increment of +that value the spe
Re: [FFmpeg-devel] mjpeg2jpeg_filter
On Sun, Dec 14, 2014 at 08:10:31AM -0500, Don Moir wrote: > I needed to convert AVI1 to normal jpeg. This happens a lot with camera > streams and the code in mjpeg2jpeg_filter works fine. > > I was looking at the code in mjpeg2jpeg_filter in file mjpeg2jpeg_bsf.c and > noticing that just creates a constant array of bytes each time for the > replacement header. > > Unless I am missing something, those bytes could just be declared in a const > array rather then building it each frame. Not sure if the values in the > various const arrays are subject to change or not and just an observation. Huh? The arrays themselves are all const. If you mean you could merge them in one single array: Yes, that should be possible. However you still have to copy the data into the frame, so it's only a question of doing 1 large memcpy vs. doing 8. It to me seems unlikely the speed difference will even be measurable, and it would replace code that is possible to understand by comparing with the spec/the normal encoder with some obscure "magic numbers" array. But if you think there is an advantage to doing it differently, I'd expect a patch for discussion (or just discussion) would be welcome. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] wavdec: RIFX file format support
On Mon, Dec 15, 2014 at 10:24:55AM +, Carl Eugen Hoyos wrote: > Thomas Volkert gmx.net> writes: > > > +#include > > This will hopefully be unneeded. > > > codec->sample_rate = avio_rl32(pb); > > codec->bit_rate= avio_rl32(pb) * 8; > > codec->block_align = avio_rl16(pb); > > +if (big_endian) { > > +id = ntohs(id); > > +codec->channels= ntohs(codec->channels); > > +codec->sample_rate = ntohl(codec->sample_rate); > > +codec->bit_rate= ntohl(codec->bit_rate / 8) * 8; > > +codec->block_align = ntohs(codec->block_align); > > +} > > Instead please do: > if (big_endian) { > id = avio_rb32(pb); > codec->channels = avio_rb32(pb); > ... > } else { > id = avio_rl32(pb); > ... > } Not sure this is a good idea, as it duplicates the code. It might be better to use the if as-is, just replacing ntoh* by av_bswap*. Also note that ntoh* is just incorrect here, since they are a NOP on big-endian systems, i.e. the code wouldn't work on big-endian. Which also means that adding a test-case for this format would be advisable so we spot such errors, rare formats are likely to break with future changes if they have no test coverage. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel