[FFmpeg-devel] [PATCH] lavf/tcp: return EOF on read, but not 0

[Takayuki 'January June' Suwa]

related to commit '858db4b01fa2b55ee55056c033054ca54ac9b0fd'.

---
 libavformat/tcp.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 07b4ed9..5438122 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -220,7 +220,12 @@ static int tcp_read(URLContext *h, uint8_t *buf, int size)
 return ret;
 }
 ret = recv(s->fd, buf, size, 0);
-return ret < 0 ? ff_neterrno() : ret;
+if (ret < 0)
+return ff_neterrno();
+else if (ret == 0)
+return AVERROR_EOF;
+else
+return ret;
 }
 
 static int tcp_write(URLContext *h, const uint8_t *buf, int size)
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] When both edit list and start padding present, take maximum.

[Michael Niedermayer]

On Wed, Oct 18, 2017 at 04:23:04PM -0700, Sasi Inguva wrote:
> Patch LGTM. Thanks.

will apply

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc: drop support for OpenJPEG 1.3-2.0

[Michael Bradshaw]

On Wed, Oct 18, 2017 at 8:21 PM, Michael Bradshaw <
mjbshaw-at-google@ffmpeg.org> wrote:
>
> Updated patch attached (which contains James Almer's suggestion for the
> -DOPJ_STATIC fix; thanks, James!).


Patch pushed. Thanks, all. Please let me know if anyone hits any snags due
to this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/h263dec.c: Duplicate the last decoded frame when xvid marks the packet as skipped.

[Michael Niedermayer]

On Thu, Oct 19, 2017 at 04:20:48PM -0700, Thierry Foucu wrote:
> On Thu, Oct 19, 2017 at 3:43 PM, Michael Niedermayer  > wrote:
> 
> > On Thu, Oct 19, 2017 at 09:51:05AM -0700, Thierry Foucu wrote:
> > > Instead of returning nothing when we detect the xvid skipped frame, we
> > > could return the last decoded frame, if we do have one.
> >
> > FRAME_SKIPPED is not limited to xvid (packed frames). There are a few
> > other pathes that return it.
> >
> >
> What if i change the test to check for mpeg4 video codec, something like
> 
>  if (ret == FRAME_SKIPPED) {
> +if (CONFIG_MPEG4_DECODER && actvx->codec_id == AV_CODEC_ID_MPEG4
> && s->next_picture_ptr) {
> +if ((ret = av_frame_ref(pict, s->next_picture_ptr->f)) < 0) {
> +return ret;
> +}
> +*got_frame = 1;
> +}
>  return get_consumed_bytes(s, buf_size);
> +}
> 
> or should i do something specific for xvid bug? I could return another
> value for the xvid (packed frames)  here
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/mpeg4videodec.c#L2590
> 
> and check for it instead of the frame_skipped.

FRAME_SKIPPED is returned in several cases

* vop not coded
 Your code seems correct for this but a testcase would be very usefull
 to confirm this
 It would be more ideal to limit this to the case where the last frame
 differs from the returned frame. As outputting no frame is cheaper
 than outputing a repeated frame

* some xvid/divx specific cases
 I dont know what is correct here

* some error conditions
 Your code is probably not optimal in some cases here

* skiped frames in i263
 your patch shouldnt lead to wrong output but it would slow the code
 down by having to handle more frames


> 
> For standard mpeg4video, outputing the next frame smells like violating
> > the spec.
> >
> >

> i'm not output the next frame, i'm output the last decoded frame

i dont think thats the case with B frames.
next/last are the reference frames for B frames, If the last is a B
frame it should not be in there.
What your code does seems to match what the standard mpeg4 wants for
vop_coded = 0 though. (this would make your code a bugfix for a case
i think i have never seen, vop_coded = 0 with b frames)



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[James Almer]

On 10/19/2017 12:12 AM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c   | 16 +++-
>  tests/fate/mov.mak  |  6 ++-
>  tests/ref/fate/mov-invalid-elst-entry-count | 57 
> +
>  3 files changed, 76 insertions(+), 3 deletions(-)
>  create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b22a116140..8d2602c739 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4596,7 +4596,7 @@ free_and_return:
>  static int mov_read_elst(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  MOVStreamContext *sc;
> -int i, edit_count, version;
> +int i, edit_count, version, elst_entry_size;
>  
>  if (c->fc->nb_streams < 1 || c->ignore_editlist)
>  return 0;
> @@ -4605,6 +4605,15 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  version = avio_r8(pb); /* version */
>  avio_rb24(pb); /* flags */
>  edit_count = avio_rb32(pb); /* entries */
> +atom.size -= 8;
> +
> +elst_entry_size = version == 1 ? 20 :  12;
> +if (atom.size != edit_count * elst_entry_size &&
> +c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
> +av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d for 
> elst atom of size: %"PRId64" bytes.\n",
> +   edit_count, atom.size + 8);
> +return AVERROR_INVALIDDATA;
> +}
>  
>  if (!edit_count)
>  return 0;
> @@ -4617,17 +4626,20 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return AVERROR(ENOMEM);
>  
>  av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n", 
> c->fc->nb_streams - 1, edit_count);
> -for (i = 0; i < edit_count && !pb->eof_reached; i++) {
> +for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached; i++) {
>  MOVElst *e = >elst_data[i];
>  
>  if (version == 1) {
>  e->duration = avio_rb64(pb);
>  e->time = avio_rb64(pb);
> +atom.size -= 16;
>  } else {
>  e->duration = avio_rb32(pb); /* segment duration */
>  e->time = (int32_t)avio_rb32(pb); /* media time */
> +atom.size -= 8;
>  }
>  e->rate = avio_rb32(pb) / 65536.0;
> +atom.size -= 4;
>  av_log(c->fc, AV_LOG_TRACE, "duration=%"PRId64" time=%"PRId64" 
> rate=%f\n",
> e->duration, e->time, e->rate);
>  
> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
> index cfdada7a2e..012e6f61b7 100644
> --- a/tests/fate/mov.mak
> +++ b/tests/fate/mov.mak
> @@ -6,7 +6,8 @@ FATE_MOV = fate-mov-3elist \
> fate-mov-1elist-ends-last-bframe \
> fate-mov-2elist-elist1-ends-bframe \
> fate-mov-3elist-encrypted \
> -   fate-mov-gpmf-remux \
> +fate-mov-invalid-elst-entry-count \
> +fate-mov-gpmf-remux \

Don't use tabs.

Could you look at ticket #6714 while at it? (And others also potentially
related to edit lists).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[Michael Niedermayer]

On Wed, Oct 18, 2017 at 08:12:50PM -0700, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c   | 16 +++-
>  tests/fate/mov.mak  |  6 ++-
>  tests/ref/fate/mov-invalid-elst-entry-count | 57 
> +
>  3 files changed, 76 insertions(+), 3 deletions(-)
>  create mode 100644 tests/ref/fate/mov-invalid-elst-entry-count
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index b22a116140..8d2602c739 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4596,7 +4596,7 @@ free_and_return:
>  static int mov_read_elst(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  MOVStreamContext *sc;
> -int i, edit_count, version;
> +int i, edit_count, version, elst_entry_size;
>  
>  if (c->fc->nb_streams < 1 || c->ignore_editlist)
>  return 0;
> @@ -4605,6 +4605,15 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  version = avio_r8(pb); /* version */
>  avio_rb24(pb); /* flags */
>  edit_count = avio_rb32(pb); /* entries */

> +atom.size -= 8;

> +
> +elst_entry_size = version == 1 ? 20 :  12;
> +if (atom.size != edit_count * elst_entry_size &&

the edit_count * elst_entry_size can overflow


> +c->fc->strict_std_compliance >= FF_COMPLIANCE_STRICT) {
> +av_log(c->fc, AV_LOG_ERROR, "Invalid edit list entry_count: %d for 
> elst atom of size: %"PRId64" bytes.\n",
> +   edit_count, atom.size + 8);
> +return AVERROR_INVALIDDATA;
> +}
>  
>  if (!edit_count)
>  return 0;
> @@ -4617,17 +4626,20 @@ static int mov_read_elst(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return AVERROR(ENOMEM);
>  
>  av_log(c->fc, AV_LOG_TRACE, "track[%u].edit_count = %i\n", 
> c->fc->nb_streams - 1, edit_count);
> -for (i = 0; i < edit_count && !pb->eof_reached; i++) {
> +for (i = 0; i < edit_count && atom.size > 0 && !pb->eof_reached; i++) {
>  MOVElst *e = >elst_data[i];

isnt atom.size < 0 an error condition ?
this could would not error out in that case
is that intended ?

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Fix parsing of edit list atoms with invalid elst entry count.

[Michael Niedermayer]

On Wed, Oct 18, 2017 at 08:18:27PM -0700, Sasi Inguva wrote:
> Attaching fate sample,

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] lavf/utils: add MP2 to the probing list

[Michael Niedermayer]

On Thu, Oct 19, 2017 at 02:39:47AM -0500, Rodger Combs wrote:
> ---
>  libavformat/utils.c | 1 +
>  1 file changed, 1 insertion(+)

shoud be ok

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[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 idea is to order 25 shirts:

1*S
5*M
10*L
7*XL
2*XXL

Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
So, we are talking about a maximum price of 562,50 Euro (excluding
delivery costs).


since I had my own shirt exchanged during VDD, I don't even have one for the 
next conf thing I might go to so I hereby revive this thread. I promised some 
shirts to Mozilla, Nicolas reminded me of getting one for him also during VDD...

I went to a nice shop today and they can offer a quite nice price for shirts 
based on Thomas' last design with breast and neck printings. So I ordered four 
samples for just 12€ each! I had the unprinted shirts in my hand and the 
quality is good in spite of that nice price. I even think that 12€ per shirt 
can't be beaten by Liu's offer to have them printed in China... shipping should 
eat up anything we might save by China-shirts.

I'll get the printed samples tomorrow and one of these will definitely find its 
way to Nicolas.
If we're happy with the samples, I'd like to order a pile of shirts for us and 
that could be the amount Thomas listed in the beginning of this thread. I'd 
also like to add some more for the shirts I've already promised to send to 
several people. This means I expect something like 350-400€ including shipping 
to various places.

This is even cheaper than what Thomas estimation was so I hope nobody objects :)

This shop can also do stitching on basecaps, with a little longer waiting time 
also the coffee mugs.
I also talked about stickers that would come in a similar manner like the nice 
ones we got from the Kodi guy some years ago and that are almost gone. However 
I want to get the shirts done first.


I got the samples done and I think they are good! You can find pictures of what 
the design is here:
https://photos.app.goo.gl/54h3WaruCTEKsJOc2

I add to the numbers for our stock of shirts (list quoted above) the additional 
need I have for already assigned/promised shirts and subtract the number of 
samples I made, what comes out are the following numbers:

S1
M6
L   11
XL  11
2XL  3

Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
Then there will be some costs for shipping, so I expect a low 400+ € total.

If there are no objections, I will order them and ship early next week :)

-Thilo


I'd also like one.
Will send you an E-Mail size and address.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavf/concatdec: Allocate the filenames on the heap

[Carl Eugen Hoyos]

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.

Please comment, Carl Eugen
From e25b8e6b77e3b9b661f1ce00beeef7e057929ba3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 20 Oct 2017 22:19:00 +0200
Subject: [PATCH] lavf/concatdec: Allocate the filenames on the heap.

Allow huge filenames, real-world content can be passed via data: protocol.

Fixes ticket #6761.
---
 libavformat/concatdec.c |   14 +++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 0e18901..739feaf 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -386,16 +386,24 @@ static int concat_read_close(AVFormatContext *avf)
 static int concat_read_header(AVFormatContext *avf)
 {
 ConcatContext *cat = avf->priv_data;
-uint8_t buf[4096];
-uint8_t *cursor, *keyword;
+int buf_size = 50002;
+uint8_t *buf, *cursor, *keyword;
 int ret, line = 0, i;
 unsigned nb_files_alloc = 0;
 ConcatFile *file = NULL;
 int64_t time = 0;
 
+buf = av_malloc(buf_size);
+if (!buf)
+return AVERROR(ENOMEM);
+
 while (1) {
-if ((ret = ff_get_line(avf->pb, buf, sizeof(buf))) <= 0)
+if ((ret = ff_get_line(avf->pb, buf, buf_size)) <= 0)
 break;
+if (ret == buf_size - 1) {
+av_log(avf, AV_LOG_ERROR, "filename too long (>%d)\n", buf_size - 2);
+FAIL(AVERROR_INVALIDDATA);
+}
 line++;
 cursor = buf;
 keyword = get_keyword();
-- 
1.7.10.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Am 20.10.17 um 19:59 schrieb Rostislav Pehlivanov:
> On 20 October 2017 at 16:16, Thilo Borgmann  wrote:
> 
>> 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 idea is to order 25 shirts:

 1*S
 5*M
 10*L
 7*XL
 2*XXL

 Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
 So, we are talking about a maximum price of 562,50 Euro (excluding
 delivery costs).
>>>
>>> since I had my own shirt exchanged during VDD, I don't even have one for
>> the next conf thing I might go to so I hereby revive this thread. I
>> promised some shirts to Mozilla, Nicolas reminded me of getting one for him
>> also during VDD...
>>>
>>> I went to a nice shop today and they can offer a quite nice price for
>> shirts based on Thomas' last design with breast and neck printings. So I
>> ordered four samples for just 12€ each! I had the unprinted shirts in my
>> hand and the quality is good in spite of that nice price. I even think that
>> 12€ per shirt can't be beaten by Liu's offer to have them printed in
>> China... shipping should eat up anything we might save by China-shirts.
>>>
>>> I'll get the printed samples tomorrow and one of these will definitely
>> find its way to Nicolas.
>>> If we're happy with the samples, I'd like to order a pile of shirts for
>> us and that could be the amount Thomas listed in the beginning of this
>> thread. I'd also like to add some more for the shirts I've already promised
>> to send to several people. This means I expect something like 350-400€
>> including shipping to various places.
>>>
>>> This is even cheaper than what Thomas estimation was so I hope nobody
>> objects :)
>>>
>>> This shop can also do stitching on basecaps, with a little longer
>> waiting time also the coffee mugs.
>>> I also talked about stickers that would come in a similar manner like
>> the nice ones we got from the Kodi guy some years ago and that are almost
>> gone. However I want to get the shirts done first.
>>
>> I got the samples done and I think they are good! You can find pictures of
>> what the design is here:
>> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
>>
>> I add to the numbers for our stock of shirts (list quoted above) the
>> additional need I have for already assigned/promised shirts and subtract
>> the number of samples I made, what comes out are the following numbers:
>>
>> S1
>> M6
>> L   11
>> XL  11
>> 2XL  3
>>
>> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
>> Then there will be some costs for shipping, so I expect a low 400+ € total.
>>
>> If there are no objections, I will order them and ship early next week :)
>>
>> -Thilo
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> I'd like one, how do I sign up?

You just did, send me your size and shipping address, please.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[Thilo Borgmann]

Am 20.10.17 um 19:44 schrieb Ronald S. Bultje:
> Hi,
> 
> On Fri, Oct 20, 2017 at 11:16 AM, Thilo Borgmann 
> wrote:
> 
>> 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 idea is to order 25 shirts:

 1*S
 5*M
 10*L
 7*XL
 2*XXL

 Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
 So, we are talking about a maximum price of 562,50 Euro (excluding
 delivery costs).
>>>
>>> since I had my own shirt exchanged during VDD, I don't even have one for
>> the next conf thing I might go to so I hereby revive this thread. I
>> promised some shirts to Mozilla, Nicolas reminded me of getting one for him
>> also during VDD...
>>>
>>> I went to a nice shop today and they can offer a quite nice price for
>> shirts based on Thomas' last design with breast and neck printings. So I
>> ordered four samples for just 12€ each! I had the unprinted shirts in my
>> hand and the quality is good in spite of that nice price. I even think that
>> 12€ per shirt can't be beaten by Liu's offer to have them printed in
>> China... shipping should eat up anything we might save by China-shirts.
>>>
>>> I'll get the printed samples tomorrow and one of these will definitely
>> find its way to Nicolas.
>>> If we're happy with the samples, I'd like to order a pile of shirts for
>> us and that could be the amount Thomas listed in the beginning of this
>> thread. I'd also like to add some more for the shirts I've already promised
>> to send to several people. This means I expect something like 350-400€
>> including shipping to various places.
>>>
>>> This is even cheaper than what Thomas estimation was so I hope nobody
>> objects :)
>>>
>>> This shop can also do stitching on basecaps, with a little longer
>> waiting time also the coffee mugs.
>>> I also talked about stickers that would come in a similar manner like
>> the nice ones we got from the Kodi guy some years ago and that are almost
>> gone. However I want to get the shirts done first.
>>
>> I got the samples done and I think they are good! You can find pictures of
>> what the design is here:
>> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
>>
>> I add to the numbers for our stock of shirts (list quoted above) the
>> additional need I have for already assigned/promised shirts and subtract
>> the number of samples I made, what comes out are the following numbers:
>>
>> S1
>> M6
>> L   11
>> XL  11
>> 2XL  3
>>
>> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
>> Then there will be some costs for shipping, so I expect a low 400+ € total.
>>
>> If there are no objections, I will order them and ship early next week :)
>>
> 
> I love it! Thanks :)

Based on Thomas comments and comparison to the previous design, I'll have the 
".org" part of the text removed and the overall size of the logo on both sides 
reduces. Should look a little more decent and is then similar to his previous 
design. Looking at the shirt in reality, I second his opinion and if nobody 
insists on the ".org" I'll go that way.

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale: more accurate DITHER_COPY macro for full and limited range

[Jan Ekstrom]

On Fri, Oct 20, 2017 at 10:26 AM, Mateusz  wrote:
> W dniu 2017-10-06 o 17:33, Mateusz pisze:
>> Fixed DITHER_COPY macro (only C code), updated FATE tests.
>>
>> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is 
>> there.
>
> Ping.

Hi,

The updated PSNR values look really good (and the max difference going
from 1 to 0), but unfortunately I lack the capacity to verify that the
code is doing the same thing as the original thing.

Can we please have someone's eyes on this? If a patchwork URL makes it
simpler, it's https://patchwork.ffmpeg.org/patch/5440/ .


Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[Rostislav Pehlivanov]

On 20 October 2017 at 16:16, Thilo Borgmann  wrote:

> 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 idea is to order 25 shirts:
> >>
> >> 1*S
> >> 5*M
> >> 10*L
> >> 7*XL
> >> 2*XXL
> >>
> >> Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
> >> So, we are talking about a maximum price of 562,50 Euro (excluding
> >> delivery costs).
> >
> > since I had my own shirt exchanged during VDD, I don't even have one for
> the next conf thing I might go to so I hereby revive this thread. I
> promised some shirts to Mozilla, Nicolas reminded me of getting one for him
> also during VDD...
> >
> > I went to a nice shop today and they can offer a quite nice price for
> shirts based on Thomas' last design with breast and neck printings. So I
> ordered four samples for just 12€ each! I had the unprinted shirts in my
> hand and the quality is good in spite of that nice price. I even think that
> 12€ per shirt can't be beaten by Liu's offer to have them printed in
> China... shipping should eat up anything we might save by China-shirts.
> >
> > I'll get the printed samples tomorrow and one of these will definitely
> find its way to Nicolas.
> > If we're happy with the samples, I'd like to order a pile of shirts for
> us and that could be the amount Thomas listed in the beginning of this
> thread. I'd also like to add some more for the shirts I've already promised
> to send to several people. This means I expect something like 350-400€
> including shipping to various places.
> >
> > This is even cheaper than what Thomas estimation was so I hope nobody
> objects :)
> >
> > This shop can also do stitching on basecaps, with a little longer
> waiting time also the coffee mugs.
> > I also talked about stickers that would come in a similar manner like
> the nice ones we got from the Kodi guy some years ago and that are almost
> gone. However I want to get the shirts done first.
>
> I got the samples done and I think they are good! You can find pictures of
> what the design is here:
> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
>
> I add to the numbers for our stock of shirts (list quoted above) the
> additional need I have for already assigned/promised shirts and subtract
> the number of samples I made, what comes out are the following numbers:
>
> S1
> M6
> L   11
> XL  11
> 2XL  3
>
> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
> Then there will be some costs for shipping, so I expect a low 400+ € total.
>
> If there are no objections, I will order them and ship early next week :)
>
> -Thilo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd like one, how do I sign up?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Moritz Barsnick]

On Thu, Oct 19, 2017 at 18:00:52 -0400, Bjorn Roche wrote:
> +{ "threshold", "set the alpha threshold for transparency. Above this 
> threshold, pixels are considered opaque, below they are considered 
> transparent.", OFFSET(trans_thresh), AV_OPT_TYPE_INT, {.i64=128}, 0, 255, },

This seems a bit verbose. The longer texts belongs into
doc/filters.texi, where you need to document this option anyway.

> +if ( c >> 24 >= trans_thresh ) { // ignore transparent entry

No whitespace next to the brackets, please.

> -if ((c & 0xff00) != 0xff00) {
> +if ( c >> 24 < s->trans_thresh ) {

Same here.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[Ronald S. Bultje]

Hi,

On Fri, Oct 20, 2017 at 11:16 AM, Thilo Borgmann 
wrote:

> 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 idea is to order 25 shirts:
> >>
> >> 1*S
> >> 5*M
> >> 10*L
> >> 7*XL
> >> 2*XXL
> >>
> >> Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
> >> So, we are talking about a maximum price of 562,50 Euro (excluding
> >> delivery costs).
> >
> > since I had my own shirt exchanged during VDD, I don't even have one for
> the next conf thing I might go to so I hereby revive this thread. I
> promised some shirts to Mozilla, Nicolas reminded me of getting one for him
> also during VDD...
> >
> > I went to a nice shop today and they can offer a quite nice price for
> shirts based on Thomas' last design with breast and neck printings. So I
> ordered four samples for just 12€ each! I had the unprinted shirts in my
> hand and the quality is good in spite of that nice price. I even think that
> 12€ per shirt can't be beaten by Liu's offer to have them printed in
> China... shipping should eat up anything we might save by China-shirts.
> >
> > I'll get the printed samples tomorrow and one of these will definitely
> find its way to Nicolas.
> > If we're happy with the samples, I'd like to order a pile of shirts for
> us and that could be the amount Thomas listed in the beginning of this
> thread. I'd also like to add some more for the shirts I've already promised
> to send to several people. This means I expect something like 350-400€
> including shipping to various places.
> >
> > This is even cheaper than what Thomas estimation was so I hope nobody
> objects :)
> >
> > This shop can also do stitching on basecaps, with a little longer
> waiting time also the coffee mugs.
> > I also talked about stickers that would come in a similar manner like
> the nice ones we got from the Kodi guy some years ago and that are almost
> gone. However I want to get the shirts done first.
>
> I got the samples done and I think they are good! You can find pictures of
> what the design is here:
> https://photos.app.goo.gl/54h3WaruCTEKsJOc2
>
> I add to the numbers for our stock of shirts (list quoted above) the
> additional need I have for already assigned/promised shirts and subtract
> the number of samples I made, what comes out are the following numbers:
>
> S1
> M6
> L   11
> XL  11
> 2XL  3
>
> Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
> Then there will be some costs for shipping, so I expect a low 400+ € total.
>
> If there are no objections, I will order them and ship early next week :)
>

I love it! Thanks :)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] HEVC ARM optimization

[Jan Ekstrom]

Hi,

On Fri, Oct 20, 2017 at 10:39 AM, Shengbin Meng  wrote:
> Hi,
>
> I’d like to know if anyone is dong or interested in ARM optimization for the 
> native HEVC decoder in FFmpeg?
>

Of course we are interested in optimizations. An example of how they
can be integrated is available @
http://git.videolan.org/?p=ffmpeg.git;a=commit;h=ffbd1d2b0002576ef0d976a41ff959c635373fdc
(this is for VP9, but the idea is similar).

For HEVC we already have some of the ground work available such as
libavcodec/arm/hevcdsp_init_{arm,neon}.c , latter of which is what
sets the DSP function pointers. You can see if your existing SIMD can
fit into any of the functions that are defined by the HEVCDSPContext.


Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[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 idea is to order 25 shirts:
>>
>> 1*S
>> 5*M
>> 10*L
>> 7*XL
>> 2*XXL
>>
>> Last time we ordered 5 shirts and got a price of 22,50 Euro per shirt.
>> So, we are talking about a maximum price of 562,50 Euro (excluding
>> delivery costs).
> 
> since I had my own shirt exchanged during VDD, I don't even have one for the 
> next conf thing I might go to so I hereby revive this thread. I promised some 
> shirts to Mozilla, Nicolas reminded me of getting one for him also during 
> VDD...
> 
> I went to a nice shop today and they can offer a quite nice price for shirts 
> based on Thomas' last design with breast and neck printings. So I ordered 
> four samples for just 12€ each! I had the unprinted shirts in my hand and the 
> quality is good in spite of that nice price. I even think that 12€ per shirt 
> can't be beaten by Liu's offer to have them printed in China... shipping 
> should eat up anything we might save by China-shirts.
> 
> I'll get the printed samples tomorrow and one of these will definitely find 
> its way to Nicolas.
> If we're happy with the samples, I'd like to order a pile of shirts for us 
> and that could be the amount Thomas listed in the beginning of this thread. 
> I'd also like to add some more for the shirts I've already promised to send 
> to several people. This means I expect something like 350-400€ including 
> shipping to various places.
> 
> This is even cheaper than what Thomas estimation was so I hope nobody objects 
> :)
> 
> This shop can also do stitching on basecaps, with a little longer waiting 
> time also the coffee mugs.
> I also talked about stickers that would come in a similar manner like the 
> nice ones we got from the Kodi guy some years ago and that are almost gone. 
> However I want to get the shirts done first.

I got the samples done and I think they are good! You can find pictures of what 
the design is here:
https://photos.app.goo.gl/54h3WaruCTEKsJOc2

I add to the numbers for our stock of shirts (list quoted above) the additional 
need I have for already assigned/promised shirts and subtract the number of 
samples I made, what comes out are the following numbers:

S1
M6
L   11
XL  11
2XL  3

Sums up to 12€ * 32 = 384€ (that includes the costs for the samples)
Then there will be some costs for shipping, so I expect a low 400+ € total.

If there are no objections, I will order them and ship early next week :)

-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: 32 bit audio support

[Douglas Marsh]

On 2017-10-19 20:08, Douglas Marsh wrote:

On 2017-10-18 12:23, Dave Rice wrote:

[...]
Updated.

From 1e5ff78fec9b13eccac9a96acc358bbfd6a7015d Mon Sep 17 00:00:00 2001
From: Dave Rice 
Date: Wed, 18 Oct 2017 15:21:46 -0400
Subject: [PATCH] libavdevice/decklink: 32 bit audio support



I (quickly before going to bed) did the following from commit: 
858db4b01fa2b55ee55056c033054ca54ac9b0fd


(documented the morning after, but believe this is correct)

Works:
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' -c:a 
pcm_s24le -vcodec libx264 -crf 0 -preset superfast test.mov
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' -c:a 
pcm_s32le -vcodec libx264 -crf 0 -preset superfast test.mkv
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' 
-acodec flac -vcodec libx264 -crf 0 -preset superfast test.mkv


Doesn't work (issues with MOV and 32-bit audio so assuming not a deal, 
unless 32-bit audio SHOULD work)
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' 
-acodec copy -vcodec libx264 -crf 0 -preset superfast test.mov
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' -c:a 
pcm_s32le -vcodec libx264 -crf 0 -preset superfast test.mov


Haven't tested rgb10 (assuming is "soft" fails [600.0fps*] or complains 
like in previous builds):
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format rgb10 -i 'DeckLink Studio 4K' -c:a 
copy -vcodec libx264 -crf 0 -preset superfast test.mkv


