| 2012-07-22 20:21:41 |
Jason Gerard DeRose |
description |
2 things are blocking this:
We need to be able to register a URIHandler with PyGI:
https://bugzilla.gnome.org/show_bug.cgi?id=679181
And there needs to be a gnonlin release/package for GStreamer 1.0.
== Details ==
Novacut will have 3 types of "render servers": the playback server, the thumbnail server, and the render server.
Currently our playback is done entirely from JavaScript using a playback trick that James Raymond developed, which uses 2 <video> elements and pre-seeks to the starting frame of the next slice while the current slice is playing. While not what we'll using going forward, this was an excellent experiment that proved there's no reason a multi-core system can't deliver perfectly smooth playback at the transition point from one slice to the next when playing H.264 video from Canon HDSLR or similar cameras.
As this transition point is editing, so to speak, the playback must be flawless. gnonlin currently delivers results that are unacceptable for professional editing, and so we need to fix this.
But we do want to move the playback server to gnonlin ASAP. We can't do multicam and our first round of audio functionality with our current JavaScript tricks. We want all 3 types of render servers to use the same gnonlin composition, assembled in (basically) the same way. Eventually we want the playback server to be in a separate process, but that's going to take some work in WebKitGtk first.
The logical next step is for us to use a custom URI handler that we register in-process, and use this as a way to make WebKitGtk pass control to Python so we can build (and update) our gnonlin composition, but still use the normal <video> element from the JavaScript side of things.
For example, we'd set the video.src to something like this:
video.src = 'novacut://WZWWEGEUSKEGWW5YSTNADIHV/SRRZIZQIZHJ3KDVH3LED2OXA';
Where the URI convention specifies the project ID and node ID like this:
novacut://PROJECT_ID/NODE_ID
Although custom URI handlers are possible with python-gst, they currently don't seem possible with PyGI (see GStreamer bug 679181). So getting this bug fixed is the first place we need help.
We'll also have to provide a WebKitGtk package built against GStreamer 1.0. We really try to avoid overriding existing packages in the Ubuntu archive, but there just isn't any way to avoid it in this case. From talking with Philippe Normand, it sounds like this should be a fairly safe thing to do. Normal apps using WebKitGtk shouldn't have any expectations when it comes to the version of GStreamer, they just need <video> and <audio> to work. And as far as I know, no apps in the default install use HTML5 video or audio.
However, we need to be very cautious providing our own WebKitGtk package as critical apps like the Ubuntu Software Center use it. |
Two things are blocking this. We need to be able to register a URIHandler with PyGI:
https://bugzilla.gnome.org/show_bug.cgi?id=679181
And there needs to be a gnonlin release/package for GStreamer 1.0.
== Details ==
Novacut will have 3 types of "render servers": the playback server, the thumbnail server, and the render server.
Currently our playback is done entirely from JavaScript using a playback trick that James Raymond developed, which uses 2 <video> elements and pre-seeks to the starting frame of the next slice while the current slice is playing. While not what we'll using going forward, this was an excellent experiment that proved there's no reason a multi-core system can't deliver perfectly smooth playback at the transition point from one slice to the next when playing H.264 video from Canon HDSLR or similar cameras.
As this transition point is editing, so to speak, the playback must be flawless. gnonlin currently delivers results that are unacceptable for professional editing, and so we need to fix this.
But we do want to move the playback server to gnonlin ASAP. We can't do multicam and our first round of audio functionality with our current JavaScript tricks. We want all 3 types of render servers to use the same gnonlin composition, assembled in (basically) the same way. Eventually we want the playback server to be in a separate process, but that's going to take some work in WebKitGtk first.
The logical next step is for us to use a custom URI handler that we register in-process, and use this as a way to make WebKitGtk pass control to Python so we can build (and update) our gnonlin composition, but still use the normal <video> element from the JavaScript side of things.
For example, we'd set the video.src to something like this:
video.src = 'novacut://WZWWEGEUSKEGWW5YSTNADIHV/SRRZIZQIZHJ3KDVH3LED2OXA';
Where the URI convention specifies the project ID and node ID like this:
novacut://PROJECT_ID/NODE_ID
Although custom URI handlers are possible with python-gst, they currently don't seem possible with PyGI (see GStreamer bug 679181). So getting this bug fixed is the first place we need help.
We'll also have to provide a WebKitGtk package built against GStreamer 1.0. We really try to avoid overriding existing packages in the Ubuntu archive, but there just isn't any way to avoid it in this case. From talking with Philippe Normand, it sounds like this should be a fairly safe thing to do. Normal apps using WebKitGtk shouldn't have any expectations when it comes to the version of GStreamer, they just need <video> and <audio> to work. And as far as I know, no apps in the default install use HTML5 video or audio.
However, we need to be very cautious providing our own WebKitGtk package as critical apps like the Ubuntu Software Center use it. |
|
| 2012-07-22 20:48:51 |
Jason Gerard DeRose |
description |
Two things are blocking this. We need to be able to register a URIHandler with PyGI:
https://bugzilla.gnome.org/show_bug.cgi?id=679181
And there needs to be a gnonlin release/package for GStreamer 1.0.
== Details ==
Novacut will have 3 types of "render servers": the playback server, the thumbnail server, and the render server.
Currently our playback is done entirely from JavaScript using a playback trick that James Raymond developed, which uses 2 <video> elements and pre-seeks to the starting frame of the next slice while the current slice is playing. While not what we'll using going forward, this was an excellent experiment that proved there's no reason a multi-core system can't deliver perfectly smooth playback at the transition point from one slice to the next when playing H.264 video from Canon HDSLR or similar cameras.
As this transition point is editing, so to speak, the playback must be flawless. gnonlin currently delivers results that are unacceptable for professional editing, and so we need to fix this.
But we do want to move the playback server to gnonlin ASAP. We can't do multicam and our first round of audio functionality with our current JavaScript tricks. We want all 3 types of render servers to use the same gnonlin composition, assembled in (basically) the same way. Eventually we want the playback server to be in a separate process, but that's going to take some work in WebKitGtk first.
The logical next step is for us to use a custom URI handler that we register in-process, and use this as a way to make WebKitGtk pass control to Python so we can build (and update) our gnonlin composition, but still use the normal <video> element from the JavaScript side of things.
For example, we'd set the video.src to something like this:
video.src = 'novacut://WZWWEGEUSKEGWW5YSTNADIHV/SRRZIZQIZHJ3KDVH3LED2OXA';
Where the URI convention specifies the project ID and node ID like this:
novacut://PROJECT_ID/NODE_ID
Although custom URI handlers are possible with python-gst, they currently don't seem possible with PyGI (see GStreamer bug 679181). So getting this bug fixed is the first place we need help.
We'll also have to provide a WebKitGtk package built against GStreamer 1.0. We really try to avoid overriding existing packages in the Ubuntu archive, but there just isn't any way to avoid it in this case. From talking with Philippe Normand, it sounds like this should be a fairly safe thing to do. Normal apps using WebKitGtk shouldn't have any expectations when it comes to the version of GStreamer, they just need <video> and <audio> to work. And as far as I know, no apps in the default install use HTML5 video or audio.
However, we need to be very cautious providing our own WebKitGtk package as critical apps like the Ubuntu Software Center use it. |
Two things are blocking this. We need to be able to register a URIHandler with PyGI:
https://bugzilla.gnome.org/show_bug.cgi?id=679181
And there needs to be a gnonlin release/package for GStreamer 1.0.
== Details ==
Novacut will have 3 types of "render servers": the playback server, the thumbnail server, and the render server.
Currently our playback is done entirely from JavaScript using a playback trick that James Raymond developed, which uses 2 <video> elements and pre-seeks to the starting frame of the next slice while the current slice is playing. While not what we'll using going forward, this was an excellent experiment that proved there's no reason a multi-core system can't deliver perfectly smooth playback at the transition point from one slice to the next when playing H.264 video from Canon HDSLR or similar cameras.
As this transition point is editing, so to speak, the playback must be flawless. gnonlin currently delivers results that are unacceptable for professional editing, and so we need to fix this.
But we do want to move the playback server to gnonlin ASAP. We can't do multicam and our first round of audio functionality with our current JavaScript tricks. We want all 3 types of render servers to use the same gnonlin composition, assembled in (basically) the same way. Eventually we want the playback server to be in a separate process, but that's going to take some work in WebKitGtk first.
The logical next step is for us to use a custom URI handler that we register in-process, and use this as a way to make WebKitGtk pass control to Python so we can build (and update) our gnonlin composition, but still use the normal <video> element from the JavaScript side of things.
For example, we'd set the video.src to something like this:
video.src = 'novacut://WZWWEGEUSKEGWW5YSTNADIHV/SRRZIZQIZHJ3KDVH3LED2OXA';
Where the URI convention specifies the project ID and node ID like this:
novacut://PROJECT_ID/NODE_ID
Although custom URI handlers are possible with python-gst, they currently don't seem possible with PyGI. So getting this bug fixed is the first place we need help.
We'll also have to provide a WebKitGtk package built against GStreamer 1.0. We really try to avoid overriding existing packages in the Ubuntu archive, but there just isn't any way to avoid it in this case. From talking with Philippe Normand, it sounds like this should be a fairly safe thing to do. Normal apps using WebKitGtk shouldn't have any expectations when it comes to the version of GStreamer, they just need <video> and <audio> to work. And as far as I know, no apps in the default install use HTML5 video or audio.
However, we need to be very cautious providing our own WebKitGtk package as critical apps like the Ubuntu Software Center use it. |
|
