Re: [FFmpeg-devel] [PATCH] avformat/dca_parser: set actual samplerate

On Wed, Feb 3, 2016 at 12:52 PM, wm4 wrote: > On Wed, 3 Feb 2016 12:45:39 +0100 > Hendrik Leppkes wrote: > >> On Wed, Feb 3, 2016 at 12:41 PM, wm4 wrote: >> > Fixes timestamps with raw .dts demuxing. >> > --- >> >

Re: [FFmpeg-devel] [PATCH 5/5] lavf/asfenc: add support for setting packet size

Marton Balint passwd.hu> writes: > + item packet_size > +Set the muxer packet size. By tuning this setting you may reduce data > +fragmentation or muxer overhead depending on your source. Default value is > +3200, minimum is 100, maximum is 64k. Is this related to ticket #4230? Carl Eugen

[FFmpeg-devel] frma warnings in mov demuxer

Hi, after having updated our application to latest head, we get tons of annoying warnings like this one: [mov,mp4,m4a,3gp,3g2,mj2 @ 0x102007800] ignoring 'frma' atom of 'mp4a', stream format is 'mp4a' Would someone reconsider making this a warning? If I understand it correctly the code now even

Re: [FFmpeg-devel] [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data packets

On date Wednesday 2016-02-03 10:18:34 +0100, Stefano Sabatini encoded: [...] > Note: since my purpose is to allow remuxing KLV data, I can change > this to enable stream_id side-data only with data streams (so that no > reference must be changed). > > Since I have no strong opinion on this I'd

Re: [FFmpeg-devel] [PATCH 5/5] lavf/asfenc: add support for setting packet size

On Thu, 4 Feb 2016, Carl Eugen Hoyos wrote: Marton Balint passwd.hu> writes: + item packet_size +Set the muxer packet size. By tuning this setting you may reduce data +fragmentation or muxer overhead depending on your source. Default value is +3200, minimum is 100, maximum is 64k. Is this

[FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

The line alignment for B1W0 and B0W1 1 bpp video in nut was previously 4 bytes, which generated alignment warning messages, not only for odd-width files. The alignment is now 16 bytes. Also, made some simplifications, added some placeholders for the future PAL8 fourcc in nut, and added

Re: [FFmpeg-devel] [PATCH 5/5] lavf/asfenc: add support for setting packet size

On Thu, Feb 04, 2016 at 01:57:59AM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/muxers.texi | 20 > libavformat/asf.h| 2 -- > libavformat/asfenc.c | 41 + > 3 files changed, 45

Re: [FFmpeg-devel] [PATCH 3/5] lavf/asfenc: add support for storing languages

On Thu, 4 Feb 2016, Michael Niedermayer wrote: On Thu, Feb 04, 2016 at 01:57:57AM +0100, Marton Balint wrote: Signed-off-by: Marton Balint --- libavformat/asf.c| 4 +++ libavformat/asf.h| 1 + libavformat/asfenc.c | 73

Re: [FFmpeg-devel] [PATCH 3/5] lavf/asfenc: add support for storing languages

On Fri, Feb 05, 2016 at 12:10:53AM +0100, Marton Balint wrote: > > On Thu, 4 Feb 2016, Michael Niedermayer wrote: > > >On Thu, Feb 04, 2016 at 01:57:57AM +0100, Marton Balint wrote: > >>Signed-off-by: Marton Balint > >>--- > >> libavformat/asf.c| 4 +++ > >>

[FFmpeg-devel] [PATCH] lavf/mov: Extend extracting XMP in mov files using UUID Box

The UUID is based on http://www.adobe.com/devnet/xmp.html The patch is made according to XMP SPECIFICATION PART 3 - STORAGE IN FILES See Table 8 --- libavformat/mov.c | 28 1 file changed, 28 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index

Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

On Fri, Feb 5, 2016 at 3:05 AM, Neil Birkbeck wrote: > According to the ITU-T H.265 v3, in Table D - 1, the persistence scope > of the mastering display metadata is "The Coded Video Sequence (CVS) > containing the SEI message". So I guess we want to clear when we start >

Re: [FFmpeg-devel] [PATCH] Add GBRAP12 pixel format.

On 2/5/16, Kieran Kunhya wrote: > In preparation for Cineform Alpha channel support > --- > libavutil/pixdesc.c | 28 > libavutil/pixfmt.h| 3 +++ > libswscale/input.c| 4 > libswscale/swscale_unscaled.c |

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On Thu, Feb 04, 2016 at 10:45:23PM +0100, Mats Peterson wrote: > The line alignment for B1W0 and B0W1 1 bpp video in nut was > previously 4 bytes, which generated alignment warning messages, not > only for odd-width files. The alignment is now 16 bytes. > > Also, made some simplifications, added

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On 02/05/2016 02:49 AM, Mats Peterson wrote: On 02/05/2016 02:46 AM, Michael Niedermayer wrote: stride can be 0 and cause division by 0 later It can't, as far as I can see, since I'm checking both avctx->width and avctx->height before doing anything else. Furthermore, it's not used in any

Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

According to the ITU-T H.265 v3, in Table D - 1, the persistence scope of the mastering display metadata is "The Coded Video Sequence (CVS) containing the SEI message". So I guess we want to clear when we start the next CVS, so I guess when we see the next IDR frame. Given that the SEI comes

[FFmpeg-devel] [PATCH v3] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

Yes, it could (regarding stride being zero). Here's an updated patch. -- Mats Peterson http://matsp888.no-ip.org/~mats/ >From 623d4a4c429d7f795359250e543510938770f6fa Mon Sep 17 00:00:00 2001 From: Mats Peterson Date: Fri, 5 Feb 2016 03:02:04 +0100 Subject: [PATCH]

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On Fri, Feb 05, 2016 at 02:49:57AM +0100, Mats Peterson wrote: > On 02/05/2016 02:46 AM, Michael Niedermayer wrote: > >stride can be 0 and cause division by 0 later > > > > It can't, as far as I can see, since I'm checking both avctx->width > and avctx->height before doing anything else.

Re: [FFmpeg-devel] frma warnings in mov demuxer

On Thu, Feb 04, 2016 at 01:35:28PM +, Eran Kornblau wrote: > > after having updated our application to latest head, we get tons of > > annoying warnings like this one: > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x102007800] ignoring 'frma' atom of 'mp4a', > > stream format is 'mp4a' > > > > Patch

Re: [FFmpeg-devel] [PATCH] lavc/lavf: transmit stream_id information for mpegts KLV data packets

On Thu, 4 Feb 2016, Stefano Sabatini wrote: On date Wednesday 2016-02-03 10:18:34 +0100, Stefano Sabatini encoded: [...] Note: since my purpose is to allow remuxing KLV data, I can change this to enable stream_id side-data only with data streams (so that no reference must be changed). Since

Re: [FFmpeg-devel] [PATCH] Add GBRAP12 pixel format.

On Fri, Feb 05, 2016 at 12:51:49AM +, Kieran Kunhya wrote: > In preparation for Cineform Alpha channel support > --- > libavutil/pixdesc.c | 28 > libavutil/pixfmt.h| 3 +++ > libswscale/input.c| 4 >

Re: [FFmpeg-devel] [PATCH v2] x11grab: fixed next frame capture time calculation

On Wed, Feb 03, 2016 at 09:10:01AM -0500, Trevor \\ Higgins wrote: > The next frame time could slip, causing the frame rate to drop until > frames were dropped. Now will capture at the next correct moment instead. > > --- > > Fixed the style to conform to the standard > > --- >

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On 02/05/2016 02:46 AM, Michael Niedermayer wrote: stride can be 0 and cause division by 0 later It can't, as far as I can see, since I'm checking both avctx->width and avctx->height before doing anything else. Furthermore, it's not used in any division. Mats

Re: [FFmpeg-devel] [PATCH] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On 02/05/2016 02:53 AM, Mats Peterson wrote: On 02/05/2016 02:49 AM, Mats Peterson wrote: On 02/05/2016 02:46 AM, Michael Niedermayer wrote: stride can be 0 and cause division by 0 later It can't, as far as I can see, since I'm checking both avctx->width and avctx->height before doing

[FFmpeg-devel] FFplay with 2 video streams in concurrent time

Dear Senior, I would like to ask something about ffplay. ffmpeg define AVMediaType in avutil.h with 5 type of media as below enum AVMediaType { AVMEDIA_TYPE_UNKNOWN = -1, ///< Usually treated as AVMEDIA_TYPE_DATA AVMEDIA_TYPE_VIDEO, AVMEDIA_TYPE_AUDIO, AVMEDIA_TYPE_DATA,

[FFmpeg-devel] [PATCH] Add GBRAP12 pixel format.

In preparation for Cineform Alpha channel support --- libavutil/pixdesc.c | 28 libavutil/pixfmt.h| 3 +++ libswscale/input.c| 4 libswscale/swscale_unscaled.c | 3 +++ libswscale/utils.c| 6 ++ 5 files

[FFmpeg-devel] Replacing fate.f.o with fatebeta

Hi all, It has been more than a year (whew!) since I deployed the [new FATE server][1] to fatebeta.ffmpeg.org. Not much has changed on my end, except that some bugs are fixed and some long-sought-after features like the failometer are implemented. Earlier today, on the #ffmpeg-devel IRC channel,

Re: [FFmpeg-devel] [PATCH v3] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On 02/05/2016 03:04 AM, Mats Peterson wrote: Yes, it could (regarding stride being zero). Here's an updated patch. If you think it's extremely important to use monow for the case of raw 1 bpp AVI without a palette, I can remove the "Temporary solution" comments. But remember this will only

[FFmpeg-devel] [PATCH v2] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

Small fix. Description follows: The line alignment for B1W0 and B0W1 1 bpp video in nut was previously 4 bytes, which generated alignment warning messages, not only for odd-width files. The alignment is now 16 bytes. Also, made some simplifications, added some placeholders for the future

Re: [FFmpeg-devel] Replacing fate.f.o with fatebeta

On Thu, Feb 04, 2016 at 05:10:16PM -0800, Timothy Gu wrote: > Hi all, > > It has been more than a year (whew!) since I deployed the [new FATE server][1] > to fatebeta.ffmpeg.org. Not much has changed on my end, except that some > bugs are fixed and some long-sought-after features like the

Re: [FFmpeg-devel] frma warnings in mov demuxer

> after having updated our application to latest head, we get tons of > annoying warnings like this one: > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x102007800] ignoring 'frma' atom of 'mp4a', > stream format is 'mp4a' > Patch attached - it simply doesn't print the warning when the format contained in the

Re: [FFmpeg-devel] Replacing fate.f.o with fatebeta

On Fri, Feb 05, 2016 at 02:58:14AM +0100, Michael Niedermayer wrote: > On Thu, Feb 04, 2016 at 05:10:16PM -0800, Timothy Gu wrote: > > As of now, the "top bar" James mentioned has been added, so fatebeta has > > full > > feature parity with the old FATE website. > > does fatebeta support the

Re: [FFmpeg-devel] [PATCH] lavc/hevc Parse SEI_TYPE_MASTERING_DISPLAY_INFO and propagate contents into the AVMasteringDisplayMetadata side data.

On Thu, Feb 04, 2016 at 06:05:08PM -0800, Neil Birkbeck wrote: > According to the ITU-T H.265 v3, in Table D - 1, the persistence scope > of the mastering display metadata is "The Coded Video Sequence (CVS) > containing the SEI message". So I guess we want to clear when we start > the next CVS, so

Re: [FFmpeg-devel] [PATCH v3] lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut

On 02/05/2016 03:29 AM, Mats Peterson wrote: On 02/05/2016 03:04 AM, Mats Peterson wrote: Yes, it could (regarding stride being zero). Here's an updated patch. If you think it's extremely important to use monow for the case of raw 1 bpp AVI without a palette, I can remove the "Temporary

Re: [FFmpeg-devel] [PATCH] avfilter/af_apulsator: assert that pathes leaving uninitialized variables do not occur

On 2/4/16, Michael Niedermayer wrote: > Fixes: CID1341581, CID1341582 > > Signed-off-by: Michael Niedermayer > --- > libavfilter/af_apulsator.c |3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/af_apulsator.c

Re: [FFmpeg-devel] movenc: Enable timecode tracks in MP4

Syed Andaleeb Roomy gmail.com> writes: > I worked on the attached patch to enable timecode tracks in MP4 files > written by ffmpeg. Could someone please take a look to see if it is > acceptable? Ping, see ticket #4704. Carl Eugen ___ ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libutvideoenc: fix compiler warnings, initialize the correct type

On Thu, Feb 04, 2016 at 03:30:34PM +, Derek Buitenhuis wrote: > On 2/4/2016 2:12 AM, Michael Niedermayer wrote: > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/libutvideoenc.cpp |6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > My

Re: [FFmpeg-devel] [PATCH] avfilter/af_apulsator: assert that pathes leaving uninitialized variables do not occur

On Thu, Feb 04, 2016 at 10:14:53AM +0100, Paul B Mahol wrote: > On 2/4/16, Michael Niedermayer wrote: > > Fixes: CID1341581, CID1341582 > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/af_apulsator.c |3 +++ > > 1 file

Re: [FFmpeg-devel] frma warnings in mov demuxer

On Thu, Feb 4, 2016 at 2:35 PM, Eran Kornblau wrote: > > after having updated our application to latest head, we get tons of > > annoying warnings like this one: > > > > [mov,mp4,m4a,3gp,3g2,mj2 @ 0x102007800] ignoring 'frma' atom of 'mp4a', > > stream format is 'mp4a'

Re: [FFmpeg-devel] [PATCH] avcodec/libutvideoenc: fix compiler warnings, initialize the correct type

On 2/4/2016 2:12 AM, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/libutvideoenc.cpp |6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) My personal preference, and that shared by every single person I've asked, is that

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 4 February 2016 at 16:04, wrote: > On 16-02-04 at 15:48, Rostislav Pehlivanov wrote: > [..] > Just being pedantic, but -Wdeclaration-after-statement does not warn on > any of those, see attached test file which compiles without errors with > -Wall -Wpedantic -Werror

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

Le sextidi 16 pluviôse, an CCXXIV, Derek Buitenhuis a écrit : > I do mind for loops, but I consider, along with VLAs, mixed code and var > decls to be bad practice, myself. I tend to agree, although I would not put it on the same level as VLAs: VLAs are really harder to compile for the compiler,

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 4 February 2016 at 16:20, Derek Buitenhuis wrote: > On 2/4/2016 4:14 PM, Rostislav Pehlivanov wrote: > > Do we even support MSVC versions old enough to error on compilation for > > mixed declarations and variables? Will c99conv actually error if it > > encounters

Re: [FFmpeg-devel] [PATCH] fate: fix fate-aac-pns-encode failures on non-sse x86_32 targets

On 4 February 2016 at 17:40, James Almer wrote: > Signed-off-by: James Almer > --- > tests/fate/aac.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > [...] LGTM Thanks ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] fate: fix fate-aac-pns-encode failures on non-sse x86_32 targets

On 2/4/2016 2:52 PM, Rostislav Pehlivanov wrote: > On 4 February 2016 at 17:40, James Almer wrote: > >> Signed-off-by: James Almer >> --- >> tests/fate/aac.mak | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> [...] > > > LGTM > > Thanks

Re: [FFmpeg-devel] [PATCH 3/5] lavf/asfenc: add support for storing languages

