[FFmpeg-devel] [PATCH 2/2] ffprobe: show seekability details in format section

[Gyan Doshi]

On 2025-04-14 12:57 pm, softworkz . wrote:
>
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Gyan
>> Doshi
>> Sent: Montag, 14. April 2025 08:54
>> To: ffmpeg-devel at 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