I've created a topology for a video file which contains just one stream (no audio).
It contains three nodes which are connected in order:
a source stream node
an Mpeg4Part2VideoDecoder as transform node
an activate object for the EVR as output node
Calling SetTopology(), allowing for a partial topology results in working playback. However, I am trying to resolve the full topology myself.
Therefore, I first need to bind my output node to a media sink. I followed the guidelines specified in the manual, and all the required calls seem to succeed. When setting the full topology, I receive the MESessionTopologySet event.
Unfortunately, playback doesn't work, but I don't get any errors.
Is there anything else required when creating a full topology?
I recall reading somewhere in the msdn docs that the topology loader which is used when setting a partial topology also sets media types. Is this required, and if so where can I find more information on this?
Matt Andrews answered this one for me on the msdn forums.
You definitely need to negotiate your own media types if you are
bypassing the topology loader. This means obtaining the source's
media type from IMFMediaTypeHandler, setting it on the downstream
transform, and then for each node down the chain, querying the
available input and output types to find a compatible media type. It
is much easier to use the topoloader unless you have a specific need
to avoid it.
Related
The deviceManagement/manageddevices Intune Graph API results always return an empty array for the roleScopeTagIds property of all devices. Can anyone explain why or better yet, how to include those values?
If you supply the GUID for a device and call the same endpoint then the correct data is returned for the roleScopeTagIds property. Also, I get an "Invalid filter clause" error if I try to filter by the roleScopeTagIds property also.
thanks for your question. The behavior you are observing for the filtering and for device list API is by design.
Device list API:
In our initial implementation we did not want to query all scope tags for all the devices as we do not cap the number of scope tags that can be applied to a given device. The size of the data returned could potentially get large. So we decided to only return all scope tags when you select a single device.
Filtering:
As of now we do not support filtering on device scope tags to optimize overall latency for the device list. We do support other wide range of filters. Hope this helps.
We would like to learn more about your use case for fetching all applied scope tags at once.
As jcurl says it would be realy nice to have roleScopeTags directly via graph and being able to filter on them.
To build a complete list of these for devices i ended up using batched queries to lower the amount of api calls needed (by 20).
I created a uservoice to get more possibilities on this
the use case we have is generating PBI insights with filtering similiar like with Intune - which is based on the Scope Tags.
The general idea is to populate the scope's tags within all device polling through graph - which unfortunatle returns "empty" array
As you might be aware the Datawarehouse in majority of cases doesnt provide up to date information.
I have a plan of writing a small command line tool that does the following (without getting into details):
Listen for input stream (a tail of some files)
Parse incoming data and update screen information real-time (like the top command does for example)
Untill the application is being quited (CTLR + C) it will be updating (not appending!) the information on the screen.
I prefer to work with the Symfony console.
Since they have for example the progress-bar I expect it to be doable, since the progress-bar does update the screen. (However, I don't need an actual progressbar).
Keep listening for an input stream and keep updating when information comes in is something I am not sure about to be possible in this manner.
I can't find enough information on how to do this. Does anyone know if this is possible and what components I would need to:
Listen for input stream and trigger an event when information comes in
Update screen information
Any help would be appreciated.
Update:
For now I built the tool without using any framework. I wrote it myself by using this "Listening for incoming streams" example and this "setting cursor position" example (and ofcourse this referenced overview of commands).
However I still would like to know whether and how this would be possible using Symfony's console components.
Given two codecs with the same merit value, how does DirectShow decide which one to use through the 'intelligent connect' mechanism?
It throws a dice.
Seriously the behavior is undefined, both decoders have chances to be taken first. In case of rejection, filter graph would try the other one.
The intelligent connect msdn page sheds some light on this.
Starting from Windows 7, a new system is used, and the merit system is only used as a fallback when no filter is found after searching for one using the new approach.
Starting in Windows 7, DirectShow has a list of preferred filters for
certain media subtypes. If there is a preferred filter for the media
type that is being rendered, the Filter Graph Manager tries that
filter next. An application can modify the list of preferred filters
by using the IAMPluginControl interface. Changes to the list affect
the application's current process, and are discarded after the process
ends.
In case the merit system is used, the msdn page only mentions the following:
Then it tries them in order of merit, from highest to lowest. (It uses additional criteria to choose between filters with equal merit.)
I have found some broken threads across the web where people claim to be able to use receive shapes in an orchestration with XLANGMessage types to receive flat file schema files that could not be assembled into a specific xsd.
I've attempted to set the messagetype in the receive shape as Microsoft.XLANGS.BaseTypes.XLANGMessage, but this basetype is not serializable. This then causes a build error.
Is there an object type that can capture both XmlDocuments of well formed xml messages as well as malformed xml and non-assembled flat files?
In answer to your direct question in bold - yes, the type you are after is System.Xml.XmlDocument.
What you need to do is create a new message and when selecting its type, select the above type from the .NET Classes section.
This message when assigned to a receive shape can then receive any payload, for example, I've often used this to pass formats such as .pdf files through BizTalk where I had no need to parse them. Do be aware, however, that despite the name, what you have here is not Xml and will cause you all sorts of issues if you try and treat is as such.
To dig a little further into your question - are you trying to make some sort of error handling orchestration?
If you are then in your error handling code you can just have a recieve shape that receives a message of type XmlDocument with its filter expression set to ErrorReport.ErrorType == "FailedMessage" that is bound to a direct bound port attached to the Message Box.
I've often found it handy to have two receive shapes, one to catch routing failures, when we have any possible payload, and another to subscribe to a strongly types fault wrapper envelope that you define and pass out of your other orchestrations from their CatchException shapes.
This means that you can then build one centralised place to handle all exceptions.
If you haven't seen it, there is a nice post by Charles Young that may describe something similar to what you are trying to do.
I have a resource that has a counter. For the sake of example, let's call the resource profile, and the counter is the number of views for that profile.
Per the REST wiki, PUT requests should be used for resource creation or modification, and should be idempotent. That combination is fine if I'm updating, say, the profile's name, because I can issue a PUT request which sets the name to something 1000 times and the result does not change.
For these standard PUT requests, I have browsers do something like:
PUT /profiles/123?property=value&property2=value2
For incrementing a counter, one calls the url like so:
PUT /profiles/123/?counter=views
Each call will result in the counter being incremented. Technically it's an update operation but it violates idempotency.
I'm looking for guidance/best practice. Are you just doing this as a POST?
I think the right answer is to use PATCH. I didn't see anyone else recommending it should be used to atomically increment a counter, but I believe RFC 2068 says it all very well:
The PATCH method is similar to PUT except that the entity contains a
list of differences between the original version of the resource
identified by the Request-URI and the desired content of the resource
after the PATCH action has been applied. The list of differences is
in a format defined by the media type of the entity (e.g.,
"application/diff") and MUST include sufficient information to allow
the server to recreate the changes necessary to convert the original
version of the resource to the desired version.
So, to update profile 123's view count, I would:
PATCH /profiles/123 HTTP/1.1
Host: www.example.com
Content-Type: application/x-counters
views + 1
Where the x-counters media type (which I just made up) is made of multiple lines of field operator scalar tuples. views = 500 or views - 1 or views + 3 are all valid syntactically (but may be forbidden semantically).
I can understand some frowning-upon making up yet another media type, but I humbly suggest it's more correct than the POST / PUT alternative. Making up a resource for a field, complete with its own URI and especially its own details (which I don't really keep, all I have is an integer) sounds wrong and cumbersome to me. What if I have 23 different counters to maintain?
An alternative might be to add another resource to the system to track the viewings of a profile. You might call it "Viewing".
To see all Viewings of a profile:
GET /profiles/123/viewings
To add a viewing to a profile:
POST /profiles/123/viewings #here, you'd submit the details using a custom media type in the request body.
To update an existing Viewing:
PUT /viewings/815 # submit revised attributes of the Viewing in the request body using the custom media type you created.
To drill down into the details of a viewing:
GET /viewings/815
To delete a Viewing:
DELETE /viewings/815
Also, because you're asking for best-practice, be sure your RESTful system is hypertext-driven.
For the most part, there's nothing wrong with using query parameters in URIs - just don't give your clients the idea that they can manipulate them.
Instead, create a media type that embodies the concepts the parameters are trying to model. Give this media type a concise, unambiguous, and descriptive name. Then document this media type. The real problem of exposing query parameters in REST is that the practice often leads out-of-band communication, and therefore increased coupling between client and server.
Then give your system a uniform interface. For example, adding a new resource is always a POST. Updating a resource is always a PUT. Deleting is DELETE, and getiing is GET.
The hardest part about REST is understanding how media types figure into system design (it's also the part that Fielding left out of his dissertation because he ran out of time). If you want a specific example of a hypertext-driven system that uses and doucuments media types, see the Sun Cloud API.
After evaluating the previous answers I decided PATCH was inappropriate and, for my purposes, fiddling around with Content-Type for a trivial task was a violation of the KISS principle. I only needed to increment n+1 so I just did this:
PUT /profiles/123$views
++
Where ++ is the message body and is interpreted by the controller as an instruction to increment the resource by one.
I chose $ to deliminate the field/property of the resource as it is a legal sub-delimiter and, for my purposes, seemed more intuitive than / which, in my opinion, has the vibe of traversability.
I think both approaches of Yanic and Rich are interresting. A PATCH does not need to be safe or indempotent but can be in order to be more robust against concurrency. Rich's solution is certainly easier to use in a "standard" REST API.
See RFC5789:
PATCH is neither safe nor idempotent as defined by [RFC2616], Section
9.1.
A PATCH request can be issued in such a way as to be idempotent,
which also helps prevent bad outcomes from collisions between two
PATCH requests on the same resource in a similar time frame.
Collisions from multiple PATCH requests may be more dangerous than
PUT collisions because some patch formats need to operate from a
known base-point or else they will corrupt the resource.