-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Video uploading endpoint #9
Comments
Includes an endpoint for uploading a video, and one for checking the status of the upload. Includes a background thread that simulates the processing of videos (copies files from one directory to another and updates the database every 10 seconds). Please refer to #9 for more information.
Here's an update for this issue. The commit above includes an endpoint for uploading a video, and one for checking the status of the upload. It also includes a background thread that simulates the processing of videos (copies files from one directory to another and updates the database every 10 seconds). I'm showing what it looks like in action below. Request:
Output:
Request:
Output:
Request:
Output:
Once the status is "Success", a (defect) version of the file can be downloaded from Instead of returning a The file can be downloaded, but includes some information that is not relevant to the uploaded file. I have created an issue about it at silkapp/rest#137. |
Ah, when I uploaded the video using Curl's Request:
Output:
Request:
Command:
And voilà, it plays. :) |
Nice :) Can I get a list of videos? Can I list per club/team/training-phase/..? |
(Sorry, I posted a copy of this message before it was finished, so I deleted that and wrote another one.) There are currently no relations between anything other than the Video and Club entities. I have made endpoints like For the second question I suppose that each video should be able to reference a team, a member, and a training phase. While the possibility of referencing at most one of each of these do for now? |
(About using lazy bytestrings, as in our current solutions: Some streaming interface would be better, since lazy IO is a bit finicky. The problem with lazy IO is that it doesn't give you control over when stuff happens. I.e. it will read from the file handler when you "look at" the bytestring. You can't control when the file handle is closed.) |
In addition to compressing the video, we probably want to generate a thumbnail (or several) for any given video as well. |
Better video support (#9): Added a video metadata step necessarily preceeding the video upload. By including an optional member identifier, we could realize the capability of instructional videos alongside individual performance videos (no member identifier means that it's an instructional video). Additionally, the video metadata includes required club and training phase identifiers (one of each). We can now get a list of videos per member, training phase and team (team is inferred by the member, if this value is set) in addition to per club. JSON relation clarifications: The JSON should now contain identifiers to explicitly express the entity relationships. Will solve issues analogous to #8. Web improvements: Added simple video viewing (assuming WebM). Fixed a problem related to the teams select box being visible even though no teams exist.
The video functionality has received significant changes in ccd9ffc. Like before, videos belong to a given club. Videos are created by first setting the metadata, and then by uploading the actual video data. The first of these two steps is carried out like so:
The payload of the above request must be
The output will look something like this:
The second identifier in the GET request is the identifier of the video as returned by the first request. The information returned has the following properties: In order to make the video "complete", and visible, throughout the API, upload the video data:
A command-line example for uploading a file would be:
Upon successful uploading of the video data you can monitor the information returned by the GET request above. Once the video has been successfully processed, you can access it using the following request:
You can at any time get all videos for a given club, all videos related to a given member, all videos related to a given training phase, all videos related to a given team (derived from the member that might be set for a video), or all instructional videos (i.e. all videos without any
The assumptions are that we don't need to reference a team directly and that we don't need names for videos. We still might want to pursuit non-lazy IO for uploading, as well as thumbnail images. Also, we are still not compressing the video, or changing it in any other way. We should probably investigate using ffmpeg for this. |
Great news: Video files can now be converted to WebM files! What happens under the hood is a simple invocation of the avconv (ffmpeg) binary). We are using the default libav-tools as shipped by Ubuntu (the system upon which the Haskell Docker image is built), as can be seen here. So the functionality is not fancy or anything, but so far, it at least seems to fulfill our basic video compression needs. I thought it might be useful for me to show some step-by-step instructions on how to upload (and download) a video using Curl. First, we need a club.
I'll use an environment variable for the club UUID, so that the instructions below are cleaner and easier to copy and paste.
Since every video has to be associated with a training phase, let's create one.
Analogous to above, I'll store away the training phase UUID.
Next, we'll create the video (metadata).
We'll save the video UUID in an environment variable as well.
At this point, the video exists, but since it doesn't have any video data associated with it, it won't be visible on the site. However, since we know the video identifier, we can query the video metadata like so:
Now, let's upload some video data:
The API will now begin processing the video data into our desired format (WebM). If we repeat the GET request performed above, we can see that the status of the video now is "processing". This can be the basis to, for instance, show a loading animation in the client.
The video file, around 30 MB, took between two and three minutes to process on my machine. However, since this happens in a separate thread, the API was still responsive during that time. Once the video has finished processing, the status will changed to "complete" (unless Ffmpeg finishes with a non-zero exit code, in which case it will change to "failure"):
We can now download the video with a simple GET request.
I have tried to upload both 3GP and MP4 files, and both worked. I also accessed the video files using the web client, and both could be played. Additionally, the endpoints mentioned in my last comment (fetching videos by member, team, training phase and instructional) still works, and so does the functionality of specifying the optional member UUID when creating the video. What do you think? Do you think you could put together some Android client-side magic using this? :) |
Hi, again! I have now added the possibility of downloading a picture snapshot from the video. This picture can be used as a thumbnail picture or whatever. The snapshot will be in the JPEG format, and is of relatively high quality, and is currently of the same resolution as the video. This "poster" picture can be downloaded like so:
One current limitation is that the picture is taken in the first frame. See #19 for more information about this. |
Just to make sure. When downloading a file we get it in webm format? |
That's correct. :) |
Here is how the video is produced: https://github.com/hesa/coachassistant/blob/master/server/source/Main.hs#L70-L73 |
Just got download to work. Request code OK and all. Will implement replacement of the "local" later Now food .. and more beer |
Lovely! :) Nice work! |
Later is now. |
Awesome! |
I should look through this issue, and probably close it. |
This issue can be closed. |
- Add new video filter endpoints (#9) - Add new "videos" tab in the web application (#41) - Add new "videos" page in the web application (#41) - Fix a problem resulting in large files not being uploaded - Give PostgreSQL a few more seconds to start up - Make some JavaScript refactoring related to resolves
Uploading a video file would work something like this:
POST
and themultipart/form-data
encoding to something like/upload-video
)202 Accepted
, and in the body include the identifier of the asynchronous video conversion job that has now startedGET
at something like/query-video/<ID>
; while the server is processing the video, it will respond with200 OK
and something likeProcessing
in the body; when the server is done processing the video, it will respond with either303 See Other
with the identifier of the new processed video in the body, or200 OK
and something likeFailure
in the body/video/<id>
usingGET
I will create a mock endpoint for this soon providing the same video back as uploaded after a certain amount of time, after which I'm planning to taking a look at converting the video to a proper/compressed format using something like ffmpeg.
The text was updated successfully, but these errors were encountered: