Re: [Cellar] "raw" data from scanner
Jerome Martinez <jerome@mediaarea.net> Thu, 26 April 2018 10:00 UTC
Return-Path: <jerome@mediaarea.net>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B9C1200F1 for <cellar@ietfa.amsl.com>; Thu, 26 Apr 2018 03:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XaiJ_qH7b-t for <cellar@ietfa.amsl.com>; Thu, 26 Apr 2018 03:00:50 -0700 (PDT)
Received: from 5.mo68.mail-out.ovh.net (5.mo68.mail-out.ovh.net [46.105.62.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C19112708C for <cellar@ietf.org>; Thu, 26 Apr 2018 03:00:50 -0700 (PDT)
Received: from player730.ha.ovh.net (unknown [10.109.105.14]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 4C829D2410 for <cellar@ietf.org>; Thu, 26 Apr 2018 12:00:47 +0200 (CEST)
Received: from [192.168.2.120] (p5DDB40F7.dip0.t-ipconnect.de [93.219.64.247]) (Authenticated sender: jerome@mediaarea.net) by player730.ha.ovh.net (Postfix) with ESMTPSA id ADCA14400CD for <cellar@ietf.org>; Thu, 26 Apr 2018 12:00:43 +0200 (CEST)
To: cellar@ietf.org
References: <r470Ps-10116i-3E6FE8CFD4314B82A7D3487B2CC4CBE6@Castor.local>
From: Jerome Martinez <jerome@mediaarea.net>
Message-ID: <d4ea785c-3f46-c564-8a01-48b6a7057bc0@mediaarea.net>
Date: Thu, 26 Apr 2018 12:00:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <r470Ps-10116i-3E6FE8CFD4314B82A7D3487B2CC4CBE6@Castor.local>
Content-Type: multipart/alternative; boundary="------------6FA383FB9318841FA17C7F41"
Content-Language: en-GB
X-Ovh-Tracer-Id: 11767342878914777233
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrleefgddvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/H8bwZxr7FYNAcxGZxvGbYh30444>
Subject: Re: [Cellar] "raw" data from scanner
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Apr 2018 10:00:58 -0000
On 26/04/2018 11:57, Reto Kromer wrote: > Jerome Martinez wrote: > >> e.g. with CineForm RAW, issue is to have a usable >> decoder for such stream, it takes time to adapt the CineForm >> RAW decoder source code to something usable for FFV1 encoder >> input), > I personally gave up this approach soon after the code has been > released This is something I don't like too, after having looked at the code. > and in my company we do actually "intercept" the > sensor's data before they are encoded in something I don't like. Whatever is the format, it may be great to have some samples (and description of the storage "format") so we can unblock https://www.ietf.org/mail-archive/web/cellar/current/msg01401.html by providing proof it is OK. Currently, it is a bit chicken and egg issue (I submitted a proposal in theory, but I have nothing for proving it is fine in practice, and looks like spec is expected before testing). > I would like to encode directly into correct, standard, etc. > FFV1 version N (possibly N = 4). That's my point. Sorry for not > haven been clear! IMO using a new colorspace_type is enough and does not mandate a new version, we could stay on v3 (lot of other formats don't upgrade their version when they add new "profiles") if we don't add complexity (e.g. my patch proposal add no complexity to the decoder, it use the same algorithm; if better compression with a different algorithm is found later, it could be in v4)
- [Cellar] "raw" data from scanner Reto Kromer
- Re: [Cellar] "raw" data from scanner Jerome Martinez
- Re: [Cellar] "raw" data from scanner Reto Kromer
- Re: [Cellar] "raw" data from scanner Jerome Martinez