Re: [FFmpeg-devel] [PATCH] ffprobe: fix XML rendering, review XML layout

[Stefano Sabatini <stefasab@gmail.com>]

On date Sunday 2023-10-15 03:09:14 +0200, Timo Rothenpieler wrote:
> On 14.10.2023 19:24, Stefano Sabatini wrote:
> > Fix rendering of int values within a side data element, which was
> > broken since commit d2d3a83ad93, where the side data element was
> > correctly marked as a variable fields element. Logic to render a
> > string variable was implemented already, but it was not implemented
> > for the int fields path, which was enabled by that commit.
> > 
> > Also, code and schema is changed in order to account for multiple
> > variable-fields elements - such as side data, contained within the
> > same parent. Previously it was assumed that a single variable-fields
> > element was contained within the parent, which was the case for tags,
> > but is not the case for side-data.
> > 
> > Previously data was rendered as:
> > <side_data_list>
> >      <side_data side_data_type="CPB properties" max_bitrate="0" min_bitrate="0" avg_bitrate="0" buffer_size="327680" vbv_delay="-1"/>
> > </side_data_list>
> > 
> > Now as:
> > <side_data_list>
> >     <side_data type="CPB properties">
> >         <side_datum key="side_data_type" value="CPB properties"/>
> >         <side_datum key="max_bitrate" value="0"/>
> >         <side_datum key="min_bitrate" value="0"/>
> >         <side_datum key="avg_bitrate" value="0"/>
> >         <side_datum key="buffer_size" value="49152"/>
> >         <side_datum key="vbv_delay" value="-1"/>
> >     </side_data>
> > </side_data_list>
> 

> Isn't a change like that practically an ABI break, and thus would need to
> happen on a major bump?

Yes, but in practice we are not tracking changes in the XML format,
and major bumps are more related to ABI changes rather than to
application level functionality, and probably there are not so many
users using the XML format anyway.

> Alternatively, just leave the old fields as they were, they looks like they
> can coexist with the new ones. At least XML wise.

Yes, but note that compliancy with the XSD is broken since side data
printing addition, so I should fix at least that one, or revert the
change/fix on the compact output (and keep strict XSD schema broken)
which I'd rather not do.

In my view fixing the side data output can be seen as a fix, so it
should not entail a major bump. OTOH I could keep the old layout for
the tags, but that would imply adding a special rule which I would
like to avoid, and having all the tags grouped together has its own
merits (simplifies some queries).

So at the end I think that breaking the format backward-compatibility
is the least evil, and we should be fine with a minor bump.

Alternatively we might even consider to do a major bump, which seems a
bit overkill and might suggest the idea that we are breaking ABI
compatibility, which is not the case here.
_______________________________________________
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".