> > 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...
ah...yes....gmerlin_encoders. I just now did that and get:
AVI/AC3/MPEG4 - creates an AVI, but gmerlin_play says
"[avdecoder.demuxer] Info: Detected AVI format
Floating point exception". mplayer plays audio but no video.
AVI/AC3/ffmpeg MSMPEG 4v3 DIVx
gmerlin_play says the same as above.
mplayer plays both audio and video...but the video timing is off. It
goes way too fast.
AVI/AC3/MJPEG
gmerlin_play says the same as above.
mplayer plays both audio and video...but the video timing is off. It
goes way too fast.
AVI/AC3/ffmpeg H263
gmerlin_play says the same as above.
mplayer plays audio but no video.
AVI/SOWT/MJPEG
works!
AVI/SOWT/ffmpeg MJPEG
works
AVI/SOWT/DIRAC
works
was it just the AC3 codec that caused problems?
> > 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).
yeah, I guess if you have an mp4 container, and that can be played by
windows users, then there may be no need for AVI. I don't know...there
seem to be so many formats out there....and the quicktime for linux
container doesn't ever seem to be compatible with Macs. I just made a
quicktime (with cinelerra) with MJPEG and 16bit twos pcm inside...and it
cannot be read by the f'ing quicktime player of a mac. Arg. I know
the cinelerra qtlib is different, but isn't it based on your qtlib as
well?
I guess what I am interested in (as I believe you are as well), is
compatibility. Video is already difficult enough. It would be great
to have a cross-listing of known compatible files formats - container,
audio, video - that work on all platforms.
> > 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).
ok.
> >> 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.
perhaps a compatibility registry could be of use. but, that might be
something for outside gmerlin.
> 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.
This is where I might differ in opinion. I think the gain might be
pretty significant. However, the work that would go into it might be
immense in comparison. Keeping up with what players play which format
is not trivial, I gather.
> >> 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.
yeah, I see what you are saying.
> 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.
agreed.
> > 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.
>
from the programmer side of things...it would be nice to be able to test
and see if a container-codec combo is even valid. Right now, I have to
start the encoder and see if it fails...but afaik, I don't get any error
report back as to why it failed. I also don't know enough about the
config and plugin registries yet to pick out my own container-codec
options. It's still very vague to me how it works.
I DO like the fact that I can set my encoding options in one place with
gmerlin_plugincfg. That is really great. However, if I build a
streaming video app with the gmerlin framework, and I want the user to
only use the theora streaming plugin, how do I set that up?
-august.
------------------------------------------------------------------------------
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
