proper handling of missing video codecs

[Boris Bobrov]

in bretons-mediagoblin, branch gst10, when video transcoding fails for some reason the failure might not get reported properly. For example, when there is no proper codec, the task might get locked.

Lack of codec should be detected on the stage of discovering

[Christopher Allan Webber]

It's not clear yet whether gst10 will make it into this release yet or not, but given that we expect the gst10 branch to land in 0.8.0, moving there.

[Boris Bobrov]

After some research I see some ways how this can be done.

1. Report on file upload and sniffing. Currently, when a user uploads a file it:
   1. Gets sniffed by extension.
   2. If sniffing by extension fails, it gets sniffed by 'sniff_handler' hook
   3. If fails again, an error is reported.

We could drop extension-based sniffing and if the file can not be processed tell the user "H.264 decoder is missing on this server", not allowing him to upload the file.

This way seems to be the most expected behaviour, though it can be pretty expensive (see "def sniff_media" in media_types/__init__.py)

2. Report during transoding.

Leave extension check, report about missing codecs during transcoding. A text about it will appear in user's media processing panel.

Another thing can be done in addition to point 2. A "gmg check" command that would check all the uploaded media using the expensive way (see "def sniff_media" in media_types/__init__.py) and report about bad files.

I'd like to get a comment on which of the ways would be the preffered one.

[Christopher Allan Webber]

So, there's a reason that we have extension based sniffing as a first-line-of-response. If we don't do that, then *every* media type will have to do a "heavy" check of whether or not the media type can handle it. So the way we handle things is that first the extension is checked to see *if* the media type can handle it at all, and then after that, the media type can do a closer look to double check that it should be the one to handle it (the video/audio extensions do some checks to make sure the video plugin doesn't pick up the audio one, etc).

It *should* be possible in the sniff handler to do a check about whether or not the file can be handled. In the old branch, this worked, I think. The gst.extend.discoverer would check if the file could be "discovered", which would mean the codecs were available. Is there any way to do the same thing here?

Correct me if I'm wrong on any of this! (Cc'ing joar)

[Boris Bobrov]

So the way we handle things is that first the extension is checked to see *if* the media type can handle it at all, and then after that, the media type can do a closer look to double check that it should be the one to handle it (the video/audio extensions do some checks to make sure the video plugin doesn't pick up the audio one, etc).

Well, no. The easiest way to proof this wrong is "echo 1234 > test.mp4; upload test.mp4 to gobblin.se" :)

Now if (video) extension check passes, the file is considered to be a video without any further check.

But I got your point, I'll change it this way: if extension check passes, check the contents. If contents check passes upload, else report an error.

[Boris Bobrov]

Answering to your irc questions: yes, it is possible in gstreamer to check for codecs and plugins.

[Boris Bobrov]

fixed in 3bb6896

[Christopher Allan Webber]

So, this can be closed after the gstreamer 1.0 branch is merged then, it sounds like.

[Christopher Allan Webber]

Now that #771 is closed / gstreamer 1.0 support is merged, so is this!