1
0
mirror of https://github.com/FFmpeg/FFmpeg.git synced 2024-11-21 10:55:51 +02:00
FFmpeg/libavcodec/xbmenc.c

99 lines
3.1 KiB
C
Raw Normal View History

/*
* XBM image format
*
* Copyright (c) 2012 Paul B Mahol
*
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* FFmpeg is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with FFmpeg; if not, write to the Free Software
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
#include "avcodec.h"
#include "codec_internal.h"
#include "encode.h"
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
#define ANSI_MIN_READLINE 509
static int xbm_encode_frame(AVCodecContext *avctx, AVPacket *pkt,
const AVFrame *p, int *got_packet)
{
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
int i, j, l, commas, ret, size, linesize, lineout, rowsout;
const uint8_t *ptr;
uint8_t *buf;
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
linesize = lineout = (avctx->width + 7) / 8;
commas = avctx->height * linesize;
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
/* 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_packet(avctx, pkt, size)) < 0)
return ret;
buf = pkt->data;
ptr = p->data[0];
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");
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
for (i = 0, l = lineout; i < avctx->height; i++) {
for (j = 0; j < linesize; j++) {
// 0..15 bitreversed as chars
static const char lut[] = {
'0', '8', '4', 'C', '2', 'A', '6', 'E',
'1', '9', '5', 'D', '3', 'B', '7', 'F'
};
buf[0] = ' ';
buf[1] = '0';
buf[2] = 'x';
buf[3] = lut[*ptr & 0xF];
buf[4] = lut[*ptr >> 4];
buf += 5;
ptr++;
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
if (--commas <= 0) {
*buf++ = '\n';
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
break;
}
*buf++ = ',';
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
if (--l <= 0) {
*buf++ = '\n';
avcodec/xbmenc: Allow for making UW images 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+<CR>+<LF>+<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).
2021-01-19 07:43:13 +02:00
l = lineout;
}
}
ptr += p->linesize[0] - linesize;
}
buf += snprintf(buf, 5, " };\n");
pkt->size = buf - pkt->data;
*got_packet = 1;
return 0;
}
const FFCodec ff_xbm_encoder = {
.p.name = "xbm",
CODEC_LONG_NAME("XBM (X BitMap) image"),
.p.type = AVMEDIA_TYPE_VIDEO,
.p.id = AV_CODEC_ID_XBM,
.p.capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_ENCODER_REORDERED_OPAQUE,
FF_CODEC_ENCODE_CB(xbm_encode_frame),
.p.pix_fmts = (const enum AVPixelFormat[]) { AV_PIX_FMT_MONOWHITE,
AV_PIX_FMT_NONE },
};