date:20141121

On Fri, 21 Nov 2014 09:01:43 +0100
wm4 nfx...@googlemail.com wrote:

 On Fri, 21 Nov 2014 08:45:47 +0100
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Thu, 20 Nov 2014 18:42:19 +0100
  wm4 nfx...@googlemail.com wrote:
   I think this should be rejected. It's far too special to be
   useful in general, and it's not even pixel- or line-addressable
   (Z-shaped tiles, seriously?). It's pretty much a raw codec, not a
   pixel format.
  
  How do you put this in an AVFrame then ?
 
 Preferably not at all. Is there a need to? Only the end result (nv12 I
 suppose) needs to be in an AVFrame.

It can be done but is ugly IMHO:

- I was under the impression that lavc decoder convention was to
  output non processed formats and let the application handle (or not)
  the conversions

- The decoder code would look like:
 * probe and open decoder
 * feed it with some frames / extradata to get the format from the
   decoder
 * if i dont like the format then:
 * probe and open another random device that may or may not
   exist for format conversion
 * copy/paste the m2m filter code in the decoder to postprocess
   the frames

- If you're thinking about manual conversion then it's a no go: this
  would break the zero copy chain I'm trying to obtain.

   Also, doesn't libv4l2 handle converting this to something sane
   transparently?
  
  transparently yes, but in sw. A 10W arm soc wouldn't like to
  transparently convert 1080p@25fps like that
  
  also, last time I checked, libv4l2 didnt support NV12MT
  
   If this is needed for the m2m filter, then maybe it should be
   part of the v4l2 libavdevice.
  
  I don't understand this.
  
  This is needed for HW decoding on MFCv5: it is the only format
  decoders can produce. To use it in your application, you send it to
  the m2m filter to get something sane.
 
 Sorry, I didn't look too close at the other patches.

It'd be hard to guess this from the other patches anyway, v4l2 driver
is the one that will tell the format, so you won't get much information
without looking at kernel driver code :)

 So this is a
 decoder. Why can't the decoder take care of this conversion too?

See above.

 This
 macroblock format isn't really useful for anything other than the m2m
 filter, but breaks all AVFrame/pixfmt conventions. Additionally, it
 breaks libavfilter conventions: conversions between pixfmts are
 supposed to be handled by libswscale, not arbitrary filters.

I didn't take the time to write swscale support for this because the
format is a bit insane, the code would be ugly and it would be
useless in practice.

I probably missed something but I was under the impression
that av_image_copy  friends should work if frames have the correct
width  height alignment.

The command:
./ffmpeg_g -y -c:v mpeg4_v4l2m2m -i bli.mkv -vf v4l2_m2m -c:v
h264_v4l2m2m -pix_fmt nv12 -c:a ac3 bli.mp4

works like a charm here, no auto-inserted scaler, mpeg4_v4l2m2m
produces nv12mt that is fed to the m2m filter that produces standard
nv12 which is fed to the h264_v4l2m2m encoder

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

[FFmpeg-devel] [PATCH] ffplay: fix mem leak when opening input or parsing options fail.

---
 ffplay.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index f79161d..1914a66 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -3169,8 +3169,9 @@ static int read_thread(void *arg)
 stream_component_close(is, is-video_stream);
 if (is-subtitle_stream = 0)
 stream_component_close(is, is-subtitle_stream);
-if (is-ic) {
-avformat_close_input(is-ic);
+if (ic) {
+avformat_close_input(ic);
+is-ic = NULL;
 }
 
 if (ret != 0) {
-- 
2.2.0.rc2.23.gca0107e

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

Re: [FFmpeg-devel] [PATCH] dashenc: Add a segment_start_number option

Hi,

- Mail original -

[...]

 ...in which I screw up and post the same patch. Here you go...
 
 From f06aa763f3e3593d12cc16d8017e796c9e5db3b3 Mon Sep 17 00:00:00
 2001
 From: Rodger Combs rodger.co...@gmail.com
 Date: Thu, 20 Nov 2014 01:47:05 -0600
 Subject: [PATCH] dashenc: Add a segment_start_number option
 
 ---
  libavformat/dashenc.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)
 
 diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
 index dac217e..549c7c3 100644
 --- a/libavformat/dashenc.c
 +++ b/libavformat/dashenc.c
 @@ -80,6 +80,7 @@ typedef struct DASHContext {
  int total_duration;
  char availability_start_time[100];
  char dirname[1024];
 +int segment_start_number;
  } DASHContext;
  
  static int dash_write(void *opaque, uint8_t *buf, int buf_size)
 @@ -182,10 +183,10 @@ static void dash_free(AVFormatContext *s)
  
  static void output_segment_list(OutputStream *os, AVIOContext *out,
  DASHContext *c)
  {
 -int i, start_index = 0, start_number = 1;
 +int i, start_index = 0, start_number = c-segment_start_number;
  if (c-window_size) {
  start_index  = FFMAX(os-nb_segments   - c-window_size, 0);
 -start_number = FFMAX(os-segment_index - c-window_size, 1);
 +start_number = FFMAX(os-segment_index - c-window_size,
 c-segment_start_number);
  }
  
  if (c-use_template) {
 @@ -193,7 +194,7 @@ static void output_segment_list(OutputStream *os,
 AVIOContext *out, DASHContext
  avio_printf(out, \t\t\t\tSegmentTemplate timescale=\%d\
  , timescale);
  if (!c-use_timeline)
  avio_printf(out, duration=\%d\ , c-last_duration);
 -avio_printf(out,
 initialization=\init-stream$RepresentationID$.m4s\
 media=\chunk-stream$RepresentationID$-$Number%%05d$.m4s\
 startNumber=\%d\\n, c-use_timeline ? start_number : 1);
 +avio_printf(out,
 initialization=\init-stream$RepresentationID$.m4s\
 media=\chunk-stream$RepresentationID$-$Number%%05d$.m4s\
 startNumber=\%d\\n, start_number);
 

Shouldn't this be c-use_timeline ? start_number : c-segment_start_number 
instead?

No other remarks from me.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/pngdec: add APNG support.

Hi,

- Mail original -
 On Thu, Nov 20, 2014 at 03:07:17PM +0100, Benoit Fouet wrote:
  ---
   libavcodec/Makefile |   1 +
   libavcodec/allcodecs.c  |   1 +
   libavcodec/avcodec.h|   1 +
   libavcodec/codec_desc.c |   8 +++
   libavcodec/pngdec.c | 142
   +++-
   5 files changed, 150 insertions(+), 3 deletions(-)
 
 apng is missing a dependancy on zlib in configure (see png in
 configure)
 

Fixed locally. Will resend when/if there are no other points to address.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
 On Thu, 20 Nov 2014 18:40:18 +0100
 Jean-Baptiste Kempf j...@videolan.org wrote:
 
  On 20 Nov, Alexis Ballier wrote :
   This is the only format supported by MFC5 HW decoders (e.g. Samsung
   exynos 4412).
  
  Why not convert it to a normal format?
  
 
 That is exactly what the m2m filter is for: on 4412 you have MFC HW
 codecs and fimc (camera  m2m module); the fimc m2m module acts
 like a filter and accepts this format and outputs much saner ones.

So you have a format outputted that is of no use, except if you use the
filter. And you have a filter that is of no use, except if you use this
v4l2 output.

In my opinion, you should just merge them, so you output something sane.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
   How do you put this in an AVFrame then ?
  
  Preferably not at all. Is there a need to? Only the end result (nv12 I
  suppose) needs to be in an AVFrame.
 
 It can be done but is ugly IMHO:
 
 - I was under the impression that lavc decoder convention was to
   output non processed formats and let the application handle (or not)
   the conversions

Sure, but this is when you can actually process them in applications,
like planar audio. No a hardware-specific format that noone can play
except with a special library.

  So this is a
  decoder. Why can't the decoder take care of this conversion too?
 
 See above.

Sorry, but that's far from clear.

  This
  macroblock format isn't really useful for anything other than the m2m
  filter, but breaks all AVFrame/pixfmt conventions. Additionally, it
  breaks libavfilter conventions: conversions between pixfmts are
  supposed to be handled by libswscale, not arbitrary filters.
 
 I didn't take the time to write swscale support for this because the
 format is a bit insane, the code would be ugly and it would be
 useless in practice.

If it is insane, keep it internal.

 works like a charm here, no auto-inserted scaler, mpeg4_v4l2m2m
 produces nv12mt that is fed to the m2m filter that produces standard
 nv12 which is fed to the h264_v4l2m2m encoder

Then, merge them together, so it only output standard nv12.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 09:58:40 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

 On 21 Nov, Alexis Ballier wrote :
  On Thu, 20 Nov 2014 18:40:18 +0100
  Jean-Baptiste Kempf j...@videolan.org wrote:
  
   On 20 Nov, Alexis Ballier wrote :
This is the only format supported by MFC5 HW decoders (e.g.
Samsung exynos 4412).
   
   Why not convert it to a normal format?
   
  
  That is exactly what the m2m filter is for: on 4412 you have MFC HW
  codecs and fimc (camera  m2m module); the fimc m2m module acts
  like a filter and accepts this format and outputs much saner ones.
 
 So you have a format outputted that is of no use, except if you use
 the filter.

On MFCv5 yes; I don't assume because I'm working on this that it is the
only one :)
MFCv6 and newer don't even understand nv12mt and can output standard
nv12:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35

there are other v4l2 mem2mem drivers than mfc ones, and I expect more
to come in the future

 And you have a filter that is of no use, except if you
 use this v4l2 output.

again, filter is not bound to samsung socs; even fimc is useful
for other format conversions and even scaling:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/exynos4-is/fimc-core.c

(the filter supports fmt conversion and scaling but see also 'missing
features' in the filter patch i've submitted)

I've been using it to convert yuv output of an usb cam to nv12 fed to
the mfc hw enc so that I can stream H263 while leaving the cpu
free for other things.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
  So you have a format outputted that is of no use, except if you use
  the filter.
 
 On MFCv5 yes; I don't assume because I'm working on this that it is the
 only one :)

So, basically, noone can display it, reencode or do anything with it,
without the filter.
Therefore, you should not introduce a new fmt for this.

 MFCv6 and newer don't even understand nv12mt and can output standard
 nv12:
 http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35

This is yet another good reason to NOT introduce a new weird pix-fmt
that will stay in FFmpeg for the next 10 years.

 I've been using it to convert yuv output of an usb cam to nv12 fed to
 the mfc hw enc so that I can stream H263 while leaving the cpu
 free for other things.

Then keep the weird format internal.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]Read aspect ratio from mxf

2014-11-21 Thread Tomas Härdin

On Sun, 2014-11-16 at 02:03 +0100, Carl Eugen Hoyos wrote:
 On Saturday 15 November 2014 11:57:00 pm Michael Niedermayer wrote:
  On Sat, Nov 15, 2014 at 02:50:38AM +0100, Carl Eugen Hoyos wrote:
   Hi!
  
   Attached patch fixes ticket #4107 for me.
   An alternative would be to force the sar to 4:3
   if h264 10bit 1440x1080 video has sar 3:4.
 
   +av_dict_set(st-metadata, display_aspect_ratio_num,
   NULL, 0); +av_dict_set(st-metadata,
   display_aspect_ratio_den, NULL, 0); +}
 
  I suggest you add a documented as private/internal
  display_aspect_ratio to AVStream instead of metadata
  also av_reduce can be replaced by av_mul_q which is probably simpler
 
 New patch attached.
 
 Thank you, Carl Eugen

Looks good to me. I recall doing something similar way back that I never
sent to this list, in order to deal with similar issues.

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 10:02:36 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

 On 21 Nov, Alexis Ballier wrote :
How do you put this in an AVFrame then ?
   
   Preferably not at all. Is there a need to? Only the end result
   (nv12 I suppose) needs to be in an AVFrame.
  
  It can be done but is ugly IMHO:
  
  - I was under the impression that lavc decoder convention was to
output non processed formats and let the application handle (or
  not) the conversions
 
 Sure, but this is when you can actually process them in applications,
 like planar audio. No a hardware-specific format that noone can play
 except with a special library.

I think it's safe to assume that if you have a SOC with a HW dec that
outputs only this insane and uncommon format, the SOC also has a HW
filter that can convert it. I've not played with it, but you can also
have a look at s5p-tv driver that is a V4L2 outdev which accepts
NV12MT. So you can even play it.

   So this is a
   decoder. Why can't the decoder take care of this conversion too?
  
  See above.
 
 Sorry, but that's far from clear.

What is not ? The important part was the one you cut :)

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

Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: export source package uids and names as metadata

2014-11-21 Thread Tomas Härdin

On Tue, 2014-11-18 at 16:52 -0800, Mark Reid wrote:
 ---
  libavformat/mxfdec.c | 74 
 +++-
  1 file changed, 39 insertions(+), 35 deletions(-)
 
 diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
 index fa0a2f4..8c13c24 100644
 --- a/libavformat/mxfdec.c
 +++ b/libavformat/mxfdec.c

  static int mxf_timestamp_to_str(uint64_t timestamp, char **str)
  {
  struct tm time = { 0 };
 @@ -1969,7 +1973,7 @@ static const MXFMetadataReadTableEntry 
 mxf_metadata_read_table[] = {
  { { 
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x30,0x00
  }, mxf_read_identification_metadata },
  { { 
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x18,0x00
  }, mxf_read_content_storage, 0, AnyType },
  { { 
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x37,0x00
  }, mxf_read_source_package, sizeof(MXFPackage), SourcePackage },
 -{ { 
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x36,0x00
  }, mxf_read_material_package, sizeof(MXFPackage), MaterialPackage },
 +{ { 
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x36,0x00
  }, mxf_read_source_package, sizeof(MXFPackage), MaterialPackage },

Maybe rename mxf_read_source_package to mxf_read_package?
Noticing that both functions are quite similar is a good catch :)
The rest of the patch looks fine.

/Tomas


signature.asc
Description: This is a digitally signed message part
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
 I think it's safe to assume that if you have a SOC with a HW dec that
 outputs only this insane and uncommon format, the SOC also has a HW
 filter that can convert it.

Then use this filter to output a standard format.

  Sorry, but that's far from clear.
 
 What is not ? The important part was the one you cut :)

Introducing yet another PIX_FMT that has almost no meaning in the
outside world, that is very linked to a specific hardware and that
will be needed to be supported for the next 10 years is a very bad idea.

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

Hi,

- Mail original -

[...]

 I think it's safe to assume that if you have a SOC with a HW dec that
 outputs only this insane and uncommon format, the SOC also has a HW
 filter that can convert it.

This is a good argument IMHO.
On a side note, I don't think it would be that complicated to support both, 
through an option.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 10:15:29 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

 On 21 Nov, Alexis Ballier wrote :
   So you have a format outputted that is of no use, except if you
   use the filter.
  
  On MFCv5 yes; I don't assume because I'm working on this that it is
  the only one :)
 
 So, basically, noone can display it, reencode or do anything with it,
 without the filter.
 Therefore, you should not introduce a new fmt for this.

First, I fail to see how this differs from AV_PIX_FMT_VDPAU  friends.
Second, I don't understand all the drama of using _one_ member of an
enum to avoid cluttering the code.

Let me re-explain my other mail:

Current decoding code is:
  * open the decoder
  * feed it with some data
  * get the output format the decoder uses
  * advertise it in codec context
  * decoding loop is: get an avpacket, feed to decoder, obtain an avframe

Keeping it internal would mean, for the sole decoder:
  * open the decoder
  * feed it with some data
  * get the output format
  * if i dont like the format then:
* probe and open another random device that may or may not
  exist for format conversion
* look for an output format i like
  * advertise the output format i will give to codec context
  * decoding loop is:
* get an avpacket, feed it to decoder, obtain an avframe
* if conversion is needed:
  * feed frame to filter, obtain the converted frame

Now, if I want to use the fimc device to apply some effects I can't
because the decoder is magically using it behind my back.

If I want to use s5p-tv to display the decoded video over HDMI, then I
have post-processed the frame with fimc for nothing since NV12MT is
accepted.

  MFCv6 and newer don't even understand nv12mt and can output standard
  nv12:
  http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35
 
 This is yet another good reason to NOT introduce a new weird pix-fmt
 that will stay in FFmpeg for the next 10 years.

It will be in kernel headers and kernel ABI for like forever, so I
don't understand why this is so much of a problem.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 10:38:37 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

 On 21 Nov, Alexis Ballier wrote :
  I think it's safe to assume that if you have a SOC with a HW dec
  that outputs only this insane and uncommon format, the SOC also has
  a HW filter that can convert it.
 
 Then use this filter to output a standard format.

I think you should read again the part you cut and reply there, or my
other reply in the thread. I explained why I don't like this.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
On Fri, 21 Nov 2014 10:15:29 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

On 21 Nov, Alexis Ballier wrote :
So you have a format outputted that is of no use, except if you
use the filter.

On MFCv5 yes; I don't assume because I'm working on this that it is
the only one :)

So, basically, noone can display it, reencode or do anything with it,
without the filter.
Therefore, you should not introduce a new fmt for this.

First, I fail to see how this differs from AV_PIX_FMT_VDPAU friends.

Because it's called NV12T, not AV_PIX_FMT_V4L_FMT. And because it's not
and HWAccel.

Second, I don't understand all the drama of using _one_ member of an
enum to avoid cluttering the code.

Because you don't use libav* libraries directly.

Let me re-explain my other mail:

Current decoding code is:
* open the decoder
* feed it with some data
* get the output format the decoder uses
* advertise it in codec context
* decoding loop is: get an avpacket, feed to decoder, obtain an avframe

Keeping it internal would mean, for the sole decoder:
* open the decoder
* feed it with some data
* get the output format
* if i dont like the format then:
* probe and open another random device that may or may not
exist for format conversion
* look for an output format i like
* advertise the output format i will give to codec context
* decoding loop is:
* get an avpacket, feed it to decoder, obtain an avframe
* if conversion is needed:
* feed frame to filter, obtain the converted frame

So what?
Your 2 cases are completly unfair, and you don't give the same level of details.

Now, if I want to use the fimc device to apply some effects I can't
because the decoder is magically using it behind my back.

How is that relevant? Just block it.
And it seems really like a technical limitation of this chip.

If I want to use s5p-tv to display the decoded video over HDMI, then I
have post-processed the frame with fimc for nothing since NV12MT is
accepted.

Then maybe, in those cases, FFmpeg is not the right tool, and you should
do a HWAccel.

MFCv6 and newer don't even understand nv12mt and can output standard
nv12:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35

This is yet another good reason to NOT introduce a new weird pix-fmt
that will stay in FFmpeg for the next 10 years.

It will be in kernel headers and kernel ABI for like forever, so I
don't understand why this is so much of a problem.

The linux kernel is not the only one around here.

With my kindest regards,

--
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On 21 Nov, Alexis Ballier wrote :
 On Fri, 21 Nov 2014 10:38:37 +0100
 Jean-Baptiste Kempf j...@videolan.org wrote:
 
  On 21 Nov, Alexis Ballier wrote :
   I think it's safe to assume that if you have a SOC with a HW dec
   that outputs only this insane and uncommon format, the SOC also has
   a HW filter that can convert it.
  
  Then use this filter to output a standard format.
 
 I think you should read again the part you cut and reply there, or my
 other reply in the thread. I explained why I don't like this.

I explained also why I don't like it.

Which gives us what?

With my kindest regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

2014-11-21 Thread wm4

On Fri, 21 Nov 2014 10:43:15 +0100
Alexis Ballier aball...@gentoo.org wrote:

On Fri, 21 Nov 2014 10:15:29 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:

On 21 Nov, Alexis Ballier wrote :
So you have a format outputted that is of no use, except if you
use the filter.

On MFCv5 yes; I don't assume because I'm working on this that it is
the only one :)

So, basically, noone can display it, reencode or do anything with it,
without the filter.
Therefore, you should not introduce a new fmt for this.

First, I fail to see how this differs from AV_PIX_FMT_VDPAU friends.

AV_PIX_FMT_VDPAU is marked as hwaccel format, and thus completely opaque.
It can't be cropped, copied, etc. - just passed around. It also means
the generic AVFrame code can't allocate frames of such a format.

Personally I'd have much less of a problem with this if it were to be
marked as opaque.

Second, I don't understand all the drama of using _one_ member of an
enum to avoid cluttering the code.

Every addition is something the API user has to care about, since there
is no automatic conversion between libavcodec and the API user.

Let me re-explain my other mail:

Now, if I want to use the fimc device to apply some effects I can't
because the decoder is magically using it behind my back.

If I want to use s5p-tv to display the decoded video over HDMI, then I
have post-processed the frame with fimc for nothing since NV12MT is
accepted.

It also means that _every_ software which wants to use this new decocer
has to know how to insert the filter etc. - what's the point? If it's
so special, it might as well be outside of libavcodec and libavfilter.

But if it just works without requiring the API user to jump through
hoops, I see at least some value in it.

MFCv6 and newer don't even understand nv12mt and can output standard
nv12:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35

This is yet another good reason to NOT introduce a new weird pix-fmt
that will stay in FFmpeg for the next 10 years.

It will be in kernel headers and kernel ABI for like forever, so I
don't understand why this is so much of a problem.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 10:51:52 +0100
wm4 nfx...@googlemail.com wrote:

 On Fri, 21 Nov 2014 10:43:15 +0100
 Alexis Ballier aball...@gentoo.org wrote:
 
  On Fri, 21 Nov 2014 10:15:29 +0100
  Jean-Baptiste Kempf j...@videolan.org wrote:
  
   On 21 Nov, Alexis Ballier wrote :
 So you have a format outputted that is of no use, except if
 you use the filter.

On MFCv5 yes; I don't assume because I'm working on this that
it is the only one :)
   
   So, basically, noone can display it, reencode or do anything with
   it, without the filter.
   Therefore, you should not introduce a new fmt for this.
  
  First, I fail to see how this differs from AV_PIX_FMT_VDPAU 
  friends.
 
 AV_PIX_FMT_VDPAU is marked as hwaccel format, and thus completely
 opaque. It can't be cropped, copied, etc. - just passed around. It
 also means the generic AVFrame code can't allocate frames of such a
 format.
 
 Personally I'd have much less of a problem with this if it were to be
 marked as opaque.

I didn't know such opaque things existed; it probably makes more
sense with it indeed.

How should I do it ? add .flags = AV_PIX_FMT_FLAG_HWACCEL and be done ?
I would like to keep 'av_pix_fmt_count_planes()' working for it at least

[...]
 It also means that _every_ software which wants to use this new
 decocer has to know how to insert the filter etc. - what's the point?

This could be fixed by adding support in swscale for it, but I see
little to no point to it.

I think you have to specifically ask for v4l2m2m codecs if you want to
use them do hw (de/en)code; so why not do everything in hw and also
setup the filter ?

(note: I shall write some doc about all this once this has settled)

 But if it just works without requiring the API user to jump through
 hoops, I see at least some value in it.


Would AV_PIX_FMT_FLAG_HWACCEL be enough ?

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

2014-11-21 Thread wm4

On Fri, 21 Nov 2014 11:15:08 +0100
Alexis Ballier aball...@gentoo.org wrote:

 On Fri, 21 Nov 2014 10:51:52 +0100
 wm4 nfx...@googlemail.com wrote:
 
  On Fri, 21 Nov 2014 10:43:15 +0100
  Alexis Ballier aball...@gentoo.org wrote:
  
   On Fri, 21 Nov 2014 10:15:29 +0100
   Jean-Baptiste Kempf j...@videolan.org wrote:
   
On 21 Nov, Alexis Ballier wrote :
  So you have a format outputted that is of no use, except if
  you use the filter.
 
 On MFCv5 yes; I don't assume because I'm working on this that
 it is the only one :)

So, basically, noone can display it, reencode or do anything with
it, without the filter.
Therefore, you should not introduce a new fmt for this.
   
   First, I fail to see how this differs from AV_PIX_FMT_VDPAU 
   friends.
  
  AV_PIX_FMT_VDPAU is marked as hwaccel format, and thus completely
  opaque. It can't be cropped, copied, etc. - just passed around. It
  also means the generic AVFrame code can't allocate frames of such a
  format.
  
  Personally I'd have much less of a problem with this if it were to be
  marked as opaque.
 
 I didn't know such opaque things existed; it probably makes more
 sense with it indeed.
 
 How should I do it ? add .flags = AV_PIX_FMT_FLAG_HWACCEL and be done ?
 I would like to keep 'av_pix_fmt_count_planes()' working for it at least

No, this would imply that the pointer to the opaque data is in
AVFrame.data[3], and all other pointers are ignored. So you have only 1
pointer. AVFrame.linesize has no meaning either in this case.

 [...]
  It also means that _every_ software which wants to use this new
  decocer has to know how to insert the filter etc. - what's the point?
 
 This could be fixed by adding support in swscale for it, but I see
 little to no point to it.
 
 I think you have to specifically ask for v4l2m2m codecs if you want to
 use them do hw (de/en)code; so why not do everything in hw and also
 setup the filter ?

