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-requ...@ffmpeg.org with subject "unsubscribe".
