On Sun, Oct 02, 2016 at 10:59:31PM -0400, compn wrote:
> vp3 is a decoder written 10+ years ago by a dev who is no longer
> active in ffmpeg.
>
> we have many decoders and encoders (and other code) in ffmpeg that have
> not been audited (to my knowledge).
>
> i know this isnt an excuse for not lo
Le duodi 12 vendémiaire, an CCXXV, wm4 a écrit :
> You could mention that this is due to FFmpeg violating the ABI
> (apparently).
Still, using floats in malloc() looks like a very bad idea, borderline
recipe for disaster. Especially on x86_32.
Regards,
--
Nicolas George
__
2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos :
> New patch attached.
> +Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is supposed
> +to work out-of-the-box.
Is this true or is it just working by accident?
Carl Eugen
___
ffmpeg-devel
Le duodi 12 vendémiaire, an CCXXV, Carl Eugen Hoyos a écrit :
> I suspect I found the responsible code:
> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
Urgh. This is even worse than I imagined. FFmpeg is using undefined
behaviours by calling it without resetting the state, but t
Hello,
This patch is done for performance increase on UHD or above resolution
color space convertions.
Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
source.
To encode these sources with NVENC 10 bits, there is a need to convert
these color spaces to P010.
Before patch
2016-10-03 11:35 GMT+02:00 Ali KIZIL :
> +/* yuv422p10_to_yuv420p */
> +if ((srcFormat == AV_PIX_FMT_YUV422P10 || srcFormat ==
> AV_PIX_FMT_YUVA422P10) &&
> +(dstFormat == AV_PIX_FMT_YUV420P) || srcFormat ==
> AV_PIX_FMT_YUVA420P)
> +c->swscale = yuv422p10ToYuv420pWrapper
On Mon, Oct 3, 2016 at 11:35 AM, Ali KIZIL wrote:
> Hello,
>
> This patch is done for performance increase on UHD or above resolution
> color space convertions.
> Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> source.
> To encode these sources with NVENC 10 bits, there
On Mon, Oct 3, 2016 at 2:36 AM, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos wrote:
>
>> Hi!
>>
>> Attached patch adds a musl section to doc/platform.
>
>
> This is counter-productive... Let's work with the musl-devs and fix their
> libc-alternative?
>
I agr
2016-10-03 12:30 GMT+02:00 Hendrik Leppkes :
> Lets just fix the bugs
Sorry: Which bugs exactly should we just fix?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
>
> Urgh. This is even worse than I imagined. FFmpeg is using undefined
> behaviours by calling it without resetting the state, but this is also
> completely undefined behaviour on their side.
I feel a duty to remind, in the mos
On Mon, Oct 03, 2016 at 12:37:29PM +0200, Carl Eugen Hoyos wrote:
> 2016-10-03 12:30 GMT+02:00 Hendrik Leppkes :
>
> > Lets just fix the bugs
>
> Sorry: Which bugs exactly should we just fix?
>
> Carl Eugen
Please fix the UB in the MMX-code.
Rune
__
2016-10-03 13:28 GMT+03:00 Hendrik Leppkes :
> On Mon, Oct 3, 2016 at 11:35 AM, Ali KIZIL wrote:
> > Hello,
> >
> > This patch is done for performance increase on UHD or above resolution
> > color space convertions.
> > Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> >
2016-10-03 13:06 GMT+03:00 Carl Eugen Hoyos :
> 2016-10-03 11:35 GMT+02:00 Ali KIZIL :
>
> > +/* yuv422p10_to_yuv420p */
> > +if ((srcFormat == AV_PIX_FMT_YUV422P10 || srcFormat ==
> AV_PIX_FMT_YUVA422P10) &&
> > +(dstFormat == AV_PIX_FMT_YUV420P) || srcFormat ==
> AV_PIX_FMT_YUVA4
2016-10-03 13:28 GMT+03:00 Hendrik Leppkes :
> On Mon, Oct 3, 2016 at 11:35 AM, Ali KIZIL wrote:
> > Hello,
> >
> > This patch is done for performance increase on UHD or above resolution
> > color space convertions.
> > Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> >
2016-10-03 12:48 GMT+02:00 Ali KIZIL :
> Yes, Alpha channel is not managed.
>
> So it should be;
>
>> +/* yuv422p10_to_yuv420p */
>> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
>> +(dstFormat == AV_PIX_FMT_YUV420P))
>> +c->swscale = yuv422p10ToYuv420pWrapper;
(Apart from "
2016-10-03 14:09 GMT+03:00 Carl Eugen Hoyos :
> 2016-10-03 12:48 GMT+02:00 Ali KIZIL :
>
> > Yes, Alpha channel is not managed.
> >
> > So it should be;
> >
> >> +/* yuv422p10_to_yuv420p */
> >> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
> >> +(dstFormat == AV_PIX_FMT_YUV420P))
>
Hello,
On Mon, Oct 3, 2016 at 11:38 AM, Carl Eugen Hoyos wrote:
> 2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos :
>
>> New patch attached.
>
>> +Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is
>> supposed
>> +to work out-of-the-box.
>
> Is this true or is it just working by acc
Hi!
2016-10-03 13:05 GMT+02:00 Guillaume POIRIER :
> Hello,
>
> On Mon, Oct 3, 2016 at 11:38 AM, Carl Eugen Hoyos wrote:
>> 2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos :
>>
>>> New patch attached.
>>
>>> +Compilation with @uref{http://www.musl-libc.org/, musl} on x86-64 is
>>> supposed
>>> +to wo
2016-10-03 13:11 GMT+02:00 Ali KIZIL :
> 2016-10-03 14:09 GMT+03:00 Carl Eugen Hoyos :
>
>> 2016-10-03 12:48 GMT+02:00 Ali KIZIL :
>>
>> > Yes, Alpha channel is not managed.
>> >
>> > So it should be;
>> >
>> >> +/* yuv422p10_to_yuv420p */
>> >> +if ((srcFormat == AV_PIX_FMT_YUV422P10) &&
>
2016-10-03 14:39 GMT+03:00 Carl Eugen Hoyos :
> 2016-10-03 13:11 GMT+02:00 Ali KIZIL :
> > 2016-10-03 14:09 GMT+03:00 Carl Eugen Hoyos :
> >
> >> 2016-10-03 12:48 GMT+02:00 Ali KIZIL :
> >>
> >> > Yes, Alpha channel is not managed.
> >> >
> >> > So it should be;
> >> >
> >> >> +/* yuv422p10_to
Hi,
On Mon, Oct 3, 2016 at 7:37 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-10-03 13:05 GMT+02:00 Guillaume POIRIER :
> > Hello,
> >
> > On Mon, Oct 3, 2016 at 11:38 AM, Carl Eugen Hoyos
> wrote:
> >> 2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos :
> >>
> >>> New patch attached.
> >>
> >>> +Compila
Hi,
On Sun, Oct 2, 2016 at 11:04 PM, compn wrote:
> On Sun, 2 Oct 2016 08:29:22 -0400
> "Ronald S. Bultje" wrote:
>
> > I also think we could contact musl developers and see what's going on
> > there. We certainly shouldn't blindly fix this bug by adding an emms
> > in a random place, to me tha
On Mon, Oct 3, 2016 at 1:37 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-10-03 13:05 GMT+02:00 Guillaume POIRIER :
>> Hello,
>>
>> On Mon, Oct 3, 2016 at 11:38 AM, Carl Eugen Hoyos wrote:
>>> 2016-10-03 3:52 GMT+02:00 Carl Eugen Hoyos :
>>>
New patch attached.
>>>
+Compilation with @uref{
On Sat, Oct 01, 2016 at 12:52:53PM +0200, Matthieu Bouron wrote:
> On Fri, Sep 30, 2016 at 07:01:09PM +0200, wm4 wrote:
> > On Fri, 30 Sep 2016 17:51:42 +0100
> > Josh de Kock wrote:
> >
> > > On 30/09/2016 17:34, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron
> > > >
> > > > ---
> > > >
2016-10-03 13:57 GMT+02:00 Hendrik Leppkes :
> The underlying problem is that mmx code is mixed with allocations,
Definitely.
> which seems like an unusual case to begin with
I am not sure if I understand this but one instance is calling radix_sort()
in the dnxhd encoder.
Below is what is need
Hi,
On Mon, Oct 3, 2016 at 8:46 AM, Carl Eugen Hoyos wrote:
> 2016-10-03 13:57 GMT+02:00 Hendrik Leppkes :
>
> > The underlying problem is that mmx code is mixed with allocations,
>
> Definitely.
>
> > which seems like an unusual case to begin with
>
> I am not sure if I understand this but one
> Please just leave the pts stuff as-is, or we'll have to undo these
> changes right in the next merge again, which deprecates pkt_pts and
> favors using AVFrame.pts for decoding as well (less redundant fields).
> Setting both for the time being should not have any negative effects.
Ok, I'll leave
On Mon, Oct 03, 2016 at 12:35:51PM +0300, Ali KIZIL wrote:
> Hello,
>
> This patch is done for performance increase on UHD or above resolution
> color space convertions.
> Some SDI sources provide yuv422p10 for 10bit source and uyvy422 for 8 bit
> source.
> To encode these sources with NVENC 10 bi
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Mon, Oct 03, 2016 at 08:01:05AM -0400, Ronald S. Bultje wrote:
> > Ping on the patch:
> The patch is unlikely to assist in fixing the issue and is likely to cause
> further inflammation. Therefore I would prefer you did not apply the patch
> and also please don't send a new version that is diff
Hi Rune,
On Mon, Oct 3, 2016 at 10:26 AM, wrote:
> On Mon, Oct 03, 2016 at 08:01:05AM -0400, Ronald S. Bultje wrote:
> > > Ping on the patch:
>
> > The patch is unlikely to assist in fixing the issue and is likely to
> cause
> > further inflammation. Therefore I would prefer you did not apply th
On Mon, Oct 03, 2016 at 04:26:50PM +0200, u-9...@aetey.se wrote:
> With all the competence present here, is it really infeasible to improve
> the code structure so that it does not involve the C library in the
> bit-crunching performance critical paths??
Bad wording. Should be: "assembler-implemen
On 02/10/2016 19:46, Adriano Pallavicino wrote:
LGTM. Will apply both patches squashed in a day if there are no further
comments.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 02/10/2016 19:35, Josh de Kock wrote:
Hi Adriano,
We appreciate the patches, but is it possible you could maybe collate
your cosmetic patches and send them as a larger set?
This patch LGTM though, will push tomorrow if no further comments.
Applied.
--
Josh
___
Ronald,
I sincerely appreciate that you are taking the effort to talk to me
and explain your position.
Unfortunately in your messages you consistently ignored a crucial point
and this is the last time I try to retell it:
> On Mon, Oct 3, 2016 at 10:26 AM, wrote:
> > What you are talking about i
On Mon, 3 Oct 2016 17:01:12 +0200
u-9...@aetey.se wrote:
> Ronald,
>
> I sincerely appreciate that you are taking the effort to talk to me
> and explain your position.
>
> Unfortunately in your messages you consistently ignored a crucial point
> and this is the last time I try to retell it:
>
>
Hi,
> On Oct 2, 2016, at 7:14 PM, James Almer wrote:
>
> On 9/27/2016 3:03 PM, James Almer wrote:
>> It's listed as supported in both https://www.webmproject.org/docs/container/
>> and https://matroska.org/technical/specs/index.html
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/matros
On 10/3/2016 12:27 PM, Dave Rice wrote:
> Hi,
>
>> On Oct 2, 2016, at 7:14 PM, James Almer wrote:
>>
>> On 9/27/2016 3:03 PM, James Almer wrote:
>>> It's listed as supported in both https://www.webmproject.org/docs/container/
>>> and https://matroska.org/technical/specs/index.html
>>>
>>> Signed-
Sure.
2016-10-03 16:48 GMT+02:00 Josh de Kock :
> On 02/10/2016 19:35, Josh de Kock wrote:
>
>> Hi Adriano,
>>
>> We appreciate the patches, but is it possible you could maybe collate
>> your cosmetic patches and send them as a larger set?
>>
>> This patch LGTM though, will push tomorrow if no fu
On Mon, 3 Oct 2016 12:45:13 +0200
u-9...@aetey.se wrote:
> > > http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
> >
> > Urgh. This is even worse than I imagined. FFmpeg is using undefined
> > behaviours by calling it without resetting the state, but this is
> > also completely und
On Mon, Oct 03, 2016 at 05:27:19PM +0200, wm4 wrote:
> > Musl merely showed you the problem and now you are suggesting to "document
> > that the messenger with his bad news about our health is no longer welcome".
>
> musl could also choose to abandon its incredibly "clever" hack (that
> makes almo
On Mon, Oct 3, 2016 at 7:24 PM, wrote:
> On Mon, Oct 03, 2016 at 05:27:19PM +0200, wm4 wrote:
>> > Musl merely showed you the problem and now you are suggesting to "document
>> > that the messenger with his bad news about our health is no longer
>> > welcome".
>>
>> musl could also choose to aba
On Mon, Oct 03, 2016 at 07:28:08PM +0200, Hendrik Leppkes wrote:
> > Again: no offence! Standard libraries are just a quite different area,
> > it postulated other skills and presents other implementation challenges
> > than multimedia programming.
>
> Optimized code is the same everywhere, you ju
Hopefully whoever wants to have support for crazy formats can help.
The table in aacenc.h (temporary position) tells the encoder what
to put in the bitstream and how to encode. Problem is, the specifications
dont specify anything. Thats because I've not been able to find any bloody
specifications a
Le duodi 12 vendémiaire, an CCXXV, u-9...@aetey.se a écrit :
> The author of the referred code acts in his actual area of competence
> (C libraries and standards).
>
> The comments here on the C library code and standard compliance come from
> developers having a different competence area (multime
On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> Le duodi 12 vendémiaire, an CCXXV, u-9...@aetey.se a écrit :
> > The author of the referred code acts in his actual area of competence
> > (C libraries and standards).
> >
> > The comments here on the C library code and standard com
Hi,
> Patch attached.
>
> It fixes the fate tests.
> However, there's a slight bug in the encoder in handling the last frame.
> I'll definitely fix it later.
> I hope the patch can be merged in this state.
no. The last frame has to be handled properly before merging happens.
I'm at LinuxCon & EL
Hi,
On Mon, Oct 3, 2016 at 4:11 PM, Clément Bœsch wrote:
> On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > Le duodi 12 vendémiaire, an CCXXV, u-9...@aetey.se a écrit :
> > > The author of the referred code acts in his actual area of competence
> > > (C libraries and standards
On Mon, Oct 03, 2016 at 04:17:00PM -0400, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Oct 3, 2016 at 4:11 PM, Clément Bœsch wrote:
>
> > On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > > Le duodi 12 vendémiaire, an CCXXV, u-9...@aetey.se a écrit :
> > > > The author of the refe
On Fri, 30 Sep 2016, Hendrik Leppkes wrote:
On Fri, Sep 30, 2016 at 11:40 AM, wm4 wrote:
On Fri, 30 Sep 2016 11:29:05 +0200
Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/utils.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/util
On Fri, 30 Sep 2016, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavdevice/openal-dec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavdevice/openal-dec.c b/libavdevice/openal-dec.c
index 0647952..6eb0efe 100644
--- a/libavdevice/openal-dec.c
Hi, I am looking for a developer for hire to help us with an issue
applying a watermark to videos after they are uploaded and converted on
the server. I am the project manager and do not have much technical
information but you will be able to speak with our coders directly. Our
deadline is roug
On Sun, Oct 2, 2016 at 6:22 PM, Hendrik Leppkes wrote:
> On Sat, Oct 1, 2016 at 4:15 PM, Hendrik Leppkes wrote:
>> Decoders have previously not used AVFrame.pts, and with the upcoming
>> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
>> interpration of timestamps.
>> -
On Fri, Sep 30, 2016 at 09:17:54PM +0200, Stephan Holljes wrote:
> Signed-off-by: Stephan Holljes
> ---
> libavformat/aviobuf.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> This fixes doc/examples/http_multiclient.c from segfaulting. Seems like these
> functions
> were forg
On Mon, Oct 03, 2016 at 09:48:47PM +0200, Nicolas George wrote:
> > As bright as the people here are, they land in a foreign area, which
> > accidentally leads to statements like the above.
>
> I am sorry, but an appeal to authority will not cut it in front of real
> arguments.
[Everyone, sorry f
On Mon, Oct 3, 2016 at 3:53 PM, Rostislav Pehlivanov
wrote:
> Hopefully whoever wants to have support for crazy formats can help.
> The table in aacenc.h (temporary position) tells the encoder what
> to put in the bitstream and how to encode. Problem is, the specifications
> dont specify anything.
On Mon, 3 Oct 2016 23:57:32 +0200
u-9...@aetey.se wrote:
please refrain from off topic posts on this mailing list.
bug reports go to trac or ffmpeg-user list.
see http://ffmpeg.org/bugreports.html
"Please do not report your problem on the developer mailing list:"
> You are welcome to learn why
Steven Liu 于2016年10月3日 周一上午7:29写道：
> will push aftet 24 hours
> Steven Liu 于2016年9月26日 周一下午4:05写道：
>
>
> pushed! Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
- Same as V12 except for an empty that shouldn't have been there.
Carlos Fernandez (4):
Adding SCTE-35 CUI codec
SCTE-35 extraction from mpegts
SCTE-35 support in hlsenc
Correct Indentation
libavcodec/avcodec.h| 2 +
libavcodec/codec_desc.c | 6 +
libavformat/Makefile| 2 +-
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavformat/mpegts.c | 47 +--
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index b31d233..932ffc1 100644
--- a/libavformat/mpegts
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavformat/hlsenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 44259ec..83d6881 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -406,
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavcodec/avcodec.h| 2 ++
libavcodec/codec_desc.c | 6 ++
2 files changed, 8 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d72ee07..9064006 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avc
From: Carlos Fernandez
Signed-off-by: Carlos Fernandez
---
libavformat/Makefile | 2 +-
libavformat/hlsenc.c | 108 +--
libavformat/scte_35.c | 527 ++
libavformat/scte_35.h | 86
4 files changed, 701 insertions(+), 22 deleti
Printing the dynamic buffer offset is useless.
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 32d5dcf..501bab2 100644
--- a/libavforma
This patchsets implements the feature requested on ticket #4347.
The first three patches are preparation work. The first one isn't
strictly related to the implementation, but comes in handy
nonetheless.
Patches 4 to 11 can be squashed into a single commit before pushing
if that's prefered, but for
The durations are never written in that situation.
Signed-off-by: James Almer
---
libavformat/matroskaenc.c| 2 +-
tests/fate/matroska.mak | 2 +-
tests/fate/wavpack.mak | 4 ++--
tests/ref/fate/binsub-mksenc | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/l
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 55 ++-
1 file changed, 16 insertions(+), 39 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 501bab2..2f56d61 100644
--- a/libavformat/matroskaenc.c
+++ b/
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 80 +--
tests/ref/fate/rgb24-mkv | 4 +--
tests/ref/lavf/mka| 4 +--
tests/ref/lavf/mkv| 8 ++---
tests/ref/seek/lavf-mkv | 44
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c| 28 +---
tests/fate/matroska.mak | 2 +-
tests/fate/wavpack.mak | 4 ++--
tests/ref/fate/binsub-mksenc | 2 +-
tests/ref/fate/rgb24-mkv | 4 ++--
tests/ref/lav
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 21 +++--
tests/ref/lavf/mkv| 4 ++--
2 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 9687833..c63ecdd
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 11 +++
tests/ref/fate/rgb24-mkv | 4 ++--
tests/ref/lavf/mka| 4 ++--
tests/ref/lavf/mkv| 8
tests/ref/seek/lavf-mkv | 44 ++-
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 38 --
1 file changed, 20 insertions(+), 18 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index d2b158f..9687833 100644
--- a/libavfor
Implements part of ticket #4347
Signed-off-by: James Almer
---
This one got messy because we update Duration tags at the end of the muxing
process, and the entire master needs to be finalized before the CRC32 can be
calculated.
libavformat/matroskaenc.c | 58 +---
Implements part of ticket #4347
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 29 -
tests/ref/fate/rgb24-mkv | 4 ++--
tests/ref/lavf/mkv| 8
3 files changed, 22 insertions(+), 19 deletions(-)
diff --git a/libavformat/matroskaenc.c b/
Finishes implementing ticket #4347
Signed-off-by: James Almer
---
Same situation as Tags, the Duration is updated at the end of the muxing
process.
libavformat/matroskaenc.c | 22 +-
tests/ref/fate/rgb24-mkv | 4 ++--
tests/ref/lavf/mka| 4 ++--
tests/ref/lavf/mk
Attachment tags were being written targetting non-existent streams in the
output file.
Also filter "filename" and "mimetype" entries, as they are standard elements
in the Attachment master.
Signed-off-by: James Almer
---
The fileuid is changed to be four bytes long instead of eight, because the
m
On Sat, Oct 1, 2016 at 10:50 AM, Marton Balint wrote:
>
> Empty line.
Thanks, corrected in V13.
If all OK, can this patchset be merged?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
libavcodec/libmp3lame.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5642264..a1bf122 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -185,7 +185,7 @@ static int mp3lame_e
---
libavformat/mp3enc.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index de63401..48cb0b4 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -111,6 +111,7 @@ typedef struct MP3Conte
Round trip wav->mp3->wav now preserves the correct number of samples.
Remuxing mp3->mp3 with -c:a copy also preserves any existing gapless
metadata in the Info tag.
The code in libmp3lame.c to set AV_PKT_DATA_SKIP_SAMPLES was mostly
copied from libopusenc.c.
Jon Toohill (3):
lavc/libmp3lame: se
Muxers can check AVCodecParameters.initial_padding for the
encoder+decoder delay, and read the AV_PKT_DATA_SKIP_SAMPLES
side data from the last packet for the encoder padding.
This change also fixes the first_discard_sample calculation
which erroneously included the decoder delay. Decoder delay
is
---
libavformat/utils.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3acb260..ce68408 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2524,7 +2524,7 @@ static int has_duration(AVFormatContext *ic
On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
> Decoders have previously not used AVFrame.pts, and with the upcoming
> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
> interpration of timestamps.
I probably misunderstand the commit message but
If code
Hi,
On Tue, Oct 4, 2016 at 1:53 AM, Thilo Borgmann wrote:
> Hi,
>
>> Patch attached.
>>
>> It fixes the fate tests.
>> However, there's a slight bug in the encoder in handling the last frame.
>> I'll definitely fix it later.
>> I hope the patch can be merged in this state.
>
> no. The last frame
---
ffprobe.c | 13 +
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-simple1-l
---
libavcodec/utils.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 6f4df93..a0931c6 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -3228,6 +3228,21 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *e
---
libavcodec/h264_parser.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 3ed7d77..bca0071 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -61,6 +61,7 @@ typedef struct H264Par
Some codecs set this in the parser, but not the decoder
---
libavcodec/parser.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/parser.c b/libavcodec/parser.c
index 2c8fc69..30cfc55 100644
--- a/libavcodec/parser.c
+++ b/libavcodec/parser.c
@@ -182,6 +182,11 @@ int av_parser_pa
On 10/2/2016 6:56 PM, wm4 wrote:
> Some API users (in particular ffmpeg.c) check the best effort timestamp
> only.
> ---
> Still undecided if this is the right approach.
> ---
> libavcodec/utils.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/utils.c b/
On 10/3/2016 11:09 PM, chuck wrote:
> Hi, I am looking for a developer for hire to help us with an issue
> applying a watermark to videos after they are uploaded and converted on
> the server. I am the project manager and do not have much technical
> information but you will be able to speak with o
On Mon, Oct 03, 2016 at 11:49:39PM -0500, Rodger Combs wrote:
> ---
> ffprobe.c | 13 +
> tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
> tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
> tests/ref/fate/concat-demuxe
Hi, I'm using ffmpeg dxva2 implementation (ffmpeg_dxva2.c) to render mp4
video to a DX texture.
The crash happens when closing my application, when I call to
av_frame_free() to the last frame I've created to decompress video. The
hwcontext references go to 0 and internal structs start to free its
On Tue, Oct 4, 2016 at 4:05 AM, Michael Niedermayer
wrote:
> On Sat, Oct 01, 2016 at 04:15:45PM +0200, Hendrik Leppkes wrote:
>> Decoders have previously not used AVFrame.pts, and with the upcoming
>> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
>> interpration of tim
93 matches
Mail list logo
