Hi,
Please find the attached patches which add support to create multiple HLS
variant streams and master playlist.
Key advantages:
1. A single HLS encoder instance can handle multiple variant streams now.
Otherwise, a separate HLS encoder instance was needed for each variant stream.
So, no
On Tue, Oct 17, 2017 at 11:29 AM, Daniel Kucera wrote:
> transfer_func variable passed to retry_transfer_wrapper
> are h->prot->url_read and h->prot->url_write functions.
> These need to return EOF or other error properly.
> In case of returning >= 0, url_read/url_write is retried
> until error is
Am 21.10.17 um 00:30 schrieb Timo Rothenpieler:
> Am 20.10.2017 um 17:16 schrieb Thilo Borgmann:
>> Hi,
>>
Some guys at the VDD asked for FFmpeg T-shirts.
I'd like to do a new T-shirt order. The shirts could be given to
multimedia devs who stop at one of our next booths.
My
Hi,
On Fri, Oct 20, 2017, at 07:16 AM, Thilo Borgmann wrote:
> If there are no objections, I will order them and ship early next week :)
Can we use a color logo? You can use my non-gradient logo variant that I
made for the hypothetical shirts I was going to make but never did. I'll
attach the SVG
On Fri, 20 Oct 2017, Carl Eugen Hoyos wrote:
Hi!
I believe that the use-case is valid and there is definitely a bug
because no error is shown for too long filenames.
In addition, allocating 50k on the heap seems nicer than 4k on the stack.
50k is not much better than 4k. You should add an f
Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :
> I thought filenames in libavformat are limited to 1K anyway because of the
> AVFormatContext->filename field. So if your patch really fixes the ticket,
> then how? :)
Yes, exactly. This limitation was the reason I did not bother handli
Hi,
> On Fri, Oct 20, 2017, at 07:16 AM, Thilo Borgmann wrote:
>> If there are no objections, I will order them and ship early next week :)
>
> Can we use a color logo?
We can use another color for sure. I guess multicolor printings would raise the
price, though.
I will ask them about it.
>
> Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency
The commit message needs adjustment "lavfi/paletteuse: ..."
[...]
> struct color_node {
> -uint8_t val[3];
> +uint8_t val[4];
> uint8_t palette_id;
> int split;
> int left_id, right_id;
> @@ -86,6 +86,
Hello,
I split the previous patch for HAPQAlpha decoding
in several part, to be easier to read
0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
prepare for multi texture support but only decode the first texture
0003-libavcodec-hapdec-indent-after-previous-commit :
Cosmetic : indent
Hello,
in attach patch to fix comment in blockdsp
the dsp need align 32 now.
Martin
0001-libavcodec-blockdsp-fix-comment.-clear_block-need-32.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
Hello,
Sample can be found here
https://we.tl/1XuI6QJ7Ra
and need to be put inside ./fate-suite/hap
can be test with
make fate-hap SAMPLES=fate-suite/
Need to be apply after patch in discussion
libavcodec/hapdec : add support for hapqa decoding
Martin
0005-fate-hapdec-add-test-for-hapqa-deco
On 9/2/2017 1:23 PM, James Almer wrote:
> From: Vittorio Giovara
>
> This disables almost everything that was deprecated at least two years ago
>
> Readjust the minimum API version as needed, postponing any
> API-incompatible changes until the next bump.
>
> (cherry picked from commit 07a2b1559
On Sat, Oct 21, 2017, at 08:38 AM, Thilo Borgmann wrote:
> We can use another color for sure. I guess multicolor printings would
> raise the price, though.
I assume it will raise the price if it is screenprinted, but I'm not
sure by how much.
> Do you think this would actually look better?
Yes,
Hello,
I am interested in hiring someone to expand FFmpeg with a flag that changes the
behavior of channel ordering for as many audio codecs as possible. When this
flag is seen in the command line it has FFmpeg use slightly modified channel
order and channel assignment (TYPESCE instead of TYPE
This patchset removes the long-deprecated ffserver program and all
its privately exposed things from libavformat.
Rostislav Pehlivanov (6):
Remove the ffserver program
libavformat: remove the ffmenc and ffmdec muxer and demuxers
libavformat: unexpose the ff_inet_aton function
libavformat:
Used only by ffserver.
Signed-off-by: Rostislav Pehlivanov
---
Changelog| 1 +
libavformat/Makefile | 2 -
libavformat/allformats.c | 1 -
libavformat/ffm.h| 62
libavformat/ffmdec.c | 878 ---
libavformat/ff
Signed-off-by: Rostislav Pehlivanov
---
libavformat/libavformat.v | 9 -
1 file changed, 9 deletions(-)
diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 87401f7a9b..df28e15b0e 100644
--- a/libavformat/libavformat.v
+++ b/libavformat/libavformat.v
@@ -1,15 +1,6 @@
Signed-off-by: Rostislav Pehlivanov
---
libavformat/mpjpeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mpjpeg.c b/libavformat/mpjpeg.c
index 3904ccb2b4..80f83c5871 100644
--- a/libavformat/mpjpeg.c
+++ b/libavformat/mpjpeg.c
@@ -23,7 +23,7 @@
/* Multipart
Only used by ffserver
Signed-off-by: Rostislav Pehlivanov
---
libavformat/libavformat.v | 1 -
libavformat/rtpproto.c| 6 --
libavformat/rtpproto.h| 1 -
3 files changed, 8 deletions(-)
diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index 4edf52f45e..87401f7a9b 1
Used only by ffserver.
Signed-off-by: Rostislav Pehlivanov
---
libavformat/libavformat.v | 1 -
libavformat/network.h | 2 --
libavformat/os_support.c | 6 +++---
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavformat/libavformat.v b/libavformat/libavformat.v
index c961c
Just to understand this better:
The plan was to remove some fields from avcodec.h to have a reason
to remove a tool that has a large user base?
What kind of logic is that?
Shouldn't we communicate to our users that we like them?
Carl Eugen
___
ffmpeg-de
On 21 October 2017 at 20:04, Carl Eugen Hoyos wrote:
> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base?
>
> What kind of logic is that?
> Shouldn't we communicate to our users that we like them?
>
>
On 10/21/17, Carl Eugen Hoyos wrote:
> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base?
This is the Joke.
>
> What kind of logic is that?
Sane one, yours is flawed.
> Shouldn't we communicate to
On 10/21/17, Rostislav Pehlivanov wrote:
> This patchset removes the long-deprecated ffserver program and all
> its privately exposed things from libavformat.
>
> Rostislav Pehlivanov (6):
> Remove the ffserver program
> libavformat: remove the ffmenc and ffmdec muxer and demuxers
> libavfor
On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
> Just to understand this better:
> The plan was to remove some fields from avcodec.h to have a reason
> to remove a tool that has a large user base
The "plan" is to follow what was agreed a year and a half ago, then
confirmed with a vote last November
2017-10-21 21:12 GMT+02:00 James Almer :
> On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
>> Just to understand this better:
>> The plan was to remove some fields from avcodec.h to have a reason
>> to remove a tool that has a large user base
> The "plan" is to follow what was agreed a year and a ha
2017-03-01 23:36 GMT+01:00 Carl Eugen Hoyos :
> Attached patch silences one of three warnings when compiling
> bitstream_filter.o, I suspect this cast is necessary.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.or
On 10/21/2017 4:14 PM, Carl Eugen Hoyos wrote:
> 2017-10-21 21:12 GMT+02:00 James Almer :
>> On 10/21/2017 4:04 PM, Carl Eugen Hoyos wrote:
>>> Just to understand this better:
>>> The plan was to remove some fields from avcodec.h to have a reason
>>> to remove a tool that has a large user base
>> T
On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> This patchset removes the long-deprecated ffserver program and all
> its privately exposed things from libavformat.
>
> Rostislav Pehlivanov (6):
> Remove the ffserver program
> libavformat: remove the ffmenc and ffmdec muxer and demuxers
>
Hi!
Attached patch fixes a warning when compiling with sufficiently new gcc.
Please comment, Carl Eugen
From bdb2ad2bc45465675e9fff7313ae5f1b062ec3e1 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sat, 21 Oct 2017 20:55:01 +0200
Subject: [PATCH] lavc/avcodec: Constify the return value of
2017-10-21 19:35 GMT+02:00 Martin Vignali :
> Hello,
>
> I split the previous patch for HAPQAlpha decoding
> in several part, to be easier to read
>
> 0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
> prepare for multi texture support but only decode the first texture
>
> 0003-libavcode
2017-10-21 21:23 GMT+02:00 Carl Eugen Hoyos :
> 2017-10-21 19:35 GMT+02:00 Martin Vignali :
> > Hello,
> >
> > I split the previous patch for HAPQAlpha decoding
> > in several part, to be easier to read
> >
> > 0002-libavcodec-hapdec-reorganize-code-before-adding-mult :
> > prepare for multi textu
2017-10-21 18:40 GMT+02:00 Clément Bœsch :
> Aside from these nitpicks, I'm still concerned about how it's going
> to conflict with GIF encoding where the transparent color is actually
> used as a mean of not updating pixels from previous frames.
But is this really related to this patch?
I just t
2017-10-21 21:32 GMT+02:00 Martin Vignali :
> 2017-10-21 21:23 GMT+02:00 Carl Eugen Hoyos :
>
>> 2017-10-21 19:35 GMT+02:00 Martin Vignali :
>> > Hello,
>> >
>> > I split the previous patch for HAPQAlpha decoding
>> > in several part, to be easier to read
>> >
>> > 0002-libavcodec-hapdec-reorganize
On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
>
> > Aside from these nitpicks, I'm still concerned about how it's going
> > to conflict with GIF encoding where the transparent color is actually
> > used as a mean of not updating pixe
2017-10-21 21:43 GMT+02:00 Clément Bœsch :
> On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
>> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
>>
>> > Aside from these nitpicks, I'm still concerned about how it's going
>> > to conflict with GIF encoding where the transparent color is
Hello,
In attach patch to add AVX2 version for add_bytes
0001-libavcodec-lossless_videodsp-add-add_bytes-avx2-vers :
add AVX2 version
pass fate-test for me (os 10.12, x86_64)
checkasm result : (Kaby Lake) (run 10 times, and i took the fastest version)
checkasm: all 2 tests passed
add_bytes_c: 1
On Sat, Oct 21, 2017 at 09:47:47PM +0200, Carl Eugen Hoyos wrote:
> 2017-10-21 21:43 GMT+02:00 Clément Bœsch :
> > On Sat, Oct 21, 2017 at 09:37:06PM +0200, Carl Eugen Hoyos wrote:
> >> 2017-10-21 18:40 GMT+02:00 Clément Bœsch :
> >>
> >> > Aside from these nitpicks, I'm still concerned about how i
2017-10-21 18:29 GMT+02:00 Nicolas George :
> Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :
>> I thought filenames in libavformat are limited to 1K anyway
>> because of the AVFormatContext->filename field.
How can I reproduce this?
I tested the data from the ticket from the command
2017-10-21 1:28 GMT+02:00 James Almer :
> Could you look at ticket #6714 while at it? (And others also potentially
> related to edit lists).
https://trac.ffmpeg.org/query?status=new&status=open&keywords=~edts
Carl Eugen
___
ffmpeg-devel mailing list
ff
Hi,
On Sat, Oct 21, 2017 at 1:30 PM, Martin Vignali
wrote:
> Hello,
>
> in attach patch to fix comment in blockdsp
>
> the dsp need align 32 now.
>
lgtm.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/
On Sat, 21 Oct 2017, Carl Eugen Hoyos wrote:
2017-10-21 18:29 GMT+02:00 Nicolas George :
Le decadi 30 vendémiaire, an CCXXVI, Marton Balint a écrit :
I thought filenames in libavformat are limited to 1K anyway
because of the AVFormatContext->filename field.
How can I reproduce this?
I test
Hello,
In attach patch to add avx2 version for huffyuv dsp and huffyuvdsp enc
for add_int16 and diff_int16 func
Check asm result for add_int16 (Kaby Lake, os 10.12)
add_int16_128_c: 1607.9
add_int16_128_sse2: 442.7
add_int16_128_avx2: 218.9
Pass fate test for me
0001-checkasm-add-test-for-huff
Hi!
On redirection to https, FFmpeg only shows "protocol missing" without
a hint to what is missing.
Please comment, Carl Eugen
From 8c068d06fa425471590a8ee8765ef510476a180d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 22 Oct 2017 01:11:55 +0200
Subject: [PATCH] lavf/avio: Print th
add padding before scantable arrays
See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a
Signed-off-by: Michael Niedermayer
---
libavcodec/h264dec.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/h264dec.h b/libavcodec/h264dec.h
index 2106ba077e..de8b7c38b9 100644
--- a/libavcodec/h264
Signed-off-by: Michael Niedermayer
---
tests/fate-run.sh | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index e8d2e67709..05f4ca5e20 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -127,15 +127,15 @@ f
Signed-off-by: Michael Niedermayer
---
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_opt.c | 16
2 files changed, 17 insertions(+)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 888f77223a..cb912d95e4 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -161,6 +161,7 @@
Hi!
Attached patch silences the many warnings shown when decoding streams
with DolbyVision content.
Please comment, Carl Eugen
From d917eb3470b957fe17d8b708957567fdfa9dbdaa Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Sun, 22 Oct 2017 02:17:27 +0200
Subject: [PATCH] lavc/hevcdec: Silenc
This is different from FF_API_VISMV which is supported through codecview.
Signed-off-by: Michael Niedermayer
---
libavcodec/version.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 8584bb7006..25696690d7 100644
--- a/libavcod
On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
> > This patchset removes the long-deprecated ffserver program and all
> > its privately exposed things from libavformat.
> >
> > Rostislav Pehlivanov (6):
> > Remove the ffserver pr
Hi,
On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer wrote:
> This is different from FF_API_VISMV which is supported through codecview.
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/version.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ve
On 10/21/2017 9:55 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 04:15:37PM -0300, James Almer wrote:
>> On 10/21/2017 3:54 PM, Rostislav Pehlivanov wrote:
>>> This patchset removes the long-deprecated ffserver program and all
>>> its privately exposed things from libavformat.
>>>
>>> Ro
On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer > wrote:
>
> > This is different from FF_API_VISMV which is supported through codecview.
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/version.h
On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer >> wrote:
>>
>>> This is different from FF_API_VISMV which is supported through codecview.
>>>
>>> Signed-off-by:
On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
> > On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
> >> Hi,
> >>
> >> On Sat, Oct 21, 2017 at 8:37 PM, Michael Niedermayer
> >> >>> wrote:
> >>
> >>> This is differ
On 10/21/2017 11:03 PM, Michael Niedermayer wrote:
> On Sat, Oct 21, 2017 at 10:30:45PM -0300, James Almer wrote:
>> On 10/21/2017 10:23 PM, Michael Niedermayer wrote:
>>> On Sat, Oct 21, 2017 at 08:52:26PM -0400, Ronald S. Bultje wrote:
Hi,
On Sat, Oct 21, 2017 at 8:37 PM, Michael N
56 matches
Mail list logo
