-
Notifications
You must be signed in to change notification settings - Fork 11
Working Notes
rtsp://163.22.32.62/live1.sdp (640*480)
rtsp://163.22.32.62/live2.sdp (320*240)
rtsp://140.109.221.238/live1.sdp (320x240)
rtsp://140.109.221.238/live2.sdp (1920x1080, Full HD)
rtsp://163.22.32.118/live1.sdp (1920x1080, Full HD)
2015-11-04
- IMONOLOGY: Perform local LAN test to understand if bad timestamps is due to network problem. Use following command and analize if video continuity is OK (no video jumps detected).
gst-launch-1.5 tcpclientsrc host=ncnu.hydra.click port=50001 ! decodebin ! autovideosink
We've run the test and not completely able to interpret the results. However, bad timestamps is a known issue to us as well and have been verified by passing the stream via ffmpeg (then it plays correctly).
2015-10-28
- IMONOLOGY: To verify if GKB camera can be configured to emit H264 baseline.
We've confirmed with GKB, currently only H264 High Profile is supported.
-
Possible to use other RTSP stream (H264 baseline encoded) to verify that Firefox indeed can see H264 video via Kurento? (maybe via other IPcam?)
-
Can KMS perform the "to baseline H264" conversion? Will this be costly as trans-coding to VP8 or maybe less expensive?
"Primarily for low-cost applications, this profile is most typically used in videoconferencing and mobile applications. It corresponds to the subset of features that are in common between the Baseline, Main, and High Profiles Main and High just add features to that. "
ref: http://superuser.com/questions/489087/what-are-the-differences-between-h-264-profiles
2015-11-04
Work done
- DONE: Development of an application able to detect RTSP errors. The application detects feed errors and it tries to reconnect to the same camera. If it is not possible, the application will try to reconnect again each 10 seconds. Code is available in shared repository.
- DONE: Added WebRTC error detection. If WebRTC disconnection is detected the application sends a message to the browser. Any further action can be performed in this node listener (line 226 server.js)
webRtcEndpoint.on ('MediaStateChanged' , function (data){if (data.newState == 'DISCONNECTED') {console.info ("WebRtcEndpoint disconnection detected");return callback(null, 'webRtcEndpoint', null);}});or in this function of index.js (line 35) from browser.case 'webRtcEndpoint_disconnected':console.log ("WebRtcEndpoint disconnected")break;
Comments No comments.
Action point No action points.
2015-11-03
Work done
- DONE: Create a demo application able to play a HD video from rtsp://163.22.32.118/live1.sdp and to record the video in a MP4 file without transcoding. This app has been uploaded to the Kurento-H264 repo. A pipeline has been updated to show that there is no transcoding.
- DONE: MPEG-TS streams successfully received from DVR connector located in tcp://ncnu.hydra.click:50001. VLC and Gstremaer players can both open the streams and show video. Both players complain about malformed timestamps.
- DONE: Test has been performed with Kurento player to find out this URL type is not supported by Kurento players.
Comments
- Stream generated by DVR-connector is showing timestamp problems. This might be caused by network delay or malformed timestamps and a local test is required in order to find out.
- Kurento player can be modified in order to support URLs of type tcp:// or udp://. This can be set as next objective, but most likelly will consume all remaining work time.
Action point IMONOLOGY: Perform local LAN test to understand if bad timestamps is due to network problem. Use following command and analize if video continuity is OK (no video jumps detected). gst-launch-1.5 tcpclientsrc host=ncnu.hydra.click port=50001 ! decodebin ! autovideosink
2015-10-28
Hi all, I’m sending today’s report.
Work done
-
As GKB cameras are not able to generate a video compatible with Firefox, we have reencoded a video to check the application developed yesterday. The video has been uploaded to the repo. Also we have performed a modification in the application to use this video. The application doesn't work all the times. Sometimes, the player doesn't connect with the WebRtcEndpoint, probably, because we request a keyframe in MediaElements connections and in this case we don't have any encoder to respond request. This problem could be investigated.
-
We have investigated how we can use your video feeds into Kurento. We tested how to change H264 video parameters on the fly without transcoding. Some parameters (like stream-format and alignment) can be changed, but video is still no compatible with firefox due to encoding profile. Most likely video will need to be transcoded in order to be displayed by Firefox, and all modifications required will need to be included to media server elements.
Comments
- Unfortunately looks like GKB streams wont play in Firefox WebRTC directly and transcoding will be required. This probably changes the scope and task will have to be reviewed.
Action point KURENTO-IMONOLOGY: Review scope and task based in findings today.
2015-10-27
Work done
- DONE: Inject RTSP flows into Kurento. Verified that media is compatible with Kurento capabilities.
- DONE: Create a nodejs demo application building a media pipeline connecting from RTSP flow into WebRTC (Firefox H264).
** Application is available at https://github.com/imonology/Kurento-H264
** Media server has to be configured to disable VP8. Make sure VP8 is removed from video codecs in
/etc/kurento/modules/kurento/SdpEndpoint.conf.json
"videoCodecs" : [
{
"name" : "H264/90000"
}
]
Comments
- Firefox is not able to reproduce H264 stream from RTSP cameras. You can check the pipeline without transcoding in the attached image. We guess that there is a problem with the video baseline. Firefox supports H264 using OpenH264 and OpenH264 only supports the profile baseline [1]. As you can see in the pipeline image, your feed sends media with profile high. Also the stream-format and the alignment are different to the used by OpenH264. We need to verify if this properties can be configured in the source camera in order to avoid transcoding.
Action points
- IMONOLOGY: To verify if GKB camera can be configured to emit H264 baseline