Re: [libav-devel] [PATCH] OpenEXR decoder
On Sun, Mar 23, 2014 at 4:07 PM, Vittorio Giovara wrote: > From: Jimmy Christensen > > Additional fixes and enhancements by Vittorio Giovara, Gonzalo Garramuno, > Nicolas George, Paul B Mahol and Michael Niedermayer. > > Signed-off-by: Vittorio Giovara > --- > Now threading is fixed and removed an unused function. > Cheers, > Vittorio > > Changelog |1 + > configure |1 + > doc/general.texi|2 + > libavcodec/Makefile |1 + > libavcodec/allcodecs.c |1 + > libavcodec/avcodec.h|1 + > libavcodec/codec_desc.c |8 + > libavcodec/exr.c| 1342 > +++ > libavcodec/version.h|4 +- > libavformat/img2.c |1 + > libavformat/isom.c |1 + > 11 files changed, 1361 insertions(+), 2 deletions(-) > create mode 100644 libavcodec/exr.c > Any more comments? Can this go in? Thanks -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] af_volume: implement replaygain pre-amplification
On 03/25/2014 09:55 AM, Alessandro Ghedini wrote:
> This adds a new "replaygain-preamp" option to the filter, and simply adds its
> value to the replaygain gain value.
> ---
> doc/filters.texi| 6 ++
> libavfilter/af_volume.c | 4 +++-
> libavfilter/af_volume.h | 1 +
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 93625c6..4a737ef 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -633,6 +633,12 @@ Prefer track gain, if present.
> @item album
> Prefer album gain, if present.
> @end table
> +
> +@item replaygain-preamp
> +Pre-amplification gain in dB to apply to the selected replaygain gain.
> +
> +Default value for @var{replaygain-preamp} is 0.0.
> +
> @end table
>
> @subsection Examples
> diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
> index 165624e..3ad1850 100644
> --- a/libavfilter/af_volume.c
> +++ b/libavfilter/af_volume.c
> @@ -59,6 +59,8 @@ static const AVOption options[] = {
> { "ignore", "replaygain side data is ignored", 0, AV_OPT_TYPE_CONST,
> { .i64 = REPLAYGAIN_IGNORE }, 0, 0, A, "replaygain" },
> { "track", "track gain is preferred", 0, AV_OPT_TYPE_CONST,
> { .i64 = REPLAYGAIN_TRACK }, 0, 0, A, "replaygain" },
> { "album", "album gain is preferred", 0, AV_OPT_TYPE_CONST,
> { .i64 = REPLAYGAIN_ALBUM }, 0, 0, A, "replaygain" },
> +{ "replaygain-preamp", "Apply replaygain pre-amplification",
> +OFFSET(replaygain_preamp), AV_OPT_TYPE_DOUBLE, { .dbl = 0.0 },
> 0, 0x7f, A },
That's an odd-looking maximum. Any particular reason for that value?
-Justin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/4] flacdec: export replaygain tags from Vorbis comments
On 03/25/2014 09:55 AM, Alessandro Ghedini wrote: > --- > libavformat/flacdec.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c > index ecbb7ec..11360a9 100644 > --- a/libavformat/flacdec.c > +++ b/libavformat/flacdec.c > @@ -26,6 +26,7 @@ > #include "rawdec.h" > #include "oggdec.h" > #include "vorbiscomment.h" > +#include "replaygain.h" > #include "libavcodec/bytestream.h" > > static int flac_read_header(AVFormatContext *s) > @@ -146,6 +147,10 @@ static int flac_read_header(AVFormatContext *s) > } > } > > +ret = ff_replaygain_export(st, s->metadata); > +if (ret < 0) > +return ret; > + > return 0; > } > Looks ok. -Justin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] h263: improve hwaccel #ifdefs
On 25/03/14 22:19, Rémi Denis-Courmont wrote:
> ---
> libavcodec/h263dec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index 6c2f322..f6c79af 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -634,10 +634,10 @@ intrax8_decoded:
> }
>
> const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
> -#if CONFIG_VAAPI
> +#if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
> AV_PIX_FMT_VAAPI_VLD,
> #endif
> -#if CONFIG_VDPAU
> +#if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
> AV_PIX_FMT_VDPAU,
> #endif
> AV_PIX_FMT_YUV420P,
>
Looks fine to me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] vc1dec: improve hwaccel #ifdefs
On 25/03/14 22:19, Rémi Denis-Courmont wrote:
> ---
> libavcodec/vc1dec.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
> index f8340ee..e6bbe58 100644
> --- a/libavcodec/vc1dec.c
> +++ b/libavcodec/vc1dec.c
> @@ -6122,13 +6122,13 @@ static const AVProfile profiles[] = {
> };
>
> static const enum AVPixelFormat vc1_hwaccel_pixfmt_list_420[] = {
> -#if CONFIG_DXVA2
> +#if CONFIG_VC1_DXVA2_HWACCEL
> AV_PIX_FMT_DXVA2_VLD,
> #endif
> -#if CONFIG_VAAPI
> +#if CONFIG_VC1_VAAPI_HWACCEL
> AV_PIX_FMT_VAAPI_VLD,
> #endif
> -#if CONFIG_VDPAU
> +#if CONFIG_VC1_VDPAU_HWACCEL
> AV_PIX_FMT_VDPAU,
> #endif
> AV_PIX_FMT_YUV420P,
>
Looks fine to me.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] vc1dec: improve hwaccel #ifdefs
---
libavcodec/vc1dec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index f8340ee..e6bbe58 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -6122,13 +6122,13 @@ static const AVProfile profiles[] = {
};
static const enum AVPixelFormat vc1_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_DXVA2
+#if CONFIG_VC1_DXVA2_HWACCEL
AV_PIX_FMT_DXVA2_VLD,
#endif
-#if CONFIG_VAAPI
+#if CONFIG_VC1_VAAPI_HWACCEL
AV_PIX_FMT_VAAPI_VLD,
#endif
-#if CONFIG_VDPAU
+#if CONFIG_VC1_VDPAU_HWACCEL
AV_PIX_FMT_VDPAU,
#endif
AV_PIX_FMT_YUV420P,
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] h263: improve hwaccel #ifdefs
---
libavcodec/h263dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 6c2f322..f6c79af 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -634,10 +634,10 @@ intrax8_decoded:
}
const enum AVPixelFormat ff_h263_hwaccel_pixfmt_list_420[] = {
-#if CONFIG_VAAPI
+#if CONFIG_H263_VAAPI_HWACCEL || CONFIG_MPEG4_VAAPI_HWACCEL
AV_PIX_FMT_VAAPI_VLD,
#endif
-#if CONFIG_VDPAU
+#if CONFIG_H263_VDPAU_HWACCEL || CONFIG_MPEG4_VDPAU_HWACCEL
AV_PIX_FMT_VDPAU,
#endif
AV_PIX_FMT_YUV420P,
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 07/10] lavu: add a pixel format for new VDA hwaccel
Le lundi 24 mars 2014, 22:44:51 wm4 a écrit : > > You configure the decoder, you feed it the surfaces. All hwaccel was > > doing was just feed the decoder the slices and get back the opaque > > frames to you. > Yes, but you still need to create the surface. Now assume you created a > decoder that expects 422 surfaces, and you give it 420 surfaces. It > will probably break. And the hwaccel API user basically can't know > which format it should use to create surfaces. > > So yes, I'm starting to see a problem here too. It's not a current > problem because everything assumes 420, but as hardware decoders gain > more features, it could become one. Though 422 would presumably be a lot less invasive to the hardware design than 9/10-bits, still extra transistors mean larger die which means higher costs... This would only make sense if there were a big market push for 422. I am actually more concerned about get_format() passing more than one software pixel format at once, than about hardware acceleration supporting 422, in the future. If the choice were between NV12 and YV12, there would be no ambiguity regarding the bits depth and colour subsampling. But if it were between 8-bits and 10-bits (say because a codec supported high-depth as an enhancement layer) or between 420 and 422, then using "the" software pixel format as reference would no longer work. In fact, it would no longer mean anything. My view is that so long as get_format() is used to select hardware acceleration, it needs provision to convey the surface type(s) and select it if there are more than one possibilities. There may be other ways to achieve it than multiplying pixel formats, but overloading the meaning of "the" software pixel format within the list does not seem very robust or future- proof. -- Rémi Denis-Courmont http://www.remlab.net/ ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 0/6] truehd: ARM optimisations
On Tue, 25 Mar 2014 16:28:47 -, Martin Storsjö wrote: All in all the series looks ok - any objections to me pushing this any day soon, with "it ne" added before the conditional branches to C functions, and with the altmacro parameter changed to use normal parameter syntax (offset vs \offset in patch 1/6)? Go for it. I didn't want to keep spamming the list with more and more reposts of the series with only relatively minor and cosmetic changes, so I was waiting for things to die down, but I'm also happy for you to make the changes at the time you commit them. Ben ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add AVDisplayOrientation type as AVPacket and AVFrame side data.
2014-03-26 2:26 GMT+09:00 Vittorio Giovara :
> On Tue, Mar 25, 2014 at 3:48 PM, wm4 wrote:
> > On Tue, 25 Mar 2014 15:31:49 +0100
> > Vittorio Giovara wrote:
> >
>
> >> +/**
> >> + * Spatial transformation information that should be applied to video
> >> + * after decoding.
> >> + *
> >> + * Note that these values are not mutually exclusive.
> >> + *
> >> + * The size of this struct is a part of the public ABI.
> >> + */
> >> +typedef struct AVDisplayOrientation {
> >> +/**
> >> + * Video should be orizontally flipped.
> >> + */
> >> +int hflip;
> >> +/**
> >> + * Video should be vertically flipped.
> >> + */
> >> +int vflip;
> >> +/**
> >> + * Rotation angle to be applied in degrees.
> >> + */
> >> +int32_t rotation;
> >> +} AVDisplayOrientation;
> >
> > So, why not just export the full matrix?
>
> Overkill and HardMath imho.
>
I don't think so :P
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add AVDisplayOrientation type as AVPacket and AVFrame side data.
On Tue, Mar 25, 2014 at 3:48 PM, wm4 wrote:
> On Tue, 25 Mar 2014 15:31:49 +0100
> Vittorio Giovara wrote:
>
>
>> +
>> +/**
>> + * An AV_PKT_DATA_ROTATION side data packet contains further spatial
>> information
>> + * to be applied to the decoded video.
>> + */
>> +AV_PKT_DATA_DISPLAYORIENTATION,
>> };
>
> Completely lacks documentation in what format the data is. It can be
> easily inferred from the rest of the patch, but an API user reading
> avcodec.h can't.
>
>
True, I'll amend that.
>> +/**
>> + * Spatial transformation information that should be applied to video
>> + * after decoding.
>> + *
>> + * Note that these values are not mutually exclusive.
>> + *
>> + * The size of this struct is a part of the public ABI.
>> + */
>> +typedef struct AVDisplayOrientation {
>> +/**
>> + * Video should be orizontally flipped.
>> + */
>> +int hflip;
>> +/**
>> + * Video should be vertically flipped.
>> + */
>> +int vflip;
>> +/**
>> + * Rotation angle to be applied in degrees.
>> + */
>> +int32_t rotation;
>> +} AVDisplayOrientation;
>
> So, why not just export the full matrix?
Overkill and HardMath imho.
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC 0/4] More ReplayGain
On mar, mar 25, 2014 at 11:17:49 -0400, Justin Ruggles wrote:
> On 03/25/2014 09:55 AM, Alessandro Ghedini wrote:
> >The patches should be more or less self-explanatory. I've also looked into
> >exporting replaygain data from ogg vorbis files, but I could not figure out
> >where to add the ff_replaygain_export() call. Help on that would be
> >appreciated.
>
> In libavformat/oggparsevorbis.c after the call to ff_vorbis_comment().
Ah, yes. That works, thanks.
Cheers
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;;eg;say~~reverse'
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 0/6] truehd: ARM optimisations
On Thu, 20 Mar 2014, Ben Avison wrote: An updated patch series. The main difference here is that for Thumb targets, it's assumed that interworking is not supported, so individual functions are either assembled as Thumb, or omitted if they cannot be supported without a major refactoring. Ben Avison (6): truehd: add hand-scheduled ARM asm version of mlp_filter_channel. truehd: break out part of rematrix_channels into platform-specific callback. truehd: add hand-scheduled ARM asm version of ff_mlp_rematrix_channel. truehd: tune VLC decoding for ARM. truehd: break out part of output_data into platform-specific callback. truehd: add hand-scheduled ARM asm version of ff_mlp_pack_output. libavcodec/arm/Makefile |3 + libavcodec/arm/mlpdsp_arm.S | 655 ++ libavcodec/arm/mlpdsp_armv6.S| 530 ++ libavcodec/arm/mlpdsp_init_arm.c | 144 + libavcodec/mlpdec.c | 90 +++--- libavcodec/mlpdsp.c | 73 + libavcodec/mlpdsp.h | 46 +++ 7 files changed, 1496 insertions(+), 45 deletions(-) create mode 100644 libavcodec/arm/mlpdsp_arm.S create mode 100644 libavcodec/arm/mlpdsp_armv6.S create mode 100644 libavcodec/arm/mlpdsp_init_arm.c All in all the series looks ok - any objections to me pushing this any day soon, with "it ne" added before the conditional branches to C functions, and with the altmacro parameter changed to use normal parameter syntax (offset vs \offset in patch 1/6)? // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/6] truehd: break out part of output_data into platform-specific callback.
On Thu, 20 Mar 2014, Ben Avison wrote: Verified with profiling that this doesn't have a measurable effect upon overall performance. --- libavcodec/mlpdec.c | 40 +++- libavcodec/mlpdsp.c | 38 ++ libavcodec/mlpdsp.h | 22 ++ 3 files changed, 83 insertions(+), 17 deletions(-) diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c index b9d1704..49353d9 100644 --- a/libavcodec/mlpdec.c +++ b/libavcodec/mlpdec.c @@ -360,6 +360,10 @@ static int read_major_sync(MLPDecodeContext *m, GetBitContext *gb) m->avctx->sample_fmt = AV_SAMPLE_FMT_S32; else m->avctx->sample_fmt = AV_SAMPLE_FMT_S16; +m->dsp.mlp_pack_output = m->dsp.mlp_select_pack_output(m->substream[m->max_decoded_substream].ch_assign, + m->substream[m->max_decoded_substream].output_shift, + m->substream[m->max_decoded_substream].max_matrix_channel, + m->avctx->sample_fmt == AV_SAMPLE_FMT_S32); I'm not sure if this is the right way to do this, or if the mlp_packet_output function pointer should be in MLPDecodeContext instead? Practically it probably doesn't matter though. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Add dvd subtitle support
On Tue, 25 Mar 2014 07:42:55 -0600 John Stebbins wrote: > On 03/18/2014 08:50 AM, John Stebbins wrote: > > --- > > libavformat/movenc.c | 83 > > > > 1 file changed, 78 insertions(+), 5 deletions(-) > > ping. any additional comments? > Not from me. Seems to look ok as far as I can judge that. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC 0/4] More ReplayGain
On 03/25/2014 09:55 AM, Alessandro Ghedini wrote: The patches should be more or less self-explanatory. I've also looked into exporting replaygain data from ogg vorbis files, but I could not figure out where to add the ff_replaygain_export() call. Help on that would be appreciated. In libavformat/oggparsevorbis.c after the call to ff_vorbis_comment(). -Justin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RFC 0/4] More ReplayGain
I've been working on porting the mpv's af_volume replaygain support to using the libav side data (using libav's af_volume still doesn't work with mpv), and these are a few fixes to help in that. I've also added additional features (preamp and clipping prevention) to af_volume. The patches should be more or less self-explanatory. I've also looked into exporting replaygain data from ogg vorbis files, but I could not figure out where to add the ff_replaygain_export() call. Help on that would be appreciated. Alessandro Ghedini (4): replaygain: correctly parse peak values flacdec: export replaygain tags from Vorbis comments af_volume: implement replaygain pre-amplification af_volume: implement replaygain clipping prevention doc/filters.texi | 6 ++ libavfilter/af_volume.c | 31 ++- libavfilter/af_volume.h | 1 + libavformat/flacdec.c| 5 + libavformat/replaygain.c | 35 +++ libavutil/replaygain.h | 3 +-- 6 files changed, 50 insertions(+), 31 deletions(-) -- 1.9.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Add dvd subtitle support
On 18/03/14 15:50, John Stebbins wrote: > --- > libavformat/movenc.c | 83 > > 1 file changed, 78 insertions(+), 5 deletions(-) > Looks fine to me as well. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] FYI: avconv LUA wrapper
On 25/03/14 14:15, Enrique Arizón Benito wrote: > Hi, > > I'm developing an small project that required to call avconv from LUA ( > http://www.lua.org/). > > After a few trials I managed to wrap the avconv main function to be called > directly from a LUA script, so that exceptions are captured by the LUA > exception mechanism (an small improvement over creating an avconv > subprocess and parsing the ouput). Sounds neat =) > Since I don't want to reinvent the wheel I wonder whether there is > something already developed. I couldn't find anything related "googling > around". Otherwise, If anyone is interested on the LUA wrapper, just let me > know. Not that I know. > The LUA+avconv wrapper scripts looks something similar to: > > -- Description > -- Take a thumbnail of a given video. > myVideo = "-i myVideo.mp4" > outputThumbnail = "myVideo.png" > cmd = "" > cmd = cmd .. myVideo > cmd = cmd .. "-ss 00:00:15.000 " > cmd = cmd .. "-f image2 " > cmd = cmd .. "-vframes 1 " > cmd = cmd .. outputThumbnail I'm quite sure some people would find it extremely useful. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 10/10] avconv: Support VDA hwaccel
On Mon, Mar 24, 2014 at 03:01:54AM +0100, Luca Barbato wrote: > --- a/Makefile > +++ b/Makefile > @@ -75,6 +75,7 @@ $(foreach prog,$(AVBASENAMES),$(eval OBJS-$(prog) += > cmdutils.o)) > > OBJS-avconv += avconv_opt.o avconv_filter.o > OBJS-avconv-$(HAVE_VDPAU_X11) += avconv_vdpau.o > +OBJS-avconv-$(CONFIG_VDA) += avconv_vda.o order > --- /dev/null > +++ b/avconv_vda.c > @@ -0,0 +1,134 @@ > + > +#include "libavcodec/avcodec.h" > +#include "libavcodec/vda.h" > +#include "libavutil/imgutils.h" > + > +#include "avconv.h" canonical header order Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Add AVDisplayOrientation type as AVPacket and AVFrame side data.
On Tue, 25 Mar 2014 15:31:49 +0100
Vittorio Giovara wrote:
> +
> +/**
> + * An AV_PKT_DATA_ROTATION side data packet contains further spatial
> information
> + * to be applied to the decoded video.
> + */
> +AV_PKT_DATA_DISPLAYORIENTATION,
> };
Completely lacks documentation in what format the data is. It can be
easily inferred from the rest of the patch, but an API user reading
avcodec.h can't.
> +/**
> + * Spatial transformation information that should be applied to video
> + * after decoding.
> + *
> + * Note that these values are not mutually exclusive.
> + *
> + * The size of this struct is a part of the public ABI.
> + */
> +typedef struct AVDisplayOrientation {
> +/**
> + * Video should be orizontally flipped.
> + */
> +int hflip;
> +/**
> + * Video should be vertically flipped.
> + */
> +int vflip;
> +/**
> + * Rotation angle to be applied in degrees.
> + */
> +int32_t rotation;
> +} AVDisplayOrientation;
So, why not just export the full matrix?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] lavu: add all color-related enums to AVFrame
On Tue, Mar 25, 2014 at 1:12 PM, wm4 wrote: > --- > doc/APIchanges | 5 > libavcodec/avcodec.h | 67 > > libavutil/frame.c| 10 > libavutil/frame.h| 30 +++ > libavutil/pixfmt.h | 62 > libavutil/version.h | 2 +- > 6 files changed, 108 insertions(+), 68 deletions(-) I think this is fine, I'll wait for some more feedback and then apply it in the next days. Thanks for the contribution. Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] Add AVDisplayOrientation type as AVPacket and AVFrame side data.
Implement exporting rotation angle from mov.
---
This is redone following more what has been done for replaygain.
Note that showinfo still reports the display orientation data only ONCE, and I
am not sure if this is the expected behaviour.
Note 2, the hflip and vflip computation are theoretical as I couldn't find a
sample implementing it, but they still might be useful later on.
It has been requested that an enum might be added to represent simple tranforms
but I'm not sure if AVDisplayOrientation is the right place to it.
Cheers,
Vittorio
Changelog | 1 +
doc/APIchanges | 7 ++
libavcodec/avcodec.h | 6 +
libavcodec/utils.c | 9 +++
libavformat/isom.h | 3 +++
libavformat/mov.c | 53 ++
libavutil/Makefile | 1 +
libavutil/displayorientation.h | 47 +
libavutil/frame.h | 4
libavutil/version.h| 2 +-
10 files changed, 132 insertions(+), 1 deletion(-)
create mode 100644 libavutil/displayorientation.h
diff --git a/Changelog b/Changelog
index 76eca07..53b62b0 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
- libx265 encoder
- shuffleplanes filter
- replaygain data export
+- rotation angle export
version 10:
diff --git a/doc/APIchanges b/doc/APIchanges
index d800253..8ae734c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,13 @@ libavutil: 2013-12-xx
API changes, most recent first:
+2014-02-xx - xxx - lavu 53.09.0 - frame.h, displayorientation.h
+ Add AV_FRAME_DATA_DISPLAYORIENTATION for exporting further
+ spatial rendering the video should do for proper display.
+
+2014-02-11 - xxx - lavc 55.37.0 - avcodec.h
+ Add AV_PKT_DATA_DISPLAYORIENTATION for exporting display orientation.
+
2014-02-xx - xxx - lavu 53.08.0 - frame.h
Add av_frame_remove_side_data() for removing a single side data
instance from a frame.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 4fda36e..e8425b8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -929,6 +929,12 @@ enum AVPacketSideDataType {
* ReplayGain information in form of the AVReplayGain struct.
*/
AV_PKT_DATA_REPLAYGAIN,
+
+/**
+ * An AV_PKT_DATA_ROTATION side data packet contains further spatial
information
+ * to be applied to the decoded video.
+ */
+AV_PKT_DATA_DISPLAYORIENTATION,
};
typedef struct AVPacketSideData {
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e04f455..1c031e0 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -597,6 +597,15 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
memcpy(frame_sd->data, packet_sd, size);
}
+/* copy rotation angle to the output frame */
+packet_sd = av_packet_get_side_data(pkt, AV_PKT_DATA_DISPLAYORIENTATION,
&size);
+if (packet_sd) {
+frame_sd = av_frame_new_side_data(frame,
AV_FRAME_DATA_DISPLAYORIENTATION, size);
+if (!frame_sd)
+return AVERROR(ENOMEM);
+
+memcpy(frame_sd->data, packet_sd, size);
+}
return 0;
}
diff --git a/libavformat/isom.h b/libavformat/isom.h
index bf0792c..b3da4cb 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -135,6 +135,9 @@ typedef struct MOVStreamContext {
int64_t track_end;///< used for dts generation in fragmented movie
files
unsigned int rap_group_count;
MOVSbgp *rap_group;
+int hflip;///< horizontal translation derived from the
display_matrix
+int vflip;///< vertical translation derived from the
display_matrix
+int32_t rotation; ///< rotation angle derived from the display_matrix
} MOVStreamContext;
typedef struct MOVContext {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6375847..e35fe44 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -31,6 +31,7 @@
#include "libavutil/attributes.h"
#include "libavutil/channel_layout.h"
+#include "libavutil/displayorientation.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/intfloat.h"
#include "libavutil/mathematics.h"
@@ -2254,6 +2255,28 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
sc->width = width >> 16;
sc->height = height >> 16;
+// get display orientation info when the matrix is not the identity one
+if (display_matrix[0][1] || display_matrix[1][0] ||
+display_matrix[2][0] || display_matrix[2][1]) {
+double rotationf, scale[2];
+#define CONV_FP(x) ((double) (x)) / 65536
+scale[0] = sqrt(CONV_FP(display_matrix[0][0]) *
CONV_FP(display_matrix[0][0]) +
+CONV_FP(display_matrix[1][0]) *
CONV_FP(display_matrix[1][0]));
+scale[1] = sqrt(CONV_FP(display_matrix[0][1]) *
CONV_FP(display_matrix[0][1]) +
+CONV_FP(display_matrix[1][1]) *
CONV
[libav-devel] [PATCH 2/2] vf_showinfo: print display orientation values
---
libavfilter/vf_showinfo.c | 20
1 file changed, 20 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 031d8fe..80bd33d 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -25,8 +25,10 @@
#include
#include "libavutil/adler32.h"
+#include "libavutil/displayorientation.h"
#include "libavutil/imgutils.h"
#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
#include "libavutil/pixdesc.h"
#include "libavutil/stereo3d.h"
@@ -68,6 +70,21 @@ static void dump_stereo3d(AVFilterContext *ctx,
AVFrameSideData *sd)
av_log(ctx, AV_LOG_INFO, " (inverted)");
}
+static void dump_displayorientation(AVFilterContext *ctx, AVFrameSideData *sd)
+{
+AVDisplayOrientation *display;
+
+av_log(ctx, AV_LOG_INFO, "display orientation: ");
+if (sd->size < sizeof(*display)) {
+av_log(ctx, AV_LOG_INFO, "invalid data");
+return;
+}
+
+display = (AVDisplayOrientation *)sd->data;
+av_log(ctx, AV_LOG_INFO, "hflip %d vflip %d ", display->hflip,
display->vflip);
+av_log(ctx, AV_LOG_INFO, "rotation angle %d degrees", display->rotation);
+}
+
static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
{
AVFilterContext *ctx = inlink->dst;
@@ -117,6 +134,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
case AV_FRAME_DATA_STEREO3D:
dump_stereo3d(ctx, sd);
break;
+case AV_FRAME_DATA_DISPLAYORIENTATION:
+dump_displayorientation(ctx, sd);
+break;
default:
av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)",
sd->type, sd->size);
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/4] replaygain: correctly parse peak values
According to the ReplayGain spec, the peak amplitude may overflow and may result
in peak amplitude values greater than 1.0 with psychoacoustically coded audio,
such as MP3. Fully compliant decoders must allow peak overflows.
Additionally, having peak values in the 0<->UINT32_MAX scale makes it more
difficult for applications to actually use the peak values (e.g. when
implementing clipping prevention) since values have to be rescaled down.
This patch corrects the peak parsing by removing the rescaling of the decoded
values between 0 and UINT32_MAX and the 1.0 upper limit.
---
libavformat/replaygain.c | 35 +++
libavutil/replaygain.h | 3 +--
2 files changed, 16 insertions(+), 22 deletions(-)
diff --git a/libavformat/replaygain.c b/libavformat/replaygain.c
index cf4dbf8..d4d3d1a 100644
--- a/libavformat/replaygain.c
+++ b/libavformat/replaygain.c
@@ -64,34 +64,29 @@ static int32_t parse_gain(const char *gain)
static uint32_t parse_peak(const uint8_t *peak)
{
-int64_t val = 0;
-int64_t scale = 1;
+char *fraction;
+unsigned int scale = 1;
+uint32_t mb = 0;
+unsigned int db;
if (!peak)
return 0;
peak += strspn(peak, " \t");
-if (peak[0] == '1' && peak[1] == '.')
-return UINT32_MAX;
-else if (!(peak[0] == '0' && peak[1] == '.'))
-return 0;
-
-peak += 2;
-
-while (av_isdigit(*peak)) {
-int digit = *peak - '0';
-
-if (scale > INT64_MAX / 10)
-break;
-
-val= 10 * val + digit;
-scale *= 10;
-
-peak++;
+db = strtol(peak, &fraction, 0);
+if (*fraction++ == '.') {
+while (av_isdigit(*fraction) && scale) {
+mb += scale * (*fraction - '0');
+scale /= 10;
+fraction++;
+}
}
-return av_rescale(val, UINT32_MAX, scale);
+if (db > (UINT32_MAX - mb) / 10)
+return 0;
+
+return db * 10 + mb;
}
static int replaygain_export(AVStream *st,
diff --git a/libavutil/replaygain.h b/libavutil/replaygain.h
index 8447703..00d2873 100644
--- a/libavutil/replaygain.h
+++ b/libavutil/replaygain.h
@@ -34,8 +34,7 @@ typedef struct AVReplayGain {
*/
int32_t track_gain;
/**
- * Peak track amplitude, with UINT32_MAX representing full scale. 0 when
- * unknown.
+ * Peak track amplitude. 0 when unknown.
*/
uint32_t track_peak;
/**
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/4] lavc: copy rotation angle from packet to frame
> +/* copy rotation angle to the output frame */ > +packet_sd = av_packet_get_side_data(pkt, AV_PKT_DATA_ROTATION, &size); I guess you'll want to factor this out because as far as I can tell it's the same operation as replaygain. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 4/4] af_volume: implement replaygain clipping prevention
---
libavfilter/af_volume.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
index 3ad1850..47c1806 100644
--- a/libavfilter/af_volume.c
+++ b/libavfilter/af_volume.c
@@ -247,24 +247,35 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*buf)
if (vol->replaygain != REPLAYGAIN_DROP) {
AVReplayGain *replaygain = (AVReplayGain*)sd->data;
int32_t gain;
-float g;
-
-if (vol->replaygain == REPLAYGAIN_TRACK &&
-replaygain->track_gain != INT32_MIN)
-gain = replaygain->track_gain;
-else if (replaygain->album_gain != INT32_MIN)
-gain = replaygain->album_gain;
-else {
+uint32_t peak;
+float g, p;
+
+if (vol->replaygain == REPLAYGAIN_TRACK) {
+if (replaygain->track_gain != INT32_MIN)
+gain = replaygain->track_gain;
+
+if (replaygain->track_peak != 0)
+peak = replaygain->track_peak;
+} else if (vol->replaygain == REPLAYGAIN_ALBUM) {
+if (replaygain->album_gain != INT32_MIN)
+gain = replaygain->album_gain;
+
+if (replaygain->album_peak != 0)
+peak = replaygain->album_peak;
+} else {
av_log(inlink->dst, AV_LOG_WARNING, "Both ReplayGain gain "
"values are unknown.\n");
gain = 10;
+peak = 10;
}
g = gain / 10.0f;
+p = peak / 10.0f;
av_log(inlink->dst, AV_LOG_VERBOSE,
"Using gain %f dB from replaygain side data.\n", g);
vol->volume = pow(10, (g + vol->replaygain_preamp) / 20);
+vol->volume = FFMIN(vol->volume, 1.0 / p);
vol->volume_i = (int)(vol->volume * 256 + 0.5);
volume_init(vol);
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/4] flacdec: export replaygain tags from Vorbis comments
--- libavformat/flacdec.c | 5 + 1 file changed, 5 insertions(+) diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c index ecbb7ec..11360a9 100644 --- a/libavformat/flacdec.c +++ b/libavformat/flacdec.c @@ -26,6 +26,7 @@ #include "rawdec.h" #include "oggdec.h" #include "vorbiscomment.h" +#include "replaygain.h" #include "libavcodec/bytestream.h" static int flac_read_header(AVFormatContext *s) @@ -146,6 +147,10 @@ static int flac_read_header(AVFormatContext *s) } } +ret = ff_replaygain_export(st, s->metadata); +if (ret < 0) +return ret; + return 0; } -- 1.9.1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/4] af_volume: implement replaygain pre-amplification
This adds a new "replaygain-preamp" option to the filter, and simply adds its
value to the replaygain gain value.
---
doc/filters.texi| 6 ++
libavfilter/af_volume.c | 4 +++-
libavfilter/af_volume.h | 1 +
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 93625c6..4a737ef 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -633,6 +633,12 @@ Prefer track gain, if present.
@item album
Prefer album gain, if present.
@end table
+
+@item replaygain-preamp
+Pre-amplification gain in dB to apply to the selected replaygain gain.
+
+Default value for @var{replaygain-preamp} is 0.0.
+
@end table
@subsection Examples
diff --git a/libavfilter/af_volume.c b/libavfilter/af_volume.c
index 165624e..3ad1850 100644
--- a/libavfilter/af_volume.c
+++ b/libavfilter/af_volume.c
@@ -59,6 +59,8 @@ static const AVOption options[] = {
{ "ignore", "replaygain side data is ignored", 0, AV_OPT_TYPE_CONST, {
.i64 = REPLAYGAIN_IGNORE }, 0, 0, A, "replaygain" },
{ "track", "track gain is preferred", 0, AV_OPT_TYPE_CONST, {
.i64 = REPLAYGAIN_TRACK }, 0, 0, A, "replaygain" },
{ "album", "album gain is preferred", 0, AV_OPT_TYPE_CONST, {
.i64 = REPLAYGAIN_ALBUM }, 0, 0, A, "replaygain" },
+{ "replaygain-preamp", "Apply replaygain pre-amplification",
+OFFSET(replaygain_preamp), AV_OPT_TYPE_DOUBLE, { .dbl = 0.0 }, 0,
0x7f, A },
{ NULL },
};
@@ -262,7 +264,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *buf)
av_log(inlink->dst, AV_LOG_VERBOSE,
"Using gain %f dB from replaygain side data.\n", g);
-vol->volume = pow(10, g / 20);
+vol->volume = pow(10, (g + vol->replaygain_preamp) / 20);
vol->volume_i = (int)(vol->volume * 256 + 0.5);
volume_init(vol);
diff --git a/libavfilter/af_volume.h b/libavfilter/af_volume.h
index ec13e80..d831ec4 100644
--- a/libavfilter/af_volume.h
+++ b/libavfilter/af_volume.h
@@ -47,6 +47,7 @@ typedef struct VolumeContext {
AVFloatDSPContext fdsp;
enum PrecisionType precision;
enum ReplayGainType replaygain;
+double replaygain_preamp;
double volume;
intvolume_i;
intchannels;
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] movenc: Add dvd subtitle support
On 03/18/2014 08:50 AM, John Stebbins wrote:
> ---
> libavformat/movenc.c | 83
>
> 1 file changed, 78 insertions(+), 5 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 2ae3475..f5b257b 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -308,7 +308,9 @@ static int mov_write_esds_tag(AVIOContext *pb, MOVTrack
> *track) // Basic
>
> // the following fields is made of 6 bits to identify the streamtype (4
> for video, 5 for audio)
> // plus 1 bit to indicate upstream and 1 bit set to 1 (reserved)
> -if (track->enc->codec_type == AVMEDIA_TYPE_AUDIO)
> +if (track->enc->codec_id == AV_CODEC_ID_DVD_SUBTITLE)
> +avio_w8(pb, (0x38 << 2) | 1); // flags (= NeroSubpicStream)
> +else if (track->enc->codec_type == AVMEDIA_TYPE_AUDIO)
> avio_w8(pb, 0x15); // flags (= Audiostream)
> else
> avio_w8(pb, 0x11); // flags (= Visualstream)
> @@ -759,6 +761,7 @@ static int mp4_get_codec_tag(AVFormatContext *s, MOVTrack
> *track)
> else if (track->enc->codec_id == AV_CODEC_ID_VC1) tag =
> MKTAG('v','c','-','1');
> else if (track->enc->codec_type == AVMEDIA_TYPE_VIDEO) tag =
> MKTAG('m','p','4','v');
> else if (track->enc->codec_type == AVMEDIA_TYPE_AUDIO) tag =
> MKTAG('m','p','4','a');
> +else if (track->enc->codec_id == AV_CODEC_ID_DVD_SUBTITLE) tag =
> MKTAG('m','p','4','s');
>
> return tag;
> }
> @@ -975,7 +978,9 @@ static int mov_write_subtitle_tag(AVIOContext *pb,
> MOVTrack *track)
> avio_wb16(pb, 0);/* Reserved */
> avio_wb16(pb, 1);/* Data-reference index */
>
> -if (track->enc->extradata_size)
> +if (track->enc->codec_id == AV_CODEC_ID_DVD_SUBTITLE)
> +mov_write_esds_tag(pb, track);
> +else if (track->enc->extradata_size)
> avio_write(pb, track->enc->extradata, track->enc->extradata_size);
>
> return update_size(pb, pos);
> @@ -1307,6 +1312,7 @@ static int mov_write_hdlr_tag(AVIOContext *pb, MOVTrack
> *track)
> descr = "SoundHandler";
> } else if (track->enc->codec_type == AVMEDIA_TYPE_SUBTITLE) {
> if (track->tag == MKTAG('t','x','3','g')) hdlr_type = "sbtl";
> +if (track->tag == MKTAG('m','p','4','s')) hdlr_type = "subp";
> else hdlr_type = "text";
> descr = "SubtitleHandler";
> } else if (track->enc->codec_tag == MKTAG('r','t','p',' ')) {
> @@ -3175,6 +3181,69 @@ static void mov_free(AVFormatContext *s)
> av_freep(&mov->tracks);
> }
>
> +static uint32_t rgb_to_yuv(uint32_t rgb)
> +{
> +uint8_t r, g, b;
> +int y, cb, cr;
> +
> +r = (rgb >> 16) & 0xFF;
> +g = (rgb >> 8) & 0xFF;
> +b = (rgb ) & 0xFF;
> +
> +y = av_clip_uint8( 16. + 0.257 * r + 0.504 * g + 0.098 * b);
> +cb = av_clip_uint8(128. - 0.148 * r - 0.291 * g + 0.439 * b);
> +cr = av_clip_uint8(128. + 0.439 * r - 0.368 * g - 0.071 * b);
> +
> +return (y << 16) | (cr << 8) | cb;
> +}
> +
> +static int mov_create_dvd_sub_decoder_specific_info(MOVTrack *track,
> +AVStream *st)
> +{
> +int i, width = 720, height = 480;
> +int have_palette = 0, have_size = 0;
> +uint32_t palette[16];
> +char *cur = st->codec->extradata;
> +
> +while (cur && *cur) {
> +if (strncmp("palette:", cur, 8) == 0) {
> +int i, count;
> +count = sscanf(cur + 8,
> +"%06x, %06x, %06x, %06x, %06x, %06x, %06x, %06x, "
> +"%06x, %06x, %06x, %06x, %06x, %06x, %06x, %06x",
> +&palette[ 0], &palette[ 1], &palette[ 2], &palette[ 3],
> +&palette[ 4], &palette[ 5], &palette[ 6], &palette[ 7],
> +&palette[ 8], &palette[ 9], &palette[10], &palette[11],
> +&palette[12], &palette[13], &palette[14], &palette[15]);
> +
> +for (i = 0; i < count; i++) {
> +palette[i] = rgb_to_yuv(palette[i]);
> +}
> +have_palette = 1;
> +} else if (!strncmp("size:", cur, 5)) {
> +sscanf(cur + 5, "%dx%d", &width, &height);
> +have_size = 1;
> +}
> +if (have_palette && have_size)
> +break;
> +cur += strcspn(cur, "\n\r");
> +cur += strspn(cur, "\n\r");
> +}
> +if (have_palette) {
> +track->vos_data = av_malloc(16*4);
> +if (!track->vos_data)
> +return AVERROR(ENOMEM);
> +for (i = 0; i < 16; i++) {
> +AV_WB32(track->vos_data + i * 4, palette[i]);
> +}
> +track->vos_len = 16 * 4;
> +}
> +st->codec->width = width;
> +st->codec->height = track->height = height;
> +
> +return 0;
> +}
> +
> static int mov_write_header(AVFormatContext *s)
> {
> AVIOContext *pb = s->pb;
> @@ -3331,9 +3400,13 @@
Re: [libav-devel] [PATCH] avconv: silence uninitialized variable clang warnings
nice
On Tue, Mar 25, 2014 at 10:49 AM, Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> ---
> avconv_opt.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/avconv_opt.c b/avconv_opt.c
> index 7bc41c9..1c10f33 100644
> --- a/avconv_opt.c
> +++ b/avconv_opt.c
> @@ -1301,7 +1301,7 @@ static int copy_chapters(InputFile *ifile,
> OutputFile *ofile, int copy_metadata)
> static void init_output_filter(OutputFilter *ofilter, OptionsContext *o,
> AVFormatContext *oc)
> {
> -OutputStream *ost;
> +OutputStream *ost = NULL;
>
> switch
> (avfilter_pad_get_type(ofilter->out_tmp->filter_ctx->output_pads,
>ofilter->out_tmp->pad_idx)) {
> @@ -1669,7 +1669,7 @@ loop_end:
>
> /* process manually set metadata */
> for (i = 0; i < o->nb_metadata; i++) {
> -AVDictionary **m;
> +AVDictionary **m = NULL;
> char type, *val;
> const char *stream_spec;
> int index = 0, j, ret;
> --
> 1.8.3.4 (Apple Git-47)
>
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
>
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] FYI: avconv LUA wrapper
Hi, I'm developing an small project that required to call avconv from LUA ( http://www.lua.org/). After a few trials I managed to wrap the avconv main function to be called directly from a LUA script, so that exceptions are captured by the LUA exception mechanism (an small improvement over creating an avconv subprocess and parsing the ouput). Since I don't want to reinvent the wheel I wonder whether there is something already developed. I couldn't find anything related "googling around". Otherwise, If anyone is interested on the LUA wrapper, just let me know. The LUA+avconv wrapper scripts looks something similar to: -- Description -- Take a thumbnail of a given video. myVideo = "-i myVideo.mp4" outputThumbnail = "myVideo.png" cmd = "" cmd = cmd .. myVideo cmd = cmd .. "-ss 00:00:15.000 " cmd = cmd .. "-f image2 " cmd = cmd .. "-vframes 1 " cmd = cmd .. outputThumbnail *avconv.run(cmd)*; Regards, Enrique ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] lavu: add all color-related enums to AVFrame
---
doc/APIchanges | 5
libavcodec/avcodec.h | 67
libavutil/frame.c| 10
libavutil/frame.h| 30 +++
libavutil/pixfmt.h | 62
libavutil/version.h | 2 +-
6 files changed, 108 insertions(+), 68 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index d800253..d18bd65 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,11 @@ libavutil: 2013-12-xx
API changes, most recent first:
+2014-xx-xx - xxx - lavu 53.09.0 - frame.h, pixfmt.h
+ Move all color-related enums (AVColorPrimaries, AVColorSpace, AVColorRange,
+ AVColorTransferCharacteristic, and AVChromaLocation) inside lavu, and add
+ AVFrame fields for them.
+
2014-02-xx - xxx - lavu 53.08.0 - frame.h
Add av_frame_remove_side_data() for removing a single side data
instance from a frame.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 4fda36e..0d0d71a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -546,73 +546,6 @@ enum AVDiscard{
AVDISCARD_ALL = 48, ///< discard all
};
-enum AVColorPrimaries{
-AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP177 Annex B
-AVCOL_PRI_UNSPECIFIED = 2,
-AVCOL_PRI_BT470M = 4,
-AVCOL_PRI_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM
-AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
-AVCOL_PRI_SMPTE240M = 7, ///< functionally identical to above
-AVCOL_PRI_FILM= 8,
-AVCOL_PRI_BT2020 = 9, ///< ITU-R BT2020
-AVCOL_PRI_NB , ///< Not part of ABI
-};
-
-enum AVColorTransferCharacteristic{
-AVCOL_TRC_BT709= 1, ///< also ITU-R BT1361
-AVCOL_TRC_UNSPECIFIED = 2,
-AVCOL_TRC_GAMMA22 = 4, ///< also ITU-R BT470M / ITU-R BT1700 625 PAL
& SECAM
-AVCOL_TRC_GAMMA28 = 5, ///< also ITU-R BT470BG
-AVCOL_TRC_SMPTE170M= 6, ///< also ITU-R BT601-6 525 or 625 / ITU-R
BT1358 525 or 625 / ITU-R BT1700 NTSC
-AVCOL_TRC_SMPTE240M= 7,
-AVCOL_TRC_LINEAR = 8, ///< "Linear transfer characteristics"
-AVCOL_TRC_LOG = 9, ///< "Logarithmic transfer characteristic
(100:1 range)"
-AVCOL_TRC_LOG_SQRT = 10, ///< "Logarithmic transfer characteristic
(100 * Sqrt( 10 ) : 1 range)"
-AVCOL_TRC_IEC61966_2_4 = 11, ///< IEC 61966-2-4
-AVCOL_TRC_BT1361_ECG = 12, ///< ITU-R BT1361 Extended Colour Gamut
-AVCOL_TRC_IEC61966_2_1 = 13, ///< IEC 61966-2-1 (sRGB or sYCC)
-AVCOL_TRC_BT2020_10= 14, ///< ITU-R BT2020 for 10 bit system
-AVCOL_TRC_BT2020_12= 15, ///< ITU-R BT2020 for 12 bit system
-AVCOL_TRC_NB , ///< Not part of ABI
-};
-
-enum AVColorSpace{
-AVCOL_SPC_RGB = 0,
-AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / SMPTE RP177 Annex B
-AVCOL_SPC_UNSPECIFIED = 2,
-AVCOL_SPC_FCC = 4,
-AVCOL_SPC_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
-AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC / functionally identical to above
-AVCOL_SPC_SMPTE240M = 7,
-AVCOL_SPC_YCOCG = 8, ///< Used by Dirac / VC-2 and H.264 FRext, see
ITU-T SG16
-AVCOL_SPC_BT2020_NCL = 9, ///< ITU-R BT2020 non-constant luminance system
-AVCOL_SPC_BT2020_CL = 10, ///< ITU-R BT2020 constant luminance system
-AVCOL_SPC_NB , ///< Not part of ABI
-};
-
-enum AVColorRange{
-AVCOL_RANGE_UNSPECIFIED = 0,
-AVCOL_RANGE_MPEG= 1, ///< the normal 219*2^(n-8) "MPEG" YUV ranges
-AVCOL_RANGE_JPEG= 2, ///< the normal 2^n-1 "JPEG" YUV ranges
-AVCOL_RANGE_NB , ///< Not part of ABI
-};
-
-/**
- * X X 3 4 X X are luma samples,
- * 1 21-6 are possible chroma positions
- * X X 5 6 X 0 is undefined/unknown position
- */
-enum AVChromaLocation{
-AVCHROMA_LOC_UNSPECIFIED = 0,
-AVCHROMA_LOC_LEFT= 1, ///< mpeg2/4, h264 default
-AVCHROMA_LOC_CENTER = 2, ///< mpeg1, jpeg, h263
-AVCHROMA_LOC_TOPLEFT = 3, ///< DV
-AVCHROMA_LOC_TOP = 4,
-AVCHROMA_LOC_BOTTOMLEFT = 5,
-AVCHROMA_LOC_BOTTOM = 6,
-AVCHROMA_LOC_NB , ///< Not part of ABI
-};
-
enum AVAudioServiceType {
AV_AUDIO_SERVICE_TYPE_MAIN = 0,
AV_AUDIO_SERVICE_TYPE_EFFECTS = 1,
diff --git a/libavutil/frame.c b/libavutil/frame.c
index cc4bfcd..bac11bf 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -38,6 +38,11 @@ static void get_frame_defaults(AVFrame *frame)
frame->sample_aspect_ratio = (AVRational){ 0, 1 };
frame->format = -1; /* unknown */
frame->extende
[libav-devel] [PATCH 2/2] libavcodec: set AVFrame colorspace fields on decoding
---
libavcodec/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e04f455..26aa4c7 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -579,6 +579,11 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
int size;
AVFrameSideData *frame_sd;
+frame->color_primaries = avctx->color_primaries;
+frame->color_trc = avctx->color_trc;
+frame->colorspace = avctx->colorspace;
+frame->color_range = avctx->color_range;
+frame->chroma_location = avctx->chroma_sample_location;
frame->reordered_opaque = avctx->reordered_opaque;
if (!pkt) {
--
1.9.1
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 0/4] [RFC] mov rotation and side data
Here is the patchset for supporting mov rotation. Two open questions up for discussion. This value reports exclusively rotation angle, no horizontal or vertical flip. While mov doesn't support reporting flipping (afaik, not sure how to interpret translateX/Y from the same atom) there might be other use for it. Since the rotation angle can fit 16 bits we could use the other 16 to store those, however it would be accessing the variable slighly more complex. Is it worth it? The side data is added only *once*, that is at the beginning of the stream (and consequently only at the first frame). I am not sure if the intended behaviour of having packet/frame side data is to have them repeated by frame. What would be the right way? The lavc/lavu patches are quite small, please tell me if I should squash them. Cheers, Vittorio Vittorio Giovara (4): mov: support exporting rotation angle as AVPacketSideData avframe: add AV_FRAME_DATA_ROTATION side data lavc: copy rotation angle from packet to frame vf_showinfo: print rotation value Changelog | 1 + doc/APIchanges| 6 ++ libavcodec/avcodec.h | 6 ++ libavcodec/utils.c| 9 + libavfilter/vf_showinfo.c | 4 libavformat/isom.h| 1 + libavformat/mov.c | 28 libavutil/frame.h | 4 libavutil/version.h | 2 +- 9 files changed, 60 insertions(+), 1 deletion(-) -- 1.8.3.4 (Apple Git-47) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 3/4] lavc: copy rotation angle from packet to frame
---
libavcodec/utils.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index e04f455..27bf066 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -597,6 +597,15 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame
*frame)
memcpy(frame_sd->data, packet_sd, size);
}
+/* copy rotation angle to the output frame */
+packet_sd = av_packet_get_side_data(pkt, AV_PKT_DATA_ROTATION, &size);
+if (packet_sd) {
+frame_sd = av_frame_new_side_data(frame, AV_FRAME_DATA_ROTATION, size);
+if (!frame_sd)
+return AVERROR(ENOMEM);
+
+memcpy(frame_sd->data, packet_sd, size);
+}
return 0;
}
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 4/4] vf_showinfo: print rotation value
--- libavfilter/vf_showinfo.c | 4 1 file changed, 4 insertions(+) diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c index 031d8fe..2a8ea18 100644 --- a/libavfilter/vf_showinfo.c +++ b/libavfilter/vf_showinfo.c @@ -27,6 +27,7 @@ #include "libavutil/adler32.h" #include "libavutil/imgutils.h" #include "libavutil/internal.h" +#include "libavutil/intreadwrite.h" #include "libavutil/pixdesc.h" #include "libavutil/stereo3d.h" @@ -117,6 +118,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame) case AV_FRAME_DATA_STEREO3D: dump_stereo3d(ctx, sd); break; +case AV_FRAME_DATA_ROTATION: +av_log(ctx, AV_LOG_INFO, "rotation angle: %d degrees", AV_RL32(sd->data)); +break; default: av_log(ctx, AV_LOG_WARNING, "unknown side data type %d (%d bytes)", sd->type, sd->size); -- 1.8.3.4 (Apple Git-47) ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/4] mov: support exporting rotation angle as AVPacketSideData
Compute the full rotatation angle exported by display_matrix.
---
Changelog| 1 +
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavformat/isom.h | 1 +
libavformat/mov.c| 28
5 files changed, 39 insertions(+)
diff --git a/Changelog b/Changelog
index 76eca07..53b62b0 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
- libx265 encoder
- shuffleplanes filter
- replaygain data export
+- rotation angle export
version 10:
diff --git a/doc/APIchanges b/doc/APIchanges
index d800253..e42d5bf 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2013-12-xx
API changes, most recent first:
+2014-02-11 - xxx - lavc 55.37.0 - avcodec.h
+ Add AV_PKT_DATA_ROTATION for exporting video rotation angle.
+
2014-02-xx - xxx - lavu 53.08.0 - frame.h
Add av_frame_remove_side_data() for removing a single side data
instance from a frame.
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 4fda36e..f753ba2 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -929,6 +929,12 @@ enum AVPacketSideDataType {
* ReplayGain information in form of the AVReplayGain struct.
*/
AV_PKT_DATA_REPLAYGAIN,
+
+/**
+ * An AV_PKT_DATA_ROTATION side data packet contains the full
+ * rotation angle as u32le degrees.
+ */
+AV_PKT_DATA_ROTATION,
};
typedef struct AVPacketSideData {
diff --git a/libavformat/isom.h b/libavformat/isom.h
index bf0792c..5409713 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -135,6 +135,7 @@ typedef struct MOVStreamContext {
int64_t track_end;///< used for dts generation in fragmented movie
files
unsigned int rap_group_count;
MOVSbgp *rap_group;
+uint32_t rotation;///< rotation angle derived from the display_matrix
} MOVStreamContext;
typedef struct MOVContext {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 6375847..24b1702 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2254,6 +2254,25 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
sc->width = width >> 16;
sc->height = height >> 16;
+// get full orientation angle when the matrix is not the identity one
+if (display_matrix[0][1] || display_matrix[1][0] ||
+display_matrix[2][0] || display_matrix[2][1]) {
+double rotationf, scale[2];
+#define CONV_FP(x) ((double) (x)) / 65536
+scale[0] = sqrt(CONV_FP(display_matrix[0][0]) *
CONV_FP(display_matrix[0][0]) +
+CONV_FP(display_matrix[1][0]) *
CONV_FP(display_matrix[1][0]));
+scale[1] = sqrt(CONV_FP(display_matrix[0][1]) *
CONV_FP(display_matrix[0][1]) +
+CONV_FP(display_matrix[1][1]) *
CONV_FP(display_matrix[1][1]));
+
+rotationf = atan2(CONV_FP(display_matrix[0][1]) / scale[1],
+ CONV_FP(display_matrix[0][0]) / scale[0]) * 180 /
M_PI;
+
+if (rotationf < 0)
+rotationf += 360.0f;
+
+sc->rotation = (uint32_t) floor(rotationf);
+}
+
// transform the display width/height according to the matrix
// skip this if the display matrix is the default identity matrix
// or if it is rotating the picture, ex iPhone 3GS
@@ -2965,6 +2984,15 @@ static int mov_read_packet(AVFormatContext *s, AVPacket
*pkt)
sc->has_palette = 0;
}
}
+if (sc->rotation != 0) {
+uint8_t *rotation;
+rotation = av_packet_new_side_data(pkt, AV_PKT_DATA_ROTATION,
sizeof(sc->rotation));
+if (rotation) {
+AV_WL32(rotation, sc->rotation);
+sc->rotation = 0;
+} else
+av_log(mov->fc, AV_LOG_ERROR, "Cannot append rotation angle to
packet\n");
+}
#if CONFIG_DV_DEMUXER
if (mov->dv_demux && sc->dv_audio_container) {
avpriv_dv_produce_packet(mov->dv_demux, pkt, pkt->data, pkt->size);
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/4] avframe: add AV_FRAME_DATA_ROTATION side data
---
doc/APIchanges | 3 +++
libavutil/frame.h | 4
libavutil/version.h | 2 +-
3 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index e42d5bf..7c899e4 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,6 +13,9 @@ libavutil: 2013-12-xx
API changes, most recent first:
+2014-02-xx - xxx - lavu 53.09.0 - frame.h
+ Add AV_FRAME_DATA_ROTATION for exporting video rotation angle.
+
2014-02-11 - xxx - lavc 55.37.0 - avcodec.h
Add AV_PKT_DATA_ROTATION for exporting video rotation angle.
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 3bec8e5..6e47d05 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -73,6 +73,10 @@ enum AVFrameSideDataType {
* ReplayGain information in the form of the AVReplayGain struct.
*/
AV_FRAME_DATA_REPLAYGAIN,
+/**
+ * Rotation angle of the video, expressed as u32le degrees.
+ */
+AV_FRAME_DATA_ROTATION,
};
typedef struct AVFrameSideData {
diff --git a/libavutil/version.h b/libavutil/version.h
index 7f439d7..f8bb447 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -54,7 +54,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 53
-#define LIBAVUTIL_VERSION_MINOR 8
+#define LIBAVUTIL_VERSION_MINOR 9
#define LIBAVUTIL_VERSION_MICRO 0
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] segment: Add an option to prepend a string to the list entries
On 25/03/14 11:17, Diego Biurrun wrote:
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -480,6 +480,9 @@ Set segment duration to @var{t} seconds.
>> Generate also a listfile named @var{name}.
>> @item segment_list_size @var{size}
>> Overwrite the listfile once it reaches @var{size} entries.
>> +@item segment_list_entry_prefix @var{prefix}
>> +Prepend @var{prefix} to each entry. Useful to generate absolute paths,
>> +has the parser consuming it unable to use relative ones.
>
> has?
>
> This is incomprehensible to me. Please rephrase it or try to explain
> so I can come up with a better phrasing.
it is incomprehensible. I'd just drop it.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec: add missing includes
On Sun, Mar 23, 2014 at 01:34:13AM +0100, Vittorio Giovara wrote: > --- a/libavcodec/mjpeg2jpeg_bsf.c > +++ b/libavcodec/mjpeg2jpeg_bsf.c > @@ -25,6 +25,9 @@ > */ > > #include > + > +#include "libavutil/mem.h" > + > #include "avcodec.h" > #include "mjpeg.h" Maybe add libavutil/error.h while you're at it. Patch LGTM. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] fate: add Alias PIX tests
On Fri, Mar 21, 2014 at 03:59:29AM +0100, Vittorio Giovara wrote: > --- a/tests/fate/image.mak > +++ b/tests/fate/image.mak > @@ -1,3 +1,9 @@ > +FATE_SAMPLES_AVCONV-$(call DEMDEC, IMAGE2, ALIAS_PIX) += fate-aliaspix-bgr > +fate-aliaspix-bgr: CMD = framecrc -i $(TARGET_SAMPLES)/aliaspix/first.pix > -pix_fmt bgr24 > + > +FATE_SAMPLES_AVCONV-$(call DEMDEC, IMAGE2, ALIAS_PIX) += fate-aliaspix-gray > +fate-aliaspix-gray: CMD = framecrc -i > $(TARGET_SAMPLES)/aliaspix/firstgray.pix -pix_fmt gray I suggest factoring out the dependency declaration. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Fixed miscellaneous coding standard violation.
On Mon, Mar 24, 2014 at 02:00:34AM +0100, Vittorio Giovara wrote:
> On Thu, Mar 20, 2014 at 3:02 AM, Tanja Batchelor
> > --- a/libavformat/mpeg.c
> > +++ b/libavformat/mpeg.c
> > @@ -390,41 +390,41 @@ static int mpegps_read_packet(AVFormatContext *s,
> > if (len < 0)
> > return len;
> >
> > -if(startcode == 0x1bd) {
> > +if (startcode == 0x1bd) {
> > dvdaudio_substream_type = avio_r8(s->pb);
> > avio_skip(s->pb, 3);
> > len -= 4;
> > }
>
> The kind of nits here are for your improvement, I'll push a correct version.
Actually, having OPW candidates amend and resend patches is a good exercise.
Sending patches is good, going through a complete send, review, revise, and
resend cycle is better. Please don't take that opportunity away from OPW
candidates :)
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] segment: Add an option to prepend a string to the list entries
On Tue, Mar 18, 2014 at 09:18:59PM +0100, Luca Barbato wrote:
> From: Enrique Arizón Benito
>
> Useful to generate lists with absolute urls.
URLs
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -480,6 +480,9 @@ Set segment duration to @var{t} seconds.
> Generate also a listfile named @var{name}.
> @item segment_list_size @var{size}
> Overwrite the listfile once it reaches @var{size} entries.
> +@item segment_list_entry_prefix @var{prefix}
> +Prepend @var{prefix} to each entry. Useful to generate absolute paths,
> +has the parser consuming it unable to use relative ones.
has?
This is incomprehensible to me. Please rephrase it or try to explain
so I can come up with a better phrasing.
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/9] Add replaygain side data type and code for parsing replaygain tags.
On Tue, Mar 18, 2014 at 06:26:42PM +0100, Anton Khirnov wrote: > --- > doc/APIchanges |7 +++ > libavcodec/avcodec.h |6 ++ > libavcodec/version.h |2 +- > libavformat/replaygain.c | 155 > ++ > libavformat/replaygain.h | 31 ++ > libavutil/Makefile |1 + > libavutil/frame.h|4 ++ > libavutil/replaygain.h | 51 +++ > 8 files changed, 256 insertions(+), 1 deletion(-) > create mode 100644 libavformat/replaygain.c > create mode 100644 libavformat/replaygain.h > create mode 100644 libavutil/replaygain.h replaygain.c is never compiled. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 06/10] lavc: add hwaccel private data and init/uninit callbacks
On 2014-03-24 21:20:27 +0100, Luca Barbato wrote: > On 24/03/14 20:26, wm4 wrote: > > In practice, it's called when the decoder is flushed, i.e. on seeking. > > And yes, this is a bit of a bother. Freeing all hardware surfaces and > > reallocating them etc. makes seeking quite a bit slower this way. > > I'm not sure how to make it more optimal, if you have ideas I'm all hears. I don't think it necessary to call get_format() unconditionally after seeking. Fixing it in h264.c might be not so nice though. I guess h264.c is not the only decoder which needs fixing. I'll look into it. Janne ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] vf_transpose: K&R formatting cosmetics
On Tue, Mar 25, 2014 at 09:39:24AM +0100, Vittorio Giovara wrote:
> ---
> libavfilter/vf_transpose.c | 56
> +-
> 1 file changed, 30 insertions(+), 26 deletions(-)
I'd suggest to reorder includes while you're at it.
> --- a/libavfilter/vf_transpose.c
> +++ b/libavfilter/vf_transpose.c
> @@ -225,14 +229,14 @@ static const AVFilterPad
> avfilter_vf_transpose_outputs[] = {
>
> AVFilter ff_vf_transpose = {
> -.name = "transpose",
> +.name= "transpose",
> .description = NULL_IF_CONFIG_SMALL("Transpose input video."),
>
> -.priv_size = sizeof(TransContext),
> +.priv_size = sizeof(TransContext),
> .priv_class = &transpose_class,
>
> .query_formats = query_formats,
>
> -.inputs= avfilter_vf_transpose_inputs,
> -.outputs = avfilter_vf_transpose_outputs,
> +.inputs = avfilter_vf_transpose_inputs,
> +.outputs = avfilter_vf_transpose_outputs,
> };
I think you could align all of the = at the same position while you're
at it.
LGTM
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avconv: silence uninitialized variable clang warnings
---
avconv_opt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/avconv_opt.c b/avconv_opt.c
index 7bc41c9..1c10f33 100644
--- a/avconv_opt.c
+++ b/avconv_opt.c
@@ -1301,7 +1301,7 @@ static int copy_chapters(InputFile *ifile, OutputFile
*ofile, int copy_metadata)
static void init_output_filter(OutputFilter *ofilter, OptionsContext *o,
AVFormatContext *oc)
{
-OutputStream *ost;
+OutputStream *ost = NULL;
switch (avfilter_pad_get_type(ofilter->out_tmp->filter_ctx->output_pads,
ofilter->out_tmp->pad_idx)) {
@@ -1669,7 +1669,7 @@ loop_end:
/* process manually set metadata */
for (i = 0; i < o->nb_metadata; i++) {
-AVDictionary **m;
+AVDictionary **m = NULL;
char type, *val;
const char *stream_spec;
int index = 0, j, ret;
--
1.8.3.4 (Apple Git-47)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] vf_transpose: K&R formatting cosmetics
---
libavfilter/vf_transpose.c | 56 +-
1 file changed, 30 insertions(+), 26 deletions(-)
diff --git a/libavfilter/vf_transpose.c b/libavfilter/vf_transpose.c
index 06a88c7..8afb124 100644
--- a/libavfilter/vf_transpose.c
+++ b/libavfilter/vf_transpose.c
@@ -98,12 +98,14 @@ static int config_props_output(AVFilterLink *outlink)
outlink->w = inlink->h;
outlink->h = inlink->w;
-if (inlink->sample_aspect_ratio.num){
-outlink->sample_aspect_ratio = av_div_q((AVRational){1,1},
inlink->sample_aspect_ratio);
-} else
+if (inlink->sample_aspect_ratio.num)
+outlink->sample_aspect_ratio = av_div_q((AVRational) { 1, 1 },
+inlink->sample_aspect_ratio);
+else
outlink->sample_aspect_ratio = inlink->sample_aspect_ratio;
-av_log(ctx, AV_LOG_VERBOSE, "w:%d h:%d dir:%d -> w:%d h:%d rotation:%s
vflip:%d\n",
+av_log(ctx, AV_LOG_VERBOSE,
+ "w:%d h:%d dir:%d -> w:%d h:%d rotation:%s vflip:%d\n",
inlink->w, inlink->h, trans->dir, outlink->w, outlink->h,
trans->dir == 1 || trans->dir == 3 ? "clockwise" :
"counterclockwise",
trans->dir == 0 || trans->dir == 3);
@@ -133,28 +135,28 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
}
for (plane = 0; out->data[plane]; plane++) {
-int hsub = plane == 1 || plane == 2 ? trans->hsub : 0;
-int vsub = plane == 1 || plane == 2 ? trans->vsub : 0;
+int hsub= plane == 1 || plane == 2 ? trans->hsub : 0;
+int vsub= plane == 1 || plane == 2 ? trans->vsub : 0;
int pixstep = trans->pixsteps[plane];
-int inh = in->height >> vsub;
-int outw = out->width >> hsub;
-int outh = out->height >> vsub;
+int inh = in->height >> vsub;
+int outw= out->width >> hsub;
+int outh= out->height >> vsub;
uint8_t *dst, *src;
int dstlinesize, srclinesize;
int x, y;
-dst = out->data[plane];
+dst = out->data[plane];
dstlinesize = out->linesize[plane];
-src = in->data[plane];
+src = in->data[plane];
srclinesize = in->linesize[plane];
-if (trans->dir&1) {
-src += in->linesize[plane] * (inh-1);
+if (trans->dir & 1) {
+src += in->linesize[plane] * (inh - 1);
srclinesize *= -1;
}
-if (trans->dir&2) {
-dst += out->linesize[plane] * (outh-1);
+if (trans->dir & 2) {
+dst += out->linesize[plane] * (outh - 1);
dstlinesize *= -1;
}
@@ -162,21 +164,23 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
switch (pixstep) {
case 1:
for (x = 0; x < outw; x++)
-dst[x] = src[x*srclinesize + y];
+dst[x] = src[x * srclinesize + y];
break;
case 2:
for (x = 0; x < outw; x++)
-*((uint16_t *)(dst + 2*x)) = *((uint16_t *)(src +
x*srclinesize + y*2));
+*((uint16_t *)(dst + 2 * x)) =
+*((uint16_t *)(src + x * srclinesize + y * 2));
break;
case 3:
for (x = 0; x < outw; x++) {
-int32_t v = AV_RB24(src + x*srclinesize + y*3);
-AV_WB24(dst + 3*x, v);
+int32_t v = AV_RB24(src + x * srclinesize + y * 3);
+AV_WB24(dst + 3 * x, v);
}
break;
case 4:
for (x = 0; x < outw; x++)
-*((uint32_t *)(dst + 4*x)) = *((uint32_t *)(src +
x*srclinesize + y*4));
+*((uint32_t *)(dst + 4 * x)) =
+*((uint32_t *)(src + x * srclinesize + y * 4));
break;
}
dst += dstlinesize;
@@ -208,8 +212,8 @@ static const AVClass transpose_class = {
static const AVFilterPad avfilter_vf_transpose_inputs[] = {
{
-.name= "default",
-.type= AVMEDIA_TYPE_VIDEO,
+.name = "default",
+.type = AVMEDIA_TYPE_VIDEO,
.filter_frame = filter_frame,
},
{ NULL }
@@ -225,14 +229,14 @@ static const AVFilterPad avfilter_vf_transpose_outputs[]
= {
};
AVFilter ff_vf_transpose = {
-.name = "transpose",
+.name= "transpose",
.description = NULL_IF_CONFIG_SMALL("Transpose input video."),
-.priv_size = sizeof(TransContext),
+.priv_size = sizeof(TransContext),
.priv_class = &transpose_class,
.query_formats = query_formats,
-.inputs= avfilter_vf_transpose_inputs,
-.outputs = avfilter_vf_transpose_outputs,
+.inputs = avfilter_vf_transpose_inputs,
+.outputs = avfilter_vf_transpose_outputs,
Re: [libav-devel] [PATCH 07/10] lavu: add a pixel format for new VDA hwaccel
On Mon, 24 Mar 2014 23:09:21 +0100, wm4 wrote:
> Not sure about this. Different decoders might support different pixel
> formats for the same thing.
I never said that the pixel formats should expose the internal packing.
> For example, it seems VDA always prefers packed 422, even for 420.
I would say that is irrelevant. If VDA always uses 422, then you might as
well define AV_PIX_FMT_VDA to mean 422. If VDA completely hides the chroma
sampling from the application, then I agree that a single AV_PIX_FMT_VDA
for
all uses is good. However, the presence of cv_pix_fmt_type in the AV VDA
context makes me suspect that VDA does in fact care about the chroma
sampling just like the other hardware accelerators do.
In any case, VA and VDPAU require the application to know the chroma type
(and, so far, they assume 8-bits per component) for the purposes of
surface allocation, interoperability and copy to memory. Hence libavcodec
needs to supply that information. The pixel format seems like the obvious
way to do so. And even if another new mechanism were defined, the
_current_ VA and VDPAU pixel formats would not be compatible with it.
On the other hand, VA and VDPAU do not require the application to know or
care about the actual packing (say NV12 vs YV12, YUYV vs UYVY), so I agree
that there is no point in exposing the packing through the pixel format,
or through any other mean. I never asked for _that_.
DxVA2 is another matter altogether as it does not seem to define a fixed
set of surface types.
> Likewise, there could be decoders which
> support hi10p decoding, but pretend the surfaces are normal 420 8 bit
> surfaces.
All I'm saying is that libavcodec should match libva and libvdpau (and
consequently VLC). If those libraries reuse the currently implicitly
8-bits chroma types for 10-bits, then I am totally fine with reusing the
existing libav pixel formats accordingly.
In practice, this is extremely unlikely though because of the memory
allocation would be too small to fit the extra bits.
> (There was something about adding 10 bit support for vdpau
> some months ago. I'm not sure how that was supposed to work or if it
> was just a misunderstanding, but it looked like it was pretending to
> return 8 bit surfaces for 10 bit decoding.)
IMU, that would have used new video surface chroma types. But it never
came to fruition as the Gallium guys never posted any patches of any sort.
VDPAU already defines separate 8-bits and 10-bits types for RGB, that is
to say output surfaces in VDPAU parliance.
> Is it really that straight-forward? Maybe separating this would be
> better. We don't store the codec profile in the pixel format either.
The codec profile is stored in the AVCodecContext. I am fine with storing
the sampling there, but that does not seem to fit well with the
get_format() pattern.
> And when we did that, it was ugly and we eventually removed it (like
> AV_PIX_FMT_VDPAU_H264).
Indeed, the input codec is irrelevant to the VDPAU video surface. But the
chroma type is very relevant to the VDPAU video surface.
> IMO it's best if AV_PIX_FMT_VDPAU means that it's a VdpVideoSurface,
> instead of attempting to encode more into it.
The point is, there is not one type of VDPAU video surface. There are
three types of them, of which two are actively used. To preserve
compatibility, a new pixel format would be required to support 422 anyway.
With that in mind, is it better to have simply:
AV_PIX_FMT_VDPAU_420,
#define AV_PIX_FMT_VDPAU AV_PIX_FMT_VDPAU_420
/*...*/
AV_PIX_FMT_VDPAU_422,
or
AV_PIX_FMT_VDPAU,
/* ... */
AV_PIX_FMT_VDPAU2,
/* ... */
VdpChromaType av_vdpau2_get_chroma_type(const AVPixelFormat *pix_fmts)
{
/* Lot of code here */
}
Either way, you end up with two pixel formats. I think it the first option
is cleaner, saner and simpler.
--
Rémi Denis-Courmont
Sent from my collocated server
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 07/10] lavu: add a pixel format for new VDA hwaccel
On Mon, 24 Mar 2014 22:59:29 +0100, Luca Barbato wrote: > As said before, can be discussed. That's not what you said before. You said I was wrong and misconstrued an hypothetical future implementation design choice as an established existing fact for justification. -- Rémi Denis-Courmont Sent from my collocated server ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Update the instructions for configuring a build for iOS
On Mon, Mar 24, 2014 at 7:40 PM, Martin Storsjo wrote: > The previous instructions were woefully outdated. > --- > README | 9 ++--- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/README b/README > index d903ba1..ef235b7 100644 > --- a/README > +++ b/README > @@ -1,13 +1,8 @@ > -To configure ffmpeg for the iPhone 3gs and iPod touch 3g: > +To configure Libav for the iPhone 3gs and iPod touch 3g: > I would just drop the 3g part nowadays, ok for the rest -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
