Re: [FFmpeg-devel] [PATCH] mxfdec: check edit_rate also for physical_track

[tim nicholson]

On 15/11/15 18:07, Andreas Cadhalpun wrote:
> Previously only the edit_rate of material_track was checked.
> If it's negative, it causes assertion failures in av_rescale_rnd.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavformat/mxfdec.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 99c8fed..429f46a 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -1776,6 +1776,16 @@ static int 
> mxf_parse_physical_source_package(MXFContext *mxf, MXFTrack *source_t
>  continue;
>  }
>  
> +if (physical_track->edit_rate.num <= 0 ||
> +physical_track->edit_rate.den <= 0) {
> +av_log(mxf->fc, AV_LOG_WARNING,
> +   "Invalid edit rate (%d/%d) found on structural"
> +   " component #%d, defaulting to 25/1\n",
> +   physical_track->edit_rate.num,
> +   physical_track->edit_rate.den, i);
> +physical_track->edit_rate = (AVRational){25, 1};
> +}
> +
>  for (k = 0; k < 
> physical_track->sequence->structural_components_count; k++) {
>  if (!(mxf_tc = mxf_resolve_timecode_component(mxf, 
> _track->sequence->structural_components_refs[k])))
>  continue;
> 

LGTM, but I am curious as to where you have seen examples of negative
edit rates. (I have found examples in mxf code where signed and unsigned
have been muddled leading to invalid figures and I am wondering if this
is another)

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Only store user comment related tags when needed

[tim nicholson]

On 10/11/15 12:28, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Also support disabling them as they seem to cause problems to some
> Users. They are also not allowed in IRT D-10 thus the default for
> mxf_d10 is not to write them
> 
> This also decreases the filesize when no user comment are stored
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  doc/muxers.texi  |   15 ++
>  libavformat/mxfenc.c |   46 +
>  tests/ref/lavf/mxf   |   12 
>  tests/ref/lavf/mxf_d10   |2 +-
>  tests/ref/lavf/mxf_opatom|2 +-
>  tests/ref/lavf/mxf_opatom_audio  |4 +--
>  tests/ref/seek/lavf-mxf  |   44 +--
>  tests/ref/seek/lavf-mxf_opatom_audio |   54 
> +-
>  8 files changed, 107 insertions(+), 72 deletions(-)
> 
> [..]

> @@ -2038,6 +2051,9 @@ static int mxf_write_header(AVFormatContext *s)
>  return -1;
>  }
>  
> +if (!av_dict_get(s->metadata, "comment_", NULL, AV_DICT_IGNORE_SUFFIX))
> +mxf->store_user_comments = 0;
> +
>  for (i = 0; i < s->nb_streams; i++) {
>  AVStream *st = s->streams[i];
>  MXFStreamContext *sc = av_mallocz(sizeof(*sc));
> @@ -2650,12 +2666,14 @@ static int mxf_interleave(AVFormatContext *s, 
> AVPacket *out, AVPacket *pkt, int
>  { "smpte349m", "SMPTE 349M (1485 Mbps mappings)",\
>0, AV_OPT_TYPE_CONST, {.i64 = 6}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},\
>  { "smpte428", "SMPTE 428-1 DCDM",\
> -  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},
> +  0, AV_OPT_TYPE_CONST, {.i64 = 7}, -1, 7, AV_OPT_FLAG_ENCODING_PARAM, 
> "signal_standard"},\

Stray \ from previous patch attempt?

>  
>  
>  
>  static const AVOption mxf_options[] = {
>  MXF_COMMON_OPTIONS
> +{ "store_user_comments", "",
> +  offsetof(MXFContext, store_user_comments), AV_OPT_TYPE_BOOL, {.i64 = 
> 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>  { NULL },
>  };
>  
> @@ -2670,6 +2688,8 @@ static const AVOption d10_options[] = {
>  { "d10_channelcount", "Force/set channelcount in generic sound essence 
> descriptor",
>offsetof(MXFContext, channel_count), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
> 8, AV_OPT_FLAG_ENCODING_PARAM},
>  MXF_COMMON_OPTIONS
> +{ "store_user_comments", "",
> +  offsetof(MXFContext, store_user_comments), AV_OPT_TYPE_BOOL, {.i64 = 
> 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>  { NULL },
>  };
>  
> diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
> [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Only store user comment related tags when needed

[tim nicholson]

On 09/11/15 17:56, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Also support disabling them as they seem to cause problems to some
> Users.
> 
> [..]
> -for (i = 0; i < local_tag_number; i++) {
> +for (i = 0; i < FF_ARRAY_ELEMS(mxf_local_tag_batch); i++) {
>  avio_wb16(pb, mxf_local_tag_batch[i].local_tag);
>  avio_write(pb, mxf_local_tag_batch[i].uid, 16);
>  }
> +if (mxf->store_user_comments)
> +for (i = 0; i < FF_ARRAY_ELEMS(mxf_local_tag_batch); i++) {

Is this right? I expected:-

for (i = 0; i < FF_ARRAY_ELEMS(mxf_user_comments_local_tag); i++) {


> +avio_wb16(pb, mxf_user_comments_local_tag[i].local_tag);
> +avio_write(pb, mxf_user_comments_local_tag[i].uid, 16);
> +}
>  }



-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE

[tim nicholson]

On 02/10/15 20:00, Christophe Gisquet wrote:
> A series of 0 in a table can be confusing, and the corresponding checks
> strange, so using a macro instead of that magic is more readable.
> ---
>  libavcodec/dnxhddata.c | 10 +-
>  libavcodec/dnxhddata.h |  3 +++
>  libavcodec/dnxhddec.c  |  6 --
>  3 files changed, 12 insertions(+), 7 deletions(-)
> 
> [..]
> +/** Indicate that a CIDEntry value must be read in the bitstream */
> +#define DNXHD_VARIABLE 0
> +

I'm all for more readable, presumably atm its only ever 0 but may change
in the future, in which case some idea of what it represents may be
useful, I am sure the spec has more than one variable ;)

> [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/10/15 13:07, Tomas Härdin wrote:
> On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
>> On 19.09.2015 22:49, Tomas Härdin wrote:
>>> On Wed, 2015-09-16 at 14:33 +0200, Tobias Rapp wrote:
 Hi,

 attached patch fixes ticket #4759 but I guess it is a bit too hasty
 to
 always abort transcoding if a single frame cannot be written. I gue
ss it
 would be better to check for some "exit_on_error" like flag set but
 couldn't find out how to achieve that.

 Any comments would be appreciated.

 Regards,
 Tobias
>>>
>>>
  From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 
2001
 From: Tobias Rapp 
 Date: Mon, 14 Sep 2015 12:06:22 +0200
 Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video p
acket
   occurs

 Fixes ticket #4759.
 ---
   libavformat/mxfenc.c | 14 +-
   1 file changed, 9 insertions(+), 5 deletions(-)

>> [...]
>>>
>>> Is this really better than not writing anything?
>>>
>>> /Tomas
>>
>> (Sorry for the long delay in answering, I was caught by a flu last we
ek.)
>>
>> I want to transcode thousands of files and want to get some indicatio
n
>> from ffmpeg if the transcoding has been successful (all frames have b
een
>> transcoded) or not. Currently I am using the process exit code to ver
ify
>> that.
>>
>> There are two different user stories when using ffmpeg:
>> a) "process the input data and exit with error as early as possible i
n
>> case of errors/problems"
>> b) "process the input data and avoid exit with error as long as possi
ble
>> in case of error/problems"
>>
>> If I understand correctly I can basically switch between (a) and (b) 
>> mode by passing the "-xerror" option to ffmpeg or not. So my plan is 
to
>> transcode all my files with "-xerror" and assume that >99% of the fil
es
>> will pass. The small amount of failing ones can then be analyzed for 
>> problems manually and possibly have a re-run without "-xerror".
>>
>> Unfortunately the "-xerror" option affects only ffmpeg but not the 
>> libraries, so I cannot use it do decide if "mxf_write_packet" should 
>> return with an error when the video packet size doesn't match the CBR

>> constraints.
> 
> For me the most important thing is that anything dealing with MXF shou
ld
> never write invalid files.

+1 for sure.


> I'm not sure whether the current code is
> broken per se, but it does look suspicious. Perhaps someone else has a
> better idea?
>

Truncate/pad mis sized frames to allow muxing to continue, and issue a
warning (as at present)?


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


- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWEiJtAAoJEAwL/ESLC/yDGQAIAJmqWRatBPd/2SXuzyFGWqB2
sg/FBpbzRqFGxr8dOfqfSkwLWu+EUL66UZKu5liVKkeksiUgx4sPtj6DFGFX7ozV
g2DbJxvsFG18ES9C8OHc3qRDsgF4Z+F4GuScWMPrVcyvimSdHeajVkS8slrZlg2Y
tMGQSin5jLwzv1pGIhCOdQLEndrr+PzwajPI837UBW2e7znWDb1uNHBy1yiPzcf+
0pyZluyhkqW6IBzgO34Dc39DfQdGrtDWlzyUacT7nQz/4W5q2KAAhUhBTNtqTabK
KCtSUfpqWgu6P2xxNvi87F9acqYprS80RC/ovrdgsXiXTNGSbYVscY748xg8mgA=
=Clgr
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/5] dnxhddec: replace some 0s by DNXHD_VARIABLE

[tim nicholson]

On 05/10/15 08:51, Christophe Gisquet wrote:
> Hi,
> 
> 2015-10-05 8:44 GMT+02:00 tim nicholson <nichot20-at-yahoo@ffmpeg.org>:
>> On 02/10/15 20:00, Christophe Gisquet wrote:
>>> A series of 0 in a table can be confusing, and the corresponding checks
>>> strange, so using a macro instead of that magic is more readable.
>>> ---
>>>  libavcodec/dnxhddata.c | 10 +-
>>>  libavcodec/dnxhddata.h |  3 +++
>>>  libavcodec/dnxhddec.c  |  6 --
>>>  3 files changed, 12 insertions(+), 7 deletions(-)
>>>
>>> [..]
>>> +/** Indicate that a CIDEntry value must be read in the bitstream */
>>> +#define DNXHD_VARIABLE 0
>>> +
>>
>> I'm all for more readable, presumably atm its only ever 0 but may change
>> in the future, in which case some idea of what it represents may be
>> useful, I am sure the spec has more than one variable ;)
> 
> Actually, it's a convenience value, that we put there after noticing
> new samples.
> 
> We don't have access to the DNxHR specs, but it seems a "profile" can
> have differing bitdepths. I haven't yet verified, but the frame header
> probably allows to distinguish them (DNXHD_VARIABLE applies to the HR
> version).
>

That's fine, I just thought there ought to be a better name for it. Just
calling it VARIABLE begs the question "what is variable?" If you are
trying to make the code clearer, give some clue as to what it relates
to. However if atm you aren't quite sure but think it might be handy
later, then I can see that that becomes a bit difficult.

I thought JJ had got hold of a copy of the specs...


> I have, down the line, things that may need to split the HR versions.
> 


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tinterlace: add mergex2 mode

[tim nicholson]

On 02/10/15 11:03, Paul B Mahol wrote:
> On 10/1/15, Paul B Mahol  wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  doc/filters.texi| 23 +++
>>  libavfilter/tinterlace.h|  1 +
>>  libavfilter/vf_tinterlace.c | 17 -
>>  3 files changed, 36 insertions(+), 5 deletions(-)
> 
> 
> So is this ok now? This is supposed to replicate DoubleWeave from
> avisynth/vapoursynth.

No further comments from me, the desired result makes more sense, and I
think the code is correct to achieve that, but I hoped others might
check the logic too.

> [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tinterlace: add mergex2 mode

[tim nicholson]

On 30/09/15 14:39, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi| 24 
>  libavfilter/tinterlace.h|  1 +
>  libavfilter/vf_tinterlace.c | 13 ++---
>  3 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/doc/filters.texi b/doc/filters.texi
> index a4d828e..0a8588d 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10774,6 +10774,30 @@ Output:
>   1   1   2   2   3   3   4
>  @end example
>  
> +@item mergex2, 7
> +Move odd frames into the upper field, even into the lower field,
> +generating a double height frame at same frame rate.
> +@example
> + --> time
> +Input:
> +Frame 1 Frame 2 Frame 3 Frame 4
> +
> +1   2   3   4
> +1   2   3   4
> +1   2   3   4
> +1   2   3   4
> +
> +Output:
> +1   2   3   4
> +2   3   4   5
> +1   2   3   4
> +2   3   4   5
> +1   2   3   4
> +2   3   4   5
> +1   2   3   4
> +2   3   4   5
> +@end example
> +
>

I can see the usefulness of merging, but making any particular frame
both the lower field in one merged frame, and upper in the next,  sounds
like a recipe for eye watering judder on the output.

I think one would need to explain how would one then strip alternate
frames to get a stream with a consistent field dominance(and how to
select even or odd frames to get the right one).

>  @end table
>  
> [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [DECISION] Server "move"

[tim nicholson]

On 21/09/15 20:44, Carl Eugen Hoyos wrote:
> Michael Niedermayer  gmx.at> writes:
> 
>> This "decision" thingy, is intended to confirm that
>> * Stuff should be moved to the telepoint server, possibly duplicates
>>   should be left at/moved to the hetzner server for redundancy, if
>>   this is technically possible (maybe it should be called copy instead
>>   of move in that case)
> 
> Copy sounds like a good idea to me.
> 
> VDD15 again confirmed that nobody wants to do the work 
> necessary to move to videolan (which would also sound 
> ok to me).
> 

Nobody, or nobody who was at VDD15? What work is necessary?

I would +1 Lou's comments, some of us who might be able to help are
still unsure of what happened at VDD15.


AIUI we would like 2 servers, and having accepted one offer, a server
has already been built and awaits commissioning. the second is still
undecided. Could that not be on Videolan? What are the issues?

Having accepted an offer which has led to those making that offer invest
time, effort, and presumably money, in setting something up. I would
imagine that they would be somewhat upset if we then turn round and say
we have changed our mind. Especially without a clear alternative.

It feels rather like we are going round in circles.

> Carl Eugen
> [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] mxfdec: set AVFMT_SEEK_TO_PTS demuxer flag

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 14/08/15 13:27, Tomas Härdin wrote:
 On Mon, 2015-08-10 at 10:14 +0200, Tomas Härdin wrote:
 On Sun, 2015-08-09 at 20:32 +0200, Marton Balint wrote:
 Since 53f2ef2c4afb1d49a679dea9163cb0e4671f3117 seeking is done using
 PTS.

 Signed-off-by: Marton Balint c...@passwd.hu
 ---
  libavformat/mxfdec.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
 index 2d921db..5734976 100644
 --- a/libavformat/mxfdec.c
 +++ b/libavformat/mxfdec.c
 @@ -3210,6 +3210,7 @@ static int mxf_read_seek(AVFormatContext *s, i
nt stream_index, int64_t sample_ti
  AVInputFormat ff_mxf_demuxer = {
  .name   = mxf,
  .long_name  = NULL_IF_CONFIG_SMALL(MXF (Material eXchange 
Format)),
 +.flags  = AVFMT_SEEK_TO_PTS,
  .priv_data_size = sizeof(MXFContext),
  .read_probe = mxf_probe,
  .read_header= mxf_read_header,

 Yeah, I seem to recall this when swearing at the seek code in mxfdec
 some years ago. I'll wait a few days to see if any other MXF guys hav
e
 something to say here or on IRC, then I suppose I'll push


Only the seek code you swear at?

 /Tomas
 
 Pushed. Hopefully everything worked alright
 

Just back from leave, so time will tell

 /Tomas
 [..]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJV3BIoAAoJEAwL/ESLC/yD4jgH/35vOcJkv8daPCvNiXc+p8HD
DJc3YBFINl3wY8HohQJWcjYTfma8DVJS4XPCIMqsYpnzPvWH+VBp5hYxQ1UwrRDY
trRjuMTtcfDp9kL3O1cGKHPDV0eyJXvoyR8gw1zpKdZsVE4In7VnQRLahj//2HFt
+tWcuPG+IhMrgyOMM5UH5rSd5doCQgkLC3iouX40NTmpzo5fGAdqH8+4qrMJSY6e
Uth3xK7hHRQqnbDEYNmKMOSeVasnwaxx26y2hCtVUaUypnyhH7lkY2ndfURg0pD3
80yCPI253cy1tbtsmRyph3z/BXTsa3xPUFIcdcKjpnQuv7pio/a+w3a1UqpE8PI=
=1mAZ
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpegs future and resigning as leader

[tim nicholson]

On 03/08/15 20:43, Michael Niedermayer wrote:
 On Mon, Aug 03, 2015 at 08:51:10AM +0100, tim nicholson wrote:
 On 31/07/15 17:19, Michael Niedermayer wrote:
 On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
 [...]
 So in order for the community to continue this, I'd say we probably need
 to have some help for:

 - guidelines on the merge strategies
 - step-by-step on the release process

 - some overview on the sysadmin state (like, what happens with the recent
   server offers?)

 i accepted the 2 offers which noone objected against (on the ML),
 so FFmpeg should
 get 2 boxes that things can be moved to and which should be dependable
 it does need volunteers doing the work.
 Maybe lou, beastd, tim nich, roberto and you would be willing to help
 move things to them

 I am up for assisting where I can, but August is going to be mainly
 holiday for me ;)


 it was discussed to move things into virtual machines (qemu) for
 higher security, isolation and ease of future moving.

 
 If we go kvm etc, prebuilding a base image beforehand that can then be
 forked for postfix/Apache/trak etc would be useful.
 
 yes
 
 

 In fact there are some pre-built images already for some things, e.g

 
 https://www.turnkeylinux.org/issue-tracking?page=1
 
 has these been build by someone who knows about security ?
 or would it require a security audit to ensure no auth stuff /session
 keys / host keys / prng state / whatever is carried over from the
 public image ?
 

From a quick look they seem to know what they are doing. On first run it
behaves somewhat like the end of an install process first boot, so each
instance is different with regenerated keys. When I tried 2 separate
instances from scrach I confirmed they had different host keys. I didn't
go deeper than that at the time. Obviously prng integrity is important
and would need checking.

 [...]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpegs future and resigning as leader

[tim nicholson]

On 31/07/15 17:19, Michael Niedermayer wrote:
 On Fri, Jul 31, 2015 at 05:37:12PM +0200, Clément Bœsch wrote:
 [...]
 So in order for the community to continue this, I'd say we probably need
 to have some help for:

 - guidelines on the merge strategies
 - step-by-step on the release process
 
 - some overview on the sysadmin state (like, what happens with the recent
   server offers?)
 
 i accepted the 2 offers which noone objected against (on the ML),
 so FFmpeg should
 get 2 boxes that things can be moved to and which should be dependable
 it does need volunteers doing the work.
 Maybe lou, beastd, tim nich, roberto and you would be willing to help
 move things to them

I am up for assisting where I can, but August is going to be mainly
holiday for me ;)


 it was discussed to move things into virtual machines (qemu) for
 higher security, isolation and ease of future moving.

If we go kvm etc, prebuilding a base image beforehand that can then be
forked for postfix/Apache/trak etc would be useful.

In fact there are some pre-built images already for some things, e.g

https://www.turnkeylinux.org/issue-tracking?page=1

that would just need the data migrating.

 moving to the new servers could be done before or after moving to VMs
 of course or while doing it in the same step
 
 [...]
 
 
 
 ___
 ffmpeg-devel mailing list
 ffmpeg-devel@ffmpeg.org
 http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add support for j2ki/mxf

[tim nicholson]

On 23/07/15 11:32, Matthieu Bouron wrote:
 On Thu, Jul 23, 2015 at 11:04 AM, tim nicholson 
 nichot20-at-yahoo@ffmpeg.org wrote:
 
 On 22/07/15 14:29, Matthieu Bouron wrote:
 Hello there,

 The following patchset add support for j2ki/mxf files (which store frames
 using the separate fields / segmented frame layouts, ie: fields are
 stored in seperate frames) through the insertion of filters at the
 ffmpeg/ffplay level. It differs from my original attempt which introduced
 modifications at the decoder level, which in my opinion was wrong and
 introduced several limitations, such as:

 [..]

 I may be missing something here, as my mind has been on other things.
 But currently most mxf material I see that ffmpeg correctly handles is
 frame wrapped with the frame layout as type 1 (SEPARATE_FIELDS).

 
 Can you provide samples with this layout ? I might have misinterpreted the
 MXF
 specs on this one. My understating is that, separated fields (as well as
 segmented frame) means
 that the fields are stored in a different packet (that might no be the
 right world for it).
 
 Also it might be specific to jpeg2000 (see below), i'll have to look again
 at the mxf/jpeg2000 spec again.
 

I have added a 4 frame example to the trac ticket of interlaced IMX50
material.

according to mxf2raw (from bmxlib) this file is flagged SEPARATE_FIELDS.

 [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Add support for j2ki/mxf

[tim nicholson]

On 22/07/15 14:29, Matthieu Bouron wrote:
 Hello there,
 
 The following patchset add support for j2ki/mxf files (which store frames
 using the separate fields / segmented frame layouts, ie: fields are
 stored in seperate frames) through the insertion of filters at the
 ffmpeg/ffplay level. It differs from my original attempt which introduced
 modifications at the decoder level, which in my opinion was wrong and
 introduced several limitations, such as:
 
 [..]

I may be missing something here, as my mind has been on other things.
But currently most mxf material I see that ffmpeg correctly handles is
frame wrapped with the frame layout as type 1 (SEPARATE_FIELDS).

AFAIK these do not use filter insertion etc to work.
Are these therefore handled at the decoder level, in which case:-

a: they will not benefit from doing things at the format level.

b: J2K will be an exception to the current way of doing things, which
could add confusion.

If they are not currently handled at the decoder level, the surely the
format level must already handle this material correctly so why is your
patch needed in this form?

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/mxf: Map codec_tag for Avid files if everything else fails

[tim nicholson]

On 22/07/15 11:10, Carl Eugen Hoyos wrote:
 Tomas Härdin tomas.hardin at codemill.se writes:
 
 New patch attached.

 Looks alright. You can reindent in a separate patch 
 if you like.
 
 Merged by Michael with the reindentation.
 
 There is still a cropping issue for the given sample:
 Am I correct that the generic descriptors 0x3208 and 
 0x3209 should be used as display size with 0x320B as 
 vertical offset (and 0x320A as horizontal offset)?
 

That is my understanding.

 [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Change version byte for JPEG2000 to match mxf.c and RP224v12

[tim nicholson]

On 15/06/15 13:13, Michael Niedermayer wrote:
 This should make no difference as the byte is ignored
 
 Found-by: tim nicholson nicho...@yahoo.com
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfdec.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
 index 7389555..b3c25b7 100644
 --- a/libavformat/mxfdec.c
 +++ b/libavformat/mxfdec.c
 @@ -1156,7 +1156,7 @@ static const MXFCodecUL 
 mxf_data_essence_container_uls[] = {
  };
  
  static const MXFCodecUL mxf_codec_uls[] = {
 -{ { 
 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
  }, 14,   AV_CODEC_ID_JPEG2000 },
 +{ { 
 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
  }, 14,   AV_CODEC_ID_JPEG2000 },
  { { 
 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
  },  0,  AV_CODEC_ID_NONE },
  };
  
 
LGTM ;)

Also just noticed that we now have both MXFCodecUL ff_mxf_codec_uls[]
and MXFCodecUL mxf_codec_uls[] in the mxf codebase. similar names
similar functionality and one a subset of the other. Yet more UL
confusion in mxf land to eventually untangle.

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: Detect jpeg2000 through codec_ul too

[tim nicholson]

On 12/06/15 18:05, Michael Niedermayer wrote:

 Fixes Ticket2345

 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfdec.c |   14 ++
  1 file changed, 14 insertions(+)

 diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
 index 78e2393..7389555 100644
 --- a/libavformat/mxfdec.c
 +++ b/libavformat/mxfdec.c
 @@ -166,6 +166,7 @@ typedef struct MXFDescriptor {
  enum MXFMetadataSetType type;
  UID essence_container_ul;
  UID essence_codec_ul;
 +UID codec_ul;
  AVRational sample_rate;
  AVRational aspect_ratio;
  int width;
 @@ -974,6 +975,9 @@ static int mxf_read_generic_descriptor(void *arg, 
 AVIOContext *pb, int tag, int
  case 0x3004:
  avio_read(pb, descriptor-essence_container_ul, 16);
  break;
 +case 0x3005:
 +avio_read(pb, descriptor-codec_ul, 16);
 +break;
  case 0x3006:
  descriptor-linked_track_id = avio_rb32(pb);
  break;
 @@ -1151,6 +1155,11 @@ static const MXFCodecUL 
 mxf_data_essence_container_uls[] = {
  { { 
 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
  },  0, AV_CODEC_ID_NONE },
  };
  
 +static const MXFCodecUL mxf_codec_uls[] = {
 +{ { 
 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x09,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00
  }, 14,   AV_CODEC_ID_JPEG2000 },
_/

mxf.c already has:-

{ { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x07,0x04,0x01,0x02,0x02,0x03,0x01,0x01,0x00 
}, 14,   AV_CODEC_ID_JPEG2000 }, /* JPEG2000 Codestream */
/

and my copy of RP224v12 agrees with that registry version byte. Since the
version byte is ignored this should make no functional difference, but it is
inconsistent with what we already have, and the published spec.


 +{ { 
 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00
  },  0,  AV_CODEC_ID_NONE },
 +};
 +
  static const char* const mxf_data_essence_descriptor[] = {
  vbi_vanc_smpte_436M,
  };
 @@ -1950,6 +1959,11 @@ static int mxf_parse_structural_metadata(MXFContext 
 *mxf)
  /* TODO: drop PictureEssenceCoding and SoundEssenceCompression, only 
 check EssenceContainer */
  codec_ul = mxf_get_codec_ul(ff_mxf_codec_uls, 
 descriptor-essence_codec_ul);
  st-codec-codec_id = (enum AVCodecID)codec_ul-id;
 +if (st-codec-codec_id == AV_CODEC_ID_NONE) {
 +codec_ul = mxf_get_codec_ul(mxf_codec_uls, 
 descriptor-codec_ul);
 +st-codec-codec_id = (enum AVCodecID)codec_ul-id;
 +}
 +
  av_log(mxf-fc, AV_LOG_VERBOSE, %s: Universal Label: ,
 avcodec_get_name(st-codec-codec_id));
  for (k = 0; k  16; k++) {

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Allow overriding /manual setting of the signal standard

[tim nicholson]

On 06/06/15 02:23, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c |   10 ++
  1 file changed, 10 insertions(+)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index c612747..f2a7f0a 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -316,6 +316,7 @@ typedef struct MXFContext {
  uint32_t instance_number;
  uint8_t umid[16];/// unique material identifier
  int channel_count;
 +int signal_standard;
  uint32_t tagged_value_count;
  AVRational audio_edit_rate;
  } MXFContext;
 @@ -2104,6 +2105,8 @@ static int mxf_write_header(AVFormatContext *s)
  
  sc-signal_standard = 1;
  }
 +if (mxf-signal_standard = 0)
 +sc-signal_standard = mxf-signal_standard;
  } else if (st-codec-codec_type == AVMEDIA_TYPE_AUDIO) {
  if (st-codec-sample_rate != 48000) {
  av_log(s, AV_LOG_ERROR, only 48khz is implemented\n);
 @@ -2627,7 +2630,12 @@ static int mxf_interleave(AVFormatContext *s, AVPacket 
 *out, AVPacket *pkt, int
 mxf_interleave_get_packet, 
 mxf_compare_timestamps);
  }
  
 +#define COMMON_OPTIONS \

nit MXF_COMMON_OPTIONS ?
feels more comfortable to me when grepping the code etc.

 +{ signal_standard, Force/set Sigal Standard,\
 +  offsetof(MXFContext, signal_standard), AV_OPT_TYPE_INT, {.i64 = -1}, 
 -1, 8, AV_OPT_FLAG_ENCODING_PARAM},
 +

Isn't 07h the largest valid value (G.2.3)? Or do I misunderstand the
constraint values? (AVOPTION not my strong point)

I thought numeric options were deprecated these days in favour of more
understandable string values, or are the string values also too obscure
to be useful in this case? (Just wondering what the current protocol was
on this nowadays, not a real concern in this case)

  static const AVOption mxf_options[] = {
 +COMMON_OPTIONS
  { NULL },
  };
  
 @@ -2641,6 +2649,7 @@ static const AVClass mxf_muxer_class = {
  static const AVOption d10_options[] = {
  { d10_channelcount, Force/set channelcount in generic sound essence 
 descriptor,
offsetof(MXFContext, channel_count), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 
 8, AV_OPT_FLAG_ENCODING_PARAM},
 +COMMON_OPTIONS
  { NULL },
  };
  
 @@ -2654,6 +2663,7 @@ static const AVClass mxf_d10_muxer_class = {
  static const AVOption opatom_options[] = {
  { mxf_audio_edit_rate, Audio edit rate for timecode,
  offsetof(MXFContext, audio_edit_rate), AV_OPT_TYPE_RATIONAL, 
 {.dbl=25}, 0, INT_MAX, AV_OPT_FLAG_ENCODING_PARAM },
 +COMMON_OPTIONS
  { NULL },
  };
  
 

otherwise LGTM.

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Test-please ignore

[tim nicholson]

Test of address munging on new server
-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Accept MXF D-10 with 49.999840 Mbit/sec

[tim nicholson]

On 01/06/15 20:35, Michael Niedermayer wrote:
 This is the maximum rate possible based on the frame size limit of MXF D-10
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index e0ae14e..7e41c5c 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -2080,7 +2080,7 @@ static int mxf_write_header(AVFormatContext *s)
  
  sc-video_bit_rate = st-codec-bit_rate ? st-codec-bit_rate : 
 st-codec-rc_max_rate;
  if (s-oformat == ff_mxf_d10_muxer) {
 -if (sc-video_bit_rate == 5000) {
 +if (sc-video_bit_rate = 4840  sc-video_bit_rate = 
 5000) {

As well as allowing setting of correct rate for 3000/1001, this could
allow setting of non standard bit rates between/including the two
figures for both frame rates, which might happen if someone made a
typo/guess. Surely better to do:-

if (sc-video_bit_rate == 5000)  (mxf-time_base.den == 25)
sc-index = 3;

else if (sc-video_bit_rate = 4840  (mxf-time_base.den != 25)
sc-index = 5;

else if ...


  if (mxf-time_base.den == 25) sc-index = 3;
  else  sc-index = 5;
  } else if (sc-video_bit_rate == 4000) {
 


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Correct klv_fill_key

[tim nicholson]

On 29/05/15 23:26, Michael Niedermayer wrote:
 See SMPTE 377-1-2009 6.3.3 KLV Fill Items
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c|2 +-
  tests/ref/lavf/mxf  |6 +++---
  tests/ref/lavf/mxf_d10  |2 +-
  tests/ref/lavf/mxf_opatom   |2 +-
  tests/ref/lavf/mxf_opatom_audio |2 +-
  5 files changed, 7 insertions(+), 7 deletions(-)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 63471e6..e0ae14e 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -334,7 +334,7 @@ static const uint8_t index_table_segment_key[] = { 
 0x06,0x0E,0x2B,0x34,0x02,
  static const uint8_t random_index_pack_key[]   = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x11,0x01,0x00
  };
  static const uint8_t header_open_partition_key[]   = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x02,0x01,0x00
  }; // OpenIncomplete
  static const uint8_t header_closed_partition_key[] = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x02,0x04,0x00
  }; // ClosedComplete
 -static const uint8_t klv_fill_key[]= { 
 0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x03,0x01,0x02,0x10,0x01,0x00,0x00,0x00
  };
 +static const uint8_t klv_fill_key[]= { 
 0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x03,0x01,0x02,0x10,0x01,0x00,0x00,0x00
  };
  static const uint8_t body_partition_key[]  = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x03,0x04,0x00
  }; // ClosedComplete
  
  

I agree the registry version was incorrect, I think there are others
too. So LGTM.


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Correct klv_fill_key

[tim nicholson]

On 01/06/15 15:01, Michael Niedermayer wrote:
 On Mon, Jun 01, 2015 at 07:11:38AM +0100, tim nicholson wrote:
 On 29/05/15 23:26, Michael Niedermayer wrote:
 See SMPTE 377-1-2009 6.3.3 KLV Fill Items

 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c|2 +-
  tests/ref/lavf/mxf  |6 +++---
  tests/ref/lavf/mxf_d10  |2 +-
  tests/ref/lavf/mxf_opatom   |2 +-
  tests/ref/lavf/mxf_opatom_audio |2 +-
  5 files changed, 7 insertions(+), 7 deletions(-)

 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 63471e6..e0ae14e 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -334,7 +334,7 @@ static const uint8_t index_table_segment_key[] = { 
 0x06,0x0E,0x2B,0x34,0x02,
  static const uint8_t random_index_pack_key[]   = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x11,0x01,0x00
  };
  static const uint8_t header_open_partition_key[]   = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x02,0x01,0x00
  }; // OpenIncomplete
  static const uint8_t header_closed_partition_key[] = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x02,0x04,0x00
  }; // ClosedComplete
 -static const uint8_t klv_fill_key[]= { 
 0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x03,0x01,0x02,0x10,0x01,0x00,0x00,0x00
  };
 +static const uint8_t klv_fill_key[]= { 
 0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x03,0x01,0x02,0x10,0x01,0x00,0x00,0x00
  };
  static const uint8_t body_partition_key[]  = { 
 0x06,0x0E,0x2B,0x34,0x02,0x05,0x01,0x01,0x0D,0x01,0x02,0x01,0x01,0x03,0x04,0x00
  }; // ClosedComplete
  
  

 I agree the registry version was incorrect,
 
 applied
 
 
 I think there are others
 too. So LGTM.
 
 do you know of any specific ones ?
 or just a general feeling that theres more?
 

I think I spotted a couple of others when I was trawling through, but I
wanted to simplify the UL layout first to make it easier to spot these
anomalies.

I had in mind to do something along the lines of bmxlib using macros to
define the common first 7 byte parts according to Registry where they
are defined, then it might be easier to see some of these oddities

 also the  MPEG video Descriptor short thingies (0x800X) differ from
 what ive seen in other implementations but i couldnt find a
 proper reference that lists them, i wonder if someone maybe knows
 where to look?
 

Not sure either mxf spec only uses below 7F.FF! There are also errors in
the normative table Annex H in S377, for example local tag 08.01 is
listed twice with 2 different UL's, hence tidying things up is a bit of
a 'mare.



-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Support storing signal standard

[tim nicholson]

On 24/05/15 02:15, Michael Niedermayer wrote:
 also store 1 for D10
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c|   11 +++
  tests/ref/lavf/mxf  |6 +++---
  tests/ref/lavf/mxf_d10  |2 +-
  tests/ref/lavf/mxf_opatom   |2 +-
  tests/ref/lavf/mxf_opatom_audio |2 +-
  5 files changed, 17 insertions(+), 6 deletions(-)
 

Do we want to make this an edge case for D10 muxing only, or should we
be aiming for it to be more universal?

Personally I try to avoid edge cases but I can see that trying to be
more universal could be difficult for a number of reasons in this case.

If we keep this as an edge case perhaps the commit message should say so:-

 Support storing signal standard for D10 muxing

or some such.
(I can see a number of similar issues on the horizon too.)

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/05/15 16:50, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 03:35:42PM +0100, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19/05/15 14:11, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 12:07:24PM +0100, tim nicholson wrote:
 On 19/05/15 01:33, Michael Niedermayer wrote:
 [...]
 the avchroma locations are explained by the ascii art above the enum
:
  *  X   X  3 4 X  X are luma samples,
  * 1 21-6 are possible chroma positions
  *  X   X  5 6 X  0 is undefined/unknown position

 and from this the english directions are exactly where the chroma
 samples are located, this also matches how H264 defines chroma
 locations.

 I cannot get the ascii art to make sense to me at all, it just doesn'
t
 click. I do no see how you can represent co-siting in ascii art wit
h a
 single character and the 3 position certainly doesn't do it for me!
 
 ascii art improved
 does it make sense now ?
 

Better, but I still cannot see the difference between say 3 and 4, or 1
and 2.

 [...]

My understanding of S377 using 2/3 ascii chars/pixel is:-

00h:-

YC Y- YC -Y-
YC Y- YC -Y-
YC Y- YC -Y-

01h:-

Y- C- Y- C- Y-
Y- C- Y- C- Y-
Y- C- Y- C- Y-

03h:-

Y-Y-
- -- C- --
Y-Y-

05h:-

YCr Y- YCr
YCb Y- YCb
YCr Y- YCr

06h:-


Y- Y- Y- Y-
C- C- C- C-
Y- Y- Y- Y-

Not all samples are retained dependening upon the subsampling scheme.
- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVXYdQAAoJEAwL/ESLC/yD0NMH/jTJYQG8ZLtwMKbDWAfvkUzk
FWhWJxVQl3JBftxmjkB7JRtRebX6XbDklUi2OQplIzAhbqLdQIJHgDC8enYRIRBf
FJE4qTPltyJ/taOuXeM1IGwrAdbXql+wIakQbwXYfu07dZ3fLAFk63u6mBx+pLeo
l3JpVwOMQsxvjnnrrEr73mKlVk9vo99+tjJiBng5UR02SLfp/6Blvyl4HhyCMYZr
WvZf/pKhETmxjhYMhM/tBncgzeA5gW6q7onFsdBM8g+n/nxSF/nQrXXlkWlWN4hN
M4gnWwVddKbdmaP/kZBzJsIfKnEsH7em2rFOseMrmtvSImDZVpIpRFkG8pVe1JY=
=9Pkq
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/05/15 11:47, Michael Niedermayer wrote:
 On Thu, May 21, 2015 at 08:20:48AM +0100, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19/05/15 16:50, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 03:35:42PM +0100, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19/05/15 14:11, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 12:07:24PM +0100, tim nicholson wrote:
 On 19/05/15 01:33, Michael Niedermayer wrote:
 [...]
 the avchroma locations are explained by the ascii art above the en
um
 :
  *  X   X  3 4 X  X are luma samples,
  * 1 21-6 are possible chroma positions
  *  X   X  5 6 X  0 is undefined/unknown position

 and from this the english directions are exactly where the chroma
 samples are located, this also matches how H264 defines chroma
 locations.

 I cannot get the ascii art to make sense to me at all, it just does
n'
 t
 click. I do no see how you can represent co-siting in ascii art w
it
 h a
 single character and the 3 position certainly doesn't do it for m
e!

 ascii art improved
 does it make sense now ?


 Better, but I still cannot see the difference between say 3 and 4, or
 1
 and 2.
 
 Ive tried to improve the text and ASCII even more
 does it make sense now ?
 

Still don't understand why two colour sample sites per pixel.

Please don't waste any more time fiddling with this, I expect it will
suddenly click in my brain when I least expect it. Oh hang on I think it
just did, you superimpose the second art on top of the first so the 3 is
on top of the X but the 4 is between them etc etc

In which case I think I agree with your mappings, sorry its taken so lon
g ;(

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


- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVXeXUAAoJEAwL/ESLC/yD/XwH+wfNWVEQ877APxfpO4fGmkc9
4WDvc8E4tzwVda6FKw+LuSLFHAQcHnuaZLcwXRfLeXrQpgsZUEqagJ/A4A8eDsFp
GI0BZLiHROOnHBAZ5yYNd3q6Y8lJump4LK/XgjOIURlnk5wEJ6nkM3sjqoP4JoDU
EkEDf1ZYAeddRnu/hfZp7o8wNqhXoreh8FBj2Sznli4jDr680WfffwavNfJ6WSF7
QRfCZ9wNSw7JrVs02BsT90VDLXh45+2DeFfQqf2XC7apYZ/1gRY97hLMu+M52NQZ
mgXTSR6gTiBU7EPwR7Mq5MS1x4Za8d2uPJy+OIdGOp4wUllrCMrgEnA+Nc47Hb0=
=wsE6
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/05/15 11:29, Michael Niedermayer wrote:
 On Thu, May 21, 2015 at 08:20:48AM +0100, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19/05/15 16:50, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 03:35:42PM +0100, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 19/05/15 14:11, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 12:07:24PM +0100, tim nicholson wrote:
 On 19/05/15 01:33, Michael Niedermayer wrote:
 [...]
 the avchroma locations are explained by the ascii art above the en
um
 :
  *  X   X  3 4 X  X are luma samples,
  * 1 21-6 are possible chroma positions
  *  X   X  5 6 X  0 is undefined/unknown position

 and from this the english directions are exactly where the chroma
 samples are located, this also matches how H264 defines chroma
 locations.

 I cannot get the ascii art to make sense to me at all, it just does
n'
 t
 click. I do no see how you can represent co-siting in ascii art w
it
 h a
 single character and the 3 position certainly doesn't do it for m
e!

 ascii art improved
 does it make sense now ?


 Better, but I still cannot see the difference between say 3 and 4, or
 1
 and 2.

 [...]

 My understanding of S377 using 2/3 ascii chars/pixel is:-

 00h:-

 YC Y- YC -Y-
 YC Y- YC -Y-
 YC Y- YC -Y-
 
 S377-2009 speaks about the first sample of the image only
 The first luma sample of the image is co-sited with the first color d
ifference sample(s), as in ITU-R Rec
  601, SMPTE 314M 4:1:1 or MPEG-2 4:2:2.
 

...and ITU-R Rec 601 dicates Orthogonal, line, field and frame
repetitive. CR and CB samples co-sited with odd (1st, 3rd, 5th, etc.) Y
samples in each line

 Your ASCII art matches my interpretation of this though 00h can be
 more than 4:2:2, it explicitly also lists 4:1:1

agreed.

 
 

 01h:-

 Y- C- Y- C- Y-
 Y- C- Y- C- Y-
 Y- C- Y- C- Y-
 
 This implies 4:4:4

I was indicating sample sites, which I then qualified with a:-

Not all samples are retained dependening upon the subsampling scheme.

 
 
 Y- C- Y- Y- C- Y-
 Y- C- Y- Y- C- Y-
 Y- C- Y- Y- C- Y-
 
 would be possible too
 not to mention the mxf text for 01h
 The color sample is sited at the point horizontally midway between th
e luma sample on each line.
 does not say which luma samples are used for the midpoint
 also it speaks about color sample while 00h speaks about
 color difference sample(s)
 color samples would be RGB, difference Cb Cr. the MXF spec isnt
 really wording this very unambigously
 
 

 03h:-

 Y-Y-
 - -- C- --
 Y-Y-
 
 This ascii art seems to be faulty in some form it looks like
 chroma had more positions than luma horizontally
 

Seems to have picked up an extra dash from what I wrote...
1 c to 2 Y horizontally and vertically


 

 05h:-

 YCr Y- YCr
 YCb Y- YCb
 YCr Y- YCr

 
 06h:-


 Y- Y- Y- Y-
 C- C- C- C-
 Y- Y- Y- Y-
 
 The text from the spec is
 The color sample is sited at the point vertically midway between the 
luma sample on each column, as in
  MPEG-2 4:2:0.
 
 i think your ascii art matches how i would interpet it for 4:4:0 or
 4:4:4, not sure if you intended this to be not 4:2:0


I refer to my previous qualification:-

Not all samples are retained dependening upon the subsampling scheme.

Which matches how S413m tries to explain it by showing all sample sites
even though some are discarded.


Not withstanding any of this don't let it hold up the patch, I twas not
my intention to bikeshed just trying to get my head around whats right.

 
 
 [...]
 

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVXeJhAAoJEAwL/ESLC/yDLXAIALtpwEEHV/FdM+ClziRTjSEu
pVL5pIMvBnR1V/QpXv6n00gFcGdYUBWOTH2HrKgcW+3gY64ofyhukm0k4vTaV5HE
zoSbne33QKaoN/x9LSiiCLPn5oMmtOLQornhLLUxHp8aXMGl66ejlUJzJSQTfxHL
ME4tV1+bZz7HOJlfFOWPI9+2DNI3eroRqguNHr4S8HMVY3NhH8ysuCueOcqLNoAQ
zWGI/tPsuirTrvRt0iGC/iJhoh6PknVnndYoiMlYOzZs3/0294i9V3qEaQMgLmmr
9dD0XHUkTdo0Y7CP2zZZYDwz6KfWhP7sjmwZ6eIyI7wUkthsVKBFLD+x1tfIU/M=
=KFhi
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 21/05/15 11:59, Michael Niedermayer wrote:
 On Thu, May 21, 2015 at 09:00:56AM +0200, Tomas Härdin wrote:
 [..]
 Why is this guessing code in mxfenc? This should be something that'
s
 taken care of before calling any muxer (like in
 avformat_write_header()), so everyone can benefit from it and so ther
e's
 less risk of duplication when it's needed elsewhere.

 I've seen stunts like this pulled in more places than mxfenc, where
 muxers will do dubious things like parse certain kinds of essence. I 
am
 not a fan.
 
 nor am i, ill try to move it into common code
 

+1 to both your comments its why I have hesitated on some of the other
mxf metadata thats been requested.


 thanks
 [...]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVXeZTAAoJEAwL/ESLC/yDWeQIALJn7YieWo7yKqmyBjsHAA8p
cSqYgLOcFufG7Hx1/sag8AfSExRe1LIcaQUR4RY8s54bUP4gmNk51je49QVlCAUo
3z6O0/0J/mkP/+M5GZ4fVKrKXj+HmL6t5keFbtxZnWFNz9nCjcWTNCGvMj0/KKfY
G5nw/owzdu2intMdqgQYM0sblCmErAVogyasABn/lGqvWrt2H0KBs+eBICtiY1ac
y667sBE4MrxCRtY3a1erDmXJSlOY7L5qFJFaYDLKx5i3mO4oeqZgHGrTnF7cojQ1
Q6iM23Zc220IIwyoCaEULGxenTS+FAz178wdAwO4Ydor238aDzlMRJdzi2iydYo=
=+djy
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

On 19/05/15 01:33, Michael Niedermayer wrote:
 The default is assumed to be 0xFF, which is what the 2009 spec lists,
 the older version i have lists 0 as the default.
 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c|   28 +
  tests/ref/lavf/mxf  |   12 +--
  tests/ref/lavf/mxf_d10  |2 +-
  tests/ref/lavf/mxf_opatom   |2 +-
  tests/ref/lavf/mxf_opatom_audio |2 +-
  tests/ref/seek/lavf-mxf |   44 
 +++
  6 files changed, 59 insertions(+), 31 deletions(-)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 659c34f..0af3db1 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -79,6 +79,7 @@ typedef struct MXFStreamContext {
  int interlaced;  /// whether picture is interlaced
  int field_dominance; /// tff=1, bff=2
  int component_depth;
 +int color_siting;
  int h_chroma_sub_sample;
  int temporal_reordering;
  AVRational aspect_ratio; /// display aspect ratio
 @@ -416,6 +417,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
  // CDCI Picture Essence Descriptor
  { 0x3301, 
 {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x05,0x03,0x0A,0x00,0x00,0x00}},
  /* Component Depth */
  { 0x3302, 
 {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x05,0x00,0x00,0x00}},
  /* Horizontal Subsampling */
 +{ 0x3303, 
 {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x06,0x00,0x00,0x00}},
  /* Color Siting */
  // Generic Sound Essence Descriptor
  { 0x3D02, 
 {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x03,0x01,0x04,0x00,0x00,0x00}},
  /* Locked/Unlocked */
  { 0x3D03, 
 {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x03,0x01,0x01,0x01,0x00,0x00}},
  /* Audio sampling rate */
 @@ -996,6 +998,8 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
 AVStream *st, const UID ke
  unsigned desc_size = size+8+8+8+8+8+8+8+5+16+sc-interlaced*4+12+20;
  if (sc-interlaced  sc-field_dominance)
  desc_size += 5;
 +if (sc-color_siting != 0xFF)
 +desc_size += 5;
  
  mxf_write_generic_desc(s, st, key, desc_size);
  
 @@ -1030,6 +1034,12 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
 AVStream *st, const UID ke
  mxf_write_local_tag(pb, 4, 0x3302);
  avio_wb32(pb, sc-h_chroma_sub_sample);
  
 +if (sc-color_siting != 0xFF) {
 +// color siting
 +mxf_write_local_tag(pb, 1, 0x3303);
 +avio_w8(pb, sc-color_siting);
 +}
 +

If the value as far as we can determine is unknown, should we not
write that value (0xFF), rather than leave the metadata out, and hope
that any reader will assume the 2009 default rather than the previous,
different default? It would seem to me to be more universal.

I'm generally wary of leaving out values just because they are some
default especially if that default is subject to change.

  // frame layout
  mxf_write_local_tag(pb, 1, 0x320C);
  avio_w8(pb, sc-interlaced);
 @@ -2037,11 +2047,29 @@ static int mxf_write_header(AVFormatContext *s)
  // Default component depth to 8
  sc-component_depth = 8;
  sc-h_chroma_sub_sample = 2;
 +sc-color_siting = 0xFF;
  
  if (pix_desc) {
  sc-component_depth = pix_desc-comp[0].depth_minus1 + 1;
  sc-h_chroma_sub_sample = 1  pix_desc-log2_chroma_w;
  }
 +switch (st-codec-chroma_sample_location) {
 +case AVCHROMA_LOC_TOPLEFT: sc-color_siting = 0; break;
 +case AVCHROMA_LOC_LEFT:sc-color_siting = 6; break;
 +case AVCHROMA_LOC_TOP: sc-color_siting = 1; break;
 +case AVCHROMA_LOC_CENTER:  sc-color_siting = 3; break;

If these mappings are correct, then the AVCHROMA_LOC_ names are
certainly not intuitive (and the comments unhelpful), and bear little
relation to the way SMPTE S377 describes the positioning!

e.g.
pixfmt.h line 541-
AVCHROMA_LOC_TOPLEFT = 3, /// DV

SMPTE S377 page 165-
00h coSiting...as in ITU-R Rec 601, SMPTE 314M 4:1:1 or MPEG-2 4:2:2.



 +case AVCHROMA_LOC_UNSPECIFIED:
 +if (pix_desc) {
 +if (pix_desc-log2_chroma_h == 0) {
 +sc-color_siting = 0;
 +} else if (pix_desc-log2_chroma_w == 1  
 pix_desc-log2_chroma_h == 1) {
 +switch (st-codec-codec_id) {
 +case AV_CODEC_ID_MPEG2VIDEO: sc-color_siting = 6; 
 break;

Only true for 4:2:0 mpeg2, what about 4:2:2 (XDCAM-HD) or does the 'if'
filter that out? (I'm not that familiar with the pix_desc struct).

 +}
 +}
 +}
 +break;
 +}
  
  mxf-timecode_base = (tbc.den + tbc.num/2) / tbc.num;
  spf = 

Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: Add color siting element

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 19/05/15 14:11, Michael Niedermayer wrote:
 On Tue, May 19, 2015 at 12:07:24PM +0100, tim nicholson wrote:
 On 19/05/15 01:33, Michael Niedermayer wrote:
 The default is assumed to be 0xFF, which is what the 2009 spec lists
,
 the older version i have lists 0 as the default.

 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c|   28 +
  tests/ref/lavf/mxf  |   12 +--
  tests/ref/lavf/mxf_d10  |2 +-
  tests/ref/lavf/mxf_opatom   |2 +-
  tests/ref/lavf/mxf_opatom_audio |2 +-
  tests/ref/seek/lavf-mxf |   44 +++-
- ---
  6 files changed, 59 insertions(+), 31 deletions(-)

 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 659c34f..0af3db1 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -79,6 +79,7 @@ typedef struct MXFStreamContext {
  int interlaced;  /// whether picture is interlaced
  int field_dominance; /// tff=1, bff=2
  int component_depth;
 +int color_siting;
  int h_chroma_sub_sample;
  int temporal_reordering;
  AVRational aspect_ratio; /// display aspect ratio
 @@ -416,6 +417,7 @@ static const MXFLocalTagPair mxf_local_tag_batch
[] = {
  // CDCI Picture Essence Descriptor
  { 0x3301, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x
05,0x03,0x0A,0x00,0x00,0x00}}, /* Component Depth */
  { 0x3302, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x
05,0x01,0x05,0x00,0x00,0x00}}, /* Horizontal Subsampling */
 +{ 0x3303, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x
05,0x01,0x06,0x00,0x00,0x00}}, /* Color Siting */
  // Generic Sound Essence Descriptor
  { 0x3D02, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x04,0x04,0x02,0x
03,0x01,0x04,0x00,0x00,0x00}}, /* Locked/Unlocked */
  { 0x3D03, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x05,0x04,0x02,0x
03,0x01,0x01,0x01,0x00,0x00}}, /* Audio sampling rate */
 @@ -996,6 +998,8 @@ static void mxf_write_cdci_common(AVFormatContex
t *s, AVStream *st, const UID ke
  unsigned desc_size = size+8+8+8+8+8+8+8+5+16+sc-interlaced*4+1
2+20;
  if (sc-interlaced  sc-field_dominance)
  desc_size += 5;
 +if (sc-color_siting != 0xFF)
 +desc_size += 5;
  
  mxf_write_generic_desc(s, st, key, desc_size);
  
 @@ -1030,6 +1034,12 @@ static void mxf_write_cdci_common(AVFormatCon
text *s, AVStream *st, const UID ke
  mxf_write_local_tag(pb, 4, 0x3302);
  avio_wb32(pb, sc-h_chroma_sub_sample);
  
 +if (sc-color_siting != 0xFF) {
 +// color siting
 +mxf_write_local_tag(pb, 1, 0x3303);
 +avio_w8(pb, sc-color_siting);
 +}
 +

 If the value as far as we can determine is unknown, should we not
 write that value (0xFF), rather than leave the metadata out, and hope
 that any reader will assume the 2009 default rather than the previous
,
 different default? It would seem to me to be more universal.

 I'm generally wary of leaving out values just because they are some
 default especially if that default is subject to change.
 
 i was trying to avoid breaking things by favoring not writing it
 as is done in git currently.
 But maybe iam too carefull here, do you think we can safely write
 0xFF always ? (which could happen if the user does not provide any
 information about the chroma location or pixel format

I should say so, but I wonder if Tomas has a view.

 
 or should this be tested with some applications? if so with what
 applications ?
 

Currently bmxlib reports an ffmpeg.mxf as:-

color_siting: Unknown (value='255')

i.e, in the absence of the metadata entry it assumes the correct
default, so forcibly setting it will make no difference here (or with
any other up to date reader). Its only for anything conforming to the
old standard of which I do not know a sample.

 

  // frame layout
  mxf_write_local_tag(pb, 1, 0x320C);
  avio_w8(pb, sc-interlaced);
 @@ -2037,11 +2047,29 @@ static int mxf_write_header(AVFormatContext 
*s)
  // Default component depth to 8
  sc-component_depth = 8;
  sc-h_chroma_sub_sample = 2;
 +sc-color_siting = 0xFF;
  
  if (pix_desc) {
  sc-component_depth = pix_desc-comp[0].depth_m
inus1 + 1;
  sc-h_chroma_sub_sample = 1  pix_desc-log2_chrom
a_w;
  }
 +switch (st-codec-chroma_sample_location) {
 +case AVCHROMA_LOC_TOPLEFT: sc-color_siting = 0; break;
 +case AVCHROMA_LOC_LEFT:sc-color_siting = 6; break;
 +case AVCHROMA_LOC_TOP: sc-color_siting = 1; break;
 +case AVCHROMA_LOC_CENTER:  sc-color_siting = 3; break;

 If these mappings are correct, then the AVCHROMA_LOC_ names are
 certainly not intuitive (and the comments unhelpful), and bear little
 relation to the way SMPTE S377 describes the positioning

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: Set the component depth from the pixel format if available

[tim nicholson]

On 16/05/15 19:18, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c |7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 5966792..14449c9 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -39,6 +39,7 @@
  #include libavutil/random_seed.h
  #include libavutil/timecode.h
  #include libavutil/avassert.h
 +#include libavutil/pixdesc.h
  #include libavutil/time_internal.h
  #include libavcodec/bytestream.h
  #include libavcodec/dnxhddata.h
 @@ -2029,10 +2030,16 @@ static int mxf_write_header(AVFormatContext *s)
  }
  
  if (st-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
 +const AVPixFmtDescriptor *pix_desc = 
 av_pix_fmt_desc_get(st-codec-pix_fmt);
  // TODO: should be avg_frame_rate
  AVRational rate, tbc = st-time_base;
  // Default component depth to 8
  sc-component_depth = 8;
 +
 +if (pix_desc) {
 +sc-component_depth = pix_desc-comp[0].depth_minus1 + 1;
 +}
 +
  mxf-timecode_base = (tbc.den + tbc.num/2) / tbc.num;
  spf = ff_mxf_get_samples_per_frame(s, tbc);
  if (!spf) {
 

LGTM

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: Set horizontal chroma subsample value from pixel format if available

[tim nicholson]

On 16/05/15 19:18, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  libavformat/mxfenc.c |7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
 index 14449c9..659c34f 100644
 --- a/libavformat/mxfenc.c
 +++ b/libavformat/mxfenc.c
 @@ -79,6 +79,7 @@ typedef struct MXFStreamContext {
  int interlaced;  /// whether picture is interlaced
  int field_dominance; /// tff=1, bff=2
  int component_depth;
 +int h_chroma_sub_sample;
  int temporal_reordering;
  AVRational aspect_ratio; /// display aspect ratio
  int closed_gop;  /// gop is closed, used in mpeg-2 frame parsing
 @@ -1027,7 +1028,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, 
 AVStream *st, const UID ke
  
  // horizontal subsampling
  mxf_write_local_tag(pb, 4, 0x3302);
 -avio_wb32(pb, 2);
 +avio_wb32(pb, sc-h_chroma_sub_sample);
  
  // frame layout
  mxf_write_local_tag(pb, 1, 0x320C);
 @@ -2035,9 +2036,11 @@ static int mxf_write_header(AVFormatContext *s)
  AVRational rate, tbc = st-time_base;
  // Default component depth to 8
  sc-component_depth = 8;
 +sc-h_chroma_sub_sample = 2;
  
  if (pix_desc) {
 -sc-component_depth = pix_desc-comp[0].depth_minus1 + 1;
 +sc-component_depth = pix_desc-comp[0].depth_minus1 + 1;
 +sc-h_chroma_sub_sample = 1  pix_desc-log2_chroma_w;
  }
  
  mxf-timecode_base = (tbc.den + tbc.num/2) / tbc.num;
 

LGTM

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Allow easy png streamcopying

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 27/04/15 13:16, Nicolas George wrote:
 L'octidi 8 floréal, an CCXXIII, Michael Niedermayer a écrit :
 the code changes look ok
 
 The phrasing seems to invite this:
 
 The commit message does not shock me.
 
 Seriously, I do not know how my message about commit messages ended be
ing so
 long, I do not intend to become a commit message tyrant, I just wanted
 to
 raise awareness about the issue.
 

You made some sensible points, that will hopefully lead to clearer
future commits, if it took that many words to make the point so be it. I
do not consider you a tyrant [ yet ;) ].

 [..]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVQdz+AAoJEAwL/ESLC/yD2ggH/jDHgzJohwr/MFrqpNtSmBCZ
qs3x2as/k9UjxU2yINv/q8MYJaM3gl1Gnr6EuZ/apTxggEXYI/DW4yf1smeKaTW0
pu4eAQZSKU8xJ3jCGGzcokR27ZVlNdYg32SkCh7mw1DQ9UlXG+fXL5uZVP10TPGz
TpgHXHjZ3KoYxbXU1MScrxU3qoQO0oV3PLRr647U1DjjNn8WZQkqbJwEdsTSL//q
S/UYuELzWXkLwumYW4VdoczEwnjchXQypGv8CwuhmBnvNnMRRuJm3WgZL5lKgI0c
RkVK8PFSUP1Exa0Q/OGHoEjTxLrk/B3Z+6XHq/9yBkWb5dfIjBtJYSSUJQE9oA0=
=MtTV
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Relaxed pattern to find ProRes in MXF.

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/04/15 16:32, Steve Dierker wrote:
 Hello,
 
 I support this patch if you didn't make the 
 file yourself.
 I only had one sample.
 
 This sample is from the same customer as the other ProRes in MXF sampl
e
 I uploaded for the bug. (Doner Advertisment)
 I found it while searching for the reason why FFmpeg refused to encode
 some files after the bug was fixed.
 I don't know if the pattern is to relaxed or if there are any other
 ul's indicating ProRes. I just orientated myself at the DnxHD
 definitions.

DNX is not in the private UL scope, and has three ranges in ffmpeg, one
of which I believe to be completely wrong (SMPTE RP224 lists them as
tiff formats), but was obviously included for some reason at some stage,
so I'm not sure its a good template.

It would be good to get a full set of Avid Prores.mxf samples to try and
see how they have structured their UL's, I only have windows machines
currently to hand, so that is a way off.

I am currently looking at the whole range of UL's to see if they can be
tidied up, but that will also take some time, so perhaps in the
interests of progress use your suggestion for now *but* change the
inline comment to something like:-

/* Avid MC7 Prores */

That will assist in identifying why the entry is there if we need to
update things, especially if the codec moves into the officially
recognised scope, as DNX did.

Given the interest in Prores in MXF from AMWA that is quite likely imho.

 
 best,
 Steve
 
 [...]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVHQlxAAoJEAwL/ESLC/yDIfYIAMKTctzbP4qNVWbnOLvlBz/g
I9JNwvYIR33Jf18bsDJJMX7QaPgnO8y3yExAOHZM7ZCEICK130b79nTWQpVrLhB/
GChnExo69UO7xSprr+RG1hypxnFw6RTf9kK2IpT1aFxRDDSXbiYoG4JyQWMLdo7w
O+Mo1/Hz+ftUkOO7twGK4rOwMLl+LjyLhAOXwQ9/xKf57g3cjOB4wBIIk78apOLT
zTD9eD2+xH/L8TciLsXC5cGPbU9UJT1JukVuKbF/7P4edLNKRno4RunJjK29poIv
iDBSWYd6Js5f3oDZZlyKCnElwPkYEjPUN7h8Zx0tf3M9/mbgjCI3+K0lNBbuEAk=
=97j1
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Relaxed pattern to find ProRes in MXF.

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/04/15 10:57, Steve Dierker wrote:
 Hello,
 

 I am currently looking at the whole range of UL's to see if they can
 be tidied up, but that will also take some time, so perhaps in the
 interests of progress use your suggestion for now *but* change the
 inline comment to something like:-

 /* Avid MC7 Prores */

 That will assist in identifying why the entry is there if we need to
 update things, especially if the codec moves into the officially
 recognised scope, as DNX did.

 
 I changed the comment and updated the patch. Here is the new file.
 

+{ {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x02,0x0d,0x01,0x03,0x01,0x02,0x04,0x
60,0x02
}, 14, AV_CODEC_ID_MPEG2VIDEO }, /* Ikegami */

Errm where did this coming from, its unrelated (and wrong afaik as its a
container UL).


 btw: Is this the intended way to offer patches to FFmpeg?

if you mean git format-patch against master, yes.

 
 best,
 Steve
 [...]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVHS0dAAoJEAwL/ESLC/yDEhYIALvaJcXst47BXby0UbhQzpLy
HVGOHUQzvDIHgcbUq+K7o3cs9JCrWvBKZCX3Wqvi9rPsB7scQqucTv0bTiz+vjO6
Y5QQCwRIitExcefOsDfZzy62szqg/8oUSQsohkJOMxdMt6904ucwVQFdzy7RJBVU
khgfCffoCCMeQlBZr7Lm+48HpioGwZvZXLIT9aJdzct886gqaS1MpCEsVDStsXTs
GH+mHp+64euNekpnfhMZ0xUl4vxKAOynR6tvfgCq5big76vP+aiVmKE7ovygep7I
YROkUlgkBWb+rphTZ7XXKLPJni6KC3OHML3IHY5FirQhmuPp2hBzS+AMmgLuSlQ=
=+Y3d
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Relaxed pattern to find ProRes in MXF.

[tim nicholson]

On 31/03/15 13:41, Steve Dierker wrote:
 Hello List,
 
 I found another MXF File containing ProRes with the following
 codec_uls: 060E2B34040101010E04020102110500
 Therefor I relaxed the pattern.
 

Are the Prores variants likely to be that big?
Difficult I know for private UL's

I wonder if we shouldn't be a little more cautous in widening the scope,
where was the sample from?

 Related to issue #4349
 ---
  libavformat/mxf.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 [...]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata

[tim nicholson]

Some software mis decodes IMX material in mxf if this metadata field is
missing. See the discussion on the ffmpeg ML:-

[FFmpeg-user] How to set 3 specific metadata flags
(ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?

This patch add this field to mxf wrapped material.
-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
From 7ab1565acb1320a6eaafd47cbae86a8415419274 Mon Sep 17 00:00:00 2001
From: Tim Nicholson tim.nichol...@bbc.co.uk
Date: Mon, 30 Mar 2015 11:11:17 +0100
Subject: [PATCH] libavformat/mxfenc.c: Add 'Presentation Y offset' metadata

Previously unset, and some software mishandles files if it is absent

Signed-off-by: Tim Nicholson tim.nichol...@bbc.co.uk
---
 libavformat/mxfenc.c  | 7 ++-
 tests/ref/lavf/mxf| 6 +++---
 tests/ref/lavf/mxf_d10| 2 +-
 tests/ref/lavf/mxf_opatom | 2 +-
 4 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ac60357..7b400b3 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -406,6 +406,7 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
 { 0x3202, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x02,0x01,0x00,0x00,0x00}}, /* Stored Height */
 { 0x3209, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0C,0x00,0x00,0x00}}, /* Display Width */
 { 0x3208, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0B,0x00,0x00,0x00}}, /* Display Height */
+{ 0x320B, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x05,0x01,0x0E,0x00,0x00,0x00}}, /* Presentation Y offset */
 { 0x320E, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x01,0x04,0x01,0x01,0x01,0x01,0x00,0x00,0x00}}, /* Aspect Ratio */
 { 0x3201, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x06,0x01,0x00,0x00,0x00,0x00}}, /* Picture Essence Coding */
 { 0x3212, {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x02,0x04,0x01,0x03,0x01,0x06,0x00,0x00,0x00}}, /* Field Dominance (Opt) */
@@ -978,7 +979,7 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
 int stored_height = (st-codec-height+15)/16*16;
 int display_height;
 int f1, f2;
-unsigned desc_size = size+8+8+8+8+8+8+5+16+sc-interlaced*4+12+20;
+unsigned desc_size = size+8+8+8+8+8+8+8+5+16+sc-interlaced*4+12+20;
 if (sc-interlaced  sc-field_dominance)
 desc_size += 5;
 
@@ -1003,6 +1004,10 @@ static void mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const UID ke
 mxf_write_local_tag(pb, 4, 0x3208);
 avio_wb32(pb, display_heightsc-interlaced);
 
+// presentation Y offset
+mxf_write_local_tag(pb, 4, 0x320B);
+avio_wb32(pb, (st-codec-height - display_height)sc-interlaced);
+
 // component depth
 mxf_write_local_tag(pb, 4, 0x3301);
 avio_wb32(pb, sc-component_depth);
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 8ead434..5fb984b 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-306708cc2ad2414def89fa2f3c0bfc5c *./tests/data/lavf/lavf.mxf
+613b160bf09927661d9455dd975ad780 *./tests/data/lavf/lavf.mxf
 525369 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xdbfff6f1
-f465084f0c365926a81aab56fb6b945c *./tests/data/lavf/lavf.mxf
+64471cfc480751f2ca7998c4edbc7a02 *./tests/data/lavf/lavf.mxf
 560697 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0x11a6178e
-52fc707e1177c97232e2537168c232e6 *./tests/data/lavf/lavf.mxf
+a546bd6d8fe1608690bf2fc326cab0c3 *./tests/data/lavf/lavf.mxf
 525369 ./tests/data/lavf/lavf.mxf
 ./tests/data/lavf/lavf.mxf CRC=0xdbfff6f1
diff --git a/tests/ref/lavf/mxf_d10 b/tests/ref/lavf/mxf_d10
index 71707ca..8201557 100644
--- a/tests/ref/lavf/mxf_d10
+++ b/tests/ref/lavf/mxf_d10
@@ -1,3 +1,3 @@
-8f601d5b55a0665cc105a115dc8b3af0 *./tests/data/lavf/lavf.mxf_d10
+22dca5c8d62fe7ad1c56416ae736d6c1 *./tests/data/lavf/lavf.mxf_d10
 5330989 ./tests/data/lavf/lavf.mxf_d10
 ./tests/data/lavf/lavf.mxf_d10 CRC=0x6c74d488
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index 5529e5b..0dd59c1 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-0f753a141424e2a1b44e6390f70172eb *./tests/data/lavf/lavf.mxf_opatom
+5df0bb1083cbe0ef3a70e4a93e44d812 *./tests/data/lavf/lavf.mxf_opatom
 4717113 ./tests/data/lavf/lavf.mxf_opatom
 ./tests/data/lavf/lavf.mxf_opatom CRC=0xbdd696b9
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 30/03/15 13:21, Michael Niedermayer wrote:
 On Mon, Mar 30, 2015 at 12:31:04PM +0200, tomas.har...@codemill.se wro
te:
 On 2015-03-30 12:19, tim nicholson wrote:
 Some software mis decodes IMX material in mxf if this metadata field
 is
 missing. See the discussion on the ffmpeg ML:-

 [FFmpeg-user] How to set 3 specific metadata flags
 (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?

 This patch add this field to mxf wrapped material.

 Looks fine, but I know from experience that all this stuff gets
 tricky quickly. Like there should be mechanisms in lavf for dealing
 with presentation rectangles and all that jazz, including different
 aspect ratios at different layers.
 
 should i apply this patch or wait ?
 

Apply, as per IRC comments..

 [...]



- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVGUmLAAoJEAwL/ESLC/yDmY0H/06658q5T2xtRpu2SRDlyLAY
GVLbxpnlWu6s4ss4uB3GRmuGvlZuj2SmJxsvn4s7lKDRiEQIByw2FWIuws5y8CMQ
+KhN9nXD2V5D+bHIBTeodb4vfFwLtA33ImPqrpnRawjvQi+b+Bm8Y1qUP1pRxEDF
yKOVH1nG2ynNHBbzZgxNAhboGk2nIBHO9JRyMeGSR8XMCiQlsiXPvZcgLXVQ0htR
e8DORhEHyNBKX6X6TxJlbqMwakPb+p9SfMXkjKdgzsrWyjz76gHqesDhgnhGwJ8S
ApM+ja8Xiy3Q9npNmPxu2RpduDXJ6pJgt87rSn9ZVBs/c2SaT7/pROLL/Pj33T4=
=VFpd
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add 'Presentation Y offset' metadata

[tim nicholson]

On 30/03/15 11:31, tomas.har...@codemill.se wrote:
 On 2015-03-30 12:19, tim nicholson wrote:
 Some software mis decodes IMX material in mxf if this metadata field is
 missing. See the discussion on the ffmpeg ML:-

 [FFmpeg-user] How to set 3 specific metadata flags
 (ITU601/displayoffset) in FFmpegs IMX50 MXF-OP1a encoding?

 This patch add this field to mxf wrapped material.
 
 Looks fine, but I know from experience that all this stuff gets tricky
 quickly. Like there should be mechanisms in lavf for dealing with
 presentation rectangles and all that jazz, including different aspect
 ratios at different layers.
 

Well I thought about adding the X offset too for completeness, but
currently due to the lack of the above mechanisms there didn't seem much
point as there was nothing to set it from..

(one use would be the 720/702 blanking which some systems also want,
but I can see no current programmatical way of setting it.)

 /Tomas
 [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Why is writing the colr atom not the default in the mov muxer?

[tim nicholson]

On 21/02/15 01:34, Dave Rice wrote:
 Hi Robert, Kevin,
 
 On Feb 20, 2015, at 9:56 AM, Robert Krüger krue...@lesspain.de wrote:

 Am Freitag, 20. Februar 2015 schrieb Kevin Wheatley :

 On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger krue...@lesspain.de
 javascript:; wrote:
 if I read the code correctly, the colr atom is only written in the mov
 muxer if the flag write_colr is specified. Was that behaviour chosen to
 have better backward compatibility or is there another reason not to
 write
 this standard atom by default?

 I chose that way to preserve the older behaviour, as it can change how
 files will be interpreted.

 I assumed that but isn't the change then a change for the better (then
 maybe requiring a version bump and an entry in the release notes)? After
 all Apple muxers write it by default as well and not trusting the input
 metadata seems to me like something that should be opt-out rather than
 opt-in but that's just my 2c.
 
 That's also my two cents and I also wondered why users have to opt-in to a 
 correctly written file. The QuickTime spec says that colr is required with 
 some streams (such as raw uyvy422 and v210), see: 
 https://developer.apple.com/library/mac/technotes/tn2162/_index.html#//apple_ref/doc/uid/DTS40013070-CH1-TNTAG9.
 
 I'd propose that colr be written by default. The interpretation may be 
 different but, since a file with a colr atom is more self-descriptive, the 
 interpretation is more likely to be correct.

+1

 Dave Rice
 
 [...]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc: Compensate for hardware trying to mess with aspect ratio of DVD content.

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 17/01/15 23:52, Nicolas George wrote:
 L'octidi 28 nivôse, an CCXXIII, Kieran Kunhya a écrit :
 There is a very simple way of flagging content that is supposed to comply
 with BT601: the SAR is 512/351. If SAR is 64/45, that means someone before
 nvenc decided that the video is not expected to conform with BT601, and
 nvenc has no right to decide otherwise.
 You fail to realise this but SARs are not necessarily arithmetic for
 historical reasons.
 
 Care to explain how historical reasons can change the laws of geometry?
 
 If a visible surface with a physical aspect ratio of 16/9 is cut into
 702×576 identical rectangular pixels, then the aspect ratio of each pixel is
 (16/9) / (702/576) = 512/351. Can you give one good reason for FFmpeg to
 use, internally, any other value?
 

I am struggling to follow some of the arguments, which seem far to
heated to be as useful as they could be.

However, as I understand the issue, whilst the above maths sound fine,
the visible surface mentioned above is framed within an actual surface
of 720x576 pixels which includes the 'digital overscan'

Taking the Sample/pixel aspect ratio (SAR) calculated above and feeding
that back into calculating a display aspect ratio *for the whole frame*
leads to a value that is not 16:9 (or 4:3), and it appears to be this
figure which is then reported as the DAR, rather than that of the active
picture. This is I think the disjoint between DAR and SAR that Kieran
refers to, there is only a mathematical relationship if you include the
overscan.

It would appear that in some cases the SAR is calculated back from a
specified DAR of 16/9 being applied as the aspect ratio of the whole
frame and this seems to be the usual cause of issues (Adobe had to admit
they had got it wrong for years as they had assumed that 720x576 was 4/3
aspect ratio).

I am not sure what is currently wrong, and where, but please let us not
'fix' one scenario with a dirty hack that breaks hoers.


 Regards,



- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUvR+WAAoJEAwL/ESLC/yDE2sH/0/ig2fasBb4QdEjx3wkhKSX
SXQP09mt44LNY9hP+EtiDQWyt1Wv4K5XuGwMSuyb48TRilxkjzxvej2m7Gh9oIny
XYuk+MIOycU/JLrN7jcY/vLbvyFo9zZirsEZyx2dkHpyt8TvHgNnMuwaAX7SBHPf
I73icHhzfipPtambgqRtRuxRThQ3yeCTiTWdF24VWywJhjGgT41TyeqpREfRoptb
+uqKbvQheWWe8W3cOAzzmud3PXPqI8fj7X/Y56I0qqEWaRLxEcawOQziE9qK7qCs
7256QUgmEI3gJTfrVY7RJ5EFMM512IhKGCGAUNW1clrb9r2y8M4+ZZC1Mgo9UcE=
=pjDp
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Unable to transcode audio from broadcast ts stream

[tim nicholson]

On 08/01/15 06:58, William Juwono wrote:
 Hi,
 I am having problem transcoding the audio of the following file. This is 
 captured from broadcast ts stream.http://www.datafilehost.com/d/cb3d03be
 If I use acodec copy, the resulting audio played fine, however, if I 
 transcode to other formats, ie: aac, mp3, it resulted in chopped audio.Can 
 someone looked at this?
 ThanksWilliam   
 [..]

As this is the developer list, you are unlikely to get an answer to this
question.

May I suggest reposting to the ffmpeg user list, and in order to save
the inevitable first reply, please include complete uncut console output
for a failed trasncode.

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: export the full UMID as metadata

[tim nicholson]

On 06/01/15 19:01, Mark Reid wrote:
 On Tue, Jan 6, 2015 at 12:03 AM, tim nicholson 
 nichot20-at-yahoo@ffmpeg.org wrote:
 
 On 05/01/15 20:41, Mark Reid wrote:
 Hi,
 This patch exports the full umid of packages as metadata. ffmpeg
 currently
 only exports the material number portion of the umid.

 The new format is
ISO label-length-instance number-material number
 example:
060a2b340101010101010f00-13-00-53dc416b9a770251060e2b347f7f2a80


 I think this is a good idea, but if we are going to make the change can
 we make the exported format be SMPTE330 compliant? Annex C (normative)
 states:-

 By default, the hexadecimal representation should be preceded by the
 identifier ‘0x’. This default method of identification will result in 66
 hexadecimal characters to represent a basic UMID as follows:
 0x060A2B340101010501010D13 ... etc.
 The hexadecimal letters should be encoded as upper case (A...F).


 sounds like the right thing to do to me.
 
 so if I understand correctly
 060a2b340101010101010f00-13-00-53dc416b9a770251060e2b347f7f2a80
 
 should be just
 0x060A2B340101010101010F00130053DC416B9A770251060E2B347F7F2A80
 
 easy enough, I'll submit a new patch doing that instead.
 ___
 [..]

That's right. drop the '-' add the 0x prefix and upper case it.
Saves a byte :)

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: export the full UMID as metadata

[tim nicholson]

On 05/01/15 20:41, Mark Reid wrote:
 Hi,
 This patch exports the full umid of packages as metadata. ffmpeg currently
 only exports the material number portion of the umid.
 
 The new format is
ISO label-length-instance number-material number
 example:
060a2b340101010101010f00-13-00-53dc416b9a770251060e2b347f7f2a80
 

I think this is a good idea, but if we are going to make the change can
we make the exported format be SMPTE330 compliant? Annex C (normative)
states:-

By default, the hexadecimal representation should be preceded by the
identifier ‘0x’. This default method of identification will result in 66
hexadecimal characters to represent a basic UMID as follows:
0x060A2B340101010501010D13 ... etc.
The hexadecimal letters should be encoded as upper case (A...F).


 Some applications use the umids to link to mxf media instead using file paths.
 I've been using ffmpeg for some AAF work and have encountered
 MXF files with different ISO labels and having just the material number alone 
 is not
 enough to link to media for Media Composer.
 
 For more on umids, this paper explains them pretty well
 http://www.digitalpreservationeurope.eu/publications/briefs/UMID_Unique%20Material%20Identifier.pdf
 
 umids also have a optional extened 32 bytes, but I've yet to see a file that
 has them.
 
 Mark Reid (1):
   libavformat/mxfdec.c: export the full UMID as metadata
 
  libavformat/mxfdec.c | 39 ---
  1 file changed, 32 insertions(+), 7 deletions(-)
 


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: add deinterleave filters

[tim nicholson]

On 06/01/15 16:31, compn wrote:
 On Tue, 6 Jan 2015 10:10:53 +
 Paul B Mahol one...@gmail.com wrote:
 
 On 1/6/15, Stefano Sabatini stefa...@gmail.com wrote:
 On date Monday 2015-01-05 16:33:44 +, Paul B Mahol encoded:
 Signed-off-by: Paul B Mahol one...@gmail.com
  3 files changed, 147 insertions(+)
  create mode 100644 libavfilter/f_deinterleave.c

 select works as this, with the expression:
 select=n=N:e='mod(n,N)'

 I forgot that select can do it, so patch dropped.
 
 should that select line go into the manual / examples somewhere?
 

I think the last example is a version of that, (assuming the misssing +1
above is a typo, as if e=0 the frame is dropped)

 -compn
 [.]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_idet: Add analyze_interlaced_flag mode

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/01/15 16:57, Michael Niedermayer wrote:
 On Mon, Jan 05, 2015 at 01:00:41PM +, tim nicholson wrote:
 On 01/01/15 01:56, Michael Niedermayer wrote:
 This should allow us to insert idet before scale and let scale have 
 interl=-1 as default in that case

 Good thinking.

 How would interl=-1 then get set as default for auto inserted filters.
 Or did I miss something?
 
 it maybe could be set when the filter togeter with idet is inserted
 i havnt implemented that yet though, idet doesnt support every format
 that scale supports so it cant be done unconditionally
 

Ahh, right.

Am I correct in thinking that currently there is no command line way to
globally override the default (interl=0) so that any auto inserted
filters use the required settings? I see nothing in sws_flags.

I am sort of thinking of a kind of partial implementation workaround
where a file is probed and the command line auto constructed based on
what is found, then provided the format is OK the default can be
changed. This would also be useful in all sorts of other ways when auto
inserted filters are likely.

 [...]



- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJUq5BuAAoJEAwL/ESLC/yDK0YIAIa1jjr9i8k9krY5HhNi7L05
YQrjDZMHZ+35D+sMgeX1/4M/tKNT09bhKhY0YFwIf2v5IDNpGCq7NjfOLuoTntSt
P/KFlij9J3zjIhs/nqNt/oKBQRF1ZbFYaQlszeNk84DONHT9qNxODgL959tRpJIx
sepbuJQfYMJcIYwuggGk3UR04iO/IFdqSABJfuuuQGNehuLPS7m0LnYbZ1Tjtco9
YvDQOJduMiZ96lV6EZDZSb/wxYiyHQWRu2qBcdlkQSpjzOV1qR28DOzcYO+ebDSf
Z4phc8j97vuiHrr+YAQSVXG0B3+/avfWIRFq3oh+rFnW0T5WqcgeDYqGh/O5VT4=
=gWUO
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_idet: Add analyze_interlaced_flag mode

[tim nicholson]

On 01/01/15 01:56, Michael Niedermayer wrote:
 This should allow us to insert idet before scale and let scale have interl=-1 
 as default in that case

Good thinking.

How would interl=-1 then get set as default for auto inserted filters.
Or did I miss something?

 
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: Add ascii graphics to clarify what the currently implemented tinterlace modes do

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/12/14 19:47, Michael Niedermayer wrote:
 On Fri, Dec 05, 2014 at 01:43:09PM +0100, Michael Niedermayer wrote:
 On Thu, Dec 04, 2014 at 04:57:09PM +, tim nicholson wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 04/12/14 16:09, Clément Bœsch wrote:
 [..]

 This representation requires way more efforts to me to understand than the
 one from Michael...


 Just shows how different minds think/work ;)

 As the saying goes, one man's meat is another man's poison.

 I was going for consistency with current work (which I happened to find
 clear) and I liked having the extra detail of line numbers.

 iam fine with either but id like to see one of them or a combination
 pushed. pushing neither would be worst ...

 so which solution do people prefer?
 
 seems people dont care
 
 so applied mine, feel free to replace by something else, iam fine with
 any way of documenting it as long as it is documented
 

People don't want choice, they just want what they want. I suspect those
with the most pertinent view on the docs style generally are users
new(ish) to ffmpeg who don't subscribe to this list.

My experience generally is that end user documentation is best not
written by developers as they cannot approach the subject from the view
point of an outsider coming new to a feature. This is a luxury ffmpeg is
not in a position to be able to afford so we do what we can, and respond
as best we can if users squawk.

Lets see if there is any further noise on the subject and if so we can
look to tweaking things. In the meantime as you say pushing neither
would be worst, and you got 100% of the votes cast so progress has been
made.

 
 [...]



- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUhVv7AAoJEAwL/ESLC/yDVlgH/0aTM27YoG8dwZ128z+rLzVQ
1+vJq8X9xjVR0yXemMG5QRkWagj7z1hhRuZMtVVkMEKIRkvxxlENwlgNrDryjRVm
GPgorWq0jkTiX0DRsF40hxqFwIavJBujZoXAmi/8B2ouJcGaVCjsKBOkDsN3RfEM
1/pbUKKLCMnU3dl49DtIFOThfztuFmDzscbwnqQf05/+rMHpYeHONwir1gsTnrOU
nEFkm8Nc84ROCcD4j5hV+GiIumThrDzYS85C9aIu9xodgrsRk13o1KWqvLvFSsrk
i69wa9C2T4GpfD6I3DWTs54oGONH2X3yZeKmvFPzK0pBoehm7deKKlO1DJxvahQ=
=mtPR
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: Add ascii graphics to clarify what the currently implemented tinterlace modes do

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/12/14 17:13, Michael Niedermayer wrote:
 On Tue, Dec 02, 2014 at 05:02:49PM +, tim nicholson wrote:
 On 02/12/14 15:33, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  doc/filters.texi |  131 
 ++
  1 file changed, 131 insertions(+)

 diff --git a/doc/filters.texi b/doc/filters.texi
 index 8c16c7a..0ea3955 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -8537,33 +8537,164 @@ Available values are:
  @item merge, 0
  Move odd frames into the upper field, even into the lower field,
  generating a double height frame at half frame rate.
 +@example
 + -- time
 +Input:
 +Frame 1 Frame 2 Frame 3 Frame 4
 +
 +1   2   3   4
 +1   2   3   4
 +1   2   3   4
 +1   2   3   4
 +
 +Output:
 +1   3
 +2   4
 +1   3
 +2   4
 +1   3
 +2   4
 +1   3
 +2   4
 [..]

 I find the ascii graphic style of the interlace filter more
 understandable
 
 how do you suggest above (and the other modes) would be documented
 in that style ?
 

Sorry for the delayed reply ISP issue...

I think the main difference is going left to right, not top to bottom
for input to output, this then matches not only interlace but the
general filtergraph descriptions.

I will try and see if I can give an example if you like.

 
 [...]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUgBpMAAoJEAwL/ESLC/yDxkEH/1hWM5A1P3V3cz2XH3pF01/0
64e4A9RRx0BpX0pDHqik9aVNQtL+qSBFYkkQGPn8smTdqWEQXfIe/lWQSXODj95T
+/Un1V33cxnPznJnTCfxrZEKuYbEQYehyuasGcgzq/L0CIYamGJmuWZ4feZKQ0Vk
ZdCAs/ygX9igc7V+41UG5dQu6n+nhIwAkOAJBiGkeVMKu76YH19fF/G4TO7tYczn
GbVgKfu78LK8cZZOWl3w42EO7aF98TeG6q29jQsiDABLNa8JocIVmxaijbaIEJ3R
2Eb5yzCeyZadgOrenRzF9iR0W4JvlXK2Expqr15SISRjVJ4L8AjZqs6nPOsraHY=
=KKl4
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/tinterlace: merge code with interlace

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/12/14 13:08, Michael Niedermayer wrote:
 On Tue, Dec 02, 2014 at 07:43:47PM +0100, Clément Bœsch wrote:
 ---
 After this commit, interlace doesn't behave the same if the input frames
 are already interlaced. Does anyone wants me to keep this behaviour?
 
 probably best if its kept but can be forced enabled/disabled with
 an option. these interlacing flags on the input can be wrong
 

+1

 otherwise LGTM
 
 [...]



- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUgBvNAAoJEAwL/ESLC/yDOmMH/3U73HxpvOsW4QwvfBDQFeD0
dMqyo9NgZFUzsNLptORc9ifRXQrDpxvhkmhPtqpCgpgLBV+E88VyXCEo+QPrq8AY
l617h6Wb/FbRHT4opYTfU2DsSgdNKalAZacrckY1dGFNEACQRg04n8jGkbyK5gu/
1YXFknMic92Vq29uwPrymrmvcGyWtjj2goTL/6ikVbAdFGQ6dks21PR412YUqk6z
BcVuWXxXv9HZft2pfE1edcT3FEqiJL/iKZmzq91i6vzkyS5xeHXkLgCNc+P3NfOx
pPvKl4lFhRFMh4OTxVT82EqUvrFovgH3bRXXocQeIxuzf+BXzrkVZOSMPjtoG1o=
=bJWr
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/tinterlace: merge code with interlace

[tim nicholson]

On 02/12/14 18:43, Clément Bœsch wrote:
 ---
 After this commit, interlace doesn't behave the same if the input frames
 are already interlaced. Does anyone wants me to keep this behaviour?
 
 Also, the PTS adjustments might be different, but I didn't follow the
 current discussions about it so I can't tell what people want.
 ---
  libavfilter/Makefile|   2 +-
  libavfilter/interlace.h |  58 -
  libavfilter/tinterlace.h|   5 +-
  libavfilter/vf_interlace.c  | 250 
 
  libavfilter/vf_tinterlace.c |  44 +++
  libavfilter/x86/Makefile|   2 +-
  libavfilter/x86/vf_interlace_init.c |  47 ---
  7 files changed, 49 insertions(+), 359 deletions(-)
  delete mode 100644 libavfilter/interlace.h
  delete mode 100644 libavfilter/vf_interlace.c
  delete mode 100644 libavfilter/x86/vf_interlace_init.c
 
 [..]

The docs will need updating to remove the vf_interlace entry and add the
lp filter options. Maybe that is the time to merge the ascii art
graphics and add Michael's additional mode ones as well?


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/tinterlace: merge code with interlace

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/12/14 09:59, Clément Bœsch wrote:
 On Thu, Dec 04, 2014 at 09:31:47AM +, tim nicholson wrote:
 On 02/12/14 18:43, Clément Bœsch wrote:
 ---
 After this commit, interlace doesn't behave the same if the input frames
 are already interlaced. Does anyone wants me to keep this behaviour?

 Also, the PTS adjustments might be different, but I didn't follow the
 current discussions about it so I can't tell what people want.
 ---
  libavfilter/Makefile|   2 +-
  libavfilter/interlace.h |  58 -
  libavfilter/tinterlace.h|   5 +-
  libavfilter/vf_interlace.c  | 250 
 
  libavfilter/vf_tinterlace.c |  44 +++
  libavfilter/x86/Makefile|   2 +-
  libavfilter/x86/vf_interlace_init.c |  47 ---
  7 files changed, 49 insertions(+), 359 deletions(-)
  delete mode 100644 libavfilter/interlace.h
  delete mode 100644 libavfilter/vf_interlace.c
  delete mode 100644 libavfilter/x86/vf_interlace_init.c

 [..]

 The docs will need updating to remove the vf_interlace entry and add the
 lp filter options. Maybe that is the time to merge the ascii art
 graphics and add Michael's additional mode ones as well?

 
 None of the filter disappear and their options don't change. It's just
 code refactoring.

Sorry misread it only looking at the diff. I thought there was a
funtionality merger as well as per the irc discussion.

 [..]


- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUgFaLAAoJEAwL/ESLC/yDRGkH/j2ZXp+JcWgfvTIG5+/U5Nrk
uDA9Gpn+QQKQHjaF+AHCL8d1KPmXlnKgbha2r9V4EBHiSyZDTNOcio9T0IvY+YDG
wbnTuCSV6SaBgm8LvKrvB2B/OC4aMFoP8aYyE10Ghqkd2HHG7jGcctPrlAIdmvpP
K6VbHFP+RKuvQLvQPX2SPigcGvUQV566azYguzum82k4CV4+kwugUCDNgGeds8rO
ySy/DoeTai0cm5A+PA3ojKMaWkuZt5AN6WFFGcYvamwLDa/WZfK8SlcpvPZoH9y9
9DYizi3PDOfyojpXKoMsi6n3zRpKJ9x7TETA+hUZ8mcJDxnhCvFhYIDeQXrt8LY=
=m1ni
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: Add ascii graphics to clarify what the currently implemented tinterlace modes do

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/12/14 16:09, Clément Bœsch wrote:
 [..]
 
 This representation requires way more efforts to me to understand than the
 one from Michael...
 

Just shows how different minds think/work ;)

As the saying goes, one man's meat is another man's poison.

I was going for consistency with current work (which I happened to find
clear) and I liked having the extra detail of line numbers.

 [...]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBAgAGBQJUgJJlAAoJEAwL/ESLC/yDmdQH/1BHNlTjS9omO0g28P7+TAXu
vpGI7kUxJWFH7txUHhRNf33lHbFFmYdKeb/lIfuiPFXvOtUgeTnmARf8RPIN82e4
7LPFIuN9BFuu78GpyjY/ZEQOUhsT8WK/5c/xWzgJDTo87WsqmQcZe1TuJW945U16
mEZnPfCoYnV4OO/Bu68FJjEMHX4MafIB5VKxhK28/6ymbSJl5v8h9uyFzEZ3TZgF
48bSSYNM4T1KwkJPQsDN+0X5YXeAjA+ZTbB1K5qBQAOZYY4Qj2oCSetl09G6XynG
FjeYUxsDCwI97/+x2i+0K6UIBj9Ey/iJRUat1QP4F1FoHQKz5WHpMN5/4XYblU0=
=ulRP
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/vf_tinterlace: Favor using standard timebases for the output

[tim nicholson]

On 01/12/14 22:32, Kieran Kunhya wrote:
 Sent from my mobile device
 [...]
 
 I would strongly advise all users of these filters generate their own
 timestamps.

Which would require much better documentation of such usage.
(e.g. the only references to the use of genpts inn ffmpeg docs are in
passing on the trac wiki)

 [...]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] doc/filters: Add ascii graphics to clarify what the currently implemented tinterlace modes do

[tim nicholson]

On 02/12/14 15:33, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer michae...@gmx.at
 ---
  doc/filters.texi |  131 
 ++
  1 file changed, 131 insertions(+)
 
 diff --git a/doc/filters.texi b/doc/filters.texi
 index 8c16c7a..0ea3955 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -8537,33 +8537,164 @@ Available values are:
  @item merge, 0
  Move odd frames into the upper field, even into the lower field,
  generating a double height frame at half frame rate.
 +@example
 + -- time
 +Input:
 +Frame 1 Frame 2 Frame 3 Frame 4
 +
 +1   2   3   4
 +1   2   3   4
 +1   2   3   4
 +1   2   3   4
 +
 +Output:
 +1   3
 +2   4
 +1   3
 +2   4
 +1   3
 +2   4
 +1   3
 +2   4
 [..]

I find the ascii graphic style of the interlace filter more
understandable
-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Mention in the documentation that fieldmatch needs cfr input

[tim nicholson]

On 23/10/14 17:06, Dave Rice wrote:
 On Oct 23, 2014, at 4:05 AM, Clément Bœsch u...@pkh.me wrote:
 On Tue, Oct 21, 2014 at 09:32:39AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 It appears to me that we all know that fieldmatch needs cfr input, 
 but it isn't mentioned in the documentation.
 Related to ticket #3968.

 Please comment, Carl Eugen

 diff --git a/doc/filters.texi b/doc/filters.texi
 index c70ddf3..bc77623 100644
 --- a/doc/filters.texi
 +++ b/doc/filters.texi
 @@ -4447,6 +4447,9 @@ and VIVTC/VFM (VapourSynth project). The later is a 
 light clone of TFM from
 which @code{fieldmatch} is based on. While the semantic and usage are very
 close, some behaviour and options names can differ.

 +The filter only works for strictly constant frame rate input. If your input
 +has variable frame rate, try the @ref{pullup} filter.
 +

 Well... isn't telecined content supposed to be CFR anyway? I would say
 it's supposed to be undefined behaviour in any ivtc filter but well. No
 opinion really.
 
 This would be ideal, but some common production applications use VFR. For 
 instance when digitizing with the Log and Capture interface of Final Cut Pro 
 the first and last frame usually have custom durations although most of the 
 rest of the file is 2997/100. There’s another setting in the Final Cut to 
 compensate for dropped frames by extending the duration of the last good 
 captured frame.

Not only FCP. Pipelines do it too.

 Dave Rice
 _[..]
-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Facebook page

[tim nicholson]

On 21/10/14 20:21, Lou Logan wrote:
 On Tue, 21 Oct 2014 19:30:39 +0200, Thomas Volkert wrote:
 
 There was also no response from Facebook within the last days.
 
 The behemoth is probably slow to respond. Let's give them some more
 time then perhaps prod them again after not hearing from them for a
 week.
 
 I'd rather have ffmpeg or nothing. Easy for me to say though since I
 haven't done a damned thing to help.

There currently seem to be 4 'pages' called FFmpeg, one auto generated
so that's a bit of work to unpick.


 [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/movenc: AVC Intra support

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/09/14 02:59, Michael Niedermayer wrote:
 On Sun, Sep 28, 2014 at 03:53:15AM +0200, Michael Niedermayer wrote:
 On Sun, Sep 28, 2014 at 02:00:00AM +0100, Kieran Kunhya wrote:
 On 28 September 2014 00:49, Michael Niedermayer michae...@gmx.at wrote:

 This allows remuxing AVC intra into mov
 it does not work with libx264 encoded AVC Intra for unknown reason

 1080i should work. 1080p needs some random magic numbers in the
 bitstream which are probably different for all the
 framerate/resolution combinations. Blame Apple for having a decoder
 that violates the H.264 spec - specifically requiring SEIs to have
 certain information in them.

 i tried various avcintra 50 and 100 and i didnt find any that
 worked. They all crashed fcpx (in apples avci decoder in the case i
 looked at)
 its of course very possible that i made some systematic mistake
 
 if someone has a known to be good set of command line options for
 x264 to generate a working stream + input + output .h264 streams
 that might (or might not) help identify what is at fault
 
 [...]

Some of the DPP AVCI100 test samples were created using x264* so could
be used for reference. Or I could knock up something if I can find my
reference CL I used last time.

*Using libx264 in ffmbc.


- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJUKm7yAAoJEAwL/ESLC/yD/mgIALrkpV2zGILv5X3TAslK6KMl
2f9czw70hPQ6uBXLUiUf3Dr2Fmg7GQ5gP/rZpPIKNiZPXcrdQwTsrU6k1FNNUUZi
OnR9BR3dfwjrH8ekYyy5i3ZjHRktlGBPD3adyQWpENahHtui0jdGMpnMeSc5Mro9
yN3FTRLlB01GHmTR4KG2QO2H6qenMe5jVShAPJbQ2crvJdSI/4mxNpEjLSYBgA5W
Fe09SdNx+1xnHuM15Uq7W2yG3N+lmRQZlscB+eWwo1zwb6SpjUYCjcuggnWaBQl8
qxfXuwIMOT0DgVdVVt5gcARZ43cM14e9rZ+eOc9Qq6RJ4/s44Ua3OYfneQurJPw=
=yTRs
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Do not ask for mxf samples with unknown field dominance

[tim nicholson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/14 21:45, Tomas Härdin wrote:
 On Tue, 2014-08-19 at 22:30 +0200, Michael Niedermayer wrote:
 On Tue, Aug 19, 2014 at 01:30:24AM +0200, Carl Eugen Hoyos wrote:
 Hi!

 Attached patch removes a request for samples of which we already
 have several that all work fine.

 field_dominance can have 256 different values, do we have samples
 for all ? do they even exist ?
 

Whilst the variable may be able to contain 256 different values in
reality there are only two possible states f1 first or f2 first.

 As far as I recall there are only two (1, 2) and possibly unknown (0).
 

Is there a distinction between unknown and progressive? I don't have
the numbers to hand.

 /Tomas
 [..]

- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)

iQEcBAEBAgAGBQJUF+7lAAoJEAwL/ESLC/yD914H/j1iF4mec8zkiVQeySSOOkB+
mebCr5yNhwuYDGQvzCp15nVpLi1y/uyP0TCu+iCJp/pDHR+z8iSO6moKhY+hB0hp
3395I22SujmSa8ODY9NWTrZWqAKnS0Lohfkzva04Tvn31cLskWpQKxPWhBajz0dP
d9G4h9O9YhsVBH1L/UhRHRDwDSeghqjTvnw3U63DoGRitFCKZAARATx0O7iH51Xv
we3Mk7FAgpWfB5GVQ3VQZWkzydsoQZNjtWnGp4kjnqdONOMY8H6EbiqeQuCY2Tfs
yu6OX5KowMAv7YfCrU0J1BlTsl90AA9Rh3KEFhHTjvI75KhAW0KL6x1Oxuz4XcU=
=hjO4
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC]Revert the default for ffplay to -noautoexit

[tim nicholson]

On 07/09/14 21:39, Carl Eugen Hoyos wrote:
 Hi!
 
 I have no strong opinion on this but I wonder if ffplay isn't primarily 
 a test application for which it is very useful not to exit.
 

+1

 Please comment, Carl Eugen
 [..]


-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Test of mail system pllease ignore

[tim nicholson]

Should munge the from headers
-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel