Hi Karthick,
Thanks for looking into this.
I'll have a look at the suggested improvement.
Regards,
Joep
On Tue, Feb 26, 2019 at 6:25 AM Jeyapal, Karthick
wrote:
>
> On 2/22/19 12:25 PM, joepadmiraal wrote:
> > From: joepadmiraal
> >
> > ---
> > libavformat/dashenc.c | 29
> I know we forgot before but this definitely needs a micro version bump.
>
>
New patchs in attach
001, 003, 004 : unchanged
002 : add avcodec micro version bump
Martin
0001-fate-qtrle-change-32b-test-to-output-bgra-instead-of.patch
Description: Binary data
0003-avcodec-qtrle-32bpp-dec-copy-tw
Hi
A friend of mine recently became the proud owner of a tape robot with
about 2 PB of storage and is looking for stuff to store on it (picture
[1]). Does FFmpeg have any longer-term archiving needs?
I may have asked about this on IRC already, but the ML is probably more
appropriate.
/Tomas
[1]
Hello,
Thanks for the files
The problem appear for "unsafe" resolution (only vsynth3 have this).
Patchs in attach are supposed to fix this
001 : fix sub_image_with_fill for interlaced encoding
002 : new fate test, with update result for vsynth3 interlace test
Can be test with :
make fate-vsynth
On 21.02.2019 04:57, Philip Langdale wrote:
The use of nvcc to compile cuda kernels is distinct from the use of
cuda sdk libraries and linking against those libraries. We have
previously not bothered to distinguish these two cases because all
the filters that used cuda kernels also used the sdk.
Hello,
On Tue, 26 Feb 2019, at 14:51, Timo Rothenpieler wrote:
> > Note that, unlike the cuda_sdk dependency, using nvcc to compile
> > a kernel does not cause a build to become non-free. Although nvcc
> > is distributed with the cuda sdk, and is EULA encumbered, the
> > compilation process we use
Hi Tomas
Thanks for the review.
My codec is a hardware codec, it depends an dynamic library that goes
with the M264 card.
The way it works will be:
1>Our customers buy the card and install the drivers of it.
2>They Compile ffmpeg.
3>Call ffmpeg with codec option of m264.
That's why I use dl
Hi Moritz
It's the first time that I send patch to ffmpeg, for sure I don't know a
lot of things for ffmpeg.
Thanks a lot for your detailed review.
I'll read the doc and fix the issues you said.
Yufei.
On 02/25/2019 04:21 PM, Moritz Barsnick wrote:
> Hi Yufei,
> before providing large patche
Yufei He (12019-02-26):
> My codec is a hardware codec, it depends an dynamic library that goes
> with the M264 card.
>
> The way it works will be:
>
> 1>Our customers buy the card and install the drivers of it.
>
> 2>They Compile ffmpeg.
>
> 3>Call ffmpeg with codec option of m264.
>
> That'
The patch seems to be corrupted by something. At least git am is
refusing to apply it, and it looks very jumbled on patchwork.
But it LGTM. Feel free to push.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg
tis 2019-02-26 klockan 14:26 + skrev Yufei He:
> Hi Tomas
>
> Thanks for the review.
>
> My codec is a hardware codec, it depends an dynamic library that goes
> with the M264 card.
>
> The way it works will be:
>
> 1>Our customers buy the card and install the drivers of it.
>
> 2>They Com
Hello,
Patch in attach, change codeword bits writing
by replacing PutBitContext, and use instead uint64_t bit_buf
Also remove byte buffer length check
encode_codeword func have two version now
- one for dc coeff and run coeff (same as previous encode_codeword func)
- one for level coeff who also
> Am 26.02.2019 um 16:54 schrieb Martin Vignali :
>
> Patch in attach, change codeword bits writing
> by replacing PutBitContext, and use instead uint64_t bit_buf
Shouldn’t there be a 64Bit PutBitContext instead so other encoders can also
profit?
Carl Eugen
___
Hi,
FFmpeg has just been selected as a mentoring organization for Google Summer of
Code 2019 [1]!
As usual, we are still looking for more interesting student projects and
mentors from our community willing to mentor.
So please feel free to suggest a project and volunteer as mentor or backup
me
---
libavformat/rtpdec_mpeg4.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/rtpdec_mpeg4.c b/libavformat/rtpdec_mpeg4.c
index 4f70599..f632ebf 100644
--- a/libavformat/rtpdec_mpeg4.c
+++ b/libavformat/rtpdec_mpeg4.c
@@ -289,15 +289,15 @@ static int parse_
> From a technical standpoint, this whole series looks fine to me.
>
> However, it really does not fell non-nonfree to me that the only way to
> build these filters remains to register with nvidia, accept their
> various EULAs and download their SDK for nvcc and the libs around it.
>
> Even moving
> From: Jean-Baptiste Kempf
> Sent: Dienstag, 26. Februar 2019 15:01
>
> [...]
>
> I don't think nvcc fit the"normally distributed with the operating system".
I'm not sure if the role of nvcc has been fully understood.
nvcc is some kind of 'pre-compiler' which is not distributed or linked to.
Di
On Tue, 26 Feb 2019, at 21:26, Soft Works wrote:
> It's an external and separate executable. It is not a violation of
> the GPL if ffmpeg checks for existence and executes that in a separate
> process.
Believing that executing in a separate process removes the obligation of the
GPL is an very-muc
On Tue, 26 Feb 2019, at 21:36, Soft Works wrote:
> I'm not sure if the role of nvcc has been fully understood.
> nvcc is some kind of 'pre-compiler' which is not distributed or linked to.
>
> Distributing GPL code that was compiled with MSVC doesn't require the
> MSVC compiler to be open source as
> From: Jean-Baptiste Kempf
> Sent: Dienstag, 26. Februar 2019 23:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] configure: Add an explicit check and
> option for nvcc
>
> On Tue, 26 Feb 2019, at 21:26, Soft Works wrote:
> > It's an external and separate executable. It
On Tue, Feb 26, 2019 at 12:04:58PM +0100, Martin Vignali wrote:
> Hello,
>
> Thanks for the files
>
> The problem appear for "unsafe" resolution (only vsynth3 have this).
>
> Patchs in attach are supposed to fix this
> 001 : fix sub_image_with_fill for interlaced encoding
> 002 : new fate test,
On Tue, Feb 26, 2019 at 09:38:20AM +0800, Shiyou Yin wrote:
> >-Original Message-
> >From: ffmpeg-devel-boun...@ffmpeg.org
> >[mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of gxw
> >Sent: Monday, February 25, 2019 6:14 PM
> >To: ffmpeg-devel@ffmpeg.org
> >Cc: gxw
> >Subject: [FFmpeg-d
On Thu, Feb 21, 2019 at 4:46 PM Chris Cunningham
wrote:
> I'm fine to do either. James, do you still prefer to skip the later
> headers if this breaks some old ogm files?
>
James, friendly ping
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
On 26.02.2019 21:36, Soft Works wrote:
From: Jean-Baptiste Kempf
Sent: Dienstag, 26. Februar 2019 15:01
[...]
I don't think nvcc fit the"normally distributed with the operating system".
I'm not sure if the role of nvcc has been fully understood.
nvcc is some kind of 'pre-compiler' which is
24 matches
Mail list logo
