Hi, august wrote: >>> My latest code test can be found here: >>> >>> http://aug.ment.org/tmp/encode.c >>> >>> I've updated it so that it writes audio and video data at half second >>> intervals. >>> >>> For testing, I am only using "twos" as the audio format. >>> >>> Whenever I set up gmerlin_plugincfg to use quicktime encoding and mov >>> container format....ALL seems to go great. I can encode all audio >>> and video formats. >> Just curious: Did you also try e_ffmpeg with the fixes I checked in? > > > with FFMPEG > > AVI/AC3/MPEG4 - video is just grey > > AVI/AC3/DIVx - video is just grey > > AVI/AC3/MJPEG - still cannot start the encoder due to colorspace
Will try to reproduce these. You did "cvs update" in gmerlin-encoders, right? The MJPEG problem should no longer be there... > mpeg1, wmv etc say they are not supported by AVI Will check if they can be enabled, although I don't see much sense in supporting them. In fact I see only little use for AVI at all, and that's mostly with MPEG-4 video and mp3 audio (for hardware divx players). > Is there a reason why these options show up in cases that they are not > allowed? This seems like a user interface or structure issue; Yes. The proper handling of these would be, that the available options in the codec menu change according to what's selected in the container menu. But right now my configuration dialogs are too dumb for that (i.e. one configuration parameters/widget doesn't know about others). >> Difficult to decide what to do for these cases. In e_ffmpeg I simply >> reject unsupported combinations of codecs and containers (with the >> disadvantage that I sometimes also rejected valid ones like AC3 in AVI). > > Couldn't this just be a tree structure in the registry? No because neither the codec registry nor the config registry knows about codecs or containers. They just knows about generic parameters. I thought about several ways to handle these in an elegant way, but all solutions lead to incredible bloat inside the code (which is complicated enough already). And the gain would be little. >> In libquicktime I have compatibility flags for the codecs (which should >> trigger the warnings). But these flags are defined according to what the >> "official" software plays. But there are some very interesting codecs >> (like ffv1, the best and fastest lossless codec I know), which would be >> rejected in all cases :) > > ok, I see. But, still, if gmerlin can make it and play it...it should > be ok. Disagree here. People will start encoding incompatible files and complain that other players cannot decode them. You already see lots of broken/incompatible files in the wild, and I don't want to contribute to this mess. As I said in some cases (like ffv1, where there is no sensible alternative), one can write such files. But in general, one should make things as compatible as possible and not encourage people to do silly things. > If gmerlin cannot make that combination of codecs into a > playable stream, it should not be an option. The TWOS in AVI case is special, because Audio codecs in AVI are sepcified by a 16 bit ID (in contrast to the fourcc for video), and if such ID isn't available (like for TWOS) the resulting file is undecodable. I'll try to catch this case. Burkhard ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Gmerlin-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gmerlin-general
