- 05 Jul, 2012 14 commits
-
-
Loren Merritt authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
Loren Merritt authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
Diego Biurrun authored
-
Anton Khirnov authored
Fixes an invalid read on size change.
-
Reimar Döffinger authored
Currently it always exits with an error when more than one position is specified. CC: libav-stable@libav.org
-
Mans Rullgard authored
Instead of inlining everything into ff_h264_hl_decode_mb(), use explicit templating to create versions of the called functions with constant parameters filled in. This greatly speeds up compilation of h264.c and reduces the code size without any measurable impact on performance. Compilation time for h264.c on an i7 goes from 30s to 5.5s. Code size is reduced by 430kB. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Samuel Pitoiset authored
Previously it was interpreted as number of bytes, while the documentation stated that it was the number of 8 byte blocks. This makes it behave similarly to the existing AES code. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Samuel Pitoiset authored
Previously it was interpreted as number of bytes, while the documentation stated that it was the number of 8 byte blocks. This makes it behave similarly to the existing AES code. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Michael Niedermayer authored
Using ff_mspel_motion assumes that s (a MpegEncContext poiinter) really is a Wmv2Context. This fixes crashes in error resilience on vc1/wmv3 videos. CC: libav-stable@libav.org Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Luca Barbato authored
Should slightly improve performance depending on the compiler used.
-
Luca Barbato authored
Should slightly improve performance depending on the compiler used.
-
Luca Barbato authored
In certain conditions video or audio frames might appear way later in the stream.
-
Martin Storsjö authored
If the output frame size is smaller than the input sample rate, and the input stream time base corresponds exactly to the input frame size (getting input packet timestamps like 0, 1, 2, 3, 4 etc), the output timestamps from the filter will be like 0, 1, 2, 3, 4, 4, 5 ..., leadning to non-monotone timestamps later. A concrete example is input mp3 data having frame sizes of 1152 samples, transcoded to aac with 1024 sample frames. By setting the audio filter time base to the sample rate, we will get sensible timestamps for all output packets, regardless of the ratio between the input and output frame sizes. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
This was missed in the the previous commit in 70a1c800. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 04 Jul, 2012 26 commits
-
-
Mans Rullgard authored
This tool uses lavfi internal symbols not accessible in shared libraries. TESTPROGS are linked statically to allow them use of library internals not normally exported. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Diego Biurrun authored
tools/graph2dot.c:85: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int’
-
Martin Storsjö authored
Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
Martin Storsjö authored
Signed-off-by:
Ronald S. Bultje <rsbultje@gmail.com>
-
Ronald S. Bultje authored
MSVC doesn't like the offsetof(..) >> 1 construct, it interprets it as a non-literal, thus causing use of this in static tables to fail compilation.
-
Ronald S. Bultje authored
-
Ronald S. Bultje authored
MSVC gives a compile error on the tentative definition of mov_default_parse_table[].
-
Diego Biurrun authored
-
Diego Biurrun authored
All libs have version headers now, which allows hardcoding the path.
-
Diego Biurrun authored
-
Diego Biurrun authored
This avoids confusion from patterns meant to only match at the top level matching files in subdirectories.
-
Ronald S. Bultje authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Samuel Pitoiset authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Samuel Pitoiset authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Martin Storsjö authored
For reading from normal files on disk, the queue limits for demuxed data work fine, but for reading data from realtime streams, they mean we're not reading from the input stream at all once the queue limit has been reached. For TCP streams, this means that writing to the socket from the peer side blocks (potentially leading to the peer dropping data), and for UDP streams it means that our kernel might drop data. For some protocols/servers, the server initially sends a large burst with data to fill client side buffers, but once filled, we should keep reading to avoid dropping data. For all realtime streams, it IMO makes sense to just buffer as much as we get (rather in buffers in avplay.c than in OS level buffers). With this option set, the input thread should always be blocking waiting for more input data, never sleeping waiting for the decoder to consume data. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Mans Rullgard authored
-
Mans Rullgard authored
-
Mans Rullgard authored
The buffers are only allocated once, although it can happen from any of a few different places, so there is no need to use realloc. Using av_malloc() ensures they are aligned suitably for SIMD optimisations. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
Mans Rullgard authored
This value does not need to be persistent across calls.
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-