[Announce] MPTvClient V1.2.5 (20.12.2007) II (1 Viewer)

[KayDiefenthal]

Anyone managed to get RTSP-Streaming with Windows Media Player working?

VLC works fine for me, but I really don't like the picture quality of the internal codecs (deinterlacing).

rtsp://HTPC/stream2.0

Tried to open it in WMP -> Protocol not supported.

I checked the settings in WMP - everything is checked. And its not a firewall problem... why should it

SQLServer: TCP/IP and Named Pipes - remote and local is activated.

MP TV CLient: TCP Connection fails???

for your help!

i tested some ways to play rtsp streams in wmp
but no luck

only the local playing of ts buffer works @ time

with this reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.ts]
"ReplaceApps"="wmplayer.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.tp]
"ReplaceApps"="wmplayer.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.tsbuffer]
"ReplaceApps"="wmplayer.exe"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Multimedia\WMPlayer\Extensions\.rtsp]
"ReplaceApps"="wmplayer.exe"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.ts]
"Source Filter"="{b9559486-e1bb-45d3-a2a2-9a7afe49b23f}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.tp]
"Source Filter"="{b9559486-e1bb-45d3-a2a2-9a7afe49b23f}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.tsbuffer]
"Source Filter"="{b9559486-e1bb-45d3-a2a2-9a7afe49b23f}"

[HKEY_CLASSES_ROOT\Media Type\Extensions\.rtsp]
"Source Filter"="{b9559486-e1bb-45d3-a2a2-9a7afe49b23f}"

 

[level20peon]

Finally found a workaround to the freeze after 45 seconds (1100 to 1125 decoded blocks according to the Stream and media Info statistics) although I don't know the cause yet .

If I set the VLC option Preferences - Demuxers - RTP/RTSP - advanced options - Use RTP over RTSP(TCP) to true everything runs correctly.

The stream is not fluid when I do this plus TV-Server crashes when I close VLC (in my case, VLC 0.8.6i, MPTV-Client 1.2.5 / 1.3.1 both tested).


-level20peon

 

[FransO]

Using RTP over TCP requires an acknowledgement of each packet. I tested with the client on the TVServer and that went all right. Put some switches and a wireless accesspoint between server and client and network latency becomes a problem and reception will be choppy yes.

I used Ms Netwerk Monitor to see what went on when the 45 second freeze occurred with RTP over UDP. The answer is: Not much. After an RTSP setup there are a lot of UDP packets and after the last UDP packet just two TCP packets: A message from the server and a response from the client. After that no more traffic attributable to RSTP at all.

Below some excerpts from the network trace, .32 is the client and .33 is the tvserver, the first IP address is the source, the second the destination. The second column is the time offset in microseconds.

302 2.971.170 192.168.2.32 192.168.2.33 TCP TCP: Flags=.S......, SrcPort=49419, DstPort=RTSP(554), Len=0, Seq=3105363208, Ack=0, Win=8192 (scale factor not found)
303 2.971.170 192.168.2.33 192.168.2.32 TCP TCP: Flags=.S..A..., SrcPort=RTSP(554), DstPort=49419, Len=0, Seq=1280543924, Ack=3105363209, Win=8192 (scale factor not found)
304 2.972.170 192.168.2.32 192.168.2.33 TCP TCP: Flags=....A..., SrcPort=49419, DstPort=RTSP(554), Len=0, Seq=3105363209, Ack=1280543925, Win=4380 (scale factor not found)
305 2.973.170 192.168.2.32 192.168.2.33 RTSP RTSP: REQUEST, OPTIONS rtsp://OADT3/stream1.0
306 2.973.170 192.168.2.33 192.168.2.32 RTSP RTSP: RESPONSE, RTSP/1.0, Status Code = 200 - OK
309 2.977.171 192.168.2.33 192.168.2.32 UDP UDP: SrcPort = Linklocal Multicast Name Resolution(5355), DstPort = 51864, Length = 52
310 2.980.171 192.168.2.32 192.168.2.33 RTSP RTSP: REQUEST, DESCRIBE rtsp://OADT3/stream1.0
315 3.014.173 192.168.2.33 192.168.2.32 SDP SDP: Session Name=Session streamed by "MediaPortal Tv Server v1.0", Version=0
316 3.023.173 192.168.2.32 192.168.2.33 RTSP RTSP: REQUEST, SETUP rtsp://192.168.2.33/stream1.0/track1
318 3.045.174 192.168.2.33 192.168.2.32 RTSP RTSP: RESPONSE, RTSP/1.0, Status Code = 200 - OK
319 3.047.175 192.168.2.32 192.168.2.33 RTSP RTSP: REQUEST, PLAY rtsp://192.168.2.33/stream1.0/
320 3.065.176 192.168.2.33 192.168.2.32 RTSP RTSP: RESPONSE, RTSP/1.0, Status Code = 200 - OK
321 3.065.176 192.168.2.33 192.168.2.32 UDP UDP: SrcPort = 6970, DstPort = 51866, Length = 1336
-
-
-A lot of UDP packets in between here
-
-
40913 47.992.745 192.168.2.33 192.168.2.32 UDP UDP: SrcPort = 6970, DstPort = 51866, Length = 1336
40914 47.994.745 192.168.2.33 192.168.2.32 TCP TCP: Flags=F...A..., SrcPort=RTSP(554), DstPort=49419, Len=0, Seq=1280544933, Ack=3105363815, Win=254 (scale factor not found)
40915 47.996.746 192.168.2.32 192.168.2.33 TCP TCP: Flags=....A..., SrcPort=49419, DstPort=RTSP(554), Len=0, Seq=3105363815, Ack=1280544934, Win=4128 (scale factor not found)

The contents of those last two TCP packets are:

From the server to the client:
Frame:
+ Ethernet: Etype = Internet IP (IPv4)
+ Ipv4: Next Protocol = TCP, Packet ID = 19365, Total IP Length = 40
- Tcp: Flags=F...A..., SrcPort=RTSP(554), DstPort=49419, Len=0, Seq=1280544933, Ack=3105363815, Win=254 (scale factor not found)
SrcPort: RTSP(554)
DstPort: 49419
SequenceNumber: 1280544933 (0x4C5390A5)
AcknowledgementNumber: 3105363815 (0xB9181767)
+ DataOffset: 80 (0x50)
- Flags: F...A...
CWR: (0.......) CWR not significant
ECE: (.0......) ECN-Echo not significant
Urgent: (..0.....) Not Urgent Data
Ack: (...1....) Acknowledgement field significant
Push: (....0...) No Push Function
Reset: (.....0..) No Reset
Syn: (......0.) Not Synchronize sequence numbers
Fin: (.......1) End of data
Window: 254 (scale factor not found)
Checksum: 34220 (0x85AC)
UrgentPointer: 0 (0x0)

response from the client:
Frame:
+ Ethernet: Etype = Internet IP (IPv4)
+ Ipv4: Next Protocol = TCP, Packet ID = 4981, Total IP Length = 40
- Tcp: Flags=....A..., SrcPort=49419, DstPort=RTSP(554), Len=0, Seq=3105363815, Ack=1280544934, Win=4128 (scale factor not found)
SrcPort: 49419
DstPort: RTSP(554)
SequenceNumber: 3105363815 (0xB9181767)
AcknowledgementNumber: 1280544934 (0x4C5390A6)
+ DataOffset: 80 (0x50)
- Flags: ....A...
CWR: (0.......) CWR not significant
ECE: (.0......) ECN-Echo not significant
Urgent: (..0.....) Not Urgent Data
Ack: (...1....) Acknowledgement field significant
Push: (....0...) No Push Function
Reset: (.....0..) No Reset
Syn: (......0.) Not Synchronize sequence numbers
Fin: (.......0) Not End of data
Window: 4128 (scale factor not found)
Checksum: 43379 (0xA973)
UrgentPointer: 0 (0x0)

I don't know enough of the protocols to be sure, but it looks like the server telling the client: That's all your gonna get.

 

[level20peon]

Doesn't matter anyways, it is in Mantis already... so a fix is most probably on the way.


-level20peon

 

[Nippywiffle]

I have a problem when VLC starts up, connects to the URL, but then crashes with this info:

AppName: vlc.exe AppVer: 0.8.6.0 ModName: msvcrt.dll
ModVer: 7.0.2600.2180 Offset: 00031b8d

I am using MPTVClient 1.2.5, and everything seems to work ok on that side - it lists my channels, and does start timeshifting etc.

I am using the latest VLC - 0.8.6i, and have also tried an earlier 0.8.6 version, with the same issue.

I tried using Mplayer and Alshow, but neither seem to work.

Does anyone have a solution to this? I know I have had this all working in the past, with VLC...

I'm using MP/TVServer 1.0 RC2.

Thanks,
Dan

 

[FransO]

It is quite possible that the freeze after 45 seconds using MP TV Client and VLC is not caused by Media Portal tv server or the MP TV client at all, but by the VLC player and/or the Live5555 library it uses to display rtsp streams.

I was triggered by the remarks of Level20peon in another thread about the same bug, that the bug persisted even though he went back to a previous version of the MP TV Client that used to work well and now showed the same behaviour as the new version.

I removed VLC player version 0.8.6i (checked the option to delete the preferences too) and installed VLC player version 0.8.6d. Works like a charm, no more freezing after 45 seconds.

I'll check the network trace to see if there is any difference in the setup of the rtsp session.

 

[level20peon]

Thanks for opening my eyes FransO, I am so stupid, really. I updated to VLC 0.8.6i recently but didn't think a second about this when the rtsp stream broke. Infinityloop told me that there might be something triggering this in TV-Server also though so maybe it is a combination of changes which didn't interfear by chance before. Let's just wait if the new SVN will enable playback with VLC 0.8.6i.
Hint: I tested old versions of VLC and 0.8.6h is the latest working version, so no need to go back to 0.8.6d .


-level20peon

 

[FransO]

The main difference that I see in the network trace when using VLC player version 0.8.6i and the earlier versions, is that the earlier versions are sending an RTCP Receiver Report package every 5 seconds whereas the 0.8.6i version does not. The RTCP Receiver Report packet is used by the client to report quality of signal information and a keep alive signal.

 

[blehmbo]

Is it normal for the ChannelID, listed in MPTvClient, to not match the SID or Channel Numbers that are set in the TV server? I am using MPTvClient v1.25 and MP Server RC2.

 

[level20peon]

blehmbo: This is normal since the Channel Numbers are simply counting the stored channels from 1-x whereas the SID is something like a sub-frequency (simply put) tuned by your tv-card.


-level20peon