On 14/07/16 10:53, John Högberg wrote:
> If I were you I'd just create a temporary image to hold the result and
> enqueue a copy operation that waits for the kernel event. It'll work
> everywhere and the performance penalty is tiny.
... If you really must have it
to explicitly use the read_write qualifier in order for
it to work as expected.
If I were you I'd just create a temporary image to hold the result and enqueue
a copy operation that waits for the kernel event. It'll work everywhere and the
performance penalty is tiny.
Reg
zed to hell and back on GPUs. Hardware samplers
are pretty neat ;)
The only drawback with image2d_t is that you can't modify them in-place in
OpenCL 1.2, but with the addition of the read_write qualifier it's not an issue
in OpenCL 2.0.
Regards,
John Högberg
_
Luca Barbato wrote:
I wanted samples or (you to confirm that works) since I want to refactor a
bit the tail skip so I might need you to test some patches later if you have
time.
Sure, no problem.
/John
___
libav-devel mailing list
decode_registered_user_data and ff_h264_decode_sei,
so you may want to give those a peek.
Regards,
John Högberg
-Original Message-
From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf Of Luca
Barbato
Sent: Saturday, August 08, 2015 01:25
To: libav-devel@libav.org
Subject: Re
Hi,
The current H264 SEI parser chokes if it encounters bar data or EIA-608
subtitles while parsing ATSC1_data. This patch fixes that.
Regards,
John Högberg
From e1f1c47cb50e2471e977911a68e07430fbbff18c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date
of a keyframe.
Regards,
John Högberg
From 8de02a6a688ed30a37073eff984ce43a8004a59d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Fri, 24 Jul 2015 15:30:38 +0200
Subject: [PATCH] h264: fix AVDISCARD_NONKEY for some interlaced content
When skip_frame is set
Hi,
This small patch fixes JPEG2000 over MPEG-TS, so long as PSI/SI are present.
Regards,
John Högberg
From 15b5e46b1d9aa4188269ff9f2be71cf40fe8503b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon, 29 Jun 2015 14:57:20 +0200
Subject: [PATCH
the
specific flags of the underlying streams since you'll need to check them all
anyway.
lu
PS: The spring^Wsummer Sprint will be almost surely held in Stockholm, if you
are close and you want to drop by would be great =)
When? I'll see if I can make it.
Regards,
John Högberg
This patch implements the CARRIER_PRESENT event as outlined here;
https://lists.libav.org/pipermail/libav-devel/2015-June/069889.html
Regards,
John Högberg
From 163ff93fab1e0ec81f8f560d946dfe2a93e7c1d6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date
://blogs.gentoo.org/lu_zero/2015/03/23/decoupling-an-api/
Cool, it looks like that might solve a few issues of mine. Aside from the blog,
is there a discussion thread for this somewhere?
On topic, should I go ahead with submitting the patch for MPEG-TS?
Regards,
John Högberg
John Högberg wrote:
Hi,
libavformat currently doesn't provide any mechanism for detecting when a
substream is no longer present but the stream as a whole is otherwise OK. Your
best guess is to check when you last got any frames on it, which tends to work
for video and audio
actual data on the stream.
--
If accepted I'll submit an implementation for MPEG-TS since I figure it's
pointless to clutter the mailing list with it before that.
Regards,
John Högberg
From f96924fa78ac535b8cfc08fe26b3073edec48c90 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg
Anton Khirnov wrote:
Well, as you're saying elsewhere, the actual meaning of this flag is very much
format-dependent. So the caller has to make some format-specifica assumptions
anyway.
True enough, I was hoping I could abstract it all away but you're right in that
it will leak one way or
that the os limit won't make
the call fail so this patch shouldn't hurt even for those setup, right?
Worse; it will make the call fail silently. The only way to be sure you've set
it correctly is to getsockopt() and check if the value is what you requested. :|
Regards,
John Högberg
as the OS allows and then
logs an error message stating that the requested buffer size exceeds that of the
maximum the OS allows. Something along those lines anyway.
Ignoring the issue is not an option =)
Agreed.
Regards,
John Högberg
___
libav-devel
no changes to existing
code or binaries.
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Sorry, I haven't really managed to make my mail client work properly with this
mailing list. Here's the patch, I hope it ends up in the correct thread. :(
Regards,
John Högberg
From 97447c2e66296b37df89a44ba5d30b4204d23418 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb
processing of the stream. This set of patches is
an attempt at addressing this.
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
business it's up to the user to determine what
the event means. There is no way for libavformat to know whether it's good or
bad, but the user needs to know something's happened.
Regards,
John Högberg
From 244d21c41b8b9c3eba711742669fd3b9393d3e1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3
generally in the order of 1s).
Regards,
John Högberg
From 1bbc8c4cbcfc405c28004fb6ade4efb02adb5faf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon, 18 May 2015 11:19:05 +0200
Subject: [PATCH] mpegts: implement the NO_CARRIER event
---
libavformat
to hold (See socket(7), SO_RCVBUF). By default this is set to
256K on most distributions, making the actual maximum 128K.
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
either fail loudly or fail loudly and fall back to the best it can do.
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
see one right now. Thoughts?
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
event_flags to 0, but the old method will still work
fine for events that are explicitly raised, requiring no changes to existing
code.
Regards,
John Högberg
From 3a85f3508ca0dcbe97a2813e15887fb58268add8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon
I forgot to include the topic in the commit message. Fix attached.
Regards,
John Högberg
From ec1068915767a03d5824a4e7de53a3007546 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon, 11 May 2015 10:59:33 +0200
Subject: [PATCH] lavf: Add a stream
was detected
and it's up to the application to decide whether to call it quits or not.
Regards,
John Högberg
From 43d1d0b89ae1b70cbb6fc819b16514a0dab1e2c7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon, 11 May 2015 09:58:00 +0200
Subject: [PATCH
Woops, I forgot to include the topic in the commit message.
Regards,
John Högberg
From a4b9de4ccd24d7130593ee047f176fbdd5ffc4cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Mon, 11 May 2015 10:54:42 +0200
Subject: [PATCH] lavf: Add a mechanism
be raised in this manner, and any code that doesn't handle that
therefore doesn't need to use av_reset_event_flags() either.
I'm hoping this is a step in the right direction. Thoughts?
Regards,
John Högberg
From b873039aa2a1cceab0a86bb690975111a395d1c9 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John
seen in
that time. The format provides no way to conclusively determine whether it's
there or not, so it's up to the user to determine when to consider it actually
dead.
Regards,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https
Luca Barbato wrote:
Do you have a sample of this behaviour to share, I want to understand it
better.
If no carrier has been present between calling av_reset_event_flags() and
any number of stream-related functions, the flag will be raised.
Call av_reset_event_flags() and read any MPEG-TS
think of a better way
of exposing this functionality?
Regards,
John Högberg
From 0f4183bf6f942df7fe7813e002b2697928acf937 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb...@ericsson.com
Date: Thu, 7 May 2015 14:24:27 +0200
Subject: [RFC] Add a stream event for detecting
it.
I'd prefer to keep the general impact of this as small as possible. carrier_type
and its default behavior of changing nothing was the best compromise I could
think of at the time.
Regards,
John Högberg
-Original Message-
From: libav-devel [mailto:libav-devel-boun...@libav.org] On Behalf
a rewrite, but preventing a second
*unaltered* PAT from closing the PMT section filter makes it behave properly
with a delay of one PMT repetition.
Regards,
John Högberg
From b5bb543d288ef160d494315f0b2ea5a11d5efbaa Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?John=20H=C3=B6gberg?= john.hogb
,
John Högberg
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
35 matches
Mail list logo
