gmane.comp.video.ffmpeg.devel

Re: [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.

Xidorn Quan — 2013-05-23T07:21:47


So you may like to have a look at my solution here:
http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143988.html

Re: [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.

Hendrik Leppkes — 2013-05-23T07:19:11

You can do that if you just create a AVBufferRef around your buffer
(you can specify a release callback for AVBufferRefs) and put it
somewhere in frame->buf, it'll be free'ed with the frame then.
I'm not really liking the new function in AVHWAccel, because its not
really required with the new buffer management functions.

Considering frame->data[3] is set by the code, i think its safe to
also set frame->buf[3] to the AVBufferRef managing this buffer without
worrying about user-code.

Re: [PATCH 0/2]: allow hwaccel vda module to manageits buffers lifetime.

Sebastien Zwickert — 2013-05-23T07:14:22

I'm not sure to understand correctly but the vda buffer is part of
Core Video SDK which is based on a ref counted memory management
and must be released with CVPixelBufferRelease().
So custom callback for freeing Core Video types is necessary.

Re: [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.

Xidorn Quan — 2013-05-23T06:46:19


It is the solution I proposed before. You can find such patchset in this
mailing list as well.

I agree that using frame->buf isn't a bad idea since changes are only in
vda_h264 files, and no callback is required to be added, but I think using
the existing hwaccel priv_buf is a better way because it hides details from
caller, and caller can still use frame->buf for other uses.
A possible case is that some callers may have started using frame->buf
themselves because there is not forbiddance from the original usage, and
setting frame->buf may break them.

Re: [PATCH 0/2]: allow hwaccel vda module to manage its buffers lifetime.

Hendrik Leppkes — 2013-05-23T06:29:08

You set frame->data[3] to the same buffer that needs freeing, why not
simply also set frame->buf appropriately to a AVBufferRef you create,
so that it gets free'ed with a callback there?
No extra release buffer callback needed from where i stand.

Re: [PATCH 2/2] vda: use hwaccel custom callback for releasing private picture context.

Hendrik Leppkes — 2013-05-23T06:22:49

Adding this in the middle of the struct breaks ABI.

Re: [PATCH] lavfi: simplify link dependencies.

Michael Niedermayer — 2013-05-23T02:20:59

in case you are making packages for a distribution.
the users dont want random unneeded dependencies
also it could slow down loading

reminds me of
a few days ago i updated the kernel header package on an old box
guess what, i had to update compilers and libc too. (i doubt anything
needed them to be upgraded)

[RFC] Dynamic Hald CLUT

Clément Bœsch — 2013-05-23T02:00:01

Hi folks,

I'm on a new project based on the recently added 3D LUT filter, and I
would like some comments.

Basically, a 3D LUT is a RGB color map. In theory, with 8-bit, you would
have 16M colors (256*256*256), one axis for each component, each "node"
associated with a new RGB color. In practice, it's generally a 16*16*16 or
eventually 32*32*32 color map, and the missing colors are interpolated
using various methods. It also makes possible to store a 16-bit map
without an insane amount of memory requirement.

So this is the basic theory behind the 3D LUT. Though, most of the formats
used to store them are different, and it's a pain to support them
properly. Fortunately, someone came up with the idea to store those tables
not in a text based file, but simply in a picture. This is called Hald
CLUT¹

Apart from the format being natively supported in FFmpeg, it also makes
possible something pretty awesome: we can apply several color filters to
the image (with FFmpeg or any external tools), and then reuse the
r

Re: [PATCH] lavfi: simplify link dependencies.

Clément Bœsch — 2013-05-23T00:45:00

Yes, it will make a dependency, but only if it's available. What problem
could that cause? I mean, in what situation would you not want that
dependency if you build the other libraries?

Re: [Patch] AAC encoder improvements

Michael Niedermayer — 2013-05-23T00:26:27

I agree



When the aac encoder was originally written i pushed to use
dynamic programming / viterbi. This code was never finished ...
I dont remember any technical reason why it wasnt finished.



ok

thanks!

[...]

Re: [PATCH] lavfi: simplify link dependencies.

Michael Niedermayer — 2013-05-23T00:12:26

I think with that change libavfilter would depend on all build libs
even if it uses nothing from them

[...]

Re: MOV: Fix old-style muxed raw-audio data

Alex Sukhanov — 2013-05-22T23:57:25

Hi Carl,

I have a file, its size about 3Mb, could you please tell me where I should
put it?

Thank you


On Wed, May 22, 2013 at 2:36 AM, Carl Eugen Hoyos <cehoyos< at >ag.or.at> wrote:

[PATCH 1/2] hwaccel: allow to set a user-definedcallback for releasing private av buffer.

Sebastien Zwickert — 2013-05-22T19:53:13

         Since the new ref counted buffer API vda hwaccel module must have its
         own free callback to release correctly its private buffers.
---
 libavcodec/avcodec.h   |   12 ++++++++++++
 libavcodec/h264.c      |    9 ++++++++-
 libavcodec/mpegvideo.c |    9 ++++++++-
 3 files changed, 28 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7ce9df4..e24a4e6 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
< at >< at > -3068,6 +3068,18 < at >< at > typedef struct AVHWAccel {
      * AVCodecContext.release_buffer().
      */
     int priv_data_size;
+
+    /**
+     * Custom free callback wich releases the private picture context.
+     *
+     * opaque data is allocated with av_mallocz() of the size of HWAccel.priv_data_size.
+     * This function is optional, if not set the default free callback
+     * AVBuffer.av_buffer_default_free() is used.
+     *
+     * < at >param opaque the picture context
+     * < at >param data the av buffer data
+     */
+    void (*release_buffe

[PATCH 2/2] vda: use hwaccel custom callback forreleasing private picture context.

Sebastien Zwickert — 2013-05-22T19:53:14

     Note: it is recommended to use AVCodecContext.get_buffer2() to
     release correctly the dropped buffers and fix memory leaks.
---
 libavcodec/vda.h      |   12 +++++++++++-
 libavcodec/vda_h264.c |   18 ++++++++++++++++++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vda.h b/libavcodec/vda.h
index 281785f..5539baa 100644
--- a/libavcodec/vda.h
+++ b/libavcodec/vda.h
< at >< at > -67,11 +67,21 < at >< at > struct vda_context {
      * The Core Video pixel buffer that contains the current image data.
      *
      * encoding: unused
-     * decoding: Set by libavcodec. Unset by user.
+     * decoding: Set by libavcodec. Unset by libavcodec or user.
      */
     CVPixelBufferRef    cv_buffer;
 
     /**
+     * If this property is set the core video buffer is released by the decoder, otherwise
+     * the user is responsible itself for releasing the core video buffer in AVFrame.data[3]
+     * with CVPixelBufferRelease().
+     *
+     * encoding: unused
+     * decoding: Set by user.
+     */

[PATCH 0/2]: allow hwaccel vda module to manage itsbuffers lifetime.

Sebastien Zwickert — 2013-05-22T19:53:12

This patchset fixes memory leaks of vda core video buffers while seeking.
It allows hwaccel modules to set a custom callback for freeing av buffers.
Then vda decoder can flush correctly dropped frames.

Thanks to Xidorn Quan who gives me good feebacks about the patch I shared
with him in private.

Sebastien Zwickert (2):
  hwaccel: allow to set a user-defined callback for releasing private
    av buffer.
  vda: use hwaccel custom callback for releasing private picture
    context.

 libavcodec/avcodec.h   |   12 ++++++++++++
 libavcodec/h264.c      |    9 ++++++++-
 libavcodec/mpegvideo.c |    9 ++++++++-
 libavcodec/vda.h       |   12 +++++++++++-
 libavcodec/vda_h264.c  |   18 ++++++++++++++++++
 5 files changed, 57 insertions(+), 3 deletions(-)

Re: [PATCH] v4l2: make possible to disable libv4l2 at runtime.

Clément Bœsch — 2013-05-22T17:51:57

Thanks, applied.

[PATCH] lavfi: simplify link dependencies.

Clément Bœsch — 2013-05-22T17:38:14

This avoids re-declaring the filter dependencies. Also, it fixes the
optional dependencies: for instance the select filter having an optional
dependency on avcodec.
---
 libavfilter/Makefile | 23 ++++++-----------------
 1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6cc2930..2897f49 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
< at >< at > -2,23 +2,12 < at >< at > include $(SUBDIR)../config.mak
 
 NAME = avfilter
 FFLIBS = avutil
-FFLIBS-$(CONFIG_ACONVERT_FILTER)             += swresample
-FFLIBS-$(CONFIG_AMOVIE_FILTER)               += avformat avcodec
-FFLIBS-$(CONFIG_ARESAMPLE_FILTER)            += swresample
-FFLIBS-$(CONFIG_ASYNCTS_FILTER)              += avresample
-FFLIBS-$(CONFIG_ATEMPO_FILTER)               += avcodec
-FFLIBS-$(CONFIG_DECIMATE_FILTER)             += avcodec
-FFLIBS-$(CONFIG_DESHAKE_FILTER)              += avcodec
-FFLIBS-$(CONFIG_MOVIE_FILTER)                += avformat avcodec
-FFLIBS-$(CONFIG_MP_FILTER)

racing video any compiling suggestions?

Micah Waddoups — 2013-05-22T04:28:18

   I've got an x86_64 (3-core x 4Ghz) AMD system with Radeon video chip 
and just lately, since my last local compiling version 1.2.1 on Arch 
Linux, I have been having difficulty with some serious timing issues. 
|ffplay| seems to drift ahead by .1 to .5 seconds in the video, so the 
sound comes too late.  I've been trying with |ffmpeg| to utilize the 
schroedinger codec, and had some sporatic success a few times at first, 
but from then since the schro/dirac codec has been racing so far ahead 
of the audio that one can actually see the video going too fast in the 
resulting video.

   I have written a bunch of scripts around the new ffmpeg release, and 
I want to maximize use of the gradually progressing support for 
schroedinger/dirac as well as opus, so how to deal with this seems to be 
a either a matter to bring development focus to, or ask help resolving 
from my end.  Does anyone have a similar experience? Could there be a 
way to work around it at the compiling stage?


|ffmpeg version 1.2.1 Copyrig

Re: [PATCH] lavfi: add lut3d filter.

Clément Bœsch — 2013-05-22T16:28:55

[...]

I've added the software that seem related to those formats. Unfortunately,
I don't own any, I just had a few random samples, so I can't really check
anything. Also, some extensions are shared with multiple softwares, and of
course different layouts. That's hard to tell which one belongs to which
one. There is certainly a room for improvements here.


Yes. But with the Hald CLUT we can do much better actually. See below.

Also, those sample are pretty huge (see
http://www.pandora-int.com/pandora/download/manual/cube_example.html)

[...]

Added.


It is described here: http://www.quelsolaar.com/technology/clut.html

I removed that chunk since I've implemented it in another filter already
(I'm still considering merging it with lut3d though).

The interesting thing about these Hald CLUT is that they are stored as
images, which allow much more awesome things. Typically, you generate an
identity LUT into a picture, process that picture with whatever color
filters, and then you can just use this picture to p

Re: [Patch] AAC encoder improvements

Claudio Freire — 2013-05-22T15:36:22

So, I've been keeping working on AAC, and I came to the conclusion
that a new encoder based on a dynamic programming approach, optimizing
rate distortion within bitrate constraints, would be the best choice.

Since this seems rather obvious, mostly because the x_trellis_x
functions seem to already use dynamic programming, I'm wondering if
anyone has already considered and discarded this. Especially since
such an algorithm would be a bit slower than twoloop (not sure by how
much yet).

The cost of a dynamic programming approach should be around Φ(W x Nsfb
x Nsfi), with W x Nsfb ~ 80 and Nsfi ~ 190 under normal circumstances,
and with currently twoloop being around Φ(W x Nsfb x 20). I included
the constants for a finer comparison, obviously.

Independently, with the insight gained while looking into this
RD-optimization approach, I got a few improvements to twoloop that are
worth pursuing. So I'll break it into tiny, manageable and tidy
patches soon. PSNR (tinypsnr) is still lying through its teeth... I'll
s

Re: [PATCH 2/2] Support playing SMV files.

Michael Niedermayer — 2013-05-22T13:37:34

patch applied

maybe you want to add a fate/regression test for it

Thanks

[...]