From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ffmpeg-devel-bounces@ffmpeg.org>
Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100])
	by master.gitmailbox.com (Postfix) with ESMTPS id 208064CD74
	for <ffmpegdev@gitmailbox.com>; Mon, 14 Apr 2025 06:54:14 +0000 (UTC)
Received: from [127.0.1.1] (localhost [127.0.0.1])
	by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id E262C687CA2;
	Mon, 14 Apr 2025 09:54:09 +0300 (EEST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152])
 by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id F2852687BCD
 for <ffmpeg-devel@ffmpeg.org>; Mon, 14 Apr 2025 09:54:02 +0300 (EEST)
Received: from smtp102.mailbox.org (smtp102.mailbox.org
 [IPv6:2001:67c:2050:b231:465::102])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256)
 (No client certificate requested)
 by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4ZbdLJ04NQz9v9m
 for <ffmpeg-devel@ffmpeg.org>; Mon, 14 Apr 2025 08:54:00 +0200 (CEST)
Message-ID: <4a2589b9-3952-437b-ae2a-c840f8fb591f@gyani.pro>
Date: Mon, 14 Apr 2025 12:23:57 +0530
MIME-Version: 1.0
To: ffmpeg-devel@ffmpeg.org
References: <20250413111545.4619-1-ffmpeg@gyani.pro>
 <20250413111545.4619-2-ffmpeg@gyani.pro>
 <DM8P223MB0365B8C3EDA17E5CAC6414D3BAB02@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
 <ebac78d5-578b-4ff4-ba3f-797f952adfa1@gyani.pro>
 <DM8P223MB03656CAE5F3A772BAF522CB6BAB32@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
Content-Language: en-US
From: Gyan Doshi <ffmpeg@gyani.pro>
In-Reply-To: <DM8P223MB03656CAE5F3A772BAF522CB6BAB32@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM>
X-Rspamd-Queue-Id: 4ZbdLJ04NQz9v9m
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
Subject: Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in
 format section
X-BeenThere: ffmpeg-devel@ffmpeg.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: FFmpeg development discussions and patches <ffmpeg-devel.ffmpeg.org>
List-Unsubscribe: <https://ffmpeg.org/mailman/options/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=unsubscribe>
List-Archive: <https://ffmpeg.org/pipermail/ffmpeg-devel>
List-Post: <mailto:ffmpeg-devel@ffmpeg.org>
List-Help: <mailto:ffmpeg-devel-request@ffmpeg.org?subject=help>
List-Subscribe: <https://ffmpeg.org/mailman/listinfo/ffmpeg-devel>,
 <mailto:ffmpeg-devel-request@ffmpeg.org?subject=subscribe>
Reply-To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: ffmpeg-devel-bounces@ffmpeg.org
Sender: "ffmpeg-devel" <ffmpeg-devel-bounces@ffmpeg.org>
Archived-At: <https://master.gitmailbox.com/ffmpegdev/4a2589b9-3952-437b-ae2a-c840f8fb591f@gyani.pro/>
List-Archive: <https://master.gitmailbox.com/ffmpegdev/>
List-Post: <mailto:ffmpegdev@gitmailbox.com>



On 2025-04-14 10:22 am, softworkz . wrote:
>>> Hi Gyan,
>>>
>>> the problem that I see here is that it's not machine-readable and
>> would require non-trivial parsing to translate back to the actual
>> information behind it.
>>> I think that either a separate sub-section or at least three separate
>> values would be better.
>>
>> I can add a delimiter like |
>>
>> e.g.
>>
>> yes|time(pts),frame-index|demuxer,packet-scan|fast
>>
>> All of the phrases for an attribute are unique, and for that, they just
>> need to grep, not parse the string.
>> Most CLI users will only care about two things: yes/no and forward-only.
> When processing data using formats like XML or JSON by software, there is no "grep".
> Machine-readable means (not only but including) that no additional parsing needs to be done. The XML schema must indicate the possible values and I don't believe that a pipe-delimited multi-string value can be described with an XML schema.

That would require one field for each bit i.e.

seekable_normal=yes
seekable_protocol=no
seekable_via_demuxer=yes
...

That seems like too much bloat for CLI usage.
Any workflow that needs to *take action* based on the seek features, as 
opposed to data archival, should have access to string parsing tools.

How about two fields:

seekability=no
seek-features=n/a

seekability=yes
seek-features=a,b,c|d,e,f|g,h,i

Regards,
Gyan
_______________________________________________
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".