[FFmpeg-devel] [PATCH 1/2] avformat/flvenc: add flv living stream flag

[Steven Liu]

0001-avformat-flvenc-add-flv-living-stream-flag.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] doc/muxers: add flvenc living_stream flag doc

[Steven Liu]

0002-doc-muxers-add-flvenc-living_stream-flag-doc.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavf/mov.c: Make audio timestamps strictly monotonically increasing inside an edit list.

[Michael Niedermayer]

On Tue, Sep 27, 2016 at 04:12:22PM -0700, Sasi Inguva wrote:
> Corrected indentation. Don't know why the patch would not apply. I am
> attaching it as a file, if it helps.

applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- 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/utils.c: Subtract skip_samples when frame is DISCARDed.

[Michael Niedermayer]

On Mon, Sep 26, 2016 at 06:41:01PM -0700, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavcodec/utils.c   | 16 +++-
>  libavcodec/version.h |  2 +-
>  2 files changed, 8 insertions(+), 10 deletions(-)

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

[FFmpeg-devel] [PATCH] avformat/framehash: also print channel layout as a string

[James Almer]

This should be more useful for users since numerical values for channel
layout can be confusing and unintuitive.

Signed-off-by: James Almer 
---
 libavformat/framehash.c |  3 +++
 tests/ref/fate/8bps |  1 +
 tests/ref/fate/adpcm-4xm|  1 +
 tests/ref/fate/adpcm-afc|  1 +
 tests/ref/fate/adpcm-dtk|  1 +
 tests/ref/fate/adpcm-ea-1   |  1 +
 tests/ref/fate/adpcm-ea-2   |  1 +
 tests/ref/fate/adpcm-ea-maxis-xa|  1 +
 tests/ref/fate/adpcm-ea-r1  |  1 +
 tests/ref/fate/adpcm-ima-amv|  1 +
 tests/ref/fate/adpcm-ima-ea-eacs|  1 +
 tests/ref/fate/adpcm-ima-ea-sead|  1 +
 tests/ref/fate/adpcm-ima-smjpeg |  1 +
 tests/ref/fate/adpcm-ima-ws |  1 +
 tests/ref/fate/adpcm-ms-mono|  1 +
 tests/ref/fate/adpcm-thp|  1 +
 tests/ref/fate/adpcm-vima   |  1 +
 tests/ref/fate/adpcm-xa |  1 +
 tests/ref/fate/adtstoasc_ticket3715 |  1 +
 tests/ref/fate/armovie-escape124|  1 +
 tests/ref/fate/bethsoft-vid |  1 +
 tests/ref/fate/bfi  |  1 +
 tests/ref/fate/bmv-audio|  1 +
 tests/ref/fate/cdxl-demux   |  1 +
 tests/ref/fate/copy-trac236 |  1 +
 tests/ref/fate/copy-trac4914|  1 +
 tests/ref/fate/copy-trac4914-avi|  1 +
 tests/ref/fate/corepng  |  1 +
 tests/ref/fate/creatureshock-avs|  1 +
 tests/ref/fate/cyberia-c93  |  1 +
 tests/ref/fate/d-cinema-demux   |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_0  |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_2   |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_6   |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_1  |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2   |  1 +
 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_6   |  1 +
 tests/ref/fate/dca-xll_51_24_48_768 |  1 +
 tests/ref/fate/dca-xll_51_24_48_768-dmix_2  |  1 +
 tests/ref/fate/dca-xll_51_24_48_768-dmix_6  |  1 +
 tests/ref/fate/dca-xll_51_24_48_none|  1 +
 tests/ref/fate/dca-xll_51_24_48_none-dmix_2 |  1 +
 tests/ref/fate/dca-xll_51_24_48_none-dmix_6 |  1 +
 tests/ref/fate/dca-xll_71_24_48_768_0   |  1 +
 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2|  1 +
 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6|  1 +
 tests/ref/fate/dca-xll_71_24_48_768_1   |  1 +
 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2|  1 +
 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6|  1 +
 tests/ref/fate/dca-xll_71_24_96_768 |  1 +
 tests/ref/fate/dca-xll_71_24_96_768-dmix_2  |  1 +
 tests/ref/fate/dca-xll_71_24_96_768-dmix_6  |  1 +
 tests/ref/fate/dca-xll_x96_51_24_96_1509|  1 +
 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_2 |  1 +
 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_6 |  1 +
 tests/ref/fate/dca-xll_xch_61_24_48_768 |  1 +
 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_2  |  1 +
 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_6  |  1 +
 tests/ref/fate/dcinema-encode   |  1 +
 tests/ref/fate/delphine-cin-audio   |  1 +
 tests/ref/fate/dpcm-idroq   |  1 +
 tests/ref/fate/dpcm-interplay   |  1 +
 tests/ref/fate/dss-lp   |  1 +
 tests/ref/fate/dss-sp   |  1 +
 tests/ref/fate/ffmpeg-filter_colorkey   |  1 +
 tests/ref/fate/filter-acrossfade|  1 +
 tests/ref/fate/filter-adelay|  1 +
 tests/ref/fate/filter-aecho |  1 +
 tests/ref/fate/filter-aemphasis-50fm|  1 +
 tests/ref/fate/filter-aemphasis-75kf|  1 +
 tests/ref/fate/filter-afade-esin|  1 +
 tests/ref/fate/filter-afade-exp |  1 +
 tests/ref/fate/filter-afade-hsin|  1 +
 tests/ref/fate/filter-afade-iqsin   |  1 +
 tests/ref/fate/filter-afade-log |  1 +
 tests/ref/fate/filter-afade-qsin|  1 +
 tests/ref/fate/filter-agate |  1 +
 tests/ref/fate/filter-alimiter  |  1 +
 tests/ref/fate/filter-amerge|  1 +
 tests/ref/fate/filter-anequalizer   |  1 +
 tests/ref/fate/filter-apad  |  1 +
 tests/ref/fate/filter-asetnsamples  |  1 +
 tests/ref/fate/filter-asetrate  |  1 +
 tests/ref/fate/filter-atrim-duration|  1 +
 tests/ref/fate/filter-atrim-mixed   |  1 +
 tests/ref/fate/filter-atrim-samples |  1 +
 

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: re-copy codec parameters after encoding

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 11:29:00AM -0700, Jon Toohill wrote:
> This preserves changes to fields of AVCodecParameters that
> get updated during encoding, such as trailing_padding
> (which may not be known until encoding is complete).
> ---
>  ffmpeg.c | 15 +++
>  1 file changed, 15 insertions(+)

this breaks 165 fate tests

[...]
-- 
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] avformat/framehash: print channel layout as a string instead of a hex value

[James Almer]

On 9/28/2016 8:26 PM, Michael Niedermayer wrote:
> On Wed, Sep 28, 2016 at 08:18:20PM -0300, James Almer wrote:
>> On 9/28/2016 8:09 PM, James Almer wrote:
>>> On 9/28/2016 7:35 PM, Michael Niedermayer wrote:
 On Wed, Sep 28, 2016 at 07:23:37PM -0300, James Almer wrote:
> Numerical values for channel layout can be confusing and unintuitive, 
> especially
> when no channel count is printed.

 doesnt this break the format in libavformat/hashenc.c
 for format_version=2 ?
>>>
>>> Yeah, it would break both versions 1 and 2, assuming anything tries to
>>> parse the hex value for some purpose, as both are expected to have it.
>>> And for that matter it would also break parsing framecrc in a similar
>>> fashion.
>>
>> Then again, framecrc doesn't report any kind of version, so a standardized
>> output shouldn't be expected.
>>
>> Ok if i make this version 3 for framehash/framemd5 then? I can also keep
>> the hex value, so something like
>>
>> #channel_layout 0: 0x3 (stereo)
>>
>> would be printed.
> 
> maybe a
>  #channel_layout 0: 0x3
> +#channel_layout_name 0: stereo
> 
> would be within the existing version syntax

Ok, sounds good.

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

Re: [FFmpeg-devel] [PATCH] avformat/framehash: print channel layout as a string instead of a hex value

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 08:18:20PM -0300, James Almer wrote:
> On 9/28/2016 8:09 PM, James Almer wrote:
> > On 9/28/2016 7:35 PM, Michael Niedermayer wrote:
> >> On Wed, Sep 28, 2016 at 07:23:37PM -0300, James Almer wrote:
> >>> Numerical values for channel layout can be confusing and unintuitive, 
> >>> especially
> >>> when no channel count is printed.
> >>
> >> doesnt this break the format in libavformat/hashenc.c
> >> for format_version=2 ?
> > 
> > Yeah, it would break both versions 1 and 2, assuming anything tries to
> > parse the hex value for some purpose, as both are expected to have it.
> > And for that matter it would also break parsing framecrc in a similar
> > fashion.
> 
> Then again, framecrc doesn't report any kind of version, so a standardized
> output shouldn't be expected.
> 
> Ok if i make this version 3 for framehash/framemd5 then? I can also keep
> the hex value, so something like
> 
> #channel_layout 0: 0x3 (stereo)
> 
> would be printed.

maybe a
 #channel_layout 0: 0x3
+#channel_layout_name 0: stereo

would be within the existing version syntax


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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

Re: [FFmpeg-devel] [PATCH] ffmpeg_vaapi: fix choice of decoder_format

[Michael Niedermayer]

On Tue, Sep 27, 2016 at 11:25:49PM +0100, Mark Thompson wrote:
> On 27/09/16 14:23, Moritz Barsnick wrote:
> > The check could previously never evaluate to true, probably due to
> > a typo.
> >
> > Reported-By: Mihai Chindea 
> > Signed-off-by: Moritz Barsnick 
> > ---
> > As discovered and suggested by Mihai Chindea,
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/198932.html
> >
> > I have only inspected/reviewed this change visually, not tested.
> >
> > Moritz
> >
> >  ffmpeg_vaapi.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/ffmpeg_vaapi.c b/ffmpeg_vaapi.c
> > index 8090597..f1e7c76 100644
> > --- a/ffmpeg_vaapi.c
> > +++ b/ffmpeg_vaapi.c
> > @@ -302,7 +302,7 @@ static int 
> > vaapi_build_decoder_config(VAAPIDecoderContext *ctx,
> >  if (ctx->output_format != AV_PIX_FMT_NONE &&
> >  ctx->output_format != AV_PIX_FMT_VAAPI) {
> >  for (i = 0; constraints->valid_sw_formats[i] != AV_PIX_FMT_NONE; 
> > i++) {
> > -if (constraints->valid_sw_formats[i] == ctx->decode_format) {
> > +if (constraints->valid_sw_formats[i] == ctx->output_format) {
> >  ctx->decode_format = ctx->output_format;
> >  av_log(ctx, AV_LOG_DEBUG, "Using decode format %s (output "
> > "format).\n", 
> > av_get_pix_fmt_name(ctx->decode_format));
> > --
> > 2.7.4
> 
> Yeah, that was what was intended there.  Tested and fine with the i965 
> driver: I don't have any case where it will actually change the behaviour, 
> but it does change the log message.

applied

thx

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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/2] movenc: Add support for writing language codes into ISML manifests

[Josh de Kock]

On 26/09/2016 23:10, Jan Ekström wrote:

Streaming servers appear to ignore all other language metadata.

Signed-off-by: Jan Ekström 
---
 libavformat/movenc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index d5ed1dd..28edb18 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3611,6 +3611,9 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 const char *type;
 int track_id = track->track_id;

+AVStream *st = track->st;
+AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", 
NULL,0);
+
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 type = "video";
 } else if (track->par->codec_type == AVMEDIA_TYPE_AUDIO) {
@@ -3630,6 +3633,7 @@ static int mov_write_isml_manifest(AVIOContext *pb, 
MOVMuxContext *mov, AVFormat
 (int64_t)manifest_bit_rate);
 param_write_int(pb, "systemBitrate", manifest_bit_rate);
 param_write_int(pb, "trackID", track_id);
+param_write_string(pb, "systemLanguage", lang ? lang->value : "und");
 if (track->par->codec_type == AVMEDIA_TYPE_VIDEO) {
 if (track->par->codec_id == AV_CODEC_ID_H264) {
 uint8_t *ptr;



LGTM. Will push tomorrow if no further comments.

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Mark Thompson]

On 28/09/16 23:30, Chao Liu wrote:
> On Wed, Sep 28, 2016 at 3:23 PM, Mark Thompson  wrote:
> 
>> On 28/09/16 22:57, Chao Liu wrote:
>>> BTW, is there any plan to support VP8 with vaapi hwaccel?
>>
>> No plan; already done: > a9fb134730da1f9642eb5a2baa50943b8a4aa245>.
>>
> Cool. Thanks!
> What about VP8 encoder?

Do go ahead.  I don't have any current plans to do it and I don't know of 
anyone else who would, so you wouldn't be conflicting with anyone.

Thanks,

- Mark

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

Re: [FFmpeg-devel] [PATCH] avformat/framehash: print channel layout as a string instead of a hex value

[James Almer]

On 9/28/2016 8:09 PM, James Almer wrote:
> On 9/28/2016 7:35 PM, Michael Niedermayer wrote:
>> On Wed, Sep 28, 2016 at 07:23:37PM -0300, James Almer wrote:
>>> Numerical values for channel layout can be confusing and unintuitive, 
>>> especially
>>> when no channel count is printed.
>>
>> doesnt this break the format in libavformat/hashenc.c
>> for format_version=2 ?
> 
> Yeah, it would break both versions 1 and 2, assuming anything tries to
> parse the hex value for some purpose, as both are expected to have it.
> And for that matter it would also break parsing framecrc in a similar
> fashion.

Then again, framecrc doesn't report any kind of version, so a standardized
output shouldn't be expected.

Ok if i make this version 3 for framehash/framemd5 then? I can also keep
the hex value, so something like

#channel_layout 0: 0x3 (stereo)

would be printed.

> 
> This can be solved with a new version 3. But that only covers the
> muxers framehash and framemd5, and not framecrc as used by most fate
> tests, which also calls ff_framehash_write_header(), the function that
> prints this line.
> 
> What would be the best course of action here?
> 

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

Re: [FFmpeg-devel] [PATCH] avformat/framehash: print channel layout as a string instead of a hex value

[James Almer]

On 9/28/2016 7:35 PM, Michael Niedermayer wrote:
> On Wed, Sep 28, 2016 at 07:23:37PM -0300, James Almer wrote:
>> Numerical values for channel layout can be confusing and unintuitive, 
>> especially
>> when no channel count is printed.
> 
> doesnt this break the format in libavformat/hashenc.c
> for format_version=2 ?

Yeah, it would break both versions 1 and 2, assuming anything tries to
parse the hex value for some purpose, as both are expected to have it.
And for that matter it would also break parsing framecrc in a similar
fashion.

This can be solved with a new version 3. But that only covers the
muxers framehash and framemd5, and not framecrc as used by most fate
tests, which also calls ff_framehash_write_header(), the function that
prints this line.

What would be the best course of action here?

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

[FFmpeg-devel] [PATCH 1/2] avformat/tee: Copy interrupt callback and flags to slave

[sebechlebskyjan]

From: Jan Sebechlebsky 

Copy interrupt callback to slave format context to allow
user to interrupt IO. Copy format flags as well.

Signed-off-by: Jan Sebechlebsky 
---
 libavformat/tee.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/tee.c b/libavformat/tee.c
index 518af4a..d59ad4d 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -161,6 +161,8 @@ static int open_slave(AVFormatContext *avf, char *slave, 
TeeSlave *tee_slave)
 avf2->opaque   = avf->opaque;
 avf2->io_open  = avf->io_open;
 avf2->io_close = avf->io_close;
+avf2->interrupt_callback = avf->interrupt_callback;
+avf2->flags = avf->flags;
 
 tee_slave->stream_map = av_calloc(avf->nb_streams, 
sizeof(*tee_slave->stream_map));
 if (!tee_slave->stream_map) {
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Lou Logan]

On Wed, 28 Sep 2016 18:15:37 +0800, Steven Liu wrote:

> From c919c381aa1a580a71f23923a567dff1c873cfd5 Mon Sep 17 00:00:00 2001
> From: Steven Liu 
> Date: Wed, 28 Sep 2016 18:12:38 +0800
> Subject: [PATCH] doc/muxers: fix hlsenc options examples error
> 
> Signed-off-by: Steven Liu 
> ---
>  doc/muxers.texi | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

LGTM and pushed.

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

[FFmpeg-devel] [PATCH 2/2] avformat/tee: Add FATE tests for tee

[sebechlebskyjan]

From: Jan Sebechlebsky 

This commit also adds new diff option for fate tests allowing do compare
multiple tuples of files.

Signed-off-by: Jan Sebechlebsky 
---
 tests/Makefile|  1 +
 tests/fate-run.sh |  7 
 tests/fate/tee-muxer.mak  | 22 ++
 tests/ref/fate/tee-muxer-h264 |  2 +
 tests/ref/fate/tee-muxer-h264-audio   | 30 +
 tests/ref/fate/tee-muxer-h264-copy| 47 +
 tests/ref/fate/tee-muxer-ignorefail   | 79 +++
 tests/ref/fate/tee-muxer-tstsrc   |  2 +
 tests/ref/fate/tee-muxer-tstsrc-audio | 49 ++
 9 files changed, 239 insertions(+)
 create mode 100644 tests/fate/tee-muxer.mak
 create mode 100644 tests/ref/fate/tee-muxer-h264
 create mode 100644 tests/ref/fate/tee-muxer-h264-audio
 create mode 100644 tests/ref/fate/tee-muxer-h264-copy
 create mode 100644 tests/ref/fate/tee-muxer-ignorefail
 create mode 100644 tests/ref/fate/tee-muxer-tstsrc
 create mode 100644 tests/ref/fate/tee-muxer-tstsrc-audio

diff --git a/tests/Makefile b/tests/Makefile
index 8e810ff..e23260f 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -164,6 +164,7 @@ include $(SRC_PATH)/tests/fate/real.mak
 include $(SRC_PATH)/tests/fate/screen.mak
 include $(SRC_PATH)/tests/fate/source.mak
 include $(SRC_PATH)/tests/fate/subtitles.mak
+include $(SRC_PATH)/tests/fate/tee-muxer.mak
 include $(SRC_PATH)/tests/fate/utvideo.mak
 include $(SRC_PATH)/tests/fate/video.mak
 include $(SRC_PATH)/tests/fate/voice.mak
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c640cc5..9c90ea5 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -73,6 +73,12 @@ oneline(){
 printf '%s\n' "$1" | diff -u -b - "$2"
 }
 
+multidiff(){
+while read -r ref_file out_file; do
+diff -u -b "${base}/ref/fate/${ref_file}" "${outdir}/${out_file}" || 
return $?
+done <"$1"
+}
+
 run(){
 test "${V:-0}" -gt 0 && echo "$target_exec" $target_path/"$@" >&3
 $target_exec $target_path/"$@"
@@ -350,6 +356,7 @@ if test -e "$ref" || test $cmp = "oneline" || test $cmp = 
"grep" ; then
 case $cmp in
 diff)   diff -u -b "$ref" "$outfile">$cmpfile ;;
 rawdiff)diff -u"$ref" "$outfile">$cmpfile ;;
+mdiff)  multidiff  "$ref"   >$cmpfile ;;
 oneoff) oneoff "$ref" "$outfile">$cmpfile ;;
 stddev) stddev "$ref" "$outfile">$cmpfile ;;
 oneline)oneline"$ref" "$outfile">$cmpfile ;;
diff --git a/tests/fate/tee-muxer.mak b/tests/fate/tee-muxer.mak
new file mode 100644
index 000..b760ea1
--- /dev/null
+++ b/tests/fate/tee-muxer.mak
@@ -0,0 +1,22 @@
+fate-tee-muxer-h264: CMD = ffmpeg -i $(TARGET_SAMPLES)/mkv/1242-small.mkv 
-vframes 11\
+   -c:v copy -c:a copy -map v:0 -map a:0 -flags 
+bitexact\
+   -fflags +bitexact -fflags +bitexact -f tee\
+  
"[f=framecrc]$(SRC_PATH)/tests/data/fate/tee-muxer-h264-copy|[f=framecrc:select=1]$(SRC_PATH)/tests/data/fate/tee-muxer-h264-audio"
+fate-tee-muxer-h264: CMP = mdiff
+FATE-SAMPLES-TEE-MUXER-$(call ALLYES, TEE_MUXER, MATROSKA_DEMUXER, 
H264_DECODER) += fate-tee-muxer-h264
+
+fate-tee-muxer-ignorefail: CMD = ./ffmpeg  -f lavfi -i "testsrc=s=640x480" -f 
lavfi -i "sine"\
+-t 1 -map 0:v -map 1:a -c:v copy -c:a copy 
-flags +bitexact -fflags +bitexact -f tee\
+
"[f=framecrc]$(SRC_PATH)/tests/data/fate/tee-muxer-ignorefail|[f=framecrc:onfail=ignore]$(SRC_PATH)/dev/full"
+FATE-TEE-MUXER-$(CONFIG_TEE_MUXER) += fate-tee-muxer-ignorefail
+
+fate-tee-muxer-tstsrc: CMD = ./ffmpeg  -f lavfi -i "testsrc=s=640x480" -f 
lavfi -i "sine"\
+ -t 1 -map 0:v -map 1:a -c:v copy -c:a copy -flags 
+bitexact -fflags +bitexact -f tee\
+
"[f=framecrc]$(SRC_PATH)/tests/data/fate/tee-muxer-tstsrc-copy|[f=framecrc:select=1]$(SRC_PATH)/tests/data/fate/tee-muxer-tstsrc-audio"
+fate-tee-muxer-tstsrc: CMP = mdiff
+FATE-TEE-MUXER-$(CONFIG_TEE_MUXER) += fate-tee-muxer-tstsrc
+
+FATE_SAMPLES_FFMPEG += $(FATE-SAMPLES-TEE-MUXER-yes)
+FATE_FFMPEG += $(FATE-TEE-MUXER-yes)
+
+fate-tee-muxer: $(FATE-TEE-MUXER-yes) $(FATE-SAMPLES-TEE-MUXER-yes)
diff --git a/tests/ref/fate/tee-muxer-h264 b/tests/ref/fate/tee-muxer-h264
new file mode 100644
index 000..2a99a6b
--- /dev/null
+++ b/tests/ref/fate/tee-muxer-h264
@@ -0,0 +1,2 @@
+tee-muxer-h264-copy  tee-muxer-h264-copy
+tee-muxer-h264-audio tee-muxer-h264-audio
\ No newline at end of file
diff --git a/tests/ref/fate/tee-muxer-h264-audio 
b/tests/ref/fate/tee-muxer-h264-audio
new file mode 100644
index 000..0b42d11
--- /dev/null
+++ b/tests/ref/fate/tee-muxer-h264-audio
@@ -0,0 +1,30 @@
+#extradata 0:2, 0x00b200a1
+#tb 0: 1/1000
+#media_type 0: 

Re: [FFmpeg-devel] [PATCH] avformat/framehash: print channel layout as a string instead of a hex value

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 07:23:37PM -0300, James Almer wrote:
> Numerical values for channel layout can be confusing and unintuitive, 
> especially
> when no channel count is printed.

doesnt this break the format in libavformat/hashenc.c
for format_version=2 ?



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

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


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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Wed, Sep 28, 2016 at 3:23 PM, Mark Thompson  wrote:

> On 28/09/16 22:57, Chao Liu wrote:
> > BTW, is there any plan to support VP8 with vaapi hwaccel?
>
> No plan; already done:  a9fb134730da1f9642eb5a2baa50943b8a4aa245>.
>
Cool. Thanks!
What about VP8 encoder?

>
> (Depends on the changed decode infrastructure though, so it won't
> cherry-pick easily.)


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

Re: [FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color related options doxigen

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 05:15:43PM -0300, James Almer wrote:
> Found-by: Michael Niedermayer 
> Signed-off-by: James Almer 
> ---
>  doc/codecs.texi | 73 
> +
>  1 file changed, 63 insertions(+), 10 deletions(-)

without checking this line by line, it does look ok

thanks

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

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


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

[FFmpeg-devel] [PATCH] avformat/framehash: print channel layout as a string instead of a hex value

[James Almer]

Numerical values for channel layout can be confusing and unintuitive, especially
when no channel count is printed.

Signed-off-by: James Almer 
---
 libavformat/framehash.c |  5 -
 tests/ref/fate/8bps |  2 +-
 tests/ref/fate/adpcm-4xm|  2 +-
 tests/ref/fate/adpcm-afc|  2 +-
 tests/ref/fate/adpcm-dtk|  2 +-
 tests/ref/fate/adpcm-ea-1   |  2 +-
 tests/ref/fate/adpcm-ea-2   |  2 +-
 tests/ref/fate/adpcm-ea-maxis-xa|  2 +-
 tests/ref/fate/adpcm-ea-r1  |  2 +-
 tests/ref/fate/adpcm-ima-amv|  2 +-
 tests/ref/fate/adpcm-ima-ea-eacs|  2 +-
 tests/ref/fate/adpcm-ima-ea-sead|  2 +-
 tests/ref/fate/adpcm-ima-smjpeg |  2 +-
 tests/ref/fate/adpcm-ima-ws |  2 +-
 tests/ref/fate/adpcm-ms-mono|  2 +-
 tests/ref/fate/adpcm-thp|  2 +-
 tests/ref/fate/adpcm-vima   |  2 +-
 tests/ref/fate/adpcm-xa |  2 +-
 tests/ref/fate/adtstoasc_ticket3715 |  2 +-
 tests/ref/fate/armovie-escape124|  2 +-
 tests/ref/fate/bethsoft-vid |  2 +-
 tests/ref/fate/bfi  |  2 +-
 tests/ref/fate/bmv-audio|  2 +-
 tests/ref/fate/cdxl-demux   |  2 +-
 tests/ref/fate/copy-trac236 |  2 +-
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/copy-trac4914-avi|  2 +-
 tests/ref/fate/corepng  |  2 +-
 tests/ref/fate/creatureshock-avs|  2 +-
 tests/ref/fate/cyberia-c93  |  2 +-
 tests/ref/fate/d-cinema-demux   |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_0  |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_2   |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_0-dmix_6   |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_1  |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_2   |  2 +-
 tests/ref/fate/dca-xll_51_16_192_768_1-dmix_6   |  2 +-
 tests/ref/fate/dca-xll_51_24_48_768 |  2 +-
 tests/ref/fate/dca-xll_51_24_48_768-dmix_2  |  2 +-
 tests/ref/fate/dca-xll_51_24_48_768-dmix_6  |  2 +-
 tests/ref/fate/dca-xll_51_24_48_none|  2 +-
 tests/ref/fate/dca-xll_51_24_48_none-dmix_2 |  2 +-
 tests/ref/fate/dca-xll_51_24_48_none-dmix_6 |  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_0   |  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_2|  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_0-dmix_6|  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_1   |  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_2|  2 +-
 tests/ref/fate/dca-xll_71_24_48_768_1-dmix_6|  2 +-
 tests/ref/fate/dca-xll_71_24_96_768 |  2 +-
 tests/ref/fate/dca-xll_71_24_96_768-dmix_2  |  2 +-
 tests/ref/fate/dca-xll_71_24_96_768-dmix_6  |  2 +-
 tests/ref/fate/dca-xll_x96_51_24_96_1509|  2 +-
 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_2 |  2 +-
 tests/ref/fate/dca-xll_x96_51_24_96_1509-dmix_6 |  2 +-
 tests/ref/fate/dca-xll_xch_61_24_48_768 |  2 +-
 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_2  |  2 +-
 tests/ref/fate/dca-xll_xch_61_24_48_768-dmix_6  |  2 +-
 tests/ref/fate/dcinema-encode   |  2 +-
 tests/ref/fate/delphine-cin-audio   |  2 +-
 tests/ref/fate/dpcm-idroq   |  2 +-
 tests/ref/fate/dpcm-interplay   |  2 +-
 tests/ref/fate/dss-lp   |  2 +-
 tests/ref/fate/dss-sp   |  2 +-
 tests/ref/fate/ffmpeg-filter_colorkey   |  2 +-
 tests/ref/fate/filter-acrossfade|  2 +-
 tests/ref/fate/filter-adelay|  2 +-
 tests/ref/fate/filter-aecho |  2 +-
 tests/ref/fate/filter-aemphasis-50fm|  2 +-
 tests/ref/fate/filter-aemphasis-75kf|  2 +-
 tests/ref/fate/filter-afade-esin|  2 +-
 tests/ref/fate/filter-afade-exp |  2 +-
 tests/ref/fate/filter-afade-hsin|  2 +-
 tests/ref/fate/filter-afade-iqsin   |  2 +-
 tests/ref/fate/filter-afade-log |  2 +-
 tests/ref/fate/filter-afade-qsin|  2 +-
 tests/ref/fate/filter-agate |  2 +-
 tests/ref/fate/filter-alimiter  |  2 +-
 tests/ref/fate/filter-amerge|  2 +-
 tests/ref/fate/filter-anequalizer   |  2 +-
 tests/ref/fate/filter-apad  |  2 +-
 tests/ref/fate/filter-asetnsamples  |  2 +-
 tests/ref/fate/filter-asetrate  |  2 +-
 tests/ref/fate/filter-atrim-duration|  2 +-
 tests/ref/fate/filter-atrim-mixed   

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Mark Thompson]

On 28/09/16 22:57, Chao Liu wrote:
> BTW, is there any plan to support VP8 with vaapi hwaccel?

No plan; already done: 
.

(Depends on the changed decode infrastructure though, so it won't cherry-pick 
easily.)

- Mark

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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[wm4]

On Wed, 28 Sep 2016 14:57:50 -0700
Chao Liu  wrote:

> On Wed, Sep 28, 2016 at 2:45 PM, wm4  wrote:
> 
> > On Wed, 28 Sep 2016 12:18:38 -0700
> > Chao Liu  wrote:
> >  
> > > On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> > >  
> > > > On Sat, 24 Sep 2016 02:34:56 +0200
> > > > Michael Niedermayer  wrote:
> > > >  
> > > > > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:  
> > > > > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > > > > please refer to the link: https://github.com/01org/  
> > > > ffmpeg_libyami/wiki/Build  
> > > > >  
> > > > > >  Makefile   |1
> > > > > >  configure  |   27 ++
> > > > > >  ffmpeg.c   |4
> > > > > >  ffmpeg.h   |1
> > > > > >  ffmpeg_libyami.c   |   85 ++
> > > > > >  libavcodec/Makefile|8
> > > > > >  libavcodec/allcodecs.c |6
> > > > > >  libavcodec/libyami.cpp |  429 ++  
> > +  
> > > > > >  libavcodec/libyami.h   |   59 
> > > > > >  libavcodec/libyami_dec.cpp |  527 ++  
> > > > +  
> > > > > >  libavcodec/libyami_dec.h   |   56 
> > > > > >  libavcodec/libyami_enc.cpp |  551 ++  
> > > > +++  
> > > > > >  libavcodec/libyami_enc.h   |   70 +
> > > > > >  libavutil/pixdesc.c|4
> > > > > >  libavutil/pixfmt.h |5
> > > > > >  15 files changed, 1833 insertions(+)
> > > > > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5  
> > 0001-lavc-yami-add-libyami-  
> > > > decoder-encoder.patch  
> > > > > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00  
> > 2001  
> > > > > > From: Jun Zhao 
> > > > > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > > > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.  
> > > > >
> > > > > it seems people are not in favor of this patchset, judging from this
> > > > > thread.
> > > > > If you are interrested in maintaining this code externally as a patch
> > > > > or git repository, then please add some reasonable link/mention to
> > > > > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > > > > existence and can find it
> > > > >
> > > > > If you belive thats incorret and people in fact majorly support this
> > > > > patchset then you can also start a vote of course.
> > > > >
> > > > > ill mark this patchset as rejected on patchwork as that seems the
> > > > > de-facto current situation
> > > > >  
> > > >
> > > > From one person who tried to use it (and who's also in the list), I
> > > > heard that ffmpeg native vaapi decoding/encoding works better for him.
> > > >  
> > > I don't know how he made that conclusion. Maybe he only uses the command
> > > line?
> > > We are building a product using ffmpeg C interface. For me, hwaccel is  
> > way  
> > > too complicated to use. IIUC, I have to copy thousand lines of code from
> > > ffmpeg_*.c to use it ...  
> >
> > Much less with the latest Libav changes once they're merged in FFmpeg.
> > Only at most 200 lines (all pretty trivial glue code, much of that
> > just to hook it up to ffmpeg.c-specifics). The new code will remove the
> > requirement to manually create the VAAPI context in the decoding case.
> >  
> Oh, that's great! When do you think it'll be ready? Cannot wait to give it
> a try!

Merging is hard work, and last I heard we were 300 commits behind, so
probably a while.

Until then, you can see it here:
https://git.libav.org/?p=libav.git;a=blob;f=avconv_vaapi.c

> BTW, is there any plan to support VP8 with vaapi hwaccel?

ffmpeg_vaapi.c seems to have some vp8 support (and the recent Libav
rework keeps that), no idea if it works.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] compat/avisynth: minor update for alpha offsets

[Michael Niedermayer]

On Tue, Sep 27, 2016 at 10:07:20PM -0400, Stephen Hutchinson wrote:
> On 9/27/2016 4:11 PM, Michael Niedermayer wrote:
> >can you update the status for the patch(es) on
> >https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=49
> >?
> >
> >so developers know what needs a review, needs to be applied and what
> >is on hold/revovked, ...
> >
> >thx
> >
> 
> Done.  I think I did it right, hopefully.

thx

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

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


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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Wed, Sep 28, 2016 at 2:45 PM, wm4  wrote:

> On Wed, 28 Sep 2016 12:18:38 -0700
> Chao Liu  wrote:
>
> > On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> >
> > > On Sat, 24 Sep 2016 02:34:56 +0200
> > > Michael Niedermayer  wrote:
> > >
> > > > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:
> > > > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > > > please refer to the link: https://github.com/01org/
> > > ffmpeg_libyami/wiki/Build
> > > >
> > > > >  Makefile   |1
> > > > >  configure  |   27 ++
> > > > >  ffmpeg.c   |4
> > > > >  ffmpeg.h   |1
> > > > >  ffmpeg_libyami.c   |   85 ++
> > > > >  libavcodec/Makefile|8
> > > > >  libavcodec/allcodecs.c |6
> > > > >  libavcodec/libyami.cpp |  429 ++
> +
> > > > >  libavcodec/libyami.h   |   59 
> > > > >  libavcodec/libyami_dec.cpp |  527 ++
> > > +
> > > > >  libavcodec/libyami_dec.h   |   56 
> > > > >  libavcodec/libyami_enc.cpp |  551 ++
> > > +++
> > > > >  libavcodec/libyami_enc.h   |   70 +
> > > > >  libavutil/pixdesc.c|4
> > > > >  libavutil/pixfmt.h |5
> > > > >  15 files changed, 1833 insertions(+)
> > > > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5
> 0001-lavc-yami-add-libyami-
> > > decoder-encoder.patch
> > > > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00
> 2001
> > > > > From: Jun Zhao 
> > > > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.
> > > >
> > > > it seems people are not in favor of this patchset, judging from this
> > > > thread.
> > > > If you are interrested in maintaining this code externally as a patch
> > > > or git repository, then please add some reasonable link/mention to
> > > > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > > > existence and can find it
> > > >
> > > > If you belive thats incorret and people in fact majorly support this
> > > > patchset then you can also start a vote of course.
> > > >
> > > > ill mark this patchset as rejected on patchwork as that seems the
> > > > de-facto current situation
> > > >
> > >
> > > From one person who tried to use it (and who's also in the list), I
> > > heard that ffmpeg native vaapi decoding/encoding works better for him.
> > >
> > I don't know how he made that conclusion. Maybe he only uses the command
> > line?
> > We are building a product using ffmpeg C interface. For me, hwaccel is
> way
> > too complicated to use. IIUC, I have to copy thousand lines of code from
> > ffmpeg_*.c to use it ...
>
> Much less with the latest Libav changes once they're merged in FFmpeg.
> Only at most 200 lines (all pretty trivial glue code, much of that
> just to hook it up to ffmpeg.c-specifics). The new code will remove the
> requirement to manually create the VAAPI context in the decoding case.
>
Oh, that's great! When do you think it'll be ready? Cannot wait to give it
a try!

>
> Since libyami requires usinf weird libyami-specific buffers instead of
> vaapi surfaces, it's unlikely that libyami could profit from further
> developments, such as vaapi filters within libavfilter. Unless someone
> changes the libyami wrapper to input/output native vaapi surfaces.
>
> Also, there were issues that were never fixed in the libyami wrapper.
>
> > With this patch, it's trivial to switch between codecs like qsv_h264,
> > libyami_h264, libyami_vp8.
> >
> > We have been trying different hardware acceleration solutions in our
> > product. So far, QSV works best for us.
> > However, QSV itself has a lot of problems, like too much work to use it
> > under Linux, quite a few critical bugs, no support for VP8.
> > Even worse, it only supports latest CPUs. We cannot use it in production
> > because we don't know when they'll stop supporting our hardware, which'll
> > leave us no option.
> >
> > So far, libyami looks like the best options for people like us. If you
> guys
> > in the end reject this patch, we'll have to patch it ourselves. That'll
> be
> > awful. I hope we won't need to do that..
>
> So it's better if _we_ have to maintain code that is redundant to our
> "proper" APIs, and that has a bunch of issues the patch submitters
> don't want to fix? Sounds wrong to me.
>
I didn't know the unfixed issues of libyami, which you mentioned above.
I agree that if you could make hwaccels easy to use, this patch is not very
useful.
BTW, is there any plan to support VP8 with vaapi hwaccel?

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

Re: [FFmpeg-devel] [PATCH 1/2 v2] movenc: use similar logic to DASH when writing bit rate to ISML

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 05:55:02PM +0200, Carl Eugen Hoyos wrote:
> 2016-09-28 1:14 GMT+02:00 Jan Ekström :
> > This way, in case of bit rate not being set, max_bitrate will be
> > used instead.
> 
> Makes sense to me but I'd prefer if somebody else (looks
> again and) applies.

