Le sextidi 6 floréal, an CCXXIV, Andrey Utkin a écrit :
> Please look at my email in ffmpeg-devel
> '[PATCH] concatdec: Fix handling of H.264 in MP4 in case of "-auto_convert 0"'
> it adds a check which allows to correctly handle both cases.
I will be able to look at this patch when it arrives, no
From: Andreas Weis
Signed-off-by: Andreas Weis
---
libavutil/log.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/libavutil/log.c b/libavutil/log.c
index 0efba7a..6d192b6 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -444,6 +444,17 @@ void avpriv_rep
From: Andreas Weis
The new function behaves the same as av_log_format_line, but also forwards
the return value from the underlying snprintf call. This will allow
callers to accurately determine the size requirements for the line buffer.
Signed-off-by: Andreas Weis
---
libavutil/log.c | 11
On Sun, Apr 24, 2016 at 11:55:06AM -0700, Dave Yeo wrote:
> On 04/23/16 12:53 PM, Michael Niedermayer wrote:
> >On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote:
> >>>On 04/20/16 03:48 PM, Dmitriy Kuminov wrote:
> >I do care about consistency, collaboration and prevention of artificial
On Sun, Apr 24, 2016 at 11:27:32AM +0100, Mark Thompson wrote:
> On 24/04/16 03:53, Michael Niedermayer wrote:
> > 0x47 is expected to be at [0] but the affected files contain something
> > else sometimes in its place that starts with 0x80 and is 12 bytes long
> > it contains some counter or timest
Jan Ekström gmail.com> writes:
> Fixes #4637
Thank you!
Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sun, Apr 24, 2016 at 05:26:33PM +0200, Nicolas George wrote:
> Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
> > Removing this causes failures when concatdec is used to concat two H.264
> > streams from an MP4 source, when remuxed, IIRC.
> >
> > Example: https://trac.ffmpeg.org/ra
On 04/23/16 12:53 PM, Michael Niedermayer wrote:
On Wed, Apr 20, 2016 at 11:15:39PM -0700, Dave Yeo wrote:
>On 04/20/16 03:48 PM, Dmitriy Kuminov wrote:
> >I do care about consistency, collaboration and prevention of artificial
> >entropy growth.
>
>One option is to make ln_s a configure optio
On 4/24/2016 4:26 PM, Nicolas George wrote:
> That may be true, but the fix is incorrect, and should not have sneaked
> during a completely unrelated merge. For the sake of tracking changes, I
> want to revert this, and then look for a more correct fix.
The fix was deemed OK at the time by a few o
Le sextidi 6 floréal, an CCXXIV, Derek Buitenhuis a écrit :
> Removing this causes failures when concatdec is used to concat two H.264
> streams from an MP4 source, when remuxed, IIRC.
>
> Example: https://trac.ffmpeg.org/raw-attachment/ticket/3108/examplefiles.zip
>
> ./ffmpeg -f concat -i ticke
On 4/24/2016 3:39 PM, Nicolas George wrote:
> Clearing the extradata is not related to the codecpar change,
> and it breaks if auto_convert is disabled.
>
> Fix trac ticket #5461.
>
> Signed-off-by: Nicolas George
> ---
> libavformat/concatdec.c | 5 -
> 1 file changed, 5 deletions(-)
Remo
Functionality used before didn't widen the values from limited to
full range. Additionally, now the decoder uses BT.709 where it
should be used according to the video resolution.
Default for not yet set colorimetry is BT.709 due to most observed
HDMV content being HD.
BT.709 coefficients were gat
Clearing the extradata is not related to the codecpar change,
and it breaks if auto_convert is disabled.
Fix trac ticket #5461.
Signed-off-by: Nicolas George
---
libavformat/concatdec.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
ind
Hi,
please excuse me, that I bother you with this old version of ffmpeg, however,
javafx 8 requires libavcodec53 and libavformat53 on linux systems, which, as
far as I know, requires that I compile ffmpeg 0.10.16. (My linux distribution
provides only more recent versions of these libraries.)
U
On Sun, Apr 24, 2016 at 04:28:38PM +0300, Andrey Utkin wrote:
> Bug ticket: http://trac.ffmpeg.org/ticket/5461
> This fix enables back the ability to concat appropriately encoded
> (with "-x264opts stitchable=1") MP4 files in less time, without conversion to
> mpegts and back.
> ---8<---
s/mpegts/
On 24/04/16 03:53, Michael Niedermayer wrote:
> 0x47 is expected to be at [0] but the affected files contain something
> else sometimes in its place that starts with 0x80 and is 12 bytes long
> it contains some counter or timestamp
> without the code above it will almost always work but if the coun
16 matches
Mail list logo
