ToS tagging is up to the application. Many applications don't bother tagging packets at all. Some will always tag a packet the way they want. Some will allow you configure whether application's packets should be tagged and, if so, how ToS is set.
Network devices, generally, by default, ignore ToS tags. If network devices do "something" with different ToS settings, it's up to the network device to determine what that "something" is.
So, unable to say a) how a media tool may, or may not, set a packet's ToS and b) what any particular network device will, or will not, do with different ToS settings.
Even in the case where voice traffic is being tagged with DSCP EF, and network devices are providing such tagged packets with higher priority, such network devices may, or may not, provide same treatment for other DSCP EF tagged packets. (The reason why non-voice traffic also tagged with DSCP EF might not the get same treatment, is because, often, at some point, better sooner than later, network devices will validate the ToS tag is "correct" for the underlying traffic, if it's not, traffic tagged "incorrectly" is usually remarked but might also be dropped too. (This to preclude someone, for example, tagging FTP traffic with DSCP EF. BTW, another approach is not bother to validate underlying traffic is valid for ToS tag, but to restrict resource allocation. For example, at one company, our user gig ports accepted DSCP EF tags for any traffic, but rate limited that traffic to only enough bandwidth to support a couple of VoIP calls. I.e. if you want to send FTP with DSCP EF, it only obtained a phone call's amount of bandwidth. [Oh, and good luck to such a user if they wanted to actually use their VoIP phone at the same time.])
