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
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
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
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
The previous patchset has been reduced to a single patch thus avoiding
the dependency with libavdevice.
I believe all the review comments raised during v6 have been addressed
- in particular delegating the closure of the device drivers until the
last AVBufRef has been freed.
Encoding and decoding
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 63 ++-
libavcodec/v4l2_fmt.h | 17 +-
libavdevice/v4l2.c| 2 +-
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 855cc64.
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez
This patch-set adds support for dynamically reconfiguring the video stream.
The set was rebased on top of [1].
The fate suite was run successfully and the encoders/decoders have
been tested (including a fix for vp8 encoding). Simultaneous
encoding/decoding was also validated and the build system
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 855cc64.
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
Configure/make scripts have been validated on Ubuntu 10.04 and
16.04.
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 63 ++-
libavcodec/v4l2_fmt.h | 17 +-
libavdevice/v4l2.c| 2 +-
This commit fixes the broken build on platforms not support v4l2_m2m
but supporting v4l - this has been tested on ubuntu 10.04, 2.6.xx
kernel.
It also fixes a regression introduced in libavcodec/Makefile with v4.
Fate suite and encoders/decoders tested as per the comments in the
main functional c
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
Tested decoders:
- h264
- mpeg4
- vp8
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/libavcodec/v4l2_fmt.c b/libavcodec/v4l2_fmt.c
index 855cc64.
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2_fmt.c | 63 ++-
libavcodec/v4l2_fmt.h | 17 +-
libavdevice/v4l2.c| 2 +-
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
v4l2-common was renamed to v4l2_fmt for clarity (v4l2-common.h belongs
to the V4L2 API)
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez
This patchset contains quite a bit of code reorganization with respect
to v3. In it, I removed plenty of sedimented code and improved the
semantics by adding some abstractions.
I have also addressed most of the concerns raised by Mark Thompson
during the v3 revision (I'll continue to scan my email
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 63
libavcodec/v4l2-common.h | 7 +-
libavdevice/v4l2.c | 2 +-
l
From: Alexis Ballier
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index
The following patchset adds support for V4L2 mem2mem codecs.
This feature gives ffmpeg access to any hardware codec implementing the
V4L2 API. Since the number of hardware codecs implementing this API is
expected to increase, we believe it will be benefitial to all users to
integrate its support i
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
---
configure | 6 ++-
libavcodec/Makefile | 1
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 63
libavcodec/v4l2-common.h | 7 +-
libavdevice/v4l2.c | 2 +-
l
From: Alexis Ballier
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
---
configure | 6 ++-
libavcodec/Makefile | 1
integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
configure | 6 --
libavcodec/Makefile | 1 +
libavcodec/v4l2-common.c | 105
From: Alexis Ballier
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
ffplay tested video decoders:
- h264,
- vp8
- mpeg4
Some of the chang
From: Alexis Ballier
In addition, enable the multi planar raw formats.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavcodec/v4l2-common.c b/libavcodec/v4l2-common.c
index
From: Alexis Ballier
Extend the mapping function to use the v4l2 conversion tables.
Reviewed-by: Jorge Ramirez
Tested-by: Jorge Ramirez
---
libavcodec/v4l2-common.c | 63
libavcodec/v4l2-common.h | 7 +-
libavdevice/v4l2.c | 2 +-
l
From: Alexis Ballier
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
---
configure | 6 ++-
libavcodec/Makefile | 1
--
In preparation to support the integation of the V4L2 API for encoding
and decoding, move v4l2 related files to libavcodec.
Signed-off-by: Alexis Ballier
Reviewed-by: Jorge Ramirez-Ortiz
configure | 6 --
libavcodec
ffplay always requires user intervention via the GUI to close the
video at the end of the file.
This commit, stops playing and terminates the program when EOF is
received.
---
ffplay.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index c0b326
94 matches
Mail list logo
