No video on UDP 5600

[tr0043t]

In the project description it notes:

View drone video feeds in QGC or forward RTP to an IP address of your choice (currently Mavic Pro 2 only)

Does the Mavic Pro 2 restriction apply to both UDP 5600 video and RTP? So far using the Mini 2 (emulating Air 2) I can see video in the RD app itself, but have been unable to see any video at all on QGC (or any other UDP video app, either on the same device or an external device). Of course I've set the parameters in QGC properly for UDP video streams on 5600, and I do have the telemetry linkage to QGC -- just no video.

Is there something I'm missing or is this simply not supported yet? Thanks.

[m4xw]

Not on hand

[m4xw]

I also pulled out the if clause with #L947-L948 in it. The result was the app won't start at all anymore. I get the initial screen but the CHOOSE AN APP FOR THE USB DEVICE panel keeps popping in over and ove

Makes zero sense btw, hence smth on your end. Sounds like a bad cable or smth

[m4xw]

fwiw reverting this might be worth a shot (in DJIVideoStreamDecoder). Really sounds like a bad cable tho. Its cached on a OS Level if you accepted it. Doesnt happen on drone disconnect either. The choose app dialog can only happen if 1. RC is turned off, 2. Connection is physically cut.

[m4xw]

https://m4xw.net/nextcloud/index.php/s/Zf526gy88McKBmX try this i guess (doesnt have the change mentioned above tho)

[tr0043t]

Will do. I'm taking the controller up to full charge before anything else. My cable is good but the controller gets pulled down pretty fast since it always charges the device and there's no way to stop that. I'm suspicious that at less than fairly full charge there may be erratic behavior (likely not affecting the video, but this USB issue).

[m4xw]

Cant say i had that before. Just came back from a field test, in the build i linked i added a transcoding rate switch if it changes more than 2.5MB. I had pretty stable feed the whole flight, only pixelation when the connection speed dropped for a bit. That build also automatically changes heading to the next WP (forced) and forces gimbal to -90° (apparently needs some fixes, if it flies fast enough the gimbal does the same as sports mode, so probably need to delay that until i actually take the pic hmm)

[tr0043t]

The USB problem was indeed apparently related to the charge state of the controller. Apparently it needs to be well up there to be reliable. I retested my build of changesurface with the changes I noted last night. Started up with good (actually great!) video on the tablet (sometimes I have to toggle to get it going). But again, video only on first start. Subsequent starts without reboot have no video. Same on tablet and phone.

Installed your apk-debug. Video starts up within a couple of seconds, AND on subsequent restarts. But it is extremely tearing and blanks out entirely every couple of seconds. Went back to my build and it behaved as before. Back to your build and it behaved as I noted above. So this seems consistent for whatever that means. Develop still looks good.

[m4xw]

Are you next to a microwave or smth, lol. Or go through lead paint? Actually serious question.

[m4xw]

Video starts up within a couple of seconds, AND on subsequent restarts.

Blame DJI, apparently resetDecoder kills your device

[m4xw]

I hope this doesnt help you, because then no clue how to deal with it https://m4xw.net/nextcloud/index.php/s/xzzK8NaNM8r3Soz

[tr0043t]

Naw, I'm in far suburban L.A., no airport nearby, even the cell towers are too far away for a really good signal! And this is all bench testing. So resetDecoder wasn't used in develop? BTW, for what's its worth, their standard Fly app has been fine.

[m4xw]

Yea I bypassed all DJI code in that regard but then we get no keyframes (full frames of content). Rn its doing it simliar like DJI Fly does, i just have a extra decoder instance to split it for the GCS. DJI Fly uses SDK v5 tho, so could be SDK v4 shenanigans. You cant compare them directly. if the build helps you, it would indicate a problem with your antennas, because that means you have constant bitrate fluctuations +- 2.5Mbit / s

[m4xw]

Could be worth trying to pin ocusync on either 2.4 or 5ghz for you as a test. What frequency does your wifi use?

