MediaConverter: shows non-writable container formats for output

[jessicah]

In hrev47063, the list of container formats now has to be filtered for demuxers.

Have provided a patch for MediaConverter; however, perhaps it is better to fix it in the ​ffmpeg plugin itself?

[jackburton]

Indeed, otherwise all applications which makes use of encoders will need to be adjusted. BeScreenCapture suffers from this, too.

[jessicah]

Is the API used solely by apps needing encoders though? Adrien seems to be using them in haiku-webkit for advertising formats Haiku can decode.

[pulkomandy]

I checked BeOS, and only formats with the B_WRITABLE capability are returned. So this API wasn't useable for knowing which formats can be read on BeOS, and the B_READABLE capability is unused there.

I made the change to the ffmpeg media add-on because I wanted a list of readable formats to feed to WebKit. I don't see any other way to do that, and this API seems to be designed for it, even if BeOS didn't make use of the feature.

I think it makes sense to fix the apps in this case, as the API was clearly designed to report all formats, including read-only ones, and already includes the flags to identify those.

[jessicah]

FYI, I've supplied a patch to BeScreenCapture which has been ​merged now :)

[stippi]

Just wanted to note that I am fully on the same page with the changes. The API is clearly not intended to report writable formats only. It just so happened that all formats it reported on BeOS were also writable. Similarily, I don't think it makes sense to offer tons of writable formats, even though ffmeg might support it. The API should offer the most sensible and most likely needed choices only. Otherwise, users are just overwhelmed without guidance.

[stippi]

(With the last bit, I meant to explain why the ffmeg plugin has its own muxer table that cherry picks some formats to export as writable).

[jessicah]

Replying to stippi:

Just wanted to note that I am fully on the same page with the changes. The API is clearly not intended to report writable formats only. It just so happened that all formats it reported on BeOS were also writable. Similarily, I don't think it makes sense to offer tons of writable formats, even though ffmeg might support it. The API should offer the most sensible and most likely needed choices only. Otherwise, users are just overwhelmed without guidance.

Haha, totally agree! I had mentioned that to PulkoMandy the other day in IRC :) Also, I think this bug can be closed now...

[pulkomandy]

Right. Applied in hrev47077.

[axeld]

Just for the record, I don't think restricting the number of formats at that point is the right decision, as that prevents to be able to write those formats at all. I'd prefer some way to filter those formats instead, either through an extra flag (I really want to get all the writable formats, you know), or through an extra API on top of that function that does the filtering.

[pulkomandy]

The idea behind the limited set of formats handled by the ffmpeg plugin is to report only the ones we know to be working. With the problems we have running ffmpeg on gcc2, it makes sense to do this. The goal isn't to limit the available formats behind that.