On Sun, Mar 11, 2018 at 11:30 AM, Mark Thompson wrote:
> ---
> libavcodec/h264_metadata_bsf.c | 121 ++
> +++
> 1 file changed, 121 insertions(+)
>
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_
> bsf.c
> index 36047887ca..d340c55990
From: Aman Gupta
---
doc/bitstream_filters.texi | 12 +++
libavcodec/mpeg2_metadata_bsf.c | 79 -
2 files changed, 90 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index b7ea549322..c0b48e62dc 1
So, I spend few hours trying to incorporate the partial change.
I'm not sure that the video sent by earlier follows the
faces order here
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3
Because when I made this change, I got a reasonable equirectangu
From: Aman Gupta
---
libavcodec/h264_slice.c| 5 +++--
libavcodec/mpeg12dec.c | 14 +-
libavcodec/mpegvideo_enc.c | 3 ++-
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 90e05ed8f1..b381397b4d 100644
-
On Mon, Mar 12, 2018 at 12:24 AM, Aman Gupta wrote:
> From: Aman Gupta
>
> ---
> doc/bitstream_filters.texi | 12 +++
> libavcodec/mpeg2_metadata_bsf.c | 79 ++
> ++-
> 2 files changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/doc/bitstream_f
On 3/12/18, Hazem Ashmawy wrote:
> So, I spend few hours trying to incorporate the partial change.
>
> I'm not sure that the video sent by earlier follows the
> faces order here
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md#semantics-3
>
> Because when I mad
---
libavcodec/mediacodecdec_common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mediacodecdec_common.c
b/libavcodec/mediacodecdec_common.c
index 5064809cf6..058825a1a2 100644
--- a/libavcodec/mediacodecdec_common.c
+++ b/libavcodec/mediacodecdec_common.c
@
On Mon, Mar 12, 2018 at 1:16 AM, Matthieu Bouron
wrote:
> ---
> libavcodec/mediacodecdec_common.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mediacodecdec_common.c b/libavcodec/mediacodecdec_
> common.c
> index 5064809cf6..058825a1a2 100644
> --- a/li
On Sat, Mar 10, 2018 at 11:48 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> Some Android devices are very finicky about how quicky output buffers
> are returned back to the decoder, especially when they are associated
> with a Surface.
>
> This commit adds a new counter that keeps track of exactl
On 3/12/18, Paul B Mahol wrote:
> On 3/12/18, Hazem Ashmawy wrote:
>> So, I spend few hours trying to incorporate the partial change.
>>
>> I'm not sure that the video sent by earlier follows the
>> faces order here
>> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-r
On 3/12/18, Hazem Ashmawy wrote:
> On 3/12/18, Paul B Mahol wrote:
>> On 3/12/18, Hazem Ashmawy wrote:
>>> So, I spend few hours trying to incorporate the partial change.
>>>
>>> I'm not sure that the video sent by earlier follows the
>>> faces order here
>>> https://github.com/google/spatial-m
On Mon, Mar 12, 2018 at 01:24:02AM -0700, Aman Gupta wrote:
> On Mon, Mar 12, 2018 at 1:16 AM, Matthieu Bouron
> wrote:
>
> > ---
> > libavcodec/mediacodecdec_common.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/mediacodecdec_common.c b/libavcode
From: Vishwanath Dixit
This is the fix for bug https://trac.ffmpeg.org/ticket/7073
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 08fe0aa..7d9512b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/h
On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson wrote:
> ---
> libavcodec/h264_metadata_bsf.c | 121
> +
> 1 file changed, 121 insertions(+)
>
> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
> index 36047887ca..d340c55990 1006
Specifications can be found here:
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
Signed-off-by: Hazem Ashmawy
---
libavfilter/vf_panorama.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/libavfilter/vf_pa
On 3/12/18, Hazem Ashmawy wrote:
> Specifications can be found here:
> https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>
> Signed-off-by: Hazem Ashmawy
> ---
> libavfilter/vf_panorama.c | 32
> 1 file changed, 16 insertions(+),
On Mon, 12 Mar 2018 11:26:26 +0100
Paul B Mahol wrote:
> On 3/12/18, Hazem Ashmawy wrote:
> > Specifications can be found here:
> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
> >
> > Signed-off-by: Hazem Ashmawy
> > ---
> > libavfilter/vf_panorama.c | 32
> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
>
> From: Vishwanath Dixit
>
> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> in
On 3/12/18, wm4 wrote:
> On Mon, 12 Mar 2018 11:26:26 +0100
> Paul B Mahol wrote:
>
>> On 3/12/18, Hazem Ashmawy wrote:
>> > Specifications can be found here:
>> > https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>> >
>> > Signed-off-by: Hazem Ashmawy
>> > ---
On 12/03/18 00:22, Mark Thompson wrote:
> On 11/03/18 23:59, Rostislav Pehlivanov wrote:
>> On 11 March 2018 at 22:41, Mark Thompson wrote:
>>
>>> Also use that to support mapping VAAPI to Beignet.
>>> ---
>>> configure| 16 +--
>>> libavutil/hwcontext_opencl.c | 264
On 12/03/18 00:03, Rostislav Pehlivanov wrote:
> On 11 March 2018 at 22:41, Mark Thompson wrote:
>
>> ---
>> doc/indevs.texi | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/doc/indevs.texi b/doc/indevs.texi
>> index 6951940a93..02d1cb3d86 100644
>> --- a/doc/indevs.texi
>> ++
On 12/03/18 00:41, Jun Zhao wrote:
> On 2018/3/12 2:30, Mark Thompson wrote:
>> Apply the same logic as the previous patch to H.265. There are no cases
>> which currently overflow here, but this is still more consistent.
>> ---
>> libavcodec/cbs_h265_syntax_template.c | 16
>> 1
On 12/03/18 05:38, Pengfei Qu wrote:
> And for VBR mode, generally the max bit rate is bigger than the taraget
> bitrate. For CBR mode, the max bitrate is same as the target bitrate.
> when there is no specfic setting for the max bit rate parameter,
> here the default value 95% is
> Does extracting really make sense? Doesn't the data end up out of
> order and basically unusable?
For what it’s worth, I’ve got a video filter which extracts the A53 side data
and saves it into an MCC file (Telestream MacCaption format). If people think
that’s something that would be useful,
Sorry about that! Here is github branch
https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
On 3/12/18, Paul B Mahol wrote:
> On 3/12/18, wm4 wrote:
>> On Mon, 12 Mar 2018 11:26:26 +0100
>> Paul B Mahol wrote:
>>
>>> On 3/12/18, Hazem Ashmawy wrote:
>>> > Specificati
On 12/03/18 06:30, Danil Iashchenko wrote:
> ---
> libavfilter/vf_convolution_opencl.c | 39
> ++---
> 1 file changed, 15 insertions(+), 24 deletions(-)
>
> diff --git a/libavfilter/vf_convolution_opencl.c
> b/libavfilter/vf_convolution_opencl.c
> index 60e2d1f..
On 3/12/18, Hazem Ashmawy wrote:
> Sorry about that! Here is github branch
>
> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
Good, now can you look at how to use bilinear instead of nearest interpolation
for cubemap to equirectangular conversion.
Nearest is extrem
On 12/03/18 07:19, Aman Gupta wrote:
> On Sun, Mar 11, 2018 at 11:30 AM, Mark Thompson wrote:
>
>> ---
>> libavcodec/h264_metadata_bsf.c | 121 ++
>> +++
>> 1 file changed, 121 insertions(+)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_m
On 12/03/18 09:54, Hendrik Leppkes wrote:
> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson wrote:
>> ---
>> libavcodec/h264_metadata_bsf.c | 121
>> +
>> 1 file changed, 121 insertions(+)
>>
>> diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_
On 3/12/2018 7:48 AM, Paul B Mahol wrote:
> On 3/12/18, wm4 wrote:
>> On Mon, 12 Mar 2018 11:26:26 +0100
>> Paul B Mahol wrote:
>>
>>> On 3/12/18, Hazem Ashmawy wrote:
Specifications can be found here:
https://github.com/google/spatial-media/blob/master/docs/spherical-video-v2-rfc.md
>
On 3/12/2018 3:34 AM, Steven Liu wrote:
> fmp4_init_filename should append after base_output_dirname
>
> Signed-off-by: Steven Liu
I'll ask you the same thing i asked Jun Zhao. Please configure git
send-email properly to send patchsets as a single thread.
On 3/11/2018 10:23 PM, Jun Zhao wrote:
> V2: update opt fate test ref file
Unrelated to this patch, but can you please make sure to the patchsets
you send are contained in a single thread? Every email in a set after
the first should be a reply to it.
___
On 3/12/18, James Almer wrote:
> On 3/12/2018 7:48 AM, Paul B Mahol wrote:
>> On 3/12/18, wm4 wrote:
>>> On Mon, 12 Mar 2018 11:26:26 +0100
>>> Paul B Mahol wrote:
>>>
On 3/12/18, Hazem Ashmawy wrote:
> Specifications can be found here:
> https://github.com/google/spatial-media/blo
On Mon, Mar 12, 2018 at 2:38 PM, Mark Thompson wrote:
> On 12/03/18 09:54, Hendrik Leppkes wrote:
>> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson wrote:
>>> ---
>>> libavcodec/h264_metadata_bsf.c | 121
>>> +
>>> 1 file changed, 121 insertions(+)
>>>
>>
> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
>
> From: Vishwanath Dixit
>
> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
> ---
> libavformat/hlsenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> inde
Paul B Mahol (2018-03-12):
> > What are these avfilter limitations you speak of?
> Sure.
Is "sure" supposed to be an answer to that question?
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ff
On 3/12/18, Nicolas George wrote:
> Paul B Mahol (2018-03-12):
>> > What are these avfilter limitations you speak of?
>
>> Sure.
>
> Is "sure" supposed to be an answer to that question?
Look at thread for stereo3d video filter patch.
___
ffmpeg-devel ma
On 12/03/18 15:10, Hendrik Leppkes wrote:
> On Mon, Mar 12, 2018 at 2:38 PM, Mark Thompson wrote:
>> On 12/03/18 09:54, Hendrik Leppkes wrote:
>>> On Sun, Mar 11, 2018 at 7:30 PM, Mark Thompson wrote:
---
libavcodec/h264_metadata_bsf.c | 121
++
On 3/12/18, Paul B Mahol wrote:
> On 3/12/18, Hazem Ashmawy wrote:
>> Sorry about that! Here is github branch
>>
>> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
>
> Good, now can you look at how to use bilinear instead of nearest
> interpolation
> for cubemap to e
On 3/12/18, Hazem Ashmawy wrote:
> On 3/12/18, Paul B Mahol wrote:
>> On 3/12/18, Hazem Ashmawy wrote:
>>> Sorry about that! Here is github branch
>>>
>>> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube
>>
>> Good, now can you look at how to use bilinear instead of
On 12 March 2018 at 12:30, Mark Thompson wrote:
> On 12/03/18 00:22, Mark Thompson wrote:
> > On 11/03/18 23:59, Rostislav Pehlivanov wrote:
> >> On 11 March 2018 at 22:41, Mark Thompson wrote:
> >>
> >>> Also use that to support mapping VAAPI to Beignet.
> >>> ---
> >>> configure
On 12 March 2018 at 00:23, Mark Thompson wrote:
> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
> > On 11 March 2018 at 22:41, Mark Thompson wrote:
> >
> >> The old vaAcquireBufferHandle() API works in fewer cases and provides
> >> less information than the current vaExportSurfaceHandle(), but
On 3/12/2018 6:58 AM, Valery Kot wrote:
> Could somebody please take a look into my patch? Or is it somehow invisible
> / badly formatted?
>
> It allows for inducing key frames at proper moments by e.g.
> -force_key_frames, while using openH264 codec. Thus accurate HLS with LGPL
> license, which i
On Mon, 12 Mar 2018, wm4 wrote:
On Sun, 11 Mar 2018 18:12:05 +0100
Marton Balint wrote:
Fixes a regression since 2a88ebd096f3c748a2d99ed1b60b22879b3c567c which caused
an infinite loop in the subtitle decoding.
Fixes ticket #6796.
Signed-off-by: Marton Balint
---
fftools/ffprobe.c | 3 ++
_
From: Derek Buitenhuis
Sent: Monday, March 12, 2018 6:54 PM
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame
in response to I frame pict_type
To:
On 3/12/2018 6:58 AM, Valery Kot wrote:
>> Could somebody please take a look into my pat
On Mon, 5 Mar 2018 15:01:16 +0100
Valery Kot wrote:
> From f95943165c91dac13a644365f775aff3dd9edb11 Mon Sep 17 00:00:00 2001
> From: vkot
> Date: Mon, 5 Mar 2018 13:51:51 +0100
> Subject: [PATCH 3/3] avcodec/openh264enc.c: generate IDR frame in response to
> I frame pict_type
>
> ---
> libavc
Got it. Do I have to post an updated patch as a reply to this thread?
Valery
_
From: Lou Logan
Sent: Monday, March 12, 2018 10:20 PM
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/openh264enc.c: generate IDR frame
in response to I frame pict_type
To:
On Mon, 5 Mar 201
On Mon, Mar 12, 2018, at 1:46 PM, Valery Kot wrote:
> Got it. Do I have to post an updated patch as a reply to this thread?
Whatever you prefer, but adding a version to the subject can be helpful for us
to keep track. You can do that with the "-v" option in "git format-patch". If
you want to kee
On 11/03/18 20:19, Danil Iashchenko wrote:
> ---
> configure | 1 +
> libavfilter/Makefile| 1 +
> libavfilter/allfilters.c| 1 +
> libavfilter/opencl/convolution.cl | 42
> libavfilter/opencl_source.h | 3 +
> libavfilt
On 12/03/18 17:40, Rostislav Pehlivanov wrote:
> On 12 March 2018 at 00:23, Mark Thompson wrote:
>
>> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
>>> On 11 March 2018 at 22:41, Mark Thompson wrote:
>>>
The old vaAcquireBufferHandle() API works in fewer cases and provides
less inform
On 12/03/18 05:38, Pengfei Qu wrote:
> this fix the overflow during the caculation before value assignment.
>
> Signed-off-by: Pengfei Qu
> ---
> libavcodec/vaapi_encode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_e
On Windows machines, the UL suffix still means 32 bits.
The only parts that need 64 bits are (1ULL << (m + 32)) and
(t*qf + qf). Hence, use the proper ULL suffix for the former
and just increase the type of the qf constant for the latter.
No overflows can happen as long as these are done in 64 bits
On 2018/3/12 20:47, Mark Thompson wrote:
> On 12/03/18 00:41, Jun Zhao wrote:
>> On 2018/3/12 2:30, Mark Thompson wrote:
>>> Apply the same logic as the previous patch to H.265. There are no cases
>>> which currently overflow here, but this is still more consistent.
>>> ---
>>> libavcodec/cbs_h
On Sun, Mar 11, 2018 at 11:56:46PM +0900, Yusuke Nakamura wrote:
> 2018-02-13 1:45 GMT+09:00 Yusuke Nakamura :
>
> > Any parameter set shall have start code of at least 4 byte size.
> > ---
> > libavcodec/h264_mp4toannexb_bsf.c| 22 +++---
> > tests/ref/fate/h264-bsf-m
On 2018/3/12 22:23, James Almer wrote:
> On 3/11/2018 10:23 PM, Jun Zhao wrote:
>> V2: update opt fate test ref file
> Unrelated to this patch, but can you please make sure to the patchsets
> you send are contained in a single thread? Every email in a set after
> the first should be a reply to it
On Sun, Mar 11, 2018 at 06:30:18PM +, Mark Thompson wrote:
> Improve documentation for the delete_filler option, and add the
> display_orientation and a53_cc options.
> ---
> doc/bitstream_filters.texi | 50
> +-
> 1 file changed, 49 insertions(+),
On Sat, Mar 10, 2018 at 03:55:06PM +0100, Paul B Mahol wrote:
> On 3/10/18, Philipp M. Scholl wrote:
> > Thanks for the discussion. Here's the next version, now with /25 and
> > removed
> > ff_log2().
> >
> > The blocksize of the PCM decoder is hard-coded. This creates
> > unnecessary delay wh
On 12 March 2018 at 23:36, Rostislav Pehlivanov wrote:
> On Windows machines, the UL suffix still means 32 bits.
> The only parts that need 64 bits are (1ULL << (m + 32)) and
> (t*qf + qf). Hence, use the proper ULL suffix for the former
> and just increase the type of the qf constant for the lat
From: Aman Gupta
---
libavcodec/h264_slice.c| 5 +++--
libavcodec/mpeg12dec.c | 12 +++-
libavcodec/mpegvideo_enc.c | 3 ++-
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 90e05ed8f1..b381397b4d 100644
---
On 12 March 2018 at 22:46, Mark Thompson wrote:
> On 12/03/18 17:40, Rostislav Pehlivanov wrote:
> > On 12 March 2018 at 00:23, Mark Thompson wrote:
> >
> >> On 12/03/18 00:01, Rostislav Pehlivanov wrote:
> >>> On 11 March 2018 at 22:41, Mark Thompson wrote:
> >>>
> The old vaAcquireBuffer
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
Thompson
Sent: Tuesday, March 13, 2018 6:54 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_encode: fix the caculation
overflow
On 12/03/18 05:38, Pengfei
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
Thompson
Sent: Monday, March 12, 2018 8:54 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavf/vaapi_encode: fix to set the
default max bitrate for AVC VBR
On 12/03/
On 3/12/18, 8:55 PM, "刘歧" wrote:
>> On 12 Mar 2018, at 17:31, vdi...@akamai.com wrote:
>>
>> From: Vishwanath Dixit
>>
>> This is the fix for bug https://trac.ffmpeg.org/ticket/7073
>> ---
>> libavformat/hlsenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib
This could previously happen in error or early-exit cases. The next commit
would make it happen in all cases.
---
libavformat/movenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5b1e66c897..353a42ae2c 100644
--- a/libavformat/movenc.c
+++
---
libavformat/dashenc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 79d63e52d4..5689aef811 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1030,10 +1030,8 @@ static int dash_write_header(AVFormatCon
Fixes crash when muxing MKV-in-DASH
---
libavformat/dashenc.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 5689aef811..63ff827583 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -985,13 +985,6 @
DASH muxing sometimes calls mov_write_eac3_tag multiple times on the same
stream.
We need to keep this data around so it's available in the second call, else we
won't write the data QuickTime needs.
---
libavformat/movenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/movenc.c b
On Mon, 12 Mar 2018 17:05:30 +0100
Paul B Mahol wrote:
> On 3/12/18, Nicolas George wrote:
> > Paul B Mahol (2018-03-12):
> >> > What are these avfilter limitations you speak of?
> >
> >> Sure.
> >
> > Is "sure" supposed to be an answer to that question?
>
> Look at thread for stereo3
68 matches
Mail list logo
