Currently, the DASH demuxer omits the final segment for a non-live
stream (using SegmentTemplate) if it is shorter than the other segments.
Correct calc_max_seg_no to round up when calulating the number of
segments instead of rounding down to resolve this issue.
Signed-off-by: Matt Robinson
---
Fixes:
src/libavcodec/tiff.c: In function ‘tiff_unpack_strip’:
src/libavcodec/tiff.c:280: error: ‘always_inline’ function could not be inlined
in call to ‘dng_blit’: the function body must appear before caller
src/libavcodec/tiff.c:720: error: called from here
---
libavcodec/tiff.c | 6 +++---
1
On Tue, Mar 23, 2021 at 12:47 AM Lynne wrote:
>
> As discussed during the last developer meeting, I am in need of new hardware
> to
> work on Vulkan filtering, hwcontext, AV1 VAAPI decoding, new assembly and
> general development on FFmpeg and projects involving the FFmpeg libraries.
>
> I was re
LGTM
On Mon, Mar 22, 2021 at 11:47 PM Lynne wrote:
> As discussed during the last developer meeting, I am in need of new
> hardware to
> work on Vulkan filtering, hwcontext, AV1 VAAPI decoding, new assembly and
> general development on FFmpeg and projects involving the FFmpeg libraries.
>
> I wa
On 3/29/2021 2:35 PM, Andreas Rheinhardt wrote:
James Almer:
On 3/29/2021 2:20 PM, Andreas Rheinhardt wrote:
James Almer:
On 3/29/2021 2:12 PM, Andreas Rheinhardt wrote:
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet
James Almer:
> On 3/29/2021 2:20 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 3/29/2021 2:12 PM, Andreas Rheinhardt wrote:
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet2() to
allocate exactly this a
On 3/29/2021 2:20 PM, Andreas Rheinhardt wrote:
James Almer:
On 3/29/2021 2:12 PM, Andreas Rheinhardt wrote:
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet2() to
allocate exactly this amount. This avoids a memcpy later
James Almer:
> On 3/29/2021 2:12 PM, Andreas Rheinhardt wrote:
>> AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
>> so one can use the min_size parameter of ff_alloc_packet2() to
>> allocate exactly this amount. This avoids a memcpy later in
>> av_packet_make_refcounted() in enc
On 3/29/2021 2:12 PM, Andreas Rheinhardt wrote:
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet2() to
allocate exactly this amount. This avoids a memcpy later in
av_packet_make_refcounted() in encode_simple_internal().
S
AC-3 and EAC-3 are codecs whose packet sizes are known in advance,
so one can use the min_size parameter of ff_alloc_packet2() to
allocate exactly this amount. This avoids a memcpy later in
av_packet_make_refcounted() in encode_simple_internal().
Signed-off-by: Andreas Rheinhardt
---
Is there act
Since the very beginning (since de6d9b6404bfd1c589799142da5a95428f146edd)
the AC-3 encoder used AC3_MAX_CODED_FRAME_SIZE (namely 3840) for the
size of the output buffer (without any check at all).
This causes problems when encoding EAC-3 for which the maximum is too small,
smaller than the actual s
On 3/29/2021 10:20 AM, Nicolas George wrote:
James Almer (12021-03-29):
Can this be done? id3v2 attached pics for many formats are handled by the
generic demux code in avformat_open_input() and not by the actual demuxer.
And in demuxers like asf, it seems to be done in read_header().
Would seeki
James Almer (12021-03-29):
> Can this be done? id3v2 attached pics for many formats are handled by the
> generic demux code in avformat_open_input() and not by the actual demuxer.
> And in demuxers like asf, it seems to be done in read_header().
> Would seeking be able to fetch these pictures again
Specifically test that the WebVTT flavour is correctly mapped to
the Matroska/WebM CodecID and back; and test that dispositions
unsupported by WebM are discarded even when they would be supported
by Matroska.
Signed-off-by: Andreas Rheinhardt
---
tests/fate/matroska.mak | 10 +++
tests
On 3/29/2021 9:57 AM, Nicolas George wrote:
James Almer (12021-03-29):
The idea for attached_pic afaik was that it's always available and easily
accessible to the user from the start, instead of just the one time the
demuxing process would return it in an av_read_frame() call.
The doxy for AV_DI
Signed-off-by: Andreas Rheinhardt
---
fftools/ffprobe.c | 5 +
.../ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
.../fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
.../ref/fate/concat-demuxer-simple1-lavf-mxf | 4 ++--
.../fate/concat-demuxer-simple1-la
James Almer (12021-03-29):
> The idea for attached_pic afaik was that it's always available and easily
> accessible to the user from the start, instead of just the one time the
> demuxing process would return it in an av_read_frame() call.
> The doxy for AV_DISPOSITION_ATTACHED_PIC even mentions th
On 3/29/2021 6:46 AM, Andreas Rheinhardt wrote:
James Almer:
As a replacement for attached_pic, which is in turn deprecated and scheduled
for removal.
Signed-off-by: James Almer
---
TODO: APIChanges entry and version bump.
Decided to use the name apic for the field, since it's how id3v2 and o
On 3/29/2021 4:38 AM, Nicolas George wrote:
Lynne (12021-03-29):
Personally I don't really like 'apic'. Maybe 'pic_attachment' or
'attachment_pic'?
By the way, do we want it to be a field?
Attached pictures can be quite big. Do we want them to stay in AVStream
forever, even when the applicat
Quoting Michael Niedermayer (2021-03-15 09:47:43)
> Suggested-by: Andreas Rheinhardt
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/common.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavutil/common.h b/libavutil/common.h
> index aee353d399..c2d47a45b4 100644
> --- a/li
James Almer:
> As a replacement for attached_pic, which is in turn deprecated and scheduled
> for removal.
>
> Signed-off-by: James Almer
> ---
> TODO: APIChanges entry and version bump.
>
> Decided to use the name apic for the field, since it's how id3v2 and other
> formats call it.
>
> Also,
Also removes a stack packet.
Signed-off-by: Andreas Rheinhardt
---
libavformat/asf.c | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/libavformat/asf.c b/libavformat/asf.c
index 204355abab..cef0f9f646 100644
--- a/libavformat/asf.c
+++ b/libavformat/asf.c
@@
Both function to read attached pictures coincide since
e83f27a21a6d2f602b55e541ef66e365400e9827 (save for some log messages
in case av_dict_set failed).
Signed-off-by: Andreas Rheinhardt
---
How nice it would be if there were consensus on which of the demuxers is
better!
libavformat/asf.c
Signed-off-by: Andreas Rheinhardt
---
mov chapter tracks are not compatible with this.
libavformat/internal.h | 3 +++
libavformat/utils.c| 9 +++--
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/internal.h b/libavformat/internal.h
index b3c5d8a1d5..a6987619f
All instances of adding attached pictures to a stream or adding
a stream and an attached packet to said stream have several things
in common like setting the index and flags of the packet, setting
the stream disposition etc. This commit therefore factors this out.
Signed-off-by: Andreas Rheinhardt
Lynne (12021-03-29):
> Personally I don't really like 'apic'. Maybe 'pic_attachment' or
> 'attachment_pic'?
By the way, do we want it to be a field?
Attached pictures can be quite big. Do we want them to stay in AVStream
forever, even when the application has already finished using them, or
does
26 matches
Mail list logo
