[FFmpeg-devel] [PATCH] avformat/img2dec: Use AVOpenCallback
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/img2dec.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index db4b4b7..1039cce 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -370,6 +370,10 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
int size[3] = { 0 }, ret[3] = { 0 };
AVIOContext *f[3] = { NULL };
AVCodecContext *codec = s1->streams[0]->codec;
+AVOpenCallback open_func = s1->open_cb;
+
+if (!open_func)
+open_func = ffio_open2_wrapper;
if (!s->is_pipe) {
/* loop over input */
@@ -396,7 +400,7 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
!s->loop &&
!s->split_planes) {
f[i] = s1->pb;
-} else if (avio_open2(&f[i], filename, AVIO_FLAG_READ,
+} else if (open_func(s1, &f[i], filename, AVIO_FLAG_READ,
&s1->interrupt_callback, NULL) < 0) {
if (i >= 1)
break;
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
Hendrik Leppkes wrote: I do not agree that it should be a warning. As outlined in the commit message and this thread, there are serious flaws with frame threading and hwaccel. I'm fine with it being an error, but since it is an API change, it should follow the usual deprecation period to allow downstream users time to fix it. Meanwhile it can be a warning so that people notice the problem. Its fundamentally broken, and making it a warning would re-introduce known crashes. So no. So are the flaws in ffmpeg or particular drivers? It does seem a shame perf wise, I've been testing my AMD UVD decode recently and for 500 UHD frames in a really high bitrate h264 file it's like - ffmpeg threaded = 16 sec. ffmpeg single thread = 20 sec. gstreamer vaapi 14 sec. gstreamer omx 10 sec. the omx is a faster as the others do nv12 -> I420 on cpu (AFAICT) Maybe -threads 1 hurts perf by limiting the format conversion as well? Is there a way to get whatever the h/w spits out (nv12) directly? Trying to ask for nv12 seemed to get a double conversion. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/ass_split: Fix null pointer dereference in ff_ass_style_get()
On 17.01.2016 15:55, Michael Niedermayer wrote: > From: Michael Niedermayer > > Fixes: > 55d71971da50365d542ed14b65565fe1/signal_sigsegv_4765a4_8499_f146af090a94f591d6254515c7700ef5.mkv > > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind > Signed-off-by: Michael Niedermayer > --- > libavcodec/ass_split.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c > index 9bc7b9d..f84a686 100644 > --- a/libavcodec/ass_split.c > +++ b/libavcodec/ass_split.c > @@ -525,7 +525,7 @@ ASSStyle *ff_ass_style_get(ASSSplitContext *ctx, const > char *style) > if (!style || !*style) > style = "Default"; > for (i=0; istyles_count; i++) > -if (!strcmp(ass->styles[i].name, style)) > +if (ass->styles[i].name && !strcmp(ass->styles[i].name, style)) > return ass->styles + i; > return NULL; > } > Looks good to me. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffplay: Update docs after previous changes in ffplay mouse behaviour.
Signed-off-by: Vittorio Gambaletta --- doc/ffplay.texi |5 - ffplay.c|3 ++- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/ffplay.texi b/doc/ffplay.texi index 2a35c21..4bc3ced 100644 --- a/doc/ffplay.texi +++ b/doc/ffplay.texi @@ -238,9 +238,12 @@ Seek to the previous/next chapter. or if there are no chapters Seek backward/forward 10 minutes. -@item mouse click +@item right mouse click Seek to percentage in file corresponding to fraction of width. +@item left mouse double-click +Toggle full screen. + @end table @c man end diff --git a/ffplay.c b/ffplay.c index 5b473e9..2cfdf26 100644 --- a/ffplay.c +++ b/ffplay.c @@ -3738,7 +3738,8 @@ void show_help_default(const char *opt, const char *arg) "left/right seek backward/forward 10 seconds\n" "down/up seek backward/forward 1 minute\n" "page down/page up seek backward/forward 10 minutes\n" - "mouse click seek to percentage in file corresponding to fraction of width\n" + "right mouse click seek to percentage in file corresponding to fraction of width\n" + "left double-click toggle full screen\n" ); } ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/2] ffplay: Toggle full screen when double-clicking the video window with the left mouse button.
On 19/01/2016 23:40:22 CET, Marton Balint wrote: On Tue, 19 Jan 2016, Marton Balint wrote: On Tue, 19 Jan 2016, Vittorio Gambaletta (VittGam) wrote: Now that the seek only happens with the right mouse button, it makes sense to toggle full screen when double-clicking with the left mouse button, like other video players do. Signed-off-by: Vittorio Gambaletta Thanks, applied. Hmm, on second thought we forgot the docs update in ffplay.c and in doc/ffplay.texi. Could you send a patch for that as well? Sure! Will do now. Thanks, Vittorio ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/avio: Remove url options parsing
On 19.01.2016 22:13, Michael Niedermayer wrote: > From: Michael Niedermayer > > This feature is not know much or used much AFAIK, and it might be helpfull in > exploits. > No specific case is known where it can be used in an exploit though I have no idea how widely used this feature is, but it is mentioned in doc/protocols.texi: " Extract a chapter from a DVD VOB file (start and end sectors obtained externally and multiplied by 2048): @example subfile,,start,153391104,end,268142592,,:/media/dvd/VIDEO_TS/VTS_08_1.VOB @end example Play an AVI file directly from a TAR archive: @example subfile,,start,183241728,end,366490624,,:archive.tar @end example " So at least this documentation would need updating. Also mentioning this in the Changelog/RELEASE_NOTES would be good. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
Hi Ronald, On 19.01.2016 21:53, Ronald S. Bultje wrote: > Crashes are never good and should be fixed immediately. > > What exact issue is left after the crash is fixed, and why? The issue is that VLC from git master doesn't compile with FFmpeg from git master, unless all hardware acceleration of VLC is disabled. The reason is that VLC apparently uses hwaccel with frame threading, and FFmpeg now errors out in this combination. Thus VLC added a configure check preventing the use of VLC's hardware acceleration with FFmpeg versions that don't allow the combination with frame threading. Changing VLC to not use frame threading for hwaccel seems like a lot of work, so it probably won't get done anytime soon. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/concatdec: set safe mode to enabled instead of auto
On 19.01.2016 22:13, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> This is safer, as a selected demuxer could still mean that it was
> auto-detected
> by a user application
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/concatdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index d226e15..de7b89a 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -710,7 +710,7 @@ static int concat_seek(AVFormatContext *avf, int stream,
>
> static const AVOption options[] = {
> { "safe", "enable safe mode",
> - OFFSET(safe), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, DEC },
> + OFFSET(safe), AV_OPT_TYPE_BOOL, {.i64 = 1}, -1, 1, DEC },
> { "auto_convert", "automatically convert bitstream format",
>OFFSET(auto_convert), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, DEC },
> { "segment_time_metadata", "output file segment start time and duration
> as packet metadata",
>
The change seems OK, but the documentation in doc/demuxers.texi should be
updated
accordingly.
Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On 19.01.2016 21:46, wm4 wrote: > On Tue, 19 Jan 2016 21:31:19 +0100 > Hendrik Leppkes wrote: >> On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun >> wrote: >>> On 19.01.2016 21:22, Hendrik Leppkes wrote: On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun wrote: They don't lack time, they lack understanding of the flaws in the system. >>> >>> How can you know that? >> >> Because I read the ticket, which says he doesn't want to do it, not >> that he doesn't have time to do it, and because I know that particular >> person and his attitude. > > It was discussed to death on #libav-devel too. And the conclusion was to allow hwaccel with frame threads? >> Its fundamentally broken, and making it a warning would re-introduce >> known crashes. So no. > > +1 Can the crashes be reproduced with VLC? If so, are they reported in the VLC bug tracker? > There was this idea that this could be fixed by having some sort of > wrapper decoder, which could take care of the fallback transparently > and without getting into these nasty threading issues. But no idea how > much work that would be. Can't the framework just ignore the threading setting when using a hwaccel? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
2016.01.19. 19:00 keltezéssel, Bodecs Bela írta: 2016.01.19. 16:53 keltezéssel, Carl Eugen Hoyos írta: Bodecs Bela vivanet.hu> writes: To retain the current behaviour and not to break any earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. So I think that the current behaviour is useful in some cases: when you use expression but you want to have fixed sized output even when the input frame size is changing. (If anybody wonder why does somebody use expression instead of fix value in this case? Well, if you write a script to handle many different sized input file.) For the new behaviour, I gave a usage scenario in my other post. And I know that the new behaviour is not important for most of the users. Additionally, most user do not care either behaviour because dynamically sized video content is very rare. This is the reason why I introduced the eval-mode option. So the user may decide which behaviour is good for him/her. So my patch has no risk for any current user but some of them will be happy because of the new feature. bb Carl Eugen ___ 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 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/2] ffplay: Toggle full screen when double-clicking the video window with the left mouse button.
On Tue, 19 Jan 2016, Marton Balint wrote: On Tue, 19 Jan 2016, Vittorio Gambaletta (VittGam) wrote: Now that the seek only happens with the right mouse button, it makes sense to toggle full screen when double-clicking with the left mouse button, like other video players do. Signed-off-by: Vittorio Gambaletta Thanks, applied. Hmm, on second thought we forgot the docs update in ffplay.c and in doc/ffplay.texi. Could you send a patch for that as well? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add fixed_dsp tests
On Tue, Jan 19, 2016 at 01:43:45PM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > tests/checkasm/Makefile| 3 + > tests/checkasm/checkasm.c | 3 + > tests/checkasm/checkasm.h | 1 + > tests/checkasm/fixed_dsp.c | 184 > + > 4 files changed, 191 insertions(+) > create mode 100644 tests/checkasm/fixed_dsp.c seems woking fine [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_overlay handles expression evaluation of frame size change in frame-by-frame evalutaion mode
On Tue, Jan 19, 2016 at 08:08:12PM +, Paul B Mahol wrote: > On 1/19/16, Bodecs Bela wrote: > > Hi All, > > > > vf_overlay video filter accepts expressions in its parameters. In > > 'frame-by-frame' evaluation mode it recalculates them regularly, but > > incoming video frame size changes did not reflect in their values. So if > > you used > > width or height of any source videos in expressions as parameters, > > they stayed on their initial values. This patch corrects this bug. > > > > > > Please consider to put this patch into the official ffmpeg source tree. > > > > thank you, > > > > Bela Bodecs > > > > > > lgtm applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/2] ffplay: Toggle full screen when double-clicking the video window with the left mouse button.
On Tue, 19 Jan 2016, Vittorio Gambaletta (VittGam) wrote: Now that the seek only happens with the right mouse button, it makes sense to toggle full screen when double-clicking with the left mouse button, like other video players do. Signed-off-by: Vittorio Gambaletta Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/2] ffplay: Seek only when pressing the right mouse button on the video window.
On Tue, 19 Jan 2016, Vittorio Gambaletta (VittGam) wrote: Seeking by clicking on the video window can be annoying, because the user might click on it accidentally while eg. trying to get focus on it, and ffplay seeks instead. This commit changes that behaviour to seek only when the right mouse button is used to click and drag on the window. Signed-off-by: Vittorio Gambaletta --- Thanks, applied. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v6 1/3] mips: improve detection of ISAs, FPU and ASEs (DSP, MSA)
On Thu, Jan 14, 2016 at 02:59:03PM +, Vicente Olivert Riera wrote: > Signed-off-by: Vicente Olivert Riera > --- > Changes v5 -> v6: > - Multiple changes: >- Use separate if blocks when detecting the MIPS ISA, this way when a block > disables one ISA it will be detected by the next one. Before the elif was > preventing this to be done. >- Don't use check_cflags and use only check_ldflags instead, which will > check if that flag is valid for compiling and linking. The compiler may > accept some cflags for compiling but not for linking, so if we check > first > for the cflags it will succeed, and the cflags will be added to the > CFLAGS > variable despite of the check_ldflags failing after that. This can cause > problems because of having multiple incompatible cflags enabled at the > same > time. >- Check if mipsfpu has been disabled, and if so, then use -msoft-float. > This > way we override the compiler default behavious which can be building for > hard-float. >- Explicitly disable the features that fail any check by adding "|| disable > $feature" at the end of the checks chain. > > Changes v4 -> v5: > - Check for msa.h and disable msa if not found. > > Changes v3 -> v4: > - Nothing. > > Changes v2 -> v3: > - Nothing. > > Changes v1 -> v2: > - Add a block of code for mipsdspr2 which was previously placed in the >first patch of this series causing a syntax error in the configure >script. >https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2015-November/183444.html make distclean ; ../configure --cross-prefix=/usr/mips-linux-gnu/bin/ --cc='ccache mips-linux-gnu-gcc-4.4' --arch=mips --target-os=linux --enable-cross-compile --disable-mipsfpu && make -j12 results in pages of: /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libswresample/libswresample.a(dither.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libswresample/libswresample.a(resample.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libswresample/libswresample.a(resample_dsp.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libavutil/libavutil.a(adler32.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libavutil/libavutil.a(aes.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libavutil/libavutil.a(aes_ctr.o) uses soft float /usr/lib/gcc/mips-linux-gnu/4.4.5/../../../../mips-linux-gnu/bin/ld: Warning: libavfilter/filtfmts-test uses hard float, libavutil/libavutil.a(audio_fifo.o) uses soft float [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- 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] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
2016.01.19. 22:23 keltezéssel, Paul B Mahol írta: On 1/19/16, Bodecs Bela wrote: 2016.01.19. 21:42 keltezessel, Paul B Mahol irta: On 1/19/16, wm4 wrote: On Tue, 19 Jan 2016 19:00:18 +0100 Bodecs Bela wrote: 2016.01.19. 16:53 keltezessel, Carl Eugen Hoyos irta: Bodecs Bela vivanet.hu> writes: To retain the current behaviour and not to break any earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. I think it's actually a bug. From what I can tell libavfilter's design doesn't actually support mid-stream reconfiguration, although it happens to work in some cases? It appears it's undocumented feature. Filter which changes parameters just calls avfilter_config_links(). But not all filter have been tested with this in mind. Working with mpeg-ts streams this feature is very usefull. I have tested vf_scale and vf_overlay, both of them work well now. This is the scenario where I use them: You have an mpeg-ts incoming stream and you transcode it to hls with a scaled down resolution. The incoming stream has constant PAL width and height but the aspect ratio regularly changes between 4/3 and 16/9 in the middle of the stream. But you want to create a 16/9 output with constant width/height regardless of incoming aspect ratio. In the 4/3 case you put black bars to both sides of screen. With my two recent patch - regarding vf_scale and vf_overlay - it is possible. Cascade the vf_scale and the vf_overlay filters. First you create a fix height but variable width output with vf_scale and than you overlay its output onto a fixed sized 16/9 black background, positioned dynamically to the center by vf_overlay. In case of incoming 16/9 a.r., the whole background will be covered by the usefull content and in case of 4/3 a.r. the usefull content only partially will cover the black background. These options were almost ready in these filters. (I know the padding filter would do the same job, but it lacks a dynamic frame-by-frame pad sizing feature) Willing to write patch for it? If you mean the pad filter, yes, I will check it. ___ 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] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
On 1/19/16, Bodecs Bela wrote: > > > 2016.01.19. 21:42 keltezessel, Paul B Mahol irta: >> On 1/19/16, wm4 wrote: >>> On Tue, 19 Jan 2016 19:00:18 +0100 >>> Bodecs Bela wrote: >>> 2016.01.19. 16:53 keltezessel, Carl Eugen Hoyos irta: > Bodecs Bela vivanet.hu> writes: > >> To retain the current behaviour and not to break any >> earlier app, a new config parameter has been introduced. > Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. >>> I think it's actually a bug. From what I can tell libavfilter's design >>> doesn't actually support mid-stream reconfiguration, although it >>> happens to work in some cases? >> It appears it's undocumented feature. Filter which changes parameters just >> calls >> avfilter_config_links(). >> >> But not all filter have been tested with this in mind. > Working with mpeg-ts streams this feature is very usefull. > I have tested vf_scale and vf_overlay, both of them work well now. > This is the scenario where I use them: > You have an mpeg-ts incoming stream and you transcode it to hls with a > scaled down resolution. > The incoming stream has constant PAL width and height but the aspect > ratio regularly changes between 4/3 and 16/9 in the middle of the stream. > But you want to create a 16/9 output with constant width/height > regardless of incoming aspect ratio. In the 4/3 case you put black bars > to both sides of screen. > With my two recent patch - regarding vf_scale and vf_overlay - it is > possible. > Cascade the vf_scale and the vf_overlay filters. > First you create a fix height but variable width output with vf_scale > and than you overlay its output onto a fixed sized 16/9 black > background, positioned dynamically to the center by vf_overlay. > In case of incoming 16/9 a.r., the whole background will be covered by > the usefull content and in case of 4/3 a.r. the usefull content only > partially will cover the black background. > These options were almost ready in these filters. > (I know the padding filter would do the same job, but it lacks a dynamic > frame-by-frame pad sizing feature) Willing to write patch for it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/concatdec: set safe mode to enabled instead of auto
From: Michael Niedermayer
This is safer, as a selected demuxer could still mean that it was auto-detected
by a user application
Signed-off-by: Michael Niedermayer
---
libavformat/concatdec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index d226e15..de7b89a 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -710,7 +710,7 @@ static int concat_seek(AVFormatContext *avf, int stream,
static const AVOption options[] = {
{ "safe", "enable safe mode",
- OFFSET(safe), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, DEC },
+ OFFSET(safe), AV_OPT_TYPE_BOOL, {.i64 = 1}, -1, 1, DEC },
{ "auto_convert", "automatically convert bitstream format",
OFFSET(auto_convert), AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, DEC },
{ "segment_time_metadata", "output file segment start time and duration as
packet metadata",
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/avio: Remove url options parsing
From: Michael Niedermayer
This feature is not know much or used much AFAIK, and it might be helpfull in
exploits.
No specific case is known where it can be used in an exploit though
Signed-off-by: Michael Niedermayer
---
libavformat/avio.c | 30 +-
1 file changed, 1 insertion(+), 29 deletions(-)
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 21713d9..21655d8 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -146,33 +146,8 @@ static int url_alloc_for_protocol(URLContext **puc, struct
URLProtocol *up,
goto fail;
}
if (up->priv_data_class) {
-int proto_len= strlen(up->name);
-char *start = strchr(uc->filename, ',');
*(const AVClass **)uc->priv_data = up->priv_data_class;
av_opt_set_defaults(uc->priv_data);
-if(!strncmp(up->name, uc->filename, proto_len) && uc->filename +
proto_len == start){
-int ret= 0;
-char *p= start;
-char sep= *++p;
-char *key, *val;
-p++;
-while(ret >= 0 && (key= strchr(p, sep)) && ppriv_data, p, key+1, 0);
-if (ret == AVERROR_OPTION_NOT_FOUND)
-av_log(uc, AV_LOG_ERROR, "Key '%s' not found.\n", p);
-*val= *key= sep;
-p= val+1;
-}
-if(ret<0 || p!=key){
-av_log(uc, AV_LOG_ERROR, "Error parsing options string
%s\n", start);
-av_freep(&uc->priv_data);
-av_freep(&uc);
-err = AVERROR(EINVAL);
-goto fail;
-}
-memmove(start, key+1, strlen(key));
-}
}
}
if (int_cb)
@@ -242,16 +217,13 @@ static struct URLProtocol *url_find_protocol(const char
*filename)
char proto_str[128], proto_nested[128], *ptr;
size_t proto_len = strspn(filename, URL_SCHEME_CHARS);
-if (filename[proto_len] != ':' &&
-(filename[proto_len] != ',' || !strchr(filename + proto_len + 1, ':'))
||
+if (filename[proto_len] != ':' ||
is_dos_path(filename))
strcpy(proto_str, "file");
else
av_strlcpy(proto_str, filename,
FFMIN(proto_len + 1, sizeof(proto_str)));
-if ((ptr = strchr(proto_str, ',')))
-*ptr = '\0';
av_strlcpy(proto_nested, proto_str, sizeof(proto_nested));
if ((ptr = strchr(proto_nested, '+')))
*ptr = '\0';
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
2016.01.19. 21:42 keltezéssel, Paul B Mahol írta: On 1/19/16, wm4 wrote: On Tue, 19 Jan 2016 19:00:18 +0100 Bodecs Bela wrote: 2016.01.19. 16:53 keltezessel, Carl Eugen Hoyos irta: Bodecs Bela vivanet.hu> writes: To retain the current behaviour and not to break any earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. I think it's actually a bug. From what I can tell libavfilter's design doesn't actually support mid-stream reconfiguration, although it happens to work in some cases? It appears it's undocumented feature. Filter which changes parameters just calls avfilter_config_links(). But not all filter have been tested with this in mind. Working with mpeg-ts streams this feature is very usefull. I have tested vf_scale and vf_overlay, both of them work well now. This is the scenario where I use them: You have an mpeg-ts incoming stream and you transcode it to hls with a scaled down resolution. The incoming stream has constant PAL width and height but the aspect ratio regularly changes between 4/3 and 16/9 in the middle of the stream. But you want to create a 16/9 output with constant width/height regardless of incoming aspect ratio. In the 4/3 case you put black bars to both sides of screen. With my two recent patch - regarding vf_scale and vf_overlay - it is possible. Cascade the vf_scale and the vf_overlay filters. First you create a fix height but variable width output with vf_scale and than you overlay its output onto a fixed sized 16/9 black background, positioned dynamically to the center by vf_overlay. In case of incoming 16/9 a.r., the whole background will be covered by the usefull content and in case of 4/3 a.r. the usefull content only partially will cover the black background. These options were almost ready in these filters. (I know the padding filter would do the same job, but it lacks a dynamic frame-by-frame pad sizing feature) bb ___ 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][RFC] avcodec: disallow hwaccel with frame threads
Hi, On Tue, Jan 19, 2016 at 3:41 PM, Andreas Cadhalpun < andreas.cadhal...@googlemail.com> wrote: > On 19.01.2016 21:31, Hendrik Leppkes wrote: > > On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun > > wrote: > >> On 19.01.2016 21:22, Hendrik Leppkes wrote: > >>> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun > >>> wrote: > On 22.10.2015 11:44, Hendrik Leppkes wrote: > They now made VLC's configure error out when compiling with FFmpeg > [1], > because they currently lack time [2] to fix this the way you suggest > and Libav doesn't return this error. > > >>> > >>> They don't lack time, they lack understanding of the flaws in the > system. > >> > >> How can you know that? > > > > Because I read the ticket, which says he doesn't want to do it, not > > that he doesn't have time to do it, and because I know that particular > > person and his attitude. > > Let's not get personal, please. > > Thus I think it would be better to reduce this to a warning for the > time being and maybe add a FF_API_* changing it to an error after > the usual deprecation period. > > >>> > >>> I do not agree that it should be a warning. As outlined in the commit > >>> message and this thread, there are serious flaws with frame threading > >>> and hwaccel. > >> > >> I'm fine with it being an error, but since it is an API change, it > >> should follow the usual deprecation period to allow downstream users > >> time to fix it. Meanwhile it can be a warning so that people notice > >> the problem. > > > > Its fundamentally broken, and making it a warning would re-introduce > > known crashes. So no. > > What do other developers think about this? Crashes are never good and should be fixed immediately. What exact issue is left after the crash is fixed, and why? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On Tue, 19 Jan 2016 21:31:19 +0100 Hendrik Leppkes wrote: > On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun > wrote: > > On 19.01.2016 21:22, Hendrik Leppkes wrote: > >> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun > >> wrote: > >>> On 22.10.2015 11:44, Hendrik Leppkes wrote: > On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin wrote: > > VLC is using frame threading with hwaccel > > Then they should fix their usage, its broken by design, as explained > in detail my post earlier in this thread. > >>> > >>> Care to provide a patch for them? > >> > >> > >> This requires deep understanding of the code in question, so nothing > >> anyone not familiar with the code can easily fix, so no patches for > >> downstreams will be provided. > > > > That suggests that fixing it properly requires a lot of time. > > > >>> They now made VLC's configure error out when compiling with FFmpeg [1], > >>> because they currently lack time [2] to fix this the way you suggest > >>> and Libav doesn't return this error. > >>> > >> > >> They don't lack time, they lack understanding of the flaws in the system. > > > > How can you know that? > > Because I read the ticket, which says he doesn't want to do it, not > that he doesn't have time to do it, and because I know that particular > person and his attitude. It was discussed to death on #libav-devel too. > Its fundamentally broken, and making it a warning would re-introduce > known crashes. So no. +1 There was this idea that this could be fixed by having some sort of wrapper decoder, which could take care of the fallback transparently and without getting into these nasty threading issues. But no idea how much work that would be. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
On 1/19/16, wm4 wrote: > On Tue, 19 Jan 2016 19:00:18 +0100 > Bodecs Bela wrote: > >> 2016.01.19. 16:53 keltezessel, Carl Eugen Hoyos irta: >> > Bodecs Bela vivanet.hu> writes: >> > >> >> To retain the current behaviour and not to break any >> >> earlier app, a new config parameter has been introduced. >> > Is the current behaviour useful or do you consider it a bug? >> First I thought that it was a bug, but I borrowed an idea from >> vf_overlay filter, where there is a very same config parameter causing a >> very similar behaviour distinction on expression evaluation. >> I will soon post a patch to vf_overlay where there was really a bug in >> this behaviour. > > I think it's actually a bug. From what I can tell libavfilter's design > doesn't actually support mid-stream reconfiguration, although it > happens to work in some cases? It appears it's undocumented feature. Filter which changes parameters just calls avfilter_config_links(). But not all filter have been tested with this in mind. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On 19.01.2016 21:31, Hendrik Leppkes wrote: > On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun > wrote: >> On 19.01.2016 21:22, Hendrik Leppkes wrote: >>> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun >>> wrote: On 22.10.2015 11:44, Hendrik Leppkes wrote: They now made VLC's configure error out when compiling with FFmpeg [1], because they currently lack time [2] to fix this the way you suggest and Libav doesn't return this error. >>> >>> They don't lack time, they lack understanding of the flaws in the system. >> >> How can you know that? > > Because I read the ticket, which says he doesn't want to do it, not > that he doesn't have time to do it, and because I know that particular > person and his attitude. Let's not get personal, please. Thus I think it would be better to reduce this to a warning for the time being and maybe add a FF_API_* changing it to an error after the usual deprecation period. >>> >>> I do not agree that it should be a warning. As outlined in the commit >>> message and this thread, there are serious flaws with frame threading >>> and hwaccel. >> >> I'm fine with it being an error, but since it is an API change, it >> should follow the usual deprecation period to allow downstream users >> time to fix it. Meanwhile it can be a warning so that people notice >> the problem. > > Its fundamentally broken, and making it a warning would re-introduce > known crashes. So no. What do other developers think about this? Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
2016.01.19. 21:09 keltezéssel, wm4 írta: On Tue, 19 Jan 2016 19:00:18 +0100 Bodecs Bela wrote: 2016.01.19. 16:53 keltezéssel, Carl Eugen Hoyos írta: Bodecs Bela vivanet.hu> writes: To retain the current behaviour and not to break any earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. I think it's actually a bug. From what I can tell libavfilter's design doesn't actually support mid-stream reconfiguration, although it happens to work in some cases? via the zmq command interface you can send a command to alter width/height anytime in vf_scale filter. vf_scale filter handles this correctly. I think, this is definitely a sign of "mid-stream reconfiguration support". ___ 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][RFC] avcodec: disallow hwaccel with frame threads
On Tue, Jan 19, 2016 at 9:27 PM, Andreas Cadhalpun wrote: > On 19.01.2016 21:22, Hendrik Leppkes wrote: >> On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun >> wrote: >>> On 22.10.2015 11:44, Hendrik Leppkes wrote: On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin wrote: > VLC is using frame threading with hwaccel Then they should fix their usage, its broken by design, as explained in detail my post earlier in this thread. >>> >>> Care to provide a patch for them? >> >> >> This requires deep understanding of the code in question, so nothing >> anyone not familiar with the code can easily fix, so no patches for >> downstreams will be provided. > > That suggests that fixing it properly requires a lot of time. > >>> They now made VLC's configure error out when compiling with FFmpeg [1], >>> because they currently lack time [2] to fix this the way you suggest >>> and Libav doesn't return this error. >>> >> >> They don't lack time, they lack understanding of the flaws in the system. > > How can you know that? Because I read the ticket, which says he doesn't want to do it, not that he doesn't have time to do it, and because I know that particular person and his attitude. > >>> Thus I think it would be better to reduce this to a warning for the >>> time being and maybe add a FF_API_* changing it to an error after >>> the usual deprecation period. >>> >> >> I do not agree that it should be a warning. As outlined in the commit >> message and this thread, there are serious flaws with frame threading >> and hwaccel. > > I'm fine with it being an error, but since it is an API change, it > should follow the usual deprecation period to allow downstream users > time to fix it. Meanwhile it can be a warning so that people notice > the problem. Its fundamentally broken, and making it a warning would re-introduce known crashes. So no. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On 19.01.2016 21:22, Hendrik Leppkes wrote: > On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun > wrote: >> On 22.10.2015 11:44, Hendrik Leppkes wrote: >>> On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin wrote: VLC is using frame threading with hwaccel >>> >>> Then they should fix their usage, its broken by design, as explained >>> in detail my post earlier in this thread. >> >> Care to provide a patch for them? > > > This requires deep understanding of the code in question, so nothing > anyone not familiar with the code can easily fix, so no patches for > downstreams will be provided. That suggests that fixing it properly requires a lot of time. >> They now made VLC's configure error out when compiling with FFmpeg [1], >> because they currently lack time [2] to fix this the way you suggest >> and Libav doesn't return this error. >> > > They don't lack time, they lack understanding of the flaws in the system. How can you know that? >> Thus I think it would be better to reduce this to a warning for the >> time being and maybe add a FF_API_* changing it to an error after >> the usual deprecation period. >> > > I do not agree that it should be a warning. As outlined in the commit > message and this thread, there are serious flaws with frame threading > and hwaccel. I'm fine with it being an error, but since it is an API change, it should follow the usual deprecation period to allow downstream users time to fix it. Meanwhile it can be a warning so that people notice the problem. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On Tue, Jan 19, 2016 at 9:13 PM, Andreas Cadhalpun wrote: > On 22.10.2015 11:44, Hendrik Leppkes wrote: >> On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin wrote: >>> VLC is using frame threading with hwaccel >> >> Then they should fix their usage, its broken by design, as explained >> in detail my post earlier in this thread. > > Care to provide a patch for them? This requires deep understanding of the code in question, so nothing anyone not familiar with the code can easily fix, so no patches for downstreams will be provided. > > They now made VLC's configure error out when compiling with FFmpeg [1], > because they currently lack time [2] to fix this the way you suggest > and Libav doesn't return this error. > They don't lack time, they lack understanding of the flaws in the system. > Thus I think it would be better to reduce this to a warning for the > time being and maybe add a FF_API_* changing it to an error after > the usual deprecation period. > I do not agree that it should be a warning. As outlined in the commit message and this thread, there are serious flaws with frame threading and hwaccel. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
On Tue, 19 Jan 2016 19:00:18 +0100 Bodecs Bela wrote: > 2016.01.19. 16:53 keltezéssel, Carl Eugen Hoyos írta: > > Bodecs Bela vivanet.hu> writes: > > > >> To retain the current behaviour and not to break any > >> earlier app, a new config parameter has been introduced. > > Is the current behaviour useful or do you consider it a bug? > First I thought that it was a bug, but I borrowed an idea from > vf_overlay filter, where there is a very same config parameter causing a > very similar behaviour distinction on expression evaluation. > I will soon post a patch to vf_overlay where there was really a bug in > this behaviour. I think it's actually a bug. From what I can tell libavfilter's design doesn't actually support mid-stream reconfiguration, although it happens to work in some cases? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH][RFC] avcodec: disallow hwaccel with frame threads
On 22.10.2015 11:44, Hendrik Leppkes wrote: > On Thu, Oct 22, 2015 at 11:27 AM, Wang Bin wrote: >> VLC is using frame threading with hwaccel > > Then they should fix their usage, its broken by design, as explained > in detail my post earlier in this thread. Care to provide a patch for them? They now made VLC's configure error out when compiling with FFmpeg [1], because they currently lack time [2] to fix this the way you suggest and Libav doesn't return this error. Thus I think it would be better to reduce this to a warning for the time being and maybe add a FF_API_* changing it to an error after the usual deprecation period. Best regards, Andreas 1: https://git.videolan.org/?p=vlc.git;a=commitdiff;h=e57d32f664ff63ead57dca1fed7aedd59edac9fb 2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803868#54 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_overlay handles expression evaluation of frame size change in frame-by-frame evalutaion mode
On 1/19/16, Bodecs Bela wrote: > Hi All, > > vf_overlay video filter accepts expressions in its parameters. In > 'frame-by-frame' evaluation mode it recalculates them regularly, but > incoming video frame size changes did not reflect in their values. So if > you used > width or height of any source videos in expressions as parameters, > they stayed on their initial values. This patch corrects this bug. > > > Please consider to put this patch into the official ffmpeg source tree. > > thank you, > > Bela Bodecs > > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 5/5] libavfilter: VAAPI surface converter
On Tue, 19 Jan 2016 14:10:59 +
Mark Thompson wrote:
> ...
> >> +static int vaapi_conv_config_input(AVFilterLink *inlink)
> >> +{
> >> +AVFilterContext *avctx = inlink->dst;
> >> +VAAPIConvContext *ctx = avctx->priv;
> >> +AVVAAPISurfaceConfig *config = &ctx->input_config;
> >> +
> >> +if(inlink->format == AV_PIX_FMT_VAAPI) {
> >> +av_log(ctx, AV_LOG_INFO, "Input is VAAPI (using incoming
> >> surfaces).\n");
> >> +ctx->input_is_vaapi = 1;
> >> +return 0;
> >> +}
> >> +ctx->input_is_vaapi = 0;
> >> +
> >> +config->rt_format = VA_RT_FORMAT_YUV420;
> >> +config->av_format = AV_PIX_FMT_VAAPI;
> >> +
> >> +switch(inlink->format) {
> >> +case AV_PIX_FMT_BGR0:
> >> +case AV_PIX_FMT_BGRA:
> >> +config->image_format.fourcc = VA_FOURCC_BGRX;
> >> +config->image_format.byte_order = VA_LSB_FIRST;
> >> +config->image_format.bits_per_pixel = 32;
> >> +config->image_format.depth = 8;
> >> +config->image_format.red_mask = 0x00ff;
> >> +config->image_format.green_mask = 0xff00;
> >> +config->image_format.blue_mask = 0x00ff;
> >> +config->image_format.alpha_mask = 0x;
> >> +break;
> >> +
> >> +case AV_PIX_FMT_RGB0:
> >> +case AV_PIX_FMT_RGBA:
> >> +config->image_format.fourcc = VA_FOURCC_RGBX;
> >> +config->image_format.byte_order = VA_LSB_FIRST;
> >> +config->image_format.bits_per_pixel = 32;
> >> +config->image_format.depth = 8;
> >> +config->image_format.red_mask = 0x00ff;
> >> +config->image_format.green_mask = 0xff00;
> >> +config->image_format.blue_mask = 0x00ff;
> >> +config->image_format.alpha_mask = 0x;
> >> +break;
> >> +
> >> +case AV_PIX_FMT_NV12:
> >> +config->image_format.fourcc = VA_FOURCC_NV12;
> >> +config->image_format.bits_per_pixel = 12;
> >> +break;
> >> +case AV_PIX_FMT_YUV420P:
> >> +config->image_format.fourcc = VA_FOURCC_YV12;
> >> +config->image_format.bits_per_pixel = 12;
> >> +break;
> >
> > Doesn't this duplicate what vaQueryImageFormats() returns?
> >
> > Also I think your AV_PIX_FMT <-> VA_FOURCC mappings are duplicated
> > somewhere else to a degree.
>
> Hmm, yes. I didn't put much thought into this part, because it was only a
> token set of things to make my two initial use-cases work (RGB
> colour-conversion, YV12/NV12 scale).
>
> I'll leave it for now and come back to it when looking at expanding the
> inputs and outputs to be able to accept anything the hardware supports.
>
OK. Well, there is the impending HEVC 10 bit support, which will likely
require adding 1 or 2 new formats all over the place.
> ...
> >> +
> >> +#define OFFSET(member) offsetof(VAAPIConvContext, options.member)
> >> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> >> +static const AVOption vaapi_conv_options[] = {
> >> +{ "hardware_context", "VAAPI hardware context",
> >> + OFFSET(hardware_context), AV_OPT_TYPE_INT64,
> >> + { .i64 = 0 }, INT64_MIN, INT64_MAX, AV_OPT_FLAG_VIDEO_PARAM },
> >
> > Setting it this way is not ideal, but I guess there's no proper way yet.
>
> Yeah. Maybe there should be an AV_OPT_TYPE_POINTER for the user to cleanly
> do naughty things like this...
Or it's made first class and somehow added to libavfilter directly. I
don't know.
Does anyone else have suggestions?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/5] ffmpeg: initialisation code for VAAPI, hwaccel helper
On Tue, 19 Jan 2016 13:54:25 +
Mark Thompson wrote:
> >> +surface = (AVVAAPISurface*)input_frame->buf[0]->data;
> >
> > I haven't paid attention to this before. Shouldn't this be a vaapi
> > surface ID according to how libavcodec works?
>
> data[3] is the VAAPI surface ID, as used in libavcodec.
>
> Here we need to carry more information around in order to have enough context
> to map/unmap the surface.
Still slightly questionable. Does this mean the user can't create
surfaces and pass them to an API which happens to expect this set?
Also, it would be cleaner to set this on a data pointer too. For
example AVFrame.data[1]. (In fact, it would be pretty sane to do it
this way. This also fulfills the AVFrame "rule" that the memory
referenced by data pointers should be covered by AVFrame.buf. We even
thought about doing this in an uniform way across all hwaccels, so that
every hwaccel would use the same struct type.)
> >> +av_log(ctx, AV_LOG_DEBUG, "Retrieve data from surface %#x (format
> >> %#x).\n",
> >> + surface->id, output->av_format);
> >> +
> >> +av_vaapi_lock_hardware_context(ctx->hardware_context);
> >> +
> >> +if(output->av_format == AV_PIX_FMT_VAAPI) {
> >> +copying = 0;
> >> +av_log(ctx, AV_LOG_VERBOSE, "Surface %#x retrieved without
> >> copy.\n",
> >> + surface->id);
> >
> > I'm not sure if this (and the one below) deserves a log message, and at
> > a verbose level at that. If you really want this, a trace level might be
> > better.
>
> This was mainly so that at -v 55 I could see what was going on without being
> totally spammed (well, several lines per frame).
>
> I'll demote these (and others in the codecs which are saying the same thing).
In general, I'm not very fond of all these log calls (they just make
the code harder to read once you're done with the implementation), but
I'll leave this to you to decide. (Or maybe others have opinions.)
> >> +
> >> +} else {
> >> +err = ff_vaapi_map_surface(surface, 1);
> >> +if(err) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to map surface %#x.",
> >> + surface->id);
> >> +goto fail;
> >> +}
> >> +
> >> +copying = 1;
> >> +av_log(ctx, AV_LOG_VERBOSE, "Surface %#x mapped: image %#x data
> >> %p.\n",
> >> + surface->id, surface->image.image_id,
> >> surface->mapped_address);
> >> +}
> >> +
> >> +// The actual frame need not fill the surface.
> >> +av_assert0(input_frame->width <= output->width);
> >> +av_assert0(input_frame->height <= output->height);
> >> +
> >> +output_frame = &ctx->output_frame;
> >> +output_frame->width = input_frame->width;
> >> +output_frame->height = input_frame->height;
> >> +output_frame->format = output->av_format;
> >> +
> >> +if(copying) {
> >> +err = av_frame_get_buffer(output_frame, 32);
> >> +if(err < 0) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to get output buffer: %d
> >> (%s).\n",
> >> + err, av_err2str(err));
> >> +goto fail_unmap;
> >> +}
> >> +
> >> +err = ff_vaapi_copy_from_surface(output_frame, surface);
> >> +if(err < 0) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to copy frame data: %d
> >> (%s).\n",
> >> + err, av_err2str(err));
> >> +goto fail_unmap;
> >> +}
> >> +
> >> +} else {
> >> +// Just copy the hidden ID field.
> >> +output_frame->data[3] = input_frame->data[3];
> >> +}
> >> +
> >> +err = av_frame_copy_props(output_frame, input_frame);
> >> +if(err < 0) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to copy frame props: %d
> >> (%s).\n",
> >> + err, av_err2str(err));
> >> +goto fail_unmap;
> >> +}
> >> +
> >> +av_frame_unref(input_frame);
> >> +av_frame_move_ref(input_frame, output_frame);
> >> +
> >> + fail_unmap:
> >> +if(copying)
> >> +ff_vaapi_unmap_surface(surface, 0);
> >> + fail:
> >> +av_vaapi_unlock_hardware_context(ctx->hardware_context);
> >> +return err;
> >> +}
> >
> > This whole thing could be a utility function. (Libav was planning to do
> > this.)
>
> Unsure, I'll think about it along with AVFrame redesign. If nothing else,
> the map/copy/unmap could be abstracted out.
>
> >> +
> >> +static const struct {
> >> +VAProfile from;
> >> +VAProfile to;
> >> +} vaapi_profile_compatibility[] = {
> >> +#define FT(f, t) { VAProfile ## f, VAProfile ## t }
> >> +FT(MPEG2Simple, MPEG2Main ),
> >> +FT(H263Baseline, MPEG4AdvancedSimple),
> >> +FT(MPEG4Simple, MPEG4AdvancedSimple),
> >> +FT(MPEG4AdvancedSimple, MPEG4Main ),
> >> +FT(H264ConstrainedBaseline, H264Baseline),
> >> +FT(H264Baseline,H264Main), // (Not quite true.)
> >> +FT(H264Main,H264High),
>
Re: [FFmpeg-devel] [PATCH v3 1/5] libavutil: some VAAPI infrastructure
On Tue, 19 Jan 2016 13:19:36 +
Mark Thompson wrote:
> ...
> >> +
> >> +static void vaapi_codec_release_surface(void *opaque, uint8_t *data)
> >> +{
> >> +AVVAAPISurface *surface = opaque;
> >> +
> >> +av_assert0(surface->refcount > 0);
> >> +--surface->refcount;
> >> +}
> >
> > Maybe that's just me, but I think vaapi surfaces shouldn't break what
> > is guaranteed by AVFrame:
> >
> > - unreffing them is thread-safe
> > - unreffing the last AVFrame will also unref whatever manages the
> > surfaces (or alternatively, if the vaapi state is not refcounted, kill
> > the process if there are still AVFrames referencing the vaapi state,
> > as these AVFrames would essentially have dangling pointers)
> >
> > That's a bit more complex, but IMO worth it.
>
> Unref being thread safe is a bit annoying because of the locking - if the
> lock were recursive then it could work, but that pushes me into pthreadland
> to do it. Is that ok?
There could be a second lock which is not user-visible, and which
protects the surface pool only.
>
> I'm not sure what you mean by the second point. What do you want to also go
> when the last AVFrame gets unreferenced?
Imagine someone holding an AVFrame referencing the surface in the pool
at a time when the surface pool should be destroyed.
In my own vaapi code, I keep the pool alive until all frames are
unreferenced, even if the decoder is destroyed before. Helps with
making format changes simpler.
>
> I know the AVFrame setup is all a bit dubious because I still don't really
> "get" how AVFrames are meant to be used. I will think about it further.
Some explanation: AVFrames are refcounted via AVFrame.buf[]. Each
AVBufferRef is a refcounted memory region, and the AVFrame.data[]
pointers are supposed to point into one of the buffers. (All planes can
point into memory covered by AVFrame.buf[0], but it's also possible to
have each plane its own buffer.) If you create a reference to an
AVFrame with e.g. av_frame_ref(), new AVBufferRefs are created, which
increases the refcount of the internal buffer. Calling av_frame_unref()
deletes the AVBufferRefs and decrease the AVBuffer refcount. If the
AVBuffer's refcount reaches 0, the user-provided free callback is
invoked. (If there's no free callback, av_free() is called on the
original buffer data pointer.)
With hwaccels, the situation is a bit more confusing. There are no data
pointers, only an ID casted to a pointer. So it's harder to reason what
exactly AVBufferRef.data should be. But everything else can work in the
same way.
If the AVFrame is used in a different thread than the decoder, then it
can easily happen that the free callback is invoked in a different
thread.
> >> +
> >> +static int vaapi_get_surface(AVVAAPIPipelineContext *ctx,
> >> + AVVAAPISurfaceConfig *config,
> >> + AVVAAPISurface *surfaces, AVFrame *frame)
> >> +{
> >> +AVVAAPISurface *surface;
> >> +int i;
> >> +
> >> +for(i = 0; i < config->count; i++) {
> >> +if(surfaces[i].refcount == 0)
> >> +break;
> >> +}
> >> +if(i >= config->count) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to allocate surface "
> >> + "(%d in use).\n", config->count);
> >> +return AVERROR(ENOMEM);
> >> +}
> >> +surface = &surfaces[i];
> >> +
> >> +++surface->refcount;
> >> +frame->data[3] = (uint8_t*)(uintptr_t)surface->id;
> >> +frame->buf[0] = av_buffer_create((uint8_t*)surface, 0,
> >> + &vaapi_codec_release_surface,
> >> + surface, AV_BUFFER_FLAG_READONLY);
> >> +if(!frame->buf[0]) {
> >> +av_log(ctx, AV_LOG_ERROR, "Failed to allocate dummy buffer "
> >> + "for surface %#x.\n", surface->id);
> >> +return AVERROR(ENOMEM);
> >> +}
> >> +
> >> +frame->format = AV_PIX_FMT_VAAPI;
> >> +frame->width = config->width;
> >> +frame->height = config->height;
> >> +
> >> +return 0;
> >> +}
> >> +
> >> +int ff_vaapi_get_input_surface(AVVAAPIPipelineContext *ctx, AVFrame
> >> *frame)
> >> +{
> >> +return vaapi_get_surface(ctx, ctx->input, ctx->input_surfaces, frame);
> >> +}
> >> +
> >> +int ff_vaapi_get_output_surface(AVVAAPIPipelineContext *ctx, AVFrame
> >> *frame)
> >> +{
> >> +return vaapi_get_surface(ctx, ctx->output, ctx->output_surfaces,
> >> frame);
> >> +}
> >
> > I wonder if vaapi_get_surface() could instead be some sort of
> > independent frame pool? (But maybe the way you did is already elegant
> > wrt. how vaapi works?)
>
> The only trickiness here is that you have to declare all of the surfaces you
> are going to use for output when you create the pipeline context.
>
> So yes, probably, if I understood AVFrames better... Will consider along
> with the previous point.
Side note: it might also be possible to recreate the decoder and
recreate all surfaces if the
[FFmpeg-devel] [PATCH] vf_overlay handles expression evaluation of frame size change in frame-by-frame evalutaion mode
Hi All, vf_overlay video filter accepts expressions in its parameters. In 'frame-by-frame' evaluation mode it recalculates them regularly, but incoming video frame size changes did not reflect in their values. So if you used width or height of any source videos in expressions as parameters, they stayed on their initial values. This patch corrects this bug. Please consider to put this patch into the official ffmpeg source tree. thank you, Bela Bodecs >From e8002f3566d4ffe32fb49bb58384b42019f6c480 Tue, 19 Jan 2016 20:41:56 +0100 From: Bela Bodecs Date: Tue, 19 Jan 2016 20:22:06 +0100 Subject: [PATCH] vf_overlay: handles expression evaluation of frame size change in frame-by-frame evalutaion mode vf_overlay video filter accepts expressions in its parameters. In 'frame-by-frame' evaluation mode it recalculates them regularly, but incoming video frame size changes did not reflect in their values. So if you used width or height of any source videos in expressions as parameters, they stayed on their initial values. This patch corrects this bug. Signed-off-by: Bela Bodecs diff --git a/libavfilter/vf_overlay.c b/libavfilter/vf_overlay.c index 7457820..3eac7f0 100644 --- a/libavfilter/vf_overlay.c +++ b/libavfilter/vf_overlay.c @@ -597,10 +597,15 @@ s->var_values[VAR_N] = inlink->frame_count; s->var_values[VAR_T] = mainpic->pts == AV_NOPTS_VALUE ? NAN : mainpic->pts * av_q2d(inlink->time_base); s->var_values[VAR_POS] = pos == -1 ? NAN : pos; +s->var_values[VAR_OVERLAY_W] = s->var_values[VAR_OW] = second->width; +s->var_values[VAR_OVERLAY_H] = s->var_values[VAR_OH] = second->height; +s->var_values[VAR_MAIN_W ] = s->var_values[VAR_MW] = mainpic->width; +s->var_values[VAR_MAIN_H ] = s->var_values[VAR_MH] = mainpic->height; + eval_expr(ctx); av_log(ctx, AV_LOG_DEBUG, "n:%f t:%f pos:%f x:%f xi:%d y:%f yi:%d\n", s->var_values[VAR_N], s->var_values[VAR_T], s->var_values[VAR_POS], s->var_values[VAR_X], s->x, s->var_values[VAR_Y], s->y); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavformat/tcp.c : add send_buffer_size and recv_buffer_size options
> tabs aren’t allowed in ffmpeg git (except makefiles)
fixed
> SO_RCVBUF occurs twice, is that intended ?
Not intended, fixed, thanks.
> cleaning up the indention is welcome, but please in a seperate patch
Removed from this patch.
> also an update to the docs is needed
Done.
Updated patch follows:
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 8b2e310..05c4bdb 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1147,6 +1147,12 @@ than this time interval, raise error.
@item listen_timeout=@var{milliseconds}
Set listen timeout, expressed in milliseconds.
+
+@item recv_buffer_size=@var{bytes}
+Set receive buffer size, expressed bytes.
+
+@item send_buffer_size=@var{bytes}
+Set send buffer size, expressed bytes.
@end table
The following example shows how to setup a listening TCP connection
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index e02c64b..5738690 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -39,6 +39,8 @@ typedef struct TCPContext {
int open_timeout;
int rw_timeout;
int listen_timeout;
+int recv_buffer_size;
+int send_buffer_size;
} TCPContext;
#define OFFSET(x) offsetof(TCPContext, x)
@@ -48,6 +50,8 @@ static const AVOption options[] = {
{ "listen", "Listen for incoming connections", OFFSET(listen),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
{ "timeout", "set timeout (in microseconds) of socket I/O operations",
OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ "listen_timeout", "Connection awaiting timeout (in milliseconds)",
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
+{ "send_buffer_size", "Socket send buffer size (in bytes)",
OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
+{ "recv_buffer_size", "Socket receive buffer size (in bytes)",
OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
.flags = D|E },
{ NULL }
};
@@ -150,6 +154,15 @@ static int tcp_open(URLContext *h, const char *uri, int
flags)
h->is_streamed = 1;
s->fd = fd;
+/* Set the socket's send or receive buffer sizes, if specified.
+ If unspecified or setting fails, system default is used. */
+if (s->recv_buffer_size > 0) {
+setsockopt (fd, SOL_SOCKET, SO_RCVBUF, &s->recv_buffer_size, sizeof
(s->recv_buffer_size));
+}
+if (s->send_buffer_size > 0) {
+setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &s->send_buffer_size, sizeof
(s->send_buffer_size));
+}
+
freeaddrinfo(ai);
return 0;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
2016.01.19. 16:53 keltezéssel, Carl Eugen Hoyos írta: Bodecs Bela vivanet.hu> writes: To retain the current behaviour and not to break any earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? First I thought that it was a bug, but I borrowed an idea from vf_overlay filter, where there is a very same config parameter causing a very similar behaviour distinction on expression evaluation. I will soon post a patch to vf_overlay where there was really a bug in this behaviour. bb Carl Eugen ___ 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
[FFmpeg-devel] [PATCH v2] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw AVI video
Simplified the setting of the default palette for 1-bit AVI files in
raw_init_decoder().
Mats
>From d2ffdb87a32be74c1a3e1e9a996fa0b1cdda8b87 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 19 Jan 2016 18:48:06 +0100
Subject: [PATCH v2] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw AVI video
The stuff about 1-bit video not necessarily being black & white in
QuickTime goes for AVI as well. Being 1 bit per pixel only means that
the data is bi-level. The two colors can be any color. Since many
1 bpp AVI files don't have a palette following the BITMAPINFOHEADER,
I'm setting a "default" black & white palette in raw_init().
Mats
---
libavcodec/raw.c|2 +-
libavcodec/rawdec.c |9 ++---
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 3f2cc11..3979c5c 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -242,7 +242,7 @@ unsigned int avcodec_pix_fmt_to_codec_tag(enum AVPixelFormat fmt)
}
const PixelFormatTag avpriv_pix_fmt_bps_avi[] = {
-{ AV_PIX_FMT_MONOWHITE, 1 },
+{ AV_PIX_FMT_PAL8,1 },
{ AV_PIX_FMT_PAL8,2 },
{ AV_PIX_FMT_PAL8,4 },
{ AV_PIX_FMT_PAL8,8 },
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index cb0364c..141a551 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -41,7 +41,7 @@ typedef struct RawVideoContext {
AVBufferRef *palette;
int frame_size; /* size of the frame in bytes */
int flip;
-int is_1_2_4_bpp; // 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
+int is_1_2_4_bpp; // 1, 2 and 4 bpp raw in avi/mov
int is_yuv2;
int is_lt_16bpp; // 16bpp pixfmt and bits_per_coded_sample < 16
int tff;
@@ -94,8 +94,11 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
return AVERROR(ENOMEM);
if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
avpriv_set_systematic_pal2((uint32_t*)context->palette->data, avctx->pix_fmt);
-else
+else {
memset(context->palette->data, 0, AVPALETTE_SIZE);
+if (avctx->bits_per_coded_sample == 1)
+memset(context->palette->data, 0xff, 4);
+}
}
if ((avctx->extradata_size >= 9 &&
@@ -202,7 +205,7 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (!frame->buf[0])
return AVERROR(ENOMEM);
-// 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
+// 1, 2 and 4 bpp raw in avi/mov
if (context->is_1_2_4_bpp) {
int i;
uint8_t *dst = frame->buf[0]->data;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
>On 1/19/2016 2:24 PM, John Cox wrote:
>> On Tue, 19 Jan 2016 14:09:22 -0300, you wrote:
>>
>>> On 1/19/2016 2:05 PM, John Cox wrote:
> On 1/19/2016 9:46 AM, John Cox wrote:
>> +// Helper fns
>> +#ifndef hevc_mem_bits32
>> +static av_always_inline uint32_t hevc_mem_bits32(const void * buf,
>> const unsigned int offset)
>> +{
>> +return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset &
>> 7);
>> +}
>> +#endif
>> +
>> +#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
>> +#define hevc_clz32 hevc_clz32_builtin
>> +static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t
>> x)
>> +{
>> +// __builtin_clz says it works on ints - so adjust if int is >32
>> bits long
>> +return __builtin_clz(x) - (sizeof(int) * 8 - 32);
>
> Why aren't you simply using ff_clz?
Because it doesn't exist? or at least I can't find it.
>> +}
>> +#endif
>> +
>> +// It is unlikely that we will ever need this but include for
>> completeness
>
> There are at least two compilers we support that don't define __GNUC__, so
> it would be used.
> And in any case, isn't all this duplicating ff_clz, which is available in
> libavutil/inthmath.h?
Are you sure of that? I can find ff_ctz but no ff_clz...
I would happily be wrong.
>>>
>>> I assume you're writing this patch for the ffmpeg 2.8 branch or older,
>>> which you shouldn't.
>>> Always use the master branch. You'll find ff_clz there.
>>
>> Yes/no - the code I wrote had to work against 2.8 as that is what
>> Rasperry Pi are using at the moment. This patch is meant to be against
>> master so I can/will happily remove that code. (And I had the wrong
>> version checked out when commenting previously)
>>
>> By the way - can you tell me what the behaviour of ff_clz is when ints
>> are 64 bits long or is that never the case? Does it count up to 63 (I
>> am aware that the behaviour applied against 0 may be undefined) or does
>> it just work on the low 32 bits? (I assume the former)
>
>The generic version checks sizeof(unsigned), so the former.
>The GNU specific version using the builtin is meant to work with an unsigned
>int and not a fixed width data type, so it's probably safe to assume it will.
In that case then it would appear that the definition of ff_log2 is
wrong as that seems to assume a max 31:
#if HAVE_FAST_CLZ
#if AV_GCC_VERSION_AT_LEAST(3,4)
#ifndef ff_log2
# define ff_log2(x) (31 - __builtin_clz((x)|1))
# ifndef ff_log2_16bit
# define ff_log2_16bit av_log2
# endif
#endif /* ff_log2 */
#endif /* AV_GCC_VERSION_AT_LEAST(3,4) */
#endif
Regards
JC
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 1/19/2016 2:24 PM, John Cox wrote:
> On Tue, 19 Jan 2016 14:09:22 -0300, you wrote:
>
>> On 1/19/2016 2:05 PM, John Cox wrote:
On 1/19/2016 9:46 AM, John Cox wrote:
> +// Helper fns
> +#ifndef hevc_mem_bits32
> +static av_always_inline uint32_t hevc_mem_bits32(const void * buf, const
> unsigned int offset)
> +{
> +return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset & 7);
> +}
> +#endif
> +
> +#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
> +#define hevc_clz32 hevc_clz32_builtin
> +static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t x)
> +{
> +// __builtin_clz says it works on ints - so adjust if int is >32
> bits long
> +return __builtin_clz(x) - (sizeof(int) * 8 - 32);
Why aren't you simply using ff_clz?
>>>
>>> Because it doesn't exist? or at least I can't find it.
>>>
> +}
> +#endif
> +
> +// It is unlikely that we will ever need this but include for
> completeness
There are at least two compilers we support that don't define __GNUC__, so
it would be used.
And in any case, isn't all this duplicating ff_clz, which is available in
libavutil/inthmath.h?
>>>
>>> Are you sure of that? I can find ff_ctz but no ff_clz...
>>> I would happily be wrong.
>>
>> I assume you're writing this patch for the ffmpeg 2.8 branch or older, which
>> you shouldn't.
>> Always use the master branch. You'll find ff_clz there.
>
> Yes/no - the code I wrote had to work against 2.8 as that is what
> Rasperry Pi are using at the moment. This patch is meant to be against
> master so I can/will happily remove that code. (And I had the wrong
> version checked out when commenting previously)
>
> By the way - can you tell me what the behaviour of ff_clz is when ints
> are 64 bits long or is that never the case? Does it count up to 63 (I
> am aware that the behaviour applied against 0 may be undefined) or does
> it just work on the low 32 bits? (I assume the former)
The generic version checks sizeof(unsigned), so the former.
The GNU specific version using the builtin is meant to work with an unsigned
int and not a fixed width data type, so it's probably safe to assume it will.
>
> Thanks
>
> JC
>
>
> ___
> 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]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On Tue, 19 Jan 2016 14:09:22 -0300, you wrote:
>On 1/19/2016 2:05 PM, John Cox wrote:
>>> On 1/19/2016 9:46 AM, John Cox wrote:
+// Helper fns
+#ifndef hevc_mem_bits32
+static av_always_inline uint32_t hevc_mem_bits32(const void * buf, const
unsigned int offset)
+{
+return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset & 7);
+}
+#endif
+
+#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
+#define hevc_clz32 hevc_clz32_builtin
+static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t x)
+{
+// __builtin_clz says it works on ints - so adjust if int is >32 bits
long
+return __builtin_clz(x) - (sizeof(int) * 8 - 32);
>>>
>>> Why aren't you simply using ff_clz?
>>
>> Because it doesn't exist? or at least I can't find it.
>>
+}
+#endif
+
+// It is unlikely that we will ever need this but include for completeness
>>>
>>> There are at least two compilers we support that don't define __GNUC__, so
>>> it would be used.
>>> And in any case, isn't all this duplicating ff_clz, which is available in
>>> libavutil/inthmath.h?
>>
>> Are you sure of that? I can find ff_ctz but no ff_clz...
>> I would happily be wrong.
>
>I assume you're writing this patch for the ffmpeg 2.8 branch or older, which
>you shouldn't.
>Always use the master branch. You'll find ff_clz there.
Yes/no - the code I wrote had to work against 2.8 as that is what
Rasperry Pi are using at the moment. This patch is meant to be against
master so I can/will happily remove that code. (And I had the wrong
version checked out when commenting previously)
By the way - can you tell me what the behaviour of ff_clz is when ints
are 64 bits long or is that never the case? Does it count up to 63 (I
am aware that the behaviour applied against 0 may be undefined) or does
it just work on the low 32 bits? (I assume the former)
Thanks
JC
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 1/19/2016 2:05 PM, John Cox wrote:
>> On 1/19/2016 9:46 AM, John Cox wrote:
>>> +// Helper fns
>>> +#ifndef hevc_mem_bits32
>>> +static av_always_inline uint32_t hevc_mem_bits32(const void * buf, const
>>> unsigned int offset)
>>> +{
>>> +return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset & 7);
>>> +}
>>> +#endif
>>> +
>>> +#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
>>> +#define hevc_clz32 hevc_clz32_builtin
>>> +static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t x)
>>> +{
>>> +// __builtin_clz says it works on ints - so adjust if int is >32 bits
>>> long
>>> +return __builtin_clz(x) - (sizeof(int) * 8 - 32);
>>
>> Why aren't you simply using ff_clz?
>
> Because it doesn't exist? or at least I can't find it.
>
>>> +}
>>> +#endif
>>> +
>>> +// It is unlikely that we will ever need this but include for completeness
>>
>> There are at least two compilers we support that don't define __GNUC__, so
>> it would be used.
>> And in any case, isn't all this duplicating ff_clz, which is available in
>> libavutil/inthmath.h?
>
> Are you sure of that? I can find ff_ctz but no ff_clz...
> I would happily be wrong.
I assume you're writing this patch for the ffmpeg 2.8 branch or older, which
you shouldn't.
Always use the master branch. You'll find ff_clz there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
>On 1/19/2016 9:46 AM, John Cox wrote:
>> +// Helper fns
>> +#ifndef hevc_mem_bits32
>> +static av_always_inline uint32_t hevc_mem_bits32(const void * buf, const
>> unsigned int offset)
>> +{
>> +return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset & 7);
>> +}
>> +#endif
>> +
>> +#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
>> +#define hevc_clz32 hevc_clz32_builtin
>> +static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t x)
>> +{
>> +// __builtin_clz says it works on ints - so adjust if int is >32 bits
>> long
>> +return __builtin_clz(x) - (sizeof(int) * 8 - 32);
>
>Why aren't you simply using ff_clz?
Because it doesn't exist? or at least I can't find it.
>> +}
>> +#endif
>> +
>> +// It is unlikely that we will ever need this but include for completeness
>
>There are at least two compilers we support that don't define __GNUC__, so
>it would be used.
>And in any case, isn't all this duplicating ff_clz, which is available in
>libavutil/inthmath.h?
Are you sure of that? I can find ff_ctz but no ff_clz...
I would happily be wrong.
[snip]
JC
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavformat/tcp.c : add send_buffer_size and recv_buffer_size options
On Fri, Jan 15, 2016 at 10:16:45PM -0500, Perette Barella wrote:
> On 2016年01月15日, at 18:42, Michael Niedermayer wrote:
> > no, theres no patch
>
>
> Trying again, including it inline below:
>
> --- tcp.c 2015-12-19 21:07:51.0 -0500
> +++ /Users/perette/Desktop/tcp.c 2016-01-15 16:09:03.0 -0500
> @@ -37,19 +37,23 @@
> int fd;
> int listen;
> int open_timeout;
> int rw_timeout;
> int listen_timeout;
> +int recv_buffer_size;
> +int send_buffer_size;
> } TCPContext;
>
> #define OFFSET(x) offsetof(TCPContext, x)
> #define D AV_OPT_FLAG_DECODING_PARAM
> #define E AV_OPT_FLAG_ENCODING_PARAM
> static const AVOption options[] = {
> -{ "listen", "Listen for incoming connections", OFFSET(listen),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 2, .flags = D|E },
> -{ "timeout", "set timeout (in microseconds) of socket I/O
> operations", OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1, INT_MAX, .flags = D|E },
> -{ "listen_timeout", "Connection awaiting timeout (in milliseconds)",
> OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
> +{ "listen", "Listen for incoming connections",
> OFFSET(listen), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> 2, .flags = D|E },
> +{ "timeout", "set timeout (in microseconds) of socket I/O
> operations", OFFSET(rw_timeout), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1, INT_MAX, .flags = D|E },
> +{ "listen_timeout", "Connection awaiting timeout (in milliseconds)",
> OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
cleaning up the indention is welcome, but please in a seperate patch
> +{ "send_buffer_size", "Socket send buffer size (in bytes)",
> OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
> +{ "recv_buffer_size", "Socket receive buffer size (in bytes)",
> OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
> { NULL }
> };
>
> static const AVClass tcp_class = {
> .class_name = "tcp",
> @@ -148,10 +152,19 @@
> }
> }
>
> h->is_streamed = 1;
> s->fd = fd;
> +/* Set the socket's send or receive buffer sizes, if specified.
> + If unspecified or setting fails, system default is used. */
> +if (s->recv_buffer_size > 0) {
> + setsockopt (fd, SOL_SOCKET, SO_RCVBUF, &s->recv_buffer_size, sizeof
> (s->recv_buffer_size));
> +}
> +if (s->send_buffer_size > 0) {
> + setsockopt (fd, SOL_SOCKET, SO_RCVBUF, &s->send_buffer_size, sizeof
> (s->send_buffer_size));
> +}
tabs arent allowed in ffmpeg git (except makefiles)
SO_RCVBUF occurs twice, is that intended ?
also an update to the docs is needed
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 1/19/2016 9:46 AM, John Cox wrote:
> +// Helper fns
> +#ifndef hevc_mem_bits32
> +static av_always_inline uint32_t hevc_mem_bits32(const void * buf, const
> unsigned int offset)
> +{
> +return AV_RB32((const uint8_t *)buf + (offset >> 3)) << (offset & 7);
> +}
> +#endif
> +
> +#if AV_GCC_VERSION_AT_LEAST(3,4) && !defined(hevc_clz32)
> +#define hevc_clz32 hevc_clz32_builtin
> +static av_always_inline unsigned int hevc_clz32_builtin(const uint32_t x)
> +{
> +// __builtin_clz says it works on ints - so adjust if int is >32 bits
> long
> +return __builtin_clz(x) - (sizeof(int) * 8 - 32);
Why aren't you simply using ff_clz?
> +}
> +#endif
> +
> +// It is unlikely that we will ever need this but include for completeness
There are at least two compilers we support that don't define __GNUC__, so
it would be used.
And in any case, isn't all this duplicating ff_clz, which is available in
libavutil/inthmath.h?
> +#ifndef hevc_clz32
> +static inline unsigned int hevc_clz32(unsigned int x)
> +{
> +unsigned int n = 1;
> +if ((x & 0x) == 0) {
> +n += 16;
> +x <<= 16;
> +}
> +if ((x & 0xff00) == 0) {
> +n += 8;
> +x <<= 8;
> +}
> +if ((x & 0xf000) == 0) {
> +n += 4;
> +x <<= 4;
> +}
> +if ((x & 0xc000) == 0) {
> +n += 2;
> +x <<= 2;
> +}
> +return n - ((x >> 31) & 1);
> +}
> +#endif
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add fixed_dsp tests
Hi,
On Tue, Jan 19, 2016 at 11:43 AM, James Almer wrote:
> +report("vector_fmul_add");
grep suggests you may be able to do report("%s", name); to get the _reverse
suffix as appropriate.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
>John Cox kynesim.co.uk> writes: > >> On Tue, 19 Jan 2016 15:59:39 + (UTC), you wrote: >> >> >John Cox kynesim.co.uk> writes: >> > >> >> >> +#define UNCHECKED_BITSTREAM_READER 1 >> >> > >> >> >I don't think that's right, and is a security issue. >> >> >> >> I added that line as (nearly) every other decoder in >> >> liavcodec has it - >> > >> >Sure? >> >> OK - not all: >> >> h263dec.c >> h264.c >> h264_cabac.c >> h264_cavlc.c >> huffyuvdec.c >> ituh263dec.c >> mpegl2dec.c >> mpeg12.c >> mpeg4videodec.c >> mpeg4video_parser.c >> >> But that probably covers 90% of the video streams >> decoded with ffmpeg > >The three decoders mpegvideo, h263/asp and h264 are >not "(nearly) every other decoder", sorry! Sorry - I (obviously) misremembered the number of hits I got when I last did that search. >> >> in particular h264_cabac.c has it. >> > >> >Extensive testing was done before it was added. >> >> Testing that it doesn't seg-fault no matter what the >> input or some other sort of testing? > >Yes, tests that show that fuzzed input does not crash >the decoder are needed. > >But afaict, the change is unrelated to the rest of your >patch and should be discussed separately (imo). Yup - perfectly happy to put that can of worms to one side. >> >Could you confirm how much of the speedup comes >> >only from this change? >> >> Not an awful lot - a few % of the total improvement, but >> I was looking for everything I can get. I'll happily >> take it out of this patch if it is controversial. > >I wouldn't say controversial (I am all for it, sorry if >this wasn't clear) but I think it can be discussed after >your speedup was committed. Yup - at this point it is simply a distraction >> >While we definitely all welcome a noticeable speedup >> >of hevc decoding (and while my opinion on your patch >> >has limited relevance) I believe that the patch >> >absolutely has to be split: First step would be to >> >have a split between changes in the general code and >> >changes to arm assembly, I believe the first patch >> >then may be split further. >> >> Happy to split out the arm asm. > >Please do, my suggestion would be to start with the >changes to the C code. But it may be wise to wait for a >real review first. I've done enough review processes to know that waiting till the comments die down before doing anything is the way to go :-) JC >Carl Eugen > >___ >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
[FFmpeg-devel] [PATCH] checkasm: add fixed_dsp tests
Signed-off-by: James Almer
---
tests/checkasm/Makefile| 3 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/fixed_dsp.c | 184 +
4 files changed, 191 insertions(+)
create mode 100644 tests/checkasm/fixed_dsp.c
diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index e38d15b..698ceef 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -11,7 +11,10 @@ AVCODECOBJS-$(CONFIG_PIXBLOCKDSP) += pixblockdsp.o
AVCODECOBJS-$(CONFIG_V210_ENCODER) += v210enc.o
AVCODECOBJS-$(CONFIG_VP9_DECODER) += vp9dsp.o
+AVUTILOBJS += fixed_dsp.o
+
CHECKASMOBJS-$(CONFIG_AVCODEC) += $(AVCODECOBJS-yes)
+CHECKASMOBJS-$(CONFIG_AVUTIL) += $(AVUTILOBJS)
-include $(SRC_PATH)/tests/checkasm/$(ARCH)/Makefile
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 33c6d8c..0ae8d4c 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -64,6 +64,9 @@ static const struct {
const char *name;
void (*func)(void);
} tests[] = {
+#if CONFIG_AVUTIL
+{ "fixed_dsp", checkasm_check_fixed_dsp },
+#endif
#if CONFIG_AVCODEC
#if CONFIG_ALAC_DECODER
{ "alacdsp", checkasm_check_alacdsp },
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index bd17156..71d95f5 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -33,6 +33,7 @@
void checkasm_check_alacdsp(void);
void checkasm_check_bswapdsp(void);
void checkasm_check_dcadsp(void);
+void checkasm_check_fixed_dsp(void);
void checkasm_check_flacdsp(void);
void checkasm_check_fmtconvert(void);
void checkasm_check_h264pred(void);
diff --git a/tests/checkasm/fixed_dsp.c b/tests/checkasm/fixed_dsp.c
new file mode 100644
index 000..b3ea500
--- /dev/null
+++ b/tests/checkasm/fixed_dsp.c
@@ -0,0 +1,184 @@
+/*
+ * Copyright (c) 2015 James Almer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "checkasm.h"
+#include "libavutil/common.h"
+#include "libavutil/fixed_dsp.h"
+#include "libavutil/internal.h"
+#include "libavutil/mem.h"
+
+#define BUF_SIZE 256
+
+#define randomize_buffers() \
+do { \
+int i;\
+for (i = 0; i < BUF_SIZE; i++) { \
+src0[i] = sign_extend(rnd(), 24); \
+src1[i] = sign_extend(rnd(), 24); \
+src2[i] = sign_extend(rnd(), 24); \
+} \
+} while (0)
+
+static void check_vector_fmul(const int *src0, const int *src1)
+{
+LOCAL_ALIGNED_32(int, ref, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int, new, [BUF_SIZE]);
+
+declare_func(void, int *dst, const int *src0, const int *src1, int len);
+
+call_ref(ref, src0, src1, BUF_SIZE);
+call_new(new, src0, src1, BUF_SIZE);
+if (memcmp(ref, new, BUF_SIZE * sizeof(int)))
+fail();
+bench_new(new, src0, src1, BUF_SIZE);
+
+report("vector_fmul");
+}
+
+static void check_vector_fmul_add(const int *src0, const int *src1, const int
*src2)
+{
+LOCAL_ALIGNED_32(int, ref, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int, new, [BUF_SIZE]);
+
+declare_func(void, int *dst, const int *src0, const int *src1, const int
*src2, int len);
+
+call_ref(ref, src0, src1, src2, BUF_SIZE);
+call_new(new, src0, src1, src2, BUF_SIZE);
+if (memcmp(ref, new, BUF_SIZE * sizeof(int)))
+fail();
+bench_new(new, src0, src1, src2, BUF_SIZE);
+
+report("vector_fmul_add");
+}
+
+static void check_vector_fmul_reverse(const int *src0, const int *src1)
+{
+LOCAL_ALIGNED_32(int, ref, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int, new, [BUF_SIZE]);
+
+declare_func(void, int *dst, const int *src0, const int *src1, int len);
+
+call_ref(ref, src0, src1, BUF_SIZE);
+call_new(new, src0, src1, BUF_SIZE);
+if (memcmp(ref, new, BUF_SIZE * sizeof(int)))
+fail();
+bench_new(new, src0, src1, BUF_SIZE);
+
+report("vector_fmul_reverse");
+}
+
+static void check_vector_fmul_window(const int32_t *src0, const int32_t *src1,
const int32_t *win)
+{
+LOCAL_ALIGNED_32(int32_t, ref, [BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, new, [BUF_SIZE]);
+
+declare_func(void, int32_t *dst, const int32_t
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
John Cox kynesim.co.uk> writes: > On Tue, 19 Jan 2016 15:59:39 + (UTC), you wrote: > > >John Cox kynesim.co.uk> writes: > > > >> >> +#define UNCHECKED_BITSTREAM_READER 1 > >> > > >> >I don't think that's right, and is a security issue. > >> > >> I added that line as (nearly) every other decoder in > >> liavcodec has it - > > > >Sure? > > OK - not all: > > h263dec.c > h264.c > h264_cabac.c > h264_cavlc.c > huffyuvdec.c > ituh263dec.c > mpegl2dec.c > mpeg12.c > mpeg4videodec.c > mpeg4video_parser.c > > But that probably covers 90% of the video streams > decoded with ffmpeg The three decoders mpegvideo, h263/asp and h264 are not "(nearly) every other decoder", sorry! > >> in particular h264_cabac.c has it. > > > >Extensive testing was done before it was added. > > Testing that it doesn't seg-fault no matter what the > input or some other sort of testing? Yes, tests that show that fuzzed input does not crash the decoder are needed. But afaict, the change is unrelated to the rest of your patch and should be discussed separately (imo). > >Could you confirm how much of the speedup comes > >only from this change? > > Not an awful lot - a few % of the total improvement, but > I was looking for everything I can get. I'll happily > take it out of this patch if it is controversial. I wouldn't say controversial (I am all for it, sorry if this wasn't clear) but I think it can be discussed after your speedup was committed. > >While we definitely all welcome a noticeable speedup > >of hevc decoding (and while my opinion on your patch > >has limited relevance) I believe that the patch > >absolutely has to be split: First step would be to > >have a split between changes in the general code and > >changes to arm assembly, I believe the first patch > >then may be split further. > > Happy to split out the arm asm. Please do, my suggestion would be to start with the changes to the C code. But it may be wise to wait for a real review first. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls: Require the file extension to be m3u / m3u8 for probing to succeed
On Sat, Jan 16, 2016 at 05:28:34PM +0100, Michael Niedermayer wrote: > From: Michael Niedermayer > > If the filename isnt set by the user application then the code behaves like > before > > Signed-off-by: Michael Niedermayer > --- > libavformat/hls.c |4 > 1 file changed, 4 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On Tue, 19 Jan 2016 15:59:39 + (UTC), you wrote: >John Cox kynesim.co.uk> writes: > >> >> +#define UNCHECKED_BITSTREAM_READER 1 >> > >> >I don't think that's right, and is a security issue. >> >> I added that line as (nearly) every other decoder in >> liavcodec has it - > >Sure? OK - not all: h263dec.c h264.c h264_cabac.c h264_cavlc.c huffyuvdec.c ituh263dec.c mpegl2dec.c mpeg12.c mpeg4videodec.c mpeg4video_parser.c But that probably covers 90% of the video streams decoded with ffmpeg >> in particular h264_cabac.c has it. > >Extensive testing was done before it was added. Testing that it doesn't seg-fault no matter what the input or some other sort of testing? >Could you confirm how much of the speedup comes >only from this change? Not an awful lot - a few % of the total improvement, but I was looking for everything I can get. I'll happily take it out of this patch if it is controversial. >While we definitely all welcome a noticeable speedup >of hevc decoding (and while my opinion on your patch >has limited relevance) I believe that the patch >absolutely has to be split: First step would be to >have a split between changes in the general code and >changes to arm assembly, I believe the first patch >then may be split further. Happy to split out the arm asm. Splitting the rest of it will be harder if you want it to continue working at all intermediate points. >I am a little surprised that you wrote some asm >functions that are slower than what the compiler >produces: Did you analyze this? Yeah - they aren't much, if at all, slower but unless they are actively faster it seems silly to use difficult to maintain asm where the C will do. In the end it came down to the asm constraining the order in which stuff happens in the surrounding code and that wasn't always good. Regards JC >Carl Eugen > >___ >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]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
John Cox kynesim.co.uk> writes: > >> +#define UNCHECKED_BITSTREAM_READER 1 > > > >I don't think that's right, and is a security issue. > > I added that line as (nearly) every other decoder in > liavcodec has it - Sure? > in particular h264_cabac.c has it. Extensive testing was done before it was added. Could you confirm how much of the speedup comes only from this change? While we definitely all welcome a noticeable speedup of hevc decoding (and while my opinion on your patch has limited relevance) I believe that the patch absolutely has to be split: First step would be to have a split between changes in the general code and changes to arm assembly, I believe the first patch then may be split further. I am a little surprised that you wrote some asm functions that are slower than what the compiler produces: Did you analyze this? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
Bodecs Bela vivanet.hu> writes: > To retain the current behaviour and not to break any > earlier app, a new config parameter has been introduced. Is the current behaviour useful or do you consider it a bug? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil: add mastering display metadata sidedata
On Tue, Jan 19, 2016 at 01:34:12PM +0100, wm4 wrote:
> On Tue, 19 Jan 2016 13:02:25 +0100
> Michael Niedermayer wrote:
>
> > On Tue, Jan 19, 2016 at 10:18:16AM +0100, wm4 wrote:
> > > On Tue, 19 Jan 2016 00:32:43 +0100
> > > Michael Niedermayer wrote:
> > >
> > > > On Sat, Jan 16, 2016 at 04:19:38PM -0800, Neil Birkbeck wrote:
> > > > > Adding mastering display metadata struct to avutil. The mastering
> > > > > display metadata contains information
> > > > > about the mastering display color volume (SMPTE 2086:2014).
> > > > >
> > > > > This info comes from HEVC in the SEI_TYPE_MASTERING_DISPLAY_INFO and
> > > > > is soon to be included in MKV:
> > > > > https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o
> > > > > so it is similar to SEI FPA / stereo_mode in MKV and as such this
> > > > > patch follows how AVStereo3D is implemented.
> > > > >
> > > > > I'll add support to HEVC in a follow-up (and MKV when spec is
> > > > > approved).
> > > > >
> > > > > Signed-off-by: Neil Birkbeck
> > > > > ---
> > > > > libavutil/Makefile | 2 +
> > > > > libavutil/frame.h | 7 ++-
> > > > > libavutil/mastering_display_metadata.c | 43 +
> > > > > libavutil/mastering_display_metadata.h | 87
> > > > > ++
> > > > > libavutil/version.h| 2 +-
> > > > > 5 files changed, 139 insertions(+), 2 deletions(-)
> > > > > create mode 100644 libavutil/mastering_display_metadata.c
> > > > > create mode 100644 libavutil/mastering_display_metadata.h
> > > > >
> > > > > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > > > > index bf8c713..65b2d25 100644
> > > > > --- a/libavutil/Makefile
> > > > > +++ b/libavutil/Makefile
> > > > > @@ -38,6 +38,7 @@ HEADERS = adler32.h
> > > > > \
> > > > >log.h
> > > > >\
> > > > >macros.h
> > > > >\
> > > > >mathematics.h
> > > > >\
> > > > > + mastering_display_metadata.h
> > > > >\
> > > > >md5.h
> > > > >\
> > > > >mem.h
> > > > >\
> > > > >motion_vector.h
> > > > >\
> > > > > @@ -115,6 +116,7 @@ OBJS = adler32.o
> > > > > \
> > > > > log.o
> > > > >\
> > > > > log2_tab.o
> > > > >\
> > > > > mathematics.o
> > > > >\
> > > > > + mastering_display_metadata.o
> > > > >\
> > > > > md5.o
> > > > >\
> > > > > mem.o
> > > > >\
> > > > > murmur3.o
> > > > >\
> > > > > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > > > > index 9c6061a..308355b 100644
> > > > > --- a/libavutil/frame.h
> > > > > +++ b/libavutil/frame.h
> > > > > @@ -106,12 +106,17 @@ enum AVFrameSideDataType {
> > > > > * @endcode
> > > > > */
> > > > > AV_FRAME_DATA_SKIP_SAMPLES,
> > > > > -
> > > > > /**
> > > > > * This side data must be associated with an audio frame and
> > > > > corresponds to
> > > > > * enum AVAudioServiceType defined in avcodec.h.
> > > > > */
> > > > > AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
> > > >
> > > > > +/**
> > > > > + * Mastering display metadata associated with a video frame. The
> > > > > payload is
> > > > > + * an AVMasteringDisplayMetadata type and contains information
> > > > > about the
> > > > > + * mastering display color volume.
> > > > > + */
> > > > > +AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
> > > >
> > > > will this always stay the same or could it require to be extended in
> > > > the future ?
> > > > if future extensions may occur then it should be documented how that
> > > > would work. Would fields be added to the end of the struct ?
> > > > If so how would this be detected ?
> > > >
> > > > C does not gurantee the sizeof to change for the addition of fields
> > > > for example these 2 are both 8bytes on x86-64
> > > > typedef struct X { int a; char b; }X;
> > > > typedef struct Y { int a; char b; char c; }Y;
> > > >
> > > > defining the meaning of the sidedata byte per byte avoids the problem
> > > > of detectability it also makes the functi
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
Hi >On Tue, Jan 19, 2016 at 7:46 AM, John Cox wrote: > >> Hi >> >> I've just done a fair bit of work on hevc_cabac decode for the Rasberry >> Pi2 and I think that the patch is generally applicable. Patch is >> attached but you may prefer to take it from git: > > >Cool! Two non-technical comments first, I'll try to make time to review >in-depth/technically soon: > >1: > >> +#define UNCHECKED_BITSTREAM_READER 1 > >I don't think that's right, and is a security issue. I added that line as (nearly) every other decoder in liavcodec has it - in particular h264_cabac.c has it. Going forward: Checking bitstream position on every load is terribly wasteful - if at all possible a better idea is to allocate more space than is required in the input bitstream buffer so some overrun is permssible without seg fault and only check position at the end of every block or other medium sized unit. (You can nearly always work out what the worst case overread can be.) >2: your indentation of function declarations is weird. E.g.: > >+static inline uint32_t get_greaterx_bits(HEVCContext * const s, const >unsigned int n_end, int * const levels, >+int * const pprev_subset_coded, int * const psum, >+const unsigned int idx0_gt1, const unsigned int idx_gt2) > >We tend to indent the second line so it aligns with the opening bracket of >the first line. Fair enough >Alike, your indentation of const variable declarations: > >+uint8_t * const state0 = s->HEVClc->cabac_state + idx0_gt1; > >doesn't need a space between * and const. If that is required style then I'll abide by it, but I think that detracts noticably from readability. >Like I said, all non-technical, I'll do technical bits soon if I find time. >If other people like it and I haven't responded yet, just commit it and we >can address them post-push. Thanks JC >Ronald >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
Hi All,
currently scale video filter accepts expressions in its width and height
parameters but evaluates them only once at init and replaces them with
their actual values. Later on, if any parameter of incoming frames
changes - ie those were used in the original size expressions - then
they new values will not have any affect for width and heigth values.
They remain the same. This patch makes possible that width and height
expressions be evaluated frame-by-frame basis if width/height/sar/format
properties of incoming frame would change. To retain the current
behaviour and not to break any earlier app, a new config parameter has
been introduced. Its name is "eval" and it has two distinct values:
"init" and "frame". The default value is "init".
This feature is very usefull in case of DVBT mpeg-ts streams where SAR
may change
time-by-time from 4/3 to 16/9 and vica-versa and the size remains the
same and
and you want to create a variable sized output with 1/1 SAR.
Please consider to put this patch into the official ffmpeg source tree.
thank you,
Bela Bodecs
>From d5d14ed4a8d0e3c06843b4e4cee2a156ac7fd344 Tue, 19 Jan 2016 16:06:27 +0100
From: Bela Bodecs
Date: Mon, 18 Jan 2016 18:44:09 +0100
Subject: [PATCH] vf_scale: Detecting changes of incoming frame properties and dinamically evaluate width and height expressions
Currently scale filter accepts expressions in its width and height
parameters but evaluates them only once at init and replaces them with
their actual values. Later on, if any parameter of incoming frames
changes - ie those were used in the original size expressions - then
they new values will not have any affect for width and heigth values.
They remain the same. This patch makes possible that width and height
expressions be evaluated frame-by-frame basis if width/height/sar/format
properties of incoming frame would change. To retain the current
behaviour and not to break any earlier app, a new config parameter has
been introduced. Its name is "eval" and it has two distinct values:
"init" and "frame". The default value is "init".
This feature is very usefull in case of DVBT mpeg-ts streams where SAR
may change time-by-time from 4/3 to 16/9 and vica-versa and the size
remains the same and you want to create a variable sized output with 1/1
SAR.
Signed-off-by: Bela Bodecs
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index 7eabe00..ac9d4c3 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -69,10 +69,17 @@
VAR_OHSUB,
VAR_OVSUB,
VARS_NB
};
+enum EvalMode {
+EVAL_MODE_INIT,
+EVAL_MODE_FRAME,
+EVAL_MODE_NB
+};
+
+
typedef struct ScaleContext {
const AVClass *class;
struct SwsContext *sws; ///< software scaler context
struct SwsContext *isws[2]; ///< software scaler context for interlaced material
AVDictionary *opts;
@@ -110,10 +117,13 @@
int in_v_chr_pos;
int force_original_aspect_ratio;
int nb_slices;
+
+int eval_mode; ///< expression evaluation mode
+
} ScaleContext;
AVFilter ff_vf_scale2ref;
static av_cold int init_dict(AVFilterContext *ctx, AVDictionary **opts)
@@ -492,20 +502,28 @@
if (av_frame_get_colorspace(in) == AVCOL_SPC_YCGCO)
av_log(link->dst, AV_LOG_WARNING, "Detected unsupported YCgCo colorspace.\n");
if( in->width != link->w
|| in->height != link->h
- || in->format != link->format) {
+ || in->format != link->format
+ || in->sample_aspect_ratio.den != link->sample_aspect_ratio.den || in->sample_aspect_ratio.num != link->sample_aspect_ratio.num) {
int ret;
-snprintf(buf, sizeof(buf)-1, "%d", outlink->w);
-av_opt_set(scale, "w", buf, 0);
-snprintf(buf, sizeof(buf)-1, "%d", outlink->h);
-av_opt_set(scale, "h", buf, 0);
+
+if (scale->eval_mode == EVAL_MODE_INIT) {
+snprintf(buf, sizeof(buf)-1, "%d", outlink->w);
+av_opt_set(scale, "w", buf, 0);
+snprintf(buf, sizeof(buf)-1, "%d", outlink->h);
+av_opt_set(scale, "h", buf, 0);
+}
link->dst->inputs[0]->format = in->format;
link->dst->inputs[0]->w = in->width;
link->dst->inputs[0]->h = in->height;
+
+link->dst->inputs[0]->sample_aspect_ratio.den = in->sample_aspect_ratio.den;
+link->dst->inputs[0]->sample_aspect_ratio.num = in->sample_aspect_ratio.num;
+
if ((ret = config_props(outlink)) < 0)
return ret;
}
@@ -663,10 +681,13 @@
{ "decrease", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 1 }, 0, 0, FLAGS, "force_oar" },
{ "increase", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 2 }, 0, 0, FLAGS, "force_oar" },
{ "param0", "Scaler param 0", OFFSET(param[0]), AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT }, INT_MIN, INT_MAX, FLAGS },
{ "param1", "Scaler param 1", OFFSET(param[1]), AV_OPT_TYPE_DOUBLE, { .dbl = SWS_PARAM_DEFAULT }, INT_MIN,
[FFmpeg-devel] [PATCH] doc/demuxers: add some concat demuxer script examples
Attached patch adds some example scripts for the concat demuxer to the documentation. Regards, Tobias >From 5ffc11e8139476d18cd2eaa28338adb0dda80999 Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Tue, 19 Jan 2016 15:42:33 +0100 Subject: [PATCH] doc/demuxers: add some concat demuxer script examples Signed-off-by: Tobias Rapp --- doc/demuxers.texi | 21 + 1 file changed, 21 insertions(+) diff --git a/doc/demuxers.texi b/doc/demuxers.texi index fb1e4fb..3900272 100644 --- a/doc/demuxers.texi +++ b/doc/demuxers.texi @@ -214,6 +214,27 @@ The default is 0. @end table +@subsection Examples + +Example script which uses absolute filenames and includes some comments: +@example +# my first filename +file /mnt/share/file-1.wav +# my second filename including whitespace +file '/mnt/share/file 2.wav' +# my third filename including whitespace plus single quote +file '/mnt/share/file 3'\''.wav' +@end example + +Example script which allows for input format auto-probing, uses safe filenames +and sets the duration of the first file: +@example +ffconcat version 1.0 +file file-1.wav +duration 20.0 +file 'file 2.wav' +@end example + @section flv Adobe Flash Video Format demuxer. -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 5/5] libavfilter: VAAPI surface converter
On 19/01/16 12:27, wm4 wrote:
> On Mon, 18 Jan 2016 22:53:33 +
> Mark Thompson wrote:
>
>> ---
>> configure | 1 +
>> libavfilter/Makefile| 1 +
>> libavfilter/allfilters.c| 1 +
>> libavfilter/vf_vaapi_conv.c | 480
>>
>> 4 files changed, 483 insertions(+)
>> create mode 100644 libavfilter/vf_vaapi_conv.c
>>
>> diff --git a/configure b/configure
>> index 9da8e8b..71c0bc0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2913,6 +2913,7 @@ stereo3d_filter_deps="gpl"
>> subtitles_filter_deps="avformat avcodec libass"
>> super2xsai_filter_deps="gpl"
>> tinterlace_filter_deps="gpl"
>> +vaapi_conv_filter_deps="vaapi"
>> vidstabdetect_filter_deps="libvidstab"
>> vidstabtransform_filter_deps="libvidstab"
>> pixfmts_super2xsai_test_deps="super2xsai_filter"
>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> index e3e3561..9a4ca12 100644
>> --- a/libavfilter/Makefile
>> +++ b/libavfilter/Makefile
>> @@ -246,6 +246,7 @@ OBJS-$(CONFIG_TRANSPOSE_FILTER) +=
>> vf_transpose.o
>> OBJS-$(CONFIG_TRIM_FILTER) += trim.o
>> OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
>> OBJS-$(CONFIG_USPP_FILTER) += vf_uspp.o
>> +OBJS-$(CONFIG_VAAPI) += vf_vaapi_conv.o
>> OBJS-$(CONFIG_VECTORSCOPE_FILTER)+= vf_vectorscope.o
>> OBJS-$(CONFIG_VFLIP_FILTER) += vf_vflip.o
>> OBJS-$(CONFIG_VIDSTABDETECT_FILTER) += vidstabutils.o
>> vf_vidstabdetect.o
>> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
>> index 1faf393..cfbfdca 100644
>> --- a/libavfilter/allfilters.c
>> +++ b/libavfilter/allfilters.c
>> @@ -266,6 +266,7 @@ void avfilter_register_all(void)
>> REGISTER_FILTER(TRIM, trim, vf);
>> REGISTER_FILTER(UNSHARP,unsharp,vf);
>> REGISTER_FILTER(USPP, uspp, vf);
>> +REGISTER_FILTER(VAAPI_CONV, vaapi_conv, vf);
>> REGISTER_FILTER(VECTORSCOPE,vectorscope,vf);
>> REGISTER_FILTER(VFLIP, vflip, vf);
>> REGISTER_FILTER(VIDSTABDETECT, vidstabdetect, vf);
>> diff --git a/libavfilter/vf_vaapi_conv.c b/libavfilter/vf_vaapi_conv.c
>> new file mode 100644
>> index 000..5180e7c
>> --- /dev/null
>> +++ b/libavfilter/vf_vaapi_conv.c
>> @@ -0,0 +1,480 @@
>> +/*
>> + * VAAPI converter (scaling and colour conversion).
>> + *
>> + * Copyright (C) 2016 Mark Thompson
>> + *
>> + * 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 "avfilter.h"
>> +#include "formats.h"
>> +#include "internal.h"
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/opt.h"
>> +#include "libavutil/pixdesc.h"
>> +#include "libavutil/vaapi.h"
>> +
>> +#include
>> +
>> +typedef struct VAAPIConvContext {
>> +const AVClass *class;
>> +
>> +AVVAAPIHardwareContext *hardware_context;
>> +AVVAAPIPipelineConfig va_config;
>> +AVVAAPIPipelineContext va_context;
>> +int pipeline_initialised;
>> +
>> +int input_is_vaapi;
>> +AVVAAPISurfaceConfig input_config;
>> +AVVAAPISurfaceConfig output_config;
>> +
>> +int output_width;
>> +int output_height;
>> +
>> +struct {
>> +int64_t hardware_context;
>> +int output_size[2];
>> +} options;
>> +
>> +} VAAPIConvContext;
>> +
>> +
>> +static int vaapi_conv_query_formats(AVFilterContext *avctx)
>> +{
>> +VAAPIConvContext *ctx = avctx->priv;
>> +VAStatus vas;
>> +VAConfigAttrib rt_format = {
>> +.type = VAConfigAttribRTFormat
>> +};
>> +enum AVPixelFormat pix_fmt_list[16] = {
>> +AV_PIX_FMT_VAAPI,
>> +};
>> +int pix_fmt_count = 1, err;
>> +
>> +#if 0
>> +// The Intel driver doesn't return anything useful here - it only
>> +// declares support for YUV 4:2:0 formats, despite working perfectly
>> +// with 32-bit RGB ones. Given another usable platform, this will
>> +// need to be updated.
>> +vas = vaGetConfigAttributes(ctx->hardware_context->display,
>> +VAProfileNone, VAEntrypointVideoProc,
>> +&rt_form
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 01/19/2016 03:05 PM, Mats Peterson wrote: from "normal" indentations of 4 columns. But I'll try to stick to what's stick with ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 01/19/2016 02:51 PM, Ronald S. Bultje wrote:
What I did in vp8 (if I remember correctly) in those cases is to split the
top line:
static av_always_inline long_return_type_name
far_too_long_function_name(type arg1, type arg2,
type arg3, type arg4)
{
..
}
May be helpful, but all of this is very personal-taste-ish...
Ronald
Yes, that's one way to do it, of course :) Otherwise, *if* I'm forced to
do anything that breaks this rule, I always use 8 columns indentation
for anything that continues on to the next line, to differentiate it
from "normal" indentations of 4 columns. But I'll try to stick to what's
customary as much as I can.
Mats
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/5] ffmpeg: initialisation code for VAAPI, hwaccel helper
On 19/01/16 12:16, wm4 wrote:
> On Mon, 18 Jan 2016 22:50:50 +
> Mark Thompson wrote:
>
>> ---
>> Makefile | 1 +
>> ffmpeg.c | 5 +
>> ffmpeg.h | 5 +
>> ffmpeg_opt.c | 14 ++
>> ffmpeg_vaapi.c | 622
>> +
>> 5 files changed, 647 insertions(+)
>> create mode 100644 ffmpeg_vaapi.c
>>
>> diff --git a/Makefile b/Makefile
>> index 7836a20..be1d2ca 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -36,6 +36,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>> endif
>> OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>> OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o
>> +OBJS-ffmpeg-$(CONFIG_VAAPI) += ffmpeg_vaapi.o
>> OBJS-ffserver += ffserver_config.o
>>
>> TESTTOOLS = audiogen videogen rotozoom tiny_psnr tiny_ssim base64
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 1f4277c..e76879a 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -2603,6 +2603,11 @@ static int init_output_stream(OutputStream *ost, char
>> *error, int error_len)
>> !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
>> av_dict_set(&ost->encoder_opts, "b", "128000", 0);
>>
>> +#if CONFIG_VAAPI
>> +if(ost->enc->type == AVMEDIA_TYPE_VIDEO)
>> +vaapi_hardware_set_options(&ost->encoder_opts);
>> +#endif
>> +
>> if ((ret = avcodec_open2(ost->enc_ctx, codec, &ost->encoder_opts))
>> < 0) {
>> if (ret == AVERROR_EXPERIMENTAL)
>> abort_codec_experimental(codec, 1);
>> diff --git a/ffmpeg.h b/ffmpeg.h
>> index 20322b0..2134213 100644
>> --- a/ffmpeg.h
>> +++ b/ffmpeg.h
>> @@ -65,6 +65,7 @@ enum HWAccelID {
>> HWACCEL_VDA,
>> HWACCEL_VIDEOTOOLBOX,
>> HWACCEL_QSV,
>> +HWACCEL_VAAPI,
>> };
>>
>> typedef struct HWAccel {
>> @@ -577,5 +578,9 @@ int vda_init(AVCodecContext *s);
>> int videotoolbox_init(AVCodecContext *s);
>> int qsv_init(AVCodecContext *s);
>> int qsv_transcode_init(OutputStream *ost);
>> +int vaapi_decode_init(AVCodecContext *s);
>> +
>> +int vaapi_hardware_init(const char *device);
>> +int vaapi_hardware_set_options(AVDictionary **dict);
>>
>> #endif /* FFMPEG_H */
>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>> index 9b341cf..47ac467 100644
>> --- a/ffmpeg_opt.c
>> +++ b/ffmpeg_opt.c
>> @@ -82,6 +82,9 @@ const HWAccel hwaccels[] = {
>> #if CONFIG_LIBMFX
>> { "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
>> #endif
>> +#if CONFIG_VAAPI
>> +{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
>> +#endif
>> { 0 },
>> };
>>
>> @@ -442,6 +445,13 @@ static int opt_sdp_file(void *optctx, const char *opt,
>> const char *arg)
>> return 0;
>> }
>>
>> +static int opt_vaapi(void *optctx, const char *opt, const char *arg)
>> +{
>> +if(vaapi_hardware_init(arg))
>> +exit_program(1);
>> +return 0;
>> +}
>> +
>> /**
>> * Parse a metadata specifier passed as 'arg' parameter.
>> * @param arg metadata string to parse
>> @@ -3438,5 +3448,9 @@ const OptionDef options[] = {
>> { "dn", OPT_BOOL | OPT_VIDEO | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT, {
>> .off = OFFSET(data_disable) },
>> "disable data" },
>>
>> +#if CONFIG_VAAPI
>> +{ "vaapi", HAS_ARG, { .func_arg = opt_vaapi }, "set VAAPI hardware
>> context" },
>> +#endif
>> +
>> { NULL, },
>> };
>> diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
>> new file mode 100644
>> index 000..e04532c
>> --- /dev/null
>> +++ b/ffmpeg_vaapi.c
>> @@ -0,0 +1,622 @@
>> +/*
>> + * VAAPI helper for hardware-accelerated decoding.
>> + *
>> + * Copyright (C) 2016 Mark Thompson
>> + *
>> + * 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
>> +
>> +#include "ffmpeg.h"
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/avconfig.h"
>> +#include "libavutil/buffer.h"
>> +#include "libavutil/frame.h"
>> +#include "libavutil/imgutils.h"
>> +#include "libavutil/opt.h"
>> +#include "libavutil/pixfmt.h"
>> +#include "libavutil/thread.h"
>> +#include "libavutil/vaapi.h"
>> +
>> +#include "libavcodec/vaapi.h"
>> +
>> +#include
>> +#include
>> +
>> +
>> +static AVClass vaapi_class = {
>> +.class
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
Hi,
On Tue, Jan 19, 2016 at 8:42 AM, Mats Peterson <
matsp888-at-yahoo@ffmpeg.org> wrote:
> On 01/19/2016 02:40 PM, Ronald S. Bultje wrote:
>
>> We tend to indent the second line so it aligns with the opening bracket of
>> the first line.
>>
>
> Excuse me if i chime in here, Ronald, yes, I've noticed that as well.
> However, sometimes it can be quite awkward to do this alignment when having
> a lot of stuff before the opening bracket, and lots of parameters.
What I did in vp8 (if I remember correctly) in those cases is to split the
top line:
static av_always_inline long_return_type_name
far_too_long_function_name(type arg1, type arg2,
type arg3, type arg4)
{
..
}
May be helpful, but all of this is very personal-taste-ish...
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
On 01/19/2016 02:40 PM, Ronald S. Bultje wrote: We tend to indent the second line so it aligns with the opening bracket of the first line. Excuse me if i chime in here, Ronald, yes, I've noticed that as well. However, sometimes it can be quite awkward to do this alignment when having a lot of stuff before the opening bracket, and lots of parameters. Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
Hi, On Tue, Jan 19, 2016 at 7:46 AM, John Cox wrote: > Hi > > I've just done a fair bit of work on hevc_cabac decode for the Rasberry > Pi2 and I think that the patch is generally applicable. Patch is > attached but you may prefer to take it from git: Cool! Two non-technical comments first, I'll try to make time to review in-depth/technically soon: 1: > +#define UNCHECKED_BITSTREAM_READER 1 I don't think that's right, and is a security issue. 2: your indentation of function declarations is weird. E.g.: +static inline uint32_t get_greaterx_bits(HEVCContext * const s, const unsigned int n_end, int * const levels, +int * const pprev_subset_coded, int * const psum, +const unsigned int idx0_gt1, const unsigned int idx_gt2) We tend to indent the second line so it aligns with the opening bracket of the first line. Alike, your indentation of const variable declarations: +uint8_t * const state0 = s->HEVClc->cabac_state + idx0_gt1; doesn't need a space between * and const. Like I said, all non-technical, I'll do technical bits soon if I find time. If other people like it and I haven't responded yet, just commit it and we can address them post-push. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/5] libavutil: some VAAPI infrastructure
On 19/01/16 11:54, wm4 wrote:
> On Mon, 18 Jan 2016 22:49:51 +
> Mark Thompson wrote:
>
>> ---
>> configure | 4 +
>> libavutil/Makefile | 1 +
>> libavutil/vaapi.c | 497
>> +
>> libavutil/vaapi.h | 123 +
>> 4 files changed, 625 insertions(+)
>> create mode 100644 libavutil/vaapi.c
>> create mode 100644 libavutil/vaapi.h
>>
>
> Trying to do a more thorough review.
Thanks :)
>> diff --git a/configure b/configure
>> index 7cef6f5..1c77015 100755
>> --- a/configure
>> +++ b/configure
>> @@ -5739,6 +5739,10 @@ enabled vaapi && enabled xlib &&
>> check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
>> enable vaapi_x11
>>
>> +enabled vaapi &&
>> +check_lib2 "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm &&
>> +enable vaapi_drm
>> +
>> enabled vdpau &&
>> check_cpp_condition vdpau/vdpau.h "defined
>> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
>> disable vdpau
>> diff --git a/libavutil/Makefile b/libavutil/Makefile
>> index bf8c713..8025f9f 100644
>> --- a/libavutil/Makefile
>> +++ b/libavutil/Makefile
>> @@ -146,6 +146,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o
>>\
>>
>> OBJS-$(CONFIG_LZO) += lzo.o
>> OBJS-$(CONFIG_OPENCL) += opencl.o opencl_internal.o
>> +OBJS-$(CONFIG_VAAPI)+= vaapi.o
>>
>> OBJS += $(COMPAT_OBJS:%=../compat/%)
>>
>> diff --git a/libavutil/vaapi.c b/libavutil/vaapi.c
>> new file mode 100644
>> index 000..8a9a524
>> --- /dev/null
>> +++ b/libavutil/vaapi.c
>> @@ -0,0 +1,497 @@
>> +/*
>> + * VAAPI helper functions.
>> + *
>> + * Copyright (C) 2016 Mark Thompson
>> + *
>> + * 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 "vaapi.h"
>> +
>> +#include "avassert.h"
>> +#include "imgutils.h"
>> +#include "pixfmt.h"
>> +
>> +
>> +void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx)
>> +{
>> +if(ctx->lock)
>> +ctx->lock();
>> +}
>> +
>> +void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx)
>> +{
>> +if(ctx->unlock)
>> +ctx->unlock();
>> +}
>
> The lock callbacks should take some sort of opaque context pointer.
Ok; will add.
>> +
>> +static const AVClass vaapi_pipeline_class = {
>> +.class_name = "VAAPI/pipeline",
>> +.item_name = av_default_item_name,
>> +.version= LIBAVUTIL_VERSION_INT,
>> +};
>> +
>> +static int vaapi_create_surfaces(AVVAAPIPipelineContext *ctx,
>> + AVVAAPISurfaceConfig *config,
>> + AVVAAPISurface *surfaces,
>> + VASurfaceID *ids)
>> +{
>> +VAStatus vas;
>> +int i;
>> +
>> +vas = vaCreateSurfaces(ctx->hardware_context->display,
>> config->rt_format,
>> + config->width, config->height, ids,
>> config->count,
>> + config->attributes, config->attribute_count);
>> +if(vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_ERROR, "Failed to create "
>> + "surfaces: %d (%s).\n", vas, vaErrorStr(vas));
>> +return AVERROR(EINVAL);
>> +}
>> +
>> +for(i = 0; i < config->count; i++) {
>> +surfaces[i].id = ids[i];
>> +surfaces[i].refcount = 0;
>> +surfaces[i].hardware_context = ctx->hardware_context;
>> +surfaces[i].config = config;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static void vaapi_destroy_surfaces(AVVAAPIPipelineContext *ctx,
>> + AVVAAPISurfaceConfig *config,
>> + AVVAAPISurface *surfaces,
>> + VASurfaceID *ids)
>> +{
>> +VAStatus vas;
>> +int i;
>> +
>> +for(i = 0; i < config->count; i++) {
>> +av_assert0(surfaces[i].id == ids[i]);
>> +if(surfaces[i].refcount > 0)
>> +av_log(ctx, AV_LOG_WARNING, "Destroying surface %#x which is "
>> + "still in use.\n", surfaces[i].id);
>> +av_assert0(surfaces[i].hardware_context == ctx->hardware_context);
>> +av_assert0(surfaces[i].config == config);
>> +
Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw AVI video
On 01/19/2016 01:51 PM, Mats Peterson wrote: This one will probably cause Michael to oppose, but I think it should be implemented as well. As long as we don't have a "pal1" pixel format, we'll have to use the somewhat redundant pal8. Below are two sample AVI files, one without a palette, and one with a blue palette. No palette (black & white): https://drive.google.com/open?id=0B3_pEBoLs0faelN5RXpKLWtfTnM Blue palette: https://drive.google.com/open?id=0B3_pEBoLs0fabnhDeGk0Zl9tSVk Mats raw_init() should be raw_init_decoder(). Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw AVI video
This one will probably cause Michael to oppose, but I think it should be
implemented as well. As long as we don't have a "pal1" pixel format,
we'll have to use the somewhat redundant pal8. Below are two sample AVI
files, one without a palette, and one with a blue palette.
No palette (black & white):
https://drive.google.com/open?id=0B3_pEBoLs0faelN5RXpKLWtfTnM
Blue palette:
https://drive.google.com/open?id=0B3_pEBoLs0fabnhDeGk0Zl9tSVk
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 037660e248df46f8e69c3255976e099ee61c72c3 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Tue, 19 Jan 2016 13:39:45 +0100
Subject: [PATCH] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw AVI video
The stuff about 1-bit video not necessarily being black & white in
QuickTime goes for AVI as well. Being 1 bit per pixel only means that
the data is bi-level. The two colors can be any color. Since many
1 bpp AVI files don't have a palette following the BITMAPINFOHEADER,
I'm setting a "default" black & white palette in raw_init().
Mats
---
libavcodec/raw.c|2 +-
libavcodec/rawdec.c | 12 +---
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 3f2cc11..3979c5c 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -242,7 +242,7 @@ unsigned int avcodec_pix_fmt_to_codec_tag(enum AVPixelFormat fmt)
}
const PixelFormatTag avpriv_pix_fmt_bps_avi[] = {
-{ AV_PIX_FMT_MONOWHITE, 1 },
+{ AV_PIX_FMT_PAL8,1 },
{ AV_PIX_FMT_PAL8,2 },
{ AV_PIX_FMT_PAL8,4 },
{ AV_PIX_FMT_PAL8,8 },
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index cb0364c..f913cad 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -41,7 +41,7 @@ typedef struct RawVideoContext {
AVBufferRef *palette;
int frame_size; /* size of the frame in bytes */
int flip;
-int is_1_2_4_bpp; // 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
+int is_1_2_4_bpp; // 1, 2 and 4 bpp raw in avi/mov
int is_yuv2;
int is_lt_16bpp; // 16bpp pixfmt and bits_per_coded_sample < 16
int tff;
@@ -94,8 +94,14 @@ static av_cold int raw_init_decoder(AVCodecContext *avctx)
return AVERROR(ENOMEM);
if (desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)
avpriv_set_systematic_pal2((uint32_t*)context->palette->data, avctx->pix_fmt);
-else
+else {
memset(context->palette->data, 0, AVPALETTE_SIZE);
+if (avctx->bits_per_coded_sample == 1) {
+uint32_t *rgb = (uint32_t *)context->palette->data;
+rgb[0] = 0xff;
+rgb[1] = 0x00;
+}
+}
}
if ((avctx->extradata_size >= 9 &&
@@ -202,7 +208,7 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
if (!frame->buf[0])
return AVERROR(ENOMEM);
-// 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
+// 1, 2 and 4 bpp raw in avi/mov
if (context->is_1_2_4_bpp) {
int i;
uint8_t *dst = frame->buf[0]->data;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]levc/hevc_cabac Optimise ff_hevc_hls_residual_coding (especially ARM)
Hi I've just done a fair bit of work on hevc_cabac decode for the Rasberry Pi2 and I think that the patch is generally applicable. Patch is attached but you may prefer to take it from git: https://github.com/jc-kynesim/rpi-ffmpeg.git branch: test/ff_hevc_cabac_3 commit: 423e160e639d301feb2b4ba220199d112def0164 On the Pi2 playing a 10Mbit 1080p H.265 clip (A bit of the Hobbit) it reduces the time in ff_hevc_hls_residual_coding (until transform) from ~26Gcycles to ~18Gcycles and it almost halves the time spent in the "core" bit of the function (from decoding the greater1 bits to the end of decode). This was measured using the CPU cycle counter. Tests done at Rasberry Pi suggests that on their ffmpeg branch it reduces overall CPU loading by ~10% whislt playing H.265. I haven't profiled it on any other platform - but I would expect useful improvements on most streams on most platforms. I have not yet run fate over it as I haven't yet finished downloading the samples (the internet connection here isn't wildly fast), but I have run it against the H265.1 conformance streams on both x86 and ARM and it causes no regressions. Known unknowns / possible issues: 1) I haven't tested it on anything with 64-bit ints (I don't have an appropriate m/c) - whilst I've coded in a manner that should hopefully be OK there I can see that there might be issues. 2) Only tested on gcc 4.8 and later (5.1 & 5.3). I've used an anonymous union to avoid changing other cabac code - I could believe this was a no-no and I'll have to change that. 3) Uses clz which doesn't seem to exist in the ffmpeg int libs (though ctz does) I'll happily accept suggestions as to what is considered better practice for these points. Regards John Cox 0001-H.265-residual-decode-performance-improvements.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil: add mastering display metadata sidedata
On Tue, 19 Jan 2016 13:02:25 +0100
Michael Niedermayer wrote:
> On Tue, Jan 19, 2016 at 10:18:16AM +0100, wm4 wrote:
> > On Tue, 19 Jan 2016 00:32:43 +0100
> > Michael Niedermayer wrote:
> >
> > > On Sat, Jan 16, 2016 at 04:19:38PM -0800, Neil Birkbeck wrote:
> > > > Adding mastering display metadata struct to avutil. The mastering
> > > > display metadata contains information
> > > > about the mastering display color volume (SMPTE 2086:2014).
> > > >
> > > > This info comes from HEVC in the SEI_TYPE_MASTERING_DISPLAY_INFO and is
> > > > soon to be included in MKV:
> > > > https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o
> > > > so it is similar to SEI FPA / stereo_mode in MKV and as such this patch
> > > > follows how AVStereo3D is implemented.
> > > >
> > > > I'll add support to HEVC in a follow-up (and MKV when spec is approved).
> > > >
> > > > Signed-off-by: Neil Birkbeck
> > > > ---
> > > > libavutil/Makefile | 2 +
> > > > libavutil/frame.h | 7 ++-
> > > > libavutil/mastering_display_metadata.c | 43 +
> > > > libavutil/mastering_display_metadata.h | 87
> > > > ++
> > > > libavutil/version.h| 2 +-
> > > > 5 files changed, 139 insertions(+), 2 deletions(-)
> > > > create mode 100644 libavutil/mastering_display_metadata.c
> > > > create mode 100644 libavutil/mastering_display_metadata.h
> > > >
> > > > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > > > index bf8c713..65b2d25 100644
> > > > --- a/libavutil/Makefile
> > > > +++ b/libavutil/Makefile
> > > > @@ -38,6 +38,7 @@ HEADERS = adler32.h
> > > > \
> > > >log.h
> > > > \
> > > >macros.h
> > > > \
> > > >mathematics.h
> > > > \
> > > > + mastering_display_metadata.h
> > > > \
> > > >md5.h
> > > > \
> > > >mem.h
> > > > \
> > > >motion_vector.h
> > > > \
> > > > @@ -115,6 +116,7 @@ OBJS = adler32.o
> > > > \
> > > > log.o
> > > > \
> > > > log2_tab.o
> > > > \
> > > > mathematics.o
> > > > \
> > > > + mastering_display_metadata.o
> > > > \
> > > > md5.o
> > > > \
> > > > mem.o
> > > > \
> > > > murmur3.o
> > > > \
> > > > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > > > index 9c6061a..308355b 100644
> > > > --- a/libavutil/frame.h
> > > > +++ b/libavutil/frame.h
> > > > @@ -106,12 +106,17 @@ enum AVFrameSideDataType {
> > > > * @endcode
> > > > */
> > > > AV_FRAME_DATA_SKIP_SAMPLES,
> > > > -
> > > > /**
> > > > * This side data must be associated with an audio frame and
> > > > corresponds to
> > > > * enum AVAudioServiceType defined in avcodec.h.
> > > > */
> > > > AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
> > >
> > > > +/**
> > > > + * Mastering display metadata associated with a video frame. The
> > > > payload is
> > > > + * an AVMasteringDisplayMetadata type and contains information
> > > > about the
> > > > + * mastering display color volume.
> > > > + */
> > > > +AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
> > >
> > > will this always stay the same or could it require to be extended in
> > > the future ?
> > > if future extensions may occur then it should be documented how that
> > > would work. Would fields be added to the end of the struct ?
> > > If so how would this be detected ?
> > >
> > > C does not gurantee the sizeof to change for the addition of fields
> > > for example these 2 are both 8bytes on x86-64
> > > typedef struct X { int a; char b; }X;
> > > typedef struct Y { int a; char b; char c; }Y;
> > >
> > > defining the meaning of the sidedata byte per byte avoids the problem
> > > of detectability it also makes the function endian and ABI independant
> > > and would allow passing it bytewise between computers, no idea how
> > > much thats a real world use case though
> > >
> > > [...]
> >
> > I thought we decided side data can be memcpy'd struct? (I.e. can be
> > ABI-dependent.)
>
> i
Re: [FFmpeg-devel] [PATCH v3 5/5] libavfilter: VAAPI surface converter
On Mon, 18 Jan 2016 22:53:33 +
Mark Thompson wrote:
> ---
> configure | 1 +
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/vf_vaapi_conv.c | 480
>
> 4 files changed, 483 insertions(+)
> create mode 100644 libavfilter/vf_vaapi_conv.c
>
> diff --git a/configure b/configure
> index 9da8e8b..71c0bc0 100755
> --- a/configure
> +++ b/configure
> @@ -2913,6 +2913,7 @@ stereo3d_filter_deps="gpl"
> subtitles_filter_deps="avformat avcodec libass"
> super2xsai_filter_deps="gpl"
> tinterlace_filter_deps="gpl"
> +vaapi_conv_filter_deps="vaapi"
> vidstabdetect_filter_deps="libvidstab"
> vidstabtransform_filter_deps="libvidstab"
> pixfmts_super2xsai_test_deps="super2xsai_filter"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e3e3561..9a4ca12 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -246,6 +246,7 @@ OBJS-$(CONFIG_TRANSPOSE_FILTER) +=
> vf_transpose.o
> OBJS-$(CONFIG_TRIM_FILTER) += trim.o
> OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
> OBJS-$(CONFIG_USPP_FILTER) += vf_uspp.o
> +OBJS-$(CONFIG_VAAPI) += vf_vaapi_conv.o
> OBJS-$(CONFIG_VECTORSCOPE_FILTER)+= vf_vectorscope.o
> OBJS-$(CONFIG_VFLIP_FILTER) += vf_vflip.o
> OBJS-$(CONFIG_VIDSTABDETECT_FILTER) += vidstabutils.o
> vf_vidstabdetect.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 1faf393..cfbfdca 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -266,6 +266,7 @@ void avfilter_register_all(void)
> REGISTER_FILTER(TRIM, trim, vf);
> REGISTER_FILTER(UNSHARP,unsharp,vf);
> REGISTER_FILTER(USPP, uspp, vf);
> +REGISTER_FILTER(VAAPI_CONV, vaapi_conv, vf);
> REGISTER_FILTER(VECTORSCOPE,vectorscope,vf);
> REGISTER_FILTER(VFLIP, vflip, vf);
> REGISTER_FILTER(VIDSTABDETECT, vidstabdetect, vf);
> diff --git a/libavfilter/vf_vaapi_conv.c b/libavfilter/vf_vaapi_conv.c
> new file mode 100644
> index 000..5180e7c
> --- /dev/null
> +++ b/libavfilter/vf_vaapi_conv.c
> @@ -0,0 +1,480 @@
> +/*
> + * VAAPI converter (scaling and colour conversion).
> + *
> + * Copyright (C) 2016 Mark Thompson
> + *
> + * 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 "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixdesc.h"
> +#include "libavutil/vaapi.h"
> +
> +#include
> +
> +typedef struct VAAPIConvContext {
> +const AVClass *class;
> +
> +AVVAAPIHardwareContext *hardware_context;
> +AVVAAPIPipelineConfig va_config;
> +AVVAAPIPipelineContext va_context;
> +int pipeline_initialised;
> +
> +int input_is_vaapi;
> +AVVAAPISurfaceConfig input_config;
> +AVVAAPISurfaceConfig output_config;
> +
> +int output_width;
> +int output_height;
> +
> +struct {
> +int64_t hardware_context;
> +int output_size[2];
> +} options;
> +
> +} VAAPIConvContext;
> +
> +
> +static int vaapi_conv_query_formats(AVFilterContext *avctx)
> +{
> +VAAPIConvContext *ctx = avctx->priv;
> +VAStatus vas;
> +VAConfigAttrib rt_format = {
> +.type = VAConfigAttribRTFormat
> +};
> +enum AVPixelFormat pix_fmt_list[16] = {
> +AV_PIX_FMT_VAAPI,
> +};
> +int pix_fmt_count = 1, err;
> +
> +#if 0
> +// The Intel driver doesn't return anything useful here - it only
> +// declares support for YUV 4:2:0 formats, despite working perfectly
> +// with 32-bit RGB ones. Given another usable platform, this will
> +// need to be updated.
> +vas = vaGetConfigAttributes(ctx->hardware_context->display,
> +VAProfileNone, VAEntrypointVideoProc,
> +&rt_format, 1);
> +#else
> +vas = VA_STATUS_SUCCESS;
> +rt_format.value = VA_RT_FORMAT_YUV420 | VA_RT_FORMAT_RGB32;
> +#endif
> +if(vas != VA_STATUS_SUCCESS) {
>
Re: [FFmpeg-devel] [PATCH v3 2/5] ffmpeg: initialisation code for VAAPI, hwaccel helper
On Mon, 18 Jan 2016 22:50:50 +
Mark Thompson wrote:
> ---
> Makefile | 1 +
> ffmpeg.c | 5 +
> ffmpeg.h | 5 +
> ffmpeg_opt.c | 14 ++
> ffmpeg_vaapi.c | 622
> +
> 5 files changed, 647 insertions(+)
> create mode 100644 ffmpeg_vaapi.c
>
> diff --git a/Makefile b/Makefile
> index 7836a20..be1d2ca 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -36,6 +36,7 @@ OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
> endif
> OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
> OBJS-ffmpeg-$(CONFIG_LIBMFX) += ffmpeg_qsv.o
> +OBJS-ffmpeg-$(CONFIG_VAAPI) += ffmpeg_vaapi.o
> OBJS-ffserver += ffserver_config.o
>
> TESTTOOLS = audiogen videogen rotozoom tiny_psnr tiny_ssim base64
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 1f4277c..e76879a 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2603,6 +2603,11 @@ static int init_output_stream(OutputStream *ost, char
> *error, int error_len)
> !av_dict_get(ost->encoder_opts, "ab", NULL, 0))
> av_dict_set(&ost->encoder_opts, "b", "128000", 0);
>
> +#if CONFIG_VAAPI
> +if(ost->enc->type == AVMEDIA_TYPE_VIDEO)
> +vaapi_hardware_set_options(&ost->encoder_opts);
> +#endif
> +
> if ((ret = avcodec_open2(ost->enc_ctx, codec, &ost->encoder_opts)) <
> 0) {
> if (ret == AVERROR_EXPERIMENTAL)
> abort_codec_experimental(codec, 1);
> diff --git a/ffmpeg.h b/ffmpeg.h
> index 20322b0..2134213 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -65,6 +65,7 @@ enum HWAccelID {
> HWACCEL_VDA,
> HWACCEL_VIDEOTOOLBOX,
> HWACCEL_QSV,
> +HWACCEL_VAAPI,
> };
>
> typedef struct HWAccel {
> @@ -577,5 +578,9 @@ int vda_init(AVCodecContext *s);
> int videotoolbox_init(AVCodecContext *s);
> int qsv_init(AVCodecContext *s);
> int qsv_transcode_init(OutputStream *ost);
> +int vaapi_decode_init(AVCodecContext *s);
> +
> +int vaapi_hardware_init(const char *device);
> +int vaapi_hardware_set_options(AVDictionary **dict);
>
> #endif /* FFMPEG_H */
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 9b341cf..47ac467 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -82,6 +82,9 @@ const HWAccel hwaccels[] = {
> #if CONFIG_LIBMFX
> { "qsv", qsv_init, HWACCEL_QSV, AV_PIX_FMT_QSV },
> #endif
> +#if CONFIG_VAAPI
> +{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI },
> +#endif
> { 0 },
> };
>
> @@ -442,6 +445,13 @@ static int opt_sdp_file(void *optctx, const char *opt,
> const char *arg)
> return 0;
> }
>
> +static int opt_vaapi(void *optctx, const char *opt, const char *arg)
> +{
> +if(vaapi_hardware_init(arg))
> +exit_program(1);
> +return 0;
> +}
> +
> /**
> * Parse a metadata specifier passed as 'arg' parameter.
> * @param arg metadata string to parse
> @@ -3438,5 +3448,9 @@ const OptionDef options[] = {
> { "dn", OPT_BOOL | OPT_VIDEO | OPT_OFFSET | OPT_INPUT | OPT_OUTPUT, {
> .off = OFFSET(data_disable) },
> "disable data" },
>
> +#if CONFIG_VAAPI
> +{ "vaapi", HAS_ARG, { .func_arg = opt_vaapi }, "set VAAPI hardware
> context" },
> +#endif
> +
> { NULL, },
> };
> diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
> new file mode 100644
> index 000..e04532c
> --- /dev/null
> +++ b/ffmpeg_vaapi.c
> @@ -0,0 +1,622 @@
> +/*
> + * VAAPI helper for hardware-accelerated decoding.
> + *
> + * Copyright (C) 2016 Mark Thompson
> + *
> + * 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
> +
> +#include "ffmpeg.h"
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/avconfig.h"
> +#include "libavutil/buffer.h"
> +#include "libavutil/frame.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/opt.h"
> +#include "libavutil/pixfmt.h"
> +#include "libavutil/thread.h"
> +#include "libavutil/vaapi.h"
> +
> +#include "libavcodec/vaapi.h"
> +
> +#include
> +#include
> +
> +
> +static AVClass vaapi_class = {
> +.class_name = "VAAPI/driver",
> +.item_name = av_default_item_name,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +
> +#define DEFAULT_SURFACES 20
> +
> +typedef struct VAAPID
Re: [FFmpeg-devel] [PATCH] libavutil: add mastering display metadata sidedata
On Tue, Jan 19, 2016 at 10:18:16AM +0100, wm4 wrote:
> On Tue, 19 Jan 2016 00:32:43 +0100
> Michael Niedermayer wrote:
>
> > On Sat, Jan 16, 2016 at 04:19:38PM -0800, Neil Birkbeck wrote:
> > > Adding mastering display metadata struct to avutil. The mastering display
> > > metadata contains information
> > > about the mastering display color volume (SMPTE 2086:2014).
> > >
> > > This info comes from HEVC in the SEI_TYPE_MASTERING_DISPLAY_INFO and is
> > > soon to be included in MKV:
> > > https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o
> > > so it is similar to SEI FPA / stereo_mode in MKV and as such this patch
> > > follows how AVStereo3D is implemented.
> > >
> > > I'll add support to HEVC in a follow-up (and MKV when spec is approved).
> > >
> > > Signed-off-by: Neil Birkbeck
> > > ---
> > > libavutil/Makefile | 2 +
> > > libavutil/frame.h | 7 ++-
> > > libavutil/mastering_display_metadata.c | 43 +
> > > libavutil/mastering_display_metadata.h | 87
> > > ++
> > > libavutil/version.h| 2 +-
> > > 5 files changed, 139 insertions(+), 2 deletions(-)
> > > create mode 100644 libavutil/mastering_display_metadata.c
> > > create mode 100644 libavutil/mastering_display_metadata.h
> > >
> > > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > > index bf8c713..65b2d25 100644
> > > --- a/libavutil/Makefile
> > > +++ b/libavutil/Makefile
> > > @@ -38,6 +38,7 @@ HEADERS = adler32.h
> > > \
> > >log.h \
> > >macros.h \
> > >mathematics.h \
> > > + mastering_display_metadata.h \
> > >md5.h \
> > >mem.h \
> > >motion_vector.h \
> > > @@ -115,6 +116,7 @@ OBJS = adler32.o
> > > \
> > > log.o\
> > > log2_tab.o \
> > > mathematics.o\
> > > + mastering_display_metadata.o \
> > > md5.o\
> > > mem.o\
> > > murmur3.o\
> > > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > > index 9c6061a..308355b 100644
> > > --- a/libavutil/frame.h
> > > +++ b/libavutil/frame.h
> > > @@ -106,12 +106,17 @@ enum AVFrameSideDataType {
> > > * @endcode
> > > */
> > > AV_FRAME_DATA_SKIP_SAMPLES,
> > > -
> > > /**
> > > * This side data must be associated with an audio frame and
> > > corresponds to
> > > * enum AVAudioServiceType defined in avcodec.h.
> > > */
> > > AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
> >
> > > +/**
> > > + * Mastering display metadata associated with a video frame. The
> > > payload is
> > > + * an AVMasteringDisplayMetadata type and contains information about
> > > the
> > > + * mastering display color volume.
> > > + */
> > > +AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
> >
> > will this always stay the same or could it require to be extended in
> > the future ?
> > if future extensions may occur then it should be documented how that
> > would work. Would fields be added to the end of the struct ?
> > If so how would this be detected ?
> >
> > C does not gurantee the sizeof to change for the addition of fields
> > for example these 2 are both 8bytes on x86-64
> > typedef struct X { int a; char b; }X;
> > typedef struct Y { int a; char b; char c; }Y;
> >
> > defining the meaning of the sidedata byte per byte avoids the problem
> > of detectability it also makes the function endian and ABI independant
> > and would allow passing it bytewise between computers, no idea how
> > much thats a real world use case though
> >
> > [...]
>
> I thought we decided side data can be memcpy'd struct? (I.e. can be
> ABI-dependent.)
i dont remember
but more importantly, how would such struct be extended, if we
want to add a field ?
searching for AV_FRAME_DATA* finds hits in libavcodec, libavdevice,
libavfilter, ffprobe as well as doc/examples
adding a field is not guranteed to change the sizeof() of the struct
so using the sidedatas size to detect the version would be undefined
behavior also the exact size could with structs d
Re: [FFmpeg-devel] [PATCH v3 1/5] libavutil: some VAAPI infrastructure
On Mon, 18 Jan 2016 22:49:51 +
Mark Thompson wrote:
> ---
> configure | 4 +
> libavutil/Makefile | 1 +
> libavutil/vaapi.c | 497
> +
> libavutil/vaapi.h | 123 +
> 4 files changed, 625 insertions(+)
> create mode 100644 libavutil/vaapi.c
> create mode 100644 libavutil/vaapi.h
>
Trying to do a more thorough review.
> diff --git a/configure b/configure
> index 7cef6f5..1c77015 100755
> --- a/configure
> +++ b/configure
> @@ -5739,6 +5739,10 @@ enabled vaapi && enabled xlib &&
> check_lib2 "va/va.h va/va_x11.h" vaGetDisplay -lva -lva-x11 &&
> enable vaapi_x11
>
> +enabled vaapi &&
> +check_lib2 "va/va.h va/va_drm.h" vaGetDisplayDRM -lva -lva-drm &&
> +enable vaapi_drm
> +
> enabled vdpau &&
> check_cpp_condition vdpau/vdpau.h "defined
> VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
> disable vdpau
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index bf8c713..8025f9f 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -146,6 +146,7 @@ OBJS-$(!HAVE_ATOMICS_NATIVE)+= atomic.o
> \
>
> OBJS-$(CONFIG_LZO) += lzo.o
> OBJS-$(CONFIG_OPENCL) += opencl.o opencl_internal.o
> +OBJS-$(CONFIG_VAAPI)+= vaapi.o
>
> OBJS += $(COMPAT_OBJS:%=../compat/%)
>
> diff --git a/libavutil/vaapi.c b/libavutil/vaapi.c
> new file mode 100644
> index 000..8a9a524
> --- /dev/null
> +++ b/libavutil/vaapi.c
> @@ -0,0 +1,497 @@
> +/*
> + * VAAPI helper functions.
> + *
> + * Copyright (C) 2016 Mark Thompson
> + *
> + * 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 "vaapi.h"
> +
> +#include "avassert.h"
> +#include "imgutils.h"
> +#include "pixfmt.h"
> +
> +
> +void av_vaapi_lock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->lock)
> +ctx->lock();
> +}
> +
> +void av_vaapi_unlock_hardware_context(AVVAAPIHardwareContext *ctx)
> +{
> +if(ctx->unlock)
> +ctx->unlock();
> +}
The lock callbacks should take some sort of opaque context pointer.
> +
> +static const AVClass vaapi_pipeline_class = {
> +.class_name = "VAAPI/pipeline",
> +.item_name = av_default_item_name,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +static int vaapi_create_surfaces(AVVAAPIPipelineContext *ctx,
> + AVVAAPISurfaceConfig *config,
> + AVVAAPISurface *surfaces,
> + VASurfaceID *ids)
> +{
> +VAStatus vas;
> +int i;
> +
> +vas = vaCreateSurfaces(ctx->hardware_context->display, config->rt_format,
> + config->width, config->height, ids, config->count,
> + config->attributes, config->attribute_count);
> +if(vas != VA_STATUS_SUCCESS) {
> +av_log(ctx, AV_LOG_ERROR, "Failed to create "
> + "surfaces: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR(EINVAL);
> +}
> +
> +for(i = 0; i < config->count; i++) {
> +surfaces[i].id = ids[i];
> +surfaces[i].refcount = 0;
> +surfaces[i].hardware_context = ctx->hardware_context;
> +surfaces[i].config = config;
> +}
> +
> +return 0;
> +}
> +
> +static void vaapi_destroy_surfaces(AVVAAPIPipelineContext *ctx,
> + AVVAAPISurfaceConfig *config,
> + AVVAAPISurface *surfaces,
> + VASurfaceID *ids)
> +{
> +VAStatus vas;
> +int i;
> +
> +for(i = 0; i < config->count; i++) {
> +av_assert0(surfaces[i].id == ids[i]);
> +if(surfaces[i].refcount > 0)
> +av_log(ctx, AV_LOG_WARNING, "Destroying surface %#x which is "
> + "still in use.\n", surfaces[i].id);
> +av_assert0(surfaces[i].hardware_context == ctx->hardware_context);
> +av_assert0(surfaces[i].config == config);
> +}
> +
> +vas = vaDestroySurfaces(ctx->hardware_context->display,
> +ids, config->count);
> +if(vas != VA_STATUS_SUCCESS) {
> +av_log(ctx, AV_LOG_ERROR, "Failed t
Re: [FFmpeg-devel] [PATCH] libkvazaar: Set frame rate as a rational number
On 2016-01-18 15:46, Nicolas George wrote: EOVERFLOW does not exist on some windows versions. IIRC, we usually use EINVAL in this kind of case. Thanks. I'll change that to EINVAL and apply the patch tomorrow if there are no other issues. - Arttu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/h264: Show "Increasing reorder buffer" message with loglevel info
On Tue, Jan 19, 2016 at 11:01:40AM +0100, Carl Eugen Hoyos wrote: > Hi! > > The message "Increasing reorder buffer" when decoding h264 seems quite > important to me, it should be shown by default imo (or as a warning). > See also ticket #5138. > > Please comment, Carl Eugen > h264.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > 2f503760410f5391baa404c5ee8eeb0e8a9d6ae1 patchh264reorder.diff LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/qtpalette: Fix incorrect palettes
On 01/19/2016 11:19 AM, Michael Niedermayer wrote: applied thanks Thank you. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/qtpalette: Fix incorrect palettes
On Tue, Jan 19, 2016 at 03:40:14AM +0100, Mats Peterson wrote: > Minor changes. > > Mats > qtpalette.h | 34 ++ > 1 file changed, 18 insertions(+), 16 deletions(-) > 10d99683bb90fc71b959edc02f375222d0e12e48 > 0001-lavf-qtpalette-Fix-incorrect-palettes.patch > From 02aba0be72a6d84873a9eabf1669e921f771c738 Mon Sep 17 00:00:00 2001 > From: Mats Peterson > Date: Tue, 19 Jan 2016 03:38:15 +0100 > Subject: [PATCH v2] lavf/qtpalette: Fix incorrect palettes > > This patch corrects the colors of the 2 and 4 bpp palettes. applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only set SAR if resolution is available
On Tue, Jan 19, 2016 at 09:16:26AM +0100, Carl Eugen Hoyos wrote: > On Tuesday 19 January 2016 02:09:06 am Michael Niedermayer wrote: > > On Tue, Jan 19, 2016 at 12:33:40AM +0100, Carl Eugen Hoyos wrote: > > > Hi! > > > > > > Attached patch fixes ticket #4479 here. > > > > > > Please comment, Carl Eugen > > > > if w/h is set at that point then their values may be unrelated to the > > actual w/h values thus the set_sar there is wrong even if w/h is set > > > > the patch is fine, iam not sure if the call shouldnt be (re)moved > > though moving it might be somewhat non trivial > > The attached patch also fixes ticket #4479 for me. > > Thank you, Carl Eugen also ok, maybe add a <= 0 check for the 2 parameters [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] lavf/qtpalette: Fix incorrect palettes
On 01/19/2016 03:40 AM, Mats Peterson wrote: Minor changes. Sample 1-frame clip with all 16 colors in the default 4 bpp palette. The display in QuickTime in Windows/Mac and FFmpeg should be identical after the patch has been applied. https://drive.google.com/open?id=0B3_pEBoLs0fad2VyRE5PdnYxcDg Mats ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] checkasm: add fixed_dsp tests
On Tue, Jan 19, 2016 at 02:01:58AM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > tests/checkasm/Makefile| 3 + > tests/checkasm/checkasm.c | 3 + > tests/checkasm/checkasm.h | 1 + > tests/checkasm/fixed_dsp.c | 169 > + > 4 files changed, 176 insertions(+) > create mode 100644 tests/checkasm/fixed_dsp.c fails to build make distclean ; ./configure && make -j12 fate-checkasm tests/checkasm/fixed_dsp.c: In function ‘check_vector_fmul’: tests/checkasm/fixed_dsp.c:53:5: error: format not a string literal and no format arguments [-Werror=format-security] cc1: some warnings being treated as errors make: *** [tests/checkasm/fixed_dsp.o] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]ape: Show more information for loglevel verbose
Paul B Mahol gmail.com> writes: > > Please comment, Carl Eugen > > > > ok Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavc/h264: Show "Increasing reorder buffer" message with loglevel info
Hi!
The message "Increasing reorder buffer" when decoding h264 seems quite
important to me, it should be shown by default imo (or as a warning).
See also ticket #5138.
Please comment, Carl Eugen
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 545ac14..2361660 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -933,7 +933,7 @@ static void decode_postinit(H264Context *h, int
setup_finished)
h->last_pocs[0] = cur->poc;
cur->mmco_reset = 1;
} else if(h->avctx->has_b_frames < out_of_order &&
!h->sps.bitstream_restriction_flag){
-av_log(h->avctx, AV_LOG_VERBOSE, "Increasing reorder buffer to %d\n",
out_of_order);
+av_log(h->avctx, AV_LOG_INFO, "Increasing reorder buffer to %d\n",
out_of_order);
h->avctx->has_b_frames = out_of_order;
h->low_delay = 0;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]ape: Show more information for loglevel verbose
On 1/19/16, Carl Eugen Hoyos wrote: > Hi! > > As requested by user Andy E. > > Please comment, Carl Eugen > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]ape: Show more information for loglevel verbose
Hi! As requested by user Andy E. Please comment, Carl Eugen diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c index a528e60..bed9a96 100644 --- a/libavcodec/apedec.c +++ b/libavcodec/apedec.c @@ -247,7 +247,7 @@ static av_cold int ape_decode_init(AVCodecContext *avctx) s->compression_level = AV_RL16(avctx->extradata + 2); s->flags = AV_RL16(avctx->extradata + 4); -av_log(avctx, AV_LOG_DEBUG, "Compression Level: %d - Flags: %d\n", +av_log(avctx, AV_LOG_VERBOSE, "Compression Level: %d - Flags: %d\n", s->compression_level, s->flags); if (s->compression_level % 1000 || s->compression_level > COMPRESSION_LEVEL_INSANE || !s->compression_level || diff --git a/libavformat/ape.c b/libavformat/ape.c index 352ddc6..3e81972 100644 --- a/libavformat/ape.c +++ b/libavformat/ape.c @@ -337,7 +337,7 @@ static int ape_read_header(AVFormatContext * s) ape_dumpinfo(s, ape); -av_log(s, AV_LOG_DEBUG, "Decoding file - v%d.%02d, compression level %"PRIu16"\n", +av_log(s, AV_LOG_VERBOSE, "Decoding file - v%d.%02d, compression level %"PRIu16"\n", ape->fileversion / 1000, (ape->fileversion % 1000) / 10, ape->compressiontype); ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavutil: add mastering display metadata sidedata
On Tue, 19 Jan 2016 00:32:43 +0100
Michael Niedermayer wrote:
> On Sat, Jan 16, 2016 at 04:19:38PM -0800, Neil Birkbeck wrote:
> > Adding mastering display metadata struct to avutil. The mastering display
> > metadata contains information
> > about the mastering display color volume (SMPTE 2086:2014).
> >
> > This info comes from HEVC in the SEI_TYPE_MASTERING_DISPLAY_INFO and is
> > soon to be included in MKV:
> > https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o
> > so it is similar to SEI FPA / stereo_mode in MKV and as such this patch
> > follows how AVStereo3D is implemented.
> >
> > I'll add support to HEVC in a follow-up (and MKV when spec is approved).
> >
> > Signed-off-by: Neil Birkbeck
> > ---
> > libavutil/Makefile | 2 +
> > libavutil/frame.h | 7 ++-
> > libavutil/mastering_display_metadata.c | 43 +
> > libavutil/mastering_display_metadata.h | 87
> > ++
> > libavutil/version.h| 2 +-
> > 5 files changed, 139 insertions(+), 2 deletions(-)
> > create mode 100644 libavutil/mastering_display_metadata.c
> > create mode 100644 libavutil/mastering_display_metadata.h
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index bf8c713..65b2d25 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -38,6 +38,7 @@ HEADERS = adler32.h
> > \
> >log.h \
> >macros.h \
> >mathematics.h \
> > + mastering_display_metadata.h \
> >md5.h \
> >mem.h \
> >motion_vector.h \
> > @@ -115,6 +116,7 @@ OBJS = adler32.o
> > \
> > log.o\
> > log2_tab.o \
> > mathematics.o\
> > + mastering_display_metadata.o \
> > md5.o\
> > mem.o\
> > murmur3.o\
> > diff --git a/libavutil/frame.h b/libavutil/frame.h
> > index 9c6061a..308355b 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -106,12 +106,17 @@ enum AVFrameSideDataType {
> > * @endcode
> > */
> > AV_FRAME_DATA_SKIP_SAMPLES,
> > -
> > /**
> > * This side data must be associated with an audio frame and
> > corresponds to
> > * enum AVAudioServiceType defined in avcodec.h.
> > */
> > AV_FRAME_DATA_AUDIO_SERVICE_TYPE,
>
> > +/**
> > + * Mastering display metadata associated with a video frame. The
> > payload is
> > + * an AVMasteringDisplayMetadata type and contains information about
> > the
> > + * mastering display color volume.
> > + */
> > +AV_FRAME_DATA_MASTERING_DISPLAY_METADATA
>
> will this always stay the same or could it require to be extended in
> the future ?
> if future extensions may occur then it should be documented how that
> would work. Would fields be added to the end of the struct ?
> If so how would this be detected ?
>
> C does not gurantee the sizeof to change for the addition of fields
> for example these 2 are both 8bytes on x86-64
> typedef struct X { int a; char b; }X;
> typedef struct Y { int a; char b; char c; }Y;
>
> defining the meaning of the sidedata byte per byte avoids the problem
> of detectability it also makes the function endian and ABI independant
> and would allow passing it bytewise between computers, no idea how
> much thats a real world use case though
>
> [...]
I thought we decided side data can be memcpy'd struct? (I.e. can be
ABI-dependent.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/x264: Improve level setting
Carl Eugen Hoyos ag.or.at> writes: > Nicolas George nsup.org> writes: > > > Le nonidi 29 nivôse, an CCXXIV, Carl Eugen Hoyos a écrit : > > > The original patch (that does not care about tail > > > since it can't be reached anyway) uses atoi(). > > > Is that not ok? > > > > atoi() has undefined behaviours in case of error > > How can I produce an error here? Ping, this code can only be reached with small numbers, so please explain what input would be an issue. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/mjpegdec: Only set SAR if resolution is available
On Tuesday 19 January 2016 02:09:06 am Michael Niedermayer wrote: > On Tue, Jan 19, 2016 at 12:33:40AM +0100, Carl Eugen Hoyos wrote: > > Hi! > > > > Attached patch fixes ticket #4479 here. > > > > Please comment, Carl Eugen > > if w/h is set at that point then their values may be unrelated to the > actual w/h values thus the set_sar there is wrong even if w/h is set > > the patch is fine, iam not sure if the call shouldnt be (re)moved > though moving it might be somewhat non trivial The attached patch also fixes ticket #4479 for me. Thank you, Carl Eugen diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index b1c5b67..9b2a43f 100644 --- a/libavcodec/mjpegdec.c +++ b/libavcodec/mjpegdec.c @@ -1653,7 +1653,6 @@ static int mjpeg_decode_app(MJpegDecodeContext *s) s->avctx->sample_aspect_ratio.num = get_bits(&s->gb, 16); s->avctx->sample_aspect_ratio.den = get_bits(&s->gb, 16); -ff_set_sar(s->avctx, s->avctx->sample_aspect_ratio); if (s->avctx->debug & FF_DEBUG_PICT_INFO) av_log(s->avctx, AV_LOG_INFO, ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
