[FFmpeg-devel] [PATCH] ffprobe: show stream id in packets and frames

[Jan Ekström]

On Sun, Feb 23, 2020 at 8:15 AM Gyan Doshi <ffmpeg at gyani.pro> wrote:
>
>
>
> On 20-02-2020 10:05 am, Gyan Doshi wrote:
> >
> >
> > On 20-02-2020 04:52 am, Jan Ekström wrote:
> >> Hi,
> >>
> >> On Wed, Feb 19, 2020 at 8:31 AM Gyan Doshi <ffmpeg at gyani.pro> wrote:
> >>> Required for reliably identifying streams in MPEGTS-like live inputs.
> >>> ---
> >> Can you please explain to me how would this be any different from
> >> adding `-show_programs -show_streams` and checking out the listing of
> >> those first?
> >
> > It saves some steps in shell scripts,  avoiding having to correlate
> > stream index with id.
>
> Any more comments?
>
> Gyan

Thanks for being honest. I had some tired days and couldn't respond
right away, unfortunately.

Now, the problem is that ffprobe in general is a thing that at least
on a general look dumps the structures as they come from the API. You
have AVStreams under streams, AVPrograms under programs, AVPackets
under packets, AVFrames (and AVSubtitles) under frames and so forth.
This basically breaks that general rule/abstraction, since AVPackets
do not have stream_ids there (right now).

And in this case, such a filtering would only work if you already know
the exact PID(s) you are interested in. As in, "I do not need to look
at the stream or program->stream listing at all for extra
information". That in a more general case tends to usually not be the
case. Only problem that I can recall for simpler scripts is that the
streams and programs tend to get dumped after the rest of the things,
not before it, If I recall correctly (this makes sense as the state of
those could change between the start of parsing and the end of
parsing). If this is the case, and you want to parse things in a live
"stream of data" (as in, not finishing up a full "document" as one
does with XML or JSON output), then that could be done with a separate
option. But of course limited to the state of programs and streams at
the start of processing. Alternatively then that data could be updated
during parsing if the format enables duplicate entries.

Thus I think there are multiple ways forward with this:
1. Find a reasoning to also add the stream_id to be included in
AVPacket (generally speaking possibly unlikely, since in the API you
can just reference the relevant AVStream). That way it would become a
part of AVPacket and thus the dump would be to OK to have that
included.
2. I am still not 100% sure what your shell scripts would be doing,
but possibly implementing stream id based stream selection in ffprobe
as an application could be useful if you are attempting to filter out
all other streams than PIDs X,Y,Z (since I think ffmpeg.c already has
this implemented)? You will still have to parse the programs->streams
or streams to figure out which is which if you want to select multiple
at a time, but at least in case of singular PIDs this should simplify
your life?
3. If ffprobe currently outputs the streams and programs at the end
and that is a problem with the streaming data that you feed into your
shell script, make that configurable with possibly streaming updates
for formats that support that? That way you still will have to parse
those streams, but it becomes possible to do it in a streaming manner
in case that is your issue currently.

Best regards,
Jan