On 6/16/2017 9:36 PM, Marton Balint wrote:
>
> On Fri, 16 Jun 2017, James Almer wrote:
>
>> On 6/16/2017 8:24 PM, Marton Balint wrote:
>>> The md5 protocol has no seek support, but some tests use seeks. This
>>> changes
>>> the fate tests to actually create the output files and calculate the
>>>
On Fri, 16 Jun 2017, James Almer wrote:
On 6/16/2017 8:24 PM, Marton Balint wrote:
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent
On 6/16/2017 8:24 PM, Marton Balint wrote:
> The md5 protocol has no seek support, but some tests use seeks. This changes
> the fate tests to actually create the output files and calculate the md5 on
> the
> written files, which also makes the tests independent of the size of the
> output
> buffe
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent of the size of the output
buffers and output buffering in general.
Signed-off-by: Marto
Signed-off-by: Marton Balint
---
libavformat/rmenc.c | 19 ---
1 file changed, 8 insertions(+), 11 deletions(-)
diff --git a/libavformat/rmenc.c b/libavformat/rmenc.c
index f9821d1875..3bff4daf0a 100644
--- a/libavformat/rmenc.c
+++ b/libavformat/rmenc.c
@@ -72,14 +72,12 @@ stati
On 6/3/2017 2:39 PM, James Almer wrote:
> On 5/28/2017 5:09 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavformat/oggenc.c | 32
>> 1 file changed, 28 insertions(+), 4 deletions(-)
>>
>
> Ping for this and the aiff one.
>
> I have a set of a
On Sun, 4 Jun 2017, Marton Balint wrote:
It is a huge performance improvement for encoding files with small packets
(e.g. wav) over SMB/CIFS.
Ping? Maybe enabling this unconditionally is also problematic for
protocols other than file? If that so, then how about making flush_packet
a tri st
On Fri, 16 Jun 2017 21:53:22 +0200
wm4 wrote:
> On Fri, 16 Jun 2017 20:31:14 +0200
> Timo Rothenpieler wrote:
>
> > Am 16.06.2017 um 16:41 schrieb Philip Langdale:
> > > This is mechanically simple, but does the fact that additional
> > > command line arguments have to be used to get the same
On 6/11/2017 2:47 PM, James Almer wrote:
> Fixes ticket #6413
>
> Signed-off-by: James Almer
> ---
> The public key authentication also tries to use the password variable. I
> don't know if NULL is valid in that case or not.
> Perhaps for that one it would be better to replace the current usage o
> Anyway, I don't understand why this makes subtitle lines actually
> disappear?
Because SubRip format does not allow to have empty lines, that is:
1. Subtitle text itself on one or more lines
2. A blank line containing no text, indicating the end of this subtitle
So, when we have '\n' at
On 2017-06-16 20:31, Michael Niedermayer wrote:
> On Thu, Jun 15, 2017 at 03:34:21PM +0200, James Darnley wrote:
>> ---
>> tests/fate/video.mak | 3 +++
>> tests/ref/fate/idct-simpleauto | 27 +++
>> 2 files changed, 30 insertions(+)
>> create mode 100644 tests/
On Fri, 16 Jun 2017 21:30:44 +0300
Evgeny Shulgin wrote:
> Info about this patch:
>
> Working with one video, I noticed that ffmpeg incorrectly extracts out
> subtitles. Some subtitles have disappeared.
> I have a video file as Matroska (.mkv) container, subtitles are there in
> the SubRip (.srt
On Wed, 07 Jun 2017 23:37:40 -0800
Lou Logan wrote:
> LGTM, but I can't push anything until after June 15.
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, 16 Jun 2017 20:31:14 +0200
Timo Rothenpieler wrote:
> Am 16.06.2017 um 16:41 schrieb Philip Langdale:
> > This is mechanically simple, but does the fact that additional command line
> > arguments have to be used to get the same results count as a compatibility
> > break? Do we need to fix
On Thu, Jun 15, 2017 at 03:34:21PM +0200, James Darnley wrote:
> ---
> tests/fate/video.mak | 3 +++
> tests/ref/fate/idct-simpleauto | 27 +++
> 2 files changed, 30 insertions(+)
> create mode 100644 tests/ref/fate/idct-simpleauto
fails on ARM
TESTidct-si
Am 16.06.2017 um 16:41 schrieb Philip Langdale:
This is mechanically simple, but does the fact that additional command line
arguments have to be used to get the same results count as a compatibility
break? Do we need to fix that before we can actually make this change?
I'd consider that as a br
Info about this patch:
Working with one video, I noticed that ffmpeg incorrectly extracts out
subtitles. Some subtitles have disappeared.
I have a video file as Matroska (.mkv) container, subtitles are there in
the SubRip (.srt) format.
Output of `ffmpeg`: https://pastebin.com/raw/vyiMNFbe
Output
We can have a certain number of newline characters at the very beginning
of the subtitles. We must skip them to get the correct result.
---
libavcodec/htmlsubtitles.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index 16295da..b144a
On 2017-06-16 17:48, Michael Niedermayer wrote:
> On Fri, Jun 16, 2017 at 03:53:28PM +0200, James Darnley wrote:
>> ---
>> libavcodec/x86/mpegvideoenc_template.c | 47
>> +-
>> 1 file changed, 46 insertions(+), 1 deletion(-)
>
> Are these 2 with the other patchset
On Fri, Jun 09, 2017 at 06:47:52PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 2143315325 + 4186162 cannot be
> represented in type 'int'
> Fixes: 2134/clusterfuzz-testcase-minimized-4619258405322752
>
> Found-by: continuous fuzzing process
> https://github
On Fri, Jun 09, 2017 at 03:14:12AM +0200, Michael Niedermayer wrote:
> Fixes OOM
> Fixes: 2131/clusterfuzz-testcase-minimized-4718045157130240
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> l
On Thu, Jun 15, 2017 at 03:50:31PM -0400, Ronald S. Bultje wrote:
> From: Anton Mitrofanov
>
> Use the correct ctxIdxInc calculation for coded_block_flag.
> Keep old behavior for old versions of x264 for backward compatibility.
>
> Signed-off-by: Ronald S. Bultje
> ---
> libavcodec/h264_cabac.
On Fri, Jun 16, 2017 at 03:53:27PM +0200, James Darnley wrote:
> ---
> libavcodec/x86/mpegvideoenc_template.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/x86/mpegvideoenc_template.c
> b/libavcodec/x86/mpegvideoenc_template.c
> index b2512744ca..3ce7
On Fri, Jun 16, 2017 at 03:53:28PM +0200, James Darnley wrote:
> ---
> libavcodec/x86/mpegvideoenc_template.c | 47
> +-
> 1 file changed, 46 insertions(+), 1 deletion(-)
Are these 2 with the other patchset intended to give exactly the same
output ?
for example:
On 05.06.2017 19:16, Marton Balint wrote:
Another huge performance improvement when using SMB/CIFS as output.
Signed-off-by: Marton Balint
---
libavformat/file.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/file.c b/libavformat/file.c
index 264542a36a..ae7231a484 100644
With generic hwaccel, it is additionally necessary to specify the
output format. If this is not done, we'll end up downloading the
frames back and then re-uploading them.
For example:
ffmpeg -y -hwaccel cuvid -hwaccel_output_format cuda \
-c:v h264_cuvid -i sample.mp4 \
-c:v h264_nv
This is mechanically simple, but does the fact that additional command line
arguments have to be used to get the same results count as a compatibility
break? Do we need to fix that before we can actually make this change?
Philip Langdale (1):
ffmpeg: Switch cuvid to generic hwaccel
Makefile
On 16 May 2017 at 19:50, James Darnley wrote:
> On 2017-05-16 13:08, Rostislav Pehlivanov wrote:
> > Reduces the amount of debugging information of external asm from
> > uselessly verbose to informative enough.
> > ---
> > configure | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
Le 16/06/2017 à 16:04, wm4 a écrit :
On Fri, 16 Jun 2017 15:43:51 +0200
21na...@gmail.com wrote:
Le 16/06/2017 à 14:25, wm4 a écrit :
On Fri, 16 Jun 2017 13:51:20 +0200
21na...@gmail.com wrote:
Le 16/06/2017 à 12:55, wm4 a écrit :
On Fri, 16 Jun 2017 02:32:10 +0200
21na...@gmail.com wrote
On Fri, 16 Jun 2017 15:43:51 +0200
21na...@gmail.com wrote:
> Le 16/06/2017 à 14:25, wm4 a écrit :
> > On Fri, 16 Jun 2017 13:51:20 +0200
> > 21na...@gmail.com wrote:
> >
> >> Le 16/06/2017 à 12:55, wm4 a écrit :
> >>> On Fri, 16 Jun 2017 02:32:10 +0200
> >>> 21na...@gmail.com wrote:
> >>>
---
libavcodec/x86/mpegvideoenc_template.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/mpegvideoenc_template.c
b/libavcodec/x86/mpegvideoenc_template.c
index b2512744ca..3ce72e1367 100644
--- a/libavcodec/x86/mpegvideoenc_template.c
+++ b/libavcodec/x
---
libavcodec/x86/mpegvideoenc_template.c | 47 +-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/mpegvideoenc_template.c
b/libavcodec/x86/mpegvideoenc_template.c
index 3ce72e1367..1201be514b 100644
--- a/libavcodec/x86/mpegvideoenc_t
Le 16/06/2017 à 14:25, wm4 a écrit :
On Fri, 16 Jun 2017 13:51:20 +0200
21na...@gmail.com wrote:
Le 16/06/2017 à 12:55, wm4 a écrit :
On Fri, 16 Jun 2017 02:32:10 +0200
21na...@gmail.com wrote:
Hello,
I would like to know why the tag “DURATION” in Matroska files (.mkv) is
a necessity?
On Fri, Jun 16, 2017 at 12:09:27PM +0200, James Darnley wrote:
> On 2017-06-16 03:58, Michael Niedermayer wrote:
> > On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote:
> >> Includes add/put functions
> >>
> >> Rounding contributed by Ronald S. Bultje
> >> ---
> >> I must be stupid. I d
On Fri, 16 Jun 2017 13:51:20 +0200
21na...@gmail.com wrote:
> Le 16/06/2017 à 12:55, wm4 a écrit :
> > On Fri, 16 Jun 2017 02:32:10 +0200
> > 21na...@gmail.com wrote:
> >
> >> Hello,
> >>
> >>
> >> I would like to know why the tag “DURATION” in Matroska files (.mkv) is
> >> a necessity? Even mkv
Le 16/06/2017 à 12:55, wm4 a écrit :
On Fri, 16 Jun 2017 02:32:10 +0200
21na...@gmail.com wrote:
Hello,
I would like to know why the tag “DURATION” in Matroska files (.mkv) is
a necessity? Even mkvmerge lets the choice to use it or not with
“--enable-durations”, in addition it is written “Wri
Signed-off-by: DongHoon Kang
---
libavcodec/htmlsubtitles.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
tags in srt and sami subtitles don't need to be in lowercase.
diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index 16295daa0c..94430f7345 100644
On 2017-06-16 12:48, Paul B Mahol wrote:
> On 6/16/17, James Darnley wrote:
>> On 2017-06-16 03:58, Michael Niedermayer wrote:
>>> theres something wrong with this
>>> it totally breaks this:
>>> make -j12 ffmpeg && ./ffmpeg -ss 1 -i cache:matrixbench_mpeg2.mpg -t 2 -y
>>> test.avi
>>> ./ffplay te
On Fri, 16 Jun 2017 02:32:10 +0200
21na...@gmail.com wrote:
> Hello,
>
>
> I would like to know why the tag “DURATION” in Matroska files (.mkv) is
> a necessity? Even mkvmerge lets the choice to use it or not with
> “--enable-durations”, in addition it is written “Write durations for all
> bl
On 6/16/17, James Darnley wrote:
> On 2017-06-16 03:58, Michael Niedermayer wrote:
>> On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote:
>>> Includes add/put functions
>>>
>>> Rounding contributed by Ronald S. Bultje
>>> ---
>>> I must be stupid. I dropped the stack space change somew
On 2017-06-16 03:58, Michael Niedermayer wrote:
> On Thu, Jun 15, 2017 at 05:08:33PM +0200, James Darnley wrote:
>> Includes add/put functions
>>
>> Rounding contributed by Ronald S. Bultje
>> ---
>> I must be stupid. I dropped the stack space change somewhere.
>>
>> libavcodec/tests/x86/dct.c
41 matches
Mail list logo
