On 1/9/26 16:42, James Almer via ffmpeg-devel wrote:
On 1/9/2026 7:32 AM, Nicolas Gaullier via ffmpeg-devel wrote:
On 1/8/26 08:32, Christophe Gisquet via ffmpeg-devel wrote:
Le jeu. 8 janv. 2026, 02:24, mypopy--- via ffmpeg-devel <
[email protected]> a écrit :
As James Almer pointed out in his response, the current merge request
has already removed the muxer component, so there won't be any
compatibility issues, even if the specification is still in draft
status.
AV1 in TS is already being utilized in certain scenarios, and we also
need an implementation to validate this specification concurrently
Well, I don't particularly like that argument (flv extension again by
some
operator?), but this is beside the point.
I also don't particularly like that argument, but what I do not
understand is why we cannot get a public sample for sharing ?
Kieran is trying to get one.
It seems to me this demuxer-case should require
FF_COMPLIANCE_EXPERIMENTAL.
Why would a demuxer require the user to set that compliance value?
Muxers i understand, but demuxers? Is there ever any reason you'd not
want to have it output something it can handle?
I understand your point because we try to make demuxers robusts and
tolerant to errors, compared to muxers which have to be very strictly
compliants.
The question is to know if you can be certain that the demuxer can
actually handle it, with no pts issues/jerkiness or anything.
I don't have information by myself, just read this thread and it is not
reassuring, not comfortable I feel.
For example, "there was no consensus/decision possible for some of the
features (maybe start code)".
Or "AV1 in TS is already being utilized in certain scenarios", but is it
in some kind of "closed" environment or in the wild ?
We already have scd and mmf demuxers using the compliance value for
similar reasons, so I thought it could be appropriate for some months
before the adoption get more widespread ?
There is also another logic for rtpdec_vp9: a simple AV_LOG_WARNING. If
something goes wrong, the user can realize he is doing something unusual
and that may be the cause.
Anyway, again, I have no information by myself, maybe I am wrong; my
suggestion is to make the user aware of the status of the specs at this
moment. Maybe at least rewording in the texi |"Carriage of AV1 in MPEG-2
TS <specification>" to "<working draft>" as recommended by the banner on
aomediacodec.github.io ?|
|Nicolas|
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
