- Dec 26, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Wim Taymans authored
Use the aggregate control instead of the original request url to perform PAUSE/PLAY and TEARDOWN. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=721003
-
Sebastian Dröge authored
-
Previous versions did not have a stable bitstream for VP9. https://bugzilla.gnome.org/show_bug.cgi?id=720986
-
Sebastian Dröge authored
-
-
- Dec 17, 2013
-
-
Sebastian Dröge authored
There was a libvpx release with VP9 support now and the bitstream is frozen too.
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
- Dec 05, 2013
-
-
Don't advance the clock to 240ms too early. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=710013
-
- Dec 04, 2013
-
-
- Nov 29, 2013
-
-
-
Mathieu Duponchelle authored
-
- Nov 28, 2013
-
-
Wim Taymans authored
Cleaning the packet info will already unref the buffer. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=715078
-
- Nov 26, 2013
-
-
... the way it has always worked fine in a52dec.
-
After dropping a buffer, move our expected seqnum Conflicts: gst/rtpmanager/gstrtpjitterbuffer.c
-
A different device with different caps may be used for the next open. https://bugzilla.gnome.org/show_bug.cgi?id=712611
-
This way we do not miss mandatory fields in caps. At the same time use the gst_pb_utils_get_codec_description helper to get codec description. https://bugzilla.gnome.org/show_bug.cgi?id=712335
-
This way we do not miss mandatory fields in caps. At the same time use the gst_pb_utils_get_codec_description helper to get codec description. https://bugzilla.gnome.org/show_bug.cgi?id=712328
-
... rather than scaling these as unsigned. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=712744 Based on patch by Krzysztof Kotlenga <pocek@users.sf.net>
-
Sebastian Dröge authored
Instead of +/- 1ns we allow 2ns now. Due to rounding errors there are some Matroska files out there with 33.333331ms per frame for 30fps.
- Nov 25, 2013
-
-
Wim Taymans authored
Don't reset the expected output seqnum when clearing the pt map because this could stall the jitterbuffer forever. Add a unit test for this. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=709800
-
Spotted by 'gratias' on IRC. Probably introduced in recent refactoring. https://bugzilla.gnome.org/show_bug.cgi?id=715039
-
- Nov 22, 2013
-
-
Wim Taymans authored
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=712722
-
Wim Taymans authored
Handle input packet sizes larger than 16 bits in the depayloader. Remove size restrictions on the payloader.
-
Wim Taymans authored
Reorganize some things in the depayloader so that it can handle packets larger than 16 bits. Remove the size restriction on the payloader.
-
Reuse the parsed structure to get the timestamps.
-
- Nov 21, 2013
-
-
The problem here was that the jitterbuffer lock was unlocked to push the event, but that caused another thread to remove the timer currently being processed, probably because the amount of rtx events (and therefore timers) was getting too high. The solution is to unlock and push the event only after timer processing has finished. fixes https://bugzilla.gnome.org/show_bug.cgi?id=711131
-
- Nov 12, 2013
- Nov 09, 2013
-
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Sebastian Dröge authored
-
Restore the behavior of the element to the state before commit db29522a. A non-empty header is generated and when the EOS event is received the header is generated again, this time with the correct size. https://bugzilla.gnome.org/show_bug.cgi?id=711699
-
If the pipeline is stalled for too long, souphttpsrc will block and stop fetching data from the network. This can cause the connection to drop and souphttpsrc would handle it as an EOS. This patch makes it persist and try to fetch more data until the end of the content length or until receiving an error that it is beyong limits in case the content is unknown. https://bugzilla.gnome.org/show_bug.cgi?id=683536
-
Avoids sending EOS too soon because of overflow. Can happen on fragmented mp4 playback.
-
Assume a file with atoms in the following order: moov, mdat, moof, mdat, moof ... The first moov usually doesn't contain any sample entries atoms (or they are all set to 0 length), because the real samples are signaled at the moofs. In push mode, qtdemux parses the moov and then finds the mdat, but then it has 0 entries and assumes it is EOS. This patch makes it continue parsing in case it is a fragmented file so that it might find the moofs and play the media. https://bugzilla.gnome.org/show_bug.cgi?id=710623
-
In push mode, when qtdemux can't use a seek to skip the mdat buffer it has to buffer it for later use. The issue is that after parsing the next moov/moof, there might be some trailing bytes from the next atom in the file. This data was being discarded along with the already parsed moov/moof and playback would fail to continue after the contents of this moov/moof are played. This is particularly bad on fragmented files that have the mdat before the corresponding moof. So you'd get: mdat|moof|mdat|moof ... When a moof was received, it usually came with some extra bytes that would belong to the next mdat (because upstream doesn't care about atoms alignment). So those bytes were being discarded and playback would fail. This patch makes qtdemux store those extra bytes to reuse them later after the mdat is emptied. https://bugzilla.gnome.org/show_bug.cgi?id=710623
-