Containers are nice because they can contain metadata, such as "Title", "Author", "Copyright", "Album", "Year", etc., as well as data about what audio and video codecs were used to encode the data.
someencoding: Typically, after you have decoded and processed the raw data, you'll want to encode the raw data (audio, video, or both) into some compressed format, whether it's lossless compression like FLAC audio (for the best quality), or lossy compression like MP3 or H264 (for the best file size).Processing may be required to change aspects of it (change sample rate, resolution of video, FPS, etc.) or it may be required to satisfy the requirements of elements further down the pipeline. someprocessing: Typically, after you have decoded the encoded input data (audio, video, or both) into a raw data type (which is basically a stream of integers or floating-point numbers for instance, one of audio's raw data types is PCM), you can perform some processing on it.You can use the built-in tool gst-inspect to get a list of available plugin elements, and to inspect the properties of individual elements. somedecoder: A decoder - this is, for instance, a Vorbis decoder, or a Theora decoder.The demuxer "removes" the container, exposing its internal streams of data, which are still encoded. For instance, you can have Ogg/Vorbis audio and Ogg/Theora video muxed together in a Matroska (mkv) container. somedemuxer: A demuxer - most, but not all, media comes muxed in some sort of container format.For instance, filesrc, which reads data from a file. somesrc: A source - where the original input data comes from.Gst-launch -v somesrc ! somedemuxer ! somedecoder ! someprocessing ! someencoding ! somemux ! somesink. There are many sites on the web if you google that will provide example pipelines to get you started, but the general format I like to use is: If the source media was produced via some consumer electronics device, this can be extremely useful to figure out just what the input file consists of, and you can then either use gstreamer directly, or some other tool, to process it into the desired form to work with it further. You can use the decodebin element along with the -v switch (for verbose) to get a huge amount of information about how gstreamer is attempting to demux and then decode your input data, which can give you deep insights into just how the source media is structured. The debugging information it provides is incredible, too.
#LIGHTWEIGHT VIDEO EDITOR FREE SOFTWARE#
It is a powerful software development tool in its own right, but you can do almost any conversion you could imagine (or even live video/audio capture from a webcam/mic) through gst-launch alone. The gstreamer SDK is a new binary build of gstreamer that provides gst-launch (among other things) across various platforms, and you don't even have to compile gstreamer yourself anymore. With gstreamer, you just do a little tweaking to your pipeline and you're off to the races. Many GUI-driven media programs have the drawback that they implicitly expect or assume certain details about input files, and if the input data doesn't satisfy those conditions, it errors out. The best part about this setup is that it's so flexible. You can use the built-in program gst-launch (variously gst-launch-0.10 or gst-launch-1.0 depending on the version you have) to build custom-tailored "pipelines" that will take almost any imaginable source media and transform it into almost any imaginable destination media. But that's okay, because someone else may find that this is the best tool for the job for them.īasically, if you get a build of gstreamer with all the codecs enabled, it supports an enormous variety of file formats.
You're probably going to hate this answer, because it technically satisfies your requirements, while not being GUI-based. I'm going to answer this by recommending gstreamer.
0 kommentar(er)
