[FFmpeg-devel] [PATCH] libavcodec/fft_template: improve performance of the ff_fft_init in fft_template

2018-12-17 Thread Steven Liu
After patch:
init nbits = 17, get 1 samples, duration: 15221
Before patch:
init nbits = 17, get 1 samples, duration: 16105

test script:
DURATION=0
for((i=0;i<1;i++)) do
./libavcodec/tests/fft -n 17 &>output
T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
DURATION=`expr $DURATION + $T_DURATION`
done
TOTAL=`expr $DURATION / 1`
echo $TOTAL

Signed-off-by: Steven Liu 
---
 libavcodec/fft_template.c | 27 +--
 1 file changed, 17 insertions(+), 10 deletions(-)

diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
index 762c014bc8..5f6f52275d 100644
--- a/libavcodec/fft_template.c
+++ b/libavcodec/fft_template.c
@@ -257,21 +257,28 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int 
inverse)
 }
 #endif /* FFT_FIXED_32 */
 
+#define SPLIT_RADIX_PERMUTATION(num) \
+for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS) \
+j = (j&~3) | ((j>>1)&1) | ((j<<1)&2); \
+k = -split_radix_permutation(i, n, s->inverse) & (n-1); \
+j = (j&~3) | ((j>>1)&1) | ((j<<1)&2); \
+k = -split_radix_permutation(i, n, s->inverse) & (n-1); \
+s->revtab##num[k] = j; \
+}
 
 if (s->fft_permutation == FF_FFT_PERM_AVX) {
 fft_perm_avx(s);
 } else {
-for(i=0; ifft_permutation == FF_FFT_PERM_SWAP_LSBS)
-j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
-k = -split_radix_permutation(i, n, s->inverse) & (n-1);
-if (s->revtab)
-s->revtab[k] = j;
-if (s->revtab32)
-s->revtab32[k] = j;
+if (s->revtab) {
+SPLIT_RADIX_PERMUTATION()
+}
+if (s->revtab32) {
+SPLIT_RADIX_PERMUTATION(32)
 }
+#undef SPLIT_RADIX_PERMUTATION
 }
 
 return 0;
-- 
2.15.2 (Apple Git-101.1)



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


[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] enable MSA optimization for loongson platform.

2018-12-17 Thread Shiyou Yin
Set initialization order of MSA after MMI to make it work on loongson 
platform(msa is supported by loongson2k、3a4000 etc.).
---
 libavcodec/mips/blockdsp_init_mips.c| 6 +++---
 libavcodec/mips/h264chroma_init_mips.c  | 6 +++---
 libavcodec/mips/h264dsp_init_mips.c | 6 +++---
 libavcodec/mips/h264pred_init_mips.c| 6 +++---
 libavcodec/mips/h264qpel_init_mips.c| 6 +++---
 libavcodec/mips/hpeldsp_init_mips.c | 6 +++---
 libavcodec/mips/idctdsp_init_mips.c | 6 +++---
 libavcodec/mips/mpegvideo_init_mips.c   | 6 +++---
 libavcodec/mips/pixblockdsp_init_mips.c | 6 +++---
 libavcodec/mips/vp8dsp_init_mips.c  | 6 +++---
 10 files changed, 30 insertions(+), 30 deletions(-)

diff --git a/libavcodec/mips/blockdsp_init_mips.c 
b/libavcodec/mips/blockdsp_init_mips.c
index 30ae95f..55ac1c3 100644
--- a/libavcodec/mips/blockdsp_init_mips.c
+++ b/libavcodec/mips/blockdsp_init_mips.c
@@ -45,10 +45,10 @@ static av_cold void blockdsp_init_mmi(BlockDSPContext *c)
 
 void ff_blockdsp_init_mips(BlockDSPContext *c)
 {
-#if HAVE_MSA
-blockdsp_init_msa(c);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 blockdsp_init_mmi(c);
 #endif /* HAVE_MMI */
+#if HAVE_MSA
+blockdsp_init_msa(c);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/h264chroma_init_mips.c 
b/libavcodec/mips/h264chroma_init_mips.c
index 122148d..ae817e4 100644
--- a/libavcodec/mips/h264chroma_init_mips.c
+++ b/libavcodec/mips/h264chroma_init_mips.c
@@ -54,10 +54,10 @@ static av_cold void h264chroma_init_mmi(H264ChromaContext 
*c, int bit_depth)
 
 av_cold void ff_h264chroma_init_mips(H264ChromaContext *c, int bit_depth)
 {
-#if HAVE_MSA
-h264chroma_init_msa(c, bit_depth);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 h264chroma_init_mmi(c, bit_depth);
 #endif /* HAVE_MMI */
+#if HAVE_MSA
+h264chroma_init_msa(c, bit_depth);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/h264dsp_init_mips.c 
b/libavcodec/mips/h264dsp_init_mips.c
index 1fe7f84..dc08a25 100644
--- a/libavcodec/mips/h264dsp_init_mips.c
+++ b/libavcodec/mips/h264dsp_init_mips.c
@@ -138,10 +138,10 @@ static av_cold void h264dsp_init_mmi(H264DSPContext * c, 
const int bit_depth,
 av_cold void ff_h264dsp_init_mips(H264DSPContext *c, const int bit_depth,
   const int chroma_format_idc)
 {
-#if HAVE_MSA
-h264dsp_init_msa(c, bit_depth, chroma_format_idc);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 h264dsp_init_mmi(c, bit_depth, chroma_format_idc);
 #endif /* HAVE_MMI */
+#if HAVE_MSA
+h264dsp_init_msa(c, bit_depth, chroma_format_idc);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/h264pred_init_mips.c 
b/libavcodec/mips/h264pred_init_mips.c
index c33d8f7..63637b8 100644
--- a/libavcodec/mips/h264pred_init_mips.c
+++ b/libavcodec/mips/h264pred_init_mips.c
@@ -146,10 +146,10 @@ av_cold void ff_h264_pred_init_mips(H264PredContext *h, 
int codec_id,
 int bit_depth,
 const int chroma_format_idc)
 {
-#if HAVE_MSA
-h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 h264_pred_init_mmi(h, codec_id, bit_depth, chroma_format_idc);
 #endif /* HAVE_MMI */
+#if HAVE_MSA
+h264_pred_init_msa(h, codec_id, bit_depth, chroma_format_idc);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/h264qpel_init_mips.c 
b/libavcodec/mips/h264qpel_init_mips.c
index 92219f8..33bae30 100644
--- a/libavcodec/mips/h264qpel_init_mips.c
+++ b/libavcodec/mips/h264qpel_init_mips.c
@@ -240,10 +240,10 @@ static av_cold void h264qpel_init_mmi(H264QpelContext *c, 
int bit_depth)
 
 av_cold void ff_h264qpel_init_mips(H264QpelContext *c, int bit_depth)
 {
-#if HAVE_MSA
-h264qpel_init_msa(c, bit_depth);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 h264qpel_init_mmi(c, bit_depth);
 #endif /* HAVE_MMI */
+#if HAVE_MSA
+h264qpel_init_msa(c, bit_depth);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/hpeldsp_init_mips.c 
b/libavcodec/mips/hpeldsp_init_mips.c
index 363a045..d6f7a97 100644
--- a/libavcodec/mips/hpeldsp_init_mips.c
+++ b/libavcodec/mips/hpeldsp_init_mips.c
@@ -113,10 +113,10 @@ static void ff_hpeldsp_init_mmi(HpelDSPContext *c, int 
flags)
 
 void ff_hpeldsp_init_mips(HpelDSPContext *c, int flags)
 {
-#if HAVE_MSA
-ff_hpeldsp_init_msa(c, flags);
-#endif  // #if HAVE_MSA
 #if HAVE_MMI
 ff_hpeldsp_init_mmi(c, flags);
 #endif  // #if HAVE_MMI
+#if HAVE_MSA
+ff_hpeldsp_init_msa(c, flags);
+#endif  // #if HAVE_MSA
 }
diff --git a/libavcodec/mips/idctdsp_init_mips.c 
b/libavcodec/mips/idctdsp_init_mips.c
index bb33b55..85b76ca 100644
--- a/libavcodec/mips/idctdsp_init_mips.c
+++ b/libavcodec/mips/idctdsp_init_mips.c
@@ -65,10 +65,10 @@ static av_cold void idctdsp_init_mmi(IDCTDSPContext *c, 
AVCodecContext *avctx,
 av_cold void ff_idctdsp_init_mips(IDCTDSPContext *c, AVCodecContext *avctx,
   unsigned high_bit_depth)
 {
-#if HAVE_MSA
-idctdsp_init_msa(

Re: [FFmpeg-devel] NUT end timestamp

2018-12-17 Thread Paul B Mahol
On 12/14/18, Michael Niedermayer  wrote:
> Hi
>
> replying to a comment from IRC here because "durandal_1707 has quit" so it
> wouldnt be seen, and might be interresting for others so not mailing
> private
>
>  michaelni: nut does not take into consideration duration of
> last frame to return real duration
>  michaelni: so duration is always smaller by small amount
>  michaelni: looks like design failure
>
> Its a bit ago that i worked on nut but the last frame duration was
> considered,
> i do remember there was discussion about it.
>
> looking at nut.txt, it says this:
> All streams SHOULD end with EOR, where the pts of the EOR indicates the
> end presentation time of the final frame.
>
> That stores and gives the last duration. Our muxer seems to not implement
> this
> so its a implementation issue not a design one

If one need to parse all packets to get last duration that is flawed design.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available

2018-12-17 Thread Jan Ekström
On Sat, Dec 15, 2018, 20:50 Jan Ekström  Fixes issues when a subtitle packet is received before PCR for the
> program has been received, leading to wildly jumping timestamps
> on the lavf client side as well as in the re-ordering logic.
>
> This usually happens in case of multiplexes where the PCR of a
> program is not taken into account with subtitle tracks' DTS/PTS.
> --


Friendly ping. Sample where this improves the result is linked in the first
attempt @ https://patchwork.ffmpeg.org/patch/11419/

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


Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak

2018-12-17 Thread Valery Kot
I just verified that patch is working. Build FFmpeg master with and
without patch, run HLS live stream from Youtube (extracted by
youtube_dl for Euronews live).

ffmpeg -i 
https://manifest.googlevideo.com/api/manifest/hls_playlist/id/V2E-jOUVsd4.1/itag/95/source/yt_live_broadcast/requiressl/yes/ratebypass/yes/live/1/cmbypass/yes/goi/160/sgoap/gir%3Dyes%3Bitag%3D140/sgovp/gir%3Dyes%3Bitag%3D136/hls_chunk_host/r4---sn-5hnedn7e.googlevideo.com/ei/E2sXXOrRGdjGgAe_6abgBA/gcr/nl/playlist_type/DVR/initcwndbps/12170/mm/32/mn/sn-5hnedn7e/ms/lv/mv/m/pl/24/dover/11/keepalive/yes/mt/1545038545/disable_polymer/true/ip/80.255.245.45/ipbits/0/expire/1545060211/sparams/ip,ipbits,expire,id,itag,source,requiressl,ratebypass,live,cmbypass,goi,sgoap,sgovp,hls_chunk_host,ei,gcr,playlist_type,initcwndbps,mm,mn,ms,mv,pl/signature/517F67575565239FC2D7117212AB722FB68BA3A6.4A8F847C14BF8C702103AEC348C8AC553E812ECE/key/dg_yt0/playlist/index.m3u8
 -c copy -t 3 -f mpegts -y NUL 2> _out.txt

Checking process memory (private working set) in Task Manager
Both instances start at 27MB RAM footprint.
Patched version within a minute grows to 31 MB and then stable.
Unmodified master RAM keeps growing, and after one hour reaches 90MB.
Thus 59MB leak in an hour! And keeps growing...

Youtube updates variant playlists app. every 2 seconds, with 3600
fragments each. Means leak of 8(bytes)*3600(pointers in
prev_segments)*30*60(playlists per hour) = 54M - correlates with
experimental results.
Of course, youtube is an extreme case, but leak also degrades over
time any live HLS input.

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


Re: [FFmpeg-devel] [PATCH]lsws/utils: Split "emms_c(); " call in two lines

2018-12-17 Thread Michael Niedermayer
On Mon, Dec 17, 2018 at 02:14:26AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes a useless warning when compiling with clang on arm.
> 
> Please comment, Carl Eugen

>  utils.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> fb6799bbc59d79d9dfba9f8661aaecbed568f3a5  
> 0001-lsws-utils-Split-emms_c-in-two-lines.patch
> From b2773d1ca9473380b99400c2bbd5a6729622f51a Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Mon, 17 Dec 2018 02:12:13 +0100
> Subject: [PATCH] lsws/utils: Split "emms_c();" in two lines.
> 
> Silences a clang warning when not compiling for x86:
> libswscale/utils.c:345:13: warning: while loop has empty body
> ---
>  libswscale/utils.c |3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index df68bcc..de64694 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -342,7 +342,8 @@ static av_cold int initFilter(int16_t **outFilter, 
> int32_t **filterPos,
>  const int64_t fone = 1LL << (54 - FFMIN(av_log2(srcW/dstW), 8));
>  int ret= -1;
>  
> -emms_c(); // FIXME should not be required but IS (even for non-MMX 
> versions)
> +emms_c() // FIXME should not be required but IS (even for non-MMX 
> versions)
> +;

this looks like a bad change that could confuse people
i think a different solution should be found or the warning left if theres none

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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


Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

2018-12-17 Thread Ronak Patel

> On Dec 13, 2018, at 9:15 PM, Ronak Patel  
> wrote:
> 
> 
> 
>> On Dec 12, 2018, at 2:46 AM, Liu Steven  wrote:
>> 
>> 
>> 
 在 2018年12月12日,上午5:08,Ronak  写道:
 
 
 On Dec 11, 2018, at 3:28 PM, Gyan  wrote:
 
 
> On 12-12-2018 01:13 AM, Ronak wrote:
> 
> Looks like I found out why: 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L790. 
> The hlsenc.c file overwrites whatever I pass in the command line...
 
 That is a bug but there's still an error in your command. It should be,
 
 
  -hls_ts_options movflags=+skip_sidx
 
 This is because mp4 is a child muxer in this context. That hls option 
 should be renamed.
 
 Line 790 should be patched by adding + before frag_custom
>>> 
>>> That doesn't work.
>>> 
>>> ffmpeg -i input.mp4 -hls_ts_options movflags=+skip_sidx -codec copy 
>>> -hls_time 0.97523809523809 -hls_segment_type fmp4 -hls_flags single_file 
>>> -hls_playlist_type vod output.m3u8
>>> ffmpeg version N-92677-gdd7d6034f1 Copyright (c) 2000-2018 the FFmpeg 
>>> developers
>>> built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
>>> configuration: --prefix=/home/ronakp/ffmpeg_build 
>>> --pkg-config-flags=--static 
>>> --extra-cflags=-I/home/ronakp/ffmpeg_build/include 
>>> --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
>>> --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-libfdk_aac 
>>> --enable-libmp3lame --enable-libopus --enable-nonfree
>>> libavutil  56. 24.101 / 56. 24.101
>>> libavcodec 58. 42.100 / 58. 42.100
>>> libavformat58. 24.100 / 58. 24.100
>>> libavdevice58.  6.101 / 58.  6.101
>>> libavfilter 7. 46.101 /  7. 46.101
>>> libswscale  5.  4.100 /  5.  4.100
>>> libswresample   3.  4.100 /  3.  4.100
>>> libpostproc55.  4.100 / 55.  4.100
>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
>>> Metadata:
>>>  major_brand : isom
>>>  minor_version   : 1
>>>  compatible_brands: isom
>>>  creation_time   : 2013-11-14T18:23:26.00Z
>>> Duration: 02:39:09.39, start: 0.00, bitrate: 31 kb/s
>>>  Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 22050 Hz, mono, 
>>> fltp, 30 kb/s (default)
>>>  Metadata:
>>>creation_time   : 2013-11-14T18:23:26.00Z
>>>handler_name: GPAC ISO Audio Handler
>>> [hls @ 0x23e1b00] Opening 'output.m4s' for writing
>>> [hls @ 0x23e1b00] Some of provided format options in 'movflags=+skip_sidx' 
>>> are not recognized
>>> Could not write header for output file #0 (incorrect codec parameters ?): 
>>> Invalid argument
>>> Stream mapping:
>>> Stream #0:0 -> #0:0 (copy)
>>>  Last message repeated 1 times
>>> 
>>> Also, I think whatever options I set on the command line are going to be 
>>> overwritten by line 790 in hlsenc.c anyway no?
>> https://patchwork.ffmpeg.org/patch/11378/
>> 
>> Try this patch please :D
> 
> Thanks that works.
> 
> Let’s merge it!

Were you able to merge this patch?

> 
> 
>>> 
 
 Gyan
 
 ___
 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 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lsws/utils: Split "emms_c(); " call in two lines

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 13:24 GMT+01:00, Michael Niedermayer :
> On Mon, Dec 17, 2018 at 02:14:26AM +0100, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes a useless warning when compiling with clang on arm.
>>
>> Please comment, Carl Eugen
>
>>  utils.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> fb6799bbc59d79d9dfba9f8661aaecbed568f3a5
>> 0001-lsws-utils-Split-emms_c-in-two-lines.patch
>> From b2773d1ca9473380b99400c2bbd5a6729622f51a Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos 
>> Date: Mon, 17 Dec 2018 02:12:13 +0100
>> Subject: [PATCH] lsws/utils: Split "emms_c();" in two lines.
>>
>> Silences a clang warning when not compiling for x86:
>> libswscale/utils.c:345:13: warning: while loop has empty body
>> ---
>>  libswscale/utils.c |3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libswscale/utils.c b/libswscale/utils.c
>> index df68bcc..de64694 100644
>> --- a/libswscale/utils.c
>> +++ b/libswscale/utils.c
>> @@ -342,7 +342,8 @@ static av_cold int initFilter(int16_t **outFilter,
>> int32_t **filterPos,
>>  const int64_t fone = 1LL << (54 - FFMIN(av_log2(srcW/dstW), 8));
>>  int ret= -1;
>>
>> -emms_c(); // FIXME should not be required but IS (even for non-MMX
>> versions)
>> +emms_c() // FIXME should not be required but IS (even for non-MMX
>> versions)
>> +;
>
> this looks like a bad change that could confuse people
> i think a different solution should be found or the warning
> left if theres none

New patch attached.

Please comment, Carl Eugen
From 67f692d81792920f5344ceba239f64b2b9b4bec1 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 17 Dec 2018 14:28:35 +0100
Subject: [PATCH] lavu/internal: Add an empty body to "while(0)".

Fixes a clang warning if arch != x86:
libswscale/utils.c:345:13: warning: while loop has empty body
---
 libavutil/internal.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 06bd561..2a6e502 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -52,7 +52,7 @@
 #endif
 
 #ifndef emms_c
-#   define emms_c() while(0)
+#   define emms_c() while(0){}
 #endif
 
 #ifndef attribute_align_arg
-- 
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 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 7:58 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos 
>> 2018-12-17 1:58 GMT+01:00, Jan Ekström :

>> > So as far as it's been possible to test this, that's been done
>>
>> Could you point me to a dva1 sample?
>
> I have not seen any dolby vision samples with avc in the wild.
> You can ask Vittorio if he has some as he noted about
> possibly being able to ask for some before.

The patch is of course ok if Vittorio tested it with his samples.

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


Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize float yuv2plane1

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 8:37 GMT+01:00, Lauri Kasanen :
> On Mon, 17 Dec 2018 01:03:36 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2018-12-16 10:06 GMT+01:00, Lauri Kasanen :
>> > This function wouldn't benefit from VSX instructions, so I put it
>> > under altivec.
>> >
>> > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt
>> > grayf32le \
>> > -f null -vframes 100 -v error -nostats -
>> >
>> > 3743 UNITS in planar1,   65495 runs, 41 skips
>> >
>> > -cpuflags 0
>> >
>> > 23511 UNITS in planar1,   65530 runs,  6 skips
>> >
>> > grayf32be
>> >
>> > 4647 UNITS in planar1,   65449 runs, 87 skips
>> >
>> > -cpuflags 0
>> >
>> > 28608 UNITS in planar1,   65530 runs,  6 skips
>> >
>> > The native speedup is 6.28133, and the bswapping one 6.15623.
>>
>> > Fate passes
>>
>> I wonder a little how, given that grayf32 already breaks fate as-is...
>
> Are the tests for it disabled? fate.ffmpeg.org reports 100% success for
> many platforms.

Iirc, it is broken with --disable-sse

>> Note that this function / this pix_fmt currently has no real use-case
>> afaict.
>
> Is there a list of which pix fmts are useful? Of course I don't want to
> waste both my and reviewers' time, if the format is considered for
> removal or otherwise broken.

The pix_fmt is not deprecated (it's new), what I meant was that it is
currently only used for obscure monochrome Photoshop images
and one filter, so I am not sure optimizing this colour conversion
will help often.

But this is of course not very much related to this patch, sorry
for the noise!

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


Re: [FFmpeg-devel] [PATCH] libavcodec/fft_template: improve performance of the ff_fft_init in fft_template

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 10:13 GMT+01:00, Steven Liu :
> After patch:
> init nbits = 17, get 1 samples, duration: 15221
> Before patch:
> init nbits = 17, get 1 samples, duration: 16105
>
> test script:
> DURATION=0
> for((i=0;i<1;i++)) do
> ./libavcodec/tests/fft -n 17 &>output
> T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
> DURATION=`expr $DURATION + $T_DURATION`
> done
> TOTAL=`expr $DURATION / 1`
> echo $TOTAL

This script does not allow to reproduce afaict.
(There is no "duration" here in output)

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


[FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Adrian

Hello,

after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
muxed stopped working.
It looks like a regression introduced by 
223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and 
tested it cross-compiling for my project's target platform (ARM, 
Buildroot) and it seems like everything is in order. I ran regression 
tests and nothing seems to be broken.


Please review it and possibly include this patch.

Regards
Adrian Guzowski

>From 41a7a0d24942ab21338be6a74eec2c7a329d610f Mon Sep 17 00:00:00 2001
From: Adrian Guzowski 
Date: Mon, 17 Dec 2018 14:23:48 +0100
Subject: [PATCH] Fix usage of temp_file flag in hls_flags option.

This is a regression introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6.
It appears that regression was introduced in 4.1, 4.0.x does not share
this behaviour.

Temp files were not created for MPEG-TS segments options - HLS_TEMP_FILE
flag was never set on AVFormatContext, it is however set on HLSContext object.
In order to fix this issue, proper flags field must be checked. In addition,
renaming code was messed up and apparently was working only for MP4 files.
---
 libavformat/hlsenc.c | 60 
 1 file changed, 33 insertions(+), 27 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bdd2a113bd..021cfa884a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1357,8 +1357,9 @@ static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
 int ret = 0;
 char temp_filename[1024];
 int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - vs->nb_entries);
-const char *proto = avio_find_protocol_name(s->url);
-int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE);
+const char *proto = avio_find_protocol_name(vs->m3u8_name);
+int is_file_proto = proto && !strcmp(proto, "file");
+int use_temp_file = is_file_proto && (hls->flags & (HLS_TEMP_FILE | HLS_SINGLE_FILE)) == HLS_TEMP_FILE;
 static unsigned warned_non_file;
 char *key_uri = NULL;
 char *iv_string = NULL;
@@ -1381,7 +1382,7 @@ static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
 hls->version = 7;
 }
 
-if (!use_temp_file && !warned_non_file++)
+if (!is_file_proto && (hls->flags & HLS_TEMP_FILE) && !warned_non_file++)
 av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this may lead to races and temporary partial files\n");
 
 set_http_options(s, &options, hls);
@@ -1477,8 +1478,8 @@ static int hls_start(AVFormatContext *s, VariantStream *vs)
 AVFormatContext *oc = vs->avf;
 AVFormatContext *vtt_oc = vs->vtt_avf;
 AVDictionary *options = NULL;
-const char *proto = avio_find_protocol_name(s->url);
-int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE);
+const char *proto = NULL;
+int use_temp_file = 0;
 char *filename, iv_string[KEYSIZE*2 + 1];
 int err = 0;
 
@@ -1574,6 +1575,9 @@ static int hls_start(AVFormatContext *s, VariantStream *vs)
 
 set_http_options(s, &options, c);
 
+proto = avio_find_protocol_name(oc->url);
+use_temp_file = proto && !strcmp(proto, "file") && (c->flags & (HLS_TEMP_FILE | HLS_SINGLE_FILE)) == HLS_TEMP_FILE;
+
 if (use_temp_file) {
 char *new_name = av_asprintf("%s.tmp", oc->url);
 if (!new_name)
@@ -2142,8 +2146,8 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 int ret = 0, can_split = 1, i, j;
 int stream_index = 0;
 int range_length = 0;
-const char *proto = avio_find_protocol_name(s->url);
-int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE);
+const char *proto = NULL;
+int use_temp_file = 0;
 uint8_t *buffer = NULL;
 VariantStream *vs = NULL;
 AVDictionary *options = NULL;
@@ -2254,19 +2258,22 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
+if (oc->url[0]) {
+proto = avio_find_protocol_name(oc->url);
+use_temp_file = proto && !strcmp(proto, "file") && (hls->flags & (HLS_TEMP_FILE | HLS_SINGLE_FILE)) == HLS_TEMP_FILE;
+}
+
 // look to rename the asset name
-if (use_temp_file && oc->url[0]) {
+if (use_temp_file) {
 if (!(hls->flags & HLS_SINGLE_FILE) || (hls->max_seg_size <= 0))
-if ((vs->avf->oformat->priv_class && vs->avf->priv_data) && hls->segment_type != SEGMENT_TYPE_FMP4) {
+if ((vs->avf->oformat->priv_class && vs->avf->priv_data) && hls->segment_type != SEGMENT_TYPE_FMP4)
 av_opt_set(vs->avf->priv_data, "mpegts_flags", "resend_headers", 0);
-}
 }
 
 if (hls->segment_type == SEGMENT_TYPE_FMP4) {
 if (hls->flags & HLS_SINGLE_FILE) {
 ret = flush_dynbuf(vs, &range_length);
 if (ret < 0) {
-av_fr

Re: [FFmpeg-devel] [PATCH] libavcodec/fft_template: improve performance of the ff_fft_init in fft_template

2018-12-17 Thread Steven Liu


> On Dec 17, 2018, at 22:05, Carl Eugen Hoyos  wrote:
> 
> 2018-12-17 10:13 GMT+01:00, Steven Liu :
>> After patch:
>> init nbits = 17, get 1 samples, duration: 15221
>> Before patch:
>> init nbits = 17, get 1 samples, duration: 16105
>> 
>> test script:
>> DURATION=0
>> for((i=0;i<1;i++)) do
>> ./libavcodec/tests/fft -n 17 &>output
>> T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
>> DURATION=`expr $DURATION + $T_DURATION`
>> done
>> TOTAL=`expr $DURATION / 1`
>> echo $TOTAL
> 
> This script does not allow to reproduce afaict.
> (There is no "duration" here in output)
Do you mean i should commit 2/3 patch of the libavcodec/tests/fft.c modify?
or just upload the modify diff here?
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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


Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

2018-12-17 Thread Steven Liu


> On Dec 17, 2018, at 21:07, Ronak Patel  
> wrote:
> 
>> 
>> On Dec 13, 2018, at 9:15 PM, Ronak Patel  
>> wrote:
>> 
>> 
>> 
>>> On Dec 12, 2018, at 2:46 AM, Liu Steven  wrote:
>>> 
>>> 
>>> 
> 在 2018年12月12日,上午5:08,Ronak  写道:
> 
> 
> On Dec 11, 2018, at 3:28 PM, Gyan  wrote:
> 
> 
>> On 12-12-2018 01:13 AM, Ronak wrote:
>> 
>> Looks like I found out why: 
>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L790. 
>> The hlsenc.c file overwrites whatever I pass in the command line...
> 
> That is a bug but there's still an error in your command. It should be,
> 
> 
> -hls_ts_options movflags=+skip_sidx
> 
> This is because mp4 is a child muxer in this context. That hls option 
> should be renamed.
> 
> Line 790 should be patched by adding + before frag_custom
 
 That doesn't work.
 
 ffmpeg -i input.mp4 -hls_ts_options movflags=+skip_sidx -codec copy 
 -hls_time 0.97523809523809 -hls_segment_type fmp4 -hls_flags single_file 
 -hls_playlist_type vod output.m3u8
 ffmpeg version N-92677-gdd7d6034f1 Copyright (c) 2000-2018 the FFmpeg 
 developers
 built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
 configuration: --prefix=/home/ronakp/ffmpeg_build 
 --pkg-config-flags=--static 
 --extra-cflags=-I/home/ronakp/ffmpeg_build/include 
 --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
 --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl 
 --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-nonfree
 libavutil  56. 24.101 / 56. 24.101
 libavcodec 58. 42.100 / 58. 42.100
 libavformat58. 24.100 / 58. 24.100
 libavdevice58.  6.101 / 58.  6.101
 libavfilter 7. 46.101 /  7. 46.101
 libswscale  5.  4.100 /  5.  4.100
 libswresample   3.  4.100 /  3.  4.100
 libpostproc55.  4.100 / 55.  4.100
 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
 Metadata:
 major_brand : isom
 minor_version   : 1
 compatible_brands: isom
 creation_time   : 2013-11-14T18:23:26.00Z
 Duration: 02:39:09.39, start: 0.00, bitrate: 31 kb/s
 Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 22050 Hz, mono, 
 fltp, 30 kb/s (default)
 Metadata:
   creation_time   : 2013-11-14T18:23:26.00Z
   handler_name: GPAC ISO Audio Handler
 [hls @ 0x23e1b00] Opening 'output.m4s' for writing
 [hls @ 0x23e1b00] Some of provided format options in 'movflags=+skip_sidx' 
 are not recognized
 Could not write header for output file #0 (incorrect codec parameters ?): 
 Invalid argument
 Stream mapping:
 Stream #0:0 -> #0:0 (copy)
 Last message repeated 1 times
 
 Also, I think whatever options I set on the command line are going to be 
 overwritten by line 790 in hlsenc.c anyway no?
>>> https://patchwork.ffmpeg.org/patch/11378/
>>> 
>>> Try this patch please :D
>> 
>> Thanks that works.
>> 
>> Let’s merge it!
> 
> Were you able to merge this patch?
No, i need more time to check that.
and look at this mail please,
i need check this patch first, [PATCH] Fix usage of temp_file flag in hls_flags 
option

> 
>> 
>> 
 
> 
> Gyan
> 
> ___
> 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 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 mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven





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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Steven Liu


> On Dec 17, 2018, at 22:23, Adrian  wrote:
> 
> Hello,
> 
> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed 
> stopped working.
> It looks like a regression introduced by 
> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it 
> cross-compiling for my project's target platform (ARM, Buildroot) and it 
> seems like everything is in order. I ran regression tests and nothing seems 
> to be broken.
> 
> Please review it and possibly include this patch.

https://patchwork.ffmpeg.org/patch/11410/

Dose this patch same as your patch?
> 
> Regards
> Adrian Guzowski
> 
> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven



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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Adrian
Looks like it, though I've fixed some inconsistencies in file checking 
too (i.e you're renaming file A, but checks file B for being able to be 
temp file) + added checking flag for HLS_SINGLE_FILE (it doesn't make 
sense to have HLS_TEMP_FILE | HLS_SINGLE_FILE).


My bad I didn't check pending patches - sorry!

Regards
Adrian Guzowski

W dniu 17.12.2018 o 16:00, Steven Liu pisze:



On Dec 17, 2018, at 22:23, Adrian  wrote:

Hello,

after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed 
stopped working.
It looks like a regression introduced by 
223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it 
cross-compiling for my project's target platform (ARM, Buildroot) and it seems 
like everything is in order. I ran regression tests and nothing seems to be 
broken.

Please review it and possibly include this patch.

https://patchwork.ffmpeg.org/patch/11410/

Dose this patch same as your patch?

Regards
Adrian Guzowski

<0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks
Steven



___
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] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Steven Liu


> On Dec 17, 2018, at 23:11, Adrian  wrote:
> 
> Looks like it, though I've fixed some inconsistencies in file checking too 
> (i.e you're renaming file A, but checks file B for being able to be temp 
> file) + added checking flag for HLS_SINGLE_FILE (it doesn't make sense to 
> have HLS_TEMP_FILE | HLS_SINGLE_FILE).
> 
> My bad I didn't check pending patches - sorry!
> 
Dose that patch can fix the problem? I will push it if that can fix. :-)
> Regards
> Adrian Guzowski
> 
> W dniu 17.12.2018 o 16:00, Steven Liu pisze:
>> 
>>> On Dec 17, 2018, at 22:23, Adrian  wrote:
>>> 
>>> Hello,
>>> 
>>> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
>>> muxed stopped working.
>>> It looks like a regression introduced by 
>>> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested 
>>> it cross-compiling for my project's target platform (ARM, Buildroot) and it 
>>> seems like everything is in order. I ran regression tests and nothing seems 
>>> to be broken.
>>> 
>>> Please review it and possibly include this patch.
>> https://patchwork.ffmpeg.org/patch/11410/
>> 
>> Dose this patch same as your patch?
>>> Regards
>>> Adrian Guzowski
>>> 
>>> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> Thanks
>> Steven
>> 
>> 
>> 
>> ___
>> 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

Thanks
Steven





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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Adrian
Yeah, it does. My device is running as we speak and I do see tmp files being 
created and renamed once done.

Regards
Adrian Guzowski17 gru 2018 16:19 Steven Liu  napisał(a):
>
> > On Dec 17, 2018, at 23:11, Adrian  wrote:
> > 
> > Looks like it, though I've fixed some inconsistencies in file checking too 
> > (i.e you're renaming file A, but checks file B for being able to be temp 
> > file) + added checking flag for HLS_SINGLE_FILE (it doesn't make sense to 
> > have HLS_TEMP_FILE | HLS_SINGLE_FILE).
> > 
> > My bad I didn't check pending patches - sorry!
> > 
> Dose that patch can fix the problem? I will push it if that can fix. :-)
> > Regards
> > Adrian Guzowski
> > 
> > W dniu 17.12.2018 o 16:00, Steven Liu pisze:
> >> 
> >>> On Dec 17, 2018, at 22:23, Adrian  wrote:
> >>> 
> >>> Hello,
> >>> 
> >>> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
> >>> muxed stopped working.
> >>> It looks like a regression introduced by 
> >>> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and 
> >>> tested it cross-compiling for my project's target platform (ARM, 
> >>> Buildroot) and it seems like everything is in order. I ran regression 
> >>> tests and nothing seems to be broken.
> >>> 
> >>> Please review it and possibly include this patch.
> >> https://patchwork.ffmpeg.org/patch/11410/
> >> 
> >> Dose this patch same as your patch?
> >>> Regards
> >>> Adrian Guzowski
> >>> 
> >>> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
> >>> ffmpeg-devel mailing list
> >>> ffmpeg-devel@ffmpeg.org
> >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> Thanks
> >> Steven
> >> 
> >> 
> >> 
> >> ___
> >> 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
>
> Thanks
> Steven
>
>
>
> ___
> 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] swscale/output: Altivec-optimize float yuv2plane1

2018-12-17 Thread Lauri Kasanen
On Mon, 17 Dec 2018 14:52:49 +0100
Carl Eugen Hoyos  wrote:

> >> Note that this function / this pix_fmt currently has no real use-case
> >> afaict.
> >
> > Is there a list of which pix fmts are useful? Of course I don't want to
> > waste both my and reviewers' time, if the format is considered for
> > removal or otherwise broken.
> 
> The pix_fmt is not deprecated (it's new), what I meant was that it is
> currently only used for obscure monochrome Photoshop images
> and one filter, so I am not sure optimizing this colour conversion
> will help often.

Oh, thanks for the clarification. I'm going roughly in difficulty
order, doing the easy functions first.

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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Aleksey Skripka
Greetings!

Adrian,
with your variant of patch in case of '-hls_flags +temp_file+single_file' no 
.tmp logic will be used.
not sure what is better, but all previous versions was doing so.

and also, i'm still sure, that for backward compatibility with all previous 
versions, index.m3u8 should always be written via .tmp file.

ps:
i noticed this bug such way: i do not use +temp_file, but rely on atomic rename 
of index.m3u8.

> On 17 Dec 2018, at 17:23, Adrian  wrote:
> 
> Hello,
> 
> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed 
> stopped working.
> It looks like a regression introduced by 
> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it 
> cross-compiling for my project's target platform (ARM, Buildroot) and it 
> seems like everything is in order. I ran regression tests and nothing seems 
> to be broken.
> 
> Please review it and possibly include this patch.
> 
> Regards
> Adrian Guzowski
> 
> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
Aleksey Skripka

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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Adrian
IMO temp_file+single_file should be mutually exclusive - why would you 
want to have temp file when you're using only one file anyway? In this 
mode you would either pool for file changes or just get updated playlist 
with new byte range (and that one should be updated after video file). I 
believe this restriction was already in place anyway, because there 
already were checks for HLS_SINGLE_FILE not being set, before doing 
actual rename, so this was just a simplification of those conditions.


As for playlist file - I'm not sure I follow, I've changed only places 
where temp files were already used, so I don't think I broke something 
in that matter. From repeat+level+trace I believe I saw that playlist 
file actually was using a temp file, so if that's the thing you are 
concerned about, it seems like it's all good.


Regards
Adrian Guzowski

W dniu 17.12.2018 o 16:36, Aleksey Skripka pisze:

Greetings!

Adrian,
with your variant of patch in case of '-hls_flags +temp_file+single_file' no 
.tmp logic will be used.
not sure what is better, but all previous versions was doing so.

and also, i'm still sure, that for backward compatibility with all previous 
versions, index.m3u8 should always be written via .tmp file.

ps:
i noticed this bug such way: i do not use +temp_file, but rely on atomic rename 
of index.m3u8.


On 17 Dec 2018, at 17:23, Adrian  wrote:

Hello,

after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed 
stopped working.
It looks like a regression introduced by 
223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it 
cross-compiling for my project's target platform (ARM, Buildroot) and it seems 
like everything is in order. I ran regression tests and nothing seems to be 
broken.

Please review it and possibly include this patch.

Regards
Adrian Guzowski

<0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
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]lsws/utils: Split "emms_c(); " call in two lines

2018-12-17 Thread Nicolas George
Carl Eugen Hoyos (2018-12-17):
>  #ifndef emms_c
> -#   define emms_c() while(0)
> +#   define emms_c() while(0){}
>  #endif

That feels really wrong, or at least completely unusual. But not the
change you made, the original code: the usual statement is:
"do { statement } while (0)"

And if you make that change, you will get a warning about a semicolon
after a braced block.

I suggest to change the definition to

#define emms_c() do { } while (0)

Regards,

-- 
  Nicolas George


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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Aleksey Skripka



> On 17 Dec 2018, at 18:45, Adrian  wrote:
> 
> IMO temp_file+single_file should be mutually exclusive - why would you want 
> to have temp file when you're using only one file anyway? In this mode you 
> would either pool for file changes or just get updated playlist with new byte 
> range (and that one should be updated after video file). I believe this 
> restriction was already in place anyway, because there already were checks 
> for HLS_SINGLE_FILE not being set, before doing actual rename, so this was 
> just a simplification of those conditions.
not me to decide, please ;)
if playlist will always be done via .tmp, we will have a choice.

> 
> As for playlist file - I'm not sure I follow, I've changed only places where 
> temp files were already used, so I don't think I broke something in that 
> matter.
not you, it was introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6

> From repeat+level+trace I believe I saw that playlist file actually was using 
> a temp file, so if that's the thing you are concerned about, it seems like 
> it's all good.
> 
> Regards
> Adrian Guzowski
> 
> W dniu 17.12.2018 o 16:36, Aleksey Skripka pisze:
>> Greetings!
>> 
>> Adrian,
>> with your variant of patch in case of '-hls_flags +temp_file+single_file' no 
>> .tmp logic will be used.
>> not sure what is better, but all previous versions was doing so.
>> 
>> and also, i'm still sure, that for backward compatibility with all previous 
>> versions, index.m3u8 should always be written via .tmp file.
>> 
>> ps:
>> i noticed this bug such way: i do not use +temp_file, but rely on atomic 
>> rename of index.m3u8.
>> 
>>> On 17 Dec 2018, at 17:23, Adrian  wrote:
>>> 
>>> Hello,
>>> 
>>> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
>>> muxed stopped working.
>>> It looks like a regression introduced by 
>>> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested 
>>> it cross-compiling for my project's target platform (ARM, Buildroot) and it 
>>> seems like everything is in order. I ran regression tests and nothing seems 
>>> to be broken.
>>> 
>>> Please review it and possibly include this patch.
>>> 
>>> Regards
>>> Adrian Guzowski
>>> 
>>> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
>>> 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Adrian

Comments inline.

Regards
Adrian Guzowski

W dniu 17.12.2018 o 16:56, Aleksey Skripka pisze:

On 17 Dec 2018, at 18:45, Adrian  wrote:

IMO temp_file+single_file should be mutually exclusive - why would you want to 
have temp file when you're using only one file anyway? In this mode you would 
either pool for file changes or just get updated playlist with new byte range 
(and that one should be updated after video file). I believe this restriction 
was already in place anyway, because there already were checks for 
HLS_SINGLE_FILE not being set, before doing actual rename, so this was just a 
simplification of those conditions.

not me to decide, please ;)
if playlist will always be done via .tmp, we will have a choice.
Could you clarify what choice you're talking about? And the purpose of 
this choice - frankly you got me lost with this. Regardless, I feel 
we're getting off topic.

As for playlist file - I'm not sure I follow, I've changed only places where 
temp files were already used, so I don't think I broke something in that matter.

not you, it was introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6
Not quite, temp files were already a feature, this commit narrowed 
conditions where they are used. If you're referring to change in 
hls_window about not checking TEMP flag - that is unrelated to current 
state (before commit introducing regression, check was ignoring TEMP 
flag, after commit it does take it into account - probably should be 
discussed with person responsible for original change as to why it was 
changed that way, so that's out of scope of this patch. Issue at hand is 
not using TEMP files at all and that is fixed by this patch.



 From repeat+level+trace I believe I saw that playlist file actually was using 
a temp file, so if that's the thing you are concerned about, it seems like it's 
all good.

Regards
Adrian Guzowski

W dniu 17.12.2018 o 16:36, Aleksey Skripka pisze:

Greetings!

Adrian,
with your variant of patch in case of '-hls_flags +temp_file+single_file' no 
.tmp logic will be used.
not sure what is better, but all previous versions was doing so.

and also, i'm still sure, that for backward compatibility with all previous 
versions, index.m3u8 should always be written via .tmp file.

ps:
i noticed this bug such way: i do not use +temp_file, but rely on atomic rename 
of index.m3u8.


On 17 Dec 2018, at 17:23, Adrian  wrote:

Hello,

after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS muxed 
stopped working.
It looks like a regression introduced by 
223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and tested it 
cross-compiling for my project's target platform (ARM, Buildroot) and it seems 
like everything is in order. I ran regression tests and nothing seems to be 
broken.

Please review it and possibly include this patch.

Regards
Adrian Guzowski

<0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
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 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] avfilter/af_apad: add pad_dur and whole_dur options

2018-12-17 Thread Paul B Mahol
On 12/16/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  | 18 +++---
>  libavfilter/af_apad.c | 23 +--
>  2 files changed, 36 insertions(+), 5 deletions(-)

Will apply ASAP!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/id3v2: fail read_apic on EOF reading mimetype

2018-12-17 Thread Michael Niedermayer
On Sun, Dec 16, 2018 at 09:42:49PM +0100, Tomas Härdin wrote:
> fre 2018-12-14 klockan 13:44 -0800 skrev chcunningham:
> > avio_read may return EOF, leaving the mimetype array unitialized.
> > fail
> > early when this occurs to avoid using the array in an unitialized
> > state.
> > ---
> >  libavformat/id3v2.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavformat/id3v2.c b/libavformat/id3v2.c
> > index f7de26a1d8..5fe055b591 100644
> > --- a/libavformat/id3v2.c
> > +++ b/libavformat/id3v2.c
> > @@ -590,7 +590,7 @@ static void read_apic(AVFormatContext *s,
> > AVIOContext *pb, int taglen,
> >    int isv34)
> >  {
> >  int enc, pic_type;
> > -char mimetype[64];
> > +char mimetype[64] = {0};
> >  const CodecMime *mime = ff_id3v2_mime_tags;
> >  enum AVCodecID id = AV_CODEC_ID_NONE;
> >  ID3v2ExtraMetaAPIC *apic  = NULL;
> > @@ -612,7 +612,9 @@ static void read_apic(AVFormatContext *s,
> > AVIOContext *pb, int taglen,
> >  if (isv34) {
> >  taglen -= avio_get_str(pb, taglen, mimetype,
> > sizeof(mimetype));
> >  } else {
> > -avio_read(pb, mimetype, 3);
> > +if (avio_read(pb, mimetype, 3) < 0)
> > +goto fail;
> > +
> 
> Looks good to me

will apply

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: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/nut: fix duration estimation by writting EOR packets

2018-12-17 Thread Michael Niedermayer
On Mon, Dec 17, 2018 at 06:04:40PM +0100, Paul B Mahol wrote:
> Hi,
> 
> patches attached.

>  nut.h|2 +
>  nutdec.c |3 ++
>  nutenc.c |   87 
> ---
>  3 files changed, 88 insertions(+), 4 deletions(-)
> 870df19d733f29294a2cb2e3ea5ed1a09745f3a4  
> 0001-avformat-nut-fix-duration-estimation-by-writing-EOR-.patch
> From 80d6805fdf386182341fe72035ab88e06a602752 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Mon, 17 Dec 2018 16:43:57 +0100
> Subject: [PATCH 1/2] avformat/nut: fix duration estimation by writing EOR
>  packets
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/nut.h|  2 +
>  libavformat/nutdec.c |  3 ++
>  libavformat/nutenc.c | 87 ++--
>  3 files changed, 88 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/nut.h b/libavformat/nut.h
> index a4409ee23d..d7ba86b5e5 100644
> --- a/libavformat/nut.h
> +++ b/libavformat/nut.h
> @@ -76,6 +76,8 @@ typedef struct StreamContext {
>  int last_flags;
>  int skip_until_key_frame;
>  int64_t last_pts;
> +int64_t last_dts;
> +int64_t last_duration;
>  int time_base_id;
>  AVRational *time_base;
>  int msb_pts_shift;
> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> index 056ef59d00..f2490f9842 100644

> --- a/libavformat/nutdec.c
> +++ b/libavformat/nutdec.c
> @@ -1080,6 +1080,9 @@ static int decode_frame(NUTContext *nut, AVPacket *pkt, 
> int frame_code)
>  
>  stc = &nut->stream[stream_id];
>  
> +if (stc->last_flags & FLAG_EOR)
> +return 1;

EOR can occur in the middle of subtitle streams. It would be used to mark
areas with no vissible subtitles.
(The point behind this is that it allows seeking to consider a subtitle stream
 if and only if there are actually any displayed subtitles at that time)

this code would break that

also demxuer and muxer changes should be in seperate patches


> +
>  if (stc->last_flags & FLAG_KEY)
>  stc->skip_until_key_frame = 0;
>  
> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> index e9a3bb49db..c12b4cc8cf 100644
> --- a/libavformat/nutenc.c
> +++ b/libavformat/nutenc.c
> @@ -940,6 +940,80 @@ fail:
>  return ret;
>  }
>  
> +static void nut_update_max_pts(AVFormatContext *s, int stream_index, int64_t 
> pts)
> +{
> +NUTContext *nut = s->priv_data;
> +StreamContext *nus = &nut->stream[stream_index];
> +
> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb, 
> pts, *nus->time_base) < 0) {
> +nut->max_pts = pts;
> +nut->max_pts_tb = nus->time_base;
> +}
> +}
> +
> +static int nut_write_eor(AVFormatContext *s, int stream_index)
> +{
> +AVIOContext *bc = s->pb, *dyn_bc;
> +NUTContext *nut = s->priv_data;
> +StreamContext *nus = &nut->stream[stream_index];
> +int ret, frame_code, flags, needed_flags;
> +int64_t pts = nus->last_pts + nus->last_duration;
> +int64_t coded_pts;
> +FrameCode *fc;
> +
> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
> +if (ff_lsb2full(nus, coded_pts) != pts)
> +coded_pts = pts + (1 << nus->msb_pts_shift);
> +
> +nut->last_syncpoint_pos = avio_tell(bc);
> +ret = avio_open_dyn_buf(&dyn_bc);
> +if (ret < 0)
> +return ret;
> +put_tt(nut, nus->time_base, dyn_bc, nus->last_dts + nus->last_duration);
> +ff_put_v(dyn_bc, 0);
> +
> +if (nut->flags & NUT_BROADCAST) {
> +put_tt(nut, nus->time_base, dyn_bc,
> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q, *nus->time_base));
> +}
> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
> +
> +frame_code  = -1;
> +for (int i = 0; i < 256; i++) {
> +FrameCode *fc = &nut->frame_code[i];
> +int flags = fc->flags;
> +
> +if (flags & FLAG_INVALID)
> +continue;
> +
> +if (!(flags & FLAG_CODED)) {
> +continue;
> +}
> +
> +frame_code = i;
> +break;
> +}
> +av_assert0(frame_code != -1);
> +
> +fc   = &nut->frame_code[frame_code];
> +flags= fc->flags;
> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS | FLAG_STREAM_ID;
> +
> +ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
> +avio_w8(bc, frame_code);
> +if (flags & FLAG_CODED) {
> +ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
> +flags = needed_flags;
> +}
> +if (flags & FLAG_STREAM_ID)  ff_put_v(bc, stream_index);
> +if (flags & FLAG_CODED_PTS)  ff_put_v(bc, coded_pts);
> +ffio_get_checksum(bc);
> +
> +nut_update_max_pts(s, stream_index, nus->last_pts + nus->last_duration);
> +
> +return 0;
> +}
> +
>  static int nut_write_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  NUTContext *nut= s->priv_data;
> @@ -1136,6 +1210,8 @@ static int nut_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  
>  nus->last_flags = flags;
>  

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available

2018-12-17 Thread Michael Niedermayer
On Sat, Dec 15, 2018 at 08:50:41PM +0200, Jan Ekström wrote:
> Fixes issues when a subtitle packet is received before PCR for the
> program has been received, leading to wildly jumping timestamps
> on the lavf client side as well as in the re-ordering logic.
> 
> This usually happens in case of multiplexes where the PCR of a
> program is not taken into account with subtitle tracks' DTS/PTS.
> ---
>  libavformat/mpegts.c | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index edf6b5701d..8f6ee81cda 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -1219,6 +1219,7 @@ skip:
>  || pes->st->codecpar->codec_id == 
> AV_CODEC_ID_DVB_SUBTITLE)
>  ) {
>  AVProgram *p = NULL;
> +int pcr_found = 0;
>  while ((p = av_find_program_from_stream(pes->stream, p, 
> pes->st->index))) {
>  if (p->pcr_pid != -1 && p->discard != AVDISCARD_ALL) 
> {
>  MpegTSFilter *f = pes->ts->pids[p->pcr_pid];
> @@ -1242,6 +1243,7 @@ skip:
>  // and the pcr error to this packet 
> should be no more than 100 ms.
>  // TODO: we should interpolate the PCR, 
> not just use the last one
>  int64_t pcr = f->last_pcr / 300;
> +pcr_found = 1;
>  pes->st->pts_wrap_reference = 
> st->pts_wrap_reference;
>  pes->st->pts_wrap_behavior = 
> st->pts_wrap_behavior;
>  if (pes->dts == AV_NOPTS_VALUE || 
> pes->dts < pcr) {
> @@ -1258,6 +1260,15 @@ skip:
>  }
>  }
>  }
> +
> +if (!pcr_found) {
> +av_log(pes->stream, AV_LOG_VERBOSE,
> +   "Forcing DTS/PTS to be unset for a "
> +   "non-trustworthy PES packet for PID %d as "
> +   "PCR hasn't been received yet.\n",
> +   pes->pid);
> +pes->dts = pes->pts = AV_NOPTS_VALUE;
> +}
>  }
>  }
>  break;

Assuming i understand the intend correctly ...
could the packet be put in a buffer and once a PCR has been encountered be
returned based on that?
This seems better as no timestamp would be lost

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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


Re: [FFmpeg-devel] [PATCH] avformat/nut: fix duration estimation by writting EOR packets

2018-12-17 Thread Paul B Mahol
On 12/17/18, Michael Niedermayer  wrote:
> On Mon, Dec 17, 2018 at 06:04:40PM +0100, Paul B Mahol wrote:
>> Hi,
>>
>> patches attached.
>
>>  nut.h|2 +
>>  nutdec.c |3 ++
>>  nutenc.c |   87
>> ---
>>  3 files changed, 88 insertions(+), 4 deletions(-)
>> 870df19d733f29294a2cb2e3ea5ed1a09745f3a4
>> 0001-avformat-nut-fix-duration-estimation-by-writing-EOR-.patch
>> From 80d6805fdf386182341fe72035ab88e06a602752 Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol 
>> Date: Mon, 17 Dec 2018 16:43:57 +0100
>> Subject: [PATCH 1/2] avformat/nut: fix duration estimation by writing EOR
>>  packets
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/nut.h|  2 +
>>  libavformat/nutdec.c |  3 ++
>>  libavformat/nutenc.c | 87 ++--
>>  3 files changed, 88 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/nut.h b/libavformat/nut.h
>> index a4409ee23d..d7ba86b5e5 100644
>> --- a/libavformat/nut.h
>> +++ b/libavformat/nut.h
>> @@ -76,6 +76,8 @@ typedef struct StreamContext {
>>  int last_flags;
>>  int skip_until_key_frame;
>>  int64_t last_pts;
>> +int64_t last_dts;
>> +int64_t last_duration;
>>  int time_base_id;
>>  AVRational *time_base;
>>  int msb_pts_shift;
>> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> index 056ef59d00..f2490f9842 100644
>
>> --- a/libavformat/nutdec.c
>> +++ b/libavformat/nutdec.c
>> @@ -1080,6 +1080,9 @@ static int decode_frame(NUTContext *nut, AVPacket
>> *pkt, int frame_code)
>>
>>  stc = &nut->stream[stream_id];
>>
>> +if (stc->last_flags & FLAG_EOR)
>> +return 1;
>
> EOR can occur in the middle of subtitle streams. It would be used to mark
> areas with no vissible subtitles.
> (The point behind this is that it allows seeking to consider a subtitle
> stream
>  if and only if there are actually any displayed subtitles at that time)
>
> this code would break that
>
> also demxuer and muxer changes should be in seperate patches
>
>
>> +
>>  if (stc->last_flags & FLAG_KEY)
>>  stc->skip_until_key_frame = 0;
>>
>> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
>> index e9a3bb49db..c12b4cc8cf 100644
>> --- a/libavformat/nutenc.c
>> +++ b/libavformat/nutenc.c
>> @@ -940,6 +940,80 @@ fail:
>>  return ret;
>>  }
>>
>> +static void nut_update_max_pts(AVFormatContext *s, int stream_index,
>> int64_t pts)
>> +{
>> +NUTContext *nut = s->priv_data;
>> +StreamContext *nus = &nut->stream[stream_index];
>> +
>> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb,
>> pts, *nus->time_base) < 0) {
>> +nut->max_pts = pts;
>> +nut->max_pts_tb = nus->time_base;
>> +}
>> +}
>> +
>> +static int nut_write_eor(AVFormatContext *s, int stream_index)
>> +{
>> +AVIOContext *bc = s->pb, *dyn_bc;
>> +NUTContext *nut = s->priv_data;
>> +StreamContext *nus = &nut->stream[stream_index];
>> +int ret, frame_code, flags, needed_flags;
>> +int64_t pts = nus->last_pts + nus->last_duration;
>> +int64_t coded_pts;
>> +FrameCode *fc;
>> +
>> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
>> +if (ff_lsb2full(nus, coded_pts) != pts)
>> +coded_pts = pts + (1 << nus->msb_pts_shift);
>> +
>> +nut->last_syncpoint_pos = avio_tell(bc);
>> +ret = avio_open_dyn_buf(&dyn_bc);
>> +if (ret < 0)
>> +return ret;
>> +put_tt(nut, nus->time_base, dyn_bc, nus->last_dts +
>> nus->last_duration);
>> +ff_put_v(dyn_bc, 0);
>> +
>> +if (nut->flags & NUT_BROADCAST) {
>> +put_tt(nut, nus->time_base, dyn_bc,
>> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
>> *nus->time_base));
>> +}
>> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
>> +
>> +frame_code  = -1;
>> +for (int i = 0; i < 256; i++) {
>> +FrameCode *fc = &nut->frame_code[i];
>> +int flags = fc->flags;
>> +
>> +if (flags & FLAG_INVALID)
>> +continue;
>> +
>> +if (!(flags & FLAG_CODED)) {
>> +continue;
>> +}
>> +
>> +frame_code = i;
>> +break;
>> +}
>> +av_assert0(frame_code != -1);
>> +
>> +fc   = &nut->frame_code[frame_code];
>> +flags= fc->flags;
>> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS |
>> FLAG_STREAM_ID;
>> +
>> +ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
>> +avio_w8(bc, frame_code);
>> +if (flags & FLAG_CODED) {
>> +ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
>> +flags = needed_flags;
>> +}
>> +if (flags & FLAG_STREAM_ID)  ff_put_v(bc, stream_index);
>> +if (flags & FLAG_CODED_PTS)  ff_put_v(bc, coded_pts);
>> +ffio_get_checksum(bc);
>> +
>> +nut_update_max_pts(s, stream_index, nus->last_pts +
>> nus->last_duration);
>> +
>> +return 0;
>> +}
>> +
>>  static int nut_write_packet(AVFormatContext 

Re: [FFmpeg-devel] NUT end timestamp

2018-12-17 Thread Michael Niedermayer
On Mon, Dec 17, 2018 at 11:24:43AM +0100, Paul B Mahol wrote:
> On 12/14/18, Michael Niedermayer  wrote:
> > Hi
> >
> > replying to a comment from IRC here because "durandal_1707 has quit" so it
> > wouldnt be seen, and might be interresting for others so not mailing
> > private
> >
> >  michaelni: nut does not take into consideration duration of
> > last frame to return real duration
> >  michaelni: so duration is always smaller by small amount
> >  michaelni: looks like design failure
> >
> > Its a bit ago that i worked on nut but the last frame duration was
> > considered,
> > i do remember there was discussion about it.
> >
> > looking at nut.txt, it says this:
> > All streams SHOULD end with EOR, where the pts of the EOR indicates the
> > end presentation time of the final frame.
> >
> > That stores and gives the last duration. Our muxer seems to not implement
> > this
> > so its a implementation issue not a design one
> 
> If one need to parse all packets to get last duration that is flawed design.

That should not be neccessary
you can find the duration from the next packet as with any other packet thats 
not
the last. And there is a index from which it should be possible to find the last
too

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

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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


Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available

2018-12-17 Thread Paul B Mahol
On 12/17/18, Michael Niedermayer  wrote:
> On Sat, Dec 15, 2018 at 08:50:41PM +0200, Jan Ekström wrote:
>> Fixes issues when a subtitle packet is received before PCR for the
>> program has been received, leading to wildly jumping timestamps
>> on the lavf client side as well as in the re-ordering logic.
>>
>> This usually happens in case of multiplexes where the PCR of a
>> program is not taken into account with subtitle tracks' DTS/PTS.
>> ---
>>  libavformat/mpegts.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
>> index edf6b5701d..8f6ee81cda 100644
>> --- a/libavformat/mpegts.c
>> +++ b/libavformat/mpegts.c
>> @@ -1219,6 +1219,7 @@ skip:
>>  || pes->st->codecpar->codec_id ==
>> AV_CODEC_ID_DVB_SUBTITLE)
>>  ) {
>>  AVProgram *p = NULL;
>> +int pcr_found = 0;
>>  while ((p = av_find_program_from_stream(pes->stream,
>> p, pes->st->index))) {
>>  if (p->pcr_pid != -1 && p->discard !=
>> AVDISCARD_ALL) {
>>  MpegTSFilter *f = pes->ts->pids[p->pcr_pid];
>> @@ -1242,6 +1243,7 @@ skip:
>>  // and the pcr error to this packet
>> should be no more than 100 ms.
>>  // TODO: we should interpolate the
>> PCR, not just use the last one
>>  int64_t pcr = f->last_pcr / 300;
>> +pcr_found = 1;
>>  pes->st->pts_wrap_reference =
>> st->pts_wrap_reference;
>>  pes->st->pts_wrap_behavior =
>> st->pts_wrap_behavior;
>>  if (pes->dts == AV_NOPTS_VALUE ||
>> pes->dts < pcr) {
>> @@ -1258,6 +1260,15 @@ skip:
>>  }
>>  }
>>  }
>> +
>> +if (!pcr_found) {
>> +av_log(pes->stream, AV_LOG_VERBOSE,
>> +   "Forcing DTS/PTS to be unset for a "
>> +   "non-trustworthy PES packet for PID %d as
>> "
>> +   "PCR hasn't been received yet.\n",
>> +   pes->pid);
>> +pes->dts = pes->pts = AV_NOPTS_VALUE;
>> +}
>>  }
>>  }
>>  break;
>
> Assuming i understand the intend correctly ...
> could the packet be put in a buffer and once a PCR has been encountered be
> returned based on that?
> This seems better as no timestamp would be lost
>
> thx

No, that is awful idea. You do not waste memory on that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] NUT end timestamp

2018-12-17 Thread Paul B Mahol
On 12/17/18, Michael Niedermayer  wrote:
> On Mon, Dec 17, 2018 at 11:24:43AM +0100, Paul B Mahol wrote:
>> On 12/14/18, Michael Niedermayer  wrote:
>> > Hi
>> >
>> > replying to a comment from IRC here because "durandal_1707 has quit" so
>> > it
>> > wouldnt be seen, and might be interresting for others so not mailing
>> > private
>> >
>> >  michaelni: nut does not take into consideration duration
>> > of
>> > last frame to return real duration
>> >  michaelni: so duration is always smaller by small
>> > amount
>> >  michaelni: looks like design failure
>> >
>> > Its a bit ago that i worked on nut but the last frame duration was
>> > considered,
>> > i do remember there was discussion about it.
>> >
>> > looking at nut.txt, it says this:
>> > All streams SHOULD end with EOR, where the pts of the EOR indicates
>> > the
>> > end presentation time of the final frame.
>> >
>> > That stores and gives the last duration. Our muxer seems to not
>> > implement
>> > this
>> > so its a implementation issue not a design one
>>
>> If one need to parse all packets to get last duration that is flawed
>> design.
>
> That should not be neccessary
> you can find the duration from the next packet as with any other packet
> thats not
> the last. And there is a index from which it should be possible to find the
> last
> too

Nope, pkt->duration is nowhere actually stored. Except this EOR thing
not implemented by you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat/nut: fix duration estimation by writting EOR packets

