Pushed.
>On 5/7/18, 6:47 PM, "vdi...@akamai.com" wrote:
>
>From: Vishwanath Dixit
>
>HMS is formatted as HH:MM:SS.mmm, but, HH part is not limited to
>24 hours. For example, the the drawn text may look like this:
>243029:20:30.342. To present the timestamp in more readable and
>user friendly
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Monday, June 4, 2018 7:20 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavfi: add opencl tonemap filter.
>
> On 29/05/18 06:54, Ruiling Song
Signed-off-by: Zhong Li
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2172901..78f450d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -219,7 +219,7 @@ Codecs:
ptx.c Ivo van Poorten
qcelp*
Hi
Actually this is the same patch as before but master has been fixed s.t.
enabling arm inline asm no longer breaks it:
I believe there is a bug in the arm feature detection for inline asm in
configure and I have a patch for it.
Currently using a command line like:
./configure
On Mon, Jun 04, 2018 at 12:43:41PM +0200, Hendrik Leppkes wrote:
> On Mon, Jun 4, 2018 at 12:16 PM, Thomas Volkert wrote:
> >
> > On 04.06.2018 04:55, Steven Liu wrote:
> >> Signed-off-by: Steven Liu
> >> ---
> >> configure| 1 -
> >> libavformat/hlsenc.c | 27
2018-06-04 18:16 GMT+08:00 Thomas Volkert :
>
> On 04.06.2018 04:55, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> configure| 1 -
>> libavformat/hlsenc.c | 27 ---
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git a/configure
On Mon, Jun 04, 2018 at 12:16:36PM +0200, Thomas Volkert wrote:
>
> On 04.06.2018 04:55, Steven Liu wrote:
> > Signed-off-by: Steven Liu
> > ---
> > configure| 1 -
> > libavformat/hlsenc.c | 27 ---
> > 2 files changed, 12 insertions(+), 16 deletions(-)
> >
[Fixed the reply order for you, please try to avoid top-posting.]
On Mon, Jun 04, 2018 at 15:26:11 +0530, Robert Clove wrote:
> On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson <
> steinar+ffm...@gunderson.no> wrote:
> > Maybe you can replay the raw packets with tcpreplay?
> Thats what i cant
Thats what i cant do, i am using the windows platform
On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson <
steinar+ffm...@gunderson.no> wrote:
> On Mon, Jun 04, 2018 at 01:57:36PM +0530, Robert Clove wrote:
> > ohk, then what should i do to convert RTP packets to H.264.
> > But what i know is
On 04.06.2018 04:55, Steven Liu wrote:
> Signed-off-by: Steven Liu
> ---
> configure| 1 -
> libavformat/hlsenc.c | 27 ---
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/configure b/configure
> index 22eeca22a5..a3d0f5837a 100755
>
On 27.05.2018 17:20, Ricardo Constantino wrote:
> On 26 May 2018 at 19:42, Reino Wijnsma wrote:
>
>> On 23-5-2018 2:11, Reino Wijnsma wrote:
>>> On 22-4-2018 14:47, Thomas Volkert wrote:
+enabled mbedtls && { check_pkg_config mbedtls mbedtls
>> mbedtls/x509_crt.h
On Mon, Jun 04, 2018 at 01:57:36PM +0530, Robert Clove wrote:
> ohk, then what should i do to convert RTP packets to H.264.
> But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy
> stream.264 we get the output file as h.264 then why not ffmpeg will be able
> to convert packet from
On 6/1/18, Robert Clove wrote:
> Hi FFMPEG people,
>
> i have a raw dump of RTP packets and want to convert it to .h264, can it be
> done via ffmpeg or needs some development ?
This can not be done with ffmpeg.
___
ffmpeg-devel mailing list
> The patch also fixes SSL0014.rcv, the only sample in this directory
> that still doesn't decode bit-exact is SSL0015.rcv, I don't know if the
> issue is also loopfilter-related.
>
> Thank you, Carl Eugen
Could someone with access to the test files check the output of the
Intel hardware decoder
On 22.05.2018 00:47, James Almer wrote:
> On 5/21/2018 11:15 AM, James Almer wrote:
>> On 5/21/2018 8:27 AM, Thomas Volkert wrote:
>>> Hi,
>>>
>>> On 14.05.2018 19:04, Dave Gregory wrote:
Hi all,
[..comparison with alternative TLS implementations..]
>>> Ping.
>>>
>>> I still
ohk, then what should i do to convert RTP packets to H.264.
But what i know is if i do ffmpeg -i rtp://stream -an -vcodec copy
stream.264 we get the output file as h.264 then why not ffmpeg will be able
to convert packet from file to H.264
On Mon, Jun 4, 2018 at 1:28 PM, Paul B Mahol wrote:
>
On Mon, Jun 4, 2018 at 12:16 PM, Thomas Volkert wrote:
>
> On 04.06.2018 04:55, Steven Liu wrote:
>> Signed-off-by: Steven Liu
>> ---
>> configure| 1 -
>> libavformat/hlsenc.c | 27 ---
>> 2 files changed, 12 insertions(+), 16 deletions(-)
>>
>> diff --git
Hello,
How are you all?
We are looking to use the atempo filter for our audio files. However, the limit
between 0.5 - 2x is too restrictive for us. We would like to expand the limit
to 0.5x - 3x.
I tried changing the range in atempo.c and the rest of the tempo filter just
worked.
Do you
Also remove the callback from the context, and add proper error handling.
Signed-off-by: Marton Balint
---
libavdevice/decklink_common.h | 1 -
libavdevice/decklink_dec.cpp | 35 ++-
2 files changed, 14 insertions(+), 22 deletions(-)
diff --git
On Sun, May 06, 2018 at 10:38:59PM +0530, vdi...@akamai.com wrote:
> From: Vishwanath Dixit
>
> Forced key frames generation functionality was assuming the first PTS
> value as zero, but, when 'copyts' is enabled, the first PTS can be any
> big number. This was eventually forcing all the frames
---
libavutil/frame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 00215ac29a..deb9b6f334 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -819,7 +819,7 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType
Hi!
I'm trying to transcode H.264 Stream to HEVC. Everything just working
fine when I'm using the in-built CPU decoder, but when I turn on the
Hardware-accelerated CUVID module, it throws some error with most of my
streams.
*
**FFMPEG CMDLINE: *
/root/bin/ffmpeg -hwaccel cuvid -c:v
2018-06-03 17:05 GMT-03:00 Pedro Arthur :
> 2018-06-03 16:55 GMT-03:00 Sergey Lavrushkin :
>>> My concern is when we add more models, currently we have to store 2
>>> models, one for the "native" implementation and one for the TF
>>> backend.
>>> There is also the case were one wants to update the
The default memory allocator is limited in the max number of frames available,
and therefore caused frame drops if the frames were not freed fast enough.
Signed-off-by: Marton Balint
---
libavdevice/decklink_dec.cpp | 50
1 file changed, 50
2018-06-04 23:07 GMT+02:00, Jacob Trimble :
> On Mon, Jun 4, 2018 at 10:46 AM Carl Eugen Hoyos wrote:
>>
>> 2018-06-04 18:59 GMT+02:00, Jacob Trimble
>> :
>> > On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
>> > wrote:
>> >>
>> >> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble
On Sun, Jun 03, 2018 at 02:44:45AM +0200, Michael Niedermayer wrote:
> This restructures the code slightly toward D_UTIL_dec_synthesis()
>
> Fixes:
> 7420/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AMRWB_fuzzer-6577305112543232
>
> Found-by: continuous fuzzing process
>
On Mon, Jun 4, 2018 at 10:46 AM Carl Eugen Hoyos wrote:
>
> 2018-06-04 18:59 GMT+02:00, Jacob Trimble :
> > On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
> > wrote:
> >>
> >> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
> >> > Found by Chrome's ClusterFuzz:
friendly ping. thx.
On Thu, May 31, 2018 at 4:26 PM Sasi Inguva wrote:
> Pls find attached, the correctly signed patch
> Thanks.
>
> On Thu, May 31, 2018 at 4:14 PM Sasi Inguva wrote:
>
>> Sorry. Forgot to attach the file. Pls find it attached. Also resending
>> the patch signed with correct
2018-05-29 14:26 GMT+02:00, Jerome Borsboom :
> Out-of-bounds reference pixel replication should take into account the frame
> coding mode of the reference frame(s), not the frame coding mode of the
> current frame.
>
> Signed-off-by: Jerome Borsboom
> ---
> Even more corrections. The starting
On 6/4/2018 11:18 AM, Jun Zhao wrote:
> move the the function init_tables() definitions from header file
> to .c file to fix make checkheaders.
What compile flags are you using? checkheaders seems to work just fine
on a normal build.
On 04.06.2018 15:38, Michael Niedermayer wrote:
> On Mon, Jun 04, 2018 at 12:16:36PM +0200, Thomas Volkert wrote:
>> On 04.06.2018 04:55, Steven Liu wrote:
>>> Signed-off-by: Steven Liu
>>> ---
>>> configure| 1 -
>>> libavformat/hlsenc.c | 27 ---
>>> 2
For chapter images, the mov demux produces streams with disposition set
to attached_pic+timed_thumbnails. This patch fixes to properly recognize
streams that should be encoded as cover image (ones with only and only
attached_pic disposition set).
Signed-off-by: Timo Teräs
---
> ffmpeg should act
On 06/04/2018 12:09 PM, Ronak wrote:
Hello,
How are you all?
We are looking to use the atempo filter for our audio files. However, the limit
between 0.5 - 2x is too restrictive for us. We would like to expand the limit
to 0.5x - 3x.
I tried changing the range in atempo.c and the rest of the
On 06/04/2018 08:35 PM, Ronak Patel wrote:
Thanks. Is it okay if I push a patch for this? How high of a limit does the
algorithm support today?
I don't think there is an upper limit... Post a patch here for review. See
http://www.ffmpeg.org/developer.html#Submitting-patches-1
Pavel.
Thanks. Is it okay if I push a patch for this? How high of a limit does the
algorithm support today?
Sent from my iPhone
> On Jun 4, 2018, at 8:00 PM, Pavel Koshevoy wrote:
>
>> On 06/04/2018 12:09 PM, Ronak wrote:
>> Hello,
>>
>> How are you all?
>>
>> We are looking to use the atempo
We did consider rubberband, but the audio quality is too poor. The audio has
echo artifacts in it that makes it sound robotic.
Sent from my iPhone
> On Jun 4, 2018, at 8:32 PM, Lou Logan wrote:
>
>> On Mon, Jun 4, 2018, at 10:09 AM, Ronak wrote:
>>
>> We are looking to use the atempo filter
On Mon, Jun 4, 2018, at 10:09 AM, Ronak wrote:
>
> We are looking to use the atempo filter for our audio files. However,
> the limit between 0.5 - 2x is too restrictive for us. We would like to
> expand the limit to 0.5x - 3x.
Consider using the rubberband filter instead if atempo is too simple
2018-06-04 22:52 GMT+08:00 James Almer :
> On 6/4/2018 11:18 AM, Jun Zhao wrote:
>> move the the function init_tables() definitions from header file
>> to .c file to fix make checkheaders.
>
> What compile flags are you using? checkheaders seems to work just fine
> on a normal build.
>
Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in type
'int'
Fixes:
8024/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SHORTEN_fuzzer-5109204648984576
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: 32768 + 2147450880 cannot be represented in
type 'int'
Fixes:
7885/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THP_fuzzer-5298834394578944
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by:
Fixes: signed integer overflow: 1077952576 + 1077952576 cannot be represented
in type 'int'
Fixes:
7712/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5056281753681920
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
wrote:
>
> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
> >
> > Signed-off-by: Jacob Trimble
> > ---
> > libavutil/encryption_info.c | 7 +--
> > 1 file changed,
move the the function init_tables() definitions from header file
to .c file to fix make checkheaders.
Signed-off-by: Jun Zhao
---
libavcodec/dolby_e.c | 87
libavcodec/dolby_e.h | 86 ---
2
move the the function aacsbr_tableinit definition from header file
to .c file to fix make checkheaders
Signed-off-by: Jun Zhao
---
libavcodec/aacsbr_tablegen_common.h | 12
libavcodec/aacsbr_template.c| 12
2 files changed, 12 insertions(+), 12 deletions(-)
On 6/4/2018 8:15 AM, Thomas Volkert wrote:
>
>
> On 22.05.2018 00:47, James Almer wrote:
>> On 5/21/2018 11:15 AM, James Almer wrote:
>>> On 5/21/2018 8:27 AM, Thomas Volkert wrote:
Hi,
On 14.05.2018 19:04, Dave Gregory wrote:
> Hi all,
>
> [..comparison with
On Mon, Jun 4, 2018 at 5:12 PM, Moritz Barsnick wrote:
> [Fixed the reply order for you, please try to avoid top-posting.]
>
> On Mon, Jun 04, 2018 at 15:26:11 +0530, Robert Clove wrote:
> > On Mon, Jun 4, 2018 at 2:22 PM, Steinar H. Gunderson <
> > steinar+ffm...@gunderson.no> wrote:
> > >
On Fri, 1 Jun 2018, Dave Rice wrote:
On May 31, 2018, at 5:29 PM, Marton Balint wrote:
On Thu, 31 May 2018, Jonathan Morley wrote:
Thank you for the clarification, Dave. It might be that the Blackmagic approach
to collecting timecode doesn’t work for that one source because it is in
2018-06-04 18:59 GMT+02:00, Jacob Trimble :
> On Fri, Jun 1, 2018 at 5:03 PM Michael Niedermayer
> wrote:
>>
>> On Thu, May 31, 2018 at 09:33:36AM -0700, Jacob Trimble wrote:
>> > Found by Chrome's ClusterFuzz: http://crbug.com/846662.
>> >
>> > Signed-off-by: Jacob Trimble
>> > ---
>> >
> On Jun 4, 2018, at 12:24 PM, Marton Balint wrote:
>
> On Fri, 1 Jun 2018, Dave Rice wrote:
>
>>> On May 31, 2018, at 5:29 PM, Marton Balint wrote:
>>> On Thu, 31 May 2018, Jonathan Morley wrote:
Thank you for the clarification, Dave. It might be that the Blackmagic
approach to
49 matches
Mail list logo
