Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 01:43:26AM -0500, Kyle Swanson wrote: > On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > > > 0001-avfilter-add-libebur128-port.patch > > This first patch ports libebur128 to ffmpeg. I haven't re-indented > > these yet, so please diff `ebur128.c' and `ebur128.h' with the > > original libebur128 files[1][2] to see what has changed. Also included > > is `queue.h' which comes from BSD, which AFAIK should be distributable > > if we decide to go this route. All these files still need their > > license header, as libebur128 is MIT licensed and needs its own > > copyright message. One other thing to take a look at is the section > > with the sse2 optimizations - does FFmpeg already have a macro we > > could use for this? > > > > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > > This patch removes the libebur128 dependency for the loudnorm and uses > > the new internal ebur128 API. > > > > Hi, > Hi, > Two updated patches attached. This is the libebur128 port and the > af_loudnorm update. Please review if you can, as I'd like to try push > these before v3.1. Updates to af_astats and f_ebur128 to use this new > API will be coming in the near future as well. I'm against using libebur128 to replace our native code in f_ebur128 so you do not need to spend effort on that. Regards, -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] one question about h.264 svc decoder
Hi, I found ffmpeg has supported openh264 now. Does ffmpeg support h.264 SVC deocding, i.e. capability of decoding temporal, spatial and quality scalability bitstream? Thanks! B.R. Andrew ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes wrote: > On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >>> >>> 0001-avfilter-add-libebur128-port.patch >>> This first patch ports libebur128 to ffmpeg. I haven't re-indented >>> these yet, so please diff `ebur128.c' and `ebur128.h' with the >>> original libebur128 files[1][2] to see what has changed. Also included >>> is `queue.h' which comes from BSD, which AFAIK should be distributable >>> if we decide to go this route. All these files still need their >>> license header, as libebur128 is MIT licensed and needs its own >>> copyright message. One other thing to take a look at is the section >>> with the sse2 optimizations - does FFmpeg already have a macro we >>> could use for this? >>> >>> >>> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >>> This patch removes the libebur128 dependency for the loudnorm and uses >>> the new internal ebur128 API. >>> >> >> Hi, >> >> Two updated patches attached. This is the libebur128 port and the >> af_loudnorm update. Please review if you can, as I'd like to try push >> these before v3.1. Updates to af_astats and f_ebur128 to use this new >> API will be coming in the near future as well. >> > > The libebur128 port still contains global state (ie. static data > initialized at runtime), as commented on in the earlier reviews can > you get rid of those and move them into a library context (ie. not > static globals)? > We really don't like global state like this because of thread safety issues. > Also, in general I must say I really don't like the idea or the precedence this sets of porting complex external libraries into the avfilter code. Whats wrong with simply linking the library when you want to use it? This is how it works for everything else, what makes this different to warrant such a step? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: > On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >> >> 0001-avfilter-add-libebur128-port.patch >> This first patch ports libebur128 to ffmpeg. I haven't re-indented >> these yet, so please diff `ebur128.c' and `ebur128.h' with the >> original libebur128 files[1][2] to see what has changed. Also included >> is `queue.h' which comes from BSD, which AFAIK should be distributable >> if we decide to go this route. All these files still need their >> license header, as libebur128 is MIT licensed and needs its own >> copyright message. One other thing to take a look at is the section >> with the sse2 optimizations - does FFmpeg already have a macro we >> could use for this? >> >> >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> This patch removes the libebur128 dependency for the loudnorm and uses >> the new internal ebur128 API. >> > > Hi, > > Two updated patches attached. This is the libebur128 port and the > af_loudnorm update. Please review if you can, as I'd like to try push > these before v3.1. Updates to af_astats and f_ebur128 to use this new > API will be coming in the near future as well. > The libebur128 port still contains global state (ie. static data initialized at runtime), as commented on in the earlier reviews can you get rid of those and move them into a library context (ie. not static globals)? We really don't like global state like this because of thread safety issues. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mpegts: include stream types for mpeg2 and aac
On Tue, Jun 14, 2016 at 11:08:55AM -0700, Aman Gupta wrote: > From: Aman Gupta > > this removes the need to probe to discover mpeg2 and aac streams > inside mpegts containers, thus speeding up initial playback. > --- > libavformat/mpegts.c | 2 ++ > 1 file changed, 2 insertions(+) this is probably ok unless there was a reason why these where missing but if it causes misdetection it could be reverted easily [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On 6/18/16, Paul B Mahol wrote: > On 6/18/16, Hendrik Leppkes wrote: >> On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes >> wrote: >>> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > 0001-avfilter-add-libebur128-port.patch > This first patch ports libebur128 to ffmpeg. I haven't re-indented > these yet, so please diff `ebur128.c' and `ebur128.h' with the > original libebur128 files[1][2] to see what has changed. Also included > is `queue.h' which comes from BSD, which AFAIK should be distributable > if we decide to go this route. All these files still need their > license header, as libebur128 is MIT licensed and needs its own > copyright message. One other thing to take a look at is the section > with the sse2 optimizations - does FFmpeg already have a macro we > could use for this? > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > This patch removes the libebur128 dependency for the loudnorm and uses > the new internal ebur128 API. > Hi, Two updated patches attached. This is the libebur128 port and the af_loudnorm update. Please review if you can, as I'd like to try push these before v3.1. Updates to af_astats and f_ebur128 to use this new API will be coming in the near future as well. >>> >>> The libebur128 port still contains global state (ie. static data >>> initialized at runtime), as commented on in the earlier reviews can >>> you get rid of those and move them into a library context (ie. not >>> static globals)? >>> We really don't like global state like this because of thread safety >>> issues. >>> >> >> Also, in general I must say I really don't like the idea or the >> precedence this sets of porting complex external libraries into the >> avfilter code. >> Whats wrong with simply linking the library when you want to use it? >> This is how it works for everything else, what makes this different to >> warrant such a step? > > Because f_ebur128 is GPL and unlikely to get relicensed. > Also, it is better to avoid extrenal libraries if it is simple. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On 6/18/16, Hendrik Leppkes wrote: > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes > wrote: >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: 0001-avfilter-add-libebur128-port.patch This first patch ports libebur128 to ffmpeg. I haven't re-indented these yet, so please diff `ebur128.c' and `ebur128.h' with the original libebur128 files[1][2] to see what has changed. Also included is `queue.h' which comes from BSD, which AFAIK should be distributable if we decide to go this route. All these files still need their license header, as libebur128 is MIT licensed and needs its own copyright message. One other thing to take a look at is the section with the sse2 optimizations - does FFmpeg already have a macro we could use for this? 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch This patch removes the libebur128 dependency for the loudnorm and uses the new internal ebur128 API. >>> >>> Hi, >>> >>> Two updated patches attached. This is the libebur128 port and the >>> af_loudnorm update. Please review if you can, as I'd like to try push >>> these before v3.1. Updates to af_astats and f_ebur128 to use this new >>> API will be coming in the near future as well. >>> >> >> The libebur128 port still contains global state (ie. static data >> initialized at runtime), as commented on in the earlier reviews can >> you get rid of those and move them into a library context (ie. not >> static globals)? >> We really don't like global state like this because of thread safety >> issues. >> > > Also, in general I must say I really don't like the idea or the > precedence this sets of porting complex external libraries into the > avfilter code. > Whats wrong with simply linking the library when you want to use it? > This is how it works for everything else, what makes this different to > warrant such a step? Because f_ebur128 is GPL and unlikely to get relicensed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: > On 6/18/16, Hendrik Leppkes wrote: > > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes > > wrote: > >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: > >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > > 0001-avfilter-add-libebur128-port.patch > This first patch ports libebur128 to ffmpeg. I haven't re-indented > these yet, so please diff `ebur128.c' and `ebur128.h' with the > original libebur128 files[1][2] to see what has changed. Also included > is `queue.h' which comes from BSD, which AFAIK should be distributable > if we decide to go this route. All these files still need their > license header, as libebur128 is MIT licensed and needs its own > copyright message. One other thing to take a look at is the section > with the sse2 optimizations - does FFmpeg already have a macro we > could use for this? > > > 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > This patch removes the libebur128 dependency for the loudnorm and uses > the new internal ebur128 API. > > >>> > >>> Hi, > >>> > >>> Two updated patches attached. This is the libebur128 port and the > >>> af_loudnorm update. Please review if you can, as I'd like to try push > >>> these before v3.1. Updates to af_astats and f_ebur128 to use this new > >>> API will be coming in the near future as well. > >>> > >> > >> The libebur128 port still contains global state (ie. static data > >> initialized at runtime), as commented on in the earlier reviews can > >> you get rid of those and move them into a library context (ie. not > >> static globals)? > >> We really don't like global state like this because of thread safety > >> issues. > >> > > > > Also, in general I must say I really don't like the idea or the > > precedence this sets of porting complex external libraries into the > > avfilter code. > > Whats wrong with simply linking the library when you want to use it? > > This is how it works for everything else, what makes this different to > > warrant such a step? > > Because f_ebur128 is GPL and unlikely to get relicensed. 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not -- 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 3/3] avformat/mpegts: include stream types for mpeg2 and aac
On Tue, Jun 14, 2016 at 8:08 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> this removes the need to probe to discover mpeg2 and aac streams
> inside mpegts containers, thus speeding up initial playback.
> ---
> libavformat/mpegts.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 6acb797..f46984d 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -700,6 +700,7 @@ static const StreamType ISO_types[] = {
> { 0x11, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC_LATM }, /* LATM syntax */
> #endif
> { 0x1b, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264 },
> +{ 0x1c, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AAC},
> { 0x20, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_H264 },
> { 0x21, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_JPEG2000 },
> { 0x24, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_HEVC },
I can see 1c in the latest spec for AAC audio, so thats probably fine.
> @@ -726,6 +727,7 @@ static const StreamType HDMV_types[] = {
>
> /* ATSC ? */
> static const StreamType MISC_types[] = {
> +{ 0x80, AVMEDIA_TYPE_VIDEO, AV_CODEC_ID_MPEG2VIDEO },
> { 0x81, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_AC3 },
> { 0x8a, AVMEDIA_TYPE_AUDIO, AV_CODEC_ID_DTS },
> { 0 },
However, are there any specs that outline this value?
> --
> 2.8.1
>
> ___
> 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][WIP] avfilter: add libebur128 port
On 6/18/16, Clement Boesch wrote: > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: >> On 6/18/16, Hendrik Leppkes wrote: >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes >> > wrote: >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: >> >> 0001-avfilter-add-libebur128-port.patch >> This first patch ports libebur128 to ffmpeg. I haven't re-indented >> these yet, so please diff `ebur128.c' and `ebur128.h' with the >> original libebur128 files[1][2] to see what has changed. Also >> included >> is `queue.h' which comes from BSD, which AFAIK should be >> distributable >> if we decide to go this route. All these files still need their >> license header, as libebur128 is MIT licensed and needs its own >> copyright message. One other thing to take a look at is the section >> with the sse2 optimizations - does FFmpeg already have a macro we >> could use for this? >> >> >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch >> This patch removes the libebur128 dependency for the loudnorm and >> uses >> the new internal ebur128 API. >> >> >>> >> >>> Hi, >> >>> >> >>> Two updated patches attached. This is the libebur128 port and the >> >>> af_loudnorm update. Please review if you can, as I'd like to try push >> >>> these before v3.1. Updates to af_astats and f_ebur128 to use this >> >>> new >> >>> API will be coming in the near future as well. >> >>> >> >> >> >> The libebur128 port still contains global state (ie. static data >> >> initialized at runtime), as commented on in the earlier reviews can >> >> you get rid of those and move them into a library context (ie. not >> >> static globals)? >> >> We really don't like global state like this because of thread safety >> >> issues. >> >> >> > >> > Also, in general I must say I really don't like the idea or the >> > precedence this sets of porting complex external libraries into the >> > avfilter code. >> > Whats wrong with simply linking the library when you want to use it? >> > This is how it works for everything else, what makes this different to >> > warrant such a step? >> >> Because f_ebur128 is GPL and unlikely to get relicensed. > > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not But you are blocking other ebur128 implementation to be used in f_ebur128.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][WIP] avfilter: add libebur128 port
On Sat, Jun 18, 2016 at 12:58:59PM +0200, Paul B Mahol wrote: > On 6/18/16, Clement Boesch wrote: > > On Sat, Jun 18, 2016 at 12:34:10PM +0200, Paul B Mahol wrote: > >> On 6/18/16, Hendrik Leppkes wrote: > >> > On Sat, Jun 18, 2016 at 10:38 AM, Hendrik Leppkes > >> > wrote: > >> >> On Sat, Jun 18, 2016 at 8:43 AM, Kyle Swanson wrote: > >> >>> On Sun, Jun 12, 2016 at 4:14 PM, Kyle Swanson wrote: > >> > >> 0001-avfilter-add-libebur128-port.patch > >> This first patch ports libebur128 to ffmpeg. I haven't re-indented > >> these yet, so please diff `ebur128.c' and `ebur128.h' with the > >> original libebur128 files[1][2] to see what has changed. Also > >> included > >> is `queue.h' which comes from BSD, which AFAIK should be > >> distributable > >> if we decide to go this route. All these files still need their > >> license header, as libebur128 is MIT licensed and needs its own > >> copyright message. One other thing to take a look at is the section > >> with the sse2 optimizations - does FFmpeg already have a macro we > >> could use for this? > >> > >> > >> 0002-avfilter-af_loudnorm-use-internal-ebur128-api.patch > >> This patch removes the libebur128 dependency for the loudnorm and > >> uses > >> the new internal ebur128 API. > >> > >> >>> > >> >>> Hi, > >> >>> > >> >>> Two updated patches attached. This is the libebur128 port and the > >> >>> af_loudnorm update. Please review if you can, as I'd like to try push > >> >>> these before v3.1. Updates to af_astats and f_ebur128 to use this > >> >>> new > >> >>> API will be coming in the near future as well. > >> >>> > >> >> > >> >> The libebur128 port still contains global state (ie. static data > >> >> initialized at runtime), as commented on in the earlier reviews can > >> >> you get rid of those and move them into a library context (ie. not > >> >> static globals)? > >> >> We really don't like global state like this because of thread safety > >> >> issues. > >> >> > >> > > >> > Also, in general I must say I really don't like the idea or the > >> > precedence this sets of porting complex external libraries into the > >> > avfilter code. > >> > Whats wrong with simply linking the library when you want to use it? > >> > This is how it works for everything else, what makes this different to > >> > warrant such a step? > >> > >> Because f_ebur128 is GPL and unlikely to get relicensed. > > > > 11:50 <@ubitux> nowadays i care much less about f_ebur128 being gpl or not > > But you are blocking other ebur128 implementation to be used in f_ebur128.c Yes but not because of licence issues. -- 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] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)
On Fri, Jun 17, 2016 at 07:26:59PM +0200, Eric Beuque wrote: > 2016-06-17 19:16 GMT+02:00 Michael Niedermayer : > > > On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote: > > > Hi, > > > > > > i'm posting here for a feature that is missing in ffmpeg (or may be i > > > missed something), which consist of decoding H.264 frame with a scaling > > > factor of 1/2, 1/4, 1/8... > > > > > > I found the parameter lowres, which works well with MJPEG stream but it's > > > not working with the H.264 decoder. > > > > > > I don't know if it's something possible to implement in the decoder, but > > if > > > yes, my compagny agreed to sponsor the feature (depending on the cost of > > > course), if a developer qualified is interested to do it. > > > > > > Is someone know if it is possible, and if it can exist someone interested > > > to develop this feature? > > > > is it acceptable if the encoder enforces some restrictions on the used > > features ? > > > > most general h264 likely cannot efficiently be decoded in lower > > resolution with acceptable quality > > Restricting the used intra modes may make it possible to do it though > > i dont know what the quality would be but better than without > > restrictions > > > > [...] > > > > > Actually, the main goal is for motion detection algorithm, so we need small > resolution and best quality is not required. We just need good estimation > for the moving pixel. > > For now, we decode in H.264, and scale it close 320x240, the then we > perform motion detection on it. The goal is to speed up the process and > reduce the memory usage since decoding a 2048x1536 picture lead around a 5 > MB for the decoded image in memory. > > So i think it could be OK. i dont think that withut restrictions it would be good enough for motion detection [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] added support for hardware assist H264 video encoding for the Raspberry Pi
> On Jun 16, 2016, at 11:16 AM, Aman Gupta wrote: > > The patchset that was merged into libav is now available in ffmpeg as well: > https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/omx.c > > You can compile ffmpeg from the master branch > with --enable-omx --enable-omx-rpi > > Aman > > On Thu, Jun 16, 2016 at 2:16 AM, Amancio Hasty wrote: > >> >>> On May 9, 2016, at 7:55 AM, Amancio Hasty wrote: >>> >>> Hi, >>> >>> So what is the next step? >>> >>> If you want testers I suggest posting to ccrisan’s motionpie mailing >> list. >>> Cheers >>> Amancio >>> >>> On Mar 31, 2016, at 7:27 PM, Amancio Hasty wrote: I am not a lawyer… I updated the patch. vc264.c now has a the copyright notice embedded in a volatile global so if a binary is compiled against vc264.o , the >> copyright notice can be displayed by: strings ffmpeg | grep -i copyright LICENSE.md has been updated to include Broadcom’s copyright notice. A distribution of a binary that includes vc264.o should include >> LICENSE.md and if that is missing, the copyright notice can be displayed via the shell command ‘strings’ . Amancio > On Mar 22, 2016, at 12:12 PM, Lou Logan wrote: > > On Mon, 21 Mar 2016 20:07:01 -0700, Amancio Hasty wrote: > >> From 874a72eec2a78f4935fea091003e534b5f8d5413 Mon Sep 17 00:00:00 2001 >> From: Amancio Hasty >> Date: Mon, 21 Mar 2016 18:56:05 -0700 >> Subject: [PATCH] added support for hardware assist H264 video >> encoding for >> the Raspberry Pi >> >> --- >> configure | 12 ++ >> libavcodec/Makefile| 1 + >> libavcodec/allcodecs.c | 2 + >> libavcodec/vc264.c | 387 >> + >> 4 files changed, 402 insertions(+) >> create mode 100644 libavcodec/vc264.c >> > [...] >> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c >> index 2a25d66..3c7bd9b 100644 >> --- a/libavcodec/allcodecs.c >> +++ b/libavcodec/allcodecs.c >> @@ -74,6 +74,7 @@ void avcodec_register_all(void) >> initialized = 1; >> > > Nit: Whitespace on the line above should be removed. > > [...] >> --- /dev/null >> +++ b/libavcodec/vc264.c >> @@ -0,0 +1,387 @@ >> +/* H.264 hardware assist video encoding code taken from >> + * raspberry's os : >> + * /opt/vc/src/hello_pi/hello_encode/encode.c >> + */ >> + >> +/* >> +Copyright (c) 2012, Broadcom Europe Ltd >> +Copyright (c) 2012, Kalle Vahlman >> +Tuomas Kulve >> +All rights reserved. >> + >> +Redistribution and use in source and binary forms, with or without >> +modification, are permitted provided that the following conditions >> are met: >> +* Redistributions of source code must retain the above copyright >> + notice, this list of conditions and the following disclaimer. >> + * Redistributions in binary form must reproduce the above >> copyright >> + notice, this list of conditions and the following disclaimer >> in the >> + documentation and/or other materials provided with the >> distribution. >> + * Neither the name of the copyright holder nor the >> + names of its contributors may be used to endorse or promote >> products >> + derived from this software without specific prior written >> permission. >> + >> +THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS >> "AS IS" AND >> +ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, >> THE IMPLIED >> +WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE >> ARE >> +DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS >> BE LIABLE FOR ANY >> +DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL >> DAMAGES >> +(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR >> SERVICES; >> +LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER >> CAUSED AND >> +ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, >> OR TORT >> +(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE >> USE OF THIS >> +SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > I wonder if any of the above legalese is compatible. Granted, I see a > similar paragraph in "libavformat/aadec.c". > >> + * ffmpeg driver for hardware assist video H.264 encoding using >> Broadcom's GPU >> + * Copyright (C) 2016 Amancio Hasty aha...@gmail.com >> + * >> + * >> + * This file is part of FFmpeg. >> + * >> + * FFmpeg is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU Lesser General Public >> + * License as published by the Free Software Foundation; either >> + * version 2.1 of
[FFmpeg-devel] [PATCH] fate: Add sm2v ref10 test
--- tests/fate/h264.mak|3 ++ tests/ref/fate/h264-sm2v-ref10 | 82 2 files changed, 85 insertions(+) create mode 100644 tests/ref/fate/h264-sm2v-ref10 diff --git a/tests/fate/h264.mak b/tests/fate/h264.mak index 4ae1305..8864735 100644 --- a/tests/fate/h264.mak +++ b/tests/fate/h264.mak @@ -204,6 +204,8 @@ FATE_H264-$(call DEMDEC, MOV, H264) += fate-h264-invalid-ref-mod # this sample has invalid extradata that is not escaped FATE_H264-$(call DEMDEC, MOV, H264) += fate-h264-unescaped-extradata +FATE_H264-$(call DEMDEC, AVI, H264) += fate-h264-sm2v-ref10 + FATE_H264-$(call ALLYES, MOV_DEMUXER H264_MP4TOANNEXB_BSF) += fate-h264-bsf-mp4toannexb FATE_H264-$(call DEMDEC, MATROSKA, H264) += fate-h264-direct-bff FATE_H264-$(call DEMDEC, FLV, H264) += fate-h264-brokensps-2580 @@ -414,6 +416,7 @@ fate-h264-xavc-4389: CMD = framecrc -i $(TARGET_SAM fate-h264-attachment-631: CMD = framecrc -i $(TARGET_SAMPLES)/h264/attachment631-small.mp4 -an -max_error_rate 0.95 fate-h264-invalid-ref-mod:CMD = framecrc -i $(TARGET_SAMPLES)/h264/h264refframeregression.mp4 -an -frames 10 -pix_fmt yuv420p10le fate-h264-unescaped-extradata:CMD = framecrc -i $(TARGET_SAMPLES)/h264/unescaped_extradata.mp4 -an -frames 10 +fate-h264-sm2v-ref10: CMD = framecrc -i $(TARGET_SAMPLES)/h264/ref_10.avi fate-h264-reinit-%: CMD = framecrc -i $(TARGET_SAMPLES)/h264/$(@:fate-h264-%=%).h264 -vf format=yuv444p10le,scale=w=352:h=288 diff --git a/tests/ref/fate/h264-sm2v-ref10 b/tests/ref/fate/h264-sm2v-ref10 new file mode 100644 index 000..bd18c3e --- /dev/null +++ b/tests/ref/fate/h264-sm2v-ref10 @@ -0,0 +1,82 @@ +#tb 0: 1001/24000 +#media_type 0: video +#codec_id 0: rawvideo +#dimensions 0: 320x240 +#sar 0: 0/1 +#tb 1: 1/44100 +#media_type 1: audio +#codec_id 1: pcm_s16le +#sample_rate 1: 44100 +#channel_layout 1: 3 +1, 0, 0, 1152, 4608, 0x +1, 1151, 1151, 1152, 4608, 0x +1, 2301, 2301, 1152, 4608, 0x3b8f13ee +1, 3450, 3450, 1152, 4608, 0xbd76c8ea +1, 4599, 4599, 1152, 4608, 0x2dee19ef +1, 5749, 5749, 1152, 4608, 0xadfe1edb +1, 6898, 6898, 1152, 4608, 0x94fbca12 +1, 8047, 8047, 1152, 4608, 0xc87d52db +1, 9197, 9197, 1152, 4608, 0xe3f53d87 +1, 10346, 10346, 1152, 4608, 0x2605ffc8 +0, 6, 6,1, 115200, 0xccfd98ff +1, 11495, 11495, 1152, 4608, 0xd8b01dcf +1, 12645, 12645, 1152, 4608, 0x3b5a6eab +0, 7, 7,1, 115200, 0x288b8d95 +1, 13794, 13794, 1152, 4608, 0x741c5d69 +0, 8, 8,1, 115200, 0x0d5cb3a8 +1, 14944, 14944, 1152, 4608, 0x2fba1b66 +1, 16093, 16093, 1152, 4608, 0x68d75bda +0, 9, 9,1, 115200, 0x865ea4e5 +1, 17242, 17242, 1152, 4608, 0xabac5a9b +1, 18392, 18392, 1152, 4608, 0x388ccfa4 +0, 10, 10,1, 115200, 0x2f07038a +1, 19541, 19541, 1152, 4608, 0xbbcaaa7c +0, 11, 11,1, 115200, 0xf4c9b24e +1, 20690, 20690, 1152, 4608, 0x91397097 +0, 12, 12,1, 115200, 0x0ee19bbc +1, 23034, 23034, 1152, 4608, 0x98800d14 +0, 13, 13,1, 115200, 0x9a01b261 +1, 24187, 24187, 1152, 4608, 0x7c0e74f8 +1, 25339, 25339, 1152, 4608, 0x6b3d358e +0, 14, 14,1, 115200, 0x5620af7b +1, 26491, 26491, 1152, 4608, 0xcce18d23 +0, 15, 15,1, 115200, 0x069536c0 +1, 27643, 27643, 1152, 4608, 0xf3f1073e +1, 28795, 28795, 1152, 4608, 0x23d23fe7 +0, 16, 16,1, 115200, 0x4d5a8933 +1, 29948, 29948, 1152, 4608, 0x2080ab5e +1, 31100, 31100, 1152, 4608, 0x5456180e +0, 17, 17,1, 115200, 0xa347008f +1, 32250, 32250, 1152, 4608, 0x77c62807 +0, 18, 18,1, 115200, 0xcd10876b +1, 33402, 33402, 1152, 4608, 0xa409b29a +1, 34554, 34554, 1152, 4608, 0x6712d5ac +0, 19, 19,1, 115200, 0x0a91d0e7 +1, 35706, 35706, 1152, 4608, 0xef92792d +0, 20, 20,1, 115200, 0x24394b2c +1, 36858, 36858, 1152, 4608, 0xd46e2dd5 +1, 38010, 38010, 1152, 4608, 0x573f9176 +0, 21, 21,1, 115200, 0x62cc14b1 +1, 39162, 39162, 1152, 4608, 0x34b6cdca
Re: [FFmpeg-devel] [PATCH] fate: Add sm2v ref10 test
On Sat, Jun 18, 2016 at 07:06:08PM +0200, Michael Niedermayer wrote: > --- > tests/fate/h264.mak|3 ++ > tests/ref/fate/h264-sm2v-ref10 | 82 > > 2 files changed, 85 insertions(+) > create mode 100644 tests/ref/fate/h264-sm2v-ref10 > thanks, that will help with the next merge I couldn't find anything in git log referencing that particular sample. Do you know if it comes from a bug report? -- 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] fate: Add sm2v ref10 test
On Sat, Jun 18, 2016 at 07:47:55PM +0200, Clément Bœsch wrote: > On Sat, Jun 18, 2016 at 07:06:08PM +0200, Michael Niedermayer wrote: > > --- > > tests/fate/h264.mak|3 ++ > > tests/ref/fate/h264-sm2v-ref10 | 82 > > > > 2 files changed, 85 insertions(+) > > create mode 100644 tests/ref/fate/h264-sm2v-ref10 > > > > thanks, that will help with the next merge > > I couldn't find anything in git log referencing that particular sample. Do > you know if it comes from a bug report? for the archives: (with uncorrected spelling even;) ubitux, i think someone sent me this file by private mail but the mail doesnt say much, i dont know if it somewhere else [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: add libopenmpt demuxer
Fixes ticket #5623
TODO: bump lavf minor
Hi,
This should address all prior concerns. The issue with channel layouts
was resolved because of various issues with surround output it was
decided to just use stereo and let the user override mono/surround if
needed.
Josh
---
Changelog| 1 +
configure| 4 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/libopenmpt.c | 182 +++
5 files changed, 189 insertions(+)
create mode 100644 libavformat/libopenmpt.c
diff --git a/Changelog b/Changelog
index 49bb557..5956a62 100644
--- a/Changelog
+++ b/Changelog
@@ -42,6 +42,7 @@ version :
- OpenExr improvements (tile data and B44/B44A support)
- BitJazz SheerVideo decoder
- CUDA CUVID H264/HEVC decoder
+- libopenmpt demuxer
version 3.0:
diff --git a/configure b/configure
index a220fa1..6fea69b 100755
--- a/configure
+++ b/configure
@@ -249,6 +249,7 @@ External library support:
--enable-libopencv enable video filtering via libopencv [no]
--enable-libopenh264 enable H.264 encoding via OpenH264 [no]
--enable-libopenjpeg enable JPEG 2000 de/encoding via OpenJPEG [no]
+ --enable-libopenmpt enable decoding tracked files via libopenmpt [no]
--enable-libopus enable Opus de/encoding via libopus [no]
--enable-libpulseenable Pulseaudio input via libpulse [no]
--enable-librubberband enable rubberband needed for rubberband filter [no]
@@ -1496,6 +1497,7 @@ EXTERNAL_LIBRARY_LIST="
libopencv
libopenh264
libopenjpeg
+libopenmpt
libopus
libpulse
librtmp
@@ -2760,6 +2762,7 @@ libopencore_amrwb_decoder_deps="libopencore_amrwb"
libopenh264_encoder_deps="libopenh264"
libopenjpeg_decoder_deps="libopenjpeg"
libopenjpeg_encoder_deps="libopenjpeg"
+libopenmpt_demuxer_deps="libopenmpt"
libopus_decoder_deps="libopus"
libopus_encoder_deps="libopus"
libopus_encoder_select="audio_frame_queue"
@@ -5667,6 +5670,7 @@ enabled libopenjpeg && { check_lib
openjpeg-2.1/openjpeg.h opj_version -lo
check_lib openjpeg-1.5/openjpeg.h opj_version
-lopenjpeg -DOPJ_STATIC ||
check_lib openjpeg.h opj_version -lopenjpeg
-DOPJ_STATIC ||
die "ERROR: libopenjpeg not found"; }
+enabled libopenmpt&& require_pkg_config libopenmpt
libopenmpt/libopenmpt.h openmpt_module_create
enabled libopus && require_pkg_config opus opus_multistream.h
opus_multistream_decoder_create
enabled libpulse && require_pkg_config libpulse pulse/pulseaudio.h
pa_context_new
enabled librtmp && require_pkg_config librtmp librtmp/rtmp.h
RTMP_Socket
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 813872b..c9b0d14 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -522,6 +522,7 @@ OBJS-$(CONFIG_LIBGME_DEMUXER)+= libgme.o
OBJS-$(CONFIG_LIBMODPLUG_DEMUXER)+= libmodplug.o
OBJS-$(CONFIG_LIBNUT_DEMUXER)+= libnut.o
OBJS-$(CONFIG_LIBNUT_MUXER) += libnut.o
+OBJS-$(CONFIG_LIBOPENMPT_DEMUXER)+= libopenmpt.o
OBJS-$(CONFIG_LIBRTMP) += librtmp.o
OBJS-$(CONFIG_LIBSSH_PROTOCOL) += libssh.o
OBJS-$(CONFIG_LIBSMBCLIENT_PROTOCOL) += libsmbclient.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ddf540c..de445b0 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -370,6 +370,7 @@ void av_register_all(void)
REGISTER_DEMUXER (LIBGME, libgme);
REGISTER_DEMUXER (LIBMODPLUG, libmodplug);
REGISTER_MUXDEMUX(LIBNUT, libnut);
+REGISTER_DEMUXER (LIBOPENMPT, libopenmpt);
initialized = 1;
}
diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
new file mode 100644
index 000..b2dcb9b
--- /dev/null
+++ b/libavformat/libopenmpt.c
@@ -0,0 +1,182 @@
+/*
+ * Tracked MOD demuxer (libopenmpt)
+ * Copyright (c) 2016 Josh de Kock
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "avformat.h"
+#include "internal.h"
+
+typedef struct OpenMPTCo
Re: [FFmpeg-devel] [PATCH] Revert "avfilter/trim: add compatibility layer to not break ABI used by ffmpeg"
On Tue, Jun 07, 2016 at 06:05:34PM +0200, Michael Niedermayer wrote: > This reverts commit 9219ec93b145725ac74fbfbde7f67ac5135b85cf. > > Fixes Ticket 5411 > --- > libavfilter/trim.c | 26 +- > 1 file changed, 5 insertions(+), 21 deletions(-) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates 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] libavcodec: factor out SEI generation for A53 captions
On Sat, Jun 04, 2016 at 09:11:52PM +0300, Andrey Turkin wrote: > --- > libavcodec/internal.h| 15 + > libavcodec/libx264.c | 49 ++--- > libavcodec/qsvenc.c | 4 +-- > libavcodec/qsvenc_h264.c | 82 > +++- > libavcodec/utils.c | 43 + > 5 files changed, 101 insertions(+), 92 deletions(-) > > internal.h| 15 ++ > libx264.c | 49 +++--- > qsvenc.c |4 -- > qsvenc_h264.c | 82 > ++ > utils.c | 43 ++ > 5 files changed, 101 insertions(+), 92 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] ffmpeg_vdpau: Re-add ability to ignore level check
On 2016-06-08 21:54, Mark Thompson wrote: On 08/06/16 13:59, Carl Eugen Hoyos wrote: Mark Thompson jkqxz.net> writes: Uses the global -hwaccel_lax_profile_check option (may be misnamed for this purpose, but it has the right spirit). Iirc, all old x264 files have a very high profile set (5.0?). Is there a usecase for the default not being to accept any profile? (You mean level rather than profile there, right?) The point here is that the driver has declared its capabilities, and the given stream is not within those capabilities so the hwaccel should not be used because it will not work (the software decoder should be used instead, which will supports a wider set of streams). However, in reality we have known cases where the driver is broken and incorrectly reports this information, and can in fact decode some streams which it has stated it is unable to. Now, obviously fixing the driver to correctly report capabilities would be the way to actually fix the problem, but we don't control that. This option allows the user to ignore the declared capabilities of the driver and attempt decode anyway - it may then fail, but the user did explicitly request it so if it doesn't work then it is their problem. Setting it by default would result in some streams which previously worked now unexpectedly failing, which would be worse than the current situation. I hope that was clearer. Is there a specific example you're thinking of? As with Carl, the only thing I'm aware of is the handling of h.264 levels. The nvidia driver doesn't declare support for anything higher than 4.1, although the hardware will successfully decode files that are not 4.1 conformant, and in fact, there is an inherent contradiction as the driver does declare support for 4K resolutions, which requires level 4.2/4.3 for practical bitrates and framerates. In this specific case, I think level enforcement is unhelpful and it's common to see media players setting the flag to ignore level enforcement. So I'd probably be in favour of reversing the default on level enforcement. Do you have real world examples that are genuinely out-of-spec for the hardware, and would have been correctly excluded by the level check? --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
