From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id F25B3448C0 for ; Mon, 26 Sep 2022 16:11:47 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id 8255168BBC9; Mon, 26 Sep 2022 19:11:42 +0300 (EEST) Received: from mail-yw1-f169.google.com (mail-yw1-f169.google.com [209.85.128.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 42C9868B391 for ; Mon, 26 Sep 2022 19:11:35 +0300 (EEST) Received: by mail-yw1-f169.google.com with SMTP id 00721157ae682-3487d84e477so73612767b3.6 for ; Mon, 26 Sep 2022 09:11:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=berkeley.edu; s=google; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date; bh=quWgygP30mqe19STEi/uMiY9vb2oWu4E2ESQ+PjPqtU=; b=SWQDizY8SFJbUxBDMH4mnlvGnmdob8g6081ji1xEvDJvsjhF6xplL96RNmlkRmL2AJ TfGKk0PruD+xCp7wa9VDkzxrb13oqS9E2ZHcFibu53w4Ck6SQTZLSwJdG8Aa8HAMlD2k G2axRYN5F3vE/fXdEPIE3mjFHCGYl43Ti1vAzULRpC8bcbk0PirWbrycVk+1hSJplT02 Ys29UXTdSgCgp/2yYUZYvU+mEgZd0PFpXTmGmeTMJ0ilhihsoYBJQHGl7NNBlTXyDnmg q4YO8iZIMIFXLIfRoAggIKb5uDG0B0qUiJxoNqweTv6VQVhqSVSZuC5Dk+Pmyir0+wT5 g0dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date; bh=quWgygP30mqe19STEi/uMiY9vb2oWu4E2ESQ+PjPqtU=; b=Bo+R/OCbri+tpDFpq/C6z8CZXxkvbVSGU7+tZ/0DLfNIuBlwzLD/+pxB63cerLXlKG 8Bg8K8SyifuvR6d/zxoMoD+BMlyAY4mLCvxhZUW60/wr4ABZMjcffRJGYJn1h+U9DYe0 WFLHpxXlCrXvLi+Zt40f93C9ua0crw3OhpJgQe/e6idL0UphKCXPFplv0O+0q7951Ur+ NrDz0wt4yLmQNlSnMtYBPR9FAxUEvfkdEnzurCmUBH0ecjz1AxdvXCNkHOPtA2uPjLBY 5vpvmbUcFTuqw7c/384ljtT9w/QJ+0vZ4w8u2vGRLytcLDpmAUV2NusHTeNXhsaGSpyN GRjQ== X-Gm-Message-State: ACrzQf2Oyi11kbOBQi4DfgGpfUd1k8Elu8qz53DKBQzDsIr8Gqz/5Ftl qoYoaG8W8GBxK0cyJjL2UwUKJRlxbj0FcwOQ/2O0brcf X-Google-Smtp-Source: AMsMyM7Y+sOwlFj+IswFwJxfU7sTiRNwMbwdtCp2Z29iP3f1RLVeZbV5rl1ymlC+f+Q750ogr2YGny+zgIw1fIWgdo8= X-Received: by 2002:a81:f88:0:b0:345:2015:1de9 with SMTP id 130-20020a810f88000000b0034520151de9mr22064711ywp.121.1664208693185; Mon, 26 Sep 2022 09:11:33 -0700 (PDT) MIME-Version: 1.0 References: <166417911337.22057.14198719724356475476@lain.khirnov.net> In-Reply-To: <166417911337.22057.14198719724356475476@lain.khirnov.net> From: Chema Gonzalez Date: Mon, 26 Sep 2022 09:11:22 -0700 Message-ID: To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] Bug on Bayer conversions X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: Yeah, it does. Will send a patch. Thanks! -Chema On Mon, Sep 26, 2022 at 12:58 AM Anton Khirnov wrote: > > Quoting Chema Gonzalez (2022-09-25 17:54:16) > > Hi, > > > > I found an issue while playing with Bayer pixel format conversions. > > > > ``` > > $ echo -ne '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff' > > > image.raw > > $ xxd image.raw > > 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000020: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > 00000030: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > ``` > > > > And then: > > ``` > > $ ffmpeg -y -f rawvideo -pixel_format bayer_bggr8 -s 8x8 -i image.raw > > -f rawvideo -pix_fmt rgb24 -video_size 8x8 image.raw.rgb > > ... > > Assertion srcSliceH > 1 failed at libswscale/swscale_unscaled.c:1310 > > Aborted (core dumped)ated 2 times > > ``` > > > > The issue relates to the ffmpeg parallelization. > > ``` > > $ ffmpeg -y -filter_threads 1 -f rawvideo -pixel_format bayer_bggr8 -s > > 8x8 -i image.raw -f rawvideo -pix_fmt rgb24 -video_size 8x8 > > image.raw.rgb > > ... > > frame= 1 fps=0.0 q=-0.0 Lsize= 0kB time=00:00:00.00 > > bitrate=N/A speed= 0x eed=N/A > > video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > > muxing overhead: 0.000000% > > $ xxd image.raw.rgb > > 00000000: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ > > 00000050: 7f00 3f7f 0000 7f00 3f7f 0000 0000 0000 ..?.....?....... > > 00000060: ffff ffff ffff 7fbf ff7f ffff 7fbf ff7f ................ > > 00000070: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > 00000080: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > 00000090: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > 000000a0: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > 000000b0: ffff ffff ffff ffff ffff ffff ffff ffff ................ > > ``` > > > > FYI: > > ``` > > $ grep processor /proc/cpuinfo |wc -l > > 64 > > ``` > > > > Problem seems to be that `ff_sws_slice_worker()` > > [libswscale/swscale.c:1222] tries to slice the input to parallelize > > the scaling task, in my case in 16 different jobs (gdb'ing the process > > shows `nb_threads == nb_jobs == 16`). The 8x8 input is therefore > > divided in eight 8x1 slices (1-pixel height), which eventually breaks > > in `bayer_to_rgb24_wrapper()` as it asserts `srcSliceH > 1`. The > > problem is the same in the 3 Bayer conversion functions > > (`bayer_to_rgb24_wrapper()`, `bayer_to_rgb48_wrapper()`, and > > `bayer_to_yv12_wrapper()`. > > > > Wondering about the right solution: We could just enforce `nb_threads > > = nb_jobs = 1` for all Bayer inputs. That may be the simplest > > solution. Or we could make sure that `nb_threads` (and `nb_jobs`) are > > capped at `input_height / 2` (to ensure at least 2 pixels per thread). > > > > Any suggestions? > > There already is code that constrains minimum slice size, see > dst_slice_align in utils.c. Would extending that code to handle bayer > input fix the problem? > > -- > Anton Khirnov > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".