GNOME Bugzilla – Bug 756457
typefind does not recognize raw VP8 streams
Last modified: 2015-10-13 07:30:33 UTC
typefind is unable to determine the type of a raw VP8 stream. To reproduce this bug run the following commands: $ gst-launch-1.0 videotestsrc num-buffers=40 ! videoconvert ! \ vp8enc ! multifilesink location=multi-vp8.%03d $ gst-launch-1.0 multifilesrc location=multi-vp8.%03d ! typefind ! \ vp8dec ! videoconvert ! xvimagesink Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPipeline:pipeline0/GstTypeFindElement:typefindelement0: Could not determine type of stream. Additional debug info: gsttypefindelement.c(943): gst_type_find_element_chain_do_typefinding (): /GstPipeline:pipeline0/GstTypeFindElement:typefindelement0 ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Replacing vp8 with vp9 shows the same issue also exists for raw VP9 streams.
Why do you think this is a bug? Which player recognises and plays these files? VP8 usually comes in a container such as Matroska/WebM or IVF. For the latter there's ivfparse.
This is not about playing files. Spice (an equivalent to VNC) can detect videos playing on the server, and encode and send them to the Spice client as a video stream. Obviously these streams are not encapsulated in a container. The server also sends the video type to the client but if typefind could identify VP8 videos it would be possible to rely on typefind rather than have to hardcode a limited set of known video formats in the client. Is there a reason to think VP8 (and VP9) video streams cannot be identified?
Well, of course they *can* be identified, the question is just if they can be identified reliably with reasonable enough effort given normal use cases (and without causing false positives). You can always typefind them by implementing a full decoder to see if the data is valid, after all. For me this looks like a WONTFIX.
Yes, VP8/9 is supposed to be in a container. Always.