From patchwork Tue Jan 19 05:43:13 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jose Da Silva X-Patchwork-Id: 25035 Return-Path: X-Original-To: patchwork@ffaux-bg.ffmpeg.org Delivered-To: patchwork@ffaux-bg.ffmpeg.org Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by ffaux.localdomain (Postfix) with ESMTP id 298C24496CE for ; Tue, 19 Jan 2021 07:43:23 +0200 (EET) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 13E87689257; Tue, 19 Jan 2021 07:43:23 +0200 (EET) X-Original-To: ffmpeg-devel@ffmpeg.org Delivered-To: ffmpeg-devel@ffmpeg.org Received: from mx0-10.i-mecca.net (mx0-10.i-mecca.net [76.74.184.244]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id C1C076881BD for ; Tue, 19 Jan 2021 07:43:16 +0200 (EET) Received: from mx0.ehosting.ca (localhost [127.0.0.1]) by mx0.i-mecca.net (Postfix) with ESMTP id 4A8F316170E for ; Mon, 18 Jan 2021 21:43:15 -0800 (PST) Received: from ns2.i-mecca.net (unknown [192.168.1.2]) by mx0.i-mecca.net (Postfix) with ESMTP id 80D0C161748 for ; Mon, 18 Jan 2021 21:43:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joescat.com; s=mail; h=date:from:to:subject; bh=TmX04VZfVbfxQBhMGl2rcAbWJZuFCICRxI/IBEZ6MSw=; b=ZEyusVELiTE4k8w8J9pJydI/AL8yceuWt7AJ25FZfi/6PBVlDBfaLfevIDWMc8kHlX B/lVN30XDNVXcCR6xmFhQKRWYrpmWpiLEnzNyr1lpgNIOWOdOwBb19whcQAJ+TN408KL v02PyI6EDGrNx8tXSeTEqCWvW2wx/pjiSljkhWOO8R1WJSc6DNa3eQ5q3iwMgW3pcmTK ObXn4uxgkueHEHA/X0sfFdtVFvx4FGHKa7QlRL7oWVQtCL5nqgx1SNnGVuTyBTjbc5KO QnBWd2bfKS/R1ayo/5rV3dvoaLUgr0Kz1L2LYBC6JEKMRzJVEwzXRCdeZQpenGZism6u rl1A== X-MES: 1.0 X-MM: 1.0 Received: from drived.localnet (d66-183-117-75.bchsia.telus.net [66.183.117.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ns2.i-mecca.net (Postfix) with ESMTPSA id 0BFA03001F6 for ; Tue, 19 Jan 2021 00:43:13 -0500 (EST) From: Jose Da Silva To: ffmpeg-devel@ffmpeg.org Date: Mon, 18 Jan 2021 21:43:13 -0800 User-Agent: KMail/1.13.7 (Linux/2.6.38.8-desktop586-10.mga; KDE/4.6.5; i686; ; ) MIME-Version: 1.0 Message-Id: <202101182143.13808.digital@joescat.com> Subject: [FFmpeg-devel] [PATCH 3/3] avcodec/xbmenc: Allow for making UW images X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" I've run into some bugs where I was downloading a bunch of data and began seeing weird hiccups. For example, javascript promises to allow you to push some very long lines of data, but the hiccups I saw was with data larger than 2k in length (windows) pushed out of a child process stdout piped into the stdin of the calling parent program. Soo much for smooth promises, this was broken and would run into similar problems on a linux PC with 32k line limits. The solution was to break the data into smaller chunks than 2k - and then these data hiccups disappeared (windows PC). It would be expected to be similar for linux PCs (32k I think) and other OSes with different sizes. If the ANSI required minimum needs to be 509 chars or larger (assuming 509+++<0>=512), then 509 was chosen as the shortest worst-case scenario) in this patch. Most small pictures will go output looking pretty much the same data out until you get to about 84bytes (672 pixels wide), where lines out begin to be split. For example a UW 4K will exceed a 2k readln and a UW 10K picture approaches an 8k readln The purpose for this patch is to ensure that data remains below the readline limits (of 509 chars), so that programs (like javascript) can push data in large chunks without breaking into hiccups because the data length is too long to be pushed cleanly in one go. Subject: [PATCH 3/3] avcodec/xbmenc: Allow for making UW images Worst-case ANSI must allow for 509 chars, while Windows allows for 2048 and Linux for 32K line length. This allows an OS with a small readline access limitation to fetch very wide images (created from ffmpeg). --- libavcodec/xbmenc.c | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/libavcodec/xbmenc.c b/libavcodec/xbmenc.c index 193ced652a..1cf13f6f0b 100644 --- a/libavcodec/xbmenc.c +++ b/libavcodec/xbmenc.c @@ -24,15 +24,25 @@ #include "internal.h" #include "mathops.h" +#define ANSI_MIN_READLINE 509 + static int xbm_encode_frame(AVCodecContext *avctx, AVPacket *pkt, const AVFrame *p, int *got_packet) { - int i, j, commas, ret, size, linesize; + int i, j, l, commas, ret, size, linesize, lineout, rowsout; uint8_t *ptr, *buf; - linesize = (avctx->width + 7) / 8; + linesize = lineout = (avctx->width + 7) / 8; commas = avctx->height * linesize; - size = avctx->height * (linesize * 6 + 1) + 106; + + /* ANSI worst case minimum readline is 509 chars. */ + rowsout = avctx->height; + if (lineout > (ANSI_MIN_READLINE / 6)) { + lineout = ANSI_MIN_READLINE / 6; + rowsout = (commas + lineout - 1) / lineout; + } + + size = rowsout * (lineout * 6 + 1) + 106; if ((ret = ff_alloc_packet2(avctx, pkt, size, 0)) < 0) return ret; @@ -42,14 +52,20 @@ static int xbm_encode_frame(AVCodecContext *avctx, AVPacket *pkt, buf += snprintf(buf, 32, "#define image_width %u\n", avctx->width); buf += snprintf(buf, 33, "#define image_height %u\n", avctx->height); buf += snprintf(buf, 39, "static unsigned char image_bits[] = {\n"); - for (i = 0; i < avctx->height; i++) { + for (i = 0, l = lineout; i < avctx->height; i++) { for (j = 0; j < linesize; j++) { buf += snprintf(buf, 6, " 0x%02X", ff_reverse[*ptr++]); - if (--commas > 0) - buf += snprintf(buf, 2, ","); + if (--commas <= 0) { + buf += snprintf(buf, 2, "\n"); + break; + } + buf += snprintf(buf, 2, ","); + if (--l <= 0) { + buf += snprintf(buf, 2, "\n"); + l = lineout; + } } ptr += p->linesize[0] - linesize; - buf += snprintf(buf, 2, "\n"); } buf += snprintf(buf, 5, " };\n");