GNOME Bugzilla – Bug 722311
matroskaparse: should try to identify data on stream header before going with a blind
Last modified: 2014-01-21 14:17:47 UTC
While working on another issue, realized filesrc ! matroskaparse ! shout2send doesn't work for a webm file whereas filesrc ! oggparse ! shout2send does for ogg/vorbis. Reason for the failure is the quick fallback to video/x-matroska on the parser while a typefind over the stream header can easily (albeit costly?) find out the data being pushed by filesrc is actually video/webm without blindly claiming otherwise.
Created attachment 266425 [details] [review] Preliminary solution typefindhelper based solution. Considering it's a corner-case the cost of iterating over the typefinders should be justified I guess
Comment on attachment 266425 [details] [review] Preliminary solution No, matroskaparse already *parses* the actual header of the matroska file and knows if it's webm or something else
See gst_matroska_read_common_parse_header(). Just needs to be stored somewhere
Created attachment 266497 [details] [review] Produce better default caps when none is set Thanks for your review Sebastian. Hooked up this to the header/track parsing as you suggested.
Review of attachment 266497 [details] [review]: Looks good in general ::: gst/matroska/matroska-parse.c @@ +311,3 @@ + /* reset stream type */ + parse->common.is_webm = FALSE; + parse->common.has_video = FALSE; These also need to be reset in matroskademux for consistency
Created attachment 266829 [details] [review] Produce better default caps when none is set Added the stream type reset to matroskademux as requested. Thanks for your review.
Review of attachment 266829 [details] [review]: Good to go IMHO, unless you want to implement the 3D support. Why does that have different caps anyway? ::: gst/matroska/matroska-parse.c @@ +3049,3 @@ + * type and whether it has video or not. + * + * FIXME: Do something with video/x-matroska-3d if possible Yes, see gst-plugins-base/gst/typefind/gsttypefindfunctions.c
> Good to go IMHO, unless you want to implement the 3D support. Why does that > have different caps anyway? I simply re-used the types on http://matroska.org/technical/specs/notes.html when refining them in 0.11.
Cool. Pushed this one as it was. Will take a look at the 3d one latter on. Thanks for your time.