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

[mypopy--- via ffmpeg-devel <ffmpeg-devel@ffmpeg.org>]

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.
_______________________________________________
ffmpeg-devel mailing list -- ffmpeg-devel@ffmpeg.org
To unsubscribe send an email to ffmpeg-devel-leave@ffmpeg.org