On 3/8/12, Paul B Mahol <[email protected]> wrote: > 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. >
As Justin just pointed out on irc this is swscale bug. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
