Bug #3921
RTSP stream on SATIP treated different than same stream via HTTP
0%
Description
Dear All,
during the last days I've tested a lot with tvheadend, ffmpeg and SATIP. I'm not 100% sure if this is a bug, or if I miss something, but it would be very helpful if this can be solved.
What I want to archive:
pipe://input -> SATIP output
- many, many, many ffmpeg options (H264 codec) to generate the streams (in the end I took SATIP stream samples, and adjusted the ffmpeg options to an extent where I can say the basic stream properties are very comparable with nicely working SATIP streams).
- native SATIP clients (Panasonic TV, VDR with vdr-plugin-satip)
- semi-native SATIP clients (VLC)
- software players (mplayer, VLC)
- ffmpeg pipe command redirect to a file, playback with software players
- stream playback with software players link directly copied from the Muxes Configuration section
- stream playback with VLC's UPNP SATIP discover (IMPORTANT: The discovered channel list has HTTP streams in it.)
- native RTSP SATIP clients
- The picture is blocky/has greenish sections/is only updated for the half-picture/...
- It is nearly impossible to get a nice looking stream via RTSP
° ffmpegs option -g 0 which does only generate I-Frames & with bitrates < 3000k, results are not that bad
° regular SATIP streams have the I-Frame typically all 32 Frames, in between mostly the streams have 3-4 B-Frames, a P-Frame and so on (IBBBPBBBP...)
° To meet the standard DVB-S(2) stream frame types options like -g 32 -bf 3 would be the best to meet the Frame formats as the TV-Stations send it. With this options the stream is not watchable via RTSP.
- What does TVheadend do different when streaming via RTSP compared to HTTP?
- Is there somewhere a different buffer size which should be pre-filled by ffmpeg?
- How to get a nice H264 stream via SATIP RTSP?
Many thanks in advance!
Kind regards,
Harald Gutmann
History
Updated by saen acro over 8 years ago
SATIP client already build in in TVHeadend.
VLC don't support SATIP it see http://device.ip:80/playlist (if supported)
Updated by Harald Gutmann over 8 years ago
- All of my post is referring to TVHeadends built-in SATIP server. Not the SATIP client.
- VLC does support SATIP: https://mailman.videolan.org/pipermail/vlc-commits/2015-October/032491.html (I used a VLC 3.0 nightly build (3.0.0~~git20160801+r65606+62~ubuntu16.04.1) for testing)
saen acro wrote:
SATIP client already build in in TVHeadend.
VLC don't support SATIP it see http://device.ip:80/playlist (if supported)
Updated by Harald Gutmann over 8 years ago
- Exported the HTTP stream via DLNA (Mediatomb) to the TV. Works perfect.
- Calling the same stream via a SAT>IP channel the result is a chunked video stream.
Updated by Jaroslav Kysela over 8 years ago
The problem is that SAT>IP uses UDP for data transfers which depends on perfect timing. TVH does not do any packet rate limiting, which may cause that the receiver might not get all data - you may try to reduce UDP packet bursts using the advanced traffic control - https://wiki.archlinux.org/index.php/Advanced_traffic_control .
Updated by Jaroslav Kysela over 8 years ago
Another option is to use embedded TCP data mode for RTSP, but commercial clients do not support this (it's not a part of the SAT>IP spec). But TVH and VDR support this.
Updated by Info Barra over 8 years ago
Jaroslav Kysela wrote:
The problem is that SAT>IP uses UDP for data transfers which depends on perfect timing. TVH does not do any packet rate limiting, which may cause that the receiver might not get all data - you may try to reduce UDP packet bursts using the advanced traffic control - https://wiki.archlinux.org/index.php/Advanced_traffic_control .
Hi maybe i am posting it on the wrong place. but does tvheadend support UDP output unicast? or even UDP multicast output?
On the client side htspclient or IPTVsimpleclient, how do i configure this to work in UDP?
basically i want to reduce memory usage of my tvheadend server and client STB iptv equipment on the network cause TCP simply can´t handle too many users connected on the same network server side.
UDP is alot better, but so far i have not been able to make this work with UDP output for end client.
any hints or ideas?