Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway

[Baptiste Coudurier]

On Aug 27, 2022, at 4:30 AM, Tomas Härdin  wrote:
> 
> lör 2022-08-27 klockan 09:53 +0200 skrev Paul B Mahol:
>> On Sat, Aug 27, 2022 at 9:30 AM Tomas Härdin 
>> wrote:
>> 
>>> ons 2022-08-24 klockan 23:03 +0200 skrev Michael Niedermayer:
 Also we have regression tests, external libs make that impossible
 as the version of external libs can change the behavior. Again
 this
 is a issue for mxf maybe less so libxml. You can also see that we
 have no
 tests involving  any of the external encoder libs, for that very
 reason.
 With each external lib that is needed for core features this
 would
 become a quickly growing problem
>>> 
>>> Testing is certainly a challenge, but almost certainly easier than
>>> reimplementing certain formats and codecs poorly, especially MXF.
>>> 
>>> 
>> Than why you are so called maintainer of thing you do not want to
>> maintain?
> 
> Me maintaining mxfdec is precisely why I want to switch to bmx

I strongly oppose to that.
Didn’t we just merge IMF support ? That seems to indicate that people are fine 
with FFmpeg MXF implementation.

If the need arises, I will maintain the MXF code, I use it everyday after all :)

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/isom: allow ISO 639 codes for mov

[Baptiste Coudurier]

Hey Yongle,

> On Jul 7, 2020, at 10:41 AM, Yongle Lin  wrote:
> 
> On Mon, Jul 6, 2020 at 3:23 PM Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
> 
>> Hi Yongle, I hope you are doing well
>> 
>>> On Jul 6, 2020, at 11:04 AM, Yongle Lin  wrote:
>>> 
>>> On Fri, Jun 19, 2020 at 5:11 PM Yongle Lin > <mailto:yongle.lin...@gmail.com>> wrote:
>>> 
>>>> Allow ISO 639 language codes for text tracks in mov format when
>>>> strictness is set to experimental
>>>> ---
>>>> libavformat/isom.c | 9 +++--
>>>> libavformat/isom.h | 2 +-
>>>> libavformat/movenc.c   | 6 +++---
>>>> tests/fate/mov.mak | 3 +++
>>>> tests/ref/fate/mov-iso639-lang | 4 
>>>> 5 files changed, 18 insertions(+), 6 deletions(-)
>>>> create mode 100644 tests/ref/fate/mov-iso639-lang
>>>> 
>>>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>>>> index 44c7b13038..de20ea8d8b 100644
>>>> --- a/libavformat/isom.c
>>>> +++ b/libavformat/isom.c
>>>> @@ -416,7 +416,7 @@ static const char mov_mdhd_language_map[][4] = {
>>>>"cat", "lat", "que", "grn", "aym", "tat", "uig", "dzo", "jav"
>>>> };
>>>> 
>>>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>>>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>>>> strict_std_compliance)
>>>> {
>>>>int i, code = 0;
>>>> 
>>>> @@ -426,8 +426,13 @@ int ff_mov_iso639_to_lang(const char lang[4], int
>> mp4)
>>>>return i;
>>>>}
>>>>/* XXX:can we do that in mov too? */
>>>> -if (!mp4)
>>>> +if (!mp4 && (strict_std_compliance != FF_COMPLIANCE_EXPERIMENTAL ||
>>>> !strcmp(lang, "und"))) {
>>>> +if (strcmp(lang, "und"))
>>>> +av_log(NULL, AV_LOG_WARNING, "Non macintosh language is
>>>> discarded for mov\n");
>>>>return -1;
>>>> +}
>>>> +if (!mp4)
>>>> +av_log(NULL, AV_LOG_WARNING, "Experimental behavior: enable iso
>>>> 639 language in mov\n");
>>>>/* handle undefined as such */
>>>>if (lang[0] == '\0')
>>>>lang = "und";
>>>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>>>> index 41a9c64c11..9d018ebf1f 100644
>>>> --- a/libavformat/isom.h
>>>> +++ b/libavformat/isom.h
>>>> @@ -43,7 +43,7 @@ extern const AVCodecTag ff_codec_movaudio_tags[];
>>>> extern const AVCodecTag ff_codec_movsubtitle_tags[];
>>>> extern const AVCodecTag ff_codec_movdata_tags[];
>>>> 
>>>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4);
>>>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>>>> strict_std_compliance);
>>>> int ff_mov_lang_to_iso639(unsigned code, char to[4]);
>>>> 
>>>> struct AVAESCTR;
>>>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>>>> index 520aaafb74..4d7a98245e 100644
>>>> --- a/libavformat/movenc.c
>>>> +++ b/libavformat/movenc.c
>>>> @@ -3429,7 +3429,7 @@ static int mov_write_string_data_tag(AVIOContext
>>>> *pb, const char *data, int lang
>>>>return size;
>>>>} else {
>>>>if (!lang)
>>>> -lang = ff_mov_iso639_to_lang("und", 1);
>>>> +lang = ff_mov_iso639_to_lang("und", 1,
>> FF_COMPLIANCE_NORMAL);
>>>>avio_wb16(pb, strlen(data)); /* string length */
>>>>avio_wb16(pb, lang);
>>>>avio_write(pb, data, strlen(data));
>>>> @@ -3468,7 +3468,7 @@ static AVDictionaryEntry
>>>> *get_metadata_lang(AVFormatContext *s,
>>>>while ((t2 = av_dict_get(s->metadata, tag2, t2,
>>>> AV_DICT_IGNORE_SUFFIX))) {
>>>>len2 = strlen(t2->key);
>>>>if (len2 == len + 4 && !strcmp(t->value, t2->value)
>>>> -&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1)) >=
>> 0) {
>>>> +&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1,
>>>> s->strict_std_compliance)) >= 0) {
>

Re: [FFmpeg-devel] [PATCH] avformat/isom: allow ISO 639 codes for mov

[Baptiste Coudurier]

Hi Yongle, I hope you are doing well

> On Jul 6, 2020, at 11:04 AM, Yongle Lin  wrote:
> 
> On Fri, Jun 19, 2020 at 5:11 PM Yongle Lin  > wrote:
> 
>> Allow ISO 639 language codes for text tracks in mov format when
>> strictness is set to experimental
>> ---
>> libavformat/isom.c | 9 +++--
>> libavformat/isom.h | 2 +-
>> libavformat/movenc.c   | 6 +++---
>> tests/fate/mov.mak | 3 +++
>> tests/ref/fate/mov-iso639-lang | 4 
>> 5 files changed, 18 insertions(+), 6 deletions(-)
>> create mode 100644 tests/ref/fate/mov-iso639-lang
>> 
>> diff --git a/libavformat/isom.c b/libavformat/isom.c
>> index 44c7b13038..de20ea8d8b 100644
>> --- a/libavformat/isom.c
>> +++ b/libavformat/isom.c
>> @@ -416,7 +416,7 @@ static const char mov_mdhd_language_map[][4] = {
>> "cat", "lat", "que", "grn", "aym", "tat", "uig", "dzo", "jav"
>> };
>> 
>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>> strict_std_compliance)
>> {
>> int i, code = 0;
>> 
>> @@ -426,8 +426,13 @@ int ff_mov_iso639_to_lang(const char lang[4], int mp4)
>> return i;
>> }
>> /* XXX:can we do that in mov too? */
>> -if (!mp4)
>> +if (!mp4 && (strict_std_compliance != FF_COMPLIANCE_EXPERIMENTAL ||
>> !strcmp(lang, "und"))) {
>> +if (strcmp(lang, "und"))
>> +av_log(NULL, AV_LOG_WARNING, "Non macintosh language is
>> discarded for mov\n");
>> return -1;
>> +}
>> +if (!mp4)
>> +av_log(NULL, AV_LOG_WARNING, "Experimental behavior: enable iso
>> 639 language in mov\n");
>> /* handle undefined as such */
>> if (lang[0] == '\0')
>> lang = "und";
>> diff --git a/libavformat/isom.h b/libavformat/isom.h
>> index 41a9c64c11..9d018ebf1f 100644
>> --- a/libavformat/isom.h
>> +++ b/libavformat/isom.h
>> @@ -43,7 +43,7 @@ extern const AVCodecTag ff_codec_movaudio_tags[];
>> extern const AVCodecTag ff_codec_movsubtitle_tags[];
>> extern const AVCodecTag ff_codec_movdata_tags[];
>> 
>> -int ff_mov_iso639_to_lang(const char lang[4], int mp4);
>> +int ff_mov_iso639_to_lang(const char lang[4], int mp4, int
>> strict_std_compliance);
>> int ff_mov_lang_to_iso639(unsigned code, char to[4]);
>> 
>> struct AVAESCTR;
>> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
>> index 520aaafb74..4d7a98245e 100644
>> --- a/libavformat/movenc.c
>> +++ b/libavformat/movenc.c
>> @@ -3429,7 +3429,7 @@ static int mov_write_string_data_tag(AVIOContext
>> *pb, const char *data, int lang
>> return size;
>> } else {
>> if (!lang)
>> -lang = ff_mov_iso639_to_lang("und", 1);
>> +lang = ff_mov_iso639_to_lang("und", 1, FF_COMPLIANCE_NORMAL);
>> avio_wb16(pb, strlen(data)); /* string length */
>> avio_wb16(pb, lang);
>> avio_write(pb, data, strlen(data));
>> @@ -3468,7 +3468,7 @@ static AVDictionaryEntry
>> *get_metadata_lang(AVFormatContext *s,
>> while ((t2 = av_dict_get(s->metadata, tag2, t2,
>> AV_DICT_IGNORE_SUFFIX))) {
>> len2 = strlen(t2->key);
>> if (len2 == len + 4 && !strcmp(t->value, t2->value)
>> -&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1)) >= 0) {
>> +&& (l = ff_mov_iso639_to_lang(>key[len2 - 3], 1,
>> s->strict_std_compliance)) >= 0) {
>> *lang = l;
>> return t;
>> }
>> @@ -6445,7 +6445,7 @@ static int mov_init(AVFormatContext *s)
>> 
>> track->st  = st;
>> track->par = st->codecpar;
>> -track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
>> mov->mode!=MODE_MOV);
>> +track->language = ff_mov_iso639_to_lang(lang?lang->value:"und",
>> mov->mode!=MODE_MOV, s->strict_std_compliance);
>> if (track->language < 0)
>> track->language = 32767;  // Unspecified Macintosh language
>> code
>> track->mode = mov->mode;
>> diff --git a/tests/fate/mov.mak b/tests/fate/mov.mak
>> index 7a721d7c95..a85cc1a07d 100644
>> --- a/tests/fate/mov.mak
>> +++ b/tests/fate/mov.mak
>> @@ -29,6 +29,7 @@ FATE_MOV_FFPROBE = fate-mov-neg-firstpts-discard \
>>fate-mov-guess-delay-2 \
>>fate-mov-guess-delay-3 \
>>fate-mov-mp4-with-mov-in24-ver \
>> +   fate-mov-iso639-lang \
>> 
>> FATE_MOV_FASTSTART = fate-mov-faststart-4gb-overflow \
>> 
>> @@ -124,3 +125,5 @@ fate-mov-faststart-4gb-overflow: CMP = oneline
>> fate-mov-faststart-4gb-overflow: REF = bc875921f151871e787c4b4023269b29
>> 
>> fate-mov-mp4-with-mov-in24-ver: CMD = run ffprobe$(PROGSSUF)$(EXESUF)
>> -show_entries stream=codec_name -select_streams 1
>> $(TARGET_SAMPLES)/mov/mp4-with-mov-in24-ver.mp4
>> +
>> +fate-mov-iso639-lang: CMD = ffmpeg$(PROGSSUF)$(EXESUF) -f lavfi -i
>> sine=frequency=1000:duration=15 -strict experimental -metadata:s:a:0
>> language=deu -y $(TARGET_PATH)/metadata.mov; run ffprobe -show_entries

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

[Baptiste Coudurier]

> On Mar 3, 2020, at 11:37 AM, Tomas Härdin  wrote:
> 
> tis 2020-03-03 klockan 11:22 -0800 skrev Baptiste Coudurier:
>> Hey guys,
>> 
>> 
>>> On Mar 3, 2020, at 10:54 AM, Tomas Härdin  wrote:
>>> 
>>> mån 2020-03-02 klockan 21:35 +0100 skrev Marton Balint:
>>>> On Mon, 2 Mar 2020, Tomas Härdin wrote:
>>>> 
>>>>> fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
>>>>>> Signed-off-by: Marton Balint 
>>>>>> ---
>>>>>> libavformat/mxf.c| 44 
>>>>>> libavformat/mxf.h|  6 --
>>>>>> libavformat/mxfdec.c | 23 +++
>>>>>> libavformat/mxfenc.c | 24 ++--
>>>>>> 4 files changed, 13 insertions(+), 84 deletions(-)
>>>>>> int ff_mxf_get_content_package_rate(AVRational time_base)
>>>>>> {
>>>>>> -int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
>>>>>> -AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
>>>>>> -
>>>>>> -diff.num = FFABS(diff.num);
>>>>>> -
>>>>>> -if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
>>>>>> -return -1;
>>>>>> -
>>>>>> -return mxf_content_package_rates[idx];
>>>>>> +for (int i = 0; mxf_time_base[i].num; i++)
>>>>>> +if (!av_cmp_q(time_base, mxf_time_base[i]))
>>>>> 
>>>>> I see this gets rid of the inexact check for an exact one. Approve!
>>>>> 
>>>>>> @@ -3307,20 +3307,17 @@ static int 
>>>>>> mxf_get_next_track_edit_unit(MXFContext *mxf, MXFTrack *track, int64_
>>>>>> static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
>>>>>>int64_t edit_unit)
>>>>>> {
>>>>>> -int i, total = 0, size = 0;
>>>>>>MXFTrack *track = st->priv_data;
>>>>>>AVRational time_base = av_inv_q(track->edit_rate);
>>>>>>AVRational sample_rate = av_inv_q(st->time_base);
>>>>>> -const MXFSamplesPerFrame *spf = NULL;
>>>>>> -int64_t sample_count;
>>>>>> 
>>>>>>// For non-audio sample_count equals current edit unit
>>>>>>if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
>>>>>>return edit_unit;
>>>>>> 
>>>>>> -if ((sample_rate.num / sample_rate.den) == 48000)
>>>>>> -spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
>>>>>> -if (!spf) {
>>>>>> +if ((sample_rate.num / sample_rate.den) == 48000) {
>>>>>> +return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
>>>>> 
>>>>> Should be OK, per previous rounding argument
>>>>> 
>>>>>>}
>>>>>>sc->index = INDEX_D10_AUDIO;
>>>>>>sc->container_ul = 
>>>>>> ((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
>>>>>> -sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 
>>>>>> 4;
>>>>>> +sc->frame_size = 4 + 8 * av_rescale_rnd(st-
>>>>>>> codecpar->sample_rate, mxf->time_base.num, mxf->time_base.den,
>>>>>> AV_ROUND_UP) * 4;
>>>>> 
>>>>> I was going to say this is only used for CBR video, but closer
>>>>> inspection reveals it's used to prevent 1/1.001 rate audio packets from
>>>>> making their way into CBR files. This is a bit surprising to me, since
>>>>> D-10 supports NTSC (without audio?)
>>>> 
>>>> I thought D10 can only be CBR and and it can only use a constant edit unit 
>>>> size, 1/1.001 audio packet size difference is handled using KLV 
>>>> padding. So what we compute here is a _maximum_ frame size.
>>> 
>>> Now I remember: D-10 is indeed CBR, but at the MXF/CP level. To make it
>>> CBR you must pad the content packages with fill KLVs as necessary. This
>>> filling was actually removed by Baptiste a while back, and we had a set
>>> of patches attempting to fix support for NTSC but sadly the ratecontrol
>>&g

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

[Baptiste Coudurier]

Hey guys,


> On Mar 3, 2020, at 10:54 AM, Tomas Härdin  wrote:
> 
> mån 2020-03-02 klockan 21:35 +0100 skrev Marton Balint:
>> 
>> On Mon, 2 Mar 2020, Tomas Härdin wrote:
>> 
>>> fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
 Signed-off-by: Marton Balint 
 ---
 libavformat/mxf.c| 44 
 libavformat/mxf.h|  6 --
 libavformat/mxfdec.c | 23 +++
 libavformat/mxfenc.c | 24 ++--
 4 files changed, 13 insertions(+), 84 deletions(-)
 int ff_mxf_get_content_package_rate(AVRational time_base)
 {
 -int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
 -AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
 -
 -diff.num = FFABS(diff.num);
 -
 -if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
 -return -1;
 -
 -return mxf_content_package_rates[idx];
 +for (int i = 0; mxf_time_base[i].num; i++)
 +if (!av_cmp_q(time_base, mxf_time_base[i]))
>>> 
>>> I see this gets rid of the inexact check for an exact one. Approve!
>>> 
 @@ -3307,20 +3307,17 @@ static int mxf_get_next_track_edit_unit(MXFContext 
 *mxf, MXFTrack *track, int64_
 static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
 int64_t edit_unit)
 {
 -int i, total = 0, size = 0;
 MXFTrack *track = st->priv_data;
 AVRational time_base = av_inv_q(track->edit_rate);
 AVRational sample_rate = av_inv_q(st->time_base);
 -const MXFSamplesPerFrame *spf = NULL;
 -int64_t sample_count;
 
 // For non-audio sample_count equals current edit unit
 if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
 return edit_unit;
 
 -if ((sample_rate.num / sample_rate.den) == 48000)
 -spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
 -if (!spf) {
 +if ((sample_rate.num / sample_rate.den) == 48000) {
 +return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
>>> 
>>> Should be OK, per previous rounding argument
>>> 
 }
 sc->index = INDEX_D10_AUDIO;
 sc->container_ul = 
 ((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
 -sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 4;
 +sc->frame_size = 4 + 8 * av_rescale_rnd(st-
> codecpar->sample_rate, mxf->time_base.num, mxf->time_base.den,
 AV_ROUND_UP) * 4;
>>> 
>>> I was going to say this is only used for CBR video, but closer
>>> inspection reveals it's used to prevent 1/1.001 rate audio packets from
>>> making their way into CBR files. This is a bit surprising to me, since
>>> D-10 supports NTSC (without audio?)
>> 
>> I thought D10 can only be CBR and and it can only use a constant edit unit 
>> size, 1/1.001 audio packet size difference is handled using KLV 
>> padding. So what we compute here is a _maximum_ frame size.
> 
> Now I remember: D-10 is indeed CBR, but at the MXF/CP level. To make it
> CBR you must pad the content packages with fill KLVs as necessary. This
> filling was actually removed by Baptiste a while back, and we had a set
> of patches attempting to fix support for NTSC but sadly the ratecontrol
> in lavc is not up to snuff to support that for files longer than about
> an hour. This also means the video essence needs to be coded at a
> bitrate slightly lower than the D-10 rate, say 49.9 Mbps for 50 Mbps D-
> 10 (+-audio).

IIRC, and correct me if I’m wrong, the VBV delay in D-10 is actually fixed, 
so the essence needs to be CBR at the essence (mpeg-2) level.
Anything else is just broken IMHO.

> I believe at some point there was code for padding the MPEG-2 essence
> with zeroes to make CBR, but that obviously doesn't work with audio due
> to 1601.6 samples per EditUnit

Yeah, the pattern of audio samples is very strict in MXF, and every 5 frames, 
Audio and video durations match perfectly.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

[Baptiste Coudurier]

Hey Marton,

> On Mar 2, 2020, at 5:18 PM, Marton Balint  wrote:
> 
> 
> 
> On Mon, 2 Mar 2020, Baptiste Coudurier wrote:
> 
>> Hey guys,
>> 
>> 
>>> On Mar 2, 2020, at 12:57 PM, Marton Balint  wrote:
>>> On Mon, 2 Mar 2020, Tomas Härdin wrote:
>>>> fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
>>>>> On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
>>>>> > Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint 
>>>>> > :
>>>>> > > Fixes ticket #8523.
>>>>> > > > > Signed-off-by: Marton Balint 
>>>>> > > ---
>>>>> > >  libavformat/mxf.c | 13 +
>>>>> > >  1 file changed, 13 insertions(+)
>>>>> > > > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
>>>>> > > index 14056647c5..987410258a 100644
>>>>> > > --- a/libavformat/mxf.c
>>>>> > > +++ b/libavformat/mxf.c
>>>>> > > @@ -135,10 +135,23 @@ static const MXFContentPackageRate 
>>>>> > > mxf_content_package_rates[] = {
>>>>> > >  {  2, { 1,24} },
>>>>> > >  {  3, { 1001, 24000 } },
>>>>> > >  {  4, { 1,25} },
>>>>> > > +{  6, { 1,30} },
>>>>> > >  {  7, { 1001, 3 } },
>>>>> > > +{  8, { 1   , 48} },
>>>>> > > +{  9, { 1001, 48000 } },
>>>>> > >  { 10, { 1,50} },
>>>>> > >  { 12, { 1,60} },
>>>>> > >  { 13, { 1001, 6 } },
>>>>> > > +{ 14, { 1,72} },
>>>>> > > +{ 15, { 1001, 72000 } },
>>>>> > > +{ 16, { 1,75} },
>>>>> > > +{ 18, { 1,90} },
>>>>> > > +{ 19, { 1001, 9 } },
>>>>> > > +{ 20, { 1,96} },
>>>>> > > +{ 21, { 1001, 96000 } },
>>>>> > > +{ 22, { 1,100   } },
>>>>> > > +{ 24, { 1,120   } },
>>>>> > > +{ 25, { 1001, 12} },
>>>>> > > Are these still the only supported frame rates?
>>>>> These are the *package* rates that SMPTE 326M defines (technically it 
>>>>> defines the /1.001 version of 25, 50, 75 and 100 fps, but those are not 
>>>>> used).
>>>> For the record, this is section 7.2 Content package rate in SMPTE 326M-
>>>> 2000. What is not initially obvious is that mxf_content_package_rates-
>>>>> rate is bits b5..b0. A comment about this would be nice, I don't like
>>>> magical tables in the MXF codebase not being justified by references :)
>>>> You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
>>>> too. But it's probably wise not to do that.
>>> I am not sure, maybe we should add all possible values, even if they are 
>>> uncommon. After all I found out that for example 50/1.001 is actually 
>>> supported for mkvmerge:
>> 
>> It seems like if we were to do that, we would open the door to allowing 
>> essences that don’t support the package rate and we should definitely NOT do 
>> that.
> 
> I am not sure I understand, there are two different things to consider:
> 
> 1) support every frame rate which can be exactly represented by a package 
> rate as defined in SMPTE 326M, even uncommon ones like 50/1.001.
> 
> 2) support all frame rates and write 0 (undefined) as the package rate for 
> frame rates which cannot be exactly represented
> 
> You are voting against 2), right? 1) should not cause any "compatibility" 
> issues as far as I see.

I’m against 1 and 2 actually. We should only explicitly support rates and 
validate that we are creating files that are compatible with other equipment 
and software that support them officially.

— 
Baptiste


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

[Baptiste Coudurier]

Hey guys,


> On Mar 2, 2020, at 12:57 PM, Marton Balint  wrote:
> 
> 
> 
> On Mon, 2 Mar 2020, Tomas Härdin wrote:
> 
>> fre 2020-02-28 klockan 10:30 +0100 skrev Marton Balint:
>>> On Fri, 28 Feb 2020, Carl Eugen Hoyos wrote:
>>> > Am Fr., 28. Feb. 2020 um 01:38 Uhr schrieb Marton Balint :
>>> > > Fixes ticket #8523.
>>> > > > > Signed-off-by: Marton Balint 
>>> > > ---
>>> > >  libavformat/mxf.c | 13 +
>>> > >  1 file changed, 13 insertions(+)
>>> > > > > diff --git a/libavformat/mxf.c b/libavformat/mxf.c
>>> > > index 14056647c5..987410258a 100644
>>> > > --- a/libavformat/mxf.c
>>> > > +++ b/libavformat/mxf.c
>>> > > @@ -135,10 +135,23 @@ static const MXFContentPackageRate 
>>> > > mxf_content_package_rates[] = {
>>> > >  {  2, { 1,24} },
>>> > >  {  3, { 1001, 24000 } },
>>> > >  {  4, { 1,25} },
>>> > > +{  6, { 1,30} },
>>> > >  {  7, { 1001, 3 } },
>>> > > +{  8, { 1   , 48} },
>>> > > +{  9, { 1001, 48000 } },
>>> > >  { 10, { 1,50} },
>>> > >  { 12, { 1,60} },
>>> > >  { 13, { 1001, 6 } },
>>> > > +{ 14, { 1,72} },
>>> > > +{ 15, { 1001, 72000 } },
>>> > > +{ 16, { 1,75} },
>>> > > +{ 18, { 1,90} },
>>> > > +{ 19, { 1001, 9 } },
>>> > > +{ 20, { 1,96} },
>>> > > +{ 21, { 1001, 96000 } },
>>> > > +{ 22, { 1,100   } },
>>> > > +{ 24, { 1,120   } },
>>> > > +{ 25, { 1001, 12} },
>>> > > Are these still the only supported frame rates?
>>> These are the *package* rates that SMPTE 326M defines (technically it 
>>> defines the /1.001 version of 25, 50, 75 and 100 fps, but those are not 
>>> used).
>> 
>> For the record, this is section 7.2 Content package rate in SMPTE 326M-
>> 2000. What is not initially obvious is that mxf_content_package_rates-
>>> rate is bits b5..b0. A comment about this would be nice, I don't like
>> magical tables in the MXF codebase not being justified by references :)
>> 
>> You could technically have 25/1.001, 50/1.001, 75/1.001 and 100/1.001
>> too. But it's probably wise not to do that.
> 
> I am not sure, maybe we should add all possible values, even if they are 
> uncommon. After all I found out that for example 50/1.001 is actually 
> supported for mkvmerge:

It seems like if we were to do that, we would open the door to allowing 
essences that don’t support the package rate and we should definitely NOT do 
that.

— 
Baptiste


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Never set codec_ul UID to NULL

[Baptiste Coudurier]

Hi Andreas,

> On Mar 2, 2020, at 10:14 AM, Tomas Härdin  wrote:
> 
> fre 2020-02-28 klockan 05:14 +0100 skrev Andreas Rheinhardt:
>> mxf distinguishes codec profiles by different UIDs and therefore needs
>> to check that the input is actually compatible with mxf (i.e. if there
>> is a defined UID for it). If not, then sometimes the UID would be set to
>> NULL and writing the (video) packet would fail. Yet the following audio
>> packet would trigger writing the header (which has been postponed because
>> the UID is not known at the start) and if the UID is NULL, this can lead
>> to segfaults. This commit therefore stops setting the UID to NULL if the
>> input is incompatible with mxf (it has initially been set to a generic
>> value in mxf_write_header()).
>> 
>> Fixes #7993.
>> 
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> a) #7993 is actually a segfault even if its description suggests
>> otherwise.
>> b) My actually preferred way to fix this was to error out if an audio
>> packet is encountered and the header has not been written yet, thereby
>> ensuring that only a video packet can trigger writing the header and
>> said code is only reached when the video is actually compatible with mxf
>> (or with this muxer?). Yet I was surprised to find out that the
>> FATE-test mxf-d10-user-comments would fail with this, because right now
>> writing the header in this test is triggered by an audio packet (the
>> video packets aren't written because they are not of the right size) and
>> if these aren't written either, there will be zero bytes of output.

Yes, we need the video track before writing the header. It’s an issue and that’s
 what should be implemented IMHO.

— 
Baptiste


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dvdec: Use av_clip_uint8 instead of ff_crop_tab

[Baptiste Coudurier]

> On Nov 15, 2019, at 3:10 PM, Michael Niedermayer  
> wrote:
> 
> Fixes: out of array access
> Fixes: 
> 18788/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DVVIDEO_fuzzer-6254863113781248
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
> libavcodec/dvdec.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index 578d7f505f..c526091eb4 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -272,11 +272,10 @@ static inline void bit_copy(PutBitContext *pb, 
> GetBitContext *gb)
> static av_always_inline void put_block_8x4(int16_t *block, uint8_t 
> *av_restrict p, int stride)
> {
> int i, j;
> -const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
> 
> for (i = 0; i < 4; i++) {
> for (j = 0; j < 8; j++)
> -p[j] = cm[block[j]];
> +p[j] = av_clip_uint8(block[j]);
> block += 8;
> p += stride;
> }

LGTM

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dv ul handling

[Baptiste Coudurier]

> On Nov 11, 2019, at 4:07 PM, Baptiste Coudurier 
>  wrote:
> 
> ---
> libavformat/mxfenc.c | 128 ---
> 1 file changed, 46 insertions(+), 82 deletions(-)
> 

Will apply

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/dvenc: support muxing dvcprohd

[Baptiste Coudurier]

---
 libavformat/dvenc.c | 48 +
 1 file changed, 22 insertions(+), 26 deletions(-)

diff --git a/libavformat/dvenc.c b/libavformat/dvenc.c
index 93c103b316..a7d1413eb2 100644
--- a/libavformat/dvenc.c
+++ b/libavformat/dvenc.c
@@ -28,7 +28,6 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 #include 
-#include 
 
 #include "avformat.h"
 #include "internal.h"
@@ -48,8 +47,8 @@ struct DVMuxContext {
 AVClass  *av_class;
 const AVDVProfile*  sys;   /* current DV profile, e.g.: 525/60, 
625/50 */
 int   n_ast; /* number of stereo audio streams (up to 
2) */
-AVStream *ast[2];/* stereo audio streams */
-AVFifoBuffer *audio_data[2]; /* FIFO for storing excessive amounts of 
PCM */
+AVStream *ast[4];/* stereo audio streams */
+AVFifoBuffer *audio_data[4]; /* FIFO for storing excessive amounts of 
PCM */
 int   frames;/* current frame number */
 int64_t   start_time;/* recording start time */
 int   has_audio; /* frame under construction has audio */
@@ -87,14 +86,12 @@ static int dv_audio_frame_size(const AVDVProfile* sys, int 
frame, int sample_rat
 
sizeof(sys->audio_samples_dist[0]))];
 }
 
-static int dv_write_pack(enum dv_pack_type pack_id, DVMuxContext *c, uint8_t* 
buf, ...)
+static int dv_write_pack(enum dv_pack_type pack_id, DVMuxContext *c, uint8_t* 
buf, int channel, int seq)
 {
 struct tm tc;
 time_t ct;
 uint32_t timecode;
-va_list ap;
 int audio_type = 0;
-int channel;
 
 buf[0] = (uint8_t)pack_id;
 switch (pack_id) {
@@ -104,8 +101,6 @@ static int dv_write_pack(enum dv_pack_type pack_id, 
DVMuxContext *c, uint8_t* bu
 AV_WB32(buf + 1, timecode);
 break;
 case dv_audio_source:  /* AAUX source pack */
-va_start(ap, buf);
-channel = va_arg(ap, int);
 if (c->ast[channel]->codecpar->sample_rate == 44100) {
 audio_type = 1;
 } else if (c->ast[channel]->codecpar->sample_rate == 32000)
@@ -118,17 +113,16 @@ static int dv_write_pack(enum dv_pack_type pack_id, 
DVMuxContext *c, uint8_t* bu
 buf[2] = (0 << 7) | /* multi-stereo  */
  (0 << 5) | /* #of audio channels per block: 0 -- 1 channel */
  (0 << 4) | /* pair bit: 0 -- one pair of channels */
- !!va_arg(ap, int); /* audio mode*/
+ (seq >= c->sys->difseg_size/2); /* audio mode (1st or 2nd 
channel) */
 buf[3] = (1 << 7) | /* res   */
  (1 << 6) | /* multi-language flag */
  (c->sys->dsf << 5) | /*  system: 60fields/50fields */
- (c->sys->n_difchan & 2); /* definition: 0 -- 25Mbps, 2 -- 
50Mbps */
+ (DV_PROFILE_IS_HD(c->sys) ? 0x3 : c->sys->video_stype ? 2 : 
0); /* stype */
 buf[4] = (1 << 7) | /* emphasis: 1 -- off */
  (0 << 6) | /* emphasis time constant: 0 -- reserved */
  (audio_type << 3) | /* frequency: 0 -- 48kHz, 1 -- 44,1kHz, 2 
-- 32kHz */
   0;/* quantization: 0 -- 16-bit linear, 1 -- 12-bit 
nonlinear */
 
-va_end(ap);
 break;
 case dv_audio_control:
 buf[1] = (0 << 6) | /* copy protection: 0 -- unrestricted */
@@ -192,7 +186,7 @@ static void dv_inject_audio(DVMuxContext *c, int channel, 
uint8_t* frame_ptr)
 for (i = 0; i < c->sys->difseg_size; i++) {
 frame_ptr += 6 * 80; /* skip DIF segment header */
 for (j = 0; j < 9; j++) {
-dv_write_pack(dv_aaux_packs_dist[i][j], c, _ptr[3], channel, 
i >= c->sys->difseg_size/2);
+dv_write_pack(dv_aaux_packs_dist[i][j], c, _ptr[3], channel, 
i);
 for (d = 8; d < 80; d+=2) {
 of = c->sys->audio_shuffle[i][j] + (d - 8)/2 * 
c->sys->audio_stride;
 if (of*2 >= size)
@@ -210,27 +204,28 @@ static void dv_inject_metadata(DVMuxContext *c, uint8_t* 
frame)
 {
 int j, k;
 uint8_t* buf;
+int seq = 0;
 
-for (buf = frame; buf < frame + c->sys->frame_size; buf += 150 * 80) {
+for (buf = frame; buf < frame + c->sys->frame_size; buf += 150 * 80, 
seq++) {
 /* DV subcode: 2nd and 3d DIFs */
 for (j = 80; j < 80 * 3; j += 80) {
 for (k = 6; k < 6 * 8; k += 8)
-dv_write_pack(dv_timecode, c, [j+k]);
+dv_write_pack(dv_timecode, c, [j+k], 0, seq);
 
 if 
(((long)(buf-frame)/(c->sys->frame_size/(c->sys->difseg_size*c->sys->n_difchan))%c->sys->difseg_size)
 > 5) { /* FIXME: is this really needed ? */
-dv_write_pack(dv_video_recdate, c, [j+14]);
-dv_write_pack(dv_video_rectime, c, [j+22]);
-dv_write_pack(dv_video_recdate, c, [j+38]);
-

Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

> On Nov 12, 2019, at 1:13 PM, Baptiste Coudurier 
>  wrote:
> 
>> 
>> On Nov 9, 2019, at 4:11 PM, Baptiste Coudurier 
>>  wrote:
>> 
>> ---
>> libavcodec/dv.h |   1 +
>> libavcodec/dvenc.c  | 561 
>> tests/fate/vcodec.mak   |  14 +-
>> tests/ref/vsynth/vsynth1-dv-fhd |   4 +
>> tests/ref/vsynth/vsynth1-dv-hd  |   4 +
>> tests/ref/vsynth/vsynth2-dv-fhd |   4 +
>> tests/ref/vsynth/vsynth2-dv-hd  |   4 +
>> tests/ref/vsynth/vsynth3-dv-fhd |   4 +
>> tests/ref/vsynth/vsynth3-dv-hd  |   4 +
>> 9 files changed, 541 insertions(+), 59 deletions(-)
>> create mode 100644 tests/ref/vsynth/vsynth1-dv-fhd
>> create mode 100644 tests/ref/vsynth/vsynth1-dv-hd
>> create mode 100644 tests/ref/vsynth/vsynth2-dv-fhd
>> create mode 100644 tests/ref/vsynth/vsynth2-dv-hd
>> create mode 100644 tests/ref/vsynth/vsynth3-dv-fhd
>> create mode 100644 tests/ref/vsynth/vsynth3-dv-hd
>> 
> 
> Will apply
> 

Applied

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: correctly set width values for dvcprohd

[Baptiste Coudurier]

> On Nov 12, 2019, at 1:14 PM, Baptiste Coudurier 
>  wrote:
> 
>> 
>> On Nov 11, 2019, at 3:30 PM, Tomas Härdin > <mailto:tjop...@acc.umu.se>> wrote:
>> 
>> lör 2019-11-09 klockan 15:46 -0800 skrev Baptiste Coudurier:
>>> ---
>>> libavformat/mxfenc.c | 15 ---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> index b7ae5cc637..f7df9c3daf 100644
>>> --- a/libavformat/mxfenc.c
>>> +++ b/libavformat/mxfenc.c
>>> @@ -1092,7 +1092,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>>> *s, AVStream *st, const UID
>>> {
>>> MXFStreamContext *sc = st->priv_data;
>>> AVIOContext *pb = s->pb;
>>> -int stored_width  = (st->codecpar->width +15)/16*16;
>>> +int stored_width = 0;
>>> int stored_height = (st->codecpar->height+15)/16*16;
>>> int display_height;
>>> int f1, f2;
>>> @@ -1101,6 +1101,15 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>>> *s, AVStream *st, const UID
>>> 
>>> get_trc(transfer_ul, st->codecpar->color_trc);
>>> 
>>> +if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO) {
>>> +if (st->codecpar->height == 1080)
>>> +stored_width = 1920;
>>> +else if (st->codecpar->height == 720)
>>> +stored_width = 1280;
>> 
>> What about the other DV variants?
> 
> These get default value
> 
>>> +}
>>> +if (!stored_width)
>>> +stored_width = (st->codecpar->width+15)/16*16;
>> 
>> Shouldn't this have SAR applied?
> 
> I didn’t change this, the code was like that before
> 

Applied

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: correctly set width values for dvcprohd

[Baptiste Coudurier]

> On Nov 11, 2019, at 3:52 PM, Baptiste Coudurier 
>  wrote:
> 
> 
>> On Nov 11, 2019, at 3:30 PM, Tomas Härdin > <mailto:tjop...@acc.umu.se>> wrote:
>> 
>> lör 2019-11-09 klockan 15:46 -0800 skrev Baptiste Coudurier:
>>> ---
>>> libavformat/mxfenc.c | 15 ---
>>> 1 file changed, 12 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>> index b7ae5cc637..f7df9c3daf 100644
>>> --- a/libavformat/mxfenc.c
>>> +++ b/libavformat/mxfenc.c
>>> @@ -1092,7 +1092,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>>> *s, AVStream *st, const UID
>>> {
>>> MXFStreamContext *sc = st->priv_data;
>>> AVIOContext *pb = s->pb;
>>> -int stored_width  = (st->codecpar->width +15)/16*16;
>>> +int stored_width = 0;
>>> int stored_height = (st->codecpar->height+15)/16*16;
>>> int display_height;
>>> int f1, f2;
>>> @@ -1101,6 +1101,15 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>>> *s, AVStream *st, const UID
>>> 
>>> get_trc(transfer_ul, st->codecpar->color_trc);
>>> 
>>> +if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO) {
>>> +if (st->codecpar->height == 1080)
>>> +stored_width = 1920;
>>> +else if (st->codecpar->height == 720)
>>> +stored_width = 1280;
>> 
>> What about the other DV variants?
> 
> These get default value
> 
>>> +}
>>> +if (!stored_width)
>>> +stored_width = (st->codecpar->width+15)/16*16;
>> 
>> Shouldn't this have SAR applied?
> 
> I didn’t change this, the code was like that before
> 

Will apply

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: simplify d-10 ul handling

[Baptiste Coudurier]

> On Nov 9, 2019, at 3:46 PM, Baptiste Coudurier  
> wrote:
> 
> ---
> libavformat/mxfenc.c | 110 ---
> 1 file changed, 41 insertions(+), 69 deletions(-)
> 

Will apply

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

> On Nov 9, 2019, at 4:11 PM, Baptiste Coudurier  
> wrote:
> 
> ---
> libavcodec/dv.h |   1 +
> libavcodec/dvenc.c  | 561 
> tests/fate/vcodec.mak   |  14 +-
> tests/ref/vsynth/vsynth1-dv-fhd |   4 +
> tests/ref/vsynth/vsynth1-dv-hd  |   4 +
> tests/ref/vsynth/vsynth2-dv-fhd |   4 +
> tests/ref/vsynth/vsynth2-dv-hd  |   4 +
> tests/ref/vsynth/vsynth3-dv-fhd |   4 +
> tests/ref/vsynth/vsynth3-dv-hd  |   4 +
> 9 files changed, 541 insertions(+), 59 deletions(-)
> create mode 100644 tests/ref/vsynth/vsynth1-dv-fhd
> create mode 100644 tests/ref/vsynth/vsynth1-dv-hd
> create mode 100644 tests/ref/vsynth/vsynth2-dv-fhd
> create mode 100644 tests/ref/vsynth/vsynth2-dv-hd
> create mode 100644 tests/ref/vsynth/vsynth3-dv-fhd
> create mode 100644 tests/ref/vsynth/vsynth3-dv-hd
> 

Will apply

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dv ul handling

[Baptiste Coudurier]

Hi Thomas,

> On Nov 11, 2019, at 3:17 PM, Tomas Härdin  wrote:
> 
> lör 2019-11-09 klockan 15:46 -0800 skrev Baptiste Coudurier:
>> +static const UID mxf_dv_container_uls[] = {
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x01,0x01
>>  }, // IEC DV25 525/60
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x02,0x01
>>  }, // IEC DV25 626/50
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x40,0x01
>>  }, // DV25 525/60
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x41,0x01
>>  }, // DV25 625/50
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x50,0x01
>>  }, // DV50 525/60
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x51,0x01
>>  }, // DV50 625/50
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x60,0x01
>>  }, // DV100 1080/60
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x61,0x01
>>  }, // DV100 1080/50
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x62,0x01
>>  }, // DV100 720/60
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x63,0x01
>>  }, // DV100 720/50
>> +};
>> +
>> +static const UID mxf_dv_codec_uls[] = {
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x01,0x01,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x01,0x02,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x01,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x02,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x03,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x04,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x05,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x06,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x07,0x00
>>  },
>> +{ 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x08,0x00
>>  },
>> +};
> 
> Maybe a struct to keep these two together, or a comment saying they
> correspond to eachother 1:1
> 
>> static int mxf_parse_dv_frame(AVFormatContext *s, AVStream *st, AVPacket 
>> *pkt)
>> {
>> MXFContext *mxf = s->priv_data;
>> MXFStreamContext *sc = st->priv_data;
>> uint8_t *vs_pack, *vsc_pack;
>> +int apt = pkt->data[4] & 0x7;
> 
> Can pkt->data ever be less than 5 bytes?
> 
>> @@ -2182,28 +2144,29 @@ static int mxf_parse_dv_frame(AVFormatContext *s, 
>> AVStream *st, AVPacket *pkt)
>> 
>> switch (stype) {
>> case 0x18: // DV100 720p
>> -ul_index = INDEX_DV100_720_50 + pal;
>> +ul_index = 8+pal;
> 
> Not a huge fan of magic constants. Maybe just move the INDEX_DV* enums
> to their own enum? Could use array index initializers to enforce that
> they're indeed in the right spots in mxf_dv_*_uls[]. Combined with the
> struct suggestion:
> 
> static const struct {
> UID container_ul, codec_ul;
> } dv_uls[] = {
> [INDEX_DV25_525_60] = 
> {{0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x01,0x01},
>
> {0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x01,0x01,0x00}},
> //...
> };

That would defeat the purpose of the patch, getting rid of the useless 
constants :)

— 
Baptiste


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: correctly set width values for dvcprohd

[Baptiste Coudurier]

> On Nov 11, 2019, at 3:30 PM, Tomas Härdin  wrote:
> 
> lör 2019-11-09 klockan 15:46 -0800 skrev Baptiste Coudurier:
>> ---
>> libavformat/mxfenc.c | 15 ---
>> 1 file changed, 12 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index b7ae5cc637..f7df9c3daf 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -1092,7 +1092,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>> *s, AVStream *st, const UID
>> {
>> MXFStreamContext *sc = st->priv_data;
>> AVIOContext *pb = s->pb;
>> -int stored_width  = (st->codecpar->width +15)/16*16;
>> +int stored_width = 0;
>> int stored_height = (st->codecpar->height+15)/16*16;
>> int display_height;
>> int f1, f2;
>> @@ -1101,6 +1101,15 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>> *s, AVStream *st, const UID
>> 
>> get_trc(transfer_ul, st->codecpar->color_trc);
>> 
>> +if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO) {
>> +if (st->codecpar->height == 1080)
>> +stored_width = 1920;
>> +else if (st->codecpar->height == 720)
>> +stored_width = 1280;
> 
> What about the other DV variants?

These get default value

>> +}
>> +if (!stored_width)
>> +stored_width = (st->codecpar->width+15)/16*16;
> 
> Shouldn't this have SAR applied?

I didn’t change this, the code was like that before

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dv ul handling

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 128 ---
 1 file changed, 46 insertions(+), 82 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index aa23ee3947..5e987488f6 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -83,6 +83,7 @@ typedef struct MXFStreamContext {
 UID track_essence_element_key;
 int index;   ///< index in mxf_essence_container_uls table
 const UID *codec_ul;
+const UID *container_ul;
 int order;   ///< interleaving order if dts are equal
 int interlaced;  ///< whether picture is interlaced
 int field_dominance; ///< tff=1, bff=2
@@ -135,16 +136,6 @@ enum ULIndex {
 INDEX_D10_525_60_30_VIDEO,
 INDEX_D10_525_60_30_AUDIO,
 INDEX_DV,
-INDEX_DV25_525_60,
-INDEX_DV25_625_50,
-INDEX_DV25_525_60_IEC,
-INDEX_DV25_625_50_IEC,
-INDEX_DV50_525_60,
-INDEX_DV50_625_50,
-INDEX_DV100_1080_60,
-INDEX_DV100_1080_50,
-INDEX_DV100_720_60,
-INDEX_DV100_720_50,
 INDEX_DNXHD,
 INDEX_JPEG2000,
 INDEX_H264,
@@ -242,64 +233,11 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
   mxf_write_generic_sound_desc },
-// DV Unknown
+// DV
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x7F,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00 
},
   mxf_write_cdci_desc },
-
-// DV25 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x40,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x01,0x00 
},
-  mxf_write_cdci_desc },
-// DV25 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x41,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x02,0x00 
},
-  mxf_write_cdci_desc },
-
-// IEC DV25 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x01,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x01,0x00 
},
-  mxf_write_cdci_desc },
-// IEC DV25 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x02,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x01,0x02,0x00 
},
-  mxf_write_cdci_desc },
-
-  // DV50 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x50,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x03,0x00 
},
-  mxf_write_cdci_desc },
-// DV50 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x51,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x04,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 1080/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x60,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x05,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 1080/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x61,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x06,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 720/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x62,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x07,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 720/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x63,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 

Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

Hi Michael,

> On Nov 6, 2019, at 11:02 AM, Michael Niedermayer  
> wrote:
> 
> On Wed, Nov 06, 2019 at 08:54:50AM -0800, Baptiste Coudurier wrote:
>> Hey Michael,
>> 
>>> On Nov 4, 2019, at 12:43 PM, Michael Niedermayer  
>>> wrote:
>>> 
>>> On Sat, Nov 02, 2019 at 12:06:19PM -0700, Baptiste Coudurier wrote:
>>>> ---
>>>> libavcodec/dv.h   |   1 +
>>>> libavcodec/dvenc.c| 555 +-
>>> 
>>>> tests/fate/vcodec.mak |  14 +-
>>> 
>>> here are the corresponding ref files i get:
>>> they are the same on x86-64/32, mingw 32/64 arm & mips (qemu)
>>> 
>>> new file mode 100644
>>> index 00..b81141f340
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth1-dv-fhd
>>> @@ -0,0 +1,4 @@
>>> +74315a8678d12c7f592c02990dc8952d *tests/data/fate/vsynth1-dv-fhd.dv
>>> +2880 tests/data/fate/vsynth1-dv-fhd.dv
>>> +c95b309bc128b162e5c8241374eb66a9 
>>> *tests/data/fate/vsynth1-dv-fhd.out.rawvideo
>>> +stddev:2.53 PSNR: 40.03 MAXDIFF:   35 bytes:  7603200/  7603200
>>> diff --git a/tests/ref/vsynth/vsynth1-dv-hd b/tests/ref/vsynth/vsynth1-dv-hd
>>> new file mode 100644
>>> index 00..c964b083b3
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth1-dv-hd
>>> @@ -0,0 +1,4 @@
>>> +12c07ee20aa824dc0ed589336647b195 *tests/data/fate/vsynth1-dv-hd.dv
>>> +1440 tests/data/fate/vsynth1-dv-hd.dv
>>> +dbeb55cfe3ed47d25cbe4e0b45d9bb00 
>>> *tests/data/fate/vsynth1-dv-hd.out.rawvideo
>>> +stddev:   53.33 PSNR: 13.59 MAXDIFF:  238 bytes:  7603200/  7603200
>>> diff --git a/tests/ref/vsynth/vsynth2-dv-fhd 
>>> b/tests/ref/vsynth/vsynth2-dv-fhd
>>> new file mode 100644
>>> index 00..948bf2269f
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth2-dv-fhd
>>> @@ -0,0 +1,4 @@
>>> +1f96ce7c1a5f09ec9d30c51c7271cf77 *tests/data/fate/vsynth2-dv-fhd.dv
>>> +2880 tests/data/fate/vsynth2-dv-fhd.dv
>>> +cff30e2430730522bf67c6d94cf1352e 
>>> *tests/data/fate/vsynth2-dv-fhd.out.rawvideo
>>> +stddev:1.16 PSNR: 46.82 MAXDIFF:   21 bytes:  7603200/  7603200
>>> diff --git a/tests/ref/vsynth/vsynth2-dv-hd b/tests/ref/vsynth/vsynth2-dv-hd
>>> new file mode 100644
>>> index 00..2dce36b94b
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth2-dv-hd
>>> @@ -0,0 +1,4 @@
>>> +095db978dd76f36d5706c96f6dac65bd *tests/data/fate/vsynth2-dv-hd.dv
>>> +1440 tests/data/fate/vsynth2-dv-hd.dv
>>> +a1c690626f90e0c79b1247ee560540ef 
>>> *tests/data/fate/vsynth2-dv-hd.out.rawvideo
>>> +stddev:   79.63 PSNR: 10.11 MAXDIFF:  240 bytes:  7603200/  7603200
>>> diff --git a/tests/ref/vsynth/vsynth3-dv-fhd 
>>> b/tests/ref/vsynth/vsynth3-dv-fhd
>>> new file mode 100644
>>> index 00..08ca9ef889
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth3-dv-fhd
>>> @@ -0,0 +1,4 @@
>>> +5b8b7f1dc31d7076af891e94c2e88c06 *tests/data/fate/vsynth3-dv-fhd.dv
>>> +2880 tests/data/fate/vsynth3-dv-fhd.dv
>>> +a038ad7c3c09f776304ef7accdea9c74 
>>> *tests/data/fate/vsynth3-dv-fhd.out.rawvideo
>>> +stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:86700/86700
>>> diff --git a/tests/ref/vsynth/vsynth3-dv-hd b/tests/ref/vsynth/vsynth3-dv-hd
>>> new file mode 100644
>>> index 00..a42f4b4bb3
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth3-dv-hd
>>> @@ -0,0 +1,4 @@
>>> +c05f2a66f9a5090e016d24373c657fd2 *tests/data/fate/vsynth3-dv-hd.dv
>>> +1440 tests/data/fate/vsynth3-dv-hd.dv
>>> +938db8c6ca3bc2d2a64d0f481960efd3 
>>> *tests/data/fate/vsynth3-dv-hd.out.rawvideo
>>> +stddev:   62.24 PSNR: 12.25 MAXDIFF:  218 bytes:86700/86700
>>> diff --git a/tests/ref/vsynth/vsynth_lena-dv-fhd 
>>> b/tests/ref/vsynth/vsynth_lena-dv-fhd
>>> new file mode 100644
>>> index 00..51a4505011
>>> --- /dev/null
>>> +++ b/tests/ref/vsynth/vsynth_lena-dv-fhd
>>> @@ -0,0 +1,4 @@
>>> +3a33e512f8b3f4213477c98d4e7e2559 *tests/data/fate/vsynth_lena-dv-fhd.dv
>>> +2880 tests/data/fate/vsynth_lena-dv-fhd.dv
>>> +b97e0a057202359ef93f2ec0b9fdfec4 
>>> *tests/data/fate/vsynth_lena-dv-fhd.out.rawvideo
>>> +stddev:1.03 PSNR: 47.80 MAXDIFF:   14 bytes:  7603200/  7603200
>>> diff --git a/tests/ref/vsynth/vsynth_lena-dv-hd 
&

[FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

---
 libavcodec/dv.h |   1 +
 libavcodec/dvenc.c  | 561 
 tests/fate/vcodec.mak   |  14 +-
 tests/ref/vsynth/vsynth1-dv-fhd |   4 +
 tests/ref/vsynth/vsynth1-dv-hd  |   4 +
 tests/ref/vsynth/vsynth2-dv-fhd |   4 +
 tests/ref/vsynth/vsynth2-dv-hd  |   4 +
 tests/ref/vsynth/vsynth3-dv-fhd |   4 +
 tests/ref/vsynth/vsynth3-dv-hd  |   4 +
 9 files changed, 541 insertions(+), 59 deletions(-)
 create mode 100644 tests/ref/vsynth/vsynth1-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth1-dv-hd
 create mode 100644 tests/ref/vsynth/vsynth2-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth2-dv-hd
 create mode 100644 tests/ref/vsynth/vsynth3-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth3-dv-hd

diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 7ef5b7c552..0205d72347 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -83,6 +83,7 @@ enum dv_pack_type {
 
 #define DV_PROFILE_IS_HD(p) ((p)->video_stype & 0x10)
 #define DV_PROFILE_IS_1080i50(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
1))
+#define DV_PROFILE_IS_1080i60(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
0))
 #define DV_PROFILE_IS_720p50(p)  (((p)->video_stype == 0x18) && ((p)->dsf == 
1))
 
 /**
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..dca57feb4f 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -60,10 +60,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 ff_dv_print_profiles(avctx, AV_LOG_ERROR);
 return AVERROR(EINVAL);
 }
-if (avctx->height > 576) {
-av_log(avctx, AV_LOG_ERROR, "DVCPRO HD encoding is not supported.\n");
-return AVERROR_PATCHWELCOME;
-}
+
 ret = ff_dv_init_dynamic_tables(s, s->sys);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
@@ -90,6 +87,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 }
 
 /* bit budget for AC only in 5 MBs */
+static const int vs_total_ac_bits_hd = (68 * 6 + 52*2) * 5;
 static const int vs_total_ac_bits = (100 * 4 + 68 * 2) * 5;
 static const int mb_area_start[5] = { 1, 6, 21, 43, 64 };
 
@@ -158,6 +156,11 @@ typedef struct EncBlockInfo {
 uint8_t  sign[64];
 uint8_t  partial_bit_count;
 uint32_t partial_bit_buffer; /* we can't use uint16_t here */
+/* used by DV100 only: a copy of the weighted and classified but
+   not-yet-quantized AC coefficients. This is necessary for
+   re-quantizing at different steps. */
+int16_t  save[64];
+int  min_qlevel; /* DV100 only: minimum qlevel (for AC coefficients 
>255) */
 } EncBlockInfo;
 
 static av_always_inline PutBitContext *dv_encode_ac(EncBlockInfo *bi,
@@ -243,13 +246,123 @@ static const int dv_weight_248[64] = {
 170627, 170627, 153560, 153560, 165371, 165371, 144651, 144651,
 };
 
-static av_always_inline int dv_init_enc_block(EncBlockInfo *bi, uint8_t *data,
-  ptrdiff_t linesize,
-  DVVideoContext *s, int bias)
+/* setting this to 1 results in a faster codec but
+ * somewhat lower image quality */
+#define DV100_SACRIFICE_QUALITY_FOR_SPEED 1
+#define DV100_ENABLE_FINER 1
+
+/* pack combination of QNO and CNO into a single 8-bit value */
+#define DV100_MAKE_QLEVEL(qno,cno) ((qno<<2) | (cno))
+#define DV100_QLEVEL_QNO(qlevel) (qlevel>>2)
+#define DV100_QLEVEL_CNO(qlevel) (qlevel&0x3)
+
+#define DV100_NUM_QLEVELS 31
+
+/* The quantization step is determined by a combination of QNO and
+   CNO. We refer to these combinations as "qlevels" (this term is our
+   own, it's not mentioned in the spec). We use CNO, a multiplier on
+   the quantization step, to "fill in the gaps" between quantization
+   steps associated with successive values of QNO. e.g. there is no
+   QNO for a quantization step of 10, but we can use QNO=5 CNO=1 to
+   get the same result. The table below encodes combinations of QNO
+   and CNO in order of increasing quantization coarseness. */
+static const uint8_t dv100_qlevels[DV100_NUM_QLEVELS] = {
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 2,0), //  2*1= 2
+DV100_MAKE_QLEVEL( 3,0), //  3*1= 3
+DV100_MAKE_QLEVEL( 4,0), //  4*1= 4
+DV100_MAKE_QLEVEL( 5,0), //  5*1= 5
+DV100_MAKE_QLEVEL( 6,0), //  6*1= 6
+DV100_MAKE_QLEVEL( 7,0), //  7*1= 7
+DV100_MAKE_QLEVEL( 8,0), //  8*1= 8
+DV100_MAKE_QLEVEL( 5,1), //  5*2=10
+DV100_MAKE_QLEVEL( 6,1), //  6*2=12
+DV100_MAKE_QLEVEL( 7,1), //  7*2=14
+DV100_MAKE_QLEVEL( 9,0), // 16*1=16
+DV100_MAKE_QLEVEL(10,0), // 18*1=18
+DV100_MAKE_QLEVEL(11,0), // 20*1=20
+DV100_MAKE_QLEVEL(12,0), // 22*1=22
+DV100_MAKE_QLEVEL(13,0), // 24*1=24
+DV100_MAKE_QLEVEL(14,0), // 28*1=28
+DV100_MAKE_QLEVEL( 9,1), // 16*2=32
+DV100_MAKE_QLEVEL(10,1), // 18*2=36
+DV100_MAKE_QLEVEL(11,1), // 20*2=40
+DV100_MAKE_QLEVEL(12,1), // 

[FFmpeg-devel] [PATCH] avformat/mxfenc: correctly set width values for dvcprohd

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index b7ae5cc637..f7df9c3daf 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1092,7 +1092,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 {
 MXFStreamContext *sc = st->priv_data;
 AVIOContext *pb = s->pb;
-int stored_width  = (st->codecpar->width +15)/16*16;
+int stored_width = 0;
 int stored_height = (st->codecpar->height+15)/16*16;
 int display_height;
 int f1, f2;
@@ -1101,6 +1101,15 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 
 get_trc(transfer_ul, st->codecpar->color_trc);
 
+if (st->codecpar->codec_id == AV_CODEC_ID_DVVIDEO) {
+if (st->codecpar->height == 1080)
+stored_width = 1920;
+else if (st->codecpar->height == 720)
+stored_width = 1280;
+}
+if (!stored_width)
+stored_width = (st->codecpar->width+15)/16*16;
+
 mxf_write_local_tag(pb, 4, 0x3203);
 avio_wb32(pb, stored_width);
 
@@ -1123,7 +1132,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 
 //Sampled width
 mxf_write_local_tag(pb, 4, 0x3205);
-avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, stored_width);
 
 //Samples height
 mxf_write_local_tag(pb, 4, 0x3204);
@@ -1138,7 +1147,7 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 avio_wb32(pb, 0);
 
 mxf_write_local_tag(pb, 4, 0x3209);
-avio_wb32(pb, st->codecpar->width);
+avio_wb32(pb, stored_width);
 
 if (st->codecpar->height == 608) // PAL + VBI
 display_height = 576;
-- 
2.21.0 (Apple Git-122)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: simplify d-10 ul handling

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 110 ---
 1 file changed, 41 insertions(+), 69 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 122d336fc3..b7ae5cc637 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -123,18 +123,8 @@ enum ULIndex {
 INDEX_MPEG2 = 0,
 INDEX_AES3,
 INDEX_WAV,
-INDEX_D10_625_50_50_VIDEO,
-INDEX_D10_625_50_50_AUDIO,
-INDEX_D10_525_60_50_VIDEO,
-INDEX_D10_525_60_50_AUDIO,
-INDEX_D10_625_50_40_VIDEO,
-INDEX_D10_625_50_40_AUDIO,
-INDEX_D10_525_60_40_VIDEO,
-INDEX_D10_525_60_40_AUDIO,
-INDEX_D10_625_50_30_VIDEO,
-INDEX_D10_625_50_30_AUDIO,
-INDEX_D10_525_60_30_VIDEO,
-INDEX_D10_525_60_30_AUDIO,
+INDEX_D10_VIDEO,
+INDEX_D10_AUDIO,
 INDEX_DV,
 INDEX_DNXHD,
 INDEX_JPEG2000,
@@ -179,60 +169,16 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x16,0x01,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
   mxf_write_wav_desc },
-// D-10 625/50 PAL 50mb/s
+// D-10 Video
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x01,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x01 
},
   mxf_write_cdci_desc },
+// D-10 Audio
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x01,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
   mxf_write_generic_sound_desc },
-// D-10 525/60 NTSC 50mb/s
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x02,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x02 
},
-  mxf_write_cdci_desc },
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x02,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
-  mxf_write_generic_sound_desc },
-// D-10 625/50 PAL 40mb/s
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x03,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x03 
},
-  mxf_write_cdci_desc },
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x03,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
-  mxf_write_generic_sound_desc },
-// D-10 525/60 NTSC 40mb/s
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x04,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x04 
},
-  mxf_write_cdci_desc },
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x04,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
-  mxf_write_generic_sound_desc },
-// D-10 625/50 PAL 30mb/s
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x05,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x05 
},
-  mxf_write_cdci_desc },
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x05,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
-  mxf_write_generic_sound_desc },
-// D-10 525/60 NTSC 30mb/s
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x06,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x05,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x01,0x02,0x01,0x06 
},
-  mxf_write_cdci_desc },
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x06,0x01 
},
-  { 

[FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dv ul handling

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 126 ---
 1 file changed, 45 insertions(+), 81 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index aa23ee3947..122d336fc3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -83,6 +83,7 @@ typedef struct MXFStreamContext {
 UID track_essence_element_key;
 int index;   ///< index in mxf_essence_container_uls table
 const UID *codec_ul;
+const UID *container_ul;
 int order;   ///< interleaving order if dts are equal
 int interlaced;  ///< whether picture is interlaced
 int field_dominance; ///< tff=1, bff=2
@@ -135,16 +136,6 @@ enum ULIndex {
 INDEX_D10_525_60_30_VIDEO,
 INDEX_D10_525_60_30_AUDIO,
 INDEX_DV,
-INDEX_DV25_525_60,
-INDEX_DV25_625_50,
-INDEX_DV25_525_60_IEC,
-INDEX_DV25_625_50_IEC,
-INDEX_DV50_525_60,
-INDEX_DV50_625_50,
-INDEX_DV100_1080_60,
-INDEX_DV100_1080_50,
-INDEX_DV100_720_60,
-INDEX_DV100_720_50,
 INDEX_DNXHD,
 INDEX_JPEG2000,
 INDEX_H264,
@@ -242,64 +233,11 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x06,0x01,0x10,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00 
},
   mxf_write_generic_sound_desc },
-// DV Unknown
+// DV
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x7F,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x00,0x00,0x00 
},
   mxf_write_cdci_desc },
-
-// DV25 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x40,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x01,0x00 
},
-  mxf_write_cdci_desc },
-// DV25 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x41,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x02,0x00 
},
-  mxf_write_cdci_desc },
-
-// IEC DV25 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x01,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x01,0x00 
},
-  mxf_write_cdci_desc },
-// IEC DV25 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x02,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x01,0x02,0x00 
},
-  mxf_write_cdci_desc },
-
-  // DV50 525/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x50,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x03,0x00 
},
-  mxf_write_cdci_desc },
-// DV50 625/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x51,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x04,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 1080/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x60,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x05,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 1080/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x61,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x06,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 720/60
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x62,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x07,0x00 
},
-  mxf_write_cdci_desc },
-// DV100 720/50
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x02,0x63,0x01 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
-  { 

Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

Hey Michael,

> On Nov 4, 2019, at 12:43 PM, Michael Niedermayer  
> wrote:
> 
> On Sat, Nov 02, 2019 at 12:06:19PM -0700, Baptiste Coudurier wrote:
>> ---
>> libavcodec/dv.h   |   1 +
>> libavcodec/dvenc.c| 555 +-
> 
>> tests/fate/vcodec.mak |  14 +-
> 
> here are the corresponding ref files i get:
> they are the same on x86-64/32, mingw 32/64 arm & mips (qemu)
> 
> new file mode 100644
> index 00..b81141f340
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth1-dv-fhd
> @@ -0,0 +1,4 @@
> +74315a8678d12c7f592c02990dc8952d *tests/data/fate/vsynth1-dv-fhd.dv
> +2880 tests/data/fate/vsynth1-dv-fhd.dv
> +c95b309bc128b162e5c8241374eb66a9 *tests/data/fate/vsynth1-dv-fhd.out.rawvideo
> +stddev:2.53 PSNR: 40.03 MAXDIFF:   35 bytes:  7603200/  7603200
> diff --git a/tests/ref/vsynth/vsynth1-dv-hd b/tests/ref/vsynth/vsynth1-dv-hd
> new file mode 100644
> index 00..c964b083b3
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth1-dv-hd
> @@ -0,0 +1,4 @@
> +12c07ee20aa824dc0ed589336647b195 *tests/data/fate/vsynth1-dv-hd.dv
> +1440 tests/data/fate/vsynth1-dv-hd.dv
> +dbeb55cfe3ed47d25cbe4e0b45d9bb00 *tests/data/fate/vsynth1-dv-hd.out.rawvideo
> +stddev:   53.33 PSNR: 13.59 MAXDIFF:  238 bytes:  7603200/  7603200
> diff --git a/tests/ref/vsynth/vsynth2-dv-fhd b/tests/ref/vsynth/vsynth2-dv-fhd
> new file mode 100644
> index 00..948bf2269f
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth2-dv-fhd
> @@ -0,0 +1,4 @@
> +1f96ce7c1a5f09ec9d30c51c7271cf77 *tests/data/fate/vsynth2-dv-fhd.dv
> +2880 tests/data/fate/vsynth2-dv-fhd.dv
> +cff30e2430730522bf67c6d94cf1352e *tests/data/fate/vsynth2-dv-fhd.out.rawvideo
> +stddev:1.16 PSNR: 46.82 MAXDIFF:   21 bytes:  7603200/  7603200
> diff --git a/tests/ref/vsynth/vsynth2-dv-hd b/tests/ref/vsynth/vsynth2-dv-hd
> new file mode 100644
> index 00..2dce36b94b
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth2-dv-hd
> @@ -0,0 +1,4 @@
> +095db978dd76f36d5706c96f6dac65bd *tests/data/fate/vsynth2-dv-hd.dv
> +1440 tests/data/fate/vsynth2-dv-hd.dv
> +a1c690626f90e0c79b1247ee560540ef *tests/data/fate/vsynth2-dv-hd.out.rawvideo
> +stddev:   79.63 PSNR: 10.11 MAXDIFF:  240 bytes:  7603200/  7603200
> diff --git a/tests/ref/vsynth/vsynth3-dv-fhd b/tests/ref/vsynth/vsynth3-dv-fhd
> new file mode 100644
> index 00..08ca9ef889
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth3-dv-fhd
> @@ -0,0 +1,4 @@
> +5b8b7f1dc31d7076af891e94c2e88c06 *tests/data/fate/vsynth3-dv-fhd.dv
> +2880 tests/data/fate/vsynth3-dv-fhd.dv
> +a038ad7c3c09f776304ef7accdea9c74 *tests/data/fate/vsynth3-dv-fhd.out.rawvideo
> +stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:86700/86700
> diff --git a/tests/ref/vsynth/vsynth3-dv-hd b/tests/ref/vsynth/vsynth3-dv-hd
> new file mode 100644
> index 00..a42f4b4bb3
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth3-dv-hd
> @@ -0,0 +1,4 @@
> +c05f2a66f9a5090e016d24373c657fd2 *tests/data/fate/vsynth3-dv-hd.dv
> +1440 tests/data/fate/vsynth3-dv-hd.dv
> +938db8c6ca3bc2d2a64d0f481960efd3 *tests/data/fate/vsynth3-dv-hd.out.rawvideo
> +stddev:   62.24 PSNR: 12.25 MAXDIFF:  218 bytes:86700/86700
> diff --git a/tests/ref/vsynth/vsynth_lena-dv-fhd 
> b/tests/ref/vsynth/vsynth_lena-dv-fhd
> new file mode 100644
> index 00..51a4505011
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth_lena-dv-fhd
> @@ -0,0 +1,4 @@
> +3a33e512f8b3f4213477c98d4e7e2559 *tests/data/fate/vsynth_lena-dv-fhd.dv
> +2880 tests/data/fate/vsynth_lena-dv-fhd.dv
> +b97e0a057202359ef93f2ec0b9fdfec4 
> *tests/data/fate/vsynth_lena-dv-fhd.out.rawvideo
> +stddev:1.03 PSNR: 47.80 MAXDIFF:   14 bytes:  7603200/  7603200
> diff --git a/tests/ref/vsynth/vsynth_lena-dv-hd 
> b/tests/ref/vsynth/vsynth_lena-dv-hd
> new file mode 100644
> index 00..c682c9eb2c
> --- /dev/null
> +++ b/tests/ref/vsynth/vsynth_lena-dv-hd
> @@ -0,0 +1,4 @@
> +4f289998e497e473a1522006bc6b3b74 *tests/data/fate/vsynth_lena-dv-hd.dv
> +1440 tests/data/fate/vsynth_lena-dv-hd.dv
> +96e4669d6941c4366e6f599d77061d97 
> *tests/data/fate/vsynth_lena-dv-hd.out.rawvideo
> +stddev:   54.07 PSNR: 13.47 MAXDIFF:  199 bytes:  7603200/  7603200

Thanks! I actually merged the muxer change in the same patch so that we don’t 
create bad .dv files with HD.
Let me know if that’s fine.
I found a workaround for compilation on macOS Catalina finally so I added the 
fate ref files.

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff

[Baptiste Coudurier]

> On Nov 2, 2019, at 12:00 PM, Baptiste Coudurier 
>  wrote:
> 
> On Wed, Sep 11, 2019 at 1:29 PM Baptiste Coudurier 
> mailto:baptiste.coudur...@gmail.com>> wrote:
> Hey Carl,
> 
>> On Sep 11, 2019, at 12:38 PM, Carl Eugen Hoyos > <mailto:ceffm...@gmail.com>> wrote:
>> 
>> Am Mi., 11. Sept. 2019 um 21:31 Uhr schrieb Baptiste Coudurier
>> mailto:baptiste.coudur...@gmail.com>>:
>>> 
>>> ---
>>> libavcodec/dvdec.c | 13 ++---
>>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>> 
>>> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
>>> index 4345cd9e29..cfa0fb9905 100644
>>> --- a/libavcodec/dvdec.c
>>> +++ b/libavcodec/dvdec.c
>>> @@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext 
>>> *avctx, void *data,
>>> 
>>> if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
>>> return ret;
>>> -frame.f->interlaced_frame = 1;
>>> -frame.f->top_field_first  = 0;
>>> 
>>> /* Determine the codec's field order from the packet */
>>> if ( *vsc_pack == dv_video_control ) {
>>> -frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>>> +if (avctx->height == 720) {
>>> +frame.f->interlaced_frame = 0;
>>> +frame.f->top_field_first = 0;
>>> +} else if (avctx->height == 1080) {
>>> +frame.f->interlaced_frame = 1;
>>> +frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
>>> +} else {
>>> +frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
>>> +frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>> 
>> Does this fix ticket #5092?
> Will apply

Applied

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding and muxing dvcprohd

[Baptiste Coudurier]

---
 libavcodec/dv.h |   1 +
 libavcodec/dvenc.c  | 555 
 libavformat/dvenc.c |  48 ++-
 tests/fate/vcodec.mak   |  14 +-
 tests/ref/vsynth/vsynth1-dv-fhd |   4 +
 tests/ref/vsynth/vsynth1-dv-hd  |   4 +
 tests/ref/vsynth/vsynth2-dv-fhd |   4 +
 tests/ref/vsynth/vsynth2-dv-hd  |   4 +
 tests/ref/vsynth/vsynth3-dv-fhd |   4 +
 tests/ref/vsynth/vsynth3-dv-hd  |   4 +
 10 files changed, 560 insertions(+), 82 deletions(-)
 create mode 100644 tests/ref/vsynth/vsynth1-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth1-dv-hd
 create mode 100644 tests/ref/vsynth/vsynth2-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth2-dv-hd
 create mode 100644 tests/ref/vsynth/vsynth3-dv-fhd
 create mode 100644 tests/ref/vsynth/vsynth3-dv-hd

diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 7ef5b7c552..0205d72347 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -83,6 +83,7 @@ enum dv_pack_type {
 
 #define DV_PROFILE_IS_HD(p) ((p)->video_stype & 0x10)
 #define DV_PROFILE_IS_1080i50(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
1))
+#define DV_PROFILE_IS_1080i60(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
0))
 #define DV_PROFILE_IS_720p50(p)  (((p)->video_stype == 0x18) && ((p)->dsf == 
1))
 
 /**
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..3afeb5ebb8 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -60,10 +60,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 ff_dv_print_profiles(avctx, AV_LOG_ERROR);
 return AVERROR(EINVAL);
 }
-if (avctx->height > 576) {
-av_log(avctx, AV_LOG_ERROR, "DVCPRO HD encoding is not supported.\n");
-return AVERROR_PATCHWELCOME;
-}
+
 ret = ff_dv_init_dynamic_tables(s, s->sys);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
@@ -90,6 +87,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 }
 
 /* bit budget for AC only in 5 MBs */
+static const int vs_total_ac_bits_hd = (68 * 6 + 52*2) * 5;
 static const int vs_total_ac_bits = (100 * 4 + 68 * 2) * 5;
 static const int mb_area_start[5] = { 1, 6, 21, 43, 64 };
 
@@ -158,6 +156,11 @@ typedef struct EncBlockInfo {
 uint8_t  sign[64];
 uint8_t  partial_bit_count;
 uint32_t partial_bit_buffer; /* we can't use uint16_t here */
+/* used by DV100 only: a copy of the weighted and classified but
+   not-yet-quantized AC coefficients. This is necessary for
+   re-quantizing at different steps. */
+int16_t  save[64];
+int  min_qlevel; /* DV100 only: minimum qlevel (for AC coefficients 
>255) */
 } EncBlockInfo;
 
 static av_always_inline PutBitContext *dv_encode_ac(EncBlockInfo *bi,
@@ -243,13 +246,123 @@ static const int dv_weight_248[64] = {
 170627, 170627, 153560, 153560, 165371, 165371, 144651, 144651,
 };
 
-static av_always_inline int dv_init_enc_block(EncBlockInfo *bi, uint8_t *data,
-  ptrdiff_t linesize,
-  DVVideoContext *s, int bias)
+/* setting this to 1 results in a faster codec but
+ * somewhat lower image quality */
+#define DV100_SACRIFICE_QUALITY_FOR_SPEED 1
+#define DV100_ENABLE_FINER 1
+
+/* pack combination of QNO and CNO into a single 8-bit value */
+#define DV100_MAKE_QLEVEL(qno,cno) ((qno<<2) | (cno))
+#define DV100_QLEVEL_QNO(qlevel) (qlevel>>2)
+#define DV100_QLEVEL_CNO(qlevel) (qlevel&0x3)
+
+#define DV100_NUM_QLEVELS 31
+
+/* The quantization step is determined by a combination of QNO and
+   CNO. We refer to these combinations as "qlevels" (this term is our
+   own, it's not mentioned in the spec). We use CNO, a multiplier on
+   the quantization step, to "fill in the gaps" between quantization
+   steps associated with successive values of QNO. e.g. there is no
+   QNO for a quantization step of 10, but we can use QNO=5 CNO=1 to
+   get the same result. The table below encodes combinations of QNO
+   and CNO in order of increasing quantization coarseness. */
+static const uint8_t dv100_qlevels[DV100_NUM_QLEVELS] = {
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 2,0), //  2*1= 2
+DV100_MAKE_QLEVEL( 3,0), //  3*1= 3
+DV100_MAKE_QLEVEL( 4,0), //  4*1= 4
+DV100_MAKE_QLEVEL( 5,0), //  5*1= 5
+DV100_MAKE_QLEVEL( 6,0), //  6*1= 6
+DV100_MAKE_QLEVEL( 7,0), //  7*1= 7
+DV100_MAKE_QLEVEL( 8,0), //  8*1= 8
+DV100_MAKE_QLEVEL( 5,1), //  5*2=10
+DV100_MAKE_QLEVEL( 6,1), //  6*2=12
+DV100_MAKE_QLEVEL( 7,1), //  7*2=14
+DV100_MAKE_QLEVEL( 9,0), // 16*1=16
+DV100_MAKE_QLEVEL(10,0), // 18*1=18
+DV100_MAKE_QLEVEL(11,0), // 20*1=20
+DV100_MAKE_QLEVEL(12,0), // 22*1=22
+DV100_MAKE_QLEVEL(13,0), // 24*1=24
+DV100_MAKE_QLEVEL(14,0), // 28*1=28
+DV100_MAKE_QLEVEL( 9,1), // 16*2=32
+DV100_MAKE_QLEVEL(10,1), // 18*2=36
+DV100_MAKE_QLEVEL(11,1), 

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly decode bottom mb row in 1080i field mode

[Baptiste Coudurier]

> On Nov 2, 2019, at 11:07 PM, Carl Eugen Hoyos  wrote:
> 
> Am Sa., 2. Nov. 2019 um 20:02 Uhr schrieb Baptiste Coudurier
> :
>> 
>> On Wed, Sep 11, 2019 at 12:29 PM Baptiste Coudurier <
>> baptiste.coudur...@gmail.com> wrote:
>> 
>>> ---
>>> libavcodec/dv.h|  2 ++
>>> libavcodec/dvdec.c | 90 +++---
>>> 2 files changed, 72 insertions(+), 20 deletions(-)
>>> 
>>> diff --git a/libavcodec/dv.h b/libavcodec/dv.h
>>> index 0e97bb200e..7ef5b7c552 100644
>>> --- a/libavcodec/dv.h
>>> +++ b/libavcodec/dv.h
>>> @@ -31,6 +31,7 @@
>>> #include "dv_profile.h"
>>> #include "me_cmp.h"
>>> #include "vlc.h"
>>> +#include "idctdsp.h"
>>> 
>>> typedef struct DVwork_chunk {
>>> uint16_t buf_offset;
>>> @@ -52,6 +53,7 @@ typedef struct DVVideoContext {
>>> me_cmp_func ildct_cmp;
>>> DVwork_chunk work_chunks[4 * 12 * 27];
>>> uint32_t idct_factor[2 * 4 * 16 * 64];
>>> +IDCTDSPContext idsp;
>>> 
>>> int quant_deadzone;
>>> } DVVideoContext;
>>> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
>>> index 89864f2edc..4345cd9e29 100644
>>> --- a/libavcodec/dvdec.c
>>> +++ b/libavcodec/dvdec.c
>>> @@ -45,7 +45,6 @@
>>> #include "dv_profile_internal.h"
>>> #include "dvdata.h"
>>> #include "get_bits.h"
>>> -#include "idctdsp.h"
>>> #include "internal.h"
>>> #include "put_bits.h"
>>> #include "simple_idct.h"
>>> @@ -177,24 +176,22 @@ static void dv_init_weight_tables(DVVideoContext
>>> *ctx, const AVDVProfile *d)
>>> static av_cold int dvvideo_decode_init(AVCodecContext *avctx)
>>> {
>>> DVVideoContext *s = avctx->priv_data;
>>> -IDCTDSPContext idsp;
>>> int i;
>>> 
>>> -memset(,0, sizeof(idsp));
>>> -ff_idctdsp_init(, avctx);
>>> +ff_idctdsp_init(>idsp, avctx);
>>> 
>>> for (i = 0; i < 64; i++)
>>> -s->dv_zigzag[0][i] = idsp.idct_permutation[ff_zigzag_direct[i]];
>>> +s->dv_zigzag[0][i] =
>>> s->idsp.idct_permutation[ff_zigzag_direct[i]];
>>> 
>>> if (avctx->lowres){
>>> for (i = 0; i < 64; i++){
>>> int j = ff_dv_zigzag248_direct[i];
>>> -s->dv_zigzag[1][i] = idsp.idct_permutation[(j & 7) + (j & 8)
>>> * 4 + (j & 48) / 2];
>>> +s->dv_zigzag[1][i] = s->idsp.idct_permutation[(j & 7) + (j &
>>> 8) * 4 + (j & 48) / 2];
>>> }
>>> }else
>>> memcpy(s->dv_zigzag[1], ff_dv_zigzag248_direct,
>>> sizeof(s->dv_zigzag[1]));
>>> 
>>> -s->idct_put[0] = idsp.idct_put;
>>> +s->idct_put[0] = s->idsp.idct_put;
>>> s->idct_put[1] = ff_simple_idct248_put;
>>> 
>>> return ff_dvvideo_init(avctx);
>>> @@ -272,6 +269,49 @@ static inline void bit_copy(PutBitContext *pb,
>>> GetBitContext *gb)
>>> put_bits(pb, bits_left, get_bits(gb, bits_left));
>>> }
>>> 
>>> +static av_always_inline void put_block_8x4(int16_t *block, uint8_t
>>> *restrict p, int stride)
>>> +{
>>> +int i, j;
>>> +const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
>>> +
>>> +for (i = 0; i < 4; i++) {
>>> +for (j = 0; j < 8; j++)
>>> +p[j] = cm[block[j]];
>>> +block += 8;
>>> +p += stride;
>>> +}
>>> +}
>>> +
>>> +static void dv100_idct_put_last_row_field_chroma(DVVideoContext *s,
>>> uint8_t *data,
>>> + int stride, int16_t
>>> *blocks)
>>> +{
>>> +s->idsp.idct(blocks + 0*64);
>>> +s->idsp.idct(blocks + 1*64);
>>> +
>>> +put_block_8x4(blocks+0*64,   data,  stride<<1);
>>> +put_block_8x4(blocks+0*64 + 4*8, data + 8,  stride<<1);
>>> +put_block_8x4(blocks+1*64,   data + stride, stride<<1);
>>> +put_block_8x4(blocks+1*64 + 4*8, data + 8 + stride, stride<<1);
>>> +}
>>> +
>>> +static void dv100_idct_put_last_row_field_luma(DVVideoContext *s, uint8_t
>

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff

[Baptiste Coudurier]

On Wed, Sep 11, 2019 at 1:29 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> Hey Carl,
>
> On Sep 11, 2019, at 12:38 PM, Carl Eugen Hoyos  wrote:
>
> Am Mi., 11. Sept. 2019 um 21:31 Uhr schrieb Baptiste Coudurier
> :
>
>
> ---
> libavcodec/dvdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index 4345cd9e29..cfa0fb9905 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext
> *avctx, void *data,
>
> if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
> return ret;
> -frame.f->interlaced_frame = 1;
> -frame.f->top_field_first  = 0;
>
> /* Determine the codec's field order from the packet */
> if ( *vsc_pack == dv_video_control ) {
> -frame.f->top_field_first = !(vsc_pack[3] & 0x40);
> +if (avctx->height == 720) {
> +frame.f->interlaced_frame = 0;
> +frame.f->top_field_first = 0;
> +} else if (avctx->height == 1080) {
> +frame.f->interlaced_frame = 1;
> +frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
> +} else {
> +frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
> +frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>
>
> Does this fix ticket #5092?
>
> Will apply
>
> —
> Baptiste Coudurier
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

On Thu, Sep 19, 2019 at 12:34 PM Michael Niedermayer 
wrote:

> On Wed, Sep 11, 2019 at 12:29:57PM -0700, Baptiste Coudurier wrote:
> > ---
> >  libavcodec/dv.h|   1 +
> >  libavcodec/dvenc.c | 576 -
> >  2 files changed, 522 insertions(+), 55 deletions(-)
>
> a fate test should be added for this if its not already planed or done
>

I'm having issues with fate on macOS catalina right now :(


> [...]
>


> > +/* LOOP1: weigh AC components and store to save[] */
> > +/* (i=0 is the DC component; we only include it to make the
> > +   number of loop iterations even, for future possible SIMD
> optimization) */
> > +for (i = 0; i < 64; i += 2) {
> > +int level0, level1;
> > +
> > +/* get the AC component (in zig-zag order) */
> > +level0 = blk[zigzag_scan[i+0]];
> > +level1 = blk[zigzag_scan[i+1]];
> > +
> > +/* extract sign and make it the lowest bit */
> > +bi->sign[i+0] = (level0>>31)&1;
> > +bi->sign[i+1] = (level1>>31)&1;
> > +
> > +/* take absolute value of the level */
> > +level0 = FFABS(level0);
> > +level1 = FFABS(level1);
> > +
> > +/* weigh it */
> > +level0 = (level0*weight[i+0] + 4096 + (1<<17)) >> 18;
> > +level1 = (level1*weight[i+1] + 4096 + (1<<17)) >> 18;
> > +
> > +/* save unquantized value */
> > +bi->save[i+0] = level0;
> > +bi->save[i+1] = level1;
> > +}
> > +
> > +/* find max component */
> > +for (i = 0; i < 64; i++) {
> > +int ac = bi->save[i];
> > +if (ac > max)
> > +max = ac;
> > +}
>
> these 2 loops can be merged avoiding a 2nd pass
>

Merged

[...]
> > +static inline void dv_guess_qnos_hd(EncBlockInfo *blks, int *qnos)
> > +{
> > +EncBlockInfo *b;
> > +int min_qlevel[5];
> > +int qlevels[5];
> > +int size[5];
> > +int i, j;
> > +/* cache block sizes at hypothetical qlevels */
> > +uint16_t size_cache[5*8][DV100_NUM_QLEVELS] = {{0}};
> > +
> > +/* get minimum qlevels */
> > +for (i = 0; i < 5; i++) {
> > +min_qlevel[i] = 1;
> > +for (j = 0; j < 8; j++) {
> > +if (blks[8*i+j].min_qlevel > min_qlevel[i])
> > +min_qlevel[i] = blks[8*i+j].min_qlevel;
> > +}
> > +}
> > +
> > +/* initialize sizes */
> > +for (i = 0; i < 5; i++) {
> > +qlevels[i] = dv100_starting_qno;
> > +if (qlevels[i] < min_qlevel[i])
> > +qlevels[i] = min_qlevel[i];
> > +
> > +qnos[i] = DV100_QLEVEL_QNO(dv100_qlevels[qlevels[i]]);
> > +size[i] = 0;
> > +for (j = 0; j < 8; j++) {
> > +size_cache[8*i+j][qlevels[i]] =
> dv100_actual_quantize([8*i+j], qlevels[i]);
> > +size[i] += size_cache[8*i+j][qlevels[i]];
> > +}
> > +}
> > +
> > +/* must we go coarser? */
> > +if (size[0]+size[1]+size[2]+size[3]+size[4] > vs_total_ac_bits_hd) {
> > +int largest = size[0] % 5; /* 'random' number */
> > +
>
> > +do {
> > +/* find the macroblock with the lowest qlevel */
> > +for (i = 0; i < 5; i++) {
> > +if (qlevels[i] < DV100_NUM_QLEVELS-1 &&
> > +qlevels[i] < qlevels[largest])
> > +largest = i;
> > +}
> > +
> > +i = largest;
> > +/* ensure that we don't enter infinite loop */
> > +largest = (largest+1) % 5;
> > +
> > +if (qlevels[i] >= DV100_NUM_QLEVELS-1) {
> > +/* can't quantize any more */
> > +continue;
> > +}
> > +
> > +/* quantize a little bit more */
> > +qlevels[i] += dv100_qlevel_inc;
> > +if (qlevels[i] > DV100_NUM_QLEVELS-1)
> > +qlevels[i] = DV100_NUM_QLEVELS-1;
> > +
> > +qnos[i] = DV100_QLEVEL_QNO(dv100_qlevels[qlevels[i]]);
> > +size[i] = 0;
> > +
> > +/* for each block */
> > +b = [8*i];
> > +for (j = 0; j < 8; j++, b++) {
> > +/* accumulate block size into macroblock */
> > +   

[FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

---
 libavcodec/dv.h   |   1 +
 libavcodec/dvenc.c| 555 +-
 tests/fate/vcodec.mak |  14 +-
 3 files changed, 514 insertions(+), 56 deletions(-)

diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 7ef5b7c552..0205d72347 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -83,6 +83,7 @@ enum dv_pack_type {
 
 #define DV_PROFILE_IS_HD(p) ((p)->video_stype & 0x10)
 #define DV_PROFILE_IS_1080i50(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
1))
+#define DV_PROFILE_IS_1080i60(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
0))
 #define DV_PROFILE_IS_720p50(p)  (((p)->video_stype == 0x18) && ((p)->dsf == 
1))
 
 /**
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..3afeb5ebb8 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -60,10 +60,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 ff_dv_print_profiles(avctx, AV_LOG_ERROR);
 return AVERROR(EINVAL);
 }
-if (avctx->height > 576) {
-av_log(avctx, AV_LOG_ERROR, "DVCPRO HD encoding is not supported.\n");
-return AVERROR_PATCHWELCOME;
-}
+
 ret = ff_dv_init_dynamic_tables(s, s->sys);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
@@ -90,6 +87,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 }
 
 /* bit budget for AC only in 5 MBs */
+static const int vs_total_ac_bits_hd = (68 * 6 + 52*2) * 5;
 static const int vs_total_ac_bits = (100 * 4 + 68 * 2) * 5;
 static const int mb_area_start[5] = { 1, 6, 21, 43, 64 };
 
@@ -158,6 +156,11 @@ typedef struct EncBlockInfo {
 uint8_t  sign[64];
 uint8_t  partial_bit_count;
 uint32_t partial_bit_buffer; /* we can't use uint16_t here */
+/* used by DV100 only: a copy of the weighted and classified but
+   not-yet-quantized AC coefficients. This is necessary for
+   re-quantizing at different steps. */
+int16_t  save[64];
+int  min_qlevel; /* DV100 only: minimum qlevel (for AC coefficients 
>255) */
 } EncBlockInfo;
 
 static av_always_inline PutBitContext *dv_encode_ac(EncBlockInfo *bi,
@@ -243,13 +246,123 @@ static const int dv_weight_248[64] = {
 170627, 170627, 153560, 153560, 165371, 165371, 144651, 144651,
 };
 
-static av_always_inline int dv_init_enc_block(EncBlockInfo *bi, uint8_t *data,
-  ptrdiff_t linesize,
-  DVVideoContext *s, int bias)
+/* setting this to 1 results in a faster codec but
+ * somewhat lower image quality */
+#define DV100_SACRIFICE_QUALITY_FOR_SPEED 1
+#define DV100_ENABLE_FINER 1
+
+/* pack combination of QNO and CNO into a single 8-bit value */
+#define DV100_MAKE_QLEVEL(qno,cno) ((qno<<2) | (cno))
+#define DV100_QLEVEL_QNO(qlevel) (qlevel>>2)
+#define DV100_QLEVEL_CNO(qlevel) (qlevel&0x3)
+
+#define DV100_NUM_QLEVELS 31
+
+/* The quantization step is determined by a combination of QNO and
+   CNO. We refer to these combinations as "qlevels" (this term is our
+   own, it's not mentioned in the spec). We use CNO, a multiplier on
+   the quantization step, to "fill in the gaps" between quantization
+   steps associated with successive values of QNO. e.g. there is no
+   QNO for a quantization step of 10, but we can use QNO=5 CNO=1 to
+   get the same result. The table below encodes combinations of QNO
+   and CNO in order of increasing quantization coarseness. */
+static const uint8_t dv100_qlevels[DV100_NUM_QLEVELS] = {
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 2,0), //  2*1= 2
+DV100_MAKE_QLEVEL( 3,0), //  3*1= 3
+DV100_MAKE_QLEVEL( 4,0), //  4*1= 4
+DV100_MAKE_QLEVEL( 5,0), //  5*1= 5
+DV100_MAKE_QLEVEL( 6,0), //  6*1= 6
+DV100_MAKE_QLEVEL( 7,0), //  7*1= 7
+DV100_MAKE_QLEVEL( 8,0), //  8*1= 8
+DV100_MAKE_QLEVEL( 5,1), //  5*2=10
+DV100_MAKE_QLEVEL( 6,1), //  6*2=12
+DV100_MAKE_QLEVEL( 7,1), //  7*2=14
+DV100_MAKE_QLEVEL( 9,0), // 16*1=16
+DV100_MAKE_QLEVEL(10,0), // 18*1=18
+DV100_MAKE_QLEVEL(11,0), // 20*1=20
+DV100_MAKE_QLEVEL(12,0), // 22*1=22
+DV100_MAKE_QLEVEL(13,0), // 24*1=24
+DV100_MAKE_QLEVEL(14,0), // 28*1=28
+DV100_MAKE_QLEVEL( 9,1), // 16*2=32
+DV100_MAKE_QLEVEL(10,1), // 18*2=36
+DV100_MAKE_QLEVEL(11,1), // 20*2=40
+DV100_MAKE_QLEVEL(12,1), // 22*2=44
+DV100_MAKE_QLEVEL(13,1), // 24*2=48
+DV100_MAKE_QLEVEL(15,0), // 52*1=52
+DV100_MAKE_QLEVEL(14,1), // 28*2=56
+DV100_MAKE_QLEVEL( 9,2), // 16*4=64
+DV100_MAKE_QLEVEL(10,2), // 18*4=72
+DV100_MAKE_QLEVEL(11,2), // 20*4=80
+DV100_MAKE_QLEVEL(12,2), // 22*4=88
+DV100_MAKE_QLEVEL(13,2), // 24*4=96
+// ...
+DV100_MAKE_QLEVEL(15,3), // 52*8=416
+};
+
+static const int dv100_min_bias = 0;
+static const int dv100_chroma_bias = 0;
+static const int dv100_starting_qno = 1;
+
+#if DV100_SACRIFICE_QUALITY_FOR_SPEED
+static const int 

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly decode bottom mb row in 1080i field mode

[Baptiste Coudurier]

On Wed, Sep 11, 2019 at 12:29 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> ---
>  libavcodec/dv.h|  2 ++
>  libavcodec/dvdec.c | 90 +++---
>  2 files changed, 72 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/dv.h b/libavcodec/dv.h
> index 0e97bb200e..7ef5b7c552 100644
> --- a/libavcodec/dv.h
> +++ b/libavcodec/dv.h
> @@ -31,6 +31,7 @@
>  #include "dv_profile.h"
>  #include "me_cmp.h"
>  #include "vlc.h"
> +#include "idctdsp.h"
>
>  typedef struct DVwork_chunk {
>  uint16_t buf_offset;
> @@ -52,6 +53,7 @@ typedef struct DVVideoContext {
>  me_cmp_func ildct_cmp;
>  DVwork_chunk work_chunks[4 * 12 * 27];
>  uint32_t idct_factor[2 * 4 * 16 * 64];
> +IDCTDSPContext idsp;
>
>  int quant_deadzone;
>  } DVVideoContext;
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index 89864f2edc..4345cd9e29 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -45,7 +45,6 @@
>  #include "dv_profile_internal.h"
>  #include "dvdata.h"
>  #include "get_bits.h"
> -#include "idctdsp.h"
>  #include "internal.h"
>  #include "put_bits.h"
>  #include "simple_idct.h"
> @@ -177,24 +176,22 @@ static void dv_init_weight_tables(DVVideoContext
> *ctx, const AVDVProfile *d)
>  static av_cold int dvvideo_decode_init(AVCodecContext *avctx)
>  {
>  DVVideoContext *s = avctx->priv_data;
> -IDCTDSPContext idsp;
>  int i;
>
> -memset(,0, sizeof(idsp));
> -ff_idctdsp_init(, avctx);
> +ff_idctdsp_init(>idsp, avctx);
>
>  for (i = 0; i < 64; i++)
> -s->dv_zigzag[0][i] = idsp.idct_permutation[ff_zigzag_direct[i]];
> +s->dv_zigzag[0][i] =
> s->idsp.idct_permutation[ff_zigzag_direct[i]];
>
>  if (avctx->lowres){
>  for (i = 0; i < 64; i++){
>  int j = ff_dv_zigzag248_direct[i];
> -s->dv_zigzag[1][i] = idsp.idct_permutation[(j & 7) + (j & 8)
> * 4 + (j & 48) / 2];
> +s->dv_zigzag[1][i] = s->idsp.idct_permutation[(j & 7) + (j &
> 8) * 4 + (j & 48) / 2];
>  }
>  }else
>  memcpy(s->dv_zigzag[1], ff_dv_zigzag248_direct,
> sizeof(s->dv_zigzag[1]));
>
> -s->idct_put[0] = idsp.idct_put;
> +s->idct_put[0] = s->idsp.idct_put;
>  s->idct_put[1] = ff_simple_idct248_put;
>
>  return ff_dvvideo_init(avctx);
> @@ -272,6 +269,49 @@ static inline void bit_copy(PutBitContext *pb,
> GetBitContext *gb)
>  put_bits(pb, bits_left, get_bits(gb, bits_left));
>  }
>
> +static av_always_inline void put_block_8x4(int16_t *block, uint8_t
> *restrict p, int stride)
> +{
> +int i, j;
> +const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
> +
> +for (i = 0; i < 4; i++) {
> +for (j = 0; j < 8; j++)
> +p[j] = cm[block[j]];
> +block += 8;
> +p += stride;
> +}
> +}
> +
> +static void dv100_idct_put_last_row_field_chroma(DVVideoContext *s,
> uint8_t *data,
> + int stride, int16_t
> *blocks)
> +{
> +s->idsp.idct(blocks + 0*64);
> +s->idsp.idct(blocks + 1*64);
> +
> +put_block_8x4(blocks+0*64,   data,  stride<<1);
> +put_block_8x4(blocks+0*64 + 4*8, data + 8,  stride<<1);
> +put_block_8x4(blocks+1*64,   data + stride, stride<<1);
> +put_block_8x4(blocks+1*64 + 4*8, data + 8 + stride, stride<<1);
> +}
> +
> +static void dv100_idct_put_last_row_field_luma(DVVideoContext *s, uint8_t
> *data,
> +   int stride, int16_t
> *blocks)
> +{
> +s->idsp.idct(blocks + 0*64);
> +s->idsp.idct(blocks + 1*64);
> +s->idsp.idct(blocks + 2*64);
> +s->idsp.idct(blocks + 3*64);
> +
> +put_block_8x4(blocks+0*64,   data,   stride<<1);
> +put_block_8x4(blocks+0*64 + 4*8, data + 16,  stride<<1);
> +put_block_8x4(blocks+1*64,   data + 8,   stride<<1);
> +put_block_8x4(blocks+1*64 + 4*8, data + 24,  stride<<1);
> +put_block_8x4(blocks+2*64,   data + stride,  stride<<1);
> +put_block_8x4(blocks+2*64 + 4*8, data + 16 + stride, stride<<1);
> +put_block_8x4(blocks+3*64,   data + 8  + stride, stride<<1);
> +put_block_8x4(blocks+3*64 + 4*8, data + 24 + stride, stride<<1);
> +}
> +
>  /* mb_x and mb_y are in units of 8 pixels */

Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff

[Baptiste Coudurier]

Hey Carl,

> On Sep 11, 2019, at 12:38 PM, Carl Eugen Hoyos  wrote:
> 
> Am Mi., 11. Sept. 2019 um 21:31 Uhr schrieb Baptiste Coudurier
> :
>> 
>> ---
>> libavcodec/dvdec.c | 13 ++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>> 
>> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
>> index 4345cd9e29..cfa0fb9905 100644
>> --- a/libavcodec/dvdec.c
>> +++ b/libavcodec/dvdec.c
>> @@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
>> void *data,
>> 
>> if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
>> return ret;
>> -frame.f->interlaced_frame = 1;
>> -frame.f->top_field_first  = 0;
>> 
>> /* Determine the codec's field order from the packet */
>> if ( *vsc_pack == dv_video_control ) {
>> -frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>> +if (avctx->height == 720) {
>> +frame.f->interlaced_frame = 0;
>> +frame.f->top_field_first = 0;
>> +} else if (avctx->height == 1080) {
>> +frame.f->interlaced_frame = 1;
>> +frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
>> +} else {
>> +frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
>> +frame.f->top_field_first = !(vsc_pack[3] & 0x40);
> 
> Does this fix ticket #5092?

Yes, I think it does

— 
Baptiste Coudurier

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff

[Baptiste Coudurier]

---
 libavcodec/dvdec.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 4345cd9e29..cfa0fb9905 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext *avctx, 
void *data,
 
 if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0)
 return ret;
-frame.f->interlaced_frame = 1;
-frame.f->top_field_first  = 0;
 
 /* Determine the codec's field order from the packet */
 if ( *vsc_pack == dv_video_control ) {
-frame.f->top_field_first = !(vsc_pack[3] & 0x40);
+if (avctx->height == 720) {
+frame.f->interlaced_frame = 0;
+frame.f->top_field_first = 0;
+} else if (avctx->height == 1080) {
+frame.f->interlaced_frame = 1;
+frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
+} else {
+frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
+frame.f->top_field_first = !(vsc_pack[3] & 0x40);
+}
 }
 
 s->buf = buf;
-- 
2.20.1 (Apple Git-117)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd

[Baptiste Coudurier]

---
 libavcodec/dv.h|   1 +
 libavcodec/dvenc.c | 576 -
 2 files changed, 522 insertions(+), 55 deletions(-)

diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 7ef5b7c552..0205d72347 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -83,6 +83,7 @@ enum dv_pack_type {
 
 #define DV_PROFILE_IS_HD(p) ((p)->video_stype & 0x10)
 #define DV_PROFILE_IS_1080i50(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
1))
+#define DV_PROFILE_IS_1080i60(p) (((p)->video_stype == 0x14) && ((p)->dsf == 
0))
 #define DV_PROFILE_IS_720p50(p)  (((p)->video_stype == 0x18) && ((p)->dsf == 
1))
 
 /**
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..b7a771fa18 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -60,10 +60,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 ff_dv_print_profiles(avctx, AV_LOG_ERROR);
 return AVERROR(EINVAL);
 }
-if (avctx->height > 576) {
-av_log(avctx, AV_LOG_ERROR, "DVCPRO HD encoding is not supported.\n");
-return AVERROR_PATCHWELCOME;
-}
+
 ret = ff_dv_init_dynamic_tables(s, s->sys);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
@@ -90,6 +87,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
 }
 
 /* bit budget for AC only in 5 MBs */
+static const int vs_total_ac_bits_hd = (68 * 6 + 52*2) * 5;
 static const int vs_total_ac_bits = (100 * 4 + 68 * 2) * 5;
 static const int mb_area_start[5] = { 1, 6, 21, 43, 64 };
 
@@ -158,6 +156,11 @@ typedef struct EncBlockInfo {
 uint8_t  sign[64];
 uint8_t  partial_bit_count;
 uint32_t partial_bit_buffer; /* we can't use uint16_t here */
+/* used by DV100 only: a copy of the weighted and classified but
+   not-yet-quantized AC coefficients. This is necessary for
+   re-quantizing at different steps. */
+int16_t  save[64];
+int  min_qlevel; /* DV100 only: minimum qlevel (for AC coefficients 
>255) */
 } EncBlockInfo;
 
 static av_always_inline PutBitContext *dv_encode_ac(EncBlockInfo *bi,
@@ -243,13 +246,135 @@ static const int dv_weight_248[64] = {
 170627, 170627, 153560, 153560, 165371, 165371, 144651, 144651,
 };
 
-static av_always_inline int dv_init_enc_block(EncBlockInfo *bi, uint8_t *data,
-  ptrdiff_t linesize,
-  DVVideoContext *s, int bias)
+/* setting this to 1 results in a faster codec but
+ * somewhat lower image quality */
+#define DV100_SACRIFICE_QUALITY_FOR_SPEED 1
+#define DV100_ENABLE_FINER 1
+
+/* pack combination of QNO and CNO into a single 8-bit value */
+#define DV100_MAKE_QLEVEL(qno,cno) ((qno<<2) | (cno))
+#define DV100_QLEVEL_QNO(qlevel) (qlevel>>2)
+#define DV100_QLEVEL_CNO(qlevel) (qlevel&0x3)
+
+#define DV100_NUM_QLEVELS 31
+
+/* The quantization step is determined by a combination of QNO and
+   CNO. We refer to these combinations as "qlevels" (this term is our
+   own, it's not mentioned in the spec). We use CNO, a multiplier on
+   the quantization step, to "fill in the gaps" between quantization
+   steps associated with successive values of QNO. e.g. there is no
+   QNO for a quantization step of 10, but we can use QNO=5 CNO=1 to
+   get the same result. The table below encodes combinations of QNO
+   and CNO in order of increasing quantization coarseness. */
+static const uint8_t dv100_qlevels[DV100_NUM_QLEVELS] = {
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 1,0), //  1*1= 1
+DV100_MAKE_QLEVEL( 2,0), //  2*1= 2
+DV100_MAKE_QLEVEL( 3,0), //  3*1= 3
+DV100_MAKE_QLEVEL( 4,0), //  4*1= 4
+DV100_MAKE_QLEVEL( 5,0), //  5*1= 5
+DV100_MAKE_QLEVEL( 6,0), //  6*1= 6
+DV100_MAKE_QLEVEL( 7,0), //  7*1= 7
+DV100_MAKE_QLEVEL( 8,0), //  8*1= 8
+DV100_MAKE_QLEVEL( 5,1), //  5*2=10
+DV100_MAKE_QLEVEL( 6,1), //  6*2=12
+DV100_MAKE_QLEVEL( 7,1), //  7*2=14
+DV100_MAKE_QLEVEL( 9,0), // 16*1=16
+DV100_MAKE_QLEVEL(10,0), // 18*1=18
+DV100_MAKE_QLEVEL(11,0), // 20*1=20
+DV100_MAKE_QLEVEL(12,0), // 22*1=22
+DV100_MAKE_QLEVEL(13,0), // 24*1=24
+DV100_MAKE_QLEVEL(14,0), // 28*1=28
+DV100_MAKE_QLEVEL( 9,1), // 16*2=32
+DV100_MAKE_QLEVEL(10,1), // 18*2=36
+DV100_MAKE_QLEVEL(11,1), // 20*2=40
+DV100_MAKE_QLEVEL(12,1), // 22*2=44
+DV100_MAKE_QLEVEL(13,1), // 24*2=48
+DV100_MAKE_QLEVEL(15,0), // 52*1=52
+DV100_MAKE_QLEVEL(14,1), // 28*2=56
+DV100_MAKE_QLEVEL( 9,2), // 16*4=64
+DV100_MAKE_QLEVEL(10,2), // 18*4=72
+DV100_MAKE_QLEVEL(11,2), // 20*4=80
+DV100_MAKE_QLEVEL(12,2), // 22*4=88
+DV100_MAKE_QLEVEL(13,2), // 24*4=96
+// ...
+DV100_MAKE_QLEVEL(15,3), // 52*8=416
+};
+
+/* how much to increase qlevel when we need to compress more coarsely */
+/* this is a tradeoff between encoding speed and space efficiency */
+/* the highest-quality, lowest-speed option it to use 1 for all 

[FFmpeg-devel] [PATCH] avcodec/dvdec: correctly decode bottom mb row in 1080i field mode

[Baptiste Coudurier]

---
 libavcodec/dv.h|  2 ++
 libavcodec/dvdec.c | 90 +++---
 2 files changed, 72 insertions(+), 20 deletions(-)

diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 0e97bb200e..7ef5b7c552 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -31,6 +31,7 @@
 #include "dv_profile.h"
 #include "me_cmp.h"
 #include "vlc.h"
+#include "idctdsp.h"
 
 typedef struct DVwork_chunk {
 uint16_t buf_offset;
@@ -52,6 +53,7 @@ typedef struct DVVideoContext {
 me_cmp_func ildct_cmp;
 DVwork_chunk work_chunks[4 * 12 * 27];
 uint32_t idct_factor[2 * 4 * 16 * 64];
+IDCTDSPContext idsp;
 
 int quant_deadzone;
 } DVVideoContext;
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 89864f2edc..4345cd9e29 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -45,7 +45,6 @@
 #include "dv_profile_internal.h"
 #include "dvdata.h"
 #include "get_bits.h"
-#include "idctdsp.h"
 #include "internal.h"
 #include "put_bits.h"
 #include "simple_idct.h"
@@ -177,24 +176,22 @@ static void dv_init_weight_tables(DVVideoContext *ctx, 
const AVDVProfile *d)
 static av_cold int dvvideo_decode_init(AVCodecContext *avctx)
 {
 DVVideoContext *s = avctx->priv_data;
-IDCTDSPContext idsp;
 int i;
 
-memset(,0, sizeof(idsp));
-ff_idctdsp_init(, avctx);
+ff_idctdsp_init(>idsp, avctx);
 
 for (i = 0; i < 64; i++)
-s->dv_zigzag[0][i] = idsp.idct_permutation[ff_zigzag_direct[i]];
+s->dv_zigzag[0][i] = s->idsp.idct_permutation[ff_zigzag_direct[i]];
 
 if (avctx->lowres){
 for (i = 0; i < 64; i++){
 int j = ff_dv_zigzag248_direct[i];
-s->dv_zigzag[1][i] = idsp.idct_permutation[(j & 7) + (j & 8) * 4 + 
(j & 48) / 2];
+s->dv_zigzag[1][i] = s->idsp.idct_permutation[(j & 7) + (j & 8) * 
4 + (j & 48) / 2];
 }
 }else
 memcpy(s->dv_zigzag[1], ff_dv_zigzag248_direct, 
sizeof(s->dv_zigzag[1]));
 
-s->idct_put[0] = idsp.idct_put;
+s->idct_put[0] = s->idsp.idct_put;
 s->idct_put[1] = ff_simple_idct248_put;
 
 return ff_dvvideo_init(avctx);
@@ -272,6 +269,49 @@ static inline void bit_copy(PutBitContext *pb, 
GetBitContext *gb)
 put_bits(pb, bits_left, get_bits(gb, bits_left));
 }
 
+static av_always_inline void put_block_8x4(int16_t *block, uint8_t *restrict 
p, int stride)
+{
+int i, j;
+const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
+
+for (i = 0; i < 4; i++) {
+for (j = 0; j < 8; j++)
+p[j] = cm[block[j]];
+block += 8;
+p += stride;
+}
+}
+
+static void dv100_idct_put_last_row_field_chroma(DVVideoContext *s, uint8_t 
*data,
+ int stride, int16_t *blocks)
+{
+s->idsp.idct(blocks + 0*64);
+s->idsp.idct(blocks + 1*64);
+
+put_block_8x4(blocks+0*64,   data,  stride<<1);
+put_block_8x4(blocks+0*64 + 4*8, data + 8,  stride<<1);
+put_block_8x4(blocks+1*64,   data + stride, stride<<1);
+put_block_8x4(blocks+1*64 + 4*8, data + 8 + stride, stride<<1);
+}
+
+static void dv100_idct_put_last_row_field_luma(DVVideoContext *s, uint8_t 
*data,
+   int stride, int16_t *blocks)
+{
+s->idsp.idct(blocks + 0*64);
+s->idsp.idct(blocks + 1*64);
+s->idsp.idct(blocks + 2*64);
+s->idsp.idct(blocks + 3*64);
+
+put_block_8x4(blocks+0*64,   data,   stride<<1);
+put_block_8x4(blocks+0*64 + 4*8, data + 16,  stride<<1);
+put_block_8x4(blocks+1*64,   data + 8,   stride<<1);
+put_block_8x4(blocks+1*64 + 4*8, data + 24,  stride<<1);
+put_block_8x4(blocks+2*64,   data + stride,  stride<<1);
+put_block_8x4(blocks+2*64 + 4*8, data + 16 + stride, stride<<1);
+put_block_8x4(blocks+3*64,   data + 8  + stride, stride<<1);
+put_block_8x4(blocks+3*64 + 4*8, data + 24 + stride, stride<<1);
+}
+
 /* mb_x and mb_y are in units of 8 pixels */
 static int dv_decode_video_segment(AVCodecContext *avctx, void *arg)
 {
@@ -443,14 +483,18 @@ retry:
 }
 y_ptr= s->frame->data[0] +
((mb_y * s->frame->linesize[0] + mb_x) << log2_blocksize);
-linesize = s->frame->linesize[0] << is_field_mode[mb_index];
-mb[0].idct_put(y_ptr, linesize, block + 0 * 64);
-if (s->sys->video_stype == 4) { /* SD 422 */
-mb[2].idct_put(y_ptr + (1 << log2_blocksize),linesize, 
block + 2 * 64);
+if (mb_y == 134 && is_field_mode[mb_index]) {
+dv100_idct_put_last_row_field_luma(s, y_ptr, 
s->frame->linesize[0], block);
 } else {
-mb[1].idct_put(y_ptr + (1 << log2_blocksize),linesize, 
block + 1 * 64);
-mb[2].idct_put(y_ptr + y_stride, linesize, 
block + 2 * 64);
-mb[3].idct_put(y_ptr + (1 << log2_blocksize) + y_stride, linesize, 
block + 3 * 64);
+  

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/qtrle: return last frame even if unchanged

[Baptiste Coudurier]

> On Aug 26, 2019, at 11:23 AM, Hendrik Leppkes  wrote:
> 
> On Mon, Aug 26, 2019 at 7:47 PM Baptiste Coudurier
> mailto:baptiste.coudur...@gmail.com>> wrote:
>> 
>> Hey guys,
>> 
>> 
>>> On Aug 26, 2019, at 9:25 AM, James Almer  wrote:
>>> 
>>> On 8/26/2019 11:35 AM, Hendrik Leppkes wrote:
>>>> On Mon, Aug 26, 2019 at 1:18 AM James Almer  wrote:
>>>>> 
>>>>> On 8/25/2019 7:14 PM, Michael Niedermayer wrote:
>>>>>> On Sun, Aug 25, 2019 at 11:46:36PM +0200, Michael Niedermayer wrote:
>>>>>>> On Sun, Aug 25, 2019 at 01:22:22PM -0300, James Almer wrote:
>>>>>>>> On 8/24/2019 3:18 PM, Michael Niedermayer wrote:
>>>>>>>>> Fixes: Ticket7880
>>>>>>>>> 
>>>>>>>>> Signed-off-by: Michael Niedermayer 
>>>>>>>>> ---
>>>>>>>>> libavcodec/qtrle.c| 30 ++
>>>>>>>>> tests/ref/fate/qtrle-8bit |  1 +
>>>>>>>>> 2 files changed, 27 insertions(+), 4 deletions(-)
>>>>>>>>> 
>>>>>>>>> diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
>>>>>>>>> index 2c29547e5a..c22a1a582d 100644
>>>>>>>>> --- a/libavcodec/qtrle.c
>>>>>>>>> +++ b/libavcodec/qtrle.c
>>>>>>>>> @@ -45,6 +45,7 @@ typedef struct QtrleContext {
>>>>>>>>> 
>>>>>>>>>GetByteContext g;
>>>>>>>>>uint32_t pal[256];
>>>>>>>>> +AVPacket flush_pkt;
>>>>>>>>> } QtrleContext;
>>>>>>>>> 
>>>>>>>>> #define CHECK_PIXEL_PTR(n)
>>>>>>>>> \
>>>>>>>>> @@ -454,11 +455,27 @@ static int qtrle_decode_frame(AVCodecContext 
>>>>>>>>> *avctx,
>>>>>>>>>int has_palette = 0;
>>>>>>>>>int ret, size;
>>>>>>>>> 
>>>>>>>>> +if (!avpkt->data) {
>>>>>>>>> +if (avctx->internal->need_flush) {
>>>>>>>>> +avctx->internal->need_flush = 0;
>>>>>>>>> +ret = ff_setup_buffered_frame_for_return(avctx, data, 
>>>>>>>>> s->frame, >flush_pkt);
>>>>>>>>> +if (ret < 0)
>>>>>>>>> +return ret;
>>>>>>>>> +*got_frame = 1;
>>>>>>>>> +}
>>>>>>>>> +return 0;
>>>>>>>>> +}
>>>>>>>>> +s->flush_pkt = *avpkt;
>>>>>>>>> +s->frame->pkt_dts = s->flush_pkt.dts;
>>>>>>>>> +
>>>>>>>>>bytestream2_init(>g, avpkt->data, avpkt->size);
>>>>>>>>> 
>>>>>>>>>/* check if this frame is even supposed to change */
>>>>>>>>> -if (avpkt->size < 8)
>>>>>>>>> +if (avpkt->size < 8) {
>>>>>>>>> +avctx->internal->need_flush = 1;
>>>>>>>>>return avpkt->size;
>>>>>>>>> +}
>>>>>>>>> +avctx->internal->need_flush = 0;
>>>>>>>>> 
>>>>>>>>>/* start after the chunk size */
>>>>>>>>>size = bytestream2_get_be32(>g) & 0x3FFF;
>>>>>>>>> @@ -471,14 +488,18 @@ static int qtrle_decode_frame(AVCodecContext 
>>>>>>>>> *avctx,
>>>>>>>>> 
>>>>>>>>>/* if a header is present, fetch additional decoding parameters */
>>>>>>>>>if (header & 0x0008) {
>>>>>>>>> -if (avpkt->size < 14)
>>>>>>>>> +if (avpkt->size < 14) {
>>>>>>>>> +avctx->internal->need_flush = 1;
>>>>>>>>>return avpkt->size;
>>>>>>>>> +}
>>>>>>>>> 

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/qtrle: return last frame even if unchanged

[Baptiste Coudurier]

Hey guys,


> On Aug 26, 2019, at 9:25 AM, James Almer  wrote:
> 
> On 8/26/2019 11:35 AM, Hendrik Leppkes wrote:
>> On Mon, Aug 26, 2019 at 1:18 AM James Almer  wrote:
>>> 
>>> On 8/25/2019 7:14 PM, Michael Niedermayer wrote:
 On Sun, Aug 25, 2019 at 11:46:36PM +0200, Michael Niedermayer wrote:
> On Sun, Aug 25, 2019 at 01:22:22PM -0300, James Almer wrote:
>> On 8/24/2019 3:18 PM, Michael Niedermayer wrote:
>>> Fixes: Ticket7880
>>> 
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>> libavcodec/qtrle.c| 30 ++
>>> tests/ref/fate/qtrle-8bit |  1 +
>>> 2 files changed, 27 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/libavcodec/qtrle.c b/libavcodec/qtrle.c
>>> index 2c29547e5a..c22a1a582d 100644
>>> --- a/libavcodec/qtrle.c
>>> +++ b/libavcodec/qtrle.c
>>> @@ -45,6 +45,7 @@ typedef struct QtrleContext {
>>> 
>>> GetByteContext g;
>>> uint32_t pal[256];
>>> +AVPacket flush_pkt;
>>> } QtrleContext;
>>> 
>>> #define CHECK_PIXEL_PTR(n)  
>>>   \
>>> @@ -454,11 +455,27 @@ static int qtrle_decode_frame(AVCodecContext 
>>> *avctx,
>>> int has_palette = 0;
>>> int ret, size;
>>> 
>>> +if (!avpkt->data) {
>>> +if (avctx->internal->need_flush) {
>>> +avctx->internal->need_flush = 0;
>>> +ret = ff_setup_buffered_frame_for_return(avctx, data, 
>>> s->frame, >flush_pkt);
>>> +if (ret < 0)
>>> +return ret;
>>> +*got_frame = 1;
>>> +}
>>> +return 0;
>>> +}
>>> +s->flush_pkt = *avpkt;
>>> +s->frame->pkt_dts = s->flush_pkt.dts;
>>> +
>>> bytestream2_init(>g, avpkt->data, avpkt->size);
>>> 
>>> /* check if this frame is even supposed to change */
>>> -if (avpkt->size < 8)
>>> +if (avpkt->size < 8) {
>>> +avctx->internal->need_flush = 1;
>>> return avpkt->size;
>>> +}
>>> +avctx->internal->need_flush = 0;
>>> 
>>> /* start after the chunk size */
>>> size = bytestream2_get_be32(>g) & 0x3FFF;
>>> @@ -471,14 +488,18 @@ static int qtrle_decode_frame(AVCodecContext 
>>> *avctx,
>>> 
>>> /* if a header is present, fetch additional decoding parameters */
>>> if (header & 0x0008) {
>>> -if (avpkt->size < 14)
>>> +if (avpkt->size < 14) {
>>> +avctx->internal->need_flush = 1;
>>> return avpkt->size;
>>> +}
>>> start_line = bytestream2_get_be16(>g);
>>> bytestream2_skip(>g, 2);
>>> height = bytestream2_get_be16(>g);
>>> bytestream2_skip(>g, 2);
>>> -if (height > s->avctx->height - start_line)
>>> +if (height > s->avctx->height - start_line) {
>>> +avctx->internal->need_flush = 1;
>>> return avpkt->size;
>>> +}
>>> } else {
>>> start_line = 0;
>>> height = s->avctx->height;
>>> @@ -572,5 +593,6 @@ AVCodec ff_qtrle_decoder = {
>>> .init   = qtrle_decode_init,
>>> .close  = qtrle_decode_end,
>>> .decode = qtrle_decode_frame,
>>> -.capabilities   = AV_CODEC_CAP_DR1,
>>> +.caps_internal  = FF_CODEC_CAP_SETS_PKT_DTS | 
>>> FF_CODEC_CAP_SETS_PKT_POS,
>>> +.capabilities   = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY,
>>> };
>>> diff --git a/tests/ref/fate/qtrle-8bit b/tests/ref/fate/qtrle-8bit
>>> index 27bb8aad71..39a03b7b6c 100644
>>> --- a/tests/ref/fate/qtrle-8bit
>>> +++ b/tests/ref/fate/qtrle-8bit
>>> @@ -61,3 +61,4 @@
>>> 0,160,160,1,   921600, 0xcfd6ad2b
>>> 0,163,163,1,   921600, 0x3b372379
>>> 0,165,165,1,   921600, 0x36f245f5
>>> +0,166,166,1,   921600, 0x36f245f5
>> 
>> Following what i said in the nuv patch, do you still experience timeouts
>> with the current codebase, or even if you revert commit
>> a9dacdeea6168787a142209bd19fdd74aefc9dd6? Creating a reference to an
>> existing frame buffer shouldn't be expensive anymore for the fuzzer
>> after my ref counting changes to target_dec_fuzzer.c
>> 
>> This is a very ugly solution to a problem that was already solved when
>> reference counting was introduced. Returning duplicate frames to achieve
>> cfr in decoders where it's expected shouldn't affect performance.
> 
> Maybe i should ask this backward to make it clearer what this is trying
> to fix.
> 
> Consider a patch that would return every frame twice with the same ref
> of course.
> Would you consider this to have 0 

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/alac: Check for bps of 0

[Baptiste Coudurier]

Hi Paul,


> On Aug 25, 2019, at 12:37 AM, Paul B Mahol  wrote:
> 
> On Sun, Aug 25, 2019 at 9:33 AM Michael Niedermayer 
> wrote:
> 
>> On Fri, Aug 23, 2019 at 11:20:48AM -0300, James Almer wrote:
>>> On 8/8/2019 8:23 PM, Michael Niedermayer wrote:
 Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int'
 Fixes:
>> 15764/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALAC_fuzzer-5102101203517440
 
 Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
 Signed-off-by: Michael Niedermayer 
 ---
 libavcodec/alac.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavcodec/alac.c b/libavcodec/alac.c
 index 6086e2caa8..1196925aa7 100644
 --- a/libavcodec/alac.c
 +++ b/libavcodec/alac.c
 @@ -250,7 +250,7 @@ static int decode_element(AVCodecContext *avctx,
>> AVFrame *frame, int ch_index,
 
 alac->extra_bits = get_bits(>gb, 2) << 3;
 bps = alac->sample_size - alac->extra_bits + channels - 1;
 -if (bps > 32U) {
 +if (bps > 32 || bps < 1) {
 avpriv_report_missing_feature(avctx, "bps %d", bps);
 return AVERROR_PATCHWELCOME;
>>> 
>>> bps 0 (or negative) is obviously a broken file,
>> 
>> id say very likely a broken file, yes
>> 
>> 
>>> so asking for a sample
>>> is pointless. Just return invalid data in those cases, and leave this
>>> check for > 32.
>> 
>> thats a few lines more code, for an error code and different/no message
>> its a bit difficult to guess where people prefer the extra code to be
>> correct and where they prefer somewhat incorrect solutions to minimize
>> fuzzer found bugfixes.
>> 
> 
> If you dislike what people prefer when reviewing, perhaps you should stop
> sending patches :-)

This remark sounds rude and disrespectful to me.
Please refrain from making remarks like this one in the future.

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Baptiste Coudurier]

Hi Tomas


> On Aug 22, 2019, at 3:47 AM, Tomas Härdin  wrote:
> 
> ons 2019-08-21 klockan 12:47 -0700 skrev Baptiste Coudurier:
>> Hey guys,
>> 
>> 
>>> On Aug 19, 2019, at 9:54 AM, Thomas Mundt  wrote:
>>> 
>>> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin >>> :
>>>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>>>>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
>>>> tjop...@acc.umu.se
>>>>>> :
>>>>>> ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
>>>>>>> 
>>>>>>> New patch attached.
>>>>>> 
>>>>>> Looks OK. I'll push in a few days if no one else has any comments
>>>>>> 
>>>>> 
>>>>> Thanks. Would you mind porting it to branches 4.1 and 4.2?
>>>> 
>>>> I'm not quite sure what the process is for that. I have confirmed that
>>>> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>>>> 
>>>> I think we also might want to put a note somewhere in the documentation
>>>> how to make NTSC IMX50 files.
>>>> 
>> 
>> Yeah, it’s been an issue for quite some time, s356m mentions:
>> "When used as a signal source for the type D-10 recording format, the
>> bit stream is carried by SDTI-CP, as defined in SMPTE 326M, using
>> recommended operating point bit rates as defined in this annex. Other
>> bit rates may be used. However, users are cautioned that other system
>> design parameters within the studio may not support all bit rates.
>> 
>> Table A.1 indicates recommended operating points to simplify studio
>> operations and to provide users with a tool to be used in designing
>> systems."
>> 
>> Then specifies the exact value of the sequence_header bit_rate_value,
>> 50mit/s being “1E848h”, "To be used when compliant with EBU D84 and
>> D85"
> 
> mpeg12enc.c does this, if I read it correctly. 4840 / 400 =
> 124999.6 which gets rounded up to 125000.

Oh, that’s good actually.

>> I don’t think it is a good idea to produce files with the wrong
>> bit_rate value, and I know for a fact that many file analyzers in use
>> today will simply reject the d-10 essence.
> 
> Would writing 5000 in mxfenc for values in the range
> [4840,5000] make it pass?

If the d-10 mpeg-2 essence has the right bit_rate value, the analyzer works.
Thinking about this, and assuming the seq header bit_rate_value is correctly 
set,
Could we infer the D-10 UL after the first frame according to the mpeg-2 
essence ? 
That would guarantee correctness and eliminate the hackish bitrate check.

Thanks!

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/mxfenc: Allow more bitrates for NTSC IMX50

[Baptiste Coudurier]

Hey guys,


> On Aug 19, 2019, at 9:54 AM, Thomas Mundt  wrote:
> 
> Am Fr., 16. Aug. 2019 um 23:31 Uhr schrieb Tomas Härdin > :
> 
>> tor 2019-08-15 klockan 13:55 +0200 skrev Thomas Mundt:
>>> Am Do., 15. Aug. 2019 um 11:01 Uhr schrieb Tomas Härdin <
>> tjop...@acc.umu.se
 :
 ons 2019-08-14 klockan 22:18 +0200 skrev Thomas Mundt:
> Hi Tomas,
> 
> Am Mi., 14. Aug. 2019 um 12:42 Uhr schrieb Tomas Härdin <
 tjop...@acc.umu.se
>> :
>> tis 2019-08-13 klockan 22:03 +0200 skrev Thomas Mundt:
>>> Hi,
>>> 
>>> attached patch fixes ticket #8077.
>>> Please comment.
>> 
>> Probably OK, bitrates lower than 5000 are fine in D-10
>> according to
>> S356m.
>> 
>>> } else if ((sc->video_bit_rate >= 4840) &&
>> (sc->video_bit_rate <=
>>> 5000) && (mxf->time_base.den != 25)) {
>> 
>> You could drop the extra parentheses, else it should be fine.
>> 
> 
> New patch attached.
 
 Looks OK. I'll push in a few days if no one else has any comments
 
>>> 
>>> Thanks. Would you mind porting it to branches 4.1 and 4.2?
>> 
>> I'm not quite sure what the process is for that. I have confirmed that
>> the problem exists in 4.1 and 4.2 and that your patch fixes it.
>> 
>> I think we also might want to put a note somewhere in the documentation
>> how to make NTSC IMX50 files.
>> 

Yeah, it’s been an issue for quite some time, s356m mentions:
"When used as a signal source for the type D-10 recording format, the bit 
stream is carried by SDTI-CP, as defined in SMPTE 326M, using recommended 
operating point bit rates as defined in this annex. Other bit rates may be 
used. However, users are cautioned that other system design parameters within 
the studio may not support all bit rates.

Table A.1 indicates recommended operating points to simplify studio operations 
and to provide users with a tool to be used in designing systems."

Then specifies the exact value of the sequence_header bit_rate_value, 50mit/s 
being “1E848h”, "To be used when compliant with EBU D84 and D85"

I don’t think it is a good idea to produce files with the wrong bit_rate value, 
and I know for a fact that many file analyzers in use today will simply reject 
the d-10 essence.
The current code is simply a hack, and IMHO the right solution is to put an 
option to force the ratecontrol to behave as people want for NTSC D-10. I’ve 
submitted a patch for that but Michael wanted it as an option.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix index byte count in partition header

[Baptiste Coudurier]

Hi Tomas,


> On Jul 22, 2019, at 2:45 AM, Tomas Härdin  wrote:
> 
> fre 2019-07-19 klockan 09:51 -0700 skrev Baptiste Coudurier:
>> Hi Tomas
>> 
>>> On Jul 19, 2019, at 8:48 AM, Tomas Härdin 
>>> wrote:
>>> 
>>> tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
>>>> ---
>>>> libavformat/mxfenc.c | 3 +--
>>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>> 
>>>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>>>> index b677f6af8e..2e54320cf0 100644
>>>> --- a/libavformat/mxfenc.c
>>>> +++ b/libavformat/mxfenc.c
>>>> @@ -1944,8 +1944,7 @@ static int
>>>> mxf_write_partition(AVFormatContext
>>>> *s, int bodysid,
>>>>index_byte_count = 80;
>>>> 
>>>>if (index_byte_count) {
>>>> -// add encoded ber length
>>>> -index_byte_count += 16 +
>>>> klv_ber_length(index_byte_count);
>>>> +index_byte_count += 16 + 4; // add encoded ber4 length
>>>>index_byte_count += klv_fill_size(index_byte_count);
>>>>}
>>>> 
>>> 
>>> Is there a reason why we don't pick a single BER length coding for
>>> the
>>> entire muxer?
>> 
>> BER It saves space, BER4 is only used when required. No strong
>> opinion,
>> I think it’s unrelated to this fix though.
> 
> Sorry about the late reply. But yeah, just thought it was a bit
> strange. BER4 does make computing sizes much easier where possible. The
> patch itself is obviously fine

No worries. Yeah I kinda agree.

Applied.

Thanks a lot!

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix index byte count in partition header

[Baptiste Coudurier]

Hi Tomas

> On Jul 19, 2019, at 8:48 AM, Tomas Härdin  wrote:
> 
> tor 2019-07-18 klockan 11:39 -0700 skrev Baptiste Coudurier:
>> ---
>> libavformat/mxfenc.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index b677f6af8e..2e54320cf0 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -1944,8 +1944,7 @@ static int mxf_write_partition(AVFormatContext
>> *s, int bodysid,
>> index_byte_count = 80;
>> 
>> if (index_byte_count) {
>> -// add encoded ber length
>> -index_byte_count += 16 + klv_ber_length(index_byte_count);
>> +index_byte_count += 16 + 4; // add encoded ber4 length
>> index_byte_count += klv_fill_size(index_byte_count);
>> }
>> 
> 
> Is there a reason why we don't pick a single BER length coding for the
> entire muxer?

BER It saves space, BER4 is only used when required. No strong opinion,
I think it’s unrelated to this fix though.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: fix index byte count in partition header

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index b677f6af8e..2e54320cf0 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1944,8 +1944,7 @@ static int mxf_write_partition(AVFormatContext *s, int 
bodysid,
 index_byte_count = 80;
 
 if (index_byte_count) {
-// add encoded ber length
-index_byte_count += 16 + klv_ber_length(index_byte_count);
+index_byte_count += 16 + 4; // add encoded ber4 length
 index_byte_count += klv_fill_size(index_byte_count);
 }
 
-- 
2.20.1 (Apple Git-117)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On May 17, 2019, at 12:07 PM, Baptiste Coudurier 
>  wrote:
> 
> Hi Thomas,
> 
>> On May 14, 2019, at 2:54 PM, Thomas Mundt > <mailto:tmund...@gmail.com>> wrote:
>> 
>> Hi Baptiste,
>> 
>> Am Di., 14. Mai 2019 um 18:59 Uhr schrieb Baptiste Coudurier 
>> mailto:baptiste.coudur...@gmail.com>>:
>> ---
>>  libavformat/Makefile |   2 +-
>>  libavformat/avc.c| 186 +
>>  libavformat/avc.h|  15 +++
>>  libavformat/hevc.c   |  36 +---
>>  libavformat/mxf.h|   1 +
>>  libavformat/mxfenc.c | 213 ++-
>>  6 files changed, 372 insertions(+), 81 deletions(-)
>> 
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 99be60d184..df87c54a58 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
>> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
>> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o 
>> audiointerleave.o avc.o
>>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
>> diff --git a/libavformat/avc.c b/libavformat/avc.c
>> index ec50033a04..a041e84357 100644
>> --- a/libavformat/avc.c
>> +++ b/libavformat/avc.c
>> @@ -21,6 +21,7 @@
>> 
>>  #include "libavutil/intreadwrite.h"
>>  #include "libavcodec/h264.h"
>> +#include "libavcodec/get_bits.h"
>>  #include "avformat.h"
>>  #include "avio.h"
>>  #include "avc.h"
>> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
>> *start,
>> 
>>  return start + res;
>>  }
>> +
>> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
>> +  uint32_t *dst_len, int header_len)
>> +{
>> +uint8_t *dst;
>> +uint32_t i, len;
>> +
>> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
>> +if (!dst)
>> +return NULL;
>> +
>> +/* NAL unit header */
>> +i = len = 0;
>> +while (i < header_len && i < src_len)
>> +dst[len++] = src[i++];
>> +
>> +while (i + 2 < src_len)
>> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
>> +dst[len++] = src[i++];
>> +dst[len++] = src[i++];
>> +i++; // remove emulation_prevention_three_byte
>> +} else
>> +dst[len++] = src[i++];
>> +
>> +while (i < src_len)
>> +dst[len++] = src[i++];
>> +
>> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>> +
>> +*dst_len = len;
>> +return dst;
>> +}
>> +
>> +static const AVRational avc_sample_aspect_ratio[17] = {
>> +{   0,  1 },
>> +{   1,  1 },
>> +{  12, 11 },
>> +{  10, 11 },
>> +{  16, 11 },
>> +{  40, 33 },
>> +{  24, 11 },
>> +{  20, 11 },
>> +{  32, 11 },
>> +{  80, 33 },
>> +{  18, 11 },
>> +{  15, 11 },
>> +{  64, 33 },
>> +{ 160, 99 },
>> +{   4,  3 },
>> +{   3,  2 },
>> +{   2,  1 },
>> +};
>> +
>> +static inline int get_ue_golomb(GetBitContext *gb) {
>> +int i;
>> +for (i = 0; i < 32 && !get_bits1(gb); i++)
>> +;
>> +return get_bitsz(gb, i) + (1 << i) - 1;
>> +}
>> +
>> +static inline int get_se_golomb(GetBitContext *gb) {
>> +int v = get_ue_golomb(gb) + 1;
>> +int sign = -(v & 1);
>> +return ((v >> 1) ^ sign) - sign;
>> +}
>> +
>> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int 
>> buf_size)
>> +{
>> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
>> +int num_ref_frames_in_pic_order_cnt_cycle;
>> +int delta_scale, lastScale = 8, nextScale = 8;
>> +int sizeOfScalingList;
>> +H264SequenceParameterSet *sps = NULL;
>> +GetBitContext gb;
>> +uint8_t *rbsp_buf;
>> +
>> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, bu

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas,

> On May 14, 2019, at 2:54 PM, Thomas Mundt  wrote:
> 
> Hi Baptiste,
> 
> Am Di., 14. Mai 2019 um 18:59 Uhr schrieb Baptiste Coudurier 
> mailto:baptiste.coudur...@gmail.com>>:
> ---
>  libavformat/Makefile |   2 +-
>  libavformat/avc.c| 186 +
>  libavformat/avc.h|  15 +++
>  libavformat/hevc.c   |  36 +---
>  libavformat/mxf.h|   1 +
>  libavformat/mxfenc.c | 213 ++-
>  6 files changed, 372 insertions(+), 81 deletions(-)
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 99be60d184..df87c54a58 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>  OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>  OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>  OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
> avc.o
>  OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>  OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>  OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index ec50033a04..a041e84357 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -21,6 +21,7 @@
> 
>  #include "libavutil/intreadwrite.h"
>  #include "libavcodec/h264.h"
> +#include "libavcodec/get_bits.h"
>  #include "avformat.h"
>  #include "avio.h"
>  #include "avc.h"
> @@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
> *start,
> 
>  return start + res;
>  }
> +
> +uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
> +  uint32_t *dst_len, int header_len)
> +{
> +uint8_t *dst;
> +uint32_t i, len;
> +
> +dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!dst)
> +return NULL;
> +
> +/* NAL unit header */
> +i = len = 0;
> +while (i < header_len && i < src_len)
> +dst[len++] = src[i++];
> +
> +while (i + 2 < src_len)
> +if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
> +dst[len++] = src[i++];
> +dst[len++] = src[i++];
> +i++; // remove emulation_prevention_three_byte
> +} else
> +dst[len++] = src[i++];
> +
> +while (i < src_len)
> +dst[len++] = src[i++];
> +
> +memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
> +
> +*dst_len = len;
> +return dst;
> +}
> +
> +static const AVRational avc_sample_aspect_ratio[17] = {
> +{   0,  1 },
> +{   1,  1 },
> +{  12, 11 },
> +{  10, 11 },
> +{  16, 11 },
> +{  40, 33 },
> +{  24, 11 },
> +{  20, 11 },
> +{  32, 11 },
> +{  80, 33 },
> +{  18, 11 },
> +{  15, 11 },
> +{  64, 33 },
> +{ 160, 99 },
> +{   4,  3 },
> +{   3,  2 },
> +{   2,  1 },
> +};
> +
> +static inline int get_ue_golomb(GetBitContext *gb) {
> +int i;
> +for (i = 0; i < 32 && !get_bits1(gb); i++)
> +;
> +return get_bitsz(gb, i) + (1 << i) - 1;
> +}
> +
> +static inline int get_se_golomb(GetBitContext *gb) {
> +int v = get_ue_golomb(gb) + 1;
> +int sign = -(v & 1);
> +return ((v >> 1) ^ sign) - sign;
> +}
> +
> +H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
> +{
> +int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
> +int num_ref_frames_in_pic_order_cnt_cycle;
> +int delta_scale, lastScale = 8, nextScale = 8;
> +int sizeOfScalingList;
> +H264SequenceParameterSet *sps = NULL;
> +GetBitContext gb;
> +uint8_t *rbsp_buf;
> +
> +rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
> +if (!rbsp_buf)
> +return NULL;
> +
> +ret = init_get_bits8(, rbsp_buf, rbsp_size);
> +if (ret < 0)
> +goto end;
> +
> +sps = av_mallocz(sizeof(*sps));
> +if (!sps)
> +goto end;
> +
> +sps->profile_idc = get_bits(, 8);
> +sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
> +sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
> +sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
> +sps->constraint_set

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 186 +
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 372 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..a041e84357 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+return get_bitsz(gb, i) + (1 << i) - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas

> On May 13, 2019, at 3:11 PM, Thomas Mundt  wrote:
> 
> Hi Baptiste,
> 
> Am Fr., 10. Mai 2019 um 17:51 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com>:
> 
>> ---
>> libavformat/Makefile |   2 +-
>> libavformat/avc.c| 188 ++
>> libavformat/avc.h|  15 +++
>> libavformat/hevc.c   |  36 +---
>> libavformat/mxf.h|   1 +
>> libavformat/mxfenc.c | 213 ++-
>> 6 files changed, 374 insertions(+), 81 deletions(-)
>> [...]
> 
> +static const MXFLocalTagPair mxf_avc_subdescriptor_local_tags[] = {
>> +{ 0x8100,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
>> /* SubDescriptors */
>> +{ 0x8200,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
>> /* AVC Decoding Delay */
>> +{ 0x8201,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
>> /* AVC Profile */
>> +{ 0x8202,
>> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
>> /* AVC Level */
>> +};
>> +
>> [...]
>> +static void mxf_write_avc_subdesc(AVFormatContext *s, AVStream *st)
>> +{
>> +AVIOContext *pb = s->pb;
>> +int64_t pos;
>> +
>> +avio_write(pb, mxf_avc_subdescriptor_key, 16);
>> +klv_encode_ber4_length(pb, 0);
>> +pos = avio_tell(pb);
>> +
>> +mxf_write_local_tag(pb, 16, 0x3C0A);
>> +mxf_write_uuid(pb, AVCSubDescriptor, 0);
>> +
>> +mxf_write_local_tag(pb, 1, 0x8200);
>> +avio_w8(pb, 0xFF); // AVC Decoding Delay, unknown
>> +
>> +mxf_write_local_tag(pb, 1, 0x8201);
>> +avio_w8(pb, st->codecpar->profile); // AVC Profile
>> +
>> +mxf_write_local_tag(pb, 1, 0x8202);
>> +avio_w8(pb, st->codecpar->level); // AVC Level
>> +
>> +mxf_update_klv_size(s->pb, pos);
>> +}
>> 
> 
> Other MXF muxers, e.g. bmxlib, also write the avc profile constraint tag
> when the avc subdescriptor is used. At least MediaInfo detects intra coded
> files as long gop otherwise.

I prefer not writing optional values unless actually required by actual 
decoders.
I think MediaInfo should be fixed in this case, it is obviously wrong.

> FFmpeg crashes with this patch when I try to remux AVC Intra files without
> SPS/PPS header.
> Tested on Windows 7. Compiled with msys2/gcc7.3.0 x86-32bit.
> Command: ffmpeg -i AVCI100_Test.mxf -c:v copy out.mxf
> Test file:
> https://www.mediafire.com/file/n0oi50u39yi3qpr/AVCI100_Test.mxf/file 
> <https://www.mediafire.com/file/n0oi50u39yi3qpr/AVCI100_Test.mxf/file>

Strange, why doesn’t gcc emit a warning for SPS might be initialized in this 
case…
Fixed in an updated patch.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 186 +
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 372 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..a041e84357 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+return get_bitsz(gb, i) + (1 << i) - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // 

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 186 +
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 372 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..a041e84357 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,188 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+return get_bitsz(gb, i) + (1 << i) - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On May 12, 2019, at 1:39 PM, Paul B Mahol  wrote:
> 
> On 5/12/19, Baptiste Coudurier  <mailto:baptiste.coudur...@gmail.com>> wrote:
>> Hi Tomas
>> 
>>> On May 12, 2019, at 6:47 AM, Tomas Härdin  wrote:
>>> 
>>> fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
>>>> +static inline int get_ue_golomb(GetBitContext *gb) {
>>>> +int i, v;
>>>> +for (i = 0; i < 32 && !get_bits1(gb); i++)
>>>> +;
>>>> +for (v = 1; i--;)
>>>> +v = (v << 1) | get_bits1(gb);
>>> 
>>> Isn't there already a function to get variable number of bits?
>> 
>> get_bits doesn’t work for n == 0
> 
> There is get_bitsz. Or I misunderstood?

Nice, updated.

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Tomas

> On May 12, 2019, at 6:47 AM, Tomas Härdin  wrote:
> 
> fre 2019-05-10 klockan 08:50 -0700 skrev Baptiste Coudurier:
>> +static inline int get_ue_golomb(GetBitContext *gb) {
>> +int i, v;
>> +for (i = 0; i < 32 && !get_bits1(gb); i++)
>> +;
>> +for (v = 1; i--;)
>> +v = (v << 1) | get_bits1(gb);
> 
> Isn't there already a function to get variable number of bits?

get_bits doesn’t work for n == 0

>> 
>> +
>> +sps->profile_idc = get_bits(, 8);
>> +sps->constraint_set_flags |= get_bits1() << 0; // 
>> constraint_set0_flag
>> +sps->constraint_set_flags |= get_bits1() << 1; // 
>> constraint_set1_flag
>> +sps->constraint_set_flags |= get_bits1() << 2; // 
>> constraint_set2_flag
>> +sps->constraint_set_flags |= get_bits1() << 3; // 
>> constraint_set3_flag
>> +sps->constraint_set_flags |= get_bits1() << 4; // 
>> constraint_set4_flag
>> +sps->constraint_set_flags |= get_bits1() << 5; // 
>> constraint_set5_flag
> 
> Why not just get 6 bits at once?

That’s how it’s done in h264_ps.c currently.
 
>> +static void mxf_write_local_tags(AVIOContext *pb, const MXFLocalTagPair 
>> *local_tags, int count)
>> +{
>> +int i;
>> +for (i = 0; i < count; i++) {
>> +avio_wb16(pb, local_tags[i].local_tag);
>> +avio_write(pb, local_tags[i].uid, 16);
>> +}
>> +}
> 
> This function could be used to simplify mxf_write_primer_pack(). But
> that probably belongs in a separate patch.

Yes, it does

>> +
>>  static void mxf_write_primer_pack(AVFormatContext *s)
>>  {
>>  MXFContext *mxf = s->priv_data;
>>  AVIOContext *pb = s->pb;
>>  int local_tag_number, i = 0;
>> +int avc_tags_count = 0;
>>  
>>  local_tag_number = FF_ARRAY_ELEMS(mxf_local_tag_batch);
>>  local_tag_number += mxf->store_user_comments * 
>> FF_ARRAY_ELEMS(mxf_user_comments_local_tag);
>>  
>> +for (i = 0; i < s->nb_streams; i++) {
>> +MXFStreamContext *sc = s->streams[i]->priv_data;
>> +if (s->streams[i]->codecpar->codec_id == AV_CODEC_ID_H264 && 
>> !sc->avc_intra) {
>> +avc_tags_count = 
>> FF_ARRAY_ELEMS(mxf_avc_subdescriptor_local_tags);
>> +local_tag_number += avc_tags_count;
> 
> This will output a broken file if there's more than one XAVC stream.
> Not possible now I think, but will be a problem is someone decides to
> give higher operational patterns a try

Yes, it will get caught when this happens.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On Apr 10, 2019, at 3:16 PM, James Almer  wrote:
> 
> On 4/10/2019 6:23 PM, Baptiste Coudurier wrote:
>> ---
>> libavformat/Makefile |   2 +-
>> libavformat/avc.c| 173 +++
>> libavformat/avc.h|  15 +++
>> libavformat/hevc.c   |  36 +---
>> libavformat/mxf.h|   1 +
>> libavformat/mxfenc.c | 213 ++-
>> 6 files changed, 359 insertions(+), 81 deletions(-)
>> 
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 99be60d184..df87c54a58 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
>> OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
>> OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
>> OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
>> -OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
>> +OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o 
>> audiointerleave.o avc.o
>> OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
>> OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
>> OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
>> diff --git a/libavformat/avc.c b/libavformat/avc.c
>> index ec50033a04..06a1e495a8 100644
>> --- a/libavformat/avc.c
>> +++ b/libavformat/avc.c
>> @@ -21,6 +21,7 @@
>> 
>> #include "libavutil/intreadwrite.h"
>> #include "libavcodec/h264.h"
>> +#include "libavcodec/golomb.h"
> 
> Right, so golomb has a bunch of lookup tables in golomb.c, obviously not
> accessible from libavformat. So this will probably fail to build in
> shared builds.
> 
> One option is to include golomb.c here. Another is donig with it the
> same we're doing with libavutil's log2_tab.c, and the other is to write
> simple get_se() and get_ue() functions here that don't use lookup tables.

Patch updated, reimplemented get_se and get_ue as suggested.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 188 ++
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 374 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..8f53228bf3 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/get_bits.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,190 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+static inline int get_ue_golomb(GetBitContext *gb) {
+int i, v;
+for (i = 0; i < 32 && !get_bits1(gb); i++)
+;
+for (v = 1; i--;)
+v = (v << 1) | get_bits1(gb);
+return v - 1;
+}
+
+static inline int get_se_golomb(GetBitContext *gb) {
+int v = get_ue_golomb(gb) + 1;
+int sign = -(v & 1);
+return ((v >> 1) ^ sign) - sign;
+}
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+

Re: [FFmpeg-devel] [DECISION] Project policy on closed source components

[Baptiste Coudurier]

> On May 3, 2019, at 1:15 AM, Paul B Mahol  wrote:
> 
> On 4/28/19, Marton Balint  wrote:
>> Hi All,
>> 
>> There has been discussion on the mailing list several times about the
>> inclusion of support for closed source components (codecs, formats,
>> filters, etc) in the main ffmpeg codebase.
>> 
>> Also the removal of libNDI happened without general consensus, so a vote
>> is necessary to justify the removal.
>> 
>> So here is a call to the voting committee [1] to decide on the following
>> two questions:
>> 
>> 1) Should libNDI support be removed from the ffmpeg codebase?
> 
> Yes, yes.

Yes

> 
>> 
>> 2) Should patches using closed source libraries which are not considered
>> "System Libraries" according to the GPL be rejected?
> 
> Yes, yes, yes.

Yes

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Michael, I hope you are doing well,

> On Apr 16, 2019, at 4:03 PM, Michael Niedermayer  
> wrote:
> 
> Signed PGP part
> On Wed, Apr 10, 2019 at 06:54:53PM -0300, James Almer wrote:
>> On 4/10/2019 6:26 PM, Baptiste Coudurier wrote:
>>>> On Apr 9, 2019, at 6:27 PM, James Almer  wrote:
>>>> 
>>>> On 4/9/2019 9:40 PM, Baptiste Coudurier wrote:
>>>>> 
>>>>>> On Apr 9, 2019, at 5:24 PM, James Almer  wrote:
>>>>>> 
>>>>>> On 4/9/2019 8:59 PM, Baptiste Coudurier wrote:
>>>>>>> 
>>>>>>>> On Apr 9, 2019, at 4:51 PM, James Almer  wrote:
>>>>>>>> 
>>>>>>>> On 4/9/2019 8:22 PM, Baptiste Coudurier wrote:
>>>>>>>>> Hi James,
>>>>>>>>> 
>>>>>>>>>> On Apr 9, 2019, at 4:09 PM, James Almer  wrote:
>>>>>>>>>> 
>>>>>>>>>>> […]
>>>>>>>>>> 
>>>>>>>>>> Ok so, the only fields you need from the sps are 
>>>>>>>>>> constraint_set_flags,
>>>>>>>>>> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar,
>>>>>>>>>> meaning you don't even need to parse the sps until the very end (sar 
>>>>>>>>>> is
>>>>>>>>>> the furthest value, and right at the beginning of vui_parameters).
>>>>>>>>>> I'd very much prefer if we can avoid making
>>>>>>>>>> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets 
>>>>>>>>>> part
>>>>>>>>>> of the ABI, so i think it's worth copying the required bitstream 
>>>>>>>>>> parsing
>>>>>>>>>> code at least until the beginning of vui_parameters. It was done for
>>>>>>>>>> hevc and av1, so it can be done for h264 as well.
>>>>>>>>> 
>>>>>>>>> Since vui parsing is needed, that would be the entire 
>>>>>>>>> "ff_h264_decode_seq_parameter_set()” function.
>>>>>>>> 
>>>>>>>> If you only need up to sar, then yo don't need to parse the entire VUI.
>>>>>>> 
>>>>>>> It still requires copying the entire 
>>>>>>> ff_h264_decode_seq_parameter_set(), even though the sub functions are 
>>>>>>> not needed.
>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I disagree with the copying. I also disagree with the copying for 
>>>>>>>>> AVC1 and HEVC btw.
>>>>>>>> 
>>>>>>>> Using avpriv opens a whole can of worms that will be unpredictable in
>>>>>>>> the future. Just look at recent commits like
>>>>>>>> f4ea930a119298c6110ee4e3d24219a66e27e230 that started storing 
>>>>>>>> previously
>>>>>>>> skipped values. If hevc_pc was made avpriv for isombff/matroska muxing
>>>>>>>> purposes and its structs part of the ABI, this wouldn't have been
>>>>>>>> possible until a major bump.
>>>>>>> 
>>>>>>> When did the sharing policy between avformat and avcodec (in the sense 
>>>>>>> avformat using avcodec) change ?
>>>>>>> It seems perfectly natural to me to have libavformat require the 
>>>>>>> libavcodec version that it was compiled with,
>>>>>>> and check it at runtime.
>>>>>> 
>>>>>> More than one ffmpeg release will ship with libavcodec/libavformat
>>>>>> sharing the same soname. Backwards compatibility is expected, hence the
>>>>>> split between major, minor and micro, as you're meant to be able to drop
>>>>>> a newer libavcodec library, say for example ffmpeg 4.1's
>>>>>> libavcodec.58.so, and it should work with an existing libavformat.so.58
>>>>>> that was linked against ffmpeg 4.0's libavcodec.58.so.
>>>>> 
>>>>> Sorry to repeat the question but when did that change ?
>>>> 
>>>> I don't know if it ever changed to being with. It's been like this for
>>>> as long as i remember, and i don't recall inter-library version checks
>>>> that would take minor and micro into consideration (which would be
>>>> needed to truly tie a given libavformat library with the exact
>>>> libavcodec it was linked to) whereas ABI backwards compatibility
>>>> considerations for inter-library stuff can be seen all across the
>>>> codebase and git history.
>>> 
>>> It definitely changed, probably around the introduction of “avpriv” prefix.
>> 
>> I think that predates my arrival to the project. Someone else will have
>> to chime in...
> 
> it possibly changed from "we dont care / we didnt think about it" in the
> distant past, iam not sure its very long ago.
> But strange interdependancies on minor/micro versions that are outside
> the established rules (https://semver.org/ <https://semver.org/>)
> can cause surprises and problems to for example packagers for distros.
> So i suggest to stay close to what most users of the libs / packagers do
> expect and whould causes the least problems and surprise …

Actually I just saw this:
WARNING: library configuration mismatch
From fftools/cmdutils.c line 1117 from 2010 it seems

So we did care about warning about it since we added this code.

I still believe we should enforce libavcodec version inside libavformat,
but that will be another topic.

—
Baptiste






signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: fix storage size for offset_for_ref_frame

[Baptiste Coudurier]

> On Apr 16, 2019, at 3:01 PM, James Almer  wrote:
> 
> On 4/16/2019 6:48 PM, Mark Thompson wrote:
>> On 11/04/2019 04:10, James Almer wrote:
>>> On 4/10/2019 3:30 PM, James Almer wrote:
 The spec defines the valid range of values to be INT32_MIN + 1 to 
 INT32_MAX, inclusive.
 
 Signed-off-by: James Almer 
 ---
 A good example of why making offsets and sizes of structs like this tied 
 to the
 ABI is not a good idea.
 
 libavcodec/h264_ps.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavcodec/h264_ps.h b/libavcodec/h264_ps.h
 index e967b9cbcf..9014326dfb 100644
 --- a/libavcodec/h264_ps.h
 +++ b/libavcodec/h264_ps.h
 @@ -81,7 +81,7 @@ typedef struct SPS {
 uint32_t num_units_in_tick;
 uint32_t time_scale;
 int fixed_frame_rate_flag;
 -short offset_for_ref_frame[256]; // FIXME dyn aloc?
 +int32_t offset_for_ref_frame[256];
>>> 
>>> The doxy for get_se_golomb() doesn't mention the range of values it can
>>> handle, but seeing there's also a get_se_golomb_long(), I guess the
>>> relevant line in h264_ps.c should now use the latter instead?
>> 
>> I think it's correct to do that.  Seems highly unlikely anyone would ever 
>> hit it outside a conformance-checking context, though - using anything other 
>> than pic_order_cnt_type 0 for nontrivial reference structures is madness.
>> 
 int bitstream_restriction_flag;
 int num_reorder_frames;
 int scaling_matrix_present;
>> 
>> There are some other fields with int32_t range which are using 
>> get_se_golomb() - e.g. offset_for_non_ref_pic.  I guess they should use 
>> get_se_golomb_long() as above.  They're also plain ints - do they want to be 
>> explicitly int32_t?
> 
> It's wildly inconsistent. There are both scalar values and arrays as
> uint32_t, int, and unsigned it, but in all cases they can store the
> correct range of values, so IMO, not worth changing unless the whole
> structs are made consistent, like you did with the CBS ones.

Sounds like a good opportunity to make the whole structs consistent.

—
Baptiste



signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/5] avformat/mxfdec: guess wrapping of tracks by other tracks with the same body sid

[Baptiste Coudurier]

Hi Tomas, I hope you are doing well

> On Apr 14, 2019, at 8:58 AM, Tomas Härdin  wrote:
> 
> […]
> 
>> @@ -2553,6 +2563,12 @@ static int mxf_parse_structural_metadata(MXFContext 
>> *mxf)
>>  }
>>  }
>> 
>> +for (int i = 0; i < mxf->fc->nb_streams; i++) {
>> +MXFTrack *track = mxf->fc->streams[i]->priv_data;
>> +if (track && track->body_sid && track->wrapping == UnknownWrapped)
>> +track->wrapping = mxf_get_wrapping_by_body_sid(mxf->fc, 
>> track->body_sid);
>> +}
> 
> Or maybe put a warning here instead. Vendors should fix their dang MXF
> muxers..


Yeah…

Since MXF is a container exclusively used in a professional environment, I 
believe we could be
way more strict than other formats. I also feel we don’t have to support older 
files that were
often broken.

—
Baptiste




signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c| 173 +++
 libavformat/avc.h|  15 +++
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 213 ++-
 6 files changed, 359 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index 99be60d184..df87c54a58 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -339,7 +339,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..06a1e495a8 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -21,6 +21,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavcodec/h264.h"
+#include "libavcodec/golomb.h"
 #include "avformat.h"
 #include "avio.h"
 #include "avc.h"
@@ -241,3 +242,175 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
+
+static const AVRational avc_sample_aspect_ratio[17] = {
+{   0,  1 },
+{   1,  1 },
+{  12, 11 },
+{  10, 11 },
+{  16, 11 },
+{  40, 33 },
+{  24, 11 },
+{  20, 11 },
+{  32, 11 },
+{  80, 33 },
+{  18, 11 },
+{  15, 11 },
+{  64, 33 },
+{ 160, 99 },
+{   4,  3 },
+{   3,  2 },
+{   2,  1 },
+};
+
+H264SequenceParameterSet *ff_avc_decode_sps(const uint8_t *buf, int buf_size)
+{
+int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
+int num_ref_frames_in_pic_order_cnt_cycle;
+int delta_scale, lastScale = 8, nextScale = 8;
+int sizeOfScalingList;
+H264SequenceParameterSet *sps = NULL;
+GetBitContext gb;
+uint8_t *rbsp_buf;
+
+rbsp_buf = ff_nal_unit_extract_rbsp(buf, buf_size, _size, 0);
+if (!rbsp_buf)
+return NULL;
+
+ret = init_get_bits8(, rbsp_buf, rbsp_size);
+if (ret < 0)
+goto end;
+
+sps = av_mallocz(sizeof(*sps));
+if (!sps)
+goto end;
+
+sps->profile_idc = get_bits(, 8);
+sps->constraint_set_flags |= get_bits1() << 0; // constraint_set0_flag
+sps->constraint_set_flags |= get_bits1() << 1; // constraint_set1_flag
+sps->constraint_set_flags |= get_bits1() << 2; // constraint_set2_flag
+sps->constraint_set_flags |= get_bits1() << 3; // constraint_set3_flag
+sps->constraint_set_flags |= get_bits1() << 4; // constraint_set4_flag
+sps->constraint_set_flags |= get_bits1() << 5; // constraint_set5_flag
+skip_bits(, 2); // reserved_zero_2bits
+sps->level_idc = get_bits(, 8);
+sps->id = get_ue_golomb_31();
+
+if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
+sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc 
==  44 ||
+sps->profile_idc ==  83 || sps->profile_idc ==  86 || sps->profile_idc 
== 118 ||
+sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc 
== 139 ||
+sps->profile_idc == 134) {
+sps->chroma_format_idc = get_ue_golomb_31(); // chroma_format_idc
+if (sps->chroma_format_idc == 3) {
+skip_bits1(); // separate_colour_plane_flag
+}
+sps->bit_depth_luma = get_ue_golomb() + 8;
+get_ue_golomb(); // bit_depth_chroma_minus8
+skip_bits1(); // qpprime_y_zero_transform_bypass_flag
+if (get_bits1()) { // seq_scaling_matrix_present_flag
+for (i = 0; i < ((sps->chroma_format_idc != 3) ? 8 : 12); i++) {
+if (get_bits1()) { // seq_scaling_list_present_flag
+lastScale = 8;
+nextScale = 8;
+sizeOfScalingList = i < 

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On Apr 9, 2019, at 6:27 PM, James Almer  wrote:
> 
> On 4/9/2019 9:40 PM, Baptiste Coudurier wrote:
>> 
>>> On Apr 9, 2019, at 5:24 PM, James Almer  wrote:
>>> 
>>> On 4/9/2019 8:59 PM, Baptiste Coudurier wrote:
>>>> 
>>>>> On Apr 9, 2019, at 4:51 PM, James Almer  wrote:
>>>>> 
>>>>> On 4/9/2019 8:22 PM, Baptiste Coudurier wrote:
>>>>>> Hi James,
>>>>>> 
>>>>>>> On Apr 9, 2019, at 4:09 PM, James Almer  wrote:
>>>>>>> 
>>>>>>>> […]
>>>>>>> 
>>>>>>> Ok so, the only fields you need from the sps are constraint_set_flags,
>>>>>>> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar,
>>>>>>> meaning you don't even need to parse the sps until the very end (sar is
>>>>>>> the furthest value, and right at the beginning of vui_parameters).
>>>>>>> I'd very much prefer if we can avoid making
>>>>>>> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets part
>>>>>>> of the ABI, so i think it's worth copying the required bitstream parsing
>>>>>>> code at least until the beginning of vui_parameters. It was done for
>>>>>>> hevc and av1, so it can be done for h264 as well.
>>>>>> 
>>>>>> Since vui parsing is needed, that would be the entire 
>>>>>> "ff_h264_decode_seq_parameter_set()” function.
>>>>> 
>>>>> If you only need up to sar, then yo don't need to parse the entire VUI.
>>>> 
>>>> It still requires copying the entire ff_h264_decode_seq_parameter_set(), 
>>>> even though the sub functions are not needed. 
>>>> 
>>>>>> 
>>>>>> I disagree with the copying. I also disagree with the copying for AVC1 
>>>>>> and HEVC btw.
>>>>> 
>>>>> Using avpriv opens a whole can of worms that will be unpredictable in
>>>>> the future. Just look at recent commits like
>>>>> f4ea930a119298c6110ee4e3d24219a66e27e230 that started storing previously
>>>>> skipped values. If hevc_pc was made avpriv for isombff/matroska muxing
>>>>> purposes and its structs part of the ABI, this wouldn't have been
>>>>> possible until a major bump.
>>>> 
>>>> When did the sharing policy between avformat and avcodec (in the sense 
>>>> avformat using avcodec) change ?
>>>> It seems perfectly natural to me to have libavformat require the 
>>>> libavcodec version that it was compiled with,
>>>> and check it at runtime.
>>> 
>>> More than one ffmpeg release will ship with libavcodec/libavformat
>>> sharing the same soname. Backwards compatibility is expected, hence the
>>> split between major, minor and micro, as you're meant to be able to drop
>>> a newer libavcodec library, say for example ffmpeg 4.1's
>>> libavcodec.58.so, and it should work with an existing libavformat.so.58
>>> that was linked against ffmpeg 4.0's libavcodec.58.so.
>> 
>> Sorry to repeat the question but when did that change ?
> 
> I don't know if it ever changed to being with. It's been like this for
> as long as i remember, and i don't recall inter-library version checks
> that would take minor and micro into consideration (which would be
> needed to truly tie a given libavformat library with the exact
> libavcodec it was linked to) whereas ABI backwards compatibility
> considerations for inter-library stuff can be seen all across the
> codebase and git history.

It definitely changed, probably around the introduction of “avpriv” prefix.

>> Which practical use case are we covering here ?
> 
> I don't know, i'm not a library user. But i know the main use case for
> the longest time was having ffmpeg work as a drop in replacement for
> libav back when the latter was shipped in debian and other ditros.
> 
>> You were never supposed to update libavcodec without updating libavformat
>> If you use libavformat in the first place.
>> Your problems are completely gone.
> 
> As i said, as far as i remember, you've been meant to do that just fine.
> Hence so much work about reducing the amount of exposed internal API,
> and plenty of preprocessor checks meant to remove unneeded avpriv
> symbols only after a major bump.

Well, AFAIR it was not the case, and IMHO it does not really make sense to
update libavcodec without libavformat.
I think all that w

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On Apr 9, 2019, at 5:24 PM, James Almer  wrote:
> 
> On 4/9/2019 8:59 PM, Baptiste Coudurier wrote:
>> 
>>> On Apr 9, 2019, at 4:51 PM, James Almer  wrote:
>>> 
>>> On 4/9/2019 8:22 PM, Baptiste Coudurier wrote:
>>>> Hi James,
>>>> 
>>>>> On Apr 9, 2019, at 4:09 PM, James Almer  wrote:
>>>>> 
>>>>>> […]
>>>>> 
>>>>> Ok so, the only fields you need from the sps are constraint_set_flags,
>>>>> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar,
>>>>> meaning you don't even need to parse the sps until the very end (sar is
>>>>> the furthest value, and right at the beginning of vui_parameters).
>>>>> I'd very much prefer if we can avoid making
>>>>> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets part
>>>>> of the ABI, so i think it's worth copying the required bitstream parsing
>>>>> code at least until the beginning of vui_parameters. It was done for
>>>>> hevc and av1, so it can be done for h264 as well.
>>>> 
>>>> Since vui parsing is needed, that would be the entire 
>>>> "ff_h264_decode_seq_parameter_set()” function.
>>> 
>>> If you only need up to sar, then yo don't need to parse the entire VUI.
>> 
>> It still requires copying the entire ff_h264_decode_seq_parameter_set(), 
>> even though the sub functions are not needed. 
>> 
>>>> 
>>>> I disagree with the copying. I also disagree with the copying for AVC1 and 
>>>> HEVC btw.
>>> 
>>> Using avpriv opens a whole can of worms that will be unpredictable in
>>> the future. Just look at recent commits like
>>> f4ea930a119298c6110ee4e3d24219a66e27e230 that started storing previously
>>> skipped values. If hevc_pc was made avpriv for isombff/matroska muxing
>>> purposes and its structs part of the ABI, this wouldn't have been
>>> possible until a major bump.
>> 
>> When did the sharing policy between avformat and avcodec (in the sense 
>> avformat using avcodec) change ?
>> It seems perfectly natural to me to have libavformat require the libavcodec 
>> version that it was compiled with,
>> and check it at runtime.
> 
> More than one ffmpeg release will ship with libavcodec/libavformat
> sharing the same soname. Backwards compatibility is expected, hence the
> split between major, minor and micro, as you're meant to be able to drop
> a newer libavcodec library, say for example ffmpeg 4.1's
> libavcodec.58.so, and it should work with an existing libavformat.so.58
> that was linked against ffmpeg 4.0's libavcodec.58.so.

Sorry to repeat the question but when did that change ?
Which practical use case are we covering here ?
You were never supposed to update libavcodec without updating libavformat
If you use libavformat in the first place.
Your problems are completely gone.

> 
>> 
>>> 
>>> sps parsing can and should be done in libavformat for this. Otherwise
>>> you'll be constraining future development in other areas. So please,
>>> take libavcodec/cbs_h264* and libavformat/av1.c as basis and write a
>>> simple sps parser that takes the raw bitstream values and does nothing
>>> else. You only need six values.
>> 
>> I disagree with the copying and we will need more opinions on this to settle
>> the argument, maybe a vote.
> 
> It's the cleanest way and the one used in all cases previous to this
> one.

We disagree here, there are at least 2 cleaner ways: not using AVCodecContext 
at all
in sps parsing or forcing libavcodec version.

> There has been work during the last bump to remove internal structs
> from the ABI precisely because they constrained development. Among them
> was GetBitsContext, which you're now trying to reintroduce and thus
> invalidate all that previous cleaning work, and only to get six values
> for a single muxer.

Adding fields are the end of structs does not break ABI, it’s been done for 
decades in FFmpeg.
Also looking at h264_ps.h:

[…]
int residual_color_transform_flag;///< residual_colour_transform_flag
int constraint_set_flags; ///< constraint_set[0-3]_flag
uint8_t data[4096];
size_t data_size;

Why are we wasting 4k here ? I’m trying to trace git logs but it seems to be 
originating
from a merge commit.

> Two thirds of SPS is not hard to implement, so i really don't understand
> why you're so adamantly against it.

I’m adamant about re-using code between libavcodec and libavformat.
Re-using code is _good_

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On Apr 9, 2019, at 4:51 PM, James Almer  wrote:
> 
> On 4/9/2019 8:22 PM, Baptiste Coudurier wrote:
>> Hi James,
>> 
>>> On Apr 9, 2019, at 4:09 PM, James Almer  wrote:
>>> 
>>>> […]
>>> 
>>> Ok so, the only fields you need from the sps are constraint_set_flags,
>>> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar,
>>> meaning you don't even need to parse the sps until the very end (sar is
>>> the furthest value, and right at the beginning of vui_parameters).
>>> I'd very much prefer if we can avoid making
>>> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets part
>>> of the ABI, so i think it's worth copying the required bitstream parsing
>>> code at least until the beginning of vui_parameters. It was done for
>>> hevc and av1, so it can be done for h264 as well.
>> 
>> Since vui parsing is needed, that would be the entire 
>> "ff_h264_decode_seq_parameter_set()” function.
> 
> If you only need up to sar, then yo don't need to parse the entire VUI.

It still requires copying the entire ff_h264_decode_seq_parameter_set(), even 
though the sub functions are not needed. 

>> 
>> I disagree with the copying. I also disagree with the copying for AVC1 and 
>> HEVC btw.
> 
> Using avpriv opens a whole can of worms that will be unpredictable in
> the future. Just look at recent commits like
> f4ea930a119298c6110ee4e3d24219a66e27e230 that started storing previously
> skipped values. If hevc_pc was made avpriv for isombff/matroska muxing
> purposes and its structs part of the ABI, this wouldn't have been
> possible until a major bump.

When did the sharing policy between avformat and avcodec (in the sense avformat 
using avcodec) change ?
It seems perfectly natural to me to have libavformat require the libavcodec 
version that it was compiled with,
and check it at runtime.

> 
> sps parsing can and should be done in libavformat for this. Otherwise
> you'll be constraining future development in other areas. So please,
> take libavcodec/cbs_h264* and libavformat/av1.c as basis and write a
> simple sps parser that takes the raw bitstream values and does nothing
> else. You only need six values.

I disagree with the copying and we will need more opinions on this to settle
the argument, maybe a vote.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

> On Apr 9, 2019, at 4:05 PM, Hendrik Leppkes  wrote:
> 
> On Wed, Apr 10, 2019 at 12:21 AM Baptiste Coudurier
>  wrote:
>> +return 0;
>> +}
>> +init_get_bits(, tmp, tmp_size*8);
>> +ret = avpriv_h264_decode_seq_parameter_set(, 
>> (AVCodecContext*)s, , 0);
> 
> The AVCodecContext cast looks like a recipe for disaster. The function
> is internal to the H264 decoder, so if it at some point decides to
> actually access the AVCodecContext it receives, or even worse, the
> priv_data element in it, expecting a H264Context, then everything goes
> to hell.
> Just another sign why exporting functions internal from a decoder is
> just an overall bad idea…

Calm down. AVCodecContext can be allocated in any case, for AV_CODEC_ID_H264.
The reason that function needs it in the first place is small.

Re-using code is _good_

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi James,

> On Apr 9, 2019, at 4:09 PM, James Almer  wrote:
> 
>> […]
> 
> Ok so, the only fields you need from the sps are constraint_set_flags,
> frame_mbs_only_flag, bit_depth_luma, profile_idc, level_idc and sar,
> meaning you don't even need to parse the sps until the very end (sar is
> the furthest value, and right at the beginning of vui_parameters).
> I'd very much prefer if we can avoid making
> ff_h264_decode_seq_parameter_set() avpriv and with it H264ParamSets part
> of the ABI, so i think it's worth copying the required bitstream parsing
> code at least until the beginning of vui_parameters. It was done for
> hevc and av1, so it can be done for h264 as well.

Since vui parsing is needed, that would be the entire 
"ff_h264_decode_seq_parameter_set()” function.

I disagree with the copying. I also disagree with the copying for AVC1 and HEVC 
btw.

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas, I hope you are doing well

> On Apr 4, 2019, at 7:27 AM, Thomas Mundt  wrote:
> 
> Hi Baptiste,
> 
> […]
> For RP2027 Class 100 1080/50i I still get the error: frame size does not
> match index unit size, 568832 != 0
> I used the following command:
> ffmpeg -f lavfi -i testsrc=size=1920x1080:rate=50 -vf interlace -c:v
> libx264 -pix_fmt yuv422p10 -flags +ildct+ilme -avcintra-class 100
> -color_primaries bt709 -color_trc bt709 -colorspace bt709 -x264-params
> overscan="crop":videoformat="component":fps=25/1:interlaced=1:tff=1:force-cfr=1
> -t 1 avci.mxf

I see, that’s the switch to CBR index.

> Also I encoded AVC High 422 Intra with the following command:
> ffmpeg lavfi -i testsrc=size=1920x1080:rate=50 -c:v libx264 -pix_fmt
> yuv422p -x264-params keyint=1 -t 1 avc.mxf
> Without your patch MediaInfo shows Format profile: High 4:2:2 Intra@L4.2.
> With your patch MediaInfo shows Format profile: High 4:2:2@L4.2 and
> Format_Profile_Original: High 4:2:2 Intra@L4.2.
> According to the MediaInfo documentation, the additional
> "Format_Profile_Original" is shown when two format profile infomations are
> found that do not match.
> 

Muxer uses ….32.30.01 UID which is High 422 Intra according to specs:

urn:smpte:ul:060e2b34.0401010a.04010202.01323001LEAFH.264/MPEG-4 
AVC High 422 Intra Profile Unconstrained CodingIdentifies H.264/MPEG-4 AVC 
High 422 Intra Profile Unconstrained Coding

So I’m not sure what media info is doing here.

— 
Baptiste

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

[Baptiste Coudurier]

Hi James, I hope you are doing well


> On Apr 3, 2019, at 6:59 AM, James Almer  wrote:
> 
> On 4/3/2019 9:25 AM, Baptiste Coudurier wrote:
>> Hey Hendrik
>> 
>>> On Apr 3, 2019, at 11:37 AM, Hendrik Leppkes  wrote:
>>> 
>>> On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
>>>  wrote:
>>>> 
>>>> ---
>>>> libavcodec/cbs_h2645.c | 28 ++--
>>>> libavcodec/extract_extradata_bsf.c |  4 ++--
>>>> libavcodec/h2645_parse.c   |  6 +++---
>>>> libavcodec/h2645_parse.h   |  6 +++---
>>>> libavcodec/h264_parse.c|  4 ++--
>>>> libavcodec/h264_parser.c   |  4 ++--
>>>> libavcodec/h264_ps.c   |  4 ++--
>>>> libavcodec/h264_ps.h   |  4 ++--
>>>> libavcodec/h264_slice.c|  2 +-
>>>> libavcodec/h264data.c  |  2 +-
>>>> libavcodec/h264data.h  |  3 ++-
>>>> libavcodec/h264dec.c   | 10 +-
>>>> libavcodec/hevc_parse.c|  2 +-
>>>> libavcodec/hevc_parser.c   |  4 ++--
>>>> libavcodec/hevcdec.c   |  4 ++--
>>>> libavcodec/svq3.c  |  2 +-
>>>> 16 files changed, 45 insertions(+), 44 deletions(-)
>>>> 
>>> 
>>> We prefer not to expose huge modules like this as avpriv, as it makes
>>> it part of the ABI and as such impossible to change without
>>> deprecation cycles.
>>> Preferably, avpriv should be avoided entirely where possible, as it
>>> has many of the same limitations as actual public API, and just adds
>>> confusion.
>> 
>> Understood. What’s the alternative ?
> 
> One usual solution is adding an avpriv_ wrapper for the internal
> function, like avpriv_ac3_parse_header() is done for
> ff_ac3_parse_header(), which prevents internal structs from being part
> of the ABI. But ff_h2645_packet_split() and
> ff_h264_decode_seq_parameter_set() don't allow for that, seeing
> H264ParamSets, H2645Packet, H2645RBSP and H2645NAL are complex and tend
> to get changes every now and then. The last time was only a few months ago.
> 
> Other than what you're doing in your patch, the only solution i can
> think of is duplicating the functionality. It wouldn't be the first, as
> you can see in avc.c, hevc.c, av1.c, where bitstream parsing was
> implemented in a reduced form exclusively for muxing purposes.

All right, I changed the code to avoid using ff_h2645_packet_split() and I 
found “nal_unit_extract_rbsp” in libavformat :)
I don’t think duplicating ff_h264_decode_seq_parameter would be good though so 
I still changed the prefix to avpriv.

Let me know if that works.

Thanks!

—
Baptiste


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/Makefile |   2 +-
 libavformat/avc.c|  32 +++
 libavformat/avc.h|   2 +
 libavformat/hevc.c   |  36 +---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 201 +--
 6 files changed, 193 insertions(+), 81 deletions(-)

diff --git a/libavformat/Makefile b/libavformat/Makefile
index c010fc83f9..f8539527bc 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -338,7 +338,7 @@ OBJS-$(CONFIG_MUSX_DEMUXER)  += musx.o
 OBJS-$(CONFIG_MV_DEMUXER)+= mvdec.o
 OBJS-$(CONFIG_MVI_DEMUXER)   += mvi.o
 OBJS-$(CONFIG_MXF_DEMUXER)   += mxfdec.o mxf.o
-OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o
+OBJS-$(CONFIG_MXF_MUXER) += mxfenc.o mxf.o audiointerleave.o 
avc.o
 OBJS-$(CONFIG_MXG_DEMUXER)   += mxg.o
 OBJS-$(CONFIG_NC_DEMUXER)+= ncdec.o
 OBJS-$(CONFIG_NISTSPHERE_DEMUXER)+= nistspheredec.o pcm.o
diff --git a/libavformat/avc.c b/libavformat/avc.c
index ec50033a04..6c97ae04ab 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -241,3 +241,35 @@ const uint8_t *ff_avc_mp4_find_startcode(const uint8_t 
*start,
 
 return start + res;
 }
+
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len)
+{
+uint8_t *dst;
+uint32_t i, len;
+
+dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!dst)
+return NULL;
+
+/* NAL unit header */
+i = len = 0;
+while (i < header_len && i < src_len)
+dst[len++] = src[i++];
+
+while (i + 2 < src_len)
+if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
+dst[len++] = src[i++];
+dst[len++] = src[i++];
+i++; // remove emulation_prevention_three_byte
+} else
+dst[len++] = src[i++];
+
+while (i < src_len)
+dst[len++] = src[i++];
+
+memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+
+*dst_len = len;
+return dst;
+}
diff --git a/libavformat/avc.h b/libavformat/avc.h
index c5e80ff650..9f9b4c0175 100644
--- a/libavformat/avc.h
+++ b/libavformat/avc.h
@@ -33,5 +33,7 @@ int ff_avc_write_annexb_extradata(const uint8_t *in, uint8_t 
**buf, int *size);
 const uint8_t *ff_avc_mp4_find_startcode(const uint8_t *start,
  const uint8_t *end,
  int nal_length_size);
+uint8_t *ff_nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
+  uint32_t *dst_len, int header_len);
 
 #endif /* AVFORMAT_AVC_H */
diff --git a/libavformat/hevc.c b/libavformat/hevc.c
index 3628d5a028..c7c4be3441 100644
--- a/libavformat/hevc.c
+++ b/libavformat/hevc.c
@@ -643,40 +643,6 @@ static int hvcc_parse_pps(GetBitContext *gb,
 return 0;
 }
 
-static uint8_t *nal_unit_extract_rbsp(const uint8_t *src, uint32_t src_len,
-  uint32_t *dst_len)
-{
-uint8_t *dst;
-uint32_t i, len;
-
-dst = av_malloc(src_len + AV_INPUT_BUFFER_PADDING_SIZE);
-if (!dst)
-return NULL;
-
-/* NAL unit header (2 bytes) */
-i = len = 0;
-while (i < 2 && i < src_len)
-dst[len++] = src[i++];
-
-while (i + 2 < src_len)
-if (!src[i] && !src[i + 1] && src[i + 2] == 3) {
-dst[len++] = src[i++];
-dst[len++] = src[i++];
-i++; // remove emulation_prevention_three_byte
-} else
-dst[len++] = src[i++];
-
-while (i < src_len)
-dst[len++] = src[i++];
-
-memset(dst + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-
-*dst_len = len;
-return dst;
-}
-
-
-
 static void nal_unit_parse_header(GetBitContext *gb, uint8_t *nal_type)
 {
 skip_bits1(gb); // forbidden_zero_bit
@@ -753,7 +719,7 @@ static int hvcc_add_nal_unit(uint8_t *nal_buf, uint32_t 
nal_size,
 uint8_t *rbsp_buf;
 uint32_t rbsp_size;
 
-rbsp_buf = nal_unit_extract_rbsp(nal_buf, nal_size, _size);
+rbsp_buf = ff_nal_unit_extract_rbsp(nal_buf, nal_size, _size, 2);
 if (!rbsp_buf) {
 ret = AVERROR(ENOMEM);
 goto end;
diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 4394450dea..f32124f772 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -48,6 +48,7 @@ enum MXFMetadataSetType {
 EssenceGroup,
 TaggedValue,
 TapeDescriptor,
+AVCSubDescriptor,
 };
 
 enum MXFFrameLayout {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 8c6db94865..8f565e39f8 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -49,12 +49,14 @@
 #include "libavcodec/bytestream.h"
 #include "libavcodec/dnxhddata.h"
 #include "libavcodec/dv_profile.h"
-#include "libavcodec/h264.h"
+#include "libavcodec/h264_ps.h"
+#include "libavcodec/golomb.h"
 #include "libavcodec/internal.h"
 #include "audiointerleave.h"
 #include "avformat.h"
 #include 

[FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

[Baptiste Coudurier]

---
 libavcodec/h264_parse.c  | 2 +-
 libavcodec/h264_parser.c | 2 +-
 libavcodec/h264_ps.c | 4 ++--
 libavcodec/h264_ps.h | 4 ++--
 libavcodec/h264dec.c | 6 +++---
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index a075443d17..0f008c29f3 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -374,7 +374,7 @@ static int decode_extradata_ps(const uint8_t *data, int 
size, H264ParamSets *ps,
 H2645NAL *nal = [i];
 switch (nal->type) {
 case H264_NAL_SPS:
-ret = ff_h264_decode_seq_parameter_set(>gb, logctx, ps, 0);
+ret = avpriv_h264_decode_seq_parameter_set(>gb, logctx, ps, 
0);
 if (ret < 0)
 goto fail;
 break;
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 5f9a9c46ef..814584cc82 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -323,7 +323,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
 
 switch (nal.type) {
 case H264_NAL_SPS:
-ff_h264_decode_seq_parameter_set(, avctx, >ps, 0);
+avpriv_h264_decode_seq_parameter_set(, avctx, >ps, 0);
 break;
 case H264_NAL_PPS:
 ff_h264_decode_picture_parameter_set(, avctx, >ps,
diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 17bfa780ce..980b1e189d 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -330,8 +330,8 @@ void ff_h264_ps_uninit(H264ParamSets *ps)
 ps->sps = NULL;
 }
 
-int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
- H264ParamSets *ps, int ignore_truncation)
+int avpriv_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext 
*avctx,
+ H264ParamSets *ps, int 
ignore_truncation)
 {
 AVBufferRef *sps_buf;
 int profile_idc, level_idc, constraint_set_flags = 0;
diff --git a/libavcodec/h264_ps.h b/libavcodec/h264_ps.h
index e967b9cbcf..d422ce122e 100644
--- a/libavcodec/h264_ps.h
+++ b/libavcodec/h264_ps.h
@@ -149,8 +149,8 @@ typedef struct H264ParamSets {
 /**
  * Decode SPS
  */
-int ff_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext *avctx,
- H264ParamSets *ps, int ignore_truncation);
+int avpriv_h264_decode_seq_parameter_set(GetBitContext *gb, AVCodecContext 
*avctx,
+ H264ParamSets *ps, int 
ignore_truncation);
 
 /**
  * Decode PPS
diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
index 837c3b7538..2e82e118b7 100644
--- a/libavcodec/h264dec.c
+++ b/libavcodec/h264dec.c
@@ -716,14 +716,14 @@ static int decode_nal_units(H264Context *h, const uint8_t 
*buf, int buf_size)
 if (ret < 0)
 goto end;
 }
-if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 0) >= 
0)
+if (avpriv_h264_decode_seq_parameter_set(_gb, avctx, >ps, 
0) >= 0)
 break;
 av_log(h->avctx, AV_LOG_DEBUG,
"SPS decoding failure, trying again with the complete 
NAL\n");
 init_get_bits8(_gb, nal->raw_data + 1, nal->raw_size - 1);
-if (ff_h264_decode_seq_parameter_set(_gb, avctx, >ps, 0) >= 
0)
+if (avpriv_h264_decode_seq_parameter_set(_gb, avctx, >ps, 
0) >= 0)
 break;
-ff_h264_decode_seq_parameter_set(>gb, avctx, >ps, 1);
+avpriv_h264_decode_seq_parameter_set(>gb, avctx, >ps, 1);
 break;
 }
 case H264_NAL_PPS:
-- 
2.20.1 (Apple Git-117)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

[Baptiste Coudurier]

Hey Hendrik

> On Apr 3, 2019, at 11:37 AM, Hendrik Leppkes  wrote:
> 
> On Wed, Apr 3, 2019 at 11:22 AM Baptiste Coudurier
>  wrote:
>> 
>> ---
>> libavcodec/cbs_h2645.c | 28 ++--
>> libavcodec/extract_extradata_bsf.c |  4 ++--
>> libavcodec/h2645_parse.c   |  6 +++---
>> libavcodec/h2645_parse.h   |  6 +++---
>> libavcodec/h264_parse.c|  4 ++--
>> libavcodec/h264_parser.c   |  4 ++--
>> libavcodec/h264_ps.c   |  4 ++--
>> libavcodec/h264_ps.h   |  4 ++--
>> libavcodec/h264_slice.c|  2 +-
>> libavcodec/h264data.c  |  2 +-
>> libavcodec/h264data.h  |  3 ++-
>> libavcodec/h264dec.c   | 10 +-
>> libavcodec/hevc_parse.c|  2 +-
>> libavcodec/hevc_parser.c   |  4 ++--
>> libavcodec/hevcdec.c   |  4 ++--
>> libavcodec/svq3.c  |  2 +-
>> 16 files changed, 45 insertions(+), 44 deletions(-)
>> 
> 
> We prefer not to expose huge modules like this as avpriv, as it makes
> it part of the ABI and as such impossible to change without
> deprecation cycles.
> Preferably, avpriv should be avoided entirely where possible, as it
> has many of the same limitations as actual public API, and just adds
> confusion.

Understood. What’s the alternative ?

Thanks!

— 
Baptiste
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas,

> On Apr 1, 2019, at 4:10 PM, Thomas Mundt  wrote:
> 
> Am Sa., 30. März 2019 um 17:52 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com <mailto:baptiste.coudur...@gmail.com>>:
> 
>> Hi Thomas,
>> 
>>> On Mar 29, 2019, at 1:11 PM, Thomas Mundt  wrote:
>>> 
>>> 
>>> […]
>>> 
>>>> 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
>>>> }, 568832, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 1080/25p
>>>> +{{
>>>> 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
>>>> }, 236544, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100
>> 720/59.94p
>>>> +{{
>>>> 
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
>>>> }, 284672, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 720/50p
>>>> 
>>> 
>>> Maybe i miss something, but doesn´t the setting of the profile for all
>> AVC
>>> Intra codec ULs make the for-loop to always select the last AVC Intra
>>> codec UL (720/50p) for AVC High 422 Intra?
>> 
>> The frame size check prevents that.
>> 
> 
> The frame size check in the first condition of the for-loop works for fixed
> frame size RP2027. However, with free frame size AVC High 422 Intra, the
> second condition in the for-loop only checks for profile and intra-only.
> Since the second condition doesn´t break the for-loop, the last UL with
> matching profile and intra-only flag is set.
> 
> I wanted to test this behavior, so I applied this patch to
> cf81284b1c14ef28d3f94e6d28c46188ba4e82f2, which is the last one that can be
> compiled.
> Unfortunately I was not able to produce any h264 mxf with this patch.
> E.g. the following command works perfect without this patch:
> ffmpeg -f lavfi -i testsrc=size=3840x2160:rate=50 -c:v libx264 -pix_fmt
> yuv422p10 -x264-params keyint=1 -t 1 avc.mxf
> With this patch I get errors: h264 profile not supported, could not get
> h264 profile.
> Same with other formats or long gop.
> RP2027 Class 100 1080/50i shows the following error: frame size does not
> match index unit size, 568832 != 0


Right, a few things have changed in the muxer in the mean time. I updated the 
patch and sent it.

Thanks a lot!

—
Baptiste






signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/h264_parse: change prefix to avpriv for usage in avformat mxf muxer

[Baptiste Coudurier]

---
 libavcodec/cbs_h2645.c | 28 ++--
 libavcodec/extract_extradata_bsf.c |  4 ++--
 libavcodec/h2645_parse.c   |  6 +++---
 libavcodec/h2645_parse.h   |  6 +++---
 libavcodec/h264_parse.c|  4 ++--
 libavcodec/h264_parser.c   |  4 ++--
 libavcodec/h264_ps.c   |  4 ++--
 libavcodec/h264_ps.h   |  4 ++--
 libavcodec/h264_slice.c|  2 +-
 libavcodec/h264data.c  |  2 +-
 libavcodec/h264data.h  |  3 ++-
 libavcodec/h264dec.c   | 10 +-
 libavcodec/hevc_parse.c|  2 +-
 libavcodec/hevc_parser.c   |  4 ++--
 libavcodec/hevcdec.c   |  4 ++--
 libavcodec/svq3.c  |  2 +-
 16 files changed, 45 insertions(+), 44 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index e74f8dce81..d1f7b2138f 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -599,9 +599,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell();
 
-err = ff_h2645_packet_split(>read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 1, 
1);
+err = avpriv_h2645_packet_split(>read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 
1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split AVCC SPS 
array.\n");
 return err;
@@ -623,9 +623,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell();
 
-err = ff_h2645_packet_split(>read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 1, 
1);
+err = avpriv_h2645_packet_split(>read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, AV_CODEC_ID_H264, 
1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split AVCC PPS 
array.\n");
 return err;
@@ -677,9 +677,9 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 }
 end = bytestream2_tell();
 
-err = ff_h2645_packet_split(>read_packet,
-frag->data + start, end - start,
-ctx->log_ctx, 1, 2, AV_CODEC_ID_HEVC, 
1, 1);
+err = avpriv_h2645_packet_split(>read_packet,
+frag->data + start, end - start,
+ctx->log_ctx, 1, 2, 
AV_CODEC_ID_HEVC, 1, 1);
 if (err < 0) {
 av_log(ctx->log_ctx, AV_LOG_ERROR, "Failed to split "
"HVCC array %d (%d NAL units of type %d).\n",
@@ -694,11 +694,11 @@ static int cbs_h2645_split_fragment(CodedBitstreamContext 
*ctx,
 } else {
 // Annex B, or later MP4 with already-known parameters.
 
-err = ff_h2645_packet_split(>read_packet,
-frag->data, frag->data_size,
-ctx->log_ctx,
-priv->mp4, priv->nal_length_size,
-codec_id, 1, 1);
+err = avpriv_h2645_packet_split(>read_packet,
+frag->data, frag->data_size,
+ctx->log_ctx,
+priv->mp4, priv->nal_length_size,
+codec_id, 1, 1);
 if (err < 0)
 return err;
 
diff --git a/libavcodec/extract_extradata_bsf.c 
b/libavcodec/extract_extradata_bsf.c
index 17e5deb96b..01ef9bed2a 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -156,8 +156,8 @@ static int extract_extradata_h2645(AVBSFContext *ctx, 
AVPacket *pkt,
 nb_extradata_nal_types = FF_ARRAY_ELEMS(extradata_nal_types_h264);
 }
 
-ret = ff_h2645_packet_split(>h2645_pkt, pkt->data, pkt->size,
-ctx, 0, 0, ctx->par_in->codec_id, 1, 0);
+ret = avpriv_h2645_packet_split(>h2645_pkt, pkt->data, pkt->size,
+ctx, 0, 0, ctx->par_in->codec_id, 1, 0);
 if (ret < 0)
 return ret;
 
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 24658b3dfa..a20a262af1 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -385,9 +385,9 @@ fail:
 return;
 }
 
-int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t *buf, int length,
-  void *logctx, int is_nalff, int nal_length_size,

[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 197 ---
 2 files changed, 147 insertions(+), 51 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 4394450dea..f32124f772 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -48,6 +48,7 @@ enum MXFMetadataSetType {
 EssenceGroup,
 TaggedValue,
 TapeDescriptor,
+AVCSubDescriptor,
 };
 
 enum MXFFrameLayout {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 8c6db94865..1f865a0ad1 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -49,7 +49,10 @@
 #include "libavcodec/bytestream.h"
 #include "libavcodec/dnxhddata.h"
 #include "libavcodec/dv_profile.h"
-#include "libavcodec/h264.h"
+#include "libavcodec/golomb.h"
+#include "libavcodec/h264data.h"
+#include "libavcodec/h264_ps.h"
+#include "libavcodec/h2645_parse.h"
 #include "libavcodec/internal.h"
 #include "audiointerleave.h"
 #include "avformat.h"
@@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
 int max_gop; ///< maximum gop size, used by mpeg-2 descriptor
 int b_picture_count; ///< maximum number of consecutive b pictures, 
used in mpeg-2 descriptor
 int low_delay;   ///< low delay, used in mpeg-2 descriptor
+int avc_intra;
 } MXFStreamContext;
 
 typedef struct MXFContainerEssenceEntry {
@@ -167,6 +171,7 @@ static const struct {
 static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
+static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
@@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00 
},
-  mxf_write_mpegvideo_desc },
+  mxf_write_h264_desc },
 // S436M ANC
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00 
},
@@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x8006, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
 /* MaxGOP */
 { 0x8007, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
 /* ProfileAndLevel */
 { 0x8008, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
 /* BPictureCount */
+// Generic Descriptor
+{ 0x8100, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
 /* SubDescriptors */
+// AVC SubDescriptor
+{ 0x8200, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
 /* AVC Decoding Delay */
+{ 0x8201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
 /* AVC Profile */
+{ 0x8202, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
 /* AVC Level */
 // Wave Audio Essence Descriptor
 { 0x3D09, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
 /* Average Bytes Per Second */
 { 0x3D0A, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
 /* Block Align */
@@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,
 static const UID mxf_cdci_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00 
};
 static const UID mxf_generic_sound_descriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00 
};
 
+static const UID mxf_avc_subdescriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00 
};
+
 static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
 {
 switch (trc){
@@ -1317,6 +1330,13 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 avio_w8(pb, sc->field_dominance);
 }
 
+if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
+// write avc sub descriptor ref
+mxf_write_local_tag(pb, 8 + 16, 0x8100);
+mxf_write_refs_count(pb, 1);
+mxf_write_uuid(pb, AVCSubDescriptor, 0);
+}
+
 return pos;
 }
 
@@ -1329,10 +1349,50 @@ static void mxf_update_klv_size(AVIOContext *pb, 
int64_t pos)
 avio_seek(pb, cur_pos, SEEK_SET);
 }
 
+static 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hi Thomas,

> On Mar 29, 2019, at 1:11 PM, Thomas Mundt  wrote:
> 
>
> […]
>
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x04
>> }, 568832, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 1080/25p
>> +{{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x08
>> }, 236544, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 720/59.94p
>> +{{
>> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x32,0x31,0x09
>> }, 284672, 122, 0,  1 }, // AVC High 422 Intra RP2027 Class 100 720/50p
>> 
> 
> Maybe i miss something, but doesn´t the setting of the profile for all AVC
> Intra codec ULs make the for-loop to always select the last AVC Intra
> codec UL (720/50p) for AVC High 422 Intra?

The frame size check prevents that.

—
Baptiste Coudurier


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

Hey Tomas, I hope you are doing well

> On Mar 29, 2019, at 2:41 AM, Tomas Härdin  wrote:
> 
> tor 2019-03-28 klockan 08:50 -0700 skrev Baptiste Coudurier:
>> ---
>>  libavformat/mxf.h|   1 +
>>  libavformat/mxfenc.c | 194 ---
>>  2 files changed, 145 insertions(+), 50 deletions(-)
>> 
>> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
>> index 4394450dea..f32124f772 100644
>> --- a/libavformat/mxf.h
>> +++ b/libavformat/mxf.h
>> @@ -1317,6 +1330,13 @@ static int64_t mxf_write_cdci_common(AVFormatContext 
>> *s, AVStream *st, const UID
>>  avio_w8(pb, sc->field_dominance);
>>  }
>> 
>> +if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
>> +// write avc sub descriptor ref
>> +mxf_write_local_tag(pb, 8 + 16, 0x8100);
>> +mxf_write_refs_count(pb, 1);
>> +mxf_write_uuid(pb, AVCSubDescriptor, 0);
>> +}
> 
> Should this always be written for long gop AVC? Not just XAVC? Same
> goes for mxf_write_avc_subdesc() I think, unless I'm reading this 
> incorrectly..

The code will write always write it for AV_CODEC_ID_H264 except if it is 
avc_intra (it uses the legacy mpegvideo desc),
so it will always be written for long gop as well. There is no check for XAVC 
technically.

>>  static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st)
>> @@ -2136,30 +2196,30 @@ static const struct {
>>  int frame_size;
>>  int profile;
>>  uint8_t interlaced;
>> -int long_gop; // 1 or 0 when there are separate UIDs for Long GOP and 
>> Intra, -1 when Intra/LGOP detection can be ignored
>> +int intra_only; // 1 or 0 when there are separate UIDs for Long GOP and 
>> Intra, -1 when Intra/LGOP detection can be ignored
> 
> Any particular reason for inverting this logic? Leaving it as is would
> make the patch smaller..
> 
> /Tomas

Checking long gop looks weird to me since the specs don’t make that 
distinction, they do however make the explicit distinction for intra only
profile, so it feels more intuitive to mark them intra only. No strong opinion 
though.

Thanks a lot!

—
Baptiste Coudurier


signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/mxfenc: support XAVC long gop

[Baptiste Coudurier]

---
 libavformat/mxf.h|   1 +
 libavformat/mxfenc.c | 194 ---
 2 files changed, 145 insertions(+), 50 deletions(-)

diff --git a/libavformat/mxf.h b/libavformat/mxf.h
index 4394450dea..f32124f772 100644
--- a/libavformat/mxf.h
+++ b/libavformat/mxf.h
@@ -48,6 +48,7 @@ enum MXFMetadataSetType {
 EssenceGroup,
 TaggedValue,
 TapeDescriptor,
+AVCSubDescriptor,
 };
 
 enum MXFFrameLayout {
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 8c6db94865..b2e818a8a5 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -49,7 +49,10 @@
 #include "libavcodec/bytestream.h"
 #include "libavcodec/dnxhddata.h"
 #include "libavcodec/dv_profile.h"
-#include "libavcodec/h264.h"
+#include "libavcodec/golomb.h"
+#include "libavcodec/h264data.h"
+#include "libavcodec/h264_ps.h"
+#include "libavcodec/h2645_parse.h"
 #include "libavcodec/internal.h"
 #include "audiointerleave.h"
 #include "avformat.h"
@@ -99,6 +102,7 @@ typedef struct MXFStreamContext {
 int max_gop; ///< maximum gop size, used by mpeg-2 descriptor
 int b_picture_count; ///< maximum number of consecutive b pictures, 
used in mpeg-2 descriptor
 int low_delay;   ///< low delay, used in mpeg-2 descriptor
+int avc_intra;
 } MXFStreamContext;
 
 typedef struct MXFContainerEssenceEntry {
@@ -167,6 +171,7 @@ static const struct {
 static void mxf_write_wav_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_aes3_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_mpegvideo_desc(AVFormatContext *s, AVStream *st);
+static void mxf_write_h264_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_cdci_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_generic_sound_desc(AVFormatContext *s, AVStream *st);
 static void mxf_write_s436m_anc_desc(AVFormatContext *s, AVStream *st);
@@ -310,7 +315,7 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x10,0x60,0x01 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x00,0x00,0x00 
},
-  mxf_write_mpegvideo_desc },
+  mxf_write_h264_desc },
 // S436M ANC
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x0D,0x01,0x03,0x01,0x02,0x0e,0x00,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00 
},
@@ -498,6 +503,12 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x8006, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x08,0x00,0x00}},
 /* MaxGOP */
 { 0x8007, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x0A,0x00,0x00}},
 /* ProfileAndLevel */
 { 0x8008, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x01,0x06,0x02,0x01,0x09,0x00,0x00}},
 /* BPictureCount */
+// Generic Descriptor
+{ 0x8100, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
 /* SubDescriptors */
+// AVC SubDescriptor
+{ 0x8200, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0E,0x00,0x00}},
 /* AVC Decoding Delay */
+{ 0x8201, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0A,0x00,0x00}},
 /* AVC Profile */
+{ 0x8202, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x0E,0x04,0x01,0x06,0x06,0x01,0x0D,0x00,0x00}},
 /* AVC Level */
 // Wave Audio Essence Descriptor
 { 0x3D09, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x03,0x05,0x00,0x00,0x00}},
 /* Average Bytes Per Second */
 { 0x3D0A, 
{0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x02,0x01,0x00,0x00,0x00}},
 /* Block Align */
@@ -1126,6 +1137,8 @@ static const UID mxf_aes3_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,
 static const UID mxf_cdci_descriptor_key  = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00 
};
 static const UID mxf_generic_sound_descriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00 
};
 
+static const UID mxf_avc_subdescriptor_key = { 
0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00 
};
+
 static int get_trc(UID ul, enum AVColorTransferCharacteristic trc)
 {
 switch (trc){
@@ -1317,6 +1330,13 @@ static int64_t mxf_write_cdci_common(AVFormatContext *s, 
AVStream *st, const UID
 avio_w8(pb, sc->field_dominance);
 }
 
+if (st->codecpar->codec_id == AV_CODEC_ID_H264 && !sc->avc_intra) {
+// write avc sub descriptor ref
+mxf_write_local_tag(pb, 8 + 16, 0x8100);
+mxf_write_refs_count(pb, 1);
+mxf_write_uuid(pb, AVCSubDescriptor, 0);
+}
+
 return pos;
 }
 
@@ -1329,10 +1349,50 @@ static void mxf_update_klv_size(AVIOContext *pb, 
int64_t pos)
 avio_seek(pb, cur_pos, SEEK_SET);
 }
 
+static 

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.

[Baptiste Coudurier]

Hi Niki,


> On Feb 4, 2019, at 6:03 PM, Niki Bowe  wrote:
> 
> Hi Baptiste. 
> I agree. This patch does cause it to fail in mov_write_header in the given 
> example, by propagating the errors returned from mov_write_ac3_tag.
> 
> It is not always extradata related.
> Eg EAC3 parses the packets during muxing to build the dec3 atom. Perhaps this 
> should be made extradata, but its not today.
> A definitely not extradata related example: mov_write_tmcd_tag can fail for 
> fps reasons.
> Many atom writing functions can fail and return error codes, but today very 
> little error checking exists.

Ok, patch looks good to me.

Thanks a lot!

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

Re: [FFmpeg-devel] [PATCH] avformat/movenc: Add more error checking when writing sample entries.

[Baptiste Coudurier]

Hi Nikolas,

> On Feb 4, 2019, at 5:02 PM, Nikolas Bowe  
> wrote:
> 
> Fixes a problem where a sample entry which cannot be written correctly 
> appears to succeed, but produces an invalid file.
> For example, this command:
> ffmpeg -f lavfi -i sine=frequency=1000:duration=5 -codec:a ac3 -movflags 
> +empty_moov -frag_duration 500 /tmp/foo.mp4
> produced a file with the ac-3 sample entry, but no AC3SpecificBox (dac3) 
> child, which is invalid according to ETSI TS 102 366.

Ideally I feel that the code you fail as early as possible, so ideally fail 
during “mov_write_header” if the issue is extradata related.

[…]

— 
Baptiste

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak

[Baptiste Coudurier]

Hi Chris,

> On Dec 14, 2018, at 3:12 PM, Chris Cunningham  
> wrote:
> 
>> 
>> from a quick look, i did not find a file this breaks
>> 
> 
> Woot.  Baptiste, I'm happy with this last patch if you are.

Yes, looks great.

Thanks a lot!

— 
Baptiste Coudurier

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak

[Baptiste Coudurier]

Hey guys,

> On Dec 13, 2018, at 11:40 AM, Chris Cunningham  
> wrote:
> 
>> I have at least 2 files which have a id of 0
>> Iam not sure where they are from so iam not sure i can share them

Does Quicktime play them ? If not they are broken files.

> This was my fear as well. Also, we currently default the ID for a new
> stream to be the number of streams now in the list. I worried that some
> files may lack a tkhd or could be structured in such a way that they're
> dependent on this defaulting and might break if I instead defaulted to
> zero.

Lacking a tkhd is a broken file, and I know that FFmpeg has a policy of trying 
to play broken files.
Now the good thing is that mp4 is supported everywhere and many other demuxer 
just refuse to play broken files :)

The main issue with this new field is that it really looks like a hack.
They are also many atoms that are not supposed to appear twice in a file and 
can break
the code down the flow, so should we add “has_” for all of them ?

"st->id" is not necessary for demuxing AFAIK, please correct me if Im wrong.
Would an init value to -1 for st->id work ?

Thanks!

— 
Baptiste

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: ensure only one tkhd per trak

[Baptiste Coudurier]

Hi,

> On Dec 12, 2018, at 6:53 PM, chcunningham  wrote:
> 
> Chromium fuzzing produced a whacky file with extra tkhds. This caused
> an AVStream that was already in use to be corrupted by assigning it a
> new id, which blows up later in mov_read_trun because the
> MOVFragmentStreamInfo.index_entry now points OOB.
> ---
> libavformat/isom.h | 3 ++-
> libavformat/mov.c  | 7 +++
> 2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index e629663949..e14d670f2f 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -230,7 +230,8 @@ typedef struct MOVStreamContext {
> 
> uint32_t format;
> 
> -int has_sidx;  // If there is an sidx entry for this stream.
> +int has_sidx;  ///< If there is a sidx entry for this stream.
> +int has_tkhd;  ///< If there is a tkhd entry for this stream.
> struct {
> struct AVAESCTR* aes_ctr;
> unsigned int per_sample_iv_size;  // Either 0, 8, or 16.
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ec57a05803..47c53d7992 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -4438,6 +4438,12 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext 
> *pb, MOVAtom atom)
> st = c->fc->streams[c->fc->nb_streams-1];
> sc = st->priv_data;
> 
> +// Each stream (trak) should have exactly 1 tkhd. This catches bad files 
> and
> +// avoids corrupting AVStreams mapped to an earlier tkhd.
> +if (sc->has_tkhd)
> +return AVERROR_INVALIDDATA;
> +sc->has_tkhd = 1;
> +
> 

Could we just check that st->id is already set ? IIRC 0 is not a valid value

Thanks a lot!

— 
Baptiste

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

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

[Baptiste Coudurier]

On Wed, Dec 5, 2018 at 3:17 PM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul
> >
> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/mxfdec.c | 12 
> >>  1 file changed, 12 insertions(+)
> >>
> >> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> >> index f49890e140..abb030b1a4 100644
> >> --- a/libavformat/mxfdec.c
> >> +++ b/libavformat/mxfdec.c
> >> @@ -2432,6 +2432,18 @@ static int
> mxf_parse_structural_metadata(MXFContext
> >> *mxf)
> >>  default:
> >>  av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout
> >> type: %d\n", descriptor->frame_layout);
> >>  }
> >> +
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
> >> +switch (descriptor->essence_codec_ul[14]) {
> >> +case 1: st->codecpar->profile =
> FF_PROFILE_PRORES_PROXY;
> >>   break;
> >> +case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;
> >>break;
> >> +case 3: st->codecpar->profile =
> >> FF_PROFILE_PRORES_STANDARD; break;
> >> +case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;
> >>break;
> >> +case 5: st->codecpar->profile = FF_PROFILE_PRORES_;
> >>break;
> >> +case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;
> >>break;
> >> +}
> >> +}
> >> +
> >
> >
> >  I'm not sure about that, we don't do it for any other codec. IMHO it
> > should be in the decoder/parser.
>
> profile is not stored in bitstream AFAIK so only way it is set is via
> demuxer via codec_tag.
> MXF does not use codec_tags. So only this way is available.
>

Seems like decoder sets it from MOV fourcc, so I think it should be fine.

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Baptiste Coudurier]

On Thu, Dec 6, 2018 at 7:45 AM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul,
> >
> > On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:
> >
> >> On 12/6/18, Baptiste Coudurier  wrote:
> >> > Hi Paul
> >> >
> >> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >> >
> >> >> Signed-off-by: Paul B Mahol 
> >> >> ---
> >> >>  libavformat/mxfenc.c | 49
> 
> >> >>  1 file changed, 49 insertions(+)
> >> >>
> >> >> [...]
> >> >>
> >> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> >> >> AVPacket *pkt)
> >> >> +{
> >> >> +MXFContext *mxf = s->priv_data;
> >> >> +MXFStreamContext *sc = st->priv_data;
> >> >> +int i, profile;
> >> >> +
> >> >> +if (mxf->header_written)
> >> >> +return 1;
> >> >> +
> >> >> +sc->codec_ul = NULL;
> >> >> +profile = st->codecpar->profile;
> >> >>
> >> >
> >> > We should fetch the profile from the bitstream.
> >> >
> >>
> >> AFAIK profile is not stored in it.
> >>
> >
> > Right. My thinking is how would this work going from MOV to MXF ? Or
> would
> > it work when encoding ?
>
> It works when encoding and stream copying, last time I tried.
>

After looking at the code, it seems like it would work assuming essence
comes from MXF or MOV,
raw would not work though but we can accept that.

So I think the patch is fine, as well as the demuxer one, could you please
apply the demuxer one first ?

Thanks!

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Baptiste Coudurier]

Hi Paul,

On Wed, Dec 5, 2018 at 3:18 PM Paul B Mahol  wrote:

> On 12/6/18, Baptiste Coudurier  wrote:
> > Hi Paul
> >
> > On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:
> >
> >> Signed-off-by: Paul B Mahol 
> >> ---
> >>  libavformat/mxfenc.c | 49 
> >>  1 file changed, 49 insertions(+)
> >>
> >> [...]
> >>
> >> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> >> AVPacket *pkt)
> >> +{
> >> +MXFContext *mxf = s->priv_data;
> >> +MXFStreamContext *sc = st->priv_data;
> >> +int i, profile;
> >> +
> >> +if (mxf->header_written)
> >> +return 1;
> >> +
> >> +sc->codec_ul = NULL;
> >> +profile = st->codecpar->profile;
> >>
> >
> > We should fetch the profile from the bitstream.
> >
>
> AFAIK profile is not stored in it.
>

Right. My thinking is how would this work going from MOV to MXF ? Or would
it work when encoding ?

Thanks!

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

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: set profile for prores codec

[Baptiste Coudurier]

Hi Paul

On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mxfdec.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index f49890e140..abb030b1a4 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2432,6 +2432,18 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
>  default:
>  av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout
> type: %d\n", descriptor->frame_layout);
>  }
> +
> +if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
> +switch (descriptor->essence_codec_ul[14]) {
> +case 1: st->codecpar->profile = FF_PROFILE_PRORES_PROXY;
>   break;
> +case 2: st->codecpar->profile = FF_PROFILE_PRORES_LT;
>break;
> +case 3: st->codecpar->profile =
> FF_PROFILE_PRORES_STANDARD; break;
> +case 4: st->codecpar->profile = FF_PROFILE_PRORES_HQ;
>break;
> +case 5: st->codecpar->profile = FF_PROFILE_PRORES_;
>break;
> +case 6: st->codecpar->profile = FF_PROFILE_PRORES_XQ;
>break;
> +}
> +}
> +


 I'm not sure about that, we don't do it for any other codec. IMHO it
should be in the decoder/parser.

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

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: allow muxing prores

[Baptiste Coudurier]

Hi Paul

On Wed, Dec 5, 2018 at 9:52 AM Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/mxfenc.c | 49 
>  1 file changed, 49 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..e481b19ff3 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -146,6 +146,7 @@ enum ULIndex {
>  INDEX_JPEG2000,
>  INDEX_H264,
>  INDEX_S436M,
> +INDEX_PRORES,
>  };
>
>  static const struct {
> @@ -159,6 +160,7 @@ static const struct {
>  { AV_CODEC_ID_DNXHD,  INDEX_DNXHD },
>  { AV_CODEC_ID_JPEG2000,   INDEX_JPEG2000 },
>  { AV_CODEC_ID_H264,   INDEX_H264 },
> +{ AV_CODEC_ID_PRORES, INDEX_PRORES },
>  { AV_CODEC_ID_NONE }
>  };
>
> @@ -314,6 +316,11 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
>{
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x17,0x01,0x02,0x00
> },
>{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0a,0x04,0x01,0x02,0x02,0x01,0x01,0x5C,0x00
> },
>mxf_write_s436m_anc_desc },
> +// ProRes
> +{ {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x0d,0x01,0x03,0x01,0x02,0x1c,0x01,0x00
> },
> +  {
> 0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x17,0x00
> },
> +  {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
> },
> +  mxf_write_cdci_desc },
>  { {
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
>{
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
>{
> 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
> },
> @@ -1945,6 +1952,43 @@ static int mxf_write_partition(AVFormatContext *s,
> int bodysid,
>  return 0;
>  }
>
> +static const struct {
> +int profile;
> +UID codec_ul;
> +} mxf_prores_codec_uls[] = {
> +{ FF_PROFILE_PRORES_PROXY,{
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x01,0x00
> } },
> +{ FF_PROFILE_PRORES_LT,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x02,0x00
> } },
> +{ FF_PROFILE_PRORES_STANDARD, {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x03,0x00
> } },
> +{ FF_PROFILE_PRORES_HQ,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x04,0x00
> } },
> +{ FF_PROFILE_PRORES_, {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x05,0x00
> } },
> +{ FF_PROFILE_PRORES_XQ,   {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0d,0x04,0x01,0x02,0x02,0x03,0x06,0x06,0x00
> } },
> +};
> +
> +static int mxf_parse_prores_frame(AVFormatContext *s, AVStream *st,
> AVPacket *pkt)
> +{
> +MXFContext *mxf = s->priv_data;
> +    MXFStreamContext *sc = st->priv_data;
> +int i, profile;
> +
> +if (mxf->header_written)
> +return 1;
> +
> +sc->codec_ul = NULL;
> +profile = st->codecpar->profile;
>

We should fetch the profile from the bitstream.

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

Re: [FFmpeg-devel] [PATCH v3] avcodec: libdav1d AV1 decoder wrapper.

[Baptiste Coudurier]

Hey guys,

On Tue, Oct 23, 2018 at 4:42 PM James Almer  wrote:

> On 10/23/2018 8:15 PM, Dale Curtis wrote:
> > On Fri, Oct 19, 2018 at 4:50 PM James Almer  wrote:
> >
> >> +s.n_tile_threads = dav1d->tile_threads;
> >> +s.n_frame_threads = dav1d->frame_threads;
> >>
> >
> > Did you consider using the AVCodecContext.threads value along
> > AVCodecContext.thread_type flags? That seems to be how this is handled
> > elsewhere.
> >
> > - dale
>
> I did, but with the library offering options for both tiles or frames i
> wasn't sure if choosing one or the other was a good idea.
> I could map avctx->thread_count to n_frame_threads and leave the other
> as a decoder specific option, i guess, but with the current API there's
> no single optimal way for auto threads.


Agree. We should map them. Can we add frame type tiles ?

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dnxhd handling and add more flavors

[Baptiste Coudurier]

On Wed, Oct 24, 2018 at 6:56 AM Tomas Härdin  wrote:

> tis 2018-10-23 klockan 14:04 -0700 skrev Baptiste Coudurier:
> > Hey Tomas,
> >
> > On Mon, Oct 22, 2018 at 12:52 PM Tomas Härdin 
> > wrote:
> >
> > > mån 2018-10-22 klockan 11:37 -0700 skrev Baptiste Coudurier:
> > > > ---
> > > >  libavformat/mxfenc.c | 215 -
> > > > --
> > > >  1 file changed, 61 insertions(+), 154 deletions(-)
> > > >
> > > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > > index f6acf80d36..71a9b97bed 100644
> > > > --- a/libavformat/mxfenc.c
> > > > +++ b/libavformat/mxfenc.c
> > > > +sc->codec_ul = NULL;
> > > > +cid = AV_RB32(pkt->data + 0x28);
> > > > +for (i = 0; i < FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls); i++)
> > > > +if (cid == mxf_dnxhd_codec_uls[i].cid) {
> > > > +sc->codec_ul = _dnxhd_codec_uls[i].codec_ul;
> > > > +    break;
> > > > +}
> > >
> > > Maybe put braces around the for
> > >
> > > Nice work!
> > >
> >
> > Ok, I will put the braces. I should be applying this later today.
>
> Sounds fine to me
>

Ty! Applied.

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dnxhd handling and add more flavors

[Baptiste Coudurier]

Hey Tomas,

On Mon, Oct 22, 2018 at 12:52 PM Tomas Härdin  wrote:

> mån 2018-10-22 klockan 11:37 -0700 skrev Baptiste Coudurier:
> > ---
> >  libavformat/mxfenc.c | 215 ---
> >  1 file changed, 61 insertions(+), 154 deletions(-)
> >
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > index f6acf80d36..71a9b97bed 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
>
> > +sc->codec_ul = NULL;
> > +cid = AV_RB32(pkt->data + 0x28);
> > +for (i = 0; i < FF_ARRAY_ELEMS(mxf_dnxhd_codec_uls); i++)
> > +if (cid == mxf_dnxhd_codec_uls[i].cid) {
> > +sc->codec_ul = _dnxhd_codec_uls[i].codec_ul;
> > +break;
> > +}
>
> Maybe put braces around the for
>
> Nice work!
>

Ok, I will put the braces. I should be applying this later today.

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

[FFmpeg-devel] [PATCH] avformat/mxfenc: simplify dnxhd handling and add more flavors

[Baptiste Coudurier]

---
 libavformat/mxfenc.c | 215 ---
 1 file changed, 61 insertions(+), 154 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index f6acf80d36..71a9b97bed 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -142,23 +142,10 @@ enum ULIndex {
 INDEX_DV100_1080_50,
 INDEX_DV100_720_60,
 INDEX_DV100_720_50,
-INDEX_DNXHD_1080p_10bit_HIGH,
-INDEX_DNXHD_1080p_8bit_MEDIUM,
-INDEX_DNXHD_1080p_8bit_HIGH,
-INDEX_DNXHD_1080i_10bit_HIGH,
-INDEX_DNXHD_1080i_8bit_MEDIUM,
-INDEX_DNXHD_1080i_8bit_HIGH,
-INDEX_DNXHD_720p_10bit,
-INDEX_DNXHD_720p_8bit_HIGH,
-INDEX_DNXHD_720p_8bit_MEDIUM,
-INDEX_DNXHD_720p_8bit_LOW,
-INDEX_DNXHR_LB,
-INDEX_DNXHR_SQ,
-INDEX_DNXHR_HQ,
-INDEX_DNXHR_HQX,
-INDEX_DNXHR_444,
+INDEX_DNXHD,
 INDEX_JPEG2000,
 INDEX_H264,
+INDEX_S436M,
 };
 
 static const struct {
@@ -169,7 +156,7 @@ static const struct {
 { AV_CODEC_ID_PCM_S24LE,  INDEX_AES3 },
 { AV_CODEC_ID_PCM_S16LE,  INDEX_AES3 },
 { AV_CODEC_ID_DVVIDEO,INDEX_DV },
-{ AV_CODEC_ID_DNXHD,  INDEX_DNXHD_1080p_10bit_HIGH },
+{ AV_CODEC_ID_DNXHD,  INDEX_DNXHD },
 { AV_CODEC_ID_JPEG2000,   INDEX_JPEG2000 },
 { AV_CODEC_ID_H264,   INDEX_H264 },
 { AV_CODEC_ID_NONE }
@@ -307,81 +294,11 @@ static const MXFContainerEssenceEntry 
mxf_essence_container_uls[] = {
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x18,0x01,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x01,0x02,0x02,0x02,0x02,0x08,0x00 
},
   mxf_write_cdci_desc },
-// DNxHD 1080p 10bit high
+// DNxHD
 { { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
   { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x01,0x00,0x00 
},
   mxf_write_cdci_desc },
-// DNxHD 1080p 8bit medium
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x03,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 1080p 8bit high
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x04,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 1080i 10bit high
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x07,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 1080i 8bit medium
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x08,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 1080i 8bit high
-{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x01,0x02,0x01,0x01,0x0D,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x09,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 720p 10bit
-{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x10,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 720p 8bit high
-{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x11,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 720p 8bit medium
-{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x12,0x00,0x00 
},
-  mxf_write_cdci_desc },
-// DNxHD 720p 8bit low
-{ { 
0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00 
},
-  { 
0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00 
},
-  { 

Re: [FFmpeg-devel] [PATCH]lavf/mxfenc: Remove a write-only variable

[Baptiste Coudurier]

Hi Carl,

On Tue, Oct 16, 2018 at 3:00 PM Carl Eugen Hoyos  wrote:

> 2018-10-13 13:12 GMT+02:00, Carl Eugen Hoyos :
>
> > Attached patch fixes a warning, I wonder if the value is actually
> > supposed to use somewhere...
>
> Ping.
>

LGTM.

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

Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

[Baptiste Coudurier]

On Sat, Oct 13, 2018 at 7:13 PM Michael Niedermayer 
wrote:

> On Sat, Oct 13, 2018 at 06:24:52PM +0200, Martin Vignali wrote:
> > >
> > > Applied
> > >
> > >
> > Seems like fate-mxf-reel_name doesn't pass after your patchs
> > make fate-mxf-reel_name SAMPLES=fate-suite
>
> this also broke 2 other fate tests:
> make: *** [fate-mxf-reel_name] Error 1
> make: *** [fate-copy-trac4914] Error 1
> make: *** [fate-time_base] Error 1
>
> i would look at it but i just now noticed and i need to go to bed :(
>
> also when testing i needed a "rm tests/data/fate/time_base.out", this seemd
> not to be removed (thats unrelated to the commit i assume, iam just saying
> so noone wastes time debuging a mysterious long standing failure)
>

Seems like all these tests generate mxf files, which would change after
this patch.
I'm looking and will fix them.

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

Re: [FFmpeg-devel] [PATCH 10/12] lavf/mxfdec: demux s436m as eia608 subtitle track

[Baptiste Coudurier]

On Wed, Jul 4, 2018 at 1:50 PM Marton Balint  wrote:

>
>
> On Wed, 4 Jul 2018, Baptiste Coudurier wrote:
>
> > ---
> > libavformat/mxfdec.c | 102 +++
> > 1 file changed, 102 insertions(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 3f443bbbc9..54e4be7934 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -52,6 +52,7 @@
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/parseutils.h"
> > #include "libavutil/timecode.h"
> > +#include "libavutil/opt.h"
> > #include "avformat.h"
> > #include "internal.h"
> > #include "mxf.h"
> > @@ -263,6 +264,7 @@ typedef struct MXFIndexTable {
> > } MXFIndexTable;
> >
> > typedef struct MXFContext {
> > +const AVClass *class; /**< Class for private options. */
> > MXFPartition *partitions;
> > unsigned partitions_count;
> > MXFOP op;
> > @@ -287,6 +289,8 @@ typedef struct MXFContext {
> > int64_t current_edit_unit;
> > int nb_index_tables;
> > MXFIndexTable *index_tables;
> > +int edit_units_per_packet;  ///< how many edit units to read at
> a time (PCM, OPAtom)
>
> This seems unused, probably remained after a merge. (edit_units_per_packet
> is now an MXFTrack property).
>
> > +int eia608_extract;
> > } MXFContext;
> >
> > /* NOTE: klv_offset is not set (-1) for local keys */
> > @@ -449,6 +453,78 @@ static int find_body_sid_by_offset(MXFContext *mxf,
> int64_t offset)
> > return mxf->partitions[a].body_sid;
> > }
> >
> > +static int mxf_get_eia608_packet(AVFormatContext *s, AVStream *st,
> AVPacket *pkt, int64_t length)
> > +{
> > +int count = avio_rb16(s->pb);
> > +int i, ret;
> > +
> > +for (i = 0; i < count; i++) {
> > +if (length < 6) {
> > +av_log(s, AV_LOG_ERROR, "error reading s436m packet
> %"PRId64"\n", length);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +int line_num = avio_rb16(s->pb);
> > +int wrapping_type = avio_r8(s->pb);
> > +int sample_coding = avio_r8(s->pb);
> > +int sample_count = avio_rb16(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "len %"PRId64" line %d wrap type %d
> coding %d count %d\n",
> > +   length, line_num, wrapping_type, sample_coding,
> sample_count);
> > +length -= 6 + 8 + sample_count;
> > +if (line_num != 9 && line_num != 11)
> > +break;
> > +if (sample_coding == 7 || sample_coding == 8 || sample_coding
> == 9) {
> > +av_log(s, AV_LOG_ERROR, "unsupported s436m 10 bit sample
> coding\n");
> > +return 0;
> > +}
> > +if (length < 0)
> > +return AVERROR_INVALIDDATA;
> > +
> > +int array_count = avio_rb32(s->pb);
> > +int array_elem_size = avio_rb32(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "array count %d elem size %d\n",
> array_count, array_elem_size);
> > +int did = avio_r8(s->pb);
> > +int sdid = avio_r8(s->pb);
> > +int data_count = avio_r8(s->pb);
> > +av_log(s, AV_LOG_DEBUG, "did %x sdid %x count %d\n", did, sdid,
> data_count);
> > +if (did != 0x61)
> > +break;
> > +int cdp_id = avio_rb16(s->pb);
> > +int cdp_data_count = avio_r8(s->pb);
> > +int cdp_framing_rate = avio_r8(s->pb) >> 4;
> > +int cdp_flags = avio_r8(s->pb);
> > +int cdp_counter = avio_rb16(s->pb);
> > +int cdp_data_section = avio_r8(s->pb);
> > +if (cdp_data_section != 0x72) {
> > +av_log(s, AV_LOG_ERROR, "wrong cdp data section %x\n",
> cdp_data_section);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +int flags = avio_r8(s->pb);
> > +int cc_count = flags & 0x1f;
> > +av_log(s, AV_LOG_DEBUG, "cdp id %x dcount %d frame rate %d cdp
> flags %x flags %x "
> > +   "cc count %d counter %d section %x\n", cdp_id,
> cdp_data_count, cdp_framing_rate,
> > +   cdp_flags, flags, cc_count, cdp_counter,
> cdp_data_section);
> > +ret = av_get_packet(s->pb, pkt, cc_count * 3);
> > +if 

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

[Baptiste Coudurier]

On Mon, Sep 24, 2018 at 1:55 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Thu, Jul 19, 2018 at 2:32 PM Michael Niedermayer 
> wrote:
>
>> On Wed, Jul 04, 2018 at 03:06:54PM -0700, Baptiste Coudurier wrote:
>> > ---
>> >  libavformat/mxf.c|  1 +
>> >  libavformat/mxfdec.c |  2 ++
>> >  libavformat/mxfenc.c | 41 +
>> >  libavformat/utils.c  |  6 +-
>> >  4 files changed, 45 insertions(+), 5 deletions(-)
>> [...]
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index c9cdd2b470..36a32ad9c2 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -1003,6 +1003,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> >  *pnum = frame_size;
>> >  *pden = sample_rate;
>> >  break;
>> > +case AVMEDIA_TYPE_DATA:
>> > +*pnum = st->time_base.num;
>> > +*pden = st->time_base.den;
>> > +break;
>> >  default:
>> >  break;
>> >  }
>> > @@ -1405,7 +1409,7 @@ static void compute_pkt_fields(AVFormatContext
>> *s, AVStream *st,
>> >  presentation_delayed, delay, av_ts2str(pkt->pts),
>> av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
>> >
>> >  /* update flags */
>> > -if (is_intra_only(st->codecpar->codec_id))
>> > +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
>> is_intra_only(st->codecpar->codec_id))
>> >  pkt->flags |= AV_PKT_FLAG_KEY;
>> >  #if FF_API_CONVERGENCE_DURATION
>> >  FF_DISABLE_DEPRECATION_WARNINGS
>>
>> This should be a seperate patch.
>> Also i think forcing duration=1 is not correct for all AVMEDIA_TYPE_DATA
>> for example there are ID3 and fonts. These would i guess if they have a
>> timebase set apply to more than 1 "unit"
>>
>
> I applied the separate patch.
> Will apply this patch shortly, addressing Marton comment.
>
> Thanks!
>

Applied.

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

Re: [FFmpeg-devel] [PATCH 04/12] avformat/mxfenc: update body partition with footer offset

[Baptiste Coudurier]

On Thu, Jul 19, 2018 at 8:40 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxfenc.c| 9 +++--
>>  tests/ref/lavf/mxf  | 6 +++---
>>  tests/ref/lavf/mxf_d10  | 2 +-
>>  tests/ref/lavf/mxf_dv25 | 2 +-
>>  tests/ref/lavf/mxf_dvcpro50 | 2 +-
>>  tests/ref/lavf/mxf_opatom   | 2 +-
>>  tests/ref/lavf/mxf_opatom_audio | 2 +-
>>  7 files changed, 15 insertions(+), 10 deletions(-)
>
>
> Will apply.
>

Applied.

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

Re: [FFmpeg-devel] [PATCH 03/12] avformat/mxfenc: add mpeg-2 specific metadata, fix compatibility with sony content browser

[Baptiste Coudurier]

On Thu, Jul 19, 2018 at 8:42 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxfenc.c| 46 ++---
>>  tests/ref/lavf/mxf  |  6 ++---
>>  tests/ref/lavf/mxf_d10  |  2 +-
>>  tests/ref/lavf/mxf_dv25 |  2 +-
>>  tests/ref/lavf/mxf_dvcpro50 |  2 +-
>>  tests/ref/lavf/mxf_opatom   |  2 +-
>>  tests/ref/lavf/mxf_opatom_audio |  2 +-
>>  7 files changed, 50 insertions(+), 12 deletions(-)
>>
>
> Will apply.
>

Applied.

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

Re: [FFmpeg-devel] [PATCH 05/12] avformat/mxfenc: correctly set content package rate in system element

[Baptiste Coudurier]

On Thu, Jul 19, 2018 at 8:37 AM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Wed, Jul 4, 2018 at 11:35 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/mxf.c| 17 +
>>  libavformat/mxf.h|  2 ++
>>  libavformat/mxfenc.c |  4 +++-
>>  tests/ref/lavf/mxf   |  2 +-
>>  4 files changed, 23 insertions(+), 2 deletions(-)
>>
>
> Will apply.
>

Applied

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

Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

[Baptiste Coudurier]

On Thu, Jul 12, 2018 at 12:44 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> Hey Thomas,
>
> On Thu, Jul 12, 2018 at 12:29 PM, Tomas Härdin  wrote:
>
>> Is this the latest/correct patch series for these things? I saw some
>> other patches conflicted with Marton's work
>>
>
> Yes, the conflicts were on the demuxer side
>

Will apply.

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

Re: [FFmpeg-devel] [PATCH] avformat/utils: set AV_PKT_FLAG_KEY for data packets

[Baptiste Coudurier]

On Tue, Aug 21, 2018 at 12:19 PM Baptiste Coudurier <
baptiste.coudur...@gmail.com> wrote:

> On Mon, Jul 30, 2018 at 11:16 AM, Baptiste Coudurier <
> baptiste.coudur...@gmail.com> wrote:
>
>> ---
>>  libavformat/utils.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index c9cdd2b470..b15f20dd23 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -1405,7 +1405,7 @@ static void compute_pkt_fields(AVFormatContext *s,
>> AVStream *st,
>>  presentation_delayed, delay, av_ts2str(pkt->pts),
>> av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
>>
>>  /* update flags */
>> -if (is_intra_only(st->codecpar->codec_id))
>> +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
>> is_intra_only(st->codecpar->codec_id))
>>  pkt->flags |= AV_PKT_FLAG_KEY;
>>  #if FF_API_CONVERGENCE_DURATION
>>  FF_DISABLE_DEPRECATION_WARNINGS
>>
>
> Will apply.
>

Applied

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

Re: [FFmpeg-devel] [PATCH v2] lavf/mxfenc: support creating s436m data tracks

[Baptiste Coudurier]

On Thu, Jul 19, 2018 at 2:32 PM Michael Niedermayer 
wrote:

> On Wed, Jul 04, 2018 at 03:06:54PM -0700, Baptiste Coudurier wrote:
> > ---
> >  libavformat/mxf.c|  1 +
> >  libavformat/mxfdec.c |  2 ++
> >  libavformat/mxfenc.c | 41 +
> >  libavformat/utils.c  |  6 +-
> >  4 files changed, 45 insertions(+), 5 deletions(-)
> [...]
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index c9cdd2b470..36a32ad9c2 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1003,6 +1003,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
> >  *pnum = frame_size;
> >  *pden = sample_rate;
> >  break;
> > +case AVMEDIA_TYPE_DATA:
> > +*pnum = st->time_base.num;
> > +*pden = st->time_base.den;
> > +break;
> >  default:
> >  break;
> >  }
> > @@ -1405,7 +1409,7 @@ static void compute_pkt_fields(AVFormatContext *s,
> AVStream *st,
> >  presentation_delayed, delay, av_ts2str(pkt->pts),
> av_ts2str(pkt->dts), av_ts2str(st->cur_dts));
> >
> >  /* update flags */
> > -if (is_intra_only(st->codecpar->codec_id))
> > +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA ||
> is_intra_only(st->codecpar->codec_id))
> >  pkt->flags |= AV_PKT_FLAG_KEY;
> >  #if FF_API_CONVERGENCE_DURATION
> >  FF_DISABLE_DEPRECATION_WARNINGS
>
> This should be a seperate patch.
> Also i think forcing duration=1 is not correct for all AVMEDIA_TYPE_DATA
> for example there are ID3 and fonts. These would i guess if they have a
> timebase set apply to more than 1 "unit"
>

I applied the separate patch.
Will apply this patch shortly, addressing Marton comment.

Thanks!

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

Re: [FFmpeg-devel] [PATCH v5 2/2] libavformat/mxfenc: add missing dnxhr mxfcontainer essence ULs

[Baptiste Coudurier]

Hi Jason,

On Sat, Sep 8, 2018 at 6:27 AM Jason Stevens  wrote:

> Add missing dnxhr mxf container essence ULs to the mxf encoder.
>
> This fixes dnxhr mxf files being quarantined by Avid Media Composer.
>
> Signed-off-by: Jason Stevens 
> ---
>  libavformat/mxfenc.c | 53 +++-
>  1 file changed, 52 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 7f629dbe53..66814ef6a1 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -146,6 +146,11 @@ enum ULIndex {
>  INDEX_DNXHD_720p_8bit_HIGH,
>  INDEX_DNXHD_720p_8bit_MEDIUM,
>  INDEX_DNXHD_720p_8bit_LOW,
> +INDEX_DNXHR_LB,
> +INDEX_DNXHR_SQ,
> +INDEX_DNXHR_HQ,
> +INDEX_DNXHR_HQX,
> +INDEX_DNXHR_444,
>  INDEX_JPEG2000,
>  INDEX_H264,
>  };
> @@ -345,6 +350,31 @@ static const MXFContainerEssenceEntry
> mxf_essence_container_uls[] = {
>{
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
>{
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x13,0x00,0x00
> },
>mxf_write_cdci_desc },
> +// DNxHR LB - CID 1274
> +{ {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x28,0x00,0x00
> },
> +  mxf_write_cdci_desc },
> +// DNxHR SQ - CID 1273
> +{ {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x27,0x00,0x00
> },
> +  mxf_write_cdci_desc },
> +// DNxHR HQ - CID 1272
> +{ {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x26,0x00,0x00
> },
> +  mxf_write_cdci_desc },
> +// DNxHR HQX - CID 1271
> +{ {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x25,0x00,0x00
> },
> +  mxf_write_cdci_desc },
> +// DNxHR 444 - CID 1270
> +{ {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x11,0x01,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x05,0x00
> },
> +  {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x02,0x71,0x24,0x00,0x00
> },
> +  mxf_write_cdci_desc },
>  // JPEG2000
>  { {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c,0x01,0x00
> },
>{
> 0x06,0x0e,0x2b,0x34,0x01,0x02,0x01,0x01,0x0d,0x01,0x03,0x01,0x15,0x01,0x08,0x00
> },
> @@ -1959,7 +1989,11 @@ AVPacket *pkt)
>  header_cid = pkt->data + 0x28;
>  cid = header_cid[0] << 24 | header_cid[1] << 16 | header_cid[2] << 8
> | header_cid[3];
>
> -if ((frame_size = avpriv_dnxhd_get_frame_size(cid)) < 0)
> +if ((frame_size = avpriv_dnxhd_get_frame_size(cid)) ==
> DNXHD_VARIABLE) {
> +frame_size = avpriv_dnxhd_get_hr_frame_size(cid,
> st->codecpar->width, st->codecpar->height);
> +}
> +
> +if (frame_size < 0)
>  return -1;
>  if ((sc->interlaced = avpriv_dnxhd_get_interlaced(cid)) < 0)
>  return AVERROR_INVALIDDATA;
> @@ -1998,6 +2032,23 @@ AVPacket *pkt)
>  case 1253:
>  sc->index = INDEX_DNXHD_720p_8bit_LOW;
>  break;
> +case 1274:
> +sc->index = INDEX_DNXHR_LB;
> +break;
> +case 1273:
> +sc->index = INDEX_DNXHR_SQ;
> +break;
> +case 1272:
> +sc->index = INDEX_DNXHR_HQ;
> +break;
> +case 1271:
> +sc->index = INDEX_DNXHR_HQX;
> +sc->component_depth = st->codecpar->bits_per_raw_sample;
> +break;
> +case 1270:
> +sc->index = INDEX_DNXHR_444;
> +sc->component_depth = st->codecpar->bits_per_raw_sample;
> +break;
>  default:
>  return -1;
>  }
>

Looks good to me.

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