On Wed, Jul 6, 2016 at 3:41 PM, Mark Reid wrote:
> ---
> libavcodec/dnxhddec.c | 3 +++
> libavformat/movenc.c | 19 ++-
> 2 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index 1808080..b310e3e 100644
> --- a/lib
On Fri, Jul 1, 2016 at 3:03 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google@ffmpeg.org> wrote:
>
>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S.
Hi,
Apologies for resending - gmail sent the first attempt as a binary attachment.
This patch starts the work on SCTE-35 support; for now it just detects
SCTE-35 and if present sends the data to a dummy function. Since it's
my first contribution to ffmpeg I preferred to start small and
continue w
Hi,
This is an update for the TrueHD encoder gsoc project. Any input from the
community about work done till now, or for plans ahead, is most welcome :)
The MLP encoder (patch attached) works without any lossless check errors now on
most samples I've tested on, both for mono and stereo.
Here's
RFC 5334 recommendens this extension to go alongside the video/ogg
mimetype for video files, with or without audio and subtitles [1].
[1] https://tools.ietf.org/html/rfc5334#section-10.2
Signed-off-by: James Almer
---
TODO: Version bump and changelog entry.
configure| 1 +
lib
While not enforced, RFC 5334[1] recommends to use the .oga extension
for all audio codecs except Vorbis (.ogg) and Speex (.spx)
RFC 7845[2] also adds Opus (.opus) to this list.
[1] https://tools.ietf.org/html/rfc5334#section-10.3
[2] https://tools.ietf.org/html/rfc7845#section-9
Signed-off-by: J
While not enforced, RFC 5334 mentions that the .ogg extension should
be used for Vorbis audio files only.
Signed-off-by: James Almer
---
This patch turns the ogg muxer into an audio only muxer to follow
the RFC's recommendation. The next patch in the set adds a new ogv
muxer to properly deal with
RFC 5334 states that the application/ogg mimetype must include an
Ogg Skeleton stream[1], something we don't currently support.
[1] https://tools.ietf.org/html/rfc5334#section-10.1
Signed-off-by: James Almer
---
libavformat/oggenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --
As the subject says, this patchset aims to make our Ogg muxer more
compliant with the latest RFC[1], which is almost eight years old
by now.
[1] https://tools.ietf.org/html/rfc5334
James Almer (4):
avformat/oggenc: make flac the default for oga muxer
avformat/oggenc: use audio/ogg mimetype fo
2016-07-07 3:54 GMT+08:00 Michael Niedermayer :
> On Wed, Jul 06, 2016 at 05:57:57PM +0800, Steven Liu wrote:
> > support split hls segment at duration set by hls_time
> >
> > after the patch , the ffmpeg can split the mpegts for hls by hls_time
> > parameter
> >
> > [root@localhost ffmpeg]# ./ffm
---
libavcodec/dnxhddec.c | 3 +++
libavformat/movenc.c | 19 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index 1808080..b310e3e 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -204,6 +204,9 @
Hi,
This patch starts the work on SCTE-35 support; for now it just detects
SCTE-35 and if present sends the data to a dummy function. Since it's
my first contribution to ffmpeg I preferred to start small and
continue working as small pieces of work are accepted or commented.
Carlos
0001-SCTE-ex
Hi,
This version drops the need for profiles completely. Muxing also
works of 12bit formats as well.
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/lb_uhd.mxf
https://dl.dropboxusercontent.com/u/170952/ffmpeg_samples/mxf/UHD/hqx_uhd.mxf
ffmpeg -i lb_uhd.mxf -vcodec copy out.mov
On Wed, Jul 6, 2016 at 2:31 AM, Rostislav Pehlivanov
wrote:
> On 6 July 2016 at 03:46, Mark Reid wrote:
>
>> ---
>> libavcodec/avcodec.h| 7 +++
>> libavcodec/codec_desc.c | 1 +
>> libavcodec/dnxhddec.c | 20
>> libavcodec/profiles.c | 10 ++
>> libavc
On Wed, Jul 06, 2016 at 09:12:54PM +0200, Paul B Mahol wrote:
> On 7/5/16, Martin Vignali wrote:
> > 2016-06-28 0:05 GMT+02:00 Martin Vignali :
> >
> >> Hello,
> >>
> >> in attach a patch to add support for Y and YA exr file
> >> (ticket #5621)
> >>
> >> sample can be found in this ticket,
> >> ht
Hi all
The next Outreachy round starts soon
FFmpeg has till august 22 IIUC (https://www.gnome.org/outreachy/)
to express interrest to participate.
We need an admin and backup admins.
They need to create the wiki page(s) for this round, and make sure
the pages are in shape by the time applicants s
On Wed, Jul 06, 2016 at 03:01:00PM +0200, Paul B Mahol wrote:
> On 7/5/16, Burt P. wrote:
> > Attached is the fourth version of this patch. I've reworked it
> > a bit to make it cleaner and provide more interesting/useful
> > information. Also, I've updated the documentation.
> > This includes the
On Wed, Jul 06, 2016 at 05:57:57PM +0800, Steven Liu wrote:
> support split hls segment at duration set by hls_time
>
> after the patch , the ffmpeg can split the mpegts for hls by hls_time
> parameter
>
> [root@localhost ffmpeg]# ./ffmpeg -i /root/facebook.mp4 -v quiet -c copy -f
> hls -hls_time
On 7/5/16, Martin Vignali wrote:
> 2016-06-28 0:05 GMT+02:00 Martin Vignali :
>
>> Hello,
>>
>> in attach a patch to add support for Y and YA exr file
>> (ticket #5621)
>>
>> sample can be found in this ticket,
>> https://trac.ffmpeg.org/ticket/5621
>>
>> or in the official samples
>>
>> http://do
On Wed, 6 Jul 2016 15:03:07 +0200, Hendrik Leppkes wrote:
> http://ffmpeg.org/developer.html#Submitting-patches
Also see:
http://ffmpeg.org/git-howto.html
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
On Thursday 12 May 2016 05:40:36 pm Derek Buitenhuis wrote:
> On 5/12/2016 4:18 PM, Carl Eugen Hoyos wrote:
> > The feature is not new (and the necessary define in the header
> > was always there) but it did not work (at least for some
> > revisions).
> > How should I proceed?
>
> Hmm.
>
> I'm not
Hi,
On Wed, Jul 6, 2016 at 10:14 AM, Ronald S. Bultje
wrote:
> +v_rslt += vec_sl(vec_splats((int)32), v_opr1);
>> +v_rslt += vec_sl(vec_splats((int)1), v_opr2);
>>
>
> vec_splats outside loop.
>
While we're at it, is the += SIMD'ed? And why aren't v_opr1/2 merged in a
si
Hi,
ok, so let's review your implementation of rgb24toY:
On Tue, Jul 5, 2016 at 10:37 PM, Dan Parrot wrote:
> +static void rgb24ToY_c_vsx(uint8_t *_dst, const uint8_t *src, const
> uint8_t *unused1, const uint8_t *unused2,
> + int width, uint32_t *rgb2yuv)
> +{
> +//ST
On 06/07/16 13:28, Dan Parrot wrote:
> On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote:
>> On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote:
>>> Finish providing SIMD versions for POWER8 VSX of functions in
>>> libswscale/input.c That should allow trac ticket #5570 to be closed.
>>> The
Hi,
On Tue, Jul 5, 2016 at 10:37 PM, Dan Parrot wrote:
> rgb24ToY_c 0.92
OK, so let's be data-driven from now on, I really don't like this
name-calling and stuff. Your speedup on average is close to 1, so let's
compare this to x86. I ran this patch:
diff --git a/libswscale/hscale
On Tue, Jul 05, 2016 at 09:47:51AM +0200, Benoit Fouet wrote:
> Hi,
>
> On 04/07/2016 10:12, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > H264ParamSets has its SPS/PPS stored raw (SODB) and needs to be
> > converted to NAL units before sending them to MediaCodec.
> >
> > This patch
On 06 Jul, Ganesh Ajjanagadde wrote :
> > A custom script is not a common build system tool.
>
> How configure.ac that gets fed into autotools etc is acceptable and configure
> is not is beyond me.
> As for their meaning, I don't know.
Ask them. But, even if your configure is good, it's not a c
06.07.2016, 08:51, "Jean-Baptiste Kempf" :
> On 06 Jul, Ganesh Ajjanagadde wrote :
>> > But, you could at least be a bit more truthful when filling it:
>> > - the buildsystem is not common tools, since you have your own
>> > configure (it's a SUGGESTED thing anyway)
>>
>> As far as I
On Wed, Jul 6, 2016 at 2:55 PM, Mike Lieman wrote:
> Is there a FAQ or other documentation on how to submit patches? There's a
> compiler warning that's driving me nuts and I'd like to clean it up if I
> can.
>
http://ffmpeg.org/developer.html#Submitting-patches
Its really not all that complica
On 7/5/16, Burt P. wrote:
> Attached is the fourth version of this patch. I've reworked it
> a bit to make it cleaner and provide more interesting/useful
> information. Also, I've updated the documentation.
> This includes the fix to low-level gain adjustment.
>
> Thanks.
>
lgtm
_
On Wed, Jul 6, 2016 at 2:51 PM, Jean-Baptiste Kempf wrote:
> On 06 Jul, Ganesh Ajjanagadde wrote :
>> > But, you could at least be a bit more truthful when filling it:
>> > - the buildsystem is not common tools, since you have your own
>> >configure (it's a SUGGESTED thing anyway)
>>
>> As fa
Is there a FAQ or other documentation on how to submit patches? There's a
compiler warning that's driving me nuts and I'd like to clean it up if I
can.
Thank you,
Mike
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listi
On Wed, Jul 06, 2016 at 07:28:27AM -0500, Dan Parrot wrote:
[...]
> > Also, one further thought:
> > From the commit message, it sounds like you might only be doing this
> > for the bounty in #5570, do you plan to maintain these optimizations
> > in the future?
>
> Unless you are a mind reader, ST
On 06 Jul, Ganesh Ajjanagadde wrote :
> > But, you could at least be a bit more truthful when filling it:
> > - the buildsystem is not common tools, since you have your own
> > configure (it's a SUGGESTED thing anyway)
>
> As far as I know, shell script is a common tool available on POSIX plat
On Wed, 2016-07-06 at 09:07 +0200, Hendrik Leppkes wrote:
> On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote:
> > Finish providing SIMD versions for POWER8 VSX of functions in
> > libswscale/input.c That should allow trac ticket #5570 to be closed.
> > The speedups obtained for the functions are:
06.07.2016, 07:48, "Jean-Baptiste Kempf" :
> On 04 Jul, Ganesh Ajjanagadde wrote :
>> https://bestpractices.coreinfrastructure.org/.
>
> Tbh, this is pure BS/PR, as we've seen for VLC. But why not...
>
> But, you could at least be a bit more truthful when filling it:
> - the buildsystem is not
On Wed, Jul 06, 2016 at 07:18:08AM -0400, Ganesh Ajjanagadde wrote:
> 06.07.2016, 04:03, "Carl Eugen Hoyos" :
> > Ganesh Ajjanagadde mit.edu> writes:
> >
> >> > No question, it would be better if tests would be added quicker ...
> >>
> >> I do not doubt this, but at the moment we do not enforce
On 04 Jul, Ganesh Ajjanagadde wrote :
> https://bestpractices.coreinfrastructure.org/.
Tbh, this is pure BS/PR, as we've seen for VLC. But why not...
But, you could at least be a bit more truthful when filling it:
- the buildsystem is not common tools, since you have your own
configure (it's
06.07.2016, 04:03, "Carl Eugen Hoyos" :
> Ganesh Ajjanagadde mit.edu> writes:
>
>> > No question, it would be better if tests would be added quicker ...
>>
>> I do not doubt this, but at the moment we do not enforce it.
>> Do you see any trouble in enforcing this requirement from
>> major rele
support split hls segment at duration set by hls_time
after the patch , the ffmpeg can split the mpegts for hls by hls_time
parameter
[root@localhost ffmpeg]# ./ffmpeg -i /root/facebook.mp4 -v quiet -c copy -f
hls -hls_time 3 -hls_flags split_by_time -bsf:v h264_mp4toannexb
-hls_list_size 20 -t 3
On 6 July 2016 at 03:46, Mark Reid wrote:
> ---
> libavcodec/avcodec.h| 7 +++
> libavcodec/codec_desc.c | 1 +
> libavcodec/dnxhddec.c | 20
> libavcodec/profiles.c | 10 ++
> libavcodec/profiles.h | 1 +
> 5 files changed, 39 insertions(+)
>
> diff
Michael Niedermayer niedermayer.cc> writes:
> thus i do not think this point is about any gurantees or future
So I misunderstood.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-de
On Wed, Jul 06, 2016 at 08:02:55AM +, Carl Eugen Hoyos wrote:
> Ganesh Ajjanagadde mit.edu> writes:
>
> > > No question, it would be better if tests would be added quicker ...
> >
> > I do not doubt this, but at the moment we do not enforce it.
> > Do you see any trouble in enforcing this re
existing API functions like ff_qsv_init_internal_session /
ff_qsv_close_internal_session are private to libavcodec and are not exported
(since they are ff_ prefixed)
first attempt was to move API functions from libavcodec to libavutil, but it
was rejected and instead it was suggested to use exis
> On 06 Jul 2016, at 15:48, Hendrik Leppkes wrote:
>
> On Wed, Jul 6, 2016 at 9:08 AM, nablet developer wrote:
>> add hwcontext_qsv (Intel QuickSync Video) implementation
>> basically it's adapted patch from libav
>> (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html)
>
> If
On Wed, Jul 6, 2016 at 9:08 AM, nablet developer wrote:
> add hwcontext_qsv (Intel QuickSync Video) implementation
> basically it's adapted patch from libav
> (https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html)
If you take a patch from libav, you need to maintain proper authorsh
nablet developer nablet.com> writes:
> hwcontext_qsv is needed for VPP filter (which cannot use API
> functions from libavcodec)
Why not?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Ganesh Ajjanagadde mit.edu> writes:
> > No question, it would be better if tests would be added quicker ...
>
> I do not doubt this, but at the moment we do not enforce it.
> Do you see any trouble in enforcing this requirement from
> major release to next major release?
I am against adding su
add hwcontext_qsv (Intel QuickSync Video) implementation
basically it's adapted patch from libav
(https://lists.libav.org/pipermail/libav-devel/2016-May/077126.html)
hwcontext_qsv is needed for VPP filter (which cannot use API functions from
libavcodec)
nablet developer (1):
hwcontext: add a Q
Signed-off-by: nablet developer
---
libavutil/Makefile | 3 +
libavutil/hwcontext.c | 3 +
libavutil/hwcontext.h | 1 +
libavutil/hwcontext_internal.h | 1 +
libavutil/hwcontext_qsv.c | 791 +
libavutil/hwcontext_q
On Wed, Jul 6, 2016 at 4:37 AM, Dan Parrot wrote:
> Finish providing SIMD versions for POWER8 VSX of functions in
> libswscale/input.c That should allow trac ticket #5570 to be closed.
> The speedups obtained for the functions are:
>
> abgrToA_c 1.19
> bgr24ToUV_c 1.23
>
51 matches
Mail list logo
