From 61c9c2539149b1e2812c81a52a18760bb566c98d Mon Sep 17 00:00:00 2001
From: Tilghman Lesher <tilghman@meg.abyt.es>
Date: Mon, 17 Jul 2006 16:31:43 +0000
Subject: [PATCH] H.263 frames can apparently be larger than was originally
coded.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@37785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---
formats/format_h263.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/formats/format_h263.c b/formats/format_h263.c
index 70108e9ef7..cee3fd7c67 100644
--- a/formats/format_h263.c
+++ b/formats/format_h263.c
@@ -49,7 +49,13 @@ ASTERISK_FILE_VERSION(__FILE__, "$Revision$")
/* Portions of the conversion code are by guido@sienanet.it */
-#define BUF_SIZE 4096 /* Two Real h263 Frames */
+/* According to:
+ * http://lists.mpegif.org/pipermail/mp4-tech/2005-July/005741.html
+ * the maximum actual frame size is not 2048, but 8192. Since the maximum
+ * theoretical limit is not much larger (32k = 15bits), we'll go for that
+ * size to ensure we don't corrupt frames sent to us (unless they're
+ * ridiculously large). */
+#define BUF_SIZE 32768 /* Four real h.263 Frames */
struct h263_desc {
unsigned int lastts;
--
GitLab