assert(3) is a debugging aid. Do not leave it enabled
on release builds.
---
At least some of those asserts should be converted to normal
failure paths, I'm afraid. Help welcome.
configure | 9 +
libavcodec/dvdsubenc.c | 1 -
libavcodec/libschroedingerdec.c
---
libavcodec/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a6e88c7..2fbcc09 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -755,6 +755,7 @@ SKIPHEADERS+= %_tablegen.h
\
SK
---
tools/graph2dot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/graph2dot.c b/tools/graph2dot.c
index 12f1066..fbf8902 100644
--- a/tools/graph2dot.c
+++ b/tools/graph2dot.c
@@ -28,7 +28,6 @@
#include "libavutil/channel_layout.h"
#include "libavutil/mem.h"
#include "libavutil/pix
On Sun, Aug 30, 2015 at 7:10 PM, Martin Storsjö wrote:
> On Sun, 30 Aug 2015, Vittorio Giovara wrote:
>
>> On Sat, Aug 29, 2015 at 10:33 PM, Martin Storsjö wrote:
>>>
>>> On Sat, 29 Aug 2015, Vittorio Giovara wrote:
>>>
---
Related to
In file included from libavutil/des.h.c:1:
On Sun, 30 Aug 2015, Vittorio Giovara wrote:
On Sat, Aug 29, 2015 at 10:33 PM, Martin Storsjö wrote:
On Sat, 29 Aug 2015, Vittorio Giovara wrote:
---
Related to
In file included from libavutil/des.h.c:1:
/Users/GiovaraV/src/libav/libavutil/des.h:33:5: warning:
'FF_API_CRYPTO_CONTEXT' i
From: Michael Niedermayer
Despite '417792' being reported in the binary decoder, the buffer at
encoding time needs to be bigger to avoid running out of space due to
interlace handling.
Signed-off-by: Vittorio Giovara
---
libavcodec/dnxhddata.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Sat, Aug 29, 2015 at 10:33 PM, Martin Storsjö wrote:
> On Sat, 29 Aug 2015, Vittorio Giovara wrote:
>
>> ---
>> Related to
>>
>> In file included from libavutil/des.h.c:1:
>> /Users/GiovaraV/src/libav/libavutil/des.h:33:5: warning:
>> 'FF_API_CRYPTO_CONTEXT' is not defined, evaluates to 0
On 30/08/15 09:24, Bryan Huh wrote:
> For example:
> Stream #0:0: Video: flv1, yuv420p, 1280x800, 512 kb/s, 1k tbr, 1k tbn,
> 1k tbc
>
> I have usually assumed that "tbr" is approximately the fps of the video,
> but that doesn't seem to be correct in the cases where it's in the "#k"
> format..
Sometimes I see videos with "tbr" values like "1k" or "90k", and sometimes
a fps value alongside it that doesn't seem to correlate with the tbr value
at all.
For example:
Stream #0:0: Video: flv1, yuv420p, 1280x800, 512 kb/s, 1k tbr, 1k tbn,
1k tbc
I have usually assumed that "tbr" is approxi