On Thu, Feb 04, 2016 at 01:57:57AM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavformat/asf.c| 4 +++ > libavformat/asf.h| 1 + > libavformat/asfenc.c | 73 > +--- > 3 files changed, 74

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc: Move prediction_method to codec private options

On 2/4/2016 1:56 AM, Michael Niedermayer wrote: > this breaks existing command line usage like -pred 3 > and "3" previously lacked a named constant so people had to use a > litteral 3 i think Already smacked around Vittorio for that. It can be fixed, or it can be left/documented. I have no

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 16-02-04 at 15:48, Rostislav Pehlivanov wrote: [..] > This will essentially help bring the project to near 21st century age > and finally allow for developers to save on line numbers by NOT having > to define the variable around which a for loop needs to iterate (e.g. > have for (int i = 0; i <

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On Thu, Feb 4, 2016 at 5:04 PM, wrote: > On 16-02-04 at 15:48, Rostislav Pehlivanov wrote: > [..] >> This will essentially help bring the project to near 21st century age >> and finally allow for developers to save on line numbers by NOT having >> to define the variable

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 4 February 2016 at 15:55, Derek Buitenhuis wrote: > On 2/4/2016 3:48 PM, Rostislav Pehlivanov wrote: > > The only reason this existed was to allow for old compilers to not > > complain/compile the project's code. As far as I know, we no longer have > > support for

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 2/4/2016 4:14 PM, Rostislav Pehlivanov wrote: > Do we even support MSVC versions old enough to error on compilation for > mixed declarations and variables? Will c99conv actually error if it > encounters such code? Yes, and, I believe, yes. > As for the other compilers, I bet they're

[FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

The only reason this existed was to allow for old compilers to not complain/compile the project's code. As far as I know, we no longer have support for such compilers hence this flag has become useless and we have no reason to continue dragging so much behind the current standard of the C

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On 2/4/2016 3:48 PM, Rostislav Pehlivanov wrote: > The only reason this existed was to allow for old compilers to not > complain/compile the project's code. As far as I know, we no longer have > support for such compilers hence this flag has become useless and we > have no reason to continue

Re: [FFmpeg-devel] [PATCH] configure: remove the mixed declarations and code warning flag

On Thu, Feb 04, 2016 at 17:04:20 +0100, ffmpeg-...@c-14.de wrote: > Just being pedantic, but -Wdeclaration-after-statement does not warn on > any of those, see attached test file which compiles without errors with > -Wall -Wpedantic -Werror -Wdeclaration-after-statement (at least on > modern clang

[FFmpeg-devel] [PATCH] fate: fix fate-aac-pns-encode failures on non-sse x86_32 targets

Signed-off-by: James Almer --- tests/fate/aac.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak index ac29cc0..8d1e303 100644 --- a/tests/fate/aac.mak +++ b/tests/fate/aac.mak @@ -178,7 +178,7 @@

Re: [FFmpeg-devel] [RFC][WIP][PATCH] avfilter: add luascript filter

On 2/2/16, Paul B Mahol wrote: > Hi, > > patch attached. > Much more useful version attached. Simple demo demonstrating functionality currently missing in lavfi: lavfi.log(0, "Lavfi script example", lavfi.script_name, lavfi.frame_count(0)); if (lavfi.frame_count(0) >= 50)

[FFmpeg-devel] Problem decoding jpeg2000 video stream in mxf container -- file uploaded to upload.ffmpeg.org/incoming

Hi all Tearing my hair out trying to decode the file “warehouse.mxf” which I have uploaded to upload.ffmpeg.org/incoming Here’s the output from my Mac. I get the same results on Debian Linux. The file is created by Maxx-2400HD video server from

Re: [FFmpeg-devel] [PATCH 4/5] lavf/asfenc: add support for storing creation time

On Thu, Feb 04, 2016 at 01:57:58AM +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavformat/asfenc.c | 24 +--- > 1 file changed, 17 insertions(+), 7 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: