Re: [FFmpeg-devel] [PATCH]lavc/gifdec: Do not error out on resolution bigger than screen size

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 03:05:27AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes ticket #6874 for me.
> I don't think it makes much sense to discuss what the specification
> means with "logical screen size" and "raster screen size" and
> "physical display": Not only do other decoders accept such files, our
> decoder already contains the necessary code to crop the image.
> I believe that it could at least be argued that the specification
> allows such files.
> 
> Please comment, Carl Eugen

>  gifdec.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 120f9d9fde11cb243440c9c4ba2051904bfc2c9c  
> 0001-lavc-gifdec-Do-not-error-out-if-resolution-is-bigger.patch
> From 47f5d312461a0d30cd1e70d819ae1daefbb5eebb Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 27 Nov 2017 02:57:50 +0100
> Subject: [PATCH] lavc/gifdec: Do not error out if resolution is bigger than
>  screen dimension.
> 
> This is what other decoders do.
> 
> Fixes ticket #6874.

this makes the decoder crash

[gif @ 0x25588b40] LZW decode failed
[gif @ 0x25588b40] LZW decode failedtime=00:00:00.10 bitrate=N/A speed=0.171x
Last message repeated 2 times
[gif @ 0x25588b40] Image too wide by 16384, truncating.
==1782== Invalid write of size 1
==1782==at 0x978928: ff_lzw_decode (in ffmpeg/ffmpeg_g)
==1782==by 0x893C47: gif_decode_frame (in ffmpeg/ffmpeg_g)
==1782==by 0x7F8976: decode_receive_frame_internal (in ffmpeg/ffmpeg_g)
==1782==by 0x7F9537: avcodec_send_packet (in ffmpeg/ffmpeg_g)
==1782==by 0x4C93CB: decode_video (in ffmpeg/ffmpeg_g)
==1782==by 0x4CC332: process_input (in ffmpeg/ffmpeg_g)
==1782==by 0x4AB176: main (in ffmpeg/ffmpeg_g)
==1782==  Address 0x257565db is 0 bytes after a block of size 91 alloc'd
==1782==at 0x4C2A6C5: memalign (vg_replace_malloc.c:727)
==1782==by 0x4C2A760: posix_memalign (vg_replace_malloc.c:876)
==1782==by 0x108446C: av_fast_malloc (in ffmpeg/ffmpeg_g)
==1782==by 0x8937D3: gif_decode_frame (in ffmpeg/ffmpeg_g)
==1782==by 0x7F8976: decode_receive_frame_internal (in ffmpeg/ffmpeg_g)
==1782==by 0x7F9537: avcodec_send_packet (in ffmpeg/ffmpeg_g)
==1782==by 0x4C93CB: decode_video (in ffmpeg/ffmpeg_g)
==1782==by 0x4CC332: process_input (in ffmpeg/ffmpeg_g)
==1782==by 0x4AB176: main (in ffmpeg/ffmpeg_g)


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

[FFmpeg-devel] [PATCH] avcodec: set correct return value in ff_mpeg_ref_picture

[Pan Bian]

In function ff_mpeg_ref_picture(), it returns 0 on the error path that
the return value of av_buffer_ref() is NULL. 0 indicates success, which
seems to deviate from the fact. Set ret to AVERROR(ENOMEM) to propagate
the error status to the callers.

Signed-off-by: Pan Bian 
---
 libavcodec/mpegpicture.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 2b72346..2be670c 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -375,8 +375,10 @@ int ff_mpeg_ref_picture(AVCodecContext *avctx, Picture 
*dst, Picture *src)
 
 if (src->hwaccel_picture_private) {
 dst->hwaccel_priv_buf = av_buffer_ref(src->hwaccel_priv_buf);
-if (!dst->hwaccel_priv_buf)
+if (!dst->hwaccel_priv_buf) {
+ret = AVERROR(ENOMEM);
 goto fail;
+}
 dst->hwaccel_picture_private = dst->hwaccel_priv_buf->data;
 }
 
-- 
1.9.1


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

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Timo Rothenpieler
> Sent: November 27, 2017 5:08 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] AMD external header
> 
> Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail:
> > Hi,
> > I would like to summarize thoughts on several threads on this forum
> > related to the issue of including AMD/AMF header file into FFmpeg source
> tree.
> > It looks like they reflect some policies formal or informal.
> > Mark tried to create some policy regarding this issue but wasn't successful.
> > I believe a policy is always created to reach some goal.
> > So my summary will be in form of triad:
> > policy->goal->possible action
> > I will skip all arguments, you already read them.
> > #1
> > policy: do not include external headers
> > goal: minimize maintenance efforts and increase stability of the project
> > action: remove NVidia headers
> > #2
> > policy: keep certain headers in the tree based on some criteria
> > goal: provide certain level of convenience for ordinary users
> > action: include AMD header
> 
> As I have stated before, I am fine with shipping the header, and would prefer
> it over having to collect a bunch of headers from various repositories.
> To limit it a bit, I'd say in-tree external headers should be limited to 
> header-
> only interfaces to system-libraries(The nvidia and amd drivers count as
> system libs) or other extreme cases like AviSynth.

This sounds like a good policy. How would we move from there on practical terms?

> 
> > #3
> >policy: do whatever is needed to achieve the goal
> >goal: achieve neutrality in relation to HW vendors
> >action: remove NVidia headers or add AMD header
> >

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[James Almer]

On 11/27/2017 6:00 AM, Tobias Rapp wrote:
> On 26.11.2017 21:51, James Almer wrote:
>> Every bitstream filter behaves as intended now, so there's no need to
>> wait for the first packet of every stream.
>>
>> Signed-off-by: James Almer 
>> ---
>>   libavformat/avformat.h |  2 +-
>>   libavformat/internal.h |  6 -
>>   libavformat/mux.c  | 52
>> --
>>   libavformat/options_table.h    |  2 +-
>>   libavformat/tests/fifo_muxer.c | 52
>> --
>>   tests/ref/fate/fifo-muxer-tst  |  1 -
>>   6 files changed, 12 insertions(+), 103 deletions(-)
>>
>> [...]
> 
> I'm just curious: Will this fix ticket #6375?
> 
> Regards,
> Tobias

Unlikely. That's from ffmpeg.c buffering logic which I'm not changing here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> >
> > I also noticed that recently there is a lot of activity to add full Nvidia
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
> > I am guessing this is to overcome DXVA or VAAPI shortcoming. What about
> AMD? We also have them.
> >
> >
> 
> DXVA2/D3D11VA work perfectly fine, on Windows i see no huge reason to
> use NVDEC (and the same can probably be said for whatever AMD
> solution) - and in fact from a user (and developer) perspective its much nicer
> to just use the same hwaccel on all hardware. But Linux is another matter. I
> don't know how well AMD works with VAAPI or VDPAU (if at all), but at least
> for NVIDIA VDPAU has its issues and VAAPI is not supported at all (except
> with a VAAPI VDPAU adapter, which  has the same issues, obviously)
> 
> Until you guys actually provide Linux support, adding a HWAccel might not be
> that advantageous for the user-base.

Thanks for the explanations. I don’t want to add more codecs just for sake of 
adding.
I will check if DXVA2/D3D11VA implementation has shortcomings and propose 
additions 
only if it is really needed. The same on Linux: we will see what driver team 
will provide on 
Linux and if AMF-based codec are needed to be integrated.
I will concentrate more on GPU color converter filter: with it user should be 
able to 
create fully accelerated pipeline.

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

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

Re: [FFmpeg-devel] avcodec/samidec: check av_strdup() return value

[Moritz Barsnick]

On Mon, Nov 27, 2017 at 08:53:22 +0800, Pan Bian wrote:
> + if (!dupsrc)
> + return AVERROR(ENOMEM);
> +

Tabs are not allowed, please check your indentation. You can use
tools/patcheck to find these kinds of issues.

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

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Mironov, Mikhail (2017-11-27):
> #1
>policy: do not include external headers
>goal: minimize maintenance efforts and increase stability of the project
>action: remove NVidia headers

Add to the goal: avoid being complicit of free-riders on the Libre
software bandwagon.

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 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

[Henrik Gramner]

>> Using 128-bit broadcasts is preferable over duplicating the constants
>> to 256-bit unless there's a good reason for doing so since it wastes
>> less cache and is faster on AMD CPU:s.
>
> What would that reason be? Afaik broadcasts are expensive, since they
> both load from memory then splat data across lanes. Using them inside
> loops doesn't sound like a good idea. But i guess you have more
> experience testing with more varied chips than i do.

128-bit broadcasts from memory are done in the load unit for free on
all AVX2-capable CPU:s.

> Also, by AMD cpus you mean Ryzen? Because on Bulldozer-based CPUs we
> purposely disabled functions using ymm regs.

Yes. 128-bit broadcasts have twice the throughput compared to 256-bit
loads on Ryzen since it only has 128-bit load units.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/matroskaenc: move some initialization checks to mkv_init

[James Almer]

It's the correct place for them.

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

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 06126781f8..35857bb02e 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1859,25 +1859,7 @@ static int mkv_write_header(AVFormatContext *s)
 av_dict_get(s->metadata, "alpha_mode", NULL, 0))
 version = 4;
 
-if (s->nb_streams > MAX_TRACKS) {
-av_log(s, AV_LOG_ERROR,
-   "At most %d streams are supported for muxing in Matroska\n",
-   MAX_TRACKS);
-return AVERROR(EINVAL);
-}
-
 for (i = 0; i < s->nb_streams; i++) {
-if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_ATRAC3 ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_COOK ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RA_288 ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_SIPR ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV10 ||
-s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV20) {
-av_log(s, AV_LOG_ERROR,
-   "The Matroska muxer does not yet support muxing %s\n",
-   avcodec_get_name(s->streams[i]->codecpar->codec_id));
-return AVERROR_PATCHWELCOME;
-}
 if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
 av_dict_get(s->streams[i]->metadata, "stereo_mode", NULL, 0) ||
 av_dict_get(s->streams[i]->metadata, "alpha_mode", NULL, 0))
@@ -2656,6 +2638,27 @@ static int mkv_init(struct AVFormatContext *s)
 {
 int i;
 
+if (s->nb_streams > MAX_TRACKS) {
+av_log(s, AV_LOG_ERROR,
+   "At most %d streams are supported for muxing in Matroska\n",
+   MAX_TRACKS);
+return AVERROR(EINVAL);
+}
+
+for (i = 0; i < s->nb_streams; i++) {
+if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_ATRAC3 ||
+s->streams[i]->codecpar->codec_id == AV_CODEC_ID_COOK ||
+s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RA_288 ||
+s->streams[i]->codecpar->codec_id == AV_CODEC_ID_SIPR ||
+s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV10 ||
+s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV20) {
+av_log(s, AV_LOG_ERROR,
+   "The Matroska muxer does not yet support muxing %s\n",
+   avcodec_get_name(s->streams[i]->codecpar->codec_id));
+return AVERROR_PATCHWELCOME;
+}
+}
+
 if (s->avoid_negative_ts < 0) {
 s->avoid_negative_ts = 1;
 s->internal->avoid_negative_ts_use_pts = 1;
-- 
2.15.0

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

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

[Martin Vignali]

2017-11-27 17:59 GMT+01:00 Henrik Gramner :

> On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali
>  wrote:
> > Hello,
> >
> > In attach patch to convert pb_bswap32 to ymm constant
> > and remove the vbroadcasti128 part
> >
> > Speed seems to be similar to me
>
> This just wastes cache for no reason. A tiny amount, sure, but minor
> things tends to add up eventually.
>
> 128-bit broadcasts are the same speed as 256-bit loads on Intel CPU:s
> and twice as fast as 256-bit loads on AMD CPU:s.
>
> A better solution if you want to avoid ifdeffery would be to create a
> macro that uses vbroadcasti128 when mmsize == 32 and mova otherwise.
> ___
>
>
Hello,

Thanks for your comments.
Do you have an idea, for the name of this macro ?

Relative to previous patch similar to this in discussion :
avcodec/x86/exrdsp : use ymm constant for pb_80 instead of vbroadcasti128

Do you think, we need to not use YMM constant (declare in constants.h/c),
and convert the constantes to XMM in this file, with a vbroadcasti128 load ?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavd/alsa: Double maximum alsa buffer size.

[Nicolas George]

Carl Eugen Hoyos (2017-11-27):
> ffmpeg | branch: master | Carl Eugen Hoyos  | Mon Nov 27 
> 14:05:28 2017 +0100| [b7324950c0fc84a93d4e7abdfd2b75ea647ec3fc] | committer: 
> Carl Eugen Hoyos
> 
> lavd/alsa: Double maximum alsa buffer size.
> 
> Fixes recording from ATI Wonder 600 USB adapter, regression since e35c674d.

Why was this pushed without discussion?

> Reported and analyzed by: Marco Paolieri, paolieri at gmail

This is no analyze, just empirical guesswork.

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] AMD external header

[Timo Rothenpieler]

Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail:

Hi,
I would like to summarize thoughts on several threads on this forum related
to the issue of including AMD/AMF header file into FFmpeg source tree.
It looks like they reflect some policies formal or informal.
Mark tried to create some policy regarding this issue but wasn't successful.
I believe a policy is always created to reach some goal.
So my summary will be in form of triad:
policy->goal->possible action
I will skip all arguments, you already read them.
#1
policy: do not include external headers
goal: minimize maintenance efforts and increase stability of the project
action: remove NVidia headers
#2
policy: keep certain headers in the tree based on some criteria
goal: provide certain level of convenience for ordinary users
action: include AMD header
#3
   policy: do whatever is needed to achieve the goal
   goal: achieve neutrality in relation to HW vendors
   action: remove NVidia headers or add AMD header

Since these policies contradict each other, some priorities should be set
and I don't know how to do it. Personally I like #2 the most, but this is not 
my call.
But my point is that by keeping NVidia headers in the tree and not allowing AMD 
header,
FFmpeg development team breaks all three policies and do not achieve any goal.
If this is what you want maybe you should state this explicitly on the "About" 
page
as Mark suggested:
"No external headers may be added to the ffmpeg tree, unless they are for AviSynth 
or Nvidia"
At least it will be clear for all users and developers.
You may say that you will include only headers hard to get. But does it mean 
that AMD must
obscure access to the headers to be included? I hope not.


I also want to mention, while I prefer to include the header, if the 
final decision is to get rid of them(which imo is the only viable other 
option), I will not fight that.


In that case I would move the nvidia headers to a repository on 
github.com/FFmpeg, if that's ok with everyone, to keep them in a 
somewhat ffmpeg-official state.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

[Henrik Gramner]

On Sun, Nov 26, 2017 at 11:51 PM, James Darnley  wrote:
> -pd_0_int_min: times  2 dd 0, -2147483648
> -pq_int_min:   times  2 dq -2147483648
> -pq_int_max:   times  2 dq  2147483647
> +pd_0_int_min: times  4 dd 0, -2147483648
> +pq_int_min:   times  4 dq -2147483648
> +pq_int_max:   times  4 dq  2147483647

Using 128-bit broadcasts is preferable over duplicating the constants
to 256-bit unless there's a good reason for doing so since it wastes
less cache and is faster on AMD CPU:s.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

[James Almer]

On 11/27/2017 1:50 PM, Henrik Gramner wrote:
> On Sun, Nov 26, 2017 at 11:51 PM, James Darnley  
> wrote:
>> -pd_0_int_min: times  2 dd 0, -2147483648
>> -pq_int_min:   times  2 dq -2147483648
>> -pq_int_max:   times  2 dq  2147483647
>> +pd_0_int_min: times  4 dd 0, -2147483648
>> +pq_int_min:   times  4 dq -2147483648
>> +pq_int_max:   times  4 dq  2147483647
> 
> Using 128-bit broadcasts is preferable over duplicating the constants
> to 256-bit unless there's a good reason for doing so since it wastes
> less cache and is faster on AMD CPU:s.

What would that reason be? Afaik broadcasts are expensive, since they
both load from memory then splat data across lanes. Using them inside
loops doesn't sound like a good idea. But i guess you have more
experience testing with more varied chips than i do.

Also, by AMD cpus you mean Ryzen? Because on Bulldozer-based CPUs we
purposely disabled functions using ymm regs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

[Henrik Gramner]

On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali
 wrote:
> Hello,
>
> In attach patch to convert pb_bswap32 to ymm constant
> and remove the vbroadcasti128 part
>
> Speed seems to be similar to me

This just wastes cache for no reason. A tiny amount, sure, but minor
things tends to add up eventually.

128-bit broadcasts are the same speed as 256-bit loads on Intel CPU:s
and twice as fast as 256-bit loads on AMD CPU:s.

A better solution if you want to avoid ifdeffery would be to create a
macro that uses vbroadcasti128 when mmsize == 32 and mova otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.


Well that is definitely not going to happen.
Nobody will watch over API/ABI compatibility in those headers.
If you need them, get them yourself.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] AMD external header

[Pavel Koshevoy]

On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George  wrote:
> Mironov, Mikhail (2017-11-27):
>> #1
>>policy: do not include external headers
>>goal: minimize maintenance efforts and increase stability of the project
>>action: remove NVidia headers
>
> Add to the goal: avoid being complicit of free-riders on the Libre
> software bandwagon.

That is unnecessarily un-diplomatic and will likely offend the
contributors from nvidia and amd.

Personally, I would prefer if the bundled external headers were
installed together with ffmpeg public headers (so nvenc/cuda/etc...
weren't simply private headers within ffmpeg).  There are some nvenc
APIs I need to query hardware capabilities to avoid setting nvenc
codec parameters that would cause the codec to fail to initialize via
ffmpeg apis.  Given that ffmpeg already includes the headers that
declare those APIs I've been able to use them without installing nvenc
SDK separately, but since they are private headers in the ffmpeg
source tree it feels dirty to do that.

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

[Bjorn Roche]

Sorry for the very delayed response, Carl:

On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-21 18:53 GMT+01:00 Bjorn Roche :
> > Support for transparencies in animated gifs requires modifying both
> > libavcodec/gif.c and libavformat/gif.c because both the graphics
> > control extension (handled by libavformat/gif.c) and the raw frame data
> > (handled by libavcodec/gif.c) must be changed.
>
> Does remuxing animated gif with transparency work with your patch?
>

A command like this:

ffmpeg -i in.gif out.gif

seems to produce the same output as before: transparency replaces with
opacity. However a command like this:

ffmpeg -i in.gif  -vf palettegen -y /tmp/pal.png && ffmpeg -i in.gif
-i /tmp/pal.png -lavfi paletteuse -y -f gif out.gif


produces an output that looks like the input (including transparency).


I believe this is a problem with the decoder, however, since


ffmpeg -i /Users/bjorn/Desktop/smoketrail.gif
/Users/bjorn/Desktop/smoketrail-out%d.png


produces opaque images as well.

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

[James Almer]

On 11/27/2017 2:17 PM, Martin Vignali wrote:
> 2017-11-27 17:59 GMT+01:00 Henrik Gramner :
> 
>> On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali
>>  wrote:
>>> Hello,
>>>
>>> In attach patch to convert pb_bswap32 to ymm constant
>>> and remove the vbroadcasti128 part
>>>
>>> Speed seems to be similar to me
>>
>> This just wastes cache for no reason. A tiny amount, sure, but minor
>> things tends to add up eventually.
>>
>> 128-bit broadcasts are the same speed as 256-bit loads on Intel CPU:s
>> and twice as fast as 256-bit loads on AMD CPU:s.
>>
>> A better solution if you want to avoid ifdeffery would be to create a
>> macro that uses vbroadcasti128 when mmsize == 32 and mova otherwise.
>> ___
>>
>>
> Hello,
> 
> Thanks for your comments.
> Do you have an idea, for the name of this macro ?

It doesn't currently exist, so look at the existing ones in x86utils.asm
and add one for vbroadcasti128.

> 
> Relative to previous patch similar to this in discussion :
> avcodec/x86/exrdsp : use ymm constant for pb_80 instead of vbroadcasti128
> 
> Do you think, we need to not use YMM constant (declare in constants.h/c),
> and convert the constantes to XMM in this file, with a vbroadcasti128 load ?

There's no need to convert them back to xmm to use broadcasts.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] avfilter/avf_ahistogram: return correct error code

[Pan Bian]

In function query_formats(), it incorrectly returns 0 when the function
ff_all_channel_counts() returns a NULL pointer (the check of variable
ret before the NULL check guarantees that the return value is not
negative).

Signed-off-by: Pan Bian 
---
 libavfilter/avf_ahistogram.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/avf_ahistogram.c b/libavfilter/avf_ahistogram.c
index 5874151..1b779da 100644
--- a/libavfilter/avf_ahistogram.c
+++ b/libavfilter/avf_ahistogram.c
@@ -97,9 +97,11 @@ static int query_formats(AVFilterContext *ctx)
 int ret = AVERROR(EINVAL);
 
 formats = ff_make_format_list(sample_fmts);
-if ((ret = ff_formats_ref (formats, >out_formats)) 
< 0 ||
-(layouts = ff_all_channel_counts()) == NULL ||
-(ret = ff_channel_layouts_ref (layouts, >out_channel_layouts)) 
< 0)
+if ((ret = ff_formats_ref(formats, >out_formats)) < 0)
+return ret;
+if (!(layouts = ff_all_channel_counts()))
+return AVERROR(ENOMEM);
+if ((ret = ff_channel_layouts_ref(layouts, >out_channel_layouts)) 
< 0)
 return ret;
 
 formats = ff_all_samplerates();
-- 
1.9.1


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

[FFmpeg-devel] Codec of Audio G.722.1

[Jacky]

Hello,

 

I am working for codec of  G.722.1 audio on the iOS, the version that I use
is the latest version 3.4, but it always failed, the detail info is as
following: 

[cook @ 0x7fac22815200] Cook version 1297043023 is not implemented. Update
your FFmpeg version to the newest one from Git. If the problem still occurs,
it means that your file has a feature which has not been implemented.

[cook @ 0x7fac22815200] If you want to help, upload a sample of this file to
ftp://upload.ffmpeg.org/incoming/ and contact the ffmpeg-devel mailing list.
(ffmpeg-devel@ffmpeg.org  )

 

can you please give some suggestion to solve this question, if available,
can you please provide a sample to guide me how to do this.

 

thanks

Jacky
IOS Developer 




 


Rm 501, Kaxiu Building, N0.7 Huoju Road,High Tech Industry Zone, Dalian,
China
China Office: +86 (0411) 3957 1279

  Website |
 vCard |
 Maps |  
Email  
    

 

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

Re: [FFmpeg-devel] [PATCH] libvpxenc, vp9: add corpus-complexity option

[James Zern]

On Mon, Nov 20, 2017 at 5:36 PM, James Zern  wrote:
> Corpus VBR mode is a variant of standard VBR where the complexity
> distribution midpoint is passed in rather than calculated for a specific
> clip or chunk.
>
> The valid range is [0, 1]. 0 (default) uses standard VBR.
>
> Signed-off-by: James Zern 
> ---
>  doc/encoders.texi  |  5 +
>  libavcodec/libvpxenc.c | 16 
>  2 files changed, 21 insertions(+)
>

I'll submit this soon if there aren't any comments.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

[Vittorio Giovara]

> On 11/27/2017 5:20 PM, James Almer wrote:
> Where are these two defined? Because
> https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md
> describes coll and smdm, and those are already supported.

these are unrelated to vp9 (or mp4), they are the mov-only atoms used by
some upcoming tools to signal hdr
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Bjorn Roche]

Thanks Moritz and Carl for your help with fate. This email was stuck in my
drafts :(

Comments below:

On Fri, Nov 3, 2017 at 8:11 PM, Carl Eugen Hoyos  wrote:

> 2017-10-24 18:40 GMT+02:00 Bjorn Roche :
>
> > - I don’t know if/how to update the FATE tests.
>
> A quick way (that needs some double-checking) is:
> $ make GEN=1 SAMPLES=fate-suite fate
>
> (This overwrites all values with the new output.)
>

Thanks. I ended up doing it manually to be sure, but this is useful!


> Is the new side-data unavoidable?
> (Would the only alternative be to merge the muxer into the
> encoder?)
>

The only way I can see is to move some functionality between the mixer and
the encoder. It's not a clear line between the codec and the container in
GIF, so I wouldn't object to an approach different from the one I took.

bjorn


-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

[FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

[Martin Vignali]

Hello

Following suggestion by Henrik Gramner

in attach a patch to add a macro in x86_utils.asm
in order to load a 128 bits constantes in an XMM register
or in each part of a ZMM register

Not sure about the name of this macro, and the position in the x86utils file

Patch 002 :
Use this new macro, in bswap dsp


Martin


0003-avutil-x86util-add-macro-for-loading-a-128-bits.patch
Description: Binary data


0004-avcodec-x86-bswapdsp-use-macro-for-128-bits-constant.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

From: mmironov 

Requires AMF headers for at least version 1.4.2 (older versions do not
support building with C).
---
Uses upstream headers from 
.
  I couldn't find an official install method so I've assumed that the AMF 
headers are under an AMF/ prefix (they have rather generic names, so they need 
something).  Just copying the two directories from the source path to 
/usr/local/include/AMF or similar is sufficient.

I've also assumed that the features which don't yet exist upstream (H.264 
CONSTRAINED profiles) will appear in a future version 1.5.0.  There might be 
more version checking needed, but I'm not sure (newer version / older header 
should work because of the version initialisation, while older version / newer 
header fails at that maybe?).

The OS checks are removed, it builds fine on Linux if you have the headers.


 Changelog|   1 +
 configure|   9 +
 libavcodec/Makefile  |   4 +
 libavcodec/allcodecs.c   |   2 +
 libavcodec/amfenc.c  | 611 +++
 libavcodec/amfenc.h  | 154 
 libavcodec/amfenc_h264.c | 399 +++
 libavcodec/amfenc_hevc.c | 326 +
 8 files changed, 1506 insertions(+)
 create mode 100644 libavcodec/amfenc.c
 create mode 100644 libavcodec/amfenc.h
 create mode 100644 libavcodec/amfenc_h264.c
 create mode 100644 libavcodec/amfenc_hevc.c

diff --git a/Changelog b/Changelog
index afead72f14..7a913bf7a7 100644
--- a/Changelog
+++ b/Changelog
@@ -21,6 +21,7 @@ version :
 - video mix filter
 - video normalize filter
 - audio lv2 wrapper filter
+- AMD AMF H.264 and HEVC encoders
 
 
 version 3.4:
diff --git a/configure b/configure
index 6748ef8bc9..96fdd8eca4 100755
--- a/configure
+++ b/configure
@@ -304,6 +304,7 @@ External library support:
   --disable-zlib   disable zlib [autodetect]
 
   The following libraries provide various hardware acceleration features:
+  --disable-amfdisable AMF video encoding code [autodetect]
   --disable-audiotoolbox   disable Apple AudioToolbox code [autodetect]
   --disable-cuda   disable dynamically linked Nvidia CUDA code 
[autodetect]
   --enable-cuda-sdkenable CUDA features that require the CUDA SDK [no]
@@ -1639,6 +1640,7 @@ EXTERNAL_LIBRARY_LIST="
 "
 
 HWACCEL_AUTODETECT_LIBRARY_LIST="
+amf
 audiotoolbox
 crystalhd
 cuda
@@ -2782,12 +2784,14 @@ scale_npp_filter_deps="cuda libnpp"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
+amf_deps_any="libdl LoadLibrary"
 nvenc_deps="cuda"
 nvenc_deps_any="libdl LoadLibrary"
 nvenc_encoder_deps="nvenc"
 
 h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
 h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
+h264_amf_encoder_deps="amf"
 h264_crystalhd_decoder_select="crystalhd h264_mp4toannexb_bsf h264_parser"
 h264_cuvid_decoder_deps="cuvid"
 h264_cuvid_decoder_select="h264_mp4toannexb_bsf"
@@ -2804,6 +2808,7 @@ h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
 h264_vaapi_encoder_select="cbs_h264 vaapi_encode"
 h264_v4l2m2m_decoder_deps="v4l2_m2m h264_v4l2_m2m"
 h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m"
+hevc_amf_encoder_deps="amf"
 hevc_cuvid_decoder_deps="cuvid"
 hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf"
 hevc_mediacodec_decoder_deps="mediacodec"
@@ -6194,6 +6199,10 @@ void f(void) { struct { const GUID guid; } s[] = { { 
NV_ENC_PRESET_HQ_GUID } };
 int main(void) { return 0; }
 EOF
 
+enabled amf &&
+check_type "AMF/core/Factory.h" AMFFactory ||
+disable amf
+
 # Funny iconv installations are not unusual, so check it after all flags have 
been set
 if enabled libc_iconv; then
 check_func_headers iconv.h iconv
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index a6203d424b..ab7893f560 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -55,6 +55,7 @@ OBJS = ac3_parser.o   
  \
 OBJS-$(CONFIG_AANDCTTABLES)+= aandcttab.o
 OBJS-$(CONFIG_AC3DSP)  += ac3dsp.o ac3.o ac3tab.o
 OBJS-$(CONFIG_ADTS_HEADER) += adts_header.o mpeg4audio.o
+OBJS-$(CONFIG_AMF) += amfenc.o
 OBJS-$(CONFIG_AUDIO_FRAME_QUEUE)   += audio_frame_queue.o
 OBJS-$(CONFIG_AUDIODSP)+= audiodsp.o
 OBJS-$(CONFIG_BLOCKDSP)+= blockdsp.o
@@ -337,6 +338,7 @@ OBJS-$(CONFIG_H264_DECODER)+= h264dec.o 
h264_cabac.o h264_cavlc.o \
   h264_mb.o h264_picture.o \
   h264_refs.o h264_sei.o \
   h264_slice.o h264data.o
+OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
 OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
 OBJS-$(CONFIG_H264_MEDIACODEC_DECODER) += mediacodecdec.o
 

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

[James Almer]

On 11/27/2017 5:20 PM, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara 
> ---
>  libavformat/mov.c | 71 
> +++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 79023ef369..bb463017a3 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -5072,6 +5072,51 @@ static int mov_read_smdm(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +static int mov_read_mdcv(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +MOVStreamContext *sc;
> +const int mapping[3] = {1, 2, 0};
> +const int chroma_den = 5;
> +const int luma_den = 1;
> +int i;
> +
> +if (c->fc->nb_streams < 1)
> +return AVERROR_INVALIDDATA;
> +
> +sc = c->fc->streams[c->fc->nb_streams - 1]->priv_data;
> +
> +if (atom.size < 24) {
> +av_log(c->fc, AV_LOG_ERROR, "Invalid Mastering Display Color Volume 
> box\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +sc->mastering = av_mastering_display_metadata_alloc();
> +if (!sc->mastering)
> +return AVERROR(ENOMEM);
> +
> +for (i = 0; i < 3; i++) {
> +const int j = mapping[i];
> +sc->mastering->display_primaries[j][0].num = avio_rb16(pb);
> +sc->mastering->display_primaries[j][0].den = chroma_den;
> +sc->mastering->display_primaries[j][1].num = avio_rb16(pb);
> +sc->mastering->display_primaries[j][1].den = chroma_den;
> +}
> +sc->mastering->white_point[0].num = avio_rb16(pb);
> +sc->mastering->white_point[0].den = chroma_den;
> +sc->mastering->white_point[1].num = avio_rb16(pb);
> +sc->mastering->white_point[1].den = chroma_den;
> +
> +sc->mastering->max_luminance.num = avio_rb32(pb);
> +sc->mastering->max_luminance.den = luma_den;
> +sc->mastering->min_luminance.num = avio_rb32(pb);
> +sc->mastering->min_luminance.den = luma_den;
> +
> +sc->mastering->has_luminance = 1;
> +sc->mastering->has_primaries = 1;
> +
> +return 0;
> +}
> +
>  static int mov_read_coll(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  MOVStreamContext *sc;
> @@ -5104,6 +5149,30 @@ static int mov_read_coll(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  return 0;
>  }
>  
> +static int mov_read_clli(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> +{
> +MOVStreamContext *sc;
> +
> +if (c->fc->nb_streams < 1)
> +return AVERROR_INVALIDDATA;
> +
> +sc = c->fc->streams[c->fc->nb_streams - 1]->priv_data;
> +
> +if (atom.size < 4) {
> +av_log(c->fc, AV_LOG_ERROR, "Empty Content Light Level Info box\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +sc->coll = av_content_light_metadata_alloc(>coll_size);
> +if (!sc->coll)
> +return AVERROR(ENOMEM);
> +
> +sc->coll->MaxCLL  = avio_rb16(pb);
> +sc->coll->MaxFALL = avio_rb16(pb);
> +
> +return 0;
> +}
> +
>  static int mov_read_st3d(MOVContext *c, AVIOContext *pb, MOVAtom atom)
>  {
>  AVStream *st;
> @@ -5912,6 +5981,8 @@ static const MOVParseTableEntry 
> mov_default_parse_table[] = {
>  { MKTAG('S','m','D','m'), mov_read_smdm },
>  { MKTAG('C','o','L','L'), mov_read_coll },
>  { MKTAG('v','p','c','C'), mov_read_vpcc },
> +{ MKTAG('m','d','c','v'), mov_read_mdcv },
> +{ MKTAG('c','l','l','i'), mov_read_clli },
>  { 0, NULL }
>  };

Where are these two defined? Because
https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md
describes coll and smdm, and those are already supported.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libavdevice/decklink: Add support for EIA-708 output over SDI

[Marton Balint]

On Thu, 16 Nov 2017, Devin Heitmueller wrote:


Hook in libklvanc and use it for output of EIA-708 captions over
SDI.  The bulk of this patch is just general support for ancillary
data for the Decklink SDI module - the real work for construction
of the EIA-708 CDP and VANC line construction is done by libklvanc.

Libklvanc can be found at: https://github.com/stoth68000/libklvanc

Updated to reflect feedback from Marton Balint 


Sorry for the delayed response, comments are below:



Signed-off-by: Devin Heitmueller 
---
configure   |   4 ++
libavcodec/v210enc.c|  12 
libavdevice/decklink_common.cpp |  17 +++--
libavdevice/decklink_common.h   |  10 +++
libavdevice/decklink_enc.cpp| 150 ++--
5 files changed, 183 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index 934ac3a..d5e3dcc 100755
--- a/configure
+++ b/configure
@@ -238,6 +238,7 @@ External library support:
  --enable-libiec61883 enable iec61883 via libiec61883 [no]
  --enable-libilbc enable iLBC de/encoding via libilbc [no]
  --enable-libjack enable JACK audio sound server [no]
+  --enable-libklvanc   enable Kernel Labs VANC processing [no]
  --enable-libkvazaar  enable HEVC encoding via libkvazaar [no]
  --enable-libmodplug  enable ModPlug via libmodplug [no]
  --enable-libmp3lame  enable MP3 encoding via libmp3lame [no]
@@ -1602,6 +1603,7 @@ EXTERNAL_LIBRARY_LIST="
libiec61883
libilbc
libjack
+libklvanc
libkvazaar
libmodplug
libmp3lame
@@ -3076,6 +3078,7 @@ decklink_deps_any="libdl LoadLibrary"
decklink_indev_deps="decklink threads"
decklink_indev_extralibs="-lstdc++"
decklink_outdev_deps="decklink threads"
+decklink_outdev_suggest="libklvanc"
decklink_outdev_extralibs="-lstdc++"
libndi_newtek_indev_deps="libndi_newtek"
libndi_newtek_indev_extralibs="-lndi"
@@ -5847,6 +5850,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h" 
"gsm/gsm.h"; do
   check_lib libgsm "${gsm_hdr}" gsm_create -lgsm 
&& break;
   done || die "ERROR: libgsm not found"; }
enabled libilbc   && require libilbc ilbc.h WebRtcIlbcfix_InitDecode 
-lilbc $pthreads_extralibs
+enabled libklvanc && require libklvanc libklvanc/vanc.h 
klvanc_context_create -lklvanc
enabled libkvazaar&& require_pkg_config libkvazaar "kvazaar >= 0.8.1" 
kvazaar.h kvz_api_get
# While it may appear that require is being used as a pkg-config
# fallback for libmfx, it is actually being used to detect a different
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a6afbbf..a825c03 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -123,6 +123,7 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
int aligned_width = ((avctx->width + 47) / 48) * 48;
int stride = aligned_width * 8 / 3;
int line_padding = stride - ((avctx->width * 8 + 11) / 12) * 4;
+AVFrameSideData *side_data;
int h, w, ret;
uint8_t *dst;

@@ -233,6 +234,17 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
}
}

+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_A53_CC);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_A53_CC, 
side_data->size);
+if (buf) {
+memcpy(buf, side_data->data, side_data->size);
+} else {
+av_log(avctx, AV_LOG_ERROR, "Unable to allocate side data\n");


For ENOMEM, I think you can skip the error message.


+return AVERROR(ENOMEM);
+}
+}
+
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 2bd63ac..c425f4a 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -247,10 +247,19 @@ int ff_decklink_set_format(AVFormatContext *avctx,
   , NULL) != S_OK)
return -1;
} else {
-if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, bmdFormat8BitYUV,
-   bmdVideoOutputFlagDefault,
-   , NULL) != S_OK)
-return -1;
+ctx->supports_vanc = 1;
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
ctx->raw_format,
+   bmdVideoOutputVANC,
+   , NULL) != S_OK) {
+/* Try again, but without VANC enabled */
+if (ctx->dlo->DoesSupportVideoMode(ctx->bmd_mode, (BMDPixelFormat) 
ctx->raw_format,
+   bmdVideoOutputFlagDefault,
+   , NULL) != S_OK) {
+return -1;
+}
+ctx->supports_vanc = 0;
+}
+
}
 

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

[Vittorio Giovara]

>* On 11/27/2017 5:20 PM, James Almer wrote:*> Pointless duplicate atoms :/ At 
>least these don't use fixed point
> values, so they are nicer.

indeed

> I assume no file will have both smdm and mdcv, or coll and clli, so
> reusing the MOVStreamContext fields should be ok, but maybe free the
> pointers first?
that's very unlikely as one set is defined for iso files (.mp4) and
the other one for qtff files (.mov).
if you think that is still needed, I'll go ahead and add that to a
separate patch

> Can't comment about the implementation as i don't have access to the spec.

if it helps, mediainfo got these properties too
https://github.com/MediaArea/MediaInfoLib/commit/818f2fd4fdfadf2dbb8cc010b1c35e8cf3ada504
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 27, 2017 3:11 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> From: mmironov 
> 
> Requires AMF headers for at least version 1.4.2 (older versions do not
> support building with C).
> ---
> Uses upstream headers from  LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't find an
> official install method so I've assumed that the AMF headers are under an
> AMF/ prefix (they have rather generic names, so they need something).  Just
> copying the two directories from the source path to /usr/local/include/AMF
> or similar is sufficient.
> 
> I've also assumed that the features which don't yet exist upstream (H.264
> CONSTRAINED profiles) will appear in a future version 1.5.0.  There might be
> more version checking needed, but I'm not sure (newer version / older
> header should work because of the version initialisation, while older version
> / newer header fails at that maybe?).
> 
> The OS checks are removed, it builds fine on Linux if you have the headers.
> 

The public headers from github do not have several fixes that were done in the 
customized header. 
I could cherry-pick and push them but I did not test this for a while assuming 
that the custom header is used.

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

Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

[James Almer]

On 11/27/2017 7:33 PM, James Darnley wrote:
> On 2017-11-27 20:19, Martin Vignali wrote:
>> +%macro VBROADCASTI128 2 ; dst xmm/ymm, src : 128bits val
>> +%if mmsize == 32
>> +vbroadcasti128 %1, %2
>> +%else
>> +mova   %1, %2
>> +%endif
>> +%endmacro
> 
> If the condition was made "mmsize > 16" would this work correctly for
> zmm registers?  (Assume I finally push my AVX-512 patches).

No, there's no EVEX variant of vbroadcasti128. For that you would need
to use vbroadcasti32x4 or vbroadcasti64x2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

[Carl Eugen Hoyos]

2017-11-27 18:50 GMT+01:00 Bjorn Roche :
> Sorry for the very delayed response, Carl:
>
> On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-11-21 18:53 GMT+01:00 Bjorn Roche :
>> > Support for transparencies in animated gifs requires modifying both
>> > libavcodec/gif.c and libavformat/gif.c because both the graphics
>> > control extension (handled by libavformat/gif.c) and the raw frame data
>> > (handled by libavcodec/gif.c) must be changed.
>>
>> Does remuxing animated gif with transparency work with your patch?
>
> A command like this:
>
> ffmpeg -i in.gif out.gif
>
> seems to produce the same output as before: transparency replaces
> with opacity.

remuxing == -vcodec copy

What about ffmpeg -i in.gif -vcodec copy out.gif ?

> However a command like this:
>
> ffmpeg -i in.gif  -vf palettegen -y /tmp/pal.png && ffmpeg -i in.gif
> -i /tmp/pal.png -lavfi paletteuse -y -f gif out.gif
>
> produces an output that looks like the input (including transparency).
>
> I believe this is a problem with the decoder, however, since
>
> ffmpeg -i /Users/bjorn/Desktop/smoketrail.gif
> /Users/bjorn/Desktop/smoketrail-out%d.png

This produces transparent images here for the output
file of ticket #6813.

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

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Lou Logan]

On Mon, Nov 27, 2017, at 02:19 PM, Lou Logan wrote:
> A very rough guess is that there are usually at least several
> patches from unsubscribed users a week (in fact there was one in the
> queue minutes ago).

To clarify, in this case it was a reply, not a message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] decklink: Add support for output of Active Format Description (AFD)

[Marton Balint]

On Thu, 16 Nov 2017, Devin Heitmueller wrote:


Implement support for including AFD in decklink output.  This
includes making sure the AFD data is preserved when going from
an AVFrame to a V210 packet (needed for 10-bit support).

Signed-off-by: Devin Heitmueller 
---
libavcodec/avcodec.h |  6 ++
libavcodec/v210enc.c | 11 +++
libavdevice/decklink_enc.cpp | 41 +++--
3 files changed, 56 insertions(+), 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 442b558..6981f07 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1327,6 +1327,12 @@ enum AVPacketSideDataType {
AV_PKT_DATA_A53_CC,

/**
+ * Active Format Description data consisting of a single byte as specified
+ * in ETSI TS 101 154 using AVActiveFormatDescription enum.
+ */
+AV_PKT_DATA_AFD,
+
+/**
 * The number of side data elements (in fact a bit more than it).
 * This is not part of the public API/ABI in the sense that it may
 * change when new side data types are added.
diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index a825c03..c28f7b1 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -245,6 +245,17 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
}
}

+side_data = av_frame_get_side_data(pic, AV_FRAME_DATA_AFD);
+if (side_data && side_data->size) {
+uint8_t* buf = av_packet_new_side_data(pkt, AV_PKT_DATA_AFD, 
side_data->size);
+if (buf) {
+memcpy(buf, side_data->data, side_data->size);
+} else {
+av_log(avctx, AV_LOG_ERROR, "Unable to allocate afd side data\n");


Same here, you can skip the error message for enomem.


+return AVERROR(ENOMEM);
+}
+}
+
pkt->flags |= AV_PKT_FLAG_KEY;
*got_packet = 1;
return 0;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 0dcbe79..070bfad 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -280,7 +280,8 @@ av_cold int ff_decklink_write_trailer(AVFormatContext 
*avctx)

#if CONFIG_LIBKLVANC
static int decklink_construct_vanc(AVFormatContext *avctx, struct decklink_ctx 
*ctx,
-   AVPacket *pkt, decklink_frame *frame)
+   AVPacket *pkt, decklink_frame *frame,
+   AVStream *st)
{
struct klvanc_line_set_s vanc_lines = { 0 };
int ret, size;
@@ -334,6 +335,42 @@ static int decklink_construct_vanc(AVFormatContext *avctx, 
struct decklink_ctx *
}
}

+data = av_packet_get_side_data(pkt, AV_PKT_DATA_AFD, );
+if (data) {
+struct klvanc_packet_afd_s *pkt;
+uint16_t *afd;
+uint16_t len;
+
+ret = klvanc_create_AFD();
+if (ret != 0)
+return AVERROR(ENOMEM);
+
+ret = klvanc_set_AFD_val(pkt, data[0]);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid AFD value specified: %d\n",
+   data[0]);
+klvanc_destroy_AFD(pkt);
+return AVERROR(EINVAL);
+}
+
+/* FIXME: Should really rely on the coded_width but seems like that
+   is not accessible to libavdevice outputs */
+if ((st->codecpar->width == 1280 && st->codecpar->height == 720) ||
+(st->codecpar->width == 1920 && st->codecpar->height == 1080))
+pkt->aspectRatio = ASPECT_16x9;
+else
+pkt->aspectRatio = ASPECT_4x3;


Does this work for SD 16x9? Shouldn't you also use st->sample_aspect_ratio 
with some rounding to handle 704x576 16:9 and such mess?



+
+klvanc_convert_AFD_to_words(pkt, , );


missing error check


+klvanc_destroy_AFD(pkt);
+
+ret = klvanc_line_insert(ctx->vanc_ctx, _lines, afd, len, 12, 0);
+if (ret != 0) {
+av_log(avctx, AV_LOG_ERROR, "VANC line insertion failed\n");
+return AVERROR(ENOMEM);
+}
+}
+
IDeckLinkVideoFrameAncillary *vanc;
int result = ctx->dlo->CreateAncillaryData(bmdFormat10BitYUV, );
if (result != S_OK) {
@@ -429,7 +466,7 @@ static int decklink_write_video_packet(AVFormatContext 
*avctx, AVPacket *pkt)
frame = new decklink_frame(ctx, avpacket, st->codecpar->codec_id, 
ctx->bmd_height, ctx->bmd_width);

#if CONFIG_LIBKLVANC
-ret = decklink_construct_vanc(avctx, ctx, pkt, frame);
+ret = decklink_construct_vanc(avctx, ctx, pkt, frame, st);
if (ret != 0) {
av_log(avctx, AV_LOG_ERROR, "Failed to construct VANC\n");
}


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

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: use avformat_init_output to initialize output files

[Michael Niedermayer]

On Sun, Nov 26, 2017 at 05:51:02PM -0300, James Almer wrote:
> Postpone writing the header until the first output packet is ready to be
> written.
> This makes sure any stream parameter change that could take place while
> processing an input frame will be taken into account when writing the
> output file header.
> 
> Signed-off-by: James Almer 
> ---
>  fftools/ffmpeg.c | 31 ++-
>  fftools/ffmpeg.h |  3 +++
>  2 files changed, 29 insertions(+), 5 deletions(-)

This changes (generates a file before, does not afterwards)
./ffmpeg  -i ~/tickets/5114/test_case.ivf -an -y test.mp4
https://trac.ffmpeg.org/attachment/ticket/5114/test_case.ivf

ill see if i can find a failure that is more clear, as this one
arguable doesnt produce a very usefull file

[...]
-- 
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/3] ffmpeg: use avformat_init_output to initialize output files

[James Almer]

On 11/27/2017 6:25 PM, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 05:51:02PM -0300, James Almer wrote:
>> Postpone writing the header until the first output packet is ready to be
>> written.
>> This makes sure any stream parameter change that could take place while
>> processing an input frame will be taken into account when writing the
>> output file header.
>>
>> Signed-off-by: James Almer 
>> ---
>>  fftools/ffmpeg.c | 31 ++-
>>  fftools/ffmpeg.h |  3 +++
>>  2 files changed, 29 insertions(+), 5 deletions(-)
> 
> This changes (generates a file before, does not afterwards)
> ./ffmpeg  -i ~/tickets/5114/test_case.ivf -an -y test.mp4
> https://trac.ffmpeg.org/attachment/ticket/5114/test_case.ivf
> 
> ill see if i can find a failure that is more clear, as this one
> arguable doesnt produce a very usefull file

Note the log message you get after this patch: "Nothing was written into
output file 0 (test.mp4), because at least one of its streams received
no packets."

Before this patch, of->header_written was set to 1 after calling
avformat_write_header even if no header was really written (Because of
the delayed header code in lavf I'm removing in patch 2), so ffmpeg.c
instead of printing the above log would call av_write_trailer() which,
again, would trigger the delayed header code in lavf and write the
header and the trailer in one go, but no packets in between.

After this patch, where we used to call avformat_write_header we're now
calling avformat_init_output, so of->header_written is 0 at the time the
invalid input data error happens, and as such av_write_trailer is
effectively never called.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

[Rainer Hochecker]

2017-11-27 22:53 GMT+01:00 Anssi Hannula :
> Hi,
>
> Rainer Hochecker kirjoitti 2017-11-26 12:46:
>>
>> fixed mem leak poined out by Steven
>>
>> ---
>>  doc/demuxers.texi |   5 +
>>  libavformat/hls.c | 304
>> --
>>  2 files changed, 209 insertions(+), 100 deletions(-)
>>
> [...]
>>
>> +
>> +@item load_all_variants
>> +If 0, only the first variant/playlist is loaded on open. All other
>> variants
>> +get disabled and can be enabled by setting discard option in program.
>> +Default value is 1.
>>  @end table
>
>
> If playlist download+parsing is indeed taking long enough time that this is
> warranted, I wonder if we should maybe just never read any variant playlists
> in read_header(), and instead set AVFMTCTX_NOHEADER.
> Then the user may discard AVPrograms right after open, before unneeded
> playlists are loaded+parsed.
>
> This would avoid having a separate option/mode for this.
>
> Any thoughts?

I actually tried it like this but somwhow did not like it because this
is different
to all other demuxers/formats. In general you open an input, call
find_stream_info,
and select a program. I did not like selecting the program between open and
find_stream_info.

>
>
>>  @section image2
>> diff --git a/libavformat/hls.c b/libavformat/hls.c
>> index 786934af03..c42e0b0f95 100644
>> --- a/libavformat/hls.c
>> +++ b/libavformat/hls.c
>> @@ -112,6 +112,7 @@ struct playlist {
>>  int n_segments;
>>  struct segment **segments;
>>  int needed, cur_needed;
>> +int parsed;
>>  int cur_seq_no;
>>  int64_t cur_seg_offset;
>>  int64_t last_load_time;
>> @@ -206,6 +207,7 @@ typedef struct HLSContext {
>>  int strict_std_compliance;
>>  char *allowed_extensions;
>>  int max_reload;
>> +int load_all_variants;
>>  } HLSContext;
>
> [...]
>>
>> @@ -721,6 +726,7 @@ static int parse_playlist(HLSContext *c, const char
>> *url,
>>  free_segment_list(pls);
>>  pls->finished = 0;
>>  pls->type = PLS_TYPE_UNSPECIFIED;
>> +pls->parsed = 1;
>>  }
>
>
> That "pls->parsed = 1" is in the "reinit old playlist for re-parse" block,
> is that intentional?
>
> I'd think it should rather be at the end of the function alongside setting
> pls->last_load_time, so it is set to 1 whenever parsing has been done.
>

I put it at the beginning because I wanted to avoid that it gets tried again
on error.

>>  while (!avio_feof(in)) {
>>  read_chomp_line(in, line, sizeof(line));
>
> [...]
>>
>> @@ -1631,6 +1655,124 @@ static int hls_close(AVFormatContext *s)
>>  return 0;
>>  }
>>
>> +static int init_playlist(HLSContext *c, struct playlist *pls)
>> +{
>
>
> This init_playlist() seems to be mostly code moved from below, could you
> split the patch so that the first patch moves the code around but does not
> change behavior, and the second patch makes the actual changes (i.e. adds
> the option)?
>
> That would ease e.g. future bisecting.

Sure. At least I can try.

>
> [...]
>>
>> +return 0;
>> +}
>> +
>>  static int hls_read_header(AVFormatContext *s)
>>  {
>>  void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
>> @@ -1663,6 +1805,9 @@ static int hls_read_header(AVFormatContext *s)
>>  if ((ret = parse_playlist(c, s->filename, NULL, s->pb)) < 0)
>>  goto fail;
>>
>> +/* first playlist was created, set it to parsed */
>> +c->variants[0]->playlists[0]->parsed = 1;
>> +
>
>
> I think parse_playlist() should set this when it parses something.

That was pitfall for my v1. The first playlist gets parsed with no
playlist given as argument.
fate failed because non-master playlists were not set to parsed.

>
>>  if ((ret = save_avio_options(s)) < 0)
>>  goto fail;
>>
>> @@ -1675,8 +1820,15 @@ static int hls_read_header(AVFormatContext *s)
>>  goto fail;
>
> [...]
>>
>>
>>  /* Select the starting segments */
>>  for (i = 0; i < c->n_playlists; i++) {
>>  struct playlist *pls = c->playlists[i];
>>
>> -if (pls->n_segments == 0)
>> +if (pls->n_segments == 0 && !pls->parsed)
>>  continue;
>
>
> Why?

playlists not parsed are invalid, right? maybe n_segments is 0 for
not parsed playlists but this was no obvious to me.

>
>>  pls->cur_seq_no = select_cur_seq_no(c, pls);
>> @@ -1736,97 +1892,9 @@ static int hls_read_header(AVFormatContext *s)
>>  /* Open the demuxer for each playlist */
>>  for (i = 0; i < c->n_playlists; i++) {
>>  struct playlist *pls = c->playlists[i];
>> -AVInputFormat *in_fmt = NULL;
>> -
>
> [...]
>
> --
> Anssi Hannula
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Rostislav Pehlivanov]

On 27 November 2017 at 23:05, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Nov 27, 2017 at 6:03 PM, Carl Eugen Hoyos 
> wrote:
>
> > 2017-11-26 22:57 GMT+01:00 Jim DeLaHunt :
> > > On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
> > >
> > >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
> > >> [...]
> > >>>
> > >>> +
> > >>>   @subheading Subscribe to the ffmpeg-cvslog mailing list.
> > >>> -It is important to do this as the diffs of all commits are sent
> there
> > >>> and
> > >>> -reviewed by all the other developers. Bugs and possible improvements
> > or
> > >>> -general questions regarding commits are discussed there. We expect
> you
> > >>> to
> > >>> -react if problems with your code are uncovered.
> > >>> +Diffs of all commits are sent to the
> > >>> +@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-cvslog,
> > >>> ffmpeg-cvslog}
> > >>> +mailing list. Some developers read this list to review all code base
> > >>> changes
> > >>> +from all sources. Subscribing to this list is not mandatory, if
> > >>> +all you want to do is submit a patch here and there.
> > >>
> > >> I am (still) against this change.
> > >
> > >
> > > OK, what specifically are you against?  More important, what are you in
> > > favour of?
> >
> > I have no issue with the current text.
> >
> > If you believe that it is unclear that there is a difference between an
> > occasional contributor (who most likely would not read -devel nor
> > -cvslog) and a committer (who is supposed to read -cvslog), then
> > maybe a patch is useful.
>
>
> FYI I'm a committer and I do not read -cvslog.
>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yeah, never touched cvslog either.
If someone has comments to a commit which was pushed and doesn't use IRC
then they should send an email to this ML. Or better yet use IRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Lou Logan]

On Mon, Nov 27, 2017, at 02:00 PM, Carl Eugen Hoyos wrote:
> No, the mail admins could (or explain that I am wrong.)

I would have to check each sender manually to see if they are in the
membership database. It would be possible to do this, but not very
practical. It would be easier for me to keep a running tally as I clear
the queue. A very rough guess is that there are usually at least several
patches from unsubscribed users a week (in fact there was one in the
queue minutes ago).

Sometimes I'll set a frequent non-subscribed senders email address to be
automatically accepted (I purge this list occasionally).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfenc: use track count to generate component instance uuid

[Mark Reid]

On Mon, Nov 27, 2017 at 2:14 AM, Tomas Härdin  wrote:

> On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> > ---
> >  libavformat/mxf.h   |  1 -
> >  libavformat/mxfenc.c| 45 +
> > 
> >  tests/ref/fate/copy-trac4914|  2 +-
> >  tests/ref/fate/time_base|  2 +-
> >  tests/ref/lavf/mxf  |  6 +++---
> >  tests/ref/lavf/mxf_d10  |  2 +-
> >  tests/ref/lavf/mxf_dv25 |  2 +-
> >  tests/ref/lavf/mxf_dvcpro50 |  2 +-
> >  tests/ref/lavf/mxf_opatom   |  2 +-
> >  tests/ref/lavf/mxf_opatom_audio |  2 +-
> >  10 files changed, 38 insertions(+), 28 deletions(-)
> > [...]
> > @@ -846,6 +847,10 @@ static void
> > mxf_write_track(AVFormatContext *s, AVStream *st, MXFPackage *packag
> >  MXFContext *mxf = s->priv_data;
> >  AVIOContext *pb = s->pb;
> >  MXFStreamContext *sc = st->priv_data;
> > +int instance = package->uuid_offset;
> > +
> > +if (st != mxf->timecode_track)
> > +instance += st->index + 1;
> >
> >  mxf_write_metadata_key(pb, 0x013b00);
> >  PRINT_KEY(s, "track key", pb->buf_ptr - 16);
> >
> >  static int mxf_write_essence_container_data(AVFormatContext *s)
> > @@ -1443,11 +1451,12 @@ static int
> > mxf_write_header_metadata_sets(AVFormatContext *s)
> >  AVDictionaryEntry *entry = NULL;
> >  AVStream *st = NULL;
> >  int i;
> > -
> > +int track_count = 0;
> >  MXFPackage packages[2] = {};
> >  int package_count = 2;
> >  packages[0].type = MaterialPackage;
> >  packages[1].type = SourcePackage;
> > +packages[1].instance = 1;
> >
> >  if (entry = av_dict_get(s->metadata, "material_package_name",
> > NULL, 0))
> > packages[0].name = entry->value;
> > @@ -1468,8 +1477,10 @@ static int
> > mxf_write_header_metadata_sets(AVFormatContext *s)
> >  mxf_write_preface(s);
> >  mxf_write_identification(s);
> >  mxf_write_content_storage(s, packages, package_count);
> > -for (i = 0; i < package_count; i++)
> > -mxf_write_package(s, [i]);
> > +for (i = 0; i < package_count; i++) {
> > +packages[i].uuid_offset = track_count;
> > +track_count += mxf_write_package(s, [i]);
> > +}
>
> I see st->index + 1 when deriving instance from uuid_offset, are you
> sure there isn't a potential off-by-one error here? An MP track and SP
> track getting the same UUID or something. I guess type is enough to
> differentiate, but then why does instance need uuid_offset?
>

I don't think so unless AVStream->index could get set incorrectly, is this
possible?
I had to change the old method because it falls apart when you add the 2nd
source package.
Basically the idea is since every 1 track has 1 sequence and 1 component
they can share the same instance number
Rethinking it a little bit I think I have come up with something simple
that achieves the same result, I'll send a new patch.


>
> /Tomas
> ___
> 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 V3] examples/vaapi_encode: Add a VA-API encode example.

[Jun Zhao]

Ping ?

On 2017/11/20 9:38, Jun Zhao wrote:
> V3: Use av_hwframe_transfer_date load YUV to HW surface

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

[FFmpeg-devel] [PATCH] [dnxhddec] Do not overwrite colorspace if the container has set it.

[Steven Robertson]

Signed-off-by: Steven Robertson 
---
 libavcodec/dnxhddec.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
index f46e41a456..6f8c716412 100644
--- a/libavcodec/dnxhddec.c
+++ b/libavcodec/dnxhddec.c
@@ -93,7 +93,9 @@ static av_cold int dnxhd_decode_init(AVCodecContext *avctx)
 
 ctx->avctx = avctx;
 ctx->cid = -1;
-avctx->colorspace = AVCOL_SPC_BT709;
+if (avctx->colorspace == AVCOL_SPC_UNSPECIFIED) {
+  avctx->colorspace = AVCOL_SPC_BT709;
+}
 
 avctx->coded_width  = FFALIGN(avctx->width,  16);
 avctx->coded_height = FFALIGN(avctx->height, 16);
-- 
2.15.0.417.g466bffb3ac-goog

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

Re: [FFmpeg-devel] AMD external header

[Hendrik Leppkes]

On Mon, Nov 27, 2017 at 4:00 AM, Mironov, Mikhail
 wrote:
>
> I also noticed that recently there is a lot of activity to add full Nvidia 
> decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
> I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? 
> We also have them.
>
>

DXVA2/D3D11VA work perfectly fine, on Windows i see no huge reason to
use NVDEC (and the same can probably be said for whatever AMD
solution) - and in fact from a user (and developer) perspective its
much nicer to just use the same hwaccel on all hardware. But Linux is
another matter. I don't know how well AMD works with VAAPI or VDPAU
(if at all), but at least for NVIDIA VDPAU has its issues and VAAPI is
not supported at all (except with a VAAPI VDPAU adapter, which  has
the same issues, obviously)

Until you guys actually provide Linux support, adding a HWAccel might
not be that advantageous for the user-base.

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

Re: [FFmpeg-devel] [PATCH] avformat/avienc: fix fields-per-frame value for interlaced video streams

[Tobias Rapp]

On 22.11.2017 16:58, Derek Buitenhuis wrote:

On 11/22/2017 3:41 PM, Tobias Rapp wrote:

Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.

Unfortunately the OpenDML v1.02 document is not very specific what value
to use for start_line when frame data is not coming from a capturing
device, so this is just using 0/1 depending on the field order as a
best-effort guess.


Looking at the OpenDML spec, I think this indeed is the best we can do without
deeper knowledge of where the source signal came from, or copying it from a
pre-existing file, within the existing avformat scaffolding.

Code itself seems OK.


Copied part of the commit message as a comment to the code and pushed. 
Thanks Carl and Derek for the review.


Regards,
Tobias

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

Re: [FFmpeg-devel] avcodec/hevc_ps: set correct return value

[PanBian]

On Mon, Nov 27, 2017 at 04:31:38AM +0100, Carl Eugen Hoyos wrote:
> 2017-11-27 4:22 GMT+01:00 Pan Bian :
> > When the call to get_bits_left() fails, the return value is not an
> > negative error code. This patch explicitly assignes an error
> > code to the return variable ret.
> 
> Can't this break decoding of damaged streams that could be
> decoded so far?

Dear Eugen,

I see your consideration. I am not familar with the decoding logic.
Sorry for that. I sent this patch because I found that some other decode
functions (e.g. ff_hevc_decode_nal_vps) return error code
AVERROR_INVALIDDATA if overread occurs.

Thanks!

Pan Bian

> 
> 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

Re: [FFmpeg-devel] [PATCH] lavr: deprecate the entire library

[Tobias Rapp]

On 25.11.2017 18:31, Derek Buitenhuis wrote:

On 11/25/2017 2:40 PM, Clément Bœsch wrote:

Maybe "libavresample is not maintained by the FFmpeg project and will be
dropped at the next major bump. Please use libswresample instead."

And it probably needs a longer explanation somewhere (website/news/...)


All API functions should be properly marked as deprecated in the headers.

Relying on a stderr warning to help migrate API users is silly, who is
going to be watching stderr using a /library/?


+1

Please avoid the AVStream.codec -> AVStream.codecpar scenario. I don't 
remember how often I was asked by users looking at the logs how they can 
avoid the "Using AVStream.codec to pass codec parameters to muxers is 
deprecated, use AVStream.codecpar instead" warning.


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[Tobias Rapp]

On 26.11.2017 21:51, James Almer wrote:

Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.

Signed-off-by: James Almer 
---
  libavformat/avformat.h |  2 +-
  libavformat/internal.h |  6 -
  libavformat/mux.c  | 52 --
  libavformat/options_table.h|  2 +-
  libavformat/tests/fifo_muxer.c | 52 --
  tests/ref/fate/fifo-muxer-tst  |  1 -
  6 files changed, 12 insertions(+), 103 deletions(-)

[...]


I'm just curious: Will this fix ticket #6375?

Regards,
Tobias

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

[FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

[Vittorio Giovara]

Signed-off-by: Vittorio Giovara 
---
 libavformat/mov.c | 71 +++
 1 file changed, 71 insertions(+)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 79023ef369..bb463017a3 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5072,6 +5072,51 @@ static int mov_read_smdm(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_mdcv(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+MOVStreamContext *sc;
+const int mapping[3] = {1, 2, 0};
+const int chroma_den = 5;
+const int luma_den = 1;
+int i;
+
+if (c->fc->nb_streams < 1)
+return AVERROR_INVALIDDATA;
+
+sc = c->fc->streams[c->fc->nb_streams - 1]->priv_data;
+
+if (atom.size < 24) {
+av_log(c->fc, AV_LOG_ERROR, "Invalid Mastering Display Color Volume 
box\n");
+return AVERROR_INVALIDDATA;
+}
+
+sc->mastering = av_mastering_display_metadata_alloc();
+if (!sc->mastering)
+return AVERROR(ENOMEM);
+
+for (i = 0; i < 3; i++) {
+const int j = mapping[i];
+sc->mastering->display_primaries[j][0].num = avio_rb16(pb);
+sc->mastering->display_primaries[j][0].den = chroma_den;
+sc->mastering->display_primaries[j][1].num = avio_rb16(pb);
+sc->mastering->display_primaries[j][1].den = chroma_den;
+}
+sc->mastering->white_point[0].num = avio_rb16(pb);
+sc->mastering->white_point[0].den = chroma_den;
+sc->mastering->white_point[1].num = avio_rb16(pb);
+sc->mastering->white_point[1].den = chroma_den;
+
+sc->mastering->max_luminance.num = avio_rb32(pb);
+sc->mastering->max_luminance.den = luma_den;
+sc->mastering->min_luminance.num = avio_rb32(pb);
+sc->mastering->min_luminance.den = luma_den;
+
+sc->mastering->has_luminance = 1;
+sc->mastering->has_primaries = 1;
+
+return 0;
+}
+
 static int mov_read_coll(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 MOVStreamContext *sc;
@@ -5104,6 +5149,30 @@ static int mov_read_coll(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
+static int mov_read_clli(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+MOVStreamContext *sc;
+
+if (c->fc->nb_streams < 1)
+return AVERROR_INVALIDDATA;
+
+sc = c->fc->streams[c->fc->nb_streams - 1]->priv_data;
+
+if (atom.size < 4) {
+av_log(c->fc, AV_LOG_ERROR, "Empty Content Light Level Info box\n");
+return AVERROR_INVALIDDATA;
+}
+
+sc->coll = av_content_light_metadata_alloc(>coll_size);
+if (!sc->coll)
+return AVERROR(ENOMEM);
+
+sc->coll->MaxCLL  = avio_rb16(pb);
+sc->coll->MaxFALL = avio_rb16(pb);
+
+return 0;
+}
+
 static int mov_read_st3d(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 AVStream *st;
@@ -5912,6 +5981,8 @@ static const MOVParseTableEntry mov_default_parse_table[] 
= {
 { MKTAG('S','m','D','m'), mov_read_smdm },
 { MKTAG('C','o','L','L'), mov_read_coll },
 { MKTAG('v','p','c','C'), mov_read_vpcc },
+{ MKTAG('m','d','c','v'), mov_read_mdcv },
+{ MKTAG('c','l','l','i'), mov_read_clli },
 { 0, NULL }
 };
 
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 27/11/17 23:34, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: November 27, 2017 6:25 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
>> AMD GPUs based on AMF SDK
>>
>> On 27/11/17 22:35, Mironov, Mikhail wrote:
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf Of Mark Thompson
> Sent: November 27, 2017 3:11 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
 AMD
> GPUs based on AMF SDK
>
> From: mmironov 
>
> Requires AMF headers for at least version 1.4.2 (older versions do
> not support building with C).
> ---
> Uses upstream headers from  LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't
> find an official install method so I've assumed that the AMF headers
> are under an AMF/ prefix (they have rather generic names, so they
> need something).  Just copying the two directories from the source
> path to /usr/local/include/AMF or similar is sufficient.
>
> I've also assumed that the features which don't yet exist upstream
> (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
> There might be more version checking needed, but I'm not sure (newer
> version / older header should work because of the version
> initialisation, while older version / newer header fails at that maybe?).
>
> The OS checks are removed, it builds fine on Linux if you have the
>> headers.
>

 The public headers from github do not have several fixes that were
 done in the customized header.
 I could cherry-pick and push them but I did not test this for a while
 assuming that the custom header is used.

>>>
>>> Pushed.
>>
>> Thank you!
>>
>> Is there an official way to detect a finer version there?  (The version 
>> number
>> is still 1.4.4.)  If not, we can just look for one of the just-added enum
>> constants for the configure test.
> 
> There is AMFQueryVersion() exposed as "C" export. See Factory.h
> It will return driver version of runtime but at this point the API is forward 
> and backward compatible.
> The changes I pushed do not change API, just fixed C  compatibility issues.
> So at this point there is no need to check version against header.
> In the future if backward compatibility is broken AMFInit() will check header 
> version and will return error.

We need to check the compatibility of the header at configure-time, though - 
configure needs to determine whether the header is usable or not.

If the user has, for example, the original 1.4.4 headers then the configure 
test looking for the AMFFactory will pass, but the compile will not succeed.

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[James Almer]

On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
> On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
>> Every bitstream filter behaves as intended now, so there's no need to
>> wait for the first packet of every stream.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavformat/avformat.h |  2 +-
>>  libavformat/internal.h |  6 -
>>  libavformat/mux.c  | 52 
>> --
>>  libavformat/options_table.h|  2 +-
>>  libavformat/tests/fifo_muxer.c | 52 
>> --
>>  tests/ref/fate/fifo-muxer-tst  |  1 -
>>  6 files changed, 12 insertions(+), 103 deletions(-)
> 
> Is this intended to change any files ?
> 
> this changes slightly:
> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
> 
> not saying this is a issue in the patch or anything (i am in favor of
> the simplification in fact), just that i saw this change

I can't access that file, but just in case it's related, this patch is
meant to be applied after the first. Otherwise, as the first patch
states, stream parameters that might be changed by ffmpeg.c while
processing an input frame (specifically field_order) will not be taken
into account during write_header.
You might remember i have sent this patch alone before, and how it
affected matroska files because of differing field_order values,
including fate-rgb24-mkv.

For that matter, ffmpeg.c changing any output codecpar values while
reading an input frame (that is, long after the output file and streams
have been initialized) is a very hacky thing to do. This is something
I'd expect avformat_find_stream_info() to do instead, since it decodes
some frames to get all the info it needs, and not the API user (ffmpeg.c).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] Remove concept of ctts entries with count > 1.

[John Stebbins]

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[Carl Eugen Hoyos]

2017-11-28 0:52 GMT+01:00 James Almer :
> On 11/27/2017 8:18 PM, Michael Niedermayer wrote:

>> this changes slightly:
>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
>>
>> not saying this is a issue in the patch or anything (i am in favor of
>> the simplification in fact), just that i saw this change
>
> I can't access that file

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2263/
Will remove it again.

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

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Lou Logan]

On Sun, Nov 26, 2017, at 12:57 PM, Jim DeLaHunt wrote:
> I'll observe that we have already heard other opinions:
> 
>   * Paul[2]: "Not at all. To be a contributor, it is not needed to
> subscribe to [ffmpeg-cvslog] list."
>   * Timo[3]: "Usually if a discussion comes up the mail from cvslog is
> replied to on [ffmpeg-devel] list, so no actual discussion happens
> on the automatic cvslog list."

ffmpeg-cvslog should only be a log and not a place for discussion.
ffmpeg-devel should be the only mailing list where development
discussions occur.

Discussing a commit that was not reviewed should also occur at
ffmpeg-devel. Currently there is little discussion in ffmpeg-cvslog
(excluding discussions also directed to ffmpeg-devel), and I'm not sure
how many patch authors actually read or see ffmpeg-cvslog only replies.

Having no conversation in ffmpeg-cvslog would mean fewer pending
messages in the infiniqueue for me to regularly deal with.

Developers, contributors, maintainers, and/or committers should not need
to subscribe to ffmpeg-cvslog to participate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Bjorn Roche]

On Mon, Nov 27, 2017 at 5:35 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-27 19:30 GMT+01:00 Bjorn Roche :
> >
>
> > The only way I can see is to move some functionality between the mixer
> and
> > the encoder. It's not a clear line between the codec and the container in
> > GIF, so I wouldn't object to an approach different from the one I took.
>
> (Just a question!)
>
> Does remuxing (animated) gif to gif work now? (I believe it does.)
> Does it work with your patch?


I think this would require changes to the reader. AFAICT, it only outputs
BGRA. Something I can look into if that seems right to you.


-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Mark Thompson]

On 28/11/17 00:12, Lou Logan wrote:
> On Sun, Nov 26, 2017, at 12:57 PM, Jim DeLaHunt wrote:
>> I'll observe that we have already heard other opinions:
>>
>>   * Paul[2]: "Not at all. To be a contributor, it is not needed to
>> subscribe to [ffmpeg-cvslog] list."
>>   * Timo[3]: "Usually if a discussion comes up the mail from cvslog is
>> replied to on [ffmpeg-devel] list, so no actual discussion happens
>> on the automatic cvslog list."
> 
> ffmpeg-cvslog should only be a log and not a place for discussion.
> ffmpeg-devel should be the only mailing list where development
> discussions occur.
> 
> Discussing a commit that was not reviewed should also occur at
> ffmpeg-devel. Currently there is little discussion in ffmpeg-cvslog
> (excluding discussions also directed to ffmpeg-devel), and I'm not sure
> how many patch authors actually read or see ffmpeg-cvslog only replies.
> 
> Having no conversation in ffmpeg-cvslog would mean fewer pending
> messages in the infiniqueue for me to regularly deal with.
> 
> Developers, contributors, maintainers, and/or committers should not need
> to subscribe to ffmpeg-cvslog to participate.

I do use -cvslog, though generally I try to reply to -devel unless the 
conversation is already on -cvslog.

If the intent is that -devel should always be used for replies, can you set a 
reply-to header on -cvslog pointing to -devel?

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

[FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

From: mmironov 

Requires AMF headers for at least version 1.4.4.1.
---
On 27/11/17 23:45, Mironov, Mikhail wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: November 27, 2017 6:39 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
>> AMD GPUs based on AMF SDK
>>
>> On 27/11/17 23:34, Mironov, Mikhail wrote:
 -Original Message-
 From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
 Of Mark Thompson
 Sent: November 27, 2017 6:25 PM
 To: ffmpeg-devel@ffmpeg.org
 Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding
 for AMD GPUs based on AMF SDK

 On 27/11/17 22:35, Mironov, Mikhail wrote:
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>>> Behalf Of Mark Thompson
>>> Sent: November 27, 2017 3:11 PM
>>> To: FFmpeg development discussions and patches >> de...@ffmpeg.org>
>>> Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding
>> for
>> AMD
>>> GPUs based on AMF SDK
>>>
>>> From: mmironov 
>>>
>>> Requires AMF headers for at least version 1.4.2 (older versions do
>>> not support building with C).
>>> ---
>>> Uses upstream headers from >> LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't
>>> find an official install method so I've assumed that the AMF
>>> headers are under an AMF/ prefix (they have rather generic names,
>>> so they need something).  Just copying the two directories from
>>> the source path to /usr/local/include/AMF or similar is sufficient.
>>>
>>> I've also assumed that the features which don't yet exist upstream
>>> (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
>>> There might be more version checking needed, but I'm not sure
>>> (newer version / older header should work because of the version
>>> initialisation, while older version / newer header fails at that 
>>> maybe?).
>>>
>>> The OS checks are removed, it builds fine on Linux if you have the
 headers.
>>>
>>
>> The public headers from github do not have several fixes that were
>> done in the customized header.
>> I could cherry-pick and push them but I did not test this for a
>> while assuming that the custom header is used.
>>
>
> Pushed.

 Thank you!

 Is there an official way to detect a finer version there?  (The
 version number is still 1.4.4.)  If not, we can just look for one of
 the just-added enum constants for the configure test.
>>>
>>> There is AMFQueryVersion() exposed as "C" export. See Factory.h It
>>> will return driver version of runtime but at this point the API is forward 
>>> and
>> backward compatible.
>>> The changes I pushed do not change API, just fixed C  compatibility issues.
>>> So at this point there is no need to check version against header.
>>> In the future if backward compatibility is broken AMFInit() will check
>> header version and will return error.
>>
>> We need to check the compatibility of the header at configure-time, though -
>> configure needs to determine whether the header is usable or not.
>>
>> If the user has, for example, the original 1.4.4 headers then the configure
>> test looking for the AMFFactory will pass, but the compile will not succeed.
> 
> OK, I pushed version change to 1.4.4.1 in Version.h  You can check against it 
> and 
> when we push full update it will be 1.4.5.x or higher. 

Ok; done, plus some trivial testing to make sure it works.  If you're happy 
with this and noone else says anything then I'll push it tomorrow.

Relatedly: your name on patches does not match your full name - I've preserved 
the patch one here, but was that intended?

Thanks,

- Mark


 Changelog|   1 +
 configure|  10 +
 libavcodec/Makefile  |   4 +
 libavcodec/allcodecs.c   |   2 +
 libavcodec/amfenc.c  | 604 +++
 libavcodec/amfenc.h  | 148 
 libavcodec/amfenc_h264.c | 395 +++
 libavcodec/amfenc_hevc.c | 326 +
 8 files changed, 1490 insertions(+)
 create mode 100644 libavcodec/amfenc.c
 create mode 100644 libavcodec/amfenc.h
 create mode 100644 libavcodec/amfenc_h264.c
 create mode 100644 libavcodec/amfenc_hevc.c

diff --git a/Changelog b/Changelog
index afead72f14..7a913bf7a7 100644
--- a/Changelog
+++ b/Changelog
@@ -21,6 +21,7 @@ version :
 - video mix filter
 - video normalize filter
 - audio lv2 wrapper filter
+- AMD AMF H.264 and HEVC encoders
 
 
 version 3.4:
diff --git a/configure b/configure
index 6748ef8bc9..3036b69cab 100755
--- a/configure
+++ b/configure
@@ 

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 12:03:38AM +, Derek Buitenhuis wrote:
> On 11/21/2017 11:12 PM, Dale Curtis wrote:
> > Otherwise ff_alloc_extradata() just leaks any existing allocated
> > memory.
> 
> Should be OK.

will apply
i had tested this one already a bit a few days ago ...

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[James Almer]

On 11/27/2017 9:00 PM, Carl Eugen Hoyos wrote:
> 2017-11-28 0:52 GMT+01:00 James Almer :
>> On 11/27/2017 8:18 PM, Michael Niedermayer wrote:
> 
>>> this changes slightly:
>>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv
>>>
>>> not saying this is a issue in the patch or anything (i am in favor of
>>> the simplification in fact), just that i saw this change
>>
>> I can't access that file
> 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket2263/
> Will remove it again.

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 27, 2017 6:39 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
> AMD GPUs based on AMF SDK
> 
> On 27/11/17 23:34, Mironov, Mikhail wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Mark Thompson
> >> Sent: November 27, 2017 6:25 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding
> >> for AMD GPUs based on AMF SDK
> >>
> >> On 27/11/17 22:35, Mironov, Mikhail wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf Of Mark Thompson
> > Sent: November 27, 2017 3:11 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding
> for
>  AMD
> > GPUs based on AMF SDK
> >
> > From: mmironov 
> >
> > Requires AMF headers for at least version 1.4.2 (older versions do
> > not support building with C).
> > ---
> > Uses upstream headers from  > LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't
> > find an official install method so I've assumed that the AMF
> > headers are under an AMF/ prefix (they have rather generic names,
> > so they need something).  Just copying the two directories from
> > the source path to /usr/local/include/AMF or similar is sufficient.
> >
> > I've also assumed that the features which don't yet exist upstream
> > (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
> > There might be more version checking needed, but I'm not sure
> > (newer version / older header should work because of the version
> > initialisation, while older version / newer header fails at that 
> > maybe?).
> >
> > The OS checks are removed, it builds fine on Linux if you have the
> >> headers.
> >
> 
>  The public headers from github do not have several fixes that were
>  done in the customized header.
>  I could cherry-pick and push them but I did not test this for a
>  while assuming that the custom header is used.
> 
> >>>
> >>> Pushed.
> >>
> >> Thank you!
> >>
> >> Is there an official way to detect a finer version there?  (The
> >> version number is still 1.4.4.)  If not, we can just look for one of
> >> the just-added enum constants for the configure test.
> >
> > There is AMFQueryVersion() exposed as "C" export. See Factory.h It
> > will return driver version of runtime but at this point the API is forward 
> > and
> backward compatible.
> > The changes I pushed do not change API, just fixed C  compatibility issues.
> > So at this point there is no need to check version against header.
> > In the future if backward compatibility is broken AMFInit() will check
> header version and will return error.
> 
> We need to check the compatibility of the header at configure-time, though -
> configure needs to determine whether the header is usable or not.
> 
> If the user has, for example, the original 1.4.4 headers then the configure
> test looking for the AMFFactory will pass, but the compile will not succeed.

OK, I pushed version change to 1.4.4.1 in Version.h  You can check against it 
and 
when we push full update it will be 1.4.5.x or higher. 

> 
> - 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] ffmpeg: Check read_ffserver_streams() return value

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 01:23:24AM +, Rostislav Pehlivanov wrote:
> On 27 November 2017 at 01:12, Pan Bian  wrote:
> 
> > The function avformat_alloc_context() will return a NULL pointer on
> > failure. However, in function read_ffserver_streams(), its return value
> > is not validated and the subsequent dereference may result in a bad
> > memory access bug. Check its return value against NULL and avoid
> > potential NULL dereference.
> >
> > Signed-off-by: Pan Bian 
> > ---
> >  fftools/ffmpeg_opt.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> > index 9445a2d..7e51c5a 100644
> > --- a/fftools/ffmpeg_opt.c
> > +++ b/fftools/ffmpeg_opt.c
> > @@ -2000,6 +2000,8 @@ static int read_ffserver_streams(OptionsContext *o,
> > AVFormatContext *s, const ch
> >  {
> >  int i, err;
> >  AVFormatContext *ic = avformat_alloc_context();
> > +   if (!ic)
> > +   return AVERROR(ENOMEM);
> >
> >  ic->interrupt_callback = int_cb;
> >  err = avformat_open_input(, filename, NULL, NULL);
> > --
> > 1.9.1
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> Pointless as ffserver's getting removed in a day or two

will apply anyway.

if its removed, it will have one bug less in the last revission which
anyone who wanted to use it or wanted to work on it would start with.

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

[Bjorn Roche]

On Mon, Nov 27, 2017 at 5:41 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-27 18:50 GMT+01:00 Bjorn Roche :
> > Sorry for the very delayed response, Carl:
> >
> > On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos 
> > wrote:
> >
> >> 2017-11-21 18:53 GMT+01:00 Bjorn Roche :
> >> > Support for transparencies in animated gifs requires modifying both
> >> > libavcodec/gif.c and libavformat/gif.c because both the graphics
> >> > control extension (handled by libavformat/gif.c) and the raw frame
> data
> >> > (handled by libavcodec/gif.c) must be changed.
> >>
> >> Does remuxing animated gif with transparency work with your patch?
> >
> > A command like this:
> >
> > ffmpeg -i in.gif out.gif
> >
> > seems to produce the same output as before: transparency replaces
> > with opacity.
>
> remuxing == -vcodec copy
>
> What about ffmpeg -i in.gif -vcodec copy out.gif ?
>

That doesn't work. Weather I use my patch or not it aborts:

Assertion video_par->format == AV_PIX_FMT_PAL8 failed at
libavformat/gif.c:132

As far as I can tell, the gif decoder (which I haven't touched) outputs
BGRA, but the gif writer requires PAL8.

> However a command like this:
> >
> > ffmpeg -i in.gif  -vf palettegen -y /tmp/pal.png && ffmpeg -i in.gif
> > -i /tmp/pal.png -lavfi paletteuse -y -f gif out.gif
> >
> > produces an output that looks like the input (including transparency).
> >
> > I believe this is a problem with the decoder, however, since
> >
> > ffmpeg -i /Users/bjorn/Desktop/smoketrail.gif
> > /Users/bjorn/Desktop/smoketrail-out%d.png
>
> This produces transparent images here for the output
> file of ticket #6813.


./ffmpeg -i transparency.apng out.gif

Produces the expected results (you don't see previous images "behind" the
current image).

bjorn

-- 


Bjorn Roche

Sr. Video Pipeline Engineer

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

[Carl Eugen Hoyos]

2017-11-28 1:07 GMT+01:00 Bjorn Roche :
> On Mon, Nov 27, 2017 at 5:41 PM, Carl Eugen Hoyos 
> wrote:

>> >> Does remuxing animated gif with transparency work with your patch?
>> >
>> > A command like this:
>> >
>> > ffmpeg -i in.gif out.gif
>> >
>> > seems to produce the same output as before: transparency replaces
>> > with opacity.
>>
>> remuxing == -vcodec copy
>>
>> What about ffmpeg -i in.gif -vcodec copy out.gif ?
>>
>
> That doesn't work. Weather I use my patch or not it aborts:

Of course, ticket #6640.

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

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

[Derek Buitenhuis]

On 11/21/2017 11:12 PM, Dale Curtis wrote:
> Otherwise ff_alloc_extradata() just leaks any existing allocated
> memory.

Should be OK.

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Carl Eugen Hoyos]

2017-11-28 1:12 GMT+01:00 Bjorn Roche :
> On Mon, Nov 27, 2017 at 5:35 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-11-27 19:30 GMT+01:00 Bjorn Roche :
>> >
>>
>> > The only way I can see is to move some functionality between the mixer
>> and
>> > the encoder. It's not a clear line between the codec and the container in
>> > GIF, so I wouldn't object to an approach different from the one I took.
>>
>> (Just a question!)
>>
>> Does remuxing (animated) gif to gif work now? (I believe it does.)
>> Does it work with your patch?
>
> I think this would require changes to the reader. AFAICT, it only outputs
> BGRA.

> Something I can look into if that seems right to you.

I have no idea.
I just wanted to point out some tests that may or may not
show if the whole approach makes sense.

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

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Lou Logan]

On Mon, Nov 27, 2017, at 03:20 PM, Mark Thompson wrote:
>
> If the intent is that -devel should always be used for replies, can you
> set a reply-to header on -cvslog pointing to -devel?

Done, thanks. Should have done that years ago. Didn't really think about
the cvslog situation much until this discussion.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [dnxhddec] Do not overwrite colorspace if the container has set it.

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 12:36:48AM -0800, Steven Robertson wrote:
> Signed-off-by: Steven Robertson 
> ---
>  libavcodec/dnxhddec.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index f46e41a456..6f8c716412 100644
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c
> @@ -93,7 +93,9 @@ static av_cold int dnxhd_decode_init(AVCodecContext *avctx)
>  
>  ctx->avctx = avctx;
>  ctx->cid = -1;
> -avctx->colorspace = AVCOL_SPC_BT709;
> +if (avctx->colorspace == AVCOL_SPC_UNSPECIFIED) {
> +  avctx->colorspace = AVCOL_SPC_BT709;
> +}

why is this sometimes but not always correct ?

can one and the same dnxhd stream be 2 different colorspace depending
on container or is the decoder implementation incomplete in relation
to setting the colorspace ?

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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

[FFmpeg-devel] [PATCH] Fix for ticket 6658 (Dash demuxer segfault)

[Colin NG]

---
 libavformat/dashdec.c | 95 ---
 1 file changed, 82 insertions(+), 13 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 3798649..5d5970e 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,11 @@ static uint64_t get_current_time_in_sec(void)
 return  av_gettime() / 100;
 }
 
+static char * ishttp(char *url) {
+char *proto_name = avio_find_protocol_name(url);
+return av_strstart(proto_name, "http", NULL);
+}
+
 static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char 
*datetime)
 {
 struct tm timeinfo;
@@ -392,7 +397,9 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, );
+av_freep(pb);
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, );
+
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -639,6 +646,74 @@ static int parse_manifest_segmenttimeline(AVFormatContext 
*s, struct representat
 return 0;
 }
 
+static int resolve_content_path(AVFormatContext *s, const char *url,  
xmlNodePtr *baseurl_nodes,  int n_baseurl_nodes) {
+
+int i;
+char *text;
+char tmp_str[MAX_URL_SIZE];
+char tmp_str_2[MAX_URL_SIZE];
+
+char *path = av_mallocz(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/"))) {
+nameSize = strlen(mpdName);
+}
+
+av_strlcpy (path, url, strlen(url)-nameSize+1);
+
+int rootId = 0;
+xmlNodePtr  *node = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--) {
+if (!(node = baseurl_nodes[rootId])) continue;
+if (ishttp(xmlNodeGetContent(node))) {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (node) {
+xmlNodeSetContent(node, root_url);
+}
+
+int size = strlen(root_url);
+char *isRootHttp= ishttp(root_url);
+
+char token ='/';
+if (av_strncasecmp(_url[size-1],, 1) != 0) {
+av_strlcat(root_url, "/", size+2);
+size+=2;
+}
+
+for (i = 0; i < n_baseurl_nodes; ++i) {
+if (i==rootId) continue;
+text = xmlNodeGetContent(baseurl_nodes[i]);
+if (text) {
+memset(tmp_str, 0, strlen(tmp_str));
+
+if (!ishttp(text) && isRootHttp) {
+av_strlcpy(tmp_str, root_url, size+1);
+}
+int start = (av_strncasecmp(text, , 1) == 0) ? 1: 0;
+memset(tmp_str_2, 0, strlen(tmp_str_2));
+av_strlcat(tmp_str, text+start, MAX_URL_SIZE);
+xmlFree(text);
+xmlNodeSetContent(baseurl_nodes[i], tmp_str);
+updated = 1;
+}
+}
+
+av_free(path);
+return updated;
+
+}
 static int parse_manifest_representation(AVFormatContext *s, const char *url,
  xmlNodePtr node,
  xmlNodePtr adaptionset_node,
@@ -698,6 +773,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 baseurl_nodes[2] = adaptionset_baseurl_node;
 baseurl_nodes[3] = representation_baseurl_node;
 
+resolve_content_path(s, url, baseurl_nodes, 4);
+
 if (representation_segmenttemplate_node || fragment_template_node) {
 fragment_timeline_node = NULL;
 fragment_templates_tab[0] = representation_segmenttemplate_node;
@@ -993,6 +1070,9 @@ static int parse_manifest(AVFormatContext *s, const char 
*url, AVIOContext *in)
 }
 
 mpd_baseurl_node = find_child_node_by_name(node, "BaseURL");
+if (!mpd_baseurl_node) {
+mpd_baseurl_node = xmlNewNode(node, "BaseURL");
+}
 
 // at now we can handle only one period, with the longest duration
 node = xmlFirstElementChild(node);
@@ -1315,6 +1395,7 @@ static int read_from_url(struct representation *pls, 
struct fragment *seg,
 } else {
 ret = avio_read(pls->input, buf, buf_size);
 }
+
 if (ret > 0)
 pls->cur_seg_offset += ret;
 
@@ -1343,18 +1424,6 @@ static int open_input(DASHContext *c, struct 
representation *pls, struct fragmen
 goto cleanup;
 }
 
-/* Seek to the requested position. If this was a HTTP request, the offset
- * should already be where want it to, but this allows e.g. local testing
- * without a HTTP server. */
-if (!ret && seg->url_offset) {
-int64_t seekret = avio_seek(pls->input, seg->url_offset, SEEK_SET);
-if (seekret < 0) {
-

[FFmpeg-devel] [PATCH 2/2] avcodec: Add hardware metadata to hardware backed decoders

[Philip Langdale]

Now that we have a way to identify hardware backed decoders, let
us do so. I may have missed some.

Signed-off-by: Philip Langdale 
---
 libavcodec/crystalhd.c |  4 +++-
 libavcodec/cuviddec.c  |  4 +++-
 libavcodec/mediacodecdec.c | 24 ++--
 libavcodec/mmaldec.c   |  3 ++-
 libavcodec/qsvdec_h2645.c  |  8 ++--
 libavcodec/qsvdec_other.c  | 12 +---
 libavcodec/v4l2_m2m_dec.c  |  2 ++
 7 files changed, 43 insertions(+), 14 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index 83bc8bf364..0e856f2919 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -786,8 +786,10 @@ static int crystalhd_receive_frame(AVCodecContext *avctx, 
AVFrame *frame)
 .receive_frame  = crystalhd_receive_frame, \
 .flush  = flush, \
 .bsfs   = bsf_name, \
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING, \
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | \
+  AV_CODEC_CAP_HARDWARE, \
 .pix_fmts   = (const enum AVPixelFormat[]){AV_PIX_FMT_YUYV422, 
AV_PIX_FMT_NONE}, \
+.provider   = "crystalhd", \
 };
 
 #if CONFIG_H264_CRYSTALHD_DECODER
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 96d56f406a..21fbbe9970 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -1127,13 +1127,15 @@ static const AVCodecHWConfigInternal 
*cuvid_hw_configs[] = {
 .decode = cuvid_decode_frame, \
 .receive_frame  = cuvid_output_frame, \
 .flush  = cuvid_flush, \
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING, \
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING | \
+  AV_CODEC_CAP_HARDWARE, \
 .pix_fmts   = (const enum AVPixelFormat[]){ AV_PIX_FMT_CUDA, \
 AV_PIX_FMT_NV12, \
 AV_PIX_FMT_P010, \
 AV_PIX_FMT_P016, \
 AV_PIX_FMT_NONE }, \
 .hw_configs = cuvid_hw_configs, \
+.provider   = "cuvid", \
 };
 
 #if CONFIG_HEVC_CUVID_DECODER
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 6d392adb3a..dd630bf6e3 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -538,10 +538,12 @@ AVCodec ff_h264_mediacodec_decoder = {
 .decode = mediacodec_decode_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
+  AV_CODEC_CAP_HARDWARE,
 .caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
 .bsfs   = "h264_mp4toannexb",
 .hw_configs = mediacodec_hw_configs,
+.provider   = "mediacodec",
 };
 #endif
 
@@ -556,10 +558,12 @@ AVCodec ff_hevc_mediacodec_decoder = {
 .decode = mediacodec_decode_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
+  AV_CODEC_CAP_HARDWARE,
 .caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
 .bsfs   = "hevc_mp4toannexb",
 .hw_configs = mediacodec_hw_configs,
+.provider   = "mediacodec",
 };
 #endif
 
@@ -574,9 +578,11 @@ AVCodec ff_mpeg2_mediacodec_decoder = {
 .decode = mediacodec_decode_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
+  AV_CODEC_CAP_HARDWARE,
 .caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
 .hw_configs = mediacodec_hw_configs,
+.provider   = "mediacodec",
 };
 #endif
 
@@ -591,9 +597,11 @@ AVCodec ff_mpeg4_mediacodec_decoder = {
 .decode = mediacodec_decode_frame,
 .flush  = mediacodec_decode_flush,
 .close  = mediacodec_decode_close,
-.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING,
+.capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_AVOID_PROBING |
+  AV_CODEC_CAP_HARDWARE,
 .caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS,
 .hw_configs = mediacodec_hw_configs,
+.provider   = "mediacodec",
 };
 #endif
 
@@ -608,9 +616,11 @@ AVCodec ff_vp8_mediacodec_decoder = {
 .decode = mediacodec_decode_frame,
 .flush  = mediacodec_decode_flush,
 .close  = 

[FFmpeg-devel] [PATCH 0/2] avcodec: metadata for hardware backed decoders

[Philip Langdale]

We have a number of hardware backed implementations in the codebase
that are done as full decoders instead of HWAccels for various
reasons. These decoders cannot be discovered today, and clients
which care end up needing to hardcode their names. It would be
helpful to provide a discovery mechanism.

Philip Langdale (2):
  avcodec: Add metadata to identify hardware backed codecs
  avcodec: Add hardware metadata to hardware backed decoders

 Changelog  |  1 +
 doc/APIchanges |  5 +
 libavcodec/avcodec.h   | 19 +++
 libavcodec/crystalhd.c |  4 +++-
 libavcodec/cuviddec.c  |  4 +++-
 libavcodec/mediacodecdec.c | 24 ++--
 libavcodec/mmaldec.c   |  3 ++-
 libavcodec/qsvdec_h2645.c  |  8 ++--
 libavcodec/qsvdec_other.c  | 12 +---
 libavcodec/v4l2_m2m_dec.c  |  2 ++
 10 files changed, 68 insertions(+), 14 deletions(-)

-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/2] avcodec: Add metadata to identify hardware backed codecs

[Philip Langdale]

If hardware acceleration is implemented through an HWAccel, then it's
easy to recognise, but some hardware implementations are best suited
to implementation as full decoders, and these are not easy to identify.
Clients typically need hardcoded lists of codecs, and usually need to
rely on related codecs using a particular naming convention.

To make it easier to discover these codecs dynamically, we can
introduce an explicit AV_CODEC_CAP_HARDWARE that indicates the codec
is hardware-backed. We also introduce a 'provider' field into AVCodec
that allows for an identifier to be attached to these codecs for
simple matching. The provider could also be used to identify the
use of an external software library.

Unfortunately, we know of at least one case where an external interface
might silently end up using a separate software implementation (libmfx)
and so we introduce AV_CODEC_CAP_MAYBE_NOT_HARDWARE so say that you
can't trust it 100%. It's silly but what can you do?

The expected use-case here is allowing a client application to
enumerate hardware decoding options for a given format and to allow
a user to select one based on a recognisable identifier (the provider).

Signed-off-by: Philip Langdale 
---
 Changelog|  1 +
 doc/APIchanges   |  5 +
 libavcodec/avcodec.h | 19 +++
 3 files changed, 25 insertions(+)

diff --git a/Changelog b/Changelog
index 76d6fad56b..a99edbf4b7 100644
--- a/Changelog
+++ b/Changelog
@@ -21,6 +21,7 @@ version :
 - video mix filter
 - video normalize filter
 - audio lv2 wrapper filter
+- Added codec metadata to identify hardware backed decoders
 
 
 version 3.4:
diff --git a/doc/APIchanges b/doc/APIchanges
index 44a740e51f..7856cb13a1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,11 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-12-xx - xxx - lavc 58.7.100 - avcodec.h
+  Add AV_CODEC_CAP_HARDWARE
+  Add AV_CODEC_CAP_MAYBE_NOT_HARDWARE
+  Add AVCodec.provider
+
 2017-xx-xx - xxx - lavc 58.6.100 - avcodec.h
   Add const to AVCodecContext.hwaccel.
 
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c1e68b1d13..04cfa48665 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1036,6 +1036,16 @@ typedef struct RcOverride{
  * choice for probing.
  */
 #define AV_CODEC_CAP_AVOID_PROBING   (1 << 17)
+/**
+ * Codec is backed by a hardware implementation. Typically used to
+ * identify a non-hwaccel hardware decoder.
+ */
+#define AV_CODEC_CAP_HARDWARE(1 << 18)
+/**
+ * Codec is normally backed by a hardware implementation, but the
+ * external abstraction could be software backed.
+ */
+#define AV_CODEC_CAP_MAYBE_NOT_HARDWARE  (1 << 19)
 /**
  * Codec is intra only.
  */
@@ -3475,6 +3485,15 @@ typedef struct AVCodec {
  * The user can only access this field via avcodec_get_hw_config().
  */
 const struct AVCodecHWConfigInternal **hw_configs;
+
+/**
+ * String that helps identify the external provider for the codec.
+ * For example, if some external hardware decoder provides support
+ * for a variety of codecs, they could each set the same provider
+ * value to signify their relationship. Could also be used to
+ * identify the use of an external software implementation.
+ */
+   const char *provider;
 } AVCodec;
 
 #if FF_API_CODEC_GET_SET
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change.

[Jun Zhao]

From 94d511d93fdb83103fdafbd9ca0d02abfbd2e305 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 28 Nov 2017 21:05:18 +0800
Subject: [PATCH] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution
 change.

Use the following command to reproduce this issue:
make fate-vp8-size-change HWACCEL="vaapi -vaapi_device \
/dev/dri/renderD128 -hwaccel_output_format yuv420p"
SAMPLES=../fate-suite/.

At the same time, reconstruct the public logic as a function.

Signed-off-by: Yun Zhou 
Signed-off-by: Jun Zhao 
---
 libavcodec/vp8.c | 46 ++
 1 file changed, 34 insertions(+), 12 deletions(-)

diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 471c0bb89e..5bf00a44f9 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -167,6 +167,30 @@ static VP8Frame *vp8_find_free_buffer(VP8Context *s)
 return frame;
 }
 
+static enum AVPixelFormat get_pixel_format(VP8Context *s)
+{
+enum AVPixelFormat fmt;
+enum AVPixelFormat pix_fmts[] = {
+#if CONFIG_VP8_VAAPI_HWACCEL
+AV_PIX_FMT_VAAPI,
+#endif
+#if CONFIG_VP8_NVDEC_HWACCEL
+AV_PIX_FMT_CUDA,
+#endif
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_NONE,
+};
+
+fmt = ff_get_format(s->avctx, pix_fmts);
+if (fmt < 0) {
+fmt = AV_PIX_FMT_NONE;
+av_log(s->avctx, AV_LOG_ERROR,
+   "Can not support the format. \n");
+}
+
+return fmt;
+}
+
 static av_always_inline
 int update_dimensions(VP8Context *s, int width, int height, int is_vp7)
 {
@@ -182,6 +206,15 @@ int update_dimensions(VP8Context *s, int width, int 
height, int is_vp7)
 return ret;
 }
 
+if (!is_vp7) {
+s->pix_fmt = get_pixel_format(s);
+if (s->pix_fmt < 0) {
+ret = AVERROR(EINVAL);
+return ret;
+}
+avctx->pix_fmt = s->pix_fmt;
+}
+
 s->mb_width  = (s->avctx->coded_width  + 15) / 16;
 s->mb_height = (s->avctx->coded_height + 15) / 16;
 
@@ -2598,18 +2631,7 @@ int vp78_decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 if (s->actually_webp) {
 // avctx->pix_fmt already set in caller.
 } else if (!is_vp7 && s->pix_fmt == AV_PIX_FMT_NONE) {
-enum AVPixelFormat pix_fmts[] = {
-#if CONFIG_VP8_VAAPI_HWACCEL
-AV_PIX_FMT_VAAPI,
-#endif
-#if CONFIG_VP8_NVDEC_HWACCEL
-AV_PIX_FMT_CUDA,
-#endif
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_NONE,
-};
-
-s->pix_fmt = ff_get_format(s->avctx, pix_fmts);
+s->pix_fmt = get_pixel_format(s);
 if (s->pix_fmt < 0) {
 ret = AVERROR(EINVAL);
 goto err;
-- 
2.14.1

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

[FFmpeg-devel] [PATCH] lavu/hwcontext_opencl.h: fix build on macOS

[Rodger Combs]

---
 libavutil/hwcontext_opencl.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavutil/hwcontext_opencl.h b/libavutil/hwcontext_opencl.h
index 8e34df44cd..ef54486c95 100644
--- a/libavutil/hwcontext_opencl.h
+++ b/libavutil/hwcontext_opencl.h
@@ -19,7 +19,11 @@
 #ifndef AVUTIL_HWCONTEXT_OPENCL_H
 #define AVUTIL_HWCONTEXT_OPENCL_H
 
+#ifdef __APPLE__
+#include 
+#else
 #include 
+#endif
 
 #include "frame.h"
 
-- 
2.14.3

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

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_opencl.h: fix build on macOS

[Jun Zhao]

On 2017/11/28 13:38, Rodger Combs wrote:
> ---
>  libavutil/hwcontext_opencl.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavutil/hwcontext_opencl.h b/libavutil/hwcontext_opencl.h
> index 8e34df44cd..ef54486c95 100644
> --- a/libavutil/hwcontext_opencl.h
> +++ b/libavutil/hwcontext_opencl.h
> @@ -19,7 +19,11 @@
>  #ifndef AVUTIL_HWCONTEXT_OPENCL_H
>  #define AVUTIL_HWCONTEXT_OPENCL_H
>  
> +#ifdef __APPLE__
> +#include 
> +#else
>  #include 
> +#endif
LGTM
>  
>  #include "frame.h"
>  
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/qsvenc: set HRD buffer size

[Zhong Li]

Hypothetical Reference Decoding (HRD) model assumes that data flows into a
buffer of the fixed size BufferSizeInKB with a constant bitrate.
BufferSizeInKB represents the maximum possible size of any compressed frames.

Signed-off-by: Zhong Li 
---
 libavcodec/qsvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index c45b2a6..9283d40 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -429,7 +429,7 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->param.mfx.NumSlice   = avctx->slices;
 q->param.mfx.NumRefFrame= FFMAX(0, avctx->refs);
 q->param.mfx.EncodedOrder   = 0;
-q->param.mfx.BufferSizeInKB = 0;
+q->param.mfx.BufferSizeInKB = (avctx->rc_buffer_size > 0) ? 
avctx->rc_buffer_size / 8000 : 0;
 
 desc = av_pix_fmt_desc_get(sw_format);
 if (!desc)
-- 
1.8.3.1

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

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mxfenc: write reel_name if metadata key is present

[Mark Reid]

On Mon, Nov 27, 2017 at 2:40 AM, Tomas Härdin  wrote:

> On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> > @@ -1396,13 +1410,17 @@ static int mxf_write_package(AVFormatContext
> > *s, MXFPackage *package)
> >  }
> >
> >  // write multiple descriptor reference
> > -if (package->type == SourcePackage) {
> > +if (package->instance == 1) {
>
> Would only ever SourcePackage have instance != 0? What if we have
> multiple MaterialPackage?
> Saying (package->type == SourcePackage && package->instance == 1) might
> be appropriate
>

simple enough, I'll do that


>
> >  mxf_write_local_tag(pb, 16, 0x4701);
> >  if (s->nb_streams > 1) {
> >  mxf_write_uuid(pb, MultipleDescriptor, 0);
> >  mxf_write_multi_descriptor(s);
> >  } else
> >  mxf_write_uuid(pb, SubDescriptor, 0);
> > +} else if (package->instance == 2) {
>
> Same here
>
> > +mxf_write_local_tag(pb, 16, 0x4701);
> > +mxf_write_uuid(pb, TapeDescriptor, 0);
> > +mxf_write_tape_descriptor(s);
> >  }
> >
> >  // write timecode track
> > @@ -1416,7 +1434,7 @@ static int mxf_write_package(AVFormatContext
> > *s, MXFPackage *package)
> >  mxf_write_sequence(s, st, package);
> >  mxf_write_structural_component(s, st, package);
> >
> > -if (package->type == SourcePackage) {
> > +if (package->instance == 1) {
>
> And here
>
> > @@ -1474,6 +1494,26 @@ static int
> > mxf_write_header_metadata_sets(AVFormatContext *s)
> >  }
> >  }
> >
> > +if (entry = av_dict_get(s->metadata, "reel_name", NULL, 0)) {
>
> Parenthesis around this and maybe an equality check. Or move the
> assignment outside the if.
>
>
Ok, I'll move it outside the if

> +packages[2].name = entry->value;
> > +} else {
> > +/* check if any of the streams contain a reel_name */
> > +for (i = 0; i < s->nb_streams; i++) {
> > +st = s->streams[i];
> > +if (entry = av_dict_get(st->metadata, "reel_name", NULL,
> > 0)) {
> > +packages[2].name = entry->value;
> > +break;
>
> Is it possible to set more than one reel_name? Conflicting values
> should probably result in an error (both s->metadata and st->metadata).
>
>
yes this is a bit messy,  mxfdec puts the reel_names on streams. Even if
the all the streams source the same reel package,  I'd like to try and fix
that in mxfdec and put them on format level. How about for mxfenc being
strict and only accepting reel_name metadata at the format level for now?



> /Tomas
> ___
> 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] hls demuxer: add option to defer parsing of variants

[Anssi Hannula]

Hi,

Rainer Hochecker kirjoitti 2017-11-26 12:46:

fixed mem leak poined out by Steven

---
 doc/demuxers.texi |   5 +
 libavformat/hls.c | 304 
--

 2 files changed, 209 insertions(+), 100 deletions(-)


[...]

+
+@item load_all_variants
+If 0, only the first variant/playlist is loaded on open. All other 
variants

+get disabled and can be enabled by setting discard option in program.
+Default value is 1.
 @end table


If playlist download+parsing is indeed taking long enough time that this 
is warranted, I wonder if we should maybe just never read any variant 
playlists in read_header(), and instead set AVFMTCTX_NOHEADER.
Then the user may discard AVPrograms right after open, before unneeded 
playlists are loaded+parsed.


This would avoid having a separate option/mode for this.

Any thoughts?



 @section image2
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 786934af03..c42e0b0f95 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -112,6 +112,7 @@ struct playlist {
 int n_segments;
 struct segment **segments;
 int needed, cur_needed;
+int parsed;
 int cur_seq_no;
 int64_t cur_seg_offset;
 int64_t last_load_time;
@@ -206,6 +207,7 @@ typedef struct HLSContext {
 int strict_std_compliance;
 char *allowed_extensions;
 int max_reload;
+int load_all_variants;
 } HLSContext;

[...]
@@ -721,6 +726,7 @@ static int parse_playlist(HLSContext *c, const char 
*url,

 free_segment_list(pls);
 pls->finished = 0;
 pls->type = PLS_TYPE_UNSPECIFIED;
+pls->parsed = 1;
 }


That "pls->parsed = 1" is in the "reinit old playlist for re-parse" 
block, is that intentional?


I'd think it should rather be at the end of the function alongside 
setting pls->last_load_time, so it is set to 1 whenever parsing has been 
done.



 while (!avio_feof(in)) {
 read_chomp_line(in, line, sizeof(line));

[...]

@@ -1631,6 +1655,124 @@ static int hls_close(AVFormatContext *s)
 return 0;
 }

+static int init_playlist(HLSContext *c, struct playlist *pls)
+{


This init_playlist() seems to be mostly code moved from below, could you 
split the patch so that the first patch moves the code around but does 
not change behavior, and the second patch makes the actual changes (i.e. 
adds the option)?


That would ease e.g. future bisecting.

[...]

+return 0;
+}
+
 static int hls_read_header(AVFormatContext *s)
 {
 void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
@@ -1663,6 +1805,9 @@ static int hls_read_header(AVFormatContext *s)
 if ((ret = parse_playlist(c, s->filename, NULL, s->pb)) < 0)
 goto fail;

+/* first playlist was created, set it to parsed */
+c->variants[0]->playlists[0]->parsed = 1;
+


I think parse_playlist() should set this when it parses something.


 if ((ret = save_avio_options(s)) < 0)
 goto fail;

@@ -1675,8 +1820,15 @@ static int hls_read_header(AVFormatContext *s)
 goto fail;

[...]


 /* Select the starting segments */
 for (i = 0; i < c->n_playlists; i++) {
 struct playlist *pls = c->playlists[i];

-if (pls->n_segments == 0)
+if (pls->n_segments == 0 && !pls->parsed)
 continue;


Why?


 pls->cur_seq_no = select_cur_seq_no(c, pls);
@@ -1736,97 +1892,9 @@ static int hls_read_header(AVFormatContext *s)
 /* Open the demuxer for each playlist */
 for (i = 0; i < c->n_playlists; i++) {
 struct playlist *pls = c->playlists[i];
-AVInputFormat *in_fmt = NULL;
-

[...]

--
Anssi Hannula

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

Re: [FFmpeg-devel] Codec of Audio G.722.1

[Moritz Barsnick]

> [cook @ 0x7fac22815200] Cook version 1297043023 is not implemented. Update
> your FFmpeg version to the newest one from Git.

Did you do this?

> [cook @ 0x7fac22815200] If you want to help, upload a sample of this file to
> ftp://upload.ffmpeg.org/incoming/

Did you do this?

> can you please give some suggestion to solve this question, if available,
> can you please provide a sample to guide me how to do this.

This list is for the development of ffmpeg. Your question is more apt
for the list ffmpeg-user, but since the error message led you here, I
guess it's okay.

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

Re: [FFmpeg-devel] [mov] Remove concept of ctts entries with count > 1.

[Dale Curtis]

Any discussion on this one? Would make the oom fix John put together
simpler I think.

- dale

On Mon, Aug 28, 2017 at 4:09 PM, Dale Curtis 
wrote:

> Previous ctts patches have all changed the system to always using
> count=1 since we expect ctts data to be 1:1 with samples. This deletes
> the concept of count>1 samples for clarity and performance.
>
> Requires "[mov] Bail when invalid sample data is present." to land first.\
>
> - dale
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Carl Eugen Hoyos]

2017-11-26 22:57 GMT+01:00 Jim DeLaHunt :
> On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
>
>> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
>> [...]
>>>
>>> +
>>>   @subheading Subscribe to the ffmpeg-cvslog mailing list.
>>> -It is important to do this as the diffs of all commits are sent there
>>> and
>>> -reviewed by all the other developers. Bugs and possible improvements or
>>> -general questions regarding commits are discussed there. We expect you
>>> to
>>> -react if problems with your code are uncovered.
>>> +Diffs of all commits are sent to the
>>> +@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-cvslog,
>>> ffmpeg-cvslog}
>>> +mailing list. Some developers read this list to review all code base
>>> changes
>>> +from all sources. Subscribing to this list is not mandatory, if
>>> +all you want to do is submit a patch here and there.
>>
>> I am (still) against this change.
>
>
> OK, what specifically are you against?  More important, what are you in
> favour of?

I have no issue with the current text.

If you believe that it is unclear that there is a difference between an
occasional contributor (who most likely would not read -devel nor
-cvslog) and a committer (who is supposed to read -cvslog), then
maybe a patch is useful.

I believe the difference could be considered common sense.

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 27, 2017 6:25 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
> AMD GPUs based on AMF SDK
> 
> On 27/11/17 22:35, Mironov, Mikhail wrote:
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >>> Behalf Of Mark Thompson
> >>> Sent: November 27, 2017 3:11 PM
> >>> To: FFmpeg development discussions and patches  >>> de...@ffmpeg.org>
> >>> Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
> >> AMD
> >>> GPUs based on AMF SDK
> >>>
> >>> From: mmironov 
> >>>
> >>> Requires AMF headers for at least version 1.4.2 (older versions do
> >>> not support building with C).
> >>> ---
> >>> Uses upstream headers from  >>> LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't
> >>> find an official install method so I've assumed that the AMF headers
> >>> are under an AMF/ prefix (they have rather generic names, so they
> >>> need something).  Just copying the two directories from the source
> >>> path to /usr/local/include/AMF or similar is sufficient.
> >>>
> >>> I've also assumed that the features which don't yet exist upstream
> >>> (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
> >>> There might be more version checking needed, but I'm not sure (newer
> >>> version / older header should work because of the version
> >>> initialisation, while older version / newer header fails at that maybe?).
> >>>
> >>> The OS checks are removed, it builds fine on Linux if you have the
> headers.
> >>>
> >>
> >> The public headers from github do not have several fixes that were
> >> done in the customized header.
> >> I could cherry-pick and push them but I did not test this for a while
> >> assuming that the custom header is used.
> >>
> >
> > Pushed.
> 
> Thank you!
> 
> Is there an official way to detect a finer version there?  (The version number
> is still 1.4.4.)  If not, we can just look for one of the just-added enum
> constants for the configure test.

There is AMFQueryVersion() exposed as "C" export. See Factory.h
It will return driver version of runtime but at this point the API is forward 
and backward compatible.
The changes I pushed do not change API, just fixed C  compatibility issues.
So at this point there is no need to check version against header.
In the future if backward compatibility is broken AMFInit() will check header 
version and will return error.

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

Re: [FFmpeg-devel] libavformat/rtpenc_mpegts: check avformat_new_stream() return value

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 09:30:53AM +0800, Pan Bian wrote:
> The function avformat_new_stream() returns a NULL pointer on failure.
> However, in function rtp_mpegts_write_header(), its return value is not
> validated before it is dereferenced. Check the return value against NULL
> to avoid potential NULL dereference.
> 
> Signed-off-by: Pan Bian 
> ---
>  libavformat/rtpenc_mpegts.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
> index 7af02e0..9089d61 100644
> --- a/libavformat/rtpenc_mpegts.c
> +++ b/libavformat/rtpenc_mpegts.c
> @@ -85,6 +85,10 @@ static int rtp_mpegts_write_header(AVFormatContext *s)
>  }
>  rtp_ctx->oformat = rtp_format;
>  st = avformat_new_stream(rtp_ctx, NULL);
> + if (!st) {
> +ret = AVERROR(ENOMEM);
> +goto fail;
> + }
>  st->time_base.num   = 1;
>  st->time_base.den   = 9;
>  st->codecpar->codec_id = AV_CODEC_ID_MPEG2TS;

will apply with the tabs removed

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

[James Darnley]

On 2017-11-27 20:19, Martin Vignali wrote:
> +%macro VBROADCASTI128 2 ; dst xmm/ymm, src : 128bits val
> +%if mmsize == 32
> +vbroadcasti128 %1, %2
> +%else
> +mova   %1, %2
> +%endif
> +%endmacro

If the condition was made "mmsize > 16" would this work correctly for
zmm registers?  (Assume I finally push my AVX-512 patches).

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

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: move some initialization checks to mkv_init

[Carl Eugen Hoyos]

2017-11-27 18:17 GMT+01:00 James Almer :
> It's the correct place for them.
>
> Signed-off-by: James Almer 
> ---
>  libavformat/matroskaenc.c | 39 +--
>  1 file changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 06126781f8..35857bb02e 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -1859,25 +1859,7 @@ static int mkv_write_header(AVFormatContext *s)
>  av_dict_get(s->metadata, "alpha_mode", NULL, 0))
>  version = 4;
>
> -if (s->nb_streams > MAX_TRACKS) {
> -av_log(s, AV_LOG_ERROR,
> -   "At most %d streams are supported for muxing in Matroska\n",
> -   MAX_TRACKS);
> -return AVERROR(EINVAL);
> -}
> -
>  for (i = 0; i < s->nb_streams; i++) {
> -if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_ATRAC3 ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_COOK ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RA_288 ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_SIPR ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV10 ||
> -s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV20) {
> -av_log(s, AV_LOG_ERROR,
> -   "The Matroska muxer does not yet support muxing %s\n",
> -   avcodec_get_name(s->streams[i]->codecpar->codec_id));
> -return AVERROR_PATCHWELCOME;
> -}
>  if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_OPUS ||
>  av_dict_get(s->streams[i]->metadata, "stereo_mode", NULL, 0) ||
>  av_dict_get(s->streams[i]->metadata, "alpha_mode", NULL, 0))
> @@ -2656,6 +2638,27 @@ static int mkv_init(struct AVFormatContext *s)
>  {
>  int i;
>
> +if (s->nb_streams > MAX_TRACKS) {
> +av_log(s, AV_LOG_ERROR,
> +   "At most %d streams are supported for muxing in Matroska\n",
> +   MAX_TRACKS);
> +return AVERROR(EINVAL);
> +}
> +
> +for (i = 0; i < s->nb_streams; i++) {
> +if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_ATRAC3 ||
> +s->streams[i]->codecpar->codec_id == AV_CODEC_ID_COOK ||
> +s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RA_288 ||
> +s->streams[i]->codecpar->codec_id == AV_CODEC_ID_SIPR ||
> +s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV10 ||
> +s->streams[i]->codecpar->codec_id == AV_CODEC_ID_RV20) {
> +av_log(s, AV_LOG_ERROR,
> +   "The Matroska muxer does not yet support muxing %s\n",
> +   avcodec_get_name(s->streams[i]->codecpar->codec_id));
> +return AVERROR_PATCHWELCOME;
> +}
> +}

(Since I may have written this)

If this is the more correct place, please commit.

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

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

[Dale Curtis]

Ping?

On Tue, Nov 21, 2017 at 3:12 PM, Dale Curtis 
wrote:

> Otherwise ff_alloc_extradata() just leaks any existing allocated
> memory.
>
> Signed-off-by: Dale Curtis 
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Ronald S. Bultje]

Hi,

On Mon, Nov 27, 2017 at 6:03 PM, Carl Eugen Hoyos 
wrote:

> 2017-11-26 22:57 GMT+01:00 Jim DeLaHunt :
> > On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
> >
> >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
> >> [...]
> >>>
> >>> +
> >>>   @subheading Subscribe to the ffmpeg-cvslog mailing list.
> >>> -It is important to do this as the diffs of all commits are sent there
> >>> and
> >>> -reviewed by all the other developers. Bugs and possible improvements
> or
> >>> -general questions regarding commits are discussed there. We expect you
> >>> to
> >>> -react if problems with your code are uncovered.
> >>> +Diffs of all commits are sent to the
> >>> +@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-cvslog,
> >>> ffmpeg-cvslog}
> >>> +mailing list. Some developers read this list to review all code base
> >>> changes
> >>> +from all sources. Subscribing to this list is not mandatory, if
> >>> +all you want to do is submit a patch here and there.
> >>
> >> I am (still) against this change.
> >
> >
> > OK, what specifically are you against?  More important, what are you in
> > favour of?
>
> I have no issue with the current text.
>
> If you believe that it is unclear that there is a difference between an
> occasional contributor (who most likely would not read -devel nor
> -cvslog) and a committer (who is supposed to read -cvslog), then
> maybe a patch is useful.


FYI I'm a committer and I do not read -cvslog.

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

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

[Carl Eugen Hoyos]

2017-11-27 19:30 GMT+01:00 Bjorn Roche :
>
> On Fri, Nov 3, 2017 at 8:11 PM, Carl Eugen Hoyos  wrote:
>
>> 2017-10-24 18:40 GMT+02:00 Bjorn Roche :
>>
>> > - I don’t know if/how to update the FATE tests.
>>
>> A quick way (that needs some double-checking) is:
>> $ make GEN=1 SAMPLES=fate-suite fate
>>
>> (This overwrites all values with the new output.)
>
> Thanks. I ended up doing it manually to be sure, but this is useful!
>
>> Is the new side-data unavoidable?
>> (Would the only alternative be to merge the muxer into the
>> encoder?)
>
> The only way I can see is to move some functionality between the mixer and
> the encoder. It's not a clear line between the codec and the container in
> GIF, so I wouldn't object to an approach different from the one I took.

(Just a question!)

Does remuxing (animated) gif to gif work now? (I believe it does.)
Does it work with your patch?

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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Mark Thompson
> > Sent: November 27, 2017 3:11 PM
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
> AMD
> > GPUs based on AMF SDK
> >
> > From: mmironov 
> >
> > Requires AMF headers for at least version 1.4.2 (older versions do not
> > support building with C).
> > ---
> > Uses upstream headers from  > LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't find
> > an official install method so I've assumed that the AMF headers are
> > under an AMF/ prefix (they have rather generic names, so they need
> > something).  Just copying the two directories from the source path to
> > /usr/local/include/AMF or similar is sufficient.
> >
> > I've also assumed that the features which don't yet exist upstream
> > (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
> > There might be more version checking needed, but I'm not sure (newer
> > version / older header should work because of the version
> > initialisation, while older version / newer header fails at that maybe?).
> >
> > The OS checks are removed, it builds fine on Linux if you have the headers.
> >
> 
> The public headers from github do not have several fixes that were done in
> the customized header.
> I could cherry-pick and push them but I did not test this for a while assuming
> that the custom header is used.
> 

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

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

On Thu, Nov 23, 2017 at 3:54 PM, Carl Eugen Hoyos 
wrote:
>
> @Dale:
> Could you do that?
>

Thanks to John for putting out a patch for this.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavd/alsa: Double maximum alsa buffer size.

[Carl Eugen Hoyos]

2017-11-27 16:29 GMT+01:00 Nicolas George :
> Carl Eugen Hoyos (2017-11-27):
>> ffmpeg | branch: master | Carl Eugen Hoyos  | Mon Nov 27 
>> 14:05:28 2017 +0100| [b7324950c0fc84a93d4e7abdfd2b75ea647ec3fc] | committer: 
>> Carl Eugen Hoyos
>>
>> lavd/alsa: Double maximum alsa buffer size.
>>
>> Fixes recording from ATI Wonder 600 USB adapter, regression since e35c674d.
>
> Why was this pushed without discussion?
>
>> Reported and analyzed by: Marco Paolieri, paolieri at gmail
>
> This is no analyze, just empirical guesswork.

The patch that introduced the regression was not discussed and
it used a guessed limit afair.
The patch that fixed ticket #373 simply doubled the value to fix
a particular use-case.
After this patch that follows this logic, the possible allocation
is still a magnitude smaller than the original commit claims.
(I cannot test the failing case.)

Do you want me to revert?
Any better suggestions?

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

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Carl Eugen Hoyos]

2017-11-26 22:44 GMT+01:00 Jim DeLaHunt :
> On 2017-11-26 03:42, Carl Eugen Hoyos wrote:
>>
>> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt :
>>>
>>> -@subsection Documentation/Other
>>> +@section Documentation/Other
>>> +@subheading Subscribe to the ffmpeg-devel mailing list.
>>> +It is important to be subscribed to the
>>
>> Of course it is important but I would much, much prefer
>> if people send their patches without being subscribed
>> than not sending their patches because it is implied
>> that they cannot send patches if they don't want to
>> subscribe
>> But if people are not interested in improving their contribution,
>> I would still prefer the patches to be sent.
>
>
> So, how realistic is this concern about non-subscribers sending patches to
> ffmpeg-devel?  Does it actually happen?

This is very realistic afair.

> Can you point to, say, three patches
> in the last six months which were sent by non-subscribers to ffmpeg-devel

No, the mail admins could (or explain that I am wrong.)

> and were applied to the code base?

I was under the impression the patches that were not
applied would support my point.

> Given how so many of the patches submitted by subscribers who know the
> unwritten rules are subjected to veto and revision, I would be surprised if
> many non-subscribers who are ignorant of the unwritten rules would produce
> something satisfactory.
>
> That said, would your concern be addressed if I were to add this sentence:
>
>However, it is more important to the project that we receive your
>patch than that you be subscribed to the ffmpeg-devel list. If you
>have a patch, and don't want to subscribe and discuss the patch,
>then please do send it to the list.

Sure but I was hoping that his is common sense unless explicitely
denied.

>
> (I am tempted to add a phrase like, "If you want to send your patch to
> ffmpeg-devel without discussion, as if  abandoning your baby on the steps of
> the orphanage, please do; one of the kind caregivers on the list may pick it
> up and find it a good home."  But this is probably too snarky to be
> appropriate.)

No objections;-)

>>> +@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel,
>>> ffmpeg-devel}
>>> +mailing list, because any patch you contribute must be sent there
>>
>> No:
>> I believe it is very important that trivial patches are not sent
>> to the development mailing list - its volume is already so big
>> that some patches are sadly (!) forgotten.
>
> Tell me more about the procedure for trivial patches. I have not seen this
> documented, and I don't know about it. Does this apply to occasional
> contributors, or only to trusted experienced ffmpeg project members with
> commit privileges to the repository?

There is a difference between contributors and committers and
this may be the reason for our misunderstanding.

> The proposed text does not distinguish between occasional contributors and
> experienced project members. Maybe it should. I believe that the main
> audience of `doc/developer.html` is new and occasional contributors, because
> the experienced members will have internalised all the undocumented norms,
> and won't be referring to this page.
>
> What revised wording do you propose for the above phrase "any patch you
> contribute must be sent there"?
>
>>> +Also, this list is where bugs and possible improvements or
>>
>> I believe this is misleading or even wrong.
>
> Oh?  I took this wording from the existing
>  regarding the
> ffmpeg-cvslog list:
> "Bugs and possible improvements or general questions regarding commits are
> discussed there."
> What is misleading or wrong about this wording? What is your objection?

Bug fixes and patches that implement improvements are discussed on
ffmpeg-devel and therefore, in this specific cases, bugs and possible
improvement are discussed. Bugs without fixes and improvements
without patches should not be discussed on ffmpeg-devel.

> What alternate wording would you propose for this sentence, which describes
> why contributors should pay attention to the content of ffmpeg-devel?
>>>
>>> +general questions regarding commits are discussed. That may be helpful
>>> +information as you write your contribution. Finally, by being a list
>>> +subscriber your contribution will be posted immediately to the list,
>>> +without the moderation hold which messages from non-subscribers
>>> experience.
>>> +
>
>
> [...]
>
> I think what is important about this new section is that it describes the
> policy and importance of the ffmpeg-devel list. It's interesting that the
> project had not put this into words in the current documentation. I'm trying
> to do that.  Carl Eugen, you are quick to object to what you don't like
> about proposed wording. I think it's especially important that you suggest
> wording that does capture what you do support. You obviously care.

I 

[FFmpeg-devel] [PATCH]ffmpeg_opt: Silence a const warning

[Carl Eugen Hoyos]

Hi!

Attached patch fixes a warning:
fftools/ffmpeg_opt.c: In function ‘add_input_streams’:
fftools/ffmpeg_opt.c:804:29: warning: assignment discards ‘const’
qualifier from pointer target type

Please comment, Carl Eugen
From 5e1be030521a4253dc8385567ef359ef794f0820 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 27 Nov 2017 23:54:33 +0100
Subject: [PATCH] ffmpeg_opt: Constify hwaccel pointer.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Fixes a warning:
fftools/ffmpeg_opt.c:804:29: warning: assignment discards ‘const’ qualifier from pointer target type
---
 fftools/ffmpeg_opt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 9445a2d..0633ea7 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -702,7 +702,8 @@ static void add_input_streams(OptionsContext *o, AVFormatContext *ic)
 AVStream *st = ic->streams[i];
 AVCodecParameters *par = st->codecpar;
 InputStream *ist = av_mallocz(sizeof(*ist));
-char *framerate = NULL, *hwaccel = NULL, *hwaccel_device = NULL;
+char *framerate = NULL, *hwaccel_device = NULL;
+const char *hwaccel = NULL;
 char *hwaccel_output_format = NULL;
 char *codec_tag = NULL;
 char *next;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

[Michael Niedermayer]

On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote:
> Every bitstream filter behaves as intended now, so there's no need to
> wait for the first packet of every stream.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/avformat.h |  2 +-
>  libavformat/internal.h |  6 -
>  libavformat/mux.c  | 52 
> --
>  libavformat/options_table.h|  2 +-
>  libavformat/tests/fifo_muxer.c | 52 
> --
>  tests/ref/fate/fifo-muxer-tst  |  1 -
>  6 files changed, 12 insertions(+), 103 deletions(-)

Is this intended to change any files ?

this changes slightly:
./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv

not saying this is a issue in the patch or anything (i am in favor of
the simplification in fact), just that i saw this change

[...]
-- 
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.


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

Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 27/11/17 22:35, Mironov, Mikhail wrote:
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>>> Of Mark Thompson
>>> Sent: November 27, 2017 3:11 PM
>>> To: FFmpeg development discussions and patches >> de...@ffmpeg.org>
>>> Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for
>> AMD
>>> GPUs based on AMF SDK
>>>
>>> From: mmironov 
>>>
>>> Requires AMF headers for at least version 1.4.2 (older versions do not
>>> support building with C).
>>> ---
>>> Uses upstream headers from >> LibrariesAndSDKs/AMF/tree/master/amf/public/include>.  I couldn't find
>>> an official install method so I've assumed that the AMF headers are
>>> under an AMF/ prefix (they have rather generic names, so they need
>>> something).  Just copying the two directories from the source path to
>>> /usr/local/include/AMF or similar is sufficient.
>>>
>>> I've also assumed that the features which don't yet exist upstream
>>> (H.264 CONSTRAINED profiles) will appear in a future version 1.5.0.
>>> There might be more version checking needed, but I'm not sure (newer
>>> version / older header should work because of the version
>>> initialisation, while older version / newer header fails at that maybe?).
>>>
>>> The OS checks are removed, it builds fine on Linux if you have the headers.
>>>
>>
>> The public headers from github do not have several fixes that were done in
>> the customized header.
>> I could cherry-pick and push them but I did not test this for a while 
>> assuming
>> that the custom header is used.
>>
> 
> Pushed.

Thank you!

Is there an official way to detect a finer version there?  (The version number 
is still 1.4.4.)  If not, we can just look for one of the just-added enum 
constants for the configure test.

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

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

[Lou Logan]

On Mon, Nov 27, 2017, at 02:22 PM, Lou Logan wrote:
>
> To clarify, in this case it was a reply, not a message.

Should have typed "patch" there, not message.

Actually reading message before sending this time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mxfenc: write reel_name if metadata key is present

[Tomas Härdin]

On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> @@ -1396,13 +1410,17 @@ static int mxf_write_package(AVFormatContext
> *s, MXFPackage *package)
>  }
>  
>  // write multiple descriptor reference
> -if (package->type == SourcePackage) {
> +if (package->instance == 1) {

Would only ever SourcePackage have instance != 0? What if we have
multiple MaterialPackage?
Saying (package->type == SourcePackage && package->instance == 1) might
be appropriate

>  mxf_write_local_tag(pb, 16, 0x4701);
>  if (s->nb_streams > 1) {
>  mxf_write_uuid(pb, MultipleDescriptor, 0);
>  mxf_write_multi_descriptor(s);
>  } else
>  mxf_write_uuid(pb, SubDescriptor, 0);
> +} else if (package->instance == 2) {

Same here

> +mxf_write_local_tag(pb, 16, 0x4701);
> +mxf_write_uuid(pb, TapeDescriptor, 0);
> +mxf_write_tape_descriptor(s);
>  }
>  
>  // write timecode track
> @@ -1416,7 +1434,7 @@ static int mxf_write_package(AVFormatContext
> *s, MXFPackage *package)
>  mxf_write_sequence(s, st, package);
>  mxf_write_structural_component(s, st, package);
>  
> -if (package->type == SourcePackage) {
> +if (package->instance == 1) {

And here

> @@ -1474,6 +1494,26 @@ static int
> mxf_write_header_metadata_sets(AVFormatContext *s)
>  }
>  }
>  
> +if (entry = av_dict_get(s->metadata, "reel_name", NULL, 0)) {

Parenthesis around this and maybe an equality check. Or move the
assignment outside the if.

> +packages[2].name = entry->value;
> +} else {
> +/* check if any of the streams contain a reel_name */
> +for (i = 0; i < s->nb_streams; i++) {
> +st = s->streams[i];
> +if (entry = av_dict_get(st->metadata, "reel_name", NULL,
> 0)) {
> +packages[2].name = entry->value;
> +break;

Is it possible to set more than one reel_name? Conflicting values
should probably result in an error (both s->metadata and st->metadata).

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat/id3v2: add some ID3v2.3 tags convertion

[tiejun.peng]

Signed-off-by: tiejun.peng 
---
 libavformat/id3v2.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
index 6c216ba..1cf759b 100644
--- a/libavformat/id3v2.c
+++ b/libavformat/id3v2.c
@@ -56,6 +56,11 @@ const AVMetadataConv ff_id3v2_34_metadata_conv[] = {
 { "TRCK", "track"},
 { "TSSE", "encoder"  },
 { "USLT", "lyrics"   },
+{ "TYER", "year" },
+{ "TDAT", "date" },
+{ "TMED", "media_type"   },
+{ "TOLY", "author"   },
+{ "TBPM", "BPM"  },
 { 0 }
 };
 
-- 

Please have a look this patch, give some advice or merge it.
Thank you.

2.7.4



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

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

I also noticed that recently there is a lot of activity to add full Nvidia 
decoders  to FFmpeg (VC1, MPEG4, VP8, VP9 etc.).
I am guessing this is to overcome DXVA or VAAPI shortcoming. What about AMD? We 
also have them.


The primary motivation here is that nvidia abandoned vdpau, so to access 
more modern decoder features, which on Windows are easily available 
through DXVA2/D3D11VA, you are forced to use their API.


If AMD properly supports all those(most prominently VP9 and 10/12bit) 
via vaapi/dxva, there shouldn't be a reason for another API.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avformat/mxfenc: pass MXFPackage around instead of type

[Tomas Härdin]

On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> ---
>  libavformat/mxfenc.c | 99 +-
> --
>  1 file changed, 55 insertions(+), 44 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 035e65ed43..ed6ecbf541 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -101,6 +101,12 @@ typedef struct MXFContainerEssenceEntry {
>  void (*write_desc)(AVFormatContext *, AVStream *);
>  } MXFContainerEssenceEntry;
>  
> +typedef struct MXFPackage {
> +char *name;
> +enum MXFMetadataSetType type;
> +int instance;
> +} MXFPackage;
> [...]

Looks OK. This would make it easier if someone is crazy enough to
implement the higher op types in the future. I still maintain that
libmxf/bmxlib is better for that however

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

[hydra3333]

never mind.  found something that works, only posted here for closure.

eg
.\ffmpeg.exe -hide_banner -v verbose -init_hw_device 
opencl=ocl:1.0 -filter_hw_device ocl -i 
".\test_01.mpg" -an -map_metadata -1 -sws_flags 
lanczos+accurate_rnd+full_chroma_int+full_chroma_inp -filter_complex 
"[0:v]yadif=0:0:0,hwupload,unsharp_opencl=lx=3:ly=3:la=0.5:cx=3:cy=3:ca=0.5,hwdownload,setdar=dar=16/9" 
-r 25 -c:v h264_nvenc -preset slow -bf 2 -g 50 -refs 3 -rc:v 
vbr_hq -rc-lookahead:v 32 -cq 22 -qmin 16 -qmax 26 -coder cabac -movflags 
+faststart -profile:v high -level 4.1 -pixel_format yuv420p -y 
".\test_01.newest.MP4" 


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

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfenc: use track count to generate component instance uuid

[Tomas Härdin]

On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote:
> ---
>  libavformat/mxf.h   |  1 -
>  libavformat/mxfenc.c| 45 +
> 
>  tests/ref/fate/copy-trac4914|  2 +-
>  tests/ref/fate/time_base|  2 +-
>  tests/ref/lavf/mxf  |  6 +++---
>  tests/ref/lavf/mxf_d10  |  2 +-
>  tests/ref/lavf/mxf_dv25 |  2 +-
>  tests/ref/lavf/mxf_dvcpro50 |  2 +-
>  tests/ref/lavf/mxf_opatom   |  2 +-
>  tests/ref/lavf/mxf_opatom_audio |  2 +-
>  10 files changed, 38 insertions(+), 28 deletions(-)
> [...]
> @@ -846,6 +847,10 @@ static void
> mxf_write_track(AVFormatContext *s, AVStream *st, MXFPackage *packag
>  MXFContext *mxf = s->priv_data;
>  AVIOContext *pb = s->pb;
>  MXFStreamContext *sc = st->priv_data;
> +int instance = package->uuid_offset;
> +
> +if (st != mxf->timecode_track)
> +instance += st->index + 1;
>  
>  mxf_write_metadata_key(pb, 0x013b00);
>  PRINT_KEY(s, "track key", pb->buf_ptr - 16);
> 
>  static int mxf_write_essence_container_data(AVFormatContext *s)
> @@ -1443,11 +1451,12 @@ static int
> mxf_write_header_metadata_sets(AVFormatContext *s)
>  AVDictionaryEntry *entry = NULL;
>  AVStream *st = NULL;
>  int i;
> -
> +int track_count = 0;
>  MXFPackage packages[2] = {};
>  int package_count = 2;
>  packages[0].type = MaterialPackage;
>  packages[1].type = SourcePackage;
> +packages[1].instance = 1;
>  
>  if (entry = av_dict_get(s->metadata, "material_package_name",
> NULL, 0))
> packages[0].name = entry->value;
> @@ -1468,8 +1477,10 @@ static int
> mxf_write_header_metadata_sets(AVFormatContext *s)
>  mxf_write_preface(s);
>  mxf_write_identification(s);
>  mxf_write_content_storage(s, packages, package_count);
> -for (i = 0; i < package_count; i++)
> -mxf_write_package(s, [i]);
> +for (i = 0; i < package_count; i++) {
> +packages[i].uuid_offset = track_count;
> +track_count += mxf_write_package(s, [i]);
> +}

I see st->index + 1 when deriving instance from uuid_offset, are you
sure there isn't a potential off-by-one error here? An MP track and SP
track getting the same UUID or something. I guess type is enough to
differentiate, but then why does instance need uuid_offset?

/Tomas

signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel