Open criticaltv opened 4 years ago
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 600.0 LPT (294.12 USD @ $0.49/LPT) attached to it as part of the videoDAC fund.
Hi @psudoanon thanks for applying.
Let me know if you have questions about setting up the Streaming Back-End to test against.
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
So far I've gotten the basic application architecture setup, finished reviewing the linked Kotlin RTMP library and implemented permissions handling; I'll be making a small update to the RTMP module in order to make the keyframe interval configerable before proceeding to the wallet generation and testing with a local backend
OK cool.
Do you have any blockers that I may be able to help with?
@criticaltv
I'm running into an issue with the streaming backend.
Followed the setup instructions for the precompiled binary and it works fine when using FFMPEG to send a test broadcast signal to the RTMP endpoint.
Once I try sending a video signal from the Android app and linked RTMP library I get the following SegmenterTimeout
error:
Any ideas on what might be causing this? The signal being sent is H264 AVC at 30FPS
We sometimes get this when it doesn't send a keyframe...
Thanks, yeah looks like that was it :)
On Wed., Apr. 22, 2020, 2:17 p.m. criticaltv, notifications@github.com wrote:
We sometimes get this when it doesn't send a keyframe...
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-617946448, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUJZGV5U4CI6MJPRQNTRN4YFDANCNFSM4LDOTFXA .
OK @psudoanon - that's reassuring to know that you've resolved that one.
Keyframe interval is a regular "thorn in my side", which is why it was specifically called out in the spec.
You may also wish to have a look at these simpler instructions for a streaming system - they use the same base software as Streaming Back-End, but much much simpler: https://github.com/videoDAC/simple-streaming-server/
Do please let me know if you hit any more blockers. Hope you're well
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
Hey, sorry for the delay.
Ended up having to go through a couple different RTMP libraries before finding one that worked reliably; just finishing up the wallet generation side of things and then I'll have a PR and the associated resources all generated and uploaded :)
On Mon., Apr. 27, 2020, 12:15 p.m. Gitcoin.co Bot, notifications@github.com wrote:
@psudoanon https://github.com/psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
- reminder (3 days)
- escalation to mods (6 days)
Funders only: Snooze warnings for 1 day https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=1 | 3 days https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=3 | 5 days https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=5 | 10 days https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=10 | 100 days https://gitcoin.co/issue/videoDAC/android/31/4223?snooze=100
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-620086105, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUK24NYLKYJ4OHJAW5DROWVS5ANCNFSM4LDOTFXA .
@psudoanon thank you for your continued efforts on this - much appreciated.
Looking forward to seeing what you have made :)
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
Hello @psudoanon sorry about the gitcoin bot.
Is there anything I can do to help with the template app build?
No worries, I'll have a PR up soon and then you can verify it builds locally on your end :)
On Mon., May 4, 2020, 1:56 a.m. criticaltv, notifications@github.com wrote:
Hello @psudoanon https://github.com/psudoanon sorry about the gitcoin bot.
Is there anything I can do to help with the template app build?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-623271759, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUKYMGC4QN3Z62FCZDLRPZKHDANCNFSM4LDOTFXA .
Hey @criticaltv
I've filed a PR here: https://github.com/videoDAC/android/pull/45
Do you mind taking a look and making sure you can import into Android Studio as expected?
As far as the APK deliverables go, where would you like the RTMP base URL set to? The application is also using the Infura API. I was using a personal API key I generated while developing - did you want to setup your own?
@psudoanon thanks I'm trying my luck with it now.
Is there an email address I can get you on to share the RTMP endpoint, it's a little sensitive :)
Yeah, you can send it to adam.allidina@gmail.com :)
On Sat., May 9, 2020, 6:35 a.m. criticaltv, notifications@github.com wrote:
@psudoanon https://github.com/psudoanon thanks I'm trying my luck with it now.
Is there an email address I can get you on to share the RTMP endpoint, it's a little sensitive :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-626145644, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUI52XPMGHSEZ6V2Z3DRQUWYFANCNFSM4LDOTFXA .
Hey, so, I've managed to generate an apk from the code, using Android Studio - which is cool.
Some initial feedback:
I've managed to get the app connecting to a local instance of simple-streaming-server
- which is great!
The screen goes dark, per the system's screen time-out setting (in my case 15 seconds!) - and when this happens, the streaming stops also. The app should take over the entire screen, and keep hold of it until the user taps the screen to close the app.
The UX / UI doesn't seem to follow the principles set out in the original issue:
In essence, the objective is to limit user interaction down to:
- tap app launcher = start streaming
- tap screen = stop streaming.
...and nothing else.
So, the following are unnecessary for the user and can be removed:
I know that this approach might seem unconventional - but I am really trying to simplify things for an end-user, and to make the UI as uncluttered as possible.
So, in essence, it should look like this to the user at all times:
such that the only action required from a user is to "tap screen", and the app takes care of the rest.
(I acknowledge that the "LIVE" indicator was not in the original specification, so feel free to raise an issue for this, and I will add a new bounty to it, if you would like. This should perhaps be grey if the device is unable to connect via RTMP...)
But I'm really pleased with the progress... and with a few simplifications, it could be really interesting to play with.
Some other thoughts - for future scope, future issues, future bounties - just spitballing:
Perhaps display the user's Ethereum address with the balance, so that they can see who they are
If the app can't connect to the rtmp endpoint, perhaps show a subtle android notification error message like "Check your internet connection"
Perhaps replace the "Broadcasting to rtmp://..." subtle notification with something like "view your livestream at http://livestream2earn.com/stream/0x62CD952fEa913116F304C89e24c0E2181682048C" or similar. This may be too complex for now, but worth considering for future.
Also... when you switch the orientation of the device, this appears to kill the stream... steps to reproduce:
Hopefully this may all be fixed by the above requested removal of complexity associated with a) starting / stopping streaming, b) switching orientation etc.
Hey, I've finished addressing the issues you've mentioned and will have a new repo up soon with the updates
I've also added a new issue for the "Live" indicator https://github.com/videoDAC/android/issues/46, feel free to add the image resource to that ticket if you have one
Regarding the other functionality you mentioned, I'd be happy to work with you to get those featured implemented as well :)
@psudoanon thank you for the update - great news that you're done with the issues.
Perhaps let's leave it in the android
repo after all, as there may be some benefit in terms of coordination / re-use of work done by @mul1sh on Connext 2.0 integration.
I see your issue has had some contributions from the videoDAC community already!
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@criticaltv I've updated the PR with your requested changes, would you mind taking a look? Once we get everything finalized on this bounty I can get started with the "Live" indicator :)
@criticaltv have you had a chance to take a look at this? was wondering what your thinking regarding @mul1sh comment regarding switching the PR repository. thanks :)
Hi @psudoanon I am looking at this.
I'm trying to load it up in a clean install of Android Studio on a clean install of Ubuntu.
I'm hitting these errors when importing the project:
I will try to debug it, but if you have any pointers, I would appreciate them.
@chrishobcroft you need to enable some SDK stuff - see stpe 5 of this: https://github.com/videoDAC/pay-to-play/blob/master/APK/Import/index.md
@psudoanon I've managed to get a build running on a phone.
Some feedback:
It succeeds at launching if the phone is held in landscape mode.
I would expect to be able to launch the app in any orientation. Hopefully it's a simple enough fix?
It seems much less processor heavy, the last version drank battery like a fish, and the phone nearly melted. This one seems subjectively less hot. I wonder if that's just circumstance.
The first time the app is launched (in landscape), it crashes...
Here's the flow of "calls to action" steps I observed:
Second time launch (i.e. after the permissions have been granted), the app launches successfully, and starts streaming into the endpoint.
There is some kind of interstitial page as the app launches - which flickers before the camera appears. I hope this might be easy enough to remove?
The app offered to report some kind of bug to something called blueline - do you know what this is?
The persistent notification about the Private Key being on the clipboard is a nice touch. The user needs to swipe it away, so it's harder for them to miss it! I have created an issue to track ideas for how to develop this further: https://github.com/videoDAC/android/issues/50
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@psudoanon Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@criticaltv Thanks for the detailed bug report, hope to have an update ready for you this weekend. #50 looks good as well!
@criticaltv I was looking into the crash when launching the application in portrait mode, can you confirm that it only crashes when the Android system portrait lock is enabled? I think there are two ways we can go about fixing it:
1) If portrait lock is enabled, have a dialog pop up prompting the user to disable the portrait lock before continuing application setup 2) Allow for broadcasting in portrait or landscape, default to broadcasting in landscape if no sensor lock is enabled and respect system sensor lock settings if enabled
Do you have a preference?
My preference is for something more simple, and in fact, more rigid (and hopefully less complex!)
To give you a flavour, I suggest that you try out Alice's Pay-to-play Streaming app on a physical smartphone (not an emulator).
The app takes over the whole screen, fixing the content in the display. No matter how you turn your phone, it keeps the same orientation, even if you set the screen to "auto-rotate". It doesn't try to be clever, it stays fixed in place.
I like this because:
What I would propose for the Publisher, is to also fix things, and don't try to rotate (i.e. ignore the OS "auto-rotate" settings).
if the Publisher changes the camera orientation, then the app should keep everything as it is in relation to the device, fixed, in landscape mode. The Consumer gets to feel the change in orientation, and can actually adapt to it themselves.
For me, this would represent minimum complexity, and would also integrate most effectively with the Consumer app.
Does that make sense? Hopefully, this might represent the least-complex path to closing this issue - but I will let you decide, as this behaviour was not explicitly specified in the original issue.
OK, FWIW, on further investigation, I've got it working on my device, so I've been able to investigate how it behaves with different "Auto-rotate" settings in the OS.
Here is a summary of findings
Auto-rotate ON | Auto-rotate OFF | |
---|---|---|
Launch with device in Portrait orientation | APP CRASHES | APP CRASHES |
Launch with device in Landscape orientation | APP LAUNCHES | APP CRASHES |
Hello @psudoanon - how are you?
Are you able to share any progress on the development of this feature?
Are you still intending to proceed with delivering this bounty?
Thanks
Yeah sorry about the delay, had a busy few weeks where I've been focusing on other stuff; I'll try to have a fix before the weekend, just been having difficulties reproducing the reported crash on my device.
@criticaltv would you mind letting me know the make / model of the Android device you're using along with the Android version?
Thanks!
On Wed., Jun. 24, 2020, 5:32 a.m. Chris Hobcroft, notifications@github.com wrote:
Hello @psudoanon https://github.com/psudoanon - how are you?
Are you able to share any progress on the development of this feature?
Are you still intending to proceed with delivering this bounty?
Thanks
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-648709618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUIOQBDT5XUV7J6BBIDRYHBZTANCNFSM4LDOTFXA .
@psudoanon
Also, still able to replicate that same behaviour...
Hey @psudoanon where are you at with this?
@mul1sh is nearly done on multi-channel support.
If we could deliver this feature and close this issue, we could enable multi-Publisher from mobile, to be connected with multi-Consumer, with pay-per-minute.
I also have a public school in India who would be a great use-case for what we're building. Proposing to use Goerli to measure which teachers the students watch the most... whoever receives most göETH from students.
There's also a lot of work in the pipeline to evolve this concept, including:
integrating Consumer app with Publisher app to create integrated end-user experience. UX/UI Design is almost complete.
integrating with Canon's SDK for connecting DSLR cameras, for beautiful visual quality
integrating with the device's microphone input, to allow stereo line-in, e.g. from a professional sound-mixer.
integrating zksync for gasless Publisher operation (helps onboarding), cheaper payments (reduces cost per minute), and gasless withdrawal to e.g. a Crypto-Fiat exchange.
integrating with ENS / 3Box to make decentralised / on-chain "Publisher profiles"
integrating something like Jitsi, for written chat (and maybe even picture-in-picture video) comm's during livestream
there is also a plan to offload the payment validation to the server-side, and pay per-2s-segment using Probabilistic Micropayments, with a DPoS staking mechanism for community to stake to Publishers, and receive share of fees.
But we need to deliver an MVP first.
Yo @psudoanon - I echo @chrishobcroft's words here.
Keen to know when we can ship this. I feel we're so close to having something which would be very interesting to release and try out with real end users.
Let us know if we can help with anything?
@psudoanon - we haven't heard from you for over 6 weeks now.
Please can you update on whether you intend to complete this work?
If I don't hear from you in 48 hours, I will open this bounty to other contributors.
Hey, sorry about my delays. I got caught up in some personal business earlier this summer and didn't have much time to dedicate to this. All good now and I'll try and have the updates ready for you within the week.
On Sun., Aug. 9, 2020, 5:22 a.m. criticaltv, notifications@github.com wrote:
@psudoanon https://github.com/psudoanon - we haven't heard from you for over 6 weeks now.
Please can you update on whether you intend to complete this work?
If I don't hear from you in 48 hours, I will open this bounty to other contributors.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/videoDAC/android/issues/31#issuecomment-671028828, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOZ6FUIFPBN5PUWNHUJTW73R7ZTG7ANCNFSM4LDOTFXA .
@mul1sh Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
@mul1sh Hello from Gitcoin Core - are you still working on this issue? Please submit a WIP PR or comment back within the next 3 days or you will be removed from this ticket and it will be returned to an ‘Open’ status. Please let us know if you have questions!
Funders only: Snooze warnings for 1 day | 3 days | 5 days | 10 days | 100 days
Introduction
This issue is to define the minimum viable product for a MVP "Livestream-to-earn" Template Publisher App.
MVP stands for "minimum viable product", and represents the minimal feature set to achieve the objective.
A Template App is a body of code which can be used to publish an app, configured for a specific situation. This allows a base level of functionality to be replicated by anyone for their specific circumstance.
"Livestream-to-earn" is the act of livestreaming, and at the same time being paid by anyone who is consuming the livestream.
Example Usage
For example, the Template can be used by Ethereum Football Club to publish the
Ethereum FC Livestream-to-earn
app.This would allow any spectator at an Ethereum FC match to livestream the action, and get paid in Ethereum, by anyone who is watching.
Scope of Functionality
The app should allow the User to:
Publish video and audio from their device's camera and microphone
See the video which is being livestreamed
Monitor for payments from "pay-to-play" consumers
User Journey
Screen 1 - on launch:
The following user interactions are possible:
Screen 2 - go live:
The following user interactions are possible:
Screen 3 - receive first payment:
The following user interactions are possible:
Screen 4 - more information (overlay)
The following user interactions are possible:
Layout
The layout of the app should be as defined below.
The app must be implemented to these specifications in order for this issue to be closed and bounty to be paid out.
Base Canvas (
9x16
)The app as designed above requires a canvas on a device with a
9x16
aspect ratio - such as2160x3840
,1080x1920
,720x1280
or450x800
.If the device has a screen with a
9x16
aspect ratio, laying out the app should be trivial.If the device does not have a screen with a
9x16
aspect ratio, the app should allocate an appropriate frame with a9x16
aspect ratio on the device's screen for the app to operate in. Laying out the app should then be trivial.On Launch Layout
Livestreaming View Layout
Livestreaming View Detailed Layout
Layout Components
Header Bar (
9x1
)The artwork for the Hamburger Button and x will be provided during the implementation.
Wallet Bar (
9x1
)The two lines of text should be the same length (which will require different font sizes).
The two lines of text should be aligned in the centre of the panel, with appropriate padding / spacing.
Live Camera Panel (
9x9
)The "live" text should be displayed over the camera feed, to tell the user that they are live.
The microphone level monitor should show if sound is being detected by the microphone.
"You" Panel (
9x2
)Note: the price per minute should be set as a default in the app template.
Note: the "set your price per minute" function should be inactive (for now). This will require some further integration with the Consumer app.
Broadcaster Node Bar (
9x1
)The Broadcaster Node is the server receiving the livestream from the user, and distributing to consumers.
They are responsible for running the broadcasting server. They will not receive any income from consumers in this phase.
Live Stream Selector Bar (
9x2
)App Specifics
No Internet Connect
In the event that the device does not have internet access to the RTMP endpoint or the ETH endpoint, the app should still launch successfully, activate the camera, and allow a user to select "You" to go live.
In this instance, the app will not be able to retrieve the wallet balance, and will not be able to go live.
The app should be able to gracefully handle the situation when it is unable to either a) reach the RTMP endpoint, b) reach the ETH endpoint, and to report these errors to the user.
Disconnection
In the event that the livestream fails for any reason, the app should handle this gracefully, and inform the user that they are no longer live.
In this instance, the app should return the user to Screen 1, with an appropriate error message.
Configuration of template
The following parameters should be configurable by a user of the template, when creating the app:
Copy
All copy, e.g. error messages, titles, hamburger button content should be configurable in the template.
Broadcaster Node settings
rtmp://89.145.161.141:1935
Payment settings
AV settings
2000kbps
320kbps
Specific Deliverables
Code should be written in pure Kotlin, and should make use of existing open-source libraries wherever possible.
The following specific deliverables are required for this issue to be closed and any bounties paid out:
Sample app generated from template:
.apk
file fordebug
purposes.apk
file signed forrelease
to e.g. Google Play Store or FDroid.Merged PR to this repo containing:
Resources
KEthereum
Kotlin RTMP Library
videoDAC's Streaming Back-End