*=soft fails as in older builds getting a reported 600.0fps (I posted 
something here previous) when -c copy output.avi and analyze the avi 
file metadata


(side note)
Also works: (with v4l2loopback)
$ ffmpeg10 -format_code Hp59 -f decklink -video_input hdmi -audio_input 
embedded -audio_depth 32 -raw_format argb -i 'DeckLink Studio 4K' -c:a 
null -c:v rawvideo -pix_fmt yuv420p -threads 2 -f v4l2 /dev/videoX


(where ffmpeg10 = 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/x264-10bit/libx264.so.148 ffmpeg 
"$@")


--Doug (dx9s)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] v4l2_m2m: Fix races around freeing data on close

[Jorge Ramirez]

On 10/19/2017 07:55 PM, Jorge Ramirez wrote:


ok so I guess there is no point to discuss further what I tried to put 
forward (I could provide my implementation to compare against this RFC 
- it is just a handful of lines of code - but I guess there is no 
point given that everyone is comfortable with the current way of doing 
things.).


so let's make this work then and fix the SIGSEGV present in master 
asap (btw this RFC also seg-fault when the above is applied)


dont worry too much about fixing this anyway - this implementation is 
incorrect and needs a couple of modifications (full reinit currently 
closes the driver when it should just send the stop command - that was 
to work around an issue in the venus driver stop ).


a fix to venus (db410/db820c hw) has been sent to the kernel mailing 
list so will validate and fix.




diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 831fd81..1dd8cf0 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -176,8 +176,8 @@ static av_cold int v4l2_decode_init(AVCodecContext 
*avctx)
  * by the v4l2 driver; this event will trigger a full pipeline 
reconfig and

  * the proper values will be retrieved from the kernel driver.
  */
-output->height = capture->height = avctx->coded_height;
-output->width = capture->width = avctx->coded_width;
+output->height = capture->height = 0; //avctx->coded_height;
+output->width = capture->width = 0; //avctx->coded_width;

 output->av_codec_id = avctx->codec_id;
 output->av_pix_fmt  = AV_PIX_FMT_NONE;


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] HEVC ARM optimization

[Shengbin Meng]

Hi,

I’d like to know if anyone is dong or interested in ARM optimization for the 
native HEVC decoder in FFmpeg?

We can see that some time-consuming operations in HEVC decoding have not been 
optimized using NEON, e.g, qpel and epel interpolation, SAO, IDCT of large 
blocks.
I have some optimization code here, and I am considering to submit to FFmpeg, 
so that we can develop together.

Regards,
Shengbin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale: more accurate DITHER_COPY macro for full and limited range

[Mateusz]

W dniu 2017-10-06 o 17:33, Mateusz pisze:
> Fixed DITHER_COPY macro (only C code), updated FATE tests.
> 
> PSNR in tests that needed update goes from 50 to 999.99 -- the quality is 
> there.

Ping.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix for paletteuse to support transparency

[Clément Bœsch]

On Fri, Oct 20, 2017 at 12:35:00AM +0200, Carl Eugen Hoyos wrote:
> 2017-10-20 0:00 GMT+02:00 Bjorn Roche :
> > The palettes generated by palettegen include one transparent color.
> > This patch enables paletteuse to identify the transparency in incoming
> > video and tag transparent pixels on outgoing video.
> >
> > This requires tracking the transparency index in the palette,
> > establishing an alpha threshold below which a pixel is considered
> > transparent and above which the pixel is considered opaque, and
> > additional changes to track the alpha value throught the conversion
> > process. If the format of a color variable has changed in this patch,
> > an effort was also made to change the variable name for clarity.
> >
> > This change is a partial fix for https://trac.ffmpeg.org/ticket/4443
> > However, animated GIFs are still output incorrectly due to a bug
> > in gif optimization which does not correctly handle transparency.
> 
> If Clément doesn't comment, I will probably push this in a few days.
> 

I need a little more time. I don't think I can do this today, but tomorrow
might be OK.

Sorry about the delay.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel