I have written a custom media sink (to control a hardware video output board). This had been working as expected for the better part of a year. Things stopped working when I recompiled the sink. I noticed that the Media Foundation libraries and dlls were updated several weeks before the recompile. MFTrace shows that the topology has the expected blocks are connected in the expected topology. The MediaTypes are also proper. When the Presentation Clock is started, I send an MEStreamSinkStarted event followed by a MEStreamSinkRequestSample event. Both events are being read, but ProcessSample is never called. The video file is playing; the audio stream is processed normally. I can play the video file successfully to the EVR through TopoEdit. That the problem occurred after a recompile and not after a Windows update suggests (to me) an interface change of some sort-- perhaps a previously optional function is now required -- but I have not found any reference to a change. I am nearly out of ideas.
Here is the function that queues the sample request:
HRESULT BmDstream::OnStarted(void)
{
OutputDebugString(_T("BmDstream::OnStarted()"));
FAIL_RETURN(QueueEvent(MEStreamSinkStarted, GUID_NULL, S_OK, NULL));
OutputDebugString(_T("BmDstream -- Requesting sample"));
FAIL_RETURN(QueueEvent(MEStreamSinkRequestSample, GUID_NULL, S_OK, NULL));
return (S_OK);
}
'''
Mea culpa (as always). At the same time I recompiled the sink, I made another change that I also suspected, but examined 3 times without finding the bug. I inadvertently instantiated the source twice. One instance was used for the audio, the other for the video. Apparently the video source was never started. Nothing to do with the sink, Windows updates, or anything except me. Aargh!
Related
Some specific IFC files load correctly on web-ifc-viewer, but didn't load on web-ifc-three.
When the file doesn't load, the browser tab freezes. The performance monitor shows 100% of the CPU is used.
After some time, the tab stops responding, and it takes about 10 sec to close it.
Here is the IFC file
It's work on viewer-demo
but didn't work on helloworld
In the console, I can see :
"web-ifc: 0.0.34 threading: 0"
"No basis found for brep!"
"unexpected style type"
Any suggestions will be thankful.
IFC.js has 2 different boolean engines right now: FAST and SLOW. Boolean operations are one of the most complex features in geometry generation in IFC, and sometimes the SLOW procedure is unable to compute the geometry of certain meshes. This will get solved eventually with both procedures.
You can use the fast boolean procedure (which is somewhat less precise in certain meshes but should never crash) changing the configuration of IFC.js like this:
ifcLoader.IfcManager.applyWebIfcConfig ({ USE_FAST_BOOLS: true });
This is unrelated to the messages you see in the console. They are warnings (not errors) of elements that have not been yet implemented in web-ifc. They will also disappear as the library progresses, but you should still be able to see the models and work with them.
I am using the excellent GMFBridge directshow family of filters to great effect, allowing me to close a video recording graph and open a new one, with no data-loss.
My original source graph was capturing live video from standard video and audio inputs.
There is an undocumented method on the GMFBridgeController filter named SetLiveTiming(). From the name, I figured that this should be set to true if we are capturing from a Live graph (not from a file) as is my case. I set this value to true and everything worked as expected
The same capture hardware allows me to capture live TV signals (ATSC in my case), so I created a new version of the graph using the BDA architecture filters, for tuning purposes. Once the data flows out from the MPEG demuxer, the rest of the graph is virtually the same as my original graph.
However, on this ocassion my muxing graph (on the other side of the bridge) was not working. Data flowed from the BridgeSource filter (video and audio) and reached an MP4 muxer filter, however no data was flowing from the muxer output feeding a FileWriter filter.
After several hours I traced the problem to the SetLiveTiming() setting. I turned it off and everything began working as expected. and the muxer filter began producing an output file, however, the audio was not synchronized to the video.
Can someone enlighten me on the real purpose of the SetLiveTiming() setting and perhaps, why one graph works with the setting enabled, while the other fails?
UPDATE
I managed to compile the GMFBridge Project, and it seems that the filter is dropping every received sample because of a negative timestamp computation. However I am completely baffled at the results I am seeing after enabling the filter log.
UPDATE 2: The dropped samples were introduced by the way I launched the secondary (muxer) graph. I inspected a sample using a SampleGrabber (thus inside a streaming thread) as a trigger-point and used a Task.Run() .NET call to instantiate the muxer graph. This somehow messed up the clocks and I ended having a 'reference start point' in the future - when the bridge attempted to fix the timestamp by subtracting the reference start point, it produced a negative timestamp - once I corrected this and spawned the graph from the application thread (by posting a graph event), the problem was fixed.
Unfortunately, my multiplexed video (regardless of the SetLiveTiming() setting) is still out of sync.
I read that the GMFBridge filter can have trouble when the InfTee filter is being used, however, I think that my graph shouldn't have this problem, as no instance of the InfTee filter is directly connected to the bridge sink.
Here is my current source graph:
-->[TIF]
|
[NetworkProvider]-->[DigitalTuner]-->[DigitalCapture]-->[demux]--|-->[Mpeg Tables]
|
|-->[lavAudioDec]-->[tee]-->[audioConvert]-->[sampleGrabber]-->[NULL]
| |
| |
| ->[aacEncoder]----------------
| |--->[*Bridge Sink*]
-->[VideoDecoder]-->[sampleGrabber]-->[x264Enc]--------
Here is my muxer graph:
video
... |bridge source|-------->[MP4 muxer]--->[fileWriter]
| ^
| audio |
---------------------
All the sample grabbers in the graph are read-only. If I mux the output file without bridging (by placing the muxer on the capture graph), the output file remains in sync, (this ended being not true, the out-of-sync problem was introduced by a latency setting in the H264 encoder) but then I can't avoid losing some seconds between releasing the current capture graph, and running the new one (with the updated file name)
UPDATE 3:
The out of sync problem was inadvertently introduced by me several days ago, when I switched off a "Zero-latency" setting in the x264vfw encoder. I hadn't noticed that this setting had desynchronized my already-working graphs too and I was blaming the bridge filter.
In summary, I screwed up things by:
Launching the muxer graph from a thread other than the Application
thread (the thread processing the graph's event loop).
A latency switch in an upstream filter that was probably delaying
things too much for the muxer to be able to keep-up.
Author's comment:
// using this option, you can share a common clock
// and avoid any time mapping (essential if audio is in mux graph)
[id(13), helpstring("Live Timing option")]
HRESULT SetLiveTiming([in] BOOL bIsLiveTiming);
The method enables a special mode of operation which addresses live data. In this mode sample times are converted between the graphs as relative to respective clock start times. Otherwise, the default mode is to expect reset of time stamps to zero with graph changes.
I am using a complex state engine system build with Qt 5.4 (using custom state engine classes).
Part of that code is logging of events, transitions, etc. It is very important for me to log all events the engine/state objects are receiving so I can completely track what is happening in the state engines.
For most event types logging is easy. However I failed to log queued connections (i.e. meta call events). QMetaCallEvent is private so there is not much I can do. However it is hard to believe that such an integral part of Qt can not be inspected properly.
Is there some way I missed that allows to log queued connections (including signal name, slot name, sender name, receiver name and arguments if possible)?
Install an event filter and intercept events with ev->type() == QEvent::MetaCall. All members visible in the debugger.
Need access to private headers? Use QT += core-private in your .pro file.
(tone mode="original poster")It's hard to believe that nobody reads documentation(/tone)
There is no official API that allows to do what I intend.
Inspecting QMetaCall events (using private framework headers) is a bad idea. First they are private (and may break your code any time) second the QMetaCall event sender() pointer may be invalid if sender was deleted immediately and I could not find a clean way to inspect events in such cases.
The way I am using now is totally different. Instead of inspecting the arriving event objects I am using a modified variant of QSignalSpy that allows to do more than the original class and helps logging the signal emissions using secondary connections.
In my situation this seems feasible even if it is pretty complicated and not a universal solution. At least no private headers are involved.
when using FlexPrintJob, after calling start(), a OS system print interface will appear, and at the same time Flex code execution will be paused, and it will remain paused until user finished interaction with the OS print dialog. the problem is I do have data from server, and the connection will time out within certain period, so is there any walk around to not pause the Flex code execution while OS print dialog is popped up. Thanks.
From the doc for FlexPrintJob:
You use the FlexPrintJob class to print a dynamically rendered document that you format specifically for printing.
This makes me wonder if you couldn't (essentially) fork off a second page from the browser that contains your print job and do the printing from there. This would leave your original page still running. In my flex apps I do this via PHP (create additional pages for printing and such). Example here.
Otherwise: you should finish all the server data d/l before starting the print job to avoid this issue.
Flex is only just recently starting to add multi-threading. It's adding worker threads of a sort but this won't help what you're asking for.
and by unresponsive I mean that after the first three successful connections, the fourth connection is initiated and nothing happens, no crashes, no delegate functions called, no data is sent out (according to wireshark)... it just sits there?!
I've been beating my head against this for a day and half...
iOS 4.3.3
latest xCode, happens the same way on a real device as in the simulator.
I've read all the NSURLConnection posts in the Developer Forums... I'm at a loss.
From my application delegate, I kick off an async NSURLConnection according to Apple docs, using the App Delegate as the delegate for the NSURLConnection.
From my applicationDidFinishLaunching... I trigger the initial two queries which successfully return XML that I then pass off to a OperationQueue to be parsed.
I can even loop, repeating these queries with no issues, repeated them 10 times and worked just fine.
The next series of five queries are triggered via user input. The first query runs successfully and returns the correct response, then the next query is created and when used to create a NSURLConnection (just like all the others), just sits there.?!
The normal delegate calls I see on all the other queries are never seen.
Nothing goes over the wire according to Wireshark?
I've reordered the queries and regardless of the query, after the first one the next one fails (fails as in does nothing, no errors or aborts, just sits there)
It's obviously in my code, but I am blind to it.
So what other tools can I use to debug the async NSURLConnection... how can I tell what it's doing? if at all.
Any suggestions for debugging a NSURLConnection or other ways accomplish doing the same thing a NSURLConnection does??
Thanks for any help you can offer...
OK tracked it down...
I was watching the stack dump in each thread as I was about to kick off each NSURLConnection, the first three were all in the main thread as expected... the fourth one ended up in a new thread?! In one of my NSOperation thread?!?!
As it turns out I inadvertently added logic(?) that started one my NSURLConnection in the last NSOperation call to didFinishParsing: so the NSURLConnection was async started and then the NSOperation terminated... >.<
So I'll move the NSURLConnection out of the didFinishParsing and it should stay in the main loop and I should be good!