[tr0043t]

Your latest build didn't make a difference -- similar behavior. Flickering in and out on first run, no video on subsequent until reinstall (though actually, I assume I could just clear out the data for the same effect -- maybe. Or maybe not). For the record, AP is at 2.4. Though I'm doing all this testing now on the app itself.

[m4xw]

Your latest build didn't make a difference -- similar behavior. Flickering in and out on first run, no video on subsequent until reinstall (though actually, I assume I could just clear out the data for the same effect -- maybe. Or maybe not). For the record, AP is at 2.4. Though I'm doing all this testing now on the app itself.

I didnt change whatever caused this to not run on subsequent starts tho..

[tr0043t]

So there's some other issue. Maybe startup timing.

[m4xw]

I had issues like that initially but fixed it for all my devices by moving it where its now. Where it was on develop, caused issues on my end.. I'd love to say you're lying lol, this is so cursed

[m4xw]

i really need a Run log of the first seconds with DEBUG = true in DJISTreamDecoder stuff..

[m4xw]

Btw did u try test mode like i said? It should bypass any startup race conditions like this..

[m4xw]

Also try making sure you start this from landscape mode. I suspect the transition to landscape is what reloads the connect/sim/open view

[tr0043t]

Ha, I'll send ya' video proof if you want it! So in Android Studio I can't get Run app to work. Is there some other way to get you a useful log? I am really reluctant to update AS because that tends to break builds. I mean, I'm happy with develop, maybe I could just build in your waypoint improvements, etc. I haven't been using test mode this morning. I'll do that shortly. Have a noon call coming up in a few minutes, I'll be back.

[m4xw]

On develop the video will eventually corrupt if u fly without keeping taking pics :/

[m4xw]

at least if u dont do a full scene change

[m4xw]

Ha, I'll send ya' video proof if you want it! So in Android Studio I can't get Run app to work. Is there some other way to get you a useful log? I am really reluctant to update AS because that tends to break builds. I mean, I'm happy with develop, maybe I could just build in your waypoint improvements, etc. I haven't been using test mode this morning. I'll do that shortly. Have a noon call coming up in a few minutes, I'll be back.

Run app probably just doesnt work because it refuses to install it because my app has a different key used. Just uninstall it prior

[m4xw]

what i do is

1. connect usb
2. adb tcpip 5555
3. disconnect usb
4. adb connect android_ip:5555
5. your phone should now auto select as run target in android studio (and u can run shit while your RC is connected)

[m4xw]

You can try manually reverting a part of this commit https://github.com/m4xw/rosettadrone_mini2/commit/bfe86500cebad9d2463e15f42a920b9de5636a50

Basically move this block back to where it initially was based on whats on the last commit

[m4xw]

I hope this doesnt help you, because then no clue how to deal with it https://m4xw.net/nextcloud/index.php/s/xzzK8NaNM8r3Soz

You could try that build again. Can you ensure me that one works reliable? Really need to get logs working mate!

[tr0043t]

OK, some progress. Testing using your test-rosetta.apk - https://m4xw.net/nextcloud/index.php/s/xzzK8NaNM8r3Soz build. I can sometimes get the app going with good video, sometimes even on subsequent starts after initial run. I think there's something timing specific. I'm trying to find the exact sequence now, which does seem to include going into test mode. When I do get video it looks very good.

[m4xw]

sounds like me but 2 commits ago..

[tr0043t]

BTW, I'm not having luck getting a log. I can get ADB connected and the RC, etc. hooked up again. But any attempt to run from AS (the device is properly selected), throws various errors about unsigned apps, etc. -- and they're all signed.

[m4xw]

you cant install it when you already have the app installed with a different signature. You also need to enable some stuff in androids developer settings for some android vers

[tr0043t]

I can get the video going almost every time now. It's like a puzzle box. Working out the exact sequence. Basically, there's a mode where it crashes on startup, and AFTER that there will be video on the next startup when you toggle.

[m4xw]

gl then, bedtime here

[tr0043t]

No luck with the logs, but you're gonna just "love" this:

I can now get the video reliably back with your test-rosetta build. The secret seems to be that after the app crashes, the next successful start will have good video after toggling the photo/video switch. So, for example:

Boot phone. Start app. OPEN Toggle photo/video [VIDEO appears. Excellent quality. No tearing.] Kill app from app manager. Start app. OPEN Video won't appear even after toggling. Crash the app by hitting the left-side "start mission" button a couple of times with no csv mission present App crashes. Start app (it may start, or may fail to start) Start app again (if attempt above failed to start) OPEN Toggle Video appears. Etc.

[tr0043t]

Super Duper Major Progress: I just did a completely sterile clean full build of your current changesurface branch. And it's working VERY well on the phone (haven't tested on tablet yet but that's much less important in my case). Haven't tested video streams yet, just video on the local app. Starts up every time. No video initially and photo/video toggle is in photo. When I toggle to video the video starts right up and look very good. No tearing. The only oddity is that the video displayed is somewhat darker in video mode, and becomes significantly brighter in photo mode. Most importantly this is behaving the same way every time the app is stopped and started without any gymnastics as above. More to come ...

[tr0043t]

More good news! Restarts continue to be fine. Sometimes the video starts right up on the app, sometimes you need to toggle. Bright/dark as I reported -- no big deal, easy to toggle to either once the video starts. Local and remote QGC video streaming look good. Sometimes it takes restarts of the app and/or QGC and/or toggling photo/video to get the video going on them, but again, no big deal. And video really looks VERY good indeed!

[tr0043t]

Now of course Android 12 will come out and break everything. I'm probably going to try block it on my phone for now.

[m4xw]

Now add this

    private float lastTranscodingRate = 20.0f;
[...]
        djiAircraft.getAirLink().getOcuSyncLink().setVideoDataRateCallback(v -> {
            // Changed more than 2MBit since last
            if(Math.abs(lastTranscodingRate - v) >= 2.5f)
            {
                VideoFeeder.getInstance().setTranscodingDataRate(v);
                lastTranscodingRate = v;
            }
        });

in drone activity, line 826 or so

[m4xw]

and try tweaking the 2.5f as required, otherwise you will get tearing when actually flying The rate at which its changed is to be discussed for ideal results

[m4xw]

Btw the last dji fly app also has RTMP streaming and they only do 5mbit, so maybe i am shooting way out of the ballpark, dunno.

[tr0043t]

I'll add that change later today. I was thinking that 10-20Mb/s was rather high for this situation. 5 may actually be just fine and avoid problems on various devices (like my quite new tablet). After all, it's really just a control feed.

[m4xw]

iirc low vals looked like shit lol

[m4xw]

The goal is basically to not let the decoder run dry

[tr0043t]

Yeah. And that RTMP feed targets YT/FB where other processing is done. Maybe 10? 15?

[tr0043t]

Now I gotta look to see why my mission simulations have failed. Probably related to that safety switch or other timing. I'm doing this all from QGC -- both the mission upload and mission start attempts.

[m4xw]

Yeah. And that RTMP feed targets YT/FB where other processing is done. Maybe 10? 15?

just trial and error. its the name of the game.

I set 20Mhz so 46Mbit/s was the upper limit. Bunch of that will be eaten by the control commands, so whatever is left for camera. I never actually checked what it sets on the VideoRate cb..

[m4xw]

also afaik the 20mhz set succeeds, not sure if it needs to set to MANUAL instead of AUTO tho to take effect. Made like no change here

[m4xw]

So i guess you can also try 10MHz with the appropriate video rate and tell me what works best for u in the end.

[tr0043t]

You're about to rebase/merge surface into develop?

[m4xw]

Not before the weekend, still buncha cleanup to do. For now just throughout testing