unpack_2ch is already using sse float ops only, and pack_2ch is a trivial
change.
Rename both to float_to_float for consistency.
Signed-off-by: James Almer jamr...@gmail.com
---
libswresample/x86/audio_convert.asm| 14 --
libswresample/x86/audio_convert_init.c | 11 +++
On 2015/1/11 0:44, Michael Niedermayer wrote:
* PGP Signed by an unknown key
On Sat, Jan 10, 2015 at 05:30:03PM +0100, Timo Rothenpieler wrote:
Looks good to merge for me.
i wanted to apply it but the patch is corrupted
Applying: avcodec/nvenc: fix dtspts when b frame = 1
fatal: corrupt
On Wed, Jan 14, 2015 at 01:35:14AM +, Zhao, Halley wrote:
Thanks your explanation.
1. I know our team/Intel plan to maintain this lib for the following years.
I'm a developer, I can't promise more.
will someone also maintain the libyami wraper code from this
patch ?
If so the patch should
On 12 Jan, Ronald S. Bultje wrote :
- how long will it take us to implement these features ourselves?
What features?
--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
On 14 Jan, Zhao, Halley wrote :
1. I know our team/Intel plan to maintain this lib for the following years.
I'm a developer, I can't promise more.
Many people have made such claims and backtracked in the end.
2. as to libxyz, it is some way like investment: Nobody is sure of the
future,
On 12 Jan, Zhao, Halley wrote :
Maintaining decoders is the point of this project.
Yes, I agree the core of ffmpeg is codec;
But, from the user, ffmpeg is usually treated as a light-weight media
framework. Being a media framework, it is good to leverage hw codec in many
cases.
FFmpeg
From: Zhao, Halley halley.z...@intel.com
- do not support multi-thread decoding, it is unnecessary for hw
- create a decode thread to interface with yami decoding, decouple
frame in and out
- the output frame type (raw data | drm handle | dmabuf) are specified
in avctx-coder during init
-
From: Zhao, Halley halley.z...@intel.com
libyami is a core codec library to support hw acceleration basing on vaapi:
https://github.com/01org/libyami
this patch add h264dec basing on libyami, similar to the solution basing on
libstagefright.
moreover, it supports dma_buf and other frame mode,
From: Zhao, Halley halley.z...@intel.com
add possible C++ based library dependency
add multiple packages dependency for one component
add h264dec basing on libyami
---
configure | 78 --
libavcodec/Makefile| 1 +
On 12 Jan, Zhao, Halley wrote :
to be honest, libyami is core codec library for vaapi (especially on Intel
platform).
FFmpeg already accesses vaapi directly. Adding a library in the middle
is just making everything slower...
With my kindest regards,
--
Jean-Baptiste Kempf
Hi Stephen,
On Tue, 13 Jan 2015 08:26:10 -0500
Stephen Hutchinson qyo...@gmail.com wrote:
On general principle, the idea would be nice. I'll leave broader
critiques on the code to others, but I do have one thing to say:
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index
Hi Michael,
On Mon, 12 Jan 2015 22:57:35 +0100
Michael Niedermayer michae...@gmx.at wrote:
On Mon, Jan 12, 2015 at 06:59:33PM +0100, Marc Giger wrote:
Hi,
Attached is a preliminary patch that enables runtime loading of
external libraries via dlopen and friends. Dynamic loading is a
Le quartidi 24 nivôse, an CCXXIII, Michael Bradshaw a écrit :
In the encoding/decoding example[1], in the video_encode_example()
function, av_opt_set() is used to set the option preset to slow (here,
c is a AVCodecContext*):
av_opt_set(c-priv_data, preset, slow, 0);
I presume this is
On Tue, Jan 13, 2015 at 02:47:47PM +0100, wm4 wrote:
If refdata was NULL, the memcpy() ended up copying the same memory
block onto itself, which is not only pointless, but also undefined
behavior.
---
Someone spotted the issue in valgrind output.
---
libavcodec/qpeg.c | 13 +++--
In the encoding/decoding example[1], in the video_encode_example()
function, av_opt_set() is used to set the option preset to slow (here,
c is a AVCodecContext*):
av_opt_set(c-priv_data, preset, slow, 0);
I presume this is wrong to use priv_data, and instead the codec context
should be
Thanks for your valued comments, I followed them in updated patch set.
+config_buffer.profile = VAProfileNone;
+status = s-decoder-start(config_buffer);
+if (status != DECODE_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, yami h264 decoder fail to start\n);
+return -1;
Thanks your explanation.
1. I know our team/Intel plan to maintain this lib for the following years. I'm
a developer, I can't promise more.
2. as to libxyz, it is some way like investment: Nobody is sure of the future,
but make decision basing on investment and profit.
A small yami wrapper
On 01/13/2015 04:30 PM, Nicolas George wrote:
Le quartidi 24 nivôse, an CCXXIII, Anshul a écrit :
Please find attachment.
Using this people can also mux cc608 stream in nut muxer
IIRC, you need to submit a patch to libnut before, because it holds the
official list of codes.
Who maintains
Hi
Please find attachment.
Using this people can also mux cc608 stream in nut muxer
-Anshul
From 996a1d20061e9c966b02c07d98096b1a87fdff10 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date: Fri, 2 Jan 2015 13:20:13 +0530
Subject: [PATCH 2/2] Added codec tag in nut
Hi
I have attached the patch.
Thanks
Anshul Maheshwari
From eacd2356796ae927c500afdca15c040a2318415b Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari anshul.ffm...@gmail.com
Date: Tue, 13 Jan 2015 16:18:16 +0530
Subject: [PATCH] webvtt in hls muxer
Signed-off-by: Anshul Maheshwari
Le quartidi 24 nivôse, an CCXXIII, Anshul a écrit :
Please find attachment.
Using this people can also mux cc608 stream in nut muxer
IIRC, you need to submit a patch to libnut before, because it holds the
official list of codes.
Regards,
--
Nicolas George
signature.asc
Description:
On date Saturday 2015-01-10 01:46:38 +0530, Arwa Arif encoded:
On Fri, Jan 9, 2015 at 10:07 PM, Stefano Sabatini stefa...@gmail.com
[...]
From 2367adb44a62e67427f0de5af8047a0008f3b0f8 Mon Sep 17 00:00:00 2001
From: Arwa Arif arwaarif1...@gmail.com
Date: Sat, 10 Jan 2015 01:21:14 +0530
If refdata was NULL, the memcpy() ended up copying the same memory
block onto itself, which is not only pointless, but also undefined
behavior.
---
Someone spotted the issue in valgrind output.
---
libavcodec/qpeg.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git
Hi Everyone,
Hope you all will be fine and doing great.
I am currently working on manipulating RTSP Streaming URL
Programatically, but I am not getting able to do at all. I actually want to
capture Streams from RTSP URL at run time and want to convert to some
format (.wav, .mp4 ...
On Tue, Jan 13, 2015 at 12:00:36PM +0100, Nicolas George wrote:
Le quartidi 24 nivôse, an CCXXIII, Anshul a écrit :
Please find attachment.
Using this people can also mux cc608 stream in nut muxer
IIRC, you need to submit a patch to libnut before, because it holds the
official list of
On general principle, the idea would be nice. I'll leave broader critiques on
the code to others, but I do have one thing to say:
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1ec5cae..2520e69 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -69,6 +69,25 @@
#include
On Mon, 12 Jan 2015 18:59:33 +0100
Marc Giger gigerst...@gmx.ch wrote:
Hi,
Attached is a preliminary patch that enables runtime loading of external
libraries via dlopen and friends. Dynamic loading is a build time option
(--enable-dynamic-loading) and if it is not activated the libs are
On 13 January 2015 at 14:54, wm4 nfx...@googlemail.com wrote:
On Mon, 12 Jan 2015 18:59:33 +0100
Marc Giger gigerst...@gmx.ch wrote:
Hi,
Attached is a preliminary patch that enables runtime loading of external
libraries via dlopen and friends. Dynamic loading is a build time option
28 matches
Mail list logo
