Opened 9 years ago

Closed 8 years ago

#912 closed task (fixed)

proper handling of missing video codecs

Reported by: Boris Bobrov Owned by:
Priority: major Milestone: 0.8.0
Component: programming Keywords:
Cc: slomo@…, joar Parent Tickets:

Description

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

Subtickets

Change History (13)

comment:1 Changed 9 years ago by Boris Bobrov

Owner: set to Boris Bobrov
Status: newin_progress

comment:2 Changed 9 years ago by Christopher Allan Webber

Milestone: 0.7.00.8.0

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.

comment:3 Changed 9 years ago by 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)

  1. 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.

comment:4 Changed 9 years ago by Boris Bobrov

Cc: Sebastian Dröge <slomo@…> added

comment:5 Changed 9 years ago by Boris Bobrov

Cc: slomo@… added; Sebastian Dröge <slomo@…> removed

comment:6 Changed 9 years ago by Christopher Allan Webber

Cc: joar added

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)

comment:7 Changed 9 years ago by 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.

comment:8 Changed 9 years ago by Boris Bobrov

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

comment:9 Changed 9 years ago by Boris Bobrov

fixed in 3bb6896

comment:10 Changed 9 years ago by Christopher Allan Webber

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

comment:11 Changed 8 years ago by Christopher Allan Webber

Milestone: 0.8.00.9.0

comment:12 Changed 8 years ago by Boris Bobrov

Milestone: 0.9.00.8.0

comment:13 Changed 8 years ago by Christopher Allan Webber

Owner: Boris Bobrov deleted
Resolution: fixed
Status: in_progressclosed

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

Note: See TracTickets for help on using tickets.