- 05 1月, 2015 5 次提交
-
-
由 Vittorio Giovara 提交于
CC: libav-stable@libav.org Bug-Id: CID 1257771
-
由 Martin Storsjö 提交于
Being able to write editlists properly is one of the main points in the delay_moov flag. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
CC: libav-stable@libav.org Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This comment can be traced back to the initial commit from 2001, and it seemed to be misleading/incorect already back then. (It was used for normal, non-raw file formats already then.) Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This allows using libraries that are detected via pkg-config with msvc. (The libraries themselves may have to be built with MSVC though.) Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 04 1月, 2015 1 次提交
-
-
由 Johan Andersson 提交于
Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 03 1月, 2015 10 次提交
-
-
由 Martin Storsjö 提交于
There shouldn't be any need to add the loaded libraries to the global symbol namespace. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
When we don't adjust the Period start time, we don't need to parse the earliest_presentation_time from the sidx boxes either. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This was only necessary to get playback to start with dash.js 1.2.0, it has been fixed in the git version. The previous behaviour was incorrect - the Period's start time is irrespective of the actual first timestamp of the contents within the period. The Period start time only says when, within the global timeline, this particular piece should start to be played back. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This should be more correct. This also should give more sensible switching between video streams with different amount of b-frame delay. The current dash.js release (1.2.0) fails to start playback of such files from the start (if the start pts is > 0), but this has been fixed in the current git version of dash.js. Also enable the use of edit lists, so that streams in many cases start at pts=0. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Use the more generic approach with the delay_moov flag, instead of having a update mechanism specific to this one single atom. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This delays writing the moov until the first fragment is written, or can be flushed by the caller explicitly when wanted. If the first sample in all streams is available at this point, we can write a proper editlist at this point, allowing streams to start at something else than dts=0. For AC3 and DNXHD, a packet is needed in order to write the moov header properly. This isn't added to the normal behaviour for empty_moov, since the behaviour that ftyp+moov is written during avformat_write_header would be changed. Callers that split the output stream into header+segments (either by flushing manually, with the custom_frag flag set, or by just differentiating between data written during avformat_write_header and the rest) will need to be adjusted to take this option into use. For handling streams that start at something else than dts=0, an alternative would be to use different kinds of heuristics for guessing the start dts (using AVCodecContext delay or has_b_frames together with the frame rate), but this is not reliable and doesn't necessarily work well with stream copy, and wouldn't work for getting the right initialization data for AC3 or DNXHD either. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This allows writing edit lists even when track->entry == 0, if the start times have been set. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
If fragments == 0 it means we haven't written any moov atom yet. If the empty_moov flag is set, we already have written an empty moov atom at startup. Thus, the check for empty_moov is redundant. This is in preparation for allowing writing the moov atom later, even when using the empty moov flag. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 30 12月, 2014 3 次提交
-
-
由 Martin Storsjö 提交于
Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
When writing an explicit time, reset the cur_time variable to this value as well. This avoids writing excessive time attributes for each segment in the timeline, as long as the segments are continuous. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
This fixes fate on e.g. ppc. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 27 12月, 2014 1 次提交
-
-
由 Anton Khirnov 提交于
CC: libav-stable@libav.org Bug-ID: 781
-
- 26 12月, 2014 7 次提交
-
-
由 Rémi Denis-Courmont 提交于
Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
Since the VDPAU pixel format does not distinguish between different VDPAU video surface chroma types, we need another way to pass this data to the application. Originally VDPAU in libavcodec only supported decoding to 8-bits YUV with 4:2:0 chroma sampling. Correspondingly, applications assumed that libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output. However some of the new HEVC profiles proposed for addition to VDPAU would require different depth and/or sampling: http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html ...as would lossless AVC profiles: http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html To preserve backward binary compatibility with existing applications, a new av_vdpau_bind_context() flag is introduced in a further change. Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
This can be used by the application to signal its ability to cope with video surface of types other than 8-bits YUV 4:2:0. Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
This carries the pixel format that would be used if it were not for hardware acceleration. This is equal to AVCodecContext.pix_fmt if hardware acceleration is not in use. Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Rémi Denis-Courmont 提交于
This is to avoid proliferation of similar tables in following changes. Signed-off-by: NRémi Denis-Courmont <remi@remlab.net> Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
- 20 12月, 2014 5 次提交
-
-
由 Kieran Kunhya 提交于
Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Martin Storsjö 提交于
The MoveFileExA is available in the headers regardless which API subset is targeted, but it is missing in the Windows Phone link libraries. When targeting Windows Store apps, the function is available both in the headers and in the link libraries, and thus there is no indication for the build system that this function should be avoided - such an indication is only given by the Windows App Certification Kit, which forbids using the MoveFileExA function. Therefore check the WINAPI_FAMILY defines instead, to figure out which API subset is targeted. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Since the mpegts muxer now can handle being called with a NULL AVIOContext, we don't need to try to allocate one before calling write_trailer. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
If opening and closing dynamic buffers as AVIOContext, we may not have any AVIOContext available when wanting to close and deallocate the muxer. Allow calling write_trailer despite this. Signed-off-by: NMartin Storsjö <martin@martin.st>
-
由 Martin Storsjö 提交于
Signed-off-by: NMartin Storsjö <martin@martin.st>
-
- 19 12月, 2014 8 次提交
-
-
由 Michael Niedermayer 提交于
Fixes invalid memory access. CC: libav-stable@libav.org Bug-ID: CVE-2014-8549 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Michael Niedermayer 提交于
Fixes invalid writes when there are more blocks in a run than total remaining blocks. CC: libav-stable@libav.org Bug-ID: CVE-2014-8548 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Michael Niedermayer 提交于
Fixes invalid writes with very small image heights. CC: libav-stable@libav.org Bug-ID: CVE-2014-8547 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind Signed-off-by: NAnton Khirnov <anton@khirnov.net>
-
由 Anton Khirnov 提交于
The frame size must be set by the caller and each dimension must be a multiple of 2. CC: libav-stable@libav.org Bug-ID: CVE-2014-8543 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
-
由 Anton Khirnov 提交于
The frame size must be set by the caller and each dimension must be a multiple of 8. CC: libav-stable@libav.org Bug-ID: CVE-2014-8542 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
-
由 Anton Khirnov 提交于
Fixes possible invalid memory access. Based on code by Michael Niedermayer <michaelni@gmx.at> CC: libav-stable@libav.org Bug-ID: CVE-2014-8541 Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
-
由 Anton Khirnov 提交于
CC: libav-stable@libav.org Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
-
由 Vittorio Giovara 提交于
-