Well, if the filter copies to system RAM anyway (if that chip
distinguishes between GPU and system RAM at all), then why do you need
such a filter as user-visible thing at all?

Where exactly is the problem in putting this code into libavcodec?

 (note: I shall write some doc about all this once this has settled)
 
  But if it just works without requiring the API user to jump through
  hoops, I see at least some value in it.
 
 
 Would AV_PIX_FMT_FLAG_HWACCEL be enough ?

I can't speak for others whether this approach is acceptable.

But I think this is all too messy, and the decoder should just output a
useful format.

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 10:50:42 +0100
Jean-Baptiste Kempf j...@videolan.org wrote:
Now, if I want to use the fimc device to apply some effects I can't
because the decoder is magically using it behind my back.

How is that relevant? Just block it.

Block what ? automatic conversion ? what fmt should i advertise if
NV12T is the only supported output ?

If I want to use s5p-tv to display the decoded video over HDMI,
then I have post-processed the frame with fimc for nothing since
NV12MT is accepted.

Then maybe, in those cases, FFmpeg is not the right tool, and you
should do a HWAccel.

Besides that this belongs more to the lavd outdev, you may or may not
have the tv driver loaded working. And this would be very specific to
socs with m2m codecs, m2m filters and v4l2 outdev, while the current
code tries to keep everything well separated: one device per context
so that it can work with various setups. This is probably increasing
work at application level though, but HWAccel always requires
application specific support afaik.

MFCv6 and newer don't even understand nv12mt and can output
standard nv12:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#n35

This is yet another good reason to NOT introduce a new weird
pix-fmt that will stay in FFmpeg for the next 10 years.

It will be in kernel headers and kernel ABI for like forever, so I
don't understand why this is so much of a problem.

The linux kernel is not the only one around here.

you'll never get to see this format in an application outside of the
linux kernel, and probably never outside of samsung socs :)

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

Re: [FFmpeg-devel] [PATCH 3/6] Add AV_PIX_FMT_NV12T.

On Fri, 21 Nov 2014 11:23:49 +0100
wm4 nfx...@googlemail.com wrote:
  I didn't know such opaque things existed; it probably makes more
  sense with it indeed.
  
  How should I do it ? add .flags = AV_PIX_FMT_FLAG_HWACCEL and be
  done ? I would like to keep 'av_pix_fmt_count_planes()' working for
  it at least
 
 No, this would imply that the pointer to the opaque data is in
 AVFrame.data[3], and all other pointers are ignored. So you have only
 1 pointer. AVFrame.linesize has no meaning either in this case.
 
  [...]
   It also means that _every_ software which wants to use this new
   decocer has to know how to insert the filter etc. - what's the
   point?
  
  This could be fixed by adding support in swscale for it, but I see
  little to no point to it.
  
  I think you have to specifically ask for v4l2m2m codecs if you want
  to use them do hw (de/en)code; so why not do everything in hw and
  also setup the filter ?
 
 Well, if the filter copies to system RAM anyway (if that chip
 distinguishes between GPU and system RAM at all),

Speaking only for that chip (this will likely differ for others), there
is no such thing as gpu ram, but there is cma allocated  reserved
memory in system ram.
Default settings ask the driver to mmap this memory and use this as a
buffer; this indeed introduces some copies to feed the filter or codec
with data: if we get random input buffers, we have to memcpy() them
at the mmap adress given by the driver. mfc codec refuses to handle
anything but mmaped io.
You can feed the filter with userptr memory (basically a userspace
pointer that the driver will translate himself) but this memory must be
_physically_ contiguous, which I don't think we have any way to ensure
at userspace level.
The solution is to take the data from the decoder, feed the frame with
zero copy (thanks to refcounted frames) to the filter: Since the
buffers come from the decoder who has mmaped them in its cma-allocated
memory it is guaranteed to be physically contiguous.

 then why do you need
 such a filter as user-visible thing at all?
 Where exactly is the problem in putting this code into libavcodec?

There is a limited # of hw filters; you may also want to scale the
video to fit your display, which the filter can do together with the
fmt conversion in one pass. I don't think up/down scaling the
decoded video should be done in lavc.

  (note: I shall write some doc about all this once this has settled)
  
   But if it just works without requiring the API user to jump
   through hoops, I see at least some value in it.
  
  
  Would AV_PIX_FMT_FLAG_HWACCEL be enough ?
 
 I can't speak for others whether this approach is acceptable.

I don't understand:

 No, this would imply that the pointer to the opaque data is in
 AVFrame.data[3], and all other pointers are ignored. So you have only
 1 pointer. AVFrame.linesize has no meaning either in this case.

this won't work with NV12(T) since the format has 2 planes
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.

---
Changes:
 - do not reset decode_next_dat when decoding IDAT of fdAT
 - add configure part
---
 configure   |   1 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   8 +++
 libavcodec/pngdec.c | 139 ++--
 6 files changed, 148 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index c013c50..b3c3e5b 100755
--- a/configure
+++ b/configure
@@ -2068,6 +2068,7 @@ amrwb_decoder_select=lsp
 amv_decoder_select=sp5x_decoder exif
 amv_encoder_select=aandcttables mpegvideoenc
 ape_decoder_select=bswapdsp llauddsp
+apng_decoder_select=zlib
 asv1_decoder_select=blockdsp bswapdsp idctdsp
 asv1_encoder_select=bswapdsp fdctdsp pixblockdsp
 asv2_decoder_select=blockdsp bswapdsp idctdsp
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6c625ce..fa0f53d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -136,6 +136,7 @@ OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o 
mjpeg.o mjpegenc_common.o \
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
+OBJS-$(CONFIG_APNG_DECODER)+= png.o pngdec.o pngdsp.o
 OBJS-$(CONFIG_SSA_DECODER) += assdec.o ass.o ass_split.o
 OBJS-$(CONFIG_SSA_ENCODER) += assenc.o ass.o
 OBJS-$(CONFIG_ASS_DECODER) += assdec.o ass.o ass_split.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index d08abd8..0d39d33 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -105,6 +105,7 @@ void avcodec_register_all(void)
 REGISTER_ENCDEC (AMV,   amv);
 REGISTER_DECODER(ANM,   anm);
 REGISTER_DECODER(ANSI,  ansi);
+REGISTER_DECODER(APNG,  apng);
 REGISTER_ENCDEC (ASV1,  asv1);
 REGISTER_ENCDEC (ASV2,  asv2);
 REGISTER_DECODER(AURA,  aura);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index eac3fc7..3323284 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -319,6 +319,7 @@ enum AVCodecID {
 AV_CODEC_ID_HEVC   = MKBETAG('H','2','6','5'),
 #define AV_CODEC_ID_H265 AV_CODEC_ID_HEVC
 AV_CODEC_ID_VP7= MKBETAG('V','P','7','0'),
+AV_CODEC_ID_APNG   = MKBETAG('A','P','N','G'),
 
 /* various PCM codecs */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, /// A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index eeb4505..0af66f4 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1440,6 +1440,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 .mime_types= MT(image/x-xwindowdump),
 },
+{
+.id= AV_CODEC_ID_APNG,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = apng,
+.long_name = NULL_IF_CONFIG_SMALL(APNG (Animated Portable Network 
Graphics) image),
+.props = AV_CODEC_PROP_LOSSLESS,
+.mime_types= MT(image/png),
+},
 
 /* various PCM codecs */
 {
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 57b73c1..ee6a2ba 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -786,15 +786,55 @@ static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
 }
 }
 
+static int decode_fctl_chunk(AVCodecContext *avctx, PNGDecContext *s,
+ uint32_t length)
+{
+uint32_t sequence_number, width, height, x_offset, y_offset;
+
+if (length != 26)
+return AVERROR_INVALIDDATA;
+
+sequence_number = bytestream2_get_be32(s-gb);
+width   = bytestream2_get_be32(s-gb);
+height  = bytestream2_get_be32(s-gb);
+x_offset= bytestream2_get_be32(s-gb);
+y_offset= bytestream2_get_be32(s-gb);
+bytestream2_skip(s-gb, 10); /* delay_num  (2)
+   * delay_den  (2)
+   * dispose_op (1)
+   * blend_op   (1)
+   * crc(4)
+   */
+
+if (width != s-width || height != s-height ||
+x_offset != 0 || y_offset != 0) {
+if (sequence_number == 0)
+return AVERROR_INVALIDDATA;
+avpriv_request_sample(avctx, non key frames);
+return AVERROR_PATCHWELCOME;
+}
+
+return 0;
+}
+
 static int decode_frame_common(AVCodecContext *avctx, PNGDecContext *s,
AVFrame *p, AVPacket *avpkt)
 {
 AVDictionary *metadata  = NULL;
 uint32_t tag, length;
+int decode_next_dat = 0;
+int ret = AVERROR_INVALIDDATA;
 
 for (;;) {
-if (bytestream2_get_bytes_left(s-gb) = 0) {
-av_log(avctx, AV_LOG_ERROR, %d bytes left\n,

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.

2014-11-21 Thread compn

On Fri, 21 Nov 2014 12:05:47 +0100
Benoit Fouet benoit.fo...@free.fr wrote:

  configure   |   1 +
  libavcodec/Makefile |   1 +
  libavcodec/allcodecs.c  |   1 +
  libavcodec/avcodec.h|   1 +
  libavcodec/codec_desc.c |   8 +++
  libavcodec/pngdec.c | 139

missing addition of apng to docs.

should there be a dependency on the apng demuxer or no?

quick review looks ok to me.

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

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.

On Fri, Nov 21, 2014 at 08:09:50AM -0500, compn wrote:
 On Fri, 21 Nov 2014 12:05:47 +0100
 Benoit Fouet benoit.fo...@free.fr wrote:
 
   configure   |   1 +
   libavcodec/Makefile |   1 +
   libavcodec/allcodecs.c  |   1 +
   libavcodec/avcodec.h|   1 +
   libavcodec/codec_desc.c |   8 +++
   libavcodec/pngdec.c | 139
 
 missing addition of apng to docs.

maybe this should be done when apng support is more complete
ATM from
https://people.mozilla.org/~dolske/apng/demo.html
not all files play yet and not all play correctly

Either way this is very nice work, ill apply it in a moment
should be easier to improve and review on top of this

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avformat/apngdec: add APNG demuxer.

On Thu, Nov 20, 2014 at 03:07:18PM +0100, Benoit Fouet wrote:
 ---
  libavformat/Makefile |   1 +
  libavformat/allformats.c |   1 +
  libavformat/apngdec.c| 409 
 +++
  3 files changed, 411 insertions(+)
  create mode 100644 libavformat/apngdec.c

patch applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.

On Fri, Nov 21, 2014 at 12:05:47PM +0100, Benoit Fouet wrote:
 ---
 Changes:
  - do not reset decode_next_dat when decoding IDAT of fdAT
  - add configure part
 ---
  configure   |   1 +
  libavcodec/Makefile |   1 +
  libavcodec/allcodecs.c  |   1 +
  libavcodec/avcodec.h|   1 +
  libavcodec/codec_desc.c |   8 +++
  libavcodec/pngdec.c | 139 
 ++--
  6 files changed, 148 insertions(+), 3 deletions(-)

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] bprint.h can't be included in C++ code

2014-11-21 Thread Vadim Kalinsky

C++ does not support anonymous struct.



0001-C-compatible-AVBPrint-definition.patch
Description: Binary data


Vadim Kalinsky
kalinsky.ru













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

[FFmpeg-devel] FFmpeg 2.5 release

Hi all

Its over 2 month since FFmpeg 2.4, so the next release is not far
away ...

If you want something in it or want something fixed dont wait too
long, though i dont plan to release it in the next week ...

Also if you want it to have a specific name, say so now, otherwise
ill pick something from the past suggestions

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavf/apngdec: properly skip currently unsupported in-stream tags

2014-11-21 Thread James Almer

Signed-off-by: James Almer jamr...@gmail.com
---
 libavformat/apngdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 54fbd29..2af87ad 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -373,6 +373,7 @@ static int apng_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 return 0;
 default:
 avpriv_request_sample(s, In-stream tag=%#08X len=%PRId64, tag, 
avio_tell(pb));
+avio_skip(pb, len + 4);
 }
 
 /* Handle the unsupported yet cases */
-- 
2.1.3

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

[FFmpeg-devel] [PATCH 2/2] lavf/apngdec: print currently unsupported in-stream tags in a readable form

2014-11-21 Thread James Almer

Also use length and not stream position

Signed-off-by: James Almer jamr...@gmail.com
---
 libavformat/apngdec.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavformat/apngdec.c b/libavformat/apngdec.c
index 2af87ad..ce62190 100644
--- a/libavformat/apngdec.c
+++ b/libavformat/apngdec.c
@@ -372,8 +372,13 @@ static int apng_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 return ret;
 return 0;
 default:
-avpriv_request_sample(s, In-stream tag=%#08X len=%PRId64, tag, 
avio_tell(pb));
+{
+char tag_buf[5];
+
+av_get_codec_tag_string(tag_buf, sizeof(tag_buf), tag);
+avpriv_request_sample(s, In-stream tag=%s len=%PRIu32, tag_buf, len);
 avio_skip(pb, len + 4);
+}
 }
 
 /* Handle the unsupported yet cases */
-- 
2.1.3

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

Re: [FFmpeg-devel] [PATCH 03/11] ffserver_config: map ffserver options to AVOptions

2014-11-21 Thread Reynaldo H. Verdejo Pinochet

Hi

On 11/20/2014 10:14 PM, Lukasz Marek wrote:
 On 18.11.2014 21:35, Reynaldo H. Verdejo Pinochet wrote:
 [...]
 Also, please make an effort
 to break lines at 80 chars as long as it doesn't make the
 code harder to read. This seems particularly possible on the
 function declarations.
 
 regarding this part, I set my editor to notice 90 chars and I try to
 respect that, but with some reasonable margin. TBH, 80 chars is
 prehistoric, probably from the era of crt's with text mode.
 I don't remember official ffmpeg's rules about that, but common, its
 21th century...

https://www.ffmpeg.org/developer.html#toc-Code-formatting-conventions

Please try to when possible. It's not a requirement but a sane
suggestion many avid by.

Bests,

-- 
Reynaldo H. Verdejo Pinochet
Open Source Group
Samsung Research America / Silicon Valley
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 03/11] ffserver_config: map ffserver options to AVOptions

2014-11-21 Thread Reynaldo H. Verdejo Pinochet



On 11/21/2014 07:17 PM, Reynaldo H. Verdejo Pinochet wrote:
 [..]
 suggestion many avid by.

s/avid by/follow/g
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 08/11] ffserver: export recommented encoder configuration


On 18.11.2014 22:50, Reynaldo H. Verdejo Pinochet wrote:

Hi

On 11/16/2014 10:46 PM, Lukasz Marek wrote:

[..]
@@ -3355,6 +3354,9 @@ static int add_av_stream(FFServerStream *feed, AVStream 
*st)
  fst = add_av_stream1(feed, av, 0);
  if (!fst)
  return -1;
+if (av_stream_get_recommended_encoder_configuration(st))
+av_stream_set_recommended_encoder_configuration(fst,
+av_strdup(av_stream_get_recommended_encoder_configuration(st)));


Is the return of av_strdup here been freed somewhere?. Also
adding braces to ifs when the body is multilined wouldn't
hurt. Not a blocker of course.

Looks OK otherwise. Feel free to push after confirming ^


Updated patch, av_dict_serialize - av_dict_get_string

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

Re: [FFmpeg-devel] [PATCH 05/11] ffserver: allow skip setting defaults


On 21.11.2014 16:31, Reynaldo H. Verdejo Pinochet wrote:

Hi

On 11/20/2014 10:09 PM, Lukasz Marek wrote:

On 18.11.2014 23:25, Reynaldo H. Verdejo Pinochet wrote:

[..]
I do think undefined behavior should be avoided if possible
without too much hassle, so if we go with the former I would
appreciate doc entries specifying the options precedence. Brownie
points+ if an odd combination fires a warning().


Not sure I follow, should I change anything? IMHO my proposal it is not
really complex and fully customizable.


After Nicolas observation I think it's OK for you to keep
the original implementation. Just see if you can document
the options' precedence when an XYES and XNO are present in
the config file and consider adding a warning in such case.

Thanks a lot!

Bests,


updated patch
From 03619921125bf66562d6487e8b5ea64dfa2ac27b Mon Sep 17 00:00:00 2001
From: Lukasz Marek lukasz.m.lu...@gmail.com
Date: Sat, 15 Nov 2014 18:43:41 +0100
Subject: [PATCH 5/9] ffserver: allow skip setting defaults

Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
 doc/ffserver.texi | 11 +++
 ffserver.c|  1 +
 ffserver_config.c | 35 +++
 ffserver_config.h |  2 ++
 4 files changed, 49 insertions(+)

diff --git a/doc/ffserver.texi b/doc/ffserver.texi
index b7c5b6a..83b6520 100644
--- a/doc/ffserver.texi
+++ b/doc/ffserver.texi
@@ -408,6 +408,12 @@ ignored, and the log is written to standard output.
 Set no-daemon mode. This option is currently ignored since now
 @command{ffserver} will always work in no-daemon mode, and is
 deprecated.
+
+@item UseDefaults
+@item NoDefaults
+Control whether default codec options are used for the all streams or not.
+Each stream may overwrite this setting for its own. Default is @var{UseDefaults}.
+The lastest occurrence overrides previous if multiple definitions.
 @end table
 
 @section Feed section
@@ -571,6 +577,11 @@ deprecated in favor of @option{Metadata}.
 @item Metadata @var{key} @var{value}
 Set metadata value on the output stream.
 
+@item UseDefaults
+@item NoDefaults
+Control whether default codec options are used for the stream or not.
+Default is @var{UseDefaults} unless disabled globally.
+
 @item NoAudio
 @item NoVideo
 Suppress audio/video.
diff --git a/ffserver.c b/ffserver.c
index 933eb0e..e24243d 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -201,6 +201,7 @@ static FFServerConfig config = {
 .nb_max_http_connections = 2000,
 .nb_max_connections = 5,
 .max_bandwidth = 1000,
+.use_defaults = 1,
 };
 
 static void new_connection(int server_fd, int is_rtsp);
diff --git a/ffserver_config.c b/ffserver_config.c
index 73cd881..8339638 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -191,6 +191,8 @@ static void add_codec(FFServerStream *stream, AVCodecContext *av,
 av_log(NULL, AV_LOG_WARNING,
Something is wrong, %d options are not set!\n, av_dict_count(*opts));
 
+if (config-stream_use_defaults) {
+//TODO: reident
 /* compute default parameters */
 switch(av-codec_type) {
 case AVMEDIA_TYPE_AUDIO:
@@ -255,6 +257,25 @@ static void add_codec(FFServerStream *stream, AVCodecContext *av,
 default:
 abort();
 }
+} else {
+switch(av-codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+if (av-bit_rate == 0)
+report_config_error(config-filename, config-line_num, AV_LOG_ERROR,
+config-errors, audio bit rate is not set\n);
+if (av-sample_rate == 0)
+report_config_error(config-filename, config-line_num, AV_LOG_ERROR,
+config-errors, audio sample rate is not set\n);
+break;
+case AVMEDIA_TYPE_VIDEO:
+if (av-width == 0 || av-height == 0)
+report_config_error(config-filename, config-line_num, AV_LOG_ERROR,
+config-errors, video size is not set\n);
+break;
+default:
+av_assert0(0);
+}
+}
 
 st = av_mallocz(sizeof(AVStream));
 if (!st)
@@ -583,6 +604,10 @@ static int ffserver_parse_config_global(FFServerConfig *config, const char *cmd,
 ffserver_get_arg(config-logfilename, sizeof(config-logfilename), p);
 } else if (!av_strcasecmp(cmd, LoadModule)) {
 ERROR(Loadable modules are no longer supported\n);
+} else if (!av_strcasecmp(cmd, NoDefaults)) {
+config-use_defaults = 0;
+} else if (!av_strcasecmp(cmd, UseDefaults)) {
+config-use_defaults = 1;
 } else
 ERROR(Incorrect keyword: '%s'\n, cmd);
 return 0;
@@ -738,6 +763,7 @@ static int ffserver_parse_config_stream(FFServerConfig *config, const char *cmd,
 config-guessed_audio_codec_id = AV_CODEC_ID_NONE;
 config-guessed_video_codec_id = AV_CODEC_ID_NONE;
 }
+config-stream_use_defaults = config-use_defaults;
 *pstream = stream;

Re: [FFmpeg-devel] [PATCH 04/11] ffserver_config: remove ffserver_apply_stream_config function


On 18.11.2014 21:44, Reynaldo H. Verdejo Pinochet wrote:

Hi Lukasz

On 11/16/2014 10:46 PM, Lukasz Marek wrote:

[..]
@@ -174,13 +174,20 @@ void ffserver_parse_acl_row(FFServerStream *stream, 
FFServerStream* feed,
  }

  /* add a codec and set the default parameters */
-static void add_codec(FFServerStream *stream, AVCodecContext *av)
+static void add_codec(FFServerStream *stream, AVCodecContext *av, 
FFServerConfig *config)
  {
  AVStream *st;
+AVDictionary **opts;

  if(stream-nb_streams = FF_ARRAY_ELEMS(stream-streams))
  return;

+opts = av-codec_type == AVMEDIA_TYPE_AUDIO ? config-audio_opts : 
config-video_opts;
+av_opt_set_dict2(av-priv_data, opts, AV_OPT_SEARCH_CHILDREN);
+av_opt_set_dict2(av, opts, AV_OPT_SEARCH_CHILDREN);
+if (av_dict_count(*opts))
+av_log(NULL, AV_LOG_ERROR, Something went wrong, %d options not 
set!!!\n, av_dict_count(*opts));
+


Is this really an error? OK to push if so. Otherwise demote to
warning and push the updated patch. Usual comments about your
line lengths apply too but are not blockers.

As a general comment, I would avoid the grammatical !!!s and
such to denote severity. We have the log categories for that.
This is also just a tip, not something you need to change.

Bests,


updated patch
From 59ccba52f3d90f992ecd65be585d0b75294ba263 Mon Sep 17 00:00:00 2001
From: Lukasz Marek lukasz.m.lu...@gmail.com
Date: Sun, 16 Nov 2014 01:33:19 +0100
Subject: [PATCH 4/9] ffserver_config: remove ffserver_apply_stream_config
 function

This function became very short and can be logically merged with add_codec().

Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
 ffserver_config.c | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/ffserver_config.c b/ffserver_config.c
index 67c4890..73cd881 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -174,13 +174,23 @@ void ffserver_parse_acl_row(FFServerStream *stream, FFServerStream* feed,
 }
 
 /* add a codec and set the default parameters */
-static void add_codec(FFServerStream *stream, AVCodecContext *av)
+static void add_codec(FFServerStream *stream, AVCodecContext *av,
+  FFServerConfig *config)
 {
 AVStream *st;
+AVDictionary **opts;
 
 if(stream-nb_streams = FF_ARRAY_ELEMS(stream-streams))
 return;
 
+opts = av-codec_type == AVMEDIA_TYPE_AUDIO ?
+   config-audio_opts : config-video_opts;
+av_opt_set_dict2(av-priv_data, opts, AV_OPT_SEARCH_CHILDREN);
+av_opt_set_dict2(av, opts, AV_OPT_SEARCH_CHILDREN);
+if (av_dict_count(*opts))
+av_log(NULL, AV_LOG_WARNING,
+   Something is wrong, %d options are not set!\n, av_dict_count(*opts));
+
 /* compute default parameters */
 switch(av-codec_type) {
 case AVMEDIA_TYPE_AUDIO:
@@ -684,14 +694,6 @@ static int ffserver_parse_config_feed(FFServerConfig *config, const char *cmd, c
 return 0;
 }
 
-static void ffserver_apply_stream_config(AVCodecContext *enc, AVDictionary **opts)
-{
-av_opt_set_dict2(enc-priv_data, opts, AV_OPT_SEARCH_CHILDREN);
-av_opt_set_dict2(enc, opts, AV_OPT_SEARCH_CHILDREN);
-if (av_dict_count(*opts))
-av_log(NULL, AV_LOG_ERROR, Something went wrong, %d options not set!!!\n, av_dict_count(*opts));
-}
-
 static int ffserver_parse_config_stream(FFServerConfig *config, const char *cmd, const char **p,
 FFServerStream **pstream)
 {
@@ -1013,15 +1015,13 @@ static int ffserver_parse_config_stream(FFServerConfig *config, const char *cmd,
 config-dummy_actx-codec_id = config-guessed_audio_codec_id;
 if (!config-no_audio  config-dummy_actx-codec_id != AV_CODEC_ID_NONE) {
 AVCodecContext *audio_enc = avcodec_alloc_context3(avcodec_find_encoder(config-dummy_actx-codec_id));
-ffserver_apply_stream_config(audio_enc, config-audio_opts);
-add_codec(stream, audio_enc);
+add_codec(stream, audio_enc, config);
 }
 if (config-dummy_vctx-codec_id == AV_CODEC_ID_NONE)
 config-dummy_vctx-codec_id = config-guessed_video_codec_id;
 if (!config-no_video  config-dummy_vctx-codec_id != AV_CODEC_ID_NONE) {
 AVCodecContext *video_enc = avcodec_alloc_context3(avcodec_find_encoder(config-dummy_vctx-codec_id));
-ffserver_apply_stream_config(video_enc, config-video_opts);
-add_codec(stream, video_enc);
+add_codec(stream, video_enc, config);
 }
 }
 av_dict_free(config-video_opts);
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH 10/11] lavf/ffmenc: store recommended encoder configuration


On 17.11.2014 02:46, Lukasz Marek wrote:

ffmenc will store recommended encoder configuration if present.
This will allow the user to base on local defaults and
apply only explicitly set options.

If recommended encoder configuration is not present, then
non-default context's options are stored.

Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
  libavformat/ffmenc.c | 74 +---
  1 file changed, 70 insertions(+), 4 deletions(-)

diff --git a/libavformat/ffmenc.c b/libavformat/ffmenc.c
index b717813..2f3f90d 100644
--- a/libavformat/ffmenc.c
+++ b/libavformat/ffmenc.c
@@ -162,6 +162,60 @@ static int ffm_write_header_codec_ctx(AVIOContext *pb, 
AVCodecContext *ctx, unsi
  #undef ENC
  }



Updated patch, av_dict_serialize - av_dict_get string

From dd19271a6724b31fe1da3a32db5d355832c0ad07 Mon Sep 17 00:00:00 2001
From: Lukasz Marek lukasz.m.lu...@gmail.com
Date: Sun, 16 Nov 2014 21:55:14 +0100
Subject: [PATCH 8/9] lavf/ffmenc: store recommended encoder configuration

ffmenc will store recommended encoder configuration if present.
This will allow the user to base on local defaults and
apply only explicitly set options.

If recommended encoder configuration is not present, then
non-default context's options are stored.

Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
 libavformat/ffmenc.c | 74 +---
 1 file changed, 70 insertions(+), 4 deletions(-)

diff --git a/libavformat/ffmenc.c b/libavformat/ffmenc.c
index c64c26b..e6d1a31 100644
--- a/libavformat/ffmenc.c
+++ b/libavformat/ffmenc.c
@@ -162,6 +162,60 @@ static int ffm_write_header_codec_ctx(AVIOContext *pb, AVCodecContext *ctx, unsi
 #undef ENC
 }
 
+static int ffm_write_recommended_config(AVIOContext *pb, AVCodecContext *ctx, unsigned tag,
+const char *configuration)
+{
+int ret;
+const AVCodec *enc = ctx-codec ? ctx-codec : avcodec_find_encoder(ctx-codec_id);
+AVIOContext *tmp;
+AVDictionaryEntry *t = NULL;
+AVDictionary *all = NULL, *comm = NULL, *prv = NULL;
+char *buf = NULL;
+
+if (!enc || !enc-priv_class || !enc-priv_data_size) {
+/* codec is not known/has no private options, so save everything as common options */
+if (avio_open_dyn_buf(tmp)  0)
+return AVERROR(ENOMEM);
+avio_put_str(tmp, configuration);
+write_header_chunk(pb, tmp, tag);
+return 0;
+}
+
+if ((ret = av_dict_parse_string(all, configuration, =, ,, 0))  0)
+return ret;
+
+while ((t = av_dict_get(all, , t, AV_DICT_IGNORE_SUFFIX))) {
+if (av_opt_find((void *)enc-priv_class, t-key, NULL, 0, AV_OPT_SEARCH_FAKE_OBJ)) {
+if ((ret = av_dict_set(prv, t-key, t-value, 0))  0)
+goto fail;
+} else if ((ret = av_dict_set(comm, t-key, t-value, 0))  0)
+goto fail;
+}
+
+if (comm) {
+if ((ret = av_dict_get_string(comm, buf, '=', ','))  0 ||
+(ret = avio_open_dyn_buf(tmp))  0)
+goto fail;
+avio_put_str(tmp, buf);
+av_freep(buf);
+write_header_chunk(pb, tmp, tag);
+}
+if (prv) {
+if ((ret = av_dict_get_string(prv, buf, '=', ','))  0 ||
+(ret = avio_open_dyn_buf(tmp))  0)
+goto fail;
+avio_put_str(tmp, buf);
+write_header_chunk(pb, tmp, MKBETAG('C', 'P', 'R', 'V'));
+}
+
+  fail:
+av_free(buf);
+av_dict_free(all);
+av_dict_free(comm);
+av_dict_free(prv);
+return ret;
+}
+
 static int ffm_write_header(AVFormatContext *s)
 {
 FFMContext *ffm = s-priv_data;
@@ -220,13 +274,25 @@ static int ffm_write_header(AVFormatContext *s)
 /* specific info */
 switch(codec-codec_type) {
 case AVMEDIA_TYPE_VIDEO:
-if ((ret = ffm_write_header_codec_ctx(s-pb, codec, MKBETAG('S', '2', 'V', 'I'), AV_OPT_FLAG_VIDEO_PARAM))  0 ||
-(ret = ffm_write_header_codec_private_ctx(s-pb, codec, AV_OPT_FLAG_VIDEO_PARAM))  0)
+if (st-recommended_encoder_configuration) {
+av_log(NULL, AV_LOG_DEBUG, writing recommended configuration: %s\n,
+   st-recommended_encoder_configuration);
+if ((ret = ffm_write_recommended_config(s-pb, codec, MKBETAG('S', '2', 'V', 'I'),
+st-recommended_encoder_configuration))  0)
+return ret;
+} else if ((ret = ffm_write_header_codec_ctx(s-pb, codec, MKBETAG('S', '2', 'V', 'I'), AV_OPT_FLAG_VIDEO_PARAM))  0 ||
+   (ret = ffm_write_header_codec_private_ctx(s-pb, codec, AV_OPT_FLAG_VIDEO_PARAM))  0)
 return ret;
 break;
 case AVMEDIA_TYPE_AUDIO:
-if ((ret = ffm_write_header_codec_ctx(s-pb, codec, MKBETAG('S', '2', 'A', 'U'), AV_OPT_FLAG_AUDIO_PARAM))  0 ||
-(ret =

[FFmpeg-devel] [PATCH] doc/decoders.texi: typo in description for option ifo_palette

2014-11-21 Thread TOYAMA Shin-ichi

---
 doc/decoders.texi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/decoders.texi b/doc/decoders.texi
index 2c920e7..01fca9f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -192,7 +192,7 @@ ee450d, 101010, eaeaea, 0ce60b, ec14ed, ebff0b, 0d617a, 
7b7b7b, d1d1d1,
 7b2a0e, 0d950c, 0f007b, cf0dec, cfa80c, 7c127b}.

 @item ifo_palette
-Specify the the IFO file from which the global palette is obtained.
+Specify the IFO file from which the global palette is obtained.
 (experimental)

 @item forced_subs_only
--
2.1.1

-- 
TOYAMA Shin-ichi mailto:sh...@wmail.plala.or.jp
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/mxfdec.c: export source package uids and names as metadata

2014-11-21 Thread Mark Reid

On Fri, Nov 21, 2014 at 1:25 AM, Tomas Härdin tomas.har...@codemill.se
wrote:

 On Tue, 2014-11-18 at 16:52 -0800, Mark Reid wrote:
  ---
   libavformat/mxfdec.c | 74
 +++-
   1 file changed, 39 insertions(+), 35 deletions(-)
 
  diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
  index fa0a2f4..8c13c24 100644
  --- a/libavformat/mxfdec.c
  +++ b/libavformat/mxfdec.c

   static int mxf_timestamp_to_str(uint64_t timestamp, char **str)
   {
   struct tm time = { 0 };
  @@ -1969,7 +1973,7 @@ static const MXFMetadataReadTableEntry
 mxf_metadata_read_table[] = {
   { {
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x30,0x00
 }, mxf_read_identification_metadata },
   { {
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x18,0x00
 }, mxf_read_content_storage, 0, AnyType },
   { {
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x37,0x00
 }, mxf_read_source_package, sizeof(MXFPackage), SourcePackage },
  -{ {
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x36,0x00
 }, mxf_read_material_package, sizeof(MXFPackage), MaterialPackage },
  +{ {
 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x36,0x00
 }, mxf_read_source_package, sizeof(MXFPackage), MaterialPackage },

 Maybe rename mxf_read_source_package to mxf_read_package?
 Noticing that both functions are quite similar is a good catch :)
 The rest of the patch looks fine.


great, sounds good, I'll submit a v2 patch renaming mxf_read_source_package
- mxf_read_package

/Tomas

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


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

Re: [FFmpeg-devel] [PATCH] doc/decoders.texi: typo in description for option ifo_palette

On Sat, Nov 22, 2014 at 09:23:43AM +0900, TOYAMA Shin-ichi wrote:
 ---
  doc/decoders.texi | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] ffserver: use avcodec_copy_context to copy context

Copying context using dedicated function is safer that raw memcpy
which creates shallow copy.

Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
 ffserver.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/ffserver.c b/ffserver.c
index e3e76ba..7e36ab1 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3319,13 +3319,8 @@ static AVStream *add_av_stream1(FFServerStream *stream, 
AVCodecContext *codec, i
 if (!fst)
 return NULL;
 if (copy) {
-fst-codec = avcodec_alloc_context3(NULL);
-memcpy(fst-codec, codec, sizeof(AVCodecContext));
-if (codec-extradata_size) {
-fst-codec-extradata = av_mallocz(codec-extradata_size + 
FF_INPUT_BUFFER_PADDING_SIZE);
-memcpy(fst-codec-extradata, codec-extradata,
-codec-extradata_size);
-}
+fst-codec = avcodec_alloc_context3(codec-codec);
+avcodec_copy_context(fst-codec, codec);
 } else {
 /* live streams must use the actual feed's codec since it may be
  * updated later to carry extradata needed by them.
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v2] libavformat/mxfdec.c: export source package uids and names as metadata

2014-11-21 Thread Mark Reid

Changes since v1:
* renamed mxf_read_source_package - mxf_read_package

---
 libavformat/mxfdec.c | 78 +++-
 1 file changed, 41 insertions(+), 37 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index fa0a2f4..cc740b5 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -668,22 +668,6 @@ static int mxf_read_source_clip(void *arg, AVIOContext 
*pb, int tag, int size, U
 return 0;
 }
 
-static int mxf_read_material_package(void *arg, AVIOContext *pb, int tag, int 
size, UID uid, int64_t klv_offset)
-{
-MXFPackage *package = arg;
-switch(tag) {
-case 0x4403:
-package-tracks_count = avio_rb32(pb);
-package-tracks_refs = av_calloc(package-tracks_count, sizeof(UID));
-if (!package-tracks_refs)
-return AVERROR(ENOMEM);
-avio_skip(pb, 4); /* useless size of objects, always 16 according to 
specs */
-avio_read(pb, (uint8_t *)package-tracks_refs, package-tracks_count * 
sizeof(UID));
-break;
-}
-return 0;
-}
-
 static int mxf_read_timecode_component(void *arg, AVIOContext *pb, int tag, 
int size, UID uid, int64_t klv_offset)
 {
 MXFTimecodeComponent *mxf_timecode = arg;
@@ -779,7 +763,7 @@ static int mxf_read_utf16_string(AVIOContext *pb, int size, 
char** str)
 return ret;
 }
 
-static int mxf_read_source_package(void *arg, AVIOContext *pb, int tag, int 
size, UID uid, int64_t klv_offset)
+static int mxf_read_package(void *arg, AVIOContext *pb, int tag, int size, UID 
uid, int64_t klv_offset)
 {
 MXFPackage *package = arg;
 switch(tag) {
@@ -1416,6 +1400,34 @@ static int mxf_is_intra_only(MXFDescriptor *descriptor)
 descriptor-essence_codec_ul)-id != 
AV_CODEC_ID_NONE;
 }
 
+static int mxf_uid_to_str(UID uid, char **str)
+{
+int i;
+char *p;
+p = *str = av_mallocz(sizeof(UID) * 2 + 4 + 1);
+if (!p)
+return AVERROR(ENOMEM);
+for (i = 0; i  sizeof(UID); i++) {
+snprintf(p, 2 + 1, %.2x, uid[i]);
+p += 2;
+if (i == 3 || i == 5 || i == 7 || i == 9) {
+snprintf(p, 1 + 1, -);
+p++;
+}
+}
+return 0;
+}
+
+static int mxf_add_uid_metadata(AVDictionary **pm, const char *key, UID uid)
+{
+char *str;
+int ret;
+if ((ret = mxf_uid_to_str(uid, str))  0)
+return ret;
+av_dict_set(pm, key, str, AV_DICT_DONT_STRDUP_VAL);
+return 0;
+}
+
 static int mxf_add_timecode_metadata(AVDictionary **pm, const char *key, 
AVTimecode *tc)
 {
 char buf[AV_TIMECODE_STR_SIZE];
@@ -1476,6 +1488,8 @@ static int mxf_parse_physical_source_package(MXFContext 
*mxf, MXFTrack *source_t
 if (!physical_package)
 break;
 
+mxf_add_uid_metadata(st-metadata, reel_uid, 
physical_package-package_uid);
+
 /* the name of physical source package is name of the reel or tape */
 if (physical_package-name  physical_package-name[0])
 av_dict_set(st-metadata, reel_name, physical_package-name, 0);
@@ -1532,6 +1546,10 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 return AVERROR_INVALIDDATA;
 }
 
+mxf_add_uid_metadata(mxf-fc-metadata, material_package_uid, 
material_package-package_uid);
+if (material_package-name  material_package-name[0])
+av_dict_set(mxf-fc-metadata, material_package_name, 
material_package-name, 0);
+
 for (i = 0; i  material_package-tracks_count; i++) {
 MXFPackage *source_package = NULL;
 MXFTrack *material_track = NULL;
@@ -1712,6 +1730,10 @@ static int mxf_parse_structural_metadata(MXFContext *mxf)
 }
 av_log(mxf-fc, AV_LOG_VERBOSE, \n);
 
+mxf_add_uid_metadata(st-metadata, file_package_uid, 
source_package-package_uid);
+if (source_package-name  source_package-name[0])
+av_dict_set(st-metadata, file_package_name, 
source_package-name, 0);
+
 mxf_parse_physical_source_package(mxf, source_track, st);
 
 if (st-codec-codec_type == AVMEDIA_TYPE_VIDEO) {
@@ -1851,24 +1873,6 @@ fail_and_free:
 return ret;
 }
 
-static int mxf_uid_to_str(UID uid, char **str)
-{
-int i;
-char *p;
-p = *str = av_mallocz(sizeof(UID) * 2 + 4 + 1);
-if (!p)
-return AVERROR(ENOMEM);
-for (i = 0; i  sizeof(UID); i++) {
-snprintf(p, 2 + 1, %.2x, uid[i]);
-p += 2;
-if (i == 3 || i == 5 || i == 7 || i == 9) {
-snprintf(p, 1 + 1, -);
-p++;
-}
-}
-return 0;
-}
-
 static int mxf_timestamp_to_str(uint64_t timestamp, char **str)
 {
 struct tm time = { 0 };
@@ -1968,8 +1972,8 @@ static const MXFMetadataReadTableEntry 
mxf_metadata_read_table[] = {
 { { 
0x06,0x0e,0x2b,0x34,0x02,0x05,0x01,0x01,0x0d,0x01,0x02,0x01,0x01,0x04,0x04,0x00 
}, mxf_read_partition_pack },
 { { 
0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x30,0x00 
},

Re: [FFmpeg-devel] [PATCH v2] libavformat/mxfdec.c: export source package uids and names as metadata

On Fri, Nov 21, 2014 at 05:43:09PM -0800, Mark Reid wrote:
 Changes since v1:
 * renamed mxf_read_source_package - mxf_read_package
 
 ---
  libavformat/mxfdec.c | 78 
 +++-
  1 file changed, 41 insertions(+), 37 deletions(-)

applied

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/apngdec: properly skip currently unsupported in-stream tags