- 01 Sep, 2015 1 commit
-
-
Andrew Stone authored
Instead of returning EINVAL, which can cause a stream to fail to load, this allows the tag to be passed through to the flv demuxer, where it's summarily ignored. Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 15 Jan, 2015 1 commit
-
-
Martin Storsjö authored
This fixes sending chunked packets (packets larger than the output chunk size, which often can be e.g. 4096 bytes) with a timestamp delta (or absolute timstamp, if it's a timestamp step backwards, or the first packet of the stream) larger than 0xffffffff. The RTMP spec explicitly says (in section 5.3.1.3.) that packets of type 3 (continuation packets) should include this field, if the previous non-continuation packet had it included. The receiving code handles these packets correctly. Pointed out by Cheolho Park. CC: libav-stable@libav.org Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 28 Nov, 2014 1 commit
-
-
Martin Storsjö authored
We try to avoid mixing av_malloc with av_realloc, since av_malloc may be implemented with functions that can't (formally) be mixed with the functions used in av_realloc. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 01 Jun, 2014 1 commit
-
-
Uwe L. Korn authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 23 Apr, 2014 1 commit
-
-
kyh96403 authored
Fixes Ticket3564 Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 07 Mar, 2014 4 commits
-
-
Martin Storsjö authored
Based on a suggestion by Martin Panter. This is more descriptive, since it's the actual timestamp field from the RTMP packet, which might or might not be a delta depending on context (in some packets it's a delta, in some packets it's an absolute timestamp, and in some packets it's 0xffffff to indicate that the actual delta or absolute timestamp is transmitted separately). Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Panter authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Panter authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Panter authored
Related fix in "rtmpdump": https://repo.or.cz/w/rtmpdump.git/commitdiff/79459a2 Adobe's RTMP specification (21 Dec 2012), section 5.3.1.3 ("Extended Timestamp"), says "this field is present in Type 3 chunks". Type 3 chunks are those with the one-byte header size. This resolves intermittent hangs and segfaults caused by the read function, and also includes an untested fix for the write function. The read function was tested with ABC (Australia) News 24 streams, however they are probably restricted to only Australian internet addresses. Some of the packets at the start of these streams seem to contain junk timestamp fields, often requiring the extended field. Test command: avplay rtmp://cp81899.live.edgefcs.net/live/news24-med@28772Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 20 Jan, 2014 1 commit
-
-
Martin Storsjö authored
The normal differential timestamps can't handle negative differences, thus send a full packet header with an absolute timestamp in these cases. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 14 Oct, 2013 1 commit
-
-
Martin Storsjö authored
Normally, all channel ids are between 0 and 10, while they in uncommon cases can have values up to 64k. This avoids allocating two arrays for up to 64k entries (at a total of over 6 MB in size) each when most of them aren't used at all. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 21 Sep, 2013 1 commit
-
-
Luca Barbato authored
And fix the AMF_DATA_TYPE_ARRAY parsing while at it. A MIXEDARRAY type, as the ARRAY, store the number of elements in an uint32 before the list. The ARRAY is strict and does not have an OBJECT terminator, MIXEDARRAY behaves like an OBJECT type and a different than stated number of element can be present.
-
- 17 Sep, 2013 1 commit
-
-
Josh Allmann authored
A given packet won't always come in contiguously; sometimes they may be broken up on chunk boundaries by packets of another channel. This support primarily involves tracking information about the data that's been read, so the reader can pick up where it left off for a given channel. As a side effect, we no longer over-report the bytes read if (toread = MIN(size, chunk_size)) == size Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 10 Aug, 2013 2 commits
-
-
Luca Barbato authored
CC: libav-stable@libav.org
-
Luca Barbato authored
-
- 01 Jun, 2013 1 commit
-
-
Kostya Shishkov authored
-
- 30 Apr, 2013 1 commit
-
-
Diego Biurrun authored
-
- 23 Jan, 2013 4 commits
-
-
Xi Wang authored
A negative `size' will bypass FFMIN(). In the subsequent memcpy() call, `size' will be considered as a large positive value, leading to a buffer overflow. Change the type of `size' to unsigned int to avoid buffer overflow, and simplify overflow checks accordingly. Also change a literal buffer size to use sizeof, and limit the amount of data copied in another memcpy call as well. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Xi Wang authored
Sanity checks like `data + size >= data_end || data + size < data' are broken, because `data + size < data' assumes pointer overflow, which is undefined behavior in C. Many compilers such as gcc/clang optimize such checks away. Use `size < 0 || size >= data_end - data' instead. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Xi Wang authored
A negative `size' will bypass FFMIN(). In the subsequent memcpy() call, `size' will be considered as a large positive value, leading to a buffer overflow. Change the type of `size' to unsigned int to avoid buffer overflow, and simplify overflow checks accordingly. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
Xi Wang authored
Sanity checks like `data + size >= data_end || data + size < data' are broken, because `data + size < data' assumes pointer overflow, which is undefined behavior in C. Many compilers such as gcc/clang optimize such checks away. Use `size < 0 || size >= data_end - data' instead. Signed-off-by:
Xi Wang <xi.wang@gmail.com> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 31 Dec, 2012 1 commit
-
-
Martin Storsjö authored
This avoids having to concatenate them into one buffer before writing them as AMF. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 02 Aug, 2012 1 commit
-
-
Jordi Ortiz authored
Signed-off-by:
Luca Barbato <lu_zero@gentoo.org>
-
- 14 Jun, 2012 1 commit
-
-
Samuel Pitoiset authored
This makes sure all incoming packets are read and handled (and reacted to) while sending an FLV stream over RTMP to a server. If there were enough incoming data to fill the TCP buffers, this could potentially make things block at unexpected places. For the upcoming RTMPT support, we need to consume all incoming data before we can send the next request. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 24 May, 2012 1 commit
-
-
Samuel Pitoiset authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 23 May, 2012 1 commit
-
-
Samuel Pitoiset authored
Check malloc calls used by ff_rtmp_packet_create, unify error handling and pass on error codes. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 11 Dec, 2011 1 commit
-
-
Mans Rullgard authored
The existing functions defined in intfloat_readwrite.[ch] are both slow and incorrect (infinities are not handled). This introduces a new header with fast, inline conversion functions using direct union punning assuming an IEEE-754 system, an assumption already made throughout the code. The one use of Intel/Motorola extended 80-bit format is replaced by simpler code sufficient under the present constraints (positive normal values). The old functions are marked deprecated and retained for compatibility. Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 03 Jul, 2011 1 commit
-
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 25 May, 2011 2 commits
-
-
Martin Storsjö authored
Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Some received packets can have size 0. The return value from av_malloc(0) may be NULL, which is ok if the size was 0. On OS X, however, the returned pointer is non-null but leads to crashes when trying to free it. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 04 Apr, 2011 3 commits
-
-
Anton Khirnov authored
-
Anton Khirnov authored
-
Anton Khirnov authored
-
- 19 Mar, 2011 1 commit
-
-
Mans Rullgard authored
Signed-off-by:
Mans Rullgard <mans@mansr.com>
-
- 07 Mar, 2010 1 commit
-
-
Kostya Shishkov authored
Originally committed as revision 22277 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 30 Jan, 2010 2 commits
-
-
Kostya Shishkov authored
Originally committed as revision 21533 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
Kostya Shishkov authored
Originally committed as revision 21532 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 24 Dec, 2009 1 commit
-
-
Diego Biurrun authored
libavformat/rtmppkt.c:350: warning: unused variable ‘i’ libavformat/rtmppkt.c:349: warning: unused variable ‘base’ Originally committed as revision 20917 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 11 Dec, 2009 1 commit
-
-
Kostya Shishkov authored
Originally committed as revision 20799 to svn://svn.ffmpeg.org/ffmpeg/trunk
-
- 04 Dec, 2009 1 commit
-
-
Sergiy authored
Patch by Sergiy (piratfmGMAIL) Originally committed as revision 20728 to svn://svn.ffmpeg.org/ffmpeg/trunk
-