Page last modified 05:16, 10 Dec 2009 by palant
Video Transcoding Device Support
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 Sync UI
- 4.1.1. Wireframes
- 4.1.2. Stories and Tasks
- 4.1.3. Notes
- 4.2. Device Capability Lookup
- 4.2.1. Wireframes
- 4.2.2. Stories and Tasks
- 4.2.3. Notes
- 4.1. Device Sync UI
- 5. Additional Considerations
- 6. Data Flow Charts
- 7. Video Transcoding Device Implementation
- 7.1.1. Wireframes
- 7.1.2. Stories and Tasks
- 7.1.3. Notes
- 7.1.4. Additional Considerations
Goals
- Allow users to transfer videos to their devices that are in an original format that is not compatible with their device.
- Expose the capabilites related to video playback for particular devices
- Extend the current device preferences for audio transcoding to support video transcoding
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)
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
Broken down by major area of functionality. If wireframes are required they should appear first in the section followed by the stories and tasks that relate to that wireframe.
As an initial drop of the topics covered in this project:
- Device Support for transcoding (roughly 5pts)
- plugging in the calls to the transcoding service into the device transfer code (msc, mtp)
- this should be about it, the changes should be plugging in calls into the existing transcoding code, (which should have been separated from audio transfer/trcoding during Led Zeppelin for the Basic Video Sync)
- Device caps
- Implement parsing and usage of the DIT
- Determination of what formats, codecs, framerate, size, bitrate etc, are supported by a device.
- further extenstions to sbIDeviceCapabilities most likely.
- What is our default behavior for MSC devices? MTP devices? -- MSC definitely won't have any info, MTP is likely to have minimal.
- Update UI for transcoding (in progress)
- Prefs UI
- Need definition of settings & meeting w/steved
- Transferring of files to devices ( should be at the level of bug fixes now )
- Prefs UI
Device Sync UI
This encapsulates the remaining work needed to wire up the events from the transcode job to the UI transitions, the new UI pieces, the auto-sync behaviors and the handling of time remaining.
Wireframes
See flow diagram here
Stories and Tasks
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19157 | P1 | 0 | task to track job time remaining bugs | * Time remaining for transcoding of video * time remaining for transfer of video * time remaining for transfer of audio * time remaining for transcoding of audio | db48x | |
| 19158 | P1 | 1 | Time remaining for transcoding of video | Time remaining for transcoding of video | db48x | 4209, 4210 |
| 19159 | P1 | 1 | Time remaining for transcoding of audio | Time remaining for transcoding of audio | db48x | 4352 |
| 19160 | P1 | 1 | Time remaining for transfering of video | Time remaining for transfering of video | db48x | 4347 |
| 19161 | P1 | 1 | Time remaining for transferring of audio | Time remaining for transferring of audio | db48x | 4346 |
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19162 | P2 | 0 | tracking task for video/audio tab changes | * addition of explanation text * canceling of editing when navigating away * Disable editing the music and video tab content when in sync mode. * Add/change radio buttons for video: Sync No Video; Sync selected playlists (default to Sync Selected & no playlists chosen) | db48x | |
| 19163 | P1 | 1 | addition of explanation text | addition of explanation text "Your sync mode is currently set to..." etc | db48x | N/A |
| 19164 | P1 | 1 | canceling of editing when navigating away | canceling of editing when navigating away | db48x | 4391 |
| 19165 | P1 | 1 | Disable editing the music and video tab content when in sync mode. | Disable editing the music and video tab content when in sync mode. | db48x | |
| 19166 | P1 | 1 | Add/change radio buttons for video tab | Add/change radio buttons for video: Sync No Video; Sync selected playlists (default to Sync Selected & no playlists chosen) | db48x | N/A |
General Device Sync changes (backend for UI)
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19170 | P2 | 0 | We need to update the general device sync flow to meet current specifications. | This is the main story for some general tasks to be done for the device sync updates. 1. Start sync when user clicks "Erase & Sync" in the dialog. 2. Only show tabs the device supports. 3. TBD playlist sync behaviour. | steven | |
| 19169 | P1 | 1 | Ensure a sync is started when the user clicks "Erase & Sync" in the dialog. | When the user switches from Manual mode to Auto Sync mode and the device has previous content on it we display a dialog to the user that asks them if they wish to Erase & Sync the device or Cancel. If the user selects Erase & Sync we need to start a Sync process. | steven | |
| 19176 | P1 | 1 | Only show the tabs the device supports. | This task will require a new widget to be created that will hold the tabs required for the device. <deviceSummaryTabs> <tabbox> <tabs> <tab sbid="device_music_tab"/> <tab sbid="device_video_tab"/> <tab sbid="device_tools_tab"/> <tab sbid="device_settings_tab"/> </tabs> <tabpanels> <tabpanel sbid="device_music_tabpanel"> <sb-device-sync contentType="audio"/> </tabpanel> <tabpanel sbid="device_video_tabpanel"> <sb-device-sync contentType="video"/> </tabpanel> <tabpanel sbid="device_tools_tabpanel"> <sb-device-tools/> </tabpanel> <tabpanel sbid="device_settings_tabpanel"> <sb-device-settings/> </tabpanel> </tabpanels> </tabbox> </deviceSummaryTabs> | steven | 4411 |
| 19222 | P1 | 2 | Ensure we properly sync what is requested by the user. | With the removal of a "Don't Sync Video" setting, we simplify the video playlist question. DesignerSteve agreed with the idea that if we are syncing all music we should sync the music playlists. So our matrix looks like: Audio lists Video lists Mixed lists All-Music Sel-Video All list should transfer Any selected lists Any selected lists Sel-Music Sel-Video Any selected lists Any selected lists Any selected lists This means that the only way to ensure no video gets to the device is to make sure none of the lists are checked in that settings tab. But it WAY simplifies the user experience (and our internal logic I think) around what lists to transfer when and what happens when a list changes type. | steven | 4551, 4548, 4547, 4550, 4549 |
Device specific changes (backend for UI)
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19172 | P2 | 0 | General story for the device specific tasks in the device sync updates. | We have some device specific tasks to get the device sync flow up to spec. 1. Create the "Video Playlist ToGo". 2. Cache any sync requests that appear when in edit mode. i. Add an attribute to set if we should disable Sync temporarily. (boolean) ii. Have an internal flag to use when the attribute is true (disable) this flag will be set to true if a sync request comes in. 3. On completion of editing (as set by the UI) check for sync flag and if set begin a sync. ii. When the attribute toggles from true(disable) to false (enable) check the internal flag to see if we should start a sync operation. Set the flag to false. | steven | |
| 19173 | P2 | 2 | Create a "Video Playlist ToGo" playlist when we detect a video capable device. | When a device is connected and we determine that it is a video capable device we need to create a playlist for the "Video Playlist ToGo" if not already created. TBD: 1. What do we name the playlist? "Video Playlist" is shown in the wireframes. 2. If the user deletes the "Video Playlist" and then connects a video capable device, do we recreate the playlist? Or do we disable the ability to delete that playlist? | steven | |
| 19174 | P1 | 2 | Add the ability to cache sync requests when required. | Create an attribute on the device component that allows use to disable the ability to process sync requests when required (during editing in the device summary page). components/devices/base/public/sbIDevice.idl ... interface sbIDevice : nsISupports { ... /** * When set to true this will cache sync requests and when set back * to false it will start a sync process if any sync requests came in * while we were caching. */ attribute boolean cacheSyncRequests; ... }; | steven | 4526, 4525, 4515, 4514 |
| 19175 | P1 | 2 | On completion of editing (as set by the UI) check for sync flag and if set begin sync. | When the cacheSyncRequests is set back to false after being true we need to check if mPendingSyncRequest is true, if it is then we need to start a sync request and set it to false. | steven | 4526, 4525, 4515, 4514 |
Progress widget changes
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19180 | P2 | 0 | Updating progress widget for the new device sync flow | New device sync flow requires some updates to the progress widget. This is a tracking bug. | palant | |
| 19071 | P1 | 2 | Sync settings need to be able to be affected externally from the Sync Tab widgets. | In order for us to be able to make changes required for the UI we need to add a notification and listener on the Sync Settings widget. This will allow other widgets to inform the sync settings widget to apply/cancel changes, and allow the sync settings widget to inform other widgets that changes have been made. Possible changes for the UI: - Add Apply/Cancel button in a separate area from the sync setting tabs. - Remove sync button and context menu. Changes required: - Add an event listener to the deviceProgress widget (assuming this is where we are putting the Apply/Cancel buttons) that will listen for "sbDeviceSync-settings" with event.detail = "change" | "save" | "cancel" - Add an event dispatch in the deviceSync widget that will send the "sbDeviceSync-settings" with event.detail = "change" when settings have changed (but not saved). - Add an event listener to the deviceSync widget that will listen for "sbDeviceSync-settings" with event.detail = "save" | "cancel". deviceProgress actions on "sbDeviceSync-settings": "change" - show the Apply/Cancel buttons (hide others) "save" | "cancel" - hide the Apply/Cancel buttons (go back to original display) NOTE: Do we do this if we are currently syncing? deviceSync actions on "sbDeviceSync-settings": "save" - Apply any changes to the settings "cancel" - Revert any changes to the settings | palant | N/A |
| 19072 | P1 | 1 | Replace sync button with apply/cancel buttons. | Possible button changes for the device summary pages: 1. Remove Sync button and Sync context menu. 2. Add Apply and Cancel buttons to progress widget. Text and placement to be determined by SteveN. | palant | N/A |
| 19181 | P1 | 1 | Implement sync mode selector with toggle buttons | User should switch between Manual and Auto mode for device sync using two toggle buttons instead of the checkbox that we have right now. | palant | N/A |
| 19182 | P1 | 2 | Show Cancel/Apply buttons when the user is editing device sync settings | The Sync button should be replaced by Cancel/Apply buttons when the user is editing device sync setting. Cancel should revert the settings to their previous values. Apply should save the new settings and start sync if necessary. | palant | |
| 19185 | P1 | 1 | Hide progress bar if the device is in idle state | The progress bar seems to stay visible even after the operation is complete right now. We should hide it an allow the user to configure sync. | palant |
Info bar widget changes
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19183 | P2 | 0 | Updating info bar widget for the new device sync flow | New device sync flow requires some updates to the info bar widget. This is a tracking bug. | palant | |
| 19184 | P1 | 1 | Remove "Finishing" panel from the info bar | New device sync flow no longer has a "Finishing" step in the info bar. | palant | N/A |
Notes
- Assets (e.g. graphics)
- Risks (e.g. unknown APis, dependencies, black holes)
Device Capability Lookup
Wireframes
Stories and Tasks
| ID | Priority | Cost | Title | Description | Engineer | Testcase |
|---|---|---|---|---|---|---|
| 19044 | P2 | 0 | Lookup acme device capability over HTTP | The acme extension currently hardcodes the capabilities of devices in C, compiled code. Using the existing framework (sbIDeviceCapabilitiesRegistrar) should be used to process an HTTP lookup to the acme device specification XML document and find the desired device caps from that page. | devices | |
| 19046 | P1 | 1 | Change the acme capabilities registrar to also handle MTP devices | Currently, the acme addon device caps registrar only provides options for MSC devices. Since the device caps will now be provided over a remote XML file, the caps registrar should also provide support for acme MTP devices as well. This is an easy 1 ptr. | alfred | N/A |
| 19047 | P1 | 1 | Stash the remote DIT table location in prefs | To prevent hard coding the DIT table location in C code, we should store the location of the remote DIT file in the prefs of the acme extension. | nick | |
| 19048 | P1 | 1 | Replace logic in ACME caps registrar's AddCapabilities() to use the DIT parser | Once the XML parsing logic has been written for the remote acme DIT, the caps registrar code should be updated to use the information that was found on the caps file. The existing hard coded logic should be kept as a fallback just in case the remote DIT file could not be processed. | nick | N/A |
| 19049 | P1 | 3 | Implement ACME DIT XML parser class | In order to parse the remote (or possibly local) ACM DIT XML file, a parser class should be written. It would make sense to design the class to take a |sbIDeviceCapabilities| instance and assign the found properties directly on the interface. This class should be designed so that it could be used to point at both remote and local files (if needed). Since this task involves writing the XML parsing logic it is an all week 3ptr. | nick | |
| 19050 | P1 | 2 | Create a unit test for the acme DIT parser | While building out the DIT XML parser, we should go ahead and write a unit test for the acme extension to validate the XML parser and the remote data. Costing as a 2 (light) since we'll most likely need to create some private interfaces to wrap the c-xml parser for a JS unit test. | nick | N/A |
| 19225 | P2 | 1 | Create a video device capabilities interface | The base device API already has a caps interface for audio and image formats and we need to create one for video. This should be a straight forward 1 (IDL class and C++ class) | nick | |
| 19233 | P1 | 2 | Hook up video capabilites stuff to the XML DIT parser | One piece of fallout from bug 19049 was that we weren't sure which video capabilites interface to use (i.e. use an existing, create new ones). We've decided that the existing |sbIVideoFormatType| interface will do the trick. This bug is to convert the parsed DIT XML data from an intermediate form to creating the |sbIVideoFormatType| and storing those values on the device capabilities instance that the parser already gets. This will also involve some unit test hook up as well. This is an all-day 1ptr to complete. | nick | 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
<meta charset="utf-8"/>
Dependencies on these tasks agains the video transcoding API's which haven't been completed yet.Data Flow Charts
Video Transcoding Device Implementation
Wireframes
Stories and Tasks
ID Priority Cost Title Description Engineer Testcase 19122 P1 0 Support video transcoding for MTP and MSC devices Support for video transcoding for MTP and MSC devices. dbradley N/A 19111 P1 1 Implement transcoding logic Implement the logic needed to check for transcoding and then perform the transcoding using the new transcoding API's. dbradley 4094, 4093, 4092, 4090, 4088, 4087, 4086, 4084, 4083, 4082, 4081, 4078, 4077, 4076, 4074, 4073, 4071, 4070, 4068, 4067, 4065, 4058, 4057, 4056, 4055, 4053, 4052, 4051, 4050 19112 P1 1 Hook up the transcoding status updates to the device status Implement the logic to wire up the transcoding status listeners and translate those statuses to device statuses. dbradley N/A 19118 P2 0 Creating transcoding status listener implementation We need to create a transcoding status listener that will serve as an adapter between the transcoding status system and the device status system. This will be used by MTP and MSC. devices N/A 19120 P1 1 Implement transcoding logic Implement the logic necessary to perform the transcoding. This includes things like determining the locations and other setup work and invoking the transcoder dbradley 4144, 4143, 4142, 4140, 4138, 4135, 4134, 4133, 4132, 4131, 4130, 4129, 4127, 4124, 4122, 4121, 4120, 4113, 4112, 4110, 4109, 4108, 4106, 4105, 4104, 4102, 4101, 4100, 4096 Notes
Additional Considerations
- Tag page
- What links here
| File | Size | Date | Attached by | |||
|---|---|---|---|---|---|---|
 | capabilites lookup flow.png No description | 49.04 kB | 10:25, 3 Dec 2009 | nick | Actions | |
| dit lookup flow.png No description | 37.5 kB | 10:25, 3 Dec 2009 | nick | Actions | |
You must login to post a comment.
