Hi,

On Thu, Mar 8, 2012 at 4:07 PM, Paul B Mahol <[email protected]> wrote:
> 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.

Please file yet another bugzilla bug. ;-).

Ronald
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to