Hi Baptiste,
On Tue, May 14, 2019 at 10:38 AM Thomas Mundt wrote:
> Hi Baptiste,
>
> Am Di., 14. Mai 2019 um 00:33 Uhr schrieb Baptiste Coudurier <
> baptiste.coudur...@gmail.com>:
>
> > ---
> > libavformat/Makefile | 2 +-
> > libavformat/avc.c| 186 +
Hi,
I recently changed code that uses libavcodec for encoding to use timebases
with a higher granularity because there were cases where certain
conversions resulted in timestamp clashes which I could fix that way.
Now I realized that this totally screwed up rate control, e.g. for
mpeg2video. Bitr
For anyone who hasn't stumbled over this yet:
https://gopro.com/news/gopro-open-sources-the-cineform-codec
Might be a target for integration (it includes an encoder) or contain clues
for ffmpeg's own decoder.
HTH
___
ffmpeg-devel mailing list
ffmpeg-de
On Thu, Aug 10, 2017 at 1:38 PM, Paul B Mahol wrote:
> On 8/10/17, Robert Krüger wrote:
> > On Thu, Aug 10, 2017 at 10:21 AM, Paul B Mahol wrote:
> >
> >> On 8/9/17, Robert Krüger wrote:
> >> > Hi,
> >> >
> >> > can someone tell me
On Thu, Aug 10, 2017 at 10:21 AM, Paul B Mahol wrote:
> On 8/9/17, Robert Krüger wrote:
> > Hi,
> >
> > can someone tell me what this hints at? Is this more likely a broken file
> > or a missing feature of the demuxer? Unfortunately I cannot make the file
> >
Hi,
can someone tell me what this hints at? Is this more likely a broken file
or a missing feature of the demuxer? Unfortunately I cannot make the file
available due to legal issues but if I know where to look, I could try to
find a sample with similar characteristics.
[mov,mp4,m4a,3gp,3g2,mj2 @
On Wed, Feb 1, 2017 at 1:07 PM, wm4 wrote:
> On Wed, 1 Feb 2017 12:50:51 +0100
> Paul B Mahol wrote:
>
> > Signed-off-by: Paul B Mahol
> > ---
> > libavformat/mov.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
On Tue, Oct 18, 2016 at 10:10 PM, Sasi Inguva <
isasi-at-google@ffmpeg.org> wrote:
> I am also happy to fix any breaking files, if they don't fall under the
> above category.
>
>
>
The change seems to have caused resulting files to have incorrect duration
in some cases (remuxing XDCAM material
On Thu, Oct 13, 2016 at 9:54 PM, Dave Rice wrote:
>
> > On Oct 13, 2016, at 1:56 PM, Hendrik Leppkes
> wrote:
> >
> > Am 13.10.2016 19:03 schrieb "liangsi" :
> >>
> >> ---
> >> libavformat/isom.h | 1 +
> >> libavformat/mov.c | 5 -
> >> 2 files changed, 5 insertions(+), 1 deletion(-)
> >>
>
On Fri, Sep 23, 2016 at 6:12 PM, compn wrote:
> On Fri, 23 Sep 2016 09:57:02 +0200
> Robert Krüger wrote:
>
> > Hi,
> >
> > I am looking for searchable archives of ffmpeg-devel and
> > ffmpeg-cvslog. I used to use gmane but that seems to no longer work.
> &
On Fri, Sep 23, 2016 at 10:13 AM, Paul B Mahol wrote:
> On 9/23/16, Robert Krueger wrote:
> > Hi,
> >
> > I am looking for searchable archives of ffmpeg-devel and ffmpeg-cvslog. I
> > used to use gmane but that seems to no longer work.
> >
> > Would be great if someone has a hint. I can't imagin
Hi,
I am looking for searchable archives of ffmpeg-devel and ffmpeg-cvslog. I
used to use gmane but that seems to no longer work.
Would be great if someone has a hint. I can't imagine that people out there
search ml archives by going through them month by month.
Cheers,
Robert
_
On Tue, Aug 30, 2016 at 3:13 AM, Davinder Singh wrote:
> On Sat, Aug 27, 2016 at 6:15 PM Robert Krüger
> wrote:
>
> > [...]
> > what is the way to best contribute with test cases? I have two samples
> that
> > I use for testing, so far the results look very, ve
On Sun, Aug 28, 2016 at 11:31 AM, Paul B Mahol wrote:
> On Sat, Aug 27, 2016 at 2:45 PM, Robert Krüger
> wrote:
> >
> > what is the way to best contribute with test cases? I have two samples
> that
> > I use for testing, so far the results look very, very promising bu
On Thu, Aug 25, 2016 at 10:28 PM, Davinder Singh
wrote:
> On Thu, Aug 25, 2016 at 5:01 AM Andy Furniss wrote:
>
> >
> >
> > I am testing with a somewhat artificial sample in that it's a framerate
> > de-interlace + scale down of a 1080i master, though it is "real" in the
> > sense that I may wan
On Tue, Aug 23, 2016 at 3:09 PM, Carl Eugen Hoyos
wrote:
> Hi!
>
> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
> > the log level of INFO does not seem appropriate for the message
> (h264dec.c,
>
> This should be fixed now: The level is below default now if the buffer
>
On Fri, Aug 19, 2016 at 4:17 PM, Paul B Mahol wrote:
> On 8/19/16, Davinder Singh wrote:
> > On Fri, Aug 19, 2016 at 3:27 AM Paul B Mahol wrote:
> >
> >> On 8/18/16, Paul B Mahol wrote:
> >> > On 8/18/16, Davinder Singh wrote:
> >> >> On Thu, Aug 18, 2016 at 11:52 PM Paul B Mahol
> wrote:
>
On Mon, Aug 15, 2016 at 7:47 PM, Rostislav Pehlivanov
wrote:
> On 15 August 2016 at 11:51, Robert Krüger
> wrote:
>
> > On Sun, Aug 14, 2016 at 5:05 PM, Rostislav Pehlivanov <
> atomnu...@gmail.com
> > >
> > wrote:
> >
> > > On 10 April 20
On Mon, Aug 15, 2016 at 7:58 PM, Nicolas George wrote:
> Le nonidi 29 thermidor, an CCXXIV, Rostislav Pehlivanov a écrit :
> > The git master is fast changing and can happen API or setting
> > wise every day. Deprecations, behavioral changes, etc. This is why users
> > who need stability use the
On Sun, Aug 14, 2016 at 5:05 PM, Rostislav Pehlivanov
wrote:
> On 10 April 2016 at 16:38, Kieran Kunhya wrote:
>
> > ---
> > Changelog | 1 +
> > configure | 6 --
> > doc/encoders.texi | 105 -
> > doc/ffserver.conf | 2 +-
> > doc/
On Thu, Aug 4, 2016 at 1:55 PM, Carl Eugen Hoyos wrote:
> 2016-08-04 13:50 GMT+02:00 Robert Krüger :
> > the log level of INFO does not seem appropriate for the message
> (h264dec.c,
> > line 531). If it is a condition that shouldn't really happen, it should
> be
>
&
Hi,
the log level of INFO does not seem appropriate for the message (h264dec.c,
line 531). If it is a condition that shouldn't really happen, it should be
a warning, otherwise it should be debug (especially for library users this
floods the logs as this seems to happen for many files.
Would a pat
Hi,
I'm observing tons of these messages in my logs for mxf files from a number
of professional cameras.
Would it help to submit a sample, so someone could check if the warning
makes sense? I'm close to hacking the code locally to suppress this warning
because it seems it is logged once per frame
On Mon, May 9, 2016 at 9:40 PM, Kyle Swanson wrote:
> On Tue, Apr 5, 2016 at 7:01 PM, Kyle Swanson wrote:
> >
> > Here's another audio filter. I hinted at this a few months ago, but I
> found out that
> > finishing the last 5% took almost as long as the first 95%. This is an
> EBU R128
> > dynam
On Tue, Mar 1, 2016 at 11:06 AM, Carl Eugen Hoyos wrote:
> Rodger Combs gmail.com> writes:
>
> > This series adds decoders and encoders based on OSX's AudioToolbox
> framework. They may be faster than the native ones (particularly in
> > cases where they can be hardware-accelerated), the encode
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'
> >
>
> Patch attached - it
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
On Fri, Oct 30, 2015 at 2:14 AM, P. van Gaans wrote:
> On 10/29/2015 09:42 AM, Paul B Mahol wrote:
>
>> On 10/29/15, P. van Gaans wrote:
>>
>>> You all know the CSI episodes where they read a license plate by
>>> "enhancing" some super-grainy security footage. Nonsense, right? Well,
>>> maybe no
>
>
> Ah, like it's being done in PACK_6CH from swr's audio_convert.asm
> For complex_high some stack ab/use will be needed (see PACK_8CH), but it
> should
> be doable.
> This way w3fdif will be able to fully dethrone yadif :P
Once it supports +8bit, that is ;-)
__
On Tue, Sep 1, 2015 at 6:28 PM, Claudio Freire
wrote:
> On Tue, Sep 1, 2015 at 5:54 AM, Robert Krüger wrote:
> >> It's been the plan all along to negotiate the removal of the
> >> experimental flag after pushing those changes discussed and heavily
> >> t
On Mon, Aug 31, 2015 at 5:31 PM, Claudio Freire
wrote:
> On Mon, Aug 31, 2015 at 6:59 AM, Robert Krüger
> wrote:
> > On Mon, Aug 31, 2015 at 10:44 AM, Carl Eugen Hoyos
> wrote:
> >
> >> Hi!
> >>
> >> I didn't test myself but iiuc, the aa
On Mon, Aug 31, 2015 at 2:08 PM, Andy Furniss wrote:
> Robert Krüger wrote:
>
> OK, thanks for the sample. It is a very good sample for
>> interlacing/deinterlacing or also frame interpolation tests (e.g.
>> for testing mc_fps). Is is rights-free?
>>
>
> I mad
On Mon, Aug 31, 2015 at 1:35 PM, Andy Furniss wrote:
> Robert Krüger wrote:
>
>> On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss
>> wrote:
>>
>> Andy Furniss wrote:
>>>
>>> I've just done a quick test converting 25i to 30i and the il way
>&
On Mon, Aug 31, 2015 at 12:51 PM, Andy Furniss wrote:
> Andy Furniss wrote:
>
> I've just done a quick test converting 25i to 30i and the il way is
>> worse than yadif.
>>
>> Of course it's just one test with a compressed SD sample which I
>> then deint and scale with mpv to see on an HD monitor.
On Mon, Aug 31, 2015 at 10:44 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> I didn't test myself but iiuc, the aac encoder produces better
> quality than all other libavcodec audio encoders and better
> quality than the libvo-aac encoder that is not marked as
> experimental, so the flag should be removed
On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss wrote:
> Carl Eugen Hoyos wrote:
>
>> Robert Krüger lesspain.de> writes:
>>
>> The only other thing I noticed was that the stream seams to be
>>> marked as interlaced when it comes out of the first il filter,
On Sun, Aug 30, 2015 at 4:23 AM, Michael Niedermayer
wrote:
> From: Michael Niedermayer
>
> Works well with some scenes, works really not well with others
> if you can improve it, i would not be unhappy
>
> this should not be optimized yet except trivial things, first the code
> should work well
On Fri, Jul 24, 2015 at 8:50 PM, Michael Niedermayer
wrote:
> Works well with some scenes, works really not well with others
> More work needed
> if you can improve it, i would not be unhappy
>
> this should not be optimized yet except trivial things, first the code
> should work well then it sho
On Sat, Aug 29, 2015 at 6:32 PM, Carl Eugen Hoyos wrote:
> Marton Balint passwd.hu> writes:
>
> > Consider you have a 25i source, and you want 30i (60p for display)
> >
> > Are you referring to this filter chain for deinterleaving?
> >
> > -vf il=l=d:c=d,framerate=30,il=l=i:c=i,yadif=1
> >
> > A
On Sat, Aug 29, 2015 at 4:53 PM, Robert Krüger wrote:
>
>
> On Sat, Aug 29, 2015 at 4:45 PM, Robert Krüger
> wrote:
>
>>
>>
>> On Sat, Aug 29, 2015 at 3:53 PM, Carl Eugen Hoyos
>> wrote:
>>
>>> Robert Krüger lesspain.de> writes:
&
On Sat, Aug 29, 2015 at 4:45 PM, Robert Krüger wrote:
>
>
> On Sat, Aug 29, 2015 at 3:53 PM, Carl Eugen Hoyos
> wrote:
>
>> Robert Krüger lesspain.de> writes:
>>
>> > Do you mean processing the top and bottom fields
>> > as separate progress
On Sat, Aug 29, 2015 at 3:53 PM, Carl Eugen Hoyos wrote:
> Robert Krüger lesspain.de> writes:
>
> > Do you mean processing the top and bottom fields
> > as separate progressive
>
> Yes.
> (Sorry, I thought this is what "deinterleaving and
> interl
On Fri, Aug 28, 2015 at 5:50 PM, Carl Eugen Hoyos wrote:
> Robert Krüger lesspain.de> writes:
>
> > I still think the text is fine as it will
> > hopefully lead to people adding something like
> > yadif before the filter
>
> Which - if I am correct - is pl
On Fri, Aug 28, 2015 at 10:55 AM, Carl Eugen Hoyos wrote:
> Robert Krüger lesspain.de> writes:
>
> > > > > Shouldn't this be:
> > > > > ... required to deinterleave before and
> > > > > interleave after this filter.
> > > >
On Fri, Aug 28, 2015 at 12:01 AM, Carl Eugen Hoyos wrote:
> Robert Krüger lesspain.de> writes:
>
> > > > you are required to deinterlace before this
> > > > filter and re-interlace after this filter.
> > >
> > > Shouldn't this be:
Am 27.08.2015 23:24 schrieb "Carl Eugen Hoyos" :
>
> Paul B Mahol gmail.com> writes:
>
> > +This filter is not designed to function correctly with interlaced
media. If
> > +you wish to change the frame rate of interlaced media then you are
required
> > +to deinterlace before this filter and re-int
On Tue, Jul 14, 2015 at 3:17 PM, Paul B Mahol wrote:
> Dana 14. 7. 2015. 13:09 osoba "Robert Krüger"
> napisala je:
> >
> > On Mon, Jul 6, 2015 at 3:12 PM, Michael Niedermayer
> > wrote:
> >
> > > On Mon, Jul 06, 2015 at 03:10:41PM +0200, Michae
On Mon, Jul 6, 2015 at 3:12 PM, Michael Niedermayer
wrote:
> On Mon, Jul 06, 2015 at 03:10:41PM +0200, Michael Niedermayer wrote:
> > On Mon, Jul 06, 2015 at 11:56:21AM +, Paul B Mahol wrote:
> > > Signed-off-by: Paul B Mahol
> > > ---
> > > libswscale/output.c | 48
> +
On Mon, Jul 6, 2015 at 3:08 PM, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
> > > Please mention the ticket in the commit message
> > > for the swscaler output.
> >
> > Will, do. Although y416 have nothing to do with 16 bit ayuv.
>
> I completely agree but I think it turned out t
On Mon, Jul 6, 2015 at 2:27 PM, Carl Eugen Hoyos wrote:
> Paul B Mahol gmail.com> writes:
>
> > +static void
> > +yuv2ayuv16le_X_c
>
> Where you able to test this with the Apple
> encoder?
>
>
I will try to get a test setup running and post the results here, probably
tomorrow.
__
On Mon, Mar 23, 2015 at 5:37 PM, Michael Niedermayer
wrote:
> On Mon, Mar 23, 2015 at 04:28:57PM +0100, Robert Krüger wrote:
> > Hi,
> >
> > after a recent library upgrade in our application, we see tons of those
> > messages. What are the consequences of this? Does
Hi,
after a recent library upgrade in our application, we see tons of those
messages. What are the consequences of this? Does libavformat consider this
file corrupt? Is this an indication for a demuxer bug? Just ignoring the
message does not feel right.
Regards,
Robert
__
On Thu, Mar 5, 2015 at 10:32 AM, Michael Niedermayer
wrote:
> On Thu, Mar 05, 2015 at 10:23:02AM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 7:14 PM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 07:07:35PM +0100, Robert Krüger wrote:
On Wed, Mar 4, 2015 at 7:14 PM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 07:07:35PM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 6:57 PM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 06:19:19PM +0100, Robert Krüger wrote:
On Wed, Mar 4, 2015 at 6:57 PM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 06:19:19PM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
On Wed, Mar 4, 2015 at 5:34 PM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 03:40:09PM +0100, Robert Krüger wrote:
> > On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
> > wrote:
> >
> > > On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
On Wed, Mar 4, 2015 at 11:05 AM, Michael Niedermayer
wrote:
> On Wed, Mar 04, 2015 at 10:22:26AM +0100, Robert Krüger wrote:
> > On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
> > wrote:
> >
> > > On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote:
On Tue, Mar 3, 2015 at 9:27 PM, Michael Niedermayer
wrote:
> On Tue, Mar 03, 2015 at 09:24:17PM +0100, Robert Krüger wrote:
> > On Tue, Mar 3, 2015 at 7:23 PM, Michael Niedermayer
> > wrote:
> >
> > > On Tue, Mar 03, 2015 at 06:17:22PM +0100, Robert Krüger wrote:
On Tue, Mar 3, 2015 at 7:23 PM, Michael Niedermayer
wrote:
> On Tue, Mar 03, 2015 at 06:17:22PM +0100, Robert Krüger wrote:
>
> > This is based on an earlier patch by Derek
>
> please mention this in the commit message
>
OK, I will change that
>
>
> > that
This is based on an earlier patch by Derek that never went in because it
was argumented earlier that api breakage is not acceptable. However, that
was more or less relaxed after Michael noted that the replaced flag had
never been part of a release and since a number of people seem to agree,
this is
On Mon, Mar 2, 2015 at 10:39 PM, Michael Niedermayer
wrote:
> Hi all
>
> FFmpeg has been accepted in GSoC this year.
Congratulations! You proved quite a few people wrong by this, I guess :-).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http:
On Mon, Mar 2, 2015 at 6:56 PM, Mark Reid wrote:
> On Mon, Mar 2, 2015 at 1:46 AM, Robert Krüger wrote:
>
> > On Sun, Mar 1, 2015 at 10:43 PM, Mark Reid wrote:
> >
> > > On Sun, Mar 1, 2015 at 4:06 AM, Robert Krüger
> > wrote:
> > >
> > > >
On Sun, Mar 1, 2015 at 5:53 PM, Michael Niedermayer
wrote:
> Hi all
>
> its a while since FFmpeg 2.5, so its getting time to make 2.6
> if you want something in it or something fixed, now is your last
> chance ;)
>
> About the name if noone suggests something then ill pick a random
> scientist fr
On Sun, Mar 1, 2015 at 10:43 PM, Mark Reid wrote:
> On Sun, Mar 1, 2015 at 4:06 AM, Robert Krüger wrote:
>
> > Currently the product name that ends up in mxf files muxed using the new
> op
> > atom muxer is "OP1A muxer" which is misleading.
Am Sonntag, 1. März 2015 schrieb Derek Buitenhuis :
> On 3/1/2015 12:26 PM, Robert Krüger wrote:
> > Am I reading the committed patch incorrectly or is colr still not written
> > by default? I thought the argument against replacing the flag (Derek's
> > first patch) w
On Tue, Feb 24, 2015 at 11:55 AM, Michael Niedermayer
wrote:
> On Tue, Feb 24, 2015 at 08:00:07AM +, tim nicholson wrote:
> > On 21/02/15 01:34, Dave Rice wrote:
> > > Hi Robert, Kevin,
> > >
> > >> On Feb 20, 2015, at 9:56 AM, Robert Krüger
> wr
Currently the product name that ends up in mxf files muxed using the new op
atom muxer is "OP1A muxer" which is misleading. Attached patch changes that.
mxf_opatom_product_name.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On Tue, Feb 24, 2015 at 6:34 PM, Michael Niedermayer
wrote:
> On Tue, Feb 24, 2015 at 03:11:44PM +, Derek Buitenhuis wrote:
> > Some formats require this, such as v210. The consensus seems to be
> > to write it by default.
> >
> > Signed-off-by: Derek Buitenhuis
> > ---
> > This is a silent
Am Freitag, 20. Februar 2015 schrieb Kevin Wheatley :
> On Fri, Feb 20, 2015 at 1:30 PM, Robert Krüger > wrote:
> > if I read the code correctly, the colr atom is only written in the mov
> > muxer if the flag write_colr is specified. Was that behaviour chosen to
> &
Hi,
if I read the code correctly, the colr atom is only written in the mov
muxer if the flag write_colr is specified. Was that behaviour chosen to
have better backward compatibility or is there another reason not to write
this standard atom by default?
Thanks and best regards,
Robert
___
On Tue, Jan 27, 2015 at 12:14 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> Not-bitexact, dunno why. Do not have actual samples to test.
> ---
> LICENSE.md| 1 +
> configure | 1 +
> libavfilter/Makefile | 1 +
> libavfilter
First of all, thanks for taking the time for the detailed feedback.
On Thu, Sep 25, 2014 at 3:51 AM, compn wrote:
> On Mon, 15 Sep 2014 14:07:06 +0200
> Robert Krüger wrote:
>
>> On Mon, Sep 15, 2014 at 1:12 PM, Michael Niedermayer
>> wrote:
>> > On Mon, Se
On Mon, Sep 15, 2014 at 1:12 PM, Michael Niedermayer wrote:
> On Mon, Sep 15, 2014 at 10:26:28AM +0200, Robert Krüger wrote:
>> On Sun, Sep 14, 2014 at 5:58 PM, Michael Niedermayer
>> wrote:
>> > On Sun, Sep 14, 2014 at 05:40:35PM +0200, Robert Krüger wrote:
>> &g
On Sun, Sep 14, 2014 at 5:58 PM, Michael Niedermayer wrote:
> On Sun, Sep 14, 2014 at 05:40:35PM +0200, Robert Krüger wrote:
>> On Sat, Sep 13, 2014 at 12:36 PM, Michael Niedermayer
>> wrote:
>> > From: Baptiste Coudurier
>> >
>> > Ported by michael f
On Sat, Sep 13, 2014 at 12:36 PM, Michael Niedermayer wrote:
> From: Baptiste Coudurier
>
> Ported by michael from ffmbc to ffmpeg
> the code is under CONFIG_GPL as ffmbc is GPL
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxfenc.c | 143
> +++
On Fri, Aug 8, 2014 at 2:31 AM, Michael Niedermayer wrote:
> On Thu, Aug 07, 2014 at 04:52:43PM +0200, Robert Krüger wrote:
>> Hi,
>>
>> could someone explain, what the difference between those two is and
>> when to use which one?
>>
>> #define AV_CH_LAY
Hi,
could someone explain, what the difference between those two is and
when to use which one?
#define AV_CH_LAYOUT_STEREO(AV_CH_FRONT_LEFT|AV_CH_FRONT_RIGHT)
#define AV_CH_LAYOUT_STEREO_DOWNMIX(AV_CH_STEREO_LEFT|AV_CH_STEREO_RIGHT)
E.g. when I extract metadata and want to use th
77 matches
Mail list logo
