Similar to cbs_h264, cbs_h265_{read, write}_nal_unit() can handle HEVC
prefix SEI NAL units now. Currently mastering display colour volume SEI
message is added only, we may add more SEI message if needed later
Signed-off-by: Haihao Xiang
---
libavcodec/cbs_h2645.c| 43 ++
'-sei xxx' is added to control SEI insertion, so far only mastering
display colour colume is available for testing. Another patch is
required to change mastering display settings later.
Signed-off-by: Haihao Xiang
---
libavcodec/vaapi_encode_h265.c | 94 +-
From: dongsheng7
the seg size is 25 - 10 + 1 = 16, not 15(=25-10).
Signed-off-by: dongshengwang
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6304ad933b..b07ed4f8f2 100644
--- a/libavformat/das
On Tue, 2018-03-13 at 07:51 +0800, Jun Zhao wrote:
>
> 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 her
> On 20 Apr 2018, at 15:37, dongsheng wang wrote:
>
> From: dongsheng7
>
>
> the seg size is 25 - 10 + 1 = 16, not 15(=25-10).
LGTM
>
> Signed-off-by: dongshengwang
> ---
> libavformat/dashdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashdec.c
Both patches LGTM.
> On Apr 19, 2018, at 18:51, Aman Gupta wrote:
>
> From: Aman Gupta
>
> ---
> libavformat/utils.c | 21 ++---
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 705b79031d..c25eab4d49 100644
On Thu, Apr 19, 2018 at 04:51:33PM -0700, Aman Gupta wrote:
> From: Aman Gupta
>
> Similar to 4c9c4fe8b21, but for durations. This fixes #7151, where
> the report duration and bitrate on a mpegts stream is wildly off
> due to the dvb_teletext stream's timings.
> ---
> libavformat/utils.c | 14 ++
If there was a way to indicate this to consumers, or expose an option to turn
this off, I'd say it should have that... but there's no good infrastructure to
do that in an hwaccel, so whatever.
One nit; otherwise LGTM.
> On Apr 19, 2018, at 17:34, Aman Gupta wrote:
>
> From: Aman Gupta
>
> Ol
On Fri, Apr 20, 2018 at 05:30:02AM +0100, Rostislav Pehlivanov wrote:
> The plan is to eventually be able to apply effects and encode entirely
> on the GPU.
>
> Rostislav Pehlivanov (8):
> hwcontext_internal: add ff_hwframe_map_replace
> hwcontext_opencl: use ff_hwframe_map_replace()
> lavu:
On Fri, 20 Apr 2018 03:43:30 -0500
Rodger Combs wrote:
> If there was a way to indicate this to consumers, or expose an option to turn
> this off, I'd say it should have that... but there's no good infrastructure
> to do that in an hwaccel, so whatever.
> One nit; otherwise LGTM.
>
I guess it
(Sorry for spamming, forgot the sign off part)
This patch make ffmpeg able to create a single HLS m3u8 with different
duration in the same manifest for VOD playlist ype.
This has benefit on optimizing HLS stream to start faster, having
initially shorter duration. The later part of the
stream coul
On Fri, Apr 20, 2018 at 02:31:59AM +0200, Michael Niedermayer wrote:
> On Thu, Apr 19, 2018 at 01:31:33PM +0200, Hendrik Leppkes wrote:
> > On Wed, Apr 18, 2018 at 11:15 PM, Michael Niedermayer
> > wrote:
> > > On Wed, Apr 18, 2018 at 04:09:41PM +0200, Hendrik Leppkes wrote:
> > >> On Mon, Apr 16,
On 20 April 2018 at 10:05, Michael Niedermayer
wrote:
> On Fri, Apr 20, 2018 at 05:30:02AM +0100, Rostislav Pehlivanov wrote:
> > The plan is to eventually be able to apply effects and encode entirely
> > on the GPU.
> >
> > Rostislav Pehlivanov (8):
> > hwcontext_internal: add ff_hwframe_map_r
On Sun, Apr 08, 2018 at 18:48:23 +0100, Mark Thompson wrote:
> Can adjust the colour information.
> ---
> configure | 1 +
> libavcodec/Makefile| 1 +
> libavcodec/bitstream_filters.c | 1 +
> libavcodec/vp9_metadata_bsf.c | 162
> ++
Hey guys,
So I think this may be my own lack of knowledge in the encoder.
Because we were specifying -b:a 32k in our encoding step, I thought the byte
ranges should align properly, but I’ve since learned that is incorrect.
The compression is still variable in terms of bytes.
Therefore this is
Awesome guys thanks for the fix! That was fast!
Sent from my iPhone
> On Apr 19, 2018, at 11:41 PM, Jeyapal, Karthick wrote:
>
>
>
>> On 4/20/18 9:02 AM, Steven Liu wrote:
>> reference hls support fmp4 file from draft-pantos-http-live-streaming-20
>> the spec describes version 7 of hls proto
Signed-off-by: James Almer
---
src/index | 50 ++
1 file changed, 50 insertions(+)
diff --git a/src/index b/src/index
index 2b44762..bbfca29 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,56 @@
News
+ April 20th, 2018, FFmpeg 4.0 "
Signed-off-by: Vasile Toncu
---
libavfilter/Makefile | 2 +-
libavfilter/interlace.h | 68 ---
libavfilter/vf_interlace.c | 366
libavfilter/vf_tinterlace.c | 26 +++
libavfilter/x86/Makefile |
On 20.04.2018 16:27, James Almer wrote:
[..]
> +
> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2
> streams
> +Experimental MagicYUV encoder
> +TiVo ty/ty+ demuxer
> +Intel QSV-accelerated MJPEG encoding
> +native aptX and aptX HD encoder and decoder
> +
On 4/20/2018 2:39 AM, Misty De Meo wrote:
> On Thu, Apr 19, 2018 at 8:31 PM, James Almer wrote:
>>
>>> +film->sample_table[i].duration = AV_RB32(&scratch[12]);
>>
>> While for video tracks this field seems to report the same packet
>> durations that were being calculated pre patch, this fi
On 4/20/2018 11:58 AM, Thomas Volkert wrote:
>
> On 20.04.2018 16:27, James Almer wrote:
> [..]
>> +
>> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2
>> streams
>> +Experimental MagicYUV encoder
>> +TiVo ty/ty+ demuxer
>> +Intel QSV-accelerated MJPEG encoding
On 20.04.2018 17:07, James Almer wrote:
> On 4/20/2018 11:58 AM, Thomas Volkert wrote:
>> On 20.04.2018 16:27, James Almer wrote:
>> [..]
>>> +
>>> +Bitstream filters for editing metadata in H.264, HEVC and MPEG-2
>>> streams
>>> +Experimental MagicYUV encoder
>>> +TiVo ty/ty+ demuxe
2018-04-20 22:27 GMT+08:00 James Almer :
> Signed-off-by: James Almer
> ---
> src/index | 50 ++
> 1 file changed, 50 insertions(+)
>
> diff --git a/src/index b/src/index
> index 2b44762..bbfca29 100644
> --- a/src/index
> +++ b/src/index
> @@ -37,6
On 4/20/2018 8:35 PM, James Almer wrote:
I don't understand the reasoning to invert the logic here. The current
behavior is clearly not right. We're marking Inter coded frames as key
frames and Intra coded frames as non keyframes.
This behaviour was how it was originally. See the sample att
On 4/20/2018 12:21 PM, Steven Liu wrote:
> 2018-04-20 22:27 GMT+08:00 James Almer :
>> Signed-off-by: James Almer
>> ---
>> src/index | 50 ++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/src/index b/src/index
>> index 2b44762..bbfca29 100
On 4/20/2018 12:34 PM, Gyan Doshi wrote:
>
>
> On 4/20/2018 8:35 PM, James Almer wrote:
>
>
>> I don't understand the reasoning to invert the logic here. The current
>> behavior is clearly not right. We're marking Inter coded frames as key
>> frames and Intra coded frames as non keyframes.
>
>
On 4/20/18, James Almer wrote:
> On 4/20/2018 12:34 PM, Gyan Doshi wrote:
>>
>>
>> On 4/20/2018 8:35 PM, James Almer wrote:
>>
>>
>>> I don't understand the reasoning to invert the logic here. The current
>>> behavior is clearly not right. We're marking Inter coded frames as key
>>> frames and Int
On 4/20/2018 9:22 PM, James Almer wrote:
Wouldn't this hint that the file in question is broken?
I don't follow. If the inversion was a mistake, then frames currently
not marked by demuxer are in fact keyframes and a stream decoded from
that frame onwards should show correct output. I see
On 4/20/2018 1:09 PM, Paul B Mahol wrote:
> On 4/20/18, James Almer wrote:
>> On 4/20/2018 12:34 PM, Gyan Doshi wrote:
>>>
>>>
>>> On 4/20/2018 8:35 PM, James Almer wrote:
>>>
>>>
I don't understand the reasoning to invert the logic here. The current
behavior is clearly not right. We're
On 4/20/2018 9:39 PM, Gyan Doshi wrote:
It's very much possible I'm missing something but I don't see what.
Yup. I see that the decoder sets the frame flags correctly. The ticket
sample file is wrongly muxed, and so the inversion is wrong.
Will send patch tomorrow unless someone gets to i
Hi!
We changed 4 files in ffmpeg, libavcodec/nvdec.c, libavutil/hwcontext.c,
libavutil/hwcontext_cuda.h, libavutil/hwcontext_cuda.c.
The purpose of this modification is very simple. We needed, for performance
reasons (per frame execution time), that nvdec.c used the same CUDA context as
we us
Hello all,
Attached is a revised patch based on your suggestions.
Rostislav Pehlivanov - I'm not sure how to address your concerns. My patch
provides support for the ambisonics features already approved and present
in Opus 1.3. If there are ways I can change my patch, please let me know.
Cheers,
On 20 April 2018 at 18:23, Drew Allen
wrote:
> Hello all,
>
> Attached is a revised patch based on your suggestions.
>
> Rostislav Pehlivanov - I'm not sure how to address your concerns. My patch
> provides support for the ambisonics features already approved and present
> in Opus 1.3. If there a
From: Damien Riegel
ff_get_buffer is used to allocate a buffer to hold frame's content. This
function was called in the function in charge of decoding an AVPacket
containing raw video with the yuv422 pixel format and a depth of 10-bit.
RFC4175 supports both progressive and interlaced mode. But t
From: Damien Riegel
This codec is already capable of depacking some combinations of pixel
formats and depth as defined in the RFC4175. The only difference between
progressive and interlace is that either a packet will contain the whole
frame, or only a field of the frame.
There is no mechanism f
From: Damien Riegel
In order to handle the interlaced formats, the demuxer has only a few
things to do:
- parse the SDP correctly and propagate the information
- check the field bit in the RFC4175 header, and pass that information
to the decoder
In interlaced mode, received data only consis
On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> src/index | 50 ++
> 1 file changed, 50 insertions(+)
This or any variant (for example with more/less entries) LGTM
thanks
[...]
--
Michael Gnu
On 20 April 2018 at 20:02, Patrick Keroulas <
patrick.kerou...@savoirfairelinux.com> wrote:
> From: Damien Riegel
>
> This codec is already capable of depacking some combinations of pixel
> formats and depth as defined in the RFC4175. The only difference between
> progressive and interlace is tha
On 20 April 2018 at 20:16, Michael Niedermayer
wrote:
> On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
> > Signed-off-by: James Almer
> > ---
> > src/index | 50 ++
> > 1 file changed, 50 insertions(+)
>
> This or any variant (for ex
On 4/20/2018 4:41 PM, Rostislav Pehlivanov wrote:
> On 20 April 2018 at 20:16, Michael Niedermayer
> wrote:
>
>> On Fri, Apr 20, 2018 at 11:27:54AM -0300, James Almer wrote:
>>> Signed-off-by: James Almer
>>> ---
>>> src/index | 50 ++
>>> 1 file
On Sun, Apr 08, 2018 at 17:28:24 +0200, Martin Vignali wrote:
> - 001 : Fix -window_size option
> Before this patch, window_size is always set to the source size
> In other word, -window_size option have no effect.
Makes sense, since the option was already there.
> - 002 : Add option to set the
The -benchmark and -benchmark_all options now show user, system, and real time,
instead of just user time.
---
fftools/ffmpeg.c | 50 ++--
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 4dbe72186
On Fri, Apr 20, 2018 at 17:44:17 +0300, Vasile Toncu wrote:
> -typedef struct InterlaceContext {
> - const AVClass *class;
> - enum ScanMode scan; // top or bottom field first scanning
> - int lowpass; // enable or disable low pass filtering
> - AVFrame *cur, *next; // th
On Thu, Apr 19, 2018 at 03:04:57PM -0700, Jacob Trimble wrote:
> On Thu, Apr 19, 2018 at 2:07 AM, Michael Niedermayer
> wrote:
> > On Tue, Jan 09, 2018 at 10:27:28AM -0800, Jacob Trimble wrote:
> >> On Mon, Jan 8, 2018 at 5:39 PM, Carl Eugen Hoyos
> >> wrote:
> >> > 2018-01-08 23:34 GMT+01:00 Ja
On 20 April 2018 at 05:30, Rostislav Pehlivanov wrote:
> This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
> VAAPI frames but additional functionality can be added later to support
> importing of D3D11 surfaces as well as exporting to various other APIs.
>
> This context r
45 matches
Mail list logo