Opened 11 years ago
Closed 9 years ago
#11852 closed Bug Report - General (Fixed)
IPTV recording with RTP protocol creates unusable videos
| Reported by: | Owned by: | Karl Egly | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.27.6 |
| Component: | MythTV - Recording | Version: | 0.27-fixes |
| Severity: | medium | Keywords: | IPTV RTP |
| Cc: | Ticket locked: | no |
Description
Hallo, i have installed mythtv 0.27 RC1 and would like use IPTV recording with German Telekom Entertainment. The German Telekom use the RTP protocol. IPTV streaming works perfect with vlc, but the recorded videos with mythtv 0.27rc1 are unusable. Have a look a the attachment.
Attachments (5)
Change History (36)
Changed 11 years ago by
| Attachment: | playlist.m3u added |
|---|
comment:1 follow-up: 3 Changed 11 years ago by
Did you had any success with fixing this? I just downloaded your m3u and implemented it in MythTV ... with the same result.
comment:2 Changed 11 years ago by
Workaround: After channel scanning with the playlist.m3u, open the mysql daterbase vom mythtv and rename the address from rtp to udp. Than it works!
comment:3 follow-up: 6 Changed 11 years ago by
Replying to publicaddress004@…:
Did you had any success with fixing this? I just downloaded your m3u and implemented it in MythTV ... with the same result.
Workaround:
After channel scanning with the playlist.m3u, open the mysql daterbase vom mythtv and rename the address from rtp to udp. Then it works!
comment:4 follow-up: 5 Changed 11 years ago by
| Status: | new → infoneeded_new |
|---|
Please try fixing the playlist to use the udp scheme instead of the rtp scheme. Does it work then?
comment:5 follow-up: 8 Changed 11 years ago by
Replying to dekarl:
Please try fixing the playlist to use the udp scheme instead of the rtp scheme. Does it work then?
The German Telekom use the RTP protocol. UDP doesn't work. It's a Mythtv bug, not the wrong protocol.
Have a look at the multicast address list: http://grinch.itg-em.de/entertain/faq/allgemein/multicastadressliste/ http://www.ard-digital.de/Empfang--Technik/IPTV/Software-Download/Software-Download
comment:6 Changed 11 years ago by
Replying to dvd-ram@…:
Replying to publicaddress004@…:
Did you had any success with fixing this? I just downloaded your m3u and implemented it in MythTV ... with the same result.
Workaround:
After channel scanning with the playlist.m3u, open the mysql daterbase vom mythtv and rename the address from rtp to udp. Then it works!
This worked, thanks! IPTV is faster than DVB-C, great for LiveTV - yeah!!
comment:7 Changed 11 years ago by
OFFTOPIC WARNING: dvd-ram, your m3u lacks some channels, e. g. ZDFinfo, RTL Nitro, hr. I assume you know about that and you have posted the links already that contain complete lists of addresses, so others may have a look there.
comment:8 Changed 11 years ago by
Replying to dvd-ram@…:
Replying to dekarl:
Please try fixing the playlist to use the udp scheme instead of the rtp scheme. Does it work then?
The German Telekom use the RTP protocol. UDP doesn't work. It's a Mythtv bug, not the wrong protocol.
Can you post a short streamdump to take a look at in wireshark? It appears like something is wrong because RTP should "just work". The suggestion "change it to UDP in the playlist" was meant as an alternative to "change it to UDP in the database".
Changed 11 years ago by
| Attachment: | vlc-record-2014-02-03-20h55m13s-rtp___239.35.10.1_10000-.ts added |
|---|
Recorded stream with vlc from german Telekom "T-Home" IPTV, channel "Das Erste HD"
comment:9 Changed 11 years ago by
Unsure if the above is a "streamdump" ... :D Feel free to hint me how to properly create it if it is wrong!
comment:10 Changed 11 years ago by
| Summary: | IPTV recording with RTP protocol creates unusable videos → IPTV recording with RTP protocol creates unusable videos |
|---|
I'm looking for a network packet capture to look at with wireshark. Maybe 5 seconds from a public and 5 seconds from a private stream.
comment:11 Changed 11 years ago by
| Resolution: | → Invalid |
|---|---|
| Status: | infoneeded_new → closed |
change your playlist
comment:12 Changed 9 years ago by
| Resolution: | Invalid |
|---|---|
| Status: | closed → new |
Re-opening as changing the playlist is a workaround but not a real solution to the problem. Why is the video unusable when using the RTP protocol? I have the same problem with Austrian IPTV A1 TV.
comment:13 Changed 9 years ago by
I believe that the related issue #11962 only exists because of the broken RTP support and the suggested UDP workaround. The official channellists of German Telekom Entertainment and Austrian A1 TV (see http://epggw.a1.net/a/service.plus.m3u?plain) contain RTP urls and not UDP urls. So I believe they only properly support RTP and not UDP.
The same holds true for VLC: It can play the RTP urls without problems, but has glitches too when playing UDP urls (similar to the glitches mentioned in #11962).
E.g. for A1 TV:
vlc "rtp://@239.2.16.1:8208"
... works fine
vlc "udp://@239.2.16.1:8208"
... has horrible glitches
comment:14 follow-up: 28 Changed 9 years ago by
By the way: The problem still exists in v0.28 (tested with v0.28-pre-2945-g19b83b8)
comment:15 Changed 9 years ago by
| Owner: | changed from danielk to Karl Egly |
|---|---|
| Status: | new → accepted |
mbt2015, please provide the information that I asked publicaddress004 for. As this is a multicast transmission it is either transmitted wrapped into RTP or it is plain UDP, the client has nothing to choose. So if it works after fixing the playlist, then the playlist is simply wrong! But to prove either way we need to look at raw network packages and see if they have a RTP header or not.
comment:16 Changed 9 years ago by
| Status: | accepted → infoneeded |
|---|
comment:17 follow-up: 24 Changed 9 years ago by
| Status: | infoneeded → assigned |
|---|
Hi dekarl, thanks for looking into this! I started Wireshark and ran
vlc rtp://@239.2.16.1:8208
for a few seconds. The resulting capture file (zipped Wireshark/tcpdump format) is attached as captured_orf1.pcap.zip.
comment:18 Changed 9 years ago by
Don't get too attached to what the url type is in the URL.
RTP or UDP are fundamentally the same, both use UDP transport.
VLC incorrectly differentiate UDP and RTP protocol due to their internal implementation. Many internet providers provide their playlist in a format VLC can understand as this is most likely most popular player.
I would close this bug as there's nothing to fix. If it works with UDP vs RTP well, that's it.
comment:19 Changed 9 years ago by
jyavenard, please do not close this.
Obviously MythTV also differentiates between UDP and RTP urls and uses different implementations for the two. It seems that for our German and Austrian IPTV streams (which I believe are just standard h264 RTP streams) currently the MythTV RTP implementation is completely broken (resulting in the "unusable" video that this bug is about), and the MythTV UDP implementation works but still has some glitches that occur every few seconds (and make the video very unpleasant to look at) (see #11962).
If you are saying that UDP and RTP is basically the same, then MythTV should use the same implementation for both URL formats, and ensure that this implementation works correctly (without glitches) for h264 streams.
comment:20 Changed 9 years ago by
Surely, you can edit the playlist. it's something that needs to be done just once.
While they are basically the same, I do believe MythTV implementation *is* correct, it's VLC that isn't and it treats a UDP streams as RTP and vice-versa.
I don't see why we should make our handling incorrect just to be in line with VLC and provider giving invalid format playlist.
Also, VLC requires to use the @ symbol to indicate it's a multicast stream ; those are invalid yet they use it, and some providers also use those in their playlist.
There's nothing wrong with mythtv handling of UDP or RTP stream.
comment:21 Changed 9 years ago by
Hi jyavenard! Sure I agree, editing the playlist once is no problem.
But the problem is that even when using udp:// MythTV still has glitches when playing those streams (see #11962). I believe that those glitches are due to the RTP headers that the MythTV UDP implementation does not consider correctly.
Did you have a look at the captured stream I attached (captured_orf1.pcap.zip)?
I did now using Wireshark. Wireshark has a nice option that can find RTP packets within the UDP stream (open "Preferences" from the menu, then "Protocols", "RTP" and activate "Try to decode RTP outside of conversations"). And indeed it does find RTP headers! So actually VNC is correct here. The rtp:// url is correct and udp:// is incorrect.
comment:23 Changed 9 years ago by
The problem can also easily be reproduced by producing an RTP h264 stream using VLC and trying to play that in MythTV.
Run
vlc -vvv video.mpg ':sout=#transcode{vcodec=h264,acodec=mpga,ab=128,channels=2,samplerate=44100}:rtp{dst=localhost,port=5000,mux=ts,sap}' :sout-keep
where video.mpg is some (not too short) video file that VLC can read. This produces a stream available at rtp://localhost:5000
It can be successfully played with VLC using
vlc rtp://localhost:5000
Running
mythavtest rtp://localhost:5000
(or importing the stream as an IPTV channel into MythTV) will show the problem. The video is completely unwatchable. (Tested with VDPAU and Default playback.)
comment:24 Changed 9 years ago by
Replying to mbt2015@…:
I started Wireshark and ran
vlc rtp://@239.2.16.1:8208
for a few seconds.
Thanks, that is exactly what I'm looking for.
A1 TV appears to use encoders that implement RFC 5285 wrong. They use random bytes for padding when they must use 0 bytes for padding. Just open your trace in Wireshark and decode as RTP. Notice how most packets are malformed. This is due to the dissector trying to decode past the second header extension, when it actually is always just three random bytes of padding. (must be 0x00 0x00 0x00 instead)
Find attached a candidate patch (compile tested) for review.
Changed 9 years ago by
| Attachment: | 0001-handle-RTP-packets-with-header-extensions-and-or-les.patch added |
|---|
proof of concept (compile tested)
comment:28 Changed 9 years ago by
| Status: | assigned → infoneeded |
|---|
Replying to mbt2015@…:
The problem still exists in v0.28 (tested with v0.28-pre-2945-g19b83b8)
I have pushed the possible fix to master two days ago and Mythbuntu nightly builds have picked it up yesterday. (I'm guessing you are still running Mythbuntu.) Please update and try a recording.
As the code is basically unchanged the fix would apply to fixes/0.27, too.
comment:29 Changed 9 years ago by
Hi Karl!
I just tested it with the newest version from the Mythbuntu 0.28 repo. Both LiveTV and Recording work like a charm now!
Finally I can use rtp:// instead of udp:// again and there are no strange glitches any more!
Thank you very, very much for fixing this! Hermann
comment:31 Changed 9 years ago by
| Milestone: | → 0.27.6 |
|---|---|
| Resolution: | → Fixed |
| Status: | infoneeded → closed |
Merging to fixes/0.27 after success report. After looking at a packet capture from T-Entertain that also needed the same fix.
IPTV Channel list German Telekom Entertain