Closed franckarts closed 7 years ago
It seems that the OS-specific brower setting differs from linux and window. I get the following error in the console of browser. Please let me know if you see the same error.
'' ' 2https: //xxx.xxx.xxx: 8080 / message? Peer_id = 2 & to = 1 Failed to load resource: the server responded with a status of 502 (Bad Gateway) Native-to-browser-test.html: 1 XMLHttpRequest can not load https://xxx.xxx.xxx:8080/message?peer_id=2&to=1. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://xxx.xxx.xxx' is therefore not allowed access. The response was HTTP status code 502. '' ' It seems to be a problem related to COR (cross-origin resource), and it seems to be solved after the whole html replacement.
Yes I am hitting the same issue:
https://192.168.1.237:8080/wait?peer_id=2 Failed to load resource: the server responded with a status of 502 (Bad Gateway) native-to-browser-test.html:1 XMLHttpRequest cannot load https://192.168.1.237:8080/wait?peer_id=2. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://192.168.1.237' is therefore not allowed access. The response had HTTP status code 502. native-to-browser-test.html:275 Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help, check https://xhr.spec.whatwg.org/. disconnect @ native-to-browser-test.html:275 2https://192.168.1.237/rms/native-to-browser-test.html Failed to load resource: the server responded with a status of 502 (Bad Gateway) disconnect @ native-to-browser-test.html:276 native-to-browser-test.html:276 XMLHttpRequest cannot load https://192.168.1.237:8080/sign_out?peer_id=2. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'https://192.168.1.237' is therefore not allowed access. The response had HTTP status code 502. disconnect @ native-to-browser-test.html:276
Is there a way to fix this?
Hmm it happened because the rpi-webrtc server exited (no error message).
Now, I am still having the problem without any particular error message (blank video).
Please find enclosed the logs.
Thanks for your help! log_js.txt log_rpi.txt
Btw, my chrome version is: Version 55.0.2883.87 m (64-bit)
I found some interesting point in chrome://webrtc-internals/. As you can see in the attached pdf file, rws sends video to windows chrome, but it does not decode and display. i think this issue need more time to find root cause. Currently, i managed to test rws with android without big problem, there was only performance and bi-directional video transfer issue. just for info.
I'll post it again if there is any changes.
I don't know if it's related, but I am getting those errors on the RPI side:
(raspi_encoder.cc:246): Encoder initialized for 1024x768 but trying to encode 1x1 frame. (raspi_encoder.cc:246): Encoder initialized for 1024x768 but trying to encode 1x1 frame. (raspi_encoder.cc:246): Encoder initialized for 1024x768 but trying to encode 1x1 frame.
However I need to dive into your code to figure out what could be the problem. Maybe you have a quick idea of what is happening?
'Encoder initialized for 1024x768 but trying to encode 1x1 frame' is the message from protecting logic. It should not be executed in the normal case. I have not seen it yet, and I have not seen this message in my environment. It also does not occur when testing Windows chrome.
How about fixing the WebRTC native code to branch/55 and try the Raspberry PI firmware upgrade if you use old Raspberry PI image.
Anyway that message means... WebRTC native code ask raspi_encoder to encode 1 x 1 resolution frame.
Yes, It is probably executed because I removed the following lines before:
if (frame.IsZeroSize()) { ReportError(); return WEBRTC_VIDEO_CODEC_ERR_PARAMETER; }
(lines 232-235)
I needed to do that because apparently the webRTC API has been updated, and the "IsZeroSize()" function does not exist anymore.
That may explain this new error. branch/55 is not working either, there is a lot of differences between the webrtc API and your calls. As a workaround, I am using the master branch and did a few updates in your code.
Hmm.... IsZeroSize does exists, i guess, you have some environment problem in building rws. when i compile the rws in my environment, maybe, there was under10 warnings. no error.
please check the Makefile and cross_gn,mk, webrtc_build_args.gn path variables.
I mean, it does not exist anymore in the master branch.
Will try on branch 55 and give updates.
Ok, it's compiling now on branch 55 without any problem. I can confirm that chrome under windows still does not show the video, but the rpi seems to be encoding as expected :(
Btw, it does not work on firefox either.
Thanks for your help!
i think, this is same issue with same error log message in windows chrome log. 11992:9724:0921/223145:ERROR:h264_decoder_impl.cc(333)] avcodec_decode_video2 error: -1094995529
https://bugs.chromium.org/p/chromium/issues/detail?id=644771
Hi,
Yes I am getting the same error message in log mode.
According to your link, there is a workaround at the end but I don't know if it's a good solution or not....
HI, I think, I found a solution for the current issue and fixed it in the 'fixing H264 frame assembling issue' commit. Could you pull the master repo again to see if it has been resolved? Current master repo is based on WebRTC branch56, you need to pull branch56 again if you use branch55. Many thanks.
Great news! However, it looks like something is missing, even with branch 56: `In file included from streamer.cc:38:0: dummyvideocapturer.h:19:42: fatal error: webrtc/api/video/i420_buffer.h: Aucun fichier ou dossier de ce type
` ==> no such file or directory.
I can confirm that the file does not exist:
➜ portable-franck ~ cd Workspace
➜ portable-franck Workspace cd webrtc
➜ portable-franck webrtc find . -name "i420_buffer.h"
➜ portable-franck webrtc
Also, there is a bug in the config_h264 shell script:
if [ -e ${HOME}/Workspace/rpi_rootfs/PI.cmake ]
should be
if [ ! -e ${HOME}/Workspace/rpi_rootfs/PI.cmake ]
Thanks!
About current main subject of this issue If rws works normally in Windows chrome (although there may be new issues, of course), it would be nice to close the current issue. There is a mix of different topics in one issue. It would be nice to create new issue with a different issue.
about i420_buffer.h Somthing strange, i420_buffer.h exists in Cr-Commit-Position: refs/heads/master@{#16130} you can check it also through google webrtc git master webrtc/api/video kclyu@keunchang2: /Workspace/webrtc/src/webrtc$ git log -1 commit bad5dadef3cf90d8ba081e7f814e913ecd2ff83d Author: deadbeef deadbeef@webrtc.org Date: Tue Jan 17 18:32:35 2017 -0800
More minor improvements to BaseChannel/transport code.
Mostly from late comments on this CL: https://codereview.webrtc.org/2614263002/
Changes SetTransport to DCHECK instead of returning false. Renames it to SetTransports. Fixes some possible transport resource leaks.
BUG=None
Review-Url: https://codereview.webrtc.org/2637503003 Cr-Commit-Position: refs/heads/master@{#16130} kclyu@keunchang2: /Workspace/webrtc/src/webrtc$ find . -name i420_buffer.h ./api/video/i420_buffer.h kclyu@keunchang2: /Workspace/webrtc/src/webrtc$
About config_h264 scripts. You are right, Thank you for pointing out.
Sure, I would be happy to close this ticket, as soon as I could verify it. Unfortunately, those issues were blocking me so I could not try your patch. I can't set another defect as a blocker, so adding dependencies between the tickets is not possible. That's why I was writting related problems here. Anyway, thanks again for your great work, I really appreciate it :) :) :) Will close this ticket as soon as I can compile and see video in chrome, don't worry ;)
Branch 56 does not contain i420_buffer.h, but I can see it in the master branch. I guess I need to switch on the master instead of branch56? If this is correct, I guess you need to update your BUILD file.
Thanks again!!
Ok it's working now, closing :) Thanks!
Thanks for the interesting piece of code. That's a great idea.
On the front end side, it's working like a charm under chrome / Debian. For some reasons, I can't make it working on chrome / Windows. The h264 flag is enabled as required. Also, the chrome release on Win 10 is much recent than the one on Debian so I would not expect that.
The play event is triggered by JS, however nothing happens. The browser is communicating but there is no video. Do you have any clue of what could be the problem? Thanks a lot!