On Sat, Jan 10, 2026 at 1:20 AM Nicolas Gaullier via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
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 < ffmpeg-devel@ffmpeg.org> 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|
Okay, adding a warning to the AV1 in TS demuxer and noting in the documentation that it's still in draft status is a good suggestion.