2018-12-17 Thread Michael Niedermayer
On Mon, Dec 17, 2018 at 07:32:49PM +0100, Paul B Mahol wrote:
> On 12/17/18, Michael Niedermayer  wrote:
> > On Mon, Dec 17, 2018 at 06:04:40PM +0100, Paul B Mahol wrote:
> >> Hi,
> >>
> >> patches attached.
> >
> >>  nut.h|2 +
> >>  nutdec.c |3 ++
> >>  nutenc.c |   87
> >> ---
> >>  3 files changed, 88 insertions(+), 4 deletions(-)
> >> 870df19d733f29294a2cb2e3ea5ed1a09745f3a4
> >> 0001-avformat-nut-fix-duration-estimation-by-writing-EOR-.patch
> >> From 80d6805fdf386182341fe72035ab88e06a602752 Mon Sep 17 00:00:00 2001
> >> From: Paul B Mahol 
> >> Date: Mon, 17 Dec 2018 16:43:57 +0100
> >> Subject: [PATCH 1/2] avformat/nut: fix duration estimation by writing EOR
> >>  packets
> >>
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/nut.h|  2 +
> >>  libavformat/nutdec.c |  3 ++
> >>  libavformat/nutenc.c | 87 ++--
> >>  3 files changed, 88 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/nut.h b/libavformat/nut.h
> >> index a4409ee23d..d7ba86b5e5 100644
> >> --- a/libavformat/nut.h
> >> +++ b/libavformat/nut.h
> >> @@ -76,6 +76,8 @@ typedef struct StreamContext {
> >>  int last_flags;
> >>  int skip_until_key_frame;
> >>  int64_t last_pts;
> >> +int64_t last_dts;
> >> +int64_t last_duration;
> >>  int time_base_id;
> >>  AVRational *time_base;
> >>  int msb_pts_shift;
> >> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
> >> index 056ef59d00..f2490f9842 100644
> >
> >> --- a/libavformat/nutdec.c
> >> +++ b/libavformat/nutdec.c
> >> @@ -1080,6 +1080,9 @@ static int decode_frame(NUTContext *nut, AVPacket
> >> *pkt, int frame_code)
> >>
> >>  stc = &nut->stream[stream_id];
> >>
> >> +if (stc->last_flags & FLAG_EOR)
> >> +return 1;
> >
> > EOR can occur in the middle of subtitle streams. It would be used to mark
> > areas with no vissible subtitles.
> > (The point behind this is that it allows seeking to consider a subtitle
> > stream
> >  if and only if there are actually any displayed subtitles at that time)
> >
> > this code would break that
> >
> > also demxuer and muxer changes should be in seperate patches
> >
> >
> >> +
> >>  if (stc->last_flags & FLAG_KEY)
> >>  stc->skip_until_key_frame = 0;
> >>
> >> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
> >> index e9a3bb49db..c12b4cc8cf 100644
> >> --- a/libavformat/nutenc.c
> >> +++ b/libavformat/nutenc.c
> >> @@ -940,6 +940,80 @@ fail:
> >>  return ret;
> >>  }
> >>
> >> +static void nut_update_max_pts(AVFormatContext *s, int stream_index,
> >> int64_t pts)
> >> +{
> >> +NUTContext *nut = s->priv_data;
> >> +StreamContext *nus = &nut->stream[stream_index];
> >> +
> >> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts, *nut->max_pts_tb,
> >> pts, *nus->time_base) < 0) {
> >> +nut->max_pts = pts;
> >> +nut->max_pts_tb = nus->time_base;
> >> +}
> >> +}
> >> +
> >> +static int nut_write_eor(AVFormatContext *s, int stream_index)
> >> +{
> >> +AVIOContext *bc = s->pb, *dyn_bc;
> >> +NUTContext *nut = s->priv_data;
> >> +StreamContext *nus = &nut->stream[stream_index];
> >> +int ret, frame_code, flags, needed_flags;
> >> +int64_t pts = nus->last_pts + nus->last_duration;
> >> +int64_t coded_pts;
> >> +FrameCode *fc;
> >> +
> >> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
> >> +if (ff_lsb2full(nus, coded_pts) != pts)
> >> +coded_pts = pts + (1 << nus->msb_pts_shift);
> >> +
> >> +nut->last_syncpoint_pos = avio_tell(bc);
> >> +ret = avio_open_dyn_buf(&dyn_bc);
> >> +if (ret < 0)
> >> +return ret;
> >> +put_tt(nut, nus->time_base, dyn_bc, nus->last_dts +
> >> nus->last_duration);
> >> +ff_put_v(dyn_bc, 0);
> >> +
> >> +if (nut->flags & NUT_BROADCAST) {
> >> +put_tt(nut, nus->time_base, dyn_bc,
> >> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
> >> *nus->time_base));
> >> +}
> >> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
> >> +
> >> +frame_code  = -1;
> >> +for (int i = 0; i < 256; i++) {
> >> +FrameCode *fc = &nut->frame_code[i];
> >> +int flags = fc->flags;
> >> +
> >> +if (flags & FLAG_INVALID)
> >> +continue;
> >> +
> >> +if (!(flags & FLAG_CODED)) {
> >> +continue;
> >> +}
> >> +
> >> +frame_code = i;
> >> +break;
> >> +}
> >> +av_assert0(frame_code != -1);
> >> +
> >> +fc   = &nut->frame_code[frame_code];
> >> +flags= fc->flags;
> >> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS |
> >> FLAG_STREAM_ID;
> >> +
> >> +ffio_init_checksum(bc, ff_crc04C11DB7_update, 0);
> >> +avio_w8(bc, frame_code);
> >> +if (flags & FLAG_CODED) {
> >> +ff_put_v(bc, (flags ^ needed_flags) & ~(FLAG_CODED));
> >> +flags = nee

Re: [FFmpeg-devel] [PATCH] avformat/nut: fix duration estimation by writting EOR packets

2018-12-17 Thread Paul B Mahol
On 12/17/18, Michael Niedermayer  wrote:
> On Mon, Dec 17, 2018 at 07:32:49PM +0100, Paul B Mahol wrote:
>> On 12/17/18, Michael Niedermayer  wrote:
>> > On Mon, Dec 17, 2018 at 06:04:40PM +0100, Paul B Mahol wrote:
>> >> Hi,
>> >>
>> >> patches attached.
>> >
>> >>  nut.h|2 +
>> >>  nutdec.c |3 ++
>> >>  nutenc.c |   87
>> >> ---
>> >>  3 files changed, 88 insertions(+), 4 deletions(-)
>> >> 870df19d733f29294a2cb2e3ea5ed1a09745f3a4
>> >> 0001-avformat-nut-fix-duration-estimation-by-writing-EOR-.patch
>> >> From 80d6805fdf386182341fe72035ab88e06a602752 Mon Sep 17 00:00:00 2001
>> >> From: Paul B Mahol 
>> >> Date: Mon, 17 Dec 2018 16:43:57 +0100
>> >> Subject: [PATCH 1/2] avformat/nut: fix duration estimation by writing
>> >> EOR
>> >>  packets
>> >>
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> >>  libavformat/nut.h|  2 +
>> >>  libavformat/nutdec.c |  3 ++
>> >>  libavformat/nutenc.c | 87
>> >> ++--
>> >>  3 files changed, 88 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/libavformat/nut.h b/libavformat/nut.h
>> >> index a4409ee23d..d7ba86b5e5 100644
>> >> --- a/libavformat/nut.h
>> >> +++ b/libavformat/nut.h
>> >> @@ -76,6 +76,8 @@ typedef struct StreamContext {
>> >>  int last_flags;
>> >>  int skip_until_key_frame;
>> >>  int64_t last_pts;
>> >> +int64_t last_dts;
>> >> +int64_t last_duration;
>> >>  int time_base_id;
>> >>  AVRational *time_base;
>> >>  int msb_pts_shift;
>> >> diff --git a/libavformat/nutdec.c b/libavformat/nutdec.c
>> >> index 056ef59d00..f2490f9842 100644
>> >
>> >> --- a/libavformat/nutdec.c
>> >> +++ b/libavformat/nutdec.c
>> >> @@ -1080,6 +1080,9 @@ static int decode_frame(NUTContext *nut,
>> >> AVPacket
>> >> *pkt, int frame_code)
>> >>
>> >>  stc = &nut->stream[stream_id];
>> >>
>> >> +if (stc->last_flags & FLAG_EOR)
>> >> +return 1;
>> >
>> > EOR can occur in the middle of subtitle streams. It would be used to
>> > mark
>> > areas with no vissible subtitles.
>> > (The point behind this is that it allows seeking to consider a subtitle
>> > stream
>> >  if and only if there are actually any displayed subtitles at that
>> > time)
>> >
>> > this code would break that
>> >
>> > also demxuer and muxer changes should be in seperate patches
>> >
>> >
>> >> +
>> >>  if (stc->last_flags & FLAG_KEY)
>> >>  stc->skip_until_key_frame = 0;
>> >>
>> >> diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
>> >> index e9a3bb49db..c12b4cc8cf 100644
>> >> --- a/libavformat/nutenc.c
>> >> +++ b/libavformat/nutenc.c
>> >> @@ -940,6 +940,80 @@ fail:
>> >>  return ret;
>> >>  }
>> >>
>> >> +static void nut_update_max_pts(AVFormatContext *s, int stream_index,
>> >> int64_t pts)
>> >> +{
>> >> +NUTContext *nut = s->priv_data;
>> >> +StreamContext *nus = &nut->stream[stream_index];
>> >> +
>> >> +if (!nut->max_pts_tb || av_compare_ts(nut->max_pts,
>> >> *nut->max_pts_tb,
>> >> pts, *nus->time_base) < 0) {
>> >> +nut->max_pts = pts;
>> >> +nut->max_pts_tb = nus->time_base;
>> >> +}
>> >> +}
>> >> +
>> >> +static int nut_write_eor(AVFormatContext *s, int stream_index)
>> >> +{
>> >> +AVIOContext *bc = s->pb, *dyn_bc;
>> >> +NUTContext *nut = s->priv_data;
>> >> +StreamContext *nus = &nut->stream[stream_index];
>> >> +int ret, frame_code, flags, needed_flags;
>> >> +int64_t pts = nus->last_pts + nus->last_duration;
>> >> +int64_t coded_pts;
>> >> +FrameCode *fc;
>> >> +
>> >> +coded_pts = pts & ((1 << nus->msb_pts_shift) - 1);
>> >> +if (ff_lsb2full(nus, coded_pts) != pts)
>> >> +coded_pts = pts + (1 << nus->msb_pts_shift);
>> >> +
>> >> +nut->last_syncpoint_pos = avio_tell(bc);
>> >> +ret = avio_open_dyn_buf(&dyn_bc);
>> >> +if (ret < 0)
>> >> +return ret;
>> >> +put_tt(nut, nus->time_base, dyn_bc, nus->last_dts +
>> >> nus->last_duration);
>> >> +ff_put_v(dyn_bc, 0);
>> >> +
>> >> +if (nut->flags & NUT_BROADCAST) {
>> >> +put_tt(nut, nus->time_base, dyn_bc,
>> >> +   av_rescale_q(av_gettime(), AV_TIME_BASE_Q,
>> >> *nus->time_base));
>> >> +}
>> >> +put_packet(nut, bc, dyn_bc, 1, SYNCPOINT_STARTCODE);
>> >> +
>> >> +frame_code  = -1;
>> >> +for (int i = 0; i < 256; i++) {
>> >> +FrameCode *fc = &nut->frame_code[i];
>> >> +int flags = fc->flags;
>> >> +
>> >> +if (flags & FLAG_INVALID)
>> >> +continue;
>> >> +
>> >> +if (!(flags & FLAG_CODED)) {
>> >> +continue;
>> >> +}
>> >> +
>> >> +frame_code = i;
>> >> +break;
>> >> +}
>> >> +av_assert0(frame_code != -1);
>> >> +
>> >> +fc   = &nut->frame_code[frame_code];
>> >> +flags= fc->flags;
>> >> +needed_flags = FLAG_KEY | FLAG_EOR | FLAG_CODED_PTS |
>> >> FLAG_STREAM_ID;
>> >> +
>> >> + 

Re: [FFmpeg-devel] [PATCH] libavcodec/fft_template: improve performance of the ff_fft_init in fft_template

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 15:56 GMT+01:00, Steven Liu :
>
>
>> On Dec 17, 2018, at 22:05, Carl Eugen Hoyos  wrote:
>>
>> 2018-12-17 10:13 GMT+01:00, Steven Liu :
>>> After patch:
>>> init nbits = 17, get 1 samples, duration: 15221
>>> Before patch:
>>> init nbits = 17, get 1 samples, duration: 16105
>>>
>>> test script:
>>> DURATION=0
>>> for((i=0;i<1;i++)) do
>>> ./libavcodec/tests/fft -n 17 &>output
>>> T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
>>> DURATION=`expr $DURATION + $T_DURATION`
>>> done
>>> TOTAL=`expr $DURATION / 1`
>>> echo $TOTAL
>>
>> This script does not allow to reproduce afaict.
>> (There is no "duration" here in output)
>
> Do you mean i should commit 2/3 patch of the libavcodec/tests/fft.c modify?
> or just upload the modify diff here?

I believe your commit message should not contain a script
that cannot be used to reproduce your findings.

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


Re: [FFmpeg-devel] [PATCH]lsws/utils: Split "emms_c(); " call in two lines

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 16:45 GMT+01:00, Nicolas George :
> Carl Eugen Hoyos (2018-12-17):
>>  #ifndef emms_c
>> -#   define emms_c() while(0)
>> +#   define emms_c() while(0){}
>>  #endif
>
> That feels really wrong, or at least completely unusual. But not the
> change you made, the original code: the usual statement is:
> "do { statement } while (0)"
>
> And if you make that change, you will get a warning about a semicolon
> after a braced block.
>
> I suggest to change the definition to
>
> #define emms_c() do { } while (0)

New patch attached.

Thank you, Carl Eugen
From 651baa2d7ec1a163dc00adf1885146b0938745e3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 17 Dec 2018 20:33:24 +0100
Subject: [PATCH] lavu/internal: Replace an empty loop with "do {}".

Silences a clang warning when not compiling for x86:
libswscale/utils.c:345:13: warning: while loop has empty body

Suggested-by: Nicolas George
---
 libavutil/internal.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/internal.h b/libavutil/internal.h
index 06bd561..4acbcf5 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -52,7 +52,7 @@
 #endif
 
 #ifndef emms_c
-#   define emms_c() while(0)
+#   define emms_c() do {} while(0)
 #endif
 
 #ifndef attribute_align_arg
-- 
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 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >
> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>
> >> > So as far as it's been possible to test this, that's been done
> >>
> >> Could you point me to a dva1 sample?
> >
> > I have not seen any dolby vision samples with avc in the wild.
> > You can ask Vittorio if he has some as he noted about
> > possibly being able to ask for some before.
>
> The patch is of course ok if Vittorio tested it with his samples.
>
> Thank you, Carl Eugen

Unfortunately I have no idea what samples Vittorio does or does not
possess, he has only mentioned off-hand that he might able to get hold
of some if required. And since you were the one requiring them, I
pointed you towards him.

For myself, I am happy with the following points regarding this:
1. The identifiers are registered at the MPEG-4 RA.
2. There is a proper specification for these mappings that is
seemingly kept up-to-date.
3. The mappings specification specifically notes that the only
difference between the AVC and HEVC identifiers are the semantics
mentioned in ISO/IEC 14496-15. We already have all of the identifiers
specified which these mappings are based upon, so those semantics
should not matter to us (and if they do, we have already broken those
constraints at this point).
4. The mapping specification specifically notes that the given AVC and
HEVC identifiers must also include the standard avcC and hvcC boxes so
that they can be decoded normally without any additional custom code.
5. We have samples for at least one of the four identifiers that
matches points 1 to 4.
6. Android, Chromium, VLC among others have already implemented these
identifiers in the same way.

Now, if you are not happy with these points, then please clearly state
that you are blocking any and all additional identifier additions - no
matter how specified - as long as there are no samples on hand for
them.

Best regards,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 21:17 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos  wrote:
>>
>> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >
>> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>>
>> >> > So as far as it's been possible to test this, that's been done
>> >>
>> >> Could you point me to a dva1 sample?
>> >
>> > I have not seen any dolby vision samples with avc in the wild.
>> > You can ask Vittorio if he has some as he noted about
>> > possibly being able to ask for some before.
>>
>> The patch is of course ok if Vittorio tested it with his samples.
>>
>> Thank you, Carl Eugen
>
> Unfortunately I have no idea what samples Vittorio does or does not
> possess, he has only mentioned off-hand that he might able to get hold
> of some if required. And since you were the one requiring them, I
> pointed you towards him.
>
> For myself, I am happy with the following points regarding this:
> 1. The identifiers are registered at the MPEG-4 RA.
> 2. There is a proper specification for these mappings that is
> seemingly kept up-to-date.
> 3. The mappings specification specifically notes that the only
> difference between the AVC and HEVC identifiers are the semantics
> mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> specified which these mappings are based upon, so those semantics
> should not matter to us (and if they do, we have already broken those
> constraints at this point).
> 4. The mapping specification specifically notes that the given AVC and
> HEVC identifiers must also include the standard avcC and hvcC boxes so
> that they can be decoded normally without any additional custom code.
> 5. We have samples for at least one of the four identifiers that
> matches points 1 to 4.
> 6. Android, Chromium, VLC among others have already implemented these
> identifiers in the same way.
>
> Now, if you are not happy with these points, then please clearly state
> that you are blocking any and all additional identifier additions - no

> matter how specified - as long as there are no samples on hand for
> them.

I thought we had samples?

Anyway, please mention ticket #7347.

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


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos  wrote:
> >>
> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> >
> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >>
> >> >> > So as far as it's been possible to test this, that's been done
> >> >>
> >> >> Could you point me to a dva1 sample?
> >> >
> >> > I have not seen any dolby vision samples with avc in the wild.
> >> > You can ask Vittorio if he has some as he noted about
> >> > possibly being able to ask for some before.
> >>
> >> The patch is of course ok if Vittorio tested it with his samples.
> >>
> >> Thank you, Carl Eugen
> >
> > Unfortunately I have no idea what samples Vittorio does or does not
> > possess, he has only mentioned off-hand that he might able to get hold
> > of some if required. And since you were the one requiring them, I
> > pointed you towards him.
> >
> > For myself, I am happy with the following points regarding this:
> > 1. The identifiers are registered at the MPEG-4 RA.
> > 2. There is a proper specification for these mappings that is
> > seemingly kept up-to-date.
> > 3. The mappings specification specifically notes that the only
> > difference between the AVC and HEVC identifiers are the semantics
> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> > specified which these mappings are based upon, so those semantics
> > should not matter to us (and if they do, we have already broken those
> > constraints at this point).
> > 4. The mapping specification specifically notes that the given AVC and
> > HEVC identifiers must also include the standard avcC and hvcC boxes so
> > that they can be decoded normally without any additional custom code.
> > 5. We have samples for at least one of the four identifiers that
> > matches points 1 to 4.
> > 6. Android, Chromium, VLC among others have already implemented these
> > identifiers in the same way.
> >
> > Now, if you are not happy with these points, then please clearly state
> > that you are blocking any and all additional identifier additions - no
>
> > matter how specified - as long as there are no samples on hand for
> > them.
>
> I thought we had samples?
>
> Anyway, please mention ticket #7347.
>
> Carl Eugen

The sample last linked in that ticket was supposedly MPEG-TS for the
other HEVC identifier, not ISOBMFF. We can not present these pictures
correctly, thus this by itself I would be against mentioning something
getting fixed. We gain the capability of decoding, not presenting due
to Dolby not even using their own ICtCp colorspace as-is for Dolby
Vision profile 5 (which is pretty much everything that these custom
identifiers get used for since they are supposed to only be utilized
for video streams that are not decode'able with "standard decoders" -
which means things that cannot present the colorspace that Dolby
Vision's non-backwards compatible profiles utilize).

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Rostislav Pehlivanov
On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos  wrote:

> Hi!
>
> The Opus struct RawBitsContext is used in both the decoder and the encoder.
> The fact that *position is const avoids warnings in the decoder where
> it points into the bitstream. The encoder writes into the same
> pointer, attached cast silences the warning on targets where AV_WB32()
> does not internally cast the qualifier away.
>
> It is also possible to use a union if anybody prefers this:
> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
> index 627f832..baad4ce 100644
> --- a/libavcodec/opus_rc.h
> +++ b/libavcodec/opus_rc.h
> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>  uint32_t cacheval;
>  } RawBitsContext;
>
> +typedef struct RawBitsEncContext {
> +uint8_t *position;
> +uint32_t bytes;
> +uint32_t cachelen;
> +uint32_t cacheval;
> +} RawBitsEncContext;
> +
>  typedef struct OpusRangeCoder {
>  GetBitContext gb;
> -RawBitsContext rb;
> +union {
> +RawBitsContext rb;
> +RawBitsEncContext rbe;
> +};
>  uint32_t range;
>  uint32_t value;
>  uint32_t total_bits;
>
> and use rbe in ff_opus_rc_put_raw().
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


NAK, we don't do anyonymous unions. To silence the warning the const can be
just removed, but I've never seen a single warning on platforms I've tried.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 21:30 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >> > wrote:
>> >> >
>> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >>
>> >> >> > So as far as it's been possible to test this, that's been done
>> >> >>
>> >> >> Could you point me to a dva1 sample?
>> >> >
>> >> > I have not seen any dolby vision samples with avc in the wild.
>> >> > You can ask Vittorio if he has some as he noted about
>> >> > possibly being able to ask for some before.
>> >>
>> >> The patch is of course ok if Vittorio tested it with his samples.
>> >>
>> >> Thank you, Carl Eugen
>> >
>> > Unfortunately I have no idea what samples Vittorio does or does not
>> > possess, he has only mentioned off-hand that he might able to get hold
>> > of some if required. And since you were the one requiring them, I
>> > pointed you towards him.
>> >
>> > For myself, I am happy with the following points regarding this:
>> > 1. The identifiers are registered at the MPEG-4 RA.
>> > 2. There is a proper specification for these mappings that is
>> > seemingly kept up-to-date.
>> > 3. The mappings specification specifically notes that the only
>> > difference between the AVC and HEVC identifiers are the semantics
>> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> > specified which these mappings are based upon, so those semantics
>> > should not matter to us (and if they do, we have already broken those
>> > constraints at this point).
>> > 4. The mapping specification specifically notes that the given AVC and
>> > HEVC identifiers must also include the standard avcC and hvcC boxes so
>> > that they can be decoded normally without any additional custom code.
>> > 5. We have samples for at least one of the four identifiers that
>> > matches points 1 to 4.
>> > 6. Android, Chromium, VLC among others have already implemented these
>> > identifiers in the same way.
>> >
>> > Now, if you are not happy with these points, then please clearly state
>> > that you are blocking any and all additional identifier additions - no
>>
>> > matter how specified - as long as there are no samples on hand for
>> > them.
>>
>> I thought we had samples?
>>
>> Anyway, please mention ticket #7347.
>
> The sample last linked in that ticket was supposedly MPEG-TS for the
> other HEVC identifier, not ISOBMFF.

Why do you think so? Which sample did you test?

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


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos 
> > wrote:
> >>
> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
> >> > wrote:
> >> >>
> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> >> > wrote:
> >> >> >
> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >>
> >> >> >> > So as far as it's been possible to test this, that's been done
> >> >> >>
> >> >> >> Could you point me to a dva1 sample?
> >> >> >
> >> >> > I have not seen any dolby vision samples with avc in the wild.
> >> >> > You can ask Vittorio if he has some as he noted about
> >> >> > possibly being able to ask for some before.
> >> >>
> >> >> The patch is of course ok if Vittorio tested it with his samples.
> >> >>
> >> >> Thank you, Carl Eugen
> >> >
> >> > Unfortunately I have no idea what samples Vittorio does or does not
> >> > possess, he has only mentioned off-hand that he might able to get hold
> >> > of some if required. And since you were the one requiring them, I
> >> > pointed you towards him.
> >> >
> >> > For myself, I am happy with the following points regarding this:
> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> > 2. There is a proper specification for these mappings that is
> >> > seemingly kept up-to-date.
> >> > 3. The mappings specification specifically notes that the only
> >> > difference between the AVC and HEVC identifiers are the semantics
> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> > specified which these mappings are based upon, so those semantics
> >> > should not matter to us (and if they do, we have already broken those
> >> > constraints at this point).
> >> > 4. The mapping specification specifically notes that the given AVC and
> >> > HEVC identifiers must also include the standard avcC and hvcC boxes so
> >> > that they can be decoded normally without any additional custom code.
> >> > 5. We have samples for at least one of the four identifiers that
> >> > matches points 1 to 4.
> >> > 6. Android, Chromium, VLC among others have already implemented these
> >> > identifiers in the same way.
> >> >
> >> > Now, if you are not happy with these points, then please clearly state
> >> > that you are blocking any and all additional identifier additions - no
> >>
> >> > matter how specified - as long as there are no samples on hand for
> >> > them.
> >>
> >> I thought we had samples?
> >>
> >> Anyway, please mention ticket #7347.
> >
> > The sample last linked in that ticket was supposedly MPEG-TS for the
> > other HEVC identifier, not ISOBMFF.
>
> Why do you think so? Which sample did you test?
>

From #7347
> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> http://4kmedia.org/tag/dolby-vision/

The site also notes that it's supposed to be a transport stream. I did
not look further.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 21:35 GMT+01:00, Rostislav Pehlivanov :
> On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos  wrote:
>
>> Hi!
>>
>> The Opus struct RawBitsContext is used in both the decoder and the
>> encoder.
>> The fact that *position is const avoids warnings in the decoder where
>> it points into the bitstream. The encoder writes into the same
>> pointer, attached cast silences the warning on targets where AV_WB32()
>> does not internally cast the qualifier away.
>>
>> It is also possible to use a union if anybody prefers this:
>> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
>> index 627f832..baad4ce 100644
>> --- a/libavcodec/opus_rc.h
>> +++ b/libavcodec/opus_rc.h
>> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>>  uint32_t cacheval;
>>  } RawBitsContext;
>>
>> +typedef struct RawBitsEncContext {
>> +uint8_t *position;
>> +uint32_t bytes;
>> +uint32_t cachelen;
>> +uint32_t cacheval;
>> +} RawBitsEncContext;
>> +
>>  typedef struct OpusRangeCoder {
>>  GetBitContext gb;
>> -RawBitsContext rb;
>> +union {
>> +RawBitsContext rb;
>> +RawBitsEncContext rbe;
>> +};
>>  uint32_t range;
>>  uint32_t value;
>>  uint32_t total_bits;
>>
>> and use rbe in ff_opus_rc_put_raw().

> NAK, we don't do anyonymous unions.

The suggested patch does not contain unions.

> To silence the warning the const can be
> just removed,

No, the original data comes from a const pointer.

> but I've never seen a single warning on platforms I've tried.

It is shown on platforms where an optimized function (instead
of the default macro) for AV_RW32() exists, for example Android arm.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 21:53 GMT+01:00, Carl Eugen Hoyos :
> 2018-12-17 21:35 GMT+01:00, Rostislav Pehlivanov :
>> On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos 
>> wrote:
>>
>>> Hi!
>>>
>>> The Opus struct RawBitsContext is used in both the decoder and the
>>> encoder.
>>> The fact that *position is const avoids warnings in the decoder where
>>> it points into the bitstream. The encoder writes into the same
>>> pointer, attached cast silences the warning on targets where AV_WB32()
>>> does not internally cast the qualifier away.
>>>
>>> It is also possible to use a union if anybody prefers this:
>>> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
>>> index 627f832..baad4ce 100644
>>> --- a/libavcodec/opus_rc.h
>>> +++ b/libavcodec/opus_rc.h
>>> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>>>  uint32_t cacheval;
>>>  } RawBitsContext;
>>>
>>> +typedef struct RawBitsEncContext {
>>> +uint8_t *position;
>>> +uint32_t bytes;
>>> +uint32_t cachelen;
>>> +uint32_t cacheval;
>>> +} RawBitsEncContext;
>>> +
>>>  typedef struct OpusRangeCoder {
>>>  GetBitContext gb;
>>> -RawBitsContext rb;
>>> +union {
>>> +RawBitsContext rb;
>>> +RawBitsEncContext rbe;
>>> +};
>>>  uint32_t range;
>>>  uint32_t value;
>>>  uint32_t total_bits;
>>>
>>> and use rbe in ff_opus_rc_put_raw().
>
>> NAK, we don't do anyonymous unions.
>
> The suggested patch does not contain unions.
>
>> To silence the warning the const can be
>> just removed,
>
> No, the original data comes from a const pointer.

...when decoding.

>> but I've never seen a single warning on platforms I've tried.
>
> It is shown on platforms where an optimized function (instead
> of the default macro) for AV_RW32() exists, for example Android arm.

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


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 21:52 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
>> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos > >> >> > wrote:
>> >> >> >
>> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >>
>> >> >> >> > So as far as it's been possible to test this, that's been done
>> >> >> >>
>> >> >> >> Could you point me to a dva1 sample?
>> >> >> >
>> >> >> > I have not seen any dolby vision samples with avc in the wild.
>> >> >> > You can ask Vittorio if he has some as he noted about
>> >> >> > possibly being able to ask for some before.
>> >> >>
>> >> >> The patch is of course ok if Vittorio tested it with his samples.
>> >> >>
>> >> >> Thank you, Carl Eugen
>> >> >
>> >> > Unfortunately I have no idea what samples Vittorio does or does not
>> >> > possess, he has only mentioned off-hand that he might able to get
>> >> > hold
>> >> > of some if required. And since you were the one requiring them, I
>> >> > pointed you towards him.
>> >> >
>> >> > For myself, I am happy with the following points regarding this:
>> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> > 2. There is a proper specification for these mappings that is
>> >> > seemingly kept up-to-date.
>> >> > 3. The mappings specification specifically notes that the only
>> >> > difference between the AVC and HEVC identifiers are the semantics
>> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
>> >> > specified which these mappings are based upon, so those semantics
>> >> > should not matter to us (and if they do, we have already broken those
>> >> > constraints at this point).
>> >> > 4. The mapping specification specifically notes that the given AVC
>> >> > and
>> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
>> >> > so
>> >> > that they can be decoded normally without any additional custom code.
>> >> > 5. We have samples for at least one of the four identifiers that
>> >> > matches points 1 to 4.
>> >> > 6. Android, Chromium, VLC among others have already implemented these
>> >> > identifiers in the same way.
>> >> >
>> >> > Now, if you are not happy with these points, then please clearly
>> >> > state
>> >> > that you are blocking any and all additional identifier additions -
>> >> > no
>> >>
>> >> > matter how specified - as long as there are no samples on hand for
>> >> > them.
>> >>
>> >> I thought we had samples?
>> >>
>> >> Anyway, please mention ticket #7347.
>> >
>> > The sample last linked in that ticket was supposedly MPEG-TS for the
>> > other HEVC identifier, not ISOBMFF.
>>
>> Why do you think so? Which sample did you test?
>>
>
> From #7347
>> Dobly Vision transport stream with codec tag "dvhe" can be found under:
>> http://4kmedia.org/tag/dolby-vision/
>
> The site also notes that it's supposed to be a transport stream. I did
> not look further.

Then please allow me to once again suggest testing (at least if
you trust neither me nor Igor).

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


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 21:52 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos 
> > wrote:
> >>
> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos 
> >> > wrote:
> >> >>
> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
> >> >> > wrote:
> >> >> >>
> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  >> >> >> > wrote:
> >> >> >> >
> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >> >>
> >> >> >> >> > So as far as it's been possible to test this, that's been done
> >> >> >> >>
> >> >> >> >> Could you point me to a dva1 sample?
> >> >> >> >
> >> >> >> > I have not seen any dolby vision samples with avc in the wild.
> >> >> >> > You can ask Vittorio if he has some as he noted about
> >> >> >> > possibly being able to ask for some before.
> >> >> >>
> >> >> >> The patch is of course ok if Vittorio tested it with his samples.
> >> >> >>
> >> >> >> Thank you, Carl Eugen
> >> >> >
> >> >> > Unfortunately I have no idea what samples Vittorio does or does not
> >> >> > possess, he has only mentioned off-hand that he might able to get
> >> >> > hold
> >> >> > of some if required. And since you were the one requiring them, I
> >> >> > pointed you towards him.
> >> >> >
> >> >> > For myself, I am happy with the following points regarding this:
> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> >> > 2. There is a proper specification for these mappings that is
> >> >> > seemingly kept up-to-date.
> >> >> > 3. The mappings specification specifically notes that the only
> >> >> > difference between the AVC and HEVC identifiers are the semantics
> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the identifiers
> >> >> > specified which these mappings are based upon, so those semantics
> >> >> > should not matter to us (and if they do, we have already broken those
> >> >> > constraints at this point).
> >> >> > 4. The mapping specification specifically notes that the given AVC
> >> >> > and
> >> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
> >> >> > so
> >> >> > that they can be decoded normally without any additional custom code.
> >> >> > 5. We have samples for at least one of the four identifiers that
> >> >> > matches points 1 to 4.
> >> >> > 6. Android, Chromium, VLC among others have already implemented these
> >> >> > identifiers in the same way.
> >> >> >
> >> >> > Now, if you are not happy with these points, then please clearly
> >> >> > state
> >> >> > that you are blocking any and all additional identifier additions -
> >> >> > no
> >> >>
> >> >> > matter how specified - as long as there are no samples on hand for
> >> >> > them.
> >> >>
> >> >> I thought we had samples?
> >> >>
> >> >> Anyway, please mention ticket #7347.
> >> >
> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> >> > other HEVC identifier, not ISOBMFF.
> >>
> >> Why do you think so? Which sample did you test?
> >>
> >
> > From #7347
> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> >> http://4kmedia.org/tag/dolby-vision/
> >
> > The site also notes that it's supposed to be a transport stream. I did
> > not look further.
>
> Then please allow me to once again suggest testing (at least if
> you trust neither me nor Igor).
>
> Carl Eugen

That was a quote FROM Igor's post
(https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
mentioned it wrong then please just note that.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 21:35 GMT+01:00, Rostislav Pehlivanov :
>> On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos  wrote:
>>
>>> Hi!
>>>
>>> The Opus struct RawBitsContext is used in both the decoder and the
>>> encoder.
>>> The fact that *position is const avoids warnings in the decoder where
>>> it points into the bitstream. The encoder writes into the same
>>> pointer, attached cast silences the warning on targets where AV_WB32()
>>> does not internally cast the qualifier away.
>>>
>>> It is also possible to use a union if anybody prefers this:
>>> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
>>> index 627f832..baad4ce 100644
>>> --- a/libavcodec/opus_rc.h
>>> +++ b/libavcodec/opus_rc.h
>>> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>>>  uint32_t cacheval;
>>>  } RawBitsContext;
>>>
>>> +typedef struct RawBitsEncContext {
>>> +uint8_t *position;
>>> +uint32_t bytes;
>>> +uint32_t cachelen;
>>> +uint32_t cacheval;
>>> +} RawBitsEncContext;
>>> +
>>>  typedef struct OpusRangeCoder {
>>>  GetBitContext gb;
>>> -RawBitsContext rb;
>>> +union {
>>> +RawBitsContext rb;
>>> +RawBitsEncContext rbe;
>>> +};
>>>  uint32_t range;
>>>  uint32_t value;
>>>  uint32_t total_bits;
>>>
>>> and use rbe in ff_opus_rc_put_raw().
>
>> NAK, we don't do anyonymous unions.
>
> The suggested patch does not contain unions.
>

It does, Are you author of this patch?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 11:02 PM Jan Ekström  wrote:
>
> On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos  wrote:
> >
> > 2018-12-17 21:52 GMT+01:00, Jan Ekström :
> > > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos 
> > > wrote:
> > >>
> > >> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
> > >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos 
> > >> > wrote:
> > >> >>
> > >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
> > >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos 
> > >> >> > 
> > >> >> > wrote:
> > >> >> >>
> > >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> > >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos  > >> >> >> > wrote:
> > >> >> >> >
> > >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> > >> >> >>
> > >> >> >> >> > So as far as it's been possible to test this, that's been done
> > >> >> >> >>
> > >> >> >> >> Could you point me to a dva1 sample?
> > >> >> >> >
> > >> >> >> > I have not seen any dolby vision samples with avc in the wild.
> > >> >> >> > You can ask Vittorio if he has some as he noted about
> > >> >> >> > possibly being able to ask for some before.
> > >> >> >>
> > >> >> >> The patch is of course ok if Vittorio tested it with his samples.
> > >> >> >>
> > >> >> >> Thank you, Carl Eugen
> > >> >> >
> > >> >> > Unfortunately I have no idea what samples Vittorio does or does not
> > >> >> > possess, he has only mentioned off-hand that he might able to get
> > >> >> > hold
> > >> >> > of some if required. And since you were the one requiring them, I
> > >> >> > pointed you towards him.
> > >> >> >
> > >> >> > For myself, I am happy with the following points regarding this:
> > >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> > >> >> > 2. There is a proper specification for these mappings that is
> > >> >> > seemingly kept up-to-date.
> > >> >> > 3. The mappings specification specifically notes that the only
> > >> >> > difference between the AVC and HEVC identifiers are the semantics
> > >> >> > mentioned in ISO/IEC 14496-15. We already have all of the 
> > >> >> > identifiers
> > >> >> > specified which these mappings are based upon, so those semantics
> > >> >> > should not matter to us (and if they do, we have already broken 
> > >> >> > those
> > >> >> > constraints at this point).
> > >> >> > 4. The mapping specification specifically notes that the given AVC
> > >> >> > and
> > >> >> > HEVC identifiers must also include the standard avcC and hvcC boxes
> > >> >> > so
> > >> >> > that they can be decoded normally without any additional custom 
> > >> >> > code.
> > >> >> > 5. We have samples for at least one of the four identifiers that
> > >> >> > matches points 1 to 4.
> > >> >> > 6. Android, Chromium, VLC among others have already implemented 
> > >> >> > these
> > >> >> > identifiers in the same way.
> > >> >> >
> > >> >> > Now, if you are not happy with these points, then please clearly
> > >> >> > state
> > >> >> > that you are blocking any and all additional identifier additions -
> > >> >> > no
> > >> >>
> > >> >> > matter how specified - as long as there are no samples on hand for
> > >> >> > them.
> > >> >>
> > >> >> I thought we had samples?
> > >> >>
> > >> >> Anyway, please mention ticket #7347.
> > >> >
> > >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> > >> > other HEVC identifier, not ISOBMFF.
> > >>
> > >> Why do you think so? Which sample did you test?
> > >>
> > >
> > > From #7347
> > >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> > >> http://4kmedia.org/tag/dolby-vision/
> > >
> > > The site also notes that it's supposed to be a transport stream. I did
> > > not look further.
> >
> > Then please allow me to once again suggest testing (at least if
> > you trust neither me nor Igor).
> >
> > Carl Eugen
>
> That was a quote FROM Igor's post
> (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> mentioned it wrong then please just note that.
>
> Jan

OK, so it is ISOBMFF and not MPEG-TS unlike Igor and the site noted.
Thank you, now there is a sample.

I think this is the sample that Rodger coded this patch set originally
against when we were hacking on this stuff around mpv.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:02 GMT+01:00, Paul B Mahol :
> On 12/17/18, Carl Eugen Hoyos  wrote:
>> 2018-12-17 21:35 GMT+01:00, Rostislav Pehlivanov :
>>> On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos 
>>> wrote:
>>>
 Hi!

 The Opus struct RawBitsContext is used in both the decoder and the
 encoder.
 The fact that *position is const avoids warnings in the decoder where
 it points into the bitstream. The encoder writes into the same
 pointer, attached cast silences the warning on targets where AV_WB32()
 does not internally cast the qualifier away.

 It is also possible to use a union if anybody prefers this:
 diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
 index 627f832..baad4ce 100644
 --- a/libavcodec/opus_rc.h
 +++ b/libavcodec/opus_rc.h
 @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
  uint32_t cacheval;
  } RawBitsContext;

 +typedef struct RawBitsEncContext {
 +uint8_t *position;
 +uint32_t bytes;
 +uint32_t cachelen;
 +uint32_t cacheval;
 +} RawBitsEncContext;
 +
  typedef struct OpusRangeCoder {
  GetBitContext gb;
 -RawBitsContext rb;
 +union {
 +RawBitsContext rb;
 +RawBitsEncContext rbe;
 +};
  uint32_t range;
  uint32_t value;
  uint32_t total_bits;

 and use rbe in ff_opus_rc_put_raw().
>>
>>> NAK, we don't do anyonymous unions.
>>
>> The suggested patch does not contain unions.
>
> It does, Are you author of this patch?

This is a poc to show that there is a possible (although
ugly) alternative to the - imo - unavoidable cast that I
attached as a git-formatted patch.

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


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:02 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 21:52 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
>> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
>> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos
>> >> >> >> > > >> >> >> > wrote:
>> >> >> >> >
>> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >> >>
>> >> >> >> >> > So as far as it's been possible to test this, that's been
>> >> >> >> >> > done
>> >> >> >> >>
>> >> >> >> >> Could you point me to a dva1 sample?
>> >> >> >> >
>> >> >> >> > I have not seen any dolby vision samples with avc in the wild.
>> >> >> >> > You can ask Vittorio if he has some as he noted about
>> >> >> >> > possibly being able to ask for some before.
>> >> >> >>
>> >> >> >> The patch is of course ok if Vittorio tested it with his samples.
>> >> >> >>
>> >> >> >> Thank you, Carl Eugen
>> >> >> >
>> >> >> > Unfortunately I have no idea what samples Vittorio does or does
>> >> >> > not
>> >> >> > possess, he has only mentioned off-hand that he might able to get
>> >> >> > hold
>> >> >> > of some if required. And since you were the one requiring them, I
>> >> >> > pointed you towards him.
>> >> >> >
>> >> >> > For myself, I am happy with the following points regarding this:
>> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> > 2. There is a proper specification for these mappings that is
>> >> >> > seemingly kept up-to-date.
>> >> >> > 3. The mappings specification specifically notes that the only
>> >> >> > difference between the AVC and HEVC identifiers are the semantics
>> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> > identifiers
>> >> >> > specified which these mappings are based upon, so those semantics
>> >> >> > should not matter to us (and if they do, we have already broken
>> >> >> > those
>> >> >> > constraints at this point).
>> >> >> > 4. The mapping specification specifically notes that the given AVC
>> >> >> > and
>> >> >> > HEVC identifiers must also include the standard avcC and hvcC
>> >> >> > boxes
>> >> >> > so
>> >> >> > that they can be decoded normally without any additional custom
>> >> >> > code.
>> >> >> > 5. We have samples for at least one of the four identifiers that
>> >> >> > matches points 1 to 4.
>> >> >> > 6. Android, Chromium, VLC among others have already implemented
>> >> >> > these
>> >> >> > identifiers in the same way.
>> >> >> >
>> >> >> > Now, if you are not happy with these points, then please clearly
>> >> >> > state
>> >> >> > that you are blocking any and all additional identifier additions
>> >> >> > -
>> >> >> > no
>> >> >>
>> >> >> > matter how specified - as long as there are no samples on hand for
>> >> >> > them.
>> >> >>
>> >> >> I thought we had samples?
>> >> >>
>> >> >> Anyway, please mention ticket #7347.
>> >> >
>> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
>> >> > other HEVC identifier, not ISOBMFF.
>> >>
>> >> Why do you think so? Which sample did you test?
>> >>
>> >
>> > From #7347
>> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
>> >> http://4kmedia.org/tag/dolby-vision/
>> >
>> > The site also notes that it's supposed to be a transport stream. I did
>> > not look further.
>>
>> Then please allow me to once again suggest testing (at least if
>> you trust neither me nor Igor).

> That was a quote FROM Igor's post
> (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> mentioned it wrong then please just note that.

Which reminds me that you could mention him too in
the commit message:
https://patchwork.ffmpeg.org/patch/10023/

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 22:02 GMT+01:00, Paul B Mahol :
>> On 12/17/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-17 21:35 GMT+01:00, Rostislav Pehlivanov :
 On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos 
 wrote:

> Hi!
>
> The Opus struct RawBitsContext is used in both the decoder and the
> encoder.
> The fact that *position is const avoids warnings in the decoder where
> it points into the bitstream. The encoder writes into the same
> pointer, attached cast silences the warning on targets where AV_WB32()
> does not internally cast the qualifier away.
>
> It is also possible to use a union if anybody prefers this:
> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
> index 627f832..baad4ce 100644
> --- a/libavcodec/opus_rc.h
> +++ b/libavcodec/opus_rc.h
> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>  uint32_t cacheval;
>  } RawBitsContext;
>
> +typedef struct RawBitsEncContext {
> +uint8_t *position;
> +uint32_t bytes;
> +uint32_t cachelen;
> +uint32_t cacheval;
> +} RawBitsEncContext;
> +
>  typedef struct OpusRangeCoder {
>  GetBitContext gb;
> -RawBitsContext rb;
> +union {
> +RawBitsContext rb;
> +RawBitsEncContext rbe;
> +};
>  uint32_t range;
>  uint32_t value;
>  uint32_t total_bits;
>
> and use rbe in ff_opus_rc_put_raw().
>>>
 NAK, we don't do anyonymous unions.
>>>
>>> The suggested patch does not contain unions.
>>
>> It does, Are you author of this patch?
>
> This is a poc to show that there is a possible (although
> ugly) alternative to the - imo - unavoidable cast that I
> attached as a git-formatted patch.

Yes, it is poc - patch of crap.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 22:02 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos 
> > wrote:
> >>
> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström :
> >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos 
> >> > wrote:
> >> >>
> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
> >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
> >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
> >> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos
> >> >> >> >> >  >> >> >> >> > wrote:
> >> >> >> >> >
> >> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
> >> >> >> >>
> >> >> >> >> >> > So as far as it's been possible to test this, that's been
> >> >> >> >> >> > done
> >> >> >> >> >>
> >> >> >> >> >> Could you point me to a dva1 sample?
> >> >> >> >> >
> >> >> >> >> > I have not seen any dolby vision samples with avc in the wild.
> >> >> >> >> > You can ask Vittorio if he has some as he noted about
> >> >> >> >> > possibly being able to ask for some before.
> >> >> >> >>
> >> >> >> >> The patch is of course ok if Vittorio tested it with his samples.
> >> >> >> >>
> >> >> >> >> Thank you, Carl Eugen
> >> >> >> >
> >> >> >> > Unfortunately I have no idea what samples Vittorio does or does
> >> >> >> > not
> >> >> >> > possess, he has only mentioned off-hand that he might able to get
> >> >> >> > hold
> >> >> >> > of some if required. And since you were the one requiring them, I
> >> >> >> > pointed you towards him.
> >> >> >> >
> >> >> >> > For myself, I am happy with the following points regarding this:
> >> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
> >> >> >> > 2. There is a proper specification for these mappings that is
> >> >> >> > seemingly kept up-to-date.
> >> >> >> > 3. The mappings specification specifically notes that the only
> >> >> >> > difference between the AVC and HEVC identifiers are the semantics
> >> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
> >> >> >> > identifiers
> >> >> >> > specified which these mappings are based upon, so those semantics
> >> >> >> > should not matter to us (and if they do, we have already broken
> >> >> >> > those
> >> >> >> > constraints at this point).
> >> >> >> > 4. The mapping specification specifically notes that the given AVC
> >> >> >> > and
> >> >> >> > HEVC identifiers must also include the standard avcC and hvcC
> >> >> >> > boxes
> >> >> >> > so
> >> >> >> > that they can be decoded normally without any additional custom
> >> >> >> > code.
> >> >> >> > 5. We have samples for at least one of the four identifiers that
> >> >> >> > matches points 1 to 4.
> >> >> >> > 6. Android, Chromium, VLC among others have already implemented
> >> >> >> > these
> >> >> >> > identifiers in the same way.
> >> >> >> >
> >> >> >> > Now, if you are not happy with these points, then please clearly
> >> >> >> > state
> >> >> >> > that you are blocking any and all additional identifier additions
> >> >> >> > -
> >> >> >> > no
> >> >> >>
> >> >> >> > matter how specified - as long as there are no samples on hand for
> >> >> >> > them.
> >> >> >>
> >> >> >> I thought we had samples?
> >> >> >>
> >> >> >> Anyway, please mention ticket #7347.
> >> >> >
> >> >> > The sample last linked in that ticket was supposedly MPEG-TS for the
> >> >> > other HEVC identifier, not ISOBMFF.
> >> >>
> >> >> Why do you think so? Which sample did you test?
> >> >>
> >> >
> >> > From #7347
> >> >> Dobly Vision transport stream with codec tag "dvhe" can be found under:
> >> >> http://4kmedia.org/tag/dolby-vision/
> >> >
> >> > The site also notes that it's supposed to be a transport stream. I did
> >> > not look further.
> >>
> >> Then please allow me to once again suggest testing (at least if
> >> you trust neither me nor Igor).
>
> > That was a quote FROM Igor's post
> > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
> > mentioned it wrong then please just note that.
>
> Which reminds me that you could mention him too in
> the commit message:
> https://patchwork.ffmpeg.org/patch/10023/
>
> Carl Eugen

I did not see that patch when taking the initial single-identifier
patch from Rodger, and even compared to Rodger's original patch me
adding the other identifiers and adding the MPEG-4 RA identifier
description comments and proper commit message at that point keep very
little of what was there to begin with.

Unless there is something substantial, I would rather just get done
with this pain that is trying to get a seemingly darn simple patch
through review. At this point I hate humans, I hate communication.
This is not fun. If you got any enjoyment of this, I am very happy for
you.

Jan
___
ffmpeg-devel mailing list
ffmp

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:18 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 11:11 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 22:02 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 10:57 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-17 21:52 GMT+01:00, Jan Ekström :
>> >> > On Mon, Dec 17, 2018 at 10:49 PM Carl Eugen Hoyos
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> 2018-12-17 21:30 GMT+01:00, Jan Ekström :
>> >> >> > On Mon, Dec 17, 2018 at 10:23 PM Carl Eugen Hoyos
>> >> >> > 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> 2018-12-17 21:17 GMT+01:00, Jan Ekström :
>> >> >> >> > On Mon, Dec 17, 2018 at 3:47 PM Carl Eugen Hoyos
>> >> >> >> > 
>> >> >> >> > wrote:
>> >> >> >> >>
>> >> >> >> >> 2018-12-17 7:58 GMT+01:00, Jan Ekström :
>> >> >> >> >> > On Mon, Dec 17, 2018, 03:02 Carl Eugen Hoyos
>> >> >> >> >> > > >> >> >> >> > wrote:
>> >> >> >> >> >
>> >> >> >> >> >> 2018-12-17 1:58 GMT+01:00, Jan Ekström :
>> >> >> >> >>
>> >> >> >> >> >> > So as far as it's been possible to test this, that's been
>> >> >> >> >> >> > done
>> >> >> >> >> >>
>> >> >> >> >> >> Could you point me to a dva1 sample?
>> >> >> >> >> >
>> >> >> >> >> > I have not seen any dolby vision samples with avc in the
>> >> >> >> >> > wild.
>> >> >> >> >> > You can ask Vittorio if he has some as he noted about
>> >> >> >> >> > possibly being able to ask for some before.
>> >> >> >> >>
>> >> >> >> >> The patch is of course ok if Vittorio tested it with his
>> >> >> >> >> samples.
>> >> >> >> >>
>> >> >> >> >> Thank you, Carl Eugen
>> >> >> >> >
>> >> >> >> > Unfortunately I have no idea what samples Vittorio does or does
>> >> >> >> > not
>> >> >> >> > possess, he has only mentioned off-hand that he might able to
>> >> >> >> > get
>> >> >> >> > hold
>> >> >> >> > of some if required. And since you were the one requiring them,
>> >> >> >> > I
>> >> >> >> > pointed you towards him.
>> >> >> >> >
>> >> >> >> > For myself, I am happy with the following points regarding
>> >> >> >> > this:
>> >> >> >> > 1. The identifiers are registered at the MPEG-4 RA.
>> >> >> >> > 2. There is a proper specification for these mappings that is
>> >> >> >> > seemingly kept up-to-date.
>> >> >> >> > 3. The mappings specification specifically notes that the only
>> >> >> >> > difference between the AVC and HEVC identifiers are the
>> >> >> >> > semantics
>> >> >> >> > mentioned in ISO/IEC 14496-15. We already have all of the
>> >> >> >> > identifiers
>> >> >> >> > specified which these mappings are based upon, so those
>> >> >> >> > semantics
>> >> >> >> > should not matter to us (and if they do, we have already broken
>> >> >> >> > those
>> >> >> >> > constraints at this point).
>> >> >> >> > 4. The mapping specification specifically notes that the given
>> >> >> >> > AVC
>> >> >> >> > and
>> >> >> >> > HEVC identifiers must also include the standard avcC and hvcC
>> >> >> >> > boxes
>> >> >> >> > so
>> >> >> >> > that they can be decoded normally without any additional custom
>> >> >> >> > code.
>> >> >> >> > 5. We have samples for at least one of the four identifiers
>> >> >> >> > that
>> >> >> >> > matches points 1 to 4.
>> >> >> >> > 6. Android, Chromium, VLC among others have already implemented
>> >> >> >> > these
>> >> >> >> > identifiers in the same way.
>> >> >> >> >
>> >> >> >> > Now, if you are not happy with these points, then please
>> >> >> >> > clearly
>> >> >> >> > state
>> >> >> >> > that you are blocking any and all additional identifier
>> >> >> >> > additions
>> >> >> >> > -
>> >> >> >> > no
>> >> >> >>
>> >> >> >> > matter how specified - as long as there are no samples on hand
>> >> >> >> > for
>> >> >> >> > them.
>> >> >> >>
>> >> >> >> I thought we had samples?
>> >> >> >>
>> >> >> >> Anyway, please mention ticket #7347.
>> >> >> >
>> >> >> > The sample last linked in that ticket was supposedly MPEG-TS for
>> >> >> > the
>> >> >> > other HEVC identifier, not ISOBMFF.
>> >> >>
>> >> >> Why do you think so? Which sample did you test?
>> >> >>
>> >> >
>> >> > From #7347
>> >> >> Dobly Vision transport stream with codec tag "dvhe" can be found
>> >> >> under:
>> >> >> http://4kmedia.org/tag/dolby-vision/
>> >> >
>> >> > The site also notes that it's supposed to be a transport stream. I
>> >> > did
>> >> > not look further.
>> >>
>> >> Then please allow me to once again suggest testing (at least if
>> >> you trust neither me nor Igor).
>>
>> > That was a quote FROM Igor's post
>> > (https://trac.ffmpeg.org/ticket/7347#comment:12). If he and the site
>> > mentioned it wrong then please just note that.
>>
>> Which reminds me that you could mention him too in
>> the commit message:
>> https://patchwork.ffmpeg.org/patch/10023/
>>
>> Carl Eugen
>
> I did not see that patch when taking the initial single-identifier

I know (actually: I assumed so) and wrote that in my first comment.

> patch from Rodger, and even compared to Rodger's original patch me
> adding the other identifiers and adding the MPEG-4 RA identifier
> description comments and proper

Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Paul B Mahol
On 12/3/18, Jan Ekström  wrote:
> From: Rodger Combs 
>
> These are registered identifiers at the MPEG-4 RA, which are
> defined as to be utilized for Dolby Vision AVC/HEVC streams that
> are not correctly presentable by standards-compliant AVC/HEVC players.
>
> According to the Dolby Vision specification for ISOBMFF, these sample
> entry codes are specified to have the standard AVC or HEVC decoder
> configuration box in addition to the Dolby custom DOVIConfigurationBox.
> This is what enables us to decode the streams without custom parsing.
>
> For correct presentation information from the DOVIConfigurationBox
> is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> layer).
> ---
>  libavformat/isom.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index ca9d22e4f7..f7e1654484 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>
>  { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which
> indicates parameter sets may be in ES */
>  { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which
> indicates parameter sets shall not be in ES */
> +{ AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby
> Vision derived from hev1 */
> + /* dvh1 is handled
> within mov.c */
>
>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
> @@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>  { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
>  { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422
> produced by FCP */
>  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2
> AVC-LongG */
> +{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby
> Vision derived from avc1 */
> +{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby
> Vision derived from avc3 */
>
>  { AV_CODEC_ID_VP8,  MKTAG('v', 'p', '0', '8') }, /* VP8 */
>  { AV_CODEC_ID_VP9,  MKTAG('v', 'p', '0', '9') }, /* VP9 */
> --
> 2.19.2

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :

> The Opus struct RawBitsContext is used in both the decoder and the encoder.
> The fact that *position is const avoids warnings in the decoder where
> it points into the bitstream. The encoder writes into the same
> pointer, attached cast silences the warning on targets where AV_WB32()
> does not internally cast the qualifier away.

Ping.

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


Re: [FFmpeg-devel] [PATCH 2/2] lavf/mov: document the dvh1 codec switch based on hvcC availability

2018-12-17 Thread Paul B Mahol
On 12/3/18, Jan Ekström  wrote:
> ---
>  libavformat/mov.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ec57a05803..497790522f 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -1903,6 +1903,11 @@ static int mov_read_glbl(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
>  if (ret < 0)
>  return ret;
>  if (atom.type == MKTAG('h','v','c','C') && st->codecpar->codec_tag ==
> MKTAG('d','v','h','1'))
> +/* HEVC-based Dolby Vision derived from hvc1.
> +   Happens to match with an identifier
> +   previously utilized for DV. Thus, if we have
> +   the hvcC extradata box available as specified,
> +   set codec to HEVC */
>  st->codecpar->codec_id = AV_CODEC_ID_HEVC;
>
>  return 0;
> --
> 2.19.2

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :
>
>> The Opus struct RawBitsContext is used in both the decoder and the
>> encoder.
>> The fact that *position is const avoids warnings in the decoder where
>> it points into the bitstream. The encoder writes into the same
>> pointer, attached cast silences the warning on targets where AV_WB32()
>> does not internally cast the qualifier away.
>
> Ping.

Anonymous unions are not accepted. NAK 2X!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:26 GMT+01:00, Paul B Mahol :
> On 12/17/18, Carl Eugen Hoyos  wrote:
>> 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :
>>
>>> The Opus struct RawBitsContext is used in both the decoder and the
>>> encoder.
>>> The fact that *position is const avoids warnings in the decoder where
>>> it points into the bitstream. The encoder writes into the same
>>> pointer, attached cast silences the warning on targets where AV_WB32()
>>> does not internally cast the qualifier away.
>>
>> Ping.
>
> Anonymous unions are not accepted. NAK 2X!

Again: There is no union in this patch.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 22:26 GMT+01:00, Paul B Mahol :
>> On 12/17/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :
>>>
 The Opus struct RawBitsContext is used in both the decoder and the
 encoder.
 The fact that *position is const avoids warnings in the decoder where
 it points into the bitstream. The encoder writes into the same
 pointer, attached cast silences the warning on targets where AV_WB32()
 does not internally cast the qualifier away.
>>>
>>> Ping.
>>
>> Anonymous unions are not accepted. NAK 2X!
>
> Again: There is no union in this patch.

Use "grep union" on your patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 11:23 PM Paul B Mahol  wrote:
>
> On 12/3/18, Jan Ekström  wrote:
> > From: Rodger Combs 
> >
> > These are registered identifiers at the MPEG-4 RA, which are
> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> > are not correctly presentable by standards-compliant AVC/HEVC players.
> >
> > According to the Dolby Vision specification for ISOBMFF, these sample
> > entry codes are specified to have the standard AVC or HEVC decoder
> > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> > This is what enables us to decode the streams without custom parsing.
> >
> > For correct presentation information from the DOVIConfigurationBox
> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> > layer).
> > ---
> >  libavformat/isom.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/isom.c b/libavformat/isom.c
> > index ca9d22e4f7..f7e1654484 100644
> > --- a/libavformat/isom.c
> > +++ b/libavformat/isom.c
> > @@ -163,6 +163,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
> >
> >  { AV_CODEC_ID_HEVC, MKTAG('h', 'e', 'v', '1') }, /* HEVC/H.265 which
> > indicates parameter sets may be in ES */
> >  { AV_CODEC_ID_HEVC, MKTAG('h', 'v', 'c', '1') }, /* HEVC/H.265 which
> > indicates parameter sets shall not be in ES */
> > +{ AV_CODEC_ID_HEVC, MKTAG('d', 'v', 'h', 'e') }, /* HEVC-based Dolby
> > Vision derived from hev1 */
> > + /* dvh1 is handled
> > within mov.c */
> >
> >  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '1') }, /* AVC-1/H.264 */
> >  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'c', '2') },
> > @@ -185,6 +187,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
> >  { AV_CODEC_ID_H264, MKTAG('r', 'v', '6', '4') }, /* X-Com Radvision */
> >  { AV_CODEC_ID_H264, MKTAG('x', 'a', 'l', 'g') }, /* XAVC-L HD422
> > produced by FCP */
> >  { AV_CODEC_ID_H264, MKTAG('a', 'v', 'l', 'g') }, /* Panasonic P2
> > AVC-LongG */
> > +{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', 'v') }, /* AVC-based Dolby
> > Vision derived from avc1 */
> > +{ AV_CODEC_ID_H264, MKTAG('d', 'v', 'a', '1') }, /* AVC-based Dolby
> > Vision derived from avc3 */
> >
> >  { AV_CODEC_ID_VP8,  MKTAG('v', 'p', '0', '8') }, /* VP8 */
> >  { AV_CODEC_ID_VP9,  MKTAG('v', 'p', '0', '9') }, /* VP9 */
> > --
> > 2.19.2
>
> OK

As it was verified to pass FATE on IRC, the patch with the comments
matching the AVC identifiers (they were the other way around) was
pushed.

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


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:29 GMT+01:00, Paul B Mahol :
> On 12/17/18, Carl Eugen Hoyos  wrote:
>> 2018-12-17 22:26 GMT+01:00, Paul B Mahol :
>>> On 12/17/18, Carl Eugen Hoyos  wrote:
 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :

> The Opus struct RawBitsContext is used in both the decoder and the
> encoder.
> The fact that *position is const avoids warnings in the decoder where
> it points into the bitstream. The encoder writes into the same
> pointer, attached cast silences the warning on targets where AV_WB32()
> does not internally cast the qualifier away.

 Ping.
>>>
>>> Anonymous unions are not accepted. NAK 2X!
>>
>> Again: There is no union in this patch.
>
> Use "grep union" on your patch.

$ grep union 0001-lavc-opus_rc-Cast-a-const-pointer-to-uint8_t.patch
$

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


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:27 GMT+01:00, Rodger Combs :
> ffmpeg | branch: master | Rodger Combs  | Mon Nov  5
> 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] | committer:
> Jan Ekström
>
> lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
>
> These are registered identifiers at the MPEG-4 RA, which are
> defined as to be utilized for Dolby Vision AVC/HEVC streams that
> are not correctly presentable by standards-compliant AVC/HEVC players.
>
> According to the Dolby Vision specification for ISOBMFF, these sample
> entry codes are specified to have the standard AVC or HEVC decoder
> configuration box in addition to the Dolby custom DOVIConfigurationBox.
> This is what enables us to decode the streams without custom parsing.
>
> For correct presentation information from the DOVIConfigurationBox
> is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> layer).

This is not only missing a requested mention of the relevant ticket
where a sample
for this patch is linked (apparently the only one existing) but also a
mention of Igor Selivanov who had sent an identical patch to the mailing list.

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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Aleksey Skripka
Evening!

First of all, about playlist writeout:
before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!) 
creating via .tmp file.
after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become 
dependent on +temp_file flag.

I suggest to return to original logic. 
Non-atomic playlist writeout - is a disaster to just any hls player. This way 
we will force everyone (except offline VOD) to start using +temp_file. Always! 
Also, if somebody relying on this - they will get broken streams just after 
upgrade (It seems to me, that it can be a lot).

So, here maintainer should decide how to be.


and about single_file:
if it will be decided to stay with current way (playlist's .tmp logic 
controlled by +temp_file flag), you are right - temp_file+single_file case 
become unreal.
if it will be decided to return original behaviour (playlist always via .tmp), 
someone can choose how to writeout media file (despite i understand temp+single 
is very-very rare case).

Thanks!
-- 
Aleksey Skripk



> On 17 Dec 2018, at 19:12, Adrian  wrote:
> 
> Comments inline.
> 
> Regards
> Adrian Guzowski
> 
> W dniu 17.12.2018 o 16:56, Aleksey Skripka pisze:
>>> On 17 Dec 2018, at 18:45, Adrian >> > wrote:
>>> 
>>> IMO temp_file+single_file should be mutually exclusive - why would you want 
>>> to have temp file when you're using only one file anyway? In this mode you 
>>> would either pool for file changes or just get updated playlist with new 
>>> byte range (and that one should be updated after video file). I believe 
>>> this restriction was already in place anyway, because there already were 
>>> checks for HLS_SINGLE_FILE not being set, before doing actual rename, so 
>>> this was just a simplification of those conditions.
>> not me to decide, please ;)
>> if playlist will always be done via .tmp, we will have a choice.
> Could you clarify what choice you're talking about? And the purpose of this 
> choice - frankly you got me lost with this. Regardless, I feel we're getting 
> off topic.
>>> As for playlist file - I'm not sure I follow, I've changed only places 
>>> where temp files were already used, so I don't think I broke something in 
>>> that matter.
>> not you, it was introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6
> Not quite, temp files were already a feature, this commit narrowed conditions 
> where they are used. If you're referring to change in hls_window about not 
> checking TEMP flag - that is unrelated to current state (before commit 
> introducing regression, check was ignoring TEMP flag, after commit it does 
> take it into account - probably should be discussed with person responsible 
> for original change as to why it was changed that way, so that's out of scope 
> of this patch. Issue at hand is not using TEMP files at all and that is fixed 
> by this patch.
> 
>>> From repeat+level+trace I believe I saw that playlist file actually was 
>>> using a temp file, so if that's the thing you are concerned about, it seems 
>>> like it's all good.
>>> 
>>> Regards
>>> Adrian Guzowski
>>> 
>>> W dniu 17.12.2018 o 16:36, Aleksey Skripka pisze:
 Greetings!
 
 Adrian,
 with your variant of patch in case of '-hls_flags +temp_file+single_file' 
 no .tmp logic will be used.
 not sure what is better, but all previous versions was doing so.
 
 and also, i'm still sure, that for backward compatibility with all 
 previous versions, index.m3u8 should always be written via .tmp file.
 
 ps:
 i noticed this bug such way: i do not use +temp_file, but rely on atomic 
 rename of index.m3u8.
 
> On 17 Dec 2018, at 17:23, Adrian  wrote:
> 
> Hello,
> 
> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
> muxed stopped working.
> It looks like a regression introduced by 
> 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6. I've prepared a patch and 
> tested it cross-compiling for my project's target platform (ARM, 
> Buildroot) and it seems like everything is in order. I ran regression 
> tests and nothing seems to be broken.
> 
> Please review it and possibly include this patch.
> 
> Regards
> Adrian Guzowski
> 
> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option.patch>___
> 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 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-dev

Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 22:29 GMT+01:00, Paul B Mahol :
>> On 12/17/18, Carl Eugen Hoyos  wrote:
>>> 2018-12-17 22:26 GMT+01:00, Paul B Mahol :
 On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :
>
>> The Opus struct RawBitsContext is used in both the decoder and the
>> encoder.
>> The fact that *position is const avoids warnings in the decoder where
>> it points into the bitstream. The encoder writes into the same
>> pointer, attached cast silences the warning on targets where AV_WB32()
>> does not internally cast the qualifier away.
>
> Ping.

 Anonymous unions are not accepted. NAK 2X!
>>>
>>> Again: There is no union in this patch.
>>
>> Use "grep union" on your patch.
>
> $ grep union 0001-lavc-opus_rc-Cast-a-const-pointer-to-uint8_t.patch
> $

Why you posted two variants of patch in single mail?

This is extremely confusing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Paul B Mahol
On 12/17/18, Carl Eugen Hoyos  wrote:
> 2018-12-17 22:27 GMT+01:00, Rodger Combs :
>> ffmpeg | branch: master | Rodger Combs  | Mon Nov
>> 5
>> 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] |
>> committer:
>> Jan Ekström
>>
>> lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
>>
>> These are registered identifiers at the MPEG-4 RA, which are
>> defined as to be utilized for Dolby Vision AVC/HEVC streams that
>> are not correctly presentable by standards-compliant AVC/HEVC players.
>>
>> According to the Dolby Vision specification for ISOBMFF, these sample
>> entry codes are specified to have the standard AVC or HEVC decoder
>> configuration box in addition to the Dolby custom DOVIConfigurationBox.
>> This is what enables us to decode the streams without custom parsing.
>>
>> For correct presentation information from the DOVIConfigurationBox
>> is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
>> layer).
>
> This is not only missing a requested mention of the relevant ticket
> where a sample
> for this patch is linked (apparently the only one existing) but also a
> mention of Igor Selivanov who had sent an identical patch to the mailing
> list.

The patches are different.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:37 GMT+01:00, Paul B Mahol :
> On 12/17/18, Carl Eugen Hoyos  wrote:
>> 2018-12-17 22:29 GMT+01:00, Paul B Mahol :
>>> On 12/17/18, Carl Eugen Hoyos  wrote:
 2018-12-17 22:26 GMT+01:00, Paul B Mahol :
> On 12/17/18, Carl Eugen Hoyos  wrote:
>> 2018-12-17 2:47 GMT+01:00, Carl Eugen Hoyos :
>>
>>> The Opus struct RawBitsContext is used in both the decoder and the
>>> encoder.
>>> The fact that *position is const avoids warnings in the decoder where
>>> it points into the bitstream. The encoder writes into the same
>>> pointer, attached cast silences the warning on targets where
>>> AV_WB32()
>>> does not internally cast the qualifier away.
>>
>> Ping.
>
> Anonymous unions are not accepted. NAK 2X!

 Again: There is no union in this patch.
>>>
>>> Use "grep union" on your patch.
>>
>> $ grep union 0001-lavc-opus_rc-Cast-a-const-pointer-to-uint8_t.patch
>> $
>
> Why you posted two variants of patch in single mail?
>
> This is extremely confusing.

Sorry: I posted a patch and I mentioned that the only alternative
that I saw is an ugly union (in case somebody doesn't like the
cast).
As explained in my original mail, the same definition is used
by two different parts of the code with different semantics, it
is not possible to simply drop the const.

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


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 11:36 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 22:27 GMT+01:00, Rodger Combs :
> > ffmpeg | branch: master | Rodger Combs  | Mon Nov  5
> > 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] | committer:
> > Jan Ekström
> >
> > lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
> >
> > These are registered identifiers at the MPEG-4 RA, which are
> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> > are not correctly presentable by standards-compliant AVC/HEVC players.
> >
> > According to the Dolby Vision specification for ISOBMFF, these sample
> > entry codes are specified to have the standard AVC or HEVC decoder
> > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> > This is what enables us to decode the streams without custom parsing.
> >
> > For correct presentation information from the DOVIConfigurationBox
> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> > layer).
>
> This is not only missing a requested mention of the relevant ticket
> where a sample
> for this patch is linked (apparently the only one existing) but also a
> mention of Igor Selivanov who had sent an identical patch to the mailing list.
>
> Carl Eugen

Thank you for once, for once actually saying what on earth you want.

Now please actually mention how do you want the ticket be mentioned.
It is not "fixed" or "fixes" because it cannot be presented without
the colorspace being figured out. I commented on this.
As for the identical patch, you yourself noted that you quite clearly
could see me not knowing about identical work being done, and I had
clearly put effort into adding the most appropriate descriptions for
the identifiers and writing up a proper commit message. Those by
themselves are most likely much more work than just writing up the
original patch that Rodger wrote. Also, with all due respect I do not
recall us having to mention all of the previous people who had
independently come up with the same solution.

I think all of us would have been much happier if THESE THINGS were
what you had said ages ago. I had wondered for ages what it really was
that you wanted to block my changes for. Which is why I specifically
noted that if you wanted to block my changes then please SAY SO. You
opted to NOT BLOCK and not say anything specifically. And
unfortunately at this point I was already completely exhausted and I
just wanted to get past this thing, so that unless there was something
substantial I would not change the patch set.

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


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:45 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 11:36 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 22:27 GMT+01:00, Rodger Combs :
>> > ffmpeg | branch: master | Rodger Combs  | Mon
>> > Nov  5
>> > 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] |
>> > committer:
>> > Jan Ekström
>> >
>> > lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
>> >
>> > These are registered identifiers at the MPEG-4 RA, which are
>> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
>> > are not correctly presentable by standards-compliant AVC/HEVC players.
>> >
>> > According to the Dolby Vision specification for ISOBMFF, these sample
>> > entry codes are specified to have the standard AVC or HEVC decoder
>> > configuration box in addition to the Dolby custom DOVIConfigurationBox.
>> > This is what enables us to decode the streams without custom parsing.
>> >
>> > For correct presentation information from the DOVIConfigurationBox
>> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
>> > layer).
>>
>> This is not only missing a requested mention of the relevant ticket
>> where a sample
>> for this patch is linked (apparently the only one existing) but also a
>> mention of Igor Selivanov who had sent an identical patch to the mailing
>> list.
>>
>> Carl Eugen
>
> Thank you for once, for once actually saying what on earth you want.
>
> Now please actually mention how do you want the ticket be mentioned.
> It is not "fixed" or "fixes" because it cannot be presented without
> the colorspace being figured out.

