= Inspiration = Simillar apps to take inspiration from: http://www.fourcc.org/identifier/gspot_example.png http://img.brothersoft.com/screenshots/softimage/g/gspot-190045-1.jpeg http://www.headbands.com/gspot/v26x/index.htm = browsing = - if one has grillo installed we could use grillo sources in addition to local files - there should be a "open url" menu entry in addition - if initial directory contains a glob as a last entry, we could set a filter on the file-choser - when a stream plays we hide the file-browser pane or show a text entry - we could also take playlists and use totem-pl-parser - needs a list-view to show the playlist instead of the file-browser - if the input arg starts with '@' we could read the file and show uris listed line by lien in the tree view. = compare = - dup detail pane and allow to pick a new file - create new Info() pane and reuse the DiscovererInfo - show differing entries in red - add a narrow vertical bar between the two details panes and mark blocks with a delta red - diffing one (broken) file against several known working files would be nice - it would build ranges for the group of files (e.g. for the video width) - it would highlight fields that the are different to any of the working files = structural view/hex view = - make parsing elements post structural messages (if enabled via property) - message would contain: - stream offset in bytes - block identifier (e.g. fourcc) - human readable description (if available) - flags (e.g. if the block is used or skipped) - indentation depth - we would need a way to indicate that e.g. h264parse would be indented below the containing container block - a structured hex view would be nice (somehow align the parse tree with the hexdump) = playback = - have a menu command to turn auto-play off - show level meters for audio next or below video drawable - show a seek bar under the drawable / or seek by scrubbing on the drawable = unsorted = - show named audio channel configurations instead only numbers e.g. "mono", "stereo", "5.1" - tag lists - if there is a "language-code" in the tags (or subtitles?) use flag icons - deluge installs some under: /usr/share/pyshared/deluge/data/mediainfo/pixmaps/flags/ - famfamfam-flag-png: locale/usr/share/flags/countries/ - geo-tags: map-widget?, link to google-maps?, rev-geocoding - artist: links to {last.fm,wikipedia} - format dates nicely (current locale, xx days ago?) - more codec details - caps have profile/level strings, can we also turn them into wikilinks? - bitrate and encode_size are related, calculate one from the other if missing - encoded_size = duration * bitrate; - bitrate = encoded_size / duration; - needed in: quicktime, ogg/theora == deep scan mode == - could be done in gst_devtools/validate - play the file by using fakesinks and gather statistics: - update fields when playing - listen for duration messages on the bus - get bit-rate over time - specify window size, get min,max,avg bitrate for each window - gst-mi can draw them as a graph - get key-frame statistics (using gst-index) - number of keyframes - min,max,avg keyframe interval - disconts - read-pos on source (show if there is excessive seeking) - raw data statistics - audio: level, ... - video: histogram, contrast, ... = TODO for gstreamer = - file/stream layout - from every element we'd like to know what data is processed, what is pushed further and some metadata about it: layout { gsize offset; // in bytes gsize length; // in bytes gboolean known; // or an enum: handled, skipped, unknown gchar *name; // e.g. atom/chunk name gchar *description; // long description or NULL enum block_type type; // meta, audio, video, text, ... }; - offset is not neccesarily easy to determine for later elements, not sure if we can make it relative - elements could emit messages with this info - need a common way to enable it: - "post-stream-layout" property - message-mask as api - visulaisation - we would need a cairo custom widget to draw a table - one row per element - each row contains colored segments - tree- view with data as hex dump = TODO for gstreamer-plugins = - wav: no bitrate for uncompressed files - mp4: no bitrate for many formats = TODO for discoverer = - add deep-scan mode (see above) - add a mode property: quick-scan, deep-scan (or just a boolean for deep-scan that is false by default) - gst-discoverer will use "-d" for deep-scan/details (-a for analyze or -s for scan are used otherwise already) - in deep-scan, don't stop on handle_message::GST_MESSAGE_ASYNC_DONE - in deep-scan we need pad-probes for encoded data pads (to get bitrates) - uridecodebin_pad_added_cb() has raw pads :/ - look at uridecodebin_element_added_cb() - the pads on uri-decodebin are sufficient to get keyframes and disconts - qtdemux could return stsz table to get bitrate profile http://wiki.multimedia.cx/index.php?title=QuickTime_container#stsz - get duration per stream - this would need individual queries on the demuxer src pads - or duration as part of per stream tags - we need byte-durations for calculating compression ratio - errors/warnings about files/stream processing - we'd like to know about fixable, unfixable issues in the file/stream - many elements do this already (178 uses in 89 files) - the pipeline and thus the bus is internal to discoverer, so it would be nice if it could gather the messages and offer them - having them globaly should be enough - CBR/VBR type for each stream - can we derive that from the bitrate tags (no min/max bitrate set)? find . -name "*.c" -exec egrep -Hn "GST_TAG[A-Z_]*_BITRATE" {} \; - formats - all raw files are cbr - some codecs are cbr only (some speech codecs) - audio - in an MP3 file, if there is no VBRI or Xing, it probably is not a vbr stream - - lossy/lossless compression/encoding - show compression type: - all raw formats are lossless - some audio formats are lossless (flac, wavpack, ...) - some video formats can be lossless (dirac, ...) - show compression raitio (in/out) - depends on the target raw format - need binary size for each stream, can we do byte queries on each pad? - if we have stream sizes we could also show container overhead = discoverer workflow = == sync quick-scan == app disco --- ----- | discover_uri() | |--------------------->| | done | |<---------------------| | == async quick-scan == app disco --- ----- | discover_uri_async() | |--------------------->| | ... | | discover_uri_async() | |--------------------->| | start() | |--------------------->| | ::discovered | |<---------------------| | ... | | ::discovered | |<---------------------| | ::finisheded | |<---------------------| | == sync deep-scan == - same as "sync quick-scan", no intermediate result == async deep-scan == - same as "async quick-scan", but each discovered signal is followed by an "analyzed" signal with detailed information - we could also just emit discovered twice. app disco --- ----- | discover_uri_async() | |--------------------->| | ... | | discover_uri_async() | |--------------------->| | start() | |--------------------->| | ::discovered | |<---------------------| | ::analyzed | |<---------------------| | ... | | ::discovered | |<---------------------| | ::analyzed | |<---------------------| | ::finisheded | |<---------------------| |