[FFmpeg-devel] Re: [PATCH] av1_in_ts_v2 (PR #21307)

[Nicolas Gaullier via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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|

_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org