Page last modified 17:13, 10 Dec 2009 by redfive
Device Video Compatability
Table of contents
- 1. Goals
- 2. Use Cases
- 3. Weekly Deliverables
- 3.1. Iteration 1
- 3.2. Iteration 2
- 3.3. Iteration 3
- 3.4. Iteration 4
- 3.5. Iteration 5
- 3.6. Iteration 6
- 4. Specifications
- 4.1. Device-Video compat.
- 4.1.1. Wireframes
- 4.1.2. Stories and Tasks
- 4.1.3. Notes
- 4.1. Device-Video compat.
- 5. Additional Considerations
Goals
- Given a URI to a file, be able to hand back an object that contains the details about the video contained within
- Given the details of a video and a set of capabilites from a device determine if the file is supported by the device.
- Deal sanely with holes in the metadata about devices or files. e.g. a device may only report formate and profile but not bitrate (mpeg4 SP).
Use Cases
- User syncs a video to their device that is much greater than the capabilites of the device (e.g. a blueray dvd rip)
- User syncs a video to their device that is close to the capabilites of the device (e.g. a current video downloaded from the web)
- User syncs a video to their device that is much lower than the capabilites of the device (e.g. a camcorder video from 2001)
- User syncs a video to their device that matches the capabilities of the device
Weekly Deliverables
For each week here is what is expected to be functioning and/or testable.
Iteration 1
Iteration 2
Iteration 3
Iteration 4
Iteration 5
Iteration 6
Specifications
an initial brain dump of things to tackle in this project
Determining if a video file is compatible with a particular device
- A separate service that will compare the device caps and a video file. (location TBD)
- Will need API something like: var fileDetails = svc.analyzeFile(uri) (unscoped 3)
- sbIMediaInspector extensions
- some new gstreamer code has just landed to support this and may have build impact.
- Another API that take sthe fileDetails and intersects with device Caps to see if the file is supported. (long but straight-forward impl) (2-3pts)
- what to do with missing entries for DeviceCaps? ( need sane defaults -- narrow range or EVERYTHING? -- different for every attribute )
Device-Video compat.
Wireframes
Stories and Tasks
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19039 | P2 | 0 | add the compatibility inspection for video file and device | When syncing video files to device, we need to have a way to determine if a video file is compatible with a particular device, does the file need to be transcoded to a certain video format so that the device can support. Basically this involves to get the media format for the file from GStreamer part and compare that with the device capabilities. This is the story bug for the compatibility check. | alfred | N/A |
| 19040 | P1 | 0 | Implement gstreamer service to get the media format info for video file | The GStreamer service will implement interface sbIMediaInspector to inspect the video file. The media format information will be retrieved so that can be compared with the device capabilities for compatibility checking. The format information should include something like bitrate, samplerate, width, height, video PAR, frame rates and some other codec-specific properties. sbMediaInspector::InspectMedia was designed to retrieve the media format information for a given media item. This matches with what we plan to do here. There might be some efforts to refactor/rename the sbIMediaInspector interface. From Mike, "It'd create instances of some other object, perhaps depending on the file extension - e.g. in the future, we might have a simple taglib-based inspector for some audio formats, and then the more complex gstreamer inspector (that will normally be slower, too) for video formats and other things taglib doesn't understand. For this release we'd only have the gstreamer implementation." | alfred | N/A |
| 19042 | P1 | 1 | Implement sbDevCapVideoStream to get the device video capability | The missing piece that we need to implement includes: sbDevCapVideoStream - GetType - GetSupportedExplicitSizes - GetSupportedWidths - GetSupportedHeights - GetSupportedVideoPARs - GetSupportedFrameRates - GetSupportedBitRates The above functions give the properties that's supported by the device. The compatibility check can be made between these properties and the media format information from the gstreamer service. Cost to 2 as it looks to be pretty straight-forward. | alfred | N/A |
| 19043 | P1 | 2 | Implement the comparison between device capabilities and media format info | This will probably be implemented as a service to compare device capabilities and media format info. The comparison should include bitrate, samplerate, width, height, video PAR, frame rates and some other codec-specific properties. Comments from Mike: "we'll need to compare some of the codec-specific properties. e.g. for mpeg-4 part 2, we'll probably have a "profile" property. Devices might support just simple profile, or possibly a (short) list of different profiles? A particular file might have some other profile used. We should (probably on the wiki) get together a list of all the canonical container and codec names we're going to use, and what properties we're going to have for them." "The existing bitrate check is also no good - we actually need to check the bitrate of the video stream, and the bitrate of the audio stream independently, and we can probably ignore the bitrate of the file as a whole. We'll add this info into the sbIMediaFormat interfaces somewhere" And also need to figure out the case for DeviceCaps missing entries. From sbIDeviceCapabilities.idl, two video properties can be null: supportedWidths, supportedHeights. In this case, comparison should fall back to supportedExplicitSizes. Apparently it's better to have some sane default values if we can't get proper setting from device or SBSettings.xml and the comparison can still work properly. Cost to 3. | alfred | N/A |
| 19045 | P1 | 2 | Expand DoesItemNeedTranscoding for video support | Currently, DoesItemNeedTranscoding only compares bitrate and samplerate for audio. We'll need to add the code logic for video support by using the comparison service. This function will in turn be used by device transcoding part to determine whether the video file needs to be transcoded. Cost to 2 for now. Could be a 1 with the comparison service ready. | alfred | N/A |
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19040 | P1 | 0 | Implement gstreamer service to get the media format info for video file | The GStreamer service will implement interface sbIMediaInspector to inspect the video file. The media format information will be retrieved so that can be compared with the device capabilities for compatibility checking. The format information should include something like bitrate, samplerate, width, height, video PAR, frame rates and some other codec-specific properties. sbMediaInspector::InspectMedia was designed to retrieve the media format information for a given media item. This matches with what we plan to do here. There might be some efforts to refactor/rename the sbIMediaInspector interface. From Mike, "It'd create instances of some other object, perhaps depending on the file extension - e.g. in the future, we might have a simple taglib-based inspector for some audio formats, and then the more complex gstreamer inspector (that will normally be slower, too) for video formats and other things taglib doesn't understand. For this release we'd only have the gstreamer implementation." | alfred | N/A |
| 19187 | P1 | 2 | concrete implementation of sbIMediaInspector with gstreamer | From bug 19040 comment #2, we'd like to split the task into two so that Mike and I can take one separately. This one is for the concrete implementation of sbIMediaInspector in the form of XPCOM, which I'll be working on. | alfred | N/A |
| 19188 | P1 | 3 | Get the media format information out of media item using gstreamer | From bug 19040 comment #2, we'd like to split the task into two so that Mike and I can take one separately. This one is to actually get the media format (container, audioType, videoType etc.) information using gstreamer. Mike will be working on this one. Set to critical to make sure it's picked up for the Dec. 21st deliverable. | msmith | N/A |
Notes
- Assets (e.g. graphics)
- Risks (e.g. unknown APis, dependencies, black holes)
Additional Considerations
Top level things to consider across all stories/tasks.
- Integration
- e.g. More than regular amounts of overlap with other ongoing or completed projects
- Special QA Requirements
- e.g. addons for testing, special file setup
- Build and Release impact
- e.g. non-public portions, subversion moves,
- BizDev
- e.g. licenses or contracts required, NDAs needed
- Project Manangement
- e.g. code or specs needed from a partner
- Tag page
- What links here
| Images 0 | ||
|---|---|---|
| No images to display in the gallery. |
You must login to post a comment.
