hi
On 26 August 2017 at 12:08, Carl Eugen Hoyos wrote:
> 2017-08-25 13:25 GMT+02:00 Jean-Yves Avenard :
>
>> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
>
> Why does this only apply to flac?
>
Sorry, I had missed your reply.
The specification on
Hi.
According to the documentation of av_parser_parse2:
https://www.ffmpeg.org/doxygen/trunk/group__lavc__parsing.html#ga691ca0258e91f99297e7726f56d8c247
"poutbuf_size set to size of parsed buffer or zero if not yet finished. "
So we can expect that both poutbuf_size and poutbuf will be set up
Hi
On 25 October 2017 at 23:57, Carl Eugen Hoyos wrote:
>> ISOBMFF only defines that AudioSampleEntryV1 should be used instead,
>> in which case the sampling_rate is a 32 bits integer (ISO 14496-12
>> 12.2.3.2)
>
> Not sure I understand:
> In ticket #6609, I asked if this is a flac-only issue.
>
On 26 October 2017 at 16:34, Carl Eugen Hoyos wrote:
> Was this already mentioned somewhere?
> Do other codecs with large sample rates in mp4 play with Firefox?
not if the metadata reports a sampling rate of 0
___
ffmpeg-devel mailing list
ffmpeg-d
Hi.
Mozilla also fixed some data races in pthread_frames.c which you may want
to look at. It's very similar to problem you mentioned
We made the code conditional on being in an TSan build.
https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/libavcodec/pthread_frame.c#46
Sorry, using the n
V1 along a
SamplingRateBox ('srat') which uses a 32 bits unsigned integer.
There's no handling of that in the current ffmpeg.
If time permit I will submit something for this.
Rgds
JY
On 25 August 2017 at 13:25, Jean-Yves Avenard wrote:
> From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon
From 9baa7166fa96ed6beac9146c7e3b4dcf425a67d0 Mon Sep 17 00:00:00 2001
From: Jean-Yves Avenard
Date: Fri, 25 Aug 2017 13:11:28 +0200
Subject: [PATCH] Properly store sampling rate for FLAC in mp4
Fixes ticket #6609
Signed-off-by: Jean-Yves Avenard
---
libavformat/movenc.c | 28
Hi.
Only going to reply to some of the misinformation provided in the post
from Reinhard Tartler
(https://lists.debian.org/debian-devel/2014/08/msg00160.html)
For the background: I am the de-facto maintainer of the MythTV's FFmpeg fork.
> To the best of my knowledge, there are only two high-pro
Hi
On 9 August 2014 11:57, wm4 wrote:
> On Sat, 9 Aug 2014 11:46:40 +1000
> Off-topic, but: it might be easier nowadays?
>
> The strangest things that are not even related to video decoding are
> getting merged - surely it's possible to merge things such as teletext.
In all honesty, we spent mon
On 9 August 2014 17:03, Matthias Urlichs wrote:
> Most forks cause additional work which, in the long term, is better spent
> elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal
> world, you wouldn't need the mythtv fork either.
>
> Debian's position is that we _really_ want to
Hi
On 10 August 2014 17:01, Matthias Urlichs wrote:
> Hi,
>
>
> IMHO it's reasonable to expect core APIs to be upwards-compatible and keep
> deprecated interfaces around for another release or two.
>
Then it becomes unreasonable for a piece of software to be compatible
with multiple version of t
On 10 August 2014 18:53, Andrew Kelley wrote:
> IMO it's not worth the effort to support multiple versions of the same
> library. If you want to use an old library, use an old version of the
> software.
In our case, we have very long release cycles. Usually only once a
year at best. We have users
On 18 August 2014 23:15, Andreas Cadhalpun
wrote:
> Why is FFmpeg treated differently than MariaDB/PerconaDB?
>
That's a very good question really.
But reading some of the comments in regards to having a nay for
including project that duplicate code, my guess is that it's a totally
irrational d
Hi
This is a discussion you guys may already have discussed about this, I
apologise in advance if that is the case (and thank you for pointing
me to it if that's the case).
I work for Mozilla, in the media playback team of gecko.
In Firefox, we've finally moved to use ffvp9 and ffvp8 in place of
On 8 January 2016 at 20:28, wm4 wrote:
> Do I understand right that only your tests do this? And that there are
> no real world sites which do this? And that you want us to change our
> architecture so that your tests actually run?
I thought I had explained the problem in rather plain words easy
On 8 January 2016 at 20:42, Carl Eugen Hoyos wrote:
> I may have misunderstood myself but I believe the
> issue actually only happens on Windows XP;-)
>
> Carl Eugen
Well the issue is mostly important on 32 bits system, particularly on
windows where a user process can only use up to 2GB of RAM.
On 8 January 2016 at 20:51, wm4 wrote:
> Anyway, as another point I would argue:
> - discouraging web devs from creating too many video elements, and
> introducing a static "reasonable" limit (maybe a dozen elements)
You're kidding right? So what, you just don't display the video
because really
On 8 January 2016 at 21:35, Andrey Turkin wrote:
> example. I ended up disabling MT everywhere I can to fix that (which was a
> right thing to do anyway since my program was already multithreaded and it
> could use all the cores anyway). This thread-pool idea sounds reasonable to
> me; more reason
On 8 January 2016 at 23:24, wm4 wrote:
>
> A global thread pool sounds like an extremely messy and unclean
> solution. The state of a library is not supposed to affect anything
> else in the same process.
The point of my message was to start a discussion, not to receive
immediate answer ridiculin
On 8 January 2016 at 23:27, wm4 wrote:
> Then don't create 30 threads.
This was just a silly example...
There are time when you do want to use multiple threads, because
someone is playing a single high-def video and a single thread
wouldn't cut it.
The conditions could change dynamically too:
Sa
On 8 January 2016 at 23:43, wm4 wrote:
> Sorry, the problem you're trying to solve is just too ridiculous.
Welcome to the world wide web ! :)
> Threads might be the heaviest resource here, but no matter what you do,
> having hundreds of objects active at the same time (bring back geocity
> websi
On 9 January 2016 at 00:39, Derek Buitenhuis wrote:
> This seems to be a rather contentious subject. Would you be amenable to
> perhaps joining #ffmpeg-devel to discuss in real time? In my experience,
> stuff gets cleared up a lot faster, and with few misunderstandings / large
> mailing list flame
On 9 January 2016 at 01:22, compn wrote:
> i think mozilla should share one test page with the hundred elements so
> that we can see first hand the destruction.
here is a simple one:
http://people.mozilla.org/~cpearce/stress/
For our test page:
http://hg.mozilla.org/mozilla-central/raw-file/tip
On 9 January 2016 at 01:37, Derek Buitenhuis wrote:
> On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote:
>> I will come on Monday if that's okay... could setup a time that works
>> for you. I'm based in Melbourne Australia
>
> Most of the channel is usually around during
On 15 January 2016 at 18:51, wm4 wrote:
> API users might check for the existence of such pixfmts with #ifdef,
> and I don't understand the reasoning behind your patch. Why would
> external projects redefine these macros?
All other pixfmts are already enums, why the discrepency ?
Having everythin
25 matches
Mail list logo
