Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now
merged in libav.
On Tue, Jan 10, 2017 at 11:18 AM, Steve Lhomme wrote:
> This was not rejected and has been merged in libav.
> 3/4 and 4/4 seem to be valid too and pending on both sides. I just
> need to send an update of 4/4 as the libavcodec version has changed.
>
> On Wed, Jan 4, 2017 at 2:36 PM, Steve Lhomme wrote:
>> ---
>> libavcodec/dxva2_h264.c | 4 +---
>> libavcodec/dxva2_hevc.c | 4 +---
>> libavcodec/dxva2_internal.h | 5 +
>> libavcodec/dxva2_mpeg2.c| 4 +---
>> libavcodec/dxva2_vc1.c | 4 +---
>> libavcodec/dxva2_vp9.c | 4 +---
>> 6 files changed, 10 insertions(+), 15 deletions(-)
>>
>> diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
>> index 82a772d..59fa5e3 100644
>> --- a/libavcodec/dxva2_h264.c
>> +++ b/libavcodec/dxva2_h264.c
>> @@ -450,9 +450,7 @@ static int dxva2_h264_start_frame(AVCodecContext *avctx,
>> AVDXVAContext *ctx = avctx->hwaccel_context;
>> struct dxva2_picture_context *ctx_pic =
>> h->cur_pic_ptr->hwaccel_picture_private;
>>
>> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
>> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>> return -1;
>> assert(ctx_pic);
>>
>> diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
>> index 5a312ea..981c888 100644
>> --- a/libavcodec/dxva2_hevc.c
>> +++ b/libavcodec/dxva2_hevc.c
>> @@ -364,9 +364,7 @@ static int dxva2_hevc_start_frame(AVCodecContext *avctx,
>> AVDXVAContext *ctx = avctx->hwaccel_context;
>> struct hevc_dxva2_picture_context *ctx_pic =
>> h->ref->hwaccel_picture_private;
>>
>> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
>> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>> return -1;
>> av_assert0(ctx_pic);
>>
>> diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
>> index c962810..e5322ef 100644
>> --- a/libavcodec/dxva2_internal.h
>> +++ b/libavcodec/dxva2_internal.h
>> @@ -76,6 +76,9 @@ typedef union {
>> #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) (avctx->pix_fmt ==
>> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigBitstreamRaw :
>> ctx->dxva2.cfg->ConfigBitstreamRaw)
>> #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) (avctx->pix_fmt ==
>> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigIntraResidUnsigned :
>> ctx->dxva2.cfg->ConfigIntraResidUnsigned)
>> #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) (avctx->pix_fmt ==
>> AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigResidDiffAccelerator :
>> ctx->dxva2.cfg->ConfigResidDiffAccelerator)
>> +#define DXVA_CONTEXT_VALID(avctx, ctx)
>> (DXVA_CONTEXT_DECODER(avctx, ctx) && \
>> + DXVA_CONTEXT_CFG(avctx,
>> ctx) && \
>> + DXVA_CONTEXT_COUNT(avctx,
>> ctx))
>> #elif CONFIG_DXVA2
>> #define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->dxva2.workaround)
>> #define DXVA_CONTEXT_COUNT(avctx, ctx) (ctx->dxva2.surface_count)
>> @@ -85,6 +88,7 @@ typedef union {
>> #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)
>> (ctx->dxva2.cfg->ConfigBitstreamRaw)
>> #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx)
>> (ctx->dxva2.cfg->ConfigIntraResidUnsigned)
>> #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx)
>> (ctx->dxva2.cfg->ConfigResidDiffAccelerator)
>> +#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->dxva2.decoder &&
>> ctx->dxva2.cfg && ctx->dxva2.surface_count)
>> #elif CONFIG_D3D11VA
>> #define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->d3d11va.workaround)
>> #define DXVA_CONTEXT_COUNT(avctx, ctx) (ctx->d3d11va.surface_count)
>> @@ -94,6 +98,7 @@ typedef union {
>> #define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)
>> (ctx->d3d11va.cfg->ConfigBitstreamRaw)
>> #define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx)
>> (ctx->d3d11va.cfg->ConfigIntraResidUnsigned)
>> #define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx)
>> (ctx->d3d11va.cfg->ConfigResidDiffAccelerator)
>> +#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->d3d11va.decoder &&
>> ctx->d3d11va.cfg && ctx->d3d11va.surface_count)
>> #endif
>>
>> unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx,
>> diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
>> index c2f0b58..14ac48f 100644
>> --- a/libavcodec/dxva2_mpeg2.c
>> +++ b/libavcodec/dxva2_mpeg2.c
>> @@ -262,9 +262,7 @@ static int dxva2_mpeg2_start_frame(AVCodecContext *avctx,
>> struct dxva2_picture_context *ctx_pic =
>> s->current_picture_ptr->hwaccel_picture_private;
>>
>> -if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
>> -DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
>> +if (!DXVA_CONTEXT_VALID(avctx, ctx))
>> retur
[FFmpeg-devel] No header for avformat/hlsenc
Hi All, I am trying to use the HLSContext struct inside ffmpeg.c, in order to have access to the context's send_buffer_size value. However, the context struct is only defined inside hlsenc.c. Is there a specific reason for hlsenc not to have a header file? Are there any other options I may be missing? Please suggest. Thanks Kamal ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, 13 Jan 2017 09:52:18 +0100 Steve Lhomme wrote: > For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now > merged in libav. So how do we handle this. Do we wait until the merges catch up, or do you want to push your patches to ffmpeg's git immediately? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] No header for avformat/hlsenc
On Fri, 13 Jan 2017 14:35:09 +0530 Kamaldeep Tumkur wrote: > Hi All, > > I am trying to use the HLSContext struct inside ffmpeg.c, in order to > have access to the context's send_buffer_size value. However, the > context struct is only defined inside hlsenc.c. > > Is there a specific reason for hlsenc not to have a header file? Are > there any other options I may be missing? Please suggest. It's not public API, so it doesn't have a public header. ffmpeg.c is supposed to use public APIs only. I don't think there's a precedent of a muxer providing "extra" API via additional public structs/functions outside of avcodec.h. But there are cases where AVOptions are used to communicate data back and forth an implementation. E.g. the HTTP protocol uses an AVOption named "metadata" to return certain HTTP headers back to the API user. Not sure what's the best thing here to do. Either way, it's probably going to be slightly unclean. But I'm fairly sure exposing the entire HLSContext struct is not a reasonable option. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, Jan 13, 2017 at 10:47 AM, wm4 wrote: > On Fri, 13 Jan 2017 09:52:18 +0100 > Steve Lhomme wrote: > >> For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now >> merged in libav. > > So how do we handle this. Do we wait until the merges catch up, or do > you want to push your patches to ffmpeg's git immediately? Not sure what you mean. What merge are you talking about ? These 3 patches can live on their own, regardless of what is being done with d3d11va in hwcontext and ffmpeg. I can send again 4/4 as the version number needs to be updated. > ___ > 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] No header for avformat/hlsenc
Thanks a lot for explaining this. I do see now that the needed metadata is being set on the HTTPContext struct in the http protocol file. For the ffmpeg.c app, AVFormatContext along with a few others are the only accessible structs through the public headers. HTTPContext, HLSContext and others are just defined inside their respective private implementations. AVFormatContext's priv->data also carries this context in it. If there are something set in the HTTPContext through av_dict_set and I wanted to access it inside ffmpeg.c using av_dict_get, what instance should this be called on? AVFormatContext->priv_data cast as an HTTPContext? What if I wanted to use AVClass to verify that the class name and only then proceed with reading the option? Thanks again. Kamal On Fri, Jan 13, 2017 at 3:21 PM, wm4 wrote: > On Fri, 13 Jan 2017 14:35:09 +0530 > Kamaldeep Tumkur wrote: > >> Hi All, >> >> I am trying to use the HLSContext struct inside ffmpeg.c, in order to >> have access to the context's send_buffer_size value. However, the >> context struct is only defined inside hlsenc.c. >> >> Is there a specific reason for hlsenc not to have a header file? Are >> there any other options I may be missing? Please suggest. > > It's not public API, so it doesn't have a public header. ffmpeg.c is > supposed to use public APIs only. > > I don't think there's a precedent of a muxer providing "extra" API via > additional public structs/functions outside of avcodec.h. But there are > cases where AVOptions are used to communicate data back and forth an > implementation. E.g. the HTTP protocol uses an AVOption named > "metadata" to return certain HTTP headers back to the API user. > > Not sure what's the best thing here to do. Either way, it's probably > going to be slightly unclean. But I'm fairly sure exposing the entire > HLSContext struct is not a reasonable option. > ___ > 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] No header for avformat/hlsenc
On Fri, 13 Jan 2017 16:04:57 +0530 Kamaldeep Tumkur wrote: > Thanks a lot for explaining this. I do see now that the needed > metadata is being set on the HTTPContext struct in the http protocol > file. For the ffmpeg.c app, AVFormatContext along with a few others > are the only accessible structs through the public headers. Via the AVOption API (see libavutil/opt.h). > HTTPContext, HLSContext and others are just defined inside their > respective private implementations. AVFormatContext's priv->data also > carries this context in it. Variables referenced by AVOptions are indirectly accessible via the AVOption API. > If there are something set in the HTTPContext through av_dict_set and > I wanted to access it inside ffmpeg.c using av_dict_get, what instance > should this be called on? AVFormatContext->priv_data cast as an > HTTPContext? What if I wanted to use AVClass to verify that the class > name and only then proceed with reading the option? Thanks again. You call the AVOption API on the AVCodecContext pointer. The dictionary stuff can also be used to set AVOptions, but obviously only in one direction. Also, please don't top-post. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavc/h264dec: reconstruct and debug flush frames as well
From: Clément Bœsch
---
libavcodec/h264dec.c | 99 +---
1 file changed, 56 insertions(+), 43 deletions(-)
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index ed0b7246b7..0cb0352485 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -1037,6 +1037,59 @@ static int is_extra(const uint8_t *buf, int buf_size)
return 1;
}
+static int finalize_frame(H264Context *h, AVFrame *dst, H264Picture *out, int
*got_frame)
+{
+int ret;
+
+if (((h->avctx->flags & AV_CODEC_FLAG_OUTPUT_CORRUPT) ||
+ (h->avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL) ||
+ out->recovered)) {
+
+if (!out->recovered)
+out->f->flags |= AV_FRAME_FLAG_CORRUPT;
+
+if (!h->avctx->hwaccel &&
+(out->field_poc[0] == INT_MAX ||
+ out->field_poc[1] == INT_MAX)
+ ) {
+int p;
+AVFrame *f = out->f;
+int field = out->field_poc[0] == INT_MAX;
+uint8_t *dst_data[4];
+int linesizes[4];
+const uint8_t *src_data[4];
+
+av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill
missing\n", field);
+
+for (p = 0; p<4; p++) {
+dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
+src_data[p] = f->data[p] + field *f->linesize[p];
+linesizes[p] = 2*f->linesize[p];
+}
+
+av_image_copy(dst_data, linesizes, src_data, linesizes,
+ f->format, f->width, f->height>>1);
+}
+
+ret = output_frame(h, dst, out);
+if (ret < 0)
+return ret;
+
+*got_frame = 1;
+
+if (CONFIG_MPEGVIDEO) {
+ff_print_debug_info2(h->avctx, dst, NULL,
+ out->mb_type,
+ out->qscale_table,
+ out->motion_val,
+ NULL,
+ h->mb_width, h->mb_height, h->mb_stride, 1);
+}
+}
+
+return 0;
+}
+
static int h264_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame, AVPacket *avpkt)
{
@@ -1074,7 +1127,6 @@ static int h264_decode_frame(AVCodecContext *avctx, void
*data,
h->cur_pic_ptr = NULL;
h->first_field = 0;
-// FIXME factorize this with the output code below
out = h->delayed_pic[0];
out_idx = 0;
for (i = 1;
@@ -1092,10 +1144,9 @@ static int h264_decode_frame(AVCodecContext *avctx, void
*data,
if (out) {
out->reference &= ~DELAYED_PIC_REF;
-ret = output_frame(h, pict, out);
+ret = finalize_frame(h, pict, out, got_frame);
if (ret < 0)
return ret;
-*got_frame = 1;
}
return buf_index;
@@ -1141,48 +1192,10 @@ static int h264_decode_frame(AVCodecContext *avctx,
void *data,
return ret;
/* Wait for second field. */
-*got_frame = 0;
-if (h->next_output_pic && ((avctx->flags &
AV_CODEC_FLAG_OUTPUT_CORRUPT) ||
- (avctx->flags2 & AV_CODEC_FLAG2_SHOW_ALL) ||
- h->next_output_pic->recovered)) {
-if (!h->next_output_pic->recovered)
-h->next_output_pic->f->flags |= AV_FRAME_FLAG_CORRUPT;
-
-if (!h->avctx->hwaccel &&
- (h->next_output_pic->field_poc[0] == INT_MAX ||
- h->next_output_pic->field_poc[1] == INT_MAX)
-) {
-int p;
-AVFrame *f = h->next_output_pic->f;
-int field = h->next_output_pic->field_poc[0] == INT_MAX;
-uint8_t *dst_data[4];
-int linesizes[4];
-const uint8_t *src_data[4];
-
-av_log(h->avctx, AV_LOG_DEBUG, "Duplicating field %d to fill
missing\n", field);
-
-for (p = 0; p<4; p++) {
-dst_data[p] = f->data[p] + (field^1)*f->linesize[p];
-src_data[p] = f->data[p] + field *f->linesize[p];
-linesizes[p] = 2*f->linesize[p];
-}
-
-av_image_copy(dst_data, linesizes, src_data, linesizes,
- f->format, f->width, f->height>>1);
-}
-
-ret = output_frame(h, pict, h->next_output_pic);
+if (h->next_output_pic) {
+ret = finalize_frame(h, pict, h->next_output_pic, got_frame);
if (ret < 0)
return ret;
-*got_frame = 1;
-if (CONFIG_MPEGVIDEO) {
-ff_print_debug_info2(h->avctx, pict, NULL,
-h->next_output_pic->mb_type,
-h->next_output_pic->qscale_table,
-h->next_output_pic->motion_val
[FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
From: Clément Bœsch
---
libavcodec/pthread_frame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 7ef5e9f6be..cb6d76284e 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
+pthread_mutex_lock(&p->progress_mutex);
if(p->state == STATE_SETUP_FINISHED){
av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
calls\n");
}
-pthread_mutex_lock(&p->progress_mutex);
p->state = STATE_SETUP_FINISHED;
pthread_cond_broadcast(&p->progress_cond);
pthread_mutex_unlock(&p->progress_mutex);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] lavc/h264_slice: drop redundant current_slice reset
From: Clément Bœsch
It is done unconditionally in ff_h264_field_end()
---
libavcodec/h264_slice.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 9a334a97cb..2dc98c109c 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1797,13 +1797,11 @@ 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;
if (ret < 0)
return ret;
} else if (h->cur_pic_ptr && !FIELD_PICTURE(h) && !h->first_field
&& h->nal_unit_type == H264_NAL_IDR_SLICE) {
av_log(h, AV_LOG_WARNING, "Broken frame packetizing\n");
ret = ff_h264_field_end(h, h->slice_ctx, 1);
-h->current_slice = 0;
ff_thread_report_progress(&h->cur_pic_ptr->tf, INT_MAX, 0);
ff_thread_report_progress(&h->cur_pic_ptr->tf, INT_MAX, 1);
h->cur_pic_ptr = NULL;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/alsdec.c: testing MPEG-4 ALS decoder with floating point audio data
If als_07_2ch192k32bF.mp4 isn't already located in fate-suite/lossless-audio/, you can download at: http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-26_2010_Bitstreams/DVD1/mpeg4audio-conformance/compressedMp4/als_07_2ch192k32bF.mp4 Signed-off-by: Thomas Turner --- tests/fate/als.mak | 3 +++ tests/ref/fate/mpeg4-als-conformance-07 | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/ref/fate/mpeg4-als-conformance-07 diff --git a/tests/fate/als.mak b/tests/fate/als.mak index ff2badf..a67302c 100644 --- a/tests/fate/als.mak +++ b/tests/fate/als.mak @@ -7,5 +7,8 @@ endef $(foreach N,$(ALS_SUITE),$(eval $(call FATE_ALS_SUITE,$(N +FATE_ALS += fate-mpeg4-als-conformance-07 +fate-mpeg4-als-conformance-07: CMD = crc -i $(TARGET_SAMPLES)/lossless-audio/als_07_2ch192k32bF.mp4 + FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, ALS) += $(FATE_ALS) fate-als: $(FATE_ALS) diff --git a/tests/ref/fate/mpeg4-als-conformance-07 b/tests/ref/fate/mpeg4-als-conformance-07 new file mode 100644 index 000..1cc705d --- /dev/null +++ b/tests/ref/fate/mpeg4-als-conformance-07 @@ -0,0 +1 @@ +CRC=0x01503df3 -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264dec: Call ff_print_debug_info2() in flush codepath
On Thu, Jan 12, 2017 at 12:11:37PM +0100, Michael Niedermayer wrote:
> Found-by: ubitux
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/h264dec.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index ed0b7246b7..dabcaf698a 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -1096,6 +1096,15 @@ static int h264_decode_frame(AVCodecContext *avctx,
> void *data,
> if (ret < 0)
> return ret;
> *got_frame = 1;
> +if (CONFIG_MPEGVIDEO) {
> +ff_print_debug_info2(h->avctx, pict, NULL,
> +out->mb_type,
> +out->qscale_table,
> +out->motion_val,
> +NULL,
> +h->mb_width, h->mb_height, h->mb_stride,
> 1);
> +}
> +
superseded by "[PATCH 3/3] lavc/h264dec: reconstruct and debug flush frames
as well"
--
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, Jan 13, 2017 at 10:40:23AM +, Stève Lhomme wrote: > On Fri, Jan 13, 2017 at 10:47 AM, wm4 wrote: > > On Fri, 13 Jan 2017 09:52:18 +0100 > > Steve Lhomme wrote: > > > >> For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now > >> merged in libav. > > > > So how do we handle this. Do we wait until the merges catch up, or do > > you want to push your patches to ffmpeg's git immediately? > > Not sure what you mean. What merge are you talking about ? > These 3 patches can live on their own, regardless of what is being > done with d3d11va in hwcontext and ffmpeg. > I can send again 4/4 as the version number needs to be updated. when resending you may want to add a patch to add yourself to the MAINTAINERs file, maybe for d3d11va or any other part you want [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, Jan 13, 2017 at 01:01:14PM +0100, Michael Niedermayer wrote: > On Fri, Jan 13, 2017 at 10:40:23AM +, Stève Lhomme wrote: > > On Fri, Jan 13, 2017 at 10:47 AM, wm4 wrote: > > > On Fri, 13 Jan 2017 09:52:18 +0100 > > > Steve Lhomme wrote: > > > > > >> For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now > > >> merged in libav. > > > > > > So how do we handle this. Do we wait until the merges catch up, or do > > > you want to push your patches to ffmpeg's git immediately? > > > > Not sure what you mean. What merge are you talking about ? > > These 3 patches can live on their own, regardless of what is being > > done with d3d11va in hwcontext and ffmpeg. > > I can send again 4/4 as the version number needs to be updated. > > when resending you may want to add a patch to add yourself to the > MAINTAINERs file, maybe for d3d11va or any other part you want to clarify, i think you should have write access to git and the list of people havig write access should match the list of people in MAINTAINERs [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
Hi, I share this for comment... With square matrices I don't see any problem, as row=col when sending the COL FEC packets. But, with a non-square matrix the "col_out_idx" has inconsistent values (repeat values). Please, review this code. I feel now is correct. Best, A.H. 0001-avformat-Fix-Pro-MPEG-non-square-matrix.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
Hi,
> Original Message
> Subject: [FFmpeg-devel] [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
> From: andreas.ha...@protonmail.com
> To: FFmpeg development discussions and patches
>
> Hi,
>
> I share this for comment...
> With square matrices I don't see any problem, as row=col when sending the COL
> FEC packets.
> But, with a non-square matrix the "col_out_idx" has inconsistent values
> (repeat values).
>
> Please, review this code. I feel now is correct.
>
> Best,
> A.H.
> ___
Incorrect mime-type in the previous e-mail. Sorry!
I resend the patch in plain text...
A.H.
From 5b4401af5bdfe4736f5192f5dc118948f4906bda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?=
Date: Fri, 13 Jan 2017 13:07:57 +0100
Subject: [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
---
libavformat/prompeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index cc1baa4..9770a91 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -432,7 +432,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
// FEC (column) send block-aligned
if (!s->first && s->packet_idx % s->d == 0) {
- col_out_idx = s->packet_idx / s->l;
+ col_out_idx = s->packet_idx / s->d;
if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx], PROMPEG_FEC_COL)) < 0)
goto end;
written += ret;
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
Hi,
Impossible to send in plain-text...
Attached as text/plain in base64From 5b4401af5bdfe4736f5192f5dc118948f4906bda Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?=
Date: Fri, 13 Jan 2017 13:07:57 +0100
Subject: [PATCH 1/1] avformat: Fix Pro-MPEG non-square matrix
---
libavformat/prompeg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index cc1baa4..9770a91 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -432,7 +432,7 @@ static int prompeg_write(URLContext *h, const uint8_t *buf,
int size) {
// FEC (column) send block-aligned
if (!s->first && s->packet_idx % s->d == 0) {
-col_out_idx = s->packet_idx / s->l;
+col_out_idx = s->packet_idx / s->d;
if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx],
PROMPEG_FEC_COL)) < 0)
goto end;
written += ret;
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)
Hi,
I resend the attachment with the correct mime type: text/plain
Sorry!
Original Message
Subject: [PATCH] avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)
From: andreas.ha...@protonmail.com
To: ffmpeg-devel@ffmpeg.org
Hi,
This patch adds a new MUXER named "rtp_mpegtsraw". This new muxer works with
the "mpegtsraw" input demuxer. The objective is enable direct bitstream
input-output of MPEG-TS for RTP+FEC. Using the recent support for Pro-MPEG CoP
FEC protocol, you can now use FFmpeg for streaming any UDP/RTP MPEG-TS stream.
Example:
ffmpeg -f mpegtsraw -i udp://239.8.8.8:12345 -map 0 -c copy -f rtp_mpegtsraw
-fec prompeg=l=8:d=8 rtp://239.9.9.9:1
In this example FFmpeg reads from the network one stream in UDP o RTP format
from the multicast address 239.8.8.8:12345 and re-encapsulates it without
remuxing to the multicast address 239.9.9.9 using RTP+FEC
(ports 1 & 10001 are for the base RTP, port 10002 are for "row" and 10004
are for "column").
If you ever have had the need to do use FFmpeg in plain "bitstream" mode
with MPEG-TS streams, you have luck: know you can!
Please comment,
Andreas HåkonFrom 8b1dba724cbce3f368da7bdc97fd802939205c02 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?=
Date: Tue, 10 Jan 2017 17:02:04 +0100
Subject: [PATCH 1/2] avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output
---
ffmpeg.c| 1 +
libavformat/allformats.c| 1 +
libavformat/mpegts.c| 2 +-
libavformat/rtpenc.c| 6 ++
libavformat/rtpenc_mpegts.c | 48 +
5 files changed, 57 insertions(+), 1 deletion(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index b85c314..838f4d2 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3228,6 +3228,7 @@ static int init_output_stream_encode(OutputStream *ost)
}
break;
case AVMEDIA_TYPE_DATA:
+av_log(NULL, AV_LOG_TRACE, "Using bitstream with codec %s\n",
avcodec_get_name(enc_ctx->codec_id));
break;
default:
abort();
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 6a79b75..b58e178 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -269,6 +269,7 @@ void av_register_all(void)
REGISTER_MUXDEMUX(RSO, rso);
REGISTER_MUXDEMUX(RTP, rtp);
REGISTER_MUXER (RTP_MPEGTS, rtp_mpegts);
+REGISTER_MUXER (RTP_MPEGTSRAW,rtp_mpegtsraw);
REGISTER_MUXDEMUX(RTSP, rtsp);
REGISTER_DEMUXER (SAMI, sami);
REGISTER_MUXDEMUX(SAP, sap);
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0aa0ad7..2c23a05 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2663,7 +2663,7 @@ static int mpegts_read_header(AVFormatContext *s)
return AVERROR(ENOMEM);
avpriv_set_pts_info(st, 60, 1, 2700);
st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
-st->codecpar->codec_id = AV_CODEC_ID_MPEG2TS;
+st->codecpar->codec_id = AV_CODEC_ID_BIN_DATA;
/* we iterate until we find two PCRs to estimate the bitrate */
pcr_pid= -1;
diff --git a/libavformat/rtpenc.c b/libavformat/rtpenc.c
index efa63a5..e465501 100644
--- a/libavformat/rtpenc.c
+++ b/libavformat/rtpenc.c
@@ -82,6 +82,7 @@ static int is_supported(enum AVCodecID id)
case AV_CODEC_ID_MJPEG:
case AV_CODEC_ID_SPEEX:
case AV_CODEC_ID_OPUS:
+case AV_CODEC_ID_BIN_DATA:
return 1;
default:
return 0;
@@ -160,6 +161,7 @@ static int rtp_write_header(AVFormatContext *s1)
avpriv_set_pts_info(st, 32, 1, 9);
}
s->buf_ptr = s->buf;
+av_log(s1, AV_LOG_TRACE, "Using RTP muxer with codec %s\n",
avcodec_get_name(st->codecpar->codec_id));
switch(st->codecpar->codec_id) {
case AV_CODEC_ID_MP2:
case AV_CODEC_ID_MP3:
@@ -571,6 +573,7 @@ static int rtp_write_packet(AVFormatContext *s1, AVPacket
*pkt)
ff_rtp_send_amr(s1, pkt->data, size);
break;
case AV_CODEC_ID_MPEG2TS:
+case AV_CODEC_ID_BIN_DATA:
rtp_send_mpegts_raw(s1, pkt->data, size);
break;
case AV_CODEC_ID_DIRAC:
@@ -624,6 +627,9 @@ static int rtp_write_packet(AVFormatContext *s1, AVPacket
*pkt)
/* Intentional fallthrough */
default:
/* better than nothing : send the codec raw data */
+av_log(s1, AV_LOG_WARNING,
+ "RTP output is unsupported with codec %s\n",
+ avcodec_get_name(st->codecpar->codec_id));
rtp_send_raw(s1, pkt->data, size);
break;
}
diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
index 7af02e0..1e7177c 100644
--- a/libavformat/rtpenc_mpegts.c
+++ b/libavformat/rtpenc_mpegts.c
@@ -143,6 +143,43 @@ static int rtp_mpegts_write_packet(AVFormatContext *s,
AVPacket *pkt)
return ret;
}
+static int rtp_mpegtsraw_write_close(AVFormatContext *s)
+{
+rtp_mpegts_write_clo
[FFmpeg-devel] [PATCH 1/3] dxva2: use a single macro to test if the DXVA context is valid
---
libavcodec/dxva2_h264.c | 4 +---
libavcodec/dxva2_hevc.c | 4 +---
libavcodec/dxva2_internal.h | 5 +
libavcodec/dxva2_mpeg2.c| 4 +---
libavcodec/dxva2_vc1.c | 4 +---
libavcodec/dxva2_vp9.c | 4 +---
6 files changed, 10 insertions(+), 15 deletions(-)
diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
index 82a772d..59fa5e3 100644
--- a/libavcodec/dxva2_h264.c
+++ b/libavcodec/dxva2_h264.c
@@ -450,9 +450,7 @@ static int dxva2_h264_start_frame(AVCodecContext *avctx,
AVDXVAContext *ctx = avctx->hwaccel_context;
struct dxva2_picture_context *ctx_pic =
h->cur_pic_ptr->hwaccel_picture_private;
-if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
-DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
-DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
+if (!DXVA_CONTEXT_VALID(avctx, ctx))
return -1;
assert(ctx_pic);
diff --git a/libavcodec/dxva2_hevc.c b/libavcodec/dxva2_hevc.c
index 5a312ea..981c888 100644
--- a/libavcodec/dxva2_hevc.c
+++ b/libavcodec/dxva2_hevc.c
@@ -364,9 +364,7 @@ static int dxva2_hevc_start_frame(AVCodecContext *avctx,
AVDXVAContext *ctx = avctx->hwaccel_context;
struct hevc_dxva2_picture_context *ctx_pic =
h->ref->hwaccel_picture_private;
-if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
-DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
-DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
+if (!DXVA_CONTEXT_VALID(avctx, ctx))
return -1;
av_assert0(ctx_pic);
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index c962810..e5322ef 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -76,6 +76,9 @@ typedef union {
#define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx) (avctx->pix_fmt ==
AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigBitstreamRaw :
ctx->dxva2.cfg->ConfigBitstreamRaw)
#define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx) (avctx->pix_fmt ==
AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigIntraResidUnsigned :
ctx->dxva2.cfg->ConfigIntraResidUnsigned)
#define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) (avctx->pix_fmt ==
AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigResidDiffAccelerator :
ctx->dxva2.cfg->ConfigResidDiffAccelerator)
+#define DXVA_CONTEXT_VALID(avctx, ctx) (DXVA_CONTEXT_DECODER(avctx,
ctx) && \
+ DXVA_CONTEXT_CFG(avctx, ctx)
&& \
+ DXVA_CONTEXT_COUNT(avctx,
ctx))
#elif CONFIG_DXVA2
#define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->dxva2.workaround)
#define DXVA_CONTEXT_COUNT(avctx, ctx) (ctx->dxva2.surface_count)
@@ -85,6 +88,7 @@ typedef union {
#define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)
(ctx->dxva2.cfg->ConfigBitstreamRaw)
#define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx)
(ctx->dxva2.cfg->ConfigIntraResidUnsigned)
#define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx)
(ctx->dxva2.cfg->ConfigResidDiffAccelerator)
+#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->dxva2.decoder &&
ctx->dxva2.cfg && ctx->dxva2.surface_count)
#elif CONFIG_D3D11VA
#define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->d3d11va.workaround)
#define DXVA_CONTEXT_COUNT(avctx, ctx) (ctx->d3d11va.surface_count)
@@ -94,6 +98,7 @@ typedef union {
#define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)
(ctx->d3d11va.cfg->ConfigBitstreamRaw)
#define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx)
(ctx->d3d11va.cfg->ConfigIntraResidUnsigned)
#define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx)
(ctx->d3d11va.cfg->ConfigResidDiffAccelerator)
+#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->d3d11va.decoder &&
ctx->d3d11va.cfg && ctx->d3d11va.surface_count)
#endif
unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx,
diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
index c2f0b58..14ac48f 100644
--- a/libavcodec/dxva2_mpeg2.c
+++ b/libavcodec/dxva2_mpeg2.c
@@ -262,9 +262,7 @@ static int dxva2_mpeg2_start_frame(AVCodecContext *avctx,
struct dxva2_picture_context *ctx_pic =
s->current_picture_ptr->hwaccel_picture_private;
-if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
-DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
-DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
+if (!DXVA_CONTEXT_VALID(avctx, ctx))
return -1;
assert(ctx_pic);
diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
index 36bf1ba..cc97d7b 100644
--- a/libavcodec/dxva2_vc1.c
+++ b/libavcodec/dxva2_vc1.c
@@ -317,9 +317,7 @@ static int dxva2_vc1_start_frame(AVCodecContext *avctx,
AVDXVAContext *ctx = avctx->hwaccel_context;
struct dxva2_picture_context *ctx_pic =
v->s.current_picture_ptr->hwaccel_picture_private;
-if (DXVA_CONTEXT_DECODER(avctx, ctx) == NULL ||
-DXVA_CONTEXT_CFG(avctx, ctx) == NULL ||
-DXVA_CONTEXT_COUNT(avctx, ctx) <= 0)
+if (!DXVA_CONTEXT_VALID(avctx, ctx))
return -1;
assert(ctx_pic);
diff --git a/libavcodec/dxva2_vp9.c b/liba
[FFmpeg-devel] [PATCH 2/3] dxva2: get the slice number directly from the surface in D3D11VA
No need to loop through the known surfaces, we'll use the requested surface
anyway.
The loop is only done for DXVA2.
---
libavcodec/dxva2.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dxva2.c b/libavcodec/dxva2.c
index 2ac3f3e..c782f1c 100644
--- a/libavcodec/dxva2.c
+++ b/libavcodec/dxva2.c
@@ -41,20 +41,19 @@ unsigned ff_dxva2_get_surface_index(const AVCodecContext
*avctx,
void *surface = get_surface(frame);
unsigned i;
-for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
#if CONFIG_D3D11VA
-if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD &&
ctx->d3d11va.surface[i] == surface)
-{
-D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
-ID3D11VideoDecoderOutputView_GetDesc(ctx->d3d11va.surface[i],
&viewDesc);
-return viewDesc.Texture2D.ArraySlice;
-}
+if (avctx->pix_fmt == AV_PIX_FMT_D3D11VA_VLD) {
+D3D11_VIDEO_DECODER_OUTPUT_VIEW_DESC viewDesc;
+ID3D11VideoDecoderOutputView_GetDesc((ID3D11VideoDecoderOutputView*)
surface, &viewDesc);
+return viewDesc.Texture2D.ArraySlice;
+}
#endif
#if CONFIG_DXVA2
+for (i = 0; i < DXVA_CONTEXT_COUNT(avctx, ctx); i++) {
if (avctx->pix_fmt == AV_PIX_FMT_DXVA2_VLD && ctx->dxva2.surface[i] ==
surface)
return i;
-#endif
}
+#endif
assert(0);
return 0;
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] dxva2: allow an empty array of ID3D11VideoDecoderOutputView
We can pick the correct slice index directly from the
ID3D11VideoDecoderOutputView
casted from data[3].
Also added myself as maintainer for DXVA2 and D3D11VA.
---
MAINTAINERS | 3 ++-
libavcodec/dxva2_internal.h | 4 ++--
libavcodec/version.h| 2 +-
3 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index cb9516d..981d71b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -260,7 +260,8 @@ Codecs:
Hardware acceleration:
crystalhd.c Philip Langdale
- dxva2*Hendrik Leppkes, Laurent Aimar
+ dxva2*Hendrik Leppkes, Laurent Aimar, Steve
Lhomme
+ d3d11va* Steve Lhomme
mediacodec* Matthieu Bouron
vaapi*Gwenole Beauchesne
vaapi_encode* Mark Thompson
diff --git a/libavcodec/dxva2_internal.h b/libavcodec/dxva2_internal.h
index e5322ef..dfff4d6 100644
--- a/libavcodec/dxva2_internal.h
+++ b/libavcodec/dxva2_internal.h
@@ -78,7 +78,7 @@ typedef union {
#define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx) (avctx->pix_fmt ==
AV_PIX_FMT_D3D11VA_VLD ? ctx->d3d11va.cfg->ConfigResidDiffAccelerator :
ctx->dxva2.cfg->ConfigResidDiffAccelerator)
#define DXVA_CONTEXT_VALID(avctx, ctx) (DXVA_CONTEXT_DECODER(avctx,
ctx) && \
DXVA_CONTEXT_CFG(avctx, ctx)
&& \
- DXVA_CONTEXT_COUNT(avctx,
ctx))
+ (avctx->pix_fmt ==
AV_PIX_FMT_D3D11VA_VLD || ctx->dxva2.surface_count))
#elif CONFIG_DXVA2
#define DXVA_CONTEXT_WORKAROUND(avctx, ctx) (ctx->dxva2.workaround)
#define DXVA_CONTEXT_COUNT(avctx, ctx) (ctx->dxva2.surface_count)
@@ -98,7 +98,7 @@ typedef union {
#define DXVA_CONTEXT_CFG_BITSTREAM(avctx, ctx)
(ctx->d3d11va.cfg->ConfigBitstreamRaw)
#define DXVA_CONTEXT_CFG_INTRARESID(avctx, ctx)
(ctx->d3d11va.cfg->ConfigIntraResidUnsigned)
#define DXVA_CONTEXT_CFG_RESIDACCEL(avctx, ctx)
(ctx->d3d11va.cfg->ConfigResidDiffAccelerator)
-#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->d3d11va.decoder &&
ctx->d3d11va.cfg && ctx->d3d11va.surface_count)
+#define DXVA_CONTEXT_VALID(avctx, ctx) (ctx->d3d11va.decoder &&
ctx->d3d11va.cfg)
#endif
unsigned ff_dxva2_get_surface_index(const AVCodecContext *avctx,
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 6b3e62e..2a0df19 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#define LIBAVCODEC_VERSION_MAJOR 57
#define LIBAVCODEC_VERSION_MINOR 72
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
--
2.10.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, Jan 13, 2017 at 1:04 PM, Michael Niedermayer wrote: > On Fri, Jan 13, 2017 at 01:01:14PM +0100, Michael Niedermayer wrote: >> On Fri, Jan 13, 2017 at 10:40:23AM +, Stève Lhomme wrote: >> > On Fri, Jan 13, 2017 at 10:47 AM, wm4 wrote: >> > > On Fri, 13 Jan 2017 09:52:18 +0100 >> > > Steve Lhomme wrote: >> > > >> > >> For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now >> > >> merged in libav. >> > > >> > > So how do we handle this. Do we wait until the merges catch up, or do >> > > you want to push your patches to ffmpeg's git immediately? >> > >> > Not sure what you mean. What merge are you talking about ? >> > These 3 patches can live on their own, regardless of what is being >> > done with d3d11va in hwcontext and ffmpeg. >> > I can send again 4/4 as the version number needs to be updated. >> >> when resending you may want to add a patch to add yourself to the >> MAINTAINERs file, maybe for d3d11va or any other part you want > > to clarify, i think you should have write access to git and the OK, How does commit work ? login/pass via HTTP ? ssh key ? > list of people havig write access should match the list of people in > MAINTAINERs I've sent the updated patches and added myself for DXVA2 and D3D11VA stuff. > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > During times of universal deceit, telling the truth becomes a > revolutionary act. -- George Orwell > > ___ > 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] No header for avformat/hlsenc
On Fri, Jan 13, 2017 at 4:51 PM, wm4 wrote: > On Fri, 13 Jan 2017 16:04:57 +0530 > Kamaldeep Tumkur wrote: > >> Thanks a lot for explaining this. I do see now that the needed >> metadata is being set on the HTTPContext struct in the http protocol >> file. For the ffmpeg.c app, AVFormatContext along with a few others >> are the only accessible structs through the public headers. > > Via the AVOption API (see libavutil/opt.h). > >> HTTPContext, HLSContext and others are just defined inside their >> respective private implementations. AVFormatContext's priv->data also >> carries this context in it. > > Variables referenced by AVOptions are indirectly accessible via the > AVOption API. > >> If there are something set in the HTTPContext through av_dict_set and >> I wanted to access it inside ffmpeg.c using av_dict_get, what instance >> should this be called on? AVFormatContext->priv_data cast as an >> HTTPContext? What if I wanted to use AVClass to verify that the class >> name and only then proceed with reading the option? Thanks again. > > You call the AVOption API on the AVCodecContext pointer. The dictionary > stuff can also be used to set AVOptions, but obviously only in one > direction. > > Also, please don't top-post. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel AVFormatContext's metadata is certainly accessible to the app. This is great to know that the AVOptions API can be used to set the metadata on the AVFormatContext or the AVStream. Thanks a lot for the guidance. Also, no more top-posting! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swresample/aarch64: add s16 and fltp neon resampling functions
On Mon, Jan 09, 2017 at 11:00:44PM +0100, Michael Niedermayer wrote: > On Mon, Jan 09, 2017 at 05:45:29PM +0100, Matthieu Bouron wrote: > > Hello, > > > > The following patch is a port of 6d82b52712af87c7831872c27fd2abfd18b04f88 to > > the aarch64 platform. > > > > Here are some results of an rpi3 running in aarch64 mode. > > > > ./ffmpeg -f lavfi -i > > sine=440,aformat=sample_fmts=fltp,asetnsamples=4096,abench=start,aresample=48000,abench=stop > > -t 1000 -f null - > > > > Without patch: > > [abench @ 0xe682380] t:0.002108 avg:0.001992 max:0.002452 min:0.001950 > > > > With patch: > > [abench @ 0x11492380] t:0.001474 avg:0.001384 max:0.001796 min:0.001332 > > > > ./ffmpeg -f lavfi -i > > sine=440,aformat=sample_fmts=s16,asetnsamples=4096,abench=start,aresample=48000,abench=stop > > -t 1000 -f null - > > > > Without patch: > > [abench @ 0x268c2380] t:0.001478 avg:0.001423 max:0.001571 min:0.001403 > > > > With patch: > > [abench @ 0x14092380] t:0.001012 avg:0.000951 max:0.001147 min:0.000922 > > nice Can I push the patchset ? Thanks, Matthieu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] avformat: Add alignment mode to Pro-MPEG
Hi,
The Pro-MPEG FEC module has troubles with some receivers.
This patch fixes this problem incorporating the option for selecting different
alignment modes.
The problem is related to the alignment of the COLUMN FEC packets (aka. when
send the packet).
Current block-alignment implies a delay of quasi-the-length of the matrix size.
Then several receivers discard the column fec packets when they start to
receive DATA packets from the next matrix.
Three different modes are possible (only two implemented):
- Mode 0: No alignment. When a new row starts, and the column is complete, then
send the COL FEC packet. This is the default behaviour for several devices.
However, this mode is prone to errors when they happen in the last row; but
it's still more compatible.
- Mode 1: COL alignment. This is the default and already implemented alignment.
COL FEC packets are send equispaced when processing the next matrix. Implies
more delay in the receiver and a double-size buffer.
- Mode 2: ROW alignment. This is unimplemented. After compute each column it's
send the COL FEC packet. Very similar to mode 0.
Please, review the code. I do several tests with professional equipment.
Results improves using mode 0 with some receivers.
A.H.From ef52c6b87d38f790280ab1988287e71ef31ecdf7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andreas=20H=C3=A5kon?=
Date: Fri, 13 Jan 2017 15:09:07 +0100
Subject: [PATCH 1/1] avformat: Add alignment mode to Pro-MPEG
---
doc/protocols.texi| 3 +++
libavformat/prompeg.c | 27 ---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index e887b75..b9da67b 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -542,6 +542,9 @@ The number of columns (4-20, LxD <= 100)
@item d=@var{n}
The number of rows (4-20, LxD <= 100)
+@item align=@var{n}
+Alignment mode for column FEC packets (0=none, 1=COL (default), 2=ROW)
+
@end table
Example usage:
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 9770a91..a040c43 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -105,6 +105,7 @@ typedef struct PrompegContext {
PrompegFec **fec_arr, **fec_col_tmp, **fec_col, *fec_row;
int ttl;
uint8_t l, d;
+uint8_t align;
uint8_t *rtp_buf;
uint16_t rtp_col_sn, rtp_row_sn;
uint16_t length_recovery;
@@ -124,6 +125,7 @@ static const AVOption options[] = {
{ "ttl", "Time to live (in milliseconds, multicast only)", OFFSET(ttl),
AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = E },
{ "l", "FEC L", OFFSET(l), AV_OPT_TYPE_INT, { .i64 = 5 }, 4, 20, .flags =
E },
{ "d", "FEC D", OFFSET(d), AV_OPT_TYPE_INT, { .i64 = 5 }, 4, 20, .flags =
E },
+{ "align", "Alignment mode: 0=none; 1=COL (default); 2=ROW",
OFFSET(align), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 2, .flags = E },
{ NULL }
};
@@ -430,9 +432,28 @@ static int prompeg_write(URLContext *h, const uint8_t
*buf, int size) {
s->fec_col_tmp[col_idx]->bitstring, s->bitstring_size);
}
-// FEC (column) send block-aligned
-if (!s->first && s->packet_idx % s->d == 0) {
-col_out_idx = s->packet_idx / s->d;
+// FEC (column) send
+col_out_idx = -1;
+if (!s->first) {
+switch (s->align) {
+case 0:
+// non-aligned
+if (s->packet_idx <= s->l)
+col_out_idx = s->packet_idx - 1;
+break;
+case 2:
+// ROW block-aligned
+// un-implemented!
+case 1:
+default:
+// COL block-aligned
+if (s->packet_idx % s->d == 0)
+col_out_idx = s->packet_idx / s->d;
+break;
+}
+
+}
+if (col_out_idx >= 0) {
if ((ret = prompeg_write_fec(h, s->fec_col[col_out_idx],
PROMPEG_FEC_COL)) < 0)
goto end;
written += ret;
--
2.8.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
Hi,
On Jan 13, 2017 6:40 AM, "Clément Bœsch" wrote:
From: Clément Bœsch
---
libavcodec/pthread_frame.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
index 7ef5e9f6be..cb6d76284e 100644
--- a/libavcodec/pthread_frame.c
+++ b/libavcodec/pthread_frame.c
@@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
+pthread_mutex_lock(&p->progress_mutex);
if(p->state == STATE_SETUP_FINISHED){
av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
calls\n");
}
-pthread_mutex_lock(&p->progress_mutex);
This has a problem in that we're potentially calling an I/O function that
potentially directly enters application space with a lock held.
Can the av_log call be moved under a local variable for the condition to
after the lock is released?
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
On Fri, 13 Jan 2017 09:07:48 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Jan 13, 2017 6:40 AM, "Clément Bœsch" wrote:
>
> From: Clément Bœsch
>
> ---
> libavcodec/pthread_frame.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 7ef5e9f6be..cb6d76284e 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext *avctx) {
>
> if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
>
> +pthread_mutex_lock(&p->progress_mutex);
> if(p->state == STATE_SETUP_FINISHED){
> av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
> calls\n");
> }
>
> -pthread_mutex_lock(&p->progress_mutex);
>
>
> This has a problem in that we're potentially calling an I/O function that
> potentially directly enters application space with a lock held.
I think the user should be taking care of this (or just don't spam
av_log in a performance critical function). The log call here seems
more like an internal warning though, and I've never seen it happening.
> Can the av_log call be moved under a local variable for the condition to
> after the lock is released?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swresample/aarch64: add s16 and fltp neon resampling functions
On 1/13/17, Matthieu Bouron wrote: > On Mon, Jan 09, 2017 at 11:00:44PM +0100, Michael Niedermayer wrote: >> On Mon, Jan 09, 2017 at 05:45:29PM +0100, Matthieu Bouron wrote: >> > Hello, >> > >> > The following patch is a port of >> > 6d82b52712af87c7831872c27fd2abfd18b04f88 to >> > the aarch64 platform. >> > >> > Here are some results of an rpi3 running in aarch64 mode. >> > >> > ./ffmpeg -f lavfi -i >> > sine=440,aformat=sample_fmts=fltp,asetnsamples=4096,abench=start,aresample=48000,abench=stop >> > -t 1000 -f null - >> > >> > Without patch: >> > [abench @ 0xe682380] t:0.002108 avg:0.001992 max:0.002452 min:0.001950 >> > >> > With patch: >> > [abench @ 0x11492380] t:0.001474 avg:0.001384 max:0.001796 >> > min:0.001332 >> > >> > ./ffmpeg -f lavfi -i >> > sine=440,aformat=sample_fmts=s16,asetnsamples=4096,abench=start,aresample=48000,abench=stop >> > -t 1000 -f null - >> > >> > Without patch: >> > [abench @ 0x268c2380] t:0.001478 avg:0.001423 max:0.001571 >> > min:0.001403 >> > >> > With patch: >> > [abench @ 0x14092380] t:0.001012 avg:0.000951 max:0.001147 >> > min:0.000922 >> >> nice > > Can I push the patchset ? Sure ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc/h264_slice: drop redundant current_slice reset
On Fri, Jan 13, 2017 at 12:40:06PM +0100, Clément Bœsch wrote: > From: Clément Bœsch > > It is done unconditionally in ff_h264_field_end() > --- > libavcodec/h264_slice.c | 2 -- > 1 file changed, 2 deletions(-) ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavc/h264dec: reconstruct and debug flush frames as well
On Fri, Jan 13, 2017 at 12:40:07PM +0100, Clément Bœsch wrote: > From: Clément Bœsch > > --- > libavcodec/h264dec.c | 99 > +--- > 1 file changed, 56 insertions(+), 43 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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/h264dec: Call ff_print_debug_info2() in flush codepath
On Fri, Jan 13, 2017 at 12:55:33PM +0100, Clément Bœsch wrote:
> On Thu, Jan 12, 2017 at 12:11:37PM +0100, Michael Niedermayer wrote:
> > Found-by: ubitux
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/h264dec.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > index ed0b7246b7..dabcaf698a 100644
> > --- a/libavcodec/h264dec.c
> > +++ b/libavcodec/h264dec.c
> > @@ -1096,6 +1096,15 @@ static int h264_decode_frame(AVCodecContext *avctx,
> > void *data,
> > if (ret < 0)
> > return ret;
> > *got_frame = 1;
> > +if (CONFIG_MPEGVIDEO) {
> > +ff_print_debug_info2(h->avctx, pict, NULL,
> > +out->mb_type,
> > +out->qscale_table,
> > +out->motion_val,
> > +NULL,
> > +h->mb_width, h->mb_height,
> > h->mb_stride, 1);
> > +}
> > +
>
> superseded by "[PATCH 3/3] lavc/h264dec: reconstruct and debug flush frames
> as well"
please either update patchwork or send a pull-req/patch to
https://github.com/michaelni/patchwork-update-bot
so it auto updates
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] dxva2: use a single macro to test if the DXVA context is valid
On Fri, Jan 13, 2017 at 02:02:29PM +0100, Steve Lhomme wrote: > On Fri, Jan 13, 2017 at 1:04 PM, Michael Niedermayer wrote: > > On Fri, Jan 13, 2017 at 01:01:14PM +0100, Michael Niedermayer wrote: > >> On Fri, Jan 13, 2017 at 10:40:23AM +, Stève Lhomme wrote: > >> > On Fri, Jan 13, 2017 at 10:47 AM, wm4 wrote: > >> > > On Fri, 13 Jan 2017 09:52:18 +0100 > >> > > Steve Lhomme wrote: > >> > > > >> > >> For the record all 3 remaining patches (2/4, 3/4 and 4/4) are now > >> > >> merged in libav. > >> > > > >> > > So how do we handle this. Do we wait until the merges catch up, or do > >> > > you want to push your patches to ffmpeg's git immediately? > >> > > >> > Not sure what you mean. What merge are you talking about ? > >> > These 3 patches can live on their own, regardless of what is being > >> > done with d3d11va in hwcontext and ffmpeg. > >> > I can send again 4/4 as the version number needs to be updated. > >> > >> when resending you may want to add a patch to add yourself to the > >> MAINTAINERs file, maybe for d3d11va or any other part you want > > > > to clarify, i think you should have write access to git and the > > OK, How does commit work ? login/pass via HTTP ? ssh key ? ssh key [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] avformat/avienc: write chained master index only if std_compliance is normal or below
On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote:
> On 10.01.2017 00:19, Michael Niedermayer wrote:
> >On Mon, Jan 09, 2017 at 09:56:50AM +0100, Tobias Rapp wrote:
> >>OpenDML specification v1.02 states that entries of a master index chunk
> >>shall point to standard or field index chunks.
> >>
> >>Changed incorrect duration of last master index entry to -1 in case it
> >>points to another master index.
> >>
> >>Propagate error when index write fails.
> >>
> >>Signed-off-by: Tobias Rapp
> >>---
> >> libavformat/avienc.c | 30 +++---
> >> 1 file changed, 23 insertions(+), 7 deletions(-)
> >>
> >>diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> >>index fd16fff..5d5c02a 100644
> >>--- a/libavformat/avienc.c
> >>+++ b/libavformat/avienc.c
> >>@@ -524,7 +524,13 @@ static int avi_write_header(AVFormatContext *s)
> >> return 0;
> >> }
> >>
> >>-static void update_odml_entry(AVFormatContext *s, int stream_index,
> >>int64_t ix, int size)
> >>+/* Index entry points to standard index */
> >>+#define AVI_UPDATE_ODML_ENTRY_DEFAULT 0x
> >>+
> >>+/* Index entry points to another master index */
> >>+#define AVI_UPDATE_ODML_ENTRY_MASTER0x0001
> >>+
> >>+static void update_odml_entry(AVFormatContext *s, int stream_index,
> >>int64_t ix, int size, int flags)
> >> {
> >> AVIOContext *pb = s->pb;
> >> AVIContext *avi = s->priv_data;
> >>@@ -544,7 +550,10 @@ static void update_odml_entry(AVFormatContext *s, int
> >>stream_index, int64_t ix,
> >> avio_wl64(pb, ix);/* qwOffset */
> >> avio_wl32(pb, size); /* dwSize */
> >> ff_parse_specific_params(s->streams[stream_index], &au_byterate,
> >> &au_ssize, &au_scale);
> >>-if (s->streams[stream_index]->codecpar->codec_type ==
> >>AVMEDIA_TYPE_AUDIO && au_ssize > 0) {
> >>+if (flags & AVI_UPDATE_ODML_ENTRY_MASTER) {
> >>+av_assert0(s->strict_std_compliance <= FF_COMPLIANCE_NORMAL);
> >>+avio_wl32(pb, -1); /* dwDuration (undefined) */
> >>+} else if (s->streams[stream_index]->codecpar->codec_type ==
> >>AVMEDIA_TYPE_AUDIO && au_ssize > 0) {
> >> uint32_t audio_segm_size = (avist->audio_strm_length -
> >> avist->indexes.audio_strm_offset);
> >> if ((audio_segm_size % au_ssize > 0) && !avist->sample_requested) {
> >> avpriv_request_sample(s, "OpenDML index duration for audio
> >> packets with partial frames");
> >
> >>@@ -567,6 +576,12 @@ static int avi_write_ix(AVFormatContext *s)
> >>
> >> av_assert0(pb->seekable);
> >>
> >>+if (avi->riff_id >= AVI_MASTER_INDEX_SIZE && s->strict_std_compliance
> >>> FF_COMPLIANCE_NORMAL) {
> >>+av_log(s, AV_LOG_ERROR, "Invalid riff index %d >= %d\n",
> >>+ avi->riff_id, AVI_MASTER_INDEX_SIZE);
> >>+return AVERROR(EINVAL);
> >>+}
> >
> >isnt it better to warn the user and inform him at the end what size
> >of reserved space would have been needed?
> >
> >not saying iam against this, i do see how it is formally correct to
> >fail hard but it feels painfull to me to fail
> >muxing at 256gb hard when we can perfectly fine just continue and
> >the user can just remux the file with bigger reserved master index
> >to fix it
>
> But then adding "-strict strict" just enables a warning message and
> a non-compliant file is written still? Or do you mean that
> additionally a warning message could be written in case
> std_compliance is <= normal?
>
> Background story: I'm working on an application that fetches some
> AVI file byte range from tape storage and restores the file header.
> The header restoration requires the ODML master index in the header
> to be complete. Thus I'd like to ensure that all AVI files put into
> the archive have a compliant/compatible index structure.
>
> For such automated processes failing hard is more safe than
> continuing with a warning message, checking for log messages in the
> host application and possibly re-running the transcoding with
> adapted options.
whats your oppinion on an option that selects muxer error behavior ?
something that can
fail immedeatly on error or
warn but continue, return failure after writing the file and trailer
that is a option to make it possible for a muxer to continue even
if there was an error, maybe even a int max_muxer_error or something
else?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat/avienc: add reserve_index_space option
On Tue, Jan 10, 2017 at 10:41:04AM +0100, Tobias Rapp wrote: > On 10.01.2017 00:15, Michael Niedermayer wrote: > >On Mon, Jan 09, 2017 at 09:56:51AM +0100, Tobias Rapp wrote: > >>Allows the user to reserve space for the ODML master index. A sufficient > >>sized master index in the AVI header avoids storing follow-up master > >>indexes within the 'movi' data later. > >> > >>Signed-off-by: Tobias Rapp > >>--- > >> libavformat/avi.h | 1 - > >> libavformat/avienc.c | 36 +--- > >> libavformat/version.h | 2 +- > >> 3 files changed, 30 insertions(+), 9 deletions(-) > > > >iam not against this but as the only way to write strictly spec > >compiant files >= 256g, i think this is not very user friendly > > > >FFmpeg should work out of the box not requireing the user to tune > >options > > I took the "reserve_index_space" option of matroskaenc.c as an > inspiration. But I see that for Matroska it is "just" a matter of > optimization while for AVI it means compliance + optimization. > > >Here are some random ideas: > > > >Enlarge the default index depending on expected bitrate, a high res > >rawvideo input should by default get a bigger reserved index space > > Yes, this would be a low-hanging fruit. > > >Use the input file duration (aka pass it to the muxer) and use it as > >a guess on duration, enlarge the space accordingly > > You mean guessing and setting the AVStream->duration field in > ffmpeg.c as a hint to the AVI muxer? Will take a look on how this > could be done. yes, that was the idea > > >Or, do the hard but correct and just enlarge it > >As in when you hit some SIZE1 like lets say 1GB leave 1mb space > >(which at this filesize is a insignificant 0.1%) > >and when writing the trailer and the file exceeded 256G go back and > >move the first 1gb forward to make space for a larger master index. > >(this at that point just moves 0.5% of the file) > >You can also use the 1mb space for holding a 2nd master index prior > >to writing the trailer. Either way the file should ideally be partially > >indexed while it is being written so a 2nd process could read and mostly > >seek in it > > Moving the first 1GB forward also means updating each entry within > the legacy "idx1" index structure plus the base offset of each ODML > standard stream index. Further as the ODML master index of each > stream has to be enlarged also parts of the file header need to be > moved. simply writing the whole header again may be cleaner than moving parts of it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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/matroskaenc: Accept time base hint
On Wed, Dec 28, 2016 at 5:03 AM, Michael Niedermayer wrote: > On Tue, Dec 27, 2016 at 09:47:47PM -0800, Michael Bradshaw wrote: > > From: Michael Bradshaw > > > > Signed-off-by: Michael Bradshaw > > --- > > libavformat/matroskaenc.c | 38 +++--- > > 1 file changed, 31 insertions(+), 7 deletions(-) > > breaks fate > [...] I've looked into this and it's expected behavior. -codec copy is also copying timing information (including time base), and with this patch the Matroska/WebM muxers are respecting that. I could update the fate files, but before doing that I'd like to ensure that this change in behavior for -codec copy is correct and desirable. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/alsdec.c: testing MPEG-4 ALS decoder with floating point audio data
On Fri, Jan 13, 2017 at 03:13:15AM -0800, Thomas Turner wrote: > If als_07_2ch192k32bF.mp4 isn't already located in > fate-suite/lossless-audio/, you can download at: > > http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_14496-26_2010_Bitstreams/DVD1/mpeg4audio-conformance/compressedMp4/als_07_2ch192k32bF.mp4 > > Signed-off-by: Thomas Turner > --- > tests/fate/als.mak | 3 +++ > tests/ref/fate/mpeg4-als-conformance-07 | 1 + > 2 files changed, 4 insertions(+) > create mode 100644 tests/ref/fate/mpeg4-als-conformance-07 This fails on qemu arm TESTmpeg4-als-conformance-07 --- ffmpeg/tests/ref/fate/mpeg4-als-conformance-07 2017-01-13 17:20:29.230418469 +0100 +++ tests/data/fate/mpeg4-als-conformance-072017-01-13 18:00:47.098469407 +0100 @@ -1 +1 @@ -CRC=0x01503df3 +CRC=0x81b53f05 Test mpeg4-als-conformance-07 failed. Look at tests/data/fate/mpeg4-als-conformance-07.err for details. make: *** [fate-mpeg4-als-conformance-07] Error 1 interrestingly it does pass on qemu-mips iam cc-ing thilo and umair they might have comments on this but a test that compares this to a pcm reference instead of using a checksum might help the result on arm seems very close stddev:0.00 PSNR: 94.36 MAXDIFF:1 bytes: 11501352/ 11501352 changing the decoder so it matches exactly would be interresting too but that might be much harder than writing a test also thats beyond the scope of adding selftests ... [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
Hi,
On Fri, Jan 13, 2017 at 9:39 AM, wm4 wrote:
> On Fri, 13 Jan 2017 09:07:48 -0500
> "Ronald S. Bultje" wrote:
>
> > Hi,
> >
> > On Jan 13, 2017 6:40 AM, "Clément Bœsch" wrote:
> >
> > From: Clément Bœsch
> >
> > ---
> > libavcodec/pthread_frame.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 7ef5e9f6be..cb6d76284e 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext
> *avctx) {
> >
> > if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
> >
> > +pthread_mutex_lock(&p->progress_mutex);
> > if(p->state == STATE_SETUP_FINISHED){
> > av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
> > calls\n");
> > }
> >
> > -pthread_mutex_lock(&p->progress_mutex);
> >
> >
> > This has a problem in that we're potentially calling an I/O function that
> > potentially directly enters application space with a lock held.
>
> I think the user should be taking care of this (or just don't spam
> av_log in a performance critical function). The log call here seems
> more like an internal warning though, and I've never seen it happening.
>
But it's easy to resolve right?
lock();
int state = p->state;
..
unlock();
if (state == ..)
av_log(..);
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] HTTP: optimize forward seek performance
> On Jan 12, 2017, at 10:59 AM, Joel Cunningham wrote: > > Nicolas, > > I’ve found existing “read-ahead logic” in avio_seek to do what I’ve > implemented in http_stream_forward(). This is controlled by > SHORT_SEEK_THRESHOLD, currently set to 4KB. I proto-typed increasing this to > the 256KB (matches the initial TCP window in my test setup) and saw the same > number of reduction in HTTP GETs and the number of seeks! Thanks for the > heads up, this should reduce my patch size! > > I could plumb this setting (s->short_seek_threshold) to a URL function that > would get the desired value from HTTP/TCP. Looking at how > ffio_init_context() is implemented, it doesn’t appear to have access to the > URLContext pointer. Any guidance on how I can plumb the protocol layer with > aviobuf without a public API change? > > Thanks, > > Joel I managed to figure the plumbing out in a way that doesn’t modify any public APIs. I added a new callback to struct AVIOContext that gets a short seek threshold value from URLContext if available (otherwise fallback to s->short_seek_threshold). This allows using the read-ahead/discard logic in avio_seek and eliminates my forwarding logic in the HTTP layer (thanks to Nicolas for pointing me in this direction). See new patch below I also updated my commit message to include assumptions/considerations about congestion control on the sender (thanks to Andy for calling out the discussion on it). Lastly, I have upload new captures/log in dropbox for those that want to take a look at my testing output (see ffplay_short_seek_output.log and mac-ffplay-short-seek-patch.pcapng) https://www.dropbox.com/sh/4q4ru8isdv22joj/AABU3XyXmgLMiEFqucf1LdZ3a?dl=0 Thanks for the feedback so far, Joel From 9bb2f184591c2d6e6a91d3760e63b013ca4c95e5 Mon Sep 17 00:00:00 2001 From: Joel Cunningham Date: Fri, 13 Jan 2017 10:52:25 -0600 Subject: [PATCH] HTTP: improve performance by reducing forward seeks This commit optimizes HTTP performance by reducing forward seeks, instead favoring a read-ahead and discard on the current connection (referred to as a short seek) for seeks that are within a TCP window's worth of data. This improves performance because with TCP flow control, a window's worth of data will be in the local socket buffer already or in-flight from the sender once congestion control on the sender is fully utilizing the window. Note: this approach doesn't attempt to differentiate from a newly opened connection which may not be fully utilizing the window due to congestion control vs one that is. The receiver can't get at this information, so we assume worst case; that full window is in use (we did advertise it after all) and that data could be in-flight The previous behavior of closing the connection, then opening a new with a new HTTP range value results in a massive amounts of discarded and re-sent data when large TCP windows are used. This has been observed on MacOS/iOS which starts with an inital window of 256KB and grows up to 1MB depending on the bandwidth-product delay. When seeking within a window's worth of data and we close the connection, then open a new one within the same window's worth of data, we discard from the current offset till the end of the window. Then on the new connection the server ends up re-sending the previous data from new offset till the end of old window. Example (assumes full window utilization): TCP window size: 64KB Position: 32KB Forward seek position: 40KB * (Next window) 32KB |--| 96KB |---| 160KB * 40KB |---| 104KB Re-sent amount: 96KB - 40KB = 56KB For a real world test example, I have MP4 file of ~25MB, which ffplay only reads ~16MB and performs 177 seeks. With current ffmpeg, this results in 177 HTTP GETs and ~73MB worth of TCP data communication. With this patch, ffmpeg issues 4 HTTP GETs and 3 seeks for a total of ~22MB of TCP data communication. To support this feature, the short seek logic in avio_seek() has been extended to call a function to get the short seek threshold value. This callback has been plumbed to the URLProtocol structure, which now has infrastructure in HTTP and TCP to get the underlying receiver window size via SO_RCVBUF. If the underlying URL and protocol don't support returning a short seek threshold, the default s->short_seek_threshold is used This feature has been tested on Windows 7 and MacOS/iOS. Windows support is slightly complicated by the fact that when TCP window auto-tuning is enabled, SO_RCVBUF doesn't report the real window size, but it does if SO_RCVBUF was manually set (disabling auto-tuning). So we can only use this optimization on Windows in the later case --- libavformat/avio.c| 7 +++ libavformat/avio.h| 6 ++ libavformat/aviobuf.c | 18 +- libavformat/http.c| 8 libavformat/tcp.c | 21 + libavformat/url.h | 8
Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write two CodecID elements for rawvideo
On Thu, Jan 12, 2017 at 03:01:03PM +0100, Carl Eugen Hoyos wrote:
> 2017-01-11 19:55 GMT+01:00 Michael Niedermayer :
> > On Tue, Jan 10, 2017 at 05:23:04PM +0100, Carl Eugen Hoyos wrote:
> >> Hi!
> >>
> >> Attached patch fixes ticket #6068.
> >>
> >> Please comment, Carl Eugen
> >
> >> matroskaenc.c |1 +
> >> 1 file changed, 1 insertion(+)
> >> 41a44b306b4f66f182c30289e093372556ca184c
> >> 0001-lavf-matroskaenc-Do-not-write-two-CodecID-elements-f.patch
> >> From b100ef83e257d8a106eefa3d2da9463ccd0e87d8 Mon Sep 17 00:00:00 2001
> >> From: Carl Eugen Hoyos
> >> Date: Tue, 10 Jan 2017 17:21:08 +0100
> >> Subject: [PATCH] lavf/matroskaenc: Do not write two CodecID elements for
> >> rawvideo.
> >>
> >> Fixes ticket #6068.
> >
> > breaks fate
>
> New patch attached.
>
> Thank you, Carl Eugen
> libavformat/matroskaenc.c |1 +
> tests/ref/fate/rgb24-mkv |4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
> ac6db46a99c6d14288d5dad0fb813b13f9c6fa28
> 0001-lavf-matroskaenc-Do-not-write-two-CodecID-elements-f.patch
> From 61fc1a71c0af73657b5260ea4e7a29d43e94c937 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 12 Jan 2017 14:50:52 +0100
> Subject: [PATCH] lavf/matroskaenc: Do not write two CodecID elements for
> rawvideo.
>
> Fixes ticket #6068.
> ---
> libavformat/matroskaenc.c |1 +
> tests/ref/fate/rgb24-mkv |4 ++--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 78a621e..7e97586 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1119,6 +1119,7 @@ static int mkv_write_track(AVFormatContext *s,
> MatroskaMuxContext *mkv,
> } else {
> // look for a codec ID string specific to mkv to use,
> // if none are found, use AVI codes
> +if (par->codec_id != AV_CODEC_ID_RAWVIDEO || par->codec_tag)
> for (j = 0; ff_mkv_codec_tags[j].id != AV_CODEC_ID_NONE; j++) {
> if (ff_mkv_codec_tags[j].id == par->codec_id) {
> put_ebml_string(pb, MATROSKA_ID_CODECID,
> ff_mkv_codec_tags[j].str);
this would be simpler and more robust as a if/else
no more comments from me
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavc/pthread_frame: protect read state access in setup finish function
On Fri, 13 Jan 2017 12:19:14 -0500
"Ronald S. Bultje" wrote:
> Hi,
>
> On Fri, Jan 13, 2017 at 9:39 AM, wm4 wrote:
>
> > On Fri, 13 Jan 2017 09:07:48 -0500
> > "Ronald S. Bultje" wrote:
> >
> > > Hi,
> > >
> > > On Jan 13, 2017 6:40 AM, "Clément Bœsch" wrote:
> > >
> > > From: Clément Bœsch
> > >
> > > ---
> > > libavcodec/pthread_frame.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > > index 7ef5e9f6be..cb6d76284e 100644
> > > --- a/libavcodec/pthread_frame.c
> > > +++ b/libavcodec/pthread_frame.c
> > > @@ -509,11 +509,11 @@ void ff_thread_finish_setup(AVCodecContext
> > *avctx) {
> > >
> > > if (!(avctx->active_thread_type&FF_THREAD_FRAME)) return;
> > >
> > > +pthread_mutex_lock(&p->progress_mutex);
> > > if(p->state == STATE_SETUP_FINISHED){
> > > av_log(avctx, AV_LOG_WARNING, "Multiple ff_thread_finish_setup()
> > > calls\n");
> > > }
> > >
> > > -pthread_mutex_lock(&p->progress_mutex);
> > >
> > >
> > > This has a problem in that we're potentially calling an I/O function that
> > > potentially directly enters application space with a lock held.
> >
> > I think the user should be taking care of this (or just don't spam
> > av_log in a performance critical function). The log call here seems
> > more like an internal warning though, and I've never seen it happening.
> >
>
> But it's easy to resolve right?
>
> lock();
> int state = p->state;
> ..
> unlock();
> if (state == ..)
> av_log(..);
I still don't see what the problem is. Why make it more complex than
necessary?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] speedhq: Align blocks variable properly.
Seemingly ff_clear_block_sse assumed that the block array is aligned,
so make sure it is.
---
libavcodec/speedhq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
index 9c21c0b1be..30160dd3f2 100644
--- a/libavcodec/speedhq.c
+++ b/libavcodec/speedhq.c
@@ -224,7 +224,7 @@ static inline int decode_dct_block(const SHQContext *s,
GetBitContext *gb, int l
{
const int *quant_matrix = s->quant_matrix;
const uint8_t *scantable = s->intra_scantable.permutated;
-int16_t block[64];
+DECLARE_ALIGNED(16, int16_t, block)[64];
int dc_offset;
s->bdsp.clear_block(block);
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] speedhq: Align blocks variable properly.
On 1/13/2017 3:04 PM, Steinar H. Gunderson wrote:
> Seemingly ff_clear_block_sse assumed that the block array is aligned,
> so make sure it is.
And so does IDCTDSPContext.idct_put()
> ---
> libavcodec/speedhq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/speedhq.c b/libavcodec/speedhq.c
> index 9c21c0b1be..30160dd3f2 100644
> --- a/libavcodec/speedhq.c
> +++ b/libavcodec/speedhq.c
> @@ -224,7 +224,7 @@ static inline int decode_dct_block(const SHQContext *s,
> GetBitContext *gb, int l
> {
> const int *quant_matrix = s->quant_matrix;
> const uint8_t *scantable = s->intra_scantable.permutated;
> -int16_t block[64];
> +DECLARE_ALIGNED(16, int16_t, block)[64];
Changed to use LOCAL_ALIGNED_16() instead and pushed.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swresample/aarch64: add s16 and fltp neon resampling functions
On Fri, Jan 13, 2017 at 03:43:24PM +0100, Paul B Mahol wrote: > On 1/13/17, Matthieu Bouron wrote: > > On Mon, Jan 09, 2017 at 11:00:44PM +0100, Michael Niedermayer wrote: > >> On Mon, Jan 09, 2017 at 05:45:29PM +0100, Matthieu Bouron wrote: > >> > Hello, > >> > > >> > The following patch is a port of > >> > 6d82b52712af87c7831872c27fd2abfd18b04f88 to > >> > the aarch64 platform. > >> > > >> > Here are some results of an rpi3 running in aarch64 mode. > >> > > >> > ./ffmpeg -f lavfi -i > >> > sine=440,aformat=sample_fmts=fltp,asetnsamples=4096,abench=start,aresample=48000,abench=stop > >> > -t 1000 -f null - > >> > > >> > Without patch: > >> > [abench @ 0xe682380] t:0.002108 avg:0.001992 max:0.002452 min:0.001950 > >> > > >> > With patch: > >> > [abench @ 0x11492380] t:0.001474 avg:0.001384 max:0.001796 > >> > min:0.001332 > >> > > >> > ./ffmpeg -f lavfi -i > >> > sine=440,aformat=sample_fmts=s16,asetnsamples=4096,abench=start,aresample=48000,abench=stop > >> > -t 1000 -f null - > >> > > >> > Without patch: > >> > [abench @ 0x268c2380] t:0.001478 avg:0.001423 max:0.001571 > >> > min:0.001403 > >> > > >> > With patch: > >> > [abench @ 0x14092380] t:0.001012 avg:0.000951 max:0.001147 > >> > min:0.000922 > >> > >> nice > > > > Can I push the patchset ? > > Sure Pushed. Thanks, Matthieu [...] ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat: Add rtp_mpegtsraw (MPEG-TS RAW Stream output)
On Fri, Jan 13, 2017 at 07:57:28 -0500, Andreas Håkon wrote:
> +static int rtp_mpegtsraw_write_close(AVFormatContext *s)
> +{
ffmpeg bracket style is different.
https://ffmpeg.org/developer.html#toc-Code-formatting-conventions
(indent's "-kr" implies "-br", which means that the opening curly
bracket is on the same line.)
> +struct MuxChain *chain = s->priv_data;
> + int ret = AVERROR(ENOMEM);
> + ret = rtp_mpegts_write_header(s);
Why would you assign a value to ret which you immediately discard?
> +avformat_free_context(chain->mpegts_ctx);
> +
> + chain->mpegts_ctx = NULL;
Indentation is inconsistent, throughout the patch BTW.
> +int ret = 0;
> +
> +ret = av_write_frame(chain->rtp_ctx, pkt);
Same here with the assignment.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avformat: Add alignment mode to Pro-MPEG
On Fri, Jan 13, 2017 at 09:26:16 -0500, Andreas Håkon wrote:
> { "d", "FEC D", OFFSET(d), AV_OPT_TYPE_INT, { .i64 = 5 }, 4, 20, .flags
> = E },
> +{ "align", "Alignment mode: 0=none; 1=COL (default); 2=ROW",
> OFFSET(align), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 2, .flags = E },
This usually calls for an enum. Something like (off the top of my
head):
enum AlignMode {
ALIGN_MODE_NONE,
ALIGN_MODE_COL,
ALIGN_MODE_ROW,
};
{ "align", "alignment mode", OFFSET(align), AV_OPT_TYPE_INT, { .i64 =
ALIGN_MODE_COL }, ALIGN_MODE_NONE, ALIGN_MODE_ROW, E, "align" },
{ "none", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = ALIGN_MODE_NONE },
INT_MIN, INT_MAX, E, "align" },
{ "COL", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = ALIGN_MODE_COL },
INT_MIN, INT_MAX, E, "align" },
{ "ROW", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = ALIGN_MODE_ROW },
INT_MIN, INT_MAX, E, "align" },
[...]
(Or as option enums, call them "col" and "row" perhaps.)
> +switch (s->align) {
> +case 0:
case ALIGN_MODE_NONE:
> +case 2:
case ALIGN_MODE_COL:
> +// ROW block-aligned
> +// un-implemented!
If so, I think you should add a warning and tell the user that the code
is falling back to COL mode.
> +case 1:
case ALIGN_MODE_ROW:
> +default:
Can't be reached if you use the option system as above, add a warning
perhaps.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Fix huge reported DTS on Ogg Theora files with bogus granulepos
Patch fixes an issue with broken Ogg Theora videos containing bogus negative granulepos on some packets: libavformat was reporting huge positive dts timestamps for these packets, causing downstream problems for ffmpeg2theora at Wikimedia Commons (near-infinite loop during transcoding). Bug report: https://trac.ffmpeg.org/ticket/6080 Downstream issue: https://phabricator.wikimedia.org/T155247 Patch for libavformat attached. Returns AV_NOPTS_VALUE instead of bogus value for the dts, which downstream ffmpeg2theora can already understand and handle. Thanks! -- brion 0001-Fix-for-dts-on-Ogg-Theora-packets-with-bad-granulepo.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate/psd : add test for bitmap and duotone
On Wed, Jan 11, 2017 at 09:59:24PM +0100, Martin Vignali wrote: > Hello, > > In attach patch to add fate test for bitmap file, and duotone. > > The duotone test, is based on the actual state of the decoder, where the > sample is interpreted as gray file. > > Sample can be found here : > https://we.tl/sKMmiVhWT1 > > and need to be put inside : fate-suite/psd/ > > > Martin > fate/image.mak |6 ++ > ref/fate/psd-duo-tone-color |6 ++ > ref/fate/psd-lena-bitmap|6 ++ > 3 files changed, 18 insertions(+) > 0404a3138995dcef8319c7eadb239aee60738f24 > 0002-fate-psd-add-test-for-bitmap-and-duotone.patch > From 031441d5033e5e7fe0b18a27f348ec2c76e04c96 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Wed, 11 Jan 2017 21:51:36 +0100 > Subject: [PATCH 2/2] fate/psd : add test for bitmap and duotone > > The duotone file is interpreted as gray applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/psd : add test for channel depth/count in bitmap mode
On Wed, Jan 11, 2017 at 09:55:33PM +0100, Martin Vignali wrote: > Hello, > > Patch in attach add test for channel depth and channel count in bitmap mode > and return invalid data, if channel count or depth != 1. > > Martin > psd.c |6 ++ > 1 file changed, 6 insertions(+) > 5b8783f5ee2bce63c5b1b19953e249069fe81384 > 0001-libavcodec-psd-add-test-for-channel-depth-channel-co.patch > From e1ae30182861bebbee7ce640db4e7038bff09e75 Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Wed, 11 Jan 2017 21:47:56 +0100 > Subject: [PATCH 1/2] libavcodec/psd : add test for channel depth/channel count > in bitmap mode applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes 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/mxf: add support for Prores from Final Cut Pro
2017-01-12 18:27 GMT+01:00 Paul B Mahol :
> Signed-off-by: Paul B Mahol
> ---
> libavformat/mxf.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index e9c48e8..8a40b67 100644
> --- a/libavformat/mxf.c
> +++ b/libavformat/mxf.c
> @@ -61,6 +61,8 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x01,0x31,0x11,0x01
> }, 14, AV_CODEC_ID_H264 }, /* H.264/MPEG-4 AVC SPS/PPS in-band */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
> }, 16, AV_CODEC_ID_V210 }, /* V210 */
> { {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x11,0x00,0x00
> }, 14, AV_CODEC_ID_PRORES }, /* Avid MC7 ProRes */
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x06,0x04,0x00
> }, 16, AV_CODEC_ID_PRORES }, /* FCPX ProRes */
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x06,0x06,0x00
> }, 16, AV_CODEC_ID_PRORES }, /* FCPX ProRes */
I had not seen this mail before, sorry!
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write two CodecID elements for rawvideo
2017-01-13 18:44 GMT+01:00 Michael Niedermayer :
> On Thu, Jan 12, 2017 at 03:01:03PM +0100, Carl Eugen Hoyos wrote:
>> 2017-01-11 19:55 GMT+01:00 Michael Niedermayer :
>> > On Tue, Jan 10, 2017 at 05:23:04PM +0100, Carl Eugen Hoyos wrote:
>> >> Hi!
>> >>
>> >> Attached patch fixes ticket #6068.
>> >>
>> >> Please comment, Carl Eugen
>> >
>> >> matroskaenc.c |1 +
>> >> 1 file changed, 1 insertion(+)
>> >> 41a44b306b4f66f182c30289e093372556ca184c
>> >> 0001-lavf-matroskaenc-Do-not-write-two-CodecID-elements-f.patch
>> >> From b100ef83e257d8a106eefa3d2da9463ccd0e87d8 Mon Sep 17 00:00:00 2001
>> >> From: Carl Eugen Hoyos
>> >> Date: Tue, 10 Jan 2017 17:21:08 +0100
>> >> Subject: [PATCH] lavf/matroskaenc: Do not write two CodecID elements for
>> >> rawvideo.
>> >>
>> >> Fixes ticket #6068.
>> >
>> > breaks fate
>>
>> New patch attached.
>>
>> Thank you, Carl Eugen
>
>> libavformat/matroskaenc.c |1 +
>> tests/ref/fate/rgb24-mkv |4 ++--
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>> ac6db46a99c6d14288d5dad0fb813b13f9c6fa28
>> 0001-lavf-matroskaenc-Do-not-write-two-CodecID-elements-f.patch
>> From 61fc1a71c0af73657b5260ea4e7a29d43e94c937 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Thu, 12 Jan 2017 14:50:52 +0100
>> Subject: [PATCH] lavf/matroskaenc: Do not write two CodecID elements for
>> rawvideo.
>>
>> Fixes ticket #6068.
>> ---
>> libavformat/matroskaenc.c |1 +
>> tests/ref/fate/rgb24-mkv |4 ++--
>> 2 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index 78a621e..7e97586 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -1119,6 +1119,7 @@ static int mkv_write_track(AVFormatContext *s,
>> MatroskaMuxContext *mkv,
>> } else {
>> // look for a codec ID string specific to mkv to use,
>> // if none are found, use AVI codes
>> +if (par->codec_id != AV_CODEC_ID_RAWVIDEO || par->codec_tag)
>> for (j = 0; ff_mkv_codec_tags[j].id != AV_CODEC_ID_NONE; j++) {
>> if (ff_mkv_codec_tags[j].id == par->codec_id) {
>> put_ebml_string(pb, MATROSKA_ID_CODECID,
>> ff_mkv_codec_tags[j].str);
>
> this would be simpler and more robust as a if/else
Pushed with this change.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Print an error if an unreadable rawvideo pix_fmt is written
2017-01-13 6:28 GMT+01:00 wm4 : > On Thu, 12 Jan 2017 23:31:11 +0100 > Carl Eugen Hoyos wrote: > >> 2017-01-12 23:20 GMT+01:00 Hendrik Leppkes : >> > On Fri, Jan 13, 2017 at 1:10 AM, Carl Eugen Hoyos >> > wrote: >> >> 2017-01-11 12:24 GMT+01:00 Moritz Barsnick : >> >>> On Tue, Jan 10, 2017 at 17:05:47 +0100, Carl Eugen Hoyos wrote: >> +enum AVPixelFormat pix_fmt = >> avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, >> + >> par->bits_per_coded_sample); >> +if (par->format != pix_fmt && par->format != >> AV_PIX_FMT_NONE) >> +av_log(s, AV_LOG_ERROR, "%s rawvideo cannot be >> written to vfw mkv, output file will be unreadable\n", >> + av_get_pix_fmt_name(par->format)); >> >>> >> >>> Should it really be an error (and not a warning) if its detection >> >>> doesn't change ffmpeg's behavior? >> >> >> >> Just copying what avi and mov muxer do. >> >> >> >> Note that (many) decoders print errors and (can) continue. >> >> >> >> (I believe library users can - and do - put rawvideo into standard >> >> containers and force the right pix_fmt on reading.) >> > >> > That seems silly, we shouldn't log an error that a file will be broken >> > and then still write it. Muxers should be strict and write only valid >> > files. >> >> This is what we currently do for both other multi-purpose containers >> (while FFmpeg logs no message for unreadable transport streams), >> so lets please commit this. > > I have to agree with Hendrik. Your patch is all about adding a message > for this case. The same message that gets printed for the other general-purpose muxers. > Why not do the right thing in the first place? I believe informing users is the right thing. > You'd only have to add an error return or so. I would prefer not to harm library users when helping cli users. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Print an error if an unreadable rawvideo pix_fmt is written
On Sat, Jan 14, 2017 at 4:18 PM, Carl Eugen Hoyos wrote: > 2017-01-13 6:28 GMT+01:00 wm4 : >> On Thu, 12 Jan 2017 23:31:11 +0100 >> Carl Eugen Hoyos wrote: >> >>> 2017-01-12 23:20 GMT+01:00 Hendrik Leppkes : >>> > On Fri, Jan 13, 2017 at 1:10 AM, Carl Eugen Hoyos >>> > wrote: >>> >> 2017-01-11 12:24 GMT+01:00 Moritz Barsnick : >>> >>> On Tue, Jan 10, 2017 at 17:05:47 +0100, Carl Eugen Hoyos wrote: >>> +enum AVPixelFormat pix_fmt = >>> avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi, >>> + >>> par->bits_per_coded_sample); >>> +if (par->format != pix_fmt && par->format != >>> AV_PIX_FMT_NONE) >>> +av_log(s, AV_LOG_ERROR, "%s rawvideo cannot be >>> written to vfw mkv, output file will be unreadable\n", >>> + av_get_pix_fmt_name(par->format)); >>> >>> >>> >>> Should it really be an error (and not a warning) if its detection >>> >>> doesn't change ffmpeg's behavior? >>> >> >>> >> Just copying what avi and mov muxer do. >>> >> >>> >> Note that (many) decoders print errors and (can) continue. >>> >> >>> >> (I believe library users can - and do - put rawvideo into standard >>> >> containers and force the right pix_fmt on reading.) >>> > >>> > That seems silly, we shouldn't log an error that a file will be broken >>> > and then still write it. Muxers should be strict and write only valid >>> > files. >>> >>> This is what we currently do for both other multi-purpose containers >>> (while FFmpeg logs no message for unreadable transport streams), >>> so lets please commit this. >> >> I have to agree with Hendrik. Your patch is all about adding a message >> for this case. > > The same message that gets printed for the other general-purpose > muxers. > >> Why not do the right thing in the first place? > > I believe informing users is the right thing. > >> You'd only have to add an error return or so. > > I would prefer not to harm library users when helping cli users. > Protection the world from writing broken unreadable files doesn't harm anyone either. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
