mirrors/gstreamer
mirrors/gstreamer
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gstreamer.git synced 2025-02-20 13:06:23 +00:00
Code Issues 1 Projects Releases Wiki Activity

Added a design proposal from metadata parse and mux.

Browse source 
Original commit message from CVS:
Added a design proposal from metadata parse and mux.
This commit is contained in:
Edgard Lima 2007-11-12 17:27:03 +00:00
parent 015dc9060f
commit 8b2cf9ce12
2 changed files with 93 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ChangeLog
View file

@ -1,3 +1,8 @@
2007-11-12 Edgard Lima <edgard.lima@indt.org.br>
* ext/metadata/README:
Added a design proposal from metadata parse and mux.
2007-11-11 Sebastian Dröge <slomo@circular-chaos.org>
* gst/equalizer/demo.c: (draw_spectrum):

88
ext/metadata/README Normal file
View file

@ -0,0 +1,88 @@
### design proposal for metadata mux and parser ###
## use cases ##
1- Create metadata
[ App send tag events to the pipeline ]
|| /\
|| ||
|| jpegenc send tag messages like (width, height and compression info)
|| ||
\/ ||
+---------+ +---------+ +-------------+ +----------+
| v4l2src | -> | jpegenc | -> | metadatamux | -> | filesink |
+---------+ +---------+ +-------------+ +----------+
* elements like videoscale should also send (width and height tags)
* should metadatamux get info from caps (width and height) and use if not receive a event with such tags?
2- View metadata
+---------+ +---------------+ +---------+ +-------------+
| filesrc | -> | metadataparse | -> | jpegdec | -> | xvimagesink |
+---------+ +---------------+ +---------+ +-------------+
or
+--> whole chunk send as event to next element
|
+---------+ +---------------+ +----------+
| filesrc | -> | metadataparse | -> | fakesink |
+---------+ +---------------+ +----------+
||
\/
1- individual tags send as messages (what about not mapped tags??)
2- whole chunk send as message (probably the application will ignore this)
* in any case metadataparse strips out metadata chunks (different from current implementation)
3- Modify (add, change, delete tags)
+--> whole chunk send as event to next element -- ... --+
| |
| V
+---------+ +---------------+ +-------------+ +----------+
| filesrc | -> | metadataparse | --------------- ... --------------> | metadatamux | -> | filesink |
+---------+ +---------------+ +-------------+ +----------+
/\ ||
|| \/
|| 1- individual tags send as messages (what about not mapped tags??) ==============\\
|| 2- whole chunk send as message (probably the application will ignore this) ||
|| ||
[ App send tag events to the pipeline ] <=======================================================//
* metadataparse strips out metadata chunks (different from current implementation)
* application receives individual tag messages (what about not mapped ones?)
* the application only send events back to the pipeline for the tags the application wants to modify or keep.
The tags not sent will not be included in metadata chunks
* the metadatamux modify the whole chunk event received before to just keep the individual tags sent by application
* the metadatamux could have a property to say if it should remove or keep tags not sent by application.
Obs: By looking at the proposed design (1- view and 2- modify) seems that the metadataparse and metadatamux should not know about mapped tags.
Only the application map the tags to/from metadata specific format. This is because, if you notice, only tags sent by application will be keep
on new file.
4- Convert (for example from jpeg to png)
+--> whole chunk send as event to next element -- ... --+
| |
| V
+---------+ +---------------+ +-------------+ +----------+
| filesrc | -> | metadataparse | -> | jpegdec | -> ... -> | pngenc | -> | metadatamux | -> | filesink |
+---------+ +---------------+ +-------------+ +----------+
/\ ||
|| \/
|| 1- individual tags send as messages (what about not mapped tags??) ==============\\
|| 2- whole chunk send as message (probably the application will ignore this) ||
|| ||
[ App send tag events to the pipeline ] <=======================================================//
* in this case the application set the metadatamux property to always keep the tags by default (application don't not need to send tag events)
* metadatamux needs additional smartness to check what tags still does make sense (some from original jpeg may not make sense anymore)
* if the image is resized, the videoscale should send messages to the application with new width (in the same way pngenc should also) and the
application could send width and height tag events to the pipeline
* should metadatamux get info from caps (width and height) and use if not receive a event with such tags?