Re: [libav-devel] [PATCH] doc: synonyms for color properties
Quoting Vittorio Giovara (2014-09-29 21:05:49) > On Mon, Sep 29, 2014 at 7:54 PM, Anton Khirnov wrote: > > Quoting Vittorio Giovara (2014-09-29 15:29:12) > >> --- > >> AVCOL_SPC_RGB should be actually AVCOL_SPC_GBR, but specs are fuzzy on > >> that too, > >> they report "Matrix GBR - Typically referred to as RGB", so I just mention > >> that > >> in the comment. > >> The alternative is either to add an alias or start the deprecation dance. > >> Opinions? > > > > Not worth it IMO. Just expanding doxy is fine. > > Agreed. > > > The commit message should be changed though, you're not adding any > > synonyms that I see. You're extending/adding doxy. > > I considered a synonym something like > +AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal > Regulations 73.682 (a)(20) > > Would "doc: expand description for some color properties" fit better? > Yes, that's fine with me. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avcodec: Reset mutex to NULL on mutex destruction
Quoting Luca Barbato (2014-09-30 02:00:50)
> From: Manfred Georg
>
> A badly behaving user provided mutex manager (such as that in OpenCV)
> may not reset the mutex to NULL on destruction.
>
> This can cause a problem for a later mutex manager
> (which may assert that the mutex is NULL before creating).
>
> Signed-off-by: Manfred Georg
> Signed-off-by: Luca Barbato
> ---
>
> Review in patch form:
> * We normally use ret for keeping the return value
> * We tend to align =
>
>
> libavcodec/utils.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index a472076..204d80b 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -2317,19 +2317,25 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel *hwaccel)
>
> int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
> {
> +int ret;
> +
> if (lockmgr_cb) {
> -if (lockmgr_cb(&codec_mutex, AV_LOCK_DESTROY))
> -return -1;
> -if (lockmgr_cb(&avformat_mutex, AV_LOCK_DESTROY))
> +void *old_codec_mutex= codec_mutex;
> +void *old_avformat_mutex = avformat_mutex;
> +
> +codec_mutex= NULL;
> +avformat_mutex = NULL;
> +
> +ret = lockmgr_cb(&old_codec_mutex, AV_LOCK_DESTROY);
> +if (lockmgr_cb(&old_avformat_mutex, AV_LOCK_DESTROY) || ret)
> return -1;
> }
>
> lockmgr_cb = cb;
>
> if (lockmgr_cb) {
> -if (lockmgr_cb(&codec_mutex, AV_LOCK_CREATE))
> -return -1;
> -if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE))
> +ret = lockmgr_cb(&codec_mutex, AV_LOCK_CREATE);
> +if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE) || ret)
What's the point of creating the lavf lock, if the lavc one failed? The
current code does not do that.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] avcodec: Reset mutex to NULL on mutex destruction
From: Manfred Georg
A badly behaving user provided mutex manager (such as that in OpenCV)
may not reset the mutex to NULL on destruction.
This can cause a problem for a later mutex manager
(which may assert that the mutex is NULL before creating).
Signed-off-by: Manfred Georg
Signed-off-by: Luca Barbato
---
Review in patch form:
* We normally use ret for keeping the return value
* We tend to align =
libavcodec/utils.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index a472076..204d80b 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2317,19 +2317,25 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel *hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
+int ret;
+
if (lockmgr_cb) {
-if (lockmgr_cb(&codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(&avformat_mutex, AV_LOCK_DESTROY))
+void *old_codec_mutex= codec_mutex;
+void *old_avformat_mutex = avformat_mutex;
+
+codec_mutex= NULL;
+avformat_mutex = NULL;
+
+ret = lockmgr_cb(&old_codec_mutex, AV_LOCK_DESTROY);
+if (lockmgr_cb(&old_avformat_mutex, AV_LOCK_DESTROY) || ret)
return -1;
}
lockmgr_cb = cb;
if (lockmgr_cb) {
-if (lockmgr_cb(&codec_mutex, AV_LOCK_CREATE))
-return -1;
-if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE))
+ret = lockmgr_cb(&codec_mutex, AV_LOCK_CREATE);
+if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE) || ret)
return -1;
}
return 0;
--
2.1.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] Reset mutex to NULL after mutex destruction.
On 30/09/14 00:03, Manfred Georg wrote: A badly behaving user provided mutex manager (such as that in OpenCV) may not reset the mutex to NULL on destruction. This can cause a problem for a later mutex manager (which may assert that the mutex is NULL before creating). Looks good to me, thanks a lot. Might be a good candidate for stable as well. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] Reset mutex to NULL after mutex destruction.
A badly behaving user provided mutex manager (such as that in OpenCV) may not
reset the mutex to NULL on destruction. This can cause a problem for a later
mutex manager (which may assert that the mutex is NULL before creating).
Signed-off-by: Manfred Georg
---
libavcodec/utils.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index a472076..47a1b1e 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2318,18 +2318,21 @@ AVHWAccel *av_hwaccel_next(const AVHWAccel *hwaccel)
int av_lockmgr_register(int (*cb)(void **mutex, enum AVLockOp op))
{
if (lockmgr_cb) {
-if (lockmgr_cb(&codec_mutex, AV_LOCK_DESTROY))
-return -1;
-if (lockmgr_cb(&avformat_mutex, AV_LOCK_DESTROY))
+void *old_codec_mutex = codec_mutex;
+void *old_avformat_mutex = avformat_mutex;
+int failure;
+codec_mutex = NULL;
+avformat_mutex = NULL;
+failure = lockmgr_cb(&old_codec_mutex, AV_LOCK_DESTROY);
+if (lockmgr_cb(&old_avformat_mutex, AV_LOCK_DESTROY) || failure)
return -1;
}
lockmgr_cb = cb;
if (lockmgr_cb) {
-if (lockmgr_cb(&codec_mutex, AV_LOCK_CREATE))
-return -1;
-if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE))
+int failure = lockmgr_cb(&codec_mutex, AV_LOCK_CREATE);
+if (lockmgr_cb(&avformat_mutex, AV_LOCK_CREATE) || failure)
return -1;
}
return 0;
--
2.1.0.rc2.206.gedb03e5
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] doc: synonyms for color properties
On 29/09/14 21:05, Vittorio Giovara wrote: Would "doc: expand description for some color properties" fit better? I think so. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] doc: synonyms for color properties
On Mon, Sep 29, 2014 at 7:54 PM, Anton Khirnov wrote: > Quoting Vittorio Giovara (2014-09-29 15:29:12) >> --- >> AVCOL_SPC_RGB should be actually AVCOL_SPC_GBR, but specs are fuzzy on that >> too, >> they report "Matrix GBR - Typically referred to as RGB", so I just mention >> that >> in the comment. >> The alternative is either to add an alias or start the deprecation dance. >> Opinions? > > Not worth it IMO. Just expanding doxy is fine. Agreed. > The commit message should be changed though, you're not adding any > synonyms that I see. You're extending/adding doxy. I considered a synonym something like +AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal Regulations 73.682 (a)(20) Would "doc: expand description for some color properties" fit better? -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/6] pixdesc: return color properties names
On Fri, Sep 26, 2014 at 7:03 PM, Luca Barbato wrote: > On 26/09/14 18:22, Vittorio Giovara wrote: >> >> --- >> doc/APIchanges | 3 +++ >> libavutil/pixdesc.c | 58 >> + >> libavutil/pixdesc.h | 25 +++ >> libavutil/version.h | 4 ++-- >> 4 files changed, 88 insertions(+), 2 deletions(-) >> > > Looks ok to me, I didn't check that every value matches one by one, but > looks like so. They are, however I'll resend this one just to make sure that we match the names used in x264 (and address Diego's comment as well). -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] hevc_mvs: make sure to always initialize the temporal MV fully
On 29/09/14 18:32, Anton Khirnov wrote: The spec requires this. Fixes uninitialized reads on some samples. Remove now unnecessary initialization of the whole merge candidate list. --- libavcodec/hevc_mvs.c | 14 -- 1 file changed, 4 insertions(+), 10 deletions(-) Thanks for cleaning it up. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avplay: Do not try to access the already freed filters
On 29/09/14 20:58, Anton Khirnov wrote:
Quoting Luca Barbato (2014-09-28 11:08:08)
Prevent a segfault on close.
CC: libav-sta...@libav.org
---
avplay.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/avplay.c b/avplay.c
index 58da984..338a881 100644
--- a/avplay.c
+++ b/avplay.c
@@ -1269,13 +1269,17 @@ static void alloc_picture(void *opaque)
SDL_FreeYUVOverlay(vp->bmp);
#if CONFIG_AVFILTER
-vp->width = is->out_video_filter->inputs[0]->w;
-vp->height = is->out_video_filter->inputs[0]->h;
-vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+if (is->out_video_filter) {
+vp->width = is->out_video_filter->inputs[0]->w;
+vp->height = is->out_video_filter->inputs[0]->h;
+vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+} else
Why would this be the correct behaviour?
I'd expect that if the filter has been freed, we don't want to allocate
any new frames, so we return an error here.
Sadly we'd have a crash since we could have pending allocation events.
Might be better flush the queue I guess.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avplay: Do not try to access the already freed filters
Quoting Luca Barbato (2014-09-28 11:08:08)
> Prevent a segfault on close.
>
> CC: libav-sta...@libav.org
> ---
>
> avplay.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/avplay.c b/avplay.c
> index 58da984..338a881 100644
> --- a/avplay.c
> +++ b/avplay.c
> @@ -1269,13 +1269,17 @@ static void alloc_picture(void *opaque)
> SDL_FreeYUVOverlay(vp->bmp);
>
> #if CONFIG_AVFILTER
> -vp->width = is->out_video_filter->inputs[0]->w;
> -vp->height = is->out_video_filter->inputs[0]->h;
> -vp->pix_fmt = is->out_video_filter->inputs[0]->format;
> +if (is->out_video_filter) {
> +vp->width = is->out_video_filter->inputs[0]->w;
> +vp->height = is->out_video_filter->inputs[0]->h;
> +vp->pix_fmt = is->out_video_filter->inputs[0]->format;
> +} else
Why would this be the correct behaviour?
I'd expect that if the filter has been freed, we don't want to allocate
any new frames, so we return an error here.
--
Anton Khirnov
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] hevc_mvs: initialize the temporal MV in case of missing ref
On 29/09/14 18:32, Anton Khirnov wrote: The caller expects the MV to always be initialized. --- libavcodec/hevc_mvs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) Looks ok and seems a good candidate for stable. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] doc: synonyms for color properties
Quoting Vittorio Giovara (2014-09-29 15:29:12) > --- > AVCOL_SPC_RGB should be actually AVCOL_SPC_GBR, but specs are fuzzy on that > too, > they report "Matrix GBR - Typically referred to as RGB", so I just mention > that > in the comment. > The alternative is either to add an alias or start the deprecation dance. > Opinions? Not worth it IMO. Just expanding doxy is fine. The commit message should be changed though, you're not adding any synonyms that I see. You're extending/adding doxy. -- Anton Khirnov ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Enable Decoder Downmix including Downmix Metadata Support
On 09/29/2014 10:24 AM, Omer Osman wrote:
Am 25.09.2014 17:54, schrieb Justin Ruggles:
Right. My point is that it should not check for the number of
channels. The switch should be done on the requested layout itself and
should only support AV_CH_LAYOUT_MONO and AV_CH_LAYOUT_STEREO.
OK, will check for AV_CH_LAYOUT_STEREO, _STEREO_DOWNMIX, and _MONO.
Also, does aacDecoder_GetStreamInfo() report the channel layout info
for the downmixed output or the full coded channel layout? I don't
know the API well enough...
Yes, for example:
CStreamInfo::numChannels = 6
CStreamInfo::pChannelType = { ::ACT_FRONT, ::ACT_FRONT, ::ACT_FRONT,
::ACT_LFE, ::ACT_BACK, ::ACT_BACK }
CStreamInfo::pChannelIndices = { 1, 2, 0, 0, 0, 1 }
Why is this needed if the downmixed output is maximum stereo? On the
other hand, this can simplify the code in
libfdk-accdec.c::get_stream_info (). Should this be implemented instead?
It is needed because get_stream_info() must set AVCodecContext.channels
and AVCodecContext.channel_layout to the downmixed values when
appropriate. Alternatively, the downmixed channel_layout can be set for
the AVFrame prior to ff_get_buffer(), but the former method is preferred
due to the interaction between libavcodec and libavfilter.
-Justin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 1/2] hevc_mvs: initialize the temporal MV in case of missing ref
The caller expects the MV to always be initialized.
---
libavcodec/hevc_mvs.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index a611b76..8b172a2 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -257,8 +257,10 @@ static int temporal_luma_motion_vector(HEVCContext *s, int
x0, int y0,
HEVCFrame *ref = s->ref->collocated_ref;
-if (!ref)
+if (!ref) {
+memset(mvLXCol, 0, sizeof(*mvLXCol));
return 0;
+}
tab_mvf = ref->tab_mvf;
colPic = ref->poc;
--
2.0.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH 2/2] hevc_mvs: make sure to always initialize the temporal MV fully
The spec requires this.
Fixes uninitialized reads on some samples.
Remove now unnecessary initialization of the whole merge candidate list.
---
libavcodec/hevc_mvs.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index 8b172a2..721eb3a 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -481,14 +481,10 @@ static void derive_spatial_merge_candidates(HEVCContext
*s, int x0, int y0,
mergecandlist[nb_merge_cand].is_intra = 0;
mergecandlist[nb_merge_cand].pred_flag[0] = available_l0;
mergecandlist[nb_merge_cand].pred_flag[1] = available_l1;
-if (available_l0) {
-mergecandlist[nb_merge_cand].mv[0] = mv_l0_col;
-mergecandlist[nb_merge_cand].ref_idx[0] = 0;
-}
-if (available_l1) {
-mergecandlist[nb_merge_cand].mv[1] = mv_l1_col;
-mergecandlist[nb_merge_cand].ref_idx[1] = 0;
-}
+AV_ZERO16(mergecandlist[nb_merge_cand].ref_idx);
+mergecandlist[nb_merge_cand].mv[0] = mv_l0_col;
+mergecandlist[nb_merge_cand].mv[1] = mv_l1_col;
+
if (merge_idx == nb_merge_cand)
return;
nb_merge_cand++;
@@ -558,8 +554,6 @@ void ff_hevc_luma_mv_merge_mode(HEVCContext *s, int x0, int
y0, int nPbW,
int nPbH2 = nPbH;
HEVCLocalContext *lc = &s->HEVClc;
-memset(mergecand_list, 0, MRG_MAX_NUM_CANDS * sizeof(*mergecand_list));
-
if (s->pps->log2_parallel_merge_level > 2 && nCS == 8) {
singleMCLFlag = 1;
x0= lc->cu.x;
--
2.0.0
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] jpeg2000: MCT in SSE
Hi, On Mon, Sep 29, 2014 at 7:07 AM, Luca Barbato wrote: > On 29/09/14 11:35, Hendrik Leppkes wrote: > >> On Mon, Sep 29, 2014 at 9:33 AM, Nicolas Bertrand < >> nicoinatte...@gmail.com> >> wrote: >> >> Finally a 1st optimization patch for jpeg2000! >>> To start: an easy one. >>> >>> The main help I need: is where and how to put the SSE optimzation in the >>> x86 directory. >>> >>> >>> We don't allow x86 intrinsics in avcodec. You should write this as a >> yasm >> function. >> >> > Do you have a tutorial about x86inc or something close to that we could > import in the wiki? Better yet, x264 has one: https://wiki.videolan.org/X264asm/ Ronald ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 1/2] Enable Decoder Downmix including Downmix Metadata Support
Am 25.09.2014 17:54, schrieb Justin Ruggles:
Right. My point is that it should not check for the number of
channels. The switch should be done on the requested layout itself and
should only support AV_CH_LAYOUT_MONO and AV_CH_LAYOUT_STEREO.
OK, will check for AV_CH_LAYOUT_STEREO, _STEREO_DOWNMIX, and _MONO.
Also, does aacDecoder_GetStreamInfo() report the channel layout info
for the downmixed output or the full coded channel layout? I don't
know the API well enough...
Yes, for example:
CStreamInfo::numChannels = 6
CStreamInfo::pChannelType = { ::ACT_FRONT, ::ACT_FRONT, ::ACT_FRONT,
::ACT_LFE, ::ACT_BACK, ::ACT_BACK }
CStreamInfo::pChannelIndices = { 1, 2, 0, 0, 0, 1 }
Why is this needed if the downmixed output is maximum stereo? On the
other hand, this can simplify the code in
libfdk-accdec.c::get_stream_info (). Should this be implemented instead?
Am 25.09.2014 09:32, schrieb Martin Storsjö:
previously, we decoded straight into the frame buffer once we knew the
number of channels
I will resubmit this patch with this behavior retained.
__
Omer Osman, M.S.
Realtime Audio Processing
Fraunhofer-Institut für Integrierte Schaltungen IIS
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] doc: synonyms for color properties
---
AVCOL_SPC_RGB should be actually AVCOL_SPC_GBR, but specs are fuzzy on that too,
they report "Matrix GBR - Typically referred to as RGB", so I just mention that
in the comment.
The alternative is either to add an alias or start the deprecation dance.
Opinions?
Vittorio
libavutil/pixfmt.h | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 0cfa1c7..6af6596 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -308,11 +308,12 @@ enum AVColorPrimaries {
AVCOL_PRI_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4 / SMPTE
RP177 Annex B
AVCOL_PRI_UNSPECIFIED = 2,
AVCOL_PRI_RESERVED= 3,
-AVCOL_PRI_BT470M = 4,
+AVCOL_PRI_BT470M = 4, ///< also FCC Title 47 Code of Federal
Regulations 73.682 (a)(20)
+
AVCOL_PRI_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM
AVCOL_PRI_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC
AVCOL_PRI_SMPTE240M = 7, ///< functionally identical to above
-AVCOL_PRI_FILM= 8,
+AVCOL_PRI_FILM= 8, ///< colour filters using Illuminant C
AVCOL_PRI_BT2020 = 9, ///< ITU-R BT2020
AVCOL_PRI_NB, ///< Not part of ABI
};
@@ -344,11 +345,11 @@ enum AVColorTransferCharacteristic {
* YUV colorspace type.
*/
enum AVColorSpace {
-AVCOL_SPC_RGB = 0,
+AVCOL_SPC_RGB = 0, ///< order of coefficients is actually GBR,
also IEC 61966-2-1 (sRGB)
AVCOL_SPC_BT709 = 1, ///< also ITU-R BT1361 / IEC 61966-2-4
xvYCC709 / SMPTE RP177 Annex B
AVCOL_SPC_UNSPECIFIED = 2,
AVCOL_SPC_RESERVED= 3,
-AVCOL_SPC_FCC = 4,
+AVCOL_SPC_FCC = 4, ///< FCC Title 47 Code of Federal Regulations
73.682 (a)(20)
AVCOL_SPC_BT470BG = 5, ///< also ITU-R BT601-6 625 / ITU-R BT1358 625
/ ITU-R BT1700 625 PAL & SECAM / IEC 61966-2-4 xvYCC601
AVCOL_SPC_SMPTE170M = 6, ///< also ITU-R BT601-6 525 / ITU-R BT1358 525
/ ITU-R BT1700 NTSC / functionally identical to above
AVCOL_SPC_SMPTE240M = 7,
--
1.9.3 (Apple Git-50)
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avplay: Do not try to access the already freed filters
On 29/09/14 14:14, Luca Barbato wrote:
On 29/09/14 13:36, Vittorio Giovara wrote:
On Sun, Sep 28, 2014 at 9:56 PM, Vittorio Giovara
wrote:
On Sun, Sep 28, 2014 at 10:08 AM, Luca Barbato
wrote:
Prevent a segfault on close.
CC: libav-sta...@libav.org
---
avplay.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/avplay.c b/avplay.c
index 58da984..338a881 100644
--- a/avplay.c
+++ b/avplay.c
@@ -1269,13 +1269,17 @@ static void alloc_picture(void *opaque)
SDL_FreeYUVOverlay(vp->bmp);
#if CONFIG_AVFILTER
-vp->width = is->out_video_filter->inputs[0]->w;
-vp->height = is->out_video_filter->inputs[0]->h;
-vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+if (is->out_video_filter) {
+vp->width = is->out_video_filter->inputs[0]->w;
+vp->height = is->out_video_filter->inputs[0]->h;
+vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+} else
#else
-vp->width = is->video_st->codec->width;
-vp->height = is->video_st->codec->height;
-vp->pix_fmt = is->video_st->codec->pix_fmt;
+{
+vp->width = is->video_st->codec->width;
+vp->height = is->video_st->codec->height;
+vp->pix_fmt = is->video_st->codec->pix_fmt;
+}
#endif
vp->bmp = SDL_CreateYUVOverlay(vp->width, vp->height,
@@ -1660,6 +1664,8 @@ static int video_thread(void *arg)
#if CONFIG_AVFILTER
av_freep(&vfilters);
avfilter_graph_free(&graph);
+is->in_video_filter = NULL;
+is->out_video_filter = NULL;
#endif
av_free_packet(&pkt);
av_frame_free(&frame);
I think it should be fine.
Well with the sample from 750 with the patch attached I get
Error: the video system does not support an image
size of 704x560 pixels. Try using -vf "scale=w:h"
to reduce the image size.
and then it exits, while without I can play that sample fine.
Grrr, please use asan now that you have it.
if freeying the graph frees also the filter (and it seems according to
asan), it is a bug trying to use those dangling pointers.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avplay: Do not try to access the already freed filters
On 29/09/14 13:36, Vittorio Giovara wrote:
On Sun, Sep 28, 2014 at 9:56 PM, Vittorio Giovara
wrote:
On Sun, Sep 28, 2014 at 10:08 AM, Luca Barbato wrote:
Prevent a segfault on close.
CC: libav-sta...@libav.org
---
avplay.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/avplay.c b/avplay.c
index 58da984..338a881 100644
--- a/avplay.c
+++ b/avplay.c
@@ -1269,13 +1269,17 @@ static void alloc_picture(void *opaque)
SDL_FreeYUVOverlay(vp->bmp);
#if CONFIG_AVFILTER
-vp->width = is->out_video_filter->inputs[0]->w;
-vp->height = is->out_video_filter->inputs[0]->h;
-vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+if (is->out_video_filter) {
+vp->width = is->out_video_filter->inputs[0]->w;
+vp->height = is->out_video_filter->inputs[0]->h;
+vp->pix_fmt = is->out_video_filter->inputs[0]->format;
+} else
#else
-vp->width = is->video_st->codec->width;
-vp->height = is->video_st->codec->height;
-vp->pix_fmt = is->video_st->codec->pix_fmt;
+{
+vp->width = is->video_st->codec->width;
+vp->height = is->video_st->codec->height;
+vp->pix_fmt = is->video_st->codec->pix_fmt;
+}
#endif
vp->bmp = SDL_CreateYUVOverlay(vp->width, vp->height,
@@ -1660,6 +1664,8 @@ static int video_thread(void *arg)
#if CONFIG_AVFILTER
av_freep(&vfilters);
avfilter_graph_free(&graph);
+is->in_video_filter = NULL;
+is->out_video_filter = NULL;
#endif
av_free_packet(&pkt);
av_frame_free(&frame);
I think it should be fine.
Well with the sample from 750 with the patch attached I get
Error: the video system does not support an image
size of 704x560 pixels. Try using -vf "scale=w:h"
to reduce the image size.
and then it exits, while without I can play that sample fine.
Grrr, please use asan now that you have it.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avplay: Do not try to access the already freed filters
On Sun, Sep 28, 2014 at 9:56 PM, Vittorio Giovara
wrote:
> On Sun, Sep 28, 2014 at 10:08 AM, Luca Barbato wrote:
>> Prevent a segfault on close.
>>
>> CC: libav-sta...@libav.org
>> ---
>>
>> avplay.c | 18 --
>> 1 file changed, 12 insertions(+), 6 deletions(-)
>>
>> diff --git a/avplay.c b/avplay.c
>> index 58da984..338a881 100644
>> --- a/avplay.c
>> +++ b/avplay.c
>> @@ -1269,13 +1269,17 @@ static void alloc_picture(void *opaque)
>> SDL_FreeYUVOverlay(vp->bmp);
>>
>> #if CONFIG_AVFILTER
>> -vp->width = is->out_video_filter->inputs[0]->w;
>> -vp->height = is->out_video_filter->inputs[0]->h;
>> -vp->pix_fmt = is->out_video_filter->inputs[0]->format;
>> +if (is->out_video_filter) {
>> +vp->width = is->out_video_filter->inputs[0]->w;
>> +vp->height = is->out_video_filter->inputs[0]->h;
>> +vp->pix_fmt = is->out_video_filter->inputs[0]->format;
>> +} else
>> #else
>> -vp->width = is->video_st->codec->width;
>> -vp->height = is->video_st->codec->height;
>> -vp->pix_fmt = is->video_st->codec->pix_fmt;
>> +{
>> +vp->width = is->video_st->codec->width;
>> +vp->height = is->video_st->codec->height;
>> +vp->pix_fmt = is->video_st->codec->pix_fmt;
>> +}
>> #endif
>>
>> vp->bmp = SDL_CreateYUVOverlay(vp->width, vp->height,
>> @@ -1660,6 +1664,8 @@ static int video_thread(void *arg)
>> #if CONFIG_AVFILTER
>> av_freep(&vfilters);
>> avfilter_graph_free(&graph);
>> +is->in_video_filter = NULL;
>> +is->out_video_filter = NULL;
>> #endif
>> av_free_packet(&pkt);
>> av_frame_free(&frame);
>
> I think it should be fine.
Well with the sample from 750 with the patch attached I get
Error: the video system does not support an image
size of 704x560 pixels. Try using -vf "scale=w:h"
to reduce the image size.
and then it exits, while without I can play that sample fine.
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf/avformat.h: use const char* instead of uint8_t* for AVProbeData.mime_type
On 29.09.2014 13:14, Vittorio Giovara wrote:
On Mon, Sep 29, 2014 at 11:54 AM, Vittorio Giovara
wrote:
On Sun, Sep 14, 2014 at 8:13 PM, Reinhard Tartler wrote:
On Sun, Sep 14, 2014 at 3:00 PM, Luca Barbato wrote:
On 14/09/14 20:57, Reinhard Tartler wrote:
The patch looks fine to me for backporting to release/11
Are we ok in considering it an API clarification (so it gets in as-is)
instead of an API change (with the warning period and so on).
uint8_t* and char* for all we are concerned are the same.
Yes, that is my understanding.
Queueing for HEAD and release/11 with minor cosmetic changes.
And unqueued, the following section looks shady
if (pb->av_class)
-av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &pd.mime_type);
+av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type_opt);
+pd.mime_type = (const char *)mime_type_opt;
+mime_type_opt = NULL;
There is either a missing {} pair or indenting there is too misleading.
Waiting for a few more comments on it or for the author to chime in.
Indeed there should be a {} pair around that block.
Thanks for noticing.
Best regards,
Andreas
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf/avformat.h: use const char* instead of uint8_t* for AVProbeData.mime_type
On Mon, Sep 29, 2014 at 11:54 AM, Vittorio Giovara
wrote:
> On Sun, Sep 14, 2014 at 8:13 PM, Reinhard Tartler wrote:
>> On Sun, Sep 14, 2014 at 3:00 PM, Luca Barbato wrote:
>>> On 14/09/14 20:57, Reinhard Tartler wrote:
The patch looks fine to me for backporting to release/11
>>>
>>> Are we ok in considering it an API clarification (so it gets in as-is)
>>> instead of an API change (with the warning period and so on).
>>>
>>> uint8_t* and char* for all we are concerned are the same.
>>
>> Yes, that is my understanding.
>
> Queueing for HEAD and release/11 with minor cosmetic changes.
And unqueued, the following section looks shady
if (pb->av_class)
-av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &pd.mime_type);
+av_opt_get(pb, "mime_type", AV_OPT_SEARCH_CHILDREN, &mime_type_opt);
+pd.mime_type = (const char *)mime_type_opt;
+mime_type_opt = NULL;
There is either a missing {} pair or indenting there is too misleading.
Waiting for a few more comments on it or for the author to chime in.
--
Vittorio
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/6] dump: split audio and video probing on multiple lines
On 29/09/14 12:56, Vittorio Giovara wrote: On Mon, Sep 29, 2014 at 8:42 AM, Luca Barbato wrote: On 28/09/14 22:37, Vittorio Giovara wrote: Moving disposition tag should be on a different patch and i'd rather leave the first line only for codec and profile information. Actually I have never seen a sample with a disposition different than "default", is it worthwhile printing it at all? disposition tells us: - which is the active/default track among many. - which are the special-use tracks. In the format that support the concept it is an useful information. Ok, I'll move it on the first line in a separate patch, is this one good to go? Yes ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] jpeg2000: MCT in SSE
On 29/09/14 11:35, Hendrik Leppkes wrote: On Mon, Sep 29, 2014 at 9:33 AM, Nicolas Bertrand wrote: Finally a 1st optimization patch for jpeg2000! To start: an easy one. The main help I need: is where and how to put the SSE optimzation in the x86 directory. We don't allow x86 intrinsics in avcodec. You should write this as a yasm function. Do you have a tutorial about x86inc or something close to that we could import in the wiki? lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] rtmpproto: Add getStreamLength call to query duration
Hi Uwe,
On Mon, 29 Sep 2014, Uwe L. Korn wrote:
In (non-live) streams with no metadata, the duration of a stream can
be retrieved by calling the RTMP function getStreamLength with the
playpath. The server will return a positive duration upon the request if
the duration is known, otherwise either no response or a duration of 0
will be returned.
---
libavformat/rtmpproto.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 4aaa420..ccc64b2 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -123,6 +123,7 @@ typedef struct RTMPContext {
int listen; ///< listen mode flag
int listen_timeout; ///< listen timeout to wait for
new connections
int nb_streamid;///< The next stream id to return
on createStream calls
+doubleduration; ///< Duration of the stream in
seconds as returned by the server (only valid if non-zero)
char username[50];
char password[50];
char auth_params[500];
@@ -679,6 +680,30 @@ static int gen_delete_stream(URLContext *s, RTMPContext
*rt)
}
/**
+ * Generate 'getStreamLength' call and send it to the server. If the server
+ * knows the duration of the selected stream, it will reply with the duration
+ * in seconds.
+ */
+static int gen_get_stream_length(URLContext *s, RTMPContext *rt)
+{
+RTMPPacket pkt;
+uint8_t *p;
+int ret;
+
+if ((ret = ff_rtmp_packet_create(&pkt, RTMP_SOURCE_CHANNEL, RTMP_PT_INVOKE,
+ 0, 31 + strlen(rt->playpath))) < 0)
+return ret;
+
+p = pkt.data;
+ff_amf_write_string(&p, "getStreamLength");
+ff_amf_write_number(&p, ++rt->nb_invokes);
+ff_amf_write_null(&p);
+ff_amf_write_string(&p, rt->playpath);
+
+return rtmp_send_packet(rt, &pkt, 1);
+}
+
+/**
* Generate client buffer time and send it to the server.
*/
static int gen_buffer_time(URLContext *s, RTMPContext *rt)
@@ -2005,11 +2030,18 @@ static int handle_invoke_result(URLContext *s,
RTMPPacket *pkt)
if ((ret = gen_publish(s, rt)) < 0)
goto fail;
} else {
+if (rt->live != -1) {
+if ((ret = gen_get_stream_length(s, rt)) < 0)
+goto fail;
+}
if ((ret = gen_play(s, rt)) < 0)
goto fail;
if ((ret = gen_buffer_time(s, rt)) < 0)
goto fail;
}
+} else if (!strcmp(tracked_method, "getStreamLength")) {
+// If the server does not know the duration of the stream, it will
report 0 here.
+rt->duration = av_int2double(AV_RB64(pkt->data + 21));
Is there any guarantee that pkt->data contains 21+8 bytes? I don't
remember all the details of this codepath at the moment, but right now it
doesn't seem so.
I do see a similar assumption above though (just above the context of this
hunk of the diff) - can you check whether there's anything that makes sure
that's correct, or is that codepath also missing a similar check?
}
fail:
@@ -2617,6 +2649,7 @@ reconnect:
rt->received_metadata = 0;
rt->last_bytes_read = 0;
rt->server_bw = 250;
+rt->duration = 0;
av_log(s, AV_LOG_DEBUG, "Proto = %s, path = %s, app = %s, fname = %s\n",
proto, path, rt->app, rt->playpath);
@@ -2675,6 +2708,54 @@ reconnect:
if (rt->has_video) {
rt->flv_data[4] |= FLV_HEADER_FLAG_HASVIDEO;
}
+
+// If we received the first packet of an A/V stream and no metadata but
+// the server returned a valid duration, create a fake metadata packet
+// to inform the FLV decoder about the duration.
+if (!rt->received_metadata && rt->duration > 0) {
+// We need to insert the metdata packet directly after the FLV
+// header, i.e. we need to move all other already read data by the
+// size of our fake metadata packet.
+
+uint8_t* p;
+// Keep old flv_data pointer
+uint8_t* old_flv_data = rt->flv_data;
+// Allocate a new flv_data pointer with enough space for the
additional package
+rt->flv_data = av_malloc(rt->flv_size + 55);
Missing a check for the malloc
+// Copy FLV header
+memcpy(rt->flv_data, old_flv_data, 13);
+// Copy remaining packets
+memcpy(rt->flv_data + 13 + 55, old_flv_data + 13, rt->flv_size -
13);
+// Increase the size by the injected packet
+rt->flv_size += 55;
+
+p = rt->flv_data + 13;
+bytestream_put_byte(&p, 18); // tag type META
At least this number could be gotten from flv.h as FLV_TAG_TYPE_META
+bytestream_put_be24(&p, 40); // size of data part (sum of all
parts below)
+bytestream_put_be24(&p, 0);
Re: [libav-devel] [PATCH 3/6] dump: split audio and video probing on multiple lines
On Mon, Sep 29, 2014 at 8:42 AM, Luca Barbato wrote: > On 28/09/14 22:37, Vittorio Giovara wrote: >> >> Moving disposition tag should be on a different patch and i'd rather >> leave the first line only for codec and profile information. Actually >> I have never seen a sample with a disposition different than >> "default", is it worthwhile printing it at all? > > > disposition tells us: > - which is the active/default track among many. > - which are the special-use tracks. > > In the format that support the concept it is an useful information. Ok, I'll move it on the first line in a separate patch, is this one good to go? -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] lavf/avformat.h: use const char* instead of uint8_t* for AVProbeData.mime_type
On Sun, Sep 14, 2014 at 8:13 PM, Reinhard Tartler wrote: > On Sun, Sep 14, 2014 at 3:00 PM, Luca Barbato wrote: >> On 14/09/14 20:57, Reinhard Tartler wrote: >>> The patch looks fine to me for backporting to release/11 >> >> Are we ok in considering it an API clarification (so it gets in as-is) >> instead of an API change (with the warning period and so on). >> >> uint8_t* and char* for all we are concerned are the same. > > Yes, that is my understanding. Queueing for HEAD and release/11 with minor cosmetic changes. -- Vittorio ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] rtmpproto: Add getStreamLength call to query duration
On 29/09/14 12:08, Uwe L. Korn wrote:
In (non-live) streams with no metadata, the duration of a stream can
be retrieved by calling the RTMP function getStreamLength with the
playpath. The server will return a positive duration upon the request if
the duration is known, otherwise either no response or a duration of 0
will be returned.
---
libavformat/rtmpproto.c | 81 +
1 file changed, 81 insertions(+)
+} else if (!strcmp(tracked_method, "getStreamLength")) {
+// If the server does not know the duration of the stream, it will
report 0 here.
+rt->duration = av_int2double(AV_RB64(pkt->data + 21));
}
Do not we have a read function for this kind of stuff?
fail:
@@ -2617,6 +2649,7 @@ reconnect:
rt->received_metadata = 0;
rt->last_bytes_read = 0;
rt->server_bw = 250;
+rt->duration = 0;
av_log(s, AV_LOG_DEBUG, "Proto = %s, path = %s, app = %s, fname = %s\n",
proto, path, rt->app, rt->playpath);
@@ -2675,6 +2708,54 @@ reconnect:
if (rt->has_video) {
rt->flv_data[4] |= FLV_HEADER_FLAG_HASVIDEO;
}
+
+// If we received the first packet of an A/V stream and no metadata but
+// the server returned a valid duration, create a fake metadata packet
+// to inform the FLV decoder about the duration.
+if (!rt->received_metadata && rt->duration > 0) {
Make it a stand-alone function please.
The concept sounds good to me.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 5/6] dump: print the original coded dimensions when available
On 26/09/14 18:22, Vittorio Giovara wrote:
---
libavcodec/utils.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 9cb3ef8..0c36548 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1912,6 +1912,12 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
snprintf(buf + strlen(buf), buf_size - strlen(buf),
"%dx%d",
enc->width, enc->height);
+if (av_log_get_level() >= AV_LOG_VERBOSE &&
+(enc->width != enc->coded_width ||
+ enc->height != enc->coded_height))
+snprintf(buf + strlen(buf), buf_size - strlen(buf),
+ " (%dx%d)", enc->coded_width, enc->coded_height);
+
av_strlcat(buf, ", ", buf_size);
if (enc->sample_aspect_ratio.num) {
av_reduce(&display_aspect_ratio.num,
&display_aspect_ratio.den,
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 4/6] dump: print detailed color space information
On 26/09/14 18:22, Vittorio Giovara wrote:
---
libavcodec/utils.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ac5fb87..9cb3ef8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1885,6 +1885,24 @@ void avcodec_string(char *buf, int buf_size,
AVCodecContext *enc, int encode)
"%s",
av_get_pix_fmt_name(enc->pix_fmt));
}
+
+if (enc->color_range != AVCOL_RANGE_UNSPECIFIED)
+snprintf(buf + strlen(buf), buf_size - strlen(buf), ", %s",
+ av_color_range_name(enc->color_range));
+if (enc->colorspace != AVCOL_SPC_UNSPECIFIED ||
+enc->color_primaries != AVCOL_PRI_UNSPECIFIED ||
+enc->color_trc != AVCOL_TRC_UNSPECIFIED) {
+new_line = 1;
+snprintf(buf + strlen(buf), buf_size - strlen(buf), ", %s/%s/%s",
+ av_color_space_name(enc->colorspace),
+ av_color_primaries_name(enc->color_primaries),
+ av_color_transfer_name(enc->color_trc));
+}
+if (av_log_get_level() >= AV_LOG_DEBUG &&
+enc->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
+snprintf(buf + strlen(buf), buf_size - strlen(buf), ", %s",
+ av_chroma_location_name(enc->chroma_sample_location));
+
if (enc->width) {
if (new_line)
snprintf(buf + strlen(buf), buf_size - strlen(buf), "\n
");
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 6/6] avcodec: make sure color_range is properly initialized
On 26/09/14 18:22, Vittorio Giovara wrote:
---
libavcodec/utils.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 0c36548..7fce674 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1153,6 +1153,11 @@ int attribute_align_arg avcodec_open2(AVCodecContext
*avctx, const AVCodec *code
ret = AVERROR(EINVAL);
goto free_and_end;
}
+if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ420P ||
+avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ422P ||
+avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ440P ||
+avctx->codec->pix_fmts[i] == AV_PIX_FMT_YUVJ444P)
+avctx->color_range = AVCOL_RANGE_JPEG;
}
if (avctx->codec->supported_samplerates) {
for (i = 0; avctx->codec->supported_samplerates[i] != 0; i++)
Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avutil/file_open: Cleanup fcntl handling in avpriv_open()
On 29/09/14 10:20, Rémi Denis-Courmont wrote: Besides, you are already screwed if you need to call fcntl() to begin with. It means the system lacks O_CLOEXEC and thus file descriptors allocation is not thread-safe fork-safe. If fcntl() were to fail too, then you merely loose non-threaded fork safety. Thanks for the in-depth analysis, I'll update coverity tonight with it. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] sdp: Make opus declaration conform to the spec
On Fri, 26 Sep 2014, Timothy B. Terriberry wrote: Err, trying again with an actual attached patch LGTM, thanks - pushed. // Martin ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] jpeg2000: MCT in SSE
On 29/09/14 09:33, Nicolas Bertrand wrote: Finally a 1st optimization patch for jpeg2000! To start: an easy one. The main help I need: is where and how to put the SSE optimzation in the x86 directory. We should put in the wiki some information about it (since now we do support also intrinsics). The steps could be: - IF you want to use intrinsics for x86 (IIRC they do not give decent results) - add intrinsics_sse in INTRINSICS_LIST - add a dependency as done by intrinsics_neon_deps - add a check like the neon one - put the file in libavcodec/sse/ as had been done with neon - IF you feel motivated you can convert it to yasm and use it, eventually somebody will do that anyway since the speed gain is usually compelling and the x86inc syntactic sugar makes quite less-painful compared to other asm approaches. Anybody against intrinsics can be constructive and show Nicolas how to use yasm, possibly writing a tutorial in the wiki. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 6/6] hwaccel: QSV H264 support using libmfx
On 02/09/14 12:08, Luca Barbato wrote: On 02/09/14 11:35, Gwenole Beauchesne wrote: I like mfx because this clearly represents the name of the supporting library too, so this could help users check it's installed beforehand to any complaint that the resulting code does not work. However, cons points include (i) probably too similar to MXF, so this could be a little confusing, and (ii) in reality, MFX is one legacy codename for the original decode block. Any name is fine to me. I'm rebasing and renaming to: files: - libmfx*.c Structs: - Libmfx*Context Namespace: - mfx_* - av_mfx_* I'd do this evening, since it is *quite* time consuming I'd like to have comments before I do that. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] rtmpproto: Add getStreamLength call to query duration
In (non-live) streams with no metadata, the duration of a stream can
be retrieved by calling the RTMP function getStreamLength with the
playpath. The server will return a positive duration upon the request if
the duration is known, otherwise either no response or a duration of 0
will be returned.
---
libavformat/rtmpproto.c | 81 +
1 file changed, 81 insertions(+)
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index 4aaa420..ccc64b2 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -123,6 +123,7 @@ typedef struct RTMPContext {
int listen; ///< listen mode flag
int listen_timeout; ///< listen timeout to wait for
new connections
int nb_streamid;///< The next stream id to
return on createStream calls
+doubleduration; ///< Duration of the stream in
seconds as returned by the server (only valid if non-zero)
char username[50];
char password[50];
char auth_params[500];
@@ -679,6 +680,30 @@ static int gen_delete_stream(URLContext *s, RTMPContext
*rt)
}
/**
+ * Generate 'getStreamLength' call and send it to the server. If the server
+ * knows the duration of the selected stream, it will reply with the duration
+ * in seconds.
+ */
+static int gen_get_stream_length(URLContext *s, RTMPContext *rt)
+{
+RTMPPacket pkt;
+uint8_t *p;
+int ret;
+
+if ((ret = ff_rtmp_packet_create(&pkt, RTMP_SOURCE_CHANNEL, RTMP_PT_INVOKE,
+ 0, 31 + strlen(rt->playpath))) < 0)
+return ret;
+
+p = pkt.data;
+ff_amf_write_string(&p, "getStreamLength");
+ff_amf_write_number(&p, ++rt->nb_invokes);
+ff_amf_write_null(&p);
+ff_amf_write_string(&p, rt->playpath);
+
+return rtmp_send_packet(rt, &pkt, 1);
+}
+
+/**
* Generate client buffer time and send it to the server.
*/
static int gen_buffer_time(URLContext *s, RTMPContext *rt)
@@ -2005,11 +2030,18 @@ static int handle_invoke_result(URLContext *s,
RTMPPacket *pkt)
if ((ret = gen_publish(s, rt)) < 0)
goto fail;
} else {
+if (rt->live != -1) {
+if ((ret = gen_get_stream_length(s, rt)) < 0)
+goto fail;
+}
if ((ret = gen_play(s, rt)) < 0)
goto fail;
if ((ret = gen_buffer_time(s, rt)) < 0)
goto fail;
}
+} else if (!strcmp(tracked_method, "getStreamLength")) {
+// If the server does not know the duration of the stream, it will
report 0 here.
+rt->duration = av_int2double(AV_RB64(pkt->data + 21));
}
fail:
@@ -2617,6 +2649,7 @@ reconnect:
rt->received_metadata = 0;
rt->last_bytes_read = 0;
rt->server_bw = 250;
+rt->duration = 0;
av_log(s, AV_LOG_DEBUG, "Proto = %s, path = %s, app = %s, fname = %s\n",
proto, path, rt->app, rt->playpath);
@@ -2675,6 +2708,54 @@ reconnect:
if (rt->has_video) {
rt->flv_data[4] |= FLV_HEADER_FLAG_HASVIDEO;
}
+
+// If we received the first packet of an A/V stream and no metadata but
+// the server returned a valid duration, create a fake metadata packet
+// to inform the FLV decoder about the duration.
+if (!rt->received_metadata && rt->duration > 0) {
+// We need to insert the metdata packet directly after the FLV
+// header, i.e. we need to move all other already read data by the
+// size of our fake metadata packet.
+
+uint8_t* p;
+// Keep old flv_data pointer
+uint8_t* old_flv_data = rt->flv_data;
+// Allocate a new flv_data pointer with enough space for the
additional package
+rt->flv_data = av_malloc(rt->flv_size + 55);
+// Copy FLV header
+memcpy(rt->flv_data, old_flv_data, 13);
+// Copy remaining packets
+memcpy(rt->flv_data + 13 + 55, old_flv_data + 13, rt->flv_size -
13);
+// Increase the size by the injected packet
+rt->flv_size += 55;
+
+p = rt->flv_data + 13;
+bytestream_put_byte(&p, 18); // tag type META
+bytestream_put_be24(&p, 40); // size of data part (sum of all
parts below)
+bytestream_put_be24(&p, 0); // timestamp
+bytestream_put_be32(&p, 0); // reserved
+
+// first event name as a string
+bytestream_put_byte(&p, AMF_DATA_TYPE_STRING);
+// "onMetaData" as AMF string
+bytestream_put_be16(&p, 10);
+bytestream_put_buffer(&p, "onMetaData", 10);
+
+// mixed array (hash) with size and string/type/data tuples
+bytestream_put_byte(&p, AMF_DATA_TYPE_MIXEDARRAY);
+bytestream_put_be32(&p, 1); // metadata_
[libav-devel] [RFC] jpeg2000: MCT in SSE
From: Nicolas Bertrand
Finally a 1st optimization patch for jpeg2000!
To start: an easy one.
The main help I need: is where and how to put the SSE optimzation in the
x86 directory.
Cheers
Nicolas
---
libavcodec/jpeg2000dec.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index aed9b2b..3b7df1e 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -28,6 +28,10 @@
#include
#include "libavutil/attributes.h"
+#ifdef __SSE__
+#include
+#endif
+
#include "libavutil/common.h"
#include "libavutil/opt.h"
#include "avcodec.h"
@@ -1056,6 +1060,52 @@ static const int i_ict_params[4] = {
116130
};
+static void mct_decode_sse(
+float* restrict c0,
+float* restrict c1,
+float* restrict c2,
+int n)
+{
+int i;
+__m128 vrv, vgu, vgv, vbu;
+vrv = _mm_set1_ps(1.402f);
+vgu = _mm_set1_ps(0.34413f);
+vgv = _mm_set1_ps(0.71414f);
+vbu = _mm_set1_ps(1.772f);
+for (i = 0; i < (n >> 3); ++i) {
+__m128 vy, vu, vv;
+__m128 vr, vg, vb;
+
+vy = _mm_load_ps(c0);
+vu = _mm_load_ps(c1);
+vv = _mm_load_ps(c2);
+vr = _mm_add_ps(vy, _mm_mul_ps(vv, vrv));
+vg = _mm_sub_ps(_mm_sub_ps(vy, _mm_mul_ps(vu, vgu)), _mm_mul_ps(vv,
vgv));
+vb = _mm_add_ps(vy, _mm_mul_ps(vu, vbu));
+_mm_store_ps(c0, vr);
+_mm_store_ps(c1, vg);
+_mm_store_ps(c2, vb);
+c0 += 4;
+c1 += 4;
+c2 += 4;
+
+vy = _mm_load_ps(c0);
+vu = _mm_load_ps(c1);
+vv = _mm_load_ps(c2);
+vr = _mm_add_ps(vy, _mm_mul_ps(vv, vrv));
+vg = _mm_sub_ps(_mm_sub_ps(vy, _mm_mul_ps(vu, vgu)), _mm_mul_ps(vv,
vgv));
+vb = _mm_add_ps(vy, _mm_mul_ps(vu, vbu));
+_mm_store_ps(c0, vr);
+_mm_store_ps(c1, vg);
+_mm_store_ps(c2, vb);
+c0 += 4;
+c1 += 4;
+c2 += 4;
+}
+n &= 7;
+}
+
+
static void mct_decode(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile)
{
int i, csize = 1;
@@ -1072,6 +1122,10 @@ static void mct_decode(Jpeg2000DecoderContext *s,
Jpeg2000Tile *tile)
csize *= tile->comp[0].coord[i][1] - tile->comp[0].coord[i][0];
switch (tile->codsty[0].transform) {
case FF_DWT97:
+#ifdef __SSE__
+mct_decode_sse(srcf[0], srcf[1], srcf[2], csize);
+#else
+
for (i = 0; i < csize; i++) {
i0f = *srcf[0] + (f_ict_params[0] * *srcf[2]);
i1f = *srcf[0] - (f_ict_params[1] * *srcf[1])
@@ -1081,6 +1135,7 @@ static void mct_decode(Jpeg2000DecoderContext *s,
Jpeg2000Tile *tile)
*srcf[1]++ = i1f;
*srcf[2]++ = i2f;
}
+#endif
break;
case FF_DWT97_INT:
for (i = 0; i < csize; i++) {
--
1.7.9.5
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [RFC] jpeg2000: MCT in SSE
On Mon, Sep 29, 2014 at 9:33 AM, Nicolas Bertrand wrote: > Finally a 1st optimization patch for jpeg2000! > To start: an easy one. > > The main help I need: is where and how to put the SSE optimzation in the > x86 directory. > > We don't allow x86 intrinsics in avcodec. You should write this as a yasm function. - Hendrik ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [RFC] jpeg2000: MCT in SSE
Finally a 1st optimization patch for jpeg2000!
To start: an easy one.
The main help I need: is where and how to put the SSE optimzation in the
x86 directory.
Cheers
Nicolas
---
libavcodec/jpeg2000dec.c | 55 ++
1 file changed, 55 insertions(+)
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index aed9b2b..3b7df1e 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -28,6 +28,10 @@
#include
#include "libavutil/attributes.h"
+#ifdef __SSE__
+#include
+#endif
+
#include "libavutil/common.h"
#include "libavutil/opt.h"
#include "avcodec.h"
@@ -1056,6 +1060,52 @@ static const int i_ict_params[4] = {
116130
};
+static void mct_decode_sse(
+float* restrict c0,
+float* restrict c1,
+float* restrict c2,
+int n)
+{
+int i;
+__m128 vrv, vgu, vgv, vbu;
+vrv = _mm_set1_ps(1.402f);
+vgu = _mm_set1_ps(0.34413f);
+vgv = _mm_set1_ps(0.71414f);
+vbu = _mm_set1_ps(1.772f);
+for (i = 0; i < (n >> 3); ++i) {
+__m128 vy, vu, vv;
+__m128 vr, vg, vb;
+
+vy = _mm_load_ps(c0);
+vu = _mm_load_ps(c1);
+vv = _mm_load_ps(c2);
+vr = _mm_add_ps(vy, _mm_mul_ps(vv, vrv));
+vg = _mm_sub_ps(_mm_sub_ps(vy, _mm_mul_ps(vu, vgu)), _mm_mul_ps(vv,
vgv));
+vb = _mm_add_ps(vy, _mm_mul_ps(vu, vbu));
+_mm_store_ps(c0, vr);
+_mm_store_ps(c1, vg);
+_mm_store_ps(c2, vb);
+c0 += 4;
+c1 += 4;
+c2 += 4;
+
+vy = _mm_load_ps(c0);
+vu = _mm_load_ps(c1);
+vv = _mm_load_ps(c2);
+vr = _mm_add_ps(vy, _mm_mul_ps(vv, vrv));
+vg = _mm_sub_ps(_mm_sub_ps(vy, _mm_mul_ps(vu, vgu)), _mm_mul_ps(vv,
vgv));
+vb = _mm_add_ps(vy, _mm_mul_ps(vu, vbu));
+_mm_store_ps(c0, vr);
+_mm_store_ps(c1, vg);
+_mm_store_ps(c2, vb);
+c0 += 4;
+c1 += 4;
+c2 += 4;
+}
+n &= 7;
+}
+
+
static void mct_decode(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile)
{
int i, csize = 1;
@@ -1072,6 +1122,10 @@ static void mct_decode(Jpeg2000DecoderContext *s,
Jpeg2000Tile *tile)
csize *= tile->comp[0].coord[i][1] - tile->comp[0].coord[i][0];
switch (tile->codsty[0].transform) {
case FF_DWT97:
+#ifdef __SSE__
+mct_decode_sse(srcf[0], srcf[1], srcf[2], csize);
+#else
+
for (i = 0; i < csize; i++) {
i0f = *srcf[0] + (f_ict_params[0] * *srcf[2]);
i1f = *srcf[0] - (f_ict_params[1] * *srcf[1])
@@ -1081,6 +1135,7 @@ static void mct_decode(Jpeg2000DecoderContext *s,
Jpeg2000Tile *tile)
*srcf[1]++ = i1f;
*srcf[2]++ = i2f;
}
+#endif
break;
case FF_DWT97_INT:
for (i = 0; i < csize; i++) {
--
1.7.9.5
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avutil/file_open: Cleanup fcntl handling in avpriv_open()
Le 2014-09-28 23:41, Vittorio Giovara a écrit : for CID-less folks, the report is on line 88-89, and it's about "check_return: Calling fcntl(fd, 2, 1) without checking return value. This library function may fail and return an error code." There are absolutely no sane circumstances in which this fcntl(F_SETFD) would fail and the least insane thing to do is ignore the error. Yes, fcntl() can fail, but on some other F_* operations. Besides, you are already screwed if you need to call fcntl() to begin with. It means the system lacks O_CLOEXEC and thus file descriptors allocation is not thread-safe fork-safe. If fcntl() were to fail too, then you merely loose non-threaded fork safety. -- Rémi Denis-Courmont ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] h264: reset ret to avoid propagating minor failures
On 28/09/14 22:54, Vittorio Giovara wrote: Ok I'll push it mentioning the commit that introduced the bug. Good. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 3/6] dump: split audio and video probing on multiple lines
On 28/09/14 22:37, Vittorio Giovara wrote: Moving disposition tag should be on a different patch and i'd rather leave the first line only for codec and profile information. Actually I have never seen a sample with a disposition different than "default", is it worthwhile printing it at all? disposition tells us: - which is the active/default track among many. - which are the special-use tracks. In the format that support the concept it is an useful information. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] hevc: Initialize mergecand_list to 0
On 29/09/14 01:01, Vittorio Giovara wrote:
On Sat, Sep 27, 2014 at 11:20 PM, Luca Barbato wrote:
On 17/09/14 19:51, Luca Barbato wrote:
Unbreaks cf6090dc6252f2b276aa4133e3d73a89f4c6046c
CC: libav-sta...@libav.org
---
libavcodec/hevc_mvs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/hevc_mvs.c b/libavcodec/hevc_mvs.c
index cc5a16c..a611b76 100644
--- a/libavcodec/hevc_mvs.c
+++ b/libavcodec/hevc_mvs.c
@@ -556,6 +556,8 @@ void ff_hevc_luma_mv_merge_mode(HEVCContext *s, int
x0, int y0, int nPbW,
int nPbH2 = nPbH;
HEVCLocalContext *lc = &s->HEVClc;
+memset(mergecand_list, 0, MRG_MAX_NUM_CANDS *
sizeof(*mergecand_list));
+
if (s->pps->log2_parallel_merge_level > 2 && nCS == 8) {
singleMCLFlag = 1;
x0= lc->cu.x;
Ping.
Should not hurt, even if the list is already initialized IMHO.
It is not, thus why I'm pinging.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] avutil/file_open: Cleanup fcntl handling in avpriv_open()
On 28/09/14 22:41, Vittorio Giovara wrote: for CID-less folks, the report is on line 88-89, and it's about "check_return: Calling fcntl(fd, 2, 1) without checking return value. This library function may fail and return an error code." We do ignore the return value on a function that is allowed to fail, not sure of the gravity of it. I'd not mind returning it properly but not sure if it's worthwhile. Actually that function can fail only if the previous open would to my understanding. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
