Project

General

Profile

Actions
Copy link

Bug #3921

closed

RTSP stream on SATIP treated different than same stream via HTTP

Bug #3921: RTSP stream on SATIP treated different than same stream via HTTP

Added by Harald Gutmann almost 10 years ago. Updated almost 9 years ago.

Status:
Invalid
Priority:
Normal
Assignee:
-
Category:
SAT>IP
Target version:
-
Start date:
2016-08-03
Due date:
% Done:

0%

Estimated time:
Found in version:
4.1-2141~g01c26fc~xenial
Affected Versions:

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

What I tested:
  • 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)
What works nicely:
  • 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.)
What makes problems:
  • 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.
The questions now are:
  • 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

Updated by saen acro almost 10 years ago Actions
Copy link
 #1

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 almost 10 years ago Actions
Copy link
 #2

I guess there is a misunderstanding of what the problem is:

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 almost 10 years ago Actions
Copy link
 #3

Did some further Tests as advised on irc:
  • 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 almost 10 years ago Actions
Copy link
 #4

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 almost 10 years ago Actions
Copy link
 #5

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 almost 10 years ago Actions
Copy link
 #6

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?

Updated by Jaroslav Kysela almost 9 years ago Actions
Copy link
 #7

  • Status changed from New to Invalid
Actions
Copy link

Also available in: PDF Atom