- 05 Feb, 2013 5 commits
-
-
Luca Barbato authored
{avg,put}_pixels4_c are not used.
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
This avoids SIMD-optimized functions having to sign-extend their line size argument manually to be able to do pointer arithmetic.
-
- 04 Feb, 2013 2 commits
-
-
Diego Biurrun authored
-
Anton Khirnov authored
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 point to elements of ref_list. Since ref_list is not copied during updating the context and is invalid until it is constructed for the current slice, there is no point in doing anything complicated with next/last_picture_ptr, as they will get updated when the ref_list is filled.
-
- 01 Feb, 2013 9 commits
-
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
Packet pts is a very unreliable indicator, use AVCodecContext.frame_number instead.
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
-
- 31 Jan, 2013 5 commits
-
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Diego Biurrun authored
On Cygwin systems MinGW headers can be present if the corresponding packages have been installed. Since the MinGW libc is checked for first, this results in newlib getting misdetected as MinGW libc.
-
Diego Biurrun authored
-
Martin Storsjö authored
REBASE_PICTURE (more specifically, this half of it) takes a Picture pointer that points into one larger struct, finds the offset of that Picture within the struct and finds the corresponding field within another instance of a similar struct. The pointer difference "pic - (Picture*)old_ctx" is a value given in sizeof(Picture) units, and when applied back on (Picture*)new_ctx gets multiplied back with sizeof(Picture). Many compilers seem to optimize out this division/multiplication, but not all do. GCC 4.2 on OS X doesn't seem to remove the division/multiplication, therefore the new pointer didn't turn out to point to exactly the right place in the new struct since it only had sizeof(Picture) granularity (and the Picture is not aligned on a sizeof(Picture) boundary within the encompassing struct). This bug has been present before 47318953 as well - with H264, pointers to h->ref_list[0][0] pointed to 88 bytes before h->ref_list[0][0] after the rebase. After shrinking Picture, the difference ended up even larger, making writes via such a Picture pointer overwrite other fields at random in H264Context, ending up in crashes later. This fixes H264 multithreaded decoding on OS X with GCC 4.2. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 30 Jan, 2013 2 commits
-
-
Ronald S. Bultje authored
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 29 Jan, 2013 14 commits
-
-
Luca Barbato authored
Added a missing header file.
-
Anton Khirnov authored
CC:libav-stable@libav.org
-
Anton Khirnov authored
CC:libav-stable@libav.org
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
That field will be deprecated.
-
Anton Khirnov authored
I.e. don't do anything on already released frames.
-
Anton Khirnov authored
This container does not store timestamps and thus supports CFR only.
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
There is no point in keeping those two functions separate.
-
Anton Khirnov authored
-
- 28 Jan, 2013 3 commits
-
-
Diego Biurrun authored
-
Diego Biurrun authored
-
Luca Barbato authored
The block must be set to 0.
-