Why is this necessary? If the alignment and stream-format fields are available in the caps you can assume correctly framed h264

Is there anywhere the list of all caps with description?
I guess stream-format implies parsed, and alignment
implies framed, but then, is it specific to h264 parser,
or is it common?
I assume that framed and parsed are common, so I can
just use those, instead of testing for the list of caps
I have no idea about. And these are booleans, while
stream-format/alignment are strings.
I just need the _simplest_ way to find out that the
stream is parsed and framed, so what would it be?

I tested my packetizer plugin with aacparse and ac3parse, and
I used parsed/framed because these parsers sets those.
It would be an inconvenience to adapt my plugin for every
other parser: it is better to get all the parsers to set the
needed common caps, that's the idea.

That's not standardized and you have to do it different for the different formats. What do you intend to do with parsed/framed streams for which you don't do anything format specific?

Basically, I use "framed" streams to assume the good
pes packet sizes, and I use "parsed" as a grant of
the timestamps presence. Of course it is possible to
packetize the unparsed and unframed stream, but the
result will be of no practical use I suppose.
Also, why do you see wrong to let all the parsers/framers
to set parsed/framed where appropriate? If these 2 booleans
where not standardized before, lets just do that right here,
right now. :)

OK, I've found this:
https://bugzilla.gnome.org/show_bug.cgi?id=606662
So the problem with framed=true is that it doesn't give
enough info, like the "alignment" does. But the reason
for removing it was not clearly stated, and it might
happen that some packetizer do not care about the particular
alignment in use, so it may go on with just "framed=true".
As for "parsed" - I guess I'll get rid of that one since
its vague. And it was _removed_ from h264parse at some
point, while "framed" was never removed (nor added) AFAICS.

So my question reduces to why not to add only "framed" for
some poor packetizers.

> As for "parsed" - I guess I'll get rid of that one since
> its vague.
But then there is no cap to indicate the presence
of timestamps that I use for pts...

I don't see a bug here.

If you want framed data, specify what kind of framing you want in the pad template caps.  H.264 has multiple bitstream formats and framing options, so a true/false will never work.

What if I need _any_ reasonable framing to just
packetize the stream into PES?

Where would you need any framing?

When packetizing... but I guess I need the
AU boundaries for PES anyway, so nevermind.