Split video payload into multiple RTP messages when too big to fit into one

[mannol]

Fixes #620

This is the implementation of the proposed fix for this issue.

Haven't tried it myself yet but, it's simple enough to work. NOTE: this fix does not break the protocol.

---

This change is 

[CLAassistant]

All committers have signed the CLA.

[nurupo]

I'd use UINT16_MAX constant instead of 65000.

What about the audio frame, will it always fit?

[mannol]

@nurupo ok, changed to UINT16_MAX. IIRC, yes, audio frames should always fit.

[nurupo]

Did you make sure UINT16_MAX is not treated as a special value by anything?

[mannol]

Yup.

[nurupo]

I'm building Windows qTox v1.12.1 with your patch for anyone wanting to test this, will upload once they are done. You can build it yourself by following this and changing --branch v0.1.10 \ to --branch mannol-patch-1 \ in build.sh file.

[mannol]

Great! I hope it works!

[nurupo]

Here are the qTox Windows builds for testing

• qtox_1.12.1_c-toxcore_pr-623_i686_win.zip

• qtox_1.12.1_c-toxcore_pr-623_x86_64_win.zip

(Apparently GitHub doesn't allow uploading 7z archives)

[zoff99]

its written in a most complex way. hard for me to understand

[zoff99]

this may not work because of:

c-toxcore/toxav/rtp.c

Line 190 in 0fce3fc

session->sequnum ++;

also this complex solution has the risk of intruducing new problems not yet found.

[mannol]

No, that's how standard RTP works, increasing sequnum to monitor packet order. Also, it's super simple: split large payload into smaller chunks. The decoder then takes those chunks and creates an image out of them.

[zoff99]

its hard to say. it opens up for many new, not found bug.
sequence number is used all over the place

c-toxcore/toxav/rtp.c

Line 314 in 0fce3fc

if (session->mp->header.sequnum == net_ntohs(header->sequnum) &&

[mannol]

You do realize that sequence number has nothing to do with the issue in the first place? You do realize that sequence number is used for ordering packets and is defined by the standard to be 16-bit value? Why are you talking nonsense about this proposed fix that's infinitely better (does not all of the existing clients) than your solution?

[sudden6]

Did not test, but code

---

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

---

Comments from Reviewable

[Diadlo]

---

Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[nurupo]

Would be nice if someone could test it. If someone who has video issues in the unpatched qTox 1.12.1 (the latest qTox stable release) could say if it works better in the patched qTox.

[Diadlo]

If someone will have time tomorrow at ~20:00 - 22:00 UTC+0, we can test this patch over network (ToxId in GitHub bio)

[zugz]

At zoff99's request, I just tested this branch and found that it's broken in
the same way that master is. Testing with some non-backwards-compatible by
zoff99, meanwhile, it worked perfectly.

I tested with https://github.com/zoff99/ToxCam/ branch '_video_test_01' to
send the video, using the test slides
https://github.com/zoff99/ToxCam/blob/_video_test_01_/toxcam/frame_1.yuv
https://github.com/zoff99/ToxCam/blob/_video_test_01_/toxcam/frame_2.yuv
, and using utox running locally to receive the video. With master and with
this PR, I get nothing at all. With zoff99's branch
'_0.1.10_2017_runtime_val_changes' on https://github.com/zoff99/c-toxcore/ ,
I receive the slides correctly.

I haven't really looked into this issue and I don't know what to recommend,
I'm just reporting test findings.

[nurupo]

Glad that someone tested it. Sounds like this PR doesn't fix things then, more debugging/investigation is needed.

[sudden6]

@zugz Did you use the patched c-toxcore from this PR only as receiver? Because this fix can only work at the sender side.

[zugz]

* Sunday, 2017-11-26 at 20:43 +0000 - sudden6 <notifications@github.com>:

@zugz Did you use the patched c-toxcore from this PR only as receiver? Because this fix can only work at the sender side.

I used it on both sides. Just tested again to be sure - same results.

[mannol]

Trying it out myself. I also used toxcam branch '_video_test_01' compiled with this patch to send the video. And this is the result: https://streamable.com/215y8

@zugz Is that the expected result or?

NOTE: In the video, there are some frames lost due to the screen recorder.

[zugz]

* Sunday, 2017-11-26 at 21:43 +0000 - mannol <notifications@github.com>:

@zugz Is that the expected result or?

Weird. Yep, I believe that's how it should look. So I've no idea why it doesn't work for me. I'd assume it was some unrelated problem with my setup, except that zoff99's branch does work for me.

[robinlinden]

---

Reviewed 1 of 1 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

---

Comments from Reviewable

[zoff99]

@mannol test again with _video_test_01_ but this time copy "frame_3.yuv" over both frame_1 and frame_2 so that it will only use frame_3.
also what CPU does your sending system have? test outcome largely depend on that. it needs to be powerful for the test to show the bug.

also dont use qTox for the test, the received video window is to small to see if its crunched down or really full res

[mannol]

@nurupo network test is failing. What do?

[nurupo]

No idea, you are asking the wrong person, I haven't been following toxcore development for at least a month or two now and back then everything was passing.

[nurupo]

There were some network refactors in toxcore recently, could be something to do with that, or could also be some issue on Travis's side. Ideally someone would debug why it's failing and fix it. I have also noticed it failing in the zoff's PR and have bugged @robinlinden about it since he has been keeping an eye on toxcore and merging PRs, but it seems like he doesn't know either. Out if curiosity, does the test fail locally for you?

[zoff99]

@mannol @nurupo let me just check that quick ...

[nurupo]

The network test passes locally for me, using the same flags that the clang travis does but with turned off format test:
cmake -DASAN=ON -DDEBUG=ON -DSTRICT_ABI=ON -DTEST_TIMEOUT_SECONDS=120 -DTRACE=ON -DUSE_IPV6=no -DERROR_ON_WARNING=ON -DBUILD_NTOX=ON -DFORMAT_TEST=OFF ..

[zoff99]

i changed the settings in circleCI

somebody set it so that not all commits were built. so you dont know which commit introduced the bug.

[Diadlo]

@zoff99 Probably, bug introduced by Travis

[zoff99]

its working now in circleCI. please don't change circleCI settings without first checking.

[zoff99]

@robinlinden @Diadlo @sudden6 wow 3 times LGTM without 1 single test.
i actually tested it myself and with zugz and it does not work

[zoff99]

#629

[mannol]

@zoff99 I presented an example of unpatched and patched versions on which there is a clear evidence of quality improvement.
You said:

also what CPU does your sending system have? test outcome largely depend on that. it needs to be powerful for the test to show the bug.

also dont use qTox for the test, the received video window is to small to see if its crunched down or really full res

And I'll say it again: there is a clear difference between unpatched and patched versions; the unpatched version is so bad that you can't see anything while the patched version is ok.

[sudden6]

I got around to testing this now too.

Setup

• PC1, qTox tag v1.13.0, c-toxcore master
• PC2, qTox qTox/qTox@9ac5f88, c-toxcore master, later switched to this PR

Both PCs are connected over WLAN. The WLAN has a few percent packet loss, so I think this is a good simulation of a longer distance internet connection.

Test1

PC2 shares the screen (2960 x 1050) to PC1, PC2 is on c-toxcore master

• No picture ever from PC2 on PC1, webcam (320p) displays fine on PC2

Test2

PC2 shares the screen (2960 x 1050) to PC1, PC2 is on c-toxcore with this PR

• desktop is shared to PC1, webcam displays fine on PC2
• sometimes the lower part of the desktop is grainy/not sharp on PC1
• rarely the desktop is displayed as pink on PC1 for a few seconds

Test3

PC2 shares the screen (2960 x 1050) to PC1, PC2 is on c-toxcore with #622

• desktop is shared to PC1, webcam displays fine on PC2
• only the top 25% of the desktop are displayed correctly on PC1, the rest is always corrupted.

Conclusion

This PR gives better results than #622, but does not completely fix the problem. I think this PR should still be merged since it improves the situation without breaking the protocol and the complete fix most likely needs this anyway.

[robinlinden]

@zoff99 I tested this PR before LGTMing it and it does work better than the current video sending code.