Re: [FFmpeg-devel] WinRT API support patch
On 21.11.2014, at 07:44, Jesse Jiang wrote:
> Now, I find a function get_generic_seed()
> So, I use this function will work fine?
It is already used as fallback so I don't see why you'd have to change the code
at all.
> uint32_t av_get_random_seed(void){uint32_t seed;
> #if HAVE_CRYPTGENRANDOMHCRYPTPROV provider;if
> (CryptAcquireContext(&provider, NULL, NULL, PROV_RSA_FULL,
> CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {BOOL ret =
> CryptGenRandom(provider, sizeof(seed), (PBYTE) &seed);
> CryptReleaseContext(provider, 0);if (ret)return seed;
> }#endif
> #if HAVE_WINRTAPIreturn get_generic_seed();#endif
>if (read_random(&seed, "/dev/urandom") == sizeof(seed))return
> seed;if (read_random(&seed, "/dev/random") == sizeof(seed))
> return seed;return get_generic_seed();}
>> From: jessejiang0...@outlook.com
>> To: ffmpeg-devel@ffmpeg.org
>> Date: Fri, 21 Nov 2014 03:51:12 +
>> Subject: Re: [FFmpeg-devel] WinRT API support patch
>>
>> Hi All,
>> I did some research, rand() is pseudo random. CryptGenRandom is the
>> system-wide seed, but it cannot be used in Windows RT.
>> I try to use CryptographicBuffer, which is Windows RT API, but there is a
>> problem. This API needs to link Windows.winmd. The Windows.winmd just like a
>> DLL, but it may different from Windows RT and Windows Phone. First, the SDKs
>> are in the different PATH,Second, the files are also different.
>> It means that developer need to choice platform first, and then compiler for
>> different library.
>> I hope ffmpeg only depends on support win32 apis and CRT apis.
>> So is there any way to instead of srand(time(0)); rand(); ? How about c++11
>> or Mersenne twister Algorithmic
>> Best regards,Jesse
>> Date: Fri, 21 Nov 2014 02:49:59 +0100
>> From: michae...@gmx.at
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] WinRT API support patch
>>
>> On Fri, Nov 21, 2014 at 01:43:29AM +, Jesse Jiang wrote:
>>> Do you mean that we can use rand() instead of CryptGenRandom in ffmpeg?
>>
>> rand() is completely wrong
>> its not even doing the correct operation
>>
>> rand() is pseudo random
>> the code requires a strong (and non pseudo) random value
>>
>> [...]
>> --
>> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>>
>> When you are offended at any man's fault, turn to yourself and study your
>> own failings. Then you will forget your anger. -- Epictetus
>>
>> ___
>> 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
>
> ___
> 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 3/6] Add AV_PIX_FMT_NV12T.
On Fri, 21 Nov 2014 08:45:47 +0100 Alexis Ballier wrote: > On Thu, 20 Nov 2014 18:42:19 +0100 > wm4 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. > > 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. So this is a decoder. Why can't the decoder take care of this conversion too? 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] WinRT API support patch
On 20.11.2014, at 09:48, Jesse Jiang wrote: > Hi Reimar, > Because of Windows RT cannot use CryptographicBuffer or _beginthreadex API, > so I try to use rand() instead of it, or we need to write own function > instead of it. If we use WinRT api to instead of these apis, it will cause > more bugs. Microsoft says explicitly that you should use _beginthreadex, so if WinRT doesn't have it or a useable alternative you'll have to disable threading or risk random crashes: A thread in an executable that calls the C run-time library (CRT) should use the _beginthreadex and_endthreadex functions for thread management rather than CreateThread and ExitThread; this requires the use of the multithreaded version of the CRT. If a thread created using CreateThread calls the CRT, the CRT may terminate the process in low-memory conditions. (note, this does not even mention the potential memleaks issue. And I don't know what insanity made them support only the broken function on WinRT. Seems to be typical Microsoft: when designing something new, only keep the most broken parts of the old and add whatever breakage you can on top). > Best regards,Jesse >> From: reimar.doeffin...@gmx.de >> Date: Thu, 20 Nov 2014 09:18:30 +0100 >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] WinRT API support patch >> >> On 20 November 2014 08:34:54 CET, Jesse Jiang >> wrote: >>> Add WinRT API supports >> >> At least 2 fairly major issues: >> 1) using rand() basically never is correct. Use the appropriate >> CryptographicBuffer function (yes, that means you need some C++ code >> unfortunately). >> 2) CreateThread is not compatible with _beginthreadex, there is a good >> reason why we use this. Using the other without additional changes will >> cause memleaks or worse. I am not even sure it is at all possible to use >> CreateThread correctly for us. >> >> ___ >> 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 ___ 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:01:43 +0100 wm4 wrote: > On Fri, 21 Nov 2014 08:45:47 +0100 > Alexis Ballier wrote: > > > On Thu, 20 Nov 2014 18:42:19 +0100 > > wm4 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
> 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\t ", 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 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 wrote: > On 21 Nov, Alexis Ballier wrote : > > On Thu, 20 Nov 2014 18:40:18 +0100 > > Jean-Baptiste Kempf 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
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 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
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 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 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 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 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.
On Fri, 21 Nov 2014 10:43:15 +0100 Alexis Ballier wrote: > On Fri, 21 Nov 2014 10:15:29 +0100 > Jean-Baptiste Kempf 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: > > 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. 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 wrote: > On Fri, 21 Nov 2014 10:43:15 +0100 > Alexis Ballier wrote: > > > On Fri, 21 Nov 2014 10:15:29 +0100 > > Jean-Baptiste Kempf 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.
On Fri, 21 Nov 2014 11:15:08 +0100 Alexis Ballier wrote: > On Fri, 21 Nov 2014 10:51:52 +0100 > wm4 wrote: > > > On Fri, 21 Nov 2014 10:43:15 +0100 > > Alexis Ballier wrote: > > > > > On Fri, 21 Nov 2014 10:15:29 +0100 > > > Jean-Baptiste Kempf 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 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 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,
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: add APNG support.
On Fri, 21 Nov 2014 12:05:47 +0100 Benoit Fouet 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 3/6] Add AV_PIX_FMT_NV12T.
On Fri, 21 Nov 2014 11:52:01 +0100 Alexis Ballier wrote: > > 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 tried that and it indeed completely breaks linesize computing which i need. ___ 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
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, -- 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] 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 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
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
Re: [FFmpeg-devel] bprint.h can't be included in C++ code
Le primidi 1er frimaire, an CCXXIII, Vadim Kalinsky a écrit :
> bprint.h can't be included in C++ code
> C++ does not support anonymous struct.
Thanks for the patch.
Basically, bprint.h is not meant to be included in c++ code.
> From a45cc83a807e7eabf158ddff52751171e80874f8 Mon Sep 17 00:00:00 2001
> From: Vadim Kalinsky
> Date: Fri, 21 Nov 2014 13:39:07 -0500
> Subject: [PATCH] C++ compatible AVBPrint definition.
>
> ---
> libavutil/bprint.h | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/libavutil/bprint.h b/libavutil/bprint.h
> index d1682fc..10e96d7 100644
> --- a/libavutil/bprint.h
> +++ b/libavutil/bprint.h
> @@ -30,9 +30,12 @@
> * Define a structure with extra padding to a fixed size
> * This helps ensuring binary compatibility with future versions.
> */
> -#define FF_PAD_STRUCTURE(size, ...) \
> -__VA_ARGS__ \
> -char reserved_padding[size - sizeof(struct { __VA_ARGS__ })];
> +#define FF_PAD_STRUCTURE(name,size, ...) \
> +typedef struct __pad_structure_helper_##name { __VA_ARGS__ }
> __pad_structure_helper_##name; \
> +typedef struct name { \
> +__VA_ARGS__ \
> +char reserved_padding[size - sizeof(__pad_structure_helper_##name)]; \
> +} name;
Apart from the fact that it makes the macro hackery vastly less readable
(maybe some indentation would help), identifiers starting with a double
underscode are reserved for the implementation, and therefore can not be
used.
>
> /**
> * Buffer to print data progressively
> @@ -74,15 +77,14 @@
> * internal buffer is large enough to hold a reasonable paragraph of text,
> * such as the current paragraph.
> */
> -typedef struct AVBPrint {
> -FF_PAD_STRUCTURE(1024,
> +
> +FF_PAD_STRUCTURE(AVBPrint, 1024,
> char *str; /**< string so far */
> unsigned len; /**< length so far */
> unsigned size; /**< allocated memory */
> unsigned size_max; /**< maximum allocated memory */
> char reserved_internal_buffer[1];
> -)
> -} AVBPrint;
> +)
>
> /**
> * Convenience macros for special values for av_bprint_init() size_max
Regards,
--
Nicolas George
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
Signed-off-by: James Almer --- 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
Also use length and not stream position
Signed-off-by: James Almer
---
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
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
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
Date: Sat, 15 Nov 2014 18:43:41 +0100
Subject: [PATCH 5/9] ffserver: allow skip setting defaults
Signed-off-by: Lukasz Marek
---
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;
return
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
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
---
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 03/11] ffserver_config: map ffserver options to AVOptions
On 21.11.2014 23:17, Reynaldo H. Verdejo Pinochet wrote:
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.
updated patch attached,
Regarding 80 chars it is just my opinion. The link says to do it only
when readability doesn't decrease and I try to do it this way tbh.
I made few changes in new versions and will keep it in mind in future,
but probably this was last so big patchset for ffserver* of mine.
Off topic:
This all is kinda funny:
http://programmers.stackexchange.com/questions/148677/why-is-80-characters-the-standard-limit-for-code-width/148729#148729
and this recall me
http://www.astrodigital.org/space/stshorse.html
>From fa7bed380a71b0be0de626ed3add5204b7cf8c67 Mon Sep 17 00:00:00 2001
From: Lukasz Marek
Date: Thu, 13 Nov 2014 18:45:43 +0100
Subject: [PATCH 3/9] ffserver_config: map ffserver options to AVOptions
Signed-off-by: Lukasz Marek
---
ffserver_config.c | 238 --
ffserver_config.h | 2 -
2 files changed, 70 insertions(+), 170 deletions(-)
diff --git a/ffserver_config.c b/ffserver_config.c
index 7266455..67c4890 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -470,6 +470,9 @@ static int ffserver_save_avoption(const char *opt, const char *arg, int type, FF
}
o = av_opt_find(ctx, option, NULL, type | AV_OPT_FLAG_ENCODING_PARAM, AV_OPT_SEARCH_CHILDREN);
+if (!o && (!strcmp(option, "time_base") || !strcmp(option, "pixel_format") ||
+ !strcmp(option, "video_size") || !strcmp(option, "codec_tag")))
+o = av_opt_find(ctx, option, NULL, 0, 0);
if (!o) {
report_config_error(config->filename, config->line_num, AV_LOG_ERROR,
&config->errors, "Option not found: %s\n", opt);
@@ -497,6 +500,14 @@ static int ffserver_save_avoption(const char *opt, const char *arg, int type, FF
return 0;
}
+static int ffserver_save_avoption_int(const char *opt, int64_t arg,
+ int type, FFServerConfig *config)
+{
+char buf[30];
+snprintf(buf, sizeof(buf), "%"PRId64, arg);
+return ffserver_save_avoption(opt, buf, type, config);
+}
+
#define ERROR(...) report_config_error(config->filename, config->line_num, AV_LOG_ERROR, &config->errors, __VA_ARGS__)
#define WARNING(...) report_config_error(config->filename, config->line_num, AV_LOG_WARNING, &config->warnings, __VA_ARGS__)
@@ -673,105 +684,10 @@ static int ffserver_parse_config_feed(FFServerConfig *config, const char *cmd, c
return 0;
}
-static void ffserver_apply_stream_config(AVCodecContext *enc, const AVDictionary *conf, AVDictionary **opts)
+static void ffserver_apply_stream_config(AVCodecContext *enc, AVDictionary **opts)
{
-AVDictionaryEntry *e;
-
-/* Return values from ffserver_set_*_param are ignored.
- Values are initially parsed and checked before inserting to
- AVDictionary. */
-
-//video params
-if ((e = av_dict_get(conf, "VideoBitRateRangeMin", NULL, 0)))
-ffserver_set_int_param(&enc->rc_min_rate, e->value, 1000, INT_MIN,
-INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "VideoBitRateRangeMax", NULL, 0)))
-ffserver_set_int_param(&enc->rc_max_rate, e->value, 1000, INT_MIN,
-INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "Debug", NULL, 0)))
-ffserver_set_int_param(&enc->debug, e->value, 0, INT_MIN, INT_MAX,
-NULL, 0, NULL);
-if ((e = av_dict_get(conf, "Strict", NULL, 0)))
-ffserver_set_int_param(&enc->strict_std_compliance, e->value, 0,
-INT_MIN, INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "VideoBufferSize", NULL, 0)))
-ffserver_set_int_param(&enc->rc_buffer_size, e->value, 8*1024,
-INT_MIN, INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "VideoBitRateTolerance", NULL, 0)))
-ffserver_set_int_param(&enc->bit_rate_tolerance, e->value, 1000,
-INT_MIN, INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "VideoBitRate", NULL, 0)))
-ffserver_set_int_param(&enc->bit_rate, e->value, 1000, INT_MIN,
-INT_MAX, NULL, 0, NULL);
-if ((e = av_dict_get(conf, "VideoSizeWidth", NULL, 0)))
-ffserver_set_int_param(&enc->width, e->value, 0,
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 ^
Bests,
Updated patch, av_dict_serialize -> av_dict_get string
I think I have resent all modified patches, but
I pushed whole patchset to my github master branch just in case.
https://github.com/lukaszmluki/ffmpeg
>From 7038a95c6398f62e2b3196a85cd4ba4754c4fee6 Mon Sep 17 00:00:00 2001
From: Lukasz Marek
Date: Sun, 16 Nov 2014 21:51:42 +0100
Subject: [PATCH 6/9] ffserver: export recommented encoder configuration
Signed-off-by: Lukasz Marek
---
ffserver.c| 6 +++--
ffserver_config.c | 77 ++-
2 files changed, 63 insertions(+), 20 deletions(-)
diff --git a/ffserver.c b/ffserver.c
index e24243d..3702fd6 100644
--- a/ffserver.c
+++ b/ffserver.c
@@ -3326,8 +3326,7 @@ static int add_av_stream(FFServerStream *feed, AVStream *st)
av = st->codec;
for(i=0;inb_streams;i++) {
-st = feed->streams[i];
-av1 = st->codec;
+av1 = feed->streams[i]->codec;
if (av1->codec_id == av->codec_id &&
av1->codec_type == av->codec_type &&
av1->bit_rate == av->bit_rate) {
@@ -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)));
return feed->nb_streams - 1;
}
diff --git a/ffserver_config.c b/ffserver_config.c
index 8339638..0792aec 100644
--- a/ffserver_config.c
+++ b/ffserver_config.c
@@ -178,13 +178,15 @@ static void add_codec(FFServerStream *stream, AVCodecContext *av,
FFServerConfig *config)
{
AVStream *st;
-AVDictionary **opts;
+AVDictionary **opts, *recommended = NULL;
+char *enc_config;
if(stream->nb_streams >= FF_ARRAY_ELEMS(stream->streams))
return;
opts = av->codec_type == AVMEDIA_TYPE_AUDIO ?
&config->audio_opts : &config->video_opts;
+av_dict_copy(&recommended, *opts, 0);
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))
@@ -196,63 +198,99 @@ static void add_codec(FFServerStream *stream, AVCodecContext *av,
/* compute default parameters */
switch(av->codec_type) {
case AVMEDIA_TYPE_AUDIO:
-if (av->bit_rate == 0)
+if (av->bit_rate == 0) {
av->bit_rate = 64000;
-if (av->sample_rate == 0)
+av_dict_set_int(&recommended, "ab", av->bit_rate, 0);
+}
+if (av->sample_rate == 0) {
av->sample_rate = 22050;
-if (av->channels == 0)
+av_dict_set_int(&recommended, "ar", av->sample_rate, 0);
+}
+if (av->channels == 0) {
av->channels = 1;
+av_dict_set_int(&recommended, "ac", av->channels, 0);
+}
break;
case AVMEDIA_TYPE_VIDEO:
-if (av->bit_rate == 0)
+if (av->bit_rate == 0) {
av->bit_rate = 64000;
+av_dict_set_int(&recommended, "b", av->bit_rate, 0);
+}
if (av->time_base.num == 0){
av->time_base.den = 5;
av->time_base.num = 1;
+av_dict_set(&recommended, "time_base", "1/5", 0);
}
if (av->width == 0 || av->height == 0) {
av->width = 160;
av->height = 128;
+av_dict_set(&recommended, "video_size", "160x128", 0);
}
/* Bitrate tolerance is less for streaming */
-if (av->bit_rate_tolerance == 0)
+if (av->bit_rate_tolerance == 0) {
av->bit_rate_tolerance = FFMAX(av->bit_rate / 4,
(int64_t)av->bit_rate*av->time_base.num/av->time_base.den);
-if (av->qmin == 0)
+av_dict_set_int(&recommended, "bt", av->bit_rate_tolerance, 0);
+}
+if (av->qmin == 0) {
av->qmin = 3;
-if (av->qmax == 0)
+av_dict_set_int(&recommended, "qmin", av->qmin, 0);
+}
+if (av->qmax == 0) {
av->qmax = 31;
-if (av->max_qdiff == 0)
+av_dict_set_int(&recommended, "qmax", av->qmax, 0
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
---
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
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
---
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 = ffm_write_header_codec_private_ctx(s-
[FFmpeg-devel] [PATCH] doc/decoders.texi: typo in description for option ifo_palette
--- 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] avcodec/pngdec: add APNG support.
On 21/11/14 8:05 AM, Benoit Fouet wrote: > --- > Changes: > - do not reset decode_next_dat when decoding IDAT of fdAT > - add configure part > --- Changelog entry? ___ 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
On Fri, Nov 21, 2014 at 1:25 AM, Tomas Härdin
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
---
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
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
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
Hi, On November 21, 2014 11:09:33 PM GMT+01:00, James Almer wrote: >Signed-off-by: James Almer >--- > 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 */ OK, of course (I have this one in my tree but I forgot to send an update for the demuxer when I sent the decoder one...), thanks. -- Ben ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/apngdec: print currently unsupported in-stream tags in a readable form
Hi,
On November 21, 2014 11:09:34 PM GMT+01:00, James Almer
wrote:
>Also use length and not stream position
>
>Signed-off-by: James Almer
>---
> 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 */
I'm fine with the len part, of course.
As for the tag part, could you please keep the u32 version too? Like "%s
(%#08X)".
Thanks,
--
Ben
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf: fix apngdec under msvc.
The recently added apngdec code does not compile under msvc. See: http://fate.ffmpeg.org/report.cgi?time=20141122053145&slot=x86_32-msvc12-windows-native Attached is a patch to fix it. 0001-lavf-fix-apngdec-under-msvc.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
