- 09 Jul, 2017 1 commit
-
-
Wan-Teh Chang authored
In url_find_protocol(), proto_str is either "file" or a string consisting of only the characters in URL_SCHEME_CHARS, which does not include ','. Therefore the strchr(proto_str, ',') call always returns NULL. Note: The code was added in commit 6161c418. Signed-off-by:
Wan-Teh Chang <wtc@google.com> Signed-off-by:
Muhammad Faiz <mfcc64@gmail.com>
-
- 14 Mar, 2017 2 commits
-
-
Alexander Strasser authored
The current form of the messages indicating matches in the white or black lists seems to be a bit too much relying on context. Make the messages more explicit. Signed-off-by:
Alexander Strasser <eclipse7@gmx.net>
-
Alexander Strasser authored
Signed-off-by:
Alexander Strasser <eclipse7@gmx.net>
-
- 14 Feb, 2017 1 commit
-
-
Joel Cunningham authored
This commit optimizes HTTP performance by reducing forward seeks, instead favoring a read-ahead and discard on the current connection (referred to as a short seek) for seeks that are within a TCP window's worth of data. This improves performance because with TCP flow control, a window's worth of data will be in the local socket buffer already or in-flight from the sender once congestion control on the sender is fully utilizing the window. Note: this approach doesn't attempt to differentiate from a newly opened connection which may not be fully utilizing the window due to congestion control vs one that is. The receiver can't get at this information, so we assume worst case; that full window is in use (we did advertise it after all) and that data could be in-flight The previous behavior of closing the connection, then opening a new with a new HTTP range value results in a massive amounts of discarded and re-sent data when large TCP windows are used. This has been observed on MacOS/iOS which starts with an initial window of 256KB and grows up to 1MB depending on the bandwidth-product delay. When seeking within a window's worth of data and we close the connection, then open a new one within the same window's worth of data, we discard from the current offset till the end of the window. Then on the new connection the server ends up re-sending the previous data from new offset till the end of old window. Example (assumes full window utilization): TCP window size: 64KB Position: 32KB Forward seek position: 40KB * (Next window) 32KB |--------------| 96KB |---------------| 160KB * 40KB |---------------| 104KB Re-sent amount: 96KB - 40KB = 56KB For a real world test example, I have MP4 file of ~25MB, which ffplay only reads ~16MB and performs 177 seeks. With current ffmpeg, this results in 177 HTTP GETs and ~73MB worth of TCP data communication. With this patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of ~22MB of TCP data communication. To support this feature, the short seek logic in avio_seek() has been extended to call a function to get the short seek threshold value. This callback has been plumbed to the URLProtocol structure, which now has infrastructure in HTTP and TCP to get the underlying receiver window size via SO_RCVBUF. If the underlying URL and protocol don't support returning a short seek threshold, the default s->short_seek_threshold is used This feature has been tested on Windows 7 and MacOS/iOS. Windows support is slightly complicated by the fact that when TCP window auto-tuning is enabled, SO_RCVBUF doesn't report the real window size, but it does if SO_RCVBUF was manually set (disabling auto-tuning). So we can only use this optimization on Windows in the later case Signed-off-by:
Joel Cunningham <joel.cunningham@me.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 17 May, 2016 2 commits
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
Yong Lei authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 10 Apr, 2016 1 commit
-
-
Carl Eugen Hoyos authored
-
- 24 Mar, 2016 3 commits
-
-
Martin Storsjö authored
Since all URLContexts have the same AVOptions, such AVOptions will be applied on the outermost context only and removed from the dict, while they probably make sense on all contexts. This makes sure that rw_timeout gets propagated to the innermost URLContext (to make sure it gets passed to the tcp protocol, when opening a http connection for instance). Alternatively, such matching options would be kept in the dict and only removed after the ffurl_connect call. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Andrey Utkin authored
If set non-zero, this limits duration of the retry_transfer_wrapper() loop, thus affecting ffurl_read*(), ffurl_write(). As soon as one single byte is successfully received/transmitted, the timer restarts. This has further changes by Michael Niedermayer and Martin Storsjö. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
Martin Storsjö authored
Currently the list of avoptions for URLContext is empty though, but such options will be added. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 17 Mar, 2016 1 commit
-
-
Michael Niedermayer authored
Fixes regression since bb8cc89bSigned-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 04 Mar, 2016 1 commit
-
-
Derek Buitenhuis authored
Signed-off-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
- 22 Feb, 2016 5 commits
-
-
Anton Khirnov authored
This way, the decisions about which protocols are available for use in any given situations can be delegated to the caller.
-
Anton Khirnov authored
Disallow other code to touch it directly, now it's only accessible through a blacklisting/whitelisting function.
-
Anton Khirnov authored
It needs to access the list of protocols directly, so it more properly belongs there.
-
Anton Khirnov authored
It's a more appropriate place for it.
-
Anton Khirnov authored
Instead of a linked list constructed at av_register_all(), store them in a constant array of pointers. Since no registration is necessary now, this removes some global state from lavf. This will also allow the urlprotocol layer caller to limit the available protocols in a simple and flexible way in the following commits.
-
- 02 Feb, 2016 1 commit
-
-
Michael Niedermayer authored
Note to maintainers: update tools Note to maintainers: set a default whitelist for your protocol If that makes no sense then consider to set "none" and thus require the user to specify a white-list for sub-protocols to be opened Note, testing and checking for missing changes is needed Reviewed-by:
Andreas Cadhalpun <andreas.cadhalpun@googlemail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 29 Jan, 2016 1 commit
-
-
Michael Niedermayer authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 20 Jan, 2016 1 commit
-
-
Michael Niedermayer authored
This feature is not know much or used much AFAIK, and it might be helpfull in exploits. No specific case is known where it can be used in an exploit though subsequent commits depend on this commit though Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- 31 Jul, 2015 1 commit
-
-
Stephan Holljes authored
Signed-off-by:
Stephan Holljes <klaxa1337@googlemail.com>
-
- 29 Jun, 2015 1 commit
-
-
Michael Niedermayer authored
This was suggested in the discussion about these functions With this change the functions are available internally but are not part of the public API Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 24 Jun, 2015 1 commit
-
-
Mariusz Szczepańczyk authored
Reviewed-by: Lukasz Marek <lukasz.m.luki2 at gmail.com> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 22 Jun, 2015 1 commit
-
-
Mariusz Szczepańczyk authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 18 Jun, 2015 1 commit
-
-
wm4 authored
Try to reduce user confusion. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 29 May, 2015 1 commit
-
-
Rodger Combs authored
Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 27 Mar, 2015 1 commit
-
-
Lukasz Marek authored
API allows protocol implementations to provide API that allows to list directory content. API is similar to POSIX opendir/readdir/closedir. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 11 Mar, 2015 1 commit
-
-
Diego Biurrun authored
This fixes a number of "assignment from incompatible pointer type" warnings.
-
- 20 Oct, 2014 1 commit
-
-
Michael Niedermayer authored
CC: libav-stable@libav.org Bug-Id: CID 732284
-
- 15 Aug, 2014 1 commit
-
-
Gabriel Dume authored
Signed-off-by:
Diego Biurrun <diego@biurrun.de>
-
- 12 Aug, 2014 1 commit
-
-
Carl Eugen Hoyos authored
-
- 26 Jul, 2014 1 commit
-
-
Diego Biurrun authored
-
- 17 May, 2014 1 commit
-
-
Olivier Langlois authored
Whenever av_gettime() is used to measure relative period of time, av_gettime_relative() is prefered as it guarantee monotonic time on supported platforms. Signed-off-by:
Olivier Langlois <olivier@trillion01.com> Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 30 Mar, 2014 1 commit
-
-
Michael Niedermayer authored
This should have no effect currently as there are no such options yet. Signed-off-by:
Michael Niedermayer <michaelni@gmx.at>
-
- 05 Mar, 2014 1 commit
-
-
Lukasz Marek authored
ffurl_alloc doc says it returns >= 0 in case of success. avio treats non-zero as errors. Signed-off-by:
Lukasz Marek <lukasz.m.luki@gmail.com>
-
- 16 Feb, 2014 1 commit
-
-
Alexander Strasser authored
Make it possible to find out what protocol will be chosen for a given URL. Signed-off-by:
Alexander Strasser <eclipse7@gmx.net>
-
- 30 Oct, 2013 1 commit
-
-
Martin Storsjö authored
This was added in 9b07a2dc as an ABI hack to allow older code built with lavf 52 to register protocols even if the size of the URLProtocol struct was increased. Later, registering protocols from outside of lavf was removed and this workaround isn't needed any longer since lavf 53. This removes an unchecked malloc and a memory leak for the cases when this workaround actually was used - which it hasn't since lavf 53. Signed-off-by:
Martin Storsjö <martin@martin.st>
-
- 29 Oct, 2013 1 commit
-
-
Derek Buitenhuis authored
Signed-off-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com>
-
- 27 Oct, 2013 2 commits
-
-
Luca Barbato authored
-
Derek Buitenhuis authored
Signed-off-by:
Derek Buitenhuis <derek.buitenhuis@gmail.com>
-