On Thu, Jan 31, 2013 at 11:43 AM, Anton Khirnov wrote:
> Always evaluate to NULL when the source Picture is not located in the
> MpegEncContext.picture array. That will only happen for
> next/last_picture_ptr when updating the thread context during h264 frame
> threaded decoding, where they will p
On Fri, Feb 8, 2013 at 11:43 AM, Diego Biurrun wrote:
> ---
>
> See the following IRC discussion:
>
> 00:48 <@DonDiego> libavcodec/rectangle.h:assertlong)vp)&(FFMIN(w,
> STRIDE_ALIGN)-1)) == 0);
> 00:48 <@DonDiego> how much sense does that asser make?
> 00:50 <@DonDiego> it is the only us
On Feb 6, 2013, at 10:40 AM, Anton Khirnov wrote:
> Most of the changes are just trivial are just trivial replacements of
> fields from MpegEncContext with equivalent fields in H264Context.
> Everything in h264* other than h264.c are those trivial changes.
>
> The nontrivial parts are:
> 1) ext
On Thu, Feb 14, 2013 at 2:12 PM, Janne Grunau wrote:
> On 2013-02-13 19:48:32 +0100, Anton Khirnov wrote:
>> [...]
>
> Are you sure the last part is true? It's probably true since we have to
> guarantee that get_buffer is always called before finish_setup for
> non-thread safe callbacks but it see
On Nov 2, 2011, at 5:44 PM, Diego Biurrun wrote:
> From: Sebastien Zwickert
>
> Support h264 accelerated decoding through MacOSX VDA framework
>
> Signed-off-by: Luca Barbato
> Signed-off-by: Diego Biurrun
> ---
>
> +
> +/* Mutex manager callback. */
> +static int vda_lock_operation(void **
On Nov 10, 2011, at 4:02 PM, Janne Grunau wrote:
> this fixes fate-iv8-demux with two threads
Seems worthwhile.
I added this to avoid mplayer/vlc having to make code changes (their a/v sync
is somewhat based on guesswork…), so if you apply this they'll need to change.
> ---8<---
> Adding the
On Wed, Nov 30, 2011 at 1:22 AM, Ronald S. Bultje wrote:
> Fixes fate-h264-conformance-{mr2_tandberg_e,mr3_tandberg_b} without
> requiring -strict 1.
> ---
> libavcodec/h264.c | 69 +++
> libavcodec/h264.h | 1 +
> libavcodec/h264_refs.c
---
libavcodec/h264.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index 4bcec7c..454b8b2 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -3758,7 +3758,7 @@ static int decode_nal_units(H264Context *h, const uint8_t
*buf,
On Thu, Dec 22, 2011 at 10:49 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Dec 22, 2011 at 7:37 PM, Sergey Radionov wrote:
>>
>> added forgotten ResetEvent to pthread_cond_broadcast.
>> added "volatile" to broadcast flag (since it using from multiple threads).
>> ---
>> libavcodec/w32pthreads.h
On Thu, Dec 22, 2011 at 3:22 PM, Janne Grunau wrote:
> Use sched_getaffinity to determine the number of logical CPUs.
Try sysconf(_SC_NPROCESSORS_ONLN), which exists on BSD too.
> Limits the number of threads to 16 since slice threading of H.264
> seems to be buggy with more than 16 threads.
Th
On Mon, Dec 12, 2011 at 7:39 PM, Ronald S. Bultje wrote:
> Hi,
>
>
> On Mon, Dec 12, 2011 at 3:13 PM, Alexander Strange
> wrote:
>>
>> ---
>> libavcodec/h264.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --g
On Tue, Dec 13, 2011 at 9:49 PM, Alex Converse wrote:
> The 'fiel' atoms can be found in H.264 tracks clobbering the extradata.
> MJPEG supports non field based extradata, and this data should be
> preserved when copying.
> ---
> avconv.c | 1 +
> libavcodec/avcodec.h | 21
On Sun, Jul 10, 2011 at 5:28 PM, Ronald S. Bultje wrote:
> This fixes a crash when seeking in some webm files with many
> threads (e.g. 8).
OK, except there's a whitespace change.
> ---
> libavcodec/pthread.c | 7 +--
> 1 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/li
On Sun, Jul 10, 2011 at 9:23 PM, Ronald S. Bultje wrote:
> This prevents a crash when seeking.
OK.
> ---
> libavcodec/pthread.c | 8 +---
> libavcodec/utils.c | 2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c
> in
On Aug 25, 2011, at 9:15 PM, Sean McGovern wrote:
> On Thu, Aug 25, 2011 at 8:01 PM, Aaron Colwell wrote:
>> Hi,
>> I started a thread with the following message on the FFmpeg-devel list and
>> someone suggested that I start a discussion on this list as well. Any help
>> you could provide would
On Aug 25, 2011, at 8:01 PM, Aaron Colwell wrote:
> Hi,
> I started a thread with the following message on the FFmpeg-devel list and
> someone suggested that I start a discussion on this list as well. Any help
> you could provide would be greatly appreciated.
>
> Thanks,
> Aaron
>
> -
Fixes a crash when FF_DEBUG_PICT_INFO is used.
---
libavcodec/h264_ps.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 276eb77..05f04af 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -332,8 +332,12 @@ i
Before this, they were only added to the delayed release queue and not
freed until later. This could lead to unnecessary memory use or buffer
exhaustion.
---
libavcodec/pthread.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/pthread.c b/libavcodec/pthr
On Sat, Mar 24, 2012 at 5:55 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Mar 24, 2012 at 2:32 PM, Alexander Strange
> wrote:
>> Fixes a crash when FF_DEBUG_PICT_INFO is used.
>> ---
>> libavcodec/h264_ps.c | 6 +-
>> 1 file changed, 5 insertions(
On Fri, Mar 16, 2012 at 3:25 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Mar 16, 2012 at 12:20 PM, Janne Grunau wrote:
>> On 2012-03-16 11:05:02 -0700, Ronald S. Bultje wrote:
>>> On Fri, Mar 16, 2012 at 10:36 AM, Janne Grunau
>>> wrote:
>>> > The decoder knows in decode_frame() already if th
On Mon, Mar 19, 2012 at 10:18 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sat, Mar 17, 2012 at 9:34 AM, Ronald S. Bultje wrote:
>> ---
>> libavcodec/x86/cabac.h | 10 +-
>> libavcodec/x86/h264_i386.h | 32 +---
>> 2 files changed, 22 insertions(+), 20 del
On Thu, Mar 22, 2012 at 9:53 AM, Ronald S. Bultje wrote:
> Hi,
>
> 2012/3/20 Måns Rullgård :
>> "Ronald S. Bultje" writes:
>>
>>> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
>>> ---
>>> libavcodec/x86/cabac.h | 15 ++-
>>> libavcodec/x86/h264_i386.h | 18 ++
On Tue, Mar 22, 2011 at 10:40 PM, Luca Barbato wrote:
> On 03/23/2011 03:31 AM, John Stebbins wrote:
>> fwiw, I've verified that both patches solve the original problem I had.
>
> I'd pick your since I expect to have 0 duration frames sooner or later.
Expect to have them where?
>
> lu
>
> --
>
>
On Mar 23, 2011, at 6:00 AM, Luca Barbato wrote:
> On 03/23/2011 08:20 AM, Alexander Strange wrote:
>> On Tue, Mar 22, 2011 at 10:40 PM, Luca Barbato wrote:
>>> On 03/23/2011 03:31 AM, John Stebbins wrote:
>>>> fwiw, I've verified that both patches solve the o
On Mar 23, 2011, at 9:09 PM, John Stebbins wrote:
>
>
> On 03/23/2011 05:42 PM, Alexander Strange wrote:
>> On Mar 23, 2011, at 6:00 AM, Luca Barbato wrote:
>>
>>> On 03/23/2011 08:20 AM, Alexander Strange wrote:
>>>> On Tue, Mar 22, 2011 at 10:40 PM
On Mar 23, 2011, at 10:10 PM, John Stebbins wrote:
> On 03/23/2011 06:25 PM, Alexander Strange wrote:
>>
>> On Mar 23, 2011, at 9:09 PM, John Stebbins wrote:
>>
>>>
>>>
>>> On 03/23/2011 05:42 PM, Alexander Strange wrote:
>>>> On
On Mar 25, 2011, at 2:44 PM, Sean McGovern wrote:
> Hi folks,
>
> I'd like to ask permission to go on warnings patrol based on the reports
> submitted to FATE. Some targets have over 700+ now. The immediate aim being
> only to squelch noisy warnings without changing code.
>
> If this is OK,
thread_count passed to ff_thread_init() is only used to set AVCodecContext.
thread_count, and can be removed. Instead move it to the legacy implementation
of avcodec_thread_init().
This also fixes the problem that calling avcodec_thread_init() with pthreads
enabled did not set it since ff1efc524cb
On Tue, Mar 29, 2011 at 5:23 PM, Alexander Strange
wrote:
> thread_count passed to ff_thread_init() is only used to set AVCodecContext.
> thread_count, and can be removed. Instead move it to the legacy implementation
> of avcodec_thread_init().
>
> This also fixes the probl
On Tue, Mar 29, 2011 at 9:43 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Mar 29, 2011 at 2:23 PM, Alexander Strange
> wrote:
>> thread_count passed to ff_thread_init() is only used to set AVCodecContext.
>> thread_count, and can be removed. Instead move it to the l
2011/3/28 Måns Rullgård :
> Anton Khirnov writes:
>
>> From: Anssi Hannula
>>
>> As per issue2629, most 23.976fps matroska H.264 files are incorrectly
>> detected as 24fps, as the matroska timestamps usually have only
>> millisecond precision.
>>
>> Fix that by doubling the amount of timestamps i
From: Reimar Döffinger
---
libavcodec/mpeg12.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/mpeg12.c b/libavcodec/mpeg12.c
index 5db24e8..7034a91 100644
--- a/libavcodec/mpeg12.c
+++ b/libavcodec/mpeg12.c
@@ -2344,7 +2344,7 @@ static int decode_chunks(AVCo
On Mar 30, 2011, at 1:53 AM, Luca Barbato wrote:
> mingw64 seems to have some activity on getting pthreads on window:
>
> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/winpthreads/
>
> Might be worthy testing it and then require pthread everywhere.
>
> I'll need win32/win6
---
libavcodec/pthread.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c
index d6b8fb2..c6f4a7e 100644
--- a/libavcodec/pthread.c
+++ b/libavcodec/pthread.c
@@ -875,7 +875,7 @@ static void validate_thread_parameters(AVCodecConte
On Apr 3, 2011, at 4:00 PM, Måns Rullgård wrote:
> Alexander Strange writes:
>
>> ---
>> libavcodec/pthread.c |2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/libavcodec/pthread.c b/libavcodec/pthread.c
>> index d
On Apr 3, 2011, at 6:23 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Apr 3, 2011 at 12:00 PM, Benjamin Larsson wrote:
>> On 04/02/2011 02:24 AM, Alexander Strange wrote:
>>> From: Reimar Döffinger
>>>
>>> ---
>>> libavcodec/mpeg12.c
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Needed for high bit depth h264 decoding.
You could avoid the indirect function call here by cloning hl_decode_mb 3 times
instead of 2 - simple 8bit, simple 10bit, complex - and have complex use the
indirect call and the other two hardcode
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Also add support for these formats in libswscale.
>
> Needed for high bit depth h264 decoding.
Looks ok as far as blocking the rest goes. Dithering would be nice...
> ---
> libavcodec/utils.c|4 +++
> libavutil/pixdesc.c
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
Looks OK.
> ---
> libavcodec/h264dsp.c | 243 +
> libavcodec/h264dsp_internal.h | 271 +
> 2 fi
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
OK.
> ---
> libavcodec/h264idct.c | 249 +---
> libavcodec/h264idct_internal.h | 278
> 2 files ch
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
> ---
> libavcodec/h264dsp_internal.h | 80 ++---
> 1 files changed, 51 insertions(+), 29 deletions(-)
>
> diff --git a/libavcodec/h264dsp_inter
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
> ---
> libavcodec/h264pred_internal.h | 718 +++-
> 1 files changed, 418 insertions(+), 300 deletions(-)
>
> diff --git a/libavcodec/h264pred_in
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
> ---
> libavcodec/h264idct_internal.h | 109 +++
> 1 files changed, 64 insertions(+), 45 deletions(-)
>
> diff --git a/libavcodec/h264idct_inter
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
Same comments as before.
> ---
> libavcodec/dsputil_internal.h | 704 +++--
> 1 files changed, 398 insertions(+), 306 deletions(-)
>
> diff --g
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> Preparatory patch for high bit depth h264 decoding support.
Factor out (bit_depth-8) into a variable. Otherwise it's ok.
How many instructions does this add to the file?
> ---
> libavcodec/h264_loopfilter.c | 84 -
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> In high bit depth the pixels will not be stored in uint8_t like in the
> normal case, but in uint16_t. The pixel size is thus 1 in normal bit
> depth and 2 in high bit depth.
>
> Preparatory patch for high bit depth h264 decoding support.
>
On Mar 29, 2011, at 11:48 AM, Oskar Arvidsson wrote:
> In high bit depth, the QP values may now be up to (51 + 6*(bit_depth-8)).
>
> Preparatory patch for high bit depth h264 decoding support.
> ---
> libavcodec/h264.c | 19 +++
> libavcodec/h264.h |7 ---
> l
On Apr 3, 2011, at 11:59 PM, Alex Converse wrote:
> On Tue, Mar 22, 2011 at 10:30 PM, Anton Khirnov wrote:
>> From: Stefano Sabatini
>>
>> Signed-off-by: Michael Niedermayer
>
> Looks like the commit message got mangled?
The git email stuff needs a newline after the first line of a commit m
On Apr 6, 2011, at 6:33 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Apr 6, 2011 at 4:26 PM, Kostya Shishkov
> wrote:
>> This adds side information to AVPacket
>>
>> ---
>> libavcodec/avcodec.h | 21 +
>> libavcodec/avpacket.c | 39 ++
On Apr 6, 2011, at 5:44 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Apr 5, 2011 at 3:08 PM, Luca Barbato wrote:
>> +if (buffer[0] && !(res = av_new_packet(pkt, len))) {
>> +memcpy(pkt->data, buffer, len);
>> +pkt->flags |= AV_PKT_FLAG_KEY;
>> +pkt->pos = pos;
>> +
On Thu, Apr 7, 2011 at 10:02 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Apr 7, 2011 at 1:01 AM, Alexander Strange
> wrote:
>> On Apr 6, 2011, at 5:44 PM, Ronald S. Bultje wrote:
>>> On Tue, Apr 5, 2011 at 3:08 PM, Luca Barbato wrote:
>>>> + if (buff
On Apr 8, 2011, at 5:48 AM, Anton Khirnov wrote:
> ---
> libavformat/avformat.h |4 +++-
> libavformat/utils.c|4
> libavformat/version.h |3 +++
> 3 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 61babd
On Sun, Apr 3, 2011 at 6:25 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Apr 3, 2011 at 1:56 PM, Luca Barbato wrote:
>> On 04/03/2011 10:15 PM, Alexander Strange wrote:
>>> The thread_type API allows you to request only FF_THREAD_FRAME (instead of
>>> FRAME |
While doing some other work I noticed that pretty much none of the assert()s in
the code are actually enabled when building. Several fate tests fail when
they're reenabled via ./configure --extra-cflags=-DDEBUG. Here they are for the
record.
All H.264 decodes fail on the assert at the top of MP
On Apr 11, 2011, at 5:07 AM, Luca Barbato wrote:
> This unbreak darwin.
When was it broken?
> ---
> libswscale/Makefile|2 +-
> libswscale/rgb2rgb.c | 65 ++
> libswscale/swscale_functions.c | 67 ---
On Apr 11, 2011, at 5:26 AM, Kostya wrote:
> On Mon, Apr 11, 2011 at 11:07:39AM +0200, Luca Barbato wrote:
>> With this commit we should have all the arch specific code moved away.
>> Init pattern now:
>> - generic C init first
>> - arch specific init later overwriting
>>
>> In future the arch s
On Apr 13, 2011, at 11:35 AM, Ronald Bultje wrote:
> Hi,
>
> Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6:
>
> time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
> ~/Downloads/sintel_trailer_1080p_vp8_vorbis.webm \
> -f null -vcodec rawvideo -an -
> 1: 0m14.630s (89.9 fps)
> 2: 0m8.0
On Wed, Apr 13, 2011 at 4:13 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Apr 13, 2011 at 4:08 PM, Alexander Strange
> wrote:
>> On Apr 13, 2011, at 11:35 AM, Ronald Bultje wrote:
>>> Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6:
>>>
>>> t
On Wed, Apr 13, 2011 at 11:35 AM, Ronald Bultje wrote:
> Hi,
> Tested on a Mac Pro, 2 CPUs, 2 cores each, OSX 10.6.6:
> time ./ffmpeg -v 0 -vsync 0 -threads [1234] -i \
> ~/Downloads/sintel_trailer_1080p_vp8_vorbis.webm \
> -f null -vcodec rawvideo -an -
> 1: 0m14.630s (89.9 fps)
> 2: 0m8.056s
On Apr 18, 2011, at 3:03 AM, Anton Khirnov wrote:
> ---
> libavcodec/avcodec.h | 19 ---
> libavcodec/utils.c | 16
> libavcodec/version.h |3 ---
> 3 files changed, 0 insertions(+), 38 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcode
On Apr 18, 2011, at 4:21 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Apr 18, 2011 at 11:35 AM, Reinhard Tartler
> wrote:
>> On Mon, Apr 18, 2011 at 15:17:20 (CEST), Kostya wrote:
>>> P.S. I still prefer to have big bump instead.
>>
>> we all do ;-)
>
> So I guess this is dropped now?
>
>
On Wed, Apr 20, 2011 at 4:23 PM, Ronald Bultje wrote:
> Hi,
>
> see attached.
>
> Ronald
As far as I see the only thing this lets us do is not start a few
threads if codecs won't call execute(). Is that right?
That's fine with me, especially once we autodetect threads.
(By the way, does anyone
On Fri, Apr 22, 2011 at 6:01 PM, Ronald S. Bultje wrote:
> From: Jason Garrett-Glaser
>
> This prevents a call to bytestream_get_be16() using a movzwl both before
> and after the ror instruction, which is obviously inefficient. Arm uses
> the same trick also.
>
> Sintel decoding goes from (avg+SD
On Fri, Apr 22, 2011 at 6:38 PM, Ronald S. Bultje wrote:
> This prevents gcc from assuming that contents of it may have changed
> between calls to vp56_range_get_prob(), thus preventing countless (and
> unnecessary) movs. Decoding of sintel trailer goes from (avg+SG) 9.796
> +/- 0.003 to 9.635 +/-
On Fri, Apr 22, 2011 at 8:10 PM, Luca Barbato wrote:
> On 4/23/11 2:07 AM, Ronald S. Bultje wrote:
>>
>> Hi,
>>
>> On Fri, Apr 22, 2011 at 6:55 PM, Alexander Strange
>> wrote:
>>>
>>> On Fri, Apr 22, 2011 at 6:01 PM, Ronald S. Bult
On Sun, Apr 24, 2011 at 9:18 AM, Clément Bœsch wrote:
> On Sun, Apr 24, 2011 at 09:06:16AM +0300, Uoti Urpala wrote:
>> The current generic C implementation, which is always used when the
>> public header is included from other programs (either directly or
>> through intreadwrite.h) compiles to a
---
ffmpeg.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index bb64f7c..088b8e4 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -1423,7 +1423,7 @@ static int output_packet(AVInputStream *ist, int
ist_index,
AVFormatContext *os;
AVOu
On May 10, 2011, at 6:57 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, May 10, 2011 at 1:53 AM, Alexander Strange
> wrote:
>> ---
>> ffmpeg.c | 15 ---
>> 1 files changed, 8 insertions(+), 7 deletions(-)
>
> I've tested this for a while
On Tue, May 17, 2011 at 10:03 AM, Kostya wrote:
> On Tue, May 10, 2011 at 11:29:09AM -0400, Ronald S. Bultje wrote:
>> From: Alexander Strange
>>
>> Signed-off-by: Ronald S. Bultje
>> ---
>> libavcodec/mdec.c | 20 +---
>> 1 files
69 matches
Mail list logo