applied

thx

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

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


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/5] lavc : yami : add libyami decoder/encoder

[wm4]

On Wed, 28 Sep 2016 12:18:38 -0700
Chao Liu  wrote:

> On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:
> 
> > On Sat, 24 Sep 2016 02:34:56 +0200
> > Michael Niedermayer  wrote:
> >  
> > > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:  
> > > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > > please refer to the link: https://github.com/01org/  
> > ffmpeg_libyami/wiki/Build  
> > >  
> > > >  Makefile   |1
> > > >  configure  |   27 ++
> > > >  ffmpeg.c   |4
> > > >  ffmpeg.h   |1
> > > >  ffmpeg_libyami.c   |   85 ++
> > > >  libavcodec/Makefile|8
> > > >  libavcodec/allcodecs.c |6
> > > >  libavcodec/libyami.cpp |  429 +++
> > > >  libavcodec/libyami.h   |   59 
> > > >  libavcodec/libyami_dec.cpp |  527 ++  
> > +  
> > > >  libavcodec/libyami_dec.h   |   56 
> > > >  libavcodec/libyami_enc.cpp |  551 ++  
> > +++  
> > > >  libavcodec/libyami_enc.h   |   70 +
> > > >  libavutil/pixdesc.c|4
> > > >  libavutil/pixfmt.h |5
> > > >  15 files changed, 1833 insertions(+)
> > > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5  0001-lavc-yami-add-libyami-  
> > decoder-encoder.patch  
> > > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00 2001
> > > > From: Jun Zhao 
> > > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.  
> > >
> > > it seems people are not in favor of this patchset, judging from this
> > > thread.
> > > If you are interrested in maintaining this code externally as a patch
> > > or git repository, then please add some reasonable link/mention to
> > > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > > existence and can find it
> > >
> > > If you belive thats incorret and people in fact majorly support this
> > > patchset then you can also start a vote of course.
> > >
> > > ill mark this patchset as rejected on patchwork as that seems the
> > > de-facto current situation
> > >  
> >
> > From one person who tried to use it (and who's also in the list), I
> > heard that ffmpeg native vaapi decoding/encoding works better for him.
> >  
> I don't know how he made that conclusion. Maybe he only uses the command
> line?
> We are building a product using ffmpeg C interface. For me, hwaccel is way
> too complicated to use. IIUC, I have to copy thousand lines of code from
> ffmpeg_*.c to use it ...

Much less with the latest Libav changes once they're merged in FFmpeg.
Only at most 200 lines (all pretty trivial glue code, much of that
just to hook it up to ffmpeg.c-specifics). The new code will remove the
requirement to manually create the VAAPI context in the decoding case.

Since libyami requires usinf weird libyami-specific buffers instead of
vaapi surfaces, it's unlikely that libyami could profit from further
developments, such as vaapi filters within libavfilter. Unless someone
changes the libyami wrapper to input/output native vaapi surfaces.

Also, there were issues that were never fixed in the libyami wrapper.

> With this patch, it's trivial to switch between codecs like qsv_h264,
> libyami_h264, libyami_vp8.
> 
> We have been trying different hardware acceleration solutions in our
> product. So far, QSV works best for us.
> However, QSV itself has a lot of problems, like too much work to use it
> under Linux, quite a few critical bugs, no support for VP8.
> Even worse, it only supports latest CPUs. We cannot use it in production
> because we don't know when they'll stop supporting our hardware, which'll
> leave us no option.
> 
> So far, libyami looks like the best options for people like us. If you guys
> in the end reject this patch, we'll have to patch it ourselves. That'll be
> awful. I hope we won't need to do that..

So it's better if _we_ have to maintain code that is redundant to our
"proper" APIs, and that has a bunch of issues the patch submitters
don't want to fix? Sounds wrong to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_colorspace: fix range for output colorspace option

[James Almer]

On 9/28/2016 5:26 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/vf_colorspace.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
> index c74fe00..5b060f9 100644
> --- a/libavfilter/vf_colorspace.c
> +++ b/libavfilter/vf_colorspace.c
> @@ -1031,7 +1031,7 @@ static const AVOption colorspace_options[] = {
>  
>  { "space",  "Output colorspace",
>OFFSET(user_csp),   AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED },
> -  AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" },
> +  AVCOL_SPC_RGB, AVCOL_SPC_NB - 1, FLAGS,  "csp"},
>  ENUM("bt709",   AVCOL_SPC_BT709,   "csp"),
>  ENUM("fcc", AVCOL_SPC_FCC, "csp"),
>  ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"),

Approved by Ronald on IRC and pushed.

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

Re: [FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color related options doxigen

[James Almer]

On 9/28/2016 5:23 PM, Moritz Barsnick wrote:
>> Subject: [FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color 
>> related options doxigen
> 
> This isn't doxygen (which you didn't spell correctly ;-)), but
> texinfo. You can just drop the last word.
> 
> Moritz

Oops. Fixed locally, thanks :p

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

[FFmpeg-devel] [PATCH] avfilter/vf_colorspace: fix range for output colorspace option

[James Almer]

Signed-off-by: James Almer 
---
 libavfilter/vf_colorspace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index c74fe00..5b060f9 100644
--- a/libavfilter/vf_colorspace.c
+++ b/libavfilter/vf_colorspace.c
@@ -1031,7 +1031,7 @@ static const AVOption colorspace_options[] = {
 
 { "space",  "Output colorspace",
   OFFSET(user_csp),   AV_OPT_TYPE_INT, { .i64 = AVCOL_SPC_UNSPECIFIED },
-  AVCOL_PRI_RESERVED0, AVCOL_PRI_NB - 1, FLAGS, "csp" },
+  AVCOL_SPC_RGB, AVCOL_SPC_NB - 1, FLAGS,  "csp"},
 ENUM("bt709",   AVCOL_SPC_BT709,   "csp"),
 ENUM("fcc", AVCOL_SPC_FCC, "csp"),
 ENUM("bt470bg", AVCOL_SPC_BT470BG, "csp"),
-- 
2.9.1

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

Re: [FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color related options doxigen

[Moritz Barsnick]

> Subject: [FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color related 
> options doxigen

This isn't doxygen (which you didn't spell correctly ;-)), but
texinfo. You can just drop the last word.

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

[FFmpeg-devel] [PATCH] doc/codecs.texi: fix and expand color related options doxigen

[James Almer]

Found-by: Michael Niedermayer 
Signed-off-by: James Almer 
---
 doc/codecs.texi | 73 +
 1 file changed, 63 insertions(+), 10 deletions(-)

diff --git a/doc/codecs.texi b/doc/codecs.texi
index 48fc3bf..913e257 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -1049,7 +1049,31 @@ Possible values:
 @item rc_max_vbv_use @var{float} (@emph{encoding,video})
 @item rc_min_vbv_use @var{float} (@emph{encoding,video})
 @item ticks_per_frame @var{integer} (@emph{decoding/encoding,audio,video})
+
 @item color_primaries @var{integer} (@emph{decoding/encoding,video})
+Possible values:
+@table @samp
+@item bt709
+BT.709
+@item bt470m
+BT.470 M
+@item bt470bg
+BT.470 BG
+@item smpte170m
+SMPTE 170 M
+@item smpte240m
+SMPTE 240 M
+@item film
+Film
+@item bt2020
+BT.2020
+@item smpte428_1
+SMPTE ST 428-1
+@item smpte431
+SMPTE 431-2
+@item smpte432
+SMPTE 432-1
+@end table
 
 @item color_trc @var{integer} (@emph{decoding/encoding,video})
 Possible values:
@@ -1060,29 +1084,58 @@ BT.709
 BT.470 M
 @item gamma28
 BT.470 BG
-@item linear
+@item smpte170m
 SMPTE 170 M
-@item log
+@item smpte240m
 SMPTE 240 M
-@item log_sqrt
+@item linear
 Linear
-@item iec61966_2_4
+@item log
 Log
-@item bt1361
+@item log_sqrt
 Log square root
-@item iec61966_2_1
+@item iec61966_2_4
 IEC 61966-2-4
-@item bt2020_10bit
+@item bt1361
 BT.1361
-@item bt2020_12bit
+@item iec61966_2_1
 IEC 61966-2-1
-@item smpte2084
+@item bt2020_10bit
 BT.2020 - 10 bit
-@item smpte428_1
+@item bt2020_12bit
 BT.2020 - 12 bit
+@item smpte2084
+SMPTE ST 2084
+@item smpte428_1
+SMPTE ST 428-1
+@item arib-std-b67
+ARIB STD-B67
 @end table
 
 @item colorspace @var{integer} (@emph{decoding/encoding,video})
+Possible values:
+@table @samp
+@item rgb
+RGB
+@item bt709
+BT.709
+@item fcc
+FCC
+@item bt470bg
+BT.470 BG
+@item smpte170m
+SMPTE 170 M
+@item smpte240m
+SMPTE 240 M
+@item ycocg
+YCOCG
+@item bt2020_ncl
+BT.2020 NCL
+@item bt2020_cl
+BT.2020 CL
+@item smpte2085
+SMPTE 2085
+@end table
 
 @item color_range @var{integer} (@emph{decoding/encoding,video})
 If used as input parameter, it serves as a hint to the decoder, which
-- 
2.9.1

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] Merge commit 'a8164323374e86ce5f93759230868c98356833a2'

[Michael Niedermayer]

On Wed, Sep 28, 2016 at 06:15:03PM +0200, James Almer wrote:
> ffmpeg | branch: master | James Almer  | Wed Sep 28 
> 13:12:18 2016 -0300| [6e76c9c45018b9cea383ff1c3f17d08792623509] | committer: 
> James Almer
> 
> Merge commit 'a8164323374e86ce5f93759230868c98356833a2'
> 
> * commit 'a8164323374e86ce5f93759230868c98356833a2':
>   pixdesc: Add new SMPTE 431, 432, and 2085 color properties
> 
> Conflicts:
> libavcodec/options_table.h
> libavcodec/version.h
> libavutil/pixdesc.c
> libavutil/pixfmt.h
> libavutil/version.h
> 
> Merged-by: James Almer 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=6e76c9c45018b9cea383ff1c3f17d08792623509
> ---
> 
>  libavcodec/options_table.h | 3 +++
>  libavcodec/version.h   | 2 +-
>  libavutil/pixdesc.c| 3 +++
>  libavutil/pixfmt.h | 5 -
>  libavutil/version.h| 2 +-
>  5 files changed, 12 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 88dee61..995906b 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -460,6 +460,8 @@ static const AVOption avcodec_options[] = {
>  {"film","Film",   0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_PRI_FILM }, INT_MIN, INT_MAX, V|E|D, "color_primaries_type"},
>  {"bt2020",  "BT.2020",0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_PRI_BT2020 },   INT_MIN, INT_MAX, V|E|D, "color_primaries_type"},
>  {"smpte428_1",  "SMPTE ST 428-1", 0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_PRI_SMPTEST428_1 }, INT_MIN, INT_MAX, V|E|D, "color_primaries_type"},
> +{"smpte431","SMPTE 431-2",0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_PRI_SMPTE431 }, INT_MIN, INT_MAX, V|E|D, "color_primaries_type"},
> +{"smpte432","SMPTE 422-1",0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_PRI_SMPTE432 }, INT_MIN, INT_MAX, V|E|D, "color_primaries_type"},
>  {"color_trc", "color transfer characteristics", OFFSET(color_trc), 
> AV_OPT_TYPE_INT, {.i64 = AVCOL_TRC_UNSPECIFIED }, 1, AVCOL_TRC_NB-1, V|E|D, 
> "color_trc_type"},
>  {"bt709","BT.709",   0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_TRC_BT709 },INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
>  {"unspecified",  "Unspecified",  0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_TRC_UNSPECIFIED },  INT_MIN, INT_MAX, V|E|D, "color_trc_type"},
> @@ -489,6 +491,7 @@ static const AVOption avcodec_options[] = {
>  {"ycocg",   "YCOCG",   0, AV_OPT_TYPE_CONST, {.i64 = AVCOL_SPC_YCOCG 
> },   INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
>  {"bt2020_ncl",  "BT.2020 NCL", 0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_SPC_BT2020_NCL },  INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
>  {"bt2020_cl",   "BT.2020 CL",  0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_SPC_BT2020_CL },   INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
> +{"smpte2085",   "SMPTE 2085",  0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_SPC_SMPTE2085 },   INT_MIN, INT_MAX, V|E|D, "colorspace_type"},
>  {"color_range", "color range", OFFSET(color_range), AV_OPT_TYPE_INT, {.i64 = 
> AVCOL_RANGE_UNSPECIFIED }, 0, AVCOL_RANGE_NB-1, V|E|D, "color_range_type"},
>  {"unspecified", "Unspecified", 0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_RANGE_UNSPECIFIED }, INT_MIN, INT_MAX, V|E|D, "color_range_type"},
>  {"mpeg", "MPEG (219*2^(n-8))", 0, AV_OPT_TYPE_CONST, {.i64 = 
> AVCOL_RANGE_MPEG },INT_MIN, INT_MAX, V|E|D, "color_range_type"},

Missing changes to doc/
also the need to update doc/ should be mentioned in doc/libav-merge.txt

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

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


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

Re: [FFmpeg-devel] [PATCH 1/5] lavc : yami : add libyami decoder/encoder

[Chao Liu]

On Sat, Sep 24, 2016 at 6:18 AM, wm4  wrote:

> On Sat, 24 Sep 2016 02:34:56 +0200
> Michael Niedermayer  wrote:
>
> > On Mon, Aug 15, 2016 at 04:22:33PM +0800, Jun Zhao wrote:
> > > add libyami decoder/encoder/vpp in ffmpeg, about build step,
> > > please refer to the link: https://github.com/01org/
> ffmpeg_libyami/wiki/Build
> >
> > >  Makefile   |1
> > >  configure  |   27 ++
> > >  ffmpeg.c   |4
> > >  ffmpeg.h   |1
> > >  ffmpeg_libyami.c   |   85 ++
> > >  libavcodec/Makefile|8
> > >  libavcodec/allcodecs.c |6
> > >  libavcodec/libyami.cpp |  429 +++
> > >  libavcodec/libyami.h   |   59 
> > >  libavcodec/libyami_dec.cpp |  527 ++
> +
> > >  libavcodec/libyami_dec.h   |   56 
> > >  libavcodec/libyami_enc.cpp |  551 ++
> +++
> > >  libavcodec/libyami_enc.h   |   70 +
> > >  libavutil/pixdesc.c|4
> > >  libavutil/pixfmt.h |5
> > >  15 files changed, 1833 insertions(+)
> > > d5ebbaa497e6f36026a4482dc6e0f26b370561b5  0001-lavc-yami-add-libyami-
> decoder-encoder.patch
> > > From 7147fdb375cb7241d69823d8b9b6e94f66df3a32 Mon Sep 17 00:00:00 2001
> > > From: Jun Zhao 
> > > Date: Mon, 15 Aug 2016 15:36:14 +0800
> > > Subject: [[PATCH] 1/5] lavc : yami : add libyami decoder/encoder.
> >
> > it seems people are not in favor of this patchset, judging from this
> > thread.
> > If you are interrested in maintaining this code externally as a patch
> > or git repository, then please add some reasonable link/mention to
> > some page on https://trac.ffmpeg.org/wiki so users are aware of its
> > existence and can find it
> >
> > If you belive thats incorret and people in fact majorly support this
> > patchset then you can also start a vote of course.
> >
> > ill mark this patchset as rejected on patchwork as that seems the
> > de-facto current situation
> >
>
> From one person who tried to use it (and who's also in the list), I
> heard that ffmpeg native vaapi decoding/encoding works better for him.
>
I don't know how he made that conclusion. Maybe he only uses the command
line?
We are building a product using ffmpeg C interface. For me, hwaccel is way
too complicated to use. IIUC, I have to copy thousand lines of code from
ffmpeg_*.c to use it ...
With this patch, it's trivial to switch between codecs like qsv_h264,
libyami_h264, libyami_vp8.

We have been trying different hardware acceleration solutions in our
product. So far, QSV works best for us.
However, QSV itself has a lot of problems, like too much work to use it
under Linux, quite a few critical bugs, no support for VP8.
Even worse, it only supports latest CPUs. We cannot use it in production
because we don't know when they'll stop supporting our hardware, which'll
leave us no option.

So far, libyami looks like the best options for people like us. If you guys
in the end reject this patch, we'll have to patch it ourselves. That'll be
awful. I hope we won't need to do that..

>
> So there's probably no reason to use this patch at all.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] ffmpeg: re-copy codec contexts after encoding

[Jon Toohill]

This was sent in error, please disregard.


Jon Toohill |  Google Play Music |  jtooh...@google.com |  (650) 215-0770

On Wed, Sep 28, 2016 at 11:28 AM, Jon Toohill  wrote:

> This preserves changes to fields of AVCodecContext that get
> updated during encoding, such as trailing_padding (which
> may not be known until encoding is complete).
> ---
>  ffmpeg.c | 15 +++
>  1 file changed, 15 insertions(+)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index df55a49..1e973f5 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -4243,6 +4243,21 @@ static int transcode(void)
>
>  term_exit();
>
> +/* update output codec contexts after encoding */
> +for (i = 0; i < nb_output_streams; i++) {
> +ost = output_streams[i];
> +if (ost->encoding_needed) {
> +ret = avcodec_copy_context(
> +output_files[ost->file_index]->ctx->streams[ost->index]->
> codec,
> +ost->enc_ctx);
> +if (ret < 0) {
> +av_log(ost, AV_LOG_ERROR, "Error copying final codec
> context: %s\n", av_err2str(ret));
> +if (exit_on_error)
> +exit_program(1);
> +}
> +}
> +}
> +
>  /* write the trailer if needed and close file */
>  for (i = 0; i < nb_output_files; i++) {
>  os = output_files[i]->ctx;
> --
> 2.8.0.rc3.226.g39d4020
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/concatdec: don't call open_file when seek position within a file

[Nicolas George]

Le duodi 2 vendémiaire, an CCXXV, raymondzheng1...@gmail.com a écrit :
> Thanks for your suggest, I have modified patch. see below.
> ---
>  libavformat/concatdec.c | 24 +---
>  1 file changed, 17 insertions(+), 7 deletions(-)
> 
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c

The comment should have been below the line with the three dashes, otherwise
it ends up in the commit message.

I have fixed this, tested and pushed, thanks for the patch.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 0/4] Handle trailing_padding in MP3 Info tag

[Jon Toohill]

Oops, forgot to send this in reply to the previous thread. Should I re-send?
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-September/200092.html

On Wed, Sep 28, 2016 at 11:28 AM, Jon Toohill  wrote:

> Trimming trailing_padding samples from the end of the track is not yet
> implemented.
>
> Jon Toohill (4):
>   ffmpeg: re-copy codec parameters after encoding
>   lavc/libmp3lame: set trailing_padding after flushing encoder
>   lavf/mp3enc: write encoder delay/padding upon closing
>   lavf/mp3dec: read encoder delay/padding from Info tag
>
>  ffmpeg.c| 15 +++
>  libavcodec/libmp3lame.c |  1 +
>  libavformat/mp3dec.c|  2 ++
>  libavformat/mp3enc.c| 20 +---
>  4 files changed, 31 insertions(+), 7 deletions(-)
>
> --
> 2.8.0.rc3.226.g39d4020
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] lavf/mp3dec: read encoder delay/padding from Info tag

[Jon Toohill]

---
 libavformat/mp3dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 56c7f8c..9cc85a3 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -239,6 +239,8 @@ static void mp3_parse_info_tag(AVFormatContext *s, AVStream 
*st,
 
 mp3->start_pad = v>>12;
 mp3->  end_pad = v&4095;
+st->codecpar->initial_padding = mp3->start_pad + 528 + 1;
+st->codecpar->trailing_padding = mp3->end_pad;
 st->start_skip_samples = mp3->start_pad + 528 + 1;
 if (mp3->frames) {
 st->first_discard_sample = -mp3->end_pad + 528 + 1 + mp3->frames * 
(int64_t)spf;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 3/4] lavf/mp3enc: write encoder delay/padding upon closing

[Jon Toohill]

trailing_padding is not known before encoding.
---
 libavformat/mp3enc.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/libavformat/mp3enc.c b/libavformat/mp3enc.c
index de63401..37608f1 100644
--- a/libavformat/mp3enc.c
+++ b/libavformat/mp3enc.c
@@ -247,12 +247,7 @@ static int mp3_write_xing(AVFormatContext *s)
 ffio_fill(dyn_ctx, 0, 8); // empty replaygain fields
 avio_w8(dyn_ctx, 0);  // unknown encoding flags
 avio_w8(dyn_ctx, 0);  // unknown abr/minimal bitrate
-
-// encoder delay
-if (par->initial_padding - 528 - 1 >= 1 << 12) {
-av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
-}
-avio_wb24(dyn_ctx, FFMAX(par->initial_padding - 528 - 1, 0)<<12);
+avio_wb24(dyn_ctx, 0);// empty encoder delay/padding
 
 avio_w8(dyn_ctx,   0); // misc
 avio_w8(dyn_ctx,   0); // mp3gain
@@ -381,7 +376,7 @@ static void mp3_update_xing(AVFormatContext *s)
 AVReplayGain *rg;
 uint16_t tag_crc;
 uint8_t *toc;
-int i, rg_size;
+int i, rg_size, delay, padding;
 
 /* replace "Xing" identification string with "Info" for CBR files. */
 if (!mp3->has_variable_bitrate)
@@ -422,6 +417,17 @@ static void mp3_update_xing(AVFormatContext *s)
 }
 }
 
+/* write encoder delay/padding */
+delay = FFMAX(s->streams[0]->codecpar->initial_padding - 528 - 1, 0);
+padding = s->streams[0]->codecpar->trailing_padding;
+if (delay >= 1 << 12) {
+av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
+}
+if (padding >= 1 << 12) {
+av_log(s, AV_LOG_WARNING, "Too many samples of initial padding.\n");
+}
+AV_WB24(mp3->xing_frame + mp3->xing_offset + 141, (delay << 12) + padding);
+
 AV_WB32(mp3->xing_frame + mp3->xing_offset + XING_SIZE - 8, 
mp3->audio_size);
 AV_WB16(mp3->xing_frame + mp3->xing_offset + XING_SIZE - 4, 
mp3->audio_crc);
 
-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH 2/4] lavc/libmp3lame: set trailing_padding after flushing encoder

[Jon Toohill]

On Tue, Sep 27, 2016 at 1:04 AM, Carl Eugen Hoyos 
wrote:

> 2016-09-26 19:13 GMT+02:00 Jon Toohill  >:
>
> > +avctx->trailing_padding = FFMAX(lame_get_encoder_padding(s->gfp)
> - 528 - 1, 0);
>
> Can you confirm that this function exists in lame 3.98.3?
>

I downloaded the source tarball for lame 3.98 and found it exists there. Is
that sufficient?


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

[FFmpeg-devel] [PATCH 1/4] ffmpeg: re-copy codec parameters after encoding

[Jon Toohill]

This preserves changes to fields of AVCodecParameters that
get updated during encoding, such as trailing_padding
(which may not be known until encoding is complete).
---
 ffmpeg.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index d0f247e..0cdc762 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4255,6 +4255,21 @@ static int transcode(void)
 
 term_exit();
 
+/* update output codec parameters after encoding */
+for (i = 0; i < nb_output_streams; i++) {
+ost = output_streams[i];
+if (ost->encoding_needed) {
+ret = avcodec_parameters_from_context(
+
output_files[ost->file_index]->ctx->streams[ost->index]->codecpar,
+ost->enc_ctx);
+if (ret < 0) {
+av_log(ost, AV_LOG_ERROR, "Error copying final codec context: 
%s\n", av_err2str(ret));
+if (exit_on_error)
+exit_program(1);
+}
+}
+}
+
 /* write the trailer if needed and close file */
 for (i = 0; i < nb_output_files; i++) {
 os = output_files[i]->ctx;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 1/4] ffmpeg: re-copy codec contexts after encoding

[Jon Toohill]

This preserves changes to fields of AVCodecContext that get
updated during encoding, such as trailing_padding (which
may not be known until encoding is complete).
---
 ffmpeg.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/ffmpeg.c b/ffmpeg.c
index df55a49..1e973f5 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -4243,6 +4243,21 @@ static int transcode(void)
 
 term_exit();
 
+/* update output codec contexts after encoding */
+for (i = 0; i < nb_output_streams; i++) {
+ost = output_streams[i];
+if (ost->encoding_needed) {
+ret = avcodec_copy_context(
+output_files[ost->file_index]->ctx->streams[ost->index]->codec,
+ost->enc_ctx);
+if (ret < 0) {
+av_log(ost, AV_LOG_ERROR, "Error copying final codec context: 
%s\n", av_err2str(ret));
+if (exit_on_error)
+exit_program(1);
+}
+}
+}
+
 /* write the trailer if needed and close file */
 for (i = 0; i < nb_output_files; i++) {
 os = output_files[i]->ctx;
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 2/4] lavc/libmp3lame: set trailing_padding after flushing encoder

[Jon Toohill]

---
 libavcodec/libmp3lame.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 5642264..1566921 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libmp3lame.c
@@ -218,6 +218,7 @@ static int mp3lame_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 } else {
 lame_result = lame_encode_flush(s->gfp, s->buffer + s->buffer_index,
 s->buffer_size - s->buffer_index);
+avctx->trailing_padding = FFMAX(lame_get_encoder_padding(s->gfp) - 528 
- 1, 0);
 }
 if (lame_result < 0) {
 if (lame_result == -1) {
-- 
2.8.0.rc3.226.g39d4020

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

[FFmpeg-devel] [PATCH 0/4] Handle trailing_padding in MP3 Info tag

[Jon Toohill]

Trimming trailing_padding samples from the end of the track is not yet
implemented.

Jon Toohill (4):
  ffmpeg: re-copy codec parameters after encoding
  lavc/libmp3lame: set trailing_padding after flushing encoder
  lavf/mp3enc: write encoder delay/padding upon closing
  lavf/mp3dec: read encoder delay/padding from Info tag

 ffmpeg.c| 15 +++
 libavcodec/libmp3lame.c |  1 +
 libavformat/mp3dec.c|  2 ++
 libavformat/mp3enc.c| 20 +---
 4 files changed, 31 insertions(+), 7 deletions(-)

-- 
2.8.0.rc3.226.g39d4020

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

Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation

[James Almer]

On 9/19/2016 7:00 AM, Ivan Uskov wrote:
> This should be a good step to make qsv branches of ffmpeg and libav
> closer.
> LGTM.

This has now been merged.

Could i ask you or Nablet to look at commits
a0524d9b1e1bb0012207584f067096df7792df6c and
ad9c9440d592e4d53d6bec9961b4b22e25387d70 from libav and see if you can
implement then in our tree? They are next in the merge queue and there
have been some changes in our tree that make merging both of them not
trivial, and i have no way to test.

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

Re: [FFmpeg-devel] [PATCH]lavc/8bps: Fix 32bit output of 24bit video

[Carl Eugen Hoyos]

2016-09-25 14:31 GMT+02:00 Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes a long-time regression.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH 1/2 v2] movenc: use similar logic to DASH when writing bit rate to ISML

[Carl Eugen Hoyos]

2016-09-28 1:14 GMT+02:00 Jan Ekström :
> This way, in case of bit rate not being set, max_bitrate will be
> used instead.

Makes sense to me but I'd prefer if somebody else (looks
again and) applies.

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

Re: [FFmpeg-devel] [PATCH]lavf/mpegtsenc: Set min PID for data pkt to 0x0010

[Carl Eugen Hoyos]

2016-09-27 9:15 GMT+02:00 Carl Eugen Hoyos :
> 2016-09-27 5:42 GMT+02:00 Andrey Turkin :
>> Nevermind, I didn't though this through. Default value is high enough to
>> comply with all standards.
>
> I'll apply the patch if there are no objections.

Patch applied.

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

Re: [FFmpeg-devel] [PATCH] flv format support mp3 audio with 48khz

[wm4]

On Wed, 28 Sep 2016 07:47:47 -0700
fuqiuping  wrote:

> ---
>  libavformat/flvenc.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 99903f5..296426a 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -107,6 +107,13 @@ static int get_audio_flags(AVFormatContext *s, 
> AVCodecParameters *par)
>  return FLV_CODECID_SPEEX | FLV_SAMPLERATE_11025HZ | 
> FLV_SAMPLESSIZE_16BIT;
>  } else {
>  switch (par->sample_rate) {
> +case 48000:
> +if (par->codec_id == AV_CODEC_ID_MP3) {
> +flags |= FLV_SAMPLERATE_44100HZ;

This looks wrong. It should have a code comment why it's right, even
though it 'll look wrong to every single person who look at tit for the
first time.

> +break;
> +} else {
> +goto error;
> +}
>  case 44100:
>  flags |= FLV_SAMPLERATE_44100HZ;
>  break;
> @@ -124,6 +131,7 @@ static int get_audio_flags(AVFormatContext *s, 
> AVCodecParameters *par)
>  break;
>  }
>  default:
> +error:
>  av_log(s, AV_LOG_ERROR,
> "FLV does not support sample rate %d, "
> "choose from (44100, 22050, 11025)\n", par->sample_rate);

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

[FFmpeg-devel] [PATCH] flv format support mp3 audio with 48khz

[fuqiuping]

---
 libavformat/flvenc.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 99903f5..296426a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -107,6 +107,13 @@ static int get_audio_flags(AVFormatContext *s, 
AVCodecParameters *par)
 return FLV_CODECID_SPEEX | FLV_SAMPLERATE_11025HZ | 
FLV_SAMPLESSIZE_16BIT;
 } else {
 switch (par->sample_rate) {
+case 48000:
+if (par->codec_id == AV_CODEC_ID_MP3) {
+flags |= FLV_SAMPLERATE_44100HZ;
+break;
+} else {
+goto error;
+}
 case 44100:
 flags |= FLV_SAMPLERATE_44100HZ;
 break;
@@ -124,6 +131,7 @@ static int get_audio_flags(AVFormatContext *s, 
AVCodecParameters *par)
 break;
 }
 default:
+error:
 av_log(s, AV_LOG_ERROR,
"FLV does not support sample rate %d, "
"choose from (44100, 22050, 11025)\n", par->sample_rate);
-- 
1.7.1

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

Re: [FFmpeg-devel] imagepipe filter (was [PATCH] avfilter: add dynoverlay filter.)

[Priebe, Jason]

On 9/23/16, Paul B Mahol  wrote:

> On 9/28/16, Priebe, Jason  wrote:
>
> > If there's a better way to decode these still images without using
> > an intermediate temp file, please point me to it, and I'll make the
> > change.
> 
> Using avformat/avcodec calls to decode input from named pipe into AVFrame.

OK.  I was able to synthesize the code from ff_load_image() and the code 
from this example: 

http://www.ffmpeg.org/doxygen/trunk/doc_2examples_2avio_reading_8c-example.html

It took 130 lines of code to read an image from a memory buffer, and
about 40 of those lines are essentially duplicated from ff_load_image().

It seems like a function like this should be in the lavfutils, not
buried in a random filter.  And maybe those 40 lines could be shared 
between this new function an dthe ff_load_image() function?

Jason Priebe
CBC New Media
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 3.2

[Carl Eugen Hoyos]

2016-09-27 15:30 GMT+02:00 Michael Niedermayer :

> Its long since FFmpeg 3.1, so its time to make 3.2

The configure option --enable-incompatible-libav-abi was intentionally
broken some time ago, if it cannot get removed it should at least be
removed from the help output.

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

Re: [FFmpeg-devel] imagepipe filter (was [PATCH] avfilter: add dynoverlay filter.)

[Moritz Barsnick]

On Wed, Sep 28, 2016 at 12:40:24 +, Priebe, Jason wrote:
> Like I said, I don't see any way to decode an in-memory encoded
> image (PNG, JPG, etc.) with the existing function calls.  I only
> see ff_load_image(), which takes a filename.

The image2pipe demuxer already handles a "stream" of still image files:

$ (cat 01.png; sleep 3; cat 02.png) | ffmpeg -f image2pipe -i - [...]
(This Unix "|" pipe could be replaced by a named pipe.)

Unfortunately, what it does not do, is to set the timestamp of the
incoming image to the wallclock, or to the realtime offset. Instead, it
assumes a constant frame rate.

If it did set the timestamps accordingly, you could duplicate its input
frames via the fps filter before overlaying the image. This also
assumes the fps filter could duplicate images as long as it doesn't get
new ones, to fulfill the constant output rate. I guess it doesn't do
that currently.

> I think you are right -- the *concept* of named pipes exists in
> Windows, but the mkfifo() call doesn't create them.  You have
> to use calls like CreateNamedPipe() and ConnectNamedPipe().

Yes, you'd need a helper program in order to be able to achieve
something as easy as Unix's "cat 03.png > /my/fifo".

Just thinking out loud,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: [PATCH] flv format support mp3 audio with 48khz

[付 秋平]

Sorry, this is a mistake.

I will change it and resubmit the patch.


发件人: ffmpeg-devel  代表 Michael Niedermayer 

发送时间: 2016年9月27日 19:57
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] [PATCH] flv format support mp3 audio with 48khz

On Tue, Sep 27, 2016 at 08:01:13AM -0700, fu.qiup...@hotmail.com wrote:

> From: frankos2 

This is not a name and email address
is this intended as "Author" information for git ?
Or is this a mistake ?
If its a mistake please correct it and resubmit the patch

thx

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

There will always be a question for which you do not know the correct answer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] 答复: [PATCH] flv format support mp3 audio with 48khz

[付 秋平]

I have already tried the "mp3_audio_48khz" flv live stream and rtmp live stream 
in the adobe flash player.

It supports the format and works well.


发件人: ffmpeg-devel  代表 Yusuke Nakamura 

发送时间: 2016年9月27日 21:15
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] [PATCH] flv format support mp3 audio with 48khz

2016-09-28 0:01 GMT+09:00 :

> From: frankos2 
>
> ---
>  libavformat/flvenc.c |8 
>  1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
> index 99903f5..296426a 100644
> --- a/libavformat/flvenc.c
> +++ b/libavformat/flvenc.c
> @@ -107,6 +107,13 @@ static int get_audio_flags(AVFormatContext *s,
> AVCodecParameters *par)
>  return FLV_CODECID_SPEEX | FLV_SAMPLERATE_11025HZ |
> FLV_SAMPLESSIZE_16BIT;
>  } else {
>  switch (par->sample_rate) {
> +case 48000:
> +if (par->codec_id == AV_CODEC_ID_MP3) {
> +flags |= FLV_SAMPLERATE_44100HZ;
> +break;
> +} else {
> +goto error;
> +}
>  case 44100:
>  flags |= FLV_SAMPLERATE_44100HZ;
>  break;
> @@ -124,6 +131,7 @@ static int get_audio_flags(AVFormatContext *s,
> AVCodecParameters *par)
>  break;
>  }
>  default:
> +error:
>  av_log(s, AV_LOG_ERROR,
> "FLV does not support sample rate %d, "
> "choose from (44100, 22050, 11025)\n",
> par->sample_rate);
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ffmpeg-devel Info Page
ffmpeg.org
This list is about FFmpeg development discussions and patches; but not for 
bug-reports. Please read the Code-of-conduct. To see the collection of prior 
postings to ...



>

Out of the spec I think. Did you confirm that Adobe (Flash Player) allows
48kHz mp3? About AAC, the spec (Adobe Flash Video File Format
Specification) says the Flash Player ignores sample rate in AudioTagHeader,
which is a dummy, and extracts the actual sample rate from AAC bitstream.
But the spec does not say about MP3 in the same way.
___
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] imagepipe filter (was [PATCH] avfilter: add dynoverlay filter.)

[Paul B Mahol]

On 9/28/16, Priebe, Jason  wrote:
> On 9/23/16, Paul B Mahol  wrote:
>
>> On 9/27/16, Priebe, Jason  wrote:
>> > On 9/23/16, Paul B Mahol  wrote:
>> >
>> > - it uses a slightly inelegant technique to read the images; it writes
>> >   the image data to a temp file so it can call ff_load_image().  I
>> > didn't
>> >   see a function that can load an image directly from an in-memory byte
>> > array.
>>
>> AVFrame stores all decoded data from image. Using temp files is
>> ridicculous.
>
> I do store the *decoded* image in an AVFrame.  I only use the temp file
> when I finish reading the *encoded* image from the named pipe -- I
> write to a temp file, hand that off to ff_load_image(), and once the
> image has been decoded, I destroy the temp file.
>
> Like I said, I don't see any way to decode an in-memory encoded
> image (PNG, JPG, etc.) with the existing function calls.  I only
> see ff_load_image(), which takes a filename.
>
> I think that trying to decode a PNG out of an in-memory buffer would
> require refactoring inside of files like libavformat/utils.c, which
> would require a deeper understanding of the internals than I have.
>
> If there's a better way to decode these still images without using
> an intermediate temp file, please point me to it, and I'll make the
> change.

Using avformat/avcodec calls to decode input from named pipe into AVFrame.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] pass TLS args for RTSPS

[jayridge]

From: Jay Ridgeway 

rename URISTR to NONNULLSTR
---
 libavformat/rtsp.c| 19 ---
 libavformat/rtsp.h|  8 
 libavformat/tls_gnutls.c  |  7 +++
 libavformat/tls_openssl.c |  7 +++
 libavformat/tls_schannel.c|  7 +++
 libavformat/tls_securetransport.c |  7 +++
 6 files changed, 52 insertions(+), 3 deletions(-)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index c6292c5..179a59b 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -78,6 +78,7 @@
 { "reorder_queue_size", "set number of packets to buffer for handling of 
reordered packets", OFFSET(reordering_queue_size), AV_OPT_TYPE_INT, { .i64 = -1 
}, -1, INT_MAX, DEC }, \
 { "buffer_size","Underlying protocol send/receive buffer size",
  OFFSET(buffer_size),   AV_OPT_TYPE_INT, { .i64 = -1 }, 
-1, INT_MAX, DEC|ENC } \
 
+#define NONNULLSTR(s) (s ? s : "")
 
 const AVOption ff_rtsp_options[] = {
 { "initial_pause",  "do not start playing the stream immediately", 
OFFSET(initial_pause), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DEC },
@@ -97,6 +98,10 @@ const AVOption ff_rtsp_options[] = {
 { "stimeout", "set timeout (in microseconds) of socket TCP I/O 
operations", OFFSET(stimeout), AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX, 
DEC },
 COMMON_OPTS(),
 { "user-agent", "override User-Agent header", OFFSET(user_agent), 
AV_OPT_TYPE_STRING, {.str = LIBAVFORMAT_IDENT}, 0, 0, DEC },
+{ "ca_file", "Certificate Authority database file", OFFSET(ca_file), 
AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, DEC|ENC },
+{ "tls_verify", "Verify the peer certificate", OFFSET(verify), 
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, DEC|ENC},
+{ "cert_file", "Certificate file", OFFSET(cert_file), AV_OPT_TYPE_STRING, 
{.str = NULL}, 0, 0, DEC|ENC },
+{ "key_file", "Private key file", OFFSET(key_file),  AV_OPT_TYPE_STRING, 
{.str = NULL}, 0, 0, DEC|ENC },
 { NULL },
 };
 
@@ -1812,9 +1817,17 @@ redirect:
 } else {
 int ret;
 /* open the tcp connection */
-ff_url_join(tcpname, sizeof(tcpname), lower_rtsp_proto, NULL,
-host, port,
-"?timeout=%d", rt->stimeout);
+if (strcmp("tls", lower_rtsp_proto) == 0) {
+ff_url_join(tcpname, sizeof(tcpname), lower_rtsp_proto, NULL,
+host, port,
+
"?timeout=%d=%d=%s_file=%s_file=%s",
+rt->stimeout, rt->verify, NONNULLSTR(rt->ca_file),
+NONNULLSTR(rt->cert_file), NONNULLSTR(rt->key_file));
+} else {
+ff_url_join(tcpname, sizeof(tcpname), lower_rtsp_proto, NULL,
+host, port,
+"?timeout=%d", rt->stimeout);
+}
 if ((ret = ffurl_open_whitelist(>rtsp_hd, tcpname, 
AVIO_FLAG_READ_WRITE,
>interrupt_callback, NULL, s->protocol_whitelist, 
s->protocol_blacklist, NULL)) < 0) {
 err = ret;
diff --git a/libavformat/rtsp.h b/libavformat/rtsp.h
index 852fd67..fa872a8 100644
--- a/libavformat/rtsp.h
+++ b/libavformat/rtsp.h
@@ -408,6 +408,14 @@ typedef struct RTSPState {
 
 char default_lang[4];
 int buffer_size;
+
+/** The following are used for RTSPS streams */
+//@{
+char *ca_file;
+int verify;
+char *cert_file;
+char *key_file;
+//@}
 } RTSPState;
 
 #define RTSP_FLAG_FILTER_SRC  0x1/**< Filter incoming UDP packets -
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 991b36b..ecc80bf 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -235,6 +235,12 @@ static int tls_write(URLContext *h, const uint8_t *buf, 
int size)
 return print_tls_error(h, ret);
 }
 
+static int tls_get_file_handle(URLContext *h)
+{
+TLSContext *c = h->priv_data;
+return ffurl_get_file_handle(c->tls_shared.tcp);
+}
+
 static const AVOption options[] = {
 TLS_COMMON_OPTIONS(TLSContext, tls_shared),
 { NULL }
@@ -253,6 +259,7 @@ const URLProtocol ff_tls_gnutls_protocol = {
 .url_read   = tls_read,
 .url_write  = tls_write,
 .url_close  = tls_close,
+.url_get_file_handle = tls_get_file_handle,
 .priv_data_size = sizeof(TLSContext),
 .flags  = URL_PROTOCOL_FLAG_NETWORK,
 .priv_data_class = _class,
diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 46eb3e6..1455392 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -283,6 +283,12 @@ static int tls_write(URLContext *h, const uint8_t *buf, 
int size)
 return print_tls_error(h, ret);
 }
 
+static int tls_get_file_handle(URLContext *h)
+{
+TLSContext *c = h->priv_data;
+return ffurl_get_file_handle(c->tls_shared.tcp);
+}
+
 static const AVOption options[] = {
 TLS_COMMON_OPTIONS(TLSContext, tls_shared),
 { NULL }
@@ -301,6 +307,7 @@ const URLProtocol 

Re: [FFmpeg-devel] FFmpeg 3.2

[Timo Rothenpieler]

Am 27.09.2016 um 15:30 schrieb Michael Niedermayer:
> Hi all
> 
> Its long since FFmpeg 3.1, so its time to make 3.2
> ill branch release/3.2 off master and make 3.2 in maybe about a week or
> 2 unless something delays it

Should ffserver be deprecated for 3.2, or will it be resurrected now?
I'm all for deprecating it. Can always un-deprecate it if something
happens about it, nobody going to complain about that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] imagepipe filter (was [PATCH] avfilter: add dynoverlay filter.)

[Priebe, Jason]

On 9/23/16, Paul B Mahol  wrote:

> On 9/27/16, Priebe, Jason  wrote:
> > On 9/23/16, Paul B Mahol  wrote:
> >
> > - it uses a slightly inelegant technique to read the images; it writes
> >   the image data to a temp file so it can call ff_load_image().  I didn't
> >   see a function that can load an image directly from an in-memory byte
> > array.
> 
> AVFrame stores all decoded data from image. Using temp files is ridicculous.

I do store the *decoded* image in an AVFrame.  I only use the temp file
when I finish reading the *encoded* image from the named pipe -- I
write to a temp file, hand that off to ff_load_image(), and once the
image has been decoded, I destroy the temp file.

Like I said, I don't see any way to decode an in-memory encoded
image (PNG, JPG, etc.) with the existing function calls.  I only
see ff_load_image(), which takes a filename.

I think that trying to decode a PNG out of an in-memory buffer would
require refactoring inside of files like libavformat/utils.c, which
would require a deeper understanding of the internals than I have.

If there's a better way to decode these still images without using
an intermediate temp file, please point me to it, and I'll make the
change.

> > - Portability - I'm worried this is the big one.  mkfifo isn't readily
> >   available on Windows without compatibility libraries, and even then,
> >   I'm not sure whether they would work the same way they do under *nix.
> >   Generally speaking, how does the ffmpeg team tackle cross-platform
> >   issues like this?
> 
> IIRC named pipes are available for Windows.

I think you are right -- the *concept* of named pipes exists in
Windows, but the mkfifo() call doesn't create them.  You have
to use calls like CreateNamedPipe() and ConnectNamedPipe().

It looks like there is some windows compatibility code for handling
standard file open() calls in libavutil/file_open.c, so I suppose
that something like that could be built for named pipes (maybe one
call that creates and opens the named pipe, with conditional calls
for *nix and Windows?)

This is way outside my wheelhouse -- I don't even have a Windows
build environment.  But if it's a show-stopper, then I can slog
my way through it. 

Jason Priebe
CBC New Media 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavcodec/qdm2.c: fix warning due to misleading indentation

[Josh de Kock]

On 27/09/2016 23:11, Josh de Kock wrote:

On 27/09/2016 20:47, Adriano Pallavicino wrote:

Sure

Adriano



This patch looks good to me, just going to give it a little time for
others to comment.


Thanks, applied.

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

Re: [FFmpeg-devel] order T-shirts

[John Warburton]

On Sun, Sep 4, 2016 at 10:34 PM, Thomas Volkert  wrote:

> Hi,
>
> Some guys at the VDD asked for FFmpeg T-shirts.
> I'd like to do a new T-shirt order. The shirts could be given to
> multimedia devs who stop at one of our next booths.
>
> ​I'd *buy* one. XL. Wear it at the lectures I give.​

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

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Steven Liu]

2016-09-28 18:03 GMT+08:00 Moritz Barsnick :

> On Wed, Sep 28, 2016 at 17:56:27 +0800, Steven Liu wrote:
> > change from "in.nut" to "-i in.nut"
> >
> > what about:
> >
> > The examples of hlsenc is error, for example:
> > ffmpeg in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts'
> > out.m3u8
> > this example missing input parameter -i, so this patch add the -i into
> the
> > example
>
> That's not what Michael complained about. (You surely don't need to be
> so verbose for a typo fix.) Look, he even marked it with little '^^^':
>
> > > > > > Subject: [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales
> > > > > 
> > > > > not a english word
>
> There's a spelling error in your commit message. That's all.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Hi Moritz Barsnick,

  What about this patch?


0001-doc-muxers-fix-hlsenc-options-examples-error.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] order T-shirts

[Carlos Fernandez Sanz]

On Tue, Sep 27, 2016 at 8:21 PM, Steven Liu  wrote:
>>
> Hi guys,
> what about the next step :-D

Probably a good idea would be to have some ready for Google's Summer
of Code summit... I know I'd love to get one there.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Moritz Barsnick]

On Wed, Sep 28, 2016 at 17:56:27 +0800, Steven Liu wrote:
> change from "in.nut" to "-i in.nut"
> 
> what about:
> 
> The examples of hlsenc is error, for example:
> ffmpeg in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts'
> out.m3u8
> this example missing input parameter -i, so this patch add the -i into the
> example

That's not what Michael complained about. (You surely don't need to be
so verbose for a typo fix.) Look, he even marked it with little '^^^':

> > > > > Subject: [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales
> > > > 
> > > > not a english word

There's a spelling error in your commit message. That's all.

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

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Steven Liu]

change from "in.nut" to "-i in.nut"



what about:

The examples of hlsenc is error, for example:
ffmpeg in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts'
out.m3u8
this example missing input parameter -i, so this patch add the -i into the
example

2016-09-28 17:44 GMT+08:00 Moritz Barsnick :

> On Wed, Sep 28, 2016 at 16:25:30 +0800, Steven Liu wrote:
> > > > Subject: [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales
> > > 
> > > not a english word
>
> You didn't fix this in your commit message!?
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Moritz Barsnick]

On Wed, Sep 28, 2016 at 16:25:30 +0800, Steven Liu wrote:
> > > Subject: [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales
> > 
> > not a english word

You didn't fix this in your commit message!?

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

Re: [FFmpeg-devel] [PATCH 3/4] V11 - SCTE-35 support in hlsenc

[Steven Liu]

2016-09-28 4:38 GMT+08:00 Carlos Fernandez Sanz :

> From: Carlos Fernandez 
>
> Signed-off-by: Carlos Fernandez 
> ---
>  libavformat/Makefile  |   2 +-
>  libavformat/hlsenc.c  | 108 +--
>  libavformat/scte_35.c | 527 ++
> 
>  libavformat/scte_35.h |  86 
>  4 files changed, 701 insertions(+), 22 deletions(-)
>  create mode 100644 libavformat/scte_35.c
>  create mode 100644 libavformat/scte_35.h
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 5d827d31..9218606 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -205,7 +205,7 @@ OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
>  OBJS-$(CONFIG_HEVC_DEMUXER)  += hevcdec.o rawdec.o
>  OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
>  OBJS-$(CONFIG_HLS_DEMUXER)   += hls.o
> -OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o
> +OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o scte_35.o
>  OBJS-$(CONFIG_HNM_DEMUXER)   += hnm.o
>  OBJS-$(CONFIG_ICO_DEMUXER)   += icodec.o
>  OBJS-$(CONFIG_ICO_MUXER) += icoenc.o
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 428bae4..3303dc8 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -38,6 +38,7 @@
>  #include "avio_internal.h"
>  #include "internal.h"
>  #include "os_support.h"
> +#include "scte_35.h"
>
>  #define KEYSIZE 16
>  #define LINE_BUFFER_SIZE 1024
> @@ -48,6 +49,10 @@ typedef struct HLSSegment {
>  double duration; /* in seconds */
>  int64_t pos;
>  int64_t size;
> +struct scte_35_event *event;
> +int out;
> +int adv_count;
> +int64_t start_pts;
>
>  char key_uri[LINE_BUFFER_SIZE + 1];
>  char iv_string[KEYSIZE*2 + 1];
> @@ -92,6 +97,8 @@ typedef struct HLSContext {
>  uint32_t flags;// enum HLSFlags
>  uint32_t pl_type;  // enum PlaylistType
>  char *segment_filename;
> +char *adv_filename;
> +char *adv_subfilename;
>
>  int use_localtime;  ///< flag to expand filename with localtime
>  int use_localtime_mkdir;///< flag to mkdir dirname in timebased
> filename
> @@ -108,6 +115,8 @@ typedef struct HLSContext {
>  int nb_entries;
>  int discontinuity_set;
>
> +int adv_count;
> +struct scte_35_interface *scte_iface;
>  HLSSegment *segments;
>  HLSSegment *last_segment;
>  HLSSegment *old_segments;
> @@ -208,6 +217,8 @@ static int hls_delete_old_segments(HLSContext *hls) {
>  av_freep();
>  previous_segment = segment;
>  segment = previous_segment->next;
> +if (hls->scte_iface)
> +hls->scte_iface->unref_scte35_event(_segment->
> event);
>  av_free(previous_segment);
>  }
>
> @@ -327,8 +338,8 @@ static int hls_mux_init(AVFormatContext *s)
>  }
>
>  /* Create a new segment and append it to the segment list */
> -static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls,
> double duration,
> -  int64_t pos, int64_t size)
> +static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls,
> double duration, int64_t pos,
> +  int64_t start_pts, struct scte_35_event
> *event, int64_t size)
>  {
>  HLSSegment *en = av_malloc(sizeof(*en));
>  char *tmp, *p;
> @@ -364,9 +375,23 @@ static int hls_append_segment(struct AVFormatContext
> *s, HLSContext *hls, double
>
>  en->duration = duration;
>  en->pos  = pos;
> +en->event= event;
>  en->size = size;
> +en->start_pts  = start_pts;
>  en->next = NULL;
>
> +if (hls->scte_iface) {
> +if (hls->scte_iface->event_state == EVENT_OUT_CONT) {
> +en->adv_count = hls->adv_count;;
> +hls->adv_count++;
> +en->out = hls->scte_iface->event_state;
> +} else {
> +hls->adv_count = 0;
> +en->out = hls->scte_iface->event_state;
> +}
> +}
> +
> +
>  if (hls->key_info_file) {
>  av_strlcpy(en->key_uri, hls->key_uri, sizeof(en->key_uri));
>  av_strlcpy(en->iv_string, hls->iv_string, sizeof(en->iv_string));
> @@ -440,7 +465,7 @@ static int parse_playlist(AVFormatContext *s, const
> char *url)
>  new_start_pos = avio_tell(hls->avf->pb);
>  hls->size = new_start_pos - hls->start_pos;
>  av_strlcpy(hls->avf->filename, line, sizeof(line));
> -ret = hls_append_segment(s, hls, hls->duration,
> hls->start_pos, hls->size);
> +ret = hls_append_segment(s, hls, hls->duration,
> hls->start_pos, 0, NULL, hls->size);
>  if (ret < 0)
>  goto fail;
>  hls->start_pos = new_start_pos;
> @@ -570,9 +595,23 @@ static int hls_window(AVFormatContext *s, int last)
>  avio_printf(out, 

Re: [FFmpeg-devel] [PATCH 1/3] avformat/hlsenc: support mkdir_p for use_localtime_mkdir

[Steven Liu]

Tested-by: Zuo Genyu <1515161...@qq.com> (Windows)


2016-09-28 16:13 GMT+08:00 Steven Liu :

>
>
> 2016-09-27 21:56 GMT+08:00 Steven Liu :
>
>>
>>
>> 2016-09-27 6:50 GMT+08:00 Michael Niedermayer :
>>
>>> On Mon, Sep 26, 2016 at 04:04:32PM +0800, Steven Liu wrote:
>>> >
>>>
>>> >  hlsenc.c |   31 ++-
>>> >  1 file changed, 30 insertions(+), 1 deletion(-)
>>> > 8647c63d575b475e6e19b6427061787e39081bc4
>>> 0001-avformat-hlsenc-support-mkdir_p-for-use_localtime_mk.patch
>>> > From 4897d06fc1c9c4d9d302942b6e3ac8a8e25aa793 Mon Sep 17 00:00:00 2001
>>> > From: Steven Liu 
>>> > Date: Mon, 26 Sep 2016 13:50:31 +0800
>>> > Subject: [PATCH 1/3] avformat/hlsenc: support mkdir_p for
>>> use_localtime_mkdir
>>> >
>>> > when use use_localtime_mkdir to create multi level dir,
>>> > ffmpeg give error message:
>>> > ffmpeg -i ~/Movies/objectC/facebook.mp4 -c copy -use_localtime 1
>>> > -use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d/%s.ts'
>>> > out.m3u8
>>> > error message:
>>> > Could not create directory 20160926/file-20160926 with
>>> use_localtime_mkdir
>>> > add mkdir_p for support the multi level dir
>>> >
>>> > Signed-off-by: Steven Liu 
>>> > ---
>>> >  libavformat/hlsenc.c | 31 ++-
>>> >  1 file changed, 30 insertions(+), 1 deletion(-)
>>> >
>>> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>> > index 428bae4..ac79759 100644
>>> > --- a/libavformat/hlsenc.c
>>> > +++ b/libavformat/hlsenc.c
>>> > @@ -133,6 +133,35 @@ typedef struct HLSContext {
>>> >  double initial_prog_date_time;
>>> >  } HLSContext;
>>> >
>>> > +static int mkdir_p(const char *path) {
>>>
>>> > +char *temp = strdup(path);
>>>
>>> mixing malloc() based functions and av_malloc() is not safe
>>> av_strdup()
>>>
>>>
>>>
>>> > +char *pos = temp;
>>> > +
>>> > +if (!path) {
>>> > +return -1;
>>> > +}
>>> > +
>>> > +if (!strncmp(temp, "/", 1)) {
>>>
>>> missing allocation failure check
>>>
>>>
>>>
>>> > +pos++;
>>> > +} else if (!strncmp(temp, "./", 2)) {
>>> > +pos += 2;
>>> > +}
>>> > +for ( ; *pos != '\0'; ++pos) {
>>> > +if (*pos == '/') {
>>> > +*pos = '\0';
>>> > +mkdir(temp, 0755);
>>> > +*pos = '/';
>>> > +}
>>> > +}
>>> > +
>>> > +if (*(pos - 1) != '/') {
>>>
>>> all the '/' stuff looks non portable (windows)
>>>
>>> Hi Michael,
>>   Do you have any suggestion for portable (windows) with the
>> '/'(Linux/OSX/Unix) and '\'(Windows) ?
>>
>>>
>>> [...]
>>>
>>>
>>> --
>>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>>
>>> Old school: Use the lowest level language in which you can solve the
>>> problem
>>> conveniently.
>>> New school: Use the highest level language in which the latest
>>> supercomputer
>>> can solve the problem without the user falling asleep
>>> waiting.
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>> patch update
>>
>
>  and test passed on Windows
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales

[Steven Liu]

2016-09-27 9:05 GMT+08:00 Michael Niedermayer :

> On Mon, Sep 26, 2016 at 04:04:55PM +0800, Steven Liu wrote:
> >
>
> >  muxers.texi |6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 44f5601d940ca8826a22c66cdbbb640b1ee247c5  0002-doc-muxers-fix-error-for-
> hlsenc-exmpales.patch
> > From 513e8ab789eff6ca7ab4fffd13b3124db34e7d0e Mon Sep 17 00:00:00 2001
> > From: Steven Liu 
> > Date: Mon, 26 Sep 2016 13:56:58 +0800
>
> > Subject: [PATCH 2/3] doc/muxers: fix error for hlsenc exmpales
> 
> not a english word
>
>
> [...]
>
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The real ebay dictionary, page 2
> "100% positive feedback" - "All either got their money back or didnt
> complain"
> "Best seller ever, very honest" - "Seller refunded buyer after failed scam"
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> patch update.


0001-doc-muxers-refine-the-hlsenc-exmpales.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avformat/hlsenc: support mkdir_p for use_localtime_mkdir

[Steven Liu]

2016-09-27 21:56 GMT+08:00 Steven Liu :

>
>
> 2016-09-27 6:50 GMT+08:00 Michael Niedermayer :
>
>> On Mon, Sep 26, 2016 at 04:04:32PM +0800, Steven Liu wrote:
>> >
>>
>> >  hlsenc.c |   31 ++-
>> >  1 file changed, 30 insertions(+), 1 deletion(-)
>> > 8647c63d575b475e6e19b6427061787e39081bc4
>> 0001-avformat-hlsenc-support-mkdir_p-for-use_localtime_mk.patch
>> > From 4897d06fc1c9c4d9d302942b6e3ac8a8e25aa793 Mon Sep 17 00:00:00 2001
>> > From: Steven Liu 
>> > Date: Mon, 26 Sep 2016 13:50:31 +0800
>> > Subject: [PATCH 1/3] avformat/hlsenc: support mkdir_p for
>> use_localtime_mkdir
>> >
>> > when use use_localtime_mkdir to create multi level dir,
>> > ffmpeg give error message:
>> > ffmpeg -i ~/Movies/objectC/facebook.mp4 -c copy -use_localtime 1
>> > -use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d/%s.ts'
>> > out.m3u8
>> > error message:
>> > Could not create directory 20160926/file-20160926 with
>> use_localtime_mkdir
>> > add mkdir_p for support the multi level dir
>> >
>> > Signed-off-by: Steven Liu 
>> > ---
>> >  libavformat/hlsenc.c | 31 ++-
>> >  1 file changed, 30 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> > index 428bae4..ac79759 100644
>> > --- a/libavformat/hlsenc.c
>> > +++ b/libavformat/hlsenc.c
>> > @@ -133,6 +133,35 @@ typedef struct HLSContext {
>> >  double initial_prog_date_time;
>> >  } HLSContext;
>> >
>> > +static int mkdir_p(const char *path) {
>>
>> > +char *temp = strdup(path);
>>
>> mixing malloc() based functions and av_malloc() is not safe
>> av_strdup()
>>
>>
>>
>> > +char *pos = temp;
>> > +
>> > +if (!path) {
>> > +return -1;
>> > +}
>> > +
>> > +if (!strncmp(temp, "/", 1)) {
>>
>> missing allocation failure check
>>
>>
>>
>> > +pos++;
>> > +} else if (!strncmp(temp, "./", 2)) {
>> > +pos += 2;
>> > +}
>> > +for ( ; *pos != '\0'; ++pos) {
>> > +if (*pos == '/') {
>> > +*pos = '\0';
>> > +mkdir(temp, 0755);
>> > +*pos = '/';
>> > +}
>> > +}
>> > +
>> > +if (*(pos - 1) != '/') {
>>
>> all the '/' stuff looks non portable (windows)
>>
>> Hi Michael,
>   Do you have any suggestion for portable (windows) with the
> '/'(Linux/OSX/Unix) and '\'(Windows) ?
>
>>
>> [...]
>>
>>
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> Old school: Use the lowest level language in which you can solve the
>> problem
>> conveniently.
>> New school: Use the highest level language in which the latest
>> supercomputer
>> can solve the problem without the user falling asleep waiting.
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> patch update
>

 and test passed on Windows


0001-avformat-hlsenc-support-mkdir_p-for-use_localtime_mk.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel