{"action":"created","issue":{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/260","labels_url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/260/labels{/name}","comments_url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/260/comments","events_url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/260/events","html_url":"https://github.com/EricssonResearch/openwebrtc/issues/260","id":63262449,"number":260,"title":"Ensuring proper iOS video quality for video conferencing","user":{"login":"ijsf","id":123868,"avatar_url":"https://avatars.githubusercontent.com/u/123868?v=3","gravatar_id":"","url":"https://api.github.com/users/ijsf","html_url":"https://github.com/ijsf","followers_url":"https://api.github.com/users/ijsf/followers","following_url":"https://api.github.com/users/ijsf/following{/other_user}","gists_url":"https://api.github.com/users/ijsf/gists{/gist_id}","starred_url":"https://api.github.com/users/ijsf/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ijsf/subscriptions","organizations_url":"https://api.github.com/users/ijsf/orgs","repos_url":"https://api.github.com/users/ijsf/repos","events_url":"https://api.github.com/users/ijsf/events{/privacy}","received_events_url":"https://api.github.com/users/ijsf/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/labels/enhancement","name":"enhancement","color":"84b6eb"},{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/labels/iOS","name":"iOS","color":"006b75"},{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/labels/Mac%20OS%20X","name":"Mac OS X","color":"c7def8"},{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/labels/Non-Build%20Issue","name":"Non-Build Issue","color":"006b75"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":77,"created_at":"2015-03-20T16:48:37Z","updated_at":"2015-04-06T13:31:38Z","closed_at":null,"body":"Summarizing multiple related problems into this ticket for now.\r\n\r\nI have been testing the local video capturing in the iOS build of OpenWebRTC on an iPad Mini Gen 1 (armv7) using demo.openwebrtc.io:38080.\r\n\r\nA-side: iOS 8.1.3, iPad Mini Gen 1\r\nB-side: Chrome 41.0.2272.76 (64-bit) on OS X 10.10\r\n\r\nCurrently, there are some serious quality issues with the video that have to be solved in order for OpenWebRTC to be useful for video conferencing:\r\n\r\n* A-side to B-side (video received on B-side): permanently green. Cause unknown.\r\n* B-side to A-side (video received on A-side): occasionally drops out to black/green, possibly to do with poor (real-time) performance in combination with RTP (RTP attempting to resync?). See https://github.com/EricssonResearch/openwebrtc/issues/244"},"comment":{"url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/comments/90065648","html_url":"https://github.com/EricssonResearch/openwebrtc/issues/260#issuecomment-90065648","issue_url":"https://api.github.com/repos/EricssonResearch/openwebrtc/issues/260","id":90065648,"user":{"login":"superdump","id":302146,"avatar_url":"https://avatars.githubusercontent.com/u/302146?v=3","gravatar_id":"","url":"https://api.github.com/users/superdump","html_url":"https://github.com/superdump","followers_url":"https://api.github.com/users/superdump/followers","following_url":"https://api.github.com/users/superdump/following{/other_user}","gists_url":"https://api.github.com/users/superdump/gists{/gist_id}","starred_url":"https://api.github.com/users/superdump/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/superdump/subscriptions","organizations_url":"https://api.github.com/users/superdump/orgs","repos_url":"https://api.github.com/users/superdump/repos","events_url":"https://api.github.com/users/superdump/events{/privacy}","received_events_url":"https://api.github.com/users/superdump/received_events","type":"User","site_admin":false},"created_at":"2015-04-06T13:31:38Z","updated_at":"2015-04-06T13:31:38Z","body":"You can see in a GST_DEBUG log of GST_SCHEDULING:7 when a buffer is passed from one element to the next. As far as I know, that is the only way to follow buffers through a pipeline. Note that messages start from the beginning of a thread with calling the next element's chain function and then when they get to the end of the thread they return saying that the chain function was called. The thread context pointer (right?) is also printed as part of each log message. You can look at the buffer pointers and timestamps and take differences to see how long a buffer spent in a specific element. There's some improved tracing work going on in GStreamer that will help this kind of end to end performance measurement. One can always write a script to parse the log, measure the differences and create graphs though.\r\n\r\nWith regard to sync, that's why RTP packets have timestamps and RTCP sender reports have a reference time for an RTP packet timestamp. These are used to keep RTP streams in sync. The evaluation of the behaviours of the remote clock according to the RTP stream and the local clock for a GStreamer receiver is done in rtp jitterbuffer.\r\n\r\nAbout the patches that are not acceptable upstream - did you get any suggestions for how to fix the issues you're observing in The Right Way, given that your patches were rejected?"}}