Re: [FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

[jkung]

Thanks;

TS file  http://www99.zippyshare.com/v/UwxzRccM/file.html
Error log attached.

I am using omxplayer to play this TS on Raspberry PI.

Selecting Audio track 1 - give funny noise 
Stream #0:4[0x3a2](zho): Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 
48000 Hz, 5.1, fltp

Selecting Audio track 2 - no problem.
  Stream #0:5[0x3a3]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 48000 
Hz, stereo, fltp


Thank you very much

Regards

Johnson Kung
Antechnic Engineering Pte Ltd
50 Ubi Avenue 3 #05-02 Frontier
S(408866)
Mobile: 9631-2875
Office: 6282-8690






-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Lou 
Logan
Sent: Thursday, September 28, 2017 10:30 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

On Wed, Sep 27, 2017, at 06:00 PM, jk...@antechnic.com wrote:
> I am sure I already registered but was always rejected from the list.

What message are you receiving?

Messages from non-subscribed users automatically go into a moderation queue, 
but I did not notice a message from you in the queue–there is a chance I may 
have missed it. Also, your email address is not listed as being subscribed to 
ffmpeg-user. However, I did not view the email logs to investigate further.
 
> Please advise how I can upload my sample TS

You can use something like Dropbox or Google Drive and then provide a link. If 
it's under 500k (actually that's the limit for the whole
message) you can attach it to your email message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] SPS unavailable in decode_picture_timing
[h264 @ 0x10e4100] non-existing PPS 0 referenced
[h264 @ 0x10e4100] decode_slice_header error
[h264 @ 0x10e4100] no frame!
[aac_latm @ 0x10e7c40] Number of bands (7) exceeds limit (3).
[aac_latm @ 0x10e7c40] element type mismatch 1 != 0
[aac_latm @ 0x10e7c40] element type mismatch 1 != 0
[aac_latm @ 0x10faba0] element type mismatch 1 != 0
[mpegts @ 0x10deee0] PES packet size mismatch
[mpegts @ 0x10deee0] PES packet size mismatch
[mpegts @ 0x10deee0] start time for stream 1 is not set in 
estimate_timings_from_pts
[mpegts @ 0x10deee0] start time for stream 2 is not set in 
estimate_timings_from_pts
[mpegts @ 0x10deee0] PES packet size mismatch
[mpegts @ 0x10deee0] PES packet size mismatch
[mpegts @ 0x10deee0] Could not find codec parameters for stream 3 (Unknown: 
none ([5][0][0][0] / 0x0005)): unknown codec
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, mpegts, from '1.TS':
  Duration: 00:01:49.70, start: 5.00, bitrate: 7867 kb/s
  Program 19
Stream #0:0[0x2d0]: Video: h264 (High) ([27][0][0][0] / 0x001B), 
yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50 tbr, 
90k tbn, 50 tbc
Stream #0:1[0x2e4](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:2[0x2e5](zho): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:3[0x30c]: Unknown: none ([5][0][0][0] / 0x0005)
Stream #0:4[0x3a2](zho): Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 
48000 Hz, 5.1, fltp
Stream #0:5[0x3a3]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011), 
48000 Hz, stereo, fltp
Video codec omx-h264 width 1920 height 1080 profile 100 fps 50.00
Audio codec aac

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Jeyapal, Karthick]

>Sorry, still not quite there... Here are some further comments:
Thanks for your comments and patience. Please find the updated patch attached, 
with all the comments taken.
Also, I have rebased this patch with the latest ffmpeg, as avcodec version 
numbers have changed in the meantime.

>Also please test your patches with real CC data before posting them, I
>know it is tedious work with all the patch iterations, but I do the same
>with teletext.
Sorry about that. I did test that patch with real CC data and corrected the 
inverted checks, but I forgot and attached the older patch in a hurry.
Sorry for wasting your time there.

>Fingers crossed for the next patch version :)
Well, me too :)

Thanks and Regards,
Karthick


0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
Description: 0003-avdevice-decklink_dec-Added-Closed-caption-decode-fr.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

[Lou Logan]

On Wed, Sep 27, 2017, at 06:00 PM, jk...@antechnic.com wrote:
> I am sure I already registered but was always rejected from the list.

What message are you receiving?

Messages from non-subscribed users automatically go into a moderation
queue, but I did not notice a message from you in the queue–there is a
chance I may have missed it. Also, your email address is not listed as
being subscribed to ffmpeg-user. However, I did not view the email logs
to investigate further.
 
> Please advise how I can upload my sample TS

You can use something like Dropbox or Google Drive and then provide a
link. If it's under 500k (actually that's the limit for the whole
message) you can attach it to your email message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

[jkung]

I am sure I already registered but was always rejected from the list.

Please advise how I can upload my sample TS

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
Eugen Hoyos
Sent: Wednesday, September 27, 2017 6:37 PM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] ffmpeg have program decoding ACC ltam audo stream

2017-09-27 6:41 GMT+02:00  :

> Seems ffmpeg had problem decoding the audio stream - ACC ltam 5.1
>
> Appreciate your advise

Please post your question on the user mailing list and provide a sample input 
file.

See also http://ffmpeg.org/contact.html#MailingLists

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 v3] avcodec/hevc_sei: Support HEVC paired fields.

[Brian Matherly]

On 9/26/2017 8:38 PM, Michael Niedermayer wrote:

On Sun, Sep 24, 2017 at 10:13:11PM -0500, Brian Matherly wrote:

From: Brian Matherly 

Correctly set the interlaced_frame and top_field_first fields when pic_struct
indicates paired fields.
---
  libavcodec/hevc_sei.c |   4 +-
  tests/fate/hevc.mak   |   6 +-
  tests/ref/fate/hevc-paired-fields | 120 ++
  3 files changed, 127 insertions(+), 3 deletions(-)
  create mode 100644 tests/ref/fate/hevc-paired-fields

the test seems to fail on big endian: (mips qemu)

@@ -14,7 +14,7 @@
  pkt_size=229528
  width=1920
  height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
  sample_aspect_ratio=1:1
  pict_type=I
  coded_picture_number=0
@@ -44,7 +44,7 @@
  pkt_size=95954
  width=1920
  height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
  sample_aspect_ratio=1:1
  pict_type=B
  coded_picture_number=0
@@ -74,7 +74,7 @@
  pkt_size=114837
  width=1920
  height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
  sample_aspect_ratio=1:1
  pict_type=B
  coded_picture_number=0
@@ -104,7 +104,7 @@
  pkt_size=85098
  width=1920
  height=540
-pix_fmt=yuv422p10le
+pix_fmt=yuv422p10be
  sample_aspect_ratio=1:1
  pict_type=B
  coded_picture_number=0

[...]


The pix_fmt is not consequential to the test. In fact, most of the 
fields are not related to the test. Patch V4 reduces the test to only 
the fields relevant to the paired fields feature of the sample.


Thanks,

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

[FFmpeg-devel] [PATCH v4] avcodec/hevc_sei: Support HEVC paired fields.

[Brian Matherly]

From: Brian Matherly 

