diff options
61 files changed, 2922 insertions, 0 deletions
diff --git a/AacPreset.mdwn b/AacPreset.mdwn new file mode 100644 index 0000000..19940de --- /dev/null +++ b/AacPreset.mdwn @@ -0,0 +1,33 @@ + +Describe AacPreset here +[[!format txt """ +[_presets_] +version=0.10 +element-name=GstFAAC + +[Profile Low Complexity] +_meta/comment=Low Complexity Profile +profile=LC + +[Profile Main] +_meta/comment=Main Profile +profile=MAIN + +[Profile Sample Rate Scalable] +_meta/comment=Sample Rate Scalable Profile +profile=SSR + +[Profile Long Term Prediction] +_meta/comment=Long Term Prediction Profile +profile=LTP + +[Quality Low] +_meta/comment=Low quality +bitrate=96000 + +[Quality Normal] +bitrate=128000 + +[Quality High] +bitrate=200000 +"""]]
\ No newline at end of file diff --git a/BufferMetadata.mdwn b/BufferMetadata.mdwn new file mode 100644 index 0000000..9c2c9c4 --- /dev/null +++ b/BufferMetadata.mdwn @@ -0,0 +1,33 @@ + +We need a mechanism to transport extra data in a GstBuffer. Unlike caps the content is likely to change for each buffer. + +Examples: + +* Pan and scan (video subregion) position information +* interlacing markers (top field, bottom field) +* theora granulepos, instead of slapping it in the 'offset' field +* MPEG Decoding timestamps, which we currently never send along. +* Feature-Extraction elements can add feature data +* Some image capture sensors can provide histograms with the frames + * Some formats (mpeg-ts from HDV cameras) provide date/gain/shutter-speed/scene-change at a regular interval but not for every frame (around 10 times per second). +* packet priority and timeout could be used by network plugins (such as DCCP) to send more important packets when congestion is detected. +Ideas: + +1. GstStructure in GstBuffer +1. GstTaglist in GstBuffer +1. syncronized downstream events +1. Store GstStructures in GstIndex +GstStructure is also use in GstTaglist. The structure can be hierarchical. We could require that the producer uses its element name as a root tag. This way the taglist could carry multiple data-sets identified in a unique way. Elements that can use the data need to know the name of the element that created it. + +Issues: + +* Performance + * copying, freeing buffers need to check/handle the presence of extra metadata +* Transformations + * there might be transformation that render the data useless. e.g. if the data is a histogram, color changes invalidate it. if its a sub-region, size changes invalidate it. +* Mixing + * if we go for (B) we could use the tag merge modes +* Muxing + * using and/or dropping the data, it does not sound sensible to send it further +* Copies (tee) + * make duplicates
\ No newline at end of file diff --git a/Buzztard.mdwn b/Buzztard.mdwn new file mode 100644 index 0000000..7c195f6 --- /dev/null +++ b/Buzztard.mdwn @@ -0,0 +1,33 @@ + +Buzztard is a music composer. + + +## Project ideas + +* Port from [[InterpolationController|InterpolationController]] to own controller class (see [[buzztard wiki|http://wiki.buzztard.org/index.php/Gst-controller_queues]]) +* Use [[EncodeBin|EncodeBin]] for Song Rendering (see [[buzztard wiki|http://wiki.buzztard.org/index.php/Song_rendering#gstreamer_encodebin]]) +* Audio recording for [[wave-table|http://buzztard.git.sourceforge.net/git/gitweb.cgi?p=buzztard/buzztard;a=blob;f=src/lib/core/wave.c;hb=HEAD#l29]] +* Improve bt-dec, the buzztard song decoder that can be used in playbin2 +* Write a audio-synthesizer baseclass to ease porting the plugins in gst-buzztard to 0.11 (will be used for simsyn, fluidsynth and the sources in bml) +* [[Port to 0.11|http://wiki.buzztard.org/index.php/GStreamer1.0]] + +## Resources + +* [[http://www.buzztard.org/|http://www.buzztard.org/]] + +## Skills needed + +* C +* Gtk +* the more GStreamer experience the better +Students interested in doing a Google Summer of code project around buzztard should join the #buzztard channel on irc.freenode.net. You should be able to find someone online at almost any time to discuss your project idea there. + +**Mentor: Stefan Sauer (buzztard author) aka ensonic on IRC ** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2012|CategoryGSOC2012]] [[CategoryTasks|CategoryTasks]] diff --git a/CameraBin.mdwn b/CameraBin.mdwn new file mode 100644 index 0000000..e6d3011 --- /dev/null +++ b/CameraBin.mdwn @@ -0,0 +1,175 @@ + +[[!toc 3]] + + +# CameraBin 2 + +Current camerabin is a single element and has some complex code with input/output-selectors for controlling the flow of buffers. Making it more modularized and with less -selectors would simplify the code a lot. We hope caps negotiation will be simplified, too. And more tricky features could be implemented inside still/video capturing modules(bins). We could also switch a whole sub-bins to ones with a different implementations. The multi-pad source design enables optimizations for hardware that can stream simultaneously on all pads. + +Even though the new camerabin will provide the same basic functions as the current one (and have quite similar API), it will be built from ground up again with a different design. We should make it camerabin2 and take it in parallel with camerabin. This way we avoid major regressions and api changes hassle to applications using current camerabin. When they feel ready, the switch to camerabin2 wouldn't be hard. Also, we can keep bugfixing on old camerabin and keeping everything using it working. + + +## Modules + +[[CameraBin2|CameraBin2]] will have 4 internal modules (bins), it should be possible to use any of them outside of camerabin2 (applications, like Empathy and Cheese could make use of those): + +[[!img CameraBin2.png]. + + +### CameraSrc + +* It's a bin with 3 output pads for parallel flow (video recording, image capture and viewfinder) +* Need to do some baseclass, and there should be an adapter element that would use current video source elements with a single srcpad internally (v4l2src, videotestsrc) and provide 3 output pads as [[CameraBin2|CameraBin2]] expects. +* Might implement gstreamer's Photography interface +The embedded world has complex camera drivers that offer more functionality that classic v4l2. E.g. they might have parallel outputs at the same time. The idea here is to make a more complex camerasource api. This could be implemented as a linux-camera-source (as a bin), reusing what we have in CameraBin, or be implemented on top of a different api providing these features as a monolithic block (e.g. gst-omx based camera-source). + +This should be done as a baseclass (subclassing a [[GstBin|GstBin]]), with the following features: + +* 3 static source pads: image, viewfinder, video (as [[GstGhostpads|GstGhostpads]]) +* Previewing using 2 sometimes source pads (image_preview, video_preview) or Messages +* Do we want to proxy interfaces or application uses them directly from the elements? (photography, colorbalance, ...) +This would be the potential class hierarchy: +[[!format txt """ +GstBin + GstBaseCameraSrc + GstSimpleV4l2CameraSrc + GstOmxCameraSrc + ... +"""]] +If the actual camera plugin is already implemented extending e.g. [[GstPushSrc|GstPushSrc]], then one would still subclass a new element from [[GstBaseCameraSrc|GstBaseCameraSrc]] and insert the [[GstPushSrc|GstPushSrc]] based camera element there. In the most simple case the wrapper for a powerful hardware based camera source proxies gobject properties and links the internal element pads to the bins ghostpads. We would definitely want to have a [[GstSimpleV4l2CameraSrc|GstSimpleV4l2CameraSrc]] as a reference implementation and also providing legacy/fallback support. + + +### Image Capture Bin + +Received the image buffers from the camera source, encodes them and saves to disk. Must have queues internally to allow further captures to be taken while others are encoding. + +* Handles eos/tags between buffers/image captures +* Possibility of multiple implementations: + * A sequential encoding implementation using queues + * Parallel encoding (pool of pipelines) + * Other ones for trickier cases (e.g. panorama pictures) + * If we allow multiple implementations: How to guarantee a basic common API here? Do we need to guarantee it? + * Need to do tagging to multiple encoders. e.g. We use jifmux for jpg, what are we using for png? + +### Video Recording Bin + +Responsible for recording video and audio. The video buffers are generated from the camera source, audio is recorded from a internal audio source element (that might be muted by the application). + +* There's an audio source element in this bin (be careful with the clock selection/distribution) +* Newsegment/timestamp handling on recordings was tricky/buggy in current camerabin +* Encodebin could work here + +### Viewfinder Bin + +* Contains the videosink and any image processing filters/analyzers the application might set +* How useful is it outside of camerabin? It's simply a branch of elements. (Hot-swapping of effects?) + +## Use Cases + +* Basic picture capture: User sets capture resolution to camerabin2, that forwards it to the camerasrc. User also sends the capture filename to camerabin2, which forwards it to the image capture branch. User then sends the capture signal and camerabin forwards it to the camerasrc. Camerasrc pushes a buffer through its imagesrc and it gets to the image encoding branch. The image encoding branch encodes, puts tags into the image and sends an EOS to the filesink so that it finishes the file. +* Basic video capture: User sets capture resolution and fps to camerabin2 and it forwards it to the camerasrc. User sets the capture filename, which is passed to the video recording bin. When the user sends the capture start signal, camerasrc starts pushing buffers through its videosrc pad. The audiosrc inside the videobin also starts recording the audio in sync with the video buffers. The viewfinder must still keep running during this. Recording continues until the user sends the capture stop signal. At this point, eos is pushed on the video recording bin and the file is finalized. It should be possible to pause and continue the recording. It should also be possible to mute audio recording. +* Panorama: Panorama pictures are not planned to be supported natively on camerabin2, it could, however, be implemented as a image capture module and replace the default module whenever the user would like to take panorama pics. Currently an external application has to take care of the pictures merging. From camerabin2, an application needs to be able to control camera parameters (AWB, AF and AE) so that subsequent captures use the same values. This is possible by using the 'manual' mode for these properties in the Photography interface. It is also possible to set it to 'manual' after the first capture so that the 3A values are automatically set up for the first capture and maintained as that for the other captures. +* Continuous shooting: In this mode, camerabin2 has little to do. This is handled by the camera source module, by setting it to 'continuous shooting' mode it will use faster algorithms to do 3A, thus reducing shot to shot time. The rest of camerabin2 will work as usual. +* <add your favorite use case here> + +## Other features + +* Digital zooming (with Photography interface or gstreamer elements) +* Night mode adjustment (Use lower framerates to allow more exposure time and have a 'lighter' image) +* Querying available capture formats +* Autopick framerate + * Highest if not specified + * rounding (when user selected fps isn't available) +* colorspace/scalers to guarantee compatibility between elements +* Hot-swapping of effects elements. + +## Intentionally not handled + +* Cameras that generate non-raw input +* Hot swapping of inputs/camera. This can be done by setting it to NULL and changing. + +## Open Questions + +* How to do effects hot swapping? cheese and empathy want it. +* Do we want a explicit prepare-for-capture step? To be set when the user finishes setting up its preferences? +* Use sometimes pads or messages for previewing on the source? +* How to map [[CameraBin2|CameraBin2]] flags to the internal bins flags? +* Detection of video sources? (Improve autovideosrc? This would be nice for Cheese) +* Effects performance + * Camerabin can do effects on all branches with a single element. Camerabin2 would need one effect element per branch. + * Proper benchmarking needed here. + * Providing effects on the source bin of camerabin2 if it supports it would help here. + +## Links + +* Rob Clark's camerabin branch: [[http://gitorious.org/robclark-gstreamer/gst-plugins-bad|http://gitorious.org/robclark-gstreamer/gst-plugins-bad]] + * Refactored camerabin to this new design +* Log of camerabin2 meeting on 07/12/2010 (dd/mm/yyyy): [[http://people.collabora.co.uk/~thiagoss/camerabin2_20101207.log|http://people.collabora.co.uk/~thiagoss/camerabin2_20101207.log]] + +# CameraBin + + +## TODO + +At some point we'd like to move CameraBin to gst-plugins-good. CameraBin already has unit tests and documentation. It is currently in use on Nokia N900 and is considered for cheese. This page lists things that should be done before declaring it stable. + + +## dataflow + +In current CameraBin we have a link from videobin back to viewfinder to so what we record. When we do the camera-source baseclass, we should move the input-selector to the [[GstSimpleV4l2CameraSrc|GstSimpleV4l2CameraSrc]] implementation or even get rid of the selectors and provide paralell dataflow if needed. Keeping the viewfinder active is important for the cases where one has analyzers in e.g. the viewfinder-slot to get continuous analysis results in videorecording or continuous shooting. + +Open items here: + +* in still capture mode we might want to set the queue in the still image camera source output to "leaky" and block its src pad. We would only unblock the on shutter press for the seleccted amount of images (burstmode). We could also use videorate or even a specialized videogate element here. What the element should do: + * only let n frames through (n=0...) + * drop frames to produce a certain output rate + +## focusing + +We need more focus mode. Right now the API can start AF and get a signal when AF is done. There are also camera subsystems providing continuous focusing, where we would just lock the AF on half press, adjust frame and shot. + + +## continuous shooting + +We would set the queue to leaky and block the capture pad. In contrast to single capture mode, we would keep capture-setting frozen and let a frame through, each time the capture button is pressed. + + +## bracketing + +Lock settings, take various shots with some settings changed, merge single images with some filter. We can use the GstController for scheduling the parameter changes. Some issues with that though: + +* the camerabin pipeline is always running - we need a newsegment on the image capture pipeline, so that timestamps start with zero +* the camerasrc is a live-src, thus it is hard to align the control-changes with frame times ( see [[bug 610338|https://bugzilla.gnome.org/show_bug.cgi?id=610338]] and [[bug 616173|https://bugzilla.gnome.org/show_bug.cgi?id=616173]]). +* v4l2 has no api yet to do timestamped CID changes + +## recording timestamps + +Try pushing a newsegment to videobin, instead of rebasing timestamps with a buffer-probe. + + +## Open Items + + +### effect preview + +When adding effects to imagebin or videobin, we might want to get a preview on viewfinder for those too. We either need to apply certain effect in the source already or add them twice. + + +### isp internal effects and effect selection + +Right now camerabin offers slots for setting effects on each of the imagebin, viewfinderbin and videobin. Some ISPs (image signal processor) come with internal effects (e.g. videostabilisation). Effect settings should then be exposed as gobject properties on the camera source, so that a camera ui can set a gstreamer plugin as an effect and link the ui to the gobject properties or activate the isp internal effect and connect the ui to the properties of that. + +The effect parameters should not be added to [[GstPhotography|GstPhotography]] to avoid it growing unbounded. [[GstPhotography|GstPhotography]] is for capture settings. This is needed for post processing effects. + + +### highspeed capture + +We might need a videorate element infront of the viewfinder bin to reduce the framerate there. + + + +--- + + + +TODO: add more from [[http://live.gnome.org/Cheese/ThreeZero?action=AttachFile&do=get&target=cheese-threezero-meeting-log.txt|http://live.gnome.org/Cheese/ThreeZero?action=AttachFile&do=get&target=cheese-threezero-meeting-log.txt]] diff --git a/CameraBin/CameraBin.png b/CameraBin/CameraBin.png Binary files differnew file mode 100644 index 0000000..fb0ba51 --- /dev/null +++ b/CameraBin/CameraBin.png diff --git a/CameraBin/CameraBin2.png b/CameraBin/CameraBin2.png Binary files differnew file mode 100644 index 0000000..935fbb2 --- /dev/null +++ b/CameraBin/CameraBin2.png diff --git a/CameraBin/CameraBin_20100428 b/CameraBin/CameraBin_20100428 Binary files differnew file mode 100644 index 0000000..73ea1be --- /dev/null +++ b/CameraBin/CameraBin_20100428 diff --git a/CameraBin/CameraBin_20100428.png b/CameraBin/CameraBin_20100428.png Binary files differnew file mode 100644 index 0000000..73ea1be --- /dev/null +++ b/CameraBin/CameraBin_20100428.png diff --git a/ChapterSupport.mdwn b/ChapterSupport.mdwn new file mode 100644 index 0000000..c64e5b9 --- /dev/null +++ b/ChapterSupport.mdwn @@ -0,0 +1,28 @@ + + +# Implement chapter support in more plugins + + +## Background + +[[Bug 540890|https://bugzilla.gnome.org/show_bug.cgi?id=540890]] provides a new API to GStreamer for chapter support in media files. [[Bug 481070|https://bugzilla.gnome.org/show_bug.cgi?id=481070]] implements that API for the matroska format. We need simillar patches for other plugins and make use of that in tools: + + +### Tools + +* gst-discoverer should show the chapter structure +* gst-launch should have a option simillar to "-t" for tags to show chapters + +## Resources + +* Riff-format: [[http://www.neurophys.wisc.edu/auditory/riff-format.txt|http://www.neurophys.wisc.edu/auditory/riff-format.txt]], see "Cue-Points Chunk" +* Mp4-Format: [[http://xhelmboyx.tripod.com/formats/mp4-layout.txt|http://xhelmboyx.tripod.com/formats/mp4-layout.txt]], see "chapterlist"; also this may be useful: [[http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/index.html|http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/index.html]], see "Chapter List" +**Mentor: ** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2012|CategoryGSOC2012]] [[CategoryTasks|CategoryTasks]] diff --git a/ChristianSchaller.mdwn b/ChristianSchaller.mdwn new file mode 100644 index 0000000..02ab912 --- /dev/null +++ b/ChristianSchaller.mdwn @@ -0,0 +1,11 @@ + + +## Christian F.K. Schaller + +Email: christian.schaller AT SPAMFREE gmail DOT com + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/Closed_Captioning_support.mdwn b/Closed_Captioning_support.mdwn new file mode 100644 index 0000000..6b6467f --- /dev/null +++ b/Closed_Captioning_support.mdwn @@ -0,0 +1,22 @@ + + +# Close Captioning Support + + +## Background + + +## Resources + +* [[http://en.wikipedia.org/wiki/Closed_Captioning|http://en.wikipedia.org/wiki/Closed_Captioning]] +* [[http://thread.gmane.org/gmane.comp.video.gstreamer.devel/19727|http://thread.gmane.org/gmane.comp.video.gstreamer.devel/19727]] +* [[http://article.gmane.org/gmane.comp.video.gstreamer.devel/24276|http://article.gmane.org/gmane.comp.video.gstreamer.devel/24276]] +**Mentor: Need Mentor - Add yourself** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2008|CategoryGSOC2008]] [[CategoryTasks|CategoryTasks]] diff --git a/ColorSpaceBin.mdwn b/ColorSpaceBin.mdwn new file mode 100644 index 0000000..552e130 --- /dev/null +++ b/ColorSpaceBin.mdwn @@ -0,0 +1,28 @@ + + +# ColorSpaceBin + +A bin that can dynamically select the correct elements for colorspace conversion (CC). + + +## Problem + +Now there is only one major well known CC element -> ffmpegcolorspace. However there are some problems with this element ( or with the fact that there is only one element): + +* ffmpegcolorspace is out of sync with upstream ffmpeg...some volunteers that want to sync it? +* many pipelines/programs depend on the ffmpegcolorspace for basic functionality, so if your CC is not in this element your CC will not work with this pipeline/program. +* If you want to create a CC element, for example with hardware acceleration, and you want that it works without changing programs/pipelines you need to hack on ffmpegcolorspace. +* with previous restriction your element needs to be LGPL. + +## Solution + +A bin element that chooses the correct CC element's out of the available elements. All application/pipeline developers can depend on this element for the CC job, like they now depend on playbin/decodebin for playing/decoding media. Maybe playbin and/or decodebin can use this element too. In that sense an application can use the ffmpegcolorspace element without hard linking it and take away some design restrictions and allow new CC just by adding/removing elements. + + +### Features + +* Application or pipeline developers don't need to choose there preferred CC element anymore. +* Allow new CC just by adding/removing elements. +* Chain multiple CC elements to handle the CC if there is no element that can do it in one time. +* All elements of the klass "Filter/Converter/Video/Colorspace" will be marked as CC elements. +* Priorities higher ranked CC elements.
\ No newline at end of file diff --git a/DebugHelperMenu.mdwn b/DebugHelperMenu.mdwn new file mode 100644 index 0000000..209ce87 --- /dev/null +++ b/DebugHelperMenu.mdwn @@ -0,0 +1,28 @@ + +The idea is to provide a reusable menu widget that applications can plug into their menu bar in debug builds. + + +## Actions + +The widget would have pre-defines actions. + +* dump pipeline graph +* dump pipeline graph and show +* dump details + * caps + * ... +* --- +* category log levels + * gstreamer + * GST_XXX + * WARNING, INFO, DEBUG, LOG + * application + * <name> + * WARNING, INFO, DEBUG, LOG + +## API + +The menu widget has some extra properties: + + * [[GstPipeline|GstPipeline]] *pipleine + * gchar *debug-categories (as ',' separated list of names)
\ No newline at end of file diff --git a/DesignDiscussions.mdwn b/DesignDiscussions.mdwn new file mode 100644 index 0000000..eb3ff1d --- /dev/null +++ b/DesignDiscussions.mdwn @@ -0,0 +1,27 @@ + + +# Design Discussions +[[!table header="no" class="mointable" data=""" +Note: none of the core developers do design discussions on the wiki. Bugzilla and IRC are better places to discuss design. These wiki pages are more of a scratchpad. +"""]] + +Space for drafting new features. + +* Core: + * -<del>[[BufferMetadata|BufferMetadata]]: variable extra data keept with buffers</del>- (obsolete) + * -<del>[[NewCapsFields|NewCapsFields]]: discuss new caps fields</del>- (obsolete) + * -<del>[[NewGstVideo|NewGstVideo]]: discuss replacement for gst-libs/gst/video API for caps parsing/building of raw yuv/rgb types</del>- (obsolete) +* Base classes: + * -<del>[[GstBaseParse|GstBaseParse]]: parser base class</del>- (obsolete) +* Bins: + * [[CameraBin|CameraBin]] : still and video camera capture + * [[ColorSpaceBin|ColorSpaceBin]]: a bin for colorspace conversion + * [[SampleBin|SampleBin]]: bin for game and event sounds +* (Gtk) widget library in gst-plugins-base: + * [[VideoWidget|VideoWidget]]: General Gtk video widget + * [[EncodingProfilesUi|EncodingProfilesUi]]: Encoding profiles UI for editing, selecting, etc of encoding profiles + * [[DebugHelperMenu|DebugHelperMenu]]: Menu to add to menu bar in debug version +* Presets (Profiles) + * [[PresetDesign|PresetDesign]]: Combining GStreamer element presets with devices + * [[DeviceProfile|DeviceProfile]]: device encoding profiles for GStreamer +* [[ZeroPointEleven|ZeroPointEleven]]: GStreamer 0.11 / 1.0 discussions
\ No newline at end of file diff --git a/DeviceProfile.mdwn b/DeviceProfile.mdwn new file mode 100644 index 0000000..88f0da5 --- /dev/null +++ b/DeviceProfile.mdwn @@ -0,0 +1,60 @@ + + +# Device Profiles + +To origin for these higher level device profiles is the XML format defined in the [[Arista|http://programmer-art.org/projects/arista-transcoder]] transcoder, they have been changed quite extensively though as the underlaying featureset in GStreamer has evolved. There are a few changes in the XML example below though from what Arista does today. First of all we replace all element names with GStreamer Caps and secondly we replace all element attribute settings with preset calls. Finally we expand the XML format to include all allowed choices for a given device, so that the application can offer the user other valid choices if they want to. Many GStreamer Caps are listed in the [[GstreamerCaps|GstreamerCaps]] list. + +To try to keep the discussion clear we always refer to these files as 'profiles' and the element specific GStreamer files as 'presets'. These files are meant to provide all information needed to create a usable caps profile for encodebin. +[[!format txt """ +<?xml version="1.0"?> + +<device> + <make>Apple</make> + <model>iPod</model> + <description>Profile for Apple iPod / iPhone</description> + <author> + <name>Joe Example</name> + <email>mr.example@example.org</email> + </author> + <version>1.0</version> + <icon>file://ipod.svg</icon> + <default>Normal</default> + + <profiles> + <profile> + <name>Normal</name> # You can have multiple profiles, Low, Normal and High, in this example we only include Normal + <container>video/quicktime,variant=apple</container> + <extension>m4v</extension> + <audio> + <caps>audio/mpeg,mpegversion=4, channels=2, rate=44100, base-profile=lc </caps> + </audio> + <video> + <caps>video/x-h264, profile=main</caps> + <border>N</border> + <passes>2</passes> # Number of passes in multipass encoding + <width>320, 640</width> # range supported by device, as we want to avoid upscaling when possible + <height>240, 480</height> # range supported by device, as we want to avoid upscaling when possible + <framerate>1, 30</framerate> # range supported by device, as we want to avoid increasing rate when possible + </video> + </profile> + </profiles> +</device> +"""]] +The general idea here is to enable the creation of a caps string that will enable encodebin to create the video we need. For fixed values they can just go into the caps, for others they need to be specified as a range and the program logic needs to handle it. + +Using this simple format the profiles for PSP, Nokia devices, the computer, etc are almost identical to the above and require no further modifications to the element presets. + +One question which needs further thought it how to deal with variations within a device type, maybe 'iPod' is too generic for instance. We could also add another gstreamer preset for variation values if needed. + +Also - what about handling multiple passes - the above can handle it by defining more <pass> + +We also need to come up with a nice, but hopefully not to verbose way of including information about all supported codecs and containers formats in addition to our recommended one. + + +## Comments + +This proposal is being discussed on the [[GNOME Multimedia mailing list|http://mail.gnome.org/mailman/listinfo/gnome-multimedia]] + +To reach the archive [[go here|http://mail.gnome.org/archives/gnome-multimedia/2009-May/date.html]] + +Comments on the proposal should be sent there. The comments below will be moved to the mailing list and removed from the wiki. So do not add more comments here. diff --git a/DvdPlayback.mdwn b/DvdPlayback.mdwn new file mode 100644 index 0000000..6abecdc --- /dev/null +++ b/DvdPlayback.mdwn @@ -0,0 +1,80 @@ + + +# DVD Playback + +Information about ongoing work on the ResinDVD components to support full featured DVD playback. The ResinDVD components are currently in gst-plugins-bad, and as of 13 August 2008 require CVS of gst-plugins-base to have working menu support via playbin in Totem, etc. + +[[!toc 3]] +## Overview + +ResinDVD consists of a single registered element: rsndvdbin. This element produces 3 pads: decoded video, decoded audio and a DVD subpicture. + +Internally, the bin contains some private elements that implement: + +* Source element - _rsndvdsrc_. libdvdnav based source element that handles the Virtual Machine operations and data reading. +* Demuxer - _rsndvddemux_. Communicates with the source. Unpacks buffers and outputs a bunch of pads with the the video stream and all the audio + subpicture streams. +* Stream selectors - _rsnstreamselector_. A modified copy of the stream selector from playbin. There are 2 - one for audio, and one for subpictures. The output from each is the currently selected encoded audio stream or subpicture stream. +* Audio stream 'munger' - _rsnaudiomunge_. Massages the decoded audio stream to fill in gaps by producing silence, or to clip discontinuous audio when switching streams and produce a smooth continuous output stream. +* Video stream 'munger' - _rsnparsetter_. Overrides caps on the video stream where necessary, as DVD's sometimes produce 4:3 video streams that should be stretched to 16:9. Eventually will also implement pan & scan operations/scaling for 4:3 display of 16:9 source materials. +In addition, rsndvdbin uses multiqueue to buffer the video and audio streams (not the subpictures, because the dvdspu element handles that) and decodebin2 to actually decode the video and audio. + + +## TODO + +A list of known items that still require implementing, and some status. + + +### Stream Selection + +**Description** + +Implement switching of audio and subpicture streams. + +Also, this means extending playbin to support ResinDVD stream switching. _rsndvdbin_ only exposes a single audio and subpicture pad, and will handle the stream switching internally. Playbin currently expects that multiple streams are exposed via multiple output pads from the source and that it will be in charge of the switching. In the Resin case, we need playbin to act as a proxy to _rsndvdbin_ and allow _rsndvdbin_ to implement the stream switching. I think the way to do this is: + +* Add a current-subpicture property to playbin +* Add current-audio and current-subpicture properties on rsndvdbin and _rsndvdsrc_. +* Make playbin proxy audio/subpicture stream changes to the source element if it provides current-audio and current-subpicture properties. +* Make the current-audio and current-video subpicture properties on _rsndvdbin_ proxy through to _rsndvdsrc_ +* Make _rsndvdsrc_ implement changes of the audio/subpicture stream by informing libdvdnav about it and sending an event downstream so that the stream selectors change input pads. +Furthermore, we need the playbin streaminfo property to reflect the available streams inside the _rsndvdbin_, probably by providing a stream-info property on _rsndvdbin_ and having playbin include streams in there in the set it outputs to players. + +** Status ** Currently, it's supported to send an internal event from _rsndvdsrc_ and handle it in _rsnstreamselector_ so that the subpicture and audio tracks can change when commanded to by DVD menu operations. This needs more work, to expose the stream info to players, so it can be changed from their menus. + + +### Switching Audio Decoder Bin + +**Description** Implement a bin which has a single input pad. When the incoming stream type changes (A52 to DTS to LPCM for e.g.), it needs to direct the stream to an appropriate audio decoder instance and then feed the output from the correct audio decoder. At the moment, all that's implemented is plugging a single decodebin2 in place of where this new _rsnaudiodec_ element should be. Using a single decodebin2 instance means that the audio stream type can't change, so we are restricted to only playing A/52 streams. + +**Status** DONE + + +### Audio Munger + +**Description** Extend _rsnaudiomunge_ to support: + +* Rendering silence buffers into gaps in more formats, to avoid unnecessary caps changes in the output. +* Mark rendered silence buffers with the 'GAP' flag for a slight efficiency improvement +* When streams switch, there might be overlapping audio timestamps that should be clipped away to produce a smooth output stream. +**Status** In progress + + +### Seeking + +**Description** _rsndvdsrc_ needs to support more seek formats: TIME, Title, Chapter. Especially TIME based seeking, as that is what most players need in order to implement the seek bar. + +**Status** Time based seeking partially implemented - works for PGC's with a time-seek table, which is usually only the main movie. Chapter/Title seeking DONE + + +### Alternate display modes + +**Description** Implement 4:3 display modes eventually: Pan & Scan, Letterbox. Pan & Scan in particular needs cooperation from the mpeg video decoder, as they currently don't output the required information. Letterbox support involves downscaling the video vertically and inserting black. The only reason to do this is that some DVDs provide subtitles that display in the 'black letterbox' area instead of over the video. It's pretty low priority - on computers, it's usual to always display only in widescreen mode, and do letterboxing by not filling the whole screen. + +**Status** Not started. + + +### Other + +* Make DURATION reporting in _rsndvdsrc_ synchronised with the display, to avoid wackiness. At the moment, it's quite common to report (for example) that the 'current' duration is 10 seconds when playing a 30 second intro sequence, because the virtual machine has already entered the 'next' program and _rsndvdsrc_ is reporting the duration from that. The correct fix for this is probably to have _rsndvdsrc_ wait on the clock before ending a program, but it'll be tricky to get that right in the face of state changes (can't wait on the clock in PAUSED) and to avoid stuttering when the pipeline drains out. It might be easier to just implement the next point: + +There are probably still other things that need implementing, and bugs to fix. Fill in the to TODO list as you find them. diff --git a/FAQ.mdwn b/FAQ.mdwn new file mode 100644 index 0000000..b53c619 --- /dev/null +++ b/FAQ.mdwn @@ -0,0 +1,104 @@ + +Also see: + +* **[[GStreamer documentation overview|http://gstreamer.freedesktop.org/documentation/]]** +* **[[Non-wiki GStreamer FAQ|http://gstreamer.freedesktop.org/data/doc/gstreamer/head/faq/html/index.html]]** +[[!toc 2]] + + +# General + + +## I wrote a new plugin/element and I would like it to be included in GStreamer, how to proceed? + +See [[SubmittingPatches|SubmittingPatches]]. + + +## It is hard to give unique names to elements I create, is there no better way to do this? + +You can just pass `NULL` as the element name to `gst_element_factory_make`. GStreamer will assign a unique name automatically in this case. + + +## My handler for the message signal of GstBus is never called, how to get it to work? + +You need to call `gst_bus_add_signal_watch` to enable emission of the `message` signal. Also make sure that you have a main loop running (`g_main_loop_run` or e.g. `gtk_main`). + + +## How to read the meta data (tags) of a file? + +Use a `playbin` element with fakesinks, connect handlers for ERROR and TAG messages and set state to PAUSED. **FIXME** give full code example + + +## My pipeline with multiple sinks never reaches the PAUSED state, what am I doing wrong? + +You need to add queue elements after the demuxer (or tee element) that you use. + +The problem is that the pipeline will deadlock without queues: When the demuxer/tee element is sending data to the first sink, the flow will block there while going from READY to PAUSED (this is called "prerolling"). Since the flow is blocked inside the first sink, the second sink will never receive any data which means that it can never reach the PAUSED state. A queue element decouples the flow by sending on data in another thread. + +**FIXME** give example pipelines + + +## When capturing from a video and/or audio source, how to make recording stop correctly? + +Since (live) video and audio sources provide an endless stream of data until you stop them, some special steps are needed. These are outlined in the documentation of [[GstBaseSrc|http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/GstBaseSrc.html]] under the section "Controlled shutdown of live sources in applications". + + +## How to read raw audio or video content from a file? + +The `audioparse` and `videoparse` elements can be used for this. **FIXME** Give examples/link to element docs. **FIXME** Since they are in -bad, maybe explain the old method of capsfilter + filesrc-blocksize. + + +## How to turn a list of image files into a video file? + +This can be done with the `multifilesrc` element. **FIXME** Give example/link to element docs. + + +## I installed new LADSPA modules/libvisual plugins but the corresponding GStreamer elements do not show up, what's going on? + +First make sure that the needed plugin is installed (ladspa from gst-plugins-bad, libvisual from gst-plugins-base). You can verify that by checking the output of `gst-inspect-0.10 ladspa` (`gst-inspect-0.10 libvisual`). + +If the GStreamer plugin is installed properly, you have to force a registry update: + + +[[!format txt """ +rm -fv ~/.gstreamer-0.10/registry* +"""]] +Unfortunately this step is needed everytime the set of LADSPA modules/libvisual plugins changes. [[Bug #350477|http://bugzilla.gnome.org/show_bug.cgi?id=350477]] is keeping track of this issue. + + +# gst-python + + +## My pygst program is mysteriously core dumping, how to fix this? + +Make sure that you initialize glib threading by using `gobject.threads_init()` very early in your program. The full import stanza that every pygst program should have looks like this: + + +[[!format txt """ +import pygtk +pygtk.require ("2.0") +import gobject +gobject.threads_init () +import pygst +pygst.require ("0.10") +import gst +"""]] + +## How to get a list of all elements available in the registry? + +Use the `get_feature_list` method of the default registry: + + +[[!format txt """ +>>> import pygst; pygst.require ("0.10") +>>> import gst +>>> registry = gst.registry_get_default () +>>> registry.get_feature_list (gst.ElementFactory) +[<gst.ElementFactory bin @ 0x87fb874>, <gst.ElementFactory pipeline @ 0x87fbc84>, <gst.ElementFactory dvdsrc @ 0x87fbc5c>, +... +"""]] + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/GStreamerConference2010.mdwn b/GStreamerConference2010.mdwn new file mode 100644 index 0000000..bd66a01 --- /dev/null +++ b/GStreamerConference2010.mdwn @@ -0,0 +1,50 @@ + + +# GStreamer Conference 2010 + +The first GStreamer conference took place in Cambridge (UK) on October 26th 2010, in conjunction with the CE Linux Conference Europe. + + +## Videos + +**Updated 22 March 2011: all videos are available now.** + +The videos (incl. slides) of all the talks are up now: + +Videos of the talks that took place in the main room can be found on the [[UbiCast GStreamer Conference Video Portal|http://gstconf.ubicast.tv/categories/conferences/]]. + +Videos of the talks that took place in the smaller room upstairs can be found on the [[Free Electrons GStreamer Conference Video Site|http://free-electrons.com/blog/gst-2010-videos/]]. + +Videos of the GStreamer-related talks that took place as part of the ELC-E programme can be found on the [[Free Electrons ELC-E Conference Video Site|http://free-electrons.com/blog/elce-2010-videos/]]. + + +## Slides + +* [[Wim Taymans: Keynote - GStreamer - Past, Present, Future|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Wim%20Taymans%20-%20Keynote%20-%20GStreamer%20-%20Past%20Present%20Future.pdf]] +* [[David Schleef: Orc|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/David%20Schleef%20-%20Optimizing%20Multimedia%20with%20Orc.pdf]] +* [[Sebastian Dröge: GStreamer and WebM|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Sebastian%20Droege%20-%20GStreamer%20and%20WebM.pdf]] +* [[Zaheer Abbas Merali: Flumotion - Open Source Streaming|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Zaheer%20Abbas%20Merali%20-%20Flumotion%20-%20Open%20Source%20Streaming.pdf]] +* [[Rob Clark: GStreamer and OMAP4|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Rob%20Clark%20-%20GStreamer%20and%20OMAP4.pdf]] +* [[Philippe Normand: HTML5 Media support in WebKit with GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Philippe%20Normand%20-%20HTML5%20media%20support%20in%20Webkit%20with%20GStreamer.pdf]] +* [[Jan Schmidt: Interactivity in GStreamer pipelines|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/gstinteract-0.10.1.tar.gz]] (Small DVD menu application :) +* [[Arun Raghavan: Pulse Audio in the Embedded World|http://www.elinux.org/images/6/61/Arun-pulse-elce2010.pdf]] (ELC-E) [[|(mirrored PDF) +* [[Benjamin Gaignard: Android and GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Benjamin%20Gaignard%20-%20GStreamer%20as%20Multimedia%20Framework%20in%20Android.pdf]] (ELC-E) +* [[Stefan Kost: Meego Multimedia|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Stefan%20Kost%20-%20The%20MeeGo%20Multimedia%20Stack.pdf]] (ELC-E) +* [[Embedded Linux Conference Europe 2010 slides|http://www.elinux.org/ELC_Europe_2010_Presentations]] +* [[Andrey Nechypurenko and Maksym Parkachov: Adaptive video streaming with Ice and GStreamer|https://docs.google.com/leaf?id=0BzV4szKbuvKwYzQwZDlhNjktMTVlOC00ZDczLThiZjQtZTRlMjcyYzRlZWIy&sort=name&layout=list&num=50]] ([[pdf|https://docs.google.com/leaf?id=0BzV4szKbuvKwYzQwZDlhNjktMTVlOC00ZDczLThiZjQtZTRlMjcyYzRlZWIy&sort=name&layout=list&num=50]], [[zip bundle with screencasts|https://docs.google.com/leaf?id=0BzV4szKbuvKwNTEwYTQwOGUtNzAzNi00NjQ5LTk2MjEtMWIzYTQzNjVkZTRh&sort=name&layout=list&num=50]] [[mirrored pdf|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Andrey%20Nechypurenko%20and%20Maksym%20Parkachov%20-%20Adaptive%20Video%20Streaming%20with%20Ice%20and%20GStreamer.pdf]]) +* [[Josep Torra: - Intel SMD elements in GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Josep%20Torra%20-%20Intel%20SMD%20elements%20in%20GStreamer.pdf]] +* [[Florent Thierry - Using gstreamer for building automated webcasting systems|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Florent%20Thierry%20-%20Using%20GStreamer%20for%20Building%20Automated%20Webcasting%20Systems.pdf%20]] +* [[Zeeshan Ali - Implementing DLNA using GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Zeeshan%20Ali%20-%20Implementing%20DLNA%20using%20GStreamer.pdf]] +* [[Jonas Holmberg - GStreamer on Axis devices|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Jonas%20Holmberg%20-%20GStreamer%20on%20Axis%20devices.pdf]] +* [[Luciana Fujii - Landell -live streaming for the masses|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Luciana%20Fujii%20-%20Landell%20-%20Live%20Streaming%20for%20the%20Masses.pdff]] +* [[Olivier Crête - Integrating Video Conferencing into Everyday Applications|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Olivier%20Crete%20-%20Integrating%20Video%20Conferencing%20into%20Everyday%20Applications.pdf]] +* [[Martin Bisson - Stereoscopic video and GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Martin%20Bisson%20-%20Stereoscopic%20Video%20and%20GStreamer.pdff]] ([[ppt and videos etc.|http://www.martinbisson.com/voyage/presentation/]]) +* [[Edward Hervey - GStreamer Editing Services: Video Editing in your pocket|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Edward%20Hervey%20-%20GStreamer%20Editing%20Services:%20Video%20Editing%20in%20your%20pocket.pdf]] +* [[Havard Graff - The Tandberg Movi - GStreamer Connection|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Havard%20Graff%20-%20The%20Movi-GStreamer%20Connection.pdf]] +* [[Mike Smith - Cross Platform Development with GStreamer: Lessons from Songbird|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2010/slides/Mike%20Smith%20-%20Cross%20Platform%20Development%20with%20GStreamer%20-%20Lessons%20from%20Songbird.pdf]] +* + +## Blogs posts about the conference + +* [[Christian Schaller: Summary of GStreamer Conference 2010|http://blogs.gnome.org/uraeus/2010/10/29/summary-of-gstreamer-conference-2010/]] +* [[Mind's Embedded Linux Blog: Impressions from the GStreamer conference|http://mindlinux.wordpress.com/2010/10/26/impressions-from-the-gstreamer-conference/]]
\ No newline at end of file diff --git a/GStreamerConference2011.mdwn b/GStreamerConference2011.mdwn new file mode 100644 index 0000000..54e0309 --- /dev/null +++ b/GStreamerConference2011.mdwn @@ -0,0 +1,13 @@ + + +# GStreamer Conference 2011 + + +## Videos + +Talks and slides have been recorded and are available at [[http://gstconf.ubicast.tv/channels/#conferences2011|http://gstconf.ubicast.tv/channels/#conferences2011]] + + +## Slides + +* [[title (FILL ME)|link]]
\ No newline at end of file diff --git a/GStreamerConference2012.mdwn b/GStreamerConference2012.mdwn new file mode 100644 index 0000000..d049343 --- /dev/null +++ b/GStreamerConference2012.mdwn @@ -0,0 +1,28 @@ + + +# GStreamer Conference 2012 + + +## Videos + +Talks have been recorded and will soon be available at [[http://gstconf.ubicast.tv/channels/#gstreamer-conference-2012|http://gstconf.ubicast.tv/channels/#gstreamer-conference-2012]] + + +## Slides + +* [[Stephen Burks and Joshua Doe - GStreamer for engineering video processing Applications|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/GStreamer_NVESD.odp]] +* [[Jason Gerard DeRose - Improving GStreamer Quality|http://t.co/2UZwEwMj]] +* [[Jan Schmidt - Multi-room playout (Home Area entertainment)|aurena-presentation.pdf]] [[GitHub Aurena sources|https://github.com/thaytan/aurena]] +* [[Guillaume Emont - Playing in the Sandbox|playing_in_the_sandbox.pdf]] +* [[Víctor M. Jáquez L. - Development of hardware-based elements for GStreamer v1.0|http://people.igalia.com/vjaquez/talks/gstconf2012.pdf]] [[Sources|https://gitorious.org/vjaquez-misc/kmsdce-talk]] +* [[Hans Verkuil - V4L2 status report|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/hv_v4l2_gstreamer2012.odp]] +* [[Rob Clark - OMAP, DMABuf and GStreamer|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/omap-dmabuf-gstcon2012.pdf]] +* [[Eric Anholt - Directions in Linux OpenGL|http://anholt.net/papers/gstreamer2012.odp]] +* [[Edward Hervey - Profiling and Optimisation|http://people.freedesktop.org/~bilboed/GStreamer-Conference-Profiling.pdf]] +* [[Tim-Philipp Müller - Keynote: GStreamer Status Report and Road Ahead|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/gstreamer-conf-2012-muller-status-report-road-ahead.pdf]] +* [[Timothy B. Terriberry - Opus Audio Codec|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/opus.pdf]] +* [[Takashi Iwai - ALSA development report|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/gsc2012_alsa.pdf]] +* [[Wim Taymans - The Road to 1.0|http://people.freedesktop.org/~wtay/gstreamer-conf-2012.pdf]] +* [[Kipp Cannon - GStreamer for Large-Scale Scientific Signal Processing|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/kcannon_gstreamer.tar.bz2]] +* [[Andoni Morales - The GStreamer SDK|https://github.com/ylatuya/Talks/blob/master/gstreamer_sdk_gstconf_2012/gstreamer_sdk.pdf?raw=true]] +* [[Rene Staedler - GStreamer Debugging|http://gstreamer.freedesktop.org/data/events/gstreamer-conference/2012/gst-debugging.pdf]]
\ No newline at end of file diff --git a/GStreamerConference2012/aurena-presentation.pdf b/GStreamerConference2012/aurena-presentation.pdf Binary files differnew file mode 100644 index 0000000..d4897ed --- /dev/null +++ b/GStreamerConference2012/aurena-presentation.pdf diff --git a/GStreamerConference2012/playing_in_the_sandbox.pdf b/GStreamerConference2012/playing_in_the_sandbox.pdf Binary files differnew file mode 100644 index 0000000..c029d8d --- /dev/null +++ b/GStreamerConference2012/playing_in_the_sandbox.pdf diff --git a/GStreamerHackfest2012.mdwn b/GStreamerHackfest2012.mdwn new file mode 100644 index 0000000..c9ce4f4 --- /dev/null +++ b/GStreamerHackfest2012.mdwn @@ -0,0 +1,153 @@ + +[[!img http://cdn9.wn.com/pd/84/f5/82da7c8f9487316bd8369e8995f3_grande.jpg] + + +# GStreamer 1.0 applications and bindings Hackfest/Sprint + +**Malaga -Spain , 25th to 27th of January 2012** + +**Primary contact:** (!) [[ChristianSchaller|ChristianSchaller]] +**Secondary contact:** (!) [[WimTaymans|WimTaymans]] + + +## Relevant GNOME/KDE/Other team + +(!) Multimedia + + +## Description + +(!) The goal of this hackfest is to kickstart the effort of porting applications to GStreamer 1.0 and fix remaining issues hindering such ports, be that bugs in binding code, missing plugins, broken pluging etc. + + +### Agenda, goals + +(!) Port a wide variety of GStreamer applications to 0.11/1.0 + +(!) Review of the 1.0 API + +(!) Make sure gobject introspection annotations are correct + +(!) Port any needed plugins from 0.10 to 0.11 + +(!) Identify and fix any general GStreamer 0.11 bugs that will hinder application porting + +(!) Make sure application developers are aware of new core features and possibilities in GStreamer 1.0 + + +### Measuring your success + +(!) If we can have initial ports done of the top 10 GNOME, KDE and server applications using GStreamer that would be a great success factor for the hackfest and allow us to be confident the transition from 0.10.x to 1.0.x will be smooth and easy. + + +### Attendants + +Please add your name here if you are interested in attending even if you are not sure you will be able to, as we want to meaure general interest.. We will be offering some travel sponsorship for this event, hopefully in collaboration with the GNOME Foundation and KDE E.v. + +Please add your name and project affiliation below: + +(!) Wim Taymans, GStreamer 1.0 lead designer and maintainer + +(!) Christian Schaller, Transmageddon + +(!) Sebastian Dröge, GStreamer Core + +(!) George Kiagiadakis, QtGStreamer/KDE + +(!) Philippe Normand, WebKit/Igalia + +(!) Olivier Crête, Farstream, VoIP/RTP + +(!) Tim Müller, GStreamer Core, Totem + +(!) Trever Fischer (tdfischer), phonon-gstreamer maintainer for Qt + +(!) Jonathan Matthew, Rhythmbox (interested but it's a long way from australia) + +(!) Jason DeRose, Novacut & Dmedia (PyGI with Python3, Gtk3) + +(!) Peteris Krisjanis, Jokosher + +(!) Edward Hervey, Python, [[PiTiVi|PiTiVi]] + +(!) Thibault Saunier, Python, [[PiTiVi|PiTiVi]] + +(!) Antigoni Papantoni, PiTiVI + +(!) Jeff Fortin, [[PiTiVi|PiTiVi]] + +(!) Thomas Vander Stichele, Flumotion + +(!) Josep Torra, Totem + +(!) Andoni Morales + +If you don't have a wiki account (and don't want to create one), you can email christian(.)schaller(at)gmail(.)com and I can add your name myself. + + +### Venue + +The venue for the hackfest will be Nido. Which is a shared office space centrally located in Malaga run by Ara and Yaiza, who happen to work for Canonical. You find more information about the venue here: [[http://www.nidomalaga.com/en|http://www.nidomalaga.com/en]] + +We will start at 10am each morning. + + +### Costs + +There is no attendance cost and the GStreamer project is not looking for any external sponsorship for the event in terms of help to cover venue rent. We might get some companies to sponsor lunches and maybe dinners specifically, so we might go around to the usual suspects to ask for that. + + +### Current sponsors + +(!) GStreamer Project + + +## How to get there + +(!) Inside Europe you can get cheap flights to Malaga with Ryanair and Easyjet. + + +## Accommodation and food + +We aim to provide free lunch at the venue and at least one dinner. + +Some hotel suggestions: + +Etap Malaga Centro: [[http://www.etaphotel.com/es/hotel-6350-etap-malaga-centro/location.shtml|http://www.etaphotel.com/es/hotel-6350-etap-malaga-centro/location.shtml]] From 29euros per night (double bedroom) + +Ibis Centro [[http://www.ibishotel.com/es/hotel-5585-ibis-malaga-centro-ciudad/index.shtml|http://www.ibishotel.com/es/hotel-5585-ibis-malaga-centro-ciudad/index.shtml]] From 39 euros per night (double bedroom) + +Hotel del Pintor [[http://www.hoteldelpintor.com/|http://www.hoteldelpintor.com/]] From 49 euros (double bedroom) + +Babia Hostel (can be a bit noisy at nights) [[http://www.babiahostel.com/|http://www.babiahostel.com/]] 15euros per person night in double 12euros per person night in dorm + +Picasso Corner Hostel [[http://www.picassoscorner.hostel.com/|http://www.picassoscorner.hostel.com/]] From 13 euros per person in a dorm, and 18euros per person in a double + +Some recommended tapas restaurants: + +Taberna Mitjana: [[http://www.travbuddy.com/Taberna-Mitjana-v471550|http://www.travbuddy.com/Taberna-Mitjana-v471550]] + +El Pimpi (a very very typical place in Malaga): [[http://www.tripadvisor.com/Restaurant_Review-g187438-d806282-Reviews-El_Pimpi-Malaga_Costa_del_Sol_Andalucia.html|http://www.tripadvisor.com/Restaurant_Review-g187438-d806282-Reviews-El_Pimpi-Malaga_Costa_del_Sol_Andalucia.html]] + + +### Previous discussions, organization threads, drafts, relevant links, etc + +(!) Floating refs in GI - [[https://bugzilla.gnome.org/show_bug.cgi?id=657202|https://bugzilla.gnome.org/show_bug.cgi?id=657202]] + +(!) GError marshaling GI - [[https://bugzilla.gnome.org/show_bug.cgi?id=666098|https://bugzilla.gnome.org/show_bug.cgi?id=666098]] + +GStreamer 0.11 status reports + +(!) Status 4 - [[http://lists.freedesktop.org/archives/gstreamer-devel/2011-December/034438.html|http://lists.freedesktop.org/archives/gstreamer-devel/2011-December/034438.html]] + +(!) Status 3 - [[http://lists.freedesktop.org/archives/gstreamer-devel/2011-August/032588.html|http://lists.freedesktop.org/archives/gstreamer-devel/2011-August/032588.html]] + +(!) Status 2 - [[http://lists.freedesktop.org/archives/gstreamer-devel/2011-June/031891.html|http://lists.freedesktop.org/archives/gstreamer-devel/2011-June/031891.html]] + +(!) Status 1 - [[http://lists.freedesktop.org/archives/gstreamer-devel/2011-April/031128.html|http://lists.freedesktop.org/archives/gstreamer-devel/2011-April/031128.html]] + +Other GStreamer 0.11 resources: + +(!) Porting guide: [[http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-0.11.txt?h=0.11|http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/random/porting-to-0.11.txt?h=0.11]] + +(!) [[ZeroPointEleven|ZeroPointEleven]] wiki page diff --git a/GStreamerHackfest2013.mdwn b/GStreamerHackfest2013.mdwn new file mode 100644 index 0000000..fbfcdf7 --- /dev/null +++ b/GStreamerHackfest2013.mdwn @@ -0,0 +1,91 @@ + +[[!img http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Milano_collage.jpg/300px-Milano_collage.jpg] + + +# GStreamer Hackfest/Sprint + +**Location Milan, Italy - 28th to 31st March 2013** + +**Primary contact:** [[ChristianSchaller|ChristianSchaller]] +**Secondary contact:** [[TimMüller|TimMüller]] + + +## Relevant GNOME/KDE/Other team + +* Multimedia +* application developers +* binding developers + +## Description + +The goal of this hackfest is to follow up on last year's GStreamer 1.0 hackfest in Malaga, try to fill in any gaps that are still open, and to discuss or hack on anything and everything GStreamer-related. Maybe even fix a few bugs. The target this year will be a lot more core GStreamer focused as opposed to the application focus of last years hackfest. + + +### Agenda, goals + +* GStreamer [[RoadMap|ReleasePlanning/RoadMap]] +* Fix GNonLin for 1.x +* Fix the deadlocks and most serious bugs in stack affecting Pitivi (Jeff will provide testing samples and reproduceability) +* Make a Pitivi release (or at least a testing/preview release) +* Port Buzztard to GStreamer 1.x +* Get gst-python to a releasable state +* Extend encodebin API to allow for profile selection +* Device enumeration and monitoring API +* Hardware codecs and GL integration +* add your goals here + +### Attendants + +Please add your name here if you are interested in attending even if you are not sure you will be able to, as we want to measure general interest. We will be offering some travel sponsorship for this event, hopefully in collaboration with the GNOME Foundation and KDE E.v. + +Please add your name and project affiliation below: + +* Wim Taymans, GStreamer 1.0 lead designer and maintainer (need accomodation) +* Christian Schaller, Transmageddon +* Tim Müller, GStreamer developer (need accommodation) +* Sebastian Dröge, GStreamer developer (need accomodation) +* -<del>Jan Schmidt, Senior mischief maker</del>- +* Philippe Normand, [[WebKit|WebKit]] (need accomodation) +* Jeff Fortin, Pitivi (need accomodation) +* Thibault Saunier, Pitivi and GES (need accomodation) +* Nicolas Dufresne, GStreamer (need accomodation) +* Stefan Sauer, GStreamer & Buzztard developer +* Edward Hervey, GStreamer and GES +* Alessandro Decina, GStreamer +* Peteris Krisjanis, GStreamer and Jokosher +* Olivier Crête, GStreamer, Farstream, etc +* Víctor Jáquez, [[WebKit|WebKit]] and GStreamer +* Arun Raghavan, Pulseaudio, GStreamer (need accommodation) +* Luciana Fujii, Cheese (need accommodation) +If you don't have a wiki account (and don't want to create one), you can email christian(.)schaller(at)gmail(.)com and I can add your name myself. + + +### Venue + +* Hub Milano - [[http://milan.the-hub.net/sale-riunioni-grandi-riunioni/|http://milan.the-hub.net/sale-riunioni-grandi-riunioni/]] + +### Costs + +There is no attendance cost and the GStreamer project is looking for some sponsorship help to cover food and similar for the attendees. + +We might get some companies to sponsor lunches and maybe dinners specifically, so we might go around to the usual suspects to ask for that. + + +## Travel sponsorship + +We have some limited funds to help with travel costs. The money will be allocated based on the focus of the hackfest and involvement level of those requesting sponsorship. + + +### Current sponsors + + +## How to get there + +* Fly in to Milan MXP airport + +## Accommodation and food + +We aim to provide free lunch at the venue and at least one dinner. + + +### Previous discussions, organization threads, drafts, relevant links, etc diff --git a/GStreamerSharp.mdwn b/GStreamerSharp.mdwn new file mode 100644 index 0000000..06478b6 --- /dev/null +++ b/GStreamerSharp.mdwn @@ -0,0 +1,16 @@ + + +# Finishing/Improving the GStreamer C#/CLI bindings + +3 years ago the GStreamer C#/CLI bindings were started as a GSoC project. Unfortunately they didn't reach a releaseable and usable state and nobody worked on it afterwards. This GSoC project is about finishing/improving these bindings. There are still some fundamental issues and a lot of functionality is not included yet. + +Useful skills for this project would be general knowledge about GStreamer and C#, even better would be knowledge about C# bindings in general and GObject-based C# bindings in specific. + + +## Resources + +[[http://cgit.freedesktop.org/gstreamer/gstreamer-sharp/|http://cgit.freedesktop.org/gstreamer/gstreamer-sharp/]] [[http://www.mono-project.com/GAPI|http://www.mono-project.com/GAPI]] + +**Mentor: Sebastian Dröge -- slomo or IRC** + +Back to [[TaskList|TaskList]] diff --git a/GeneratedFormatTestdata.mdwn b/GeneratedFormatTestdata.mdwn new file mode 100644 index 0000000..dc9812a --- /dev/null +++ b/GeneratedFormatTestdata.mdwn @@ -0,0 +1,28 @@ + + +# Generated Format Testdata + + +## Background + +As one can see from the [[test coverage reports|http://gstreamer.freedesktop.org/data/coverage/lcov/]] we lack of in depth testing on the demuxers and parsers. Testing those is important to be able to deliver standard compliant and robust implementation. Shipping a huge ammount of testfiles with the tests is not feasable. + + +## Task + +The scope of the project would be to use a tool to generate a set of testdata form a formal format description. One such tool that could be used is [[peach fuzzer|http://peachfuzzer.com/]]. The idea here is to generate not all possible mutationl of a file (which is close to impossible), but instead create a subset that is likely to trigger the majority of bugs. To give an example, one would create variants of wav files that contain 0,1,2,17,255 audio-channels - 1 and two would be likely cases, 0 and 255 corner cases and 17 a random value in the middle. + + +## Resources + +* [[GStreamer test coverage|http://gstreamer.freedesktop.org/data/coverage/lcov/]] +* [[peach fuzzer|http://peachfuzzer.com/]] +**Mentor: Stefan Kost - ensonic on IRC** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2010|CategoryGSOC2010]] [[CategoryTasks|CategoryTasks]] diff --git a/GstBaseDemux.mdwn b/GstBaseDemux.mdwn new file mode 100644 index 0000000..c93884e --- /dev/null +++ b/GstBaseDemux.mdwn @@ -0,0 +1,15 @@ + + +## Features + +* [[GstIndex|GstIndex]] +* handling queries +* seeking +Some implementation can probably be shared with [[GstBaseParse|GstBaseParse]]. + + +## Design + +A key benefit would be more complete implementation for the GStreamer feature set. For an example right now mostly SEEK_SET works - the generic implementation might be able to add the support for other modes - no need to fix it in every single element. + +Index handling should be more intelligent (at least as the implementation in avidemux). Seeking is not the primary usecase. Fast time-to-play is important. Thus if possible build the index on demand. In the case of avi, it currently parses the whole file and build an in memory index. This can easily generate a huge data structure (e.g. 50 mb). On the other hand avidemux can play streams where it parses index information while it plays. It would be good it it could also do this for non stream playback - start immediately and remember the index entries. If one seeks backwards, we have the index. If one seeks forward, parse until we have the position. diff --git a/GstBaseParse.mdwn b/GstBaseParse.mdwn new file mode 100644 index 0000000..3f9f555 --- /dev/null +++ b/GstBaseParse.mdwn @@ -0,0 +1,35 @@ + +**Outdated**: _GstBaseParse_ was introduced in gstreamer-0.10.33. The text below may or may not reflect the current implementation. Read [[the current documentation|http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-libs/html/gstreamer-libs-GstBaseParse.html]] for more information. + +We need a base class for general parsers as most current parsers share a lot of rather complex code. + +Implementation has started at [[bug 518857|http://bugzilla.gnome.org/show_bug.cgi?id=518857]]. + + +### Features: + +* Keeping synchronization and splitting into complete frames that the subclass handles +* TIMESTAMP and other metadata of buffers should be set by the base class as good as possible if the subclass didn't already +* Pull & Push mode support +* [[GstIndex|GstIndex]] +* Event handling, especially NEWSEGMENT/SEEKING/EOS and friends +* Query handling, especially DURATION/POSITION/CONVERT, let subclass provide methods for conversions +* Seek handling, by calling the subclass' conversion method and in pull mode by scanning for the required frame and generating a seek table. Allow subclass to overwrite the accurate seeking behaviour. + +### Base class structure: + +* guint min_frame_size: minimal size required to check if this could be a valid frame and to calculate the size of the complete frame +* gboolean check_valid_frame (GstBaseParse *parse, [[GstBuffer|GstBuffer]] *buffer, guint *size): Gets a buffer of at least min_frame_size bytes passed. Should return TRUE if this looks like a valid frame and the size of the complete frame in size. Otherwise should return FALSE and the base class activates resynchronization logic. +* [[GstFlowReturn|GstFlowReturn]] parse_frame (GstBaseParse *parse, [[GstBuffer|GstBuffer]] *buffer): Gets a complete frame passed. subclass should parse this, set caps as appropiate, set timestamp/duration/etc if it can, mark as keyframe, set duration if possible. Has a custom return value to get this frame dropped. The base class pushes the buffer downstream after processing, updating it's position values and adding buffer metadata that is missing and can be calculated. The passed buffer's offset, if set, is the byte offset from which this frame was read. +* gboolean convert (GstBaseParse * parse, [[GstFormat|GstFormat]] src_format, gint64 src_value, [[GstFormat|GstFormat]] dest_format, gint64 * dest_value): converts from source to target format if possible, otherwise returns FALSE. Is used for queries and inaccurate seeks. GST_FORMAT_DEFAULT has the meaning of frames. **Optional**, if not implemented seeking will not be supported and queries might also not be supported in all formats. +* gboolean find_frame (GstBaseParse *parse, [[GstFormat|GstFormat]] src_format, gint64 src_value, gint64 * dest_value): Gets a position passed and should return TRUE and the offset in bytes where this position is. Will only be called in pull mode and the subclass can pull whatever it wants from upstream. **Optional**, if not implemented the base class will implement it by calling check_valid_frame() and parse_frame() to find the wanted frame and build a seek table. + +### Functions: + +* void gst_base_parse_set_duration (GstBaseParse *parse, [[GstFormat|GstFormat]] fmt, gint64 duration): Updates the duration in the given format for duration queries, etc. + +### Discussion: + +Is something missing or not optimal? + +It might make sense to have a way to let subclasses specify the minimal frame size necessary to read timestamp and other useful information and then let them implement a parse_frame_minimal() method that can be used for building the seek table in pull mode. diff --git a/GstreamerCaps.mdwn b/GstreamerCaps.mdwn new file mode 100644 index 0000000..822df99 --- /dev/null +++ b/GstreamerCaps.mdwn @@ -0,0 +1,116 @@ + + +# GStreamer Caps list + +This list is not complete, but lists some of the unique caps identifies in GStreamer: + + +## Audio Caps + + +[[!format txt """ +'audio/x-sbc' +'audio/x-mulaw' +'audio/x-flac' +'audio/x-alaw' +'audio/x-speex' +'audio/x-ac3' +'audio/x-alac' +'audio/mpeg,mpegversion=1,layer=2' +'audio/x-nellymoser' +'audio/x-gst_ff-sonic' +'audio/x-gst_ff-sonicls' +'audio/x-wma,wmaversion=1' # This is WMA7 +'audio/x-wma,wmaversion=2' # This is WMA8 +'audio/x-dpcm,layout=roq' +'audio/x-adpcm,layout=adx' +'audio/x-adpcm,layout=g726' +'audio/x-adpcm,layout=quicktime' +'audio/x-adpcm,layout=dvi' +'audio/x-adpcm,layout=microsoft' +'audio/x-adpcm,layout=swf' +'audio/x-adpcm,layout=yamaha' +'audio/mpeg,mpegversion=4' # This is aac +'audio/mpeg,mpegversion=1,layer=3' # This is mp3 +'audio/x-celt' +'audio/mpeg,mpegversion=[4, 2]' # This is aac +'audio/x-vorbis' +'audio/x-gsm' +"""]] +== Container Caps == + + +[[!format txt """ +'audio/x-wav' +'video/x-matroska' +'audio/x-iec958' +'application/x-id3' +'multipart/x-mixed-replace' +'video/x-msvideo' +'application/mxf' +'video/mpegts' +'video/x-mve' +'video/mj2' +'video/quicktime,variant=3gp' +'video/quicktime,variant=iso' +'video/quicktime,variant=apple' +'application/ogg' +'video/mpeg' +'application/x-rtp' +'application/x-rtp' +'video/x-flv' +"""]] + +## Video caps + + +[[!format txt """ +'video/x-dirac' +'image/png' +'image/jpeg' +'video/x-smoke' # mjpeg variant developed by Wim Taymans +'video/x-asus,asusversion=1' +'video/x-asus,asusversion=2' +'image/bmp' +'video/x-dnxhd' +'video/x-dv' +'video/x-ffv,ffvversion=1' +'video/x-gst_ff-ffvhuff' +'video/x-flash-screen' +'video/x-flash-video,flvversion=1' # This is Sorenson variation of h263+ also known as s263 +'video/x-h261' +'video/x-h263,variant=itu,h263version=h263' +'video/x-h263,variant=itu,h263version=h263p' +'video/x-huffyuv' +'image/jpeg' +'image/jpeg' +'video/mpeg,mpegversion=1' +'video/mpeg,mpegversion=2' +'video/mpeg,mpegversion=4' # This is MPEG4 Part2 +'video/x-msmpeg,msmpegversion=41' +'video/x-msmpeg,msmpegversion=42' +'video/x-msmpeg,msmpegversion=43' +'video/x-gst_ff-pam' +'image/pbm' +'video/x-gst_ff-pgm' +'video/x-gst_ff-pgmyuv' +'image/png' +'image/ppm' +'video/x-rle,layout=quicktime' +'video/x-gst_ff-roqvideo' +'video/x-pn-realvideo,rmversion=1' +'video/x-pn-realvideo,rmversion=2' +'video/x-gst_ff-snow' +'video/x-svq,svqversion=1' +'video/x-wmv,wmvversion=1' +'video/x-wmv,wmvversion=2' +'video/x-gst_ff-zmbv' +'video/x-theora' +'video/x-h264' +'video/x-gst_ff-libxvid' +'video/x-h264', +'video/x-xvid' +'video/mpeg,mpegversion=[1, 2]' +'video/x-theora' +'application/x-yuv4mpeg,y4mversion=2' +"""]]
\ No newline at end of file diff --git a/HowToCompileForEmbedded.mdwn b/HowToCompileForEmbedded.mdwn new file mode 100644 index 0000000..37658f8 --- /dev/null +++ b/HowToCompileForEmbedded.mdwn @@ -0,0 +1,55 @@ + +The easiest way to build GStreamer is with a scratchbox environment, either scratchbox, or scratchbox2. + +Set prefix to the place where you want GStreamer to be installed. + + +### glib + + +[[!format txt """ +./configure --prefix="$prefix" --disable-static --with-html-dir=/tmp/dump +make install +"""]] + +### gstreamer + + +[[!format txt """ +./configure --prefix="$prefix" --disable-nls --disable-static --disable-gobject-cast-checks --enable-binary-registry --disable-loadsave --disable-trace --with-html-dir=/tmp/dump +make install +"""]] + +### orc (replaces liboil) + + +[[!format txt """ +./configure --prefix="$prefix" --disable-static --with-html-dir=/tmp/dump +make install +"""]] + +### gst-plugins-base + + +[[!format txt """ +./configure --prefix="$prefix" --disable-nls --disable-static --with-html-dir=/tmp/dump +make install +"""]] + +### gst-plugins-good + + +[[!format txt """ +./configure --prefix="$prefix" --disable-nls --disable-static --with-html-dir=/tmp/dump --with-plugins=avi,qtdemux +make install +"""]] +_Note_: If you want all the plug-ins remove the **with-plugins** option, otherwise specify the ones you want + + +### gst-plugins-ugly + + +[[!format txt """ +./configure --prefix="$prefix" --disable-nls --disable-static --with-html-dir=/tmp/dump --with-plugins=asfdemux +make install +"""]]
\ No newline at end of file diff --git a/HowToUseThisSite.mdwn b/HowToUseThisSite.mdwn new file mode 100644 index 0000000..46886a2 --- /dev/null +++ b/HowToUseThisSite.mdwn @@ -0,0 +1,21 @@ + + +# How to use this site + +A Wiki is a collaborative site, anyone can contribute and share: + +* Edit any page by pressing **Edit** at the top or the bottom of the page +* Create a link to another page with joined capitalized words (like [[WikiSandBox|WikiSandBox]]) or with `["quoted words in brackets"]` +* Search for page titles or text within pages using the search box at the top of any page +* See [[HelpForBeginners|HelpForBeginners]] to get you going, [[HelpContents|HelpContents]] for all help pages. +To learn more about what a [[WikiWikiWeb|WikiWikiWeb]] is, read about [[!MoinMoin WhyWikiWorks desc="WhyWikiWorks"]] and the [[!MoinMoin WikiNature desc="WikiNature"]]. Also, consult the [[HelpMiscellaneous/FrequentlyAskedQuestions|HelpMiscellaneous/FrequentlyAskedQuestions]] page. + + +# Interesting starting points + +* [[RecentChanges|RecentChanges]]: see where people are currently working +* [[WikiSandBox|WikiSandBox]]: feel free to change this page and experiment with editing +* [[FindPage|FindPage]]: search or browse the database in various ways +* [[SyntaxReference|SyntaxReference]]: quick access to wiki syntax +* [[SiteNavigation|SiteNavigation]]: get an overview over this site and what it contains +This wiki is powered by [[MoinMoin|MoinMoin]]. diff --git a/Moovit.mdwn b/Moovit.mdwn new file mode 100644 index 0000000..c74a370 --- /dev/null +++ b/Moovit.mdwn @@ -0,0 +1,23 @@ + + +# Moovit + + +## Background + +To edit HD video it would be good to have more GPU based elements. Movit, a free C++ library for video effects processing that completely relies on GPU. + + +## Resources + +[[http://libregraphicsworld.org/blog/entry/introducing-movit-free-library-for-gpu-side-video-processing|http://libregraphicsworld.org/blog/entry/introducing-movit-free-library-for-gpu-side-video-processing]] + +**Mentor: #pitivi on IRC** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2013|CategoryGSOC2013]] [[CategoryTasks|CategoryTasks]] diff --git a/MoreBaseClases.mdwn b/MoreBaseClases.mdwn new file mode 100644 index 0000000..9a34a7b --- /dev/null +++ b/MoreBaseClases.mdwn @@ -0,0 +1,19 @@ + + +# Create more baseclases + + +## Background + +One major improvment of the 0.10 series was the use of baseclasses. All plugins were derived directly from [[GstElement|GstElement]] in the 0.8 series. In 0.10 there are still several use cases where base classes would be beneficial. The task consist of studying existing elements and refactoring common functionality into a baseclass. Ideally unit tests are written along to ensure the implementation is correct. + +* [[GstBaseParse|GstBaseParse]]: parser base class +* [[GstBaseDemux|GstBaseDemux]]: demuxer base class +* [[GstBaseDecode|GstBaseDecode]]: decoder base class +* [[GstBaseMux|GstBaseMux]]: muxer base class +* [[GstBaseEncode|GstBaseEncode]]: encoder base class +* [[GstTagMux|GstTagMux]]: tag muxer base class + +## Resources + +Back to [[TaskList|TaskList]] diff --git a/MorePlugins.mdwn b/MorePlugins.mdwn new file mode 100644 index 0000000..40dbdb8 --- /dev/null +++ b/MorePlugins.mdwn @@ -0,0 +1,79 @@ + +In addition to the [[official plugins|Plugins]], there are many other open source and commercial plugins listed below (in alphabetical order) : + + +# Open source + + +## gladstone + +GladSToNe is an educational tool for learning about hi-performance audio handling for real-time transmissions. The goal of the project is to use the open source model to improve the psycho acoustics, noise shaping and speed of audio transmissions over IP. Contains a G729 codec plugin, **g729enc** for encoding and **g729dec** for decoding. + +* [[Project page on Google Code|http://code.google.com/p/gladstone/]] +* [[Code repository on Gitorious|http://gitorious.org/gladstone]] +* [[Profile on ohloh.net|http://www.ohloh.net/p/gladstone]] + +## gst-buzztard + +Extra interfaces for audio plugins + a few plugin using them. Contains a wrapper for buzz-machine plugins. **audiodelay** add an echo effect to audio, the **bml** plugin wraps buzz-machine plugins, **fluidsynth** is an audio synthesizer, and **simsyn** is a simple monophonic audio synthesizer. + +* [[http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/gst-buzztard/|http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/gst-buzztard/]] + +## gst-fluendo + +[[Fluendo|http://www.fluendo.com/]] provides several open source plugins, including: + +* an MIT-licensed mp3 decoder (**flump3dec**) +* an MPL-licensed MPEG Transport Stream and Program Stream demuxer (**flutsdemux**, **flupsdemux**) +* an MPL-licensed MPEG Transport Stream muxer (**flutsmux**) +* an MPEG TS Timeshifter element (**flufakeshifter** for time shifting on fake streams, and **flumpegshifter** for time shifting on MPEG TS streams) +* an MIT-licensed iLBC decoder / encoder (**fluilbcdec**, **fluilbcenc**) +* an MIT-licensed ADPCM decoder (**fluadpcmimaqtdec**, **fluadpcmimadvidec**, **fluadpcmmsdec**) +* an LGPL-licensed GDL sink for Intel's Sodaville and Canmore platforms (**flugdlsink**) +The code and issue tracker are hosted on Fluendo's TRAC: + +* [[https://core.fluendo.com/gstreamer/trac|https://core.fluendo.com/gstreamer/trac]] + +## gstlal + +A suite of elements for gravitational-wave data analysis from the [[LIGO|http://en.wikipedia.org/wiki/LIGO]] project. + +* [[Project page|https://www.lsc-group.phys.uwm.edu/daswg/projects/gstlal.html]] - including Git repository + +## gst-plugins-elphel + +Elphel camera-related plugins, including **jp462bayer** which converts color and monochrome JP46 Elphel bitstreams to Bayer raw format, and **bayer2rgb2** which converts raw Bayer streams to RGB images using libdc1394 debayering algorithms. + +* [[Project page on Google Code|http://code.google.com/p/gst-plugins-elphel/]] - including SVN repository + +## GstStabilizer + +Python plugin using OpenCV to stabilize video. + +* [[https://github.com/guijemont/GstStabilizer|https://github.com/guijemont/GstStabilizer]] + +## PiTiVi + +[[http://www.pitivi.org/ PiTiVi|http://www.pitivi.org/ PiTiVi]] is a Python-based non-linear editor, and includes several Python plugins + +* [[repository browser|http://git.pitivi.org/?p=pitivi.git;a=tree;f=pitivi/elements Git]] + +## pocketsphinx + +Speech recognition plugin based on CMU sphinx. **pocketsphinx** takes audio as input and produces text on output, and **vader** marks utterance start and end points in an audio stream. + +* [[Using PocketSphinx with GStreamer and Python (or Vala)|http://cmusphinx.sourceforge.net/wiki/gstreamer]] - includes example code +* [[SVN repository on Sourceforge|http://cmusphinx.svn.sourceforge.net/viewvc/cmusphinx/trunk/pocketsphinx/src/gst-plugin/]] + +<div style="display:none"> +Perhaps use a table instead? +[[!table header="no" class="mointable" data=""" +**Name** | **Description** | **Website** | **Source** +gladstone | Contains a G729 codec plugin | [[http://code.google.com/p/gladstone/|http://code.google.com/p/gladstone/]] | [[http://gitorious.org/gladstone|http://gitorious.org/gladstone]] +gst-buzztard | Contains a wrapper for buzz-machine plugins. | | [[http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/gst-buzztard/|http://buzztard.svn.sourceforge.net/viewvc/buzztard/trunk/gst-buzztard/]] +"""]] +</div> + +# Commercial + +* [[Entropy Wave codec package|http://entropywave.com/products/codecs-for-oems/]]
\ No newline at end of file diff --git a/NewCapsFields.mdwn b/NewCapsFields.mdwn new file mode 100644 index 0000000..7de3806 --- /dev/null +++ b/NewCapsFields.mdwn @@ -0,0 +1,15 @@ + + +# Video + +Should parsers parse codec_data and put it on the caps. Then we could negotiate profile and level of e.g. mpeg4/h263, h264. + + +## h264 + +See [[this thread|https://sourceforge.net/mailarchive/forum.php?thread_name=1228234535.18691.30.camel%40metal&forum_name=gstreamer-devel]]. Proposal is to add another field to video/x-h264. I don't think we can use systemstream={true/false} here, should we use h264packing={length-prefixed,startcode-delimmited} as a enum (are there more variants). + +Affected elements: + +* gst-plugins-good: gst/avi/avi(mux,demux), gst/rtp/rtph264(pay,depay), gst/qtdemux/qtdemux +* gst-plugins-bad: ext/x264enc, , gst/h264parse/h264parse, gst/qtmux/qtmux
\ No newline at end of file diff --git a/NewGstVideo.moin b/NewGstVideo.moin new file mode 100644 index 0000000..18d3914 --- /dev/null +++ b/NewGstVideo.moin @@ -0,0 +1,54 @@ +Collection of thoughts on new raw video caps and utility API for building/parsing these caps.
+
+The caps themselves (to replace {{{video/x-raw-{yuv,rgb,gray,etc} }}}) should support:
+ * stride
+ * interlaced buffer layout possibilities
+ * stereo buffer layout possibilities
+ * combinations of the above
+ * use fourcc's, or some fourcc-like value for rgb/grey caps (maybe string.. quarks for fast '==' comparison)
+ * note that if all raw video formats are supported w/ some fourcc-like value, then perhaps the caps name should just be {{{video/x-raw}}}
+ * what about bayer?
+
+And should be flexible enough to support addition of new features later. Which means some way to negotiate between different elements which may or may not support the new feature.
+
+To this end, direct parsing of video/raw caps by the elements should be discouraged, and likewise direct access to buffer data. Instead gstvideo API should be used to parse caps into a video descriptor struct, and then accessor functions to return information like row/pixel stride, get offset to various position in buffer (ie. find ptr to beginning of 2nd field of right frame of video, which may or may not be interlaced and/or stereo)..
+
+Note that existing {{{gst-libs/gst/video/video.[ch]}}} should be replaced as it does not scale well to add new features. For example, functions to calculate rowstride would all need to have an additional parameter added to deal with strided buffers.
+
+Some features like rowstride can be added somewhat transparently, because it is only a matter of calculation of certain positions within the raw data. Others, like stereo, probably require the element to have a fundamental understanding of the format. Maybe this can be handled, and allow certain room for extension in the future with a features bitmask. ie. something like:
+
+{{{#!c
+#define MY_RAW_FEATURES (GST_VIDEO_INTERLACED | GST_VIDEO_STRIDED) /* but not GST_VIDEO_STEREO */
+
+...
+ GstVideo desc;
+ gst_video_parse_caps (&desc, caps);
+ if (desc.features & ~MY_RAW_FEATURES) {
+ ... I don't support this ...
+ return FALSE;
+ }
+}}}
+(a bitmask does limit number of features that could be added.. but how many possible features could there be?)
+
+Open points:
+ * some formats, like I420, could have two differing definitions of rowstride. (1) U and V planes have same stride in bytes as Y, or (2) U and V planes have 1/2 stride as Y.
+ * in some cases, it might be nice to have some flexibility to allow support for non-packed planar/semi-planar formats. In some cases where decoder requires padding or cropping for edges, or certain alignment requirements, the U and V planes may not start immediately after the previous frame.
+
+= Interlaced caps =
+
+= RGB/grey caps =
+
+= Stereo video support in an existing branch =
+
+Stereo caps have been proposed in a Google Summer of Code development branch (see [[http://gitorious.org/video3d/video3d]]). One of the important points in choosing how to extend existing caps to support a way to specify whether the video stream was stereo or not was the fact that we don't want existing plugins to accept silently a stereo stream and treat it as normal stream, as the interpretation of a {{{width x height}}} buffer is totally different if the buffer is stereo or not. Therefore, the addition of a field such as {{{"stereo=true"}}} or {{{"channels=2"}}} to existing video caps was not used.
+
+Instead, the new caps use new media-types : {{{video/x-raw-{yuv,rgb,gray}-stereo}}}. The addition of the {{{"-stereo"}}} to the media-type makes sure that existing plugins won't accept these caps. The new caps that are to replace {{{video/x-raw-{yuv,rgb,gray,etc}}}} could add something like {{{-full}}} during integration of these new caps in order to keep compatibility with existing plugins.
+
+The only addition in the caps for the {{{"-stereo"}}} variants is a new {{{layout}}} field:
+ * GST_VIDEO3D_LAYOUT_MEMORY_CONSECUTIVE:
+ * GST_VIDEO3D_LAYOUT_ROW_INTERLEAVED:
+This might need need more variants as:
+ * GST_VIDEO3D_LAYOUT_MEMORY_CONSECUTIVE_LEFT_RIGHT:
+ * GST_VIDEO3D_LAYOUT_MEMORY_CONSECUTIVE_RIGHT_LEFT:
+ * GST_VIDEO3D_LAYOUT_ROW_INTERLEAVED_LEFT_RIGHT:
+ * GST_VIDEO3D_LAYOUT_ROW_INTERLEAVED_RIGHT_LEFT:
diff --git a/OpencvGestureDetection.mdwn b/OpencvGestureDetection.mdwn new file mode 100644 index 0000000..09b3419 --- /dev/null +++ b/OpencvGestureDetection.mdwn @@ -0,0 +1,26 @@ + + +# OpenCV Plugin for gesture detection + + +## Background + +The idea of the project is to add a plugin to gst-plugins-bad/ext/opencv for gesture(eg:hand) detection. + +* implement the [[GestureDetection|GestureDetection]] + [[GestureTracking|GestureTracking]] plugin +* synthesize navigation-events (use case: control media player using gestures) +* sub task: Port all the gst-opencv plugins(facedetect, textoverlay etc..) to 0.11/1.0 + +## Resources + +* [[http://opencv.willowgarage.com/wiki/|http://opencv.willowgarage.com/wiki/]] +* A handful of information is available in the following blog post: [[http://www.andol.info/hci/1661.htm|http://www.andol.info/hci/1661.htm]] +**Mentor: Sreerenj Balachandran - sree on IRC** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2009|CategoryGSOC2009]] [[CategoryTasks|CategoryTasks]] diff --git a/Pitivi.mdwn b/Pitivi.mdwn new file mode 100644 index 0000000..79ce6a6 --- /dev/null +++ b/Pitivi.mdwn @@ -0,0 +1,29 @@ + +[[PiTiVi|http://www.pitivi.org]] is an open source video editor. + +The current status of [[PiTiVi|PiTiVi]], what's done and what needs to be done is detailed on the pitivi wiki ([[http://wiki.pitivi.org/wiki/Google_Summer_of_Code|http://wiki.pitivi.org/wiki/Google_Summer_of_Code]]) + +Check out the [[PiTiVi|PiTiVi]] page on the [[PiTiVi|PiTiVi]] wiki for some ideas for [[PiTiVi|PiTiVi]] related Summer of Code projects. + + +## Resources + +* [[http://www.pitivi.org/|http://www.pitivi.org/]] + +## Skills needed + +* Python +* GTK +* Student needs to know how to use GStreamer, plugin creation knowledge would be handy too +* Knowledge about video-editing +Students interested in doing a Google Summer of code project around [[PiTiVi|PiTiVi]] should join the #pitivi channel on irc.freenode.net. You should be able to find someone online at almost any time to discuss your project idea there. + +**Mentor: Edward Hervey ([[PiTiVi|PiTiVi]] author) aka bilboed on IRC ** + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2010|CategoryGSOC2010]] [[CategoryTasks|CategoryTasks]] diff --git a/Plugins.mdwn b/Plugins.mdwn new file mode 100644 index 0000000..d831943 --- /dev/null +++ b/Plugins.mdwn @@ -0,0 +1,5 @@ + +GStreamer plugin modules hosted by Freedesktop.org are listed here: + +* [[http://gstreamer.freedesktop.org/modules/|http://gstreamer.freedesktop.org/modules/]] +Additional plugin modules hosted elsewhere are described in [[MorePlugins|MorePlugins]]. diff --git a/PresetDesign.mdwn b/PresetDesign.mdwn new file mode 100644 index 0000000..2bcc0a5 --- /dev/null +++ b/PresetDesign.mdwn @@ -0,0 +1,96 @@ + +Presets are a fairly straightforward idea conceptually, but have lot of practical issues with them. These pages are meant to outline the various levels of presets we are trying to put together and discuss some of the practical implications. + +**Part of this page is out of date as part of what we used to use presets for, like codec profiles are now put into the caps instead, presets are still useful for certain things though, but be aware that part of this page might refer to out of date things**; + +**GStreamer presets interface**; Design details and more on the [[GStreamer presets interface|http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstPreset.html]] can be found on the Buzztard [[Preset Interface|http://www.buzztard.org/index.php/Preset_handling_interface]] pages. + +There are multiple goals of the GStreamer presets interface, among them to function as a higher level abstraction for setting attribute values for elements which does the same thing, but with different implementations. For example we can have multiple Dirac encoders which all output Dirac video, but due to the implementation details they do not share the same properties. So an application developer can not rely on that the properties working well with one implementation will work with another. The presets interface tries to solve this by allowing the elements to define presets which can be named the same, but which has different properties changed for different elements. Lets look at an example preset (shipped presets are stored in /usr/share/gstreamer-0.10/presets, users own presets are stored under ~/.gstreamer-0.10/presets, if both exist, both are loaded and the user ones override the system wide ones). + +The most important part of this page is to define a dictionary for how to write these preset files. The current practice is to include the following elements if available. + +1. Official profiles. A lot of codecs have official profiles like Profile Baseline, Profile Main, Profile Extended as an example of some of the profiles defined for H264 as shown below. Codecs without any official profiles should not define such here. The names of these profiles are the same as the official names, with the first letter of each word capitalized. We do not use underscores or dashes in the profile names, whitespaces are fine. As you see here and with the Quality profiles below, we put the generic word first, cause it makes things a bit easier in terms of parsing for these values. + +2. Quality levels. We define 3 quality level profiles, Quality Low,Quality Normal and Quality High. All codecs should define this. Since it is a subjective value try to choose values for these presets you feel would match the existing ones or google for 'best practice' examples. These three profiles should only be named Low, Normal and High. + +3. Passes. If the codecs support multipass encoding the various passes should be defined here. These profiles should be named - Pass X - with X being replaced for each level of multipass encoding offered. + +4. Custom presets. We want to try to avoid these as far as possible, but in some cases we might not be able to get the output we need by combining the above profiles. In that case you are allowed to create a special profile to address that, like WeirdPhoneXYZ - which sets bitrate to the only allowed value for Weird phone XYZ for example. Such profiles should be submitted into bugzilla and have had some discussion before getting added though. + + +[[!format txt """ +[_presets_] +version=0.10 +element-name=GstX264Enc + +[Pass 1] +pass=pass1 + +[Pass 2] +pass=pass2 + +[Pass 3] +pass=pass3 + +[Profile Baseline] +_meta/comment=Baseline Profile +bframes=0 +cabac=false +dct8x8=false + +[Profile Main] +_meta/comment=Main Profile +cabac=true +dct8x8=false + +[Profile High] +_meta/comment=High Profile +cabac=true +dct8x8=true + +[Quality Low] +_meta/comment=Low quality +pass=qual +quantizer=27 +subme=4 +threads=0 + +[Quality Normal] +_meta/comment=Normal quality +pass=qual +quantizer=21 +me=umh +subme=6 +ref=3 +threads=0 + +[Quality High] +_meta/comment=High quality +pass=qual +quantizer=18 +me=umh +subme=6 +ref=3 +threads=0 +"""]] +There is also an [[AacPreset|AacPreset]] example to be looked at. + +This file, using the GKeyFile format lists a few attribute values for H264 encoding using x264enc.The important thing to remember is that we could create a 'Profile Baseline' for another H264 encoder also, and the application developer would know that no matter what encoder ended up being used on a specific users computer, by using the Profile Baseline preset she can know the output will be H.264 Baseline compliant. If a device needs more fine-grained options then a special preset can be made for it, and these devices should be listed somewhere publicly for new encoder developers. + +Be aware that presets stack, so we should make sure no preset crash with another one for a given codec as we can instead stack them to give us what we need. + +One of the hard problems which these profiles do not solve is of course the problem of creating optimal files versus files that 'work'. First of all what is optimal is of course subjective, but even so the tradeoffs you do with one encoder might not be reproducible with another, so you will get different results depending on different encoders. In these pages we will aim at creating presets which are known to work well for various devices based on what people already do out there, to make the presets work well on the devices in question. Creating presets which aim at producing close to identical output with different encoder implementations it outside of our scope. + +If an application encounters multiple encoders of the same type in a GStreamer application we recommend the following ordering of them: + +* with preset +* highest rank +* whatever is found +This means if only one encoder got the preset you are looking for you pick that. If more than one or none of the encoders got presets, then you sort on the GStreamer factory Rank value of the encoder. If more than one encoder got a preset and a rank or neither of those, then you just choose the first (by whatever ordering algorithm). The application developer can of course in the case where no presets exists, hardcode property values for a known encoder, but we recommend that in such situations, making a patch to add presets support to the element in question and adding the wanted preset file is the best long term solution. + +The python psuedo code below shows how to load this preset onto the x264enc element. The print statement below would simply return True if the preset exists. So in your code you just load the preset(s) you want onto the element(s) you want start your pipeline. To figure out which presets exist, looking at the files in /usr/share/gstreamer-0.10/presets is probably the easiest solution. +[[!format txt """ +element = gst.element_factory_make("x264enc") +dingdong = element.load_preset("Profile Baseline") +print dingdong +"""]]
\ No newline at end of file diff --git a/ReleasePlanning.mdwn b/ReleasePlanning.mdwn new file mode 100644 index 0000000..4ff2945 --- /dev/null +++ b/ReleasePlanning.mdwn @@ -0,0 +1,27 @@ + + +## Release Planning + + +### Upcoming Releases + +For information about upcoming GStreamer releases, see the [[2013 Release Schedule|ReleasePlanning2013]]. + +Information about the different types of [[Freezes|ReleasePlanning/Freezes]] (out of date). + +Information about the most likely [[version of GLib required|ReleasePlanning/GLibRequirement]] for upcoming releases. + +[[RoadMap|ReleasePlanning/RoadMap]] has some details about things people may work on. + + +### Historical Release Information + +For information about historical releases, see the older release planning pages: + +* [[2008 Release Schedule Part 1|ReleasePlanning2008-1]] +* [[2008 Release Schedule Part 2|ReleasePlanning2008]] +* [[2009 Release Schedule Jan-June|ReleasePlanning2009-1]] +* [[2009 Release Schedule July-Dec|ReleasePlanning2009-2]] +* [[2010 Release Schedule|ReleasePlanning2010]] +* [[2011 Release Schedule|ReleasePlanning2011]] +* [[2012 Release Schedule|ReleasePlanning2012]]
\ No newline at end of file diff --git a/ReleasePlanning/Freezes.mdwn b/ReleasePlanning/Freezes.mdwn new file mode 100644 index 0000000..c1865fa --- /dev/null +++ b/ReleasePlanning/Freezes.mdwn @@ -0,0 +1,21 @@ + + +# Release Freezes + +The release schedule should include dates for the following freezes. + +[[!toc ]] + +<a name="CodeFreeze"></a> +## Code Freeze + +The particular module is completely frozen for commits without prior approval from the person managing that release. + +To request a code freeze break, file a bug with attached patch and mark it blocker, then email or contact the release manager on IRC to ensure they're aware of the bug. + +<a name="DependencyFreeze"></a> +## Dependency Freeze + +Modules may only depend on released (or shortly to be released) versions of other GStreamer modules. For example, the dependency of Good Plugins may not be changed to require a CVS install of Core. + +Dependency freeze ensures that a module will stay releasable until it is time for it to be released. diff --git a/ReleasePlanning/GLibRequirement.mdwn b/ReleasePlanning/GLibRequirement.mdwn new file mode 100644 index 0000000..085cd42 --- /dev/null +++ b/ReleasePlanning/GLibRequirement.mdwn @@ -0,0 +1,85 @@ + + +# GLib Version Requirement + +GLib is GStreamer's main dependency. + +We want to make use of new GLib API over time (and benefit from bug fixes of course), but we also don't want to make life unnecessarily difficult for developers, users and system integrators who want to deploy a newer version of GStreamer than the one that is shipped with their distro/system by requiring a bleeding edge version of GLib. So a balance has to be struck. + +Keeping things predictable is likely to be valuable for system integrators and anyone else deploying GStreamer or GStreamer-based applications, and keeping things moving forward slowly but certainly without requiring endless discussions whenever someone wants to bump the requirement is likely to benefit developers. + +To this effect, the proposed (and, dare I say, generally accepted amongst developers) solution was something along these lines: + + +### The Policy + + * whenever we release core/base, we look into bumping the GLib requirement for core/base (ie. right *after* the core/base release, not for the release itself) + * we then look at all (stable) GLib 2.N.1 releases that are older than ~12 months, and pick the highest N. That's our new GLIB_REQ then. + * plugin modules should follow the GLib requirement of their core/base requirement (highest wins) or make plugins which require a newer version optional +This will roughly result in a schedule like this: + + +### Estimated GLib requirement of core/base versions + + +#### 1.0 + +* **1.0.0**, to be released around 23-Sep-2012: GLib 2.32 +* **1.0.x**, same as 1.0.0 +* **1.2.0**, to be released around Feb/March-2013: GLib 2.32 +* **1.2.x**, same as 1.2.0 +* **1.4.0**, to be released Q2-Q3 2013: 2.34 +* **1.4.x**, same as 1.4.0 + +#### 0.10 + +(this is based on the original proposal to check after each release; Mike suggested to only check after every second release, but that doesn't really seem to change that much in practice) + +* **0.10.23**, released around 20-Apr-2009: GLib 2.14 +* check glib req in Apr 2009 => 2.16 +* **0.10.24**, released around 04-Aug-2009: GLib 2.16 +* check glib req in Aug 2009 => 2.16 +* **0.10.25**, released around 02-Oct-2009: GLib 2.16 +* check glib req in October 2009 => 2.18 +* **0.10.26**, released around 10-Feb-2010: GLib 2.18 +* check glib req in February 2010 => 2.18 +* **0.10.27**, released around 05-Mar-2010: GLib 2.18 +* check glib req in March 2010 => 2.18 +* **0.10.28**, released around 09-Mar-2010: GLib 2.18 +* check glib req in March 2010 => 2.18 +* **0.10.29**, released around 28-Apr-2010: GLib 2.18 +* check glib req in April 2010 => 2.20 +* **0.10.30**, released around 16-Jul-2010: GLib 2.20 +* check glib req in July 2010 => 2.20 +* **0.10.31**, released around 30-Nov-2010: GLib 2.20 +* check glib req in November 2010 => 2.22 +* **0.10.32**, released around 21-Jan-2011: GLib 2.22 +* check glib req in January 2011 => 2.22 +* **0.10.33**, released around 10-May-2011: Glib 2.22 +* **0.10.34**, released around 13-May-2011: Glib 2.22 +* check glib req in May 2011 => 2.24 +* **0.10.35**, released around 15-Jun-2011: GLib 2.24 +* **0.10.36**, released around 20-Feb-2012: Glib 2.24 + +### GLib major versions release dates (for reference) + +[[(glib source directory on ftp.gnome.org)|http://ftp.gnome.org/pub/GNOME/sources/glib/]] + +* **2.12.1**: 22-Jul-2006 +* **2.14.1**: 16-Sep-2007 +* **2.16.1**: 11-Mar-2008 +* **2.18.1**: 18-Sep-2008 +* **2.20.1**: 10-Apr-2009 +* **2.22.1**: 30-Sep-2009 +* **2.24.1**: 03-May-2010 +* **2.26.1**: 14-Nov-2010 +* **2.28.1**: 18-Feb-2011 +* **2.30.1**: 14-Oct-2011 +* **2.32.1**: 14-Apr-2012 +* **2.34.1**: 16-Oct-2012 +* **2.36.1**: tbd. (ca. April 2013) + +### See Also + +* [[http://article.gmane.org/gmane.comp.video.gstreamer.devel/24023|http://article.gmane.org/gmane.comp.video.gstreamer.devel/24023]] and previous threads on the GLib requirement +* discussions and comments on IRC (not archived)
\ No newline at end of file diff --git a/ReleasePlanning/RoadMap.mdwn b/ReleasePlanning/RoadMap.mdwn new file mode 100644 index 0000000..5510617 --- /dev/null +++ b/ReleasePlanning/RoadMap.mdwn @@ -0,0 +1,50 @@ + + +## Road Map + +GStreamer doesn't operate feature-based road map planning of any kind. People work on what they feel like working on, what they have time to work on, and what happens to come up. + +This road map is simply an indication of what new features _might_ land in future versions. + +If you are a GStreamer developer, feel free to add items here that you intend or hope to work on. + + +### Schedule + +These are tentative at best, [[full schedule here|ReleasePlanning2013]]: + +* **2012-Sep**: 1.0.0 stable +* **2012-Dec**: 1.1.0 development +* **2013-Feb**: 1.2.0 stable +* **2013-Mar**: 1.3.0 development +* **2013-Apr**: 1.4.0 stable +* **2013-Jun**: 1.5.0 development +* **2013-Jul**: 1.6.0 stable + +### 1.2 + +* buffer pool drain for v4l2src renegotiation: [[bug #682770|https://bugzilla.gnome.org/show_bug.cgi?id=682770]] +* video/x-surface replacement and playbin re-enablement (probably not this cycle) +* hardware-accelerated video decoding (vdpau/vaapi) (probably not this cycle) +* integrate bluetooth elements from bluez-gstreamer and port them to 1.0: [[bug #690582|https://bugzilla.gnome.org/show_bug.cgi?id=690582]] +* GVariant registry (probably not this cycle) +* RFC6051 (Rapid Synchronisation of RTP Flows): [[http://www.ietf.org/rfc/rfc6051.txt|http://www.ietf.org/rfc/rfc6051.txt]] (probably not this cycle) +* Initial work for RTP retransmission (probably not this cycle) +* _fill me_ +* plugin moves: + * -<del>rtpmux from -bad to -good</del>- + * camerabin from -bad to -base (incl. basecamerabin library and photography interface) + * consolidate tag-related elements in a new -base/gst/tag/ plugin (id3mux from -bad, icydemux, ape*, id3*, etc.) + * -<del>move scaletempo from -bad to -good</del>- + * -<del>move VP8 RTP payloader/depayloader to -good</del>- + * move dtmf plugin from -bad to -good ([[bug #687416|https://bugzilla.gnome.org/show_bug.cgi?id=687416]]) +* [[Show all open bugs with target milestone 1.1.x|https://bugzilla.gnome.org/buglist.cgi?product=GStreamer&target_milestone=1.1.x]] +* [[Show all resolved bugs with target milestone 1.1.x|https://bugzilla.gnome.org/buglist.cgi?product=GStreamer&target_milestone=1.1.x&target_milestone=1.1.1&target_milestone=1.1.2&target_milestone=1.1.3&target_milestone=1.1.4&target_milestone=1.1.5&target_milestone=1.1.6&target_milestone=1.1.7&target_milestone=1.1.8&target_milestone=1.1.9&bug_status=RESOLVED]] + +### 1.4 + +* device discovery and probing, [[GstPropertyProbe|GstPropertyProbe]] replacement: [[bug #678402|https://bugzilla.gnome.org/show_bug.cgi?id=678402]] +* gst-plugins-bad split ? +* _fill me_ +* [[Show all open bugs with target milestone 1.3.x|https://bugzilla.gnome.org/buglist.cgi?product=GStreamer&target_milestone=1.3.x]] +* [[Show all resolved bugs with target milestone 1.3.x|https://bugzilla.gnome.org/buglist.cgi?product=GStreamer&target_milestone=1.3.x&target_milestone=1.3.1&target_milestone=1.3.2&target_milestone=1.3.3&target_milestone=1.3.4&target_milestone=1.3.5&target_milestone=1.3.6&target_milestone=1.3.7&target_milestone=1.3.8&target_milestone=1.3.9&bug_status=RESOLVED]]
\ No newline at end of file diff --git a/ReleasePlanning2008-1.mdwn b/ReleasePlanning2008-1.mdwn new file mode 100644 index 0000000..1afd990 --- /dev/null +++ b/ReleasePlanning2008-1.mdwn @@ -0,0 +1,65 @@ + + +# GStreamer release schedule for Jan-June 2008 + +In the past, GStreamer releases have been a bit haphazard, with a tendency for some modules to go a long time without seeing a release. The goal of this schedule is to provide regular releases of all modules and to help people plan their development more easily by knowing in advance when releases are going to occur. + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer OpenGL support - doesn't exist yet :) +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + +The cycle starts with of out-of-pattern releases of Core/Base/Python and then Good/Bad/Ugly together because all modules urgently need releases. After that, it should be possible to follow a regular pattern of Core/Base/Python then Good/Bad then Ugly/FFmpeg. The Ugly/FFmpeg release might include a second Bad release if needed due to plugin moves. See the [[Plugin Moves|ReleasePlanning2008-1]] section. + + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing, since it includes so many codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. + + +### TODO + +* Add notes for KDE release/freeze schedules? +* Extend the release schedule later, to cover the rest of the year.
\ No newline at end of file diff --git a/ReleasePlanning2008.mdwn b/ReleasePlanning2008.mdwn new file mode 100644 index 0000000..49d9705 --- /dev/null +++ b/ReleasePlanning2008.mdwn @@ -0,0 +1,85 @@ + + +# GStreamer release schedule for 2008 July - Dec + +Release schedule for the 2nd half of 2008. See [[ReleasePlanning2008-1|ReleasePlanning2008-1]] for the first half. + + +## Summary Schedule + +This is the quick summary of the releases for the next 6 months. See below for the full schedule +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + Jul 14 | **Good/Bad freeze. 4 day plugin window opens** + Jul 28 | Good 0.10.9, Bad 0.10.8 release + Aug 8 | **Ugly/FFmpeg/Bad freeze. 4 day plugin window opens** + Aug 22 | Ugly 0.10.9, FFmpeg 0.10.5, Bad 0.10.9 (if needed) release + Sep 9 | **Core/Base/Python freeze.** + Sep 22 | Core 0.10.21, Base 0.10.21, Python 0.10.13 release + Oct 6 | **Good/Bad freeze. 4 day plugin window opens** + Oct 20 | Good 0.10.10, Bad 0.10.10 release + Nov 3 | **Ugly/FFmpeg/Bad freeze. 4 day plugin window opens** + Nov 17 | Ugly 0.10.10, FFmpeg 0.10.6, Bad 0.10.11 (if needed) release +"""]] + + +## Process + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer OpenGL support - doesn't exist yet :) +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + +The cycle starts with of out-of-pattern releases of Core/Base/Python and then Good/Bad/Ugly together because all modules urgently need releases. After that, it should be possible to follow a regular pattern of Core/Base/Python then Good/Bad then Ugly/FFmpeg. The Ugly/FFmpeg release might include a second Bad release if needed due to plugin moves. See the [[Plugin Moves|ReleasePlanning2008]] section. + + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing, since it includes so many codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. + + +### TODO + +* Add notes for KDE release/freeze schedules?
\ No newline at end of file diff --git a/ReleasePlanning2009-1.mdwn b/ReleasePlanning2009-1.mdwn new file mode 100644 index 0000000..cca51fb --- /dev/null +++ b/ReleasePlanning2009-1.mdwn @@ -0,0 +1,80 @@ + + +# GStreamer release schedule for Jan-June 2009 + +Release schedule for the 1st half of 2009. + + +## Summary Schedule + +This is the quick summary of the releases for the 6 months January 2009 - June 2009. See below for the full schedule +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + Jan 5 | **Core/Base/Python/Bad freeze.** + Jan 19 | Core 0.10.22, Base 0.10.22, Python 0.10.14 Bad 0.10.10 release + Feb 2 | **Good/Bad freeze. 4 day plugin window opens** + Feb 16 | Good 0.10.12 release (no Bad release this time, since it was released recently and there were no plugin moves) + Mar 2 | **Ugly/FFmpeg/Bad freeze. 4 day plugin window opens** + Mar 16 | Ugly 0.10.11, FFmpeg 0.10.7, Bad 0.10.11 (if needed) release + Apr 6 | **Core/Base/Python freeze.** + Apr 20 | Core 0.10.23, Base 0.10.23, Python 0.10.15 release + May 2 | **Good/Bad freeze. 4 day plugin window opens** + May 18 | Good 0.10.13, Bad 0.10.12 release + Jun 1 | **Ugly/FFmpeg/Bad freeze. 4 day plugin window opens** + June 15 | Ugly 0.10.12, FFmpeg 0.10.8, Bad 0.10.13 (if needed) release +"""]] + + +## Process + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer OpenGL support - doesn't exist yet :) +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing due to the quantity of codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. diff --git a/ReleasePlanning2009-2.mdwn b/ReleasePlanning2009-2.mdwn new file mode 100644 index 0000000..c4b7669 --- /dev/null +++ b/ReleasePlanning2009-2.mdwn @@ -0,0 +1,84 @@ + + +# GStreamer release schedule for Jul-Dec 2009 + +Release schedule for the 2nd half of 2009. + + +## Summary Schedule + +This is the quick summary of the releases for the 6 months June 2009 - December 2009. See below for the full schedule +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + Jul 14 | **Core/Base/Python freeze.** + Jul 30 | Core 0.10.24, Base 0.10.24, Python 0.10.16 + Aug 3 | 4 day Good <-> Bad plugin move window opens + Aug 7 | **Good/Bad freeze** + Aug 17 | Good 0.10.16 release (Bad 0.10.15 maybe) + Sep 11 | **Core/Base/Python/FFmpeg freeze** + Sep 25 | Core 0.10.25, Base 0.10.25, Python 0.10.17, FFmpeg 0.10.9 release + Oct 5 | 4 day Ugly <-> Bad plugin move window opens + Oct 9 | **Ugly/Bad freeze. 4 day plugin move window closes** + Oct 19 | Ugly 0.10.13, Bad 0.10.16 (if needed) release + Nov 2 | 4 day Good <-> Bad plugin move window opens + Nov 6 | **Good/Bad freeze. 4 day plugin window closes** + Nov 16 | Good 0.10.17, Bad 0.10.17 release + Dec 7 | 4 day Ugly <-> Bad plugin move window opens + Dec 11 | **Ugly/FFmpeg/Bad freeze. 4 day plugin move window closes** + Dec 21 | Ugly 0.10.14, FFmpeg 0.10.10, Bad 0.10.18 (if needed) release +"""]] + + +## Process + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer OpenGL support - doesn't exist yet :) +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing due to the quantity of codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. diff --git a/ReleasePlanning2010.mdwn b/ReleasePlanning2010.mdwn new file mode 100644 index 0000000..aa93cc6 --- /dev/null +++ b/ReleasePlanning2010.mdwn @@ -0,0 +1,105 @@ + + +# GStreamer release schedule for 2010 + +Proposed release schedule / roadmap for the year 2010. + + +## Summary Schedule + +This is a tentative schedule for releases for the first few months of 2010: +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + Jan 18 | **Core/Base/Good freeze** + Feb 1 | Ugly <-> Bad plugin move window opens + Feb 8 | **Core 0.10.26, Base 0.10.26, Good 0.10.18 release** + Feb 8 | **Ugly/Bad/ffmpeg freeze, Core/Base/Good still frozen** + Feb 9 | Good <-> Ugly and Good <-> Bad plugin move window opens + Feb 10 | Base <-> Bad plugin move window opens + Feb 10 | **Core/Base/Good/Ugly/Bad/ffmpeg still frozen** + Mar 5 | **Core 0.10.27, Base 0.10.27, Good 0.10.19, Ugly 0.10.14, Bad 0.10.18, gst-ffmpeg 0.10.10 release** + Mar 9 | **Core 0.10.28, Base 0.10.28, Good 0.10.21 release** + Mar 9 | **Core/Base/Good/Ugly/Bad/ffmpeg thaw** + ... | ... + Apr 9 | **Core/Base/Good freeze** + Apr 28 | **Core 0.10.29, Base 0.10.29, Good 0.10.22 release** + Apr 29 | **Core/Base/Good thaw** + ... | ... + May 7 | **Good/Ugly/Bad freeze** + May 31 | **Good 0.10.23, Ugly 0.10.15, Bad 0.10.19 release** + Jun 1 | **Good/Ugly/Bad thaw** + ... | ... + Jun 20 | **Core/Base/Good/gst-ffmpeg/gst-python freeze** + Jul 15 | **Core 0.10.30, Base 0.10.30, Good 0.10.24, gst-ffmpeg 0.10.11, gst-python 0.10.19 release** + Jul 16 | **Core/Base/Good/gst-ffmpeg/gst-python thaw** + ... | ... + Aug 09 | **Good/Ugly/Bad/-gl freeze** + Sep 02 | **Good 0.10.25, Ugly 0.10.16, Bad 0.10.20, plugins-gl 0.10.2 release** + Sep 03 | **Good/Ugly/Bad thaw** + Sep 04 | **gst-plugins-gl 0.10.2 release** + Sep 05 | **gst-plugins-gl thaw** + ... | ... + Oct 15 | **Core/Base/Good/python freeze** + Dec 1 | **Core 0.10.31, Base 0.10.31, Good 0.10.26, gst-python 0.10.20 release** + Dec 2 | **Core/Base/Good/python thaw** + ... | ... + ~Dec 31 | **Core/Base/Good/Ugly/Bad freeze** + ... | continued on [[ReleasePlanning2011|ReleasePlanning2011]] page... +"""]] + +gst-ffmpeg, gst-python, and gnonlin releases may be done in any of these cycles as well. + + +## Process (not entirely up-to-date) + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer OpenGL support - doesn't exist yet :) +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing due to the quantity of codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. diff --git a/ReleasePlanning2011.mdwn b/ReleasePlanning2011.mdwn new file mode 100644 index 0000000..efe277e --- /dev/null +++ b/ReleasePlanning2011.mdwn @@ -0,0 +1,92 @@ + + +# GStreamer release schedule for 2011 + +Proposed release schedule / roadmap for the year 2011. + + +## Summary Schedule + +This is a tentative schedule for releases for the first few months of 2011: +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + ... | ... + Jan 5 | **Core/Base/Good/Ugly/Bad/python/gnonlin freeze** + ~Jan 20 | **Core 0.10.32, Base 0.10.32, Good 0.10.27, Ugly 0.10.17, Bad 0.10.21, gst-python 0.10.21, gnonlin 0.10.16 release** + ~Jan 21 | **Core/Base/Good/Ugly/Bad/python/gnonlin thaw** + ... | ... + Mar 8 | **Good 0.10.28 release** (one patch ad-hoc release to fix build issue) + ... | ... + Apr 14 | **Core/Base/Good/Ugly/Bad freeze** + May 10 | **Core 0.10.33, Base 0.10.33, Good 0.10.29, Ugly 0.10.18, Bad 0.10.22 release** + May 13 | **Core 0.10.34, Base 0.10.34 release** (to fix critical multiqueue regression) + May 14 | **Core/Base/Good/Ugly/Bad thaw** + ... | ... + June 15 | **Core 0.10.35, Base 0.10.35, Good 0.10.30 release** (to handle GLib 2.29.x atomic ops API change) + ... | ... + July 6 | **Core/Base 0.11.0 release** (unstable development series) + ... | ... + December 11 | stable Core/Base/Good/Ugly/Bad 0.10.x pre-releases + end-December / early-January | **Core 0.10.36, Base 0.10.36, Good 0.10.31, Ugly 0.10.19, Bad 0.10.23 stable releases** +"""]] + +gst-ffmpeg, gst-python, and gnonlin releases may be done in any of these cycles as well. + + +## Process (not entirely up-to-date) + +At the moment there are 7 GStreamer modules included in the schedule: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer FFmpeg +* GStreamer Python Bindings +Each module will see a release every 3 months. For an explanation of the freezes please see [[here|ReleasePlanning/Freezes]]. + +Modules not included: + +* Gnonlin - released by Edward Hervey as he sees fit +* GStreamer Editing Services - released when maintainer sees fit +* GStreamer openmax - released when maintainer sees fit +* GStreamer OpenGL support - released when maintainer sees fit +* GStreamer RTSP server - released when maintainer sees fit +* QT-GStreamer - released when maintainer sees fit + +## Release procedure for Core/Base/Python + +The release procedure is to freeze the modules, and then make a series of pre-release tarballs. 2 weeks later, the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found, and we can all go to the pub. + +The modules thaw the day after the final release, just in case a paper bag release is needed. + +* Day 0: Code Freeze Core/Base/Python. Make first pre-release tarballs +* Day 3: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 7: Make 3rd pre-releases if any new blocker bugs have been identified and fixed. +* Day 14: Release new version. Good/Bad/Ugly/FFmpeg are now dependency frozen. +* Day 15: Code thaw for Core/Base/Python. + +## Release procedure for plugin modules + +Plugin module releases begin with a plugin move window (4 days), then freeze and pre-releases begin. 2 weeks later the final release is done. At the discretion of the release manager, this may happen after only one week if no bugs are found. + +Code & dependency freezes end the day after the final release. + +* Day 0: Plugin move window opens. Commits should be done with care. +* Day 4: Plugin move window closes. First pre-releases made. Modules are frozen for commits. +* Day 9: Make 2nd pre-releases if any blocker bugs have been identified and fixed. +* Day 14: Release new versions +* Day 15: Code and dependency thaw for the newly released modules. +Additionally, when Good/Bad are released (together), the Bad module is branched so that later a 2nd option 'plugin moves' release of Bad can be done simultaneously with Ugly _if needed_ + +We may vary the schedule to skip an FFmpeg release from time to time if it seems that nothing exciting has been changed, since releases of FFmpeg require a lot of testing due to the quantity of codecs. + +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +To support this, the schedule provides plugin move windows during which plugins can be moved. Further, after the Good/Bad release, the Bad module will be branched. If during the next Ugly/FFmpeg release phase plugin moves happen between the Bad & Ugly modules, a 2nd release of the Bad plugins will occur from the branch **with the only changes being the removal or addition of plugins from the Ugly module**. diff --git a/ReleasePlanning2012.mdwn b/ReleasePlanning2012.mdwn new file mode 100644 index 0000000..94ba29f --- /dev/null +++ b/ReleasePlanning2012.mdwn @@ -0,0 +1,106 @@ + + +# GStreamer release schedule for 2012 + +Proposed release schedule / roadmap for the year 2012. + + +## Road Map + +see [[ReleasePlanning/RoadMap|ReleasePlanning/RoadMap]] + + +## Summary Schedule + +This is a tentative schedule for releases for the remainder of 2012: +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + ... | ... + Feb 20 | **Core 0.10.36, Base 0.10.36, Good 0.10.31, Ugly 0.10.19, Bad 0.10.23 stable releases** + ... | ... + Aug 08 | **Core/Base/Good/Ugly/Bad/gst-libav 0.11.93 release** + ... | ... + ~Sep 12 | **Core/Base/Good/Ugly/Bad/gst-libav 0.11.94 release** ? + ... | ... + Sep 17 | **Core/Base/Good/Ugly/Bad/gst-libav 0.11.99 release (1.0 release candidate)** + Sep 17 | git master frozen for release, important bug fixes only + Sep 24 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.0** release off git master + Sep 24 | git master still frozen, bug fixes only + ... | ... + Oct 07 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.1** bug-fix release off git master + Oct 07 | git master open for commits again, bug fixes only + ... | ... + Oct 25 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.2** bug-fix release off git master + ... | ... + Oct 25 | **git 1.0 branch created** for further 1.0.x bug-fixing + Oct 25 | **git master becomes 1.1.x**, open for new development and bug-fixing + ... | ... + ~Nov 18 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.3** bug-fix release off 1.0 branch + ... | ... + ~Dec 02 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.4** bug-fix release off 1.0 branch + ... | ... + ~Jan 04 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.5** bug-fix release off 1.0 branch + ... | ... + ~January | **Core/Base/Good/Ugly/Bad/gst-libav 1.1.1** development release off git master + ... | ... + ~January/February | **Core/Base/Good/Ugly/Bad/gst-libav 1.2.0** stable release off git master +"""]] + +gst-libav, gst-python, gnonlin and gst-editing-services releases may be done ad-hoc or in any of these cycles as well. + + +## New Versioning Scheme + +All 1.x.y versions will carry a -1.0 API version suffix. + +* 1.0.0, 1.0.1, 1.0.2, 1.0.3... stable release and follow-up bug-fix releases +* 1.1.0, 1.1.1, 1.1.2, 1.1.3... pre-releases, development version leading up to 1.2.0 +* 1.2.0, 1.2.1, 1.2.2, 1.2.3... stable release and follow-up bug-fix releases +* 1.3.0, .. +* 1.4.0, .. +* ... +2.0.0 would be the next ABI break, with "-2.0" as API version suffix (the unstable development versions leading up to it would be 1.99.x with a -1.99 API suffix). + + +## More frequent bug-fix releases + +1.x.1, 1.x.2, 1.x.3 etc. are stable follow-up bug-fix releases for the stable 1.x.0 release, for even values of x (0, 2, 4, 6..). + +Bug-fix releases may be made from git master or from a 1.x bug-fix branch into which fixes are cherry-picked from git master. + +Bug-fix releases will usually not feature new API (at best minor additions like a new utility function or property). + +There will be no plugin moves, renaming or plugin merges within a stable bug-fix series. + +There will be no upping of version requirements of libraries we depend on (e.g. GLib or libraries plugins depend on) within a stable bug-fix series. + + +## Process (not entirely up-to-date) + +At the moment there are six GStreamer modules included in the schedule, which are regularly released: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer Libav Plugins (formerly GStreamer FFmpeg) +Each module will see a major stable release (a new 1.x.0 for even x) every few months. Each major stable release will see a few follow-up 1.x.y bug-fix releases. + +Modules not included in the release schedule: + +* Gnonlin - released ad-hoc as maintainer sees fit +* GStreamer Editing Services (GES) - released ad-hoc as maintainer sees fit +* GStreamer Openmax (gst-omx) - released ad-hoc as maintainer sees fit +* GStreamer OpenGL support - released ad-hoc as maintainer and/or active developers see fit +* GStreamer RTSP server library - released ad-hoc as maintainer sees fit +* GStreamer Streaming Server (GSS) - released ad-hoc as maintainer sees fit +* QT-GStreamer - released ad-hoc as maintainer sees fit +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +Plugin moves will only happen during a development series (1.1.x, 1.3.x, etc.) in git master, leading up to a new major stable release (1.2.0, 1.4.0, 1.6.0). No plugin moves will happen within a bug-fix release series. diff --git a/ReleasePlanning2013.mdwn b/ReleasePlanning2013.mdwn new file mode 100644 index 0000000..45606e6 --- /dev/null +++ b/ReleasePlanning2013.mdwn @@ -0,0 +1,105 @@ + + +# GStreamer release schedule for 2013 + +Proposed release schedule / roadmap for the year 2013. + + +## Road Map + +see [[ReleasePlanning/RoadMap|ReleasePlanning/RoadMap]] + + +## Summary Schedule + +This is a tentative schedule for releases for 2013: +[[!table header="no" class="mointable" data=""" + **Date** | **Task** + ~Jan 04 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.5** bug-fix release off 1.0 branch + ~January | **Core/Base/Good/Ugly/Bad/gst-libav 1.1.1** development release off git master + ~Jan 20 | **Core/Base/Good/Ugly/Bad/gst-libav 1.0.6** bug-fix release off 1.0 branch + ~January | **Core/Base/Good/Ugly/Bad/gst-libav 1.1.x** development releases off git master + ~February | **Core/Base/Good/Ugly/Bad/gst-libav 1.2.0** stable release off git master + ~February | git master open for bug-fix commits only + ~Feb/March | **Core/Base/Good/Ugly/Bad/gst-libav 1.2.x** bug-fix releases off git master + ~March | **git 1.2 branch created** for further 1.2.x bug-fixing + ~March | **git master becomes 1.3.x**, open for new feature development, bigger changes and bug-fixing + ~March/April | **Core/Base/Good/Ugly/Bad/gst-libav 1.2.x** bug-fix releases off 1.2 branch + ~April/May | **Core/Base/Good/Ugly/Bad/gst-libav 1.3.x** development releases off git master + ~May | **Core/Base/Good/Ugly/Bad/gst-libav 1.4.0** stable release off git master + ~May | git master open for bug-fix commits only + ~May/June | **Core/Base/Good/Ugly/Bad/gst-libav 1.4.x** bug-fix releases off git master + ~June | **git 1.4 branch created** for further 1.4.x bug-fixing + ~June | **git master becomes 1.5.x**, open for new feature development, bigger changes and bug-fixing + ~June/July | **Core/Base/Good/Ugly/Bad/gst-libav 1.4.x** bug-fix releases off 1.4 branch + ~July/Aug | **Core/Base/Good/Ugly/Bad/gst-libav 1.5.x** development releases off git master + ~August | **Core/Base/Good/Ugly/Bad/gst-libav 1.6.0** stable release off git master + ~August | git master open for bug-fix commits only + ~Aug/Sept | **Core/Base/Good/Ugly/Bad/gst-libav 1.6.x** bug-fix releases off git master + ~Sept | **git 1.6 branch created** for further 1.6.x bug-fixing + ~Sept | **git master becomes 1.7.x**, open for new feature development, bigger changes and bug-fixing + ~Sept/Oct | **Core/Base/Good/Ugly/Bad/gst-libav 1.6.x** bug-fix releases off 1.6 branch + ~Oct/Nov | **Core/Base/Good/Ugly/Bad/gst-libav 1.7.x** development releases off git master + ~Dec | **Core/Base/Good/Ugly/Bad/gst-libav 1.8.0** stable release off git master + ~Dec | git master open for bug-fix commits only + ~Dec | **Core/Base/Good/Ugly/Bad/gst-libav 1.8.x** bug-fix releases off git master +"""]] + +gst-libav, gst-python, gnonlin and gst-editing-services releases may be done ad-hoc or in any of these cycles as well. + + +## New Versioning Scheme + +All 1.x.y versions will carry a -1.0 API version suffix. + +* 1.0.0, 1.0.1, 1.0.2, 1.0.3... stable release and follow-up bug-fix releases +* 1.1.0, 1.1.1, 1.1.2, 1.1.3... pre-releases, development version leading up to 1.2.0 +* 1.2.0, 1.2.1, 1.2.2, 1.2.3... stable release and follow-up bug-fix releases +* 1.3.0, .. +* 1.4.0, .. +* ... +2.0.0 would be the next ABI break, with "-2.0" as API version suffix (the unstable development versions leading up to it would be 1.99.x with a -1.99 API suffix), which would be parallel-installable with 1.0 of course. There are currently no plans for a 2.0 version. + + +## More frequent bug-fix releases + +1.x.1, 1.x.2, 1.x.3 etc. are stable follow-up bug-fix releases for the stable 1.x.0 release, for even values of x (0, 2, 4, 6..). + +Bug-fix releases may be made from git master or from a 1.x bug-fix branch into which fixes are cherry-picked from git master. + +Bug-fix releases will usually not feature new API (at best minor additions like a new utility function or property). + +There will be no plugin moves, renaming or plugin merges within a stable bug-fix series. + +There will be no upping of version requirements of libraries we depend on (e.g. GLib or libraries plugins depend on) within a stable bug-fix series. + + +## Process (not entirely up-to-date) + +At the moment there are six GStreamer modules included in the schedule, which are regularly released: + +* GStreamer Core +* GStreamer Base Plugins +* GStreamer Good Plugins +* GStreamer Bad Plugins +* GStreamer Ugly Plugins +* GStreamer Libav Plugins (formerly GStreamer FFmpeg) +Each module will see a major stable release (a new 1.x.0 for even x) every few months. Each major stable release will see a few follow-up 1.x.y bug-fix releases. + +Modules not included in the release schedule: + +* Gnonlin - released ad-hoc as maintainer sees fit +* GStreamer Editing Services (GES) - released ad-hoc as maintainer sees fit +* GStreamer Openmax (gst-omx) - released ad-hoc as maintainer sees fit +* GStreamer OpenGL support - released ad-hoc as maintainer and/or active developers see fit +* GStreamer RTSP server library - released ad-hoc as maintainer sees fit +* GStreamer Streaming Server (GSS) - released ad-hoc as maintainer sees fit +* QT-GStreamer - released ad-hoc as maintainer sees fit +<a name="PluginMoves"></a> + + +## Plugin Moves + +From time to time, plugins improve in quality sufficiently to warrant moving them from Bad to Good or Bad to Ugly (or sometimes vice versa in cases of neglect). Such plugin moves require simultaneous releases of the modules involved so that we never ship tarballs with conflicting installed plugins. + +Plugin moves will only happen during a development series (1.1.x, 1.3.x, etc.) in git master, leading up to a new major stable release (1.2.0, 1.4.0, 1.6.0). No plugin moves will happen within a bug-fix release series. diff --git a/SampleBin.mdwn b/SampleBin.mdwn new file mode 100644 index 0000000..13c2a17 --- /dev/null +++ b/SampleBin.mdwn @@ -0,0 +1,83 @@ + + +# SampleBin + +Event sounds and games need a convinience api to trigger short sound snippets. + + +## Concepts + + +### Caching + +Event sounds and in-game sounds are usually relaive short audio clips (<2sec). Having them predecoded would allow to trigger them more or less immediately. We could do that by getting a filedescriptor from fileno(tmpfile()) / mkstemp("...XXXXXX") and using that with: +[[!format txt """ +gnomevfssrc ! decodebin ! capsfilter ! fdsink sync=false +"""]] +When playing, we would use: +[[!format txt """ +fdsrc ! capsfilter ! volume ! audiopanorama ! adder +"""]] +For uncached sounds we can use: +[[!format txt """ +gnomevfssrc ! decodebin ! volume ! audiopanorama ! adder +"""]] +When doing the cache on demand, we can do: +[[!format txt """ +gnomevfssrc ! decodebin ! tee name=t ! queue ! capsfilter ! fdsink sync=false +t. queue ! volume ! audiopanorama ! adder +"""]] +Each pipeline-fragment should be implemented as a bin. + + +### Mixing + +Mixing is done with the adder. It will have one static conection - the background music or silence. This keeps the stream continous. + +When setting up the mixer we need to setup n playback subpipelines. We check if there are samples for each caching mode. Then we create n pipelines of each type (voice slots), if there are samples of that type (We need to create caching ones if there are cache after use ones). For each subpipeline we add a event-probe to the src pad of the audiopanorama (the proxy-pad of the bin in fact). This will check for eos in that bin and once it gets eos blocks the pad and marks the bin as free. + +When playing a sound, we need to check for a free voice slot. If we found none, we could: * kill the one that is finished next * kill the one that is the most silent * fail * ... + +For good performance we should add gap handling to the adder. + + +## API + + +[[!format txt """ +gchar* !GstSampleBin::background-music-uri, rw, default=NULL +// Set an uri to a media file that will be played in a loop. If %NULL silence is used. + +gdouble !GstSampleBin::background-music-volume, rw, default=1.0 +// Volume level for background music, unused if there is no background music + + +typedef enum { + GST_SAMPLE_BIN_CACHE_NEVER, + GST_SAMPLE_BIN_CACHE_ALWAYS, + GST_SAMPLE_BIN_CACHE_AFTER_USE +} !GstSampleBinCacheMode; + +glong gst_sample_bin_add_sound(!GstsampleBin *sbin,const gchar *uri, !GstSampleBinCacheMode cache_mode); +// Set a sound sample clip and eventually preload. Returns a clip-id. + +glong gst_sample_bin_remove_sound(!GstsampleBin *sbin, glong clip_id); +// Remove a sound-clip. All clips are removed when destroying. + +gst_sample_bin_play_sound(!GstsampleBin *sbin, glong clip_id, gdouble volume, gdouble pan); +// Play the sound clip with the given volume and panorama position. +"""]] + +# Comments + +* can we consider mixing as a separate functionnality? +* background could be considered as a regular sample +* a sample as a (mini)object, shareable in different contexts (refcount), and with attached (dynamic?) properties (vol,pan?,loop,name..) +* add and remove as part of ref/unref and internal sample/memory management +* playsound as a method of a sample object, with more state control?: start/stop (as props?) +-- [[MarcAndreLureau|MarcAndreLureau]] 2008-02-12 08:47:20 + +* why mixing as a separate components? it will use adder +* the rationale for background is, that we need something to keep adder running, and background would automatically loop on eos (segmented seek) +* I want volume and panorama be parameters of play action. then e.g. you can play the same sound at different volumes or pan-positions +-- [[StefanKost|StefanKost]] 2008-02-12 09:20:43 diff --git a/SocManagement.mdwn b/SocManagement.mdwn new file mode 100644 index 0000000..e967284 --- /dev/null +++ b/SocManagement.mdwn @@ -0,0 +1,13 @@ + + +# Running of GStreamer GSOC 2012 + +== Key people =1 + +* Christian Schaller - Will maintain and develop these pages and ensure we actually apply for GSOC 2012 +* [[StefanKost|StefanKost]] - Writing the application and mentor students + +## Key Tasks + +* Apply for GSOC 2012 +Back to [[TaskList|TaskList]] diff --git a/SocProjects.mdwn b/SocProjects.mdwn new file mode 100644 index 0000000..583937a --- /dev/null +++ b/SocProjects.mdwn @@ -0,0 +1,46 @@ + +The list below is just some suggestions made by various members of the GStreamer community. We are more than happy for students to make proposals based on their own wishes and ideas instead of using any of these suggestions. The important part for us is that you are motivated and that you put good work into writing a good and detailed proposal and that you try to interact with us from the start. Try to early find a possible mentor and shape your proposal (e.g. using Google docs). When writing the proposal, be sure to describe what you will deliver, how this is useful and include a rough timeline how you plan to get there. Please include useful references (links to projects you worked on in the past, online references for code you wrote (create an account on [[ohloh|http://ohloh.net]] and add your contributions), links to specifications you want to implement, ...) - anything that helps to understand your proposal is well researched and you suited to achieve the goals by the end of the summer. + +If you do that then any kind of project you can think of using GStreamer has a good chance of being selected. + + +# List of Summer of Code project ideas for students + +* plugins + * [[WebP|WebP]] : Project to create a decoder and encoder for WebP image format + * [[PluginsForEditing|PluginsForEditing]]: Wrapping much-needed audio/video filters as gstreamer plugins. + * [[SrtpSupport|SrtpSupport]]: Write plugins to support sRTP (and maybe zRTP) + * [[ChapterSupport|ChapterSupport]]: Implement chapter support in more plugins + * [[OpencvGestureDetection|OpencvGestureDetection]] : Implement an opencv plugin for gesture detection (eg: hand gesture) + * [[Moovit|Moovit]]: Implement a wrapper plugin for the Moovit GPU accelerated library +* applications + * [[Pitivi|Pitivi]]: Improve Pitivi + * [[Buzztard|Buzztard]]: Improve Buzztard +* framework + * [[Closed_Captioning_support|Closed_Captioning_support]]: Subtitles for the hearing impaired + * [[Multichannel_grabber_card_support|TamasKorodi/IVC_multichannel_grabber_card_support]] : Multichannel video grabber card support and more baseclasses + * [[GeneratedFormatTestdata|GeneratedFormatTestdata]]: Generate robustness testdata for demuxer/parser tests +* bindings + * [[Gstreamer-Lua|SocProjects/GStreamerLua]] : Gstreamer Lua binding enhancement + * [[Gstreamer-Java enhancement|RobinHorvath/Gstreamer-java_enhancement]] : GStreamer Java binding enhancement, GStreamer and GStreamer-Java Mac OS and Windows port + * [[gstreamer-sharp|GStreamerSharp]] : Finish/improve the GStreamer C# bindings + * Port GStreamer applications and/or plugins from 0.10 to 0.11/1.0 + * [[Automatic low-level Java binding generation|RolandElek/AutomaticLowLevelJavaBindingGeneration]] : Automatically generate the low-level layer of gstreamer-java +We have a [[list of previous projects|PreviousSocProjets]] for reference. + + +# Other Organizations + +Other organizations that have project ideas related to GStreamer: + +* [[http://live.gnome.org/SummerOfCode2012/Ideas|http://live.gnome.org/SummerOfCode2012/Ideas]] +* [[http://community.kde.org/GSoC/2012/Ideas|http://community.kde.org/GSoC/2012/Ideas]] +Back to [[TaskList|TaskList]] + + + +--- + + + +* [[CategoryGSOC2012|CategoryGSOC2012]]
\ No newline at end of file diff --git a/StudentInfo.mdwn b/StudentInfo.mdwn new file mode 100644 index 0000000..4c2a962 --- /dev/null +++ b/StudentInfo.mdwn @@ -0,0 +1,43 @@ + + +# How to write the Application + +Once the students applications period has opened, you have to submit your application on Google's Summer of Code website. Your application must be written in English. It should contain a detailed description of your project proposal. There are some ideas on this wiki for various projects, but be aware that it is perfectly fine for you to propose a project of your own instead. The important part is to start talking with people in the GStreamer community about it as soon as possible and get some feedback. Once you write your proposal you should consider answering questions such as: + + * What is its ultimate goal? + * What components will it have? + * What benefits does it have for GStreamer and its community? + * Why you'd like to complete this particular project? + * How do you plan to achieve completion of your project? + * Why do you think you are be the best person to work on this project? + * What are your past experiences (if any) with the open source world? + * Why are you interested in improving GStreamer or GStreamer related applications? + * Make sure to make a timeline of your project, with milestones and clear deliverables for these milestones +Don't just answer these questions, use your imagination and try to be clear. Don't forget to show enthusiasm. Please try to use correct English if possible. The selection committee understands that not all applicants speak English as their first language. In fact, many GStreamer community members speak English as their second or third language! + + +# Discussing your ideas or projects + +The best place to get feedback on new ideas before you propose them or discuss existing ideas from the wiki is the GStreamer IRC channel. You find that on irc.freenode.com in #gstreamer. + +You can also contact the GStreamer development mailing list which you find here: [[https://lists.sourceforge.net/lists/listinfo/gstreamer-devel|https://lists.sourceforge.net/lists/listinfo/gstreamer-devel]] + +Choose your project with care! If you don't have a clear vision and goal for a project don't choose something which isn't very strictly specified. For instance writing a plugin to support a specific format is a good task if you just want to do *something*, as the task is very clearly defined and specified. On the other hand taking on the task of writing for example an 'easy to use video player' is a bad idea unless you yourself have a strong vision for what that entails. If your project ends up stalling because you have no idea for which direction to take it, there is a very real chance we will fail you and you don't get paid. + + +# How to file the application + +Google got a page with instructions on how you as a student file the application here: [[http://www.google-melange.com/gsoc/dashboard/google/gsoc2012|http://www.google-melange.com/gsoc/dashboard/google/gsoc2012]] + + +# Before GSoC starts + +To be ready to go if we're chosen to participate, you can read the [[documentation|http://gstreamer.freedesktop.org/documentation/]] and prepare the development environment. For the later learn about the [[git|http://git-scm.com/]] version control system, clone the [[gstreamer modules|http://gstreamer.freedesktop.org/dev/]] and ensure that you can build and run the development version (e.g. in an [[UninstalledSetup|UninstalledSetup]]). + +Back to [[TaskList|TaskList]] + + + +--- + + [[CategoryGSOC2012|CategoryGSOC2012]] diff --git a/SubmittingPatches.mdwn b/SubmittingPatches.mdwn new file mode 100644 index 0000000..b59c256 --- /dev/null +++ b/SubmittingPatches.mdwn @@ -0,0 +1,105 @@ + + +## Submitting Patches + + +### Where + +Please submit patches for GStreamer in [[GNOME bugzilla|https://bugzilla.gnome.org]]: + +* you will need to create a GNOME bugzilla account if you don't have one yet (yep, that's just how it is, sorry for the inconvenience) +* create a new bug if there is no bug report for this issue yet; [[This page|http://gstreamer.freedesktop.org/bugs/]] has shortcuts for the major components +* once you have created a bug you can attach your patch(es), see below for more details +* if your patch is an enhancement or new API, please set your bug's severity to 'enhancement' +* if your patch is against a specific plugin or element, prefix the Summary with `[element-name]` or `[plugin-name]` and keep the rest of the description as short and precise as possible. Example: _[id3demux] add support for WCOP frame_. This makes sure developers looking through the [[list of open bugs|http://bugzilla.gnome.org/buglist.cgi?product=GStreamer&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&form_name=query]] can quickly identify what your bug is about; if your text is too long and only contains fill words at the beginning, the important information will be cut off and not show up in the list view. +* create separate bugs for separate issues +Please do not submit patches on the gstreamer-devel mailing list. Patches submitted on the mailing list are most likely going to be ignored or simply overlooked. + +Please also do not attach patches to already-existing bugs unless they are directly relevant to the issue, ie. do not attach patches to already-existing bugs that are only vaguely related to your issue. + + +### How + +You should prepare patches against a current git checkout, if possible at all. Patches against the current stable release of the module in question _may_ be acceptable as well if the plugin/code hasn't changed much since then, but if it has, chances are that you will be asked to provide an updated patch against the git repository. + +If you have created a new plugin, please submit a patch that adds it to gst-plugins-bad (including configure.ac and the various Makefile.am modifications and all new files). + + +#### General information on how we like our patches + +Please submit patches in `git format-patch` format, as attachement to a bug in bugzilla. + +The easiest way to create such patches is to create one or more local commits for your changes in a local git repository. This can be a git clone checkout of the module in question, or you could create a git repository in any directory that has the source code, e.g. the directory created when unpacking the source tarball (using `git init`, then `git add .` and `git commit -m 'import tarball as initial revision'`). + +Once you have a git repository with the original code in in it, you can make your modifications and create a local commit with e.g. `git commit path/to/file1.[ch]`. This will pop up an editor where you can create your commit message. It should look like: + + +[[!format txt """ +exampledemux: fix seeking without index in push mode + +Without an index we would refuse to seek in push mode. Make +seeking without an index work by estimating the position +to seek to. It might not be 100% accurate, but better than +nothing. + +https://bugzilla.gnome.org/show_bug.cgi?id=987654 +"""]] +Then exit the editor, and you should have a commit. + +Check the commit with `git show` or `git log -p`. + +Make sure the author is correctly set to your full name and e-mail address. + +You can make changes to the last commit using: + + * `git commit --amend` to fix up the commit message, or + * `git commit --amend --author='John You <john@you.com>'` to fix up the author, or + * `git add path/to/file1.[ch]; git commit --amend` to incorporate fixes made to the files into the last commit +Once everything looks fine, create the patch file for the last commit with: `git format-patch -1` + +If you have multiple commits, pass -2, -3, etc. + +This should create one or more patch files named 0001-blahblah, 0002-blehblah etc. in the current directory. Attach these to a bug report in bugzilla. + +Please make sure your patches are as terse and precise as possible. Do not include 'clean-ups' or non-functional changes, since they distract from the real changes and make things harder to review (if you feel there are things to clean-up, please submit the clean-ups as a separate patch that does not contain any functional changes). + +Try to stick to the GStreamer coding style. Run [[gst-indent|http://cgit.freedesktop.org/gstreamer/gstreamer/tree/tools/gst-indent]] over your .c or .cpp files, but not the header files, if you want your code auto-indented before making the patch (requires GNU indent installed). + + +#### Create a diff from a git commit + +Working with a git repository is generally easier if you commit your changes locally. Unlike CVS, where commiting your changes is synonymous with sending those changes to the central repository, git has a two-stage commit process: commit the changes locally, then separately push those changes to a central repository. This allows developers to have the benefits of change control without needing write access to the central repository. + +To commit changes locally, use the 'git add' and 'git commit' commands. You can add several times on various files, and then commit them all together. For example: + + +[[!format txt """ +$ git add file1.c +$ git add file2.c file3.h +$ git commit +"""]] +The commit command will allow you to write a commit message. GStreamer developers generally use 'pluginname: short description of changes', a blank line, and then potentially several lines of detailed information about the changes. + +To modify a commit, including adding new files, you can use 'git commit --amend'. + +Once you have committed changes, and want to pull new changes from the central GStreamer repository, use 'git pull --rebase'. The '--rebase' option causes git to replay your changes on top of any changes that you pull from the central repository. + +To create a nicely formatted patch from the most recent commit, use: + + +[[!format txt """ +$ git format-patch -n1 +"""]] +Attaching a patch that is in this form to a bugzilla bug makes applying and merging the patch much easier for another developers that reviews your patch. + +If you haven't used git before, it would be a good idea to tell it who you are: + + +[[!format txt """ +$ git config --global user.name "George S. Treamer" +$ git config --global user.email "gstreamer@gmail.com" +"""]] + +### What to do after you have submitted your patch + +Most of all, please be patient. We try to review patches as quickly as possible, but there is such a high turnaround of bugs, patches and feature requests that it is not always possible to tend to them all as quickly as we'd like. This is especially true for completely new plugins. If you haven't gotten any response at all for a while, feel free to 'ping' us by posting a quick follow-up comment to the bug or finding us on IRC (many developers actively track changes in bugzilla via e-mail, so a follow-up comment will usually be noticed). diff --git a/TaskList.mdwn b/TaskList.mdwn new file mode 100644 index 0000000..6188751 --- /dev/null +++ b/TaskList.mdwn @@ -0,0 +1,17 @@ + + +# Google SoC + +* [[SocProjects|SocProjects]]: List of suggested Summer of Code projects +* [[StudentInfo|StudentInfo]]: Information for students considering to apply +* [[SocManagement|SocManagement]]: Overview of involved people + +# Other Tasks + +* [[MoreBaseClases|MoreBaseClases]]: Create baseclases for decoders, encoders, demuxers and muxers +* [[DvdPlayback|DvdPlayback]]: Ongoing work on ResinDVD to suppport full DVD playback. + + +--- + + [[CategoryTasks|CategoryTasks]] diff --git a/TimMüller.mdwn b/TimMüller.mdwn new file mode 100644 index 0000000..cee478b --- /dev/null +++ b/TimMüller.mdwn @@ -0,0 +1,13 @@ + + +## Tim-Philipp Müller + +Email: tim at centricular net + +I hack on GStreamer. + + + +--- + + [[CategoryHomepage|CategoryHomepage]] diff --git a/Tutorials.mdwn b/Tutorials.mdwn new file mode 100644 index 0000000..05b9591 --- /dev/null +++ b/Tutorials.mdwn @@ -0,0 +1,25 @@ + + +# Introduction + +* [[Introducing GStreamer|http://www.cin.ufpe.br/~cinlug/wiki/index.php/Introducing_GStreamer]] +* [[Multipurpose multimedia processing with GStreamer|http://www-128.ibm.com/developerworks/aix/library/au-gstreamer.html?ca=dgr-lnxw07GStreamer]] + +# Python + +* [[gst-python api docs and tutorials|http://pygstdocs.berlios.de/]] +* [[Getting started with GStreamer with Python|http://www.jonobacon.org/?p=750]] +* [[GStreamer Dynamic Pads, Explained|http://www.jonobacon.org/?p=810]] +* [[Using Gnonlin with GStreamer|http://www.jonobacon.org/?p=851]] + +# Gnonlin + +* [[GStreamer and GNonLin Tutorials|http://www.ocf.berkeley.edu/~brandon/wiki/index.php5?title=Main_Page]] + +# Vala + +* [[GStreamer examples in Vala|http://live.gnome.org/Vala/GStreamerSample]] + +# Development + +* [[Debugging GStreamer applications|http://www.buzztard.org/index.php/Debugging]]
\ No newline at end of file diff --git a/index.mdwn b/index.mdwn new file mode 100644 index 0000000..aa822ab --- /dev/null +++ b/index.mdwn @@ -0,0 +1,43 @@ + + +# GStreamer Wiki + +This wiki serves as a scratchpad for tasks, design discussions and the like. + + +## General + +* [[Plugins|Plugins]] and [[MorePlugins|MorePlugins]]: listings of official and external plugin modules +* [[ReleasePlanning|ReleasePlanning]]: schedule for code freezes and planning for dates +* [[RoadMap|ReleasePlanning/RoadMap]]: road map +* [[DesignDiscussions|DesignDiscussions]]: drafting new features +* [[TaskList|TaskList]]: standalone tasks for anyone to take, Google SoC planning +* [[FAQ|FAQ]]: frequently asked questions +* [[Tutorials|Tutorials]] : links to external tutorials +* [[SubmittingPatches|SubmittingPatches]]: where and how to submit patches +* General documentation about GStreamer libraries and plugins can be found on the [[GStreamer Documentation Page|http://gstreamer.freedesktop.org/documentation/]] + +## Links + +* [[GStreamer Hackfest 2013 (Location TBD)|GStreamerHackfest2013]] +* [[GStreamer Conference 2012 (San Diego) - slides and videos|GStreamerConference2012]] +* [[GStreamer 1.0 Hackfest 2012 (Malaga)|GStreamerHackfest2012]] +* [[GStreamer Conference 2011 (Prague) - slides and videos|GStreamerConference2011]] +* [[GStreamer Conference 2010 (Cambridge) slides and videos|GStreamerConference2010]] +* [[GStreamer build bot|http://git.pitivi.org:8010/waterfall]] (currently defunct) +* [[GStreamer Windows MingW build bot|http://lrn.no-ip.info]] +* [[Release Planning|ReleasePlanning]]: [[2010|ReleasePlanning2010]] [[2011|ReleasePlanning2011]] [[2012|ReleasePlanning2012]] [[2013|ReleasePlanning2013]] +* [[GStreamer device profile format discussion|http://gstreamer.freedesktop.org/wiki/DeviceProfile]] + +## Starting points + +* [[RecentChanges|RecentChanges]]: see where people are currently working +* [[WikiSandBox|WikiSandBox]]: feel free to change this page and experiment with editing +* [[FindPage|FindPage]]: search or browse the database in various ways +* [[SyntaxReference|SyntaxReference]]: quick access to wiki syntax +* [[SiteNavigation|SiteNavigation]]: get an overview over this site and what it contains +* [[HowToCompileForEmbedded|HowToCompileForEmbedded]]: tips about how to do compile GStreamer for embedded devices + +## Random + +* [[HowToUseThisSite|HowToUseThisSite]]: help about this wiki
\ No newline at end of file |
