[FFmpeg-devel] [PATCH] libavformat/mov: Accept known codepoints in 'colr'
This change relaxes the whitelist on reading color metadata in MOV/BMFF
containers. The whitelist on writing values is still in place.
As a consequence it also fixes an apparent bug in reading 'nclc' values.
The 'nclc' spec [1] is in harmony with ISO 23001-8 for the values it
lists, but the code getting removed was remapping 5->6 and 6->7 for
primaries, which is incorrect, and was remapping 6->5 for color matrix
("colorspace" in the code), which is equivalent but an unnecessary
inconsistency. This logic error doesn't appear in movenc.
Removing the whitelist allows proper conversion when the source codec
relies on the container for proper signaling of newer codepoints, such
as DNxHR and VP9. If converting to a codec or container that has updated
its spec to include the new codepoints, the metadata will be preserved.
If going back to MOV/BMFF, the output whitelist will still kick in, so
this won't result in out-of-spec files being created.
[1] https://developer.apple.com/library/mac/technotes/tn2162/_index.html
Signed-off-by: Steven Robertson
---
libavformat/mov.c | 40 +---
1 file changed, 9 insertions(+), 31 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 7c8f784..6450d52 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -1324,38 +1324,16 @@ static int mov_read_colr(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
st->codecpar->color_range = AVCOL_RANGE_JPEG;
else
st->codecpar->color_range = AVCOL_RANGE_MPEG;
-/* 14496-12 references JPEG XR specs (rather than the more complete
- * 23001-8) so some adjusting is required */
-if (color_primaries >= AVCOL_PRI_FILM)
-color_primaries = AVCOL_PRI_UNSPECIFIED;
-if ((color_trc >= AVCOL_TRC_LINEAR &&
- color_trc <= AVCOL_TRC_LOG_SQRT) ||
-color_trc >= AVCOL_TRC_BT2020_10)
-color_trc = AVCOL_TRC_UNSPECIFIED;
-if (color_matrix >= AVCOL_SPC_BT2020_NCL)
-color_matrix = AVCOL_SPC_UNSPECIFIED;
-st->codecpar->color_primaries = color_primaries;
-st->codecpar->color_trc = color_trc;
-st->codecpar->color_space = color_matrix;
-} else if (!strncmp(color_parameter_type, "nclc", 4)) {
-/* color primaries, Table 4-4 */
-switch (color_primaries) {
-case 1: st->codecpar->color_primaries = AVCOL_PRI_BT709; break;
-case 5: st->codecpar->color_primaries = AVCOL_PRI_SMPTE170M; break;
-case 6: st->codecpar->color_primaries = AVCOL_PRI_SMPTE240M; break;
-}
-/* color transfer, Table 4-5 */
-switch (color_trc) {
-case 1: st->codecpar->color_trc = AVCOL_TRC_BT709; break;
-case 7: st->codecpar->color_trc = AVCOL_TRC_SMPTE240M; break;
-}
-/* color matrix, Table 4-6 */
-switch (color_matrix) {
-case 1: st->codecpar->color_space = AVCOL_SPC_BT709; break;
-case 6: st->codecpar->color_space = AVCOL_SPC_BT470BG; break;
-case 7: st->codecpar->color_space = AVCOL_SPC_SMPTE240M; break;
-}
}
+if (color_primaries >= AVCOL_PRI_NB)
+color_primaries = AVCOL_PRI_UNSPECIFIED;
+if (color_trc >= AVCOL_TRC_NB)
+color_trc = AVCOL_TRC_UNSPECIFIED;
+if (color_matrix >= AVCOL_SPC_NB)
+color_matrix = AVCOL_SPC_UNSPECIFIED;
+st->codecpar->color_primaries = color_primaries;
+st->codecpar->color_trc = color_trc;
+st->codecpar->color_space = color_matrix;
av_log(c->fc, AV_LOG_TRACE, "\n");
return 0;
--
2.8.0.rc2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffmpeg: Update muxer extradata after flushing encoders
This is needed for encoders which store a final sample count or checksum in
extradata
alternatively every encoder as well as muxer can implement
AV_PKT_DATA_NEW_EXTRADATA support
to update the extradata at the end.
Signed-off-by: Michael Niedermayer
---
ffmpeg.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index bae515d..9d972d0 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1772,6 +1772,23 @@ static void flush_encoders(void)
if (stop_encoding)
break;
}
+if (ost->enc_ctx->extradata_size) {
+void *ptr = av_mallocz(ost->enc_ctx->extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+void *ptr2 = av_mallocz(ost->enc_ctx->extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (ptr && ptr2) {
+av_free(ost->st->codec->extradata);
+av_free(ost->st->codecpar->extradata);
+ost->st->codec->extradata= ptr;
+ost->st->codecpar->extradata = ptr2;
+memcpy(ost->st->codec->extradata , ost->enc_ctx->extradata,
ost->enc_ctx->extradata_size);
+memcpy(ost->st->codecpar->extradata, ost->enc_ctx->extradata,
ost->enc_ctx->extradata_size);
+ost->st->codec ->extradata_size =
ost->enc_ctx->extradata_size;
+ost->st->codecpar->extradata_size =
ost->enc_ctx->extradata_size;
+} else {
+av_free(ptr);
+av_free(ptr2);
+}
+}
}
}
--
2.9.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Update muxer extradata after flushing encoders
On 8/17/16, Michael Niedermayer wrote:
> This is needed for encoders which store a final sample count or checksum in
> extradata
>
> alternatively every encoder as well as muxer can implement
> AV_PKT_DATA_NEW_EXTRADATA support
> to update the extradata at the end.
>
> Signed-off-by: Michael Niedermayer
> ---
> ffmpeg.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index bae515d..9d972d0 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -1772,6 +1772,23 @@ static void flush_encoders(void)
> if (stop_encoding)
> break;
> }
> +if (ost->enc_ctx->extradata_size) {
> +void *ptr = av_mallocz(ost->enc_ctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> +void *ptr2 = av_mallocz(ost->enc_ctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> +if (ptr && ptr2) {
> +av_free(ost->st->codec->extradata);
> +av_free(ost->st->codecpar->extradata);
> +ost->st->codec->extradata= ptr;
> +ost->st->codecpar->extradata = ptr2;
> +memcpy(ost->st->codec->extradata ,
> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
> +memcpy(ost->st->codecpar->extradata,
> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
> +ost->st->codec ->extradata_size =
> ost->enc_ctx->extradata_size;
> +ost->st->codecpar->extradata_size =
> ost->enc_ctx->extradata_size;
> +} else {
> +av_free(ptr);
> +av_free(ptr2);
> +}
> +}
> }
> }
I'm against this patch. Use API already available, don't add hacks on
top of hacks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Outreachy 2016 december
On Fri, Jul 22, 2016 at 07:18:13PM +0200, Michael Niedermayer wrote: > On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer wrote: > > Hi all > > > > The next Outreachy round starts soon > > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/) > > to express interrest to participate. > > > > We need an admin and backup admins. > > ping! ping2 so far the only person doing anything was compn https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12?action=history I think there are 2 questions that the community needs to awnser first, should FFmpeg be participating in the december 2016 round of Outreachy ? If so, some people need to come forth with projects to mentor. Ive previously asked people privatly one by one i wont do that this time its a surprissingly large amount of work and anyone else, even a non programer could ask / organize this and probably better than i can, asking people is not by strong side ... And someone needs to come forth as "Admin" Second is the question, which project ideas the community wants and which we do not want. To me it appeard that there was a disparity between objections to proojects and suggestions for projects. I think we need more people suggesting projects and volunteering to mentor than objections against project ideas Thanks PS: keep in mind august 22 is the official deadline for FFmpeg to join IIUC. We need some project idea with a mentor first before any potential admin would contact the Outreachy admins for joining i suspect ... [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- 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] [GSOC][PATCH 1/4] factoring obmc out of snow
Hi Stanislav, On Wed, Aug 17, 2016 at 7:07 AM, Станислав Долганов < stanislav.dolga...@gmail.com> wrote: > Hello, > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > frame support. The current FFV1 uses the same OBMC code as the Snow codec. > Also new median_me_mp function has appeared. > > I'm attaching speed&compression report to every patch to proof effectivity > of each implemented part. Thanks for the report! Typically, people will measure a few coding points per file (instead of one) so you can plot filesize vs. quality (in whatever metric) and see relative improvement between clips (old vs. new) over interpolated points. See e.g. a graph like this: https://blogs.gnome.org/rbultje/files/2015/09/vp9-x264-x265-encoding-quality.png More importantly: nice work! Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] FATE : add libyami fate test case
Hi! Independently of the question how useful libyami is: We do not add fate tests for external libraries. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
> Thanks for the report! Typically, people will measure a few coding points > per file (instead of one) so you can plot filesize vs. quality (in whatever > metric) and see relative improvement between clips (old vs. new) over > interpolated points. See e.g. a graph like this: > > https://blogs.gnome.org/rbultje/files/2015/09/vp9- x264-x265-encoding-quality.png But FFV1 is lossless, so there is no quality range. 2016-08-17 14:59 GMT+03:00 Ronald S. Bultje : > Hi Stanislav, > > On Wed, Aug 17, 2016 at 7:07 AM, Станислав Долганов < > stanislav.dolga...@gmail.com> wrote: > > > Hello, > > > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > > frame support. The current FFV1 uses the same OBMC code as the Snow > codec. > > Also new median_me_mp function has appeared. > > > > I'm attaching speed&compression report to every patch to proof > effectivity > > of each implemented part. > > > Thanks for the report! Typically, people will measure a few coding points > per file (instead of one) so you can plot filesize vs. quality (in whatever > metric) and see relative improvement between clips (old vs. new) over > interpolated points. See e.g. a graph like this: > > https://blogs.gnome.org/rbultje/files/2015/09/vp9- > x264-x265-encoding-quality.png > > More importantly: nice work! > > Ronald > ___ > 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 4/4] lavf/mov: Add support for edit list parsing.
On Mon, Aug 15, 2016 at 07:04:56PM -0700, Sasi Inguva wrote: > Changes done. Also commented in the code about the differences between the > add_index_entry function and teh ff_add_index_entry function. > > About stream copy, yes there will be a big behavior difference when doing "-c > copy" for files with edit lists. > Currently, ignoring edit lists we will copy all packets from input to output. > So for videos with edit lists the current way of stream copy is already > semantically wrong. In summary these will be the changes with this patch > i) For videos with no edit lists - no change. > ii) For videos with one edit list in their streams > - Only portion of the video from the closest keyframe before the > edit list begins, to the closest keyframe after the edit list ends will be > copied. > - All audio from the start of the audio stream to the end of the > edit will be copied. > > iii) For videos with multiple edit lists in their streams > - For video, the timestamps can be non-monotonocially increasing. > Keyframe packets might be repeated. etc. > - For audio too, timestamps can be non-monotonically increasing. > For each edit list we will output packets from the start of the audio stream, > so audio will be repeated. > > Though points (ii) and (iii) might look dangerous, we should keep in mind > that it is very hard, and maybe impossible to implement proper stream copy of > only those portions of streams which are inside edit lists. We need a way to > mark some frames as decode-and-discard, and maybe writing edit lists in case > of MOV container is a way but if we are doing -c copy to some other > container, it won't be possible mostly. If (ii) and (iii) sound unacceptable > I can gate the mov_fix_index function behind a no-stream-copy condition, if > there is a way to do so. > OK. So. I've made some test with a bunch of personal samples from different different sources and it fixes the playback for all of them. I don't have much more comment as it seems to work well. I'm not the maintainer of the MOV demuxer though, so don't take this as a OK. Someone should probably do a deeper review (hint: look at mov_fix_index() in particular) Thanks -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc: add Libav merge document
On Tue, Aug 02, 2016 at 09:23:04AM -0700, Timothy Gu wrote: > I've put this document onto the wiki so that it's easier to edit: > https://trac.ffmpeg.org/wiki/LibavMerge > I actually think it belongs in FFmpeg repository as it's partly a political document so you don't want anyone to be able to edit it at will without review. Patch applied with an additional entry at the end of the document. You should probably drop that wiki page (after merging the eventual changes back into the file in the repository) Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: mark stream as const pointer in av_stream_get_side_data()
On Thu, Jun 30, 2016 at 04:04:56PM +0200, Michael Niedermayer wrote: > On Mon, Jun 27, 2016 at 12:10:53PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > TODO: bump lavf minor > > > XXX: should i add a FF_API_NOCONST_GET_SIDE_DATA? > > yes > done & applied -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/utils: add some const to pointers parameters in a few functions
On Thu, Jun 30, 2016 at 04:01:36PM +0200, Michael Niedermayer wrote: > On Mon, Jun 27, 2016 at 12:10:52PM +0200, Clément Bœsch wrote: > > From: Clément Bœsch > > > > --- > > libavformat/internal.h | 2 +- > > libavformat/utils.c| 6 +++--- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > LGTM > > thx > pushed -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 2/4] FFV1 p frames
On Wed, Aug 17, 2016 at 14:07:24 +0300, Станислав Долганов wrote:
> +{ "pframe", "Using P frames", OFFSET(p_frame), AV_OPT_TYPE_BOOL, { .i64
> = 0 }, 0, 1, VE },
Nit: imperative wording, i.e. "Use P frames".
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] v6 - SCTE-35 support in hlsenc
On Tue, Aug 16, 2016 at 01:10:39PM -0700, Carlos Fernandez Sanz wrote: > From: Carlos Fernandez > > Signed-off-by: Carlos Fernandez > --- > libavformat/Makefile | 2 +- > libavformat/hlsenc.c | 107 -- > libavformat/scte_35.c | 525 > ++ > libavformat/scte_35.h | 86 + > 4 files changed, 698 insertions(+), 22 deletions(-) > create mode 100644 libavformat/scte_35.c > create mode 100644 libavformat/scte_35.h breaks (segfaults) ./ffmpeg -i matrixbench_mpeg2.mpg -acodec mp2 -vcodec mpeg2video -vn -ab 128k -t 3 file.m3u8 [..] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/pcmdec: Map mime_type audio/L16 to the s16le demuxer
On Tue, Aug 09, 2016 at 12:51:30AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-08-05 12:44 GMT+02:00 Nicolas George :
> > Le nonidi 19 thermidor, an CCXXIV, Carl Eugen Hoyos a écrit :
> >> Hi!
> >>
> >> Attached patch implements RFC 2586.
> >>
> >> Please comment, Carl Eugen
> >
> >> From ba470c643c836826d75854e3e3539eb09ddd288a Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos
> >> Date: Fri, 5 Aug 2016 12:22:17 +0200
> >> Subject: [PATCH] lavf/pcmdec: Map mime_type audio/L16 to s16le as specified
> >> in RFC 2586.
> >>
> >> ---
> >> libavformat/pcmdec.c | 63
> >> +-
> >> 1 file changed, 42 insertions(+), 21 deletions(-)
> >>
> >> diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
> >> index df94345..36ef2c2 100644
> >> --- a/libavformat/pcmdec.c
> >> +++ b/libavformat/pcmdec.c
> >> @@ -36,6 +36,7 @@ static int pcm_read_header(AVFormatContext *s)
> >> {
> >> PCMAudioDemuxerContext *s1 = s->priv_data;
> >> AVStream *st;
> >> +uint8_t *mime_type_opt = NULL;
> >>
> >> st = avformat_new_stream(s, NULL);
> >> if (!st)
> >> @@ -47,6 +48,25 @@ static int pcm_read_header(AVFormatContext *s)
> >> st->codecpar->sample_rate = s1->sample_rate;
> >> st->codecpar->channels= s1->channels;
> >>
> >> +av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN,
> >> &mime_type_opt);
> >> +if (mime_type_opt) {
> >
> >> +const char *mime_type = mime_type_opt;
> >
> > I do not understand the need for that line.
>
> Removed.
>
> >> +size_t len = strlen(s->iformat->mime_type);
> >
> > Maybe I am missing something obvious, but I think s->iformat->mime_type is
> > NULL for all the other formats. It needs to be checked.
>
> Added the check.
>
> >> +int rate, channels = 0;
> >> +if (!av_strncasecmp(s->iformat->mime_type, mime_type, len)) {
> >
> >> +if ( !sscanf(mime_type + len, ";rate=%d;channels=%d",
> >> &rate, &channels)
> >
> > If I understand the way MIME type works, ";channels=2;rate=48000" would be
> > exactly as valid, and spaces can surround the semicolons.
>
> I changed this hunk.
>
> >> +|| !rate) {
> >> +av_log(s, AV_LOG_ERROR,
> >> + "Invalid sample_rate found in mime_type \"%s\"\n",
> >> + mime_type);
> >> +return AVERROR_INVALIDDATA;
> >> +}
> >> +st->codecpar->sample_rate = rate;
> >> +if (channels)
> >> +st->codecpar->channels = channels;
> >> +}
> >> +}
> >> +
> >> st->codecpar->bits_per_coded_sample =
> >> av_get_bits_per_sample(st->codecpar->codec_id);
> >>
> >> @@ -65,7 +85,7 @@ static const AVOption pcm_options[] = {
> >> { NULL },
> >> };
> >>
> >> -#define PCMDEF(name_, long_name_, ext, codec) \
> >
> >> +#define PCMDEF(name_, long_name_, ext, codec, mime_type_) \
> >
> > Instead of changing PCMDEF and all the subsequent declarations, you can
> > create a new macro PCMDEF_WITH_MIME.
> >
> > Even simpler: make PCMDEF varadic, add __ARGS__ in the structure definition.
> > Then, adding the MIME type is just a matter of adding ".mime_type = ..." in
> > the macro call.
>
> Yes, much simpler.
>
> New patch attached.
>
> Thank you, Carl Eugen
> pcmdec.c | 34 --
> version.h |2 +-
> 2 files changed, 33 insertions(+), 3 deletions(-)
> 069eb6ba5db3434e3cc6abca155d8a712c54a8e3
> 0002-lavf-pcmdec-Map-mime_type-audio-L16-to-the-s16le-dem.patch
> From 3ef0951db492f1425a574aac71fe73f144c2d99a Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Tue, 9 Aug 2016 00:46:57 +0200
> Subject: [PATCH 2/2] lavf/pcmdec: Map mime_type audio/L16 to the s16le
> demuxer as specified in RFC 2586.
>
> ---
> libavformat/pcmdec.c | 34 --
> libavformat/version.h |2 +-
> 2 files changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
> index df94345..e3cc2ae 100644
> --- a/libavformat/pcmdec.c
> +++ b/libavformat/pcmdec.c
> @@ -36,6 +36,7 @@ static int pcm_read_header(AVFormatContext *s)
> {
> PCMAudioDemuxerContext *s1 = s->priv_data;
> AVStream *st;
> +uint8_t *mime_type = NULL;
>
> st = avformat_new_stream(s, NULL);
> if (!st)
> @@ -47,6 +48,34 @@ static int pcm_read_header(AVFormatContext *s)
> st->codecpar->sample_rate = s1->sample_rate;
> st->codecpar->channels= s1->channels;
>
> +av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type);
> +if (mime_type && s->iformat->mime_type) {
> +int rate = 0, channels = 0;
> +size_t len = strlen(s->iformat->mime_type);
> +if (!strncmp(s->iformat->mime_type, mime_type, len)) {
> +uint8_t *options = mime_type + len;
> +len = strlen(mime_type);
> +while (options < mime_type + len) {
> +
Re: [FFmpeg-devel] [PATCH]ffmpeg: Do not set too large bits_per_raw_sample
On Tue, Jul 05, 2016 at 11:51:58AM +0200, Carl Eugen Hoyos wrote:
> On Tuesday 05 July 2016 12:36:53 am Michael Niedermayer wrote:
> > On Sun, May 01, 2016 at 05:11:08PM +0200, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached patch stops setting bits_per_raw_sample if it makes no sense as
> > > for example in the wmall24 -> pcm_s16 case:
> > > Stream #0:0: Audio: pcm_s16le, 96000 Hz, stereo, s16 (24 bit), 3072
> > > kb/s
> > >
> > > Mostly tested with audio.
> > >
> > > Please comment, Carl Eugen
> > >
> > > ffmpeg.c |7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > 1a672d3fd9fe8e65d2ad9a4271fe5260a888e28a patchrawsample.diff
> > > diff --git a/ffmpeg.c b/ffmpeg.c
> > > index adc3ff7..86bc518 100644
> > > --- a/ffmpeg.c
> > > +++ b/ffmpeg.c
> > > @@ -2859,7 +2859,6 @@ static int transcode_init(void)
> > > dec_ctx = ist->dec_ctx;
> > >
> > > ost->st->disposition = ist->st->disposition;
> > > -enc_ctx->bits_per_raw_sample=
> > > dec_ctx->bits_per_raw_sample; enc_ctx->chroma_sample_location =
> > > dec_ctx->chroma_sample_location; } else {
> > > for (j=0; jnb_streams; j++) {
> > > @@ -3100,6 +3099,9 @@ static int transcode_init(void)
> > > switch (enc_ctx->codec_type) {
> > > case AVMEDIA_TYPE_AUDIO:
> > > enc_ctx->sample_fmt =
> > > ost->filter->filter->inputs[0]->format; +if (dec_ctx)
> > > +enc_ctx->bits_per_raw_sample =
> > > FFMIN(dec_ctx->bits_per_raw_sample, +
> > > av_get_bytes_per_sample(enc_ctx->sample_fmt) << 3);
> > > enc_ctx->sample_rate= ost->filter->filter->inputs[0]->sample_rate;
> > > enc_ctx->channel_layout = ost->filter->filter->inputs[0]->channel_layout;
> > > enc_ctx->channels =
> > > avfilter_link_get_channels(ost->filter->filter->inputs[0]); @@ -3140,6
> > > +3142,9 @@ static int transcode_init(void)
> > > "Use -pix_fmt yuv420p for compatibility with
> > > outdated media players.\n",
> > > av_get_pix_fmt_name(ost->filter->filter->inputs[0]->format));
> > > enc_ctx->pix_fmt = ost->filter->filter->inputs[0]->format; +
> > > if (dec_ctx)
> > > +enc_ctx->bits_per_raw_sample =
> > > FFMIN(dec_ctx->bits_per_raw_sample, +
> > >
> > > av_pix_fmt_desc_get(enc_ctx->pix_fmt)->comp[0].depth);
> >
> > these 2 are missing the stream copy case above
>
> New patch attached.
>
> Thank you, Carl Eugen
> ffmpeg.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
> fdc6c80180ce86fd7767306018660292217060ee
> 0001-ffmpeg-Do-not-set-too-large-bits_per_raw_sample.patch
> From fc564ed83ddf55b9ae783044ad0884803d27d9a7 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Tue, 5 Jul 2016 11:50:00 +0200
> Subject: [PATCH] ffmpeg: Do not set too large bits_per_raw_sample.
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- 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] Outreachy 2016 december
Hi, On Wed, Aug 17, 2016 at 5:33 PM, Michael Niedermayer wrote: > On Fri, Jul 22, 2016 at 07:18:13PM +0200, Michael Niedermayer wrote: >> On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer wrote: >> > Hi all >> > >> > The next Outreachy round starts soon >> > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/) >> > to express interrest to participate. >> > >> > We need an admin and backup admins. >> >> ping! > > ping2 > > so far the only person doing anything was compn > https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12?action=history > > I think there are 2 questions that the community needs to awnser > > first, should FFmpeg be participating in the december 2016 round > of Outreachy ? > > If so, some people need to come forth with projects to mentor. > Ive previously asked people privatly one by one i wont do that this > time its a surprissingly large amount of work and anyone else, even > a non programer could ask / organize this and probably better than i > can, asking people is not by strong side ... > And someone needs to come forth as "Admin" > > Second is the question, which project ideas the community wants and > which we do not want. > To me it appeard that there was a disparity between objections to > proojects and suggestions for projects. I think we need more people > suggesting projects and volunteering to mentor than objections against > project ideas > > Thanks > > PS: keep in mind august 22 is the official deadline for FFmpeg to > join IIUC. We need some project idea with a mentor first before any > potential admin would contact the Outreachy admins for joining i > suspect ... I'd love to mentor some *easy* project in the Outreachy program definitely. May be I can even get some students to apply to the program. - Umair ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] lavf/mov: Add support for edit list parsing.
Thanks On Aug 17, 2016 6:25 AM, "Clément Bœsch" wrote: > On Mon, Aug 15, 2016 at 07:04:56PM -0700, Sasi Inguva wrote: > > Changes done. Also commented in the code about the differences between > the add_index_entry function and teh ff_add_index_entry function. > > > > About stream copy, yes there will be a big behavior difference when > doing "-c copy" for files with edit lists. > > Currently, ignoring edit lists we will copy all packets from input to > output. So for videos with edit lists the current way of stream copy is > already semantically wrong. In summary these will be the changes with this > patch > > i) For videos with no edit lists - no change. > > ii) For videos with one edit list in their streams > > - Only portion of the video from the closest keyframe before > the edit list begins, to the closest keyframe after the edit list ends will > be copied. > > - All audio from the start of the audio stream to the end of > the edit will be copied. > > > > iii) For videos with multiple edit lists in their streams > > - For video, the timestamps can be non-monotonocially > increasing. Keyframe packets might be repeated. etc. > > - For audio too, timestamps can be non-monotonically > increasing. For each edit list we will output packets from the start of the > audio stream, so audio will be repeated. > > > > Though points (ii) and (iii) might look dangerous, we should keep in > mind that it is very hard, and maybe impossible to implement proper stream > copy of only those portions of streams which are inside edit lists. We need > a way to mark some frames as decode-and-discard, and maybe writing edit > lists in case of MOV container is a way but if we are doing -c copy to > some other container, it won't be possible mostly. If (ii) and (iii) sound > unacceptable I can gate the mov_fix_index function behind a no-stream-copy > condition, if there is a way to do so. > > > > OK. > > So. I've made some test with a bunch of personal samples from different > different sources and it fixes the playback for all of them. I don't have > much more comment as it seems to work well. I'm not the maintainer of the > MOV demuxer though, so don't take this as a OK. > > Someone should probably do a deeper review (hint: look at mov_fix_index() > in particular) > > Thanks > > -- > Clément B. > > ___ > 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 max value output option to psnr stats log.
On Thu, Aug 11, 2016 at 10:44:12AM -0700, Lucas Cooper wrote:
> This allows retroactive calculation/aggregation of PSNR from the stats
> log.
> ---
> libavfilter/vf_psnr.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/libavfilter/vf_psnr.c b/libavfilter/vf_psnr.c
> index 3bec747..de5cc8f 100644
> --- a/libavfilter/vf_psnr.c
> +++ b/libavfilter/vf_psnr.c
> @@ -45,6 +45,7 @@ typedef struct PSNRContext {
> char *stats_file_str;
> int stats_version;
> int stats_header_written;
> +int stats_add_max;
> int max[4], average_max;
> int is_rgb;
> uint8_t rgba_map[4];
> @@ -63,6 +64,7 @@ static const AVOption psnr_options[] = {
> {"stats_file", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0,
> FLAGS },
> {"f", "Set file where to store per-frame difference
> information", OFFSET(stats_file_str), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0,
> FLAGS },
> {"stats_version", "Set the format version for the stats file.",
> OFFSET(stats_version), AV_OPT_TYPE_INT,{.i64=1},1, 2, FLAGS },
> +{"output_max", "Add raw stats (max values) to the output log.",
>OFFSET(stats_add_max), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> { NULL }
> };
>
> @@ -182,6 +184,12 @@ static AVFrame *do_psnr(AVFilterContext *ctx, AVFrame
> *main,
> for (j = 0; j < s->nb_components; j++) {
> fprintf(s->stats_file, ",psnr_%c", s->comps[j]);
> }
> +if (s->stats_add_max) {
> + fprintf(s->stats_file, ",max_avg");
> + for (j = 0; j < s->nb_components; j++) {
> + fprintf(s->stats_file, ",max_%c", s->comps[j]);
> + }
> +}
> fprintf(s->stats_file, "\n");
> s->stats_header_written = 1;
newly added code should follow the same style as existing code
and indention depth is 4 throughout ffmpeg
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- 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 1/2] compat/avisynth: update AviSynth+ header
On Mon, Aug 15, 2016 at 12:37:30PM -0400, Stephen Hutchinson wrote: > --- > compat/avisynth/avisynth_c.h | 256 > --- > 1 file changed, 219 insertions(+), 37 deletions(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]ffmpeg: Do not set too large bits_per_raw_sample
Hi! 2016-08-17 17:39 GMT+02:00 Michael Niedermayer : >> ffmpeg.c |8 +++- >> 1 file changed, 7 insertions(+), 1 deletion(-) >> fdc6c80180ce86fd7767306018660292217060ee >> 0001-ffmpeg-Do-not-set-too-large-bits_per_raw_sample.patch >> From fc564ed83ddf55b9ae783044ad0884803d27d9a7 Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Tue, 5 Jul 2016 11:50:00 +0200 >> Subject: [PATCH] ffmpeg: Do not set too large bits_per_raw_sample. > > LGTM Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/pcmdec: Map mime_type audio/L16 to the s16le demuxer
Hi!
2016-08-17 17:32 GMT+02:00 Michael Niedermayer :
>> +av_opt_get(s->pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type);
>> +if (mime_type && s->iformat->mime_type) {
>> +int rate = 0, channels = 0;
>> +size_t len = strlen(s->iformat->mime_type);
>> +if (!strncmp(s->iformat->mime_type, mime_type, len)) {
>> +uint8_t *options = mime_type + len;
>> +len = strlen(mime_type);
>> +while (options < mime_type + len) {
>> +options = strstr(options, ";");
>> +if (!options++)
>> +break;
>> +if (!rate)
>> +sscanf(options, " rate=%d", &rate);
>> +if (!channels)
>> +sscanf(options, " channels=%d", &channels);
>> +}
>
> rate and channels probably should be subject to some sanity checks
> like < 0
Sanity checks for <0 added, INT_MAX is also possible with the current
code.
Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Outreachy 2016 december
On Wed, Aug 17, 2016 at 09:16:16PM +0530, Umair Khan wrote: > Hi, > > On Wed, Aug 17, 2016 at 5:33 PM, Michael Niedermayer > wrote: > > On Fri, Jul 22, 2016 at 07:18:13PM +0200, Michael Niedermayer wrote: > >> On Wed, Jul 06, 2016 at 11:25:21PM +0200, Michael Niedermayer wrote: > >> > Hi all > >> > > >> > The next Outreachy round starts soon > >> > FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/) > >> > to express interrest to participate. > >> > > >> > We need an admin and backup admins. > >> > >> ping! > > > > ping2 > > > > so far the only person doing anything was compn > > https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12?action=history > > > > I think there are 2 questions that the community needs to awnser > > > > first, should FFmpeg be participating in the december 2016 round > > of Outreachy ? > > > > If so, some people need to come forth with projects to mentor. > > Ive previously asked people privatly one by one i wont do that this > > time its a surprissingly large amount of work and anyone else, even > > a non programer could ask / organize this and probably better than i > > can, asking people is not by strong side ... > > And someone needs to come forth as "Admin" > > > > Second is the question, which project ideas the community wants and > > which we do not want. > > To me it appeard that there was a disparity between objections to > > proojects and suggestions for projects. I think we need more people > > suggesting projects and volunteering to mentor than objections against > > project ideas > > > > Thanks > > > > PS: keep in mind august 22 is the official deadline for FFmpeg to > > join IIUC. We need some project idea with a mentor first before any > > potential admin would contact the Outreachy admins for joining i > > suspect ... > > I'd love to mentor some *easy* project in the Outreachy program > definitely. May be I can even get some students to apply to the > program. that would be great, do you have any specific ideas for a easy project ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc&tools: Add murge script, for analyzing 3 way conflicts.
Signed-off-by: Michael Niedermayer --- doc/libav-merge.txt | 4 tools/murge | 13 + 2 files changed, 17 insertions(+) create mode 100755 tools/murge diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt index 60c953a..47c513a 100644 --- a/doc/libav-merge.txt +++ b/doc/libav-merge.txt @@ -103,6 +103,10 @@ It has two modes: merge, and noop. The noop mode creates a merge with no change to the HEAD. You can pass a hash as extra argument to reference a justification (it is common that we already have the change done in FFmpeg). +Also see tools/murge, you can copy and paste a 3 way conflict into its stdin +and it will display colored diffs. Any arguments to murge (like ones to supress +whitespace differences) are passed into colordiff. + TODO/FIXME/UNMERGED === diff --git a/tools/murge b/tools/murge new file mode 100755 index 000..b4d88a1 --- /dev/null +++ b/tools/murge @@ -0,0 +1,13 @@ +#!/bin/sh + +grep -A9 '<<<' | grep -B9 '>>>' >murge.X +grep -A '' murge.X | egrep -v '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.theirs +grep -B '' murge.X | egrep -v '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.ours +grep -B '' murge.X | grep -A '' | egrep -v '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.common + +colordiff -du $* murge.ours murge.theirs +grep . murge.common > /dev/null && colordiff -du $* murge.common murge.theirs +grep . murge.common > /dev/null && colordiff -du $* murge.common murge.ours +rm murge.theirs murge.common murge.ours murge.X + + -- 2.9.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Update muxer extradata after flushing encoders
Hi,
On Wed, Aug 17, 2016 at 3:43 PM, Paul B Mahol wrote:
> On 8/17/16, Michael Niedermayer wrote:
>> This is needed for encoders which store a final sample count or checksum in
>> extradata
>>
>> alternatively every encoder as well as muxer can implement
>> AV_PKT_DATA_NEW_EXTRADATA support
>> to update the extradata at the end.
>>
>> Signed-off-by: Michael Niedermayer
>> ---
>> ffmpeg.c | 17 +
>> 1 file changed, 17 insertions(+)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index bae515d..9d972d0 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -1772,6 +1772,23 @@ static void flush_encoders(void)
>> if (stop_encoding)
>> break;
>> }
>> +if (ost->enc_ctx->extradata_size) {
>> +void *ptr = av_mallocz(ost->enc_ctx->extradata_size +
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> +void *ptr2 = av_mallocz(ost->enc_ctx->extradata_size +
>> AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (ptr && ptr2) {
>> +av_free(ost->st->codec->extradata);
>> +av_free(ost->st->codecpar->extradata);
>> +ost->st->codec->extradata= ptr;
>> +ost->st->codecpar->extradata = ptr2;
>> +memcpy(ost->st->codec->extradata ,
>> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
>> +memcpy(ost->st->codecpar->extradata,
>> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
>> +ost->st->codec ->extradata_size =
>> ost->enc_ctx->extradata_size;
>> +ost->st->codecpar->extradata_size =
>> ost->enc_ctx->extradata_size;
>> +} else {
>> +av_free(ptr);
>> +av_free(ptr2);
>> +}
>> +}
>> }
>> }
>
> I'm against this patch. Use API already available, don't add hacks on
> top of hacks.
I had a look at the mp4 muxer code. And it itself doesn't implement
the AV_PKT_DATA_NEW_EXTRADATA api.
I'll try to implement that in the mp4 muxer now.
- Umair
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc&tools: Add murge script, for analyzing 3 way conflicts.
On Wed, Aug 17, 2016 at 07:06:44PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/libav-merge.txt | 4 > tools/murge | 13 + > 2 files changed, 17 insertions(+) > create mode 100755 tools/murge > > diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt > index 60c953a..47c513a 100644 > --- a/doc/libav-merge.txt > +++ b/doc/libav-merge.txt > @@ -103,6 +103,10 @@ It has two modes: merge, and noop. The noop mode creates > a merge with no change > to the HEAD. You can pass a hash as extra argument to reference a > justification > (it is common that we already have the change done in FFmpeg). > > +Also see tools/murge, you can copy and paste a 3 way conflict into its stdin > +and it will display colored diffs. Any arguments to murge (like ones to > supress suppress > +whitespace differences) are passed into colordiff. > + This makes me realize that the script pasted in that document could end up in the tools directory > TODO/FIXME/UNMERGED > === > > diff --git a/tools/murge b/tools/murge > new file mode 100755 > index 000..b4d88a1 > --- /dev/null > +++ b/tools/murge > @@ -0,0 +1,13 @@ > +#!/bin/sh > + > +grep -A9 '<<<' | grep -B9 '>>>' >murge.X > +grep -A '' murge.X | egrep -v > '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.theirs sometimes 9, sometimes ? > +grep -B '' murge.X | egrep -v > '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.ours > +grep -B '' murge.X | grep -A '' | egrep -v > '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.common > + > +colordiff -du $* murge.ours murge.theirs > +grep . murge.common > /dev/null && colordiff -du $* murge.common murge.theirs > +grep . murge.common > /dev/null && colordiff -du $* murge.common murge.ours > +rm murge.theirs murge.common murge.ours murge.X maybe these files should be in /tmp i'd also suggest TMPFILES="murge.theirs murge.common murge.ours murge.X" trap 'rm -f -- $TMPFILES' EXIT (stolen from configure) -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc&tools: Add murge script, for analyzing 3 way conflicts.
On Wed, Aug 17, 2016 at 07:06:44PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > doc/libav-merge.txt | 4 > tools/murge | 13 + > 2 files changed, 17 insertions(+) > create mode 100755 tools/murge > > diff --git a/doc/libav-merge.txt b/doc/libav-merge.txt > index 60c953a..47c513a 100644 > --- a/doc/libav-merge.txt > +++ b/doc/libav-merge.txt > @@ -103,6 +103,10 @@ It has two modes: merge, and noop. The noop mode creates > a merge with no change > to the HEAD. You can pass a hash as extra argument to reference a > justification > (it is common that we already have the change done in FFmpeg). > > +Also see tools/murge, you can copy and paste a 3 way conflict into its stdin > +and it will display colored diffs. Any arguments to murge (like ones to > supress > +whitespace differences) are passed into colordiff. > + > TODO/FIXME/UNMERGED > === > > diff --git a/tools/murge b/tools/murge > new file mode 100755 > index 000..b4d88a1 > --- /dev/null > +++ b/tools/murge > @@ -0,0 +1,13 @@ > +#!/bin/sh > + > +grep -A9 '<<<' | grep -B9 '>>>' >murge.X > +grep -A '' murge.X | egrep -v > '===|<<<|>>>|\|\|\|\|\|\|\|' >murge.theirs btw, a few files contain '=', see for instance libavcodec/h264dec.h you might want to add an extra ^ marker to make sure it matches the beginning of the line -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc&tools: Add murge script, for analyzing 3 way conflicts.
Le primidi 1er fructidor, an CCXXIV, Clement Boesch a écrit :
> maybe these files should be in /tmp
>
> i'd also suggest
>
> TMPFILES="murge.theirs murge.common murge.ours murge.X"
> trap 'rm -f -- $TMPFILES' EXIT
>
> (stolen from configure)
Temporary files are annoying and tricky (and configure does not clean up
when it is interrupted).
I suggest to require a more advanced shell (bash or zsh; since this tool is
meant for developers it is acceptable) and use process substitution:
diff <(grep ...) <(grep ...)
It starts both grep processes just like "grep | diff", but then, instead of
connecting the other end of the pipe to diff's standard input, it gives it
the corresponding file name as /dev/fd/42.
If temp files are really necessary because the command does not work with
pipes, then zsh's process substitution can serve:
diff =(grep ...) =(grep ...)
It does the same as <(grep) but with a temp file instead of a pipe; zsh does
all the cleanup for us.
Last of all, if temp files are necessary because the output needs to be
processed several times, zsh's process substitution can still be abused:
function do_the_work {
grep > $1
grep > $2
grep > $3
diff $1 $2
diff $2 $3
}
do_the_work =(:) =(:) =(:)
The strange smileys are just process substitution with a dummy command.
Therefore, it starts the function with three temp files. They are all empty,
because the dummy command does not produce output, but they can then be used
in the function.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] 64-bit pcm signed support
Hi, patches attached. 0001-swresample-add-int64-sample-format.patch Description: Binary data 0002-avcodec-add-64-bit-signed-pcm-codec.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
On Wed, Aug 17, 2016 at 02:07:20PM +0300, Станислав Долганов wrote: > Hello, > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > frame support. The current FFV1 uses the same OBMC code as the Snow codec. > Also new median_me_mp function has appeared. > > I'm attaching speed&compression report to every patch to proof effectivity > of each implemented part. > > I'll appreciate feedback > > Best regards, > Stanislav > b/libavcodec/Makefile |8 > b/libavcodec/obmc.c| 59 + > b/libavcodec/obmc.h| 30 > b/libavcodec/obme.c| 1133 > b/libavcodec/obme.h| 33 + > b/libavcodec/obmemc.c | 650 > b/libavcodec/obmemc.h | 522 > b/libavcodec/obmemc_data.h | 132 > b/libavcodec/snow.c| 571 -- > b/libavcodec/snow.h| 341 -- > b/libavcodec/snowdec.c | 217 +- > b/libavcodec/snowenc.c | 1411 > +++-- > libavcodec/snowdata.h | 132 > 13 files changed, 2890 insertions(+), 2349 deletions(-) > 302bd7a57b192a32abc855abc11a86b5b347ceea > 0001-factoring-obmc-out-of-snow.patch > From 6e16cf2f222a3989db71742511a6cc3250a41980 Mon Sep 17 00:00:00 2001 > From: Stanislav Dolganov > Date: Tue, 16 Aug 2016 15:14:32 +0300 > Subject: [PATCH 1/4] factoring obmc out of snow this causes some crashes with invalid input files, like: for example: [snow @ 0x10c7b420] pixel format changed ==17523== Invalid read of size 1 ==17523==at 0xEA57A3: mc_block (obmemc.c:209) ==17523==by 0xEA624D: ff_obmc_pred_block (obmemc.c:304) ==17523==by 0xAA34FF: add_yblock (obmemc.h:283) ==17523==by 0xAA41C5: predict_slice_buffered (obmemc.h:438) ==17523==by 0xAA73B1: decode_frame (snowdec.c:490) ==17523==by 0xAF1EA2: avcodec_decode_video2 (utils.c:2223) ==17523==by 0x431548: decode_video (ffmpeg.c:2087) ==17523==by 0x4326AF: process_input_packet (ffmpeg.c:2340) ==17523==by 0x439A9B: process_input (ffmpeg.c:4016) ==17523==by 0x439DA7: transcode_step (ffmpeg.c:4104) ==17523==by 0x439EEE: transcode (ffmpeg.c:4158) ==17523==by 0x43A61F: main (ffmpeg.c:4353) ==17523== Address 0x17d326ef is 0 bytes after a block of size 1,071 alloc'd ==17523==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727) ==17523==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876) ==17523==by 0x1034A6F: av_malloc (mem.c:97) ==17523==by 0x10224FB: av_buffer_alloc (buffer.c:71) ==17523==by 0x1022560: av_buffer_allocz (buffer.c:84) ==17523==by 0x1022C76: pool_alloc_buffer (buffer.c:353) ==17523==by 0x1022DA4: av_buffer_pool_get (buffer.c:418) ==17523==by 0xAED00D: video_get_buffer (utils.c:677) ==17523==by 0xAED34A: avcodec_default_get_buffer2 (utils.c:732) ==17523==by 0x433259: get_buffer (ffmpeg.c:2533) ==17523==by 0xAEDB78: get_buffer_internal (utils.c:915) ==17523==by 0xAEDBFA: ff_get_buffer (utils.c:930) ==17523==by 0xEA65E7: ff_obmc_get_buffer (obmemc.c:335) ==17523==by 0xEA759A: ff_obmc_frame_start (obmemc.c:519) ==17523==by 0xE9D1E4: ff_obmc_predecode_frame (obmc.c:47) ==17523==by 0xAA6B50: decode_frame (snowdec.c:391) ==17523==by 0xAF1EA2: avcodec_decode_video2 (utils.c:2223) ==17523==by 0x431548: decode_video (ffmpeg.c:2087) ==17523==by 0x4326AF: process_input_packet (ffmpeg.c:2340) ==17523==by 0x439A9B: process_input (ffmpeg.c:4016) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC][PATCH 1/4] factoring obmc out of snow
On Wed, Aug 17, 2016 at 07:50:22PM +0200, Michael Niedermayer wrote: > On Wed, Aug 17, 2016 at 02:07:20PM +0300, Станислав Долганов wrote: > > Hello, > > > > I'm sending the patch set with implementation of GSoC project -- FFV1 P > > frame support. The current FFV1 uses the same OBMC code as the Snow codec. > > Also new median_me_mp function has appeared. > > > > I'm attaching speed&compression report to every patch to proof effectivity > > of each implemented part. > > > > I'll appreciate feedback > > > > Best regards, > > Stanislav > > > b/libavcodec/Makefile |8 > > b/libavcodec/obmc.c| 59 + > > b/libavcodec/obmc.h| 30 > > b/libavcodec/obme.c| 1133 > > b/libavcodec/obme.h| 33 + > > b/libavcodec/obmemc.c | 650 > > b/libavcodec/obmemc.h | 522 > > b/libavcodec/obmemc_data.h | 132 > > b/libavcodec/snow.c| 571 -- > > b/libavcodec/snow.h| 341 -- > > b/libavcodec/snowdec.c | 217 +- > > b/libavcodec/snowenc.c | 1411 > > +++-- > > libavcodec/snowdata.h | 132 > > 13 files changed, 2890 insertions(+), 2349 deletions(-) > > 302bd7a57b192a32abc855abc11a86b5b347ceea > > 0001-factoring-obmc-out-of-snow.patch > > From 6e16cf2f222a3989db71742511a6cc3250a41980 Mon Sep 17 00:00:00 2001 > > From: Stanislav Dolganov > > Date: Tue, 16 Aug 2016 15:14:32 +0300 > > Subject: [PATCH 1/4] factoring obmc out of snow > > this causes some crashes with invalid input files, like: > > for example: > [snow @ 0x10c7b420] pixel format changed > ==17523== Invalid read of size 1 > ==17523==at 0xEA57A3: mc_block (obmemc.c:209) > ==17523==by 0xEA624D: ff_obmc_pred_block (obmemc.c:304) > ==17523==by 0xAA34FF: add_yblock (obmemc.h:283) > ==17523==by 0xAA41C5: predict_slice_buffered (obmemc.h:438) > ==17523==by 0xAA73B1: decode_frame (snowdec.c:490) > ==17523==by 0xAF1EA2: avcodec_decode_video2 (utils.c:2223) > ==17523==by 0x431548: decode_video (ffmpeg.c:2087) > ==17523==by 0x4326AF: process_input_packet (ffmpeg.c:2340) > ==17523==by 0x439A9B: process_input (ffmpeg.c:4016) > ==17523==by 0x439DA7: transcode_step (ffmpeg.c:4104) > ==17523==by 0x439EEE: transcode (ffmpeg.c:4158) > ==17523==by 0x43A61F: main (ffmpeg.c:4353) > ==17523== Address 0x17d326ef is 0 bytes after a block of size 1,071 alloc'd > ==17523==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727) > ==17523==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876) > ==17523==by 0x1034A6F: av_malloc (mem.c:97) > ==17523==by 0x10224FB: av_buffer_alloc (buffer.c:71) > ==17523==by 0x1022560: av_buffer_allocz (buffer.c:84) > ==17523==by 0x1022C76: pool_alloc_buffer (buffer.c:353) > ==17523==by 0x1022DA4: av_buffer_pool_get (buffer.c:418) > ==17523==by 0xAED00D: video_get_buffer (utils.c:677) > ==17523==by 0xAED34A: avcodec_default_get_buffer2 (utils.c:732) > ==17523==by 0x433259: get_buffer (ffmpeg.c:2533) > ==17523==by 0xAEDB78: get_buffer_internal (utils.c:915) > ==17523==by 0xAEDBFA: ff_get_buffer (utils.c:930) > ==17523==by 0xEA65E7: ff_obmc_get_buffer (obmemc.c:335) > ==17523==by 0xEA759A: ff_obmc_frame_start (obmemc.c:519) > ==17523==by 0xE9D1E4: ff_obmc_predecode_frame (obmc.c:47) > ==17523==by 0xAA6B50: decode_frame (snowdec.c:391) > ==17523==by 0xAF1EA2: avcodec_decode_video2 (utils.c:2223) > ==17523==by 0x431548: decode_video (ffmpeg.c:2087) > ==17523==by 0x4326AF: process_input_packet (ffmpeg.c:2340) > ==17523==by 0x439A9B: process_input (ffmpeg.c:4016) heres how to reproduce some crash: zzuf -c -s0: -r0.01 ./ffmpeg -i snow-chroma-bug.avi -f null - crashes within seconds like: zzuf[s=48,r=0.01]: signal 11 (SIGSEGV) original sample from: https://samples.mplayerhq.hu/V-codecs/SNOW/ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] avformat/movenc: allow rewriting extradata
Hi,
Patch attached.
I hope this is the cleanest solution. :)
- Umair
From be04357d54897173b1776ed92ab8347b3cdffd46 Mon Sep 17 00:00:00 2001
From: Umair Khan
Date: Thu, 18 Aug 2016 00:27:42 +0530
Subject: [PATCH] avformat/movenc: allow rewriting extradata
Signed-off-by: Umair Khan
---
libavformat/movenc.c | 30 ++
libavformat/movenc.h | 2 ++
2 files changed, 32 insertions(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 14db880..b33f24c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4919,6 +4919,19 @@ static int mov_write_single_packet(AVFormatContext *s,
AVPacket *pkt)
trk->start_cts = pkt->pts - pkt->dts;
else
trk->start_cts = 0;
+}
+
+if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
+int side_size = 0;
+uint8_t *side = av_packet_get_side_data(pkt,
AV_PKT_DATA_NEW_EXTRADATA, &side_size);
+av_log(s, AV_LOG_ERROR, "side_size = %d\n", side_size);
+if (side && side_size > 0 && (side_size != par->extradata_size
|| memcmp(side, par->extradata, side_size))) {
+av_free(par->extradata);
+par->extradata = av_mallocz(side_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+memcpy(par->extradata, side, side_size);
+par->extradata_size = side_size;
+mov->need_rewrite_extradata = 1;
+}
}
return 0; /* Discard 0 sized packets */
@@ -5923,6 +5936,23 @@ static int mov_write_trailer(AVFormatContext *s)
int i;
int64_t moov_pos;
+if (mov->need_rewrite_extradata) {
+for (i = 0; i < s->nb_streams; i++) {
+AVStream *st= s->streams[i];
+MOVTrack *track= &mov->tracks[i];
+AVCodecParameters *par = track->par;
+
+track->vos_len = par->extradata_size;
+track->vos_data = av_malloc(track->vos_len);
+if (!track->vos_data) {
+AVERROR(ENOMEM);
+goto error;
+}
+memcpy(track->vos_data, par->extradata, track->vos_len);
+}
+mov->need_rewrite_extradata = 0;
+}
+
/*
* Before actually writing the trailer, make sure that there are no
* dangling subtitles, that need a terminating sample.
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 6e9f5ac..894a1b0 100644
--- a/libavformat/movenc.h
+++ b/libavformat/movenc.h
@@ -215,6 +215,8 @@ typedef struct MOVMuxContext {
uint8_t *encryption_kid;
int encryption_kid_len;
+int need_rewrite_extradata;
+
} MOVMuxContext;
#define FF_MOV_FLAG_RTP_HINT (1 << 0)
--
2.8.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: Update muxer extradata after flushing encoders
Hi,
On Wed, Aug 17, 2016 at 10:44 PM, Umair Khan wrote:
> Hi,
>
> On Wed, Aug 17, 2016 at 3:43 PM, Paul B Mahol wrote:
>> On 8/17/16, Michael Niedermayer wrote:
>>> This is needed for encoders which store a final sample count or checksum in
>>> extradata
>>>
>>> alternatively every encoder as well as muxer can implement
>>> AV_PKT_DATA_NEW_EXTRADATA support
>>> to update the extradata at the end.
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> ffmpeg.c | 17 +
>>> 1 file changed, 17 insertions(+)
>>>
>>> diff --git a/ffmpeg.c b/ffmpeg.c
>>> index bae515d..9d972d0 100644
>>> --- a/ffmpeg.c
>>> +++ b/ffmpeg.c
>>> @@ -1772,6 +1772,23 @@ static void flush_encoders(void)
>>> if (stop_encoding)
>>> break;
>>> }
>>> +if (ost->enc_ctx->extradata_size) {
>>> +void *ptr = av_mallocz(ost->enc_ctx->extradata_size +
>>> AV_INPUT_BUFFER_PADDING_SIZE);
>>> +void *ptr2 = av_mallocz(ost->enc_ctx->extradata_size +
>>> AV_INPUT_BUFFER_PADDING_SIZE);
>>> +if (ptr && ptr2) {
>>> +av_free(ost->st->codec->extradata);
>>> +av_free(ost->st->codecpar->extradata);
>>> +ost->st->codec->extradata= ptr;
>>> +ost->st->codecpar->extradata = ptr2;
>>> +memcpy(ost->st->codec->extradata ,
>>> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
>>> +memcpy(ost->st->codecpar->extradata,
>>> ost->enc_ctx->extradata, ost->enc_ctx->extradata_size);
>>> +ost->st->codec ->extradata_size =
>>> ost->enc_ctx->extradata_size;
>>> +ost->st->codecpar->extradata_size =
>>> ost->enc_ctx->extradata_size;
>>> +} else {
>>> +av_free(ptr);
>>> +av_free(ptr2);
>>> +}
>>> +}
>>> }
>>> }
>>
>> I'm against this patch. Use API already available, don't add hacks on
>> top of hacks.
>
> I had a look at the mp4 muxer code. And it itself doesn't implement
> the AV_PKT_DATA_NEW_EXTRADATA api.
> I'll try to implement that in the mp4 muxer now.
I've sent the patch to the mailing list. Please review it.
Meanwhile, I'll finalise my alsenc patch. :)
- Umair
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/movenc: allow rewriting extradata
Hi, On 8/17/16, Umair Khan wrote: > Hi, > > Patch attached. > > I hope this is the cleanest solution. :) Looks much cleaner. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] h264_qsv decoder speed
Hi there, I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode. There is pretty big speed gap. I wonder whether I did sth. wrong or there are really some problems with ffmpeg's implementation.. The test video was captured from a 3MP(2048x1536) camera. The commands I used: - ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f null /dev/null - sample_decode h264 -i test.h264 Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got 370FPS. I haven't got time debugging into this. Sending this out to see whether you guys might have sth. in mind.. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/movenc: allow rewriting extradata
On 8/17/2016 3:59 PM, Umair Khan wrote:
> Hi,
>
> Patch attached.
>
> I hope this is the cleanest solution. :)
>
> - Umair
>
>
> patch.diff
>
>
> From be04357d54897173b1776ed92ab8347b3cdffd46 Mon Sep 17 00:00:00 2001
> From: Umair Khan
> Date: Thu, 18 Aug 2016 00:27:42 +0530
> Subject: [PATCH] avformat/movenc: allow rewriting extradata
>
> Signed-off-by: Umair Khan
> ---
> libavformat/movenc.c | 30 ++
> libavformat/movenc.h | 2 ++
> 2 files changed, 32 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 14db880..b33f24c 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -4919,6 +4919,19 @@ static int mov_write_single_packet(AVFormatContext *s,
> AVPacket *pkt)
> trk->start_cts = pkt->pts - pkt->dts;
> else
> trk->start_cts = 0;
> +}
> +
> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
> +int side_size = 0;
> +uint8_t *side = av_packet_get_side_data(pkt,
> AV_PKT_DATA_NEW_EXTRADATA, &side_size);
> +av_log(s, AV_LOG_ERROR, "side_size = %d\n", side_size);
I'm not sure this is useful at all, but if you think it is
then make it either AV_ERROR_VERBOSE or AV_ERROR_DEBUG.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Outreachy 2016 december
On Wed, 17 Aug 2016 18:24:09 +0200 Michael Niedermayer wrote: > On Wed, Aug 17, 2016 at 09:16:16PM +0530, Umair Khan wrote: > > I'd love to mentor some *easy* project in the Outreachy program > > definitely. May be I can even get some students to apply to the > > program. > > that would be great, do you have any specific ideas for a easy > project ? reviewing all (or maybe 500) bugs in trac, testing with latest git version and updating or closing old bugs? -compn ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
Hi! 2016-08-17 19:48 GMT+02:00 Paul B Mahol : > patches attached. Which other application supports this format? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
Hi! 2016-08-17 22:53 GMT+02:00 Paul B Mahol : > On 8/17/16, Carl Eugen Hoyos wrote: >> Which other application supports this format? > > Adobe Audition I think. Do we have a sample? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/movenc: allow rewriting extradata
On Thu, Aug 18, 2016 at 1:28 AM, James Almer wrote:
> On 8/17/2016 3:59 PM, Umair Khan wrote:
>> Hi,
>>
>> Patch attached.
>>
>> I hope this is the cleanest solution. :)
>>
>> - Umair
>>
>>
>> patch.diff
>>
>>
>> From be04357d54897173b1776ed92ab8347b3cdffd46 Mon Sep 17 00:00:00 2001
>> From: Umair Khan
>> Date: Thu, 18 Aug 2016 00:27:42 +0530
>> Subject: [PATCH] avformat/movenc: allow rewriting extradata
>>
>> Signed-off-by: Umair Khan
>> ---
>> libavformat/movenc.c | 30 ++
>> libavformat/movenc.h | 2 ++
>> 2 files changed, 32 insertions(+)
>>
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index 14db880..b33f24c 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -4919,6 +4919,19 @@ static int mov_write_single_packet(AVFormatContext
>> *s, AVPacket *pkt)
>> trk->start_cts = pkt->pts - pkt->dts;
>> else
>> trk->start_cts = 0;
>> +}
>> +
>> +if (trk->par->codec_id == AV_CODEC_ID_MP4ALS) {
>> +int side_size = 0;
>> +uint8_t *side = av_packet_get_side_data(pkt,
>> AV_PKT_DATA_NEW_EXTRADATA, &side_size);
>> +av_log(s, AV_LOG_ERROR, "side_size = %d\n", side_size);
>
> I'm not sure this is useful at all, but if you think it is
> then make it either AV_ERROR_VERBOSE or AV_ERROR_DEBUG.
Sorry for this. I overlooked it.
I'll resend the patch.
- Umair
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
On 8/17/16, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-17 19:48 GMT+02:00 Paul B Mahol : >> patches attached. > > Which other application supports this format? > Adobe Audition I think. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
Hello Mr. Hoyos! On 8/17/16, Carl Eugen Hoyos wrote: > Hi! > > 2016-08-17 22:53 GMT+02:00 Paul B Mahol : >> On 8/17/16, Carl Eugen Hoyos wrote: >>> Which other application supports this format? >> >> Adobe Audition I think. > > Do we have a sample? Yes, one without much of dynamics, its on trac, bug report http://trac.ffmpeg.org/ticket/5649 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
>> Do we have a sample? > > Yes, one without much of dynamics, its on trac, bug report > http://trac.ffmpeg.org/ticket/5649 Thanks! (I only found the float tickets...) Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] 64-bit pcm signed support
On Wed, Aug 17, 2016 at 07:48:29PM +0200, Paul B Mahol wrote: > Hi, > > patches attached. > libavutil/samplefmt.c|2 ++ > libavutil/samplefmt.h|2 ++ > libswresample/audioconvert.c | 22 ++ > libswresample/swresample.c |3 ++- > 4 files changed, 28 insertions(+), 1 deletion(-) > 8601ff14a5d9ee52b12d24ef679d3dda7b635304 > 0001-swresample-add-int64-sample-format.patch > From dd0fa451f6d8bd2e266437e324f5b53bc8ebfdf8 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Wed, 17 Aug 2016 19:08:43 +0200 > Subject: [PATCH 1/2] swresample: add int64 sample format > > --- > libavutil/samplefmt.c| 2 ++ > libavutil/samplefmt.h| 2 ++ > libswresample/audioconvert.c | 22 ++ > libswresample/swresample.c | 3 ++- > 4 files changed, 28 insertions(+), 1 deletion(-) [...] > libavcodec/Makefile |4 > libavcodec/allcodecs.c |2 ++ > libavcodec/avcodec.h|6 +++--- > libavcodec/codec_desc.c | 14 ++ > libavcodec/pcm.c| 11 ++- > libavcodec/utils.c |3 +++ > libavformat/riff.c |1 + > libavformat/utils.c |2 ++ > 8 files changed, 39 insertions(+), 4 deletions(-) > 1840a20147e545516618f008ff51eb39d67165e4 > 0002-avcodec-add-64-bit-signed-pcm-codec.patch > From e250151d7aba48d8d9e9e2e82329f321a8ad8a2d Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Wed, 17 Aug 2016 19:46:21 +0200 > Subject: [PATCH 2/2] avcodec: add 64-bit signed pcm codec > > --- > libavcodec/Makefile | 4 > libavcodec/allcodecs.c | 2 ++ > libavcodec/avcodec.h| 6 +++--- > libavcodec/codec_desc.c | 14 ++ > libavcodec/pcm.c| 11 ++- > libavcodec/utils.c | 3 +++ > libavformat/riff.c | 1 + > libavformat/utils.c | 2 ++ > 8 files changed, 39 insertions(+), 4 deletions(-) patches LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] h264_qsv decoder speed
On 17/08/16 20:47, Chao Liu wrote: > Hi there, > I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode. > There is pretty big speed gap. I wonder whether I did sth. wrong or there > are really some problems with ffmpeg's implementation.. > > The test video was captured from a 3MP(2048x1536) camera. The commands I > used: > - ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f null > /dev/null > - sample_decode h264 -i test.h264 > Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got > 370FPS. > > I haven't got time debugging into this. Sending this out to see whether you > guys might have sth. in mind.. I think in both cases your speed bound must be on something other than the decode, because the hardware goes a lot faster than either of those for me. Perhaps you are downloading the all of the output frames to normal memory in order to write them to a null device output, and one of the cases is doing that less efficiently somehow? Using vaapi on a low-power Haswell mobile chip (i.e. the same Quick Sync hardware that libmfx uses) decodes a single 2048x1536 stream at around 800fps with less than 50% CPU for me. - Mark (My command to compare is: ./ffmpeg_g -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i input.mp4 -an -vf 'format=nv12|vaapi,hwupload' -f null - The nasty filtering there is contrived to do nothing, even with the inconvenient stream reinitialisation. I think libmfx might also work somehow with "-c:v h264_qsv -hwaccel qsv", but I'm not sure and I don't have anything to try it on right now.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2 2/3] avformat: factorize iso 8601 timestamp writer to a dictionary avutil function
On Sun, 14 Aug 2016, Marton Balint wrote: On Mon, 11 Jul 2016, Marton Balint wrote: On Sat, 2 Jul 2016, James Almer wrote: On 7/2/2016 7:10 PM, Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/internal.h | 1 + libavformat/utils.c| 16 ++-- libavutil/dict.c | 17 + libavutil/internal.h | 10 ++ 4 files changed, 30 insertions(+), 14 deletions(-) diff --git a/libavformat/internal.h b/libavformat/internal.h index 647ad65..3ec4b0c 100644 --- a/libavformat/internal.h +++ b/libavformat/internal.h @@ -24,6 +24,7 @@ #include #include "libavutil/bprint.h" +#include "libavutil/internal.h" utils.c already includes this, so no need to include it here. Don't resend the patch just for this. Wait for a real review, or locally fix and apply if there's no need for another patch revision. Thanks, fixed locally. Ping for the patch and for the rest of the series. Will apply this soon. Applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] examples/demuxing_decoding: convert to codecpar
On 8/17/2016 1:21 AM, James Almer wrote: > On 8/10/2016 1:20 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> doc/examples/demuxing_decoding.c | 33 ++--- >> 1 file changed, 22 insertions(+), 11 deletions(-) > > I'll be pushing this soon unless someone objects. Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avisynth: support pix_fmts added to AviSynth+
On 8/16/2016 6:45 PM, Stephen Hutchinson wrote: A number of new pix_fmts have been added to AviSynth+: 16-bit packed RGB and RGBA 10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4 8-, 10-, 12-, 14-, and 16-bit Planar RGB 8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA* 10-, 12-, 14-, and 16-bit GRAY variants* 32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY* *some of which are not currently available pix_fmts here and were not added to the demuxer due to this --- libavformat/avisynth.c | 183 - 1 file changed, 182 insertions(+), 1 deletion(-) Ping on updated main patch. Only the header update got committed earlier. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] h264_qsv decoder speed
Mark Thompson wrote: On 17/08/16 20:47, Chao Liu wrote: Hi there, I compared h264_qsv decoder from ffmpeg to intel media sdk sample_decode. There is pretty big speed gap. I wonder whether I did sth. wrong or there are really some problems with ffmpeg's implementation.. The test video was captured from a 3MP(2048x1536) camera. The commands I used: - ffmpeg -c:v h264_qsv -async_depth 10 -i test.h264 -c:v rawvideo -f null /dev/null - sample_decode h264 -i test.h264 Both uses 100% cpu (a full core). ffmpeg got 170FPS. sample_decode got 370FPS. I haven't got time debugging into this. Sending this out to see whether you guys might have sth. in mind.. I think in both cases your speed bound must be on something other than the decode, because the hardware goes a lot faster than either of those for me. Perhaps you are downloading the all of the output frames to normal memory in order to write them to a null device output, and one of the cases is doing that less efficiently somehow? Only tested with AMD UVD, but unless you use -pix_fmt nv12 you will also get cpu load from ffmpeg doing nv12 -> yuv420p conversion. Using vaapi on a low-power Haswell mobile chip (i.e. the same Quick Sync hardware that libmfx uses) decodes a single 2048x1536 stream at around 800fps with less than 50% CPU for me. - Mark (My command to compare is: ./ffmpeg_g -vaapi_device /dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -i input.mp4 -an -vf 'format=nv12|vaapi,hwupload' -f null - Oh nice, I always wondered if there was a way to bench without copy back. The nasty filtering there is contrived to do nothing, even with the inconvenient stream reinitialisation. I think libmfx might also work somehow with "-c:v h264_qsv -hwaccel qsv", but I'm not sure and I don't have anything to try it on right now.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