Correctly set the interlaced_frame and top_field_first fields when pic_struct
indicates paired fields.
---
 libavcodec/hevc_sei.c |  4 ++--
 tests/fate/hevc.mak   |  6 +-
 tests/ref/fate/hevc-paired-fields | 16 
 3 files changed, 23 insertions(+), 3 deletions(-)
 create mode 100644 tests/ref/fate/hevc-paired-fields

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index cd55d50..d0f9966 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -137,10 +137,10 @@ static int decode_nal_sei_pic_timing(HEVCSEIContext *s, 
GetBitContext *gb, const
 if (sps->vui.frame_field_info_present_flag) {
 int pic_struct = get_bits(gb, 4);
 h->picture_struct = AV_PICTURE_STRUCTURE_UNKNOWN;
-if (pic_struct == 2) {
+if (pic_struct == 2 || pic_struct == 10 || pic_struct == 12) {
 av_log(logctx, AV_LOG_DEBUG, "BOTTOM Field\n");
 h->picture_struct = AV_PICTURE_STRUCTURE_BOTTOM_FIELD;
-} else if (pic_struct == 1) {
+} else if (pic_struct == 1 || pic_struct == 9 || pic_struct == 11) {
 av_log(logctx, AV_LOG_DEBUG, "TOP Field\n");
 h->picture_struct = AV_PICTURE_STRUCTURE_TOP_FIELD;
 }
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index d23d1ba..140fa2a 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -225,6 +225,9 @@ $(foreach N,$(HEVC_SAMPLES_444_12BIT),$(eval $(call 
FATE_HEVC_TEST_444_12BIT,$(N
 fate-hevc-paramchange-yuv420p-yuv420p10: CMD = framecrc -vsync 0 -i 
$(TARGET_SAMPLES)/hevc/paramchange_yuv420p_yuv420p10.hevc -sws_flags 
area+accurate_rnd+bitexact
 FATE_HEVC += fate-hevc-paramchange-yuv420p-yuv420p10
 
+fate-hevc-paired-fields: CMD = probeframes -show_entries 
frame=interlaced_frame,top_field_first $(TARGET_SAMPLES)/hevc/paired_fields.hevc
+FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-paired-fields
+
 tests/data/hevc-mp4.mov: TAG = GEN
 tests/data/hevc-mp4.mov: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
@@ -244,5 +247,6 @@ FATE_HEVC-$(call DEMDEC, MOV, HEVC) += 
fate-hevc-extradata-reload
 fate-hevc-extradata-reload: CMD = framemd5 -i 
$(TARGET_SAMPLES)/hevc/extradata-reload-multi-stsd.mov -sws_flags bitexact
 
 FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes)
+FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes)
 
-fate-hevc: $(FATE_HEVC-yes)
+fate-hevc: $(FATE_HEVC-yes) $(FATE_HEVC_FFPROBE-yes)
diff --git a/tests/ref/fate/hevc-paired-fields 
b/tests/ref/fate/hevc-paired-fields
new file mode 100644
index 000..f2223e7
--- /dev/null
+++ b/tests/ref/fate/hevc-paired-fields
@@ -0,0 +1,16 @@
+[FRAME]
+interlaced_frame=1
+top_field_first=1
+[/FRAME]
+[FRAME]
+interlaced_frame=1
+top_field_first=0
+[/FRAME]
+[FRAME]
+interlaced_frame=1
+top_field_first=1
+[/FRAME]
+[FRAME]
+interlaced_frame=1
+top_field_first=0
+[/FRAME]
-- 
2.7.4

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

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[wm4]

On Wed, 27 Sep 2017 22:26:48 -0300
James Almer  wrote:

> On 9/27/2017 9:59 PM, wm4 wrote:
> > On Wed, 27 Sep 2017 21:37:54 -0300
> > James Almer  wrote:
> >   
> >>> API users can rely on it. So you better make sure that can't break.
> >>> Other aspects don't really matter.
> >>
> >> What do you mean with this? Do i apply it or not? The function will
> >> return a value based on runtime cpuflags. The value is guaranteed to be
> >> correct, but how the user uses it is beyond our control.  
> > 
> > If the user uses the return value of the API to align pointers, and
> > then passes these pointers to ffmpeg functions that process data, they
> > must not crash or exhibit low performance. Or in other words, the
> > alignment returned by the function must be high enough. At least as
> > long as the global CPU flags are not changed afterwards.
> > 
> > So if this is correct, I see no reason not to apply this patch?
> > 
> > I'm not sure if your question was only about this patch, or potentially
> > later Libav commits that need to be merged.  
> 
> Yes, i mentioned there's a commit after this one that makes use of the
> function internally, which based on the above (global CPU flags can be
> changed by the user), should probably not be applied in favor of keeping
> the current safe hardcoded STRIDE value.

I'd argue we should use this commit. But it doesn't matter too much,
since it doesn't affect the API. But only if the API function is
correct. If the API function were to become buggy because FFmpeg does
something else internally, the outcome would be worse.

> My question was, since it will not be used by ffmpeg itself, does it
> make sense adding it? You argued that yes (users may have use for it),
> so I'll merge it.

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

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[James Almer]

On 9/27/2017 9:59 PM, wm4 wrote:
> On Wed, 27 Sep 2017 21:37:54 -0300
> James Almer  wrote:
> 
>>> API users can rely on it. So you better make sure that can't break.
>>> Other aspects don't really matter.  
>>
>> What do you mean with this? Do i apply it or not? The function will
>> return a value based on runtime cpuflags. The value is guaranteed to be
>> correct, but how the user uses it is beyond our control.
> 
> If the user uses the return value of the API to align pointers, and
> then passes these pointers to ffmpeg functions that process data, they
> must not crash or exhibit low performance. Or in other words, the
> alignment returned by the function must be high enough. At least as
> long as the global CPU flags are not changed afterwards.
> 
> So if this is correct, I see no reason not to apply this patch?
> 
> I'm not sure if your question was only about this patch, or potentially
> later Libav commits that need to be merged.

Yes, i mentioned there's a commit after this one that makes use of the
function internally, which based on the above (global CPU flags can be
changed by the user), should probably not be applied in favor of keeping
the current safe hardcoded STRIDE value.

My question was, since it will not be used by ffmpeg itself, does it
make sense adding it? You argued that yes (users may have use for it),
so I'll merge it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[wm4]

On Wed, 27 Sep 2017 21:37:54 -0300
James Almer  wrote:

> > API users can rely on it. So you better make sure that can't break.
> > Other aspects don't really matter.  
> 
> What do you mean with this? Do i apply it or not? The function will
> return a value based on runtime cpuflags. The value is guaranteed to be
> correct, but how the user uses it is beyond our control.

If the user uses the return value of the API to align pointers, and
then passes these pointers to ffmpeg functions that process data, they
must not crash or exhibit low performance. Or in other words, the
alignment returned by the function must be high enough. At least as
long as the global CPU flags are not changed afterwards.

So if this is correct, I see no reason not to apply this patch?

I'm not sure if your question was only about this patch, or potentially
later Libav commits that need to be merged.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[James Almer]

On 9/27/2017 9:19 PM, wm4 wrote:
> On Wed, 27 Sep 2017 21:15:39 -0300
> James Almer  wrote:
> 
>> On 9/4/2017 5:53 PM, Michael Niedermayer wrote:
>>> On Mon, Sep 04, 2017 at 09:27:32PM +0200, wm4 wrote:  
 On Mon, 4 Sep 2017 21:18:35 +0200
 Michael Niedermayer  wrote:
  
> On Sat, Sep 02, 2017 at 09:47:38PM -0300, James Almer wrote:  
>> From: Anton Khirnov 
>>
>> (cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
>> Signed-off-by: James Almer 
>> ---
>> This is (afaics) the last API introduced to libav before the major bump.
>>
>> Now checking all the x86 flags that would require aligment of 16 bytes
>> or more.
>>
>>  doc/APIchanges  |  3 +++
>>  libavutil/cpu.c | 35 +++
>>  libavutil/cpu.h | 13 +
>>  libavutil/version.h |  2 +-
>>  4 files changed, 52 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 4effbf9364..6a57c210a9 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>>  
>>  API changes, most recent first:
>>  
>> +2017-09-xx - xxx - lavu 55.75.100 / lavu 55.31.0 - cpu.h
>> +  Add av_cpu_max_align() for querying maximum required data alignment.
>> +
>>  2017-09-01 - xxx - lavf 57.81.100 - avio.h
>>Add avio_read_partial().
>>  
>> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> index a22da0fa8c..4f04da2460 100644
>> --- a/libavutil/cpu.c
>> +++ b/libavutil/cpu.c
>> @@ -16,9 +16,11 @@
>>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>> 02110-1301 USA
>>   */
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> +#include "attributes.h"
>>  #include "cpu.h"
>>  #include "cpu_internal.h"
>>  #include "config.h"
>> @@ -299,3 +301,36 @@ int av_cpu_count(void)
>>  
>>  return nb_cpus;
>>  }
>> +
>> +size_t av_cpu_max_align(void)
>> +{
>> +int av_unused flags = av_get_cpu_flags();
>> +
>> +#if ARCH_ARM || ARCH_AARCH64
>> +if (flags & AV_CPU_FLAG_NEON)
>> +return 16;
>> +#elif ARCH_PPC
>> +if (flags & AV_CPU_FLAG_ALTIVEC)
>> +return 16;
>> +#elif ARCH_X86
>> +if (flags & (AV_CPU_FLAG_AVX2 |
>> + AV_CPU_FLAG_AVX  |
>> + AV_CPU_FLAG_FMA4 |
>> + AV_CPU_FLAG_FMA3))
>> +return 32;
>> +if (flags & (AV_CPU_FLAG_XOP  |
>> + AV_CPU_FLAG_AESNI|
>> + AV_CPU_FLAG_SSE42|
>> + AV_CPU_FLAG_SSE4 |
>> + AV_CPU_FLAG_SSSE3|
>> + AV_CPU_FLAG_SSE3 |
>> + AV_CPU_FLAG_SSE2 |
>> + AV_CPU_FLAG_SSE  |
>> + AV_CPU_FLAG_AVXSLOW  |
>> + AV_CPU_FLAG_SSE3SLOW |
>> + AV_CPU_FLAG_SSE2SLOW))
>> +return 16;
>> +#endif
>> +
>> +return 8;
>> +}
>> diff --git a/libavutil/cpu.h b/libavutil/cpu.h
>> index de05593446..9e5d40affe 100644
>> --- a/libavutil/cpu.h
>> +++ b/libavutil/cpu.h
>> @@ -21,6 +21,8 @@
>>  #ifndef AVUTIL_CPU_H
>>  #define AVUTIL_CPU_H
>>  
>> +#include 
>> +
>>  #include "attributes.h"
>>  
>>  #define AV_CPU_FLAG_FORCE0x8000 /* force usage of selected 
>> flags (OR) */
>
>  
>> @@ -113,4 +115,15 @@ int av_parse_cpu_caps(unsigned *flags, const char 
>> *s);
>>   */
>>  int av_cpu_count(void);
>>  
>> +/**
>> + * Get the maximum data alignment that may be required by FFmpeg.
>> + *
>> + * Note that this is affected by the build configuration and the CPU 
>> flags mask,
>> + * so e.g. if the CPU supports AVX, but libavutil has been built with
>> + * --disable-avx or the AV_CPU_FLAG_AVX flag has been disabled through
>> + *  av_set_cpu_flags_mask(), then this function will behave as if AVX 
>> is not
>> + *  present.
>> + */
>> +size_t av_cpu_max_align(void);
>
> This might interact badly with runtime cpu flags/mask changes
>
> If its used to choose the alignment for allocated frames and
> after some are allocated the cpu flags are changed there could be
> still frames in queues that may not have sufficient alignment for the
> new flags  

 There's no such thing as runtime CPU flag changes.  
>>>
>>> We even have an API to change the cpu flags at runtime.
>>>
>>> av_set_cpu_flags_mask() and av_force_cpu_flags()
>>>
>>> There is no restriction in the API on when they can be called.
>>>
>>> you can call av_force_cpu_flags(0) then open a decoder then call
>>> av_force_cpu_flags(AV_CPU_FLAG_MMX|AV_CPU_FLA

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[wm4]

On Wed, 27 Sep 2017 21:15:39 -0300
James Almer  wrote:

> On 9/4/2017 5:53 PM, Michael Niedermayer wrote:
> > On Mon, Sep 04, 2017 at 09:27:32PM +0200, wm4 wrote:  
> >> On Mon, 4 Sep 2017 21:18:35 +0200
> >> Michael Niedermayer  wrote:
> >>  
> >>> On Sat, Sep 02, 2017 at 09:47:38PM -0300, James Almer wrote:  
>  From: Anton Khirnov 
> 
>  (cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
>  Signed-off-by: James Almer 
>  ---
>  This is (afaics) the last API introduced to libav before the major bump.
> 
>  Now checking all the x86 flags that would require aligment of 16 bytes
>  or more.
> 
>   doc/APIchanges  |  3 +++
>   libavutil/cpu.c | 35 +++
>   libavutil/cpu.h | 13 +
>   libavutil/version.h |  2 +-
>   4 files changed, 52 insertions(+), 1 deletion(-)
> 
>  diff --git a/doc/APIchanges b/doc/APIchanges
>  index 4effbf9364..6a57c210a9 100644
>  --- a/doc/APIchanges
>  +++ b/doc/APIchanges
>  @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>   
>   API changes, most recent first:
>   
>  +2017-09-xx - xxx - lavu 55.75.100 / lavu 55.31.0 - cpu.h
>  +  Add av_cpu_max_align() for querying maximum required data alignment.
>  +
>   2017-09-01 - xxx - lavf 57.81.100 - avio.h
> Add avio_read_partial().
>   
>  diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>  index a22da0fa8c..4f04da2460 100644
>  --- a/libavutil/cpu.c
>  +++ b/libavutil/cpu.c
>  @@ -16,9 +16,11 @@
>    * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
>  02110-1301 USA
>    */
>   
>  +#include 
>   #include 
>   #include 
>   
>  +#include "attributes.h"
>   #include "cpu.h"
>   #include "cpu_internal.h"
>   #include "config.h"
>  @@ -299,3 +301,36 @@ int av_cpu_count(void)
>   
>   return nb_cpus;
>   }
>  +
>  +size_t av_cpu_max_align(void)
>  +{
>  +int av_unused flags = av_get_cpu_flags();
>  +
>  +#if ARCH_ARM || ARCH_AARCH64
>  +if (flags & AV_CPU_FLAG_NEON)
>  +return 16;
>  +#elif ARCH_PPC
>  +if (flags & AV_CPU_FLAG_ALTIVEC)
>  +return 16;
>  +#elif ARCH_X86
>  +if (flags & (AV_CPU_FLAG_AVX2 |
>  + AV_CPU_FLAG_AVX  |
>  + AV_CPU_FLAG_FMA4 |
>  + AV_CPU_FLAG_FMA3))
>  +return 32;
>  +if (flags & (AV_CPU_FLAG_XOP  |
>  + AV_CPU_FLAG_AESNI|
>  + AV_CPU_FLAG_SSE42|
>  + AV_CPU_FLAG_SSE4 |
>  + AV_CPU_FLAG_SSSE3|
>  + AV_CPU_FLAG_SSE3 |
>  + AV_CPU_FLAG_SSE2 |
>  + AV_CPU_FLAG_SSE  |
>  + AV_CPU_FLAG_AVXSLOW  |
>  + AV_CPU_FLAG_SSE3SLOW |
>  + AV_CPU_FLAG_SSE2SLOW))
>  +return 16;
>  +#endif
>  +
>  +return 8;
>  +}
>  diff --git a/libavutil/cpu.h b/libavutil/cpu.h
>  index de05593446..9e5d40affe 100644
>  --- a/libavutil/cpu.h
>  +++ b/libavutil/cpu.h
>  @@ -21,6 +21,8 @@
>   #ifndef AVUTIL_CPU_H
>   #define AVUTIL_CPU_H
>   
>  +#include 
>  +
>   #include "attributes.h"
>   
>   #define AV_CPU_FLAG_FORCE0x8000 /* force usage of selected 
>  flags (OR) */
> >>>
> >>>  
>  @@ -113,4 +115,15 @@ int av_parse_cpu_caps(unsigned *flags, const char 
>  *s);
>    */
>   int av_cpu_count(void);
>   
>  +/**
>  + * Get the maximum data alignment that may be required by FFmpeg.
>  + *
>  + * Note that this is affected by the build configuration and the CPU 
>  flags mask,
>  + * so e.g. if the CPU supports AVX, but libavutil has been built with
>  + * --disable-avx or the AV_CPU_FLAG_AVX flag has been disabled through
>  + *  av_set_cpu_flags_mask(), then this function will behave as if AVX 
>  is not
>  + *  present.
>  + */
>  +size_t av_cpu_max_align(void);
> >>>
> >>> This might interact badly with runtime cpu flags/mask changes
> >>>
> >>> If its used to choose the alignment for allocated frames and
> >>> after some are allocated the cpu flags are changed there could be
> >>> still frames in queues that may not have sufficient alignment for the
> >>> new flags  
> >>
> >> There's no such thing as runtime CPU flag changes.  
> > 
> > We even have an API to change the cpu flags at runtime.
> > 
> > av_set_cpu_flags_mask() and av_force_cpu_flags()
> > 
> > There is no restriction in the API on when they can be called.
> > 
> > you can call av_force_cpu_flags(0) then open a decoder then call
> > av_force_cpu_flags(AV_CPU_FLAG_MMX|AV_CPU_FLAG_SSE)
> > then open a filter or enc

Re: [FFmpeg-devel] [PATCH v2] cpu: add a function for querying maximum required data alignment

[James Almer]

On 9/4/2017 5:53 PM, Michael Niedermayer wrote:
> On Mon, Sep 04, 2017 at 09:27:32PM +0200, wm4 wrote:
>> On Mon, 4 Sep 2017 21:18:35 +0200
>> Michael Niedermayer  wrote:
>>
>>> On Sat, Sep 02, 2017 at 09:47:38PM -0300, James Almer wrote:
 From: Anton Khirnov 

 (cherry picked from commit e6bff23f1e11aefb16a2b5d6ee72bf7469c5a66e)
 Signed-off-by: James Almer 
 ---
 This is (afaics) the last API introduced to libav before the major bump.

 Now checking all the x86 flags that would require aligment of 16 bytes
 or more.

  doc/APIchanges  |  3 +++
  libavutil/cpu.c | 35 +++
  libavutil/cpu.h | 13 +
  libavutil/version.h |  2 +-
  4 files changed, 52 insertions(+), 1 deletion(-)

 diff --git a/doc/APIchanges b/doc/APIchanges
 index 4effbf9364..6a57c210a9 100644
 --- a/doc/APIchanges
 +++ b/doc/APIchanges
 @@ -15,6 +15,9 @@ libavutil: 2015-08-28
  
  API changes, most recent first:
  
 +2017-09-xx - xxx - lavu 55.75.100 / lavu 55.31.0 - cpu.h
 +  Add av_cpu_max_align() for querying maximum required data alignment.
 +
  2017-09-01 - xxx - lavf 57.81.100 - avio.h
Add avio_read_partial().
  
 diff --git a/libavutil/cpu.c b/libavutil/cpu.c
 index a22da0fa8c..4f04da2460 100644
 --- a/libavutil/cpu.c
 +++ b/libavutil/cpu.c
 @@ -16,9 +16,11 @@
   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 
 02110-1301 USA
   */
  
 +#include 
  #include 
  #include 
  
 +#include "attributes.h"
  #include "cpu.h"
  #include "cpu_internal.h"
  #include "config.h"
 @@ -299,3 +301,36 @@ int av_cpu_count(void)
  
  return nb_cpus;
  }
 +
 +size_t av_cpu_max_align(void)
 +{
 +int av_unused flags = av_get_cpu_flags();
 +
 +#if ARCH_ARM || ARCH_AARCH64
 +if (flags & AV_CPU_FLAG_NEON)
 +return 16;
 +#elif ARCH_PPC
 +if (flags & AV_CPU_FLAG_ALTIVEC)
 +return 16;
 +#elif ARCH_X86
 +if (flags & (AV_CPU_FLAG_AVX2 |
 + AV_CPU_FLAG_AVX  |
 + AV_CPU_FLAG_FMA4 |
 + AV_CPU_FLAG_FMA3))
 +return 32;
 +if (flags & (AV_CPU_FLAG_XOP  |
 + AV_CPU_FLAG_AESNI|
 + AV_CPU_FLAG_SSE42|
 + AV_CPU_FLAG_SSE4 |
 + AV_CPU_FLAG_SSSE3|
 + AV_CPU_FLAG_SSE3 |
 + AV_CPU_FLAG_SSE2 |
 + AV_CPU_FLAG_SSE  |
 + AV_CPU_FLAG_AVXSLOW  |
 + AV_CPU_FLAG_SSE3SLOW |
 + AV_CPU_FLAG_SSE2SLOW))
 +return 16;
 +#endif
 +
 +return 8;
 +}
 diff --git a/libavutil/cpu.h b/libavutil/cpu.h
 index de05593446..9e5d40affe 100644
 --- a/libavutil/cpu.h
 +++ b/libavutil/cpu.h
 @@ -21,6 +21,8 @@
  #ifndef AVUTIL_CPU_H
  #define AVUTIL_CPU_H
  
 +#include 
 +
  #include "attributes.h"
  
  #define AV_CPU_FLAG_FORCE0x8000 /* force usage of selected flags 
 (OR) */  
>>>
>>>
 @@ -113,4 +115,15 @@ int av_parse_cpu_caps(unsigned *flags, const char *s);
   */
  int av_cpu_count(void);
  
 +/**
 + * Get the maximum data alignment that may be required by FFmpeg.
 + *
 + * Note that this is affected by the build configuration and the CPU 
 flags mask,
 + * so e.g. if the CPU supports AVX, but libavutil has been built with
 + * --disable-avx or the AV_CPU_FLAG_AVX flag has been disabled through
 + *  av_set_cpu_flags_mask(), then this function will behave as if AVX is 
 not
 + *  present.
 + */
 +size_t av_cpu_max_align(void);  
>>>
>>> This might interact badly with runtime cpu flags/mask changes
>>>
>>> If its used to choose the alignment for allocated frames and
>>> after some are allocated the cpu flags are changed there could be
>>> still frames in queues that may not have sufficient alignment for the
>>> new flags
>>
>> There's no such thing as runtime CPU flag changes.
> 
> We even have an API to change the cpu flags at runtime.
> 
> av_set_cpu_flags_mask() and av_force_cpu_flags()
> 
> There is no restriction in the API on when they can be called.
> 
> you can call av_force_cpu_flags(0) then open a decoder then call
> av_force_cpu_flags(AV_CPU_FLAG_MMX|AV_CPU_FLAG_SSE)
> then open a filter or encoder
> then run the code and it could crash as the allocated frames from
> earlier are not aligned enough for the 2nd filter or encoder
> 
> There also may be other scenarios where this can occur

Alright, I just arrived to this cherry pick during merges. So my
question is, do i apply it and skip the commit that makes use of it to
choose alignment within ffmpe

[FFmpeg-devel] [PATCH] doc: add mailing list faq

[Lou Logan]

Signed-off-by: Lou Logan 
---
 doc/Makefile  |   1 +
 doc/mailing-list-faq.texi | 204 ++
 2 files changed, 205 insertions(+)
 create mode 100644 doc/mailing-list-faq.texi

diff --git a/doc/Makefile b/doc/Makefile
index b670f0bd4c..9a4d225e65 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -24,6 +24,7 @@ HTMLPAGES   = $(AVPROGS-yes:%=doc/%.html) 
$(AVPROGS-yes:%=doc/%-all.html) $(COMP
   doc/fate.html \
   doc/general.html  \
   doc/git-howto.html\
+  doc/mailing-list-faq.html \
   doc/nut.html  \
   doc/platform.html \
 
diff --git a/doc/mailing-list-faq.texi b/doc/mailing-list-faq.texi
new file mode 100644
index 00..a047fdcd51
--- /dev/null
+++ b/doc/mailing-list-faq.texi
@@ -0,0 +1,204 @@
+\input texinfo @c -*- texinfo -*-
+@documentencoding UTF-8
+
+@settitle FFmpeg Mailing List FAQ
+@titlepage
+@center @titlefont{FFmpeg Mailing List FAQ}
+@end titlepage
+
+@top
+
+@contents
+
+@chapter General Questions
+
+@section What is a mailing list?
+
+A mailing list is not much different than emailing someone, but the
+main difference is that your message is received by everyone who
+subscribes to the list. It is somewhat like a forum but in email form.
+
+See the @url{https://lists.ffmpeg.org/pipermail/ffmpeg-user/, ffmpeg-user 
archives}
+for examples.
+
+@section What type of questions can I ask?
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/, ffmpeg-user}:
+For questions involving unscripted usage or compilation of the FFmpeg
+command-line tools (@command{ffmpeg}, @command{ffprobe}, @command{ffplay},
+@command{ffserver}).
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/libav-user/, libav-user}:
+For questions involving the FFmpeg libav* libraries (libavcodec,
+libavformat, libavfilter, etc).
+
+@url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel/, ffmpeg-devel}:
+Only for discussions involving the development of FFmpeg and for
+submitting patches. User questions should be asked at ffmpeg-user or
+libav-user.
+
+To report a bug see @url{https://ffmpeg.org/bugreports.html}.
+
+We cannot provide help for scripts and/or third-party tools.
+
+@section How do I ask a question or send a message to the mailing list?
+
+E-mail @email{ffmpeg-user@@ffmpeg.org}.
+
+If you are not subscribed to the mailing list then your question must be
+manually approved. Approval may take several days, but the wait is
+usually less. If you want the message to be sent with no delay then you
+must subscribe first.
+
+Please do not send a message, subscribe, and re-send the message: this
+results in duplicates, causes more work for the admins, and may lower
+your chance at getting an answer. However, you may do so if you first
+@ref{How do I delete my message in the moderation queue, delete your original 
message from the moderation queue}.
+
+@chapter Subscribing / Unsubscribing
+
+@section Do I need to subscribe?
+
+No.
+
+However, you will not directly receive replies unless you ask to be CCd
+in your message, but on occasion users will forget to CC you when
+replying. Alternatively, you can view and reply to messages via the
+@ref{Where are the archives, archives}.
+
+@section How do I subscribe?
+
+Email @email{ffmpeg-user-request@@ffmpeg.org} with the subject
+@emph{subscribe}.
+
+Or visit the @url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/, 
ffmpeg-user mailing list info page}
+and refer to the @emph{Subscribing to ffmpeg-user} section.
+
+The process is the same for the other mailing lists.
+
+@section How do I unsubscribe?
+
+Email @email{ffmpeg-user-request@@ffmpeg.org} with subject @emph{unsubscribe}.
+
+Or visit the @url{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-user/, 
ffmpeg-user mailing list info page},
+scroll to bottom of page, enter your email address in the box, and click
+the @emph{Unsubscribe or edit options} button.
+
+The process is the same for the other mailing lists.
+
+Please avoid asking a mail admin to unsubscribe you: there should be no
+reason to do so.
+
+@anchor{How do I delete my message in the moderation queue}
+@section How do I delete my message in the moderation queue?
+
+You should have received an email with the subject @emph{Your message to 
ffmpeg-user awaits moderator approval}.
+A link is in the message that will allow you to delete your message
+unless a mail admin already approved or rejected it.
+
+@chapter Archives
+
+@anchor{Where are the archives}
+@section Where are the archives?
+
+See the @emph{Archives} section on the @url{https://ffmpeg.org/contact.html, 
FFmpeg Contact}
+page for links to all FFmpeg mailing list archives.
+
+Note that the archives are split by month. Di

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[Aman Gupta]

On Wed, Sep 27, 2017 at 4:13 PM, wm4  wrote:

> On Wed, 27 Sep 2017 19:45:23 -0300
> James Almer  wrote:
>
> > On 9/27/2017 7:19 PM, Aman Gupta wrote:
> > > From: Aman Gupta 
> > >
> > > additional changes to hevc patchset, as suggested on-list
> > >
> > > if these look fine, I will squash into previous patchset and push it to
> > > master.
> > > ---
> > >  libavcodec/videotoolbox.c | 27 +--
> > >  1 file changed, 9 insertions(+), 18 deletions(-)
> > >
> > > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > > index 078174cc61..c96200cbdb 100644
> > > --- a/libavcodec/videotoolbox.c
> > > +++ b/libavcodec/videotoolbox.c
> > > @@ -165,10 +165,8 @@ CFDataRef 
> > > ff_videotoolbox_hvcc_extradata_create(AVCodecContext
> *avctx)
> > >   ptlc.non_packed_constraint_flag << 5 |
> > >   ptlc.frame_only_constraint_flag << 4);
> > >  AV_W8(p + 7, 0);
> > > -AV_W8(p + 8, 0);
> > > -AV_W8(p + 9, 0);
> > > -AV_W8(p + 10, 0);
> > > -AV_W8(p + 11, 0);
> > > +AV_WB16(p + 8, 0);
> > > +AV_WB16(p + 10, 0);
> >
> > AV_WB32(p + 8, 0)
> >
> > or even AV_WN32(p + 8, 0) since it's 0 and endianness doesn't matter.
>
> IMO it should reflect whatever bitstream elements these are. Ideally,
> we'd have comments about what each element is too.
>

There is already a comment in this section. It's supposed to be 48bits of
flags, but the spec has 44 of those bits defined as 'reserved zero bits'.

/* unsigned int(48) general_constraint_indicator_flags; */
AV_W8(p + 6, ptlc.progressive_source_flag<< 7 |
   ptlc.interlaced_source_flag << 6 |
   ptlc.non_packed_constraint_flag << 5 |
   ptlc.frame_only_constraint_flag << 4);
AV_W8(p + 7, 0);
AV_WN32(p + 8, 0);

In hvcc_write (lavf/hevc.c), libavformat uses:

/* unsigned int(48) general_constraint_indicator_flags; */
avio_wb32(pb, hvcc->general_constraint_indicator_flags >> 16);
avio_wb16(pb, hvcc->general_constraint_indicator_flags);

But the PTL parsing code in libavcodec defines the flags individually.
See decode_profile_tier_level (lavc/hevc_ps.c):

ptl->progressive_source_flag= get_bits1(gb);
ptl->interlaced_source_flag = get_bits1(gb);
ptl->non_packed_constraint_flag = get_bits1(gb);
ptl->frame_only_constraint_flag = get_bits1(gb);

skip_bits(gb, 16); // XXX_reserved_zero_44bits[0..15]
skip_bits(gb, 16); // XXX_reserved_zero_44bits[16..31]
skip_bits(gb, 12); // XXX_reserved_zero_44bits[32..43]

Aman


> ___
> 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] libavformat/nutenc.c: Use ffv1 as default video encoder for NUT muxing

[Leo Izen]

---
 libavformat/nutenc.c|  2 +-
 tests/ref/lavf/nut  |  6 +++---
 tests/ref/seek/lavf-nut | 54 -
 3 files changed, 31 insertions(+), 31 deletions(-)

diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index a92ff55c01..6e96626ff0 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -1221,7 +1221,7 @@ AVOutputFormat ff_nut_muxer = {
 .priv_data_size = sizeof(NUTContext),
 .audio_codec= CONFIG_LIBVORBIS ? AV_CODEC_ID_VORBIS :
   CONFIG_LIBMP3LAME ? AV_CODEC_ID_MP3 : AV_CODEC_ID_MP2,
-.video_codec= AV_CODEC_ID_MPEG4,
+.video_codec= AV_CODEC_ID_FFV1,
 .write_header   = nut_write_header,
 .write_packet   = nut_write_packet,
 .write_trailer  = nut_write_trailer,
diff --git a/tests/ref/lavf/nut b/tests/ref/lavf/nut
index 1c3d7107da..ea2f89124d 100644
--- a/tests/ref/lavf/nut
+++ b/tests/ref/lavf/nut
@@ -1,3 +1,3 @@
-424e8037d7b6f3d3c09cf76bf06a63cb *./tests/data/lavf/lavf.nut
-319958 ./tests/data/lavf/lavf.nut
-./tests/data/lavf/lavf.nut CRC=0xec6c3c68
+cb603de6d9dce6eccef210f8b73980e5 *./tests/data/lavf/lavf.nut
+1353826 ./tests/data/lavf/lavf.nut
+./tests/data/lavf/lavf.nut CRC=0x233df7f5
diff --git a/tests/ref/seek/lavf-nut b/tests/ref/seek/lavf-nut
index b2da52629b..d2191a6efa 100644
--- a/tests/ref/seek/lavf-nut
+++ b/tests/ref/seek/lavf-nut
@@ -1,53 +1,53 @@
-ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:395 size:   
208
+ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:364 size:   
208
 ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:623 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:592 size: 
55646
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st: 0 flags:0  ts: 0.788340
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st: 0 flags:1  ts:-0.317500
-ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:623 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:592 size: 
55646
 ret: 0 st: 1 flags:0  ts: 2.576667
-ret: 0 st: 1 flags:1 dts: 0.862041 pts: 0.862041 pos: 271315 size:   
209
+ret: 0 st: 1 flags:1 dts: 0.940408 pts: 0.940408 pos:1297077 size:   
209
 ret: 0 st: 1 flags:1  ts: 1.470839
-ret: 0 st: 1 flags:1 dts: 0.862041 pts: 0.862041 pos: 271315 size:   
209
+ret: 0 st: 1 flags:1 dts: 0.940408 pts: 0.940408 pos:1297077 size:   
209
 ret: 0 st:-1 flags:0  ts: 0.365002
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 650696 size: 
54610
 ret: 0 st:-1 flags:1  ts:-0.740831
-ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:623 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:592 size: 
55646
 ret: 0 st: 0 flags:0  ts: 2.153340
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st: 0 flags:1  ts: 1.047500
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st: 1 flags:0  ts:-0.058322
-ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:395 size:   
208
+ret: 0 st: 1 flags:1 dts: 0.00 pts: 0.00 pos:364 size:   
208
 ret: 0 st: 1 flags:1  ts: 2.835828
-ret: 0 st: 1 flags:1 dts: 0.862041 pts: 0.862041 pos: 271315 size:   
209
+ret: 0 st: 1 flags:1 dts: 0.940408 pts: 0.940408 pos:1297077 size:   
209
 ret: 0 st:-1 flags:0  ts: 1.730004
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st:-1 flags:1  ts: 0.624171
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 650696 size: 
54610
 ret: 0 st: 0 flags:0  ts:-0.481660
-ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:623 size: 
27837
+ret: 0 st: 0 flags:1 dts: 0.010918 pts: 0.010918 pos:592 size: 
55646
 ret: 0 st: 0 flags:1  ts: 2.412500
-ret: 0 st: 0 flags:1 dts: 0.490918 pts: 0.490918 pos: 146490 size: 
27925
+ret: 0 st: 0 flags:1 dts: 0.970918 pts: 0.970918 pos:1297517 size: 
55895
 ret: 0 st: 1 flags:0  ts: 1.306667
-ret: 0 s

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[James Almer]

On 9/27/2017 8:11 PM, wm4 wrote:
> On Wed, 27 Sep 2017 19:52:13 -0300
> James Almer  wrote:
> 
>>> +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
>>> +enum { kCMVideoCodecType_HEVC = 'hvc1' };
>>> +#endif  
>>
>> The correct thing to do is adding kCMVideoCodecType_HEVC to
>> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
>> that don't support it since, i assume, no computer with MacOS 10.8 will
>> be able to play hevc videos anyway.
> 
> SDK version != OS you build on != target machine
> 
> So this has some justification.

Neither is the case for dxva2 hevc and vp9, yet it's done like i
mentioned above.
Of course, those two require an entire header and not a single enum
value, so it probably explains the decision to make them dependencies.

I'm not going to block the patch for this, so implement it however you
prefer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[wm4]

On Wed, 27 Sep 2017 19:45:23 -0300
James Almer  wrote:

> On 9/27/2017 7:19 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> > 
> > additional changes to hevc patchset, as suggested on-list
> > 
> > if these look fine, I will squash into previous patchset and push it to
> > master.
> > ---
> >  libavcodec/videotoolbox.c | 27 +--
> >  1 file changed, 9 insertions(+), 18 deletions(-)
> > 
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index 078174cc61..c96200cbdb 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -165,10 +165,8 @@ CFDataRef 
> > ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
> >   ptlc.non_packed_constraint_flag << 5 |
> >   ptlc.frame_only_constraint_flag << 4);
> >  AV_W8(p + 7, 0);
> > -AV_W8(p + 8, 0);
> > -AV_W8(p + 9, 0);
> > -AV_W8(p + 10, 0);
> > -AV_W8(p + 11, 0);
> > +AV_WB16(p + 8, 0);
> > +AV_WB16(p + 10, 0);  
> 
> AV_WB32(p + 8, 0)
> 
> or even AV_WN32(p + 8, 0) since it's 0 and endianness doesn't matter.

IMO it should reflect whatever bitstream elements these are. Ideally,
we'd have comments about what each element is too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[wm4]

On Wed, 27 Sep 2017 19:52:13 -0300
James Almer  wrote:

> > +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> > +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> > +#endif  
> 
> The correct thing to do is adding kCMVideoCodecType_HEVC to
> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
> that don't support it since, i assume, no computer with MacOS 10.8 will
> be able to play hevc videos anyway.

SDK version != OS you build on != target machine

So this has some justification.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] prores: Always assume limited range

[Kieran O Leary]

On Wed, Sep 27, 2017 at 10:28 PM, Vittorio Giovara
 wrote:
> As defined by the spcifications

Is this the paywalled SMPTE spec? I don't see any mention of it in the
openly available whitepaper,
https://images.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[Aman Gupta]

On Wed, Sep 27, 2017 at 3:52 PM, James Almer  wrote:

> On 9/27/2017 7:19 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  configure | 5 -
> >  libavcodec/videotoolbox.c | 4 
> >  2 files changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index d353e9d824..aae23bf38f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
> >
> >  TYPES_LIST="
> >  CONDITION_VARIABLE_Ptr
> > +kCMVideoCodecType_HEVC
>
> Remove this line and read below.
>
> >  socklen_t
> >  struct_addrinfo
> >  struct_group_source_req
> > @@ -5809,8 +5810,10 @@ enabled avfoundation && {
> >  check_lib avfoundation CoreGraphics/CoreGraphics.h
>  CGGetActiveDisplayList "-framework CoreGraphics" ||
> >  check_lib avfoundation ApplicationServices/ApplicationServices.h
> CGGetActiveDisplayList "-framework ApplicationServices"; }
> >
> > -enabled videotoolbox &&
> > +enabled videotoolbox && {
> >  check_lib coreservices CoreServices/CoreServices.h
> UTGetOSTypeFromString "-framework CoreServices"
> > +check_func_headers CoreMedia/CMFormatDescription.h
> kCMVideoCodecType_HEVC "-framework CoreMedia"
>
> Look how DXVA_PicParams_HEVC is checked and try to do the same instead.
>

I don't think check_type will work because kCMVideoCodecType_HEVC is
defined as an enum.


>
> > +}
> >
> >  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> >
> > diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> > index c96200cbdb..e62452c078 100644
> > --- a/libavcodec/videotoolbox.c
> > +++ b/libavcodec/videotoolbox.c
> > @@ -40,6 +40,10 @@
> >  #  define 
> > kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
> >  #endif
> >
> > +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> > +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> > +#endif
>
> The correct thing to do is adding kCMVideoCodecType_HEVC to
> hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
> that don't support it since, i assume, no computer with MacOS 10.8 will
> be able to play hevc videos anyway.
>

kCMVideoCodecType_HEVC is defined on 10.11 and 10.12, even though those
machines can't play hevc either. I don't think it should matter what mac
version you built ffmpeg on, only whether or not the machine where the
binary is being executed supports HEVC.

videotoolbox.c and videotoolboxenc.c both use runtime stubs for various
constants
like kVTVideoEncoderSpecification_RequireHardwareAcceleratedVideoEncoder
which are not defined consistently across different versions of macOS, so I
followed a similar pattern here.

That said, I don't have a strong preference and can make hevc_videotoolbox
depend on the symbol instead. My main goal is to allow binaries compiled on
10.12 to use HEVC on 10.13, and that will work with either configuration.


>
> > +
> >  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
> >
> >  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
> >
>
> ___
> 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 v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[James Almer]

On 9/27/2017 7:19 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  configure | 5 -
>  libavcodec/videotoolbox.c | 4 
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index d353e9d824..aae23bf38f 100755
> --- a/configure
> +++ b/configure
> @@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
>  
>  TYPES_LIST="
>  CONDITION_VARIABLE_Ptr
> +kCMVideoCodecType_HEVC

Remove this line and read below.

>  socklen_t
>  struct_addrinfo
>  struct_group_source_req
> @@ -5809,8 +5810,10 @@ enabled avfoundation && {
>  check_lib avfoundation CoreGraphics/CoreGraphics.h   
> CGGetActiveDisplayList "-framework CoreGraphics" ||
>  check_lib avfoundation ApplicationServices/ApplicationServices.h 
> CGGetActiveDisplayList "-framework ApplicationServices"; }
>  
> -enabled videotoolbox &&
> +enabled videotoolbox && {
>  check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
> "-framework CoreServices"
> +check_func_headers CoreMedia/CMFormatDescription.h 
> kCMVideoCodecType_HEVC "-framework CoreMedia"

Look how DXVA_PicParams_HEVC is checked and try to do the same instead.

> +}
>  
>  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
>  
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index c96200cbdb..e62452c078 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -40,6 +40,10 @@
>  #  define 
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
>  #endif
>  
> +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> +#endif

The correct thing to do is adding kCMVideoCodecType_HEVC to
hevc_videotoolbox_hwaccel_deps in configure, and not forcing it on SDKs
that don't support it since, i assume, no computer with MacOS 10.8 will
be able to play hevc videos anyway.

> +
>  #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
>  
>  static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
> 

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[James Almer]

On 9/27/2017 7:19 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> additional changes to hevc patchset, as suggested on-list
> 
> if these look fine, I will squash into previous patchset and push it to
> master.
> ---
>  libavcodec/videotoolbox.c | 27 +--
>  1 file changed, 9 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 078174cc61..c96200cbdb 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -165,10 +165,8 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>   ptlc.non_packed_constraint_flag << 5 |
>   ptlc.frame_only_constraint_flag << 4);
>  AV_W8(p + 7, 0);
> -AV_W8(p + 8, 0);
> -AV_W8(p + 9, 0);
> -AV_W8(p + 10, 0);
> -AV_W8(p + 11, 0);
> +AV_WB16(p + 8, 0);
> +AV_WB16(p + 10, 0);

AV_WB32(p + 8, 0)

or even AV_WN32(p + 8, 0) since it's 0 and endianness doesn't matter.

>  
>  /* unsigned int(8) general_level_idc; */
>  AV_W8(p + 12, ptlc.level_idc);
> @@ -215,8 +213,7 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
>  
>  /* bit(16) avgFrameRate; */
> -AV_W8(p + 19, 0);
> -AV_W8(p + 20, 0);
> +AV_WB16(p + 19, 0);
>  
>  /*
>   * bit(2) constantFrameRate;
> @@ -242,11 +239,9 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_VPS & 0x3f);
>  /* unsigned int(16) numNalus; */
> -AV_W8(p + 1, 0);
> -AV_W8(p + 2, 1);
> +AV_WB16(p + 1, 1);
>  /* unsigned int(16) nalUnitLength; */
> -AV_W8(p + 3, vps->data_size >> 8);
> -AV_W8(p + 4, vps->data_size & 0x);
> +AV_WB16(p + 3, vps->data_size);
>  /* bit(8*nalUnitLength) nalUnit; */
>  memcpy(p + 5, vps->data, vps->data_size);
>  p += 5 + vps->data_size;
> @@ -254,24 +249,20 @@ CFDataRef 
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  /* sps */
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_SPS & 0x3f);
> -AV_W8(p + 1, 0);
> -AV_W8(p + 2, 1);
> -AV_W8(p + 3, sps->data_size >> 8);
> -AV_W8(p + 4, sps->data_size & 0x);
> +AV_WB16(p + 1, 1);
> +AV_WB16(p + 3, sps->data_size);
>  memcpy(p + 5, sps->data, sps->data_size);
>  p += 5 + sps->data_size;
>  
>  /* pps */
>  AV_W8(p, 1 << 7 |
>   HEVC_NAL_PPS & 0x3f);
> -AV_W8(p + 1, num_pps >> 8);
> -AV_W8(p + 2, num_pps & 0x);
> +AV_WB16(p + 1, num_pps);
>  p += 3;
>  for (i = 0; i < MAX_PPS_COUNT; i++) {
>  if (h->ps.pps_list[i]) {
>  const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
> -AV_W8(p + 0, pps->data_size >> 8);
> -AV_W8(p + 1, pps->data_size & 0x);
> +AV_WB16(p, pps->data_size);
>  memcpy(p + 2, pps->data, pps->data_size);
>  p += 2 + pps->data_size;
>  }
> 

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

[FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: use AV_WB16 where possible

[Aman Gupta]

From: Aman Gupta 

additional changes to hevc patchset, as suggested on-list

if these look fine, I will squash into previous patchset and push it to
master.
---
 libavcodec/videotoolbox.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 078174cc61..c96200cbdb 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -165,10 +165,8 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
  ptlc.non_packed_constraint_flag << 5 |
  ptlc.frame_only_constraint_flag << 4);
 AV_W8(p + 7, 0);
-AV_W8(p + 8, 0);
-AV_W8(p + 9, 0);
-AV_W8(p + 10, 0);
-AV_W8(p + 11, 0);
+AV_WB16(p + 8, 0);
+AV_WB16(p + 10, 0);
 
 /* unsigned int(8) general_level_idc; */
 AV_W8(p + 12, ptlc.level_idc);
@@ -215,8 +213,7 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 AV_W8(p + 18, (sps->bit_depth_chroma - 8) | 0xfc);
 
 /* bit(16) avgFrameRate; */
-AV_W8(p + 19, 0);
-AV_W8(p + 20, 0);
+AV_WB16(p + 19, 0);
 
 /*
  * bit(2) constantFrameRate;
@@ -242,11 +239,9 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 AV_W8(p, 1 << 7 |
  HEVC_NAL_VPS & 0x3f);
 /* unsigned int(16) numNalus; */
-AV_W8(p + 1, 0);
-AV_W8(p + 2, 1);
+AV_WB16(p + 1, 1);
 /* unsigned int(16) nalUnitLength; */
-AV_W8(p + 3, vps->data_size >> 8);
-AV_W8(p + 4, vps->data_size & 0x);
+AV_WB16(p + 3, vps->data_size);
 /* bit(8*nalUnitLength) nalUnit; */
 memcpy(p + 5, vps->data, vps->data_size);
 p += 5 + vps->data_size;
@@ -254,24 +249,20 @@ CFDataRef 
ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
 /* sps */
 AV_W8(p, 1 << 7 |
  HEVC_NAL_SPS & 0x3f);
-AV_W8(p + 1, 0);
-AV_W8(p + 2, 1);
-AV_W8(p + 3, sps->data_size >> 8);
-AV_W8(p + 4, sps->data_size & 0x);
+AV_WB16(p + 1, 1);
+AV_WB16(p + 3, sps->data_size);
 memcpy(p + 5, sps->data, sps->data_size);
 p += 5 + sps->data_size;
 
 /* pps */
 AV_W8(p, 1 << 7 |
  HEVC_NAL_PPS & 0x3f);
-AV_W8(p + 1, num_pps >> 8);
-AV_W8(p + 2, num_pps & 0x);
+AV_WB16(p + 1, num_pps);
 p += 3;
 for (i = 0; i < MAX_PPS_COUNT; i++) {
 if (h->ps.pps_list[i]) {
 const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
-AV_W8(p + 0, pps->data_size >> 8);
-AV_W8(p + 1, pps->data_size & 0x);
+AV_WB16(p, pps->data_size);
 memcpy(p + 2, pps->data, pps->data_size);
 p += 2 + pps->data_size;
 }
-- 
2.13.5 (Apple Git-94)

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

[FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: fix hevc hwaccel build on older macOS

[Aman Gupta]

From: Aman Gupta 

---
 configure | 5 -
 libavcodec/videotoolbox.c | 4 
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index d353e9d824..aae23bf38f 100755
--- a/configure
+++ b/configure
@@ -2073,6 +2073,7 @@ TOOLCHAIN_FEATURES="
 
 TYPES_LIST="
 CONDITION_VARIABLE_Ptr
+kCMVideoCodecType_HEVC
 socklen_t
 struct_addrinfo
 struct_group_source_req
@@ -5809,8 +5810,10 @@ enabled avfoundation && {
 check_lib avfoundation CoreGraphics/CoreGraphics.h   
CGGetActiveDisplayList "-framework CoreGraphics" ||
 check_lib avfoundation ApplicationServices/ApplicationServices.h 
CGGetActiveDisplayList "-framework ApplicationServices"; }
 
-enabled videotoolbox &&
+enabled videotoolbox && {
 check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
+check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
+}
 
 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
 
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index c96200cbdb..e62452c078 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -40,6 +40,10 @@
 #  define kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder 
CFSTR("RequireHardwareAcceleratedVideoDecoder")
 #endif
 
+#if !HAVE_KCMVIDEOCODECTYPE_HEVC
+enum { kCMVideoCodecType_HEVC = 'hvc1' };
+#endif
+
 #define VIDEOTOOLBOX_ESDS_EXTRADATA_PADDING  12
 
 static void videotoolbox_buffer_release(void *opaque, uint8_t *data)
-- 
2.13.5 (Apple Git-94)

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

Re: [FFmpeg-devel] [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from VANC

[Marton Balint]

On Wed, 27 Sep 2017, Jeyapal, Karthick wrote:


Sorry for the late reply, the last was busy week. Here are some more
comments:


Thanks for your comments. Please find the updated patch attached with your 
comments incorporated.


Sorry, still not quite there... Here are some further comments:


From 9a572cb8b4ea599ee6bc1eedd6c7ca6868cfe0c6 Mon Sep 17 00:00:00 2001
From: Karthick J 
Date: Wed, 30 Aug 2017 11:43:16 +0530
Subject: [PATCH 3/4] avdevice/decklink_dec: Added Closed caption decode from
 VANC

Signed-off-by: Karthick J 
---
 libavcodec/avcodec.h |   7 ++
 libavcodec/avpacket.c|   1 +
 libavcodec/version.h |   2 +-
 libavdevice/decklink_dec.cpp | 196 +++
 4 files changed, 188 insertions(+), 18 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 513236a..d4a458f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1600,6 +1600,13 @@ enum AVPacketSideDataType {
 AV_PKT_DATA_CONTENT_LIGHT_LEVEL,

 /**
+ * ATSC A53 Part 4 Closed Captions. This metadata should be associated with
+ * a video stream. A53 CC bitstream is stored as uint8_t in 
AVPacketSideData.data.
+ * The number of bytes of CC data is AVPacketSideData.size.
+ */
+AV_PKT_DATA_A53_CC,


I forgot to mention that you should also add a note about this to 
doc/APIChanges, sorry.


+
+/**
  * The number of side data elements (in fact a bit more than it).
  * This is not part of the public API/ABI in the sense that it may
  * change when new side data types are added.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 5ce3228..a292b15 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -387,6 +387,7 @@ const char *av_packet_side_data_name(enum 
AVPacketSideDataType type)
 case AV_PKT_DATA_MASTERING_DISPLAY_METADATA: return "Mastering display 
metadata";
 case AV_PKT_DATA_CONTENT_LIGHT_LEVEL:return "Content light level 
metadata";
 case AV_PKT_DATA_SPHERICAL:  return "Spherical Mapping";
+case AV_PKT_DATA_A53_CC: return "A53 Closed Captions";
 }
 return NULL;
 }
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 22cab7b..29cdb85 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@

 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR 104
-#define LIBAVCODEC_VERSION_MICRO 100
+#define LIBAVCODEC_VERSION_MICRO 101

 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 38e6bd8..a24f563 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -1,6 +1,7 @@
 /*
  * Blackmagic DeckLink input
  * Copyright (c) 2013-2014 Luca Barbato, Deti Fliegl
+ * Copyright (c) 2014 Rafaël Carré
  * Copyright (c) 2017 Akamai Technologies, Inc.
  *
  * This file is part of FFmpeg.
@@ -105,6 +106,42 @@ static int get_vanc_line_idx(BMDDisplayMode mode)
 return i - 1;
 }

+static inline uint16_t parity (uint16_t x)
+{
+uint16_t i;
+for (i = 4 * sizeof (x); i > 0; i /= 2)
+x ^= x >> i;
+return x & 1;
+}
+
+static inline void clear_parity_bits(uint16_t *buf, int len) {
+int i;
+for (i = 0; i < len; i++)
+buf[i] &= 0xff;
+}
+
+static int check_vanc_parity_checksum(uint16_t *buf, int len, uint16_t 
checksum) {
+int i;
+uint32_t vanc_sum;


uint16_t is enough, it does not matter if it overflows. Also don't forget to
initialize this to 0, the previous patch had that.


+for (i = 3; i < len - 1; i++) {
+uint16_t v = buf[i];
+int np = v >> 8;
+int p = parity(v & 0xff);
+if ((!!p ^ !!(v & 0x100)) || (np != 1 && np != 2)) {
+// Parity check failed
+return -1;
+}
+vanc_sum += v;
+}
+vanc_sum &= 0x1ff;
+vanc_sum |= ((~vanc_sum & 0x100) << 1);
+if (checksum != vanc_sum) {
+// Checksum verification failed
+return -1;
+}
+return 0;
+}
+
 /* The 10-bit VANC data is packed in V210, we only need the luma component. */
 static void extract_luma_from_v210(uint16_t *dst, const uint8_t *src, int 
width)
 {
@@ -232,19 +269,148 @@ static uint8_t* 
teletext_data_unit_from_ancillary_packet(uint16_t *py, uint16_t
 return tgt;
 }

-static uint8_t* teletext_data_unit_from_vanc_data(uint16_t *py, uint8_t *tgt, 
int64_t wanted_lines)
+uint8_t *vanc_to_cc(AVFormatContext *avctx, uint16_t *buf, size_t words,
+unsigned &cc_count)
 {
-uint16_t *pend = py + 1920;
+size_t i, len = (buf[5] & 0xff) + 6 + 1;
+uint8_t cdp_sum, rate;
+uint16_t hdr, ftr;
+uint8_t *cc;
+uint16_t *cdp = &buf[6]; // CDP follows
+if (cdp[0] != 0x96 || cdp[1] != 0x69) {
+av_log(avctx, AV_LOG_WARNING, "Invalid CDP header 0x%.2x 0x%.2x", 
cdp[0],

Re: [FFmpeg-devel] [PATCH] [PATCH v7] Add support for RockChip Media Process Platform

[Mark Thompson]

On 24/09/17 06:39, LongChair . wrote:
> From: Lionel CHAZALLON 
> 
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that 
> allows drm / dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
> 
> Changes from Previous patch :
> - Frame colorspace info is now filled.
> - Frame interlacing is now filled (Note : currently had a bug in mpp which 
> will be fixed soon by rockchip, will set the to progressive).
> - hw_frame_context returns none as format for the rockchip specific 10 bits.
> - Added support for VP9 codec.
> - removed MPG4 codec : it seems that MPP doesn't handle properly all the 
> MPEG4 formats
> - removed MPEG2 : there is still an issue with MPEG2 decoder, this is being 
> investigated by RockChip.
> - the ION format has been kept for MPP init (rather than DRM) as this is the 
> only one working right, using DRM format will cause assertions upon close.
> - Other minor comments have been taken into account
> ---
>  Changelog  |   2 +-
>  configure  |  15 ++
>  libavcodec/Makefile|   4 +
>  libavcodec/allcodecs.c |   4 +
>  libavcodec/rkmppdec.c  | 591 
> +
>  5 files changed, 615 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/rkmppdec.c

Applied (with minor changes as discussed on IRC, version bump, and fixup for 
recent merge to configure).

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: fix profile search when disable exact profile match.

[Mark Thompson]

On 21/09/17 08:22, Jun Zhao wrote:
> From d7dc5c00692302e810412dea44ae3d2f122fb9a4 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 21 Sep 2017 02:44:42 -0400
> Subject: [PATCH 2/2] lavc/vaapi_decode: fix profile search when disable exact
>  profile match.
> 
> When disable exact profile match, alway use the profile found by
> codecid.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_decode.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index cf58aae4c6..98b00e3637 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -329,6 +329,10 @@ static int vaapi_decode_make_config(AVCodecContext 
> *avctx)
>  if (exact_match)
>  break;
>  alt_profile = vaapi_profile_map[i].codec_profile;
> +
> +if (avctx->hwaccel_flags &
> +AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH)
> +break;
>  }
>  }
>  av_freep(&profile_list);
> -- 
> 2.11.0
> 

An exact match might exist later in the list.  Consider an H.264 high input - 
this change can choose H.264 constrained baseline instead even if H.264 high is 
present.

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

Re: [FFmpeg-devel] [PATCH] prores: Always assume limited range

[wm4]

On Wed, 27 Sep 2017 17:28:12 -0400
Vittorio Giovara  wrote:

> As defined by the spcifications
> ---
>  libavcodec/proresdec_lgpl.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
> index bc5bdb5a4d..c86d433f50 100644
> --- a/libavcodec/proresdec_lgpl.c
> +++ b/libavcodec/proresdec_lgpl.c
> @@ -177,6 +177,7 @@ static int decode_frame_header(ProresContext *ctx, const 
> uint8_t *buf,
>  avctx->color_primaries = buf[14];
>  avctx->color_trc   = buf[15];
>  avctx->colorspace  = buf[16];
> +avctx->color_range = AVCOL_RANGE_MPEG;
>  
>  ctx->qmat_changed = 0;
>  ptr   = buf + 20;

LGTM. (A bit disgusted at Prores...)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] prores: Always assume limited range

[Vittorio Giovara]

As defined by the spcifications
---
 libavcodec/proresdec_lgpl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/proresdec_lgpl.c b/libavcodec/proresdec_lgpl.c
index bc5bdb5a4d..c86d433f50 100644
--- a/libavcodec/proresdec_lgpl.c
+++ b/libavcodec/proresdec_lgpl.c
@@ -177,6 +177,7 @@ static int decode_frame_header(ProresContext *ctx, const 
uint8_t *buf,
 avctx->color_primaries = buf[14];
 avctx->color_trc   = buf[15];
 avctx->colorspace  = buf[16];
+avctx->color_range = AVCOL_RANGE_MPEG;
 
 ctx->qmat_changed = 0;
 ptr   = buf + 20;
-- 
2.14.2

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

The current situation is inconsistent.
It creates .lib/.dlls files for dynamic libraries and .a files for
static libraries.
This complicates e.g. detecting ffmpeg using cmake needlessly.
Changing this behavior would be a net gain.

I would also be happy if there would be a (configure) switch to
manually set the pre/suffix.

Maarten

On 27 September 2017 at 22:26, Hendrik Leppkes  wrote:
> On Wed, Sep 27, 2017 at 10:11 PM, Mateusz  wrote:
>> W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
>>> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>>>  wrote:
 Hey,

 Building the static ffmpeg library using vcpkg is currently broken [1][2].
 This is mainly due to the fact that the built static libraries are .a files
 with lib prefixes.

 The attached patch sets the lib prefix to "" and the lib suffix to ".lib".

 Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
 Edition on Windows 10.
 The resulted libraries link correctly to my application.

>>> This would break the workflow for everyone that is currently working
>>> with the current names, however.
>>
>> For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
>> improvement.
>> Is there any person happy with lib...a names for lib in msvc?
>>
>
> It doesn't really matter if you're happy with it or not, if you change
> it stuff will still break.
>
> - Hendrik
> ___
> 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] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 10:39 PM, Carl Eugen Hoyos  wrote:
> 2017-09-27 22:30 GMT+02:00 Hendrik Leppkes :
>> On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:
>
>>> No opinion here, this was reported twice on trac this week, I don't
>>> know if there was really more than one user affected.
>>
>> "Signaling" as a single word isn't very descriptive, and should
>> probably be expanded.
>
> I don't disagree, do you have a suggestion?
>
>> Additionally, if its on -1 (default/auto), it should probably
>> automatically use a mode that works with the requested profile.
>
> Is that possible? fdk refuses explicit signaling here for (e)ld.
>

You cannot put ELD into ADTS, so that combination is entirely
impossible, and maybe a better thing to check and error out on first.
And when you use "raw" mode with a global header, explicit signaling
should also work.

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

Re: [FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Carl Eugen Hoyos]

2017-09-27 22:30 GMT+02:00 Hendrik Leppkes :
> On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:

>> No opinion here, this was reported twice on trac this week, I don't
>> know if there was really more than one user affected.
>
> "Signaling" as a single word isn't very descriptive, and should
> probably be expanded.

I don't disagree, do you have a suggestion?

> Additionally, if its on -1 (default/auto), it should probably
> automatically use a mode that works with the requested profile.

Is that possible? fdk refuses explicit signaling here for (e)ld.

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

Re: [FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 8:18 PM, Carl Eugen Hoyos  wrote:
> Hi!
>
> No opinion here, this was reported twice on trac this week, I don't
> know if there was really more than one user affected.

"Signaling" as a single word isn't very descriptive, and should
probably be expanded.

Additionally, if its on -1 (default/auto), it should probably
automatically use a mode that works with the requested profile.

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 10:11 PM, Mateusz  wrote:
> W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
>> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>>  wrote:
>>> Hey,
>>>
>>> Building the static ffmpeg library using vcpkg is currently broken [1][2].
>>> This is mainly due to the fact that the built static libraries are .a files
>>> with lib prefixes.
>>>
>>> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>>>
>>> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
>>> Edition on Windows 10.
>>> The resulted libraries link correctly to my application.
>>>
>> This would break the workflow for everyone that is currently working
>> with the current names, however.
>
> For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
> improvement.
> Is there any person happy with lib...a names for lib in msvc?
>

It doesn't really matter if you're happy with it or not, if you change
it stuff will still break.

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Mateusz]

W dniu 2017-09-27 o 17:40, Hendrik Leppkes pisze:
> On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
>  wrote:
>> Hey,
>>
>> Building the static ffmpeg library using vcpkg is currently broken [1][2].
>> This is mainly due to the fact that the built static libraries are .a files
>> with lib prefixes.
>>
>> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>>
>> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
>> Edition on Windows 10.
>> The resulted libraries link correctly to my application.
>>
> This would break the workflow for everyone that is currently working
> with the current names, however.

For gcc it breaks nothing (it still makes lib...a files), for msvc it is 
improvement.
Is there any person happy with lib...a names for lib in msvc?

Mateusz


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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc put mc 20, 01 and 03 msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 11:56:20AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx


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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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/mips: Improve avc weighted mc msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 08:49:15AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx

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

Re: [FFmpeg-devel] [PATCH] avcodec/mips: Improve avc chroma vert mc msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 08:49:24AM +, Manojkumar Bhosale wrote:
> LGTM

applied

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] avcodec/mips: Removed generic function call in avc intra msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 07:48:51AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thx

[...]
-- 
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] avcodec/mips: preload data in hevc sao edge 45 degree filter msa functions

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 07:43:48AM +, Manojkumar Bhosale wrote:
> LGTM

applied

thanks

[...]
-- 
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] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

>>* Hey,
** Building the static ffmpeg library using vcpkg is currently
broken [1][2].
*>>* This is mainly due to the fact that the built static libraries are .a files
*>>* with lib prefixes.
** The attached patch sets the lib prefix to "" and the lib suffix
to ".lib".
** Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
*>>* Edition on Windows 10.
*>>* The resu*lted libraries link correctly to my application.
>>
> Carl Eugen Hoyos:
> Did this work with older versions of any of the involved tools
(including FFmpeg)?

3.3.3 is the first version I have tried to build using vcpkg. [1]
I guess 'no' is the answer to your question.

> Hendrik Leppkes:
> This would break the workflow for everyone that is currently working with the 
> current names, however.

I would be equally happy if there would be a way (using configure
arguments?) to set these two parameters.

[1] 
https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6891109f0fc/ports/ffmpeg/CONTROL


Thanks.

On 27 September 2017 at 16:43, Anonymous Maarten <
anonymous.maar...@gmail.com> wrote:

> Hey,
>
> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a
> files with lib prefixes.
>
> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>
> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
> Edition on Windows 10.
> The resulted libraries link correctly to my application.
>
> [1] https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6
> 891109f0fc/ports/ffmpeg/portfile.cmake#L1-L4
> [2] https://github.com/Microsoft/vcpkg/issues/1821
>
> Maarten,
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Ronald S. Bultje]

Hi,

On Wed, Sep 27, 2017 at 2:10 PM, Carl Eugen Hoyos 
wrote:

> 2017-09-27 20:09 GMT+02:00 Carl Eugen Hoyos :
> > 2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :
>
> >> It's intruiging that the existing demuxer (as you mentioned,
> >> it expects a prefix) works with unicast but not
> >> multicast input.
> >
> > I don't think this is correct (as in: "This is impossible") but
> > I may of course miss something ;-)
>
> It of course works if you start the listener first but this
> doesn't count imo.


Ah, that indeed explains anything, thank you. (In terms of whether to
update the existing demuxer or add a new one, I have no preference.)

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

[FFmpeg-devel] [PATCH 2/2] configure: simplify checks for libxcb dependent features

[James Almer]

---
 configure | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/configure b/configure
index 1676215146..5b3e2ecdbf 100755
--- a/configure
+++ b/configure
@@ -6189,13 +6189,9 @@ fi
 enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb libxcb_shm libxcb_shape libxcb_xfixes
 
 if enabled libxcb; then
-
-enabled libxcb_shm&& check_pkg_config xcb-shmxcb/shm.h
xcb_shm_attach  || disable libxcb_shm
-enabled libxcb_shape  && check_pkg_config xcb-shape  xcb/shape.h  
xcb_shape_get_rectangles|| disable libxcb_shape
-enabled libxcb_xfixes && check_pkg_config xcb-xfixes xcb/xfixes.h 
xcb_xfixes_get_cursor_image || disable libxcb_xfixes
-
-add_cflags $xcb_cflags $xcb_shm_cflags $xcb_xfixes_cflags $xcb_shape_cflags
-add_extralibs $xcb_extralibs $xcb_shm_extralibs $xcb_xfixes_extralibs 
$xcb_shape_extralibs
+enabled libxcb_shm&& use_pkg_config xcb-shmxcb/shm.h
xcb_shm_attach  || disable libxcb_shm
+enabled libxcb_shape  && use_pkg_config xcb-shape  xcb/shape.h  
xcb_shape_get_rectangles|| disable libxcb_shape
+enabled libxcb_xfixes && use_pkg_config xcb-xfixes xcb/xfixes.h 
xcb_xfixes_get_cursor_image || disable libxcb_xfixes
 fi
 
 check_func_headers "windows.h" CreateDIBSection "$gdigrab_indev_extralibs"
-- 
2.14.1

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

[FFmpeg-devel] [PATCH 1/2] configure: disable libxcb dependent features if libxcb is not enabled

[James Almer]

---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a4baeb3b2a..1676215146 100755
--- a/configure
+++ b/configure
@@ -6186,7 +6186,7 @@ if enabled libcdio; then
 die "ERROR: No usable libcdio/cdparanoia found"
 fi
 
-enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb
+enabled libxcb && check_pkg_config "xcb >= 1.4" xcb/xcb.h xcb_connect || 
disable libxcb libxcb_shm libxcb_shape libxcb_xfixes
 
 if enabled libxcb; then
 
-- 
2.14.1

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

[FFmpeg-devel] [RFC]lavc/fdk-aacenc: Print an error if (e)ld was requested without signaling

[Carl Eugen Hoyos]

Hi!

No opinion here, this was reported twice on trac this week, I don't
know if there was really more than one user affected.

Please comment, Carl Eugen
From 256d46d2479b19103fab3f79f34f6ae597ae402c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 20:15:13 +0200
Subject: [PATCH] lavc/fdk-aacenc: Print an error if (e)ld is requested without
 signaling.

Related to ticket #6683.
---
 libavcodec/libfdk-aacenc.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index 0e2051b..1477ad41 100644
--- a/libavcodec/libfdk-aacenc.c
+++ b/libavcodec/libfdk-aacenc.c
@@ -244,6 +244,8 @@ static av_cold int aac_encode_init(AVCodecContext *avctx)
  * implicit signaling if using ADTS. */
 if (s->signaling < 0)
 s->signaling = avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER ? 2 : 0;
+if (!s->signaling && (avctx->profile == FF_PROFILE_AAC_LD || avctx->profile == FF_PROFILE_AAC_ELD))
+av_log(avctx, AV_LOG_ERROR, "Signaling required for LD and ELD, initialization will fail.\n");
 
 if ((err = aacEncoder_SetParam(s->handle, AACENC_SIGNALING_MODE,
s->signaling)) != AACENC_OK) {
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 20:09 GMT+02:00 Carl Eugen Hoyos :
> 2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :

>> It's intruiging that the existing demuxer (as you mentioned,
>> it expects a prefix) works with unicast but not
>> multicast input.
>
> I don't think this is correct (as in: "This is impossible") but
> I may of course miss something ;-)

It of course works if you start the listener first but this
doesn't count imo.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:46 GMT+02:00 Ronald S. Bultje :

> @Carl Eugen: I've read the bug report.

Thank you; sorry that imo, this cannot help in this case;-(
The relevant issue is that live streams or truncated
amr files cannot be handled by the existing demuxer
although they work if the properties are forced with
the new demuxers.

The alternative is to allow forcing properties for the
existing demuxer, this has the disadvantage that it is
more difficult to use (and it would make hypothetical
auto-detection more messy).

> It's intruiging that the existing demuxer (as you mentioned,
> it expects a prefix) works with unicast but not
> multicast input.

I don't think this is correct (as in: "This is impossible") but
I may of course miss something ;-)

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Ronald S. Bultje]

Hi guys,

On Wed, Sep 27, 2017 at 1:32 PM, wm4  wrote:

> On Wed, 27 Sep 2017 19:22:37 +0200
> Carl Eugen Hoyos  wrote:
>
> > 2017-09-27 19:08 GMT+02:00 wm4 :
> > >  Maybe you could get back to the technical discussion
> >
> > I wish this were so easy with you:
>
> Well, it certainly isn't with you.


OK, this discussion is over between you two, please stop it.

@Carl Eugen: I've read the bug report. It's intruiging that the existing
demuxer (as you mentioned, it expects a prefix) works with unicast but not
multicast input. Do you know what's causing this difference?

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:22:37 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 19:08 GMT+02:00 wm4 :
> >  Maybe you could get back to the technical discussion  
> 
> I wish this were so easy with you:

Well, it certainly isn't with you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

Stopping the codec when no more input is available causes captured
buffers that might be ready to be invalidated.

This commit follows the V4L2 API more closely:

 1. when ffmpeg indicates EOS (NULL frame or packet size), the
 v4l2_m2m codec will send a dummy buffer to the driver with the
 V4L2_BUF_FLAG_LAST flag.

 2. the v4l2_m2m codec will then continue dequeuing captured buffers
 until EPIPE is raised by the driver (v4l2 EOF condition)

This makes the current timeout on dequeuing capture buffers while
draining unnecessary.
---
 libavcodec/v4l2_buffers.c |  18 +++
 libavcodec/v4l2_context.c | 132 ++
 2 files changed, 58 insertions(+), 92 deletions(-)

diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
index ef7d040..26e7b12 100644
--- a/libavcodec/v4l2_buffers.c
+++ b/libavcodec/v4l2_buffers.c
@@ -255,6 +255,18 @@ static int v4l2_bufref_to_buf(V4L2Buffer *out, int plane, 
const uint8_t* data, i
 return 0;
 }
 
+static int v4l2_buffer_set_eos(V4L2Buffer* avbuf)
+{
+/* flag that we are draining to the v4l2_m2m context */
+buf_to_m2mctx(avbuf)->draining = 1;
+
+/* flag to the v4l2 driver - either of these two conditions (use both to 
be safe on old drivers) */
+avbuf->buf.m.planes[0].bytesused = 0;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
+
+return 0;
+}
+
 /**
  *
  *  V4L2uffer interface
@@ -265,6 +277,9 @@ int ff_v4l2_buffer_avframe_to_buf(const AVFrame *frame, 
V4L2Buffer* out)
 {
 int i, ret;
 
+if (!frame)
+return v4l2_buffer_set_eos(out);
+
 for(i = 0; i < out->num_planes; i++) {
 ret = v4l2_bufref_to_buf(out, i, frame->buf[i]->data, 
frame->buf[i]->size, frame->buf[i]);
 if (ret)
@@ -356,6 +371,9 @@ int ff_v4l2_buffer_avpkt_to_buf(const AVPacket *pkt, 
V4L2Buffer *out)
 {
 int ret;
 
+if (!pkt->size)
+return v4l2_buffer_set_eos(out);
+
 ret = v4l2_bufref_to_buf(out, 0, pkt->data, pkt->size, pkt->buf);
 if (ret)
 return ret;
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index d675c55..ef3d263 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -189,40 +189,6 @@ reinit_run:
 return 1;
 }
 
-static int v4l2_stop_decode(V4L2Context *ctx)
-{
-struct v4l2_decoder_cmd cmd = {
-.cmd = V4L2_DEC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_DECODER_CMD, &cmd);
-if (ret) {
-/* DECODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
-static int v4l2_stop_encode(V4L2Context *ctx)
-{
-struct v4l2_encoder_cmd cmd = {
-.cmd = V4L2_ENC_CMD_STOP,
-};
-int ret;
-
-ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_ENCODER_CMD, &cmd);
-if (ret) {
-/* ENCODER_CMD is optional */
-if (errno == ENOTTY)
-return ff_v4l2_context_set_status(ctx, VIDIOC_STREAMOFF);
-}
-
-return 0;
-}
-
 static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, int timeout)
 {
 struct v4l2_plane planes[VIDEO_MAX_PLANES];
@@ -236,6 +202,13 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 
 if (V4L2_TYPE_IS_OUTPUT(ctx->type))
 pfd.events =  POLLOUT | POLLWRNORM;
+else {
+/* on the capture queue */
+if (ctx_to_m2mctx(ctx)->draining) {
+/* ignore driver requests for more input and just wait for a valid 
frame */
+pfd.events = POLLIN | POLLRDNORM | POLLPRI;
+}
+}
 
 for (;;) {
 ret = poll(&pfd, 1, timeout);
@@ -243,50 +216,45 @@ static V4L2Buffer* v4l2_dequeue_v4l2buf(V4L2Context *ctx, 
int timeout)
 break;
 if (errno == EINTR)
 continue;
-
-/* timeout is being used to indicate last valid bufer when draining */
-if (ctx_to_m2mctx(ctx)->draining)
-ctx->done = 1;
-
 return NULL;
 }
 
-/* 0. handle errors */
+/* handle errors */
 if (pfd.revents & POLLERR) {
 av_log(logger(ctx), AV_LOG_WARNING, "%s POLLERR\n", ctx->name);
 return NULL;
 }
 
-/* 1. handle resolution changes */
+/* handle resolution changes */
 if (pfd.revents & POLLPRI) {
 ret = v4l2_handle_event(ctx);
 if (ret < 0) {
 /* if re-init failed, abort */
-ctx->done = EINVAL;
+ctx->done = 1;
 return NULL;
 }
 if (ret) {
 /* if re-init was successfull drop the buffer (if there was one)
- * since we had to reconfigure capture (unmap all buffers)
- */
+ * since we had to reconfigure capture (unmap all buffers) */
 return NULL;
 }
 }
 
-/* 2. dequeue the buffer */
+/* dequeue the buffer or provide more input */
 if

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:08 GMT+02:00 wm4 :
>  Maybe you could get back to the technical discussion

I wish this were so easy with you:

You first wrote:
> That seems particularly pointless, since the user has
> to force the demuxers.

If I understand this sentence correctly, you agree with me
that it should be as easy as possible for users to receive
amrnb and amrwb streams.

It should be added here that the demuxer always has to be
forced - I don't know if auto-detecting amrnb and amrwb
could be done but it is not part of the patch. (But the patch
is a necessary prerequisite for this hypothetical auto-detection).
The question for the user is though: How to force the codec?

Then you wrote:
> Then maybe there should be a mechanism to force
> stream parameters

How does this not contradict your first statement?
It is probably (I did not immediately succeed) possible
to allow users to first force the amr demuxer and - in
addition - force a codec.
But as we - seemingly - agree above that users should
not have to force everything, I considered that actual
patch much more useful.

When you add the fact that you wrote that you refuse
to read a user report to the contradiction, you will
hopefully understand how futile it appears to have
this technical discussion with you.

> instead of this weird nonsense?

Adding personal insults to every single one of your
emails of course significantly strengthen above
reasoning.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Nicolas George]

Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit :
> I see no reason to bring parity to ffplay then.

Nobody asked you to do that.

Why do you want to remove these devices in the first place?

Regards,

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:04:26 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 19:02 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 19:00:04 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-09-27 18:58 GMT+02:00 wm4 :
> >>  
> >> > It may be better for you not committing anything if you don't know what
> >> > commit messages are.  
> >>
> >> I assume this is how you interpret our code-of-conduct
> >> to which you agreed?
> >>
> >> Watch your tongue, Carl Eugen  
> >
> > I don't know, you started with this. I only replied with the equivalent.  
> 
> While this does not sound true to me, 

> I wonder how it is related.

So do I. Maybe you could get back to the technical discussion instead
of this weird nonsense?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 19:02 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 19:00:04 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-09-27 18:58 GMT+02:00 wm4 :
>>
>> > It may be better for you not committing anything if you don't know what
>> > commit messages are.
>>
>> I assume this is how you interpret our code-of-conduct
>> to which you agreed?
>>
>> Watch your tongue, Carl Eugen
>
> I don't know, you started with this. I only replied with the equivalent.

While this does not sound true to me, I wonder how it is related.

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

On 09/27/2017 09:31 AM, wm4 wrote:

On Wed, 27 Sep 2017 09:03:58 -0700
Jorge Ramirez-Ortiz  wrote:


On 09/27/2017 06:01 AM, wm4 wrote:

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:
  

Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.

This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
raised by the driver (EOF condition)

This also has the advantage of making the timeout on dequeuing capture
buffers while draining unnecessary.
---
   libavcodec/v4l2_context.c | 162 
++
   1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.
  

-/* 0. handle errors */
+/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.

ACK. will do on any following patches - or I can do it on this one if you want.

Not necessary. In general we prefer separating unrelated changes, but I
think there's a limit to which we have to cause additional work to
follow this rule. (It's mainly in cases where the cosmetic changes are
significant or in completely different code.)


+if (!frame) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
 /* handle the end of stream case */
+} else {
+ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
+if (ret)
+return ret;
+}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?

yes
I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at this
level as well.
will fix

That sounds good. So you're going to send a new patch? Then I'll hold
off applying this one.


yes, just testing.
it is much cleaner this way.

I looked [1] at how the  V4L2_BUF_FLAG_LAST is used in the Venus driver and it 
seems that I could either set bytesused to 0 _OR_ set the  V4L2_BUF_FLAG_LAST 
instead (the API suggests using the flag)
I will do both to make sure all cases are covered in drivers that might not use 
the flag.


[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/qcom/venus/helpers.c?h=v4.14-rc2#n325



___
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]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 19:00:04 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 18:58 GMT+02:00 wm4 :
> 
> > It may be better for you not committing anything if you don't know what
> > commit messages are.  
> 
> I assume this is how you interpret our code-of-conduct
> to which you agreed?
> 
> Watch your tongue, Carl Eugen

I don't know, you started with this. I only replied with the equivalent.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 18:58 GMT+02:00 wm4 :

> It may be better for you not committing anything if you don't know what
> commit messages are.

I assume this is how you interpret our code-of-conduct
to which you agreed?

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 18:47:16 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 18:40 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 18:08:19 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> Hi!
> >>
> >> The existing amr demuxer does not allow reading streams, it requires
> >> the 3GPP-conforming file header.
> >> Attached patch allows reading amrnb and amrwb from (live) streams,
> >> fixes ticket #6678.
> >>
> >> Please comment, Carl Eugen  
> >
> > That seems particularly pointless, since the user has to force the
> > demuxers.  
> 
> Like for any other demuxer without auto-detection?

Actually no.

> I wasn't able to "force" reading such a stream without this patch,
> am I missing something?

Then maybe there should be a mechanism to force stream parameters, just
like they obviously exist for raw audio/video.

> > I don't know what that ticket is  
> 
> Then it may be better not to comment.

It may be better for you not committing anything if you don't know what
commit messages are.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 6:37 PM, wm4  wrote:
> On Wed, 27 Sep 2017 09:17:36 -0700
> Aman Gupta  wrote:
>
>> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
>>
>> > On Tue, 26 Sep 2017 18:08:10 -0700
>> > Aman Gupta  wrote:
>> >
>> > > From: Aman Gupta 
>> > >
>> > > ---
>> > >  configure|   2 +
>> > >  libavcodec/allcodecs.c   |   1 +
>> > >  libavcodec/hevc_refs.c   |   3 +
>> > >  libavcodec/hevcdec.c |  12 ++-
>> > >  libavcodec/vda_vt_internal.h |   1 +
>> > >  libavcodec/videotoolbox.c| 203 ++
>> > +
>> > >  6 files changed, 221 insertions(+), 1 deletion(-)
>> >
>> > PS: A final patch should make sure these symbols don't cause build
>> > failures with older SDKs:
>> >
>> > > +case kCMVideoCodecType_HEVC :
>> >
>> > > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;
>> >
>> >
>> > Maybe with a configure check.
>> >
>>
>> This is available since macOS 10.11. How far back does ffmpeg support?
>
> Really not sure. If VideoToolbox support is never detected before
> 10.11, then it's OK.

VT is supported since 10.8, if anything newer is required for this,
then it should get a configure check.

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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

2017-09-27 18:40 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 18:08:19 +0200
> Carl Eugen Hoyos  wrote:
>
>> Hi!
>>
>> The existing amr demuxer does not allow reading streams, it requires
>> the 3GPP-conforming file header.
>> Attached patch allows reading amrnb and amrwb from (live) streams,
>> fixes ticket #6678.
>>
>> Please comment, Carl Eugen
>
> That seems particularly pointless, since the user has to force the
> demuxers.

Like for any other demuxer without auto-detection?

I wasn't able to "force" reading such a stream without this patch,
am I missing something?

> I don't know what that ticket is

Then it may be better not to comment.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[James Almer]

On 9/27/2017 1:37 PM, wm4 wrote:
> On Wed, 27 Sep 2017 09:17:36 -0700
> Aman Gupta  wrote:
> 
>> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
>>
>>> On Tue, 26 Sep 2017 18:08:10 -0700
>>> Aman Gupta  wrote:
>>>  
 From: Aman Gupta 

 ---
  configure|   2 +
  libavcodec/allcodecs.c   |   1 +
  libavcodec/hevc_refs.c   |   3 +
  libavcodec/hevcdec.c |  12 ++-
  libavcodec/vda_vt_internal.h |   1 +
  libavcodec/videotoolbox.c| 203 ++  
>>> +  
  6 files changed, 221 insertions(+), 1 deletion(-)  
>>>
>>> PS: A final patch should make sure these symbols don't cause build
>>> failures with older SDKs:
>>>  
 +case kCMVideoCodecType_HEVC :  
>>>  
 +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;  
>>>
>>>
>>> Maybe with a configure check.
>>>  
>>
>> This is available since macOS 10.11. How far back does ffmpeg support?
> 
> Really not sure. If VideoToolbox support is never detected before
> 10.11, then it's OK.

Videotoolbox is available since 10.8, so this definitely needs a
configure check, much like we're doing for DXVA_PicParams_HEVC in dxva2.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/9] avcodec/h264, videotoolbox: return AVERROR_INVALIDDATA when no frames are produced

[Michael Niedermayer]

On Mon, Sep 25, 2017 at 05:36:28PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> The only reason videotoolbox wouldn't produce frames is if the data fed
> to it was invalid, so returning AVERROR_INVALIDDATA makes sense here.
> 
> Further, it means AVERROR_EXTERNAL can be used in further commits to signal
> fatal VideoToolbox errors, letting the user know that they need to fallback to
> another decoder.
> ---
>  libavcodec/h264dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

probably ok

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[wm4]

On Wed, 27 Sep 2017 18:08:19 +0200
Carl Eugen Hoyos  wrote:

> Hi!
> 
> The existing amr demuxer does not allow reading streams, it requires
> the 3GPP-conforming file header.
> Attached patch allows reading amrnb and amrwb from (live) streams,
> fixes ticket #6678.
> 
> Please comment, Carl Eugen

That seems particularly pointless, since the user has to force the
demuxers. I don't know what that ticket is, all information should be
in the commit message anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[wm4]

On Wed, 27 Sep 2017 09:17:36 -0700
Aman Gupta  wrote:

> On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:
> 
> > On Tue, 26 Sep 2017 18:08:10 -0700
> > Aman Gupta  wrote:
> >  
> > > From: Aman Gupta 
> > >
> > > ---
> > >  configure|   2 +
> > >  libavcodec/allcodecs.c   |   1 +
> > >  libavcodec/hevc_refs.c   |   3 +
> > >  libavcodec/hevcdec.c |  12 ++-
> > >  libavcodec/vda_vt_internal.h |   1 +
> > >  libavcodec/videotoolbox.c| 203 ++  
> > +  
> > >  6 files changed, 221 insertions(+), 1 deletion(-)  
> >
> > PS: A final patch should make sure these symbols don't cause build
> > failures with older SDKs:
> >  
> > > +case kCMVideoCodecType_HEVC :  
> >  
> > > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;  
> >
> >
> > Maybe with a configure check.
> >  
> 
> This is available since macOS 10.11. How far back does ffmpeg support?

Really not sure. If VideoToolbox support is never detected before
10.11, then it's OK.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[wm4]

On Wed, 27 Sep 2017 09:03:58 -0700
Jorge Ramirez-Ortiz  wrote:

> On 09/27/2017 06:01 AM, wm4 wrote:
> > On Tue, 26 Sep 2017 16:22:23 -0700
> > Jorge Ramirez-Ortiz  wrote:
> >  
> >> Stopping the codec when no more input is available causes captured
> >> buffers that might be ready to be dequeued to be invalidated.
> >>
> >> This commit follows the V4L2 API more closely:
> >> 1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
> >> 2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
> >> raised by the driver (EOF condition)
> >>
> >> This also has the advantage of making the timeout on dequeuing capture
> >> buffers while draining unnecessary.
> >> ---
> >>   libavcodec/v4l2_context.c | 162 
> >> ++
> >>   1 file changed, 64 insertions(+), 98 deletions(-)  
> > I can't really comment on the logic of this code. So LGTM, just some
> > minor comments/questions.
> >  
> >> -/* 0. handle errors */
> >> +/* handle errors */  
> > (Apparently) unrelated cosmetic changes should usually be in separate
> > patches, but that's probably not worth the trouble in this case.  
> 
> ACK. will do on any following patches - or I can do it on this one if you 
> want.

Not necessary. In general we prefer separating unrelated changes, but I
think there's a limit to which we have to cause additional work to
follow this rule. (It's mainly in cases where the cosmetic changes are
significant or in completely different code.)

> >> +if (!frame) {
> >> +/* flag that we are draining */
> >> +ctx_to_m2mctx(ctx)->draining = 1;
> >> +
> >> +/* send EOS */
> >> +avbuf->buf.m.planes[0].bytesused = 1;
> >> +avbuf->flags |= V4L2_BUF_FLAG_LAST;
> >> +} else {
> >> +ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
> >> +if (ret)
> >> +return ret;
> >> +}  
> > Wouldn't it be better to switch the if/else bodies and avoid the
> > negation in the if condition?  
> 
> yes
> I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at 
> this 
> level as well.
> will fix

That sounds good. So you're going to send a new patch? Then I'll hold
off applying this one.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/videotoolbox: add hevc support

[Aman Gupta]

On Wed, Sep 27, 2017 at 5:51 AM, wm4  wrote:

> On Tue, 26 Sep 2017 18:08:10 -0700
> Aman Gupta  wrote:
>
> > From: Aman Gupta 
> >
> > ---
> >  configure|   2 +
> >  libavcodec/allcodecs.c   |   1 +
> >  libavcodec/hevc_refs.c   |   3 +
> >  libavcodec/hevcdec.c |  12 ++-
> >  libavcodec/vda_vt_internal.h |   1 +
> >  libavcodec/videotoolbox.c| 203 ++
> +
> >  6 files changed, 221 insertions(+), 1 deletion(-)
>
> PS: A final patch should make sure these symbols don't cause build
> failures with older SDKs:
>
> > +case kCMVideoCodecType_HEVC :
>
> > +videotoolbox->cm_codec_type = kCMVideoCodecType_HEVC;
>
>
> Maybe with a configure check.
>

This is available since macOS 10.11. How far back does ffmpeg support?


> ___
> 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] lavd: remove deprecated dv1394 device

[Josh de Kock]

On 27/09/2017 13:33, wm4 wrote:
> On Wed, 27 Sep 2017 13:09:02 +0100
> Josh de Kock  wrote:
> 
>> Support for this device has been removed in kernel since v2.6.37. dv1394
>> has been superseded by libiec61883 which is functionally equivalent.
>>
>> Signed-off-by: Josh de Kock 
>> ---
> 
> The API has been removed 7 years ago from the kernel. LGTM.

Thanks pushed,

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

[FFmpeg-devel] [PATCH]lavf/amr: Add amrnb and amrwb demuxers

[Carl Eugen Hoyos]

Hi!

The existing amr demuxer does not allow reading streams, it requires
the 3GPP-conforming file header.
Attached patch allows reading amrnb and amrwb from (live) streams,
fixes ticket #6678.

Please comment, Carl Eugen
From 1b548fbd47f521d0c2a7b443ac2b1f2925e8bb41 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 18:04:39 +0200
Subject: [PATCH] lavf/amr: Add amrnb and amrwb demuxers.

Fixes ticket #6678.
---
 libavformat/Makefile |2 ++
 libavformat/allformats.c |2 ++
 libavformat/amr.c|   54 ++
 libavformat/version.h|4 ++--
 4 files changed, 60 insertions(+), 2 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index df709c29..c4c8713 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -87,6 +87,8 @@ OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
 OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
 OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
 OBJS-$(CONFIG_AMR_MUXER) += amr.o
+OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
+OBJS-$(CONFIG_AMRWB_DEMUXER) += amr.o
 OBJS-$(CONFIG_ANM_DEMUXER)   += anm.o
 OBJS-$(CONFIG_APC_DEMUXER)   += apc.o
 OBJS-$(CONFIG_APE_DEMUXER)   += ape.o apetag.o img2.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 405ddb5..dc8984e 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -63,6 +63,8 @@ static void register_all(void)
 REGISTER_MUXDEMUX(AIFF, aiff);
 REGISTER_DEMUXER (AIX,  aix);
 REGISTER_MUXDEMUX(AMR,  amr);
+REGISTER_DEMUXER (AMRNB,amrnb);
+REGISTER_DEMUXER (AMRWB,amrwb);
 REGISTER_DEMUXER (ANM,  anm);
 REGISTER_DEMUXER (APC,  apc);
 REGISTER_DEMUXER (APE,  ape);
diff --git a/libavformat/amr.c b/libavformat/amr.c
index b5194a2..07f2315 100644
--- a/libavformat/amr.c
+++ b/libavformat/amr.c
@@ -176,6 +176,60 @@ AVInputFormat ff_amr_demuxer = {
 };
 #endif
 
+#if CONFIG_AMRNB_DEMUXER
+static int amrnb_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_tag  = MKTAG('s', 'a', 'm', 'r');
+st->codecpar->codec_id   = AV_CODEC_ID_AMR_NB;
+st->codecpar->sample_rate= 8000;
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+avpriv_set_pts_info(st, 64, 1, 8000);
+
+return 0;
+}
+
+AVInputFormat ff_amrnb_demuxer = {
+.name   = "amrnb",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AMR-NB"),
+.priv_data_size = sizeof(AMRContext),
+.read_header= amrnb_read_header,
+.read_packet= amr_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
+#endif
+
+#if CONFIG_AMRWB_DEMUXER
+static int amrwb_read_header(AVFormatContext *s)
+{
+AVStream *st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->codecpar->codec_tag  = MKTAG('s', 'a', 'w', 'b');
+st->codecpar->codec_id   = AV_CODEC_ID_AMR_WB;
+st->codecpar->sample_rate= 16000;
+st->codecpar->channels   = 1;
+st->codecpar->channel_layout = AV_CH_LAYOUT_MONO;
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+avpriv_set_pts_info(st, 64, 1, 16000);
+
+return 0;
+}
+
+AVInputFormat ff_amrwb_demuxer = {
+.name   = "amrwb",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AMR-WB"),
+.priv_data_size = sizeof(AMRContext),
+.read_header= amrwb_read_header,
+.read_packet= amr_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+};
+#endif
+
 #if CONFIG_AMR_MUXER
 AVOutputFormat ff_amr_muxer = {
 .name  = "amr",
diff --git a/libavformat/version.h b/libavformat/version.h
index ac6edf7..878917d 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,8 +32,8 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  57
-#define LIBAVFORMAT_VERSION_MINOR  82
-#define LIBAVFORMAT_VERSION_MICRO 102
+#define LIBAVFORMAT_VERSION_MINOR  83
+#define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/hevc_ps: extract SPS fields required for hvcC construction

[Michael Niedermayer]

On Tue, Sep 26, 2017 at 06:08:09PM -0700, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/hevc_ps.c | 3 ++-
>  libavcodec/hevc_ps.h | 2 ++
>  2 files changed, 4 insertions(+), 1 deletion(-)

LGTM

thx

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

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


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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[Jorge Ramirez-Ortiz]

On 09/27/2017 06:01 AM, wm4 wrote:

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:


Stopping the codec when no more input is available causes captured
buffers that might be ready to be dequeued to be invalidated.

This commit follows the V4L2 API more closely:
1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
raised by the driver (EOF condition)

This also has the advantage of making the timeout on dequeuing capture
buffers while draining unnecessary.
---
  libavcodec/v4l2_context.c | 162 ++
  1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.


-/* 0. handle errors */
+/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.


ACK. will do on any following patches - or I can do it on this one if you want.


+if (!frame) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;
+} else {
+ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
+if (ret)
+return ret;
+}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?


yes
I am going to add a ff_v4l2_buffer_eos() to avoid exposing the bytesused at this 
level as well.

will fix




-ret = ff_v4l2_buffer_avpkt_to_buf(pkt, avbuf);
-if (ret)
-return ret;
+if (!pkt->size) {
+/* flag that we are draining */
+ctx_to_m2mctx(ctx)->draining = 1;
+
+/* send EOS */
+avbuf->buf.m.planes[0].bytesused = 1;
+avbuf->flags |= V4L2_BUF_FLAG_LAST;

What is going on here? Dummy buffer of size 1 to send the flag?


yes. we need to queue a dummy buffer to the input queue that carries that flag.
that way, the v4l2 device driver can raise EPIPE to indicate that the last 
buffer was processed.





___
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] libavcodec/hapdec : add support for HapAphaOnly decoding

[Carl Eugen Hoyos]

2017-09-27 15:20 GMT+02:00 Martin Vignali :
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth :
>
>>
>>
>> > On 27 Sep 2017, at 11:59, Martin Vignali 
>> wrote:
>> >
>> >>
>> >>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
>> >>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
>> >>
>> >> The rgtc1u_block function places the single channel value in every
>> channel
>> >> except the alpha channel
>> >> The pixel format you have chosen is one which disregards the alpha
>> channel
>> >>
>> >> The output of this alpha-only decoder should be in the alpha channel of
>> a
>> >> pixel format which carries alpha. Probably other channels should have
>> zero
>> >> values.
>> >>
>> >>
>> > Hi Tom,
>> >
>> > After Carl answer, and thinking about that,
>> > The goal of HapAlphaOnly, is to store alpha, but can also store gray only
>> > (much better than HAP)
>> > In fact, it can be call HAP Gray !
>>
>> But it isn’t
>>
>> > For example from my part, i would like to use this codec, for matte, but
>> > also for gray only layer (use with color blending)
>>
>> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
>> non-standard use of it. If you would like this flexibility in Hap, that
>> should be argued for on the Hap project, not within FFmpeg.
>>
>> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
>> implementation in FFmpeg must follow the definition (see
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md>
>> ).
>>
>> The Alpha Only encoder and decoder must ingest and emit a pixel format
>> which carries alpha. It may be that adding a new alpha-only pixel format is
>> not seen as desirable, in which case an existing format with alpha should
>> be selected. This allows users to, eg, transcode from an RGBA format to Hap
>> Alpha Only and have the channel they expect be preserved from the input
>> video. Any other behaviour (eg having RGB converted to grey and then stored
>> as alpha) is not acceptable.
>>
>> > If a user want to compress a gray picture, it can be done using
>> > RGB to Gray conversion

Of course.
But if the input is single-plane, 8bit, it does not make sense to
output rgb (or rgba).

>> > And if user want to compress only alpha or a specific channel, i think
>> > ffmpeg have a filter for that (extractplanes (untested)),
>>
>> Your non-standard usage can still be achieved by channel switching in a
>> filter, the default behaviour must be according to the standard, which is
>> to encode and decode the alpha channel.

Which is not possible because FFmpeg does not support a single
alpha plane.

> Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> alpha from RGBA input)

I am less convinced:
As long as FFmpeg does not have a native alpha-only
pix_fmt (I am not sure this would have any user-visible
advantage), single-layer 8bit formats should be decoded
as gray8.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 16:31:37 +0100
Josh de Kock  wrote:

> On 27/09/2017 16:28, Carl Eugen Hoyos wrote:
> > 2017-09-27 17:21 GMT+02:00 Josh de Kock :  
> >> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:  
> >>> 2017-09-27 17:15 GMT+02:00 wm4 :  
>  On Wed, 27 Sep 2017 17:08:06 +0200
>  Carl Eugen Hoyos  wrote:
>   
> > 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> >  
> >> There is no point of having these output devices as all the
> >> functionality is contained in the 'ffplay' tool.  
> >
> > I use at least sdl and opengl regularly for tests that cannot
> > be done with ffplay.  
> 
>  How does it make sense to use those for testing  
> >>>
> >>> FFplay only supports a limited set of pix_fmts,
> >>> contrary to those devices.  
> >>
> >> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?  
> > 
> > No, but you can mark my argument as obsolete.  
> 
> I see no reason to bring parity to ffplay then.
> 
> >> This should be simple enough.  
> > 
> > Sure?
> > I was more under the assumption that this is simply impossible.
> > (Until SDL3)  
> 
> Why would it be impossible? I don't see how the OpenGL, SDL2 device
> could support more pixel formats than FFplay when they *all* use SDL2.

The OpenGL one uses shaders, but for the others his argument is bogus,
yes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Hendrik Leppkes]

On Wed, Sep 27, 2017 at 4:43 PM, Anonymous Maarten
 wrote:
> Hey,
>
> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a files
> with lib prefixes.
>
> The attached patch sets the lib prefix to "" and the lib suffix to ".lib".
>
> Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
> Edition on Windows 10.
> The resulted libraries link correctly to my application.
>

This would break the workflow for everyone that is currently working
with the current names, however.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

On 27/09/2017 16:28, Carl Eugen Hoyos wrote:
> 2017-09-27 17:21 GMT+02:00 Josh de Kock :
>> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
>>> 2017-09-27 17:15 GMT+02:00 wm4 :
 On Wed, 27 Sep 2017 17:08:06 +0200
 Carl Eugen Hoyos  wrote:

> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>
>> There is no point of having these output devices as all the
>> functionality is contained in the 'ffplay' tool.
>
> I use at least sdl and opengl regularly for tests that cannot
> be done with ffplay.

 How does it make sense to use those for testing
>>>
>>> FFplay only supports a limited set of pix_fmts,
>>> contrary to those devices.
>>
>> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?
> 
> No, but you can mark my argument as obsolete.

I see no reason to bring parity to ffplay then.

>> This should be simple enough.
> 
> Sure?
> I was more under the assumption that this is simply impossible.
> (Until SDL3)

Why would it be impossible? I don't see how the OpenGL, SDL2 device
could support more pixel formats than FFplay when they *all* use SDL2.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 17:21 GMT+02:00 Josh de Kock :
> On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
>> 2017-09-27 17:15 GMT+02:00 wm4 :
>>> On Wed, 27 Sep 2017 17:08:06 +0200
>>> Carl Eugen Hoyos  wrote:
>>>
 2017-09-27 15:18 GMT+02:00 Josh de Kock :

> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

 I use at least sdl and opengl regularly for tests that cannot
 be done with ffplay.
>>>
>>> How does it make sense to use those for testing
>>
>> FFplay only supports a limited set of pix_fmts,
>> contrary to those devices.
>
> So if there is pix_fmt parity then I can remove OpenGL, and SDL2?

No, but you can mark my argument as obsolete.

> This should be simple enough.

Sure?
I was more under the assumption that this is simply impossible.
(Until SDL3)

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 17:17:37 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 17:15 GMT+02:00 wm4 :
> > On Wed, 27 Sep 2017 17:08:06 +0200
> > Carl Eugen Hoyos  wrote:
> >  
> >> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> >>  
> >> > There is no point of having these output devices as all the
> >> > functionality is contained in the 'ffplay' tool.  
> >>
> >> I use at least sdl and opengl regularly for tests that cannot
> >> be done with ffplay.  
> >
> > How does it make sense to use those for testing  
> 
> FFplay only supports a limited set of pix_fmts,
> contrary to those devices.
> 
> > when the rendering isn't particularly correct in the first place?  
> 
> I had not known this / this has not hit me so far.
> How can I reproduce?

Apparently it doesn't respect colorspace, any other colorimetry
settings, chroma location, and I wouldn't trust it to get odd cropping
right. It's really basic and naive.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[Michael Niedermayer]

On Wed, Sep 27, 2017 at 05:01:59PM +0200, wm4 wrote:
> On Wed, 27 Sep 2017 16:34:49 +0200
> Michael Niedermayer  wrote:
> 
> > On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> > > Hi,
> > > 
> > > There is no point of having these output devices as all the
> > > functionality is contained in the 'ffplay' tool. If people wanted to
> > > integrate these devices in their own programs instead of using the
> > > ffmpeg tool then they are far too constrained for proper control, not to  
> > 
> > > mention output devices have been quick hacky in libavdevice for a long  
> > 
> > then please write a better API / lib / system
> 
> It should never have been added this way. Why did it happen? On that
> note, I tried to prevent it,

> and to argue that the contributor should
> have created a better API instead of badly hacking it into libavdevice.

I did not say anything like that.

What i stated should be the obvious
if people feel what we have doesnt serve its intended goals then
it makes sense to write something that does.

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

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


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

Re: [FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Carl Eugen Hoyos]

2017-09-27 15:30 GMT+02:00 Tobias Rapp :
> Metadata filter output is passed through an Awk script comparing floats

Is awk needed on the host or the target system?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

On 27/09/2017 16:17, Carl Eugen Hoyos wrote:
> 2017-09-27 17:15 GMT+02:00 wm4 :
>> On Wed, 27 Sep 2017 17:08:06 +0200
>> Carl Eugen Hoyos  wrote:
>>
>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>>>
 There is no point of having these output devices as all the
 functionality is contained in the 'ffplay' tool.
>>>
>>> I use at least sdl and opengl regularly for tests that cannot
>>> be done with ffplay.
>>
>> How does it make sense to use those for testing
> 
> FFplay only supports a limited set of pix_fmts,
> contrary to those devices.
> 

So if there is pix_fmt parity then I can remove OpenGL, and SDL2? This
should be simple enough.

>> when the rendering isn't particularly correct in the first place?
> 
> I had not known this / this has not hit me so far.
> How can I reproduce?
> 
> Carl Eugen

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 17:15 GMT+02:00 wm4 :
> On Wed, 27 Sep 2017 17:08:06 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
>>
>> > There is no point of having these output devices as all the
>> > functionality is contained in the 'ffplay' tool.
>>
>> I use at least sdl and opengl regularly for tests that cannot
>> be done with ffplay.
>
> How does it make sense to use those for testing

FFplay only supports a limited set of pix_fmts,
contrary to those devices.

> when the rendering isn't particularly correct in the first place?

I had not known this / this has not hit me so far.
How can I reproduce?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 17:08:06 +0200
Carl Eugen Hoyos  wrote:

> 2017-09-27 15:18 GMT+02:00 Josh de Kock :
> 
> > There is no point of having these output devices as all the
> > functionality is contained in the 'ffplay' tool.  
> 
> I use at least sdl and opengl regularly for tests that cannot
> be done with ffplay.

How does it make sense to use those for testing, when the rendering
isn't particularly correct in the first place? Seems like a rather bad
idea.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]fate: Add a test for latm-in-dvb autodetection

[Carl Eugen Hoyos]

Hi!

Attached patch adds a test for ticket #6657.

Please comment, Carl Eugen
From bef8e7beff7a674180404aa70424f08c6a86a9cd Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 27 Sep 2017 17:05:14 +0200
Subject: [PATCH] fate: Add a test for latm-in-dvb auto-detection, ticket
 #6657.

---
 tests/Makefile   |1 +
 tests/fate/mpegts.mak|   14 +++
 tests/ref/fate/mpegts-probe-latm |  191 ++
 3 files changed, 206 insertions(+)
 create mode 100644 tests/fate/mpegts.mak
 create mode 100644 tests/ref/fate/mpegts-probe-latm

diff --git a/tests/Makefile b/tests/Makefile
index 99f7e17..278be24 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -156,6 +156,7 @@ include $(SRC_PATH)/tests/fate/mov.mak
 include $(SRC_PATH)/tests/fate/mp3.mak
 include $(SRC_PATH)/tests/fate/mpc.mak
 include $(SRC_PATH)/tests/fate/mpeg4.mak
+include $(SRC_PATH)/tests/fate/mpegts.mak
 include $(SRC_PATH)/tests/fate/mxf.mak
 include $(SRC_PATH)/tests/fate/opus.mak
 include $(SRC_PATH)/tests/fate/pcm.mak
diff --git a/tests/fate/mpegts.mak b/tests/fate/mpegts.mak
new file mode 100644
index 000..b0644aa
--- /dev/null
+++ b/tests/fate/mpegts.mak
@@ -0,0 +1,14 @@
+#
+# Test probing MPEGTS format and stream properties
+#
+PROBE_FORMAT_STREAMS_COMMAND = \
+ffprobe$(PROGSSUF)$(EXESUF) -show_entries format=format_tags:streams \
+-print_format default -bitexact -v 0
+
+FATE_MPEGTS_PROBE-$(call DEMDEC, MPEGTS, HEVC, AAC_LATM) += fate-mpegts-probe-latm
+fate-mpegts-probe-latm: SRC = $(TARGET_SAMPLES)/mpegts/loewe.ts
+fate-mpegts-probe-latm: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)"
+
+FATE_SAMPLES_FFPROBE += $(FATE_MPEGTS_PROBE-yes)
+
+fate-mpegts: $(FATE_MPEGTS_PROBE-yes)
diff --git a/tests/ref/fate/mpegts-probe-latm b/tests/ref/fate/mpegts-probe-latm
new file mode 100644
index 000..1d36306
--- /dev/null
+++ b/tests/ref/fate/mpegts-probe-latm
@@ -0,0 +1,191 @@
+[PROGRAM]
+[STREAM]
+index=0
+codec_name=hevc
+profile=1
+codec_type=video
+codec_time_base=1/50
+codec_tag_string=[36][0][0][0]
+codec_tag=0x0024
+width=1920
+height=1080
+coded_width=1920
+coded_height=1080
+has_b_frames=5
+sample_aspect_ratio=1:1
+display_aspect_ratio=16:9
+pix_fmt=yuv420p
+level=123
+color_range=tv
+color_space=bt709
+color_transfer=bt709
+color_primaries=bt709
+chroma_location=unspecified
+field_order=unknown
+timecode=N/A
+refs=1
+id=0x551
+r_frame_rate=50/1
+avg_frame_rate=50/1
+time_base=1/9
+start_pts=2863340144
+start_time=31814.890489
+duration_ts=41400
+duration=0.46
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[STREAM]
+index=1
+codec_name=aac_latm
+profile=1
+codec_type=audio
+codec_time_base=1/48000
+codec_tag_string=[15][0][0][0]
+codec_tag=0x000f
+sample_fmt=fltp
+sample_rate=48000
+channels=2
+channel_layout=stereo
+bits_per_sample=0
+id=0x552
+r_frame_rate=0/0
+avg_frame_rate=0/0
+time_base=1/9
+start_pts=2863278584
+start_time=31814.206489
+duration_ts=24960
+duration=0.277333
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[/PROGRAM]
+[STREAM]
+index=0
+codec_name=hevc
+profile=1
+codec_type=video
+codec_time_base=1/50
+codec_tag_string=[36][0][0][0]
+codec_tag=0x0024
+width=1920
+height=1080
+coded_width=1920
+coded_height=1080
+has_b_frames=5
+sample_aspect_ratio=1:1
+display_aspect_ratio=16:9
+pix_fmt=yuv420p
+level=123
+color_range=tv
+color_space=bt709
+color_transfer=bt709
+color_primaries=bt709
+chroma_location=unspecified
+field_order=unknown
+timecode=N/A
+refs=1
+id=0x551
+r_frame_rate=50/1
+avg_frame_rate=50/1
+time_base=1/9
+start_pts=2863340144
+start_time=31814.890489
+duration_ts=41400
+duration=0.46
+bit_rate=N/A
+max_bit_rate=N/A
+bits_per_raw_sample=N/A
+nb_frames=N/A
+nb_read_frames=N/A
+nb_read_packets=N/A
+DISPOSITION:default=0
+DISPOSITION:dub=0
+DISPOSITION:original=0
+DISPOSITION:comment=0
+DISPOSITION:lyrics=0
+DISPOSITION:karaoke=0
+DISPOSITION:forced=0
+DISPOSITION:hearing_impaired=0
+DISPOSITION:visual_impaired=0
+DISPOSITION:clean_effects=0
+DISPOSITION:attached_pic=0
+DISPOSITION:timed_thumbnails=0
+[/STREAM]
+[STREAM]
+index=1
+codec_name=aac_latm
+profile=1
+codec_type=audio
+codec_time_base=1/48000
+codec_tag_string=[15][0][0][0]
+codec_tag=0x000

Re: [FFmpeg-devel] Deprecation of visual output devices

[James Almer]

On 9/27/2017 12:01 PM, wm4 wrote:
> On Wed, 27 Sep 2017 16:34:49 +0200
> Michael Niedermayer  wrote:
> 
>> On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
>>> Hi,
>>>
>>> There is no point of having these output devices as all the
>>> functionality is contained in the 'ffplay' tool. If people wanted to
>>> integrate these devices in their own programs instead of using the
>>> ffmpeg tool then they are far too constrained for proper control, not to  
>>
>>> mention output devices have been quick hacky in libavdevice for a long  
>>
>> then please write a better API / lib / system
> 
> It should never have been added this way. Why did it happen? On that
> note, I tried to prevent it, and to argue that the contributor should
> have created a better API instead of badly hacking it into libavdevice.
> 
> Why do you suddenly think there is a strong argument for keeping it?
> 
>>> time. There are three patches attached to deprecate the SDL2, OpenGL,
>>> and libcaca devices.  
>>
>> Once a better system exists with these features this can be deprecated.
> 
>> requiring each user application to directly support each API of each
>> of these systems is very inconvenient for all but the large applications
> 
> There are entire frameworks for abstracting these things. libavdevice
> is one of them, but only as a joke.
> 
>> Indeed the large applications benefit from the absence of a single API
>> as they eliminate competition from smaller apps which are unable to
>> maintain support for a wide range of output devices.
>>
>> I think a good API that supports a wide range of in/out devices would
>> be very usefull for smaller/simpler applications using the libs
> 
> Name a user of these APIs.
> 
> Your argumentation is full of fallacies. We don't actually do any of
> those things for applications. As far as I'm aware, only the person who
> added this API is even using it. Are you even aware that ffplay doesn't
> use this API?
> 
> I'm sick of this attitude to keep bad/broken stuff just so that we
> "have it". Supporting a feature is meaningless if it's low quality.
> Maybe one day you will learn this.

We can't just remove something that works and has a defined use, as much
as it's disliked, without at least come up with a replacement or a good
reason why it's being dropped without a replacement. And by good reason
i mean something like "This is in the way of this other useful thing
that we're trying to add/achieve". If that happens, i assume not a lot
of people will speak in favor of lavd.

> 
> I can't way for the day libavdevice or libavfilter will grow a UI
> toolkit.
> ___
> 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] Deprecation of visual output devices

[Carl Eugen Hoyos]

2017-09-27 15:18 GMT+02:00 Josh de Kock :

> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

I use at least sdl and opengl regularly for tests that cannot
be done with ffplay.

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

Re: [FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Carl Eugen Hoyos]

2017-09-27 16:43 GMT+02:00 Anonymous Maarten :

> Building the static ffmpeg library using vcpkg is currently broken [1][2].
> This is mainly due to the fact that the built static libraries are .a files
> with lib prefixes.

Did this work with older versions of any of the involved tools
(including FFmpeg)?

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 16:34:49 +0200
Michael Niedermayer  wrote:

> On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> > Hi,
> > 
> > There is no point of having these output devices as all the
> > functionality is contained in the 'ffplay' tool. If people wanted to
> > integrate these devices in their own programs instead of using the
> > ffmpeg tool then they are far too constrained for proper control, not to  
> 
> > mention output devices have been quick hacky in libavdevice for a long  
> 
> then please write a better API / lib / system

It should never have been added this way. Why did it happen? On that
note, I tried to prevent it, and to argue that the contributor should
have created a better API instead of badly hacking it into libavdevice.

Why do you suddenly think there is a strong argument for keeping it?

> > time. There are three patches attached to deprecate the SDL2, OpenGL,
> > and libcaca devices.  
> 
> Once a better system exists with these features this can be deprecated.

> requiring each user application to directly support each API of each
> of these systems is very inconvenient for all but the large applications

There are entire frameworks for abstracting these things. libavdevice
is one of them, but only as a joke.

> Indeed the large applications benefit from the absence of a single API
> as they eliminate competition from smaller apps which are unable to
> maintain support for a wide range of output devices.
> 
> I think a good API that supports a wide range of in/out devices would
> be very usefull for smaller/simpler applications using the libs

Name a user of these APIs.

Your argumentation is full of fallacies. We don't actually do any of
those things for applications. As far as I'm aware, only the person who
added this API is even using it. Are you even aware that ffplay doesn't
use this API?

I'm sick of this attitude to keep bad/broken stuff just so that we
"have it". Supporting a feature is meaningless if it's low quality.
Maybe one day you will learn this.

I can't way for the day libavdevice or libavfilter will grow a UI
toolkit.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Create .lib static libraries on Windows instead of .a libraries (using MSVC compiler)

[Anonymous Maarten]

Hey,

Building the static ffmpeg library using vcpkg is currently broken [1][2].
This is mainly due to the fact that the built static libraries are .a files
with lib prefixes.

The attached patch sets the lib prefix to "" and the lib suffix to ".lib".

Tested by building ffmpeg using vcpkg and Visual Studio 2017 Community
Edition on Windows 10.
The resulted libraries link correctly to my application.

[1]
https://github.com/Microsoft/vcpkg/blob/084b1afe9af1690916fab95bbb80c6891109f0fc/ports/ffmpeg/portfile.cmake#L1-L4
[2] https://github.com/Microsoft/vcpkg/issues/1821

Maarten,


0001-configure-create-.lib-static-libraries-using-MSVC-co.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Deprecation of visual output devices

[Michael Niedermayer]

On Wed, Sep 27, 2017 at 02:18:13PM +0100, Josh de Kock wrote:
> Hi,
> 
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to

> mention output devices have been quick hacky in libavdevice for a long

then please write a better API / lib / system


> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.

Once a better system exists with these features this can be deprecated.
requiring each user application to directly support each API of each
of these systems is very inconvenient for all but the large applications

Indeed the large applications benefit from the absence of a single API
as they eliminate competition from smaller apps which are unable to
maintain support for a wide range of output devices.

I think a good API that supports a wide range of in/out devices would
be very usefull for smaller/simpler applications using the libs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

On 27.09.2017 15:50, Paul B Mahol wrote:

On 9/27/17, Tobias Rapp  wrote:

Signed-off-by: Tobias Rapp 
---
  libavfilter/f_metadata.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)



lgtm


Pushed both patches.

Thanks,
Tobias

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Martin Vignali]

2017-09-27 15:33 GMT+02:00 Tom Butterworth :

>
>
> > On 27 Sep 2017, at 14:20, Martin Vignali 
> wrote:
> >
> > 2017-09-27 13:25 GMT+02:00 Tom Butterworth  bangno...@gmail.com>>:
> >
> >>
> >>
> >>> On 27 Sep 2017, at 11:59, Martin Vignali 
> >> wrote:
> >>>
> 
> > +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> > +avctx->pix_fmt = AV_PIX_FMT_RGB0;
> 
>  The rgtc1u_block function places the single channel value in every
> >> channel
>  except the alpha channel
>  The pixel format you have chosen is one which disregards the alpha
> >> channel
> 
>  The output of this alpha-only decoder should be in the alpha channel
> of
> >> a
>  pixel format which carries alpha. Probably other channels should have
> >> zero
>  values.
> 
> 
> >>> Hi Tom,
> >>>
> >>> After Carl answer, and thinking about that,
> >>> The goal of HapAlphaOnly, is to store alpha, but can also store gray
> only
> >>> (much better than HAP)
> >>> In fact, it can be call HAP Gray !
> >>
> >> But it isn’t
> >>
> >>> For example from my part, i would like to use this codec, for matte,
> but
> >>> also for gray only layer (use with color blending)
> >>
> >> This is fine, but let’s concentrate on supporting Hap Alpha Only, not
> your
> >> non-standard use of it. If you would like this flexibility in Hap, that
> >> should be argued for on the Hap project, not within FFmpeg.
> >>
> >> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and
> the
> >> implementation in FFmpeg must follow the definition (see
> >> https://github.com/Vidvox/hap/blob/master/documentation/
> HapVideoDRAFT.md <
> >> https://github.com/Vidvox/hap/blob/master/documentation/
> HapVideoDRAFT.md  HapVideoDRAFT.md>>
> >> ).
> >>
> >> The Alpha Only encoder and decoder must ingest and emit a pixel format
> >> which carries alpha. It may be that adding a new alpha-only pixel
> format is
> >> not seen as desirable, in which case an existing format with alpha
> should
> >> be selected. This allows users to, eg, transcode from an RGBA format to
> Hap
> >> Alpha Only and have the channel they expect be preserved from the input
> >> video. Any other behaviour (eg having RGB converted to grey and then
> stored
> >> as alpha) is not acceptable.
> >>
> >>> If a user want to compress a gray picture, it can be done using RGB to
> >> Gray
> >>> conversion
> >>> And if user want to compress only alpha or a specific channel, i think
> >>> ffmpeg have a filter for that (extractplanes (untested)),
> >>
> >> Your non-standard usage can still be achieved by channel switching in a
> >> filter, the default behaviour must be according to the standard, which
> is
> >> to encode and decode the alpha channel.
> >>
> >> Cheers - Tom
> >>  http://ffmpeg.org/mailman/listinfo/ffmpeg-devel>>
> >>
> >
> >
> > Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> > alpha from RGBA input)
> > I will change the 24 to 32 as requested and send a new patch
> >
> > Before sending a new patch for the decoding :
> > did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
> > for RGTC1 alpha decoding in RGBA ?
>
> Personally I’d think 0 to allow further operations to eg combine the image
> with one with colour channels to work as expected.
>
> Ok, i will do that,
so i can have the same decoding func in texture dsp that the one use for
hapqa_decoding.

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

Re: [FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Paul B Mahol]

On 9/27/17, Tobias Rapp  wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  libavfilter/f_metadata.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Tom Butterworth]

> On 27 Sep 2017, at 14:20, Martin Vignali  wrote:
> 
> 2017-09-27 13:25 GMT+02:00 Tom Butterworth  >:
> 
>> 
>> 
>>> On 27 Sep 2017, at 11:59, Martin Vignali 
>> wrote:
>>> 
 
> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
 
 The rgtc1u_block function places the single channel value in every
>> channel
 except the alpha channel
 The pixel format you have chosen is one which disregards the alpha
>> channel
 
 The output of this alpha-only decoder should be in the alpha channel of
>> a
 pixel format which carries alpha. Probably other channels should have
>> zero
 values.
 
 
>>> Hi Tom,
>>> 
>>> After Carl answer, and thinking about that,
>>> The goal of HapAlphaOnly, is to store alpha, but can also store gray only
>>> (much better than HAP)
>>> In fact, it can be call HAP Gray !
>> 
>> But it isn’t
>> 
>>> For example from my part, i would like to use this codec, for matte, but
>>> also for gray only layer (use with color blending)
>> 
>> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
>> non-standard use of it. If you would like this flexibility in Hap, that
>> should be argued for on the Hap project, not within FFmpeg.
>> 
>> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
>> implementation in FFmpeg must follow the definition (see
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
>> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md 
>> >
>> ).
>> 
>> The Alpha Only encoder and decoder must ingest and emit a pixel format
>> which carries alpha. It may be that adding a new alpha-only pixel format is
>> not seen as desirable, in which case an existing format with alpha should
>> be selected. This allows users to, eg, transcode from an RGBA format to Hap
>> Alpha Only and have the channel they expect be preserved from the input
>> video. Any other behaviour (eg having RGB converted to grey and then stored
>> as alpha) is not acceptable.
>> 
>>> If a user want to compress a gray picture, it can be done using RGB to
>> Gray
>>> conversion
>>> And if user want to compress only alpha or a specific channel, i think
>>> ffmpeg have a filter for that (extractplanes (untested)),
>> 
>> Your non-standard usage can still be achieved by channel switching in a
>> filter, the default behaviour must be according to the standard, which is
>> to encode and decode the alpha channel.
>> 
>> Cheers - Tom
>> > >
>> 
> 
> 
> Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
> alpha from RGBA input)
> I will change the 24 to 32 as requested and send a new patch
> 
> Before sending a new patch for the decoding :
> did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
> for RGTC1 alpha decoding in RGBA ?

Personally I’d think 0 to allow further operations to eg combine the image with 
one with colour channels to work as expected.

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Nicolas George]

Le sextidi 6 vendémiaire, an CCXXVI, Josh de Kock a écrit :
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool.

ffplay is not a library.

>  If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control

Maybe for your needs. Do not generalize.

Regards,

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

[FFmpeg-devel] [PATCH v5 2/2] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).

Signed-off-by: Tobias Rapp 
---
tested on Linux x86-32/64 and Mips (Qemu)

v5:
  - fixed trailing whitespace within reference files

v4:
  - fixed iteration order of final print loop
  - update of debug output

v3:
  - avoid precision loss due to rounding of float values

v2:
  - removed CPUFLAGS work-around for ssim filter issue
  - added metadata float value post-processing script

 tests/fate-run.sh |  9 +
 tests/fate/filter-video.mak   | 14 
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 
 tests/refcmp-metadata.awk | 64 +++
 7 files changed, 237 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
 create mode 100644 tests/refcmp-metadata.awk

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9aa9a22..c5480c7 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -234,6 +234,15 @@ lavftest(){
 ${base}/lavf-regression.sh $t lavf tests/vsynth1 "$target_exec" 
"$target_path" "$threads" "$thread_type" "$cpuflags" "$target_samples"
 }
 
+refcmp_metadata(){
+refcmp=$1
+pixfmt=$2
+fuzz=${3:-0.001}
+ffmpeg $FLAGS $ENC_OPTS \
+-lavfi 
"testsrc2=size=300x200:rate=1:duration=5,format=${pixfmt},split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]${refcmp},metadata=print:file=-"
 \
+-f null /dev/null | awk -v ref=${ref} -v fuzz=${fuzz} -f 
${base}/refcmp-metadata.awk -
+}
+
 video_filter(){
 filters=$1
 shift
diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d1e1341..78cd471 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -747,6 +747,20 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+REFCMP_DEPS = FFMPEG LAVFI_INDEV TESTSRC2_FILTER AVGBLUR_FILTER METADATA_FILTER
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-rgb
+fate-filter-refcmp-psnr-rgb: CMD = refcmp_metadata psnr rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) PSNR_FILTER) += 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr-yuv: CMD = refcmp_metadata psnr yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-rgb
+fate-filter-refcmp-ssim-rgb: CMD = refcmp_metadata ssim rgb24
+
+FATE_FILTER_SAMPLES-$(call ALLYES, $(REFCMP_DEPS) SSIM_FILTER) += 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim-yuv: CMD = refcmp_metadata ssim yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..f06db57
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..0e634ed
--- /dev/null
+++ b/tests/ref/fate/f

[FFmpeg-devel] [PATCH v5 1/2] avfilter/f_metadata: avoid trailing whitespace in filter output

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 libavfilter/f_metadata.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavfilter/f_metadata.c b/libavfilter/f_metadata.c
index 23bc254..523a94d 100644
--- a/libavfilter/f_metadata.c
+++ b/libavfilter/f_metadata.c
@@ -314,14 +314,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 break;
 case METADATA_PRINT:
 if (!s->key && e) {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, &inlink->time_base));
 s->print(ctx, "%s=%s\n", e->key, e->value);
 while ((e = av_dict_get(*metadata, "", e, AV_DICT_IGNORE_SUFFIX)) 
!= NULL) {
 s->print(ctx, "%s=%s\n", e->key, e->value);
 }
 } else if (e && e->value && (!s->value || (e->value && s->compare(s, 
e->value, s->value {
-s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%-7s\n",
+s->print(ctx, "frame:%-4"PRId64" pts:%-7s pts_time:%s\n",
  inlink->frame_count_out, av_ts2str(frame->pts), 
av_ts2timestr(frame->pts, &inlink->time_base));
 s->print(ctx, "%s=%s\n", s->key, e->value);
 }
-- 
2.7.4


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

Re: [FFmpeg-devel] Deprecation of visual output devices

[Paul B Mahol]

On 9/27/17, Josh de Kock  wrote:
> Hi,
>
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to
> mention output devices have been quick hacky in libavdevice for a long
> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.
>
> --
> Josh
>

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

Re: [FFmpeg-devel] Deprecation of visual output devices

[wm4]

On Wed, 27 Sep 2017 14:18:13 +0100
Josh de Kock  wrote:

> Hi,
> 
> There is no point of having these output devices as all the
> functionality is contained in the 'ffplay' tool. If people wanted to
> integrate these devices in their own programs instead of using the
> ffmpeg tool then they are far too constrained for proper control, not to
> mention output devices have been quick hacky in libavdevice for a long
> time. There are three patches attached to deprecate the SDL2, OpenGL,
> and libcaca devices.
> 

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

Re: [FFmpeg-devel] libavcodec/hapdec : add support for HapAphaOnly decoding

[Martin Vignali]

2017-09-27 13:25 GMT+02:00 Tom Butterworth :

>
>
> > On 27 Sep 2017, at 11:59, Martin Vignali 
> wrote:
> >
> >>
> >>> +ctx->tex_fun = ctx->dxtc.rgtc1u_block;
> >>> +avctx->pix_fmt = AV_PIX_FMT_RGB0;
> >>
> >> The rgtc1u_block function places the single channel value in every
> channel
> >> except the alpha channel
> >> The pixel format you have chosen is one which disregards the alpha
> channel
> >>
> >> The output of this alpha-only decoder should be in the alpha channel of
> a
> >> pixel format which carries alpha. Probably other channels should have
> zero
> >> values.
> >>
> >>
> > Hi Tom,
> >
> > After Carl answer, and thinking about that,
> > The goal of HapAlphaOnly, is to store alpha, but can also store gray only
> > (much better than HAP)
> > In fact, it can be call HAP Gray !
>
> But it isn’t
>
> > For example from my part, i would like to use this codec, for matte, but
> > also for gray only layer (use with color blending)
>
> This is fine, but let’s concentrate on supporting Hap Alpha Only, not your
> non-standard use of it. If you would like this flexibility in Hap, that
> should be argued for on the Hap project, not within FFmpeg.
>
> Hap Alpha Only is defined as an *alpha* channel stored in RGTC1U, and the
> implementation in FFmpeg must follow the definition (see
> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md <
> https://github.com/Vidvox/hap/blob/master/documentation/HapVideoDRAFT.md>
> ).
>
> The Alpha Only encoder and decoder must ingest and emit a pixel format
> which carries alpha. It may be that adding a new alpha-only pixel format is
> not seen as desirable, in which case an existing format with alpha should
> be selected. This allows users to, eg, transcode from an RGBA format to Hap
> Alpha Only and have the channel they expect be preserved from the input
> video. Any other behaviour (eg having RGB converted to grey and then stored
> as alpha) is not acceptable.
>
> > If a user want to compress a gray picture, it can be done using RGB to
> Gray
> > conversion
> > And if user want to compress only alpha or a specific channel, i think
> > ffmpeg have a filter for that (extractplanes (untested)),
>
> Your non-standard usage can still be achieved by channel switching in a
> filter, the default behaviour must be according to the standard, which is
> to encode and decode the alpha channel.
>
> Cheers - Tom
> 
>


Ok, in that case, the HAP Alpha Encoding current patch is fine (it take
alpha from RGBA input)
I will change the 24 to 32 as requested and send a new patch

Before sending a new patch for the decoding :
did you think, it's better to have [255,255,255, alpha] or [0,0,0, alpha]
for RGTC1 alpha decoding in RGBA ?

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

[FFmpeg-devel] Deprecation of visual output devices

[Josh de Kock]

Hi,

There is no point of having these output devices as all the
functionality is contained in the 'ffplay' tool. If people wanted to
integrate these devices in their own programs instead of using the
ffmpeg tool then they are far too constrained for proper control, not to
mention output devices have been quick hacky in libavdevice for a long
time. There are three patches attached to deprecate the SDL2, OpenGL,
and libcaca devices.

-- 
Josh
From f950674e8893da8438ade6cee1050062d2bfb86c Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:26:19 +0100
Subject: [PATCH 1/3] lavd: deprecate libcaca output device

Signed-off-by: Josh de Kock 
---
 libavdevice/caca.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/caca.c b/libavdevice/caca.c
index 93cc0ffd25..31cb94eda9 100644
--- a/libavdevice/caca.c
+++ b/libavdevice/caca.c
@@ -95,6 +95,8 @@ static int caca_write_header(AVFormatContext *s)
 AVCodecParameters *encctx = st->codecpar;
 int ret, bpp;
 
+av_log(s, AV_LOG_WARNING, "The libcaca output device is DEPRECATED and 
will be removed in a future version.\n");
+
 c->ctx = s;
 if (c->list_drivers) {
 list_drivers(c);
-- 
2.11.0 (Apple Git-81)

From da4aba837ff0effe873ea16d17100397843db464 Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:27:53 +0100
Subject: [PATCH 2/3] lavd: deprecate opengl output device

Signed-off-by: Josh de Kock 
---
 libavdevice/opengl_enc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index bb6787c6f1..046383066f 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -1054,6 +1054,8 @@ static av_cold int opengl_write_header(AVFormatContext *h)
 AVStream *st;
 int ret;
 
+av_log(h, AV_LOG_WARNING, "The OpenGL output device is DEPRECATED and will 
be removed in a future version.\n");
+
 if (h->nb_streams != 1 ||
 h->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO ||
 h->streams[0]->codecpar->codec_id != AV_CODEC_ID_RAWVIDEO) {
-- 
2.11.0 (Apple Git-81)

From 7c576e6acfa04cec6df9f8a59d98bacf43a44938 Mon Sep 17 00:00:00 2001
From: Josh de Kock 
Date: Wed, 27 Sep 2017 13:28:47 +0100
Subject: [PATCH 3/3] lavd: deprecate SDL2 output device

Signed-off-by: Josh de Kock 
---
 libavdevice/sdl2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c
index 5d9e91ec21..e53637eb42 100644
--- a/libavdevice/sdl2.c
+++ b/libavdevice/sdl2.c
@@ -164,6 +164,8 @@ static int sdl2_write_header(AVFormatContext *s)
 int i, ret = 0;
 int flags  = 0;
 
+av_log(s, AV_LOG_WARNING, "The SDL2 output device is DEPRECATED and will 
be removed in a future version.\n");
+
 if (!sdl->window_title)
 sdl->window_title = av_strdup(s->filename);
 
-- 
2.11.0 (Apple Git-81)

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

Re: [FFmpeg-devel] [PATCH] avcodec/v4l2_m2m: fix draining process (dequeue without input)

[wm4]

On Tue, 26 Sep 2017 16:22:23 -0700
Jorge Ramirez-Ortiz  wrote:

> Stopping the codec when no more input is available causes captured
> buffers that might be ready to be dequeued to be invalidated.
> 
> This commit follows the V4L2 API more closely:
> 1. on the last valid input buffer, it sets the V4L2_BUF_FLAG_LAST.
> 2. ffmpeg then will continue dequeuing captured buffers until EPIPE is
> raised by the driver (EOF condition)
> 
> This also has the advantage of making the timeout on dequeuing capture
> buffers while draining unnecessary.
> ---
>  libavcodec/v4l2_context.c | 162 
> ++
>  1 file changed, 64 insertions(+), 98 deletions(-)

I can't really comment on the logic of this code. So LGTM, just some
minor comments/questions.

> -/* 0. handle errors */
> +/* handle errors */

(Apparently) unrelated cosmetic changes should usually be in separate
patches, but that's probably not worth the trouble in this case.

> +if (!frame) {
> +/* flag that we are draining */
> +ctx_to_m2mctx(ctx)->draining = 1;
> +
> +/* send EOS */
> +avbuf->buf.m.planes[0].bytesused = 1;
> +avbuf->flags |= V4L2_BUF_FLAG_LAST;
> +} else {
> +ret = ff_v4l2_buffer_avframe_to_buf(frame, avbuf);
> +if (ret)
> +return ret;
> +}

Wouldn't it be better to switch the if/else bodies and avoid the
negation in the if condition?

> -ret = ff_v4l2_buffer_avpkt_to_buf(pkt, avbuf);
> -if (ret)
> -return ret;
> +if (!pkt->size) {
> +/* flag that we are draining */
> +ctx_to_m2mctx(ctx)->draining = 1;
> +
> +/* send EOS */
> +avbuf->buf.m.planes[0].bytesused = 1;
> +avbuf->flags |= V4L2_BUF_FLAG_LAST;

What is going on here? Dummy buffer of size 1 to send the flag?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel