I'm writing an HTTP Live Streaming (HLS) player on Samsung TV. I need to implement an HTTP Proxy which receives every HTTP request sent by Samsung TV Player, modifies the request (by adding a proprietary HTTP header) & sends the modified request to the Media server. Is there a way to implement this type of simple HTTP Proxy on Samsung TV ?
Thanks
S R
There is no method to set up proxy in Samsung TV.
Are you doing a webapp? Or a dotnet app?
One idea is to override the XMLHttpRequest, so you will be able to add your header to all the requests.
Or maybe the setStreamingProperty from avplay doc
Related
I recently bought an ip cam for a project. So my project was just to create a button on a webpage to show the video feed coming from the cam when clicked on it. If i have to stream the rtsp link of the ip cam via a browser, i need to use ffmpeg for converting into HLS. But when i use a http video link of the cam, its easy and convenient. So my question is, what advantage does rtsp have over http ? and what method should i choose in a industrial project. At the moment i have successfully implemented the button with http video link and it works. I was just curious to know the advantage i will have if i use rtsp. Thanks a lot for you precious time.
it depends on the network environment that you are dealing with. For sure using dash/HLS will result in higher latency but on the other hand using TCP for streaming is easier to go through the firewalls.
Apple reasoning for introducing RTSP over HTTP:
Using standard RTSP/RTP it is possible to stream a presentation to a user via a single
TCP connection. (See RFC 2036 “Real Time Streaming Protocol (RTSP)”, section 10.12)
Unfortunately, that is not sufficient to reach a significant population of Internet users.
These users are typically on private IP networks where the client machines have indirect
access to the public Internet via email and HTTP Proxies.
The QuickTime HTTP transport exploits the capability of HTTP GET and POST
methods to carry an indefinite amount of data in their reply, and message body
respectively. In the most simple case, the client makes a HTTP GET request to the
streaming server to open the server to client channel. Then the client makes a POST
request to the server to open the client to server channel.
Link
Please explain to me how webpush work in TCP/IP network layers (especially layer 4-5).
I understand that HTTP is stateless protocol:
the protocol is opening TCP / layer 4 connection,
'state' is 'made to work' with cookie/session,
then client send HTTP request (plaintext/compressed "HTTP/1.1 /url/here ... Content-Length: ..."),
then server respond with HTTP request (plaintext/compressed "200 OK ... ..."),
Therefore it's understandable that for a user behind NAT to be able to view webpage of a remote host (because the user behind NAT is the one initiating the connection); but the webserver cannot initiate TCP connection with the client (browser process).
However there are some exceptions like 'websocket' where client (browser) initiate a connection, then leave it open (elevate to just TCP, not HTTP anymore). In this architecture, webserver may send / initiate sending message to client (for example "you have new chat message" notification).
What I don't understand is the new term 'webpush'.
I observed that it can send notification from server to client/browser (from user, it 'feels' like the server is the one initiating the connection)
webpush can send notification anytime, even when browser is closed / not opened yet (as when the device was just freshly turned on), or when it's just connected to internet
How does it work? How do they accomplish this? Previously I think that:
either a javascript in a page is continously (ex: 5 second interval) checking if there's a new notification in server,
or a javascript initiate a websocket (browser initiate/open TCP connection) and keep it alive, when server need to send something, it's sent from webserver to client/browser through this connection
Is this correct? Or am I missing something? Since both of my guess above won't work behind NAT'd network
Is Firebase web notification also this kind of webpush?
I have searched the internet for explanation on what make it work on client side, but there seems only explanation on 'how to send webpush', 'how to market your product with webpush', those articles only explain the server side (communication of app server with push service server) or articles about marketing.
Also, I'm interested in understanding what application layer protocol they're running on (as in what text/binary data the client/server send to each other), if it's not HTTP
Web Push works because there is a persistent connection between the browser (e.g. Chrome) and the browser push service (e.g. FCM).
When your application server needs to send a notification to a browser, it cannot reach the browser directly with a connection, instead it contacts the browser push service (e.g. FCM for Chrome) and then it's the browser push service that delivers the notification to the user browser.
This is possible because the browser constantly tries to keep an open connection with the server (e.g. FCM for Chrome). This means that there isn't any problem for NAT, since it's the clients that starts the connection. Also consider that any TCP connection is bi-directional: so any side of the connection can start sending data at any time. Don't confuse higher level protocols like HTTP with a normal TCP connection.
If you want more details I have written this article that explains in simple words how Web Push works. You can also read the standards: Push API and IETF Web Push in particular.
Note: Firebase (FCM) is two different things, even if that is not clear from the documentation. It is both the browser push service required to deliver notifications to Chrome (like Mozilla autopush for Firefox, Windows Push Notification Services for Edge and Apple Push Notification service for Safari), but it is also a proprietary service with additional features to send notifications to any browser (like Pushpad, Onesignal and many others).
Can a client use HTTP Post to stream live video to a server? If not, what protocol should be used?
Yes it can, like in the case of the RTMPT protocol (Real Time Messaging Protocol tunneled over HTTP) which uses HTTP 1.1 POST to traverse firewalls.
Other HTTP streaming protocols include: HLS, DASH, HDS or Smooth.
I have started to develop a Rails application, and decided to use websockets as a way to push notifications to the client - and am using basic HTTP requests to get and manipulate data on the server.
Now, websockets allows you to send messages from the client to the server, a feature I currently am not sure when to use - I mean I can always do post requests.
This feels somewhat odd to me - so I guess I am doing something wrong - why should I send HTTP requests when there is already a connection between the client and the server? it could just send a message through the websocket, and request the data to be pushed back to it.
I guess the websocket protocol isn't meant to fully replace http - and servers should support both - so I am wondering, what was the intended usage? - when should I send messages from the client through the websocket and when should I use POST for example?
I am trying to debug the server component of a mobile application. Are there any tools that will allow me to send a HTTPS request and view the response? At the moment I have a Windows computer next to a Mac.
Fiddler supports HTTPS. It's Windows-only, but you didn't specify a platform. There's plenty of others whatever your platform, though.