On 3/8/12, Paul B Mahol <[email protected]> wrote: > On 3/8/12, Justin Ruggles <[email protected]> wrote: >> On 03/08/2012 11:08 AM, Paul B Mahol wrote: >> >>> >>> Signed-off-by: Paul B Mahol <[email protected]> >>> --- >>> Changelog | 1 + >>> doc/general.texi | 4 ++- >>> libavcodec/Makefile | 1 + >>> libavcodec/allcodecs.c | 1 + >>> libavcodec/avcodec.h | 1 + >>> libavcodec/version.h | 2 +- >>> libavcodec/xbmenc.c | 93 >>> ++++++++++++++++++++++++++++++++++++++++++++++++ >>> libavformat/img2.c | 1 + >>> libavformat/img2enc.c | 2 +- >>> 9 files changed, 103 insertions(+), 3 deletions(-) >>> create mode 100644 libavcodec/xbmenc.c >> >> [...] >> >>> +static av_cold int xbm_encode_init(AVCodecContext *avctx) >>> +{ >>> + if (avctx->width & 7) { >>> + av_log(avctx, AV_LOG_ERROR, "width is not divisible by >>> eight.\n"); >>> + return AVERROR(EINVAL); >>> + } >> >> >> Wikipedia says this is allowed: >> "If the image width does not match a multiple of 8, the display >> mechanism ignores and discards the extra bits in the last byte of each >> row." >> >> The input frame should also be padded in such cases, so it should be >> trivial to support. > > Wrong, mono is bitstream format, implementing support for width not > multiple > of 8 is going to be a little bit ugly. > > Perhaps byte variant should be added to sws? > > FYI both ImageMagick and Gimp (and Libav) appears to encode/decode > HHHHxWWW3 pbm wrong. > Actually not, ImageMagick & Gimp decodes ImageMagick output just fine.
On other hand our pbm decoder displays black rows on right side. Our pbm encoder writes random crap on right side too. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
