Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-06 Thread Thomas Guillem 

On Fri, Jul 6, 2018, at 09:21, Kári Helgason wrote:
> Sorry for jumping in with a slightly OT question,
> 
> Am I understanding correctly that you have noticed that when using kVTCompre
> ssionPropertyKey_DataRateLimits you will sometimes get random garbage from
> the encoder in the output callback?

Not garbage, but the output callback will be called with a 0 error_status (OK 
then) but without any sample_buffer.
Then, a crash within the VT lib will follow.

> 
> How frequently does this happen, and can you reproduce it reliably, or do
> you only see it in production?
> 
> Has a radar been filed with Apple about this?

This issue doesn't reproduce on the iOS 12 beta (with the same device), so I 
guess they are aware or it has been fixed.

> 
> On Wed, Jul 4, 2018 at 1:44 PM Thomas Guillem  wrote:
> 
> > On Wed, Jul 4, 2018, at 09:05, Thomas Guillem wrote:
> > > On macOS, a zero rc_max_rate cause an error from
> > > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> > >
> > > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > > arguments from the vtenc_output_callback after few frames and then a
> > crash
> > > within the VideoToolbox library.
> >
> > In fact, when setting a correct max_rate on iOS, you could still get
> > random crashes the same way. It's happening on ios 11.4 but seems to be OK
> > on iOS 12 Beta.
> >
> > > ---
> > >  libavcodec/videotoolboxenc.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > > index ac847358ab..aa9aae7e05 100644
> > > --- a/libavcodec/videotoolboxenc.c
> > > +++ b/libavcodec/videotoolboxenc.c
> > > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> > >
> > >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> > >  // kVTCompressionPropertyKey_DataRateLimits is not available
> > > for HEVC
> > > +if (max_rate > 0) {
> > >  bytes_per_second_value = max_rate >> 3;
> > >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> > >kCFNumberSInt64Type,
> > > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> > > *avctx,
> > >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > > property: %d\n", status);
> > >  return AVERROR_EXTERNAL;
> > >  }
> > > +}
> > >
> > >  if (profile_level) {
> > >  status = VTSessionSetProperty(vtctx->session,
> > > --
> > > 2.18.0
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavc/hevc_ps: use skip_bits instead of get_bits when skip bits.

2018-07-06 Thread Jun Zhao 
use skip_bits when want to skip some bits.

Signed-off-by: Jun Zhao 
---
 libavcodec/hevc_ps.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index bc5406b..278b928 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1679,7 +1679,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb, 
AVCodecContext *avctx,
 
 if (get_bits1(gb)) { // pps_extension_present_flag
 int pps_range_extensions_flag = get_bits1(gb);
-/* int pps_extension_7bits = */ get_bits(gb, 7);
+skip_bits(gb, 7);
 if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT && 
pps_range_extensions_flag) {
 if ((ret = pps_range_extensions(gb, avctx, pps, sps)) < 0)
 goto err;
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-06 Thread Thomas Guillem 


On Thu, Jul 5, 2018, at 20:49, Aman Gupta wrote:
> On Wed, Jul 4, 2018 at 3:05 AM Thomas Guillem  wrote:
> 
> > On macOS, a zero rc_max_rate cause an error from
> > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> >
> > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > arguments from the vtenc_output_callback after few frames and then a crash
> > within the VideoToolbox library.
> > ---
> >  libavcodec/videotoolboxenc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index ac847358ab..aa9aae7e05 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> >
> >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> >  // kVTCompressionPropertyKey_DataRateLimits is not available for
> > HEVC
> > +if (max_rate > 0) {
> 
> 
> I think it would be better to add this condition to the existing if block
> above so we can avoid another level of indentation.

That's what I first wanted to do but there is a also a profile level in this 
code block.

> 
> Patch looks fine to me otherwise. I can make this change and commit this
> week.
> 
> Aman
> 
> 
> >  bytes_per_second_value = max_rate >> 3;
> >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> >kCFNumberSInt64Type,
> > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> >  *avctx,
> >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > property: %d\n", status);
> >  return AVERROR_EXTERNAL;
> >  }
> > +}
> >
> >  if (profile_level) {
> >  status = VTSessionSetProperty(vtctx->session,
> > --
> > 2.18.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavc/hevc_ps: Refine sps_range_extension parse.

2018-07-06 Thread Jun Zhao 
Signed-off-by: Jun Zhao 
---
 libavcodec/hevc_ps.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index bca3abb..bc5406b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1094,11 +1094,9 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb, 
unsigned int *sps_id,
 decode_vui(gb, avctx, apply_defdispwin, sps);
 
 if (get_bits1(gb)) { // sps_extension_flag
-int sps_extension_flag[1];
-for (i = 0; i < 1; i++)
-sps_extension_flag[i] = get_bits1(gb);
+int sps_range_extension_flag = get_bits1(gb);
 skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
-if (sps_extension_flag[0]) {
+if (sps_range_extension_flag) {
 int extended_precision_processing_flag;
 int cabac_bypass_alignment_enabled_flag;
 
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/setpts: add FR shorthand for FRAME_RATE

2018-07-06 Thread Gyan Doshi 


Plan to push tonight if no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Use channel count if channel layout is undefined

2018-07-06 Thread Michael Niedermayer 
On Fri, Jul 06, 2018 at 03:15:58PM +0100, Marcin Gorzel wrote:
> Rematrixing supports up to 64 channels but there is only a limited number of 
> channel layouts defined. Currently, in/out channel count is obtained from the 
> channel layout so if the channel layout is undefined (e.g. for 9, 10, 11 
> channels etc.) the in/out channel count will be 0 and the rematrixing will 
> fail. This change adds a check if the channel layout is non-zero, and if not, 
> prefers to use the in|out_ch_count instead. This seems to be related to 
> ticket #6790.
> ---
>  libswresample/rematrix.c  | 18 --
>  libswresample/x86/rematrix_init.c |  8 ++--
>  2 files changed, 18 insertions(+), 8 deletions(-)

Iam not completely sure what this is trying to do exactly
but the commit message inadequently describes it.

#6790 is already fixed, the commit message doesnt explain how its related

also the FFMIN is wrong. If the user provided a value outside
the supported range the code must have failed with an error
already or something is not working correctly.

How can the bug this fixes be reproduced ?

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Check input sample count

2018-07-06 Thread Michael Niedermayer 
On Fri, Jul 06, 2018 at 02:24:45PM -0700, Baptiste Coudurier wrote:
> Hi Michael,
> 
> On Fri, Jul 6, 2018 at 2:09 PM, Michael Niedermayer 
> wrote:
> 
> > Fixes: division by 0
> > Fixes: fpe_movenc.c_199_1.wav
> > Fixes: fpe_movenc.c_199_2.wav
> > Fixes: fpe_movenc.c_199_3.wav
> > Fixes: fpe_movenc.c_199_4.wav
> > Fixes: fpe_movenc.c_199_5.wav
> > Fixes: fpe_movenc.c_199_6.wav
> > Fixes: fpe_movenc.c_199_7.wav
> >
> > Found-by: #CHEN HONGXU# 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/movenc.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> > index fe0a244a8f..78291a9adc 100644
> > --- a/libavformat/movenc.c
> > +++ b/libavformat/movenc.c
> > @@ -5269,6 +5269,11 @@ int ff_mov_write_packet(AVFormatContext *s,
> > AVPacket *pkt)
> >  else
> >  samples_in_chunk = 1;
> >
> > +if (samples_in_chunk < 1) {
> > +av_log(s, AV_LOG_ERROR, "fatal error, input packet contains no
> > samples\n");
> > +return AVERROR_PATCHWELCOME;
> > +}
> > +
> 
> 
> Since "samples_in_chunk" is set to 1 just above, maybe the check can be
> moved earlier ?

the code before the else contains a few else if()
from a quick look it seems plausible that multiple could reach 
samples_in_chunk=0


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mxfdec: only call mxf_free_metadataset when ctx_size is != 0, otherwise ctx == mxf

2018-07-06 Thread Michael Niedermayer 
On Fri, Jul 06, 2018 at 12:08:07PM -0700, Baptiste Coudurier wrote:
> ---
>  libavformat/mxfdec.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

should be ok

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/aacenc: report channel layout by name

2018-07-06 Thread Moritz Barsnick 
Possibly useful in the error case.

Signed-off-by: Moritz Barsnick 
---
 libavcodec/aacenc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
index 6d94c76905..4d0abb107f 100644
--- a/libavcodec/aacenc.c
+++ b/libavcodec/aacenc.c
@@ -982,11 +982,13 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
 }
 
 if (s->needs_pce) {
+char buf[64];
 for (i = 0; i < FF_ARRAY_ELEMS(aac_pce_configs); i++)
 if (avctx->channel_layout == aac_pce_configs[i].layout)
 break;
-ERROR_IF(i == FF_ARRAY_ELEMS(aac_pce_configs), "Unsupported channel 
layout\n");
-av_log(avctx, AV_LOG_INFO, "Using a PCE to encode channel layout\n");
+av_get_channel_layout_string(buf, sizeof(buf), -1, 
avctx->channel_layout);
+ERROR_IF(i == FF_ARRAY_ELEMS(aac_pce_configs), "Unsupported channel 
layout \"%s\"\n", buf);
+av_log(avctx, AV_LOG_INFO, "Using a PCE to encode channel layout 
\"%s\"\n", buf);
 s->pce = aac_pce_configs[i];
 s->reorder_map = s->pce.reorder_map;
 s->chan_map = s->pce.config_map;
-- 
2.14.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfdec: demux s436m as eia608 subtitle track

2018-07-06 Thread Baptiste Coudurier 
Hi Derek,

On Wed, Jul 4, 2018 at 3:54 PM, Derek Buitenhuis  wrote:

> On 04/07/2018 23:05, Baptiste Coudurier wrote:
> > +if (length < 0)
> > +return AVERROR_INVALIDDATA;
> > +
> > +int array_count = avio_rb32(s->pb);
> > +int array_elem_size = avio_rb32(s->pb);
>
> Mixed declarations aren't allowed in FFmpeg.
>

True, forgot about that. I'm addressing this in the next update.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 3/3] aadec: fix seeking in mp3 content

2018-07-06 Thread Michael Niedermayer 
On Fri, Jul 06, 2018 at 10:49:46AM +0200, Karsten Otto wrote:
> 
> > Am 04.07.2018 um 23:54 schrieb Michael Niedermayer :
> > 
> > Signierter PGP-Teil
> > On Wed, Jul 04, 2018 at 09:32:32AM +0200, Karsten Otto wrote:
> >> 
> >>> Am 04.07.2018 um 03:26 schrieb Michael Niedermayer 
> >>> :
> >>> 
> >>> Signierter PGP-Teil
> >>> On Tue, Jul 03, 2018 at 10:25:36PM +0200, Karsten Otto wrote:
>  TL;DR: I will drop patch 3/3, may rather spend some time investigating 
>  why
>  "ff ee 47 9d“ passes the mp3 header parser. Also, the aa file "index" 
>  cannot
>  be used for frame or chapter detection, unfortunately.
>  
>  More details inline below.
>  
> > Am 03.07.2018 um 02:32 schrieb Michael Niedermayer 
> > :
> > 
> > Signierter PGP-Teil
> > On Mon, Jul 02, 2018 at 07:21:43PM +0200, Karsten Otto wrote:
> >> 
> >>> Am 02.07.2018 um 10:59 schrieb Michael Niedermayer 
> >>> :
> >>> 
> >>> Signierter PGP-Teil
> >>> On Thu, Jun 21, 2018 at 06:58:26PM +0200, Karsten Otto wrote:
>  MP3 frames may not be aligned to aa chunk boundaries. After seeking,
>  scan for the next valid frame header. Then truncate the packet, and
>  also adjust timestamp information accordingly.
>  ---
>  libavformat/aadec.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)
> >>> 
> >>> Please see AVSTREAM_PARSE_TIMESTAMPS
> >>> 
> >>> This codec specific code in demuxers should not be needed
> >>> 
> >> I tried that before, and you are right that it takes care of timestamp 
> >> adjustments.
> >> 
> >> However, after a seek the parsed packet still contains a partial frame 
> >> before the
> >> next full one. I had expected libavformat/mpegaudio_parser.c to detect 
> >> this
> >> situation and discard the fragment, but unfortunately it does not. 
> >> Instead it passes
> >> it unchanged to the codec, which plays it as a pop or even a very ugly 
> >> BLEEEP -
> >> painful while wearing headphones!
> > 
> > I think you mis-diagnose this at least somewhat
> > your code searches for a specific mp3 header, the parser and decoder 
> > would
> > accept a wider range of mp3 variants.
> > But both can choose points that are not mp3 frame starts. (if that is 
> > the
> > problem you are seeing, iam not completely sure it is)
> > 
>  It took a closer look at what happens when I hear a BLEEP: The packet 
>  begins
>  with a partial frame, starting with the byte sequence "ff ee 47 9d“. 
>  Unfortunately,
>  the mp3 parser indeed accepts this as a valid mp3 header, causing the 
>  noise.
>  By looking for the more restricted header, my patch finds the real next 
>  frame at
>  offset 78.
>  
>  BTW: Should this sequence actually pass? AFAIK 01 is not a valid MPEG 
>  audio
>  version ID?
>  
> > Also is the more restricted header you search for always used or could
> > this be failing with some files ?
> > 
>  Good question. So far, all mp3 aa files I tested with matched the format 
>  (MPEG 2
>  Layer III at 32 kbps and 22kHz). I doubt there are other variants, but 
>  can’t be sure.
>  
> > Either way, looking at the demuxer a bit deeper, theres a TOC list in 
> > the
> > main header which points to chunks. The one file i found has 12 such 
> > chunks
> > the first represents the whole file i suspect, the next largest the 
> > audio
> > data, another one the metadata.
> > I guess the remaining 2 large ones could be a cover image and an index.
>  Correct, seems like all aa files have the TOC, but its entries can be in 
>  a different
>  order in each file. I guess thats why the original aadec.c 
>  implementation just
>  looks for the largest chunk to play.
>  
> > I didnt really look at it, but theres a table in there with pairs of 
> > 32bit
> > values. the first in the file i have goes from 0 to 3 the second starts
> > multiple times from 0 and seems monotonly increasing and staying within
> > the filesize.
> > The sample i have does not store mp3 but it looks like this is a index
> > maybe offsets for packets in each of the 3 chapters.
> > 
> > Please look at the data, if it can be used. It would be much better than
> > scaning the file linearly and searching for some byte sequence to find
> > packet starts.
> > 
>  Short answer: Sorry, it is not possible to derive frame offsets nor 
>  chapter
>  offsets from the index.
>  
> >>> 
>  Long answer:
>  All offsets in the index are the same, and matching the 
>  "codec_second_size"
>  = crypto chunk size, roughly one second of audio:
>  - 1045 for format 2 (SIPR 8kbps)
>  - 2000 for format 3 (SIPR 16kbps)
>  -

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfdec: demux s436m as eia608 subtitle track

2018-07-06 Thread Baptiste Coudurier 
Hi Michael,

On Thu, Jul 5, 2018 at 5:23 PM, Michael Niedermayer 
wrote:

> On Wed, Jul 04, 2018 at 03:05:58PM -0700, Baptiste Coudurier wrote:
> > ---
> >  libavformat/mxfdec.c | 103 +++
> >  1 file changed, 103 insertions(+)
>
> This crashes with
>
> ./ffmpeg -i /home/michael/tickets//4256/invalid_pointer.mxf
>
> https://trac.ffmpeg.org/raw-attachment/ticket/4256/invalid_pointer.mxf
>
>
Yes, even though the crash is only surfacing with this patch, the issue
already existed before.
Sent a different patch to address the crash.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Check input sample count

2018-07-06 Thread Baptiste Coudurier 
Hi Michael,

On Fri, Jul 6, 2018 at 2:09 PM, Michael Niedermayer 
wrote:

> Fixes: division by 0
> Fixes: fpe_movenc.c_199_1.wav
> Fixes: fpe_movenc.c_199_2.wav
> Fixes: fpe_movenc.c_199_3.wav
> Fixes: fpe_movenc.c_199_4.wav
> Fixes: fpe_movenc.c_199_5.wav
> Fixes: fpe_movenc.c_199_6.wav
> Fixes: fpe_movenc.c_199_7.wav
>
> Found-by: #CHEN HONGXU# 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/movenc.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index fe0a244a8f..78291a9adc 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -5269,6 +5269,11 @@ int ff_mov_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>  else
>  samples_in_chunk = 1;
>
> +if (samples_in_chunk < 1) {
> +av_log(s, AV_LOG_ERROR, "fatal error, input packet contains no
> samples\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +


Since "samples_in_chunk" is set to 1 just above, maybe the check can be
moved earlier ?
It's nitpick though.

-- 
Baptiste Coudurier
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/movenc: Check input sample count

2018-07-06 Thread Michael Niedermayer 
Fixes: division by 0
Fixes: fpe_movenc.c_199_1.wav
Fixes: fpe_movenc.c_199_2.wav
Fixes: fpe_movenc.c_199_3.wav
Fixes: fpe_movenc.c_199_4.wav
Fixes: fpe_movenc.c_199_5.wav
Fixes: fpe_movenc.c_199_6.wav
Fixes: fpe_movenc.c_199_7.wav

Found-by: #CHEN HONGXU# 
Signed-off-by: Michael Niedermayer 
---
 libavformat/movenc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index fe0a244a8f..78291a9adc 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5269,6 +5269,11 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 else
 samples_in_chunk = 1;
 
+if (samples_in_chunk < 1) {
+av_log(s, AV_LOG_ERROR, "fatal error, input packet contains no 
samples\n");
+return AVERROR_PATCHWELCOME;
+}
+
 /* copy extradata if it exists */
 if (trk->vos_len == 0 && par->extradata_size > 0 &&
 !TAG_IS_AVCI(trk->tag) &&
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mxfdec: only call mxf_free_metadataset when ctx_size is != 0, otherwise ctx == mxf

2018-07-06 Thread Baptiste Coudurier 
---
 libavformat/mxfdec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index c7f90b29f2..819e4dfeb9 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -2711,7 +2711,8 @@ static int mxf_read_local_tags(MXFContext *mxf, KLVPacket 
*klv, MXFMetadataReadF
 if (ctx_size && tag == 0x3C0A) {
 avio_read(pb, ctx->uid, 16);
 } else if ((ret = read_child(ctx, pb, tag, size, uid, -1)) < 0) {
-mxf_free_metadataset(, !!ctx_size);
+if (ctx_size)
+mxf_free_metadataset(, 1);
 return ret;
 }
 
@@ -2720,7 +2721,7 @@ static int mxf_read_local_tags(MXFContext *mxf, KLVPacket 
*klv, MXFMetadataReadF
 if (avio_tell(pb) > klv_end) {
 if (ctx_size) {
 ctx->type = type;
-mxf_free_metadataset(, !!ctx_size);
+mxf_free_metadataset(, 1);
 }
 
 av_log(mxf->fc, AV_LOG_ERROR,
-- 
2.17.0 (Apple Git-106)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 01/12] avformat/mxfenc: automatically update descriptors klv size

2018-07-06 Thread Carl Eugen Hoyos 
2018-07-04 20:35 GMT+02:00, Baptiste Coudurier :
> ---
>  libavformat/mxfenc.c | 80 +---
>  1 file changed, 39 insertions(+), 41 deletions(-)

Does any of the patches fix ticket #6693?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avcodec/dvbsub_parser: Do not discard data

2018-07-06 Thread Michael Niedermayer 
May fix: oss fuzz issue 9220

Signed-off-by: Michael Niedermayer 
---
 libavcodec/dvbsub_parser.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/libavcodec/dvbsub_parser.c b/libavcodec/dvbsub_parser.c
index e77b9655cc..8ced3c4c34 100644
--- a/libavcodec/dvbsub_parser.c
+++ b/libavcodec/dvbsub_parser.c
@@ -57,6 +57,7 @@ static int dvbsub_parse(AVCodecParserContext *s,
 DVBSubParseContext *pc = s->priv_data;
 uint8_t *p, *p_end;
 int i, len, buf_pos = 0;
+int out_size = 0;
 
 ff_dlog(avctx, "DVB parse packet pts=%"PRIx64", lpts=%"PRIx64", 
cpts=%"PRIx64":\n",
 s->pts, s->last_pts, s->cur_frame_pts[s->cur_frame_start_index]);
@@ -71,8 +72,8 @@ static int dvbsub_parse(AVCodecParserContext *s,
 if (i % 16 != 0)
 ff_dlog(avctx, "\n");
 
-*poutbuf = NULL;
-*poutbuf_size = 0;
+*poutbuf  = buf;
+*poutbuf_size = buf_size;
 
 s->fetch_timestamp = 1;
 
@@ -89,7 +90,7 @@ static int dvbsub_parse(AVCodecParserContext *s,
 
 if (buf_size < 2 || buf[0] != 0x20 || buf[1] != 0x00) {
 ff_dlog(avctx, "Bad packet header\n");
-return -1;
+return buf_size;
 }
 
 buf_pos = 2;
@@ -113,9 +114,9 @@ static int dvbsub_parse(AVCodecParserContext *s,
 }
 
 if (buf_size - buf_pos + pc->packet_index > PARSE_BUF_SIZE)
-return -1;
+return buf_size;
 
-/* if not currently in a packet, discard data */
+/* if not currently in a packet, pass data */
 if (pc->in_packet == 0)
 return buf_size;
 
@@ -135,7 +136,7 @@ static int dvbsub_parse(AVCodecParserContext *s,
 
 if (len + 6 <= p_end - p)
 {
-*poutbuf_size += len + 6;
+out_size += len + 6;
 
 p += len + 6;
 } else
@@ -159,9 +160,10 @@ static int dvbsub_parse(AVCodecParserContext *s,
 }
 }
 
-if (*poutbuf_size > 0)
+if (out_size > 0)
 {
 *poutbuf = pc->packet_buf;
+*poutbuf_size = out_size;
 pc->packet_start = *poutbuf_size;
 }
 
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: Check for odd progressive RGB

2018-07-06 Thread Michael Niedermayer 
Fixes: out of array access
Fixes: 
9225/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEGLS_fuzzer-5684770334834688

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mjpegdec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 00cfdd7151..5e784d980c 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -626,6 +626,10 @@ unk_pixfmt:
 avpriv_report_missing_feature(s->avctx, "Lowres for weird 
subsampling");
 return AVERROR_PATCHWELCOME;
 }
+if ((AV_RB32(s->upscale_h) || AV_RB32(s->upscale_v)) && s->progressive && 
s->avctx->pix_fmt == AV_PIX_FMT_GBRP) {
+avpriv_report_missing_feature(s->avctx, "progressive for weird 
subsampling");
+return AVERROR_PATCHWELCOME;
+}
 if (s->ls) {
 memset(s->upscale_h, 0, sizeof(s->upscale_h));
 memset(s->upscale_v, 0, sizeof(s->upscale_v));
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Use channel count if channel layout is undefined

2018-07-06 Thread Marcin Gorzel 
Rematrixing supports up to 64 channels but there is only a limited number of 
channel layouts defined. Currently, in/out channel count is obtained from the 
channel layout so if the channel layout is undefined (e.g. for 9, 10, 11 
channels etc.) the in/out channel count will be 0 and the rematrixing will 
fail. This change adds a check if the channel layout is non-zero, and if not, 
prefers to use the in|out_ch_count instead. This seems to be related to ticket 
#6790.
---
 libswresample/rematrix.c  | 18 --
 libswresample/x86/rematrix_init.c |  8 ++--
 2 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index 8227730056..45e84eb2df 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -69,10 +69,12 @@ int swr_set_matrix(struct SwrContext *s, const double 
*matrix, int stride)
 return AVERROR(EINVAL);
 memset(s->matrix, 0, sizeof(s->matrix));
 memset(s->matrix_flt, 0, sizeof(s->matrix_flt));
-nb_in = (s->user_in_ch_count > 0) ? s->user_in_ch_count :
-av_get_channel_layout_nb_channels(s->user_in_ch_layout);
-nb_out = (s->user_out_ch_count > 0) ? s->user_out_ch_count :
-av_get_channel_layout_nb_channels(s->user_out_ch_layout);
+nb_in = s->user_in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->user_in_ch_layout)
+: FFMIN(s->user_in_ch_count, SWR_CH_MAX);
+nb_out = s->user_out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->user_out_ch_layout)
+: FFMIN(s->user_out_ch_count, SWR_CH_MAX);
 for (out = 0; out < nb_out; out++) {
 for (in = 0; in < nb_in; in++)
 s->matrix_flt[out][in] = s->matrix[out][in] = matrix[in];
@@ -384,8 +386,12 @@ av_cold static int auto_matrix(SwrContext *s)
 
 av_cold int swri_rematrix_init(SwrContext *s){
 int i, j;
-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in  = s->in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->in_ch_layout)
+: FFMIN(s->user_in_ch_count, SWR_CH_MAX);
+int nb_out = s->out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->out_ch_layout)
+: FFMIN(s->user_out_ch_count, SWR_CH_MAX);
 
 s->mix_any_f = NULL;
 
diff --git a/libswresample/x86/rematrix_init.c 
b/libswresample/x86/rematrix_init.c
index d71b41a73e..f3363567cd 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -33,8 +33,12 @@ D(int16, sse2)
 av_cold int swri_rematrix_init_x86(struct SwrContext *s){
 #if HAVE_X86ASM
 int mm_flags = av_get_cpu_flags();
-int nb_in  = av_get_channel_layout_nb_channels(s->in_ch_layout);
-int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
+int nb_in  = s->in_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->in_ch_layout)
+: FFMIN(s->user_in_ch_count, SWR_CH_MAX);
+int nb_out = s->out_ch_layout != 0
+? av_get_channel_layout_nb_channels(s->out_ch_layout)
+: FFMIN(s->user_out_ch_count, SWR_CH_MAX);
 int num= nb_in * nb_out;
 int i,j;
 
-- 
2.18.0.399.gad0ab374a1-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

2018-07-06 Thread Mathieu Duponchelle 

> A newbie question - how would cross-compiling for a target of Win10x64 work, 
> in say ubuntu still eg per zeranoe's method, or rdp's at 
> https://github.com/rdp/ffmpeg-windows-build-helpers ?

meson has excellent support for cross compilation, you can find more info on 
this at


I am not familiar with zeranoe's method or rdp.

-- 
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

2018-07-06 Thread Mathieu Duponchelle 
On 07/06/2018 12:46 PM, Tobias Rapp wrote:
>
> What are the dependencies besides Meson and Python v3 itself?

Meson has no hard dependency apart from python3, if the default backend (ninja)
is used, then ninja must indeed also be present on the system.

> Is using Ninja mandatory for building or can Make be used as an alternative?

Make is not an available backend, see 
.

You can find a list of backends at 
.

>
> What happens to build targets when using Meson? Are granular things like 
> "make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?

Yes, when using the ninja backend, you can build individual targets with `ninja 
`.

Note that the fate test suite hasn't been ported to meson (yet).

-- 
Mathieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

2018-07-06 Thread hydra3333 
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Tobias Rapp
> Sent: Friday, July 6, 2018 8:16 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] New build system
>
> On 04.07.2018 16:36, Mathieu Duponchelle wrote:
> > [...]
> > 
> > If there are any other questions related to meson or the FFmpeg meson 
> > port please feel free to ask and I'll do my best to answer them.
>
> What are the dependencies besides Meson and Python v3 itself? Is using Ninja 
> mandatory for building or can Make be used as an alternative?
>
> What happens to build targets when using Meson? Are granular things like 
> "make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?
>
> Regards,
> Tobias

A newbie question - how would cross-compiling for a target of Win10x64 work, in 
say ubuntu still eg per zeranoe's method, or rdp's at 
https://github.com/rdp/ffmpeg-windows-build-helpers ?


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] New build system

2018-07-06 Thread Tobias Rapp 

On 04.07.2018 16:36, Mathieu Duponchelle wrote:

[...]

If there are any other questions related to meson or the FFmpeg meson port
please feel free to ask and I'll do my best to answer them.


What are the dependencies besides Meson and Python v3 itself? Is using 
Ninja mandatory for building or can Make be used as an alternative?


What happens to build targets when using Meson? Are granular things like 
"make all", "make doc", "make fate", "make fate-filter-pixfmts" possible?


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/vp8_parser: Do not leave data/size uninitialized

2018-07-06 Thread Michael Niedermayer 
This is identical to what the VP9 parser does

Fixes: 
9215/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LIBVPX_VP8_fuzzer-5768227253649408
Fixes: out of memory access

This may also fix oss fuzz issue 9212

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/vp8_parser.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/vp8_parser.c b/libavcodec/vp8_parser.c
index 609f5077d1..e2d91b271f 100644
--- a/libavcodec/vp8_parser.c
+++ b/libavcodec/vp8_parser.c
@@ -28,6 +28,9 @@ static int parse(AVCodecParserContext *s,
 unsigned int frame_type;
 unsigned int profile;
 
+*poutbuf  = buf;
+*poutbuf_size = buf_size;
+
 if (buf_size < 3)
 return buf_size;
 
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] tools/target_dec_fuzzer: set parser codec id to avoid assertion failure

2018-07-06 Thread Michael Niedermayer 
Signed-off-by: Michael Niedermayer 
---
 tools/target_dec_fuzzer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 3146bf2c1a..a94d5e6a92 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -193,6 +193,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 av_free(parser_avctx);
 return 0; // Failure of avcodec_open2() does not imply that a issue 
was found
 }
+parser_avctx->codec_id = ctx->codec_id;
 
 FDBCreate();
 int got_frame;
-- 
2.18.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: allow temp files for passed test to be kept

2018-07-06 Thread Gyan Doshi 
From 18351747e460d52939d54bdf20364e4156852034 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Fri, 6 Jul 2018 14:53:33 +0530
Subject: [PATCH] fate: allow temp files for passed test to be kept

Set make variable KEEP to non-zero value to preserve temp files
when a test has passed.

Helpful in diagnosing failed tests when test outfile is some type of
single hash and does not reveal differences in processed output.
---
 doc/fate.texi | 5 +
 tests/Makefile| 2 +-
 tests/fate-run.sh | 5 -
 3 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/doc/fate.texi b/doc/fate.texi
index c9c0d3aea9..a352994230 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -222,6 +222,11 @@ Set to @samp{1} to generate the missing or mismatched 
references.
 Specify which hardware acceleration to use while running regression tests,
 by default @samp{none} is used.
 
+@item KEEP
+Set to @samp{1} to keep temp files generated by fate test(s) when test is 
successful.
+Default is @samp{0}, which removes these files. Files are always kept when a 
test
+fails.
+
 @end table
 
 @section Examples
diff --git a/tests/Makefile b/tests/Makefile
index e564279b0a..24680b8150 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -225,7 +225,7 @@ FATE += $(FATE_HW-yes)
 $(FATE) $(FATE_TESTS-no): export PROGSUF = $(PROGSSUF)
 $(FATE) $(FATE_TESTS-no): $(FATE_UTILS:%=tests/%$(HOSTEXESUF))
@echo "TEST$(@:fate-%=%)"
-   $(Q)$(SRC_PATH)/tests/fate-run.sh $@ "$(TARGET_SAMPLES)" 
"$(TARGET_EXEC)" "$(TARGET_PATH)" '$(CMD)' '$(CMP)' '$(REF)' '$(FUZZ)' 
'$(THREADS)' '$(THREAD_TYPE)' '$(CPUFLAGS)' '$(CMP_SHIFT)' '$(CMP_TARGET)' 
'$(SIZE_TOLERANCE)' '$(CMP_UNIT)' '$(GEN)' '$(HWACCEL)' '$(REPORT)'
+   $(Q)$(SRC_PATH)/tests/fate-run.sh $@ "$(TARGET_SAMPLES)" 
"$(TARGET_EXEC)" "$(TARGET_PATH)" '$(CMD)' '$(CMP)' '$(REF)' '$(FUZZ)' 
'$(THREADS)' '$(THREAD_TYPE)' '$(CPUFLAGS)' '$(CMP_SHIFT)' '$(CMP_TARGET)' 
'$(SIZE_TOLERANCE)' '$(CMP_UNIT)' '$(GEN)' '$(HWACCEL)' '$(REPORT)' '$(KEEP)'
 
 fate-list:
@printf '%s\n' $(sort $(FATE))
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 457761c152..aece90a01d 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -25,6 +25,7 @@ cmp_unit=${15:-2}
 gen=${16:-no}
 hwaccel=${17:-none}
 report_type=${18:-standard}
+keep=${19:-0}
 
 outdir="tests/data/fate"
 outfile="${outdir}/${test}"
@@ -428,7 +429,9 @@ if test $err != 0 && test $gen != "no" ; then
 fi
 
 if test $err = 0; then
-rm -f $outfile $errfile $cmpfile $cleanfiles
+if test $keep = 0; then
+rm -f $outfile $errfile $cmpfile $cleanfiles
+fi
 elif test $gen = "no"; then
 echo "Test $test failed. Look at $errfile for details."
 test "${V:-0}" -gt 0 && cat $errfile
-- 
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/6] avformat/mms: Add missing chunksize check

2018-07-06 Thread Michael Niedermayer 
On Tue, Jul 03, 2018 at 11:05:25PM +0200, Michael Niedermayer wrote:
> Fixes: out of array read
> Fixes: mms-crash-01b6c5d85f9d9f40f4e879896103e9f5b222816a
> 
> Found-by: Paul Ch 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mms.c | 6 ++
>  1 file changed, 6 insertions(+)

will apply with an additional check


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 3/3] aadec: fix seeking in mp3 content

2018-07-06 Thread Karsten Otto 

> Am 04.07.2018 um 23:54 schrieb Michael Niedermayer :
> 
> Signierter PGP-Teil
> On Wed, Jul 04, 2018 at 09:32:32AM +0200, Karsten Otto wrote:
>> 
>>> Am 04.07.2018 um 03:26 schrieb Michael Niedermayer :
>>> 
>>> Signierter PGP-Teil
>>> On Tue, Jul 03, 2018 at 10:25:36PM +0200, Karsten Otto wrote:
 TL;DR: I will drop patch 3/3, may rather spend some time investigating why
 "ff ee 47 9d“ passes the mp3 header parser. Also, the aa file "index" 
 cannot
 be used for frame or chapter detection, unfortunately.
 
 More details inline below.
 
> Am 03.07.2018 um 02:32 schrieb Michael Niedermayer 
> :
> 
> Signierter PGP-Teil
> On Mon, Jul 02, 2018 at 07:21:43PM +0200, Karsten Otto wrote:
>> 
>>> Am 02.07.2018 um 10:59 schrieb Michael Niedermayer 
>>> :
>>> 
>>> Signierter PGP-Teil
>>> On Thu, Jun 21, 2018 at 06:58:26PM +0200, Karsten Otto wrote:
 MP3 frames may not be aligned to aa chunk boundaries. After seeking,
 scan for the next valid frame header. Then truncate the packet, and
 also adjust timestamp information accordingly.
 ---
 libavformat/aadec.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)
>>> 
>>> Please see AVSTREAM_PARSE_TIMESTAMPS
>>> 
>>> This codec specific code in demuxers should not be needed
>>> 
>> I tried that before, and you are right that it takes care of timestamp 
>> adjustments.
>> 
>> However, after a seek the parsed packet still contains a partial frame 
>> before the
>> next full one. I had expected libavformat/mpegaudio_parser.c to detect 
>> this
>> situation and discard the fragment, but unfortunately it does not. 
>> Instead it passes
>> it unchanged to the codec, which plays it as a pop or even a very ugly 
>> BLEEEP -
>> painful while wearing headphones!
> 
> I think you mis-diagnose this at least somewhat
> your code searches for a specific mp3 header, the parser and decoder would
> accept a wider range of mp3 variants.
> But both can choose points that are not mp3 frame starts. (if that is the
> problem you are seeing, iam not completely sure it is)
> 
 It took a closer look at what happens when I hear a BLEEP: The packet 
 begins
 with a partial frame, starting with the byte sequence "ff ee 47 9d“. 
 Unfortunately,
 the mp3 parser indeed accepts this as a valid mp3 header, causing the 
 noise.
 By looking for the more restricted header, my patch finds the real next 
 frame at
 offset 78.
 
 BTW: Should this sequence actually pass? AFAIK 01 is not a valid MPEG audio
 version ID?
 
> Also is the more restricted header you search for always used or could
> this be failing with some files ?
> 
 Good question. So far, all mp3 aa files I tested with matched the format 
 (MPEG 2
 Layer III at 32 kbps and 22kHz). I doubt there are other variants, but 
 can’t be sure.
 
> Either way, looking at the demuxer a bit deeper, theres a TOC list in the
> main header which points to chunks. The one file i found has 12 such 
> chunks
> the first represents the whole file i suspect, the next largest the audio
> data, another one the metadata.
> I guess the remaining 2 large ones could be a cover image and an index.
 Correct, seems like all aa files have the TOC, but its entries can be in a 
 different
 order in each file. I guess thats why the original aadec.c implementation 
 just
 looks for the largest chunk to play.
 
> I didnt really look at it, but theres a table in there with pairs of 32bit
> values. the first in the file i have goes from 0 to 3 the second starts
> multiple times from 0 and seems monotonly increasing and staying within
> the filesize.
> The sample i have does not store mp3 but it looks like this is a index
> maybe offsets for packets in each of the 3 chapters.
> 
> Please look at the data, if it can be used. It would be much better than
> scaning the file linearly and searching for some byte sequence to find
> packet starts.
> 
 Short answer: Sorry, it is not possible to derive frame offsets nor chapter
 offsets from the index.
 
>>> 
 Long answer:
 All offsets in the index are the same, and matching the "codec_second_size"
 = crypto chunk size, roughly one second of audio:
 - 1045 for format 2 (SIPR 8kbps)
 - 2000 for format 3 (SIPR 16kbps)
 - 3982 for format 4 (MP3 32kbps)
 This is different from the respective frame size, which is 19, 20, and 
 104/105
>>> 
>>> The first 2 are exact multiples of the frame size.
>>> 
>>> I dont have a sample for the mp3 case so i cannot check but are you sure
>>> the actually writen numbers dont match up multiples of mp3 frames ?
>>> 
>> Yes, I have tested both

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/videotoolboxenc: fix undefined behavior with rc_max_rate=0

2018-07-06 Thread Kári Helgason 
Sorry for jumping in with a slightly OT question,

Am I understanding correctly that you have noticed that when using kVTCompre
ssionPropertyKey_DataRateLimits you will sometimes get random garbage from
the encoder in the output callback?

How frequently does this happen, and can you reproduce it reliably, or do
you only see it in production?

Has a radar been filed with Apple about this?

On Wed, Jul 4, 2018 at 1:44 PM Thomas Guillem  wrote:

> On Wed, Jul 4, 2018, at 09:05, Thomas Guillem wrote:
> > On macOS, a zero rc_max_rate cause an error from
> > VTSessionSetProperty(kVTCompressionPropertyKey_DataRateLimits).
> >
> > on iOS (depending on device/version), a zero rc_max_rate cause invalid
> > arguments from the vtenc_output_callback after few frames and then a
> crash
> > within the VideoToolbox library.
>
> In fact, when setting a correct max_rate on iOS, you could still get
> random crashes the same way. It's happening on ios 11.4 but seems to be OK
> on iOS 12 Beta.
>
> > ---
> >  libavcodec/videotoolboxenc.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> > index ac847358ab..aa9aae7e05 100644
> > --- a/libavcodec/videotoolboxenc.c
> > +++ b/libavcodec/videotoolboxenc.c
> > @@ -1019,6 +1019,7 @@ static int vtenc_create_encoder(AVCodecContext
>  *avctx,
> >
> >  if (vtctx->codec_id == AV_CODEC_ID_H264) {
> >  // kVTCompressionPropertyKey_DataRateLimits is not available
> > for HEVC
> > +if (max_rate > 0) {
> >  bytes_per_second_value = max_rate >> 3;
> >  bytes_per_second = CFNumberCreate(kCFAllocatorDefault,
> >kCFNumberSInt64Type,
> > @@ -1058,6 +1059,7 @@ static int vtenc_create_encoder(AVCodecContext
> > *avctx,
> >  av_log(avctx, AV_LOG_ERROR, "Error setting max bitrate
> > property: %d\n", status);
> >  return AVERROR_EXTERNAL;
> >  }
> > +}
> >
> >  if (profile_level) {
> >  status = VTSessionSetProperty(vtctx->session,
> > --
> > 2.18.0
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi/minterpolate: fix blending calc issue.

2018-07-06 Thread Steven Liu 
myp...@gmail.com  于2018年7月4日周三 下午3:05写道：
>
> On Wed, Jun 27, 2018 at 5:52 PM Jun Zhao  wrote:
> >
> > the right blending calc is:
> > (alpha * Frame_2 + (MAX - alpha) * Frame_1 + 512) >> 10
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  libavfilter/vf_minterpolate.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
> > index d534315..c6a5e63 100644
> > --- a/libavfilter/vf_minterpolate.c
> > +++ b/libavfilter/vf_minterpolate.c
> > @@ -1122,8 +1122,8 @@ static void interpolate(AVFilterLink *inlink,
> AVFrame *avf_out)
> >  for (y = 0; y < height; y++) {
> >  for (x = 0; x < width; x++) {
> >  avf_out->data[plane][x + y * 
> > avf_out->linesize[plane]]
> =
> > -  alpha  * 
> > mi_ctx->frames[2].avf->data[plane][x
> + y * mi_ctx->frames[2].avf->linesize[plane]] +
> > -((ALPHA_MAX - alpha) * 
> > mi_ctx->frames[1].avf->data[plane][x
> + y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> > +(alpha  * mi_ctx->frames[2].avf->data[plane][x
> + y * mi_ctx->frames[2].avf->linesize[plane]] +
> > + (ALPHA_MAX - alpha) * 
> > mi_ctx->frames[1].avf->data[plane][x
> + y * mi_ctx->frames[1].avf->linesize[plane]] + 512) >> 10;
> >  }
> >  }
> >  }
> > --
> > 2.7.4
> >
> ping, any comments for this fix?

LGTM

Go on improve it to OpenCL :D
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.

2018-07-06 Thread Manojkumar Bhosale 
Hi yinshiyou-hf,

Sorry for not responding to your patches.
As I am no longer being part of MIPS, you may want to contact MIPS and ask for 
assigning the appropriate maintainer.

Copying David Lau from MIPS.

Thanks,
Manoj


-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
Michael Niedermayer
Sent: Friday, July 6, 2018 1:56 AM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 
decoding in vp8dsp.

On Thu, Jul 05, 2018 at 08:02:01PM +0800, yinshiyou...@loongson.cn wrote:
> 
> Is there anyone reviewing my patch? I sent 9 patchs about 20 days ago, but 
> only one patch received reply at June 14. 

Theres a maintainer listed for mips in MAINTAINERs he should review the 
patches. If he has no time then someone else should maybe help him Also it may 
make sense to split maintainership of the 2 MIPS implementations if that would 
make reviews work better but it still requires someone to do the review.

I dont know mips asm well enough to do a optimal review

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know 
nothing. -- Socrates
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel