Michael, I appreciate it if you can take a look and give me your feedback.
Thanks,
Mohammad
On Thu, Sep 8, 2022 at 10:03 AM Mohammad Izadi wrote:
> Michael, I appreciate it if you can take a look and give me your feedback.
>
>
> On Thu, Sep 8, 2022 at 9:31 AM Michael Niederma
Michael, I appreciate it if you can take a look and give me your feedback.
On Thu, Sep 8, 2022 at 9:31 AM Michael Niedermayer
wrote:
> On Wed, Sep 07, 2022 at 02:12:46PM +0100, Derek Buitenhuis wrote:
> > On 9/6/2022 10:47 PM, Mohammad Izadi wrote:
> > > +if (side_data
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
libavcodec/dynamic_hdr10_plus.c | 269 +---
libavcodec/dynamic_hdr10_plus.h |
Thank you Derek for your comment ! It’s fixed.
On Wed, Sep 7, 2022 at 6:13 AM Derek Buitenhuis
wrote:
> On 9/6/2022 10:47 PM, Mohammad Izadi wrote:
> > +if (side_data && side_data_size > 0)
> > +
> ff_write_dynamic_hdr10_plus_to_full_itu_t_t35
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
libavcodec/dynamic_hdr10_plus.c | 269 +---
libavcodec/dynamic_hdr10_plus.h |
FYI
On Thu, May 19, 2022 at 1:42 PM Mohammad Izadi wrote:
> ffmpeg support YCOCG (YCOCG=YCGCO). However, vf_colorspace is only support
> YCGCO as input. Added YCOCG to the inputs.
> ---
> libavfilter/vf_colorspace.c | 1 +
> 1 file changed, 1 insertion(+)
>
> dif
ffmpeg support YCOCG (YCOCG=YCGCO). However, vf_colorspace is only support
YCGCO as input. Added YCOCG to the inputs.
---
libavfilter/vf_colorspace.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_colorspace.c b/libavfilter/vf_colorspace.c
index 3c8b3b20eb..bccd04528e 100644
From: Gyan Doshi
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
libavcodec/dynamic_hdr10_plus.c | 269 +---
On Tue, Aug 17, 2021 at 9:41 PM Gyan Doshi wrote:
>
>
> On 2021-08-18 04:10 am, Mohammad Izadi wrote:
> > From: Gyan Doshi
>
> Can you refresh my memory on how I'm involved?
>
Don't know. Sent to ffmpeg-devel@ffmpeg.org.
>
> >
> > The fa
From: Gyan Doshi
The fate test file can be found here:
https://drive.google.com/file/d/1jGW3f94rglLfr5WGmMQe3SEnp1YkbMRy/view?usp=drivesdk
The video file needs to be copied to fate-suite/mkv/
---
libavcodec/dynamic_hdr10_plus.c | 273 +---
On Tue, Jun 22, 2021 at 1:47 PM James Zern
wrote:
> On Thu, Jun 17, 2021 at 10:21 PM Mohammad Izadi
> wrote:
> >
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
LGTM?
On Thu, Jun 17, 2021 at 10:21 PM Mohammad Izadi wrote:
>
>
> On Thu, Jun 17, 2021 at 1:04 PM James Zern
> wrote:
>
>> On Wed, Jun 16, 2021 at 3:53 PM Mohammad Izadi
>> wrote:
>> >
>> > HDR10+ metadata is stored in the bit stream for HEVC.
On Thu, Jun 17, 2021 at 1:04 PM James Zern
wrote:
> On Wed, Jun 16, 2021 at 3:53 PM Mohammad Izadi
> wrote:
> >
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Tue, Jun 15, 2021 at 5:18 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passe
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
Thanks,
Mohammad
On Mon, Jun 14, 2021 at 5:17 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > On Thu, Jun 10, 2021 at 4:05 PM Andreas Rheinhardt <
> > andreas.rheinha...@outlook.com> wrote:
> >
> >> Mohammad Izadi:
Thanks,
Mohammad
On Mon, Jun 14, 2021 at 4:42 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Thu, Jun 10, 2021 at 4:05 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passe
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Tue, Jun 8, 2021 at 12:01 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Andreas Rheinhardt:
> > Mohammad Izadi:
> >> HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the
On Mon, Jun 7, 2021 at 12:59 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Michael Niedermayer:
> > On Mon, Jun 07, 2021 at 10:39:19AM -0700, Mohammad Izadi wrote:
> >> HDR10+ metadata is stored in the bit stream for HEVC. The story is
> differe
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Mon, Jun 7, 2021 at 9:51 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Mohammad Izadi:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passe
On Wed, Jun 2, 2021 at 1:34 PM James Zern
wrote:
> On Tue, Jun 1, 2021 at 6:23 PM Mohammad Izadi
> wrote:
> >
> > On Fri, May 28, 2021 at 4:49 AM Michael Niedermayer
>
> > wrote:
> >
> > > On Thu, May 27, 2021 at 09:44:10AM -0700, Mohammad Izad
On Wed, Jun 2, 2021 at 1:31 PM James Zern
wrote:
> On Tue, Jun 1, 2021 at 6:47 PM Mohammad Izadi
> wrote:
> > [...]
> > +static av_cold int add_hdr10_plus(AVFifoBuffer *fifo, struct
> FrameHDR10Plus *data)
> > +{
> > +int err = av_fifo_grow(fifo, sizeof(Fr
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Fri, May 28, 2021 at 4:49 AM Michael Niedermayer
wrote:
> On Thu, May 27, 2021 at 09:44:10AM -0700, Mohammad Izadi wrote:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> s
On Wed, May 26, 2021 at 9:17 PM James Zern
wrote:
> On Wed, May 26, 2021 at 6:35 PM Mohammad Izadi
> wrote:
> > [...]
> > +static void add_hdr10_plus(AVFifoBuffer *fifo, struct FrameHDR10Plus
> *data)
> > +{
> > +av_fifo_grow(fifo, sizeof(FrameHDR10Plus));
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
All done.
On Wed, May 26, 2021 at 2:42 PM Lynne wrote:
> May 26, 2021, 20:43 by izadi-at-google@ffmpeg.org:
>
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to packet side
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Tue, May 25, 2021 at 11:21 PM Moritz Barsnick wrote:
> On Tue, May 25, 2021 at 18:53:11 -0700, Mohammad Izadi wrote:
>
> > Subject: Pass the HDR10+ metadata to the packet side data in VP9 encoder
>
> You should prefix this with "avcodec: ".
>
Done
>
&
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
Answered inline:
On Tue, May 25, 2021 at 8:15 AM James Almer wrote:
> On 4/26/2021 10:54 PM, Mohammad Izadi wrote:
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be p
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
Any more comments or looks good to go?
Thanks,
Mohammad
On Mon, Apr 26, 2021 at 6:54 PM Mohammad Izadi wrote:
> HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream. HDR10+
> should be passed to packet
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
On Fri, Apr 23, 2021 at 11:53 AM James Zern
wrote:
> Hi,
>
> On Fri, Apr 23, 2021 at 8:58 AM Mohammad Izadi
> wrote:
> >
> > HDR10+ metadata is stored in the bit stream for HEVC. The story is
> different for VP9 and cannot store the metadata in the bit stream
HDR10+ metadata is stored in the bit stream for HEVC. The story is different
for VP9 and cannot store the metadata in the bit stream. HDR10+ should be
passed to packet side data an stored in the container (mkv) for VP9.
This CL is taking HDR10+ from AVFrame side data in libvpxenc and is passing
Ian, can you please take a look into it? And if it's fine to push it.
Thanks,
Mohammad
On Mon, Nov 23, 2020 at 1:29 PM Mohammad Izadi wrote:
> From: Mohammad Izadi
>
> HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to
> be decoded from ITU-T T.35 in HE
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
The fate test file can be found here:
https://drive.google.com/file/d
Thanks,
Mohammad
On Fri, Nov 20, 2020 at 5:44 AM Anton Khirnov wrote:
> Quoting Mohammad Izadi (2020-11-20 04:57:11)
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> to be decoded from ITU-T T.35 in H
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
The fate test file can be found here:
https://drive.google.com/file/d
On Sun, Nov 15, 2020 at 12:19 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Mohammad Izadi:
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> to be decoded from ITU-T T.35 in HEVC bitstr
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
The fate test file can be found here:
https://drive.google.com/file/d
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
The fate test file can be found here:
https://drive.google.com/file/d
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
The fate test file can be found here:
https://drive.google.com/file/d
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
The fate test file can be found here:
https://drive.google.com/file/d
Thank you Ian for your great detailed comments.
Thanks,
Mohammad
On Wed, Nov 11, 2020 at 5:10 PM Jan Ekström wrote:
> On 14.10.2020 2:53, Mohammad Izadi wrote:
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> to
Is anybody there? Any update? Can we push it to the head?
Thanks,
Mohammad
On Fri, Nov 6, 2020 at 9:42 PM Mohammad Izadi wrote:
> Any update? Can we push it to the head?
> Thanks,
> Mohammad
>
>
> On Mon, Oct 26, 2020 at 11:53 AM Mohammad Izadi wrote:
>
>> Than
Any update? Can we push it to the head?
Thanks,
Mohammad
On Mon, Oct 26, 2020 at 11:53 AM Mohammad Izadi wrote:
> Thank you, Jan! I hope you feel better soon.
>
>
>
> On Sun, Oct 25, 2020 at 5:49 PM Jan Ekström wrote:
>
>> On Wed, Oct 14, 2020 at 2:54 AM
Thank you, Jan! I hope you feel better soon.
On Sun, Oct 25, 2020 at 5:49 PM Jan Ekström wrote:
> On Wed, Oct 14, 2020 at 2:54 AM Mohammad Izadi
> wrote:
> >
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that need
Any comments?
Thanks,
Mohammad
On Tue, Oct 13, 2020 at 4:53 PM Mohammad Izadi wrote:
> From: Mohammad Izadi
>
> HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to
> be decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to
> side data pa
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
The fate test file can be found here:
https://drive.google.com/file/d
I will add the test by the end of this week.
Thanks,
Mohammad
On Mon, Sep 7, 2020 at 2:56 AM Jan Ekström wrote:
> On Sat, Jul 25, 2020 at 12:09 AM Mohammad Izadi
> wrote:
> >
> > On Fri, Jul 24, 2020 at 9:30 AM Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com
Vittorio,
What is the next step for me?
Thanks,
Mohammad
On Fri, Aug 7, 2020 at 9:51 AM Mohammad Izadi wrote:
> Any more comments? Are you OK to merge?
> Thanks,
> Mohammad
>
>
> On Thu, Jul 30, 2020 at 9:06 AM Vittorio Giovara <
> vittorio.giov...@gmail.com>
Any more comments? Are you OK to merge?
Thanks,
Mohammad
On Thu, Jul 30, 2020 at 9:06 AM Vittorio Giovara
wrote:
> On Mon, Jul 27, 2020 at 11:44 PM Mohammad Izadi <
> izadi-at-google@ffmpeg.org> wrote:
>
> > It seems FATE is for the regression test. Here is a samp
It seems FATE is for the regression test. Here is a sample that you can use
and check:
https://www.dropbox.com/s/3ewr2t2lvv2cy8d/20200727_143643.mp4?dl=0
Thanks,
Mohammad
On Mon, Jul 27, 2020 at 7:53 AM Vittorio Giovara
wrote:
> On Fri, Jul 24, 2020 at 11:09 PM Mohammad Izadi <
&
On Fri, Jul 24, 2020 at 9:30 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
> Mohammad Izadi:
> > From: Mohammad Izadi
> >
> > HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs
> to be decoded from ITU-T T.35 in HEVC bitstr
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec
,
Mohammad
On Thu, Jul 23, 2020 at 3:29 PM Mohammad Izadi wrote:
>
> Thanks,
> Mohammad
>
>
> On Thu, Jul 23, 2020 at 1:14 AM zhilizhao wrote:
>
>>
>>
>> > On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson <
>> steinar+ffm...@gunderson.no> wro
From: Mohammad Izadi
HDR10+ is dynamic metadata (A/341 Amendment - SMPTE2094-40) that needs to be
decoded from ITU-T T.35 in HEVC bitstream. The HDR10+ is transferred to side
data packet to be used or passed through.
---
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec
Thanks,
Mohammad
On Thu, Jul 23, 2020 at 1:14 AM zhilizhao wrote:
>
>
> > On Jul 17, 2020, at 5:47 AM, Steinar H. Gunderson <
> steinar+ffm...@gunderson.no> wrote:
> >
> > On Thu, Jul 16, 2020 at 06:34:31PM -0300, James Almer wrote:
> >>> static AVMutex codec_mutex = AV_MUTEX_INITIALIZER;
>
Please see my answers inline:
On Thu, Jul 16, 2020 at 2:34 PM James Almer wrote:
> On 7/16/2020 4:23 PM, Mohammad Izadi wrote:
> > From: Mohammad Izadi
> >
> > ---
> > libavcodec/avpacket.c | 1 +
> > libavcodec/decode.c | 1 +
> > libavcodec/hevc
Please see my answers inline:
On Thu, Jul 16, 2020 at 1:30 PM Carl Eugen Hoyos wrote:
> Am Do., 16. Juli 2020 um 21:24 Uhr schrieb Mohammad Izadi
> :
>
> > -user_identifier = get_bits_long(gb, 32);
> > -
> > -switch (user_identifier) {
> > -
From: Mohammad Izadi
---
libavcodec/avpacket.c | 1 +
libavcodec/decode.c | 1 +
libavcodec/hevc_sei.c | 40 +++---
libavcodec/hevc_sei.h | 5 ++
libavcodec/hevcdec.c | 7 ++
libavcodec/internal.h | 9 +++
libavcodec/packet.h | 9 +++
libavcodec/utils.c| 180
On Tue, Feb 25, 2020, 9:32 PM Vittorio Giovara
wrote:
> On Tue, Feb 25, 2020 at 9:16 PM Mohammad Izadi
> wrote:
>
> > On Mon, Feb 24, 2020 at 9:56 AM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Sat, Feb
On Mon, Feb 24, 2020 at 9:56 AM Vittorio Giovara
wrote:
> On Sat, Feb 22, 2020 at 12:44 PM Mohammad Izadi
> wrote:
>
> > On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara <
> vittorio.giov...@gmail.com
> > >
> > wrote:
> >
> > > On Fri,
On Fri, Feb 21, 2020, 6:44 PM Vittorio Giovara
wrote:
> On Fri, Feb 21, 2020 at 5:17 PM Mohammad Izadi
> wrote:
>
> > Why does the struct belong to lavu? This struct is super similar to
> structs
> > in libavcodec/hevc_sei.h. We just move it to a new file to share it
&g
PM Mohammad Izadi
> wrote:
> >
> > If you believe lavc is at the top of the hierarchy, I can simply move the
> > file to lavc. Then both lavc and lavf can use it and hierarchy is
> > respected. Can I do that? Doesn't break API? Any objection (with
> solution)?
> >
On Fri, Feb 21, 2020 at 2:53 AM Hendrik Leppkes wrote:
> On Fri, Feb 21, 2020 at 5:59 AM Vittorio Giovara
> wrote:
> >
> > On Thu, Feb 20, 2020 at 6:38 PM James Almer wrote:
> >
> > > On 2/20/2020 5:02 PM, Vittorio Giovara wrote:
> > > > O
On Thu, Feb 20, 2020 at 12:10 PM Vittorio Giovara <
vittorio.giov...@gmail.com> wrote:
> On Mon, Feb 10, 2020 at 3:14 PM Mohammad Izadi
> wrote:
>
> > From: Mohammad Izadi
> >
> > Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet s
On Wed, Feb 19, 2020 at 4:22 PM Mark Thompson wrote:
> On 10/02/2020 19:38, Mohammad Izadi wrote:
> > On Sun, Feb 9, 2020 at 8:31 AM Mark Thompson wrote:
> >
> >> On 07/02/2020 17:46, Mohammad Izadi wrote:
> >>> From: Mohammad Izadi
> >>>
&g
The comment was wrong.
--
Best,
Mohammad
On Wed, Feb 19, 2020 at 7:22 AM Derek Buitenhuis
wrote:
> On 10/02/2020 19:44, Mohammad Izadi wrote:
> > /**
> > * The nominal maximum display luminance of the targeted system
> display,
> > - * in units of 0.
Hello,
What's the status of the cl review? Is it good to submit?
--
Best,
Mohammad
On Mon, Feb 10, 2020 at 11:44 AM Mohammad Izadi wrote:
> From: Mohammad Izadi
>
> Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side
> data in the follow-up CLs.
> -
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 165 +++
libavutil/hdr_dynamic_metadata.h | 13 ++-
libavutil/version.h | 2 +-
3 files
On Sun, Feb 9, 2020 at 8:31 AM Mark Thompson wrote:
> On 07/02/2020 17:46, Mohammad Izadi wrote:
> > From: Mohammad Izadi
> >
> > Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side
> data in the follow-up CLs.
> > ---
> > li
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 165 +++
libavutil/hdr_dynamic_metadata.h | 12 ++-
libavutil/version.h | 2 +-
3 files
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 165 +++
libavutil/hdr_dynamic_metadata.h | 12 ++-
libavutil/version.h | 2 +-
3 files
Please check my responses inline:
On Wed, Feb 5, 2020 at 5:48 AM Moritz Barsnick wrote:
> Hi Mohammad,
>
> On Tue, Feb 04, 2020 at 18:44:00 -0800, Mohammad Izadi wrote:
> > --- a/libavutil/hdr_dynamic_metadata.c
> > +++ b/libavutil/hdr_dynamic_metada
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 167 ++-
libavutil/hdr_dynamic_metadata.h | 14 ++-
libavutil/version.h | 2 +-
3 files
Great! Thanks!
On Mon, Feb 3, 2020, 6:37 PM James Almer wrote:
> On 2/3/2020 11:01 PM, Mohammad Izadi wrote:
> > James, I am making another CL to comply with API.
> > I have a question about using GetBitContext and PutBitContext. Is there
> any
> > alternative to use i
James, I am making another CL to comply with API.
I have a question about using GetBitContext and PutBitContext. Is there any
alternative to use in libavutil?
--
Best,
Mohammad
On Mon, Jan 27, 2020 at 11:50 AM James Almer wrote:
> On 1/27/2020 4:08 PM, Mohammad Izadi wrote:
> > From:
wrote:
> Am Mo., 27. Jan. 2020 um 20:34 Uhr schrieb Mohammad Izadi <
> moh.iz...@gmail.com>:
>
> > /**
> > * Allocate an AVDynamicHDRPlus structure and set its fields to
> > * default values. The resulting struct can be freed using av_freep().
>
From: Mohammad Izadi
Trying to read HDR10+ metadata from HEVC/SEI and pass it to packet side data in
the follow-up CLs.
---
libavutil/hdr_dynamic_metadata.c | 386 +++
libavutil/hdr_dynamic_metadata.h | 51 +++-
libavutil/version.h | 2 +-
3 files
---
libavcodec/hevc_sei.c | 216 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 21
3 files changed, 237 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..15cd956e85 100644
---
---
libavcodec/hevc_sei.c | 216 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 21
3 files changed, 237 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..15cd956e85 100644
---
---
libavcodec/hevc_sei.c | 211 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 22 +
3 files changed, 233 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..6edec9f0db 100644
---
---
libavcodec/hevc_sei.c | 211 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 22 +
3 files changed, 233 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..265e3f4dd1 100644
---
t find it.
>
>
>
> --
> Best,
> Mohammad
>
>
> On Mon, Jan 7, 2019 at 5:19 PM James Almer wrote:
>
>> On 1/7/2019 8:55 PM, Mohammad Izadi wrote:
>> > ---
>> > libavcodec/hevc_sei.c | 236 --
>&
PM, Mohammad Izadi wrote:
> > ---
> > libavcodec/hevc_sei.c | 236 --
> > libavcodec/hevc_sei.h | 6 ++
> > libavcodec/hevcdec.c | 19
> > 3 files changed, 255 insertions(+), 6 deletions(-)
> >
> > di
---
libavcodec/hevc_sei.c | 236 --
libavcodec/hevc_sei.h | 6 ++
libavcodec/hevcdec.c | 19
3 files changed, 255 insertions(+), 6 deletions(-)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index c59bd4321e..7e59bf0813 100644
---
Thanks James.
--
Best,
Mohammad
On Fri, Jan 4, 2019 at 3:03 PM James Almer wrote:
> On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
> > On Fri, 4 Jan 2019 at 21:08, James Almer wrote:
> >
> >> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> >>> On Fri,
1 - 100 of 115 matches
Mail list logo
