mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-07-03 05:05:52 +00:00
6fd179b578
Original commit message from CVS: * ext/flac/gstflacdec.c: (gst_flacdec_src_query): Only return true if we actually filled something in. Prevents player applications from showing a random length for flac files. * gst-libs/gst/riff/riff-read.c: (gst_riff_read_class_init), (gst_riff_read_use_event), (gst_riff_read_handle_event), (gst_riff_read_seek), (gst_riff_read_skip), (gst_riff_read_strh), (gst_riff_read_strf_vids_with_data), (gst_riff_read_strf_auds_with_data), (gst_riff_read_strf_iavs): OK, ok, so I implemented event handling. Apparently it's normal that we receive random events at random points without asking for it. * gst/avi/gstavidemux.c: (gst_avi_demux_reset), (gst_avi_demux_src_convert), (gst_avi_demux_handle_src_query), (gst_avi_demux_handle_src_event), (gst_avi_demux_stream_index), (gst_avi_demux_sync), (gst_avi_demux_stream_scan), (gst_avi_demux_massage_index), (gst_avi_demux_stream_header), (gst_avi_demux_handle_seek), (gst_avi_demux_process_next_entry), (gst_avi_demux_stream_data), (gst_avi_demux_loop): * gst/avi/gstavidemux.h: Implement non-lineair chunk handling and subchunk processing. The first solves playback of AVI files where the audio and video data of individual buffers that we read are not synchronized. This should not happen according to the wonderful AVI specs, but of course it does happen in reality. It is also a prerequisite for the second. Subchunk processing allows us to cut chunks in small pieces and process each of these pieces separately. This is required because I've seen several AVI files with incredibly large audio chunks, even some files with only one audio chunk for the whole file. This allows for proper playback including seeking. This patch is supposed to fix all AVI A/V sync issues. * gst/flx/gstflxdec.c: (gst_flxdec_class_init), (flx_decode_chunks), (flx_decode_color), (gst_flxdec_loop): Work. * gst/modplug/gstmodplug.cc: Proper return value setting for the query() function. * gst/playback/gstplaybasebin.c: (setup_source): Being in non-playing state (after, e.g., EOS) is not necessarily a bad thing. Allow for that. This fixes playback of short files. They don't actually playback fully now, because the clock already runs. This means that small files (<500kB) with a small length (<2sec) will still not or barely play. Other files, such as mod or flx, will work correctly, however. |
||
|---|---|---|
| .. | ||
| .gitignore | ||
| decodetest.c | ||
| gstdecodebin.c | ||
| gstplaybasebin.c | ||
| gstplaybasebin.h | ||
| gstplaybin.c | ||
| gststreaminfo.c | ||
| gststreaminfo.h | ||
| Makefile.am | ||
| README | ||
| test.c | ||
| test2.c | ||
| test3.c | ||
| test4.c | ||
decoderbin:
A bin with a sinkpad that decodes the data into raw formats. It works by sending
the input data through a typefind element and then recursively autoplugs elements
from the registry until a raw format is obtained. It will then create a new ghostpad
on itself to signal the app of the new pad.
TODO
- reuse of decoderbin, cleanup in READY state
- debugging
- threading after demuxing?
- better factory selection, based on Demuxer/Decoder types and ranks.
- error handling
baseplaybin:
A bin with an uri property. It will find the right source element from the registry
and connect a decoderbin to it. When going to the PAUSED state, it will iterate the
decoderbin and listen for new pad signals from it. It will connect a queue to each
new pad and will iterate the decoderbin until one of the queues is filled. It is
assumed that by that time all the streams will be found so that when leaving the
PAUSED state, one can query the number of streams in the media file with the given
uri.
Before going to the PLAYING state, it is possible to connect a custom element to
each of the streams. To do that, you have to add the element to the bin and then
connect the pad(s) from the stream(s). You do not have to add the elements in
a thread, the bin will take care of then when it's needed. You are allowed to use
threads inside the elements, of course.
The bin tries to be smart and doesn't add a queue when there is only one possible
stream.
TODO
- reuse, cleanup in ready state
- debugging
- when the first pad is closed, it's possible that another dynamic element is
added somewhere so that we need a queue for the first pad as well.
- error handling
playbin:
Extends baseplaybin, sets up default audiosink and videosink for first audio/video
stream detected. implements seeking and querying on the configured sinks.
TODO
- reuse, refcounting, cleanup in READY state
- debugging
- error handling