On Sun, Feb 23, 2020 at 8:15 AM Gyan Doshi <ffm...@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 <ffm...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
