The function typedefs we were using are only present when using the
dynamic loader, which means compilation breaks for code directly
using the cuda SDK.
To fix this, let's just duplicate the function typedefs locally.
These are not going to change.
Signed-off-by: Philip Langdale
---
libavutil/c
On Tue, 12 Feb 2019, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavformat/mpegtsenc.c | 88 +
1 file changed, 53 insertions(+), 35 deletions(-)
Ping, will push soon.
Regards,
Marton
diff --git a/libavformat/mpegtsenc.c b/libavf
2017-03-15 23:56 GMT+01:00, Ricardo Constantino :
> ffmpeg | branch: master | Ricardo Constantino | Wed Mar
> 15 22:47:58 2017 +| [b409d8d4a276490cd67255fd4230ea0954bd8c50] |
> committer: James Almer
>
> configure: libnpp is always nonfree, even with LGPL
>
> libnpp was erroneously grouped up
In practice, compiling a real-world cuda kernel requires the use of
the cuda SDK and specifically involves linking in some sort of
static library that implements various parts of the cuda API on
the GPU side.
As such, it's unclear to me whether it's even logically consistent
to place the cuda ker
sön 2019-02-17 klockan 23:22 +0100 skrev Tomas Härdin:
> tor 2019-01-17 klockan 11:14 +0100 skrev Michael Niedermayer:
> > On Thu, Jan 17, 2019 at 09:44:47AM +0100, Clément Bœsch wrote:
> > > On Wed, Jan 16, 2019 at 01:40:20PM +0100, Tomas Härdin wrote:
> > > > Hi
> > > >
> > > > I was helping the
sön 2019-02-10 klockan 17:04 +0100 skrev Tomas Härdin:
> lör 2019-02-09 klockan 13:10 + skrev Matthew Fearnley:
> > - Clamp ME range to -64..63 (prevents corruption when me_range is too high)
> > - Allow MV's up to *and including* the positive range limit
> > - Allow out-of-edge ME by padding t
Speeds up error cases
Fixes:
13132/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664190616829952
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wcmv.c | 20 ++
This speeds up the testcase by a factor of 4
Fixes: Timeout
Fixes:
13100/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV2_fuzzer-5767533905313792
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
li
Improves speed of the testcase by about a factor of 10
Fixes: Timeout
Fixes:
13132/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WCMV_fuzzer-5664190616829952
Signed-off-by: Michael Niedermayer
---
libavcodec/wcmv.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/liba
2019-02-18 22:43 GMT+01:00, Marton Balint :
>
>
> On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote:
>
>> 2019-02-17 20:55 GMT+01:00, Marton Balint :
>>> This reworks the code to be more strict about accepting
>>> stream specifiers. From now on we strictly enforce the
>>> syntax in the documentation up u
2019-02-19 7:48 GMT+01:00, Karthick J :
> +// Explanation for why certain movflags are used for streaming:
I don't think this is a useful line.
> +// frag_every_frame :- Every frame should be moof fragment, so
Is there a smiley in the middle of the line?
> +// the data from cur
2019-02-19 20:25 GMT+01:00, Soft Works :
>> > From your explanations, the situation doesn't seem to be as
>> > bad as it could be. When the CPU code of the filters can be
>> > changed to dynamic linking
>>
>> The type of the linking of course cannot change the license.
>
> Maybe I should have said
On 2019-02-19 11:25, Soft Works wrote:
> From your explanations, the situation doesn't seem to be as
> bad as it could be. When the CPU code of the filters can be
> changed to dynamic linking
The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading
> > From your explanations, the situation doesn't seem to be as
> > bad as it could be. When the CPU code of the filters can be
> > changed to dynamic linking
>
> The type of the linking of course cannot change the license.
Maybe I should have said 'dynamic loading' rather than 'dynamic
linking'.
2019-02-18 22:44 GMT+01:00, Soft Works :
> From your explanations, the situation doesn't seem to be as
> bad as it could be. When the CPU code of the filters can be
> changed to dynamic linking
The type of the linking of course cannot change the license.
Carl Eugen
__
> > Thanks again for your kind reply. Although I’m not a lawyer myself, I
> > know
> > that if you’re the sole(!) author of the yadif_cuda kernel source, then
> > you
> > would be allowed to publish that code under any additional license you
> > want.
> >
> > But that would be your very own decisi
On 2019-02-18 20:08, Soft Works wrote:
Thanks again for your kind reply. Although I’m not a lawyer myself, I
know
that if you’re the sole(!) author of the yadif_cuda kernel source, then
you
would be allowed to publish that code under any additional license you
want.
But that would be your
Hi James,
On 19/02/2019 17:14, James Almer wrote:
On 2/11/2019 1:59 PM, Guillaume Desmottes wrote:
CDG doesn't ensure a constant framerate as we can have holes in the CDG
stream. So there is no guarantee of the duration of a single frame, it
will be displayed until a new packet with CDG instruc
On 2/11/2019 1:59 PM, Guillaume Desmottes wrote:
> CDG doesn't ensure a constant framerate as we can have holes in the CDG
> stream. So there is no guarantee of the duration of a single frame, it
> will be displayed until a new packet with CDG instruction arrives in the
> stream.
>
> Signed-off-by
On 2/19/19, Adam Sampson wrote:
> When a JACOsub subtitle has two timestamps, they represent its start and
> end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
> duration is the difference between the two, not the sum of the two.
>
> The subtitle end times in the FATE test for th
When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (
21 matches
Mail list logo
