On 08/06/2018 10:12 PM, Mark Thompson wrote:
On 06/08/18 16:44, Jorge Ramirez-Ortiz wrote:
On 08/04/2018 11:43 PM, Mark Thompson wrote:
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..9457fadb1e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec
On 08/12/2018 04:40 PM, Maxime Jourdan wrote:
Tested on an Odroid-C2 with a V4L2 M2M MJPEG decoder.
cool. did you also test the encoder?
Signed-off-by: Maxime Jourdan
---
configure | 3 +++
libavcodec/Makefile | 2 ++
libavcodec/allcodecs.c| 2 ++
libavcodec/v
On 08/04/2018 11:43 PM, Mark Thompson wrote:
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..9457fadb1e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
struct
On 08/04/2018 02:40 AM, Lukas Rusak wrote:
From: Jorge Ramirez-Ortiz
Signed-off-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_context.c | 19 ---
libavcodec/v4l2_m2m_dec.c | 9 +++--
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/libavcodec
On 06/26/2018 11:36 PM, Lukas Rusak wrote:
This was found using valgrind. Using this patch there is no more memleak
present.
---
libavcodec/v4l2_m2m_dec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 598dc1
On 06/21/2018 11:59 PM, Carl Eugen Hoyos wrote:
2018-06-20 16:50 GMT+02:00, Ariel Frailich :
Input: mostly ProRes (10-20Gb), HD to 4K res, 90 mins average length.
Output: a set of .mp4 files at 5 different resolutions, up to 1080.
These are further processed (primarily bento4) to create multip
On 05/16/2018 08:06 PM, wm4 wrote:
I actually don't have much of a solution to the "nobody willing to step
up" problem, though, no. The offical documents should at least reflect
that reality then, though. A CoC that is ignored, is not a CoC.
True, in that case it's better to remove the CoC becau
On 05/10/2018 04:47 PM, wm4 wrote:
so what would be the sequence of calls for an libavcodec client to
request the DRM format?
https://github.com/BayLibre/ffmpeg-drm/blob/master/main.c#L598
Like in 100% of all existing cases in ffmpeg: set a get_format
callback, and return the format from it.
S
On 05/09/2018 04:11 PM, Mark Thompson wrote:
On 09/05/18 08:57, Jorge Ramirez-Ortiz wrote:
On 05/09/2018 01:33 AM, Mark Thompson wrote:
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index ed5193ecc1..2b33badb08 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec
On 05/09/2018 01:33 AM, Mark Thompson wrote:
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index efcb0426e4..9457fadb1e 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -393,22 +393,54 @@ static int v4l2_release_buffers(V4L2Context* ctx)
struct
On 05/09/2018 01:33 AM, Mark Thompson wrote:
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index ed5193ecc1..2b33badb08 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -23,12 +23,18 @@
#include
#include
+
+#include "libavutil/hwcontext.h"
+
On 04/05/2018 06:42 PM, Maxime Jourdan wrote:
Reduce the minimum amount of CAPTURE and OUTPUT buffers to 1.
makes sense to me if that is indeed the case.
could you provide a real life use case?
There are drivers that may work with such drastic settings,
and FFmpeg doesn't complain.
---
liba
On 02/02/2018 06:50 AM, wm4 wrote:
On Thu, 1 Feb 2018 07:48:27 +0100
Marcin Woźniak wrote:
Hello,
I try to implement an HiSilicon H264 encoder direct input as ffmpeg
libavdevice source (someking like V4L linux for cameras with H264 source
driver).
I successfully recieve H264 packets with NAL u
On 01/21/2018 01:46 AM, Mark Thompson wrote:
On 09/01/18 22:56, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
Tested-by
On 01/22/2018 12:25 AM, Mark Thompson wrote:
On 19/01/18 16:40, Jorge Ramirez-Ortiz wrote:
On 01/19/2018 12:30 AM, Michael Niedermayer wrote:
On Thu, Jan 18, 2018 at 09:24:20AM +0100, Jorge Ramirez-Ortiz wrote:
On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount
Paul B Mahol
txd.c Ivo van Poorten
+ v4l2_*Jorge Ramirez-Ortiz
vc2* Rostislav Pehlivanov
vcr1.cMichael Niedermayer
videotoolboxenc.c
On 01/19/2018 12:30 AM, Michael Niedermayer wrote:
On Thu, Jan 18, 2018 at 09:24:20AM +0100, Jorge Ramirez-Ortiz wrote:
On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when
On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
just a follow up on the patchset (patches 1 to 3)
any
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
Tested-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_buffers.c | 32 ++--
libavcodec
From: Jorge Ramirez-Ortiz
During the initialization stage, the codec attempts to get free
buffers from the driver before any have been queued (this is to keep
the code simple and generic)
When the kernel driver detects this situation, it returns POLLERR in
revents and ffmpeg therefore raises a
From: Jorge Ramirez-Ortiz
Qualcomm's db410c/db820 Venus driver currently present in mainline
kernel has a bug which mishandles the CMD_STOP requests causing the
decoder to block while draining [1].
This patch removes the workaround that was used to prevent that
situation.
Encoding/Dec
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
Tested-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_buffers.c | 32 ++--
libavcodec
On 01/09/2018 06:06 PM, Jorge Ramirez-Ortiz wrote:
From: Jorge Ramirez-Ortiz
During the initialization stage, the codec attempts to get free
buffers from the driver before any have been queued (this is to keep
the code simple and generic)
When the kernel driver detects this situation, it
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -131,14 +131,22 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
V4L2Context *const capture = &s->capture;
V4L2Context *const output = &s->output;
AVPacket avpkt = {0};
-int ret;
+
On 01/09/2018 08:36 PM, wm4 wrote:
Yes, that seems much better conceptually. Though I wonder why there's
still an atomic refcount left.
that one is for the dynamic resolution change (a feature that is
probably broken).
I don't have the hardware I need to test it yet but will start to work
on
From: Jorge Ramirez-Ortiz
During the initialization stage, the codec attempts to get free
buffers from the driver before any have been queued (this is to keep
the code simple and generic)
When the kernel driver detects this situation, it returns POLLERR in
revents and ffmpeg therefore raises a
From: Mark Thompson
Refcount all of the context information. This also fixes a potential
segmentation fault when accessing freed memory (buffer returned after
the codec has been closed).
Tested-by: Jorge Ramirez-Ortiz
---
libavcodec/v4l2_buffers.c | 32 ++--
libavcodec
From: Jorge Ramirez-Ortiz
Qualcomm's db410c/db820 Venus driver currently present in mainline
kernel has a bug which mishandles the CMD_STOP requests causing the
decoder to block while draining [1].
This patch removes the workaround that was used to prevent that
situation.
Encoding/Dec
On 01/09/2018 12:27 AM, Lukas Rusak wrote:
Some small fixes that I have done while working with v4l2
hi Lukas, what sort of error where you observing? I'd like to reproduce
on my end
I was about to post Mark Thompson's fix plus another one to get rid of
the unnecessary timeouts. will do tomor
On 12/21/2017 09:54 AM, wm4 wrote:
On Fri, 15 Dec 2017 12:46:10 +0100
Jorge Ramirez wrote:
On 12/14/2017 07:54 PM, Jorge Ramirez wrote:
On 12/14/2017 07:48 PM, wm4 wrote:
This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially
On 12/14/2017 07:54 PM, Jorge Ramirez wrote:
On 12/14/2017 07:48 PM, wm4 wrote:
This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially could lead to issues
like missing frames at the end of a stream.
---
Untested.
ok you can add
On 12/14/2017 07:48 PM, wm4 wrote:
This is pretty much a requirement for any codec that handles modern
codecs like h264, but it was missing. Potentially could lead to issues
like missing frames at the end of a stream.
---
Untested.
hi,
please do not merge this (the capability was not missing, i
On 11/05/2017 11:12 PM, Jan Ekstrom wrote:
I also feel like whatever this rule would look like, it's already practiced
that way. There isn't really a way not do decide this on a case by case
basis. Luckily it's not something that comes up every other day.
If someone would submit random third part
On 10/23/2017 01:47 AM, Mark Thompson wrote:
so let's make this work then and fix the SIGSEGV present in master asap (btw
this RFC also seg-fault when the above is applied)
Where does that version segfault? (It doesn't for me.)
the patch will segfault if the changes below are applied to the
On 10/19/2017 07:55 PM, Jorge Ramirez wrote:
ok so I guess there is no point to discuss further what I tried to put
forward (I could provide my implementation to compare against this RFC
- it is just a handful of lines of code - but I guess there is no
point given that everyone is
On 10/19/2017 07:55 PM, Jorge Ramirez wrote:
On 10/19/2017 11:49 AM, Mark Thompson wrote:
On 19/10/17 08:28, Jorge Ramirez wrote:
On 10/19/2017 02:10 AM, Mark Thompson wrote:
Refcount all of the context information.
---
As discussed in the other thread, something like this. We move
most of
On 10/19/2017 11:49 AM, Mark Thompson wrote:
On 19/10/17 08:28, Jorge Ramirez wrote:
On 10/19/2017 02:10 AM, Mark Thompson wrote:
Refcount all of the context information.
---
As discussed in the other thread, something like this. We move most of the
context into a refcounted buffer and
On 10/19/2017 02:10 AM, Mark Thompson wrote:
Refcount all of the context information.
---
As discussed in the other thread, something like this. We move most of the
context into a refcounted buffer and AVCodecContext.priv_data is left as a stub
holding a reference to it.
Thoughts:
* Change is
On 10/19/2017 02:10 AM, Mark Thompson wrote:
Refcount all of the context information.
---
As discussed in the other thread, something like this. We move most of the
context into a refcounted buffer and AVCodecContext.priv_data is left as a stub
holding a reference to it.
um, ok ... please co
On 10/18/2017 09:40 PM, Michael Niedermayer wrote:
On Wed, Oct 18, 2017 at 09:46:40AM +0200, Jorge Ramirez wrote:
On 10/18/2017 12:34 AM, Mark Thompson wrote:
int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
{
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mCont
On 10/18/2017 03:28 PM, Mark Thompson wrote:
On 18/10/17 08:46, Jorge Ramirez wrote:
On 10/18/2017 12:34 AM, Mark Thompson wrote:
int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
{
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->pri
On 10/18/2017 12:34 AM, Mark Thompson wrote:
int ff_v4l2_m2m_codec_end(AVCodecContext *avctx)
{
-V4L2m2mContext* s = avctx->priv_data;
-int ret;
+V4L2m2mContext *m2m, *s = avctx->priv_data;
+int i, ret;
ret = ff_v4l2_context_set_status(&s->output, VIDIOC_STREAMOFF);
On 10/17/2017 08:25 PM, wm4 wrote:
On Tue, 17 Oct 2017 19:20:50 +0200
Jorge Ramirez-Ortiz wrote:
A user can close the codec while keeping references to some of the
capture buffers. When the codec is closed, the structure that keeps
the contexts, state and the driver file descriptor is freed
A user can close the codec while keeping references to some of the
capture buffers. When the codec is closed, the structure that keeps
the contexts, state and the driver file descriptor is freed.
Since access to some of the elements in that structure is required to
properly release the memory duri
On 10/06/2017 11:38 PM, Jorge Ramirez-Ortiz wrote:
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original
On 10/06/2017 10:01 PM, Mark Thompson wrote:
On 06/10/17 20:53, Mark Thompson wrote:
On 06/10/17 08:52, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was
On 10/06/2017 09:47 PM, Mark Thompson wrote:
On 06/10/17 08:51, Jorge Ramirez-Ortiz wrote:
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
On 10/06/2017 09:52 AM, Jorge Ramirez-Ortiz wrote:
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
On 10/06/2017 09:51 AM, Jorge Ramirez-Ortiz wrote:
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
bug fix. needed in 3.4
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
--- a/libavcodec
---
libavcodec/v4l2_buffers.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..ba70c5d 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -244,13 +244,23 @@ static int v4l
It occurs when the codec is closed while buffer references still
exist. This is a regression from the original patchset where support
for this use-case was implemented.
The regression occurred while cleaning the code for the last patchset
(decoding was tested only with ffplay which disposes of the
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not imp
On 10/04/2017 08:56 PM, Michael Niedermayer wrote:
On Wed, Oct 04, 2017 at 06:50:31PM +0200, Jorge Ramirez-Ortiz wrote:
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this
On 10/04/2017 06:20 PM, wm4 wrote:
Isn't this something that should be fixed in the driver?
yes but it might take forever and I dont know how many other drivers might
need it.
Why 2MB?
no analysis done but seems to be enough to hold an encoded frame. Should it be
any bigger?
I could use
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for s5p-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not imp
On 10/04/2017 06:23 PM, Mark Thompson wrote:
On 04/10/17 16:48, Jorge Ramirez-Ortiz wrote:
On 10/04/2017 11:28 AM, Jorge Ramirez-Ortiz wrote:
On 10/04/2017 11:23 AM, wm4 wrote:
On Wed, 4 Oct 2017 11:17:24 +0200
Jorge Ramirez-Ortiz wrote:
Some V4L2 drivers fail to allocate buffers when
On 10/04/2017 05:59 PM, wm4 wrote:
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index 297792f..2707ef5 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -92,6 +92,8 @@ static inline int v4l2_type_supported(V4L2Context *ctx)
static inline void v4l
On 10/04/2017 11:28 AM, Jorge Ramirez-Ortiz wrote:
On 10/04/2017 11:23 AM, wm4 wrote:
On Wed, 4 Oct 2017 11:17:24 +0200
Jorge Ramirez-Ortiz wrote:
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for sp5-mfc [1]
Most drivers
On 10/04/2017 11:23 AM, wm4 wrote:
On Wed, 4 Oct 2017 11:17:24 +0200
Jorge Ramirez-Ortiz wrote:
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for sp5-mfc [1]
Most drivers should be able to calculate this value from the frame
Some V4L2 drivers fail to allocate buffers when sizeimage is not set
to a max value. This is indeed the case for sp5-mfc [1]
Most drivers should be able to calculate this value from the frame
dimensions and format - or at least have their own default.
However since this work around should not imp
On 09/28/2017 10:59 AM, Thilo Borgmann wrote:
Am 28.09.17 um 19:57 schrieb Thilo Borgmann:
Am 28.09.17 um 19:29 schrieb Jorge Ramirez-Ortiz:
On 09/28/2017 09:48 AM, Thilo Borgmann wrote:
Am 23.09.17 um 16:48 schrieb Michael Niedermayer:
On Sat, Sep 23, 2017 at 12:28:01AM -0700, Jorge Ramirez
On 09/28/2017 09:48 AM, Thilo Borgmann wrote:
Am 23.09.17 um 16:48 schrieb Michael Niedermayer:
On Sat, Sep 23, 2017 at 12:28:01AM -0700, Jorge Ramirez-Ortiz wrote:
On 09/22/2017 11:49 PM, wm4 wrote:
On Wed, 20 Sep 2017 18:55:40 -0700
Jorge Ramirez-Ortiz wrote:
This patchset enhances
Stopping the codec when no more input is available causes captured
buffers that might be ready to be invalidated.
This commit follows the V4L2 API more closely:
1. when ffmpeg indicates EOS (NULL frame or packet size), the
v4l2_m2m codec will send a dummy buffer to the driver with the
V4L2_BUF
On 09/27/2017 09:31 AM, wm4 wrote:
On Wed, 27 Sep 2017 09:03:58 -0700
Jorge Ramirez-Ortiz wrote:
On 09/27/2017 06:01 AM, wm4 wrote:
On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz wrote:
Stopping the codec when no more input is available causes captured
buffers that might be
On 09/27/2017 06:01 AM, wm4 wrote:
On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz wrote:
Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.
This commit follows the V4L2 API more closely:
1. on the last
Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.
This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers
On 09/22/2017 11:49 PM, wm4 wrote:
On Wed, 20 Sep 2017 18:55:40 -0700
Jorge Ramirez-Ortiz wrote:
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
Pushed to master.
thanks
On 09/20/2017 06:55 PM, Jorge Ramirez-Ortiz wrote:
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been tested on Qualcomm's DragonBoard 410c and 820c
On 09/20/2017 08:31 PM, wm4 wrote:
On Wed, 20 Sep 2017 19:01:52 -0700
Jorge Ramirez-Ortiz wrote:
Btw. I noticed that this apparently never sets chroma_location?
I didnt find anything in v4l2 to retrieve the chroma_location from the kernel
driver (the API doesnt handle this information).
does
42l_m2m_enc/dec --> v4l2_m2m --> v4l2_context --> v4l2_buffers
Reviewed-by: Jorge Ramirez
Reviewed-by: Alexis Ballier
Tested-by: Jorge Ramirez
---
Changelog | 1 +
configure | 28 ++
libavcodec/Makefile | 15 ++
libavcodec/allcodecs.
On 09/19/2017 12:35 PM, wm4 wrote:
On Mon, 11 Sep 2017 16:26:33 +0200
Jorge Ramirez-Ortiz wrote:
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been
This patchset fixes handling the draining use case (tested on db410c)
and simplifies the overall design making it easier to analyze and
maintain.
All encoders/decoders have been tested on db410c and db820c (Qualcomm's
96Boards) on their latest software releases.
__
On 09/19/2017 12:54 PM, wm4 wrote:
On Tue, 19 Sep 2017 12:48:06 -0700
Jorge Ramirez-Ortiz wrote:
I
also assume the data flow issues got solved.
data flow?
Wasn't there some confusion about how send/receive works, and how to
connect it to how v4l2 data flow works?
ah yes, you are
On 09/19/2017 12:35 PM, wm4 wrote:
On Mon, 11 Sep 2017 16:26:33 +0200
Jorge Ramirez-Ortiz wrote:
This patchset enhances Alexis Ballier's original patch and validates
it using Qualcomm's Venus hardware (driver recently landed upstream
[1]).
This has been
reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez
Reviewed-by:
Improvements on v12:
- fixes error detection during context configuration.
- closes the driver properly on exit.
- removes lazy_init field from V4L2Context.
- add more clarity to the context initialization API.
Patch applies on top of:
86eb505 Changelog: add vp9 tile threading support
reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez
Reviewed-by:
reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez
Reviewed-by:
Apologies for sending v10 right after having sent v9 just a few hours ago but I
think it makes sense to improve the overall readability while saving some
memory.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/f
On 09/05/2017 10:27 AM, wm4 wrote:
On Tue, 5 Sep 2017 10:03:49 +0200
Jorge Ramirez wrote:
On 09/05/2017 09:16 AM, Jorge Ramirez wrote:
On 09/05/2017 12:16 AM, Mark Thompson wrote:
On 04/09/17 22:55, Jorge Ramirez wrote:
On 09/04/2017 11:29 PM, Mark Thompson wrote:
... stuff ...
So the
reconfiguration.
- v4l2: add more frame information
- v4l2: free hardware resources on last reference being released
- v4l2: encoding: disable b-frames for upstreaming (patch required)
[1] https://lwn.net/Articles/697956/
Reviewed-by: Jorge Ramirez
Reviewed-by:
On 09/05/2017 09:16 AM, Jorge Ramirez wrote:
On 09/05/2017 12:16 AM, Mark Thompson wrote:
On 04/09/17 22:55, Jorge Ramirez wrote:
On 09/04/2017 11:29 PM, Mark Thompson wrote:
... stuff ...
So the sequence of calls is:
send_frame(frame 0) -> success
receive_packet() -> EAGAIN
send
On 09/05/2017 12:16 AM, Mark Thompson wrote:
On 04/09/17 22:55, Jorge Ramirez wrote:
On 09/04/2017 11:29 PM, Mark Thompson wrote:
... stuff ...
So the sequence of calls is:
send_frame(frame 0) -> success
receive_packet() -> EAGAIN
send_frame(frame 1) -> success
receive_packet()
On 09/04/2017 11:29 PM, Mark Thompson wrote:
On 04/09/17 22:07, Jorge Ramirez wrote:
On 09/04/2017 10:45 PM, Mark Thompson wrote:
On 04/09/17 21:34, Jorge Ramirez wrote:
On 09/04/2017 07:55 PM, Mark Thompson wrote:
On 04/09/17 18:01, Jorge Ramirez wrote:
On 09/04/2017 06:31 PM, Mark
On 09/04/2017 10:45 PM, Mark Thompson wrote:
On 04/09/17 21:34, Jorge Ramirez wrote:
On 09/04/2017 07:55 PM, Mark Thompson wrote:
On 04/09/17 18:01, Jorge Ramirez wrote:
On 09/04/2017 06:31 PM, Mark Thompson wrote:
On 04/09/17 17:00, Jorge Ramirez wrote:
On 09/03/2017 08:23 PM, Mark
On 09/04/2017 07:55 PM, Mark Thompson wrote:
On 04/09/17 18:01, Jorge Ramirez wrote:
On 09/04/2017 06:31 PM, Mark Thompson wrote:
On 04/09/17 17:00, Jorge Ramirez wrote:
On 09/03/2017 08:23 PM, Mark Thompson wrote:
On 03/09/17 17:54, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark
On 09/04/2017 07:01 PM, Jorge Ramirez wrote:
On 09/04/2017 06:31 PM, Mark Thompson wrote:
On 04/09/17 17:00, Jorge Ramirez wrote:
On 09/03/2017 08:23 PM, Mark Thompson wrote:
On 03/09/17 17:54, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+/* in ffmpeg there is a single
On 09/04/2017 06:31 PM, Mark Thompson wrote:
On 04/09/17 17:00, Jorge Ramirez wrote:
On 09/03/2017 08:23 PM, Mark Thompson wrote:
On 03/09/17 17:54, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+/* in ffmpeg there is a single thread could be queueing/dequeuing buffers so
On 09/03/2017 08:06 PM, Mark Thompson wrote:
On 03/09/17 15:36, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+}
+
+/* 2.1 update the AVCodecContext */
+avctx->pix_fmt =
ff_v4l2_v4l2fmt_to_avfmt(capture->format.fmt.pix_mp.pixelformat,
AV_CODEC_ID_RA
On 09/03/2017 08:23 PM, Mark Thompson wrote:
On 03/09/17 17:54, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+/* in ffmpeg there is a single thread could be queueing/dequeuing buffers so a
+ * timeout is * required when retrieving a frame in case the driver has not
On 09/03/2017 08:13 PM, Mark Thompson wrote:
On 03/09/17 16:26, Jorge Ramirez wrote:
On 09/03/2017 04:56 PM, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+.long_name = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " decoder
wrapper
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+
+return 0;
+}
+
+static int v4l2m2m_send_frame(AVCodecContext *avctx, const AVFrame *frame)
+{
+V4L2m2mContext *s = avctx->priv_data;
+V4L2Context *const output = &s->output;
+
+return ff_v4l2_enqueue_frame(output, frame);
+}
+
+/* Se
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+/* in ffmpeg there is a single thread could be queueing/dequeuing buffers so a
+ * timeout is * required when retrieving a frame in case the driver has not
received
+ * enough input * to start generating output.
+ *
+ * once decoding starts, the time
On 09/03/2017 02:53 PM, Mark Thompson wrote:
On 03/09/17 13:20, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+# check V4L2 codecs available in the API
check_header linux/fb.h
check_header linux/videodev.h
check_header linux/videodev2.h
check_code cc linux
On 09/03/2017 02:27 AM, Mark Thompson wrote:
# Enable hwaccels by default.
-enable_weak d3d11va dxva2 vaapi vda vdpau videotoolbox_hwaccel xvmc
+enable_weak d3d11va dxva2 vaapi v4l2_m2m vda vdpau videotoolbox_hwaccel xvmc
[This line has disappeared on rebase.]
ok, just rebased today and saw
On 09/03/2017 04:56 PM, Jorge Ramirez wrote:
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+.long_name = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " decoder
wrapper"),\
+.type = AVMEDIA_TYPE_VIDEO,\
+.id = CODEC ,\
+.pri
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+
+val = lfind(&p, profile, &len, sizeof(profile[0]), match_profile);
+if (val)
+return val->v4l2_val;
+
+return FF_PROFILE_UNKNOWN;
Returning FF_PROFILE_UNKNOWN here is bit weird because it mixes the namespaces.
I know that's ho
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+.long_name = NULL_IF_CONFIG_SMALL("V4L2 mem2mem " LONGNAME " decoder
wrapper"),\
+.type = AVMEDIA_TYPE_VIDEO,\
+.id = CODEC ,\
+.priv_data_size = sizeof(V4L2m2mContext),\
+.priv_class = &v4l2_m2m_ ##
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+}
+
+/* 2.1 update the AVCodecContext */
+avctx->pix_fmt =
ff_v4l2_v4l2fmt_to_avfmt(capture->format.fmt.pix_mp.pixelformat,
AV_CODEC_ID_RAWVIDEO);
+capture->av_pix_fmt = avctx->pix_fmt;
+
+/* 3. set the crop parameters */
+se
On 09/03/2017 02:27 AM, Mark Thompson wrote:
+/* 0. subscribe to source change event */
+memset(&sub, 0, sizeof(sub));
+sub.type = V4L2_EVENT_SOURCE_CHANGE;
+ret = ioctl(s->fd, VIDIOC_SUBSCRIBE_EVENT, &sub);
+if ( ret < 0)
+av_log(avctx, AV_LOG_WARNING, "decoding does
1 - 100 of 208 matches
Mail list logo
