John Högberg wrote: > Hi, > > libavformat currently doesn't provide any mechanism for detecting when a > substream is no longer present but the stream as a whole is otherwise OK. Your > best guess is to check when you last got any frames on it, which tends to work > for video and audio but not for substreams that sometimes spend a long amount > of > time without presenting anything, like subtitles. > > Why is this an issue? Formats like MPEG-TS and MSS in push/ingest mode have > separate transports for each stream; audio, video, and subtitles come from > separate sources. If one of these breaks you have a fairly big problem on your > hands, but returning an error on av_read_frame would be a bad course of action > -- it may just be that the broadcaster has switched to regional news or > similar > which lacks subtitles or only runs one audio track, and things will return to > normal once it's over. > > Put shortly, the API user needs to know that something is potentially broken, > but without preventing further processing of the stream. > > This is my fourth proposal for a method of carrier loss detection. I've given > up > the ideas of having it edge-triggered and trying to hide format-specifics from > the API user, so it's now a level-triggered event denoting the presence of a > carrier which can be queried if the format has the (new) AVFMT_SEPCARRIERS > flag. > > -- > > AVFMT_SEPCARRIERS is a new flag denoting that the format has a separate > carrier > for each stream, e.g. a separate file, transport stream, or connection per > stream. > > AVSTREAM_EVENT_FLAG_CARRIER_PRESENT is a new event indicating the presence of > a given stream, and is relevant for formats with the above flag. Its operation > is fairly simple; all it does is indicate that the stream was alive/present > since the last time the event flags were cleared, and is distinct from there > being actual data on the stream. > > -- > > If accepted I'll submit an implementation for MPEG-TS since I figure it's > pointless to clutter the mailing list with it before that. > > Regards, > John Högberg
Ping. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
