Friendly ping.
Are these changes acceptable now?
On Fri, Jul 31, 2020 at 1:35 AM Julio César Rocha
wrote:
> Understood, thanks!
>
> Here are the updated patches.
>
> On Fri, Jul 31, 2020 at 1:07 AM zhilizhao wrote:
>
>>
>>
>> > On Jul 31, 2020, at 3:19 PM, Julio César Rocha
>> wrote:
>> >
>>
Fixes: Ticket8762
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 49 +---
1 file changed, 42 insertions(+), 7 deletions(-)
diff --git a/libavformat/dv.c b/libavformat/dv.c
index e99422d4b5..7ebe1815b3 100644
--- a/libavformat/dv.c
+++ b/liba
With this change the AV sync issues should be fixed without manually
setting the dvaudio_concealment
Signed-off-by: Michael Niedermayer
---
libavformat/dv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dv.c b/libavformat/dv.c
index 7ebe1815b3..aea68d40fc 100644
On 31/07/2020 00:59, James Almer wrote:
On 7/30/2020 6:31 PM, Mark Thompson wrote:
The external library is called libsvtav1, so use this name everywhere.
---
configure| 2 +-
libavcodec/Makefile | 2 +-
libavcodec/allcodecs.c
On Fri, Jul 31, 2020 at 12:39:46PM +0200, Andreas Rheinhardt wrote:
> If a bit is reserved, it matters very much what value it has, because
> otherwise a decoder conforming to a future version of the standard might
> interpret the output file in an unintended manner. This implies that
> one must no
Hi
On Fri, Jul 31, 2020 at 03:53:56PM +0100, Jack Haughton wrote:
> Commit a500b975 removed NULL input handling from this function,
> moving the check higher up the call tree in one branch. However,
> there is another call to set_string_video_rate() which may pass
> NULL, and future users of the f
Commit a500b975 removed NULL input handling from this function,
moving the check higher up the call tree in one branch. However,
there is another call to set_string_video_rate() which may pass
NULL, and future users of the function may not be clear that
a NULL check is required. This patch restores
Attached patch increases the max length of control URI to 2048 characters,
as urls of some RTSP streams do exceed this limit.
0001-Increasing-the-max-length-of-control-URI-to-2048-cha.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-d
On Thu, Jul 30, 2020 at 01:32:47AM -0500, Sebastian Pop wrote:
> On Sat, Jul 18, 2020 at 1:35 AM Michael Niedermayer
> wrote:
>
> > Multithreading support should be added in a architecture independant way
> >
> >
> Attached patch moves helper threads up from hscale to
> chr_h_scale and lum_h_scal
On Thu, Jul 30, 2020 at 02:42:30PM +0200, Alexander Strasser wrote:
> Don't pass a potential NULL pointer to av_log, instead use a default
> in the rc_eq AVOption definitions. Now the context variable always
> holds a string; even if it's the default expression.
>
> Note this also fixes the evalua
probably ok
On 7/31/20, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/smacker.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
> index 9f054f071d..e53183318e 100644
> --- a/libavcodec/smacker.c
> +++
On 7/31/20, Harry Mallon wrote:
> Hi,
>
> V2 fixes all the fate tests (I didn't know to download the test footage
> before. Doh).
>
> The following patch adds reading colour metadata (transfer, primaries and
> colour space) from
> standard MXF files. I wrote it without seeing the other patch but i
Kieran Kunhya (12020-07-31):
> > /* Geometric progression with ratio 42. */
> >
> > Or, if you used a one-liner in whatever language of your choice, just
> > copy-paste it into the comment:
> >
> > /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
>
> This is completely unrealistic
On 31.07.2020 14:11, Julio César Rocha wrote:
You would, if you had to or wanted to use the Microsoft compilers, as in my
case.
Just tested with msvc in WSL(i.e. launch wsl.exe from within a x64
native tools cmd), and it works just fine as well without any
modifications made.
___
> /* Geometric progression with ratio 42. */
>
> Or, if you used a one-liner in whatever language of your choice, just
> copy-paste it into the comment:
>
> /* Zsh: for i in {0..11}; printf "%8x\\n" $[440*2**(22+i/12.)] */
>
This is completely unrealistic for reverse engineered tables such as VLCs
On Fri, 31 Jul 2020 at 13:26, Timo Rothenpieler
wrote:
> On 31.07.2020 13:17, Julio César Rocha wrote:
> > Do you use the MSVC compilers?
> > If so, how do you get around compiling linux-type absolute paths with
> > cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c).
> > Microsoft's CL.EXE does not
Jul 31, 2020, 10:48 by geo...@nsup.org:
> Tables that were not just written by the code author are
> not actually source code, otherwise,
> "recode data..x1 < proprietary.o > source.c"
> would be enough to launder a proprietary blob into
> the source code.
>
> Documenting the origin of the tables
You would, if you had to or wanted to use the Microsoft compilers, as in my
case.
So, in summary, your use case is different to what I’m trying to do.
On Fri, Jul 31, 2020 at 04:26 Timo Rothenpieler
wrote:
> On 31.07.2020 13:17, Julio César Rocha wrote:
> > Do you use the MSVC compilers?
> > If
On Sun, Jul 5, 2020 at 5:26 AM Jean-Baptiste Kempf wrote:
> On Sat, Jul 4, 2020, at 19:44, Michael Niedermayer wrote:
> > Another area as we are already on the subject is stuff falling a little
> > outside what FFmpeg covers.
> > Not every filter that anyone wants to write should have to be in FF
Please help review the patch, thanks!
> On Jul 26, 2020, at 1:30 PM, Zhao Zhili wrote:
>
> pre_tag_size is always reset by avio_rb32(). For AVFormatContext
> start_time, as the document says, "NEVER set this value directly:
> It is deduced from the AVStream values."
> ---
> fix commit subject
>
On 31.07.2020 13:17, Julio César Rocha wrote:
Do you use the MSVC compilers?
If so, how do you get around compiling linux-type absolute paths with
cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c).
Microsoft's CL.EXE does not accept paths beginning with a forward slash.
I don't, why would I?
I j
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 07fa8887d8..9ba70af6f7 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -653,18 +653,15 @@ stati
smacker_decode_header_tree() uses different variables for return values
(res) and for errors (err) leading to code like
res = foo(bar);
if (res < 0) {
err = res;
goto error;
}
Given that no positive return value is ever used at all one can simplify
the above by removing the intermediate res
ff_init_vlc_sparse() supports arrays of uint8_t, uint16_t and uint32_t
as input (and it also supports padding/other elements in between the
elements). This makes the typical case in which the input is a simple
array more cumbersome. E.g. for an array of uint8_t one would either
need to call the fun
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 8a4d88cfed..4b1f0f1b7c 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -251,17 +251,18 @@ static
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 83 +++-
1 file changed, 28 insertions(+), 55 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 3c9f118fb7..b6245a0ce1 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec
The Huffmann tables used by Smacker can consist of exactly one leaf only
in which case the length of the corresponding code is zero; there is
then exactly one value encoded. Our VLC can't handle this and therefore
this case needs to be treated separately; it has been implemented in
commit 48cbdaea1
The extradata for Smacker video contains Huffman trees as well as a
field containing the size (in bytes) of said Huffman tree when stored
as a table. Due to three special values the decoder allocates more than
the size field indicates; yet when it parses the table it only errors
out if the number o
Signed-off-by: Andreas Rheinhardt
---
libavcodec/smacker.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavcodec/smacker.c b/libavcodec/smacker.c
index 9f054f071d..e53183318e 100644
--- a/libavcodec/smacker.c
+++ b/libavcodec/smacker.c
@@ -59,7 +59,6 @@ typedef struct SmackVContex
Do you use the MSVC compilers?
If so, how do you get around compiling linux-type absolute paths with
cl.exe? (i.e. /home/user/src/ffmpeg/dir/file.c).
Microsoft's CL.EXE does not accept paths beginning with a forward slash.
On Fri, Jul 31, 2020 at 4:02 AM Timo Rothenpieler
wrote:
> On 31.07.2020
On 31.07.2020 09:41, Julio César Rocha wrote:
Hi. I recently submitted a patch to enable building the Windows flavor with
Windows Subsystem for Linux as an alternative to MSYS / CYGWIN.
I got the feedback that people are already able to achieve this.
Has anyone achieved this without patching th
If a bit is reserved, it matters very much what value it has, because
otherwise a decoder conforming to a future version of the standard might
interpret the output file in an unintended manner. This implies that
one must not use skip_put_bits() for it (which does not give any
guarantees wrt what en
Before c63c303a1f2b58677d480505ec93a90f77dd25b5 (the commit which
introduced a typedef for the type of the buffer of a PutBitContext)
skip_put_bits() was as follows:
static inline void skip_put_bits(PutBitContext *s, int n)
{
s->bit_left -= n;
s->buf_ptr -= 4 * (s->bit_left >> 5);
s->
The xcam filter is providing high quality stitching, accepting data from
the current 360 camera, one example is:
https://www.insta360.com/product/insta360-pro2/.
Now the current 360 camera output doesn't provide a broad pixel format,
only YUV420P and NV12. (For other formats, we can use current FFm
Hi,
V2 fixes all the fate tests (I didn't know to download the test footage before.
Doh).
The following patch adds reading colour metadata (transfer, primaries and
colour space) from
standard MXF files. I wrote it without seeing the other patch but it turned out
very similar to this
one that w
Lynne (12020-07-31):
> I disagree. We don't have any proprietary blobs in our codebase.
> Everything that you think is binary is in fact a well defined VLC
> table that simply describes bit positions and lengths.
Please read my message more carefully (and possibly with less
hostility): I never sai
Tables that were not just written by the code author are
not actually source code, otherwise,
"recode data..x1 < proprietary.o > source.c"
would be enough to launder a proprietary blob into
the source code.
Documenting the origin of the tables or the methods
for their generation is necessary to le
Paul B Mahol (12020-07-31):
> As already said they are derived from other parts of code or by research,
> there is no original source that could be used and written as link in
> source code.
>
> For reverse engineered codecs documenting from which binary blob it
> came from is nonsense.
I do not
On 7/31/20, Zong, Wei wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Paul B
>> Mahol
>> Sent: Friday, July 31, 2020 3:57 PM
>> To: FFmpeg development discussions and patches
>> Cc: Liu, YinhangX
>> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video
On 7/31/20, Nicolas George wrote:
> Paul B Mahol (12020-07-31):
>> Always when you appear you must evoke your request that must be
>> fulfilled at any costs no matter how useless they are.
>
> I will not answer this personal attack.
You think this is some kind of game, that you will reply only if
Understood, thanks!
Here are the updated patches.
On Fri, Jul 31, 2020 at 1:07 AM zhilizhao wrote:
>
>
> > On Jul 31, 2020, at 3:19 PM, Julio César Rocha
> wrote:
> >
> > I didn't find any documentation that refers to building with WSL.
> > Can builds with WSL be achieved without any patching?
> -Original Message-
> From: ffmpeg-devel On Behalf Of Paul B
> Mahol
> Sent: Friday, July 31, 2020 3:57 PM
> To: FFmpeg development discussions and patches
> Cc: Liu, YinhangX
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
>
> On 7/31/20, Zong, Wei wro
Paul B Mahol (12020-07-31):
> Always when you appear you must evoke your request that must be
> fulfilled at any costs no matter how useless they are.
I will not answer this personal attack.
> No existing encoder/decoder document their tables and how they got it,
> unless they are part of existin
On 7/31/20, Nicolas George wrote:
> Paul B Mahol (12020-07-31):
>> Disagree, no it does not, also only you complained about it.
>
> Do not push this patch unless the origin of all these numbers is
> properly documented in the source code.
>
> I am ready to argue, but I will not spend more text tha
Paul B Mahol (12020-07-31):
> Disagree, no it does not, also only you complained about it.
Do not push this patch unless the origin of all these numbers is
properly documented in the source code.
I am ready to argue, but I will not spend more text than you on it.
--
Nicolas George
signature
On 7/31/20, Nicolas George wrote:
> Paul B Mahol (12020-07-31):
>> From 6ec6fb33ac4a21c602b44efa94ff3246a6ea4342 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jul 2020 18:18:18 +0200
>> Subject: [PATCH 1/3] avcodec: add CFHD encoder
>>
>> ---
>> libavcodec/Makefile| 1 +
>
On 7/31/20, Nicolas George wrote:
> Paul B Mahol (12020-07-31):
>> These are either made up by inspecting numbers from already encoded
>> files or added new ones from scratch.
>
> "Document" means in the source code. And I meant all the numbers,
> including codebook and runbook, not just quantizat
Paul B Mahol (12020-07-31):
> From 6ec6fb33ac4a21c602b44efa94ff3246a6ea4342 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Sat, 25 Jul 2020 18:18:18 +0200
> Subject: [PATCH 1/3] avcodec: add CFHD encoder
>
> ---
> libavcodec/Makefile| 1 +
> libavcodec/allcodecs.c | 1 +
> libavco
Hi,
updated patches attached.
This work is sponsored by VideoLAN.
0001-avcodec-add-CFHD-encoder.patch
Description: Binary data
0002-avcodec-cfhd-move-if-else-out-of-loop-in-inverse-tra.patch
Description: Binary data
0003-avcodec-cfhd-fix-non-aligned-to-8-height-decoding.patch
Description: B
> On Jul 31, 2020, at 3:19 PM, Julio César Rocha wrote:
>
> I didn't find any documentation that refers to building with WSL.
> Can builds with WSL be achieved without any patching?
>
> Also, how should I split the patch, if it's only modifying one file?
Modify a part of the file, git add &&
Paul B Mahol (12020-07-31):
> These are either made up by inspecting numbers from already encoded
> files or added new ones from scratch.
"Document" means in the source code. And I meant all the numbers,
including codebook and runbook, not just quantization_per_subband.
--
Nicolas George
sig
On 7/31/20, Zong, Wei wrote:
> Thank you for the comments on this patch, I want to make some explanation on
> your comments.
>
> 1. the purpose of this patch
> We got some requirements from users who are trying libxcam stitching or
> developers who showing interests. Many of them want an easy
Thank you for the comments on this patch, I want to make some explanation on
your comments.
1. the purpose of this patch
We got some requirements from users who are trying libxcam stitching or
developers who showing interests. Many of them want an easy way to construct an
end 2 end pipelin
On 7/30/20, Nicolas George wrote:
> Paul B Mahol (12020-07-30):
>> Hi,
>>
>> patches attached.
>>
>> Decoder speedup is approx %20 overall.
>
>> From 9692daafc0c4a69ce3cf7dca5b5aa90b5737e15f Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jul 2020 18:18:18 +0200
>> Subject: [PATCH
On 7/30/20, Andreas Rheinhardt wrote:
> Paul B Mahol:
>>
>> +static int cfhd_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
>> + const AVFrame *frame, int *got_packet)
>> +{
>> +CFHDEncContext *s = avctx->priv_data;
>> +PutByteContext *pby = &s->pby;
>> +
On 7/30/20, James Almer wrote:
> On 7/30/2020 1:32 PM, Paul B Mahol wrote:
>> Hi,
>>
>> patches attached.
>>
>> Decoder speedup is approx %20 overall.
>
>> From 9692daafc0c4a69ce3cf7dca5b5aa90b5737e15f Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Sat, 25 Jul 2020 18:18:18 +0200
>> Subj
Hi. I recently submitted a patch to enable building the Windows flavor with
Windows Subsystem for Linux as an alternative to MSYS / CYGWIN.
I got the feedback that people are already able to achieve this.
Has anyone achieved this without patching the sources (out of the box)?
If so, could you ple
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'ceil'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
It can be tested with the model generated with below python script:
import tensorflow as tf
import os
import numpy as np
import imageio
from tensorflow.python.framework import graph_util
name = 'ceil'
pb_file_path = os.getcwd()
if not os.path.exists(pb_file_path+'/{}_savemodel/'.format(name)):
I didn't find any documentation that refers to building with WSL.
Can builds with WSL be achieved without any patching?
Also, how should I split the patch, if it's only modifying one file?
On Thu, Jul 30, 2020 at 11:52 PM Carl Eugen Hoyos
wrote:
>
>
> > Am 31.07.2020 um 06:59 schrieb Julio Césa
From: Yinhang Liu
xcam filter is a wrapper of libxcam project which supports 360 video stitching,
automotive surround view stitching, digital video stabilization (DVS),
wavelet noise reduction, 3D noise reduction, etc.
libxcam library optimized algorithms by AVX, GLES and Vulkan depends on
hardw
> -Original Message-
> From: ffmpeg-devel On Behalf Of Steven
> Liu
> Sent: Thursday, July 30, 2020 7:04 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_xcam: add xcam video filter
>
> Zong, Wei 于2020年7月30日周四 下午6:00写道：
> >
> > Some
62 matches
Mail list logo
