On 2025-04-14 12:57 pm, softworkz . wrote:
-----Original Message-----
From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Gyan
Doshi
Sent: Montag, 14. April 2025 08:54
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability
details in format section
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.
Start thinking from the other side: You want to define a class (be it Python,
C#, Java, TypeScript or whatever) which corresponds to the FFprobe format
output in a way that you can work with it efficiently in that application and
then you serialize that class - that's how the output should be.
For the representation of bitfields in the output, there are multiple ways.
One way is like it's done for disposition:
JSON:
"disposition": {
"default": 0,
"dub": 0,
"original": 0,
"comment": 0,
"lyrics": 0,
"karaoke": 0,
"forced": 0,
"hearing_impaired": 0,
"visual_impaired": 0,
"clean_effects": 0,
"attached_pic": 0,
"timed_thumbnails": 0,
"non_diegetic": 0,
"captions": 0,
"descriptions": 0,
"metadata": 0,
"dependent": 0,
"still_image": 0,
"multilayer": 0
},
another way would be a list of predefined (enum) values:
which would look as follows in JSON:
"disposition": ["original", "dub"],
In an xml schema, the latter can be defined like this:
<xs:element name="Flags">
<xs:complexType>
<xs:sequence maxOccurs="unbounded">
<xs:element name="disposition">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="original"/>
<xs:enumeration value="dub"/>
<xs:enumeration value="lyrics"/>
<!-- ... -->
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
Then the XML would look like this:
<MyElement>
<disposition>
<dispositionvalue>original</dispositionvalue>
<dispositionvalue>dub</dispositionvalue>
</disposition>
</MyElement>
That seems like too much bloat for CLI usage.
Whether it's "bloat" or not only depends on the output format.
In the default or flat format this might probably condense to a
Bloat in terms of number of fields, not necessarily size of textual
representation.
I'll think I'll only report seekability and its directionality for now.
The other data is academic for now.
When I extend the seek options in ffmpeg is when I'll extend the reporting.
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".
