I am working on an application that features IIS Smooth Streaming using the SmoothStreamingMediaElement. Because of the nature of the project I can't disclose the source of the stream, I can however provide full technical information on the problem I encounter.
I seperated the SmoothStreaming part into a seperate application for testing purposes. Everything seems to be working well since the test stream provided by Microsoft works the way it should (http://video3.smoothhd.com.edgesuite.net/ondemand/Big%20Buck%20Bunny%20Adaptive.ism/Manifest)
I took the restrictions for SmoothStreaming on Windows Phone into account:
- In the ManifestReady event the available tracks are filtered to show only one available resolution
- The device is not connected through Zune while testing.
The error message presented is very clear:
"3108 Insufficient content duration available to begin playback.
Available = 3840 ms, Required = 7250 ms"
I have not been able to find any references to this error. I did find some more information on where the required duration of 7250 ms originates from. This MSDN page suggests it has something to do with the LivePlaybackOffset which defaults at 7 seconds and cannot be changed in the WP7 SmoothStreamingMediaElement. The same code works fine in a browser-silverlight application.
I don't have direct access to the server providing the stream. Is there a way to address this issue clientside? Or does it require server-side configuration? If it helps I can share parts of the source code, please let me know what parts would be relevant. Your help is highly appreciated!
This is the manifest file:
<SmoothStreamingMedia MajorVersion="2" MinorVersion="2" TimeScale="10000000" Duration="0" LookAheadFragmentCount="2" IsLive="TRUE" DVRWindowLength="300000000">
<StreamIndex Type="audio" QualityLevels="1" TimeScale="10000000" Name="audio" Chunks="7" Url="http://xxxx/xxx.isml/QualityLevels({bitrate})/Fragments(audio={start time})">
<QualityLevel Index="0" Bitrate="128000" CodecPrivateData="1190" SamplingRate="48000" Channels="2" BitsPerSample="16" PacketSize="4" AudioTag="255" FourCC="AACL"/>
<c t="3485836800000" d="38400000" r="7"/>
</StreamIndex>
<StreamIndex Type="video" QualityLevels="6" TimeScale="10000000" Name="video" Chunks="7" Url="http://xxxx/xxx.isml/QualityLevels({bitrate})/Fragments(video={start time})" MaxWidth="1024" MaxHeight="576" DisplayWidth="1024" DisplayHeight="576">
<QualityLevel Index="0" Bitrate="350000" CodecPrivateData="000000016742E01596540D0FF3CFFF80980097A440000003004000000CA10000000168CE060CC8" MaxWidth="405" MaxHeight="228" FourCC="AVC1" NALUnitLengthField="4"/>
<QualityLevel Index="1" Bitrate="700000" CodecPrivateData="000000016742E01E965404814F2FFF8140013FA440000003004000000CA10000000168CE060CC8" MaxWidth="568" MaxHeight="320" FourCC="AVC1" NALUnitLengthField="4"/>
<QualityLevel Index="2" Bitrate="1000000" CodecPrivateData="000000016742E01E965405217F7FFE0B800B769100000300010000030032840000000168CE060CC8" MaxWidth="654" MaxHeight="368" FourCC="AVC1" NALUnitLengthField="4"/>
<QualityLevel Index="3" Bitrate="1300000" CodecPrivateData="00000001674D4028965605819FDE029100000300010000030032840000000168EA818332" MaxWidth="704" MaxHeight="396" FourCC="AVC1" NALUnitLengthField="4"/>
<QualityLevel Index="4" Bitrate="1600000" CodecPrivateData="00000001674D402A965605A1AFCFFF80CA00CAA440000003004000000CA10000000168EA818332" MaxWidth="718" MaxHeight="404" FourCC="AVC1" NALUnitLengthField="4"/>
<QualityLevel Index="5" Bitrate="2000000" CodecPrivateData="00000001674D4032965300800936029100000300010000030032840000000168E96060CC80" MaxWidth="1024" MaxHeight="576" FourCC="AVC1" NALUnitLengthField="4"/>
<c t="3485836800000" d="38400000" r="7"/>
</StreamIndex>
</SmoothStreamingMedia>
I know this question is a bit old but I had a very similar problem today, so I thought I should answer it...
The problem is with the r="7"
This parameter is not documented in the MS documentation and only found in Smooth Streaming version 2.2 and above (not 2.0).
r="7" means that the chunk in the manifest should be repeated 7 times, which means you have 7 * 3.84 sec in total.
There is a blog post which explains it here:
http://blogs.iis.net/samzhang/archive/2011/03/10/how-to-troubleshoot-live-smooth-streaming-issues-part-5-client-manifest.aspx
Related
I am working on a windows phone app that can scan BLE devices. I have implemented the logic which is showing the desired devices.
But the problem is that if I remove those devices or switch them off, even then my application returns their names in scan result. I think it is returning cached result. How I can make sure it will show only those devices which are available/present.
I have tried using the additional properties i.e. System.Devices.Aep.IsPresent etc in scan but they are coming as null in result no matter ble devices available or not.
Here is code snippet I am using -
string[] requestedProperties = new string[] { "System.Devices.Aep.IsPresent"
, "System.Devices.Present"
, "System.Devices.Connected"
, "System.Devices.Paired"
, "System.Devices.Aep.IsConnected"
, "System.Devices.AepContainer.IsPresent"
};
diCollection = await DeviceInformation.FindAllAsync(GattDeviceService.GetDeviceSelectorFromUuid(serviceUuid)
, requestedProperties
);
foreach (var diItem in diCollection)
{
Debug.WriteLine("Discovered Device name - " + diItem.Name);
Debug.WriteLine("Discovered Device Additional Properties Below");
foreach (var item in diItem.Properties)
{
Debug.WriteLine("Key-{0} Value-{1}", item.Key, item.Value);
}
}
Here is the Package.appxmanifest capabilities used -
<Capabilities>
<Capability Name="internetClientServer" />
<DeviceCapability Name="bluetooth" />
</Capabilities>
Please help me resolve this small issue. Am I missing something trivial here?
Thanks in advance.
-Jitender
I tried every single one of the properties below with 2 PCs, where both were paired to the Handheld and only one was turned on and a Windows Handheld 8.1.
https://learn.microsoft.com/en-us/windows/uwp/devices-sensors/device-information-properties
The ones needed were AssociationEndpoint related properties, none of which are supported in windows phone 8.1 (even the enumeration is not available) - so basically the api does not provide any way for us to be able to query the connections from cache for whether they are presently available or not.
I tested with every combinations and they do not provide sufficient information (the PC that is turned on is indistinguishable from the one that was not).
The only workaround was to connect to every paired computer on the cache and see if each connection was successful to add this to the list displayed if succeeeded. Every failed connection takes ~4-5 seconds. So this can take some significant amount of delay in showing the list if there are multiple paired computers via in the past. Yet I could not find any other feasible way of checking this, at least this resolves the issue.
I have a Visual Studio web performance test that I am planning on running with a variety of network mixes to simulate different network conditions. However when I report this I would like to know context of this (actual bandwidth, latency in ms, etc.). The best information I've found is this: http://msdn.microsoft.com/en-us/library/dd997557.aspx
Specifically what I would like to know is: What is the intra-continental connection's properties?
Is there a better reference on this?
As said by AdrianHHH, you can find *.network file for each of available network profile at %ProgramFiles%\Microsoft Visual Studio XXX\Common7\IDE\Templates\LoadTest\Networks e.g.IntracontinentalWAN.network. This file contains all settings for a network file like Latency, Packet Loss, Queue Management etc.
A good description of all properties are available here. There is not problem to edit an existing profile and to create a new one just for your specific
So, the intra-continental connection's properties are
<NetworkEmulationProfile name="Intra-continental WAN 1.5 Mbps" xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Emulation>
<VirtualChannel name="ICWAN-Channel2">
<FilterList />
<VirtualLink instances="1" name="link1">
<LinkRule dir="upstream">
<Bandwidth>
<Speed unit="kbps">1500</Speed>
<QueueManagement>
<NormalQueue>
<Size>100</Size>
<QueueMode>packet</QueueMode>
<DropType>DropTail</DropType>
</NormalQueue>
</QueueManagement>
</Bandwidth>
<Latency>
<Fixed>
<Time unit="msec">50</Time>
</Fixed>
</Latency>
</LinkRule>
<LinkRule dir="downstream">
<Bandwidth>
<Speed unit="kbps">1500</Speed>
<QueueManagement>
<NormalQueue>
<Size>100</Size>
<QueueMode>packet</QueueMode>
<DropType>DropTail</DropType>
</NormalQueue>
</QueueManagement>
</Bandwidth>
<Latency>
<Fixed>
<Time unit="msec">50</Time>
</Fixed>
</Latency>
</LinkRule>
</VirtualLink>
</VirtualChannel>
</Emulation>
</NetworkEmulationProfile>
I have a general question about Rs232 Software Flowcontrol (aka XOn/XOff)
The .Net implementation (and the nativ win32 api) bothe define a property called WriteTimeout / ReadTimeout, which is a time in ms after which a communication is considered to be overdue.
No my problem is this: If I send, lets say a 5 Byte string to the device I don't see any WriteTimeout, as expected. How is this implemented? Everything I find about Software flow control is that XOFF is to be set, when the recieve buffer is full; XOn when it is ready to recieve again.
But from the behavior I see, I would suspect, hat the device sends XON, after it has processed the 5-Byte information that I send, thus creating the information for windows to generate the corresponding events.
So when to send XON on a two-wire only RS232 implementation? Only if the buffer was full and to restart recieving; Or to signal, that we are "still ready" to receive after every chunk we processed?
How to implement?
Cheers & thx in advance!
Corelgott
Send an XON any time you are ready to receive data (your receive buffer is empty or nearly so). Send an XOFF any time you cannot accept more incoming data (your receive buffer is full or nearly so). The process is documented on the Wikipedia software flow control page.
This guys says yes:
http://web.tiscalinet.it/giordy/midi-tech/lowmidi.htm
Same with a really old book from 1998 (Maximum MIDI).
MSDN doesn't mention it.
I'm not getting any sound.
I fill a char buffer with status|note|velocity|status|note|velocity...
Set lpData, dwBufferLength, and dwFlags of a MIDIHDR struct
call midiOutPrepareHeader (MMSYSERR_NOERROR)
call midiOutLongMsg (MMSYSERR_NOERROR)
Still no sound! Spamming midiOutShortMsg is working but will that work for slower machines? Did they change the functionality?
Thanks.
I'm an idiot! I figured it out: Microsoft GS Wavetable Synth does NOT support sending multiple short messages in midiOutLongMsg. The MIDI Mapper DOES!
midiOutShortMsg should be plenty fast, even on slow machines. MIDI interfaces themselves (hardware that is, but some software will limit themselves) run at 31,250 baud. This of course is ignoring any slow code you may have wrapped around where you call midiOutShortMsg.
Anyway, technically you should also be able to get away with one status byte, if the following notes use the same status byte. So, if you want to do note on/off (using velocity 0 for off) and those notes are on the same channel, you could do this:
status|note|velocity|note|velocity|note|velocity|note|velocity
This is called running status.
I'm using the WML function "providelocalinfo" to put location information into Short Messages send via a WIB menu on a GSM handset.
I'm using the WIG WML v.4 Spec from SmartTrust. The relevant section is "9.4 providelocalinfo Element"
I use the code as in the example, and then transmit the variable via SMS, and use Kannel to retrieve the message from the SMSC.
Here's the code that I'm using, with the exception of [myservicecentre] being my actual service centre:
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE wml PUBLIC "-//SmartTrust//DTD WIG-WML 4.0//EN"
"http://www.smarttrust.com/DTD/WIG-WML4.0.dtd">
<wml wibletenc="UCS2">
<card id="s">
<p>
<providelocalinfo cmdqualifier="location" destvar="LOC"/>
<setvar name="X" value="loc=" class="binary"/>
<sendsm>
<destaddress value="367"/>
<userdata docudenc="hex-binary" dcs="245">
$(X)$(LOC)
</userdata>
<servicecentreaddress value="[myservicecentre]"/>
</sendsm>
</p>
</card>
</wml>
What I see in my received messages is "loc=" followed by 7 bytes (octets) or binary data. I have tried to find documentation explaining how to decode this data, but found nothing the explains this clearly.
Of the decoded 7 octets,
the first 3 octets are always the same,
The next 2 octets tend to vary between three unique values,
the last 2 octets appear to be the cellid.
So I have coded the receiver to pull the last two octets and construct a 16-bit GSM cellid. Most of the time it matches known cellids from the network. But quite often, the value does not match.
So I'm trying to find information on the following:
How to properly transmit the location information in a safe manner (encodings, casts, etc)
How to decode the information properly
How to configure Kannel to honor binary location data
I've examined the following documents in my vain searching, but not found the relevant data:
GSM 03.38, GSM 04.07, GSM 04.08, GSM 11.15, as well as the WIG WML Spec V .4
Any insight into what I might be doing wrong would be appreciated!
To decode the location info, you need to look in GSM 11.14 page 48
1.19 LOCATION INFORMATION
Byte(s) Description Length
1 Location Information tag 1
2 Length (X) of bytes following 1
3-5 Mobile Country & Network Codes (MCC & MNC) 3
6-7 Location Area Code (LAC) 2
8-9 Cell Identity Value (Cell ID) 2
The mobile country code (MCC), the mobile network code (MNC), the location area code (LAC) and the
cell ID are coded as in TS GSM 04.08 [8].
From personal experience, the first octet mentioned here is usually left off, so your first three unchanging bytes are the length and the country. The next 2 are the network operator code.
Not too many bites on this question! I wanted to summarize my findings in case others can find them useful:
Need to send messages with a dcs setting not equal to 0. dcs="0" sends data packed (honoring the lower 7-bits of each octet; this allows 160 character SMS messages when the max message size is actually 140 octets)
Need to parse the data in a binary safe manner: regex expressions that stop searching when 0x0A is encountered will fail when the binary data itself can be that value.
I found no need to change Kannel's default configuration.
Cheers
Disclaimer: Safe transmission of 16-bit GSM Cell-Ids requires dealing with a few settings that I understand only because they weren't configured by default. There are probably other defaults that I've depended on but am unaware that they can vary.