Le quintidi 5 thermidor, an CCXXV, Maksym Veremeyenko a écrit : > according to SDK documentation terminology, *source* and *find* used for > this, there are no actual *devices* but only network sources.
This is a case where we have two opposite requirements: consistency within FFmpeg or consistency with other NDI applications. In this particular case, I think consistency within FFmpeg is more important. But also remember that options can have several names, that would eliminate the problem. > it has internal queue, but the main goal of using AVPacketQueue is to avoid > loosing packets during *probe* operation, if we discard this (ignore that > packets or i find how deal in a case of AVFMTCTX_NOHEADER) then all > decklink's AVPacketQueue code could be dropped You have nothing special to do if using AVFMTCTX_NOHEADER: create no stream in read_header(), in read_packet() create streams as needed (the first time a video packet arrives, create the video stream, idem for audio), and libavformat takes care of everything else: probing the packets until properties are known, buffering the packets, etc. If this API can be read without an explicit thread in the application, then by all means get rid of all the threading code. Running components in separate threads is better done with generic code. > i can suppress printing found sources until find_sources specified I think that is exactly what Marton meant. Regards, -- Nicolas George
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
