Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Disha Singh]

> testing this
> ./ffmpeg -i in.m4a test.mlp
> says it needs  'To use it anyways, you must set "-strict inofficial".'
> thats ok if it would work:
>
> ./ffmpeg -i in.m4a -strict inofficial test.mlp
> [mlp @ 0x2494740] Unable to parse option value "inofficial"
>
> Using :ffmpeg -i ~/input.mp3 -strict -unofficial -strict -2 -c:a mlp
~/output.mkv " gave me :

 [matroska @ 0x2bebe40] Timestamps are unset in a packet for stream 1. This
is deprecated and will stop working in the future. Fix your code to set the
timestamps properly
[matroska @ 0x2bebe40] Encoder did not produce proper pts, making some up.
Segmentation fault (core dumped)

 I know why segfault comes but what is the timestamp error ?


Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker.
> User
> questions about the command line tools should be sent to the ffmpeg-user
> ML.
> And questions about how to use libav* should be sent to the libav-user ML.
>

I would take care of this next time. :)

Thanks !

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

[FFmpeg-devel] [PATCH] lavf/matroskadec: Demux the PixelCrop* values

[Nic Wolfe]

The Matroska spec defines PixelCropTop, PixelCropBottom, PixelCropLeft,
and PixelCropRight elements: https://www.matroska.org/technical/specs/index.html

This commit adds support for demuxing these values so that
applications using libav*
are able to use them when playing the stream. They're added to the AVStream's
metadata if they are set to something non-zero.


My official patch is base64 encoded and attached but I will also
include the diff below for (hopefully) convenience.

Thanks,

Nic



diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d788232..72537df 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -139,6 +139,10 @@ typedef struct MatroskaTrackVideo {
 EbmlBin color_space;
 uint64_t stereo_mode;
 uint64_t alpha_mode;
+uint64_t crop_bottom;
+uint64_t crop_top;
+uint64_t crop_left;
+uint64_t crop_right;
 } MatroskaTrackVideo;

 typedef struct MatroskaTrackAudio {
@@ -364,10 +368,10 @@ static const EbmlSyntax matroska_track_video[] = {
 { MATROSKA_ID_VIDEOPIXELHEIGHT,EBML_UINT,  0,
offsetof(MatroskaTrackVideo, pixel_height) },
 { MATROSKA_ID_VIDEOCOLORSPACE, EBML_BIN,   0,
offsetof(MatroskaTrackVideo, color_space) },
 { MATROSKA_ID_VIDEOALPHAMODE,  EBML_UINT,  0,
offsetof(MatroskaTrackVideo, alpha_mode) },
-{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_NONE },
-{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_NONE },
-{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_NONE },
-{ MATROSKA_ID_VIDEOPIXELCROPR, EBML_NONE },
+{ MATROSKA_ID_VIDEOPIXELCROPB, EBML_UINT,  0,
offsetof(MatroskaTrackVideo, crop_bottom) },
+{ MATROSKA_ID_VIDEOPIXELCROPT, EBML_UINT,  0,
offsetof(MatroskaTrackVideo, crop_top) },
+{ MATROSKA_ID_VIDEOPIXELCROPL, EBML_UINT,  0,
offsetof(MatroskaTrackVideo, crop_left) },
+{ MATROSKA_ID_VIDEOPIXELCROPR, EBML_UINT,  0,
offsetof(MatroskaTrackVideo, crop_right) },
 { MATROSKA_ID_VIDEODISPLAYUNIT,EBML_NONE },
 { MATROSKA_ID_VIDEOFLAGINTERLACED, EBML_NONE },
 { MATROSKA_ID_VIDEOSTEREOMODE, EBML_UINT,  0,
offsetof(MatroskaTrackVideo, stereo_mode), { .u =
MATROSKA_VIDEO_STEREOMODE_TYPE_NB } },
@@ -2152,6 +2156,16 @@ static int matroska_parse_tracks(AVFormatContext *s)
 if (track->video.stereo_mode && track->video.stereo_mode
< MATROSKA_VIDEO_STEREOMODE_TYPE_NB)
 av_dict_set(>metadata, "stereo_mode",
ff_matroska_video_stereo_mode[track->video.stereo_mode], 0);

+/* export the matroska crop settings as metadata */
+if (track->video.crop_bottom != 0)
+av_dict_set_int(>metadata, "crop_bottom",
track->video.crop_bottom, 0);
+if (track->video.crop_top != 0)
+av_dict_set_int(>metadata, "crop_top",
track->video.crop_top, 0);
+if (track->video.crop_left != 0)
+av_dict_set_int(>metadata, "crop_left",
track->video.crop_left, 0);
+if (track->video.crop_right != 0)
+av_dict_set_int(>metadata, "crop_right",
track->video.crop_right, 0);
+
 /* export alpha mode flag as metadata tag  */
 if (track->video.alpha_mode)
 av_dict_set(>metadata, "alpha_mode", "1", 0);


0001-lavf-matroskadec-Demux-the-PixelCrop-values.patch.base64
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavd/dshow_crossbar: remove trailing whitespace

[Lou Logan]

Signed-off-by: Lou Logan 
---
Probably don't need to send this for review, but I know nothing of dshow
and can't test this trivial change since I don't use Windows.
---
 libavdevice/dshow_crossbar.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/dshow_crossbar.c b/libavdevice/dshow_crossbar.c
index c0739da..95fb466 100644
--- a/libavdevice/dshow_crossbar.c
+++ b/libavdevice/dshow_crossbar.c
@@ -167,7 +167,7 @@ dshow_try_setup_crossbar_options(ICaptureGraphBuilder2 
*graph_builder2,
 }
 
 if (devtype == VideoDevice && ctx->show_analog_tv_tuner_dialog) {
-hr = ICaptureGraphBuilder2_FindInterface(graph_builder2, 
_UPSTREAM_ONLY, NULL, 
+hr = ICaptureGraphBuilder2_FindInterface(graph_builder2, 
_UPSTREAM_ONLY, NULL,
  device_filter, _IAMTVTuner, (void**) _tuner_filter);
 if (hr == S_OK) {
 hr = IAMCrossbar_QueryInterface(tv_tuner_filter, _IBaseFilter, 
(void **) _tuner_base_filter);
@@ -179,7 +179,7 @@ dshow_try_setup_crossbar_options(ICaptureGraphBuilder2 
*graph_builder2,
 }
 }
 if (devtype == AudioDevice && ctx->show_analog_tv_tuner_audio_dialog) {
-hr = ICaptureGraphBuilder2_FindInterface(graph_builder2, 
_UPSTREAM_ONLY, NULL, 
+hr = ICaptureGraphBuilder2_FindInterface(graph_builder2, 
_UPSTREAM_ONLY, NULL,
  device_filter, _IAMTVAudio, (void**) _audio_filter);
 if (hr == S_OK) {
 hr = IAMCrossbar_QueryInterface(tv_audio_filter, _IBaseFilter, 
(void **) _audio_base_filter);
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: Update first_slice when updating current_slice for 2nd fields

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 05:17:46PM +, Kieran Kunhya wrote:
> On Fri, 25 Mar 2016 at 16:33 Michael Niedermayer 
> wrote:
> 
> > This fixes Ticket 4389 differently
> > Fixes Ticket5371
> > Fixes null pointer dereference
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_slice.c |3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index 9a5bc3f..c4340dc 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -1188,6 +1188,7 @@ int ff_h264_decode_slice_header(H264Context *h,
> > H264SliceContext *sl)
> >  if (h->cur_pic_ptr && FIELD_PICTURE(h) && h->first_field) {
> >  ret = ff_h264_field_end(h, h->slice_ctx, 1);
> >  h->current_slice = 0;
> > +first_slice = 1;
> >  if (ret < 0)
> >  return ret;
> >  } else if (h->cur_pic_ptr && !FIELD_PICTURE(h) &&
> > !h->first_field && h->nal_unit_type  == NAL_IDR_SLICE) {
> > @@ -1422,7 +1423,7 @@ int ff_h264_decode_slice_header(H264Context *h,
> > H264SliceContext *sl)
> >  }
> >  }
> >
> > -if (!h->current_slice && h->dequant_coeff_pps != pps_id) {
> > +if (first_slice && h->dequant_coeff_pps != pps_id) {
> >  h->dequant_coeff_pps = pps_id;
> >  ff_h264_init_dequant_tables(h);
> >  }
> > --
> > 1.7.9.5
> >
> >
> Ok if tested but I will fuzz more.

applied a different (safer) solution

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 10:18:47PM +0530, Disha Singh wrote:
> This is the revised patch created using git format-patch.
> 
> -Disha
> 
> On Thu, Mar 24, 2016 at 2:45 PM, Paul B Mahol  wrote:
> 
> > On 3/21/16, Disha Singh  wrote:
> > > Qualification task for project TrueHD encoder.
> > > There are two patches.
> > > One has the changes made to other files to support mlpenc.c and the other
> > > only has mlpenc.c.
> > > Also attached is the diff file of mlpenc.c.
> > > (Modified the file :
> > > https://github.com/ramiropolla/soc/blob/master/mlp/mlpenc.c)
> > >
> >
> > You need to make proper patch that can be applied to ffmpeg with no
> > separate files and strange patches.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >

>  configure  |1 
>  libavcodec/Makefile|1 
>  libavcodec/allcodecs.c |2 
>  libavcodec/mlp.h   |4 
>  libavcodec/mlpenc.c| 2443 
> +
>  5 files changed, 2450 insertions(+), 1 deletion(-)
> eac7dbd4d7bc0502d9fa09c13a6d5275114f3b83  0001-Mlp-encoder-addition.patch
> From 639aa2a07be6064049b2ba1e134e1474cb7f0806 Mon Sep 17 00:00:00 2001
> From: dinux5 
> Date: Sat, 26 Mar 2016 22:11:59 +0530
> Subject: [PATCH] Mlp encoder addition.

testing this
./ffmpeg -i in.m4a test.mlp
says it needs  'To use it anyways, you must set "-strict inofficial".'
thats ok if it would work:

./ffmpeg -i in.m4a -strict inofficial test.mlp
[mlp @ 0x2494740] Unable to parse option value "inofficial"

./ffmpeg -i in.m4a -strict -2 test.mlp
segfaults
Program received signal SIGSEGV, Segmentation fault.
0x00aeed33 in determine_quant_step_size (ctx=0x20bf200) at 
libavcodec/mlpenc.c:1402
1402dp->quant_step_size[channel] = 
number_trailing_zeroes(sample_mask[channel]) - mp->shift[channel];
(gdb) bt
Python Exception  No module named gdb.frames:
#0  0x00aeed33 in determine_quant_step_size (ctx=0x20bf200) at 
libavcodec/mlpenc.c:1402
#1  0x00af1434 in analyze_sample_buffer (ctx=0x20bf200) at 
libavcodec/mlpenc.c:2208
#2  0x00af1dbe in mlp_encode_frame (avctx=0x20bdde0, 
avpkt=0x7fffdef0, frame=0x20bec20, got_packet_ptr=0x7fffdf5c) at 
libavcodec/mlpenc.c:2386
#3  0x00cb179e in avcodec_encode_audio2 (avctx=0x20bdde0, 
avpkt=0x7fffdef0, frame=0x20bec20, got_packet_ptr=0x7fffdf5c) at 
libavcodec/utils.c:1826
#4  0x0042cd37 in do_audio_out (s=0x20a9b40, ost=0x20bdc00, 
frame=0x20bec20) at ffmpeg.c:815
#5  0x0042f5c5 in reap_filters (flush=0) at ffmpeg.c:1367
#6  0x0043c068 in transcode_step () at ffmpeg.c:4099
#7  0x0043c14c in transcode () at ffmpeg.c:4143
#8  0x0043c912 in main (argc=6, argv=0x7fffe448) at ffmpeg.c:4334

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Disha Singh]

Just running ./patcheck would do?

On Sun, Mar 27, 2016 at 12:50 AM, Lou Logan  wrote:

> On Sat, 26 Mar 2016 22:18:47 +0530, Disha Singh wrote:
>
> > From 639aa2a07be6064049b2ba1e134e1474cb7f0806 Mon Sep 17 00:00:00 2001
> > From: dinux5 
> > Date: Sat, 26 Mar 2016 22:11:59 +0530
> > Subject: [PATCH] Mlp encoder addition.
> >
> > ---
> >  configure  |1 +
> >  libavcodec/Makefile|1 +
> >  libavcodec/allcodecs.c |2 +-
> >  libavcodec/mlp.h   |4 +
> >  libavcodec/mlpenc.c| 2443
> 
> >  5 files changed, 2450 insertions(+), 1 deletion(-)
> >  create mode 100755 libavcodec/mlpenc.c
>
> Tabs and trailing whitespace should be avoided. Using tools/patcheck
> will tell you where they are, or if you like vim or emacs see:
>
> http://ffmpeg.org/developer.html#Editor-configuration
> ___
> 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] fate : add test for exr B44, B44A files

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 09:14:27PM +0100, Martin Vignali wrote:
> Hello,
> 

> In attach a patch for fate test of B44/B44A compression inside openexr file.
> samples can be download here : http://we.tl/QwJcxVn9CV
> need to be put inside : ./fate-suite/exr/

uploaded

thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avformat/segment: set format options for all segments

[Marton Balint]

On Fri, 25 Mar 2016, Stefano Sabatini wrote:


On date Tuesday 2016-03-15 19:21:23 +0100, Marton Balint encoded:

Fixes ticket #5318.

Signed-off-by: Marton Balint 
---
 libavformat/segment.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/segment.c b/libavformat/segment.c
index ccedd04..70590b4 100644
--- a/libavformat/segment.c
+++ b/libavformat/segment.c
@@ -256,7 +256,11 @@ static int segment_start(AVFormatContext *s, int 
write_header)
 av_opt_set(oc->priv_data, "mpegts_flags", "+resend_headers", 0);

 if (write_header) {
-if ((err = avformat_write_header(oc, NULL)) < 0)
+AVDictionary *options = NULL;
+av_dict_copy(, seg->format_options, 0);
+err = avformat_write_header(oc, );
+av_dict_free();
+if (err < 0)
 return err;
 }


LGTM, missed the patch, thanks.


Pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part

[Matthieu Bouron]

On Fri, Mar 25, 2016 at 11:46 PM, Matthieu Bouron  wrote:

> From: Matthieu Bouron 
>
> ---
>  libswscale/arm/swscale_unscaled.c | 16 +++
>  libswscale/arm/yuv2rgb_neon.S | 89
> +--
>  2 files changed, 47 insertions(+), 58 deletions(-)
>
>
Patch updated (resolve a conflict with the updated version of patch 06/10).
From 24b2371eb5ea859b2a68ef1ee3cf9a0098d9375a Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Wed, 23 Mar 2016 16:51:20 +
Subject: [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its
 aarch64 counter part

---
 libswscale/arm/swscale_unscaled.c | 16 +++
 libswscale/arm/yuv2rgb_neon.S | 89 +--
 2 files changed, 47 insertions(+), 58 deletions(-)

diff --git a/libswscale/arm/swscale_unscaled.c b/libswscale/arm/swscale_unscaled.c
index 149208c..1986d65 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -62,10 +62,10 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext *context, const uint8_t *src[
 }
 
 #define YUV_TO_RGB_TABLE\
-c->yuv2rgb_v2r_coeff / (1 << 7),\
-c->yuv2rgb_u2g_coeff / (1 << 7),\
-c->yuv2rgb_v2g_coeff / (1 << 7),\
-c->yuv2rgb_u2b_coeff / (1 << 7),\
+c->yuv2rgb_v2r_coeff,   \
+c->yuv2rgb_u2g_coeff,   \
+c->yuv2rgb_v2g_coeff,   \
+c->yuv2rgb_u2b_coeff,   \
 
 #define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)   \
 int ff_##ifmt##_to_##ofmt##_neon(int w, int h,  \
@@ -88,8 +88,8 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, const uint8_t *src[],
  src[1], srcStride[1],  \
  src[2], srcStride[2],  \
  yuv2rgb_table, \
- c->yuv2rgb_y_offset >> 9,  \
- c->yuv2rgb_y_coeff / (1 << 7));\
+ c->yuv2rgb_y_offset >> 6,  \
+ c->yuv2rgb_y_coeff);   \
 \
 return 0;   \
 }   \
@@ -121,8 +121,8 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, const uint8_t *src[],
  dst[0] + srcSliceY * dstStride[0], dstStride[0],   \
  src[0], srcStride[0], src[1], srcStride[1],\
  yuv2rgb_table, \
- c->yuv2rgb_y_offset >> 9,  \
- c->yuv2rgb_y_coeff / (1 << 7));\
+ c->yuv2rgb_y_offset >> 6,  \
+ c->yuv2rgb_y_coeff);   \
 \
 return 0;   \
 }   \
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 4a5ce11..bd994e3 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -68,14 +68,14 @@
 
 .macro load_chroma_nv12
 vld2.8  {d2, d3}, [r6]!@ q1: interleaved chroma line
-vsubl.u8q14, d2, d10   @ q14 = U - 128
-vsubl.u8q15, d3, d10   @ q15 = V - 128
+vshll.u8q14, d2, #3@ q14 = U * (1 << 3)
+vshll.u8q15, d3, #3@ q15 = V * (1 << 3)
 

Re: [FFmpeg-devel] [PATCH 09/10] swscale/arm/yuv2rgb: re-order arguments of the compute_rgba macro

[Matthieu Bouron]

On Fri, Mar 25, 2016 at 11:46 PM, Matthieu Bouron  wrote:

> From: Matthieu Bouron 
>
> ---
>  libswscale/arm/yuv2rgb_neon.S | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

Patch updated (resolve a conflict with the updated version of patch 06/10).
From 41b0ff49706d82ef964faa75888e95d86f69df34 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Fri, 25 Mar 2016 15:38:37 +
Subject: [PATCH 09/10] swscale/arm/yuv2rgb: re-order arguments of the
 compute_rgba macro

---
 libswscale/arm/yuv2rgb_neon.S | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 6a15778..4a5ce11 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -123,7 +123,7 @@
 vqrshrun.s16\dst_comp2, q2, #6
 .endm
 
-.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
+.macro compute_rgba r1 g1 b1 a1 r2 g2 b2 a2
 compute_color   \r1, \r2, q8,  q9
 compute_color   \g1, \g2, q10, q11
 compute_color   \b1, \b2, q12, q13
@@ -178,19 +178,19 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
 vmul.s16q15, q7@ q15 = (srcY - y_offset) * y_coeff (right)
 
 .ifc \ofmt,argb
-compute_rgbad7, d11, d8, d12, d9, d13, d6, d10
+compute_rgbad7, d8, d9, d6, d11, d12, d13, d10
 .endif
 
 .ifc \ofmt,rgba
-compute_rgbad6, d10, d7, d11, d8, d12, d9, d13
+compute_rgbad6, d7, d8, d9, d10, d11, d12, d13
 .endif
 
 .ifc \ofmt,abgr
-compute_rgbad9, d13, d8, d12, d7, d11, d6, d10
+compute_rgbad9, d8, d7, d6, d13, d12, d11, d10
 .endif
 
 .ifc \ofmt,bgra
-compute_rgbad8, d12, d7, d11, d6, d10, d9, d13
+compute_rgbad8, d7, d6, d9, d12, d11, d10, d13
 .endif
 
 vst4.8  {q3, q4}, [r2,:128]!
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH 08/10] swscale/arm/yuv2rgb: re-organize the code like its aarch64 counter part

[Matthieu Bouron]

On Fri, Mar 25, 2016 at 11:46 PM, Matthieu Bouron  wrote:

> From: Matthieu Bouron 
>
> ---
>  libswscale/arm/yuv2rgb_neon.S | 154
> +++---
>  1 file changed, 69 insertions(+), 85 deletions(-)
>

Patch updated (resolve a conflict with the updated version of patch 06/10).
From d06a5437f9042e0b350556e9642d52866284e7a8 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Wed, 23 Mar 2016 14:10:45 +
Subject: [PATCH 08/10] swscale/arm/yuv2rgb: re-organize the code like its
 aarch64 counter part

---
 libswscale/arm/yuv2rgb_neon.S | 154 +++---
 1 file changed, 69 insertions(+), 85 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 6279637..6a15778 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -21,90 +21,6 @@
 
 #include "libavutil/arm/asm.S"
 
-
-.macro compute_premult half_u1, half_u2, half_v1, half_v2
-vmovd2, \half_u1   @ copy left q14 to left q1
-vmovd3, \half_u1   @ copy left q14 to right q1
-vmovd4, \half_u2   @ copy right q14 to left q2
-vmovd5, \half_u2   @ copy right q14 to right q2
-
-vmovd6, \half_v1   @ copy left q15 to left q3
-vmovd7, \half_v1   @ copy left q15 to right q3
-vmovd8, \half_v2   @ copy right q15 to left q4
-vmovd9, \half_v2   @ copy right q15 to right q4
-
-vzip.16 d2, d3 @ U1U1U2U2U3U3U4U4
-vzip.16 d4, d5 @ U5U5U6U6U7U7U8U8
-
-vzip.16 d6, d7 @ V1V1V2V2V3V3V4V4
-vzip.16 d8, d9 @ V5V5V6V6V7V7V8V8
-
-vmul.s16q8,  q3, d1[0] @  V * v2r (left,  red)
-vmul.s16q9,  q4, d1[0] @  V * v2r (right, red)
-vmul.s16q10, q1, d1[1] @  U * u2g
-vmul.s16q11, q2, d1[1] @  U * u2g
-vmla.s16q10, q3, d1[2] @  U * u2g + V * v2g   (left,  green)
-vmla.s16q11, q4, d1[2] @  U * u2g + V * v2g   (right, green)
-vmul.s16q12, q1, d1[3] @  U * u2b (left,  blue)
-vmul.s16q13, q2, d1[3] @  U * u2b (right, blue)
-.endm
-
-.macro compute_color dst_comp1 dst_comp2 pre1 pre2
-vadd.s16q1, q14, \pre1
-vadd.s16q2, q15, \pre2
-vqrshrun.s16\dst_comp1, q1, #6
-vqrshrun.s16\dst_comp2, q2, #6
-.endm
-
-.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
-compute_color   \r1, \r2, q8,  q9
-compute_color   \g1, \g2, q10, q11
-compute_color   \b1, \b2, q12, q13
-vmov.u8 \a1, #255
-vmov.u8 \a2, #255
-.endm
-
-.macro compute_16px dst y0 y1 ofmt
-vmovl.u8q14, \y0   @ 8px of y
-vmovl.u8q15, \y1   @ 8px of y
-
-vdup.16 q5, r9 @ q5  = y_offset
-vmovd14, d0@ q7  = y_coeff
-vmovd15, d0@ q7  = y_coeff
-
-vsub.s16q14, q5
-vsub.s16q15, q5
-
-vmul.s16q14, q7@ q14 = (srcY - y_offset) * y_coeff (left)
-vmul.s16q15, q7@ q15 = (srcY - y_offset) * y_coeff (right)
-
-
-.ifc \ofmt,argb
-compute_rgbad7, d11, d8, d12, d9, d13, d6, d10
-.endif
-
-.ifc \ofmt,rgba
-compute_rgbad6, d10, d7, d11, d8, d12, d9, d13
-.endif
-
-.ifc \ofmt,abgr
-compute_rgbad9, d13, d8, d12, d7, d11, d6, d10
-.endif
-
-.ifc \ofmt,bgra
-compute_rgbad8, d12, d7, d11, d6, d10, d9, d13
-.endif
-vst4.8  {q3, q4}, [\dst,:128]!
-vst4.8  {q5, q6}, [\dst,:128]!
-
-.endm
-
-.macro process_1l_16px ofmt
-compute_premult d28, d29, d30, d31
-vld1.8  {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
-.endm
-
 .macro load_args_nv12
 push{r4-r12, lr}
 

Re: [FFmpeg-devel] [PATCH 07/10] swscale/arm/yuv2rgb: macro-ify

[Matthieu Bouron]

On Fri, Mar 25, 2016 at 11:46 PM, Matthieu Bouron  wrote:

> From: Matthieu Bouron 
>
> ---
>  libswscale/arm/yuv2rgb_neon.S | 115
> ++
>  1 file changed, 39 insertions(+), 76 deletions(-)
>

[...]

Patch updated (resolve a conflict with the updated version of patch 06/10).
From f8a7db56aba4b38089698c2f87583b071d03bf29 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Wed, 23 Mar 2016 13:51:10 +
Subject: [PATCH 07/10] swscale/arm/yuv2rgb: macro-ify

---
 libswscale/arm/yuv2rgb_neon.S | 116 ++
 1 file changed, 39 insertions(+), 77 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 6aeccae..6279637 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -105,7 +105,7 @@
 compute_16pxr2, d14, d15, \ofmt
 .endm
 
-.macro load_args_nvx
+.macro load_args_nv12
 push{r4-r12, lr}
 vpush   {q4-q7}
 ldr r4, [sp, #104] @ r4  = srcY
@@ -122,6 +122,10 @@
 sub r7, r7, r0 @ r7 = linesizeC - width (paddingC)
 .endm
 
+.macro load_args_nv21
+load_args_nv12
+.endm
+
 .macro load_args_yuv420p
 push{r4-r12, lr}
 vpush   {q4-q7}
@@ -146,116 +150,74 @@
 load_args_yuv420p
 .endm
 
-.macro declare_func ifmt ofmt
-function ff_\ifmt\()_to_\ofmt\()_neon, export=1
-
-.ifc \ifmt,nv12
-load_args_nvx
-.endif
-
-.ifc \ifmt,nv21
-load_args_nvx
-.endif
-
-.ifc \ifmt,yuv420p
-load_args_yuv420p
-.endif
-
-
-.ifc \ifmt,yuv422p
-load_args_yuv422p
-.endif
-
-1:
-mov r8, r0 @ r8 = width
-2:
-pld [r6, #64*3]
-pld [r4, #64*3]
-
-vmov.i8 d10, #128
-
-.ifc \ifmt,nv12
+.macro load_chroma_nv12
 vld2.8  {d2, d3}, [r6]!@ q1: interleaved chroma line
 vsubl.u8q14, d2, d10   @ q14 = U - 128
 vsubl.u8q15, d3, d10   @ q15 = V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,nv21
+.macro load_chroma_nv21
 vld2.8  {d2, d3}, [r6]!@ q1: interleaved chroma line
 vsubl.u8q14, d3, d10   @ q14 = U - 128
 vsubl.u8q15, d2, d10   @ q15 = V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv420p
-pld [r10, #64*3]
-
-vld1.8  d2, [r6]!  @ d2: chroma red line
-vld1.8  d3, [r10]! @ d3: chroma blue line
-vsubl.u8q14, d2, d10   @ q14 = U - 128
-vsubl.u8q15, d3, d10   @ q15 = V - 128
-
-process_1l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv420p
 pld [r10, #64*3]
 
 vld1.8  d2, [r6]!  @ d2: chroma red line
 vld1.8  d3, [r10]! @ d3: chroma blue line
 vsubl.u8q14, d2, d10   @ q14 = U - 128
 vsubl.u8q15, d3, d10   @ q15 = V - 128
+.endm
 
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width -= 16
-bgt 2b
-
-add r2, r2, r3 @ dst   += padding
-add r4, r4, r5 @ srcY  += paddingY
-
-.ifc \ifmt,nv12
-tst r1, #1
-ite eq
-subeq   r6, r6, r0 @ if (height % 2 == 0) paddingU -= width
-addne   r6, r7 @ else paddingU += linesizeU - width
-
-subsr1, r1, #1 @ height -= 1
-.endif
+.macro load_chroma_yuv422p
+load_chroma_yuv420p
+.endm
 
-.ifc \ifmt,nv21
+.macro increment_nv12
 tst r1, #1
 ite eq
 subeq   r6, r6, r0 @ if (height % 2 == 0) paddingU -= width
 addne   r6, r7 @ else paddingU += linesizeU - width
+.endm
 
-subsr1, r1, #1 @ height -= 1
-.endif
+.macro increment_nv21
+increment_nv12
+.endm
 
-.ifc \ifmt,yuv420p
+.macro increment_yuv420p
 tst r1, #1
 

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Steven Liu]

2016-03-27 2:42 GMT+08:00 Bodecs Bela :

>
>
> 2016.03.26. 15:10 keltezéssel, Steven Liu írta:
>
>> Because the hls_flags use delete_segments flag can delete the old
>>
>> segment files and instead of the hls_wrap option, so remove it.
>>
>> I suggest to leave hls_wrap option to be available. If you use this
> option, the set of output file names is the same as the value of hls_wrap,
> so it depends on you and sometimes it is very convinent. Mainly when you
> use ffmpeg in scripting environment.
>
> There have a problem:

There are 3 segment files in playlist,set hls_time 2,and the keyframe is
not  uniform:
test-0.ts
test-1.ts
test-2.ts

It's  dangerous  when refreshing the segment files for player.
There are repeated or jump segments problem.

Signed-off-by: LiuQi 
>>
>> ---
>>
>>   doc/muxers.texi  | 9 -
>>
>>   libavformat/hlsenc.c | 8 +++-
>>
>>   2 files changed, 3 insertions(+), 14 deletions(-)
>>
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>
>> index c36c72c..4dabfd1 100644
>>
>> --- a/doc/muxers.texi
>>
>> +++ b/doc/muxers.texi
>>
>> @@ -284,15 +284,6 @@ Set output format options using a :-separated list of
>> key=value
>>
>>   parameters. Values containing @code{:} special characters must be
>>
>>   escaped.
>>
>>
>>
>> -@item hls_wrap @var{wrap}
>>
>> -Set the number after which the segment filename number (the number
>>
>> -specified in each segment file) wraps. If set to 0 the number will be
>>
>> -never wrapped. Default value is 0.
>>
>> -
>>
>> -This option is useful to avoid to fill the disk with many segment
>>
>> -files, and limits the maximum number of segment files written to disk
>>
>> -to @var{wrap}.
>>
>> -
>>
>>   @item start_number @var{number}
>>
>>   Start the playlist sequence number from @var{number}. Default value is
>>
>>   0.
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>
>> index fd36b21..a22543a 100644
>>
>> --- a/libavformat/hlsenc.c
>>
>> +++ b/libavformat/hlsenc.c
>>
>> @@ -84,7 +84,6 @@ typedef struct HLSContext {
>>
>>
>>
>>   float time;// Set by a private option.
>>
>>   int max_nb_segments;   // Set by a private option.
>>
>> -int  wrap; // Set by a private option.
>>
>>   uint32_t flags;// enum HLSFlags
>>
>>   uint32_t pl_type;  // enum PlaylistType
>>
>>   char *segment_filename;
>>
>> @@ -373,7 +372,7 @@ static int hls_append_segment(struct AVFormatContext
>> *s, HLSContext *hls, double
>>
>>   en = hls->segments;
>>
>>   hls->segments = en->next;
>>
>>   if (en && hls->flags & HLS_DELETE_SEGMENTS &&
>>
>> -!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
>>
>> +!(hls->flags & HLS_SINGLE_FILE)) {
>>
>>   en->next = hls->old_segments;
>>
>>   hls->old_segments = en;
>>
>>   if ((ret = hls_delete_old_segments(hls)) < 0)
>>
>> @@ -561,13 +560,13 @@ static int hls_start(AVFormatContext *s)
>>
>>   av_free(fn_copy);
>>
>>   }
>>
>>   } else if (av_get_frame_filename(oc->filename,
>> sizeof(oc->filename),
>>
>> -  c->basename, c->wrap ? c->sequence %
>> c->wrap : c->sequence) < 0) {
>>
>> +  c->basename, c->sequence) < 0) {
>>
>>   av_log(oc, AV_LOG_ERROR, "Invalid segment filename template
>> '%s' you can try use -use_localtime 1 with it\n", c->basename);
>>
>>   return AVERROR(EINVAL);
>>
>>   }
>>
>>   if( c->vtt_basename) {
>>
>>   if (av_get_frame_filename(vtt_oc->filename,
>> sizeof(vtt_oc->filename),
>>
>> -  c->vtt_basename, c->wrap ? c->sequence %
>> c->wrap : c->sequence) < 0) {
>>
>> +  c->vtt_basename, c->sequence) < 0) {
>>
>>   av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename
>> template '%s'\n", c->vtt_basename);
>>
>>   return AVERROR(EINVAL);
>>
>>   }
>>
>> @@ -911,7 +910,6 @@ static const AVOption options[] = {
>>
>>   {"hls_list_size", "set maximum number of playlist entries",
>> OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0,
>> INT_MAX,
>> E},
>>
>>   {"hls_ts_options","set hls mpegts list of options for the container
>> format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING,
>> {.str
>> = NULL},  0, 0,E},
>>
>>   {"hls_vtt_options","set hls vtt list of options for the container
>> format used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING,
>> {.str = NULL},  0, 0,E},
>>
>> -{"hls_wrap",  "set number after which the index wraps",
>> OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
>>
>>   {"hls_allow_cache", "explicitly set whether the client MAY (1) or
>> MUST
>> NOT (0) cache media segments", OFFSET(allowcache), AV_OPT_TYPE_INT, {.i64
>> =
>> -1}, INT_MIN, INT_MAX, 

Re: [FFmpeg-devel] fate : add test for exr B44, B44A files

[Paul B Mahol]

On 3/26/16, Martin Vignali  wrote:
> 2016-03-26 21:24 GMT+01:00 Paul B Mahol :
>
>> On 3/26/16, Martin Vignali  wrote:
>> > Hello,
>> >
>> > In attach a patch for fate test of B44/B44A compression inside openexr
>> > file.
>> > samples can be download here : http://we.tl/QwJcxVn9CV
>> > need to be put inside : ./fate-suite/exr/
>> >
>> > Detail of tests :
>> >
>> > rgba_scanline_float_b44.exr : test scanline B44 float file
>> >  (uncompress data)
>> >
>> > rgba_multiscanline_half_b44.exr : b44 file with alpha. have multiple
>> > scanlines
>> >
>> > rgba_scanline_half_b44_12x8.exr : have b44 and b44A block, all pixels
>> > inside b44 block are used in the final picture
>> >
>> > rgba_scanline_half_b44_13x9.exr : have b44 and b44A block, some pixels
>> > in
>> > B44 block are not used in the final picture
>>
>> Do you have by any chance INT32 format exr files?
>>
>
> In attach a sample (it's a 4 point gradient), but most software display it
> in white (for thoses who interpret it in float, you need to reduce a lot
> the exposure (-30. in after effects), to have something close to the
> original render.)
>
> Like UINT32 of exr is mostly for 3D data pass (like object id), i don't
> know how to interpret it (in a general way) as rgba image.
>
>
>
>> Do you gonna add other missing features, mostly tile and subsampling
>> support?
>>
>> Yes (both are in progress)
> - tile support (because it's the default render mode of several 3D
> software).
> - subsampling (mostly for YCbCr 420 mode , because it's the "more common"
> mode with subsampling (can be output by RgbaOutputFile class of the
> official library (like in Adobe After Effects using Luma/Chroma mode).
>
> The French National Cinematography Center (http://www.cnc.fr/web/en)
> support us (Jokyo Images) for this work, in order to have a better use of
> ffmpeg inside post-production companies (who use openexr), avoiding lot of
> intermediate conversion (like what is suggest in ffmpeg wiki)

Awesome! looking for patches.

>
>
> Best Regards
>
> Martin
> Jokyo Images
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mov: add support for reading end padding from gapless itunes metadata

[Marton Balint]

On Tue, 22 Mar 2016, Michael Niedermayer wrote:


On Mon, Mar 21, 2016 at 01:06:21AM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 libavformat/mov.c| 13 ++---
 tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 12 ++--
 tests/ref/fate/gaplessinfo-itunes1   |  2 +-
 tests/ref/fate/gaplessinfo-itunes2   |  2 +-
 4 files changed, 18 insertions(+), 11 deletions(-)


breaks (latest) fate

some tests seem improve some seem to get worse


Hmm, it seems our HE-AAC decoder is using more samples for 
priming than it supposed to... Also there is the issue of duplicated 
sample rate in case of spectral band replication, which sooner or later 
will cause problems, because the priming is in the base sample rate but 
the codec sample rate is the duplicated sample rate...


I will extract the usable parts from this patchset, and re-send them, 
unfortunately I will not be able to work on gapless support further 
because of my limited knowledge of the AAC decoder, and that needs fixing 
as well, in order to not make things worse.


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

Re: [FFmpeg-devel] fate : add test for exr B44, B44A files

[Martin Vignali]

2016-03-26 21:24 GMT+01:00 Paul B Mahol :

> On 3/26/16, Martin Vignali  wrote:
> > Hello,
> >
> > In attach a patch for fate test of B44/B44A compression inside openexr
> > file.
> > samples can be download here : http://we.tl/QwJcxVn9CV
> > need to be put inside : ./fate-suite/exr/
> >
> > Detail of tests :
> >
> > rgba_scanline_float_b44.exr : test scanline B44 float file
> >  (uncompress data)
> >
> > rgba_multiscanline_half_b44.exr : b44 file with alpha. have multiple
> > scanlines
> >
> > rgba_scanline_half_b44_12x8.exr : have b44 and b44A block, all pixels
> > inside b44 block are used in the final picture
> >
> > rgba_scanline_half_b44_13x9.exr : have b44 and b44A block, some pixels in
> > B44 block are not used in the final picture
>
> Do you have by any chance INT32 format exr files?
>

In attach a sample (it's a 4 point gradient), but most software display it
in white (for thoses who interpret it in float, you need to reduce a lot
the exposure (-30. in after effects), to have something close to the
original render.)

Like UINT32 of exr is mostly for 3D data pass (like object id), i don't
know how to interpret it (in a general way) as rgba image.



> Do you gonna add other missing features, mostly tile and subsampling
> support?
>
> Yes (both are in progress)
- tile support (because it's the default render mode of several 3D
software).
- subsampling (mostly for YCbCr 420 mode , because it's the "more common"
mode with subsampling (can be output by RgbaOutputFile class of the
official library (like in Adobe After Effects using Luma/Chroma mode).

The French National Cinematography Center (http://www.cnc.fr/web/en)
support us (Jokyo Images) for this work, in order to have a better use of
ffmpeg inside post-production companies (who use openexr), avoiding lot of
intermediate conversion (like what is suggest in ffmpeg wiki)


Best Regards

Martin
Jokyo Images


INT_32_SCANLINE_UNCOMPRESSED.exr
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Configure with --cpu=host and Clang

[yukari yakumo]

Oh, seems like upstream already have this patch...
Well, clang doesn't have -mcpu at all, there -march only, just for gcc 
compatibility.

26.03.2016, 23:37, "Reimar Döffinger" :
> On 26.03.2016, at 13:10, yukari yakumo  wrote:
>>  Hi everyone!
>>  I'm Gentoo Linux user and currently I play with Clang as default compiler.
>>  And currently I tried to build ffmpeg 2.8.6 with Clang 3.9.0 and 
>> `-march=native` in C(XX)FLAGS (ffmpeg-2.8.6.ebuild automatically convert 
>> this to `--cpu=host` configure flag).
>>  But I get `--cpu=host not supported with compiler clang` error on 
>> configure phase. It's seems like output of clang test compilation different 
>> from GCC's output.
>>  I make a little patch that you can find in attachment to fix this issue. 
>> This is very similar to GCC's check_native method.
>
> Is there a need for all that?
> It's used for gcc because the gcc developers decided to randomly use -march 
> and -mcpu with no sense or system.
> If -march=native always does the right thing for clang, just testing if it is 
> accepted should be enough?
> ___
> 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] Configure with --cpu=host and Clang

[Reimar Döffinger]

On 26.03.2016, at 13:10, yukari yakumo  wrote:
> Hi everyone!
> I'm Gentoo Linux user and currently I play with Clang as default compiler.
> And currently I tried to build ffmpeg 2.8.6 with Clang 3.9.0 and 
> `-march=native` in C(XX)FLAGS (ffmpeg-2.8.6.ebuild automatically convert this 
> to `--cpu=host` configure flag).
> But I get `--cpu=host not supported with compiler clang` error on configure 
> phase. It's seems like output of clang test compilation different from GCC's 
> output.
> I make a little patch that you can find in attachment to fix this issue. This 
> is very similar to GCC's check_native method.

Is there a need for all that?
It's used for gcc because the gcc developers decided to randomly use -march and 
-mcpu with no sense or system.
If -march=native always does the right thing for clang, just testing if it is 
accepted should be enough?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Thilo Borgmann]

Am 26.03.16 um 15:00 schrieb Josh de Kock:
> On 26/03/2016 13:28, Michael Niedermayer wrote:
>> +@section Code of conduct
>> +
>> +Respect other people, treat others the way you yourself want to be treated.
> The Code of Conduct is simple, and is based around a few key points:

No ',', I think, just plain "and".


> *insert goal of project here*
> 
> Be friendly & respectful.

... and ...


> This is the most simple point; treat others the way you would like to be
> treated.

... point: Treat others...


>> +Be tolerant to differences in oppinion, people often have different 
>> priorities
>> +and may see a problem from a different viewpoint.
>> +Do not assume mallice for things that can be attributed to incompetence. 
>> Even if
>> +it is mallice its rarely good to start with that as initial assumtation.

> Be considerate.
> Not everyone has the viewpoint as you; different opinions, and
> interpretations help the project, as looking at issues from a different
> angle can assist development.

Be considerate. Not everyone shares the same viewpoint as you do.
Different opinions and interpretations help the project.
Looking at issues from a different perspective assists development.


>> +Act friendly towards others and about 3rd parties.

Act friendly towards others and third parties.


>> +Be friendly when someone once has a bad day or is angry and acts unfriendly.
>> +Everyone has a bad day once in a while.

Stay friendly even if someone acts contrarily. Everyone has a bad day
once in a while.


>> +If you yourself have a bad day or are angry then try to take a break and 
>> reply
>> +once you are calm and without anger if you have to.

If it is you who misbehaved in such a way, try to take a break and
continue to reply once you are in a good mood again.


>> +Help other teammembers if you can instead of trying to personally gain from 
>> not helping.

Try to help other team members and cooperate if you can.


>> +The goal of Software development is to create technical excellence, not for 
>> any
>> +individual to be better and "win" against the others. Large software 
>> projects
>> +are only possible and successfull through teamwork.
> This is open source, it's for the common good.

This is open source and it is for the common good.


> Remember that there are others who try to benefit from the project, and
> in different ways. Some want to use it, some want to contribute to it,
> but the main thing is that we all have a goal--to help each other. 

Remember that there are other who try to benefit from the project in
different ways. There are users and contributors but everyone shares our
common goal of helping each other.


> If you see someone struggling with something, rather than putting them
> down, why not help them? Give them some pointers, or show them in the
> right direction.

If someone struggles do not put them down. Give them a helping hand
instead and point them in the right direction.


>> +Or maybe all that can be condensed into Bill and Teds words
> However, all these point can easily be summarised using Bill & Ted's
> words: "Be excellent to each other."

Finally, ... "Be excellent to each other."



I think I might have made it a little better. However, I'm far from
being a native speaker.

-Thilo

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

Re: [FFmpeg-devel] fate : add test for exr B44, B44A files

[Paul B Mahol]

On 3/26/16, Martin Vignali  wrote:
> Hello,
>
> In attach a patch for fate test of B44/B44A compression inside openexr
> file.
> samples can be download here : http://we.tl/QwJcxVn9CV
> need to be put inside : ./fate-suite/exr/
>
> Detail of tests :
>
> rgba_scanline_float_b44.exr : test scanline B44 float file
>  (uncompress data)
>
> rgba_multiscanline_half_b44.exr : b44 file with alpha. have multiple
> scanlines
>
> rgba_scanline_half_b44_12x8.exr : have b44 and b44A block, all pixels
> inside b44 block are used in the final picture
>
> rgba_scanline_half_b44_13x9.exr : have b44 and b44A block, some pixels in
> B44 block are not used in the final picture

Do you have by any chance INT32 format exr files?

Do you gonna add other missing features, mostly tile and subsampling support?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] fate : add test for exr B44, B44A files

[Martin Vignali]

Hello,

In attach a patch for fate test of B44/B44A compression inside openexr file.
samples can be download here : http://we.tl/QwJcxVn9CV
need to be put inside : ./fate-suite/exr/

Detail of tests :

rgba_scanline_float_b44.exr : test scanline B44 float file
 (uncompress data)

rgba_multiscanline_half_b44.exr : b44 file with alpha. have multiple
scanlines

rgba_scanline_half_b44_12x8.exr : have b44 and b44A block, all pixels
inside b44 block are used in the final picture

rgba_scanline_half_b44_13x9.exr : have b44 and b44A block, some pixels in
B44 block are not used in the final picture



Martin
Jokyo Images
From adb891b3789ed355a012e4924b293fe025dd7992 Mon Sep 17 00:00:00 2001
From: Martin Vignali 
Date: Sat, 26 Mar 2016 21:02:07 +0100
Subject: [PATCH] fate/exr : add test for b44/b44a compression

---
 tests/fate/image.mak   | 12 
 tests/ref/fate/exr-rgb-scanline-float-b44  |  2 ++
 tests/ref/fate/exr-rgb-scanline-half-b44-12x8  |  2 ++
 tests/ref/fate/exr-rgb-scanline-half-b44-13x9  |  2 ++
 tests/ref/fate/exr-rgba-multiscanline-half-b44 |  2 ++
 5 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/exr-rgb-scanline-float-b44
 create mode 100644 tests/ref/fate/exr-rgb-scanline-half-b44-12x8
 create mode 100644 tests/ref/fate/exr-rgb-scanline-half-b44-13x9
 create mode 100644 tests/ref/fate/exr-rgba-multiscanline-half-b44

diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index 2224e3e..4155d6b 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -65,6 +65,18 @@ fate-exr-slice-zip16: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_slice_zip16.e
 FATE_EXR += fate-exr-slice-pxr24
 fate-exr-slice-pxr24: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_slice_pxr24.exr -pix_fmt rgb48le
 
+FATE_EXR += fate-exr-rgba-multiscanline-half-b44
+fate-exr-rgba-multiscanline-half-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgba_multiscanline_half_b44.exr -pix_fmt rgba64le
+
+FATE_EXR += fate-exr-rgb-scanline-float-b44
+fate-exr-rgb-scanline-float-b44: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_float_b44.exr -pix_fmt rgb48le
+
+FATE_EXR += fate-exr-rgb-scanline-half-b44-12x8
+fate-exr-rgb-scanline-half-b44-12x8: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_12x8.exr -pix_fmt rgb48le
+
+FATE_EXR += fate-exr-rgb-scanline-half-b44-13x9
+fate-exr-rgb-scanline-half-b44-13x9: CMD = framecrc -i $(TARGET_SAMPLES)/exr/rgb_scanline_half_b44_13x9.exr -pix_fmt rgb48le
+
 FATE_EXR-$(call DEMDEC, IMAGE2, EXR) += $(FATE_EXR)
 
 FATE_IMAGE += $(FATE_EXR-yes)
diff --git a/tests/ref/fate/exr-rgb-scanline-float-b44 b/tests/ref/fate/exr-rgb-scanline-float-b44
new file mode 100644
index 000..d8f3934
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-scanline-float-b44
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  576, 0x39c8e03e
diff --git a/tests/ref/fate/exr-rgb-scanline-half-b44-12x8 b/tests/ref/fate/exr-rgb-scanline-half-b44-12x8
new file mode 100644
index 000..ce1e009
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-scanline-half-b44-12x8
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  576, 0x506469f9
diff --git a/tests/ref/fate/exr-rgb-scanline-half-b44-13x9 b/tests/ref/fate/exr-rgb-scanline-half-b44-13x9
new file mode 100644
index 000..e40608d
--- /dev/null
+++ b/tests/ref/fate/exr-rgb-scanline-half-b44-13x9
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  702, 0x6914838a
diff --git a/tests/ref/fate/exr-rgba-multiscanline-half-b44 b/tests/ref/fate/exr-rgba-multiscanline-half-b44
new file mode 100644
index 000..e82481d
--- /dev/null
+++ b/tests/ref/fate/exr-rgba-multiscanline-half-b44
@@ -0,0 +1,2 @@
+#tb 0: 1/25
+0,  0,  0,1,  1877480, 0x6f28b860
-- 
1.9.3 (Apple Git-50)

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

Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder

[Lou Logan]

On Sat, 26 Mar 2016 22:18:47 +0530, Disha Singh wrote:

> From 639aa2a07be6064049b2ba1e134e1474cb7f0806 Mon Sep 17 00:00:00 2001
> From: dinux5 
> Date: Sat, 26 Mar 2016 22:11:59 +0530
> Subject: [PATCH] Mlp encoder addition.
> 
> ---
>  configure  |1 +
>  libavcodec/Makefile|1 +
>  libavcodec/allcodecs.c |2 +-
>  libavcodec/mlp.h   |4 +
>  libavcodec/mlpenc.c| 2443 
> 
>  5 files changed, 2450 insertions(+), 1 deletion(-)
>  create mode 100755 libavcodec/mlpenc.c

Tabs and trailing whitespace should be avoided. Using tools/patcheck
will tell you where they are, or if you like vim or emacs see:

http://ffmpeg.org/developer.html#Editor-configuration
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_colormatrix: add 10 & 12 bit depth support

[Ronald S. Bultje]

Hi,

On Sat, Mar 26, 2016 at 10:04 AM, Thomas Mundt <
loudmax-at-yahoo...@ffmpeg.org> wrote:

> >>>Kieran Kunhya  schrieb am Sa, 26.3.2016:
> >> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt  ffmpeg.org> wrote:
> >
> >> Signed-off-by: Thomas Mundt 
> >> ---
> >>  libavfilter/vf_colormatrix.c | 182
> >> ++-
> >>
> >
> > These functions are basically the same, have you considered factoring the
> > code out?
> >
> > Kieran
>
> I thought keeping it seperate would be easier to review.
> But I can do that. Maybe as a subsequent patch?


I think he means templating out typelessly like h264/hevc/vp9 do. I agree
that would probably be nicer. Binary size is same but less duplicated code.

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

Re: [FFmpeg-devel] [PATCH 0/4] avfilter/vf_colormatrix: add UHD support

[Thomas Mundt]

>>>Ronald S. Bultje  schrieb am Sa, 26.3.2016:
> Hi,
> 
> On Fri, Mar 25, 2016 at 6:30 PM, Thomas Mundt  ffmpeg.org> wrote:
> 
>> These patches add bt.2020 colorspace and 10 and 12 bit depth support.
>> The calculation of the Y component is simplified but with identical
>> results.
>> Some unused variables are removed.
>> The YUV croma coefficients are calculated instead of taken from a rough
>> rounded table.
>> Since these calculations happen only once the increased precision is worth
>> it.
>> Please comment.
>
>
> I was working on this also, very cool!

Great, thanks! If you have other/better ideas or solutions feel free to bring 
them in.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Bodecs Bela]

2016.03.26. 15:10 keltezéssel, Steven Liu írta:

Because the hls_flags use delete_segments flag can delete the old

segment files and instead of the hls_wrap option, so remove it.

I suggest to leave hls_wrap option to be available. If you use this 
option, the set of output file names is the same as the value of 
hls_wrap, so it depends on you and sometimes it is very convinent. 
Mainly when you use ffmpeg in scripting environment.



Signed-off-by: LiuQi 

---

  doc/muxers.texi  | 9 -

  libavformat/hlsenc.c | 8 +++-

  2 files changed, 3 insertions(+), 14 deletions(-)


diff --git a/doc/muxers.texi b/doc/muxers.texi

index c36c72c..4dabfd1 100644

--- a/doc/muxers.texi

+++ b/doc/muxers.texi

@@ -284,15 +284,6 @@ Set output format options using a :-separated list of
key=value

  parameters. Values containing @code{:} special characters must be

  escaped.



-@item hls_wrap @var{wrap}

-Set the number after which the segment filename number (the number

-specified in each segment file) wraps. If set to 0 the number will be

-never wrapped. Default value is 0.

-

-This option is useful to avoid to fill the disk with many segment

-files, and limits the maximum number of segment files written to disk

-to @var{wrap}.

-

  @item start_number @var{number}

  Start the playlist sequence number from @var{number}. Default value is

  0.

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c

index fd36b21..a22543a 100644

--- a/libavformat/hlsenc.c

+++ b/libavformat/hlsenc.c

@@ -84,7 +84,6 @@ typedef struct HLSContext {



  float time;// Set by a private option.

  int max_nb_segments;   // Set by a private option.

-int  wrap; // Set by a private option.

  uint32_t flags;// enum HLSFlags

  uint32_t pl_type;  // enum PlaylistType

  char *segment_filename;

@@ -373,7 +372,7 @@ static int hls_append_segment(struct AVFormatContext
*s, HLSContext *hls, double

  en = hls->segments;

  hls->segments = en->next;

  if (en && hls->flags & HLS_DELETE_SEGMENTS &&

-!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {

+!(hls->flags & HLS_SINGLE_FILE)) {

  en->next = hls->old_segments;

  hls->old_segments = en;

  if ((ret = hls_delete_old_segments(hls)) < 0)

@@ -561,13 +560,13 @@ static int hls_start(AVFormatContext *s)

  av_free(fn_copy);

  }

  } else if (av_get_frame_filename(oc->filename,
sizeof(oc->filename),

-  c->basename, c->wrap ? c->sequence %
c->wrap : c->sequence) < 0) {

+  c->basename, c->sequence) < 0) {

  av_log(oc, AV_LOG_ERROR, "Invalid segment filename template
'%s' you can try use -use_localtime 1 with it\n", c->basename);

  return AVERROR(EINVAL);

  }

  if( c->vtt_basename) {

  if (av_get_frame_filename(vtt_oc->filename,
sizeof(vtt_oc->filename),

-  c->vtt_basename, c->wrap ? c->sequence %
c->wrap : c->sequence) < 0) {

+  c->vtt_basename, c->sequence) < 0) {

  av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename
template '%s'\n", c->vtt_basename);

  return AVERROR(EINVAL);

  }

@@ -911,7 +910,6 @@ static const AVOption options[] = {

  {"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
E},

  {"hls_ts_options","set hls mpegts list of options for the container
format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str
= NULL},  0, 0,E},

  {"hls_vtt_options","set hls vtt list of options for the container
format used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING,
{.str = NULL},  0, 0,E},

-{"hls_wrap",  "set number after which the index wraps",
OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},

  {"hls_allow_cache", "explicitly set whether the client MAY (1) or MUST
NOT (0) cache media segments", OFFSET(allowcache), AV_OPT_TYPE_INT, {.i64 =
-1}, INT_MIN, INT_MAX, E},

  {"hls_base_url",  "url to prepend to each playlist entry",
OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,   E},

  {"hls_segment_filename", "filename template for segment files",
OFFSET(segment_filename),   AV_OPT_TYPE_STRING, {.str = NULL},
0,   0, E},



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


bb

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

Re: [FFmpeg-devel] [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time for the yuv420p and nv{12, 21} formats

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 01:05:56PM +0100, Matthieu Bouron wrote:
> On Sat, Mar 26, 2016 at 2:09 AM, Michael Niedermayer  > wrote:
> 
> > On Fri, Mar 25, 2016 at 11:46:01PM +0100, Matthieu Bouron wrote:
> > > From: Matthieu Bouron 
> > >
> > > ---
> > >  libswscale/arm/yuv2rgb_neon.S | 89
> > ---
> > >  1 file changed, 24 insertions(+), 65 deletions(-)
> >
> > breaks build
> >
> >  make distclean ; ../configure --cross-prefix=/usr/arm-linux-gnueabi/bin/
> > --cc='ccache arm-linux-gnueabi-gcc-4.5' --extra-cflags='-mfpu=neon
> > -mfloat-abi=softfp' --cpu=cortex-a8 --arch=armv7 --target-os=linux
> > --enable-cross-compile && make -j12
> >
> > CC  libavutil/arm/float_dsp_init_arm.o
> > src/libswscale/arm/yuv2rgb_neon.S: Assembler messages:
> > src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
> > instruction should be in IT block -- `subeq r6,r6,r0'
> > src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
> > instruction should be in IT block -- `addne r6,r7'
> >
> 
> [...]
> 
> Patch updated with the relevant it instructions added. It still does build
> on my rpi2 setup but is not tested on the same setup as yours.
> Can you confirm it builds/works on your setup ?

confirmed up to and includng this patch

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_slice: Update first_slice when updating current_slice for 2nd fields

[Kieran Kunhya]

On Fri, 25 Mar 2016 at 16:33 Michael Niedermayer 
wrote:

> This fixes Ticket 4389 differently
> Fixes Ticket5371
> Fixes null pointer dereference
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_slice.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 9a5bc3f..c4340dc 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1188,6 +1188,7 @@ int ff_h264_decode_slice_header(H264Context *h,
> H264SliceContext *sl)
>  if (h->cur_pic_ptr && FIELD_PICTURE(h) && h->first_field) {
>  ret = ff_h264_field_end(h, h->slice_ctx, 1);
>  h->current_slice = 0;
> +first_slice = 1;
>  if (ret < 0)
>  return ret;
>  } else if (h->cur_pic_ptr && !FIELD_PICTURE(h) &&
> !h->first_field && h->nal_unit_type  == NAL_IDR_SLICE) {
> @@ -1422,7 +1423,7 @@ int ff_h264_decode_slice_header(H264Context *h,
> H264SliceContext *sl)
>  }
>  }
>
> -if (!h->current_slice && h->dequant_coeff_pps != pps_id) {
> +if (first_slice && h->dequant_coeff_pps != pps_id) {
>  h->dequant_coeff_pps = pps_id;
>  ff_h264_init_dequant_tables(h);
>  }
> --
> 1.7.9.5
>
>
Ok if tested but I will fuzz more.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Steven Liu]

2016-03-27 0:35 GMT+08:00 Michael Niedermayer :

> On Sat, Mar 26, 2016 at 11:47:37PM +0800, Steven Liu wrote:
> > 2016-03-26 22:58 GMT+08:00 Michael Niedermayer :
> >
> > > On Sat, Mar 26, 2016 at 10:10:28PM +0800, Steven Liu wrote:
> > > > Because the hls_flags use delete_segments flag can delete the old
> > > >
> > > > segment files and instead of the hls_wrap option, so remove it.
> > >
> > > options should be deprecated and replacement documented before
> > > removial
> > >
> > >
> > Hi Michael,
> >
> >   You mean is that i need add some introduction in doc/ for this
> patch,
> > is it?
> >   I saw the .gitignore file have been ignore the files:
> >   /doc/ffmpeg-all.1
> >   /doc/ffmpeg-formats.pod
> >   /doc/ffmpeg-all.pod
> >   /doc/ffserver-all.1
> >   /doc/ffserver-all.pod
> >
> >  There just one file of the document: /doc/muxers.texi
> >
> >   What can i do for this patch next step?
> >   Can you give me some suggestions?
>
> explain in the docs under the hls-wrap option what users should do
> instead of using the deprecated option


 The **hls_wrap** option is used for avoid to fill the disk with many
segment files, and limits the maximum number of segment files written to
disk to wrap. But the **"hls_flags delete_segments** option is can do this
function. So hls_wrap is needless，This is what the patch done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] fate: Modify a random h264 test to also test the -framerate option

[Michael Niedermayer]

On Sun, Mar 20, 2016 at 08:37:58PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/h264.mak  |5 -
>  tests/ref/fate/h264-conformance-ba1_ft_c |2 +-
>  2 files changed, 5 insertions(+), 2 deletions(-)

patchset applied

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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Steven Liu]

2016-03-26 22:58 GMT+08:00 Michael Niedermayer :

> On Sat, Mar 26, 2016 at 10:10:28PM +0800, Steven Liu wrote:
> > Because the hls_flags use delete_segments flag can delete the old
> >
> > segment files and instead of the hls_wrap option, so remove it.
>
> options should be deprecated and replacement documented before
> removial
>
>
Hi Michael,

  You mean is that i need add some introduction in doc/ for this patch,
is it?
  I saw the .gitignore file have been ignore the files:
  /doc/ffmpeg-all.1
  /doc/ffmpeg-formats.pod
  /doc/ffmpeg-all.pod
  /doc/ffserver-all.1
  /doc/ffserver-all.pod

 There just one file of the document: /doc/muxers.texi

  What can i do for this patch next step?
  Can you give me some suggestions?


Thanks

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

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Michael Niedermayer]

On Sat, Mar 26, 2016 at 10:10:28PM +0800, Steven Liu wrote:
> Because the hls_flags use delete_segments flag can delete the old
> 
> segment files and instead of the hls_wrap option, so remove it.

options should be deprecated and replacement documented before
removial

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousands in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] [PATCH] mpegts: pcr period option for variable bitrate multiplexing

[Michael Niedermayer]

On Fri, Mar 25, 2016 at 12:50:29PM -0400, Predrag Filipovic wrote:
> Enable proper PCR insertion for VBR multiplexing (muxrate not specified).
> Insertion timing is based on video frame keys and frame period, consequently
> pcr period precision is limited to +/- one video frame period.
> 
> Signed-off-by: Predrag Filipovic 
> ---
>  libavformat/mpegtsenc.c | 80 
> +
>  1 file changed, 61 insertions(+), 19 deletions(-)
> 
> diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> index 7656720..7ed9076 100644
> --- a/libavformat/mpegtsenc.c
> +++ b/libavformat/mpegtsenc.c
> @@ -105,6 +105,7 @@ typedef struct MpegTSWrite {
>  int tables_version;
>  double pat_period;
>  double sdt_period;
> +int64_t last_pcr_ts;
>  int64_t last_pat_ts;
>  int64_t last_sdt_ts;
>  
> @@ -903,6 +904,9 @@ static int mpegts_init(AVFormatContext *s)
>  ts_st = pcr_st->priv_data;
>  
>  if (ts->mux_rate > 1) {
> +if (ts->pcr_period >= INT_MAX/2) {
> +ts->pcr_period = PCR_RETRANS_TIME;
> +}
>  service->pcr_packet_period = (int64_t)ts->mux_rate * ts->pcr_period /
>   (TS_PACKET_SIZE * 8 * 1000);
>  ts->sdt_packet_period  = (int64_t)ts->mux_rate * 
> SDT_RETRANS_TIME /
> @@ -931,10 +935,19 @@ static int mpegts_init(AVFormatContext *s)
>  service->pcr_packet_period =
>  ts_st->user_tb.den / (10 * ts_st->user_tb.num);
>  }
> -if (!service->pcr_packet_period)
> +/* if pcr_period specified, mark pcr_packet_period as NA (=INT_MAX) 
> */
> +if (ts->pcr_period < INT_MAX/2) {
> +service->pcr_packet_period = INT_MAX;
> +} else {
> +if (!service->pcr_packet_period) {
>  service->pcr_packet_period = 1;
> +} else if (service->pcr_packet_period == INT_MAX) {
> +service->pcr_packet_period--;
> +}
> +}

there is somethig wrong with the indention here

have you tested the patch with multiple programs ?
what have you used to test that the TS after this patch is more
valid than before ?

[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/flicvideo: Implement padding in COPY chunks.

[Carl Eugen Hoyos]

Reimar Döffinger  gmx.de> writes:

> > +if (s->avctx->width & 3)
> > +bytestream2_skip(, 4 - (s->avctx->width & 3));
> 
> Maybe it's more reliable/clear to keep like that

Yes, it definitely is imo;-)

> but I think this could also be written as
> bytestream2_skip(, -s-≥avctx->width & 3);

> Should be fine otherwise I think.

Thank you, patch applied.

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

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Steven Liu]

2016-03-26 22:21 GMT+08:00 Carl Eugen Hoyos :

> Steven Liu  gmail.com> writes:
>
> > Because the hls_flags use delete_segments flag can delete the old
> >
> > segment files and instead of the hls_wrap option, so remove it.
> >
> > Signed-off-by: LiuQi  gosun.com>
>
> I cannot comment on the content of your patch but
> it seems your mailer has corrupted it so it cannot
> get applied.
>
> Hi Carl,

   What about this attachment file ?


0001-remove-the-hls_wrap-option.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] remove the hls_wrap option

[Carl Eugen Hoyos]

Steven Liu  gmail.com> writes:

> Because the hls_flags use delete_segments flag can delete the old
> 
> segment files and instead of the hls_wrap option, so remove it.
> 
> Signed-off-by: LiuQi  gosun.com>

I cannot comment on the content of your patch but 
it seems your mailer has corrupted it so it cannot 
get applied.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_colormatrix: add 10 & 12 bit depth support

[Thomas Mundt]

>>>Kieran Kunhya  schrieb am Sa, 26.3.2016:
>> On Fri, 25 Mar 2016 at 22:32 Thomas Mundt > ffmpeg.org> wrote:
>
>> Signed-off-by: Thomas Mundt 
>> ---
>>  libavfilter/vf_colormatrix.c | 182
>> ++-
>>
>
> These functions are basically the same, have you considered factoring the
> code out?
>
> Kieran

I thought keeping it seperate would be easier to review.
But I can do that. Maybe as a subsequent patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/4] avfilter/vf_colormatrix: add UHD support

[Ronald S. Bultje]

Hi,

On Fri, Mar 25, 2016 at 6:30 PM, Thomas Mundt <
loudmax-at-yahoo...@ffmpeg.org> wrote:

> These patches add bt.2020 colorspace and 10 and 12 bit depth support.
> The calculation of the Y component is simplified but with identical
> results.
> Some unused variables are removed.
> The YUV croma coefficients are calculated instead of taken from a rough
> rounded table.
> Since these calculations happen only once the increased precision is worth
> it.
> Please comment.


I was working on this also, very cool!

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

Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Clément Bœsch]

On Sat, Mar 26, 2016 at 02:28:46PM +0100, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/developer.texi |   19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/doc/developer.texi b/doc/developer.texi
> index 6db93ce..ec21c57 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -403,6 +403,25 @@ finding a new maintainer and also don't forget to update 
> the @file{MAINTAINERS}
>  
>  We think our rules are not too hard. If you have comments, contact us.
>  
> +@section Code of conduct
> +
> +Respect other people, treat others the way you yourself want to be treated.
> +Be tolerant to differences in oppinion, people often have different 
> priorities
> +and may see a problem from a different viewpoint.
> +Do not assume mallice for things that can be attributed to incompetence. 
> Even if
> +it is mallice its rarely good to start with that as initial assumtation.
> +Act friendly towards others and about 3rd parties.
> +Be friendly when someone once has a bad day or is angry and acts unfriendly.
> +Everyone has a bad day once in a while.
> +If you yourself have a bad day or are angry then try to take a break and 
> reply
> +once you are calm and without anger if you have to.
> +Help other teammembers if you can instead of trying to personally gain from 
> not helping.
> +The goal of Software development is to create technical excellence, not for 
> any
> +individual to be better and "win" against the others. Large software projects
> +are only possible and successfull through teamwork.
> +Or maybe all that can be condensed into Bill and Teds words
> +"Be excellent to each other."
> +

:set spell

→ oppinion
→ mallice (x2)
→ assumtation
→ teammembers
→ successfull

Regards,

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi |   19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 6db93ce..ec21c57 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -403,6 +403,25 @@ finding a new maintainer and also don't forget to update 
the @file{MAINTAINERS}
 
 We think our rules are not too hard. If you have comments, contact us.
 
+@section Code of conduct
+
+Respect other people, treat others the way you yourself want to be treated.
+Be tolerant to differences in oppinion, people often have different priorities
+and may see a problem from a different viewpoint.
+Do not assume mallice for things that can be attributed to incompetence. Even 
if
+it is mallice its rarely good to start with that as initial assumtation.
+Act friendly towards others and about 3rd parties.
+Be friendly when someone once has a bad day or is angry and acts unfriendly.
+Everyone has a bad day once in a while.
+If you yourself have a bad day or are angry then try to take a break and reply
+once you are calm and without anger if you have to.
+Help other teammembers if you can instead of trying to personally gain from 
not helping.
+The goal of Software development is to create technical excellence, not for any
+individual to be better and "win" against the others. Large software projects
+are only possible and successfull through teamwork.
+Or maybe all that can be condensed into Bill and Teds words
+"Be excellent to each other."
+
 @anchor{Submitting patches}
 @section Submitting patches
 
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH]lavc/fic: Be less verbose for invisible or empty cursor

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #5174, there seems to be nothing invalid about a 
cursor outside of the screen or an empty cursor.

Please comment, Carl Eugen
diff --git a/libavcodec/fic.c b/libavcodec/fic.c
index 7d698f0..3b5cb29 100644
--- a/libavcodec/fic.c
+++ b/libavcodec/fic.c
@@ -309,7 +309,7 @@ static int fic_decode_frame(AVCodecContext *avctx, void 
*data,
 return AVERROR_INVALIDDATA;
 }
 
-if (!tsize)
+if (!tsize || !AV_RL16(src + 37) || !AV_RL16(src + 39))
 skip_cursor = 1;
 
 if (!skip_cursor && tsize < 32) {
@@ -322,7 +322,7 @@ static int fic_decode_frame(AVCodecContext *avctx, void 
*data,
 cur_x = AV_RL16(src + 33);
 cur_y = AV_RL16(src + 35);
 if (!skip_cursor && (cur_x > avctx->width || cur_y > avctx->height)) {
-av_log(avctx, AV_LOG_WARNING,
+av_log(avctx, AV_LOG_DEBUG,
"Invalid cursor position: (%d,%d). Skipping cusor.\n",
cur_x, cur_y);
 skip_cursor = 1;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_colormatrix: add 10 & 12 bit depth support

[Kieran Kunhya]

On Fri, 25 Mar 2016 at 22:32 Thomas Mundt 
wrote:

> Signed-off-by: Thomas Mundt 
> ---
>  libavfilter/vf_colormatrix.c | 182
> ++-
>

These functions are basically the same, have you considered factoring the
code out?

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

Re: [FFmpeg-devel] [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time for the yuv420p and nv{12, 21} formats

[Matthieu Bouron]

On Sat, Mar 26, 2016 at 2:09 AM, Michael Niedermayer  wrote:

> On Fri, Mar 25, 2016 at 11:46:01PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> >
> > ---
> >  libswscale/arm/yuv2rgb_neon.S | 89
> ---
> >  1 file changed, 24 insertions(+), 65 deletions(-)
>
> breaks build
>
>  make distclean ; ../configure --cross-prefix=/usr/arm-linux-gnueabi/bin/
> --cc='ccache arm-linux-gnueabi-gcc-4.5' --extra-cflags='-mfpu=neon
> -mfloat-abi=softfp' --cpu=cortex-a8 --arch=armv7 --target-os=linux
> --enable-cross-compile && make -j12
>
> CC  libavutil/arm/float_dsp_init_arm.o
> src/libswscale/arm/yuv2rgb_neon.S: Assembler messages:
> src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
> instruction should be in IT block -- `subeq r6,r6,r0'
> src/libswscale/arm/yuv2rgb_neon.S:269: Error: thumb conditional
> instruction should be in IT block -- `addne r6,r7'
>

[...]

Patch updated with the relevant it instructions added. It still does build
on my rpi2 setup but is not tested on the same setup as yours.
Can you confirm it builds/works on your setup ?

If it works, i will send an updated version of the next patch (07/10) to
resolve the conflicts.

Matthieu
From 7b3a405b2b483fb16f549b69ce6f21d8a946 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Wed, 23 Mar 2016 11:26:13 +
Subject: [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time
 for the yuv420p and nv{12,21} formats

---
 libswscale/arm/yuv2rgb_neon.S | 92 +--
 1 file changed, 27 insertions(+), 65 deletions(-)

diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..6aeccae 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -105,16 +105,6 @@
 compute_16pxr2, d14, d15, \ofmt
 .endm
 
-.macro process_2l_16px ofmt
-compute_premult d28, d29, d30, d31
-
-vld1.8  {q7}, [r4]!@ first line of luma
-compute_16pxr2, d14, d15, \ofmt
-
-vld1.8  {q7}, [r12]!   @ second line of luma
-compute_16pxr11, d14, d15, \ofmt
-.endm
-
 .macro load_args_nvx
 push{r4-r12, lr}
 vpush   {q4-q7}
@@ -127,13 +117,9 @@
 ldr r10,[sp, #128] @ r10 = y_coeff
 vdup.16 d0, r10@ d0  = y_coeff
 vld1.16 {d1}, [r8] @ d1  = *table
-add r11, r2, r3@ r11 = dst + linesize (dst2)
-add r12, r4, r5@ r12 = srcY + linesizeY (srcY2)
-lsl r3, r3, #1
-lsl r5, r5, #1
-sub r3, r3, r0, lsl #2 @ r3 = linesize  * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 = linesizeY * 2 - width (paddingY)
-sub r7, r7, r0 @ r7 = linesizeC - width (paddingC)
+sub r3, r3, r0, lsl #2 @ r3 = linesize  - width * 4 (padding)
+sub r5, r5, r0 @ r5 = linesizeY - width (paddingY)
+sub r7, r7, r0 @ r7 = linesizeC - width (paddingC)
 .endm
 
 .macro load_args_yuv420p
@@ -142,26 +128,6 @@
 ldr r4, [sp, #104] @ r4  = srcY
 ldr r5, [sp, #108] @ r5  = linesizeY
 ldr r6, [sp, #112] @ r6  = srcU
-ldr r8, [sp, #128] @ r8  = table
-ldr r9, [sp, #132] @ r9  = y_offset
-ldr r10,[sp, #136] @ r10 = y_coeff
-vdup.16 d0, r10@ d0  = y_coeff
-vld1.16 {d1}, [r8] @ d1  = *table
-add r11, r2, r3@ r11 = dst + linesize (dst2)
-add r12, r4, r5@ r12 = srcY + linesizeY (srcY2)
-lsl r3, r3, #1
-lsl r5, r5, #1
-sub r3, r3, r0, lsl #2 @ r3 = linesize  * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 = linesizeY * 2 - width (paddingY)
-ldr r10,[sp, #120] @ r10 = 

[FFmpeg-devel] Configure with --cpu=host and Clang

[yukari yakumo]

Hi everyone!
I'm Gentoo Linux user and currently I play with Clang as default compiler.
And currently I tried to build ffmpeg 2.8.6 with Clang 3.9.0 and 
`-march=native` in C(XX)FLAGS (ffmpeg-2.8.6.ebuild automatically convert this 
to `--cpu=host` configure flag).
But I get `--cpu=host not supported with compiler clang` error on configure 
phase. It's seems like output of clang test compilation different from GCC's 
output.
I make a little patch that you can find in attachment to fix this issue. This 
is very similar to GCC's check_native method.
Thanks!--- a/configure
+++ b/configure
@@ -3838,6 +3838,17 @@
 }
 cpu=$(check_native -march || check_native -mcpu)
 ;;
+clang)
+check_native(){
+$cc $1=native -v -c -o $TMPO $TMPC >$TMPE 2>&1 || return
+sed -n "/cc1.*-target-cpu /{
+s/.*-target-cpu \\([^ ]*\\).*/\\1/
+p
+q
+}" $TMPE
+}
+cpu=$(check_native -march)
+;;
 esac
 
 test "${cpu:-host}" = host &&
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Fwd: libavcodec/exr : add B44 and B44A compression

[Martin Vignali]

2016-03-26 12:28 GMT+01:00 Carl Eugen Hoyos :

> Martin Vignali  gmail.com> writes:
>
> > New patch attached, with ILM copyright at the top of the file
> > And remove some comments line.
> >
> > Ping
>
> The patch was applied today by Paul, no mail appeared
> on cvslog so far.
>
> Carl Eugen
>
>
Sorry didn't check, before ping.

Thanks

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

Re: [FFmpeg-devel] Fwd: libavcodec/exr : add B44 and B44A compression

[Carl Eugen Hoyos]

Martin Vignali  gmail.com> writes:

> New patch attached, with ILM copyright at the top of the file
> And remove some comments line.
> 
> Ping

The patch was applied today by Paul, no mail appeared 
on cvslog so far.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH 1/4] avfilter/vf_colormatrix: increase precision

[Thomas Mundt]

>>>Michael Niedermayer  schrieb am Sa, 26.3.2016:
>
> this causes some compiler warnings
>
> libavfilter/vf_colormatrix.c: In function ‘calc_coefficients’:
> libavfilter/vf_colormatrix.c:163:9: warning: passing argument 2 of 
> ‘inverse3x3’ from incompatible pointer type [enabled by default]
> libavfilter/vf_colormatrix.c:117:13: note: expected ‘const double (*)[3]’ but 
> argument is of type ‘double (*)[3]’
> libavfilter/vf_colormatrix.c:166:13: warning: passing argument 3 of 
> ‘solve_coefficients’ from incompatible pointer type [enabled by default]
> libavfilter/vf_colormatrix.c:132:13: note: expected ‘const double (*)[3]’ but 
> argument is of type ‘double (*)[3]’

Strange, here (msys mingw-w64 gcc5.3) these warnings don´t appear.
But it´s correct of course. New patch attached.

0001-avfilter-vf_colormatrix-increase-precision.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame already starts with startcode

[Hendrik Leppkes]

On Sat, Mar 26, 2016 at 11:10 AM, Carl Eugen Hoyos  wrote:
> Hendrik Leppkes  gmail.com> writes:
>
>> On Sat, Mar 26, 2016 at 10:38 AM, Carl Eugen Hoyos wrote:
>
>> >   /* nothing to filter */
>> > - if (!avctx->extradata || avctx->extradata_size < 6) {
>> > + if (   !avctx->extradata || avctx->extradata_size < 6
>> > + || !buf[0] && !buf[1] && (buf[2] == 1 || !buf[2] && buf[3] == 1)) {
>> >   *poutbuf  = (uint8_t *)buf;
>> >   *poutbuf_size = buf_size;
>> >   return 0;
>>
>> A 4-byte mp4 style size code could conceivably start with 0x01xx
>> (ie. a size from 256 bytes to 511 bytes), this seems very risky.
>
> Understood.
> Is it ok to test for 32bit "1"?
> ie:
> || !buf[0] && !buf[1] && !buf[2] && buf[3] == 1)
>

Conceivably a stream could also have a 1-byte sized NAL, ie. a AUD, or
EOS, there are a number of NALs without payload.
Checking for only 4 byte start codes would be incomplete either way
and probably not worth tripping into new bugs along the way, IMHO
anyway.

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

Re: [FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame already starts with startcode

[Carl Eugen Hoyos]

Hendrik Leppkes  gmail.com> writes:

> On Sat, Mar 26, 2016 at 10:38 AM, Carl Eugen Hoyos wrote:

> >   /* nothing to filter */
> > - if (!avctx->extradata || avctx->extradata_size < 6) {
> > + if (   !avctx->extradata || avctx->extradata_size < 6
> > + || !buf[0] && !buf[1] && (buf[2] == 1 || !buf[2] && buf[3] == 1)) {
> >   *poutbuf  = (uint8_t *)buf;
> >   *poutbuf_size = buf_size;
> >   return 0;
> 
> A 4-byte mp4 style size code could conceivably start with 0x01xx
> (ie. a size from 256 bytes to 511 bytes), this seems very risky.

Understood.
Is it ok to test for 32bit "1"?
ie:
|| !buf[0] && !buf[1] && !buf[2] && buf[3] == 1)

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] Implement hdcd filtering

[Carl Eugen Hoyos]

Benjamin St  gmail.com> writes:

> I tried to test with the files sample.cdda.flac and
> > sample.hdcd.flac attached in the ticket.
> > The output is different and one possible reason
> > is the usage of floating point arithmetic in the
> > filter.
> 
> Did you compare flac files or raw audiodata (e.g. wav)?

I did compare wav but I probably made a mistake:
I can confirm that the output is bitexact with the 
Windows app and your patch.

> For me flac it is not identical but wav is.

> (probably due to different flac encoders?)

I also used the FFmpeg flac encoder when producing the 
sample file...

Not all of the comments on top of the filter file look 
very useful to me, what do you think?
In any case, I'd say a link to these should be useful:
http://www.audiomisc.co.uk/HFN/HDCD/Enigma.html
http://www.audiomisc.co.uk/HFN/HDCD/Examined.html
(Or only the second one.)

Please also add a fate test, since this is using floats, 
I would suggest to only compare pcm_s16 (instead of 24).

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame already starts with startcode

[Hendrik Leppkes]

On Sat, Mar 26, 2016 at 10:38 AM, Carl Eugen Hoyos  wrote:
> index 2d447f7..170db31 100644
> --- a/libavcodec/h264_mp4toannexb_bsf.c
> +++ b/libavcodec/h264_mp4toannexb_bsf.c
> @@ -167,7 +167,8 @@ static int 
> h264_mp4toannexb_filter(AVBitStreamFilterContext *bsfc,
>  int ret = 0;
>
>  /* nothing to filter */
> -if (!avctx->extradata || avctx->extradata_size < 6) {
> +if (   !avctx->extradata || avctx->extradata_size < 6
> +|| !buf[0] && !buf[1] && (buf[2] == 1 || !buf[2] && buf[3] == 1)) {
>  *poutbuf  = (uint8_t *)buf;
>  *poutbuf_size = buf_size;
>  return 0;

A 4-byte mp4 style size code could conceivably start with 0x01xx
(ie. a size from 256 bytes to 511 bytes), this seems very risky.

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

Re: [FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame already starts with startcode

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

>  /* nothing to filter */
> -if (!avctx->extradata || avctx->extradata_size < 6) {
> +if (   !avctx->extradata || avctx->extradata_size < 6
> +|| !buf[0]

Inserted "buf_size > 3 && " locally.

Carl Eugen

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

[FFmpeg-devel] [PATCH]lavc/h264_mp4toannexb: Do not fail if frame already starts with startcode

[Carl Eugen Hoyos]

Hi!

The h264_mp4toannexb filter already does not fail if no extradata 
is provided. Attached patch makes it also not fail if extradata 
was provided but the stream is already in Annex B format.

Fixes ticket #5380.

Please comment, Carl Eugen
diff --git a/libavcodec/h264_mp4toannexb_bsf.c 
b/libavcodec/h264_mp4toannexb_bsf.c
index 2d447f7..170db31 100644
--- a/libavcodec/h264_mp4toannexb_bsf.c
+++ b/libavcodec/h264_mp4toannexb_bsf.c
@@ -167,7 +167,8 @@ static int h264_mp4toannexb_filter(AVBitStreamFilterContext 
*bsfc,
 int ret = 0;
 
 /* nothing to filter */
-if (!avctx->extradata || avctx->extradata_size < 6) {
+if (   !avctx->extradata || avctx->extradata_size < 6
+|| !buf[0] && !buf[1] && (buf[2] == 1 || !buf[2] && buf[3] == 1)) {
 *poutbuf  = (uint8_t *)buf;
 *poutbuf_size = buf_size;
 return 0;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel