Re: [FFmpeg-devel] [PATCH] vaapi_h265: general_level_idc should times 3.

[Li, Zhong]

>  libavcodec/vaapi_encode_h265.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c
> b/libavcodec/vaapi_encode_h265.c index 3ae92a7..32b8bc6 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -219,7 +219,7 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>  .general_non_packed_constraint_flag = 1,
>  .general_frame_only_constraint_flag = 1,
> 
> -.general_level_idc = avctx->level,
> +.general_level_idc = avctx->level * 3,

LGTM. 
Actually it is a regression introduced by commit 
00179664bccd1dd6fa0d1c40db453528757bf6f7. 

>  };

___
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)]

[Jim DeLaHunt]

On 2017-11-27 15:03, 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.


With respect, this section of ffmpeg.org/develop.html is not intended 
for an experienced, knowledgeable, deeply involved senior committer like 
you.  So it doesn't really matter that you have no issue with the 
current text. What matters is whether a new developer, trying to learn 
how to contribute to ffmpeg, has an issue with the text.


I can tell you that, as a new contributor reading this section with 
fresh eyes, I most certainly do have an issue with this text. It says 
things about how ffmpeg-cvslog are used that are flat out incorrect. 
Incorrect instructions waste time and cause confusion.



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 will point out that two more people, Ronald[1] and Rostislav[2], do 
not behave in accordance with your belief that committers are supposed 
to read -cvslog. How sure are you that your belief reflects what the 
project actually expects?


I proposed my wording above.  What wording describing -cvslog, which 
corrects the incorrect information and reflects what your colleagues 
tell you about how they use the list, would you accept?



I believe the difference could be considered common sense.
As I said in the thread about ffmpeg-devel[3], Your sense of what is 
common might be biased by how much you know. I am here to tell you that 
the paragraphs in this patch are not at all "common sense". New 
contributors need to have them said out loud.

[1] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221152.html
[2] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221155.html
[3] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/221199.html

My goal here is to fix the bug in ffmpeg.org/developer.html, in the 
section which describes the -cvslog mailing list. I'll make the patch. 
Just tell me what wording will pass review.


--
--Jim DeLaHunt, j...@jdlh.com http://blog.jdlh.com/ (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

___
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)]

[Clément Bœsch]

On Mon, Nov 27, 2017 at 11:19:01PM +, Rostislav Pehlivanov wrote:
> 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.

I'm subscribed to cvslog, and sometimes use it to comment on a commit.
But when I do, I CC ffmpeg-devel anyway. I don't think cvslog subscription
should be mandatory at all, even for core developers. It's fine to
acknowledge its existence in the developers documentation though.

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] avdevice/gdigrab: Fix screen size and mouse position calculations on hi-DPI screens

[Harald Gaechter]

Signed-off-by: Harald Gaechter 
---
 libavdevice/gdigrab.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/libavdevice/gdigrab.c b/libavdevice/gdigrab.c
index 87f5012034..ff2ef3b162 100644
--- a/libavdevice/gdigrab.c
+++ b/libavdevice/gdigrab.c
@@ -235,7 +235,9 @@ gdigrab_read_header(AVFormatContext *s1)
 AVStream   *st   = NULL;
 
 int bpp;
+int horzres;
 int vertres;
+int desktophorzres;
 int desktopvertres;
 RECT virtual_rect;
 RECT clip_rect;
@@ -279,11 +281,13 @@ gdigrab_read_header(AVFormatContext *s1)
 GetClientRect(hwnd, &virtual_rect);
 } else {
 /* desktop -- get the right height and width for scaling DPI */
+horzres = GetDeviceCaps(source_hdc, HORZRES);
 vertres = GetDeviceCaps(source_hdc, VERTRES);
+desktophorzres = GetDeviceCaps(source_hdc, DESKTOPHORZRES);
 desktopvertres = GetDeviceCaps(source_hdc, DESKTOPVERTRES);
 virtual_rect.left = GetSystemMetrics(SM_XVIRTUALSCREEN);
 virtual_rect.top = GetSystemMetrics(SM_YVIRTUALSCREEN);
-virtual_rect.right = (virtual_rect.left + 
GetSystemMetrics(SM_CXVIRTUALSCREEN)) * desktopvertres / vertres;
+virtual_rect.right = (virtual_rect.left + 
GetSystemMetrics(SM_CXVIRTUALSCREEN)) * desktophorzres / horzres;
 virtual_rect.bottom = (virtual_rect.top + 
GetSystemMetrics(SM_CYVIRTUALSCREEN)) * desktopvertres / vertres;
 }
 
@@ -447,7 +451,9 @@ static void paint_mouse_pointer(AVFormatContext *s1, struct 
gdigrab *gdigrab)
 POINT pos;
 RECT clip_rect = gdigrab->clip_rect;
 HWND hwnd = gdigrab->hwnd;
+int horzres = GetDeviceCaps(gdigrab->source_hdc, HORZRES);
 int vertres = GetDeviceCaps(gdigrab->source_hdc, VERTRES);
+int desktophorzres = GetDeviceCaps(gdigrab->source_hdc, 
DESKTOPHORZRES);
 int desktopvertres = GetDeviceCaps(gdigrab->source_hdc, 
DESKTOPVERTRES);
 info.hbmMask = NULL;
 info.hbmColor = NULL;
@@ -483,7 +489,7 @@ static void paint_mouse_pointer(AVFormatContext *s1, struct 
gdigrab *gdigrab)
 }
 
 //that would keep the correct location of mouse with hidpi screens
-pos.x = pos.x * desktopvertres / vertres;
+pos.x = pos.x * desktophorzres / horzres;
 pos.y = pos.y * desktopvertres / vertres;
 
 av_log(s1, AV_LOG_DEBUG, "Cursor pos (%li,%li) -> (%li,%li)\n",
-- 
2.15.0

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

Re: [FFmpeg-devel] AMD external header

[Timo Rothenpieler]

Your use-case looks like an argument for moving the external headers 
into some separate repository. Not that I personally care much about 
bundling or not bundling. To me the more important question seems to be 
whether to auto-enable the encoders/decoders that depend on the external 
headers and libraries or not.


At least nvenc will stay as auto-enable even with out-of-tree headers, 
except that it will obviously check if it has the required headers 
available.




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 3/4] avformat/mxfenc: write reel_name if metadata key is present

[Tomas Härdin]

On 2017-11-28 05:35, Mark Reid wrote:

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?


Yes, strictness is good. Can always be relaxed later, unlike the opposite

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Fixed initial setting for end_pts

[Steven Liu]

2017-11-27 13:16 GMT+08:00 Steven Liu :
> 2017-11-27 13:03 GMT+08:00 Karthick J :
>> This patch fixes Bug #6868
>> Sometimes end_pts is getting initialized to audio stream's
>> first pts, while the duration is calculated based on video stream's pts.
>> In this patch the end_pts is initialized with the correct stream's first pts.
>> ---
>>  libavformat/hlsenc.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 30ccf73..6997a5c 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1737,6 +1737,7 @@ static int hls_write_header(AVFormatContext *s)
>>  vs->sequence   = hls->start_sequence;
>>  hls->recording_time = (hls->init_time ? hls->init_time : hls->time) * 
>> AV_TIME_BASE;
>>  vs->start_pts  = AV_NOPTS_VALUE;
>> +vs->end_pts  = AV_NOPTS_VALUE;
>>  vs->current_segment_final_filename_fmt[0] = '\0';
>>
>>  if (hls->flags & HLS_SPLIT_BY_TIME && hls->flags & 
>> HLS_INDEPENDENT_SEGMENTS) {
>> @@ -2111,7 +2112,6 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>
>>  if (vs->start_pts == AV_NOPTS_VALUE) {
>>  vs->start_pts = pkt->pts;
>> -vs->end_pts   = pkt->pts;
>>  }
>>
>>  if (vs->has_video) {
>> @@ -2123,6 +2123,8 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>  is_ref_pkt = can_split = 0;
>>
>>  if (is_ref_pkt) {
>> +if (vs->end_pts == AV_NOPTS_VALUE)
>> +vs->end_pts = pkt->pts;
>>  if (vs->new_start) {
>>  vs->new_start = 0;
>>  vs->duration = (double)(pkt->pts - vs->end_pts)
>> --
>> 1.9.1
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> LGTM,
>
> Wait the reporter feedback
>
>
> Thanks

pushed


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

Re: [FFmpeg-devel] AMD external header

[Nicolas George]

Pavel Koshevoy (2017-11-27):
> That is unnecessarily un-diplomatic and will likely offend the
> contributors from nvidia and amd.

Well, I find offensive that they benefit from my work yet make extra
efforts to make sure I cannot benefit from theirs. Maybe I should start
putting my contributions under GPL and not LGPL, what do you think?

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

I understand it is more convenient for you than what the vendors
provide, but why should the effort of making things more convenient be
carried by the FFmpeg developers?

It has a non-negligible cost: more testing required, git grep pollution,
all the while giving these companies an unfair advantage against the
companies that play by the rules of Libre software and inciting them to
continue in that direction.

I think the whole compat directory is misguided, but these headers for
external libraries are the worse of it.

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] Fix for ticket 6658 (Dash demuxer segfault)

[Carl Eugen Hoyos]

2017-11-28 1:46 GMT+01:00 Colin NG :

> +char tmp_str[MAX_URL_SIZE];
> +char tmp_str_2[MAX_URL_SIZE];

Assuming this is not speed-critical code, please also
allocate these two with av_malloc(), FFmpeg can be
compiled for systems with tiny stack.

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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Carl Eugen Hoyos]

2017-11-28 8:50 GMT+01:00 Felix Matouschek :

> One last note if you try to build it yourself:
> Your NDK needs to have the patch in commit be9b8bc of this
> issue https://github.com/android-ndk/ndk/issues/559 applied.

Sorry if I misunderstand:
The patch breaks default compilation for Android?

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

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

[Carl Eugen Hoyos]

2017-11-28 6:20 GMT+01:00 Jun Zhao :

Could be split.

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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Am 28.11.2017 14:01, schrieb Carl Eugen Hoyos:


The patch breaks default compilation for Android?


Actually... you are right, it does.
It's a bit unfortunate as the header file in the NDK is broken.

We can't work around that in ffmpeg, the NDK needs to be fixed.
As soon as you include NdkCameraManager.h even to official examples fail 
to build.

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

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Felix Matouschek]

Sorry... tested it again, it does not break the default compilation.

The library check in the configure script just fails and the indev is 
not included when using the broken NDK.

___
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

[Devin Heitmueller]

Hello Marton,

Thanks for taking the time to review.  Most of the comments you’ve raised will 
be fixed and I’ll resubmit an updated patch.  Comments on other issues inline 
below.
>> 
>>/* Options */
>>int list_devices;
>> @@ -88,6 +93,7 @@ struct decklink_ctx {
>>DecklinkPtsSource audio_pts_source;
>>DecklinkPtsSource video_pts_source;
>>int draw_bars;
>> +int raw_format;
> 
> Since this header includes decklink headers, this can be BMDPixelFormat 
> instead of int, and you can use the decklink constants directly instead of 
> MKBETAG.

I used MKBETAG because that was what was being used in decklink_dec.cpp (and I 
wanted to be consistent).  That said, I have no objection to changing it.

> 
> For older decklink models (E.g. Decklink SDI, Decklink Duo 1), when you 
> capture in 8 bit mode, you can only query 8bit VANC. For output, can you 
> always use 10-bit VANC? Even if you use 8bit mode for video? Because if you 
> can't, then it might make sense to return silently here, or only warn to user 
> once, not for every frame (and maybe disable vanc_support?).

All decklink models require that VANC be in the same bit depth as video capture 
(i.e. with both older and newer models you cannot do 8-bit video with 10-bit 
VANC or vice-versa).  The only exception is the RGB formats which do VANC in 
10-bit YUV.  The decklink_construct_vanc() function is only ever called if the 
device is putting out 10-bit video, and thus your question about putting out 
10-bit VANC when doing 8-bit video isn’t an issue since we never hit that code 
path.  

In summary, 8-bit VANC isn’t supported in the module, and I don’t have any 
immediate plans to do such given how rare it is nowadays.  If somebody really 
cares about that use case, we can discuss further.

Devin

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

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

[Nicolas George]

Carl Eugen Hoyos (2017-11-27):
> The patch that introduced the regression was not discussed and
> it used a guessed limit afair.

Two wrong don't make a right. You should not have pushed without
discussion.

> The patch that fixed ticket #373 simply doubled the value to fix
> a particular use-case.

Well, it was wrong too, I did not notice at the time.

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

I want you to refrain from pushing this kind of patch.

> Any better suggestions?

When the problem is that the value returned by
snd_pcm_hw_params_get_buffer_size_max() is too large and the cap set by
ALSA_BUFFER_SIZE_MAX is too small, the obvious fix is to involve
snd_pcm_hw_params_get_buffer_size_min().

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 2/2] decklink: Add support for output of Active Format Description (AFD)

[Devin Heitmueller]

Hi Marton,

Comments inline.

>> +data = av_packet_get_side_data(pkt, AV_PKT_DATA_AFD, &size);
>> +if (data) {
>> +struct klvanc_packet_afd_s *pkt;
>> +uint16_t *afd;
>> +uint16_t len;
>> +
>> +ret = klvanc_create_AFD(&pkt);
>> +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?

Bear in mind that the “aspectRatio” field in question isn’t what the video 
should ultimately be rendered in.  It’s just the aspect ratio of the source 
video.  For cases where you’re doing SD with 16x9, the source video itself is 
in 4x3 aspect ratio, but the expected result should be in 16x9.  The fact that 
the video should be rendered in 16x9 is controlled by the call to 
klvanc_set_AFD_val() further up in the function.  SAR/PAR, etc aren’t a 
consideration for what drives the aspectRatio field in AFD.

In short, this routine could probably be replaced with something that just 
divides pixelwidth/pixelheight and determines whether it’s equal to 1.77 or 
some smaller value.

I know it’s counter-intuitive to have a detailed aspect ratio description with 
something like 16 possible values, and then to also have a single bit which 
indicates whether the original source video is “16x9” or “4x3” when any 
downstream device can just look at the real pixel width/height of the video.  
Complain to the ATSC, I guess.  :-)

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

Re: [FFmpeg-devel] AMD external header

[Mironov, Mikhail]

> 
> Pavel Koshevoy (2017-11-27):
> > That is unnecessarily un-diplomatic and will likely offend the
> > contributors from nvidia and amd.
> 
> Well, I find offensive that they benefit from my work yet make extra efforts
> to make sure I cannot benefit from theirs. Maybe I should start putting my
> contributions under GPL and not LGPL, what do you think?
> 
> > 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.
> 
> I understand it is more convenient for you than what the vendors provide,
> but why should the effort of making things more convenient be carried by
> the FFmpeg developers?
> 
> It has a non-negligible cost: more testing required, git grep pollution, all 
> the
> while giving these companies an unfair advantage against the companies that
> play by the rules of Libre software and inciting them to continue in that
> direction.
> 
> I think the whole compat directory is misguided, but these headers for
> external libraries are the worse of it.
> 
> Regards,
> 
> --
>   Nicolas George

I wanted to stay out of license issues and this forum is oriented more towards 
technical discussion but I can't resist putting my two cents: Yes, HW 
manufactures
 live out of HW sell. And yes, integration with products like ffmpeg should 
benefit them (us).
But they(us) do not sell software. The enablement of HW acceleration adds 
features to ffmpeg project.  
And we do it ourselves. We also intend to contribute more. So it is mutually 
beneficial.  Isn't it?
Thanks,
Mikhail
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] vf_zscale: Add more supported input properties

[Vittorio Giovara]

Signed-off-by: Vittorio Giovara 
---
This version should be more complete.
Regarding configure changes, this library is not packaged by any distribution
that I could find, so users will just need to use zimg HEAD or any stable
snapshot (2.6.2).
Vittorio

 libavfilter/vf_zscale.c | 51 +
 1 file changed, 51 insertions(+)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 972f720ee6..865910bd87 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -353,16 +353,26 @@ static int convert_matrix(enum AVColorSpace colorspace)
 return ZIMG_MATRIX_709;
 case AVCOL_SPC_UNSPECIFIED:
 return ZIMG_MATRIX_UNSPECIFIED;
+case AVCOL_SPC_FCC:
+return ZIMG_MATRIX_FCC;
 case AVCOL_SPC_BT470BG:
 return ZIMG_MATRIX_470BG;
 case AVCOL_SPC_SMPTE170M:
 return ZIMG_MATRIX_170M;
+case AVCOL_SPC_SMPTE240M:
+return ZIMG_MATRIX_240M;
 case AVCOL_SPC_YCGCO:
 return ZIMG_MATRIX_YCGCO;
 case AVCOL_SPC_BT2020_NCL:
 return ZIMG_MATRIX_2020_NCL;
 case AVCOL_SPC_BT2020_CL:
 return ZIMG_MATRIX_2020_CL;
+case AVCOL_SPC_CHROMA_DERIVED_NCL:
+return ZIMG_MATRIX_CHROMATICITY_DERIVED_NCL;
+case AVCOL_SPC_CHROMA_DERIVED_CL:
+return ZIMG_MATRIX_CHROMATICITY_DERIVED_CL;
+case AVCOL_SPC_ICTCP:
+return ZIMG_MATRIX_ICTCP;
 }
 return ZIMG_MATRIX_UNSPECIFIED;
 }
@@ -374,10 +384,22 @@ static int convert_trc(enum AVColorTransferCharacteristic 
color_trc)
 return ZIMG_TRANSFER_UNSPECIFIED;
 case AVCOL_TRC_BT709:
 return ZIMG_TRANSFER_709;
+case AVCOL_TRC_GAMMA22:
+return ZIMG_TRANSFER_470_M;
+case AVCOL_TRC_GAMMA28:
+return ZIMG_TRANSFER_470_BG;
 case AVCOL_TRC_SMPTE170M:
 return ZIMG_TRANSFER_601;
+case AVCOL_TRC_SMPTE240M:
+return ZIMG_TRANSFER_240M;
 case AVCOL_TRC_LINEAR:
 return ZIMG_TRANSFER_LINEAR;
+case AVCOL_TRC_LOG:
+return ZIMG_TRANSFER_LOG_100;
+case AVCOL_TRC_LOG_SQRT:
+return ZIMG_TRANSFER_LOG_316;
+case AVCOL_TRC_IEC61966_2_4:
+return ZIMG_TRANSFER_IEC_61966_2_4;
 case AVCOL_TRC_BT2020_10:
 return ZIMG_TRANSFER_2020_10;
 case AVCOL_TRC_BT2020_12:
@@ -399,14 +421,26 @@ static int convert_primaries(enum AVColorPrimaries 
color_primaries)
 return ZIMG_PRIMARIES_UNSPECIFIED;
 case AVCOL_PRI_BT709:
 return ZIMG_PRIMARIES_709;
+case AVCOL_PRI_BT470M:
+return ZIMG_PRIMARIES_470_M;
+case AVCOL_PRI_BT470BG:
+return ZIMG_PRIMARIES_470_BG;
 case AVCOL_PRI_SMPTE170M:
 return ZIMG_PRIMARIES_170M;
 case AVCOL_PRI_SMPTE240M:
 return ZIMG_PRIMARIES_240M;
+case AVCOL_PRI_FILM:
+return ZIMG_PRIMARIES_FILM;
 case AVCOL_PRI_BT2020:
 return ZIMG_PRIMARIES_2020;
+case AVCOL_PRI_SMPTE428:
+return ZIMG_PRIMARIES_ST428;
+case AVCOL_PRI_SMPTE431:
+return ZIMG_PRIMARIES_ST431_2;
 case AVCOL_PRI_SMPTE432:
 return ZIMG_PRIMARIES_ST432_1;
+case AVCOL_PRI_JEDEC_P22:
+return ZIMG_PRIMARIES_EBU3213_E;
 }
 return ZIMG_PRIMARIES_UNSPECIFIED;
 }
@@ -745,10 +779,16 @@ static const AVOption zscale_options[] = {
 { "2020", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS, "primaries" },
 { "bt709",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS, "primaries" },
+{ "bt470m",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_M},   0, 0, FLAGS, "primaries" },
+{ "bt470bg",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_BG},  0, 0, FLAGS, "primaries" },
 { "smpte170m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS, "primaries" },
 { "smpte240m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS, "primaries" },
+{ "film", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_FILM},0, 0, FLAGS, "primaries" },
 { "bt2020",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
+{ "smpte428", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_ST428},   0, 0, FLAGS, "primaries" },
+{ "smpte431", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_ST431_2}, 0, 0, FLAGS, "primaries" },
 { "smpte432", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_ST432_1}, 0, 0

[FFmpeg-devel] [PATCH 1/2] vf_zscale: Relax color properties maximum bounds

[Vittorio Giovara]

This simplifies adding new values, which are already validated elsewhere.

Signed-off-by: Vittorio Giovara 
---
 libavfilter/vf_zscale.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 09fd842fe5..972f720ee6 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -735,8 +735,8 @@ static const AVOption zscale_options[] = {
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = -1}, 0, 0, FLAGS, "range" },
 { "tv",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_RANGE_LIMITED}, 0, 0, FLAGS, "range" },
 { "pc",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_RANGE_FULL},0, 0, FLAGS, "range" },
-{ "primaries", "set color primaries", OFFSET(primaries), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_PRIMARIES_ST432_1, FLAGS, "primaries" },
-{ "p", "set color primaries", OFFSET(primaries), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_PRIMARIES_ST432_1, FLAGS, "primaries" },
+{ "primaries", "set color primaries", OFFSET(primaries), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "primaries" },
+{ "p", "set color primaries", OFFSET(primaries), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "primaries" },
 { "input",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = -1}, 0, 0, FLAGS, "primaries" },
 { "709",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS, "primaries" },
 { "unspecified",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS, "primaries" },
@@ -749,8 +749,8 @@ static const AVOption zscale_options[] = {
 { "smpte240m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS, "primaries" },
 { "bt2020",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
 { "smpte432", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_ST432_1}, 0, 0, FLAGS, "primaries" },
-{ "transfer", "set transfer characteristic", OFFSET(trc), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_TRANSFER_ARIB_B67, FLAGS, "transfer" },
-{ "t","set transfer characteristic", OFFSET(trc), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_TRANSFER_ARIB_B67, FLAGS, "transfer" },
+{ "transfer", "set transfer characteristic", OFFSET(trc), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "transfer" },
+{ "t","set transfer characteristic", OFFSET(trc), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "transfer" },
 { "input",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = -1}, 0, 0, FLAGS, "transfer" },
 { "709",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_709}, 0, 0, FLAGS, "transfer" },
 { "unspecified",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
@@ -767,8 +767,8 @@ static const AVOption zscale_options[] = {
 { "smpte2084",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_ST2084},  0, 0, FLAGS, "transfer" },
 { "iec61966-2-1", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_IEC_61966_2_1},0, 0, FLAGS, "transfer" },
 { "arib-std-b67", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_ARIB_B67},0, 0, FLAGS, "transfer" },
-{ "matrix", "set colorspace matrix", OFFSET(colorspace), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
-{ "m",  "set colorspace matrix", OFFSET(colorspace), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
+{ "matrix", "set colorspace matrix", OFFSET(colorspace), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "matrix" },
+{ "m",  "set colorspace matrix", OFFSET(colorspace), AV_OPT_TYPE_INT, 
{.i64 = -1}, -1, INT_MAX, FLAGS, "matrix" },
 { "input",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = -1},  0, 0, FLAGS, "matrix" },
 { "709",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_MATRIX_709}, 0, 0, FLAGS, "matrix" },
 { "unspecified",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_MATRIX_UNSPECIFIED}, 0, 0, FLAGS, "matrix" },
@@ -786,12 +786,12 @@ static const AVOption zscale_options[] = {
 { "in_range", "set input color range", OFFSET(range_in),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
 { "rangein", "set input color range", OFFSET(range_in), 
AV_OPT_TYPE_INT, {.i64 = -1}, 

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

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 12:07:33AM +0100, Carl Eugen Hoyos wrote:
> 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

>  ffmpeg_opt.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> f2101d38b3539e2f560eb7eb9dab1c9f722a5549  
> 0001-ffmpeg_opt-Constify-hwaccel-pointer.patch
> 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

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
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

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 03:20:10PM -0500, 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];

rather minor suggestion but you could use:
 ((int[]){ 1, 2, 0 })[i];

as mapping is not used anywhere else

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

It is what and why we do it that matters, not just one of them.


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

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

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 08:41:10PM +0800, Pan Bian wrote:
> 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(-)

will apply

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH 2/2] vf_zscale: Add more supported input properties

[Paul B Mahol]

On 11/28/17, Vittorio Giovara  wrote:
> Signed-off-by: Vittorio Giovara 
> ---
> This version should be more complete.
> Regarding configure changes, this library is not packaged by any
> distribution
> that I could find, so users will just need to use zimg HEAD or any stable
> snapshot (2.6.2).
> Vittorio
>
>  libavfilter/vf_zscale.c | 51
> +
>  1 file changed, 51 insertions(+)
>

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

Re: [FFmpeg-devel] [PATCH 2/2] vf_zscale: Add more supported input properties

[James Almer]

On 11/28/2017 3:57 PM, Vittorio Giovara wrote:
> Signed-off-by: Vittorio Giovara 
> ---
> This version should be more complete.
> Regarding configure changes, this library is not packaged by any distribution
> that I could find, so users will just need to use zimg HEAD or any stable
> snapshot (2.6.2).

Then change the pkg_config check in configure from 2.3.0 to 2.6.2.
configure should not succeed if compilation is guaranteed to fail
afterwards.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avcodec/mlpenc: fix undefined shift

[Paul B Mahol]

Decreases artifacts.

Signed-off-by: Paul B Mahol 
---
 libavcodec/mlpenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index c588f5b904..eceb0ddbb2 100644
--- a/libavcodec/mlpenc.c
+++ b/libavcodec/mlpenc.c
@@ -466,7 +466,7 @@ static void default_decoding_params(MLPEncodeContext *ctx,
  */
 static int inline number_sbits(int number)
 {
-if (number < 0)
+if (number <= 0)
 number++;
 
 return av_log2(FFABS(number)) + 1 + !!number;
-- 
2.11.0

___
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

[Henrik Gramner]

On Mon, Nov 27, 2017 at 11:37 PM, James Almer  wrote:
> On 11/27/2017 7:33 PM, James Darnley wrote:
>> 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.

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

[FFmpeg-devel] [PATCH 1/2] avcodec/mlpenc: encode last frame too

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/mlpenc.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
index 7536d3b2f5..c588f5b904 100644
--- a/libavcodec/mlpenc.c
+++ b/libavcodec/mlpenc.c
@@ -2225,29 +2225,27 @@ static int mlp_encode_frame(AVCodecContext *avctx, 
AVPacket *avpkt,
 int restart_frame, ret;
 uint8_t *data;
 
-if ((ret = ff_alloc_packet2(avctx, avpkt, 87500 * avctx->channels, 0)) < 0)
-return ret;
-
-if (!frame)
-return 1;
-
 /* add current frame to queue */
 if (frame) {
 if ((ret = ff_af_queue_add(&ctx->afq, frame)) < 0)
 return ret;
+} else {
+if (ctx->last_frame == ctx->inout_buffer) {
+return 0;
+}
 }
 
-data = frame->data[0];
+
+if ((ret = ff_alloc_packet2(avctx, avpkt, 87500 * avctx->channels, 0)) < 0)
+return ret;
+
+data = frame ? frame->data[0] : NULL;
 
 ctx->frame_index = avctx->frame_number % ctx->max_restart_interval;
 
 ctx->inout_buffer = ctx->major_inout_buffer
   + ctx->frame_index * ctx->one_sample_buffer_size;
 
-if (ctx->last_frame == ctx->inout_buffer) {
-return 0;
-}
-
 ctx->sample_buffer = ctx->major_scratch_buffer
+ ctx->frame_index * ctx->one_sample_buffer_size;
 
@@ -2333,6 +2331,8 @@ input_and_return:
 number_of_samples += 
ctx->frame_size[(ctx->starting_frame_index + index) % 
ctx->max_restart_interval];
 }
 ctx->number_of_samples = number_of_samples;
+if (!ctx->number_of_samples)
+break;
 
 for (index = 0; index < ctx->seq_size[seq_index]; index++) {
 clear_channel_params(ctx, ctx->seq_channel_params + 
index*(ctx->avctx->channels));
-- 
2.11.0

___
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 Tue, 28 Nov 2017, Devin Heitmueller wrote:


Hello Marton,

Thanks for taking the time to review.  Most of the comments you’ve raised will 
be fixed and I’ll resubmit an updated patch.  Comments on other issues inline 
below.


   /* Options */
   int list_devices;
@@ -88,6 +93,7 @@ struct decklink_ctx {
   DecklinkPtsSource audio_pts_source;
   DecklinkPtsSource video_pts_source;
   int draw_bars;
+int raw_format;


Since this header includes decklink headers, this can be BMDPixelFormat instead 
of int, and you can use the decklink constants directly instead of MKBETAG.


I used MKBETAG because that was what was being used in decklink_dec.cpp (and I 
wanted to be consistent).  That said, I have no objection to changing it.


Ok, maybe better to change it.





For older decklink models (E.g. Decklink SDI, Decklink Duo 1), when you 
capture in 8 bit mode, you can only query 8bit VANC. For output, can 
you always use 10-bit VANC? Even if you use 8bit mode for video? 
Because if you can't, then it might make sense to return silently here, 
or only warn to user once, not for every frame (and maybe disable 
vanc_support?).


All decklink models require that VANC be in the same bit depth as video 
capture (i.e. with both older and newer models you cannot do 8-bit video 
with 10-bit VANC or vice-versa).  The only exception is the RGB formats 
which do VANC in 10-bit YUV.


SDK says:

When capturing ancillary data with a 4K DeckLink device, the ancillary
data will always be in the 10-bit YUV pixel format.

This also applies to 8 bit YUV captures according to my experience.

The decklink_construct_vanc() function is 
only ever called if the device is putting out 10-bit video, and thus 
your question about putting out 10-bit VANC when doing 8-bit video isn’t 
an issue since we never hit that code path.


Ah, OK. I missed that. You can keep the code as is then, somebody else 
interested can figure out if outputting 10 bit VANC works with 8 bit video 
or not.


Regards,
Marton
___
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

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 11:00:51AM +0100, Tomas Härdin wrote:
> 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.

will apply

thanks


> 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



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


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

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

[Devin Heitmueller]

Hello Marton,

> SDK says:
> 
> When capturing ancillary data with a 4K DeckLink device, the ancillary
> data will always be in the 10-bit YUV pixel format.
> 
> This also applies to 8 bit YUV captures according to my experience.
> 

Thanks for refreshing my memory.  I remember reading that text, but for some 
reason thought it was RGB formats, not 4K capture products.

That’s actually a really nice feature - if you’re not feeding a 10-bit encoder 
then it would avoid having to do 10-to-8bit colorspace conversion in software 
in order for VANC to be properly preserved.  In earlier products you either had 
to choose between 8-bit video but VANC wouldn’t be properly preserved, or you 
could do 10-bit video but then have to colorspace convert from V210 to an 8-bit 
format.

In the future I’ll have to look and see if that’s exposed through a decklink 
attribute (or do we have to hard-code the model info into the application to 
know which cards work this way).

Regards,

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

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/avfilter: simplify filter registration

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 04:30:19AM +, Rostislav Pehlivanov wrote:
> Atomics were entirely pointless and did nothing but slow and complicate
> the process down. This could be improved further still but the main
> objective of this commit is to simplify.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavfilter/avfilter.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

*_register() can be called by the user app in a unsyncronized way
for example from a module like vlc used AFAIK.
or from libs loaded by an application which use libavfilter or other
internally.

These registration functions should stay thread safe


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH]lavf/mov: Do not blindly allocate stts entries

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 05:24:14AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch avoids allocations >1GB for (short and) invalid mov
> files with only reasonable speed impact.
> 
> Please review, Carl Eugen

>  mov.c |   16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 980861e4c47c80c850d4e849043df2510a3d1d32  
> 0001-lavf-mov-Do-not-blindly-allocate-huge-memory-blocks-.patch
> From 0d243bad5fdd9850ff41d49a32a06274a3cd9756 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 27 Nov 2017 05:13:25 +0100
> Subject: [PATCH] lavf/mov: Do not blindly allocate huge memory blocks for
>  stts entries.
> 
> Fixes large allocations for short files with invalid stts entry.
> Fixes bugzilla 1102.
> ---
>  libavformat/mov.c |   16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ddb1e59..9d353bf 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2838,14 +2838,24 @@ static int mov_read_stts(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
>  if (sc->stts_data)
>  av_log(c->fc, AV_LOG_WARNING, "Duplicated STTS atom\n");
>  av_free(sc->stts_data);
> -sc->stts_count = 0;
> -sc->stts_data = av_malloc_array(entries, sizeof(*sc->stts_data));
> +sc->stts_count = FFMIN(1024 * 1024, entries);
> +sc->stts_data = av_realloc_array(NULL, sc->stts_count, 
> sizeof(*sc->stts_data));
>  if (!sc->stts_data)
>  return AVERROR(ENOMEM);

i dont know if leaving stts_count random on return is a good idea


>  
>  for (i = 0; i < entries && !pb->eof_reached; i++) {
> -int sample_duration;
> +int sample_duration, ret;
>  unsigned int sample_count;
> +if (i > sc->stts_count) {
> +ret = av_reallocp_array(&sc->stts_data,
> +FFMIN(sc->stts_count * 2LL, entries),
> +sizeof(*sc->stts_data));

this should use a variat of
av_fast_realloc


[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/avfilter: simplify filter registration

[Paul B Mahol]

On 11/28/17, Michael Niedermayer  wrote:
> On Mon, Nov 27, 2017 at 04:30:19AM +, Rostislav Pehlivanov wrote:
>> Atomics were entirely pointless and did nothing but slow and complicate
>> the process down. This could be improved further still but the main
>> objective of this commit is to simplify.
>>
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  libavfilter/avfilter.c | 8 +---
>>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> *_register() can be called by the user app in a unsyncronized way
> for example from a module like vlc used AFAIK.
> or from libs loaded by an application which use libavfilter or other
> internally.
>
> These registration functions should stay thread safe

I don't see why, your description is weak at best.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-devel 2/2] avformat/mov: return correct value in mov_read_cmov

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 11:13:05AM +0800, Pan Bian wrote:
> On some failure paths, the error code is not correctly set.
> 
> Signed-off-by: Pan Bian 
> ---
>  libavformat/mov.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

thanks

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [FFmpeg-devel 1/2] avformat/mov: set correct error code in mov_read_custom

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 11:12:56AM +0800, Pan Bian wrote:
> In function mov_read_custom(), it returns 0 on the path that av_malloc()
> returns a NULL pointer. 0 indicates success. An error code should be
> assigned to ret.
> 
> Signed-off-by: Pan Bian 
> ---
>  libavformat/mov.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

will apply

thanks

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH] avfilter/drawbox: rename variable for maximum thickness

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 10:10:08AM +0530, Gyan Doshi wrote:
> 
> On 11/23/2017 7:12 PM, Gyan Doshi wrote:
> >
> >On 11/20/2017 3:59 PM, Gyan Doshi wrote:
> >>At present, the value name 'max' for maximum thickness in
> >>drawbox (and drawgrid) filter leads to a parse error if the
> >>thickness expression contains 'max(val1,val2)' i.e.
> >>
> >> [Eval @ ...] Invalid chars '(20,30)' at the end of
> >>expression 'max(20,30)'
> >>
> >>Renamed to 'fill'; tested & documented.
> 
> Ping. x2

will apply

thanks

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

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

[Michael Niedermayer]

On Mon, Nov 27, 2017 at 06:43:32PM -0800, Steven Robertson wrote:
> It's... less wrong.
> 
> The VC-3 DNxHR update added a 'clv' field to an existing byte in the frame
> header to allow for the carriage of a limited set of color info (0 =
> 709/709, 1=2020/2020NCL, 2=2020/2020CL, 3=container specifies), but because
> that field is new-ish and assigns a meaning other than 'unspecified' to 0,
> we see files that have correct colorimetry in a 'colr' atom or equivalent
> (e.g. 2020/2020NCL with PQ transfer curve) but which do not set the 'clv'
> value, so it defaults to 0. For these media, the most correct choice is to
> trust the container over the file. Because DNxHD/DNxHR is getting more
> popular for delivering HDR, HDR requires setting a transfer function, and
> 'clv' doesn't have a way to specify the transfer function, DNxHR for HDR
> always needs to rely on the container for metadata, and this at least gets
> the issue out of the way for those cases without changing existing behavior
> for containers that don't specify a color system.
> 
> Additionally, because it's set in the frame header, we'd have to probe a
> frame and guard against frame changes or even reconfigure things after a
> frame change, and since I'm not an experienced ffmpeg dev I opted for the
> minimal fix to make 2020NCL for HDR files work properly.

Something like this should be in the commit message

thx

> 
> 
> On Mon, Nov 27, 2017 at 4:35 PM, Michael Niedermayer  > wrote:
> 
> > 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
> >
> > ___
> > 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

-- 
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] [ogg] Respect AVERROR codes returned by ogg header parsing.

[Dale Curtis]

Fixes ticket #6804. All of the ogg header parsers may return
standard AVERROR codes; these return values should not be
treated as success.

Signed-off-by: Dale Curtis 
From 34d68a511a2d933b111964f84cfd2d0a289dec97 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 28 Nov 2017 13:40:20 -0800
Subject: [PATCH] Respect AVERROR codes returned by ogg header parsing.

Fixes ticket #6804. All of the ogg header parsers may return
standard AVERROR codes; these return values should not be
treated as success.

Signed-off-by: Dale Curtis 
---
 libavformat/oggdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 193a286e43..4ab7fdc0bd 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -544,6 +544,9 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
 
 if (os->header) {
 os->header = os->codec->header(s, idx);
+if (os->header < 0)
+return os->header;
+
 if (!os->header) {
 os->segp  = segp;
 os->psize = psize;
-- 
2.15.0.417.g466bffb3ac-goog

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

[FFmpeg-devel] [ogg] Free opus extradata before reallocating.

[Dale Curtis]

Otherwise ff_alloc_extradata() just leaks any existing allocated
memory. Similar to the patch for ogm extradata leaks.

Signed-off-by: Dale Curtis 
From ac7f2deaa48ac0578be19b178b7c0bc8040bc278 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 28 Nov 2017 13:44:49 -0800
Subject: [PATCH] [ogg] Free opus extradata before reallocating.

Otherwise ff_alloc_extradata() just leaks any existing allocated
memory.

Signed-off-by: Dale Curtis 
---
 libavformat/oggparseopus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/oggparseopus.c b/libavformat/oggparseopus.c
index f45ad84874..cd34cf23ba 100644
--- a/libavformat/oggparseopus.c
+++ b/libavformat/oggparseopus.c
@@ -62,6 +62,7 @@ static int opus_header(AVFormatContext *avf, int idx)
 /*gain= AV_RL16(packet + 16);*/
 /*channel_map = AV_RL8 (packet + 18);*/
 
+av_freep(&st->codecpar->extradata);
 if (ff_alloc_extradata(st->codecpar, os->psize))
 return AVERROR(ENOMEM);
 
-- 
2.15.0.417.g466bffb3ac-goog

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

Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.

[Dale Curtis]

Actually packet() was broken too, updated the patch to fix this case too.

- dale

On Tue, Nov 28, 2017 at 1:41 PM, Dale Curtis 
wrote:

> Fixes ticket #6804. All of the ogg header parsers may return
> standard AVERROR codes; these return values should not be
> treated as success.
>
> Signed-off-by: Dale Curtis 
>
>
>
From 986e24ed45c5eb222eb87f2aa6ca703a371a267a Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 28 Nov 2017 13:40:20 -0800
Subject: [PATCH] Respect AVERROR codes returned by ogg parsers.

Fixes ticket #6804. All of the ogg header and packet parsers may
return standard AVERROR codes; these return values should not be
treated as success.

Signed-off-by: Dale Curtis 
---
 libavformat/oggdec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 193a286e43..b1f318bfb2 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -543,7 +543,9 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
 os->incomplete = 0;
 
 if (os->header) {
-os->header = os->codec->header(s, idx);
+if (ret = os->codec->header(s, idx) < 0)
+return ret;
+os->header = ret;
 if (!os->header) {
 os->segp  = segp;
 os->psize = psize;
@@ -574,8 +576,10 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
 } else {
 os->pflags= 0;
 os->pduration = 0;
-if (os->codec && os->codec->packet)
-os->codec->packet(s, idx);
+if (os->codec && os->codec->packet) {
+if (ret = os->codec->packet(s, idx) < 0)
+return ret;
+}
 if (sid)
 *sid = idx;
 if (dstart)
-- 
2.15.0.417.g466bffb3ac-goog

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

Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.

[Dale Curtis]

Fixes bad parens in the above patch.

- dale

On Tue, Nov 28, 2017 at 2:03 PM, Dale Curtis 
wrote:

> Actually packet() was broken too, updated the patch to fix this case too.
>
> - dale
>
> On Tue, Nov 28, 2017 at 1:41 PM, Dale Curtis 
> wrote:
>
>> Fixes ticket #6804. All of the ogg header parsers may return
>> standard AVERROR codes; these return values should not be
>> treated as success.
>>
>> Signed-off-by: Dale Curtis 
>>
>>
>>
>
From 8d3b21ab59d835430f057cfb40a63318b25e7014 Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 28 Nov 2017 13:40:20 -0800
Subject: [PATCH] Respect AVERROR codes returned by ogg parsers.

Fixes ticket #6804. All of the ogg header and packet parsers may
return standard AVERROR codes; these return values should not be
treated as success.

Signed-off-by: Dale Curtis 
---
 libavformat/oggdec.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
index 193a286e43..281eba44cf 100644
--- a/libavformat/oggdec.c
+++ b/libavformat/oggdec.c
@@ -543,7 +543,9 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
 os->incomplete = 0;
 
 if (os->header) {
-os->header = os->codec->header(s, idx);
+if ((ret = os->codec->header(s, idx)) < 0)
+return ret;
+os->header = ret;
 if (!os->header) {
 os->segp  = segp;
 os->psize = psize;
@@ -574,8 +576,10 @@ static int ogg_packet(AVFormatContext *s, int *sid, int *dstart, int *dsize,
 } else {
 os->pflags= 0;
 os->pduration = 0;
-if (os->codec && os->codec->packet)
-os->codec->packet(s, idx);
+if (os->codec && os->codec->packet) {
+if ((ret = os->codec->packet(s, idx)) < 0)
+return ret;
+}
 if (sid)
 *sid = idx;
 if (dstart)
-- 
2.15.0.417.g466bffb3ac-goog

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

[Mark Thompson]

On 20/11/17 01:38, Jun Zhao wrote:
> V3: Use av_hwframe_transfer_date load YUV to HW surface
> 
> From c0edef97f4f123e74e62396b45db01236ae6477d Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Mon, 6 Nov 2017 14:45:27 +0800
> Subject: [PATCH V3] examples/vaapi_encode: Add a VA-API encode example.
> 
> add a VA-API encode example, only support NV12 input, usage like:
> ./vaapi_encode 1920 1080 test.yuv test.h264
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Liu, Kaixuan 
> ---
>  configure   |   2 +
>  doc/examples/Makefile   |   1 +
>  doc/examples/vaapi_encode.c | 225 
> 
>  3 files changed, 228 insertions(+)
>  create mode 100644 doc/examples/vaapi_encode.c
> 
> diff --git a/configure b/configure
> index 8262358138..ea029750c7 100755
> --- a/configure
> +++ b/configure
> @@ -1521,6 +1521,7 @@ EXAMPLE_LIST="
>  scaling_video_example
>  transcode_aac_example
>  transcoding_example
> +vaapi_encode_example
>  "
>  
>  EXTERNAL_AUTODETECT_LIBRARY_LIST="
> @@ -3308,6 +3309,7 @@ resampling_audio_example_deps="avutil swresample"
>  scaling_video_example_deps="avutil swscale"
>  transcode_aac_example_deps="avcodec avformat swresample"
>  transcoding_example_deps="avfilter avcodec avformat avutil"
> +vaapi_encode_example_deps="avfilter avcodec avformat avutil"

LGTM.  I removed the unused dependency on avfilter/avformat (only needs 
avcodec/avutil now), and applied.

Thanks,

- Mark
___
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 28/11/17 02:23, Mironov, Mikhail wrote:
> 
> 
>> 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.
> 
> OK.
> 
>> Relatedly: your name on patches does not match your full name - I've 
>> preserved the patch one here, but was that intended?
> 
> No, it was how I configured global  git user name on dev machine for several 
> other projects and did not change it for ffmpeg.
> If you can put the full one: Mikhail Mironov. I will adjust in the future.

Changed, and pushed.

Thank you!

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

Re: [FFmpeg-devel] [PATCH] vaapi_h265: general_level_idc should times 3.

[Mark Thompson]

On 28/11/17 07:46, Ruiling Song wrote:
> Signed-off-by: Ruiling Song 
> ---
>  libavcodec/vaapi_encode_h265.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 3ae92a7..32b8bc6 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -219,7 +219,7 @@ static int 
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>  .general_non_packed_constraint_flag = 1,
>  .general_frame_only_constraint_flag = 1,
>  
> -.general_level_idc = avctx->level,
> +.general_level_idc = avctx->level * 3,
>  };
>  
> vps->profile_tier_level.general_profile_compatibility_flag[avctx->profile & 
> 31] = 1;
>  
> 
The documentation has always said "profile and level set the values of 
general_profile_idc and general_level_idc respectively" 
() - the code disagreed 
for a while, but that was made consistent in 
00179664bccd1dd6fa0d1c40db453528757bf6f7.

Why do you want to change it to be general_level_idc / 3 instead?

Thanks,

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

[FFmpeg-devel] [oggvp8] Don't manipulate duration when it's AV_NOPTS_VALUE.

[Dale Curtis]

This leads to signed integer overflow.

Signed-off-by: Dale Curtis 
From c1fa869b79aeb314f30746a561903fcfa8f305fb Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Tue, 28 Nov 2017 14:26:55 -0800
Subject: [PATCH] [oggvp8] Don't manipulate duration when it's AV_NOPTS_VALUE.

This leads to signed integer overflow.

Signed-off-by: Dale Curtis 
---
 libavformat/oggparsevp8.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/oggparsevp8.c b/libavformat/oggparsevp8.c
index c534ab117d..b76ac71cc5 100644
--- a/libavformat/oggparsevp8.c
+++ b/libavformat/oggparsevp8.c
@@ -125,7 +125,7 @@ static int vp8_packet(AVFormatContext *s, int idx)
 os->lastdts = vp8_gptopts(s, idx, os->granule, NULL) - duration;
 if(s->streams[idx]->start_time == AV_NOPTS_VALUE) {
 s->streams[idx]->start_time = os->lastpts;
-if (s->streams[idx]->duration)
+if (s->streams[idx]->duration && s->streams[idx]->duration != AV_NOPTS_VALUE)
 s->streams[idx]->duration -= s->streams[idx]->start_time;
 }
 }
-- 
2.15.0.417.g466bffb3ac-goog

___
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 Tue, 2017-11-28 at 21:09 +0100, Michael Niedermayer wrote:
> On Mon, Nov 27, 2017 at 11:00:51AM +0100, Tomas Härdin wrote:
> > 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.
> 
> will apply
> 
> thanks

It sounded like he's working on an alternate patchset, see the PATCH
3/4 thread

/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] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change.

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 01:20:59PM +0800, Jun Zhao wrote:
> 

>  vp8.c |   46 ++
>  1 file changed, 34 insertions(+), 12 deletions(-)
> d548af3b82a9d77f67fe9621fc7aeee0392fcc89  
> 0001-lavc-vp8-Fix-HWAccel-VP8-decoder-can-t-support-resol.patch
> 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(-)

Causes fate-webp-rgba-lossy-q80 to segfault

Program received signal SIGSEGV, Segmentation fault.
0x00ceee65 in vp8_lossy_decode_alpha (avctx=0x21c7da0, p=0x21c8980, 
data_start=0x21caa67 "\027 
\020HR\331\037r\215\210\b\a\261`r\a8\177\235\020\"\372\037\064\001VP8 R", 
data_size=25) at libavcodec/webp.c:1312
1312*pp = *ap;
(gdb) bt
Python Exception  No module named gdb.frames:
#0  0x00ceee65 in vp8_lossy_decode_alpha (avctx=0x21c7da0, p=0x21c8980, 
data_start=0x21caa67 "\027 
\020HR\331\037r\215\210\b\a\261`r\a8\177\235\020\"\372\037\064\001VP8 R", 
data_size=25) at libavcodec/webp.c:1312
#1  0x00cef050 in vp8_lossy_decode_frame (avctx=0x21c7da0, p=0x21c8980, 
got_frame=0x7fffd648, data_start=0x21caa88 "\320\001", data_size=82) at 
libavcodec/webp.c:1362
#2  0x00cef357 in webp_decode_frame (avctx=0x21c7da0, data=0x21c8980, 
got_frame=0x7fffd648, avpkt=0x21c8ca0) at libavcodec/webp.c:1421
#3  0x00875781 in decode_simple_internal (avctx=0x21c7da0, 
frame=0x21c8980) at libavcodec/decode.c:398
#4  0x00876408 in decode_simple_receive_frame (avctx=0x21c7da0, 
frame=0x21c8980) at libavcodec/decode.c:594
#5  0x008764d3 in decode_receive_frame_internal (avctx=0x21c7da0, 
frame=0x21c8980) at libavcodec/decode.c:612
#6  0x0087674b in avcodec_send_packet (avctx=0x21c7da0, 
avpkt=0x7fffd7f0) at libavcodec/decode.c:674
#7  0x007be3e1 in try_decode_frame (s=0x21c6420, st=0x21c7480, 
avpkt=0x7fffd9a0, options=0x21c6e20) at libavformat/utils.c:3007
#8  0x007c174a in avformat_find_stream_info (ic=0x21c6420, 
options=0x21c6e20) at libavformat/utils.c:3832
#9  0x004154a5 in open_input_file (o=0x7fffdcf0, 
filename=0x7fffe688 
"/home/michael/fatesamples/fate/fate-suite//webp/rgba_q80.webp") at 
fftools/ffmpeg_opt.c:1091
#10 0x0041f061 in open_files (l=0x21c5d78, inout=0x11fa077 "input", 
open_file=0x4149d3 ) at fftools/ffmpeg_opt.c:3296
#11 0x0041f1f3 in ffmpeg_parse_options (argc=17, argv=0x7fffe308) 
at fftools/ffmpeg_opt.c:3336
#12 0x0043d5d2 in main (argc=17, argv=0x7fffe308) at 
fftools/ffmpeg.c:4837

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


signature.asc
Description: Digital signature
___
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 27, 2017 at 10:55 AM, James Zern  wrote:
> 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.

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

Re: [FFmpeg-devel] [ogg] Respect AVERROR codes returned by ogg header parsing.

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 02:17:21PM -0800, Dale Curtis wrote:
> Fixes bad parens in the above patch.
> 
> - dale
> 
> On Tue, Nov 28, 2017 at 2:03 PM, Dale Curtis 
> wrote:
> 
> > Actually packet() was broken too, updated the patch to fix this case too.
> >
> > - dale
> >
> > On Tue, Nov 28, 2017 at 1:41 PM, Dale Curtis 
> > wrote:
> >
> >> Fixes ticket #6804. All of the ogg header parsers may return
> >> standard AVERROR codes; these return values should not be
> >> treated as success.
> >>
> >> Signed-off-by: Dale Curtis 
> >>
> >>
> >>
> >

>  oggdec.c |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 07e15d08be7fcce839206cdd699eea804b1520ff  fix_ogg_v3.patch
> From 8d3b21ab59d835430f057cfb40a63318b25e7014 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Tue, 28 Nov 2017 13:40:20 -0800
> Subject: [PATCH] Respect AVERROR codes returned by ogg parsers.
> 
> Fixes ticket #6804. All of the ogg header and packet parsers may
> return standard AVERROR codes; these return values should not be
> treated as success.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/oggdec.c | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)

This breaks converting of this:
./ffmpeg -i bgc.sub.dub.ogm -vf subtitles=bgc.sub.dub.ogm -an  file.avi

https://samples.ffmpeg.org/ogg/bgc.sub.dub.ogm

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

[FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Mark Thompson]

This removes all remaining device-type specificity.
---
 doc/examples/hw_decode.c | 55 
 1 file changed, 23 insertions(+), 32 deletions(-)

diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
index 9c7adbf51a..8f48f3b706 100644
--- a/doc/examples/hw_decode.c
+++ b/doc/examples/hw_decode.c
@@ -44,34 +44,6 @@ static AVBufferRef *hw_device_ctx = NULL;
 static enum AVPixelFormat hw_pix_fmt;
 static FILE *output_file = NULL;
 
-static enum AVPixelFormat find_fmt_by_hw_type(const enum AVHWDeviceType type)
-{
-enum AVPixelFormat fmt;
-
-switch (type) {
-case AV_HWDEVICE_TYPE_VAAPI:
-fmt = AV_PIX_FMT_VAAPI;
-break;
-case AV_HWDEVICE_TYPE_DXVA2:
-fmt = AV_PIX_FMT_DXVA2_VLD;
-break;
-case AV_HWDEVICE_TYPE_D3D11VA:
-fmt = AV_PIX_FMT_D3D11;
-break;
-case AV_HWDEVICE_TYPE_VDPAU:
-fmt = AV_PIX_FMT_VDPAU;
-break;
-case AV_HWDEVICE_TYPE_VIDEOTOOLBOX:
-fmt = AV_PIX_FMT_VIDEOTOOLBOX;
-break;
-default:
-fmt = AV_PIX_FMT_NONE;
-break;
-}
-
-return fmt;
-}
-
 static int hw_decoder_init(AVCodecContext *ctx, const enum AVHWDeviceType type)
 {
 int err = 0;
@@ -184,18 +156,23 @@ int main(int argc, char *argv[])
 AVCodec *decoder = NULL;
 AVPacket packet;
 enum AVHWDeviceType type;
+int i;
 
 if (argc < 4) {
-fprintf(stderr, "Usage: %s   
\n", argv[0]);
+fprintf(stderr, "Usage: %s   \n", argv[0]);
 return -1;
 }
 
 av_register_all();
 
 type = av_hwdevice_find_type_by_name(argv[1]);
-hw_pix_fmt = find_fmt_by_hw_type(type);
-if (hw_pix_fmt == -1) {
-fprintf(stderr, "Cannot support '%s' in this example.\n", argv[1]);
+if (type == AV_HWDEVICE_TYPE_NONE) {
+fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
+fprintf(stderr, "Available device types:");
+type = AV_HWDEVICE_TYPE_NONE;
+while((type = av_hwdevice_iterate_types(type)) != 
AV_HWDEVICE_TYPE_NONE)
+fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
+fprintf(stderr, "\n");
 return -1;
 }
 
@@ -218,6 +195,20 @@ int main(int argc, char *argv[])
 }
 video_stream = ret;
 
+for (i = 0;; i++) {
+const AVCodecHWConfig *config = avcodec_get_hw_config(decoder, i);
+if (!config) {
+fprintf(stderr, "Decoder %s does not support device type %s.\n",
+decoder->name, av_hwdevice_get_type_name(type));
+return -1;
+}
+if (config->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX &&
+config->device_type == type) {
+hw_pix_fmt = config->pix_fmt;
+break;
+}
+}
+
 if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
 return AVERROR(ENOMEM);
 
-- 
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] examples/hw_decode: Use hw-config information to find pixfmt

[Jun Zhao]

On 2017/11/29 8:34, Mark Thompson wrote:
> This removes all remaining device-type specificity.
> ---
>  doc/examples/hw_decode.c | 55 
> 
>  1 file changed, 23 insertions(+), 32 deletions(-)
>
> diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
> index 9c7adbf51a..8f48f3b706 100644
> --- a/doc/examples/hw_decode.c
> +++ b/doc/examples/hw_decode.c
> @@ -44,34 +44,6 @@ static AVBufferRef *hw_device_ctx = NULL;
>  static enum AVPixelFormat hw_pix_fmt;
>  static FILE *output_file = NULL;
>  
> -static enum AVPixelFormat find_fmt_by_hw_type(const enum AVHWDeviceType type)
> -{
> -enum AVPixelFormat fmt;
> -
> -switch (type) {
> -case AV_HWDEVICE_TYPE_VAAPI:
> -fmt = AV_PIX_FMT_VAAPI;
> -break;
> -case AV_HWDEVICE_TYPE_DXVA2:
> -fmt = AV_PIX_FMT_DXVA2_VLD;
> -break;
> -case AV_HWDEVICE_TYPE_D3D11VA:
> -fmt = AV_PIX_FMT_D3D11;
> -break;
> -case AV_HWDEVICE_TYPE_VDPAU:
> -fmt = AV_PIX_FMT_VDPAU;
> -break;
> -case AV_HWDEVICE_TYPE_VIDEOTOOLBOX:
> -fmt = AV_PIX_FMT_VIDEOTOOLBOX;
> -break;
> -default:
> -fmt = AV_PIX_FMT_NONE;
> -break;
> -}
> -
> -return fmt;
> -}
> -
>  static int hw_decoder_init(AVCodecContext *ctx, const enum AVHWDeviceType 
> type)
>  {
>  int err = 0;
> @@ -184,18 +156,23 @@ int main(int argc, char *argv[])
>  AVCodec *decoder = NULL;
>  AVPacket packet;
>  enum AVHWDeviceType type;
> +int i;
>  
>  if (argc < 4) {
> -fprintf(stderr, "Usage: %s   
> \n", argv[0]);
> +fprintf(stderr, "Usage: %sfile>\n", argv[0]);
>  return -1;
>  }
>  
>  av_register_all();
>  
>  type = av_hwdevice_find_type_by_name(argv[1]);
> -hw_pix_fmt = find_fmt_by_hw_type(type);
> -if (hw_pix_fmt == -1) {
> -fprintf(stderr, "Cannot support '%s' in this example.\n", argv[1]);
> +if (type == AV_HWDEVICE_TYPE_NONE) {
> +fprintf(stderr, "Device type %s is not supported.\n", argv[1]);
> +fprintf(stderr, "Available device types:");
> +type = AV_HWDEVICE_TYPE_NONE;
> +while((type = av_hwdevice_iterate_types(type)) != 
> AV_HWDEVICE_TYPE_NONE)
> +fprintf(stderr, " %s", av_hwdevice_get_type_name(type));
> +fprintf(stderr, "\n");
>  return -1;
>  }
>  
> @@ -218,6 +195,20 @@ int main(int argc, char *argv[])
>  }
>  video_stream = ret;
>  
> +for (i = 0;; i++) {
> +const AVCodecHWConfig *config = avcodec_get_hw_config(decoder, i);
> +if (!config) {
> +fprintf(stderr, "Decoder %s does not support device type %s.\n",
> +decoder->name, av_hwdevice_get_type_name(type));
> +return -1;
> +}
> +if (config->methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX &&
> +config->device_type == type) {
> +hw_pix_fmt = config->pix_fmt;
> +break;
> +}
> +}
> +
>  if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
>  return AVERROR(ENOMEM);
>  
LGTM and tesed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

On 2017/11/29 7:09, Michael Niedermayer wrote:
> On Tue, Nov 28, 2017 at 01:20:59PM +0800, Jun Zhao wrote:
>>  vp8.c |   46 ++
>>  1 file changed, 34 insertions(+), 12 deletions(-)
>> d548af3b82a9d77f67fe9621fc7aeee0392fcc89  
>> 0001-lavc-vp8-Fix-HWAccel-VP8-decoder-can-t-support-resol.patch
>> 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(-)
> Causes fate-webp-rgba-lossy-q80 to segfault
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00ceee65 in vp8_lossy_decode_alpha (avctx=0x21c7da0, p=0x21c8980, 
> data_start=0x21caa67 "\027 
> \020HR\331\037r\215\210\b\a\261`r\a8\177\235\020\"\372\037\064\001VP8 R", 
> data_size=25) at libavcodec/webp.c:1312
> 1312*pp = *ap;
> (gdb) bt
> Python Exception  No module named gdb.frames:
> #0  0x00ceee65 in vp8_lossy_decode_alpha (avctx=0x21c7da0, 
> p=0x21c8980, data_start=0x21caa67 "\027 
> \020HR\331\037r\215\210\b\a\261`r\a8\177\235\020\"\372\037\064\001VP8 R", 
> data_size=25) at libavcodec/webp.c:1312
> #1  0x00cef050 in vp8_lossy_decode_frame (avctx=0x21c7da0, 
> p=0x21c8980, got_frame=0x7fffd648, data_start=0x21caa88 "\320\001", 
> data_size=82) at libavcodec/webp.c:1362
> #2  0x00cef357 in webp_decode_frame (avctx=0x21c7da0, data=0x21c8980, 
> got_frame=0x7fffd648, avpkt=0x21c8ca0) at libavcodec/webp.c:1421
> #3  0x00875781 in decode_simple_internal (avctx=0x21c7da0, 
> frame=0x21c8980) at libavcodec/decode.c:398
> #4  0x00876408 in decode_simple_receive_frame (avctx=0x21c7da0, 
> frame=0x21c8980) at libavcodec/decode.c:594
> #5  0x008764d3 in decode_receive_frame_internal (avctx=0x21c7da0, 
> frame=0x21c8980) at libavcodec/decode.c:612
> #6  0x0087674b in avcodec_send_packet (avctx=0x21c7da0, 
> avpkt=0x7fffd7f0) at libavcodec/decode.c:674
> #7  0x007be3e1 in try_decode_frame (s=0x21c6420, st=0x21c7480, 
> avpkt=0x7fffd9a0, options=0x21c6e20) at libavformat/utils.c:3007
> #8  0x007c174a in avformat_find_stream_info (ic=0x21c6420, 
> options=0x21c6e20) at libavformat/utils.c:3832
> #9  0x004154a5 in open_input_file (o=0x7fffdcf0, 
> filename=0x7fffe688 
> "/home/michael/fatesamples/fate/fate-suite//webp/rgba_q80.webp") at 
> fftools/ffmpeg_opt.c:1091
> #10 0x0041f061 in open_files (l=0x21c5d78, inout=0x11fa077 "input", 
> open_file=0x4149d3 ) at fftools/ffmpeg_opt.c:3296
> #11 0x0041f1f3 in ffmpeg_parse_options (argc=17, argv=0x7fffe308) 
> at fftools/ffmpeg_opt.c:3336
> #12 0x0043d5d2 in main (argc=17, argv=0x7fffe308) at 
> fftools/ffmpeg.c:4837
>
> [...]
Will check the segmentation fault, Tks.
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

[Steven Robertson]

The existing logic overrides container metadata even in cases where the
container metadata must be trusted (e.g. HDR). The original spec had no
provision for specifying color volume, so many files rely on the
assumption of Rec. 709.

An update to the spec included a 'clv' field for explicitly signaling
that the container should be trusted in an existing bitfield in the
frame header, but the default of 0 from old encoders forces Rec. 709,
which would break any HDR stream. Because there is no place in DNxHR for
specifying a transfer function, DNxHR HDR files must include
container-level color information.

This patch maintains the existing behavior of choosing the 709 over the
601 matrix when container-level information is missing, and allows
container-level information to win if present.

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

[FFmpeg-devel] [PATCH] swscale/utils: Remove bpc==8 gating init_range_convert

[Neil Birkbeck]

On higher bit depth YUV inputs with range metadata signaled as PC/full levels,
this change makes the results of scaling without explicitly
setting the input range on vf_scale as if it were explicitly set.

For example, the results with implicit color settings from the frame:
-vf scale=-1:-1:out_range=mpeg,format=yuv420p

Are the same as the correct result when set explicitly in the scaler:
-vf scale=-1:-1:in_range=jpeg:out_range=mpeg,format=yuv420p

The results are consistent with a similar yuv420p(pc) test input
(e.g., implicit and explicit setting of in_range on vf_scale both work).

Fate passes without the checks (or with a more specific check for >= 8).
If this seems sane, I'll write some tests.

I tried to reproduce the old results from before and after the commit
that I think the previous comment was referring to
4959a4fcf76e7c595dbb23c4e3bf59abf2e60ea4
but failed to repro (I may be testing the wrong thing). Using the samples
from (https://trac.ffmpeg.org/ticket/2939), without the check:
ffmpeg -i /tmp/progressive.jpg -vf format=rgb24 /tmp/progressive.png
is still treated as full range input (treating it as studio causes clipping
in the rgb).

There are still some other edge cases where range conversion doesn't work
unless explicitly set (e.g., when no scale is happening)

Signed-off-by: Neil Birkbeck 
---
 libswscale/utils.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libswscale/utils.c b/libswscale/utils.c
index 4df09306d3..f900e3bdef 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -883,9 +883,7 @@ int sws_setColorspaceDetails(struct SwsContext *c, const 
int inv_table[4],
 c->srcRange   = srcRange;
 c->dstRange   = dstRange;
 
-//The srcBpc check is possibly wrong but we seem to lack a definitive 
reference to test this
-//and what we have in ticket 2939 looks better with this check
-if (need_reinit && (c->srcBpc == 8 || !isYUV(c->srcFormat)))
+if (need_reinit)
 ff_sws_init_range_convert(c);
 
 c->dstFormatBpp = av_get_bits_per_pixel(desc_dst);
-- 
2.15.0.417.g466bffb3ac-goog

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

[FFmpeg-devel] [PATCH 1/5] avformat/avc: return an error in ff_isom_write_avcc if the buffer lenght is too small

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/avc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index 094a95821f..7b32590778 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -105,7 +105,9 @@ int ff_avc_parse_nal_units_buf(const uint8_t *buf_in, 
uint8_t **buf, int *size)
 
 int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
 {
-if (len > 6) {
+if (len < 6)
+return AVERROR_INVALIDDATA;
+
 /* check for H.264 start code */
 if (AV_RB32(data) == 0x0001 ||
 AV_RB24(data) == 0x01) {
@@ -157,7 +159,6 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 } else {
 avio_write(pb, data, len);
 }
-}
 return 0;
 }
 
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 2/5] avformat/avc: refactor ff_isom_write_avcc

[James Almer]

This lets us remove one indentation level.

Signed-off-by: James Almer 
---
 libavformat/avc.c | 20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index 7b32590778..6ec2f19577 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -105,17 +105,22 @@ int ff_avc_parse_nal_units_buf(const uint8_t *buf_in, 
uint8_t **buf, int *size)
 
 int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
 {
+uint8_t *buf = NULL, *end, *start;
+uint8_t *sps = NULL, *pps = NULL;
+uint32_t sps_size = 0, pps_size = 0;
+int ret;
+
 if (len < 6)
 return AVERROR_INVALIDDATA;
 
 /* check for H.264 start code */
-if (AV_RB32(data) == 0x0001 ||
-AV_RB24(data) == 0x01) {
-uint8_t *buf=NULL, *end, *start;
-uint32_t sps_size=0, pps_size=0;
-uint8_t *sps=0, *pps=0;
+if (AV_RB32(data) != 0x0001 &&
+AV_RB24(data) != 0x01) {
+avio_write(pb, data, len);
+return 0;
+}
 
-int ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
+ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
 if (ret < 0)
 return ret;
 start = buf;
@@ -156,9 +161,6 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 avio_wb16(pb, pps_size);
 avio_write(pb, pps, pps_size);
 av_free(start);
-} else {
-avio_write(pb, data, len);
-}
 return 0;
 }
 
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 4/5] avformat/avc: free buffer in ff_isom_write_avcc on failure

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/avc.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index 7542db684b..6ef6e08778 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -145,8 +145,10 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 buf += size;
 }
 
-if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
UINT16_MAX)
-return AVERROR_INVALIDDATA;
+if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
UINT16_MAX) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 
 avio_w8(pb, 1); /* version */
 avio_w8(pb, sps[1]); /* profile */
@@ -160,9 +162,11 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 avio_w8(pb, 1); /* number of pps */
 avio_wb16(pb, pps_size);
 avio_write(pb, pps, pps_size);
+
+fail:
 av_free(start);
 
-return 0;
+return ret;
 }
 
 int ff_avc_write_annexb_extradata(const uint8_t *in, uint8_t **buf, int *size)
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 3/5] avformat/avc: reindent after the last commit

[James Almer]

Signed-off-by: James Almer 
---
 libavformat/avc.c | 91 ---
 1 file changed, 46 insertions(+), 45 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index 6ec2f19577..7542db684b 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -113,54 +113,55 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 if (len < 6)
 return AVERROR_INVALIDDATA;
 
-/* check for H.264 start code */
-if (AV_RB32(data) != 0x0001 &&
-AV_RB24(data) != 0x01) {
-avio_write(pb, data, len);
-return 0;
+/* check for H.264 start code */
+if (AV_RB32(data) != 0x0001 &&
+AV_RB24(data) != 0x01) {
+avio_write(pb, data, len);
+return 0;
+}
+
+ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
+if (ret < 0)
+return ret;
+start = buf;
+end = buf + len;
+
+/* look for sps and pps */
+while (end - buf > 4) {
+uint32_t size;
+uint8_t nal_type;
+size = FFMIN(AV_RB32(buf), end - buf - 4);
+buf += 4;
+nal_type = buf[0] & 0x1f;
+
+if (nal_type == 7) { /* SPS */
+sps = buf;
+sps_size = size;
+} else if (nal_type == 8) { /* PPS */
+pps = buf;
+pps_size = size;
 }
 
-ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
-if (ret < 0)
-return ret;
-start = buf;
-end = buf + len;
-
-/* look for sps and pps */
-while (end - buf > 4) {
-uint32_t size;
-uint8_t nal_type;
-size = FFMIN(AV_RB32(buf), end - buf - 4);
-buf += 4;
-nal_type = buf[0] & 0x1f;
-
-if (nal_type == 7) { /* SPS */
-sps = buf;
-sps_size = size;
-} else if (nal_type == 8) { /* PPS */
-pps = buf;
-pps_size = size;
-}
-
-buf += size;
-}
+buf += size;
+}
+
+if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
UINT16_MAX)
+return AVERROR_INVALIDDATA;
+
+avio_w8(pb, 1); /* version */
+avio_w8(pb, sps[1]); /* profile */
+avio_w8(pb, sps[2]); /* profile compat */
+avio_w8(pb, sps[3]); /* level */
+avio_w8(pb, 0xff); /* 6 bits reserved (11) + 2 bits nal size length - 
1 (11) */
+avio_w8(pb, 0xe1); /* 3 bits reserved (111) + 5 bits number of sps (1) 
*/
+
+avio_wb16(pb, sps_size);
+avio_write(pb, sps, sps_size);
+avio_w8(pb, 1); /* number of pps */
+avio_wb16(pb, pps_size);
+avio_write(pb, pps, pps_size);
+av_free(start);
 
-if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || 
pps_size > UINT16_MAX)
-return AVERROR_INVALIDDATA;
-
-avio_w8(pb, 1); /* version */
-avio_w8(pb, sps[1]); /* profile */
-avio_w8(pb, sps[2]); /* profile compat */
-avio_w8(pb, sps[3]); /* level */
-avio_w8(pb, 0xff); /* 6 bits reserved (11) + 2 bits nal size 
length - 1 (11) */
-avio_w8(pb, 0xe1); /* 3 bits reserved (111) + 5 bits number of sps 
(1) */
-
-avio_wb16(pb, sps_size);
-avio_write(pb, sps, sps_size);
-avio_w8(pb, 1); /* number of pps */
-avio_wb16(pb, pps_size);
-avio_write(pb, pps, pps_size);
-av_free(start);
 return 0;
 }
 
-- 
2.15.0

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

[FFmpeg-devel] [PATCH 5/5] avformat/avc: support writting more than one sps/pps in ff_isom_write_avcc

[James Almer]

Addresses ticket #6864

Signed-off-by: James Almer 
---
I don't have the h264 in isobmff spec at hand, so i just looked at what
the h264_mp4toannexb bsf does to handle more than one sps and pps and
worked with that.
If there's a pps limit it's not currently enforced, but adding it is
trivial. The sps limit i added is arbitrarily 2^5-1, as that's the
amount of bits available for it.

 libavformat/avc.c | 50 +-
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/libavformat/avc.c b/libavformat/avc.c
index 6ef6e08778..634324aee5 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -105,10 +105,11 @@ int ff_avc_parse_nal_units_buf(const uint8_t *buf_in, 
uint8_t **buf, int *size)
 
 int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
 {
+AVIOContext *sps_pb = NULL, *pps_pb = NULL;
 uint8_t *buf = NULL, *end, *start;
 uint8_t *sps = NULL, *pps = NULL;
 uint32_t sps_size = 0, pps_size = 0;
-int ret;
+int ret, nb_sps = 0, nb_pps = 0;
 
 if (len < 6)
 return AVERROR_INVALIDDATA;
@@ -126,6 +127,13 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 start = buf;
 end = buf + len;
 
+ret = avio_open_dyn_buf(&sps_pb);
+if (ret < 0)
+goto fail;
+ret = avio_open_dyn_buf(&pps_pb);
+if (ret < 0)
+goto fail;
+
 /* look for sps and pps */
 while (end - buf > 4) {
 uint32_t size;
@@ -135,35 +143,51 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t 
*data, int len)
 nal_type = buf[0] & 0x1f;
 
 if (nal_type == 7) { /* SPS */
-sps = buf;
-sps_size = size;
+if (size > UINT16_MAX) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+avio_wb16(sps_pb, size);
+avio_write(sps_pb, buf, size);
+nb_sps++;
 } else if (nal_type == 8) { /* PPS */
-pps = buf;
-pps_size = size;
+if (size > UINT16_MAX) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+avio_wb16(pps_pb, size);
+avio_write(pps_pb, buf, size);
+nb_pps++;
 }
 
 buf += size;
 }
+sps_size = avio_close_dyn_buf(sps_pb, &sps);
+pps_size = avio_close_dyn_buf(pps_pb, &pps);
 
-if (!sps || !pps || sps_size < 4 || sps_size > UINT16_MAX || pps_size > 
UINT16_MAX) {
+if (nb_sps > 31 || sps_size < 6 || !pps_size) {
 ret = AVERROR_INVALIDDATA;
 goto fail;
 }
 
 avio_w8(pb, 1); /* version */
-avio_w8(pb, sps[1]); /* profile */
-avio_w8(pb, sps[2]); /* profile compat */
-avio_w8(pb, sps[3]); /* level */
+avio_w8(pb, sps[3]); /* profile */
+avio_w8(pb, sps[4]); /* profile compat */
+avio_w8(pb, sps[5]); /* level */
 avio_w8(pb, 0xff); /* 6 bits reserved (11) + 2 bits nal size length - 
1 (11) */
-avio_w8(pb, 0xe1); /* 3 bits reserved (111) + 5 bits number of sps (1) 
*/
+avio_w8(pb, 0xe0 | nb_sps); /* 3 bits reserved (111) + 5 bits number of 
sps */
 
-avio_wb16(pb, sps_size);
 avio_write(pb, sps, sps_size);
-avio_w8(pb, 1); /* number of pps */
-avio_wb16(pb, pps_size);
+avio_w8(pb, nb_pps); /* number of pps */
 avio_write(pb, pps, pps_size);
 
 fail:
+if (!sps)
+avio_close_dyn_buf(sps_pb, &sps);
+if (!pps)
+avio_close_dyn_buf(pps_pb, &pps);
+av_free(sps);
+av_free(pps);
 av_free(start);
 
 return ret;
-- 
2.15.0

___
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

[Mark Reid]

On Tue, Nov 28, 2017 at 3:05 PM, Tomas Härdin  wrote:

> On Tue, 2017-11-28 at 21:09 +0100, Michael Niedermayer wrote:
> > On Mon, Nov 27, 2017 at 11:00:51AM +0100, Tomas Härdin wrote:
> > > 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.
> >
> > will apply
> >
> > thanks
>
> It sounded like he's working on an alternate patchset, see the PATCH
> 3/4 thread
>

I see this was already applied, this one wasn't going to change in my new
patchset so it should be okay.


> /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] swscale/utils: Remove bpc==8 gating init_range_convert

[Neil Birkbeck]

On Tue, Nov 28, 2017 at 5:14 PM, Neil Birkbeck 
wrote:

> -//The srcBpc check is possibly wrong but we seem to lack a definitive
> reference to test this
> -//and what we have in ticket 2939 looks better with this check
> -if (need_reinit && (c->srcBpc == 8 || !isYUV(c->srcFormat)))
> +if (need_reinit)
>  ff_sws_init_range_convert(c);
>

Wanted to check and see if someone more familiar with this condition can
comment as to whether some parts of it may still be necessary.

Also, this may also need to be coupled with a change to vf_scale.
E.g., at the moment, I think scaling >10bit YUV without explicit _range
settings may not change color range of the data (but it may assign
incorrect color_range flag to the frame).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Jun Zhao]

On 2017/11/28 21:23, Carl Eugen Hoyos wrote:
> 2017-11-28 6:20 GMT+01:00 Jun Zhao :
>
> Could be split.
Do you means split with 2 patches? 1) for issue fix 2) for coding
reconstruct ?
>
> 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 1/2] avcodec/mlpenc: encode last frame too

[James Almer]

On 11/28/2017 4:55 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/mlpenc.c | 22 +++---
>  1 file changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index 7536d3b2f5..c588f5b904 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -2225,29 +2225,27 @@ static int mlp_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  int restart_frame, ret;
>  uint8_t *data;
>  
> -if ((ret = ff_alloc_packet2(avctx, avpkt, 87500 * avctx->channels, 0)) < 
> 0)
> -return ret;
> -
> -if (!frame)
> -return 1;
> -
>  /* add current frame to queue */
>  if (frame) {
>  if ((ret = ff_af_queue_add(&ctx->afq, frame)) < 0)
>  return ret;
> +} else {
> +if (ctx->last_frame == ctx->inout_buffer) {
> +return 0;
> +}
>  }
>  
> -data = frame->data[0];
> +
> +if ((ret = ff_alloc_packet2(avctx, avpkt, 87500 * avctx->channels, 0)) < 
> 0)
> +return ret;
> +
> +data = frame ? frame->data[0] : NULL;
>  
>  ctx->frame_index = avctx->frame_number % ctx->max_restart_interval;
>  
>  ctx->inout_buffer = ctx->major_inout_buffer
>+ ctx->frame_index * ctx->one_sample_buffer_size;
>  
> -if (ctx->last_frame == ctx->inout_buffer) {
> -return 0;
> -}
> -
>  ctx->sample_buffer = ctx->major_scratch_buffer
> + ctx->frame_index * ctx->one_sample_buffer_size;
>  
> @@ -2333,6 +2331,8 @@ input_and_return:
>  number_of_samples += 
> ctx->frame_size[(ctx->starting_frame_index + index) % 
> ctx->max_restart_interval];
>  }
>  ctx->number_of_samples = number_of_samples;
> +if (!ctx->number_of_samples)
> +break;
>  
>  for (index = 0; index < ctx->seq_size[seq_index]; index++) {
>  clear_channel_params(ctx, ctx->seq_channel_params + 
> index*(ctx->avctx->channels));
> 

After this patch the sample from ticket 6216 prints a "Trying to remove
40 samples, but the queue is empty" warning during encoding.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add android_capture indev

[Michael Niedermayer]

On Fri, Nov 10, 2017 at 09:41:04PM +0100, Felix Matouschek wrote:
> Hello,
> 
> here is a new version of the patch with further fixes.
[...]

> +static const char *camera_status_string(camera_status_t val)
> +{
> +switch(val) {
> +case ACAMERA_OK:
> +return "ACAMERA_OK";

if the identifer and the string always match you could do this
with a macro avoiding the neede to duplcate each string
see AV_STRINGIFY


[...]
> +static int read_closing(AndroidCameraCtx *ctx)
> +{
> +int read_closing;
> +pthread_mutex_lock(&ctx->read_closing_mutex);
> +read_closing = ctx->read_closing;
> +pthread_mutex_unlock(&ctx->read_closing_mutex);
> +return read_closing;
> +}
> +
> +static void set_read_closing(AndroidCameraCtx *ctx, int read_closing)
> +{
> +pthread_mutex_lock(&ctx->read_closing_mutex);
> +ctx->read_closing = read_closing;
> +pthread_mutex_unlock(&ctx->read_closing_mutex);
> +}

Thic can be simplified using C11 atomics


[...]
> +static void match_video_size(AVFormatContext *avctx)
> +{
> +AndroidCameraCtx *ctx = avctx->priv_data;
> +ACameraMetadata_const_entry available_configs;
> +int ret = -1;
> +
> +ACameraMetadata_getConstEntry(ctx->camera_metadata,
> +  
> ACAMERA_SCALER_AVAILABLE_STREAM_CONFIGURATIONS,
> +  &available_configs);
> +
> +for (int i = 0; i < available_configs.count; i++) {
> +int32_t input = available_configs.data.i32[i * 4 + 3];
> +int32_t format = available_configs.data.i32[i * 4 + 0];
> +
> +if (input) {
> +continue;
> +}
> +
> +if (format == IMAGE_FORMAT_ANDROID) {
> +int32_t width = available_configs.data.i32[i * 4 + 1];
> +int32_t height = available_configs.data.i32[i * 4 + 2];
> +
> +//Same ratio

> +if (ctx->requested_width * ctx->requested_height == width * 
> height) {

the product of these can maybe overflow i think


> +ctx->width = width;
> +ctx->height = height;
> +ret = 0;
> +break;
> +}
> +}
> +}
> +

> +if (ret < 0 || ctx->width == 0 || ctx->height == 0) {
> +ctx->width = available_configs.data.i32[1];
> +ctx->height = available_configs.data.i32[2];
> +ret = -1;
> +
> +av_log(avctx, AV_LOG_WARNING,
> +   "Requested video_size %dx%d not available, falling back to 
> %dx%d\n",
> +   ctx->requested_width, ctx->requested_height, ctx->width, 
> ctx->height);
> +}

you set ret but nothing uses it

> +
> +return;
> +}

[...]
> +static int add_video_stream(AVFormatContext *avctx)
> +{
> +AndroidCameraCtx *ctx = avctx->priv_data;
> +AVStream *st;
> +AVCodecParameters *codecpar;
> +
> +st = avformat_new_stream(avctx, NULL);
> +if (!st) {
> +return AVERROR(ENOMEM);
> +}
> +
> +st->id = VIDEO_STREAM_INDEX;

> +st->avg_frame_rate = (AVRational) { ctx->framerate_range[1], 1 };
> +st->r_frame_rate = (AVRational) { ctx->framerate_range[1], 1 };

Are these values always correct ?


[...]
> +if (ctx->camera_id) {
> +av_freep(&ctx->camera_id);
> +}

the if() is unneeded


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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

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

[Michael Niedermayer]

On Tue, Nov 28, 2017 at 01:47:11PM -0800, Dale Curtis wrote:
> Otherwise ff_alloc_extradata() just leaks any existing allocated
> memory. Similar to the patch for ogm extradata leaks.
> 
> Signed-off-by: Dale Curtis 

>  oggparseopus.c |1 +
>  1 file changed, 1 insertion(+)
> bf0b03b22a4253d86fb8617fc8e00d945042  ogg_extradata_v1.patch
> From ac7f2deaa48ac0578be19b178b7c0bc8040bc278 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Tue, 28 Nov 2017 13:44:49 -0800
> Subject: [PATCH] [ogg] Free opus extradata before reallocating.
> 
> Otherwise ff_alloc_extradata() just leaks any existing allocated
> memory.

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] vaapi_h265: general_level_idc should times 3.

[Li, Zhong]

> On 28/11/17 07:46, Ruiling Song wrote:
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavcodec/vaapi_encode_h265.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h265.c
> > b/libavcodec/vaapi_encode_h265.c index 3ae92a7..32b8bc6 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -219,7 +219,7 @@ static int
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> >  .general_non_packed_constraint_flag = 1,
> >  .general_frame_only_constraint_flag = 1,
> >
> > -.general_level_idc = avctx->level,
> > +.general_level_idc = avctx->level * 3,
> >  };
> >
> > vps->profile_tier_level.general_profile_compatibility_flag[avctx->prof
> > ile & 31] = 1;
> >
> >
> The documentation has always said "profile and level set the values of
> general_profile_idc and general_level_idc respectively"
> () - the code
> disagreed for a while, but that was made consistent in
> 00179664bccd1dd6fa0d1c40db453528757bf6f7.
> 
> Why do you want to change it to be general_level_idc / 3 instead?

As HEVC spec, "general_level_idc and sub_layer_level_idc[ i ] shall be set 
equal to a value of 30 times the level number specified in
Table A.4."
And use the tool "mediainfo" to check the encoded bitstream, it show the level 
is 1.7 if set the option "-level" to be 51.

Maybe the documentation 
(()) also needs to be 
changed? 



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

Re: [FFmpeg-devel] [oggvp8] Don't manipulate duration when it's AV_NOPTS_VALUE.

[James Almer]

On 11/28/2017 7:28 PM, Dale Curtis wrote:
> This leads to signed integer overflow.
> 
> Signed-off-by: Dale Curtis 
> 
> 
> ogg_vp8_v1.patch
> 
> 
> From c1fa869b79aeb314f30746a561903fcfa8f305fb Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Tue, 28 Nov 2017 14:26:55 -0800
> Subject: [PATCH] [oggvp8] Don't manipulate duration when it's AV_NOPTS_VALUE.
> 
> This leads to signed integer overflow.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/oggparsevp8.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/oggparsevp8.c b/libavformat/oggparsevp8.c
> index c534ab117d..b76ac71cc5 100644
> --- a/libavformat/oggparsevp8.c
> +++ b/libavformat/oggparsevp8.c
> @@ -125,7 +125,7 @@ static int vp8_packet(AVFormatContext *s, int idx)
>  os->lastdts = vp8_gptopts(s, idx, os->granule, NULL) - duration;
>  if(s->streams[idx]->start_time == AV_NOPTS_VALUE) {
>  s->streams[idx]->start_time = os->lastpts;
> -if (s->streams[idx]->duration)
> +if (s->streams[idx]->duration && s->streams[idx]->duration != 
> AV_NOPTS_VALUE)
>  s->streams[idx]->duration -= s->streams[idx]->start_time;
>  }
>  }
> -- 2.15.0.417.g466bffb3ac-goog

Applied, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/4] lavfi/avfilter: simplify filter registration

[Rostislav Pehlivanov]

On 28 November 2017 at 20:23, Michael Niedermayer 
wrote:

> On Mon, Nov 27, 2017 at 04:30:19AM +, Rostislav Pehlivanov wrote:
> > Atomics were entirely pointless and did nothing but slow and complicate
> > the process down. This could be improved further still but the main
> > objective of this commit is to simplify.
> >
> > Signed-off-by: Rostislav Pehlivanov 
> > ---
> >  libavfilter/avfilter.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
>
> *_register() can be called by the user app in a unsyncronized way
> for example from a module like vlc used AFAIK.
> or from libs loaded by an application which use libavfilter or other
> internally.
>
> These registration functions should stay thread safe
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
What variable actually needs to be protected?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mlpenc: fix undefined shift

[Rostislav Pehlivanov]

On 28 November 2017 at 19:55, Paul B Mahol  wrote:

> Decreases artifacts.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/mlpenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index c588f5b904..eceb0ddbb2 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -466,7 +466,7 @@ static void default_decoding_params(MLPEncodeContext
> *ctx,
>   */
>  static int inline number_sbits(int number)
>  {
> -if (number < 0)
> +if (number <= 0)
>  number++;
>
>  return av_log2(FFABS(number)) + 1 + !!number;
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Doesn't really seem to do anything to lossless check failures (not in 32
bit mode either where most of the errors are, which is why its disabled).
Which undefined shift does it fix?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mlpenc: fix undefined shift

[James Almer]

On 11/29/2017 1:05 AM, Rostislav Pehlivanov wrote:
> On 28 November 2017 at 19:55, Paul B Mahol  wrote:
> 
>> Decreases artifacts.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavcodec/mlpenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
>> index c588f5b904..eceb0ddbb2 100644
>> --- a/libavcodec/mlpenc.c
>> +++ b/libavcodec/mlpenc.c
>> @@ -466,7 +466,7 @@ static void default_decoding_params(MLPEncodeContext
>> *ctx,
>>   */
>>  static int inline number_sbits(int number)
>>  {
>> -if (number < 0)
>> +if (number <= 0)
>>  number++;
>>
>>  return av_log2(FFABS(number)) + 1 + !!number;
>> --
>> 2.11.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> Doesn't really seem to do anything to lossless check failures (not in 32
> bit mode either where most of the errors are, which is why its disabled).

It does for the sample in ticket 6216. It removes the check failure
errors, but the end result is apparently still not bitexact.

> Which undefined shift does it fix?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

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

[Mark Reid]

---
 libavformat/mxf.h|  1 +
 libavformat/mxfenc.c | 42 +++---
 2 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 2d5b44943b..ffcc429a8b 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -47,6 +47,7 @@ enum MXFMetadataSetType {
 EssenceContainerData,
 EssenceGroup,
 TaggedValue,
+TapeDescriptor,
 };
 
 enum MXFFrameLayout {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index baaeb8c617..02192aa22b 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -105,6 +105,7 @@ typedef struct MXFPackage {
 char *name;
 enum MXFMetadataSetType type;
 int instance;
+struct MXFPackage *ref;
 } MXFPackage;
 
 enum ULIndex {
@@ -991,20 +992,33 @@ static void 
mxf_write_structural_component(AVFormatContext *s, AVStream *st, MXF
 
 // write source package uid, end of the reference
 mxf_write_local_tag(pb, 32, 0x1101);
-if (package->type == SourcePackage) {
+if (!package->ref) {
 for (i = 0; i < 4; i++)
 avio_wb64(pb, 0);
 } else
-mxf_write_umid(s, 1);
+mxf_write_umid(s, package->ref->instance);
 
 // write source track id
 mxf_write_local_tag(pb, 4, 0x1102);
-if (package->type == SourcePackage)
+if (package->type == SourcePackage && !package->ref)
 avio_wb32(pb, 0);
 else
 avio_wb32(pb, st->index+2);
 }
 
+static void mxf_write_tape_descriptor(AVFormatContext *s)
+{
+AVIOContext *pb = s->pb;
+
+mxf_write_metadata_key(pb, 0x012e00);
+PRINT_KEY(s, "tape descriptor key", pb->buf_ptr - 16);
+klv_encode_ber_length(pb, 20);
+mxf_write_local_tag(pb, 16, 0x3C0A);
+mxf_write_uuid(pb, TapeDescriptor, 0);
+PRINT_KEY(s, "tape_desc uid", pb->buf_ptr - 16);
+}
+
+
 static void mxf_write_multi_descriptor(AVFormatContext *s)
 {
 MXFContext *mxf = s->priv_data;
@@ -1388,13 +1402,17 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
 }
 
 // write multiple descriptor reference
-if (package->type == SourcePackage) {
+if (package->type == SourcePackage && package->instance == 1) {
 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->type == SourcePackage && package->instance == 2) {
+mxf_write_local_tag(pb, 16, 0x4701);
+mxf_write_uuid(pb, TapeDescriptor, 0);
+mxf_write_tape_descriptor(s);
 }
 
 // write timecode track
@@ -1410,7 +1428,7 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
 mxf_write_structural_component(s, st, package);
 mxf->track_uuid_offset++;
 
-if (package->type == SourcePackage) {
+if (package->type == SourcePackage && package->instance == 1) {
 MXFStreamContext *sc = st->priv_data;
 mxf_essence_container_uls[sc->index].write_desc(s, st);
 }
@@ -1445,12 +1463,13 @@ static int 
mxf_write_header_metadata_sets(AVFormatContext *s)
 AVDictionaryEntry *entry = NULL;
 AVStream *st = NULL;
 int i;
-
-MXFPackage packages[2] = {};
+MXFPackage packages[3] = {};
 int package_count = 2;
 packages[0].type = MaterialPackage;
 packages[1].type = SourcePackage;
 packages[1].instance = 1;
+packages[0].ref = &packages[1];
+
 
 if (entry = av_dict_get(s->metadata, "material_package_name", NULL, 0))
packages[0].name = entry->value;
@@ -1468,6 +1487,15 @@ static int 
mxf_write_header_metadata_sets(AVFormatContext *s)
 }
 }
 
+entry = av_dict_get(s->metadata, "reel_name", NULL, 0);
+if (entry) {
+packages[2].name = entry->value;
+packages[2].type = SourcePackage;
+packages[2].instance = 2;
+packages[1].ref = &packages[2];
+package_count = 3;
+}
+
 mxf_write_preface(s);
 mxf_write_identification(s);
 mxf_write_content_storage(s, packages, package_count);
-- 
2.13.6 (Apple Git-96)

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

[FFmpeg-devel] [PATCH v2 1/3] avformat/mxfenc: use track count to generate component instance uuid

[Mark Reid]

---
 libavformat/mxf.h   |  1 -
 libavformat/mxfenc.c| 30 +-
 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, 27 insertions(+), 24 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index f3db1f939b..2d5b44943b 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -45,7 +45,6 @@ enum MXFMetadataSetType {
 SubDescriptor,
 IndexTableSegment,
 EssenceContainerData,
-TypeBottom,// add metadata type before this
 EssenceGroup,
 TaggedValue,
 };
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ed6ecbf541..baaeb8c617 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -386,6 +386,7 @@ typedef struct MXFContext {
 uint32_t tagged_value_count;
 AVRational audio_edit_rate;
 int store_user_comments;
+int track_uuid_offset;
 } MXFContext;
 
 static const uint8_t uuid_base[]= { 
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd };
@@ -853,7 +854,7 @@ static void mxf_write_track(AVFormatContext *s, AVStream 
*st, MXFPackage *packag
 
 // write track uid
 mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? Track : Track + 
TypeBottom, st->index);
+mxf_write_uuid(pb, Track, mxf->track_uuid_offset);
 PRINT_KEY(s, "track uid", pb->buf_ptr - 16);
 
 // write track id
@@ -884,7 +885,7 @@ static void mxf_write_track(AVFormatContext *s, AVStream 
*st, MXFPackage *packag
 
 // write sequence refs
 mxf_write_local_tag(pb, 16, 0x4803);
-mxf_write_uuid(pb, package->type == MaterialPackage ? Sequence: Sequence + 
TypeBottom, st->index);
+mxf_write_uuid(pb, Sequence, mxf->track_uuid_offset);
 }
 
 static const uint8_t smpte_12m_timecode_track_data_ul[] = { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x01,0x03,0x02,0x01,0x01,0x00,0x00,0x00 
};
@@ -924,7 +925,7 @@ static void mxf_write_sequence(AVFormatContext *s, AVStream 
*st, MXFPackage *pac
 klv_encode_ber_length(pb, 80);
 
 mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? Sequence: Sequence + 
TypeBottom, st->index);
+mxf_write_uuid(pb, Sequence, mxf->track_uuid_offset);
 
 PRINT_KEY(s, "sequence uid", pb->buf_ptr - 16);
 mxf_write_common_fields(s, st);
@@ -936,9 +937,8 @@ static void mxf_write_sequence(AVFormatContext *s, AVStream 
*st, MXFPackage *pac
 component = TimecodeComponent;
 else
 component = SourceClip;
-if (package->type == SourcePackage)
-component += TypeBottom;
-mxf_write_uuid(pb, component, st->index);
+
+mxf_write_uuid(pb, component, mxf->track_uuid_offset);
 }
 
 static void mxf_write_timecode_component(AVFormatContext *s, AVStream *st, 
MXFPackage *package)
@@ -951,8 +951,7 @@ static void mxf_write_timecode_component(AVFormatContext 
*s, AVStream *st, MXFPa
 
 // UID
 mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? TimecodeComponent :
-   TimecodeComponent + TypeBottom, st->index);
+mxf_write_uuid(pb, TimecodeComponent, mxf->track_uuid_offset);
 
 mxf_write_common_fields(s, st);
 
@@ -971,6 +970,7 @@ static void mxf_write_timecode_component(AVFormatContext 
*s, AVStream *st, MXFPa
 
 static void mxf_write_structural_component(AVFormatContext *s, AVStream *st, 
MXFPackage *package)
 {
+MXFContext *mxf = s->priv_data;
 AVIOContext *pb = s->pb;
 int i;
 
@@ -980,7 +980,7 @@ static void mxf_write_structural_component(AVFormatContext 
*s, AVStream *st, MXF
 
 // write uid
 mxf_write_local_tag(pb, 16, 0x3C0A);
-mxf_write_uuid(pb, package->type == MaterialPackage ? SourceClip: 
SourceClip + TypeBottom, st->index);
+mxf_write_uuid(pb, SourceClip, mxf->track_uuid_offset);
 
 PRINT_KEY(s, "structural component uid", pb->buf_ptr - 16);
 mxf_write_common_fields(s, st);
@@ -1357,7 +1357,7 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
 
 // write package umid
 mxf_write_local_tag(pb, 32, 0x4401);
-mxf_write_umid(s, package->type == SourcePackage);
+mxf_write_umid(s, package->instance);
 PRINT_KEY(s, "package umid second part", pb->buf_ptr - 16);
 
 // package name
@@ -1375,10 +1375,9 @@ static void mxf_write_package(AVFormatContext *s, 
MXFPackage *package)
 // write track refs
 mxf_write_local_tag(pb, track_count*16 + 8, 0x4403);
 mxf_write_refs_count(pb, track_count);
-mxf_write_uuid(pb, package->type == MaterialPackage ? Track :
-   Track + TypeBottom, -1); // timecode track
+mxf_write_uuid(pb, Track, mxf->track_uuid_offset); // timecode tr

[FFmpeg-devel] [PATCH v2 0/3] avformat/mxfenc add reel_name write support

[Mark Reid]

changes since v1
* simplified uuid_offset
* added SourcePackage type checks
* only support reel_name at the format level

Mark Reid (3):
  avformat/mxfenc: use track count to generate component instance uuid
  avformat/mxfenc: write reel_name if metadata key is present
  fate/mxf: add reel name test

 libavformat/mxf.h   |  2 +-
 libavformat/mxfenc.c| 72 +
 tests/fate/mxf.mak  |  8 +++--
 tests/ref/fate/copy-trac4914|  2 +-
 tests/ref/fate/mxf-reel_name|  1 +
 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 +-
 12 files changed, 70 insertions(+), 33 deletions(-)
 create mode 100644 tests/ref/fate/mxf-reel_name

-- 
2.13.6 (Apple Git-96)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2 3/3] fate/mxf: add reel name test

[Mark Reid]

---
 tests/fate/mxf.mak   | 8 ++--
 tests/ref/fate/mxf-reel_name | 1 +
 2 files changed, 7 insertions(+), 2 deletions(-)
 create mode 100644 tests/ref/fate/mxf-reel_name

diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak
index 7714b61569..dce23d522e 100644
--- a/tests/fate/mxf.mak
+++ b/tests/fate/mxf.mak
@@ -33,9 +33,13 @@ FATE_MXF_PROBE-$(call ENCDEC2, DVVIDEO, PCM_S16LE, MXF) += 
fate-mxf-probe-dv25
 fate-mxf-probe-dv25: SRC = $(TARGET_SAMPLES)/mxf/Avid-5.mxf
 fate-mxf-probe-dv25: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
 
+FATE_MXF_REEL_NAME-$(call ENCDEC2, MPEG2VIDEO, PCM_S16LE, MXF) += 
fate-mxf-reel_name
+fate-mxf-reel_name: $(TARGET_SAMPLES)/mxf/Sony-1.mxf
+fate-mxf-reel_name: CMD = md5 -y -i $(TARGET_SAMPLES)/mxf/Sony-1.mxf  -c 
copy -timecode 00:00:00:00 -metadata "reel_name=test_reel" -fflags +bitexact -f 
mxf
+
 FATE_MXF-$(CONFIG_MXF_DEMUXER) += $(FATE_MXF)
 
-FATE_SAMPLES_AVCONV += $(FATE_MXF-yes)
+FATE_SAMPLES_AVCONV += $(FATE_MXF-yes) $(FATE_MXF_REEL_NAME-yes)
 FATE_SAMPLES_FFPROBE += $(FATE_MXF_PROBE-yes)
 
-fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes)
+fate-mxf: $(FATE_MXF-yes) $(FATE_MXF_PROBE-yes) $(FATE_MXF_REEL_NAME-yes)
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
new file mode 100644
index 00..fb9586097a
--- /dev/null
+++ b/tests/ref/fate/mxf-reel_name
@@ -0,0 +1 @@
+dda6c54b642b8794a87d809fdb361f95
-- 
2.13.6 (Apple Git-96)

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

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/24/17, 3:49 PM, "Jeyapal, Karthick"  wrote:
>
>On 11/24/17, 3:40 PM, "刘歧"  wrote:
>
>>> 在 2017年11月24日，18:02，Jeyapal, Karthick  写道：
>>> 
>>> On 11/22/17, 1:27 PM, "Jeyapal, Karthick"  wrote:
>>> 
> On 11/22/17, 9:32 AM, "刘歧"  wrote:
> 
> This patch is ok, but i see it need an API: ffio_geturlcontext
> 
> it in the other patch, i see it have some thing need talk? If that is ok, 
> this patch should be apply.
>>Is this ok?
>Yes, ffio_geturlcontext has already been accepted by Nicolas.
>http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220014.html
>He had concerns on calling prot->url_write directly from hlsenc, which has 
>been removed on new patchset(v2).
>Also av_assert0 has been added as suggested by him
A gentle reminder. 
7 days have gone by since the last version of this patchset was submitted. And 
no objections so far.
Could this patchset be pushed, please? Thanks.
>>
>>Thanks
 Thanks for the reply. 
 All concerns raised by Nicolas has been addressed in this latest patch set.
 Let us wait for few days to check if anyone still has any objections.
>>> Looks like nobody has anymore objections to this patchset. 
>>> Well, it has already passed through multiple rounds of reviews.
>>> Could somebody please push this to the master. 
>>> I have few more patches waiting to be submitted, dependent on this feature.



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

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[刘歧]

> 在 2017年11月29日，12:05，Jeyapal, Karthick  写道：
> 
> 
> On 11/24/17, 3:49 PM, "Jeyapal, Karthick"  wrote:
>> 
>> On 11/24/17, 3:40 PM, "刘歧"  wrote:
>> 
 在 2017年11月24日，18:02，Jeyapal, Karthick  写道：
 
 On 11/22/17, 1:27 PM, "Jeyapal, Karthick"  wrote:
 
>> On 11/22/17, 9:32 AM, "刘歧"  wrote:
>> 
>> This patch is ok, but i see it need an API: ffio_geturlcontext
>> 
>> it in the other patch, i see it have some thing need talk? If that is 
>> ok, this patch should be apply.
>>> Is this ok?
>> Yes, ffio_geturlcontext has already been accepted by Nicolas.
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220014.html
>> He had concerns on calling prot->url_write directly from hlsenc, which has 
>> been removed on new patchset(v2).
>> Also av_assert0 has been added as suggested by him
> A gentle reminder. 
> 7 days have gone by since the last version of this patchset was submitted. 
> And no objections so far.
> Could this patchset be pushed, please? Thanks.
Can you resubmit a new version of this patchiest, There have too many version 
and ignore version patches.


Thanks
>>> 
>>> Thanks
> Thanks for the reply. 
> All concerns raised by Nicolas has been addressed in this latest patch 
> set.
> Let us wait for few days to check if anyone still has any objections.
 Looks like nobody has anymore objections to this patchset. 
 Well, it has already passed through multiple rounds of reviews.
 Could somebody please push this to the master. 
 I have few more patches waiting to be submitted, dependent on this feature.
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



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

[FFmpeg-devel] [PATCH v3 1/3] libavformat/avio: Utility function to return URLContext

[Karthick J]

---
 libavformat/avio_internal.h |  8 
 libavformat/aviobuf.c   | 13 +
 2 files changed, 21 insertions(+)

diff --git a/libavformat/avio_internal.h b/libavformat/avio_internal.h
index c01835d..04c1ad5 100644
--- a/libavformat/avio_internal.h
+++ b/libavformat/avio_internal.h
@@ -133,6 +133,14 @@ int ffio_open_dyn_packet_buf(AVIOContext **s, int 
max_packet_size);
 int ffio_fdopen(AVIOContext **s, URLContext *h);
 
 /**
+ * Return the URLContext associated with the AVIOContext
+ *
+ * @param s IO context
+ * @return pointer to URLContext or NULL.
+ */
+URLContext *ffio_geturlcontext(AVIOContext *s);
+
+/**
  * Open a write-only fake memory stream. The written data is not stored
  * anywhere - this is only used for measuring the amount of data
  * written.
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 3b4c843..86eb657 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -980,6 +980,19 @@ fail:
 return AVERROR(ENOMEM);
 }
 
+URLContext* ffio_geturlcontext(AVIOContext *s)
+{
+AVIOInternal *internal;
+if (!s)
+return NULL;
+
+internal = s->opaque;
+if (internal && s->read_packet == io_read_packet)
+return internal->h;
+else
+return NULL;
+}
+
 int ffio_ensure_seekback(AVIOContext *s, int64_t buf_size)
 {
 uint8_t *buffer;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v3 2/3] libavformat/http: Handled multiple_requests option during write

[Karthick J]

---
 libavformat/http.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 056d5f6..cf86adc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -171,6 +171,7 @@ static int http_connect(URLContext *h, const char *path, 
const char *local_path,
 const char *hoststr, const char *auth,
 const char *proxyauth, int *new_location);
 static int http_read_header(URLContext *h, int *new_location);
+static int http_shutdown(URLContext *h, int flags);
 
 void ff_http_init_auth_state(URLContext *dest, const URLContext *src)
 {
@@ -306,6 +307,11 @@ int ff_http_do_new_request(URLContext *h, const char *uri)
 AVDictionary *options = NULL;
 int ret;
 
+ret = http_shutdown(h, h->flags);
+if (ret < 0)
+return ret;
+
+s->end_chunked_post = 0;
 s->chunkend  = 0;
 s->off   = 0;
 s->icy_data_read = 0;
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v3 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Karthick J]

---
 doc/muxers.texi  |  3 +++
 libavformat/hlsenc.c | 48 +---
 2 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 9d9ca31..8ec48c2 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -854,6 +854,9 @@ ffmpeg -re -i in.ts -f hls -master_pl_name master.m3u8 \
 This example creates HLS master playlist with name master.m3u8 and keep
 publishing it repeatedly every after 30 segments i.e. every after 60s.
 
+@item http_persistent
+Use persistent HTTP connections. Applicable only for HTTP output.
+
 @end table
 
 @anchor{ico}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6997a5c..d5c732f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -45,6 +45,7 @@
 
 #include "avformat.h"
 #include "avio_internal.h"
+#include "http.h"
 #include "internal.h"
 #include "os_support.h"
 
@@ -205,6 +206,7 @@ typedef struct HLSContext {
 char *var_stream_map; /* user specified variant stream map string */
 char *master_pl_name;
 unsigned int master_publish_rate;
+int http_persistent;
 } HLSContext;
 
 static int get_int_from_double(double val)
@@ -245,10 +247,38 @@ static int mkdir_p(const char *path) {
 return ret;
 }
 
+static int is_http_proto(char *filename) {
+const char *proto = avio_find_protocol_name(filename);
+return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
"https")) : 0;
+}
+
+static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char *filename,
+  AVDictionary **options) {
+HLSContext *hls = s->priv_data;
+int http_base_proto = is_http_proto(filename);
+int err;
+if (!*pb || !http_base_proto || !hls->http_persistent) {
+err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
+} else {
+URLContext *http_url_context = ffio_geturlcontext(*pb);
+av_assert0(http_url_context);
+err = ff_http_do_new_request(http_url_context, filename);
+}
+return err;
+}
+
+static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
*filename) {
+HLSContext *hls = s->priv_data;
+int http_base_proto = is_http_proto(filename);
+
+if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
hls->encrypt) {
+ff_format_io_close(s, pb);
+}
+}
+
 static void set_http_options(AVFormatContext *s, AVDictionary **options, 
HLSContext *c)
 {
-const char *proto = avio_find_protocol_name(s->filename);
-int http_base_proto = proto ? (!av_strcasecmp(proto, "http") || 
!av_strcasecmp(proto, "https")) : 0;
+int http_base_proto = is_http_proto(s->filename);
 
 if (c->method) {
 av_dict_set(options, "method", c->method, 0);
@@ -258,6 +288,8 @@ static void set_http_options(AVFormatContext *s, 
AVDictionary **options, HLSCont
 }
 if (c->user_agent)
 av_dict_set(options, "user_agent", c->user_agent, 0);
+if (c->http_persistent)
+av_dict_set_int(options, "multiple_requests", 1, 0);
 
 }
 
@@ -1437,17 +1469,17 @@ static int hls_start(AVFormatContext *s, VariantStream 
*vs)
 err = AVERROR(ENOMEM);
 goto fail;
 }
-err = s->io_open(s, &oc->pb, filename, AVIO_FLAG_WRITE, &options);
+err = hlsenc_io_open(s, &oc->pb, filename, &options);
 av_free(filename);
 av_dict_free(&options);
 if (err < 0)
 return err;
 } else
-if ((err = s->io_open(s, &oc->pb, oc->filename, AVIO_FLAG_WRITE, 
&options)) < 0)
+if ((err = hlsenc_io_open(s, &oc->pb, oc->filename, &options)) < 0)
 goto fail;
 if (vs->vtt_basename) {
 set_http_options(s, &options, c);
-if ((err = s->io_open(s, &vtt_oc->pb, vtt_oc->filename, 
AVIO_FLAG_WRITE, &options)) < 0)
+if ((err = hlsenc_io_open(s, &vtt_oc->pb, vtt_oc->filename, &options)) 
< 0)
 goto fail;
 }
 av_dict_free(&options);
@@ -2165,11 +2197,12 @@ static int hls_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 avio_open_dyn_buf(&oc->pb);
 vs->packets_written = 0;
 ff_format_io_close(s, &vs->out);
+hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
 } else {
-ff_format_io_close(s, &oc->pb);
+hlsenc_io_close(s, &oc->pb, oc->filename);
 }
 if (vs->vtt_avf) {
-ff_format_io_close(s, &vs->vtt_avf->pb);
+hlsenc_io_close(s, &vs->vtt_avf->pb, vs->vtt_avf->filename);
 }
 }
 if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
@@ -2355,6 +2388,7 @@ static const AVOption options[] = {
 {"var_stream_map", "Variant stream map string", OFFSET(var_stream_map), 
AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
 {"master_pl_name", "Create HLS master playlist with this name", 
OFFSET(master_pl_name), AV_OPT_TYPE_STRING, {.str = NULL}, 

Re: [FFmpeg-devel] [PATCH v2 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/29/17, 11:41 AM, "刘歧"  wrote:

>> 在 2017年11月29日，12:05，Jeyapal, Karthick  写道：
>> 
>> A gentle reminder. 
>> 7 days have gone by since the last version of this patchset was submitted. 
>> And no objections so far.
>> Could this patchset be pushed, please? Thanks.
>Can you resubmit a new version of this patchiest, There have too many version 
>and ignore version patches.

Thanks for the reply. 
I have resent the patches as new version v3 for the sake of clarity.

>Thanks

regards,
Karthick

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

Re: [FFmpeg-devel] [PATCH v3 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[刘歧]

> 在 2017年11月29日，14:19，Karthick J  写道：
> 
> ---
> doc/muxers.texi  |  3 +++
> libavformat/hlsenc.c | 48 +---
> 2 files changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 9d9ca31..8ec48c2 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -854,6 +854,9 @@ ffmpeg -re -i in.ts -f hls -master_pl_name master.m3u8 \
> This example creates HLS master playlist with name master.m3u8 and keep
> publishing it repeatedly every after 30 segments i.e. every after 60s.
> 
> +@item http_persistent
> +Use persistent HTTP connections. Applicable only for HTTP output.
> +
> @end table
> 
> @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 6997a5c..d5c732f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -45,6 +45,7 @@
> 
> #include "avformat.h"
> #include "avio_internal.h"
> +#include "http.h"
> #include "internal.h"
> #include "os_support.h"
> 
> @@ -205,6 +206,7 @@ typedef struct HLSContext {
> char *var_stream_map; /* user specified variant stream map string */
> char *master_pl_name;
> unsigned int master_publish_rate;
> +int http_persistent;
> } HLSContext;
> 
> static int get_int_from_double(double val)
> @@ -245,10 +247,38 @@ static int mkdir_p(const char *path) {
> return ret;
> }
> 
> +static int is_http_proto(char *filename) {
> +const char *proto = avio_find_protocol_name(filename);
> +return proto ? (!av_strcasecmp(proto, "http") || !av_strcasecmp(proto, 
> "https")) : 0;
> +}
> +
> +static int hlsenc_io_open(AVFormatContext *s, AVIOContext **pb, char 
> *filename,
> +  AVDictionary **options) {
> +HLSContext *hls = s->priv_data;
> +int http_base_proto = is_http_proto(filename);
> +int err;
> +if (!*pb || !http_base_proto || !hls->http_persistent) {
> +err = s->io_open(s, pb, filename, AVIO_FLAG_WRITE, options);
> +} else {
> +URLContext *http_url_context = ffio_geturlcontext(*pb);
> +av_assert0(http_url_context);
> +err = ff_http_do_new_request(http_url_context, filename);
> +}
> +return err;
> +}
> +
> +static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
> *filename) {
> +HLSContext *hls = s->priv_data;
> +int http_base_proto = is_http_proto(filename);
> +
> +if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
> hls->encrypt) {
> +ff_format_io_close(s, pb);
> +}
> +}
> +
> static void set_http_options(AVFormatContext *s, AVDictionary **options, 
> HLSContext *c)
> {
> -const char *proto = avio_find_protocol_name(s->filename);
> -int http_base_proto = proto ? (!av_strcasecmp(proto, "http") || 
> !av_strcasecmp(proto, "https")) : 0;
> +int http_base_proto = is_http_proto(s->filename);
> 
> if (c->method) {
> av_dict_set(options, "method", c->method, 0);
> @@ -258,6 +288,8 @@ static void set_http_options(AVFormatContext *s, 
> AVDictionary **options, HLSCont
> }
> if (c->user_agent)
> av_dict_set(options, "user_agent", c->user_agent, 0);
> +if (c->http_persistent)
> +av_dict_set_int(options, "multiple_requests", 1, 0);
> 
> }
> 
> @@ -1437,17 +1469,17 @@ static int hls_start(AVFormatContext *s, 
> VariantStream *vs)
> err = AVERROR(ENOMEM);
> goto fail;
> }
> -err = s->io_open(s, &oc->pb, filename, AVIO_FLAG_WRITE, &options);
> +err = hlsenc_io_open(s, &oc->pb, filename, &options);
> av_free(filename);
> av_dict_free(&options);
> if (err < 0)
> return err;
> } else
> -if ((err = s->io_open(s, &oc->pb, oc->filename, AVIO_FLAG_WRITE, 
> &options)) < 0)
> +if ((err = hlsenc_io_open(s, &oc->pb, oc->filename, &options)) < 0)
> goto fail;
> if (vs->vtt_basename) {
> set_http_options(s, &options, c);
> -if ((err = s->io_open(s, &vtt_oc->pb, vtt_oc->filename, 
> AVIO_FLAG_WRITE, &options)) < 0)
> +if ((err = hlsenc_io_open(s, &vtt_oc->pb, vtt_oc->filename, 
> &options)) < 0)
> goto fail;
> }
> av_dict_free(&options);
> @@ -2165,11 +2197,12 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> avio_open_dyn_buf(&oc->pb);
> vs->packets_written = 0;
> ff_format_io_close(s, &vs->out);
> +hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
> } else {
> -ff_format_io_close(s, &oc->pb);
> +hlsenc_io_close(s, &oc->pb, oc->filename);
> }
> if (vs->vtt_avf) {
> -ff_format_io_close(s, &vs->vtt_avf->pb);
> +hlsenc_io_close(s, &vs->vtt_avf->pb, vs->vtt_avf->filename);
> }
> }
> if ((hls->flags & HLS_TEMP_FILE) && oc->filename[0]) {
> @@ -2355,6 +2388,7 @@ static const AVOption options[]

Re: [FFmpeg-devel] [PATCH v3 3/3] libavformat/hlsenc: Persistent HTTP connections supported as an option

[Jeyapal, Karthick]

On 11/29/17, 12:04 PM, "刘歧"  wrote:


>Patchset pushed!
Thanks a lot!

Regards,
Karthick
>
>
>Thanks



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