I don't understand:
Why are you asking this after pushing the objected patch?

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


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 11:47 PM Carl Eugen Hoyos  wrote:
>
> 2018-12-17 22:45 GMT+01:00, Jan Ekström :
> > On Mon, Dec 17, 2018 at 11:36 PM Carl Eugen Hoyos 
> > wrote:
> >>
> >> 2018-12-17 22:27 GMT+01:00, Rodger Combs :
> >> > ffmpeg | branch: master | Rodger Combs  | Mon
> >> > Nov  5
> >> > 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] |
> >> > committer:
> >> > Jan Ekström
> >> >
> >> > lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
> >> >
> >> > These are registered identifiers at the MPEG-4 RA, which are
> >> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
> >> > are not correctly presentable by standards-compliant AVC/HEVC players.
> >> >
> >> > According to the Dolby Vision specification for ISOBMFF, these sample
> >> > entry codes are specified to have the standard AVC or HEVC decoder
> >> > configuration box in addition to the Dolby custom DOVIConfigurationBox.
> >> > This is what enables us to decode the streams without custom parsing.
> >> >
> >> > For correct presentation information from the DOVIConfigurationBox
> >> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
> >> > layer).
> >>
> >> This is not only missing a requested mention of the relevant ticket
> >> where a sample
> >> for this patch is linked (apparently the only one existing) but also a
> >> mention of Igor Selivanov who had sent an identical patch to the mailing
> >> list.
> >>
> >> Carl Eugen
> >
> > Thank you for once, for once actually saying what on earth you want.
> >
> > Now please actually mention how do you want the ticket be mentioned.
> > It is not "fixed" or "fixes" because it cannot be presented without
> > the colorspace being figured out.
>
> I don't understand:
> Why are you asking this after pushing the objected patch?
>

Because I had mentioned my opinion, and then you seemingly dropped the
topic in the following replies, which seemed to me like that was it.

And now that you object, I want to know what you want.

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


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264

2018-12-17 Thread Carl Eugen Hoyos
2018-12-17 22:51 GMT+01:00, Jan Ekström :
> On Mon, Dec 17, 2018 at 11:47 PM Carl Eugen Hoyos 
> wrote:
>>
>> 2018-12-17 22:45 GMT+01:00, Jan Ekström :
>> > On Mon, Dec 17, 2018 at 11:36 PM Carl Eugen Hoyos 
>> > wrote:
>> >>
>> >> 2018-12-17 22:27 GMT+01:00, Rodger Combs :
>> >> > ffmpeg | branch: master | Rodger Combs  | Mon
>> >> > Nov  5
>> >> > 10:26:24 2018 -0600| [6ebe88f3a4c427511eba7495896f4a57a2b4b529] |
>> >> > committer:
>> >> > Jan Ekström
>> >> >
>> >> > lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
>> >> >
>> >> > These are registered identifiers at the MPEG-4 RA, which are
>> >> > defined as to be utilized for Dolby Vision AVC/HEVC streams that
>> >> > are not correctly presentable by standards-compliant AVC/HEVC
>> >> > players.
>> >> >
>> >> > According to the Dolby Vision specification for ISOBMFF, these sample
>> >> > entry codes are specified to have the standard AVC or HEVC decoder
>> >> > configuration box in addition to the Dolby custom
>> >> > DOVIConfigurationBox.
>> >> > This is what enables us to decode the streams without custom parsing.
>> >> >
>> >> > For correct presentation information from the DOVIConfigurationBox
>> >> > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement
>> >> > layer).
>> >>
>> >> This is not only missing a requested mention of the relevant ticket
>> >> where a sample
>> >> for this patch is linked (apparently the only one existing) but also a
>> >> mention of Igor Selivanov who had sent an identical patch to the
>> >> mailing
>> >> list.
>> >>
>> >> Carl Eugen
>> >
>> > Thank you for once, for once actually saying what on earth you want.
>> >
>> > Now please actually mention how do you want the ticket be mentioned.
>> > It is not "fixed" or "fixes" because it cannot be presented without
>> > the colorspace being figured out.
>>
>> I don't understand:
>> Why are you asking this after pushing the objected patch?
>>
>
> Because I had mentioned my opinion, and then you seemingly dropped the
> topic in the following replies, which seemed to me like that was it.
>
> And now that you object, I want to know what you want.

That you mention the ticket that contains a link to the only sample
we know of.
Since the sample cannot be played without your patch but plays
now, I believe you fixed the ticket but if you disagree you could
have written "does not fix ticket ...".

Which of course makes no difference now.

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


[FFmpeg-devel] avdevice/decklink: Fix seg fault in decklink

2018-12-17 Thread BIGLER Don (Framatome)
Attached is a patch that fixes a potential segmentation fault in 
avdevice/decklink when used in a multi-threaded environment outside of ffmpeg.  
Because the capture_started flag is not set the stream is not closed properly.  
This can cause a segmentation fault when the input callback is called in a 
multi-threaded reader that has not stopped reading before the connection is 
closed.

Best regards,

Don Bigler, Ph.D.
Principal Engineer
NDE Engineering

Framatome

Office   1 434 832 4181
Fax   1 434 382 3773

155 Mill Ridge Road
Lynchburg, VA 24503
mail to:  don.big...@framatome.com
[cid:image004.png@01D4962A.22F659B0]
www.framatome.com
Important Note: This e-mail may contain trade secrets or privileged, 
undisclosed or otherwise confidential information. If you have received this 
e-mail in error, you are hereby notified that any review, copying or 
distribution of it is strictly prohibited. Please inform us immediately and 
destroy the original transmittal. Thank you for your cooperation.
[cid:image004.jpg@01D3848C.B8D0DCE0]Please don't print this e-mail unless you 
really need to. Thank you



0001-avdevice-decklink-Fix-seg-fault-in-decklink.patch
Description: 0001-avdevice-decklink-Fix-seg-fault-in-decklink.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found

2018-12-17 Thread Mark Thompson
On 11/12/2018 14:28, Paul B Mahol wrote:
> On 12/11/18, Carl Eugen Hoyos  wrote:
>> 2018-12-10 23:41 GMT+01:00, Mark Thompson :
>>> On 09/12/2018 14:21, Mark Thompson wrote:
 On 09/12/2018 13:54, Paul B Mahol wrote:
> On 12/9/18, Mark Thompson  wrote:
>> On 09/12/2018 08:52, Paul B Mahol wrote:
>>> On 12/7/18, Paul B Mahol  wrote:
 On 12/7/18, Michael Niedermayer  wrote:
> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
>> On 12/7/18, Paul B Mahol  wrote:
>>> On 12/7/18, Michael Niedermayer  wrote:
 On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
> This recovers state with #7374 linked sample.
>
> Work funded by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/h264_refs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index eaf965e43d..5645a203a7 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -718,6 +718,7 @@ int
> ff_h264_execute_ref_pic_marking(H264Context
> *h)
>  }
>  break;
>  case MMCO_RESET:
> +default:
>  while (h->short_ref_count) {
>  remove_short(h, h->short_ref[0]->frame_num, 0);
>  }
> @@ -730,7 +731,6 @@ int
> ff_h264_execute_ref_pic_marking(H264Context
> *h)
>  for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>  h->last_pocs[j] = INT_MIN;
>  break;
> -default: assert(0);
>  }
>  }

 mmco[i].opcode should not be invalid, its checked around the
 point
 where
 this
 array is filled.
 unless there is something iam missing
>>>
>>> Yes, you are missing big time.
>>> If you think by "checked" about those nice asserts they are not
>>> enabled
>>> at
>>> all.
>>>
>>
>> There is check for invalid opcode, but stored invalid opcode is not
>> changed.
>
> Theres no question that we end with a invalid value in the struct,
> but
> that
> is not intended to be in there. You can see that this is not
> intended
> by
> simply looking at the variable that holds the number of entries, it
> is
> not written at all in this case.
>
> So for example if this code stores 5 correct looking mmcos and the
> 6th
> is
> invalid, 6 are in the array but the number of entries is just left
> where
> it
> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the
> invalid
> value
> later doesnt feel ideal.

 Nope, mmco state is left in inconsistent state, and my patch fix it.
 As
 you
 provided nothing valuable to consider as alternative I will apply it.

>>>
>>> What about converting any invalid mmco opcode to mmco reset and
>>> updating mmco size too?
>>> Currently mmco size is left in previous state.
>>
>> Don't invent a new RESET (= 5) operation - that type is special and its
>> presence implies other constraints which we probably don't want to
>> think
>> about here (around frame_num in particular).
>>
>> I think END / truncating the list would be best option?
>>
>
> Nope, that would still put it into bad state. With your approach decoder
> does
> not recover from artifacts. Try sample from bug report #7374.

 Adding a spurious reset here throws away all previous reference frames,
 which will break the stream where it wouldn't otherwise be if the
 corrupted frame would have been bypassed for referencing.  For example,
 in
 real-time cases with feedback a stream which has encountered errors can
 be
 recovered without an intra frame by referring to an older frame which
 still exists in the DPB.
>>>
>>> Sample: .  The bad frame
>>> here has frame_num 24, but we already hit an error before that point and
>>> the
>>> feedback about that makes frame_num 25 refer to LTRF 1 such that 24 is
>>> never
>>> used.  (From a simulator rather than a real capture, because random bit
>>> errors are never where you want them.)
>>>
>>> It doesn't exactly hit the original issue because the leftover MMCO count
>>> from the previous slice is not large enough.  With:
>>>
>>> diff --git a/libavcodec/

[FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option - 2nd attempt

2018-12-17 Thread Adrian
Thanks for the explanation, now your intent is clear. I agree that 
keeping playlist file always as temp as long as it's a file protocol 
makes sense and won't do harm, though I'm still curious why original 
change to accept HLS_TEMP_FILE flag was sent to include and was included 
in official release, I believe there must be a reason.


Given that, I've prepared another patch with fix for original problem + 
proper file picked up for computing 'use_temp_file' variable value. I 
don't know what is the exact flow here, so I'll send it as another 
patch, previous can be discarded and hopefully this one won't raise any 
more objections, though I'd still appreciate a review.


Thanks for your input Aleksey!

Regards
Adrian Guzowski

W dniu 17.12.2018 o 22:35, Aleksey Skripka pisze:

Evening!

First of all, about playlist writeout:
before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!) 
creating via .tmp file.
after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become 
dependent on +temp_file flag.

I suggest to return to original logic.
Non-atomic playlist writeout - is a disaster to just any hls player. This way 
we will force everyone (except offline VOD) to start using +temp_file. Always!
Also, if somebody relying on this - they will get broken streams just after 
upgrade (It seems to me, that it can be a lot).

So, here maintainer should decide how to be.


and about single_file:
if it will be decided to stay with current way (playlist's .tmp logic 
controlled by +temp_file flag), you are right - temp_file+single_file case 
become unreal.
if it will be decided to return original behaviour (playlist always via .tmp), 
someone can choose how to writeout media file (despite i understand temp+single 
is very-very rare case).

Thanks!
>From 3976dac67e65e8065f9150528a0b6fa62100f0c0 Mon Sep 17 00:00:00 2001
From: Adrian Guzowski 
Date: Mon, 17 Dec 2018 23:14:53 +0100
Subject: [PATCH] Fix usage of temp_file flag in hls_flags option.

This is a regression introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6.
It appears that regression was introduced in 4.1, 4.0.x does not share
this behaviour.

Temp files were not created for MPEG-TS segments options - HLS_TEMP_FILE
flag was never set on AVFormatContext, it is however set on HLSContext object.
In order to fix this issue, proper flags field must be checked. In addition,
renaming code was messed up and apparently was working only for MP4 files.

NOTE: This patch is a remake of an original proposal with changes from mailing
list suggestions about keeping playlist always as temp file and stick
to original logic of single file concept.
---
 libavformat/hlsenc.c | 59 
 1 file changed, 32 insertions(+), 27 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bdd2a113bd..52ba4c65f1 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1357,8 +1357,8 @@ static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
 int ret = 0;
 char temp_filename[1024];
 int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - vs->nb_entries);
-const char *proto = avio_find_protocol_name(s->url);
-int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE);
+const char *proto = avio_find_protocol_name(vs->m3u8_name);
+int use_temp_file = proto && !strcmp(proto, "file");
 static unsigned warned_non_file;
 char *key_uri = NULL;
 char *iv_string = NULL;
@@ -1381,7 +1381,7 @@ static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
 hls->version = 7;
 }
 
-if (!use_temp_file && !warned_non_file++)
+if (!use_temp_file && (hls->flags & HLS_TEMP_FILE) && !warned_non_file++)
 av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this may lead to races and temporary partial files\n");
 
 set_http_options(s, &options, hls);
@@ -1477,8 +1477,8 @@ static int hls_start(AVFormatContext *s, VariantStream *vs)
 AVFormatContext *oc = vs->avf;
 AVFormatContext *vtt_oc = vs->vtt_avf;
 AVDictionary *options = NULL;
-const char *proto = avio_find_protocol_name(s->url);
-int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & HLS_TEMP_FILE);
+const char *proto = NULL;
+int use_temp_file = 0;
 char *filename, iv_string[KEYSIZE*2 + 1];
 int err = 0;
 
@@ -1574,6 +1574,9 @@ static int hls_start(AVFormatContext *s, VariantStream *vs)
 
 set_http_options(s, &options, c);
 
+proto = avio_find_protocol_name(oc->url);
+use_temp_file = proto && !strcmp(proto, "file") && (c->flags & HLS_TEMP_FILE);
+
 if (use_temp_file) {
 char *new_name = av_asprintf("%s.tmp", oc->url);
 if (!new_name)
@@ -2142,8 +2145,8 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 int ret = 0, can_split = 1, i, j;
 int stream_index = 0;
 int range_length = 0;
-const char *proto = avio_find_prot

Re: [FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Vittorio Giovara
On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi  wrote:

> From: Mohammad Izadi 
>
> The dynamic metadata contains data for color volume transform -
> application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC in
> the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
>
> I'll add support to HEVC in a follow-up.
>
---
>  libavutil/Makefile   |   2 +
>  libavutil/frame.c|   1 +
>  libavutil/frame.h|   7 +
>  libavutil/hdr_dynamic_metadata.c |  40 
>  libavutil/hdr_dynamic_metadata.h | 344 +++
>  libavutil/version.h  |   2 +-
>  6 files changed, 395 insertions(+), 1 deletion(-)
>  create mode 100644 libavutil/hdr_dynamic_metadata.c
>  create mode 100644 libavutil/hdr_dynamic_metadata.h
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index caddc7e155..7dcb92b06b 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -31,6 +31,7 @@ HEADERS = adler32.h
>\
>file.h\
>frame.h   \
>hash.h\
> +  hdr_dynamic_metadata.h\
>

There

>hmac.h\
>hwcontext.h   \
>hwcontext_cuda.h  \
> @@ -119,6 +120,7 @@ OBJS = adler32.o
>   \
> fixed_dsp.o  \
> frame.o  \
> hash.o   \
> +   hdr_dynamic_metadata.o   \
> hmac.o   \
> hwcontext.o  \
> imgutils.o   \
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 9b3fb13e68..c5f30b6847 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table
> properties";
>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> data";
>  #endif
> +case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR
> Dynamic Metadata SMPTE2094-40";
>

I like VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse
as much as the next guy, but this is overly too long and the related
structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with the
public type naming present in this project.

If I may suggest, please use the following names:
- AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously metadata,
and the fact that is based on SMPTE2094-40 should not be hardcoded in the
name
- dynamic_hdr.h as header name: again the fact that it's metadata does not
be carried everywhere
- AVDynamicHDR as structure name: short and to the point, and without spec
numbers or underscores


>  }
>  return NULL;
>  }
> diff --git a/libavutil/hdr_dynamic_metadata.c
> b/libavutil/hdr_dynamic_metadata.c
> new file mode 100644
> index 00..59dfcc84e4
> --- /dev/null
> +++ b/libavutil/hdr_dynamic_metadata.c
> @@ -0,0 +1,40 @@
> +
> +#include "hdr_dynamic_metadata.h"
> +#include "mem.h"
> +
> +AVDynamicMetadataSMPTE2094_40
> *av_dynamic_metadata_smpte2094_40_alloc(void)
>

you need to return the size of allocation back to the caller, see
spherical.h as example (especially since you document that "its size is not
a part of the public ABI.")

+/**
> + * Option for overlapping elliptical pixel selectors in an image.
> + */
> +enum AVOverlapProcessOption {
> +AV_OVERLAP_PROCESS_WEIGHTED_AVERAGING = 0,
> +AV_OVERLAP_PROCESS_LAYERING = 1,
> +};
>

I'm not a fan of these names, but i've bikeshed enough


> +
> +/**
> + * Percentile represents the percentile at a specific percentage in
> + * a distribution.
> + */
> +typedef struct AVPercentile {
> +/**
> + * The percentage value corresponding to a spesific percentile
> linearized
>

typo 'spesific'

+ * RGB value in the processing window in the scene. The value shall be
> in
> + * the range of 0 to100, inclusive.
> + */
> +uint8_t percentage;
> +/**
> + * The linearized maxRGB value at a specific percentile in the
> processing
> + * window in the scene. The value shall be in the range of 0 to 1,
> inclusive
> + * and in multiples of 0.1.
> + */
> +AVRational percentile;
> +} AVPercentile;
> +
>
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/ma

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_hwmap: make hwunmap from software frame work.

2018-12-17 Thread Mark Thompson
 13/12/2018 01:50, Ruiling Song wrote:
> This patch was used to fix the second hwmap filter issue:
> [vaapi_frame] hwmap [software filters] hwmap [vaapi_frame]
> For such case, we also need to allocate the hardware frame
> and map it back to software.
> 
> Signed-off-by: Ruiling Song 
> ---
>  libavfilter/vf_hwmap.c | 125 
> +
>  1 file changed, 75 insertions(+), 50 deletions(-)
> 
> diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
> index 290559a..03cb325 100644
> --- a/libavfilter/vf_hwmap.c
> +++ b/libavfilter/vf_hwmap.c
> @@ -50,6 +50,36 @@ static int hwmap_query_formats(AVFilterContext *avctx)
>  return 0;
>  }
>  
> +static int create_hwframe_context(HWMapContext *ctx, AVFilterContext *avctx,
> +  AVBufferRef *device, int format,
> +  int sw_format, int width, int height)
> +{
> +int err;
> +AVHWFramesContext *frames;
> +
> +ctx->hwframes_ref = av_hwframe_ctx_alloc(device);
> +if (!ctx->hwframes_ref) {
> +return AVERROR(ENOMEM);
> +}
> +frames = (AVHWFramesContext*)ctx->hwframes_ref->data;
> +
> +frames->format= format;
> +frames->sw_format = sw_format;
> +frames->width = width;
> +frames->height= height;
> +
> +if (avctx->extra_hw_frames >= 0)
> +frames->initial_pool_size = 2 + avctx->extra_hw_frames;
> +
> +err = av_hwframe_ctx_init(ctx->hwframes_ref);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to initialise "
> +   "target frames context: %d.\n", err);
> +return err;
> +}
> +return 0;
> +}
> +
>  static int hwmap_config_output(AVFilterLink *outlink)
>  {
>  AVFilterContext *avctx = outlink->src;
> @@ -130,29 +160,11 @@ static int hwmap_config_output(AVFilterLink *outlink)
>  // overwrite the input hwframe context with a derived context
>  // mapped from that back to the source type.
>  AVBufferRef *source;
> -AVHWFramesContext *frames;
> -
> -ctx->hwframes_ref = av_hwframe_ctx_alloc(device);
> -if (!ctx->hwframes_ref) {
> -err = AVERROR(ENOMEM);
> +err = create_hwframe_context(ctx, avctx, device, outlink->format,
> + hwfc->sw_format, hwfc->width,
> + hwfc->height);
> +if (err < 0)
>  goto fail;
> -}
> -frames = (AVHWFramesContext*)ctx->hwframes_ref->data;
> -
> -frames->format= outlink->format;
> -frames->sw_format = hwfc->sw_format;
> -frames->width = hwfc->width;
> -frames->height= hwfc->height;
> -
> -if (avctx->extra_hw_frames >= 0)
> -frames->initial_pool_size = 2 + avctx->extra_hw_frames;
> -
> -err = av_hwframe_ctx_init(ctx->hwframes_ref);
> -if (err < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Failed to initialise "
> -   "target frames context: %d.\n", err);
> -goto fail;
> -}
>  
>  err = av_hwframe_ctx_create_derived(&source,
>  inlink->format,
> @@ -175,10 +187,20 @@ static int hwmap_config_output(AVFilterLink *outlink)
>  inlink->hw_frames_ctx = source;
>  
>  } else if ((outlink->format == hwfc->format &&
> -inlink->format  == hwfc->sw_format) ||
> -   inlink->format == hwfc->format) {
> -// Map from a hardware format to a software format, or
> -// undo an existing such mapping.
> +inlink->format  == hwfc->sw_format)) {
> +// unmap a software frame back to hardware
> +ctx->reverse = 1;
> +// incase user does not provide filter device, use the device_ref
> +// from inlink
> +if (!device)
> +device = hwfc->device_ref;
> +
> +err = create_hwframe_context(ctx, avctx, device, outlink->format,
> + inlink->format, inlink->w, 
> inlink->h);
> +if (err < 0)
> +goto fail;

I don't think the unmap case here wants to make a new hardware frames context?  
You have a software frame which is actually a mapping of a hardware frame and 
want to retrieve the original hardware frame, so the frames context is that of 
the original frame.

This happens when making writeable mappings to make changes to a frame.  
Consider, for example:

./ffmpeg_g -y -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 
-hwaccel_output_format vaapi -i in.mp4 -an -vf 
'scale_vaapi=format=nv12,hwmap=mode=read+write,format=nv12,drawtext=fontfile=font.ttf:text=Hello
 World!,format=nv12,hwmap' -c:v h264_vaapi out.mp4

> +} else if (inlink->format == hwfc->form

Re: [FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Jan Ekström
On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara
 wrote:
>
> On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi  wrote:
>
> > From: Mohammad Izadi 
> >
> > The dynamic metadata contains data for color volume transform -
> > application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC in
> > the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
> >
> > I'll add support to HEVC in a follow-up.
> >
> ---
> >  libavutil/Makefile   |   2 +
> >  libavutil/frame.c|   1 +
> >  libavutil/frame.h|   7 +
> >  libavutil/hdr_dynamic_metadata.c |  40 
> >  libavutil/hdr_dynamic_metadata.h | 344 +++
> >  libavutil/version.h  |   2 +-
> >  6 files changed, 395 insertions(+), 1 deletion(-)
> >  create mode 100644 libavutil/hdr_dynamic_metadata.c
> >  create mode 100644 libavutil/hdr_dynamic_metadata.h
> >
> > diff --git a/libavutil/Makefile b/libavutil/Makefile
> > index caddc7e155..7dcb92b06b 100644
> > --- a/libavutil/Makefile
> > +++ b/libavutil/Makefile
> > @@ -31,6 +31,7 @@ HEADERS = adler32.h
> >\
> >file.h\
> >frame.h   \
> >hash.h\
> > +  hdr_dynamic_metadata.h\
> >
>
> There
>
> >hmac.h\
> >hwcontext.h   \
> >hwcontext_cuda.h  \
> > @@ -119,6 +120,7 @@ OBJS = adler32.o
> >   \
> > fixed_dsp.o  \
> > frame.o  \
> > hash.o   \
> > +   hdr_dynamic_metadata.o   \
> > hmac.o   \
> > hwcontext.o  \
> > imgutils.o   \
> > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > index 9b3fb13e68..c5f30b6847 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum
> > AVFrameSideDataType type)
> >  case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table
> > properties";
> >  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> > data";
> >  #endif
> > +case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR
> > Dynamic Metadata SMPTE2094-40";
> >
>
> I like VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse
> as much as the next guy, but this is overly too long and the related
> structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with the
> public type naming present in this project.
>
> If I may suggest, please use the following names:
> - AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously metadata,
> and the fact that is based on SMPTE2094-40 should not be hardcoded in the
> name
> - dynamic_hdr.h as header name: again the fact that it's metadata does not
> be carried everywhere
> - AVDynamicHDR as structure name: short and to the point, and without spec
> numbers or underscores
>

I don't think SMPTE ST.2094-XX utilized the same fields?

I think SMPTE ST.2094-40 is Samsung's dynamic metadata which is effect
usually called "HDR10+" ? Not just calling it AVDynamicHDR could come
up useful if we plan on adding support for SMPTE ST.2094-10 which is
one part of what's called "Dolby Vision" (even though it is just
dynamic metadata - because of course you have to stick everything
under a single marketing name).

Just my 20 cents.

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


[FFmpeg-devel] [PATCH]lavc/mjpegdec: Interpret three-component Adobe transform 0 also as RGB

2018-12-17 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes ticket #7625 for me.

Please comment, Carl Eugen
From be83e6c657b8d8e2a158747b58c4dbc6ba3cc516 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 17 Dec 2018 23:53:29 +0100
Subject: [PATCH] lavc/mjpegdec: Interpret three-component Adobe transform 0
 also as RGB.

Fixes ticket #7625.
---
 libavcodec/mjpegdec.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 2f16358..4cab660 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -488,7 +488,8 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
 if (s->rgb)
 s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 : AV_PIX_FMT_BGR48;
 else {
-if (s->component_id[0] == 'Q' && s->component_id[1] == 'F' && s->component_id[2] == 'A') {
+if (   s->adobe_transform == 0
+|| s->component_id[0] == 'R' - 1 && s->component_id[1] == 'G' - 1 && s->component_id[2] == 'B' - 1) {
 s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP : AV_PIX_FMT_GBRP16;
 } else {
 if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Vittorio Giovara
On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström  wrote:

> On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara
>  wrote:
> >
> > On Mon, Dec 10, 2018 at 2:50 PM Mohammad Izadi 
> wrote:
> >
> > > From: Mohammad Izadi 
> > >
> > > The dynamic metadata contains data for color volume transform -
> > > application 4 of SPMTE 2094-40:2016 standard. The data comes from HEVC
> in
> > > the SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35.
> > >
> > > I'll add support to HEVC in a follow-up.
> > >
> > > diff --git a/libavutil/frame.c b/libavutil/frame.c
> > > index 9b3fb13e68..c5f30b6847 100644
> > > --- a/libavutil/frame.c
> > > +++ b/libavutil/frame.c
> > > @@ -840,6 +840,7 @@ const char *av_frame_side_data_name(enum
> > > AVFrameSideDataType type)
> > >  case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table
> > > properties";
> > >  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> > > data";
> > >  #endif
> > > +case AV_FRAME_DATA_HDR_DYNAMIC_METADATA_SMPTE2094_40: return "HDR
> > > Dynamic Metadata SMPTE2094-40";
> > >
> >
> > I like
> VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse
> > as much as the next guy, but this is overly too long and the related
> > structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with the
> > public type naming present in this project.
> >
> > If I may suggest, please use the following names:
> > - AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously
> metadata,
> > and the fact that is based on SMPTE2094-40 should not be hardcoded in the
> > name
> > - dynamic_hdr.h as header name: again the fact that it's metadata does
> not
> > be carried everywhere
> > - AVDynamicHDR as structure name: short and to the point, and without
> spec
> > numbers or underscores
> >
>
> I don't think SMPTE ST.2094-XX utilized the same fields?
>
> I think SMPTE ST.2094-40 is Samsung's dynamic metadata which is effect
> usually called "HDR10+" ? Not just calling it AVDynamicHDR could come
> up useful if we plan on adding support for SMPTE ST.2094-10 which is
> one part of what's called "Dolby Vision" (even though it is just
> dynamic metadata - because of course you have to stick everything
> under a single marketing name).
>

It's still technically dynamic metadata but I get your point.
It could maybe be stored in dynamic_hdr.h header, and call it
AVDynamicHDRPlus to differenciate it from the future AVDolbyVisionHDR. What
do you think?


> Just my 20 cents.
>
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


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


Re: [FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Jan Ekström
On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara
 wrote:
>
> On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström  wrote:
>
> > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara
> >  wrote:
> > >
> > > I like
> > VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse
> > > as much as the next guy, but this is overly too long and the related
> > > structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with the
> > > public type naming present in this project.
> > >
> > > If I may suggest, please use the following names:
> > > - AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously
> > metadata,
> > > and the fact that is based on SMPTE2094-40 should not be hardcoded in the
> > > name
> > > - dynamic_hdr.h as header name: again the fact that it's metadata does
> > not
> > > be carried everywhere
> > > - AVDynamicHDR as structure name: short and to the point, and without
> > spec
> > > numbers or underscores
> > >
> >
> > I don't think SMPTE ST.2094-XX utilized the same fields?
> >
> > I think SMPTE ST.2094-40 is Samsung's dynamic metadata which is effect
> > usually called "HDR10+" ? Not just calling it AVDynamicHDR could come
> > up useful if we plan on adding support for SMPTE ST.2094-10 which is
> > one part of what's called "Dolby Vision" (even though it is just
> > dynamic metadata - because of course you have to stick everything
> > under a single marketing name).
> >
>
> It's still technically dynamic metadata but I get your point.
> It could maybe be stored in dynamic_hdr.h header, and call it
> AVDynamicHDRPlus to differenciate it from the future AVDolbyVisionHDR. What
> do you think?
>

The other alternative would have been to make sure that the structure
can take the values that are "essential" from those separate
specifications.

I do not have a heavy opinion one way or another (separate structure
per spec or single with all the required data), but just had to
mention it because it would have otherwise been a singular "dynamic
HDR metadata" entity while it unfortunately seems that these things
have splintered into multiple competing alternatives... (of which
Samsung's and Dolby's things seem to be those getting most use)

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


Re: [FFmpeg-devel] [PATCH] libavcodec/fft_template: improve performance of the ff_fft_init in fft_template

2018-12-17 Thread Michael Niedermayer
On Mon, Dec 17, 2018 at 05:13:05PM +0800, Steven Liu wrote:
> After patch:
> init nbits = 17, get 1 samples, duration: 15221
> Before patch:
> init nbits = 17, get 1 samples, duration: 16105
> 
> test script:
> DURATION=0
> for((i=0;i<1;i++)) do
> ./libavcodec/tests/fft -n 17 &>output
> T_DURATION=`grep "duration" output | awk -F"=" '{ print $2}'`
> DURATION=`expr $DURATION + $T_DURATION`
> done
> TOTAL=`expr $DURATION / 1`
> echo $TOTAL
> 
> Signed-off-by: Steven Liu 
> ---
>  libavcodec/fft_template.c | 27 +--
>  1 file changed, 17 insertions(+), 10 deletions(-)

this breaks fate
make: *** [fate-unknown_layout-ac3] Error 1
make: *** [fate-acodec-dca] Error 1
make: *** [fate-acodec-dca2] Error 1
make: *** [fate-lavf-rm] Error 1
make: *** [fate-ac3-fixed-2.0] Error 1
make: *** [fate-ac3-fixed-4.0-downmix-mono] Error 1
make: *** [fate-ac3-fixed-5.1-downmix-stereo] Error 1
make: *** [fate-ac3-fixed-5.1-downmix-mono] Error 1
make: *** [fate-ac3-fixed-encode] Error 1
make: *** [fate-atrac1-1] Error 1
make: *** [fate-atrac3p-2] Error 1
make: *** [fate-atrac3p-1] Error 1
make: *** [fate-opus-testvector01] Error 1
make: *** [fate-opus-testvector06] Error 1
make: *** [fate-opus-testvector05] Error 1
make: *** [fate-opus-testvector11] Error 1
make: *** [fate-opus-testvector08] Error 1
make: *** [fate-opus-tron.6ch.tinypkts] Error 1
make: *** [fate-opus-testvector07] Error 1
make: *** [fate-opus-testvector09] Error 1
make: *** [fate-opus-testvector10] Error 1
make: *** [fate-prores-gray] Error 1
make: *** [fate-aac-al04sf_48] Error 1
make: *** [fate-aac-fixed-al05_44] Error 1
make: *** [fate-aac-er_eld2100np_48_ep0] Error 1
make: *** [fate-aac-fixed-al06_44] Error 1
make: *** [fate-aac-fixed-al04_44] Error 1
make: *** [fate-aac-fixed-al15_44] Error 1
make: *** [fate-aac-fixed-al17_44] Error 1
make: *** [fate-aac-fixed-er_ad6000np_44_ep0] Error 1
make: *** [fate-aac-fixed-al18_44] Error 1
make: *** [fate-aac-fixed-ap05_48] Error 1
make: *** [fate-aac-fixed-al_sbr_hq_cm_48_2] Error 1
make: *** [fate-aac-fixed-er_eld1001np_44_ep0] Error 1
make: *** [fate-aac-fixed-er_eld2000np_48_ep0] Error 1
make: *** [fate-aac-fixed-al_sbr_hq_sr_48_2_fsaac48] Error 1
make: *** [fate-aac-fixed-al_sbr_hq_cm_48_5.1] Error 1
make: *** [fate-dca-core_51_24_48_768_1] Error 1
make: *** [fate-dca-core_51_24_48_768_0] Error 1
make: *** [fate-dca-core_51_24_48_768_1-dmix_2] Error 1
make: *** [fate-dca-xxch_71_24_48_2046] Error 1
make: *** [fate-dca-xbr_xxch_71_24_48_3840] Error 1
make: *** [fate-dca-xch_61_24_48_768-dmix_6] Error 1
make: *** [fate-dca-xbr_xch_61_24_48_3840] Error 1
make: *** [fate-dca-xch_61_24_48_768] Error 1
make: *** [fate-dca-xbr_51_24_48_3840] Error 1
make: *** [fate-dts_es] Error 1
make: *** [fate-dca-core] Error 1
...

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

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


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


Re: [FFmpeg-devel] [PATCH] avformat/mpegts: unset DTS/PTS for subtitle PES packets if PCR not available

2018-12-17 Thread Jan Ekström
On Mon, Dec 17, 2018 at 8:26 PM Michael Niedermayer
 wrote:
>
> On Sat, Dec 15, 2018 at 08:50:41PM +0200, Jan Ekström wrote:
> > Fixes issues when a subtitle packet is received before PCR for the
> > program has been received, leading to wildly jumping timestamps
> > on the lavf client side as well as in the re-ordering logic.
> >
> > This usually happens in case of multiplexes where the PCR of a
> > program is not taken into account with subtitle tracks' DTS/PTS.
> > ---
> >  libavformat/mpegts.c | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index edf6b5701d..8f6ee81cda 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -1219,6 +1219,7 @@ skip:
> >  || pes->st->codecpar->codec_id == 
> > AV_CODEC_ID_DVB_SUBTITLE)
> >  ) {
> >  AVProgram *p = NULL;
> > +int pcr_found = 0;
> >  while ((p = av_find_program_from_stream(pes->stream, 
> > p, pes->st->index))) {
> >  if (p->pcr_pid != -1 && p->discard != 
> > AVDISCARD_ALL) {
> >  MpegTSFilter *f = pes->ts->pids[p->pcr_pid];
> > @@ -1242,6 +1243,7 @@ skip:
> >  // and the pcr error to this packet 
> > should be no more than 100 ms.
> >  // TODO: we should interpolate the 
> > PCR, not just use the last one
> >  int64_t pcr = f->last_pcr / 300;
> > +pcr_found = 1;
> >  pes->st->pts_wrap_reference = 
> > st->pts_wrap_reference;
> >  pes->st->pts_wrap_behavior = 
> > st->pts_wrap_behavior;
> >  if (pes->dts == AV_NOPTS_VALUE || 
> > pes->dts < pcr) {
> > @@ -1258,6 +1260,15 @@ skip:
> >  }
> >  }
> >  }
> > +
> > +if (!pcr_found) {
> > +av_log(pes->stream, AV_LOG_VERBOSE,
> > +   "Forcing DTS/PTS to be unset for a "
> > +   "non-trustworthy PES packet for PID %d as "
> > +   "PCR hasn't been received yet.\n",
> > +   pes->pid);
> > +pes->dts = pes->pts = AV_NOPTS_VALUE;
> > +}
> >  }
> >  }
> >  break;
>
> Assuming i understand the intend correctly ...
> could the packet be put in a buffer and once a PCR has been encountered be
> returned based on that?
> This seems better as no timestamp would be lost
>
> thx
>

That was one of the initial ideas I had on this (the other was the
"just drop/skip the PES packet(s)", for which I posted a patch in
order to receive comments).

The problems in such a case are:
- There technically is no upper bound for the buffering (not 100% sure
but in theory I think the demuxer can go on without PCR - of course
this kind of stream would be completely against the spec, but so would
be files without PMT/PAT which we still support).
- How do you set the timestamp at that point... do you try to keep
count on which packets with what sort of timestamps had already
passed, and adjust according to those - or would you just set it to
the PCR?
- Do you buffer only the subtitle packets, or also all the other ones?
If you only buffer the subtitle packets, you might end up returning
the subtitle packet after its intended time of presentation.

Additionally to keep in mind:
- You already are effectively losing original timestamp information
with the timestamp fixing logic. You can disable this logic with
`fix_teletext_pts` being set to zero (enabled by default).
- AV_NOPTS_VALUE can effectively be thought as "utilize ASAP", and if
the comments are correct that should be generally correct.

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


Re: [FFmpeg-devel] avdevice/decklink: Fix seg fault in decklink

2018-12-17 Thread Marton Balint



On Mon, 17 Dec 2018, BIGLER Don (Framatome) wrote:

Attached is a patch that fixes a potential segmentation fault in 
avdevice/decklink when used in a multi-threaded environment outside of 
ffmpeg.  Because the capture_started flag is not set the stream is not 
closed properly.  This can cause a segmentation fault when the input 
callback is called in a multi-threaded reader that has not stopped 
reading before the connection is closed.


It might be better just to call the cleanup functions unconditonally in 
ff_decklink_read_close if ctx->dli is not null, e.g.:


if (ctx->dli) {
ctx->dli->StopStreams();
ctx->dli->DisableVideoInput();
ctx->dli->DisableAudioInput();
}

Input format autodetection can start the stream long before you added the 
capture_started line.


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


Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option - 2nd attempt

2018-12-17 Thread Aleksey Skripka
Thanks for your attention, Adrian!

just one moment,
in hls_write_packet():

instead:
+if (use_temp_file) {
+hls_rename_temp_file(s, oc);

should be:
+if (use_temp_file && !(hls->flags & HLS_SINGLE_FILE))
+hls_rename_temp_file(s, oc);

or we a killing 'single' filename in few iterations.



Steven,
i recall my version of patch. Adrian's version fixes more issues and hope v3 
will be the best :)


Aleksey Skripka

> On 18 Dec 2018, at 01:30, Adrian  wrote:
> 
> Thanks for the explanation, now your intent is clear. I agree that keeping 
> playlist file always as temp as long as it's a file protocol makes sense and 
> won't do harm, though I'm still curious why original change to accept 
> HLS_TEMP_FILE flag was sent to include and was included in official release, 
> I believe there must be a reason.
> 
> Given that, I've prepared another patch with fix for original problem + 
> proper file picked up for computing 'use_temp_file' variable value. I don't 
> know what is the exact flow here, so I'll send it as another patch, previous 
> can be discarded and hopefully this one won't raise any more objections, 
> though I'd still appreciate a review.
> 
> Thanks for your input Aleksey!
> 
> Regards
> Adrian Guzowski
> 
> W dniu 17.12.2018 o 22:35, Aleksey Skripka pisze:
>> Evening!
>> 
>> First of all, about playlist writeout:
>> before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!) 
>> creating via .tmp file.
>> after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become 
>> dependent on +temp_file flag.
>> 
>> I suggest to return to original logic.
>> Non-atomic playlist writeout - is a disaster to just any hls player. This 
>> way we will force everyone (except offline VOD) to start using +temp_file. 
>> Always!
>> Also, if somebody relying on this - they will get broken streams just after 
>> upgrade (It seems to me, that it can be a lot).
>> 
>> So, here maintainer should decide how to be.
>> 
>> 
>> and about single_file:
>> if it will be decided to stay with current way (playlist's .tmp logic 
>> controlled by +temp_file flag), you are right - temp_file+single_file case 
>> become unreal.
>> if it will be decided to return original behaviour (playlist always via 
>> .tmp), someone can choose how to writeout media file (despite i understand 
>> temp+single is very-very rare case).
>> 
>> Thanks!
> <0001-Fix-usage-of-temp_file-flag-in-hls_flags-option-2nd-attempt.patch>___
> 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] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

2018-12-17 Thread Fu, Linjie
> -Original Message-
> From: Fu, Linjie
> Sent: Monday, December 10, 2018 18:24
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH,v3] lavc/hevc_parser: cope with more leading_zero_8bits
> and update FATE
> 
> Given that leading_zero_8bits can be included many times at the beginning
> of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> in last frame and may lead to some warnings in parse_nal_units when s-
> >flags
> is set to PARSER_FLAG_COMPLETE_FRAMES.
> 
> Modify to put all of the zeroes between two frames into the second frame.
> Modify the code to print the buf_size like in H264 and reduce the duplication.
> 
> Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
> 
> To verify the output of FATE:
> ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
> +bitexact hevc-mp4.mov
> ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: Update FATE checksum.
> [v3]: Cope with more leading_zero_8bits cases.
> 
>  libavcodec/hevc_parser.c | 14 +-
>  tests/fate/hevc.mak  |  2 +-
>  2 files changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index 369d1338d0..62100ac654 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -239,7 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s,
> const uint8_t *buf,
>  }
>  }
>  /* didn't find a picture! */
> -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with
> size %d\n", buf_size);
>  return -1;
>  }
> 
> @@ -267,8 +267,7 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>  if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> HEVC_NAL_SEI_PREFIX ||
>  (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
>  if (pc->frame_start_found) {
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
>  }
>  } else if (nut <= HEVC_NAL_RASL_R ||
> (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
> @@ -277,14 +276,19 @@ static int
> hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
>  if (!pc->frame_start_found) {
>  pc->frame_start_found = 1;
>  } else { // First slice of next frame found
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
>  }
>  }
>  }
>  }
> 
>  return END_NOT_FOUND;
> +
> +found:
> +pc->frame_start_found = 0;
> +while (i - 6 >= 0 && !buf[i - 6])
> +i--;
> +return i - 5;
>  }
> 
>  static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index db3ea19340..ab8da53535 100644
> --- a/tests/fate/hevc.mak
> +++ b/tests/fate/hevc.mak
> @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER
> MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER
>  fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
>  fate-hevc-bsf-mp4toannexb: CMD = md5 -i
> $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f
> hevc
>  fate-hevc-bsf-mp4toannexb: CMP = oneline
> -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
> 
>  fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
> $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags
> bitexact
>  FATE_HEVC += fate-hevc-skiploopfilter
> --
> 2.17.1
Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec: add AV1 frame split bitstream filter

2018-12-17 Thread James Almer
This will be needed by the eventual native AV1 decoder.

Signed-off-by: James Almer 
---
Missing Changelog entry, version bump

 configure|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/av1_frame_split_bsf.c | 246 +++
 libavcodec/bitstream_filters.c   |   1 +
 4 files changed, 249 insertions(+)
 create mode 100644 libavcodec/av1_frame_split_bsf.c

diff --git a/configure b/configure
index b062b6318e..16854f5418 100755
--- a/configure
+++ b/configure
@@ -3036,6 +3036,7 @@ vc1_parser_select="vc1dsp"
 
 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
+av1_frame_split_select="cbs_av1"
 av1_metadata_bsf_select="cbs_av1"
 eac3_core_bsf_select="ac3_parser"
 filter_units_bsf_select="cbs"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d53b8ff330..5d3acca45f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1060,6 +1060,7 @@ OBJS-$(CONFIG_XMA_PARSER)  += xma_parser.o
 # bitstream filters
 OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += aac_adtstoasc_bsf.o mpeg4audio.o
 OBJS-$(CONFIG_AV1_METADATA_BSF)   += av1_metadata_bsf.o
+OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= av1_frame_split_bsf.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
diff --git a/libavcodec/av1_frame_split_bsf.c b/libavcodec/av1_frame_split_bsf.c
new file mode 100644
index 00..8f4a7c3aa5
--- /dev/null
+++ b/libavcodec/av1_frame_split_bsf.c
@@ -0,0 +1,246 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * This bitstream filter splits AV1 Temporal Units into packets containing
+ * just one frame.
+ */
+
+#include "libavutil/avassert.h"
+#include "avcodec.h"
+#include "cbs.h"
+#include "cbs_av1.h"
+#include "bsf.h"
+
+typedef struct AV1FSplitContext {
+AVPacket *buffer_pkt;
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment temporal_unit;
+
+int nb_frames;
+int cur_frame;
+int cur_frame_idx;
+int last_frame_idx;
+} AV1FSplitContext;
+
+static int av1_frame_split_filter(AVBSFContext *ctx, AVPacket *out)
+{
+AV1FSplitContext *s = ctx->priv_data;
+CodedBitstreamFragment *td = &s->temporal_unit;
+int i, ret;
+int split = !!s->buffer_pkt->data;
+
+if (!s->buffer_pkt->data) {
+int nb_frames = 0;
+
+ret = ff_bsf_get_packet_ref(ctx, s->buffer_pkt);
+if (ret < 0)
+return ret;
+
+ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Failed to parse temporal unit.\n");
+return ret;
+}
+
+for (i = 0; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = &td->units[i];
+
+if (unit->type == AV1_OBU_FRAME ||
+unit->type == AV1_OBU_FRAME_HEADER)
+nb_frames++;
+else if (unit->type == AV1_OBU_TILE_LIST) {
+av_log(ctx, AV_LOG_VERBOSE, "Large scale tiles are 
unsupported. Skipping Temporal Unit.\n");
+break;
+}
+}
+if (nb_frames > 1) {
+s->cur_frame = 0;
+// Don't attach the Temporal Delimiter OBU with the first frame
+s->cur_frame_idx = s->last_frame_idx =
+td->units[0].type == AV1_OBU_TEMPORAL_DELIMITER;
+s->nb_frames = nb_frames;
+split = 1;
+}
+}
+
+if (split) {
+AV1RawFrameHeader *frame = NULL;
+int cur_frame_type = -1, size = 0;
+
+for (i = s->cur_frame_idx; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = &td->units[i];
+
+size += unit->data_size;
+if (unit->type == AV1_OBU_FRAME) {
+AV1RawOBU *obu = unit->content;
+
+if (frame) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+frame = &obu->obu.frame.header;
+cur_frame_type = obu->header.obu_type;
+s->last_frame_idx = s->cur_frame_idx;
+s->cur_frame_idx  = i + 1;
+s->cur_frame++;
+
+ 

[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case: hevc-conformance-AMP_A_Samsung_* in loongson2k

2018-12-17 Thread gxw
The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is 
still 32
in function ff_hevc_sao_edge_filter_8_msa. So, Modify the corresponding value 
to 64.
Fate tests passed.
---
 libavcodec/mips/hevc_lpf_sao_msa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
b/libavcodec/mips/hevc_lpf_sao_msa.c
index 5b5537a..bb883d0 100644
--- a/libavcodec/mips/hevc_lpf_sao_msa.c
+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
@@ -2630,7 +2630,7 @@ void ff_hevc_sao_edge_filter_8_msa(uint8_t *dst, uint8_t 
*src,
int16_t *sao_offset_val,
int eo, int width, int height)
 {
-ptrdiff_t stride_src = (2 * 64 + 32) / sizeof(uint8_t);
+ptrdiff_t stride_src = (2 * 64 + 64) / sizeof(uint8_t);
 
 switch (eo) {
 case 0:
-- 
2.1.0


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


Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_hwmap: make hwunmap from software frame work.

2018-12-17 Thread Song, Ruiling


> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Tuesday, December 18, 2018 6:33 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavfi/vf_hwmap: make hwunmap from
> software frame work.
> 
>  13/12/2018 01:50, Ruiling Song wrote:
> > This patch was used to fix the second hwmap filter issue:
> > [vaapi_frame] hwmap [software filters] hwmap [vaapi_frame]
> > For such case, we also need to allocate the hardware frame
> > and map it back to software.
> >
> > Signed-off-by: Ruiling Song 
> > ---
> >  libavfilter/vf_hwmap.c | 125 +
> 
> >  1 file changed, 75 insertions(+), 50 deletions(-)
> >
> > diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
> > index 290559a..03cb325 100644
> > --- a/libavfilter/vf_hwmap.c
> > +++ b/libavfilter/vf_hwmap.c
> > @@ -50,6 +50,36 @@ static int hwmap_query_formats(AVFilterContext
> *avctx)
> >  return 0;
> >  }
> >
> > +static int create_hwframe_context(HWMapContext *ctx, AVFilterContext
> *avctx,
> > +  AVBufferRef *device, int format,
> > +  int sw_format, int width, int height)
> > +{
> > +int err;
> > +AVHWFramesContext *frames;
> > +
> > +ctx->hwframes_ref = av_hwframe_ctx_alloc(device);
> > +if (!ctx->hwframes_ref) {
> > +return AVERROR(ENOMEM);
> > +}
> > +frames = (AVHWFramesContext*)ctx->hwframes_ref->data;
> > +
> > +frames->format= format;
> > +frames->sw_format = sw_format;
> > +frames->width = width;
> > +frames->height= height;
> > +
> > +if (avctx->extra_hw_frames >= 0)
> > +frames->initial_pool_size = 2 + avctx->extra_hw_frames;
> > +
> > +err = av_hwframe_ctx_init(ctx->hwframes_ref);
> > +if (err < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to initialise "
> > +   "target frames context: %d.\n", err);
> > +return err;
> > +}
> > +return 0;
> > +}
> > +
> >  static int hwmap_config_output(AVFilterLink *outlink)
> >  {
> >  AVFilterContext *avctx = outlink->src;
> > @@ -130,29 +160,11 @@ static int hwmap_config_output(AVFilterLink
> *outlink)
> >  // overwrite the input hwframe context with a derived context
> >  // mapped from that back to the source type.
> >  AVBufferRef *source;
> > -AVHWFramesContext *frames;
> > -
> > -ctx->hwframes_ref = av_hwframe_ctx_alloc(device);
> > -if (!ctx->hwframes_ref) {
> > -err = AVERROR(ENOMEM);
> > +err = create_hwframe_context(ctx, avctx, device, 
> > outlink->format,
> > + hwfc->sw_format, hwfc->width,
> > + hwfc->height);
> > +if (err < 0)
> >  goto fail;
> > -}
> > -frames = (AVHWFramesContext*)ctx->hwframes_ref->data;
> > -
> > -frames->format= outlink->format;
> > -frames->sw_format = hwfc->sw_format;
> > -frames->width = hwfc->width;
> > -frames->height= hwfc->height;
> > -
> > -if (avctx->extra_hw_frames >= 0)
> > -frames->initial_pool_size = 2 + avctx->extra_hw_frames;
> > -
> > -err = av_hwframe_ctx_init(ctx->hwframes_ref);
> > -if (err < 0) {
> > -av_log(avctx, AV_LOG_ERROR, "Failed to initialise "
> > -   "target frames context: %d.\n", err);
> > -goto fail;
> > -}
> >
> >  err = av_hwframe_ctx_create_derived(&source,
> >  inlink->format,
> > @@ -175,10 +187,20 @@ static int hwmap_config_output(AVFilterLink
> *outlink)
> >  inlink->hw_frames_ctx = source;
> >
> >  } else if ((outlink->format == hwfc->format &&
> > -inlink->format  == hwfc->sw_format) ||
> > -   inlink->format == hwfc->format) {
> > -// Map from a hardware format to a software format, or
> > -// undo an existing such mapping.
> > +inlink->format  == hwfc->sw_format)) {
> > +// unmap a software frame back to hardware
> > +ctx->reverse = 1;
> > +// incase user does not provide filter device, use the 
> > device_ref
> > +// from inlink
> > +if (!device)
> > +device = hwfc->device_ref;
> > +
> > +err = create_hwframe_context(ctx, avctx, device, 
> > outlink->format,
> > + inlink->format, inlink->w, 
> > inlink->h);
> > +if (err < 0)
> > +goto fail;
> 
> I don't think the unmap case here wants to make a new hardware frames
> context?  You have a software frame which is actually a mapping of a h

Re: [FFmpeg-devel] [PATCH] Fix usage of temp_file flag in hls_flags option

2018-12-17 Thread Ronak


> On Dec 17, 2018, at 4:35 PM, Aleksey Skripka  wrote:
> 
> Evening!
> 
> First of all, about playlist writeout:
> before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlist was always(!) 
> creating via .tmp file.
> after 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 - playlists .tmp logic become 
> dependent on +temp_file flag.
> 
> I suggest to return to original logic. 
> Non-atomic playlist writeout - is a disaster to just any hls player. This way 
> we will force everyone (except offline VOD) to start using +temp_file. 
> Always! 
> Also, if somebody relying on this - they will get broken streams just after 
> upgrade (It seems to me, that it can be a lot).
> 
> So, here maintainer should decide how to be.
> 
> 
> and about single_file:
> if it will be decided to stay with current way (playlist's .tmp logic 
> controlled by +temp_file flag), you are right - temp_file+single_file case 
> become unreal.
> if it will be decided to return original behaviour (playlist always via 
> .tmp), someone can choose how to writeout media file (despite i understand 
> temp+single is very-very rare case).
> 
> Thanks!
> -- 
> Aleksey Skripk
> 

Hey Aleksey,

I'm not sure the best thing to do here is to switch to the original logic. The 
temp file is only necessary if you are doing LIVE or EVENT streams; it has 
nothing to do with VOD; where streams are pre-generated. I don't see why you 
would ever want tmp files there.
Before this commit; ffmpeg used to take more than a week to fragment a 2.2 GB 
Audio File in VOD mode. With this change; it takes less than 1 minute. Other 
competing tools take less than 1 minute.

Also, if you want temp files, you should be supplying the temp_file option - 
the documentation clearly says that: 
https://www.ffmpeg.org/ffmpeg-all.html#hls-2. If you do not want temp files; 
then you should leave this option out. If you are forcing folks to always 
accept the temp file, then why have an option? You should delete the option and 
do it based on the playlist type.

Ronak

> 
> 
>> On 17 Dec 2018, at 19:12, Adrian > > wrote:
>> 
>> Comments inline.
>> 
>> Regards
>> Adrian Guzowski
>> 
>> W dniu 17.12.2018 o 16:56, Aleksey Skripka pisze:
 On 17 Dec 2018, at 18:45, Adrian >>>  >> wrote:
 
 IMO temp_file+single_file should be mutually exclusive - why would you 
 want to have temp file when you're using only one file anyway? In this 
 mode you would either pool for file changes or just get updated playlist 
 with new byte range (and that one should be updated after video file). I 
 believe this restriction was already in place anyway, because there 
 already were checks for HLS_SINGLE_FILE not being set, before doing actual 
 rename, so this was just a simplification of those conditions.
>>> not me to decide, please ;)
>>> if playlist will always be done via .tmp, we will have a choice.
>> Could you clarify what choice you're talking about? And the purpose of this 
>> choice - frankly you got me lost with this. Regardless, I feel we're getting 
>> off topic.
 As for playlist file - I'm not sure I follow, I've changed only places 
 where temp files were already used, so I don't think I broke something in 
 that matter.
>>> not you, it was introduced by 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6
>> Not quite, temp files were already a feature, this commit narrowed 
>> conditions where they are used. If you're referring to change in hls_window 
>> about not checking TEMP flag - that is unrelated to current state (before 
>> commit introducing regression, check was ignoring TEMP flag, after commit it 
>> does take it into account - probably should be discussed with person 
>> responsible for original change as to why it was changed that way, so that's 
>> out of scope of this patch. Issue at hand is not using TEMP files at all and 
>> that is fixed by this patch.
>> 
 From repeat+level+trace I believe I saw that playlist file actually was 
 using a temp file, so if that's the thing you are concerned about, it 
 seems like it's all good.
 
 Regards
 Adrian Guzowski
 
 W dniu 17.12.2018 o 16:36, Aleksey Skripka pisze:
> Greetings!
> 
> Adrian,
> with your variant of patch in case of '-hls_flags +temp_file+single_file' 
> no .tmp logic will be used.
> not sure what is better, but all previous versions was doing so.
> 
> and also, i'm still sure, that for backward compatibility with all 
> previous versions, index.m3u8 should always be written via .tmp file.
> 
> ps:
> i noticed this bug such way: i do not use +temp_file, but rely on atomic 
> rename of index.m3u8.
> 
>> On 17 Dec 2018, at 17:23, Adrian  wrote:
>> 
>> Hello,
>> 
>> after upgrading FFmpeg from 4.0 to 4.1 I noticed that temp files in HLS 
>> muxed stopped working.
>> It looks

Re: [FFmpeg-devel] [PATCH] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Mohammad Izadi
As Jan mentioned, we need to specify the kind of the HDR metadata. Here are
some alternatives:

AVDynamicHDRPlus
AVSMPTE2094App4 (Application 4 is HDR10+ while Dolby is application 1)
AVHDRPlusMetadata

Which one do you prefer?


--
Best,
Mohammad


On Mon, Dec 17, 2018 at 3:07 PM Jan Ekström  wrote:

> On Tue, Dec 18, 2018 at 12:58 AM Vittorio Giovara
>  wrote:
> >
> > On Mon, Dec 17, 2018 at 5:53 PM Jan Ekström  wrote:
> >
> > > On Tue, Dec 18, 2018 at 12:41 AM Vittorio Giovara
> > >  wrote:
> > > >
> > > > I like
> > > VeryLongJavaLikeNamingForFunctionsAndDataTypesAsWellAsEnumsOfCourse
> > > > as much as the next guy, but this is overly too long and the related
> > > > structure name (AVDynamicMetadataSMPTE2094_40) is inconsistent with
> the
> > > > public type naming present in this project.
> > > >
> > > > If I may suggest, please use the following names:
> > > > - AV_FRAME_DATA_DYNAMIC_HDR for frame data type: it is obviously
> > > metadata,
> > > > and the fact that is based on SMPTE2094-40 should not be hardcoded
> in the
> > > > name
> > > > - dynamic_hdr.h as header name: again the fact that it's metadata
> does
> > > not
> > > > be carried everywhere
> > > > - AVDynamicHDR as structure name: short and to the point, and without
> > > spec
> > > > numbers or underscores
> > > >
> > >
> > > I don't think SMPTE ST.2094-XX utilized the same fields?
> > >
> > > I think SMPTE ST.2094-40 is Samsung's dynamic metadata which is effect
> > > usually called "HDR10+" ? Not just calling it AVDynamicHDR could come
> > > up useful if we plan on adding support for SMPTE ST.2094-10 which is
> > > one part of what's called "Dolby Vision" (even though it is just
> > > dynamic metadata - because of course you have to stick everything
> > > under a single marketing name).
> > >
> >
> > It's still technically dynamic metadata but I get your point.
> > It could maybe be stored in dynamic_hdr.h header, and call it
> > AVDynamicHDRPlus to differenciate it from the future AVDolbyVisionHDR.
> What
> > do you think?
> >
>
> The other alternative would have been to make sure that the structure
> can take the values that are "essential" from those separate
> specifications.
>
> I do not have a heavy opinion one way or another (separate structure
> per spec or single with all the required data), but just had to
> mention it because it would have otherwise been a singular "dynamic
> HDR metadata" entity while it unfortunately seems that these things
> have splintered into multiple competing alternatives... (of which
> Samsung's and Dolby's things seem to be those getting most use)
>
> Jan
> ___
> 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] Add HDR dynamic metadata struct (for SPMTE 2094-40) to libavutil.

2018-12-17 Thread Vittorio Giovara
On Tue, Dec 18, 2018 at 12:04 AM Mohammad Izadi  wrote:

> As Jan mentioned, we need to specify the kind of the HDR metadata. Here are
> some alternatives:
>
> AVDynamicHDRPlus
> AVSMPTE2094App4 (Application 4 is HDR10+ while Dolby is application 1)
> AVHDRPlusMetadata
>
> Which one do you prefer?


IMO AVDynamicHDRPlus or AVHDRPlusMetadata.
Thanks,
Vittorio


> --
> Best,
> Mohammad
>
>
> On Mon, Dec 17, 2018 at 3:07 PM Jan Ekström  wrote:
>
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter

2018-12-17 Thread Li, Zhong
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zhou, Zachary
> Sent: Monday, December 3, 2018 6:56 PM
> To: FFmpeg development discussions and patches
> 
> Cc: Zhou, Zachary 
> Subject: Re: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi filter
> 
> ping? any more comments ?
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Zachary Zhou
> > Sent: Thursday, November 29, 2018 2:14 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Zachary Zhou ; Zhou, Zachary
> > 
> > Subject: [FFmpeg-devel] [PATCH v4] libavfilter: add transpose_vaapi
> > filter
> >
> > Swap width and height when do clock/cclock rotation Add 180/180_flip
> > options
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -
> > hwaccel_output_format vaapi -i input.264 -vf
> "transpose_vaapi=clock_flip"
> > -c:v h264_vaapi output.h264
> >
> > Signed-off-by: Zachary Zhou 
> > ---
> >  configure|   2 +
> >  libavfilter/Makefile |   1 +
> >  libavfilter/allfilters.c |   1 +
> >  libavfilter/vf_transpose_vaapi.c | 356
> > +++
> >  4 files changed, 360 insertions(+)
> >  create mode 100644 libavfilter/vf_transpose_vaapi.c
> >
> > diff --git a/configure b/configure
> > index 3e9222ed1b..9e3908ef61 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3480,6 +3480,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
> >  tinterlace_pad_test_deps="tinterlace_filter"
> >  tonemap_filter_deps="const_nan"
> >  tonemap_opencl_filter_deps="opencl const_nan"
> > +transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
> >  unsharp_opencl_filter_deps="opencl"
> >  uspp_filter_deps="gpl avcodec"
> >  vaguedenoiser_filter_deps="gpl"
> > @@ -5979,6 +5980,7 @@ check_type "d3d9.h dxva2api.h"
> > DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
> >
> >  check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> >  check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> > +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> > +rotation_flags
> >  check_type "va/va.h va/va_enc_hevc.h"
> > "VAEncPictureParameterBufferHEVC"
> >  check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> >  check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > 1895fa2b0d..ccce4bbb2f 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -393,6 +393,7 @@ OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER)
> +=
> > vf_tonemap_opencl.o colorspace.o
> >  OBJS-$(CONFIG_TPAD_FILTER)   += vf_tpad.o
> >  OBJS-$(CONFIG_TRANSPOSE_FILTER)  += vf_transpose.o
> >  OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER)  +=
> vf_transpose_npp.o
> > cuda_check.o
> > +OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+=
> vf_transpose_vaapi.o
> > vaapi_vpp.o
> >  OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
> >  OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  +=
> vf_premultiply.o
> > framesync.o
> >  OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
> > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> > 837c99eb75..40e5d82b62 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -372,6 +372,7 @@ extern AVFilter ff_vf_tonemap_opencl;  extern
> > AVFilter ff_vf_tpad;  extern AVFilter ff_vf_transpose;  extern
> > AVFilter ff_vf_transpose_npp;
> > +extern AVFilter ff_vf_transpose_vaapi;
> >  extern AVFilter ff_vf_trim;
> >  extern AVFilter ff_vf_unpremultiply;
> >  extern AVFilter ff_vf_unsharp;
> > diff --git a/libavfilter/vf_transpose_vaapi.c
> > b/libavfilter/vf_transpose_vaapi.c
> > new file mode 100644
> > index 00..d0502b7944
> > --- /dev/null
> > +++ b/libavfilter/vf_transpose_vaapi.c
> > @@ -0,0 +1,356 @@
> > +/*
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > +02110-1301 USA  */ #include 
> > +
> > +#include "libavutil/avassert.h"
> > +#include "libavutil/mem.h"
> > +#include "libavutil/opt.h"
> > +#include "libavutil/pixdesc.h"
> > +
> > +#include "avfilter.h"
> > +#include "formats.h"
> > +#include "internal.h"
> >

Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case: hevc-conformance-AMP_A_Samsung_* in loongson2k

2018-12-17 Thread Shiyou Yin
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of gxw
>Sent: Tuesday, December 18, 2018 9:15 AM
>To: ffmpeg-devel@ffmpeg.org
>Cc: gxw
>Subject: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] fix failed case:
>hevc-conformance-AMP_A_Samsung_* in loongson2k
>
>The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is 
>still 32
>in function ff_hevc_sao_edge_filter_8_msa. So, Modify the corresponding value 
>to 64.
>Fate tests passed.
>---
> libavcodec/mips/hevc_lpf_sao_msa.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/libavcodec/mips/hevc_lpf_sao_msa.c 
>b/libavcodec/mips/hevc_lpf_sao_msa.c
>index 5b5537a..bb883d0 100644
>--- a/libavcodec/mips/hevc_lpf_sao_msa.c
>+++ b/libavcodec/mips/hevc_lpf_sao_msa.c
>@@ -2630,7 +2630,7 @@ void ff_hevc_sao_edge_filter_8_msa(uint8_t *dst, uint8_t 
>*src,
>int16_t *sao_offset_val,
>int eo, int width, int height)
> {
>-ptrdiff_t stride_src = (2 * 64 + 32) / sizeof(uint8_t);
>+ptrdiff_t stride_src = (2 * 64 + 64) / sizeof(uint8_t);
>
> switch (eo) {
> case 0:
>--
>2.1.0
>
You can use AV_INPUT_BUFFER_PADDING_SIZE like 
ff_hevc_sao_edge_filter_neon_8_wrapper did or directly include avcode.h in 
hevc_lpf_sao_msa.c.


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


Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: set pict_type to be I for IDR frames.

2018-12-17 Thread Li, Zhong
>  libavcodec/qsvenc.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 931e994..96cf642 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1377,11 +1377,10 @@ int ff_qsv_encode(AVCodecContext *avctx,
> QSVEncContext *q,
>  new_pkt.pts  = av_rescale_q(bs->TimeStamp,
> (AVRational){1, 9}, avctx->time_base);
>  new_pkt.size = bs->DataLength;
> 
> -if (bs->FrameType & MFX_FRAMETYPE_IDR ||
> -bs->FrameType & MFX_FRAMETYPE_xIDR)
> +if (bs->FrameType & MFX_FRAMETYPE_IDR || bs->FrameType &
> + MFX_FRAMETYPE_xIDR) {
>  new_pkt.flags |= AV_PKT_FLAG_KEY;
> -
> -if (bs->FrameType & MFX_FRAMETYPE_I || bs->FrameType &
> MFX_FRAMETYPE_xI)
> +pict_type = AV_PICTURE_TYPE_I;
> +} else if (bs->FrameType & MFX_FRAMETYPE_I || bs->FrameType
> &
> + MFX_FRAMETYPE_xI)
>  pict_type = AV_PICTURE_TYPE_I;
>  else if (bs->FrameType & MFX_FRAMETYPE_P || bs->FrameType
> & MFX_FRAMETYPE_xP)
>  pict_type = AV_PICTURE_TYPE_P;
> --
> 2.7.4

Will apply if nobody against. 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel