On Tue, 17 Jan 2017 22:31:48 +
Mark Thompson wrote:
> Previously it was only created if the decode hwaccel was requested;
> this makes it unconditionally so we can use it without the hwaccel.
> ---
> ffmpeg.h | 4 +---
> ffmpeg_opt.c | 13 -
> ffmpeg_qsv.c | 14 ++---
On Tue, 17 Jan 2017 22:32:15 +
Mark Thompson wrote:
> ---
> ffmpeg.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 6d1e358..781c0a4 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -2748,6 +2748,12 @@ static int init_input_stream(int ist_ind
On 1/18/17, Tobias Rapp wrote:
> On 17.01.2017 20:43, Paul B Mahol wrote:
>> Signed-off-by: Dave Rice
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi| 70
>> libavfilter/Makefile| 1 +
>> libavfilter/allfilters.c| 1 +
>> libavfilter/vf_readei
On 1/18/17, Kieran Kunhya wrote:
> On Tue, 17 Jan 2017, 22:31 Paul B Mahol, wrote:
>
>> On 1/17/17, Kieran Kunhya wrote:
>> > On Tue, 17 Jan 2017 at 19:44 Paul B Mahol wrote:
>> >
>> >> Signed-off-by: Dave Rice
>> >> Signed-off-by: Paul B Mahol
>> >>
>> >
>> > Is this better than libzvbi?
>>
On 17.01.2017 19:10, Michael Niedermayer wrote:
On Tue, Jan 17, 2017 at 02:44:28PM +0100, Tobias Rapp wrote:
On 13.01.2017 17:42, Michael Niedermayer wrote:
On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote:
On 10.01.2017 00:19, Michael Niedermayer wrote:
[...]
isnt it better to war
Changes since version 1:
Added suggested output stream duration hinting. Uses output stream duration
and bitrate as a hint for better filesize guessing. If stream bitrate is
unknown a worst-case value is assumed.
Changes since version 2:
Removed the patch which changes avi muxer to fail
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.
If the option is omitted or zero the index size is estimated from output
duration and bitrate. A worst-case bitrate fo
Signed-off-by: Tobias Rapp
---
ffmpeg.c | 9 +
libavformat/avformat.h | 3 +++
2 files changed, 12 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 6d1e358..977708c 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -2908,6 +2908,10 @@ static int init_output_stream_streamcopy(Outp
Signed-off-by: Tobias Rapp
---
doc/muxers.texi | 33 +
1 file changed, 33 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 26a8f2d..4372078 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -57,6 +57,39 @@ fragmentation or muxer overhead depe
Discards edit list with duration equals to 0 for video streams with only
one frame and avoid discarding covers art muxed as a single frame video
stream.
---
Hello,
The following patch discards single edit list with duration equals to 0 for
video streams with only one frame which prevents discardi
Seems like a good idea to run the full set of capability checks only on
the device that's actually about to be used.
The only issue I see is that if a system has a bunch of different GPUs,
of which some don't support the required capabilities, one might get
unexpected results with the device indice
0001-PATCH-avformat-caf-add-aacl-codec-tag.diff
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
L'octidi 28 nivôse, an CCXXV, Michael Niedermayer a écrit :
> instructions to reproduce the issue or a stack trace would make it
> easier for interrested people to fix this
>
> i can guess that maybe buf is NULL but thats just a guess
Yes, it happens when flirting with OOM, when OOM happens in on
On Tue, Jan 17, 2017 at 08:36:14PM +0100, Michael Niedermayer wrote:
> On Tue, Jan 17, 2017 at 10:50:31AM +0100, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > ---
> > libavcodec/h264dec.c | 70
> > +++-
> > 1 file changed, 37 insertions(+),
---
libavcodec/h264_slice.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index fe71d57421..ad7a75fa2e 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -254,25 +254,15 @@ fail:
retur
On Wed, 18 Jan 2017 at 08:40 Paul B Mahol wrote:
> On 1/18/17, Kieran Kunhya wrote:
> > On Tue, 17 Jan 2017, 22:31 Paul B Mahol, wrote:
> >
> >> On 1/17/17, Kieran Kunhya wrote:
> >> > On Tue, 17 Jan 2017 at 19:44 Paul B Mahol wrote:
> >> >
> >> >> Signed-off-by: Dave Rice
> >> >> Signed-off
2017-01-18 19:38 GMT+09:00 Matthieu Bouron :
> Discards edit list with duration equals to 0 for video streams with only
> one frame and avoid discarding covers art muxed as a single frame video
> stream.
> ---
> Hello,
>
> The following patch discards single edit list with duration equals to 0
> f
On 1/18/17, Piotr Bandurski wrote:
>
>
Have samples?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
---
libavcodec/aarch64/vp9dsp_init_aarch64.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/libavcodec/aarch64/vp9dsp_init_aarch64
This work is sponsored by, and copyright, Google.
This is similar to the arm version, but due to the larger registers
on aarch64, we can do 8 pixels at a time for all filter sizes.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
ARM AArch6
This work is sponsored by, and copyright, Google.
The plain pixel put/copy functions are used from the 8 bit version,
for the double size (e.g. put16 uses ff_vp9_copy32_neon), and a new
copy128 is added.
Compared with the 8 bit version, the filters can no longer use the
trick to accumulate in 16
This work is sponsored by, and copyright, Google.
This is structured similarly to the 8 bit version. In the 8 bit
version, the coefficients are 16 bits, and intermediates are 32 bits.
Here, the coefficients are 32 bit. For the 4x4 transforms for 10 bit
content, the intermediates also fit in 32 bi
This work is sponsored by, and copyright, Google.
This has mostly got the same differences to the 8 bit version as
in the arm version. For the horizontal filters, we do 16 pixels
in parallel as well. For the 8 pixel wide vertical filters, we can
accumulate 4 rows before storing, just as in the 8 b
This work is sponsored by, and copyright, Google.
Compared to the arm version, on aarch64 we can keep the full 8x8
transform in registers, and for 16x16 and 32x32, we can process
it in slices of 4 pixels instead of 2.
Examples of runtimes vs the 32 bit version, on a Cortex A53:
This work is sponsored by, and copyright, Google.
This is more in line with how it will be extended for more bitdepths.
---
libavcodec/arm/vp9dsp_init_arm.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/libavcodec/arm/vp9dsp_init_arm.c b/libavcodec/
This work is sponsored by, and copyright, Google.
This is pretty much similar to the 8 bpp version, but in some senses
simpler. All input pixels are 16 bits, and all intermediates also fit
in 16 bits, so there's no lengthening/narrowing in the filter at all.
For the full 16 pixel wide filter, we
Made this into a patch:
https://github.com/BtbN/FFmpeg/commit/cbd128a67fc4621c953419dddc5cc17612764a57
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2017-01-17 14:28 GMT+08:00 Steven Liu :
> when push hls to http server, the old segemnts can not delete by hls
> formats.
> so add the http option into hls_delete_old_segments
>
> Reported-by: Yin Jiaoyuan
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 17 +++--
> 1 file
2017-01-18 6:24 GMT+08:00 Steven Liu :
> add line_spacing parameter to set the space between two lines
>
> Based on an idea by: Leandro Santiago
> Reviewed-by: Michael Niedermayer
> Signed-off-by: Steven Liu
> ---
> doc/filters.texi | 4
> libavfilter/vf_drawtext.c | 4 +++-
> 2
Hi, > Have samples? Yes: www.megafileupload.com www.megafileupload.com
Regards
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 1/19/17, Piotr Bandurski wrote:
> Hi, > Have samples? Yes: www.megafileupload.com
> www.megafileupload.com Regards
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
Your mailer is b
On 1/18/17, Piotr Bandurski wrote:
>
>
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Jan 18, 2017 at 10:18:36AM +0100, Tobias Rapp wrote:
> On 17.01.2017 19:10, Michael Niedermayer wrote:
> >On Tue, Jan 17, 2017 at 02:44:28PM +0100, Tobias Rapp wrote:
> >>On 13.01.2017 17:42, Michael Niedermayer wrote:
> >>>On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote:
>
On Thu, Jan 19, 2017 at 12:44:38AM +0100, Paul B Mahol wrote:
> ffmpeg | branch: master | Paul B Mahol | Tue Jan 17
> 15:54:57 2017 +0100| [6c43f33ac2e7606b2013f6261144389589394196] | committer:
> Paul B Mahol
>
> avcodec/wmaprodec: >2 channel support for XMA
>
> Signed-off-by: Paul B Mahol
>
I test this patch, I found it show below log info and ffmpeg term auto.
av_interleaved_write_frame(): Too many open files
No more output streams to write to, finishing.
I think it is not OK.
Yin Jiaoyuan
At 2017-01-19 07:08:08, "Steven Liu" wrote:
>2017-01-17 14:28 GMT+08:00 Steven Liu :
>
>
On Wed, Jan 18, 2017 at 06:13:02PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/h264_slice.c | 16 +++-
> 1 file changed, 3 insertions(+), 13 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I k
On Tue, Jan 17, 2017 at 02:39:18PM +0100, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp
> ---
> ffmpeg.c | 9 +
> libavformat/avformat.h | 3 +++
> 2 files changed, 12 insertions(+)
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040
On Thu, Jan 19, 2017 at 12:35:28AM +0100, Paul B Mahol wrote:
> On 1/18/17, Piotr Bandurski wrote:
> >
>
> >
>
> LGTM
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -
2017-01-19 9:35 GMT+08:00 殷焦元 :
> I test this patch, I found it show below log info and ffmpeg term auto.
>
> av_interleaved_write_frame(): Too many open files
> No more output streams to write to, finishing.
>
> I think it is not OK.
> Yin Jiaoyuan
>
ok , i wll make a new patch to file the too m
When use http method to delete the old segments,
there is only io_open, hove not io_close yet,
this patch is used to fix it
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1f4bf8b..85d3955
I test the new patch, it is OK.
Thanks
Yin Jiaoyuan
At 2017-01-19 10:20:38, "Steven Liu" wrote:
>When use http method to delete the old segments,
>there is only io_open, hove not io_close yet,
>this patch is used to fix it
>
>Signed-off-by: Steven Liu
>---
> libavformat/hlsenc.c | 2 ++
> 1 f
On 17.01.2017 14:39, Tobias Rapp wrote:
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.
If the option is omitted or zero the index size is estimated from output
dur
On 17.01.2017 14:39, Tobias Rapp wrote:
OpenDML specification v1.02 states that entries of a master index chunk
shall point to standard or field index chunks.
Changed incorrect duration of last master index entry to -1 in case it
points to another master index.
Propagate error when index write
43 matches
Mail list logo
