SQL
injection).
Either you remove that functionality, or you ensure that all URls ever passed
to libavformat trusted. Best of luck with the latter option.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.
On Wednesday 20 January 2016 13:42:43 Anton Khirnov wrote:
> It is of very limited usefulness and is a source of important security
> problems.
I suggested it so obviously fine with me.
If someone really has a use for it, I´d suggest configuring it via out-of-band
options.
--
Rémi
HLS.
I would suggest either:
1) removing concat completely, or
2) ignoring the concat locator string, and passing the list of concatenated
URIs through AV options (similarly to what VLC does).
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-de
On Wednesday 13 January 2016 19:29:40 Luca Barbato wrote:
> On 13/01/16 18:46, Rémi Denis-Courmont wrote:
> > How and to whom? I fail to see a bug.
>
> In a moderately convoluted way one can upload a m3u8 that references to
> the concatenation of a playlist and the fil
On Wednesday 13 January 2016 18:14:16 Luca Barbato wrote:
> concat can be abused to leak local file contents as url parameter.
How and to whom? I fail to see a bug.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
li
h
I'm
going to be happy if you tell me that vdpau surface allocation is
always maximally efficient and doesn't need a pool.)
Rémi tells me the pools are not need for performance reasons. But
some
old hardware requires preallocating surfaces for some other weird
reasons. And of course many other APIs can only work with the full
pool
preallocated beforehand, so some support for that will be needed.
Uh? No. VDPAU has no requirements to preallocate surfaces. The problem
is, preallocating is the only way to ensure that the GPU will have
enough memory to meet the run-time buffers requirements.
Otherwise, you might end up, e.g. with 4 video surfaces on a bitstream
that requires 16 reference frames. And fail.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
+int av_hwframe_ctx_init(AVBufferRef *ref);
+
+int av_hwframe_get_target_formats(const AVFrame *frame,
+ enum AVPixelFormat **formats);
+
+int av_hwframe_retrieve_data(AVFrame *dst, const AVFrame *src);
+
+#endif /* AVUTIL_HWFRAME_H */
--
Rémi Denis-Courmont
http://www.remlab.net/
___
.name = "VDPAU",
+.hwctx_size = sizeof(AVVDPAUFramesContext),
+.priv_size = sizeof(VDPAUFramesContext),
+.init = vdpau_init,
+.uninit = vdpau_uninit,
+.get_target_formats = vdpau_get_target_formats,
+.retrieve_data = vdpau_retrieve_data,
+};
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
I would probably have noticed the problem in the
first place if libavcodec did not print (at least) one deprecation
warning per source module :-(
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https:/
t) branch when getservbyport is
not
available.
On ancient OSes, I'd remove all use of servent and replace with
strtoul/s*printf or whatever. It would be thread safe and not have those
issues.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-deve
The VDPAU API never explicitly supported H.263 in the first place.
---
configure| 2 --
libavcodec/Makefile | 1 -
libavcodec/allcodecs.c | 1 -
libavcodec/vdpau_mpeg4.c | 24
4 files changed, 28 deletions(-)
diff --git a/configure b/configure
On Wednesday 28 October 2015 20:59:01 Luca Barbato wrote:
> On 28/10/15 20:21, Rémi Denis-Courmont wrote:
> > The VDPAU API never explicitly supported H.263 in the first place.
> > ---
> >
> > configure| 2 --
> > libavcodec/Makefile |
strict implementations require that there be no quotes here.
It might be a good idea to accept invalid extraneous quotes for IOP.
Sending invalid messages ones on purpose is insane. The problem is known
and the conclusion from RFC7616 was to verry explicitly FORBID quotes.
--
Rémi Denis-Courmon
Le 2015-10-13 20:47, Luca Barbato a écrit :
On 13/10/15 18:21, Rémi Denis-Courmont wrote:
Le 2015-10-13 12:44, Martin Storsjö a écrit :
From: Carl Eugen Hoyos <ceho...@ag.or.at>
Some overly strict implementations require this, even though it
technically is incorrect according to th
+#include "libavutil/thread.h"
#include "cabac.h"
#include "error_resilience.h"
#include "get_bits.h"
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
ing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
is pthread_create().
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Le 2015-10-08 18:01, wm4 a écrit :
It's extremely related. We could use pthread function names directly,
instead of going through our stupid ff_ aliases.
And you wouldn't have to make two separate builds of libav*.
--
Rémi Denis-Courmont
http://www.remlab.net
and CV operations. Namely, abort if init fails, and assert
for all other functions for self debugging.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
letely. Even MSDN
started dropping documentation for it.
Either way, the function is no longer necessary at all.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo
g code bases.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
This function can intrinsically not deal with codec profile fallback
(for H.264 Constrained Baseline especially), and was made redundant
by av_vdpau_bind_context().
---
libavcodec/vdpau.h | 5 +
libavcodec/version.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.h
_level, _mb,
Seems fine.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
this is really a matter for FFmpeg developers to decide. But if
I were them, I would definitely not waste my time^W^W^Wcare for binary
compatiblity.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https
is impractical.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
by MSG_NOSIGNAL on modern BSD,
of course.)
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
= FF_PROFILE_H264_HIGH;
+break;
+}
+
+if (ctx-level) {
+h264-level = ctx-level;
+} else {
+h264-level = NV_ENC_LEVEL_AUTOSELECT;
+}
+
+return 0;
+}
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel
Le 2015-05-25 13:54, Luca Barbato a écrit :
On 25/05/15 12:46, Rémi Denis-Courmont wrote:
+switch (avctx-profile) {
+case FF_PROFILE_H264_BASELINE:
+cc-profileGUID = NV_ENC_H264_PROFILE_BASELINE_GUID;
+break;
What about CBP?
I see
Le 2015-05-25 14:44, Luca Barbato a écrit :
On 25/05/15 13:37, Rémi Denis-Courmont wrote:
How does that justify falling back to High when CBP is requested?
And
ditto for CHP since you brought it up.
Issuing an error and going out instead of a warning sounds better?
IMHO, an encoder output
Le lundi 25 mai 2015, 20:42:58 Luca Barbato a écrit :
On 25/05/15 13:51, Rémi Denis-Courmont wrote:
Le 2015-05-25 14:44, Luca Barbato a écrit :
On 25/05/15 13:37, Rémi Denis-Courmont wrote:
How does that justify falling back to High when CBP is requested? And
ditto for CHP since you
Le vendredi 15 mai 2015, 22:06:02 Luca Barbato a écrit :
On 15/05/15 20:39, Rémi Denis-Courmont wrote:
Le 2015-05-15 17:18, Luca Barbato a écrit :
Make it as large as 5 times the expected maximum udp packet.
Increasing the buffer size may be a good idea on Windows. But setting a
buffer
whatever size the OS wanted.
My point is that leaving the OS default is the best choice on Linux, and that
the patch is hardly an improvement in this respect. I of course agree that
shrinking the OS default is bad idea.
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net
OFFSET(x) offsetof(UDPContext, x)
#define D AV_OPT_FLAG_DECODING_PARAM
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Le dimanche 10 mai 2015, 19:15:24 wm4 a écrit :
GnuTLS uses writev() to write to the socket without giving MSG_NOSIGNAL.
Should that not be fixed upstream? Do they specifically want to support non-
socket file descriptors?
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net
+return ret;
}
static int tls_close(URLContext *h)
{
TLSContext *c = h-priv_data;
+BLOCK_SIGPIPE
TLS_shutdown(c);
TLS_free(c);
ffurl_close(c-tcp);
ff_tls_deinit();
+UNBLOCK_SIGPIPE
return 0;
}
--
Rémi Denis-Courmont
Remlab T:mi
http
Le 2015-05-06 14:42, Steve Lhomme a écrit :
most calls to DXVA are now done via macros and the core C code is
included
I am not an authority here, but I'd use callbacks over macros, if only
to avoid duplicate byte code.
--
Rémi Denis-Courmont
Remlab T:mi
http://www.remlab.net
-parameters.xhtml#rtp-parameters-10
?
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Le 2015-04-30 16:13, Anton Khirnov a écrit :
I meant that we don't currently support it. Is this feature actually
used in the wild?
I would not call Video over LTE wild just yet... (if ever.)
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav
,
+ Insufficient thread locking around avcodec_open2().
+ At least %d threads are running at the same time
right now.\n,
+ entangled_thread_counter);
Why don't you use standard __func__ and %s ?
ret = -1;
goto end;
}
--
Rémi Denis-Courmont
, you are better off outputting to
libpulse directly or through a more specific and feature-rich audio
output abstraction.
And then there is the major issue of timing.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https
This uses explicit memory copying to read and write pointer to pointers
of arbitrary object types. This works provided that the architecture
uses the same representation for all pointer types (the previous code
made that assumption already anyway).
---
libavutil/mem.c | 32
on the compiler performing DCE.
Its done this way in the expectation that more implementations will
appear
eventually, where having it inside the if condition makes no sense
anymore.
I'd use a switch statement though.
--
Rémi Denis-Courmont
___
libav-devel
1-5 LGTM.
6-7 I don't have much clue.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
.
That would fail miserably if libva is present but has no functioning
driver backend. Besides, it makes no sense: it is not libavcodec that
devices to use libva or not, it is the calling application.
--
Rémi Denis-Courmont
___
libav-devel mailing list
Le 2015-01-15 18:06, Luca Barbato a écrit :
Personally I'm not against that assuming we can make it not
completely
brittle.
The calling application and libavcodec must agree on the instance and
SO version of libva in use. How do you make that not brittle?
--
Rémi Denis-Courmont
.
It makes no sense for a library that is itself a plugin loader. libva
is neither large nor sensitive; if anything, the individual VA drivers
are large and/or sensitive.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https
Le mercredi 14 janvier 2015, 16:09:47 Kim Gunsoo a écrit :
- If you are deploying libav, build and runtime environments are different.
Using --enable-vaapi can might cause to fail on the execution.
- This is an optional feature to check the execution environment in the
runtime. It can
fare type. Otherwise, you have to pay the normal
price, but you avoid queues at the ticket counter.
Looking forward to seeing many of you in Brussels,
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
. That pretty much
excludes x264 and x265, and according to the comments in the previous
patch, Cisco's OpenH264 as well.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
to code the mapping from
AV_PIX_FMT_* to VDP_CHROMA_TYPE_* and to VDPAU-specific dimension
constraints.
Speaking of which, why is avcodec_default_get_format even public
right
now?
I don't know but at least VLC uses it.
--
Rémi Denis-Courmont
This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 7 +++
libavcodec/utils.c | 15 +++
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10
This is to avoid proliferation of similar tables in following changes.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 11 +--
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 5ed1fff..742b648
://lists.freedesktop.org/archives/vdpau/2014-November/000241.html
To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
doc/APIchanges | 3 +++
libavcodec
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau.c | 6 +-
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index c2826e6..edce30f 100644
--- a/libavcodec
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..1bd1f48 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer
, and means
more per-application copycat code.
The last option is to store the needed bits directly in the context. That
would be awful though.
I think adding the new function from patch 4 is yet the cleanest and least
invasive solution.
--
Rémi Denis-Courmont
http://www.remlab.net
From: Michael Niedermayer michae...@gmx.at
Add padding, clear size, use the correct pointer.
Signed-off-by: Michael Niedermayer michae...@gmx.at
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/svq1dec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Thiago Santos thiago.sousa.san...@collabora.com
Fixes linking when only a subset of vaapi decoders is enabled.
To reproduce, disable all features except h264 decoder and vaapi/vdpau
for h264
Signed-off-by: Rémi Denis-Courmont r...@remlab.net
---
libavcodec/vaapi.c | 4
1 file
Le dimanche 14 décembre 2014, 22:59:26 Rémi Denis-Courmont a écrit :
From: Michael Niedermayer michae...@gmx.at
Fixes bug #766.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org
Le dimanche 14 décembre 2014, 22:59:27 Rémi Denis-Courmont a écrit :
From: Thiago Santos thiago.sousa.san...@collabora.com
Fixes bug #760.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https
last changes:
- resync with libvdpau git tree,
- address comments from Luca and Vittorio,
- misc minor fixes.
Rémi Denis-Courmont (10):
vdpau: revector macro to reduce line span
vdpau: add mapping for H.264 Extended profile
Old VDPAU drivers do not support this newly defined profile, so falling
back to Main profile is necessary for backward binary compatibility.
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c
---
libavcodec/vdpau.c | 38 ++
libavcodec/vdpau_h264.c | 2 +-
libavcodec/vdpau_internal.h | 3 ++-
libavcodec/vdpau_mpeg12.c | 6 --
libavcodec/vdpau_mpeg4.c| 6 --
libavcodec/vdpau_vc1.c | 3 ++-
6 files changed, 43
---
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 11 +--
2 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vdpau_h264.c b/libavcodec/vdpau_h264.c
index 578b711..b7f79bf 100644
--- a/libavcodec/vdpau_h264.c
+++
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau.c | 11 +++
libavcodec/vdpau_h264.c | 29 -
libavcodec/vdpau_internal.h | 3 +++
4 files changed, 45 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do {
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed
This is to avoid proliferation of similar tables in following changes.
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 42d0c95..fe9c0e9
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/vdpau.c | 2 +-
libavcodec/version.h | 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..1bd1f48 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
where it currently is undefined for instance.
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do {
This is to avoid proliferation of similar tables in following changes.
---
libavcodec/h264_slice.c | 89 +++--
1 file changed, 35 insertions(+), 54 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 42d0c95..f20e017
/!\ DO NOT MERGE YET ! /!\ This depends on a pending libvdpau patch.
---
libavcodec/vdpau.h | 3 +++
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 3 +++
3 files changed, 25 insertions(+)
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1e891ed..ccb3352 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -125,6 +125,15 @@ int
---
libavcodec/vdpau.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 93b53dd..fd3ae62 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -264,45 +264,46 @@ int
---
avconv_vdpau.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/avconv_vdpau.c b/avconv_vdpau.c
index 37b50f6..5d7ef36 100644
--- a/avconv_vdpau.c
+++ b/avconv_vdpau.c
@@ -90,9 +90,14 @@ static int vdpau_get_buffer(AVCodecContext *s, AVFrame
*frame, int flags)
This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.
---
doc/APIchanges | 3 +++
libavcodec/avcodec.h | 6 ++
libavcodec/version.h | 2 +-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges
---
libavcodec/vdpau.c | 39 +++
libavcodec/vdpau_internal.h | 3 ++-
libavcodec/vdpau_mpeg12.c | 6 --
libavcodec/vdpau_mpeg4.c| 6 --
libavcodec/vdpau_vc1.c | 3 ++-
5 files changed, 43 insertions(+), 14 deletions(-)
diff
---
libavcodec/h264_slice.c | 6 +++---
libavcodec/vdpau_h264.c | 18 +-
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index f20e017..d9e296a 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@
Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.
Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed
Le 2014-12-10 17:57, Luca Barbato a écrit :
On 10/12/14 15:20, Rémi Denis-Courmont wrote:
---
libavcodec/vdpau.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
I think I gave it an Ok already.
So you did, but to my knowledge, I cannot push
Le 2014-12-10 18:11, Luca Barbato a écrit :
On 10/12/14 15:20, Rémi Denis-Courmont wrote:
/!\ DO NOT MERGE YET ! /!\ This depends on a pending libvdpau patch.
---
libavcodec/vdpau.h | 3 +++
libavcodec/vdpau_h264.c | 19 +++
libavcodec/vdpau_internal.h | 3
---
libavcodec/vdpau.c | 9 +
libavcodec/vdpau_h264.c | 4
2 files changed, 13 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1e891ed..ccb3352 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -125,6 +125,15 @@ int
---
libavcodec/vdpau.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 93b53dd..fd3ae62 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -264,45 +264,46 @@ int
---
libavcodec/vdpau.c | 3 +++
libavcodec/vdpau_h264.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index fd3ae62..1e891ed 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -291,6 +291,9 @@ do {
The application will destroy the underlying hardware handles when
get_format() gets called again. Also this ensures the deinitialization
takes place if the get_format callback returns an error.
Regression from 1c80c9d7ef809180042257200c7b5f6b81d0b0e2.
---
libavcodec/utils.c | 10 +-
1
.
--
Rémi Denis-Courmont
http://www.remlab.net/
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
The H.264 Constrained Baseline Profile (CBP) is a subset of both the
Main Profile and the Baseline Profile. In principles, a hardware
decoder that supports either of those can decode CBP content. As it
happens, Main is supported by all VDPAU drivers, and Baseline is not.
So favor map CBP to MP
This is the same as the previous change, but for applications using the
old API (such as VLC 2.2).
---
libavcodec/vdpau.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 1d68e70..93b53dd 100644
--- a/libavcodec/vdpau.c
+++
);
if (!final) {
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
sockaddr_storage));
-if (!source_addr)
+if (!source_addr) {
+freeaddrinfo(ai);
break;
+}
memcpy(source_addr, ai-ai_addr, ai-ai_addrlen);
freeaddrinfo(ai);
LGTM
--
Rémi Denis-Courmont
Currently, no flags are supported.
---
libavcodec/vdpau.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 44eef20..9805a8d 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -313,6 +313,9 @@ int av_vdpau_bind_context(AVCodecContext
Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.
Applications should obviously not set this
---
doc/APIchanges | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 48b0ac8..a8c8e2e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -13,7 +13,7 @@ libavutil: 2014-08-09
API changes, most recent first:
-2014-10-13 - xxx -
and cluttering the hwaccel abstraction with it?
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
);
+ff_url_join(tcpname, sizeof(tcpname), lower_rtsp_proto,
NULL,
+host, port, NULL);
if (ffurl_open(rt-rtsp_hd, tcpname, AVIO_FLAG_READ_WRITE,
s-interrupt_callback, NULL) 0) {
err = AVERROR(EIO);
--
Rémi Denis-Courmont
-initial_timeout *
1000);
if (ret = ffurl_open(rt-rtsp_hd, tcpname,
AVIO_FLAG_READ_WRITE,
--
Rémi Denis-Courmont
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
1 - 100 of 368 matches
Mail list logo
