Re: [FFmpeg-devel] [PATCH 1/1] libavformat/dashenc: Fix relative URI of HLS master playlist

2018-07-29 Thread Jeyapal, Karthick


On 7/27/18 12:50 PM, Jeyapal, Karthick wrote:
> On 7/26/18 6:52 PM, Antonio Morell wrote:
>> ---
>>  libavformat/dashenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index a9b8b1d4f6..ae57fd5493 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -868,7 +868,7 @@ static int write_manifest(AVFormatContext *s, int final)
>>  int max_audio_bitrate = 0;
>>  
>>  if (*c->dirname)
>> -snprintf(filename_hls, sizeof(filename_hls), "%s/master.m3u8", 
>> c->dirname);
>> +snprintf(filename_hls, sizeof(filename_hls), "%smaster.m3u8", 
>> c->dirname);
>>  else
>>  snprintf(filename_hls, sizeof(filename_hls), "master.m3u8");
>>  
>
> LGTM.
Pushed.
>
> Thanks, Karthick 
>> -- 
>> 2.15.2 (Apple Git-101.1)
>>
>> ___
>> 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 5/5] avformat/matroskaenc: update AV1 support

2018-07-29 Thread Steve Lhomme

On 26/07/2018 03:11, James Almer wrote:

Make sure to not write forbidden OBUs to CodecPrivate, and do the same with
unnecessary OBUs for packets.


Does this include reordering the OBUs ? The first one must be the 
Sequence Header OBU. Also it must be the only one of that kind.




Signed-off-by: James Almer 
---
  libavformat/matroskaenc.c | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b7ff1950d3..816ddd059a 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -21,6 +21,7 @@
  
  #include 
  
+#include "av1.h"

  #include "avc.h"
  #include "hevc.h"
  #include "avformat.h"
@@ -769,6 +770,9 @@ static int mkv_write_native_codecprivate(AVFormatContext 
*s, AVIOContext *pb,
  ff_isom_write_hvcc(dyn_cp, par->extradata,
 par->extradata_size, 0);
  return 0;
+case AV_CODEC_ID_AV1:
+return ff_isom_write_av1c(dyn_cp, par->extradata,
+  par->extradata_size);
  case AV_CODEC_ID_ALAC:
  if (par->extradata_size < 36) {
  av_log(s, AV_LOG_ERROR,
@@ -2120,6 +2124,8 @@ static void mkv_write_block(AVFormatContext *s, 
AVIOContext *pb,
   (AV_RB24(par->extradata) == 1 || AV_RB32(par->extradata) == 1))
  /* extradata is Annex B, assume the bitstream is too and convert it */
  ff_hevc_annexb2mp4_buf(pkt->data, , , 0, NULL);
+else if (par->codec_id == AV_CODEC_ID_AV1)
+ff_av1_filter_obus_buf(pkt->data, , );
  else if (par->codec_id == AV_CODEC_ID_WAVPACK) {
  int ret = mkv_strip_wavpack(pkt->data, , );
  if (ret < 0) {
--
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


Re: [FFmpeg-devel] [PATCH] doc/formats: Add documentation for skip_estimate_duration_from_pts

2018-07-29 Thread Gyan Doshi



On 30-07-2018 04:37 AM, Michael Niedermayer wrote:



I'll modify and push this tomorrow.


sure, thx


Pushed as 67fb9c75efec9f069fc57b3ed211a35c63c686e5

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


[FFmpeg-devel] [PATCH 1/2] avcodec/qtrle: Check remaining bytestream in qtrle_decode_XYbpp()

2018-07-29 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 
9213/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-5649753332252672

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

diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
index 670690d0a4..6155b4f3e3 100644
--- a/libavcodec/qtrle.c
+++ b/libavcodec/qtrle.c
@@ -155,6 +155,8 @@ static inline void qtrle_decode_2n4bpp(QtrleContext *s, int 
row_ptr,
 CHECK_PIXEL_PTR(0);
 
 while ((rle_code = (int8_t)bytestream2_get_byte(>g)) != -1) {
+if (bytestream2_get_bytes_left(>g) < 1)
+return;
 if (rle_code == 0) {
 /* there's another skip code in the stream */
 pixel_ptr += (num_pixels * (bytestream2_get_byte(>g) - 1));
@@ -210,6 +212,8 @@ static void qtrle_decode_8bpp(QtrleContext *s, int row_ptr, 
int lines_to_change)
 CHECK_PIXEL_PTR(0);
 
 while ((rle_code = (int8_t)bytestream2_get_byte(>g)) != -1) {
+if (bytestream2_get_bytes_left(>g) < 1)
+return;
 if (rle_code == 0) {
 /* there's another skip code in the stream */
 pixel_ptr += (4 * (bytestream2_get_byte(>g) - 1));
@@ -259,6 +263,8 @@ static void qtrle_decode_16bpp(QtrleContext *s, int 
row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(0);
 
 while ((rle_code = (int8_t)bytestream2_get_byte(>g)) != -1) {
+if (bytestream2_get_bytes_left(>g) < 1)
+return;
 if (rle_code == 0) {
 /* there's another skip code in the stream */
 pixel_ptr += (bytestream2_get_byte(>g) - 1) * 2;
@@ -303,6 +309,8 @@ static void qtrle_decode_24bpp(QtrleContext *s, int 
row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(0);
 
 while ((rle_code = (int8_t)bytestream2_get_byte(>g)) != -1) {
+if (bytestream2_get_bytes_left(>g) < 1)
+return;
 if (rle_code == 0) {
 /* there's another skip code in the stream */
 pixel_ptr += (bytestream2_get_byte(>g) - 1) * 3;
@@ -350,6 +358,8 @@ static void qtrle_decode_32bpp(QtrleContext *s, int 
row_ptr, int lines_to_change
 CHECK_PIXEL_PTR(0);
 
 while ((rle_code = (int8_t)bytestream2_get_byte(>g)) != -1) {
+if (bytestream2_get_bytes_left(>g) < 1)
+return;
 if (rle_code == 0) {
 /* there's another skip code in the stream */
 pixel_ptr += (bytestream2_get_byte(>g) - 1) * 4;
-- 
2.18.0

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


[FFmpeg-devel] [PATCH 2/2] avcodec/mlp_parser: Check if synccode is within buffer

2018-07-29 Thread Michael Niedermayer
Fixes: undefined shift
Fixes: 
9216/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEHD_fuzzer-6281404575907840

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

diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
index 185bd4d667..eb3435b6cb 100644
--- a/libavcodec/mlp_parser.c
+++ b/libavcodec/mlp_parser.c
@@ -320,7 +320,7 @@ static int mlp_parse(AVCodecParserContext *s,
 mp->bytes_left = 0;
 }
 
-sync_present = (AV_RB32(buf + 4) & 0xfffe) == 0xf8726fba;
+sync_present = buf_size >= 8 && (AV_RB32(buf + 4) & 0xfffe) == 
0xf8726fba;
 
 if (!sync_present) {
 /* The first nibble of a frame is a parity check of the 4-byte
-- 
2.18.0

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


Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb_bsf: use enum constants for the NAL unit type values

2018-07-29 Thread myp...@gmail.com
On Mon, Jul 30, 2018 at 5:22 AM James Almer  wrote:
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/h264_mp4toannexb_bsf.c | 15 ---
>  1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/h264_mp4toannexb_bsf.c
b/libavcodec/h264_mp4toannexb_bsf.c
> index 292d106433..794c82e650 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -26,6 +26,7 @@
>
>  #include "avcodec.h"
>  #include "bsf.h"
> +#include "h264.h"
>
>  typedef struct H264BSFContext {
>  int32_t  sps_offset;
> @@ -209,9 +210,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
>  if (nal_size > buf_end - buf || nal_size < 0)
>  goto fail;
>
> -if (unit_type == 7)
> +if (unit_type == H264_NAL_SPS)
>  s->idr_sps_seen = s->new_idr = 1;
> -else if (unit_type == 8) {
> +else if (unit_type == H264_NAL_PPS) {
>  s->idr_pps_seen = s->new_idr = 1;
>  /* if SPS has not been seen yet, prepend the AVCC one to PPS
*/
>  if (!s->idr_sps_seen) {
> @@ -232,18 +233,18 @@ static int h264_mp4toannexb_filter(AVBSFContext
*ctx, AVPacket *out)
>  /* if this is a new IDR picture following an IDR picture, reset
the idr flag.
>   * Just check first_mb_in_slice to be 0 as this is the simplest
solution.
>   * This could be checking idr_pic_id instead, but would
complexify the parsing. */
> -if (!s->new_idr && unit_type == 5 && (buf[1] & 0x80))
> +if (!s->new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] &
0x80))
>  s->new_idr = 1;
>
>  /* prepend only to the first type 5 NAL unit of an IDR picture,
if no sps/pps are already present */
> -if (s->new_idr && unit_type == 5 && !s->idr_sps_seen &&
!s->idr_pps_seen) {
> +if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
!s->idr_sps_seen && !s->idr_pps_seen) {
>  if ((ret=alloc_and_copy(out,
> ctx->par_out->extradata,
ctx->par_out->extradata_size,
> buf, nal_size, 1)) < 0)
>  goto fail;
>  s->new_idr = 0;
>  /* if only SPS has been seen, also insert PPS */
> -} else if (s->new_idr && unit_type == 5 && s->idr_sps_seen &&
!s->idr_pps_seen) {
> +} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE &&
s->idr_sps_seen && !s->idr_pps_seen) {
>  if (s->pps_offset == -1) {
>  av_log(ctx, AV_LOG_WARNING, "PPS not present in the
stream, nor in AVCC, stream may be unreadable\n");
>  if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size,
0)) < 0)
> @@ -253,9 +254,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx,
AVPacket *out)
>  buf, nal_size, 1)) < 0)
>  goto fail;
>  } else {
> -if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size,
unit_type == 7 || unit_type == 8)) < 0)
> +if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size,
unit_type == H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
>  goto fail;
> -if (!s->new_idr && unit_type == 1) {
> +if (!s->new_idr && unit_type == H264_NAL_SLICE) {
>  s->new_idr = 1;
>  s->idr_sps_seen = 0;
>  s->idr_pps_seen = 0;
> --
LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] doc/formats: Add documentation for skip_estimate_duration_from_pts

2018-07-29 Thread Michael Niedermayer
On Sun, Jul 29, 2018 at 10:57:58PM +0530, Gyan Doshi wrote:
> 
> 
> On 26-07-2018 11:38 AM, Gyan Doshi wrote:
> >
> >On 26-07-2018 03:37 AM, Michael Niedermayer wrote:
> 
> >>what do people prefer ? I have no real oppinion on where to put it as
> >>long
> >>as it is documented somewhere in the docs ...
> >
> ...
> >
> >We can leave the possible shifting for later on, but let's add the
> >limitation to the doc.
> 
> I'll modify and push this tomorrow.

sure, thx 

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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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


Re: [FFmpeg-devel] [GSOC] [PATCH] On the fly generation of default DNN models and code style fixes

2018-07-29 Thread Michael Niedermayer
On Sat, Jul 28, 2018 at 01:00:53PM +0300, Sergey Lavrushkin wrote:
> 2018-07-28 4:31 GMT+03:00 Michael Niedermayer :
> 
> > On Fri, Jul 27, 2018 at 08:06:15PM +0300, Sergey Lavrushkin wrote:
> > > Hello,
> > >
> > > The first patch provides on the fly generation of default DNN models,
> > > that eliminates data duplication for model weights. Also, files with
> > > internal weights
> > > were replaced with automatically generated one for models I trained.
> > > Scripts for training and generating these files can be found here:
> > > https://github.com/HighVoltageRocknRoll/sr
> > > Later, I will add a description to this repo on how to use it and
> > benchmark
> > > results for trained models.
> > >
> > > The second patch fixes some code style issues for pointers in DNN module
> > > and sr filter. Are there any other code style fixes I should make for
> > this
> > > code?
> >
> >
> > It seems the code with these patches produces some warnings:
> >
> > In file included from libavfilter/dnn_backend_native.c:27:0:
> > libavfilter/dnn_srcnn.h:2113:21: warning: ‘srcnn_consts’ defined but not
> > used [-Wunused-variable]
> >  static const float *srcnn_consts[] = {
> >  ^
> > libavfilter/dnn_srcnn.h:2122:24: warning: ‘srcnn_consts_dims’ defined but
> > not used [-Wunused-variable]
> >  static const long int *srcnn_consts_dims[] = {
> > ^
> > libavfilter/dnn_srcnn.h:2142:20: warning: ‘srcnn_activations’ defined but
> > not used [-Wunused-variable]
> >  static const char *srcnn_activations[] = {
> > ^
> > In file included from libavfilter/dnn_backend_native.c:28:0:
> > libavfilter/dnn_espcn.h:5401:21: warning: ‘espcn_consts’ defined but not
> > used [-Wunused-variable]
> >  static const float *espcn_consts[] = {
> >  ^
> > libavfilter/dnn_espcn.h:5410:24: warning: ‘espcn_consts_dims’ defined but
> > not used [-Wunused-variable]
> >  static const long int *espcn_consts_dims[] = {
> > ^
> > libavfilter/dnn_espcn.h:5432:20: warning: ‘espcn_activations’ defined but
> > not used [-Wunused-variable]
> >  static const char *espcn_activations[] = {
> > ^
> >
> 
> Here is the patch, that fixes these warnings.

>  dnn_backend_tf.c |   64 
> ++-
>  dnn_espcn.h  |   37 ---
>  dnn_srcnn.h  |   35 --
>  3 files changed, 63 insertions(+), 73 deletions(-)
> 1faef51b86165326a4693c07a203113e2c85f7fb  
> 0003-libavfilter-Fixes-warnings-for-unused-variables-in-d.patch
> From 37cd7bdf2610e1c3e89210a49e8f5f3832726281 Mon Sep 17 00:00:00 2001
> From: Sergey Lavrushkin 
> Date: Sat, 28 Jul 2018 12:55:02 +0300
> Subject: [PATCH 3/3] libavfilter: Fixes warnings for unused variables in
>  dnn_srcnn.h, dnn_espcn.h, dnn_backend_tf.c.
> 
> ---
>  libavfilter/dnn_backend_tf.c | 64 
> +++-
>  libavfilter/dnn_espcn.h  | 37 -
>  libavfilter/dnn_srcnn.h  | 35 
>  3 files changed, 63 insertions(+), 73 deletions(-)
> 
> diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> index 6307c794a5..7a4ad72d27 100644
> --- a/libavfilter/dnn_backend_tf.c
> +++ b/libavfilter/dnn_backend_tf.c
> @@ -374,9 +374,71 @@ DNNModel *ff_dnn_load_default_model_tf(DNNDefaultModel 
> model_type)
>  TFModel *tf_model = NULL;
>  TF_OperationDescription *op_desc;
>  TF_Operation *op;
> -TF_Operation *const_ops_buffer[6];
>  TF_Output input;
>  int64_t input_shape[] = {1, -1, -1, 1};
> +const char tanh[] = "Tanh";
> +const char sigmoid[] = "Sigmoid";
> +const char relu[] = "Relu";
> +
> +const float *srcnn_consts[] = {
> +srcnn_conv1_kernel,
> +srcnn_conv1_bias,
> +srcnn_conv2_kernel,
> +srcnn_conv2_bias,
> +srcnn_conv3_kernel,
> +srcnn_conv3_bias
> +};
> +const long int *srcnn_consts_dims[] = {
> +srcnn_conv1_kernel_dims,
> +srcnn_conv1_bias_dims,
> +srcnn_conv2_kernel_dims,
> +srcnn_conv2_bias_dims,
> +srcnn_conv3_kernel_dims,
> +srcnn_conv3_bias_dims
> +};
> +const int srcnn_consts_dims_len[] = {
> +4,
> +1,
> +4,
> +1,
> +4,
> +1
> +};

not important at all but, why do you remove "static" from these ?

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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


[FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb_bsf: use enum constants for the NAL unit type values

2018-07-29 Thread James Almer
Signed-off-by: James Almer 
---
 libavcodec/h264_mp4toannexb_bsf.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
b/libavcodec/h264_mp4toannexb_bsf.c
index 292d106433..794c82e650 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -26,6 +26,7 @@
 
 #include "avcodec.h"
 #include "bsf.h"
+#include "h264.h"
 
 typedef struct H264BSFContext {
 int32_t  sps_offset;
@@ -209,9 +210,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
AVPacket *out)
 if (nal_size > buf_end - buf || nal_size < 0)
 goto fail;
 
-if (unit_type == 7)
+if (unit_type == H264_NAL_SPS)
 s->idr_sps_seen = s->new_idr = 1;
-else if (unit_type == 8) {
+else if (unit_type == H264_NAL_PPS) {
 s->idr_pps_seen = s->new_idr = 1;
 /* if SPS has not been seen yet, prepend the AVCC one to PPS */
 if (!s->idr_sps_seen) {
@@ -232,18 +233,18 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
AVPacket *out)
 /* if this is a new IDR picture following an IDR picture, reset the 
idr flag.
  * Just check first_mb_in_slice to be 0 as this is the simplest 
solution.
  * This could be checking idr_pic_id instead, but would complexify the 
parsing. */
-if (!s->new_idr && unit_type == 5 && (buf[1] & 0x80))
+if (!s->new_idr && unit_type == H264_NAL_IDR_SLICE && (buf[1] & 0x80))
 s->new_idr = 1;
 
 /* prepend only to the first type 5 NAL unit of an IDR picture, if no 
sps/pps are already present */
-if (s->new_idr && unit_type == 5 && !s->idr_sps_seen && 
!s->idr_pps_seen) {
+if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && !s->idr_sps_seen 
&& !s->idr_pps_seen) {
 if ((ret=alloc_and_copy(out,
ctx->par_out->extradata, 
ctx->par_out->extradata_size,
buf, nal_size, 1)) < 0)
 goto fail;
 s->new_idr = 0;
 /* if only SPS has been seen, also insert PPS */
-} else if (s->new_idr && unit_type == 5 && s->idr_sps_seen && 
!s->idr_pps_seen) {
+} else if (s->new_idr && unit_type == H264_NAL_IDR_SLICE && 
s->idr_sps_seen && !s->idr_pps_seen) {
 if (s->pps_offset == -1) {
 av_log(ctx, AV_LOG_WARNING, "PPS not present in the stream, 
nor in AVCC, stream may be unreadable\n");
 if ((ret = alloc_and_copy(out, NULL, 0, buf, nal_size, 0)) < 0)
@@ -253,9 +254,9 @@ static int h264_mp4toannexb_filter(AVBSFContext *ctx, 
AVPacket *out)
 buf, nal_size, 1)) < 0)
 goto fail;
 } else {
-if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size, unit_type == 
7 || unit_type == 8)) < 0)
+if ((ret=alloc_and_copy(out, NULL, 0, buf, nal_size, unit_type == 
H264_NAL_SPS || unit_type == H264_NAL_PPS)) < 0)
 goto fail;
-if (!s->new_idr && unit_type == 1) {
+if (!s->new_idr && unit_type == H264_NAL_SLICE) {
 s->new_idr = 1;
 s->idr_sps_seen = 0;
 s->idr_pps_seen = 0;
-- 
2.18.0

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


Re: [FFmpeg-devel] [PATCH] doc/formats: Add documentation for skip_estimate_duration_from_pts

2018-07-29 Thread Gyan Doshi



On 26-07-2018 11:38 AM, Gyan Doshi wrote:


On 26-07-2018 03:37 AM, Michael Niedermayer wrote:


what do people prefer ? I have no real oppinion on where to put it as 
long

as it is documented somewhere in the docs ...



...


We can leave the possible shifting for later on, but let's add the 
limitation to the doc.


I'll modify and push this tomorrow.

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


Re: [FFmpeg-devel] [PATCH] Add YUV-based floating-point pixel formats.

2018-07-29 Thread Andrew Sun
On Sun, Jul 29, 2018 at 8:10 AM Ronald S. Bultje  wrote:

> Hi,
>
> On Sun, Jul 29, 2018 at 8:07 AM, Paul B Mahol  wrote:
>
>> On 9/2/17, Andrew Sun  wrote:
>> > This commit adds support for 32-bpc YUV-based floating-point pixel
>> formats.
>> > ---
>> >  doc/APIchanges  |  2 ++
>> >  libavutil/pixdesc.c | 75
>> > +
>> >  libavutil/pixfmt.h  | 11 
>> >  libavutil/version.h |  2 +-
>> >  4 files changed, 89 insertions(+), 1 deletion(-)
>> >
>>
>> All float formats need proper definition in nut container.
>
>
> The nut maintainer can do that him/herself.
>
> I agree with Michael we need swscale support, we've always required that
> for new (non-hw) pix_fmt additions.
>
> Ronald
>
I am really sorry, this is an old email I tried to send over a year ago,
but my mail client did not work at the time
and I apparently forgot about the email until I fixed my mail client
recently, which led to this old mail being sent.

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


Re: [FFmpeg-devel] Why not integrate libyuv as a scale filter

2018-07-29 Thread Paul B Mahol
On 7/23/18, Jeff <163j...@163.com> wrote:
> Hi there,
>
>
> It seems like libyuv has better performace on scaling than libswscale. So
> I'm wondering is there anyone has tried integrating libyuv as a scale filter
> before. I mean link it as a 3rd party lib, and then call it's API through a
> wrap filter. Just like how libavcodec use libx264.
> If not, why? Is there any licensee issue? Effort worth pay on it?
>

I see it support only very limited number of pixel formats, so it is
not very useful for us.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Add YUV-based floating-point pixel formats.

2018-07-29 Thread Ronald S. Bultje
Hi,

On Sun, Jul 29, 2018 at 8:07 AM, Paul B Mahol  wrote:

> On 9/2/17, Andrew Sun  wrote:
> > This commit adds support for 32-bpc YUV-based floating-point pixel
> formats.
> > ---
> >  doc/APIchanges  |  2 ++
> >  libavutil/pixdesc.c | 75
> > +
> >  libavutil/pixfmt.h  | 11 
> >  libavutil/version.h |  2 +-
> >  4 files changed, 89 insertions(+), 1 deletion(-)
> >
>
> All float formats need proper definition in nut container.


The nut maintainer can do that him/herself.

I agree with Michael we need swscale support, we've always required that
for new (non-hw) pix_fmt additions.

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


Re: [FFmpeg-devel] [PATCH] Add YUV-based floating-point pixel formats.

2018-07-29 Thread Paul B Mahol
On 9/2/17, Andrew Sun  wrote:
> This commit adds support for 32-bpc YUV-based floating-point pixel formats.
> ---
>  doc/APIchanges  |  2 ++
>  libavutil/pixdesc.c | 75
> +
>  libavutil/pixfmt.h  | 11 
>  libavutil/version.h |  2 +-
>  4 files changed, 89 insertions(+), 1 deletion(-)
>

All float formats need proper definition in nut container.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2] avformat/movenc: implicitly enable negative CTS offsets for ismv

2018-07-29 Thread Jan Ekström
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.

Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
---
 doc/muxers.texi   | 2 ++
 libavformat/movenc.c  | 2 +-
 tests/ref/fate/movenc | 4 ++--
 tests/ref/lavf/ismv   | 6 +++---
 4 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 33f1f7bbaf..268c152023 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1344,6 +1344,8 @@ be negative. This enables the initial sample to have 
DTS/CTS of zero, and
 reduces the need for edit lists for some cases such as video tracks with
 B-frames. Additionally, eases conformance with the DASH-IF interoperability
 guidelines.
+
+This option is implicitly set when writing ismv (Smooth Streaming) files.
 @item -write_prft
 Write producer time reference box (PRFT) with a specified time source for the
 NTP field in the PRFT box. Set value as @samp{wallclock} to specify timesource
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d530f40cab..14f85eb2a7 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6049,7 +6049,7 @@ static int mov_init(AVFormatContext *s)
 /* Set other implicit flags immediately */
 if (mov->mode == MODE_ISM)
 mov->flags |= FF_MOV_FLAG_EMPTY_MOOV | FF_MOV_FLAG_SEPARATE_MOOF |
-  FF_MOV_FLAG_FRAGMENT;
+  FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_NEGATIVE_CTS_OFFSETS;
 if (mov->flags & FF_MOV_FLAG_DASH)
 mov->flags |= FF_MOV_FLAG_FRAGMENT | FF_MOV_FLAG_EMPTY_MOOV |
   FF_MOV_FLAG_DEFAULT_BASE_MOOF;
diff --git a/tests/ref/fate/movenc b/tests/ref/fate/movenc
index 872796ebce..5e8f324ea3 100644
--- a/tests/ref/fate/movenc
+++ b/tests/ref/fate/movenc
@@ -17,10 +17,10 @@ write_data len 20, time nopts, type header atom ftyp
 write_data len 1171, time nopts, type header atom -
 write_data len 728, time 0, type sync atom moof
 write_data len 828, time nopts, type unknown atom -
-write_data len 728, time 1013106, type sync atom moof
+write_data len 728, time 1046439, type sync atom moof
 write_data len 812, time nopts, type unknown atom -
 write_data len 148, time nopts, type trailer atom -
-1f37c1a8e01651e8bebcd66f00b6a226 4435 ismv
+49bf122c4c732a344ef68b58acd19be5 4435 ismv
 write_data len 36, time nopts, type header atom ftyp
 write_data len 1123, time nopts, type header atom -
 write_data len 796, time 0, type sync atom moof
diff --git a/tests/ref/lavf/ismv b/tests/ref/lavf/ismv
index f29b5ff3ef..7b4a466096 100644
--- a/tests/ref/lavf/ismv
+++ b/tests/ref/lavf/ismv
@@ -1,9 +1,9 @@
-a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv
+96053075a3f60d271131fe2d0765c267 *./tests/data/lavf/lavf.ismv
 312542 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0x9d9a638a
-440d85f9fd5b9f63c2676638782b5c15 *./tests/data/lavf/lavf.ismv
+7022701b4c693bc4ffe1e9f96dd82a02 *./tests/data/lavf/lavf.ismv
 321448 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0xe8130120
-a9ccbb4cd1436d222ef4425567b4e03d *./tests/data/lavf/lavf.ismv
+96053075a3f60d271131fe2d0765c267 *./tests/data/lavf/lavf.ismv
 312542 ./tests/data/lavf/lavf.ismv
 ./tests/data/lavf/lavf.ismv CRC=0x9d9a638a
-- 
2.17.1

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