Oops, forgot to mention, in dshow_pin.c the libAVPin_QueryAccept() have to be edited to almost the same as libAVPin_ReceiveConnection() just without the pin management.
On Mon, Aug 24, 2015 at 10:44 PM, Máté Sebők <smfinc....@gmail.com> wrote: > I did a dirty little hack to attempt to fix it. > Don't call the dshow_add_device() just in build time, but run the graph > and sleep() a bit, then call dshow_add_device() at the end of the > dshow_read_header(). > > Sadly, it does not work, it does not goes beyond the dshow "chit-chat" > between filters/pins. > > After ctrl+c however the right codec stats are displayed... > > Regards, > Máté > > > On Mon, Aug 24, 2015 at 10:29 PM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > >> On Mon, Aug 24, 2015 at 02:09:28PM -0600, Roger Pack wrote: >> > I've run into the case today where (if we understand it correctly) you >> > setup a directshow graph, it advertises media types, then when you >> > "start" the graph, it actually calls through and says "here's your >> > *real* media type". >> > Does ffmpeg internals have any concept of or support for a "changing >> > media type" at runtime? (any other suggestions for how to handle this >> > if it doesn't?) >> >> do i understand correctly that the type at read_header() stage is >> wrong but the type later at read_packet() stage is correct ? >> if that is the case, you can just wait with setting the type till it >> is reliably known. >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> I have never wished to cater to the crowd; for what I know they do not >> approve, and what they approve I do not know. -- Epicurus >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
