Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
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-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
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. > You answered: "The issue can be reproduced with any codec." The issue can be reproduced with every codec. That is, every mp4 file with an audio sampling rate greater than INT16_MAX will have 0 for the sample_rate value. This will prevent those generated files to be played in Firefox for example. A sampling rate of 0 being treated as invalid. This is why I answered that the problem could be reproduce with any codecs. It is a problem with all audio codec when used with FFmpeg generated mp4. However, only the flac-in-isobmff defines on what to do. If we were to generalize the fix to other codec, then those files wouldn't be spec compliant either (though it's my belief it would be better if it were). > > So why does your patch only fix the issue for flac? > Or do I misunderstand? Only the flac-in-isobmff clearly states what to do under those circumstances. For the other format, there's no specific documentation on what should be done for how to store sampling rate value greater than 16 bits. ISOBMFF spec itself define an AudioSampleEntryV1 box instead which has the sampling rate store on 32 bits instead. FFmpeg doesn't support AudioSampleEntryV1 So the special fix for flac is one poor man's attempt to make things better without having to implement a much more complex fix. (That and few players supports AudioSampleEntryV1 either) Hope this help clarify the problem at hand better. Sorry if I didn't make things clearer earlier. JY ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Invalid behaviour of av_parser_parse2 with some content
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 upon av_parser_parse2 returning. However, looking at the code of some parser, such as the vp8 decoder: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/vp8_parser.c;h=609f5077d1a1b2add1dd3e13f0508615428dafa0;hb=HEAD#l30 we can see that the vp8 parser will do return buf_size immediately under some circumstances (such as the size being to small, the sync code being invalid and so forth... but when doing so doesn't set the two out parameters. I believe this is a bug Either the documentation needs fixing, or the two out parameters needs to be set to poutbuf and poutbuf_size respectively as all data is to be consumed. An alternative would be to set them both to 0 if content is invalid (or too small) and as such we don't want the parser to output anything. Thanks JY ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
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 how sampling rate is to be stored should it be
greater than INT16_MAX is a FLAC in ISOBMFF requirement:
https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt;h=574df9f54a779fca2e62c726703fc7be199d4c05;hb=refs/heads/master#l165
It definitely could be applied to other codecs, but I haven't seen
such requirements clearly defined.
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)
JY
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
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 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 10b959ad02..aa4a9c962a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
*s, AVIOContext *pb, MOVMuxContex
avio_wb16(pb, 0); /* packet size (= 0) */
if (track->par->codec_id == AV_CODEC_ID_OPUS)
avio_wb16(pb, 48000);
-else
-avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
- track->par->sample_rate : 0);
+else {
+uint32_t rate;
+if (track->par->codec_id == AV_CODEC_ID_FLAC) {
+/* When the bitstream's native sample rate is greater
+ than the maximum expressible value of 65535 Hz,
+ the samplerate field shall hold the greatest
+ expressible regular division of that rate. I.e.
+ the samplerate field shall hold 48000.0 for
+ native sample rates of 96 and 192 kHz. In the
+ case of unusual sample rates which do not have
+ an expressible regular division, the maximum value
+ of 65535.0 Hz should be used. */
+rate = track->par->sample_rate;
+while (rate > UINT16_MAX && (rate & 1) == 0) {
+rate = rate >> 1;
+}
+if (rate > UINT16_MAX) {
+rate = UINT16_MAX;
+}
+} else {
+rate = track->par->sample_rate <= UINT16_MAX ?
+ track->par->sample_rate : 0;
+}
+avio_wb16(pb, rate);
+}
avio_wb16(pb, 0); /* Reserved */
}
--
2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Properly store sampling rate for FLAC in mp4
Note that that it's also not correct for other codecs when the
sampling rate is greater than 65536. Right now it stores 0.
If in quicktime mode, it could use a SoundDescription v2 box, but in
mp4 that doesn't exist.
Per ISO 14496-12 , it should be using a AudioSampleEntryV1 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 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 +---
> 1 file changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 10b959ad02..aa4a9c962a 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -1028,9 +1028,31 @@ static int mov_write_audio_tag(AVFormatContext
> *s, AVIOContext *pb, MOVMuxContex
> avio_wb16(pb, 0); /* packet size (= 0) */
> if (track->par->codec_id == AV_CODEC_ID_OPUS)
> avio_wb16(pb, 48000);
> -else
> -avio_wb16(pb, track->par->sample_rate <= UINT16_MAX ?
> - track->par->sample_rate : 0);
> +else {
> +uint32_t rate;
> +if (track->par->codec_id == AV_CODEC_ID_FLAC) {
> +/* When the bitstream's native sample rate is greater
> + than the maximum expressible value of 65535 Hz,
> + the samplerate field shall hold the greatest
> + expressible regular division of that rate. I.e.
> + the samplerate field shall hold 48000.0 for
> + native sample rates of 96 and 192 kHz. In the
> + case of unusual sample rates which do not have
> + an expressible regular division, the maximum value
> + of 65535.0 Hz should be used. */
> +rate = track->par->sample_rate;
> +while (rate > UINT16_MAX && (rate & 1) == 0) {
> +rate = rate >> 1;
> +}
> +if (rate > UINT16_MAX) {
> +rate = UINT16_MAX;
> +}
> +} else {
> +rate = track->par->sample_rate <= UINT16_MAX ?
> + track->par->sample_rate : 0;
> +}
> +avio_wb16(pb, rate);
> +}
> avio_wb16(pb, 0); /* Reserved */
> }
>
> --
> 2.11.0 (Apple Git-81)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: fix data race in av_get_cpu_flags().
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 new gmail app, not allowing me to reply inline. I can only top post. Jean-Yves Le jeu. 24 nov. 2016 à 06:47, Wan-Teh Chang a écrit : > On Tue, Nov 22, 2016 at 3:30 PM, wm4 wrote: > > On Tue, 22 Nov 2016 23:57:15 +0100 > > Michael Niedermayer wrote: > > > >> For example the progress code in the frame threading. > > > > Which was recently fixed in Libav AFAIR... > > You're right. libav/libavcodec/pthread_frame.c has code similar to my > ffmpeg patch > http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/190454.html, > and much more. > > Note: libav/libavcodec/pthread_frame.c uses unnecessary (too strong) > memory barriers in ff_thread_report_progress(). We can fix those when > the code is merged to ffmpeg. > > Wan-Teh Chang > ___ > 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] define AVPixelFormat aliases as enumerators instead of macros
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 everything an enum seems much cleaner to me IMHO. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 daytime GMT/CET hours. > Happy to discuss this on IRC. My nickname is jya. I also typically hang in the #media mozilla channel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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/layout/reftests/webm-video/object-fit-contain-webm-001.html it contains 21 tiny videos, but when displayed very quickly with all the ones found in http://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-video, you easily reach > 100 videos. > > does this also happen with webp ? e.g. if all images are vp8 webp and if > you used libavcodec to decode them? we don't support webp, but it would be unlikely as we only need the decoder once to get the image. After that it can be shutdown. > > because 100 images would be a real world test, and it would explain why > this is needed. > > i've seen html pages with 100 videos, thats just a forum with a music > thread where people post youtube music videos. set forum to display 100 > posts at a time and thats easily 100 video elements on one page, > although of course not playing at the same time. they are indeed very common. Even more so in China. Lots of shiny, moving web sites there with animated smileys, buttons you name it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 flames/threads, for subjects like these, in such a setting. > That's just my 2 cents of course. It's already Saturday here, and 1:20AM. So can't argue with much conviction :) As mentioned on #opus, be it a global pool, or a call back , or whatever context that can be shared across decoder, the end result is the same: share of resources across all decoders. I will come on Monday if that's okay... could setup a time that works for you. I'm based in Melbourne Australia ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 > websites from the 90ies?) will cause a memory and CPU resource usage > problem. So what if it fails on Windows XP. You do know that people using a web browser typically have more than one page or tab open at any given time. I have about 75 opened as I'm writing this. Of course not all of them have animated objects being displayed, but it's far from uncommon. So have 30 video elements in one page, or 1 in 30 pages, it's kind of the same issue. Ever used facebook? see how many videos or animated objects you can have in a discussion? Luckily not everyone think it's a ridiculous problem to solve and just gave up. Apple's VideoToolbox or Windows's WMF typically have a pool of surfaces and threads they share internally. I'm only suggesting that FFmpeg should consider doing the same, because it has more potential use than old fashion media player that only needed to worry about playing a single video at a time. > >> clearly haven't done much work on highly parallelised application, and >> who fail to even consider the problem. > > Maybe you're trying to argue from some sort of theoretical point of > view, but I'm thinking about practical issues, such as managing a > global thread pool. Regardless of "parallisation", for the problem at > this is also an overcomplicated and inefficient solution. Plus I didn't > even completely reject the idea of having some sort of thread pool. Have you ever used thread pools or task queue ? how could that ever be over complicated or inefficient? There are plenty of libraries providing them, heck you could use our own XPCOM to do it. As far as thread pools are concerned, it's very lightweight, far easier to use than pthreads and extremely efficient (which I could say the same for the rest of it). You feed it with runnables and it run them as best as it can (either sequentially or multiple at once if there are enough threads to service them) Please think about the problem more carefully, and reconsider. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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: Say you had a thread pool of 8 threads ; when you have a single video to play, it can make full use of the processor. Something you can't achieve if you didn't create any threads at all. Now create a new decoder, they are still sharing the same pool, so about 4 each. The point is that as your amount of decoders climb there aren't an negative effect as opposed to not creating new thread, while when the decoder count drops: improvements do kick in. The advantages are so many that I'm even surprised I have to mention it... It's so obvious. Thread pools / task queues aren't messy. It's the modern approach taken by almost all highly parallelised and efficient applications. We certainly use them a lot in gecko (and webkit too) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 ridiculing the idea and I have to say by someone who clearly haven't done much work on highly parallelised application, and who fail to even consider the problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 reasonable than 8-16 threads per codec anyway. Thank you ! :) Yeah, Win7 32 bits dies when your process attempt to open about 730 threads. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 it was a silly idea in creating such page? The world is moving from Flash to HTML5. Those web sites exist *today*, they are moving to html5 progressively (and we want to make them move to html5) > - not using MT for very small video (MT would probably make it slower > anyway) Even with one thread per decoder, it's still not enough. Even by your example, it would be silly to open 30 threads to play 30 videos when your processor is unable to handle all those thread concurrently anyway. A task queue would perform just as well with 4/30th of the RAM (assuming you created the thread pool with 4 threads). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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. But regardless of the OS or platform. Potentially having to create thousands of threads because you have lots of videos is a problem. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 to understand. But obviously not :) In FFmpeg, the default when you create a decoder is to create for *that* decoder as many threads as there are core. So on a quad-core machine, with hyper threading: that makes 8 threads. So create two decoders: 16 threads. 3 decoders: 24 threads.. I can understand that the most common use of ffmpeg is to display *one* video at a given time. I so wish it was that easy. Now, as a web browser, our use is rather nowhere as simple. Their could be hundreds of videos. You find web site setting a video to play in the background that does nothing but change colours and give an ambiance. And then you have dozens of animated icons: all made using simple video elements. Those web sites are found in the wild, it's not just an internal test page. Actually our tests are typically based on things actually found. Because noone is as good as a web developer to break things :) So yes, the current threading architecture of ffmpeg is inadequate for our use. But it's not just *our* use. And as such, I wish we could make it better. The use of global thread pool is a sane (and much better) approach regardless. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model
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 libvpx for video decoding. Should be available in Nightly shortly (ffmpeg was already used if available in 43 and later on Linux). So we now ship ffvp9 and ffvp8 in our code tree. Likely make us the biggest user of ffvp9 at once ! :) One of the issues we've faced was with our reftest tests , with pages creating hundreds of small video elements (the test change orientation, sizes, transparency and the like and check that there's no regression on how things are displayed). We originally had configured AVCodecContext::thread_count to 0, which on the machines running the tests would end up creating 8 threads per decoder. On windows 32 bits, that would amount in thousand of threads being created for that particular test which would typically fail with OOM (Windows XP would fail to create more than 1380 threads). We've worked around the problem by limiting the number of threads per decoder (the amount varies according to the video resolution) However the issue remains, in that the current way threads are used, it won't scale well. We've seen more and more web page, replacing all their tiny flash video elements with HTML5 webm or mp4 ; so the more time goes, the more it will become a problem. Rather than setting the number of threads per decoder, independently of any other decoders created ; what about using a global thread pool with task queues instead ? The thread pool could be created with a set amount of working threads, something global. When a decoder is created, rather than using N threads, it uses N task queues (all task queues sharing the same thread pool). When it needs to perform a particular operation, it would dispatch a task (of course it can dispatch multiple task at once) This would solve the problem of scalability, having hundreds of decoders live wouldn't put the system to its knee like it does now. Would this be something any of you guys would be interested in tackling ? If not and I was to work on something bringing this functionality, would it have a chance to be integrated? Thanks Jean-Yves ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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 decision ; and one that has very little technical basis at that. Also gotta love when the security breach are actually unique to Debian because some package maintainer has decided he knew better and happily broke things. SSL anyone? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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 virtually all platforms. We can't assume the OS/distribution it will be running on will have the library we're hoping for. In the perfect world, sure all platforms would all be running the same versions of a given lib at a given time... In practice it never happens. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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 the same library, and support all of those. When a used come to use complaining that something is broken, that a file doesn't play or what else. It's a moot point trying to expect them to understand that the issue is due to a 3rd party library. MythTV aimed to be an appliance-like application. You install it and you forget about it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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 avoid having multiple copies > of essentially the same code in the archive; it's additional work for the > security team (if they even know about the copies), needlessly eats memory > when the two are in use simultaneously, and causes no end of trouble when a > plug-in is linked against copy A while the main code (or another plugin) > uses copy B (unless everybody is very careful WRT symbol versioning). I beg to differ. What would be a massive amount of waste, both in time and resources, would be to have a project such as MythTV having to handle multiple versions of a dependency. Especially one such as libav* where the API changes often, and more often than not in a totally incompatible manner from one API to the next. Including rename of constants (code enums id for example). You would have to keep your own headers (like what Firefox/Mozilla is doing) and have multiple code paths only adding to the difficulty of proper coverage testing... Keeping your own static version is the only reasonable approach. As far as naming and conflicts, I don't see what the problem is unless it's improperly packaged, or for example when the packagers decide that they know better than the original authors and start to do weird thing, modify the code as they wish. That's where the issues are most of the time. Sounds familiar ? :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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 months trying to get our changes merge over the course of 10+ years... There's unfortunately a time where one gives up. This is the core reason why we started to maintain our own fork. We have now limited our changes to the bare minimum, and things have diverged greatly since. Backporting our changes to our mpegts demuxer would be significant work. And unfortunately, we are all very time constrained these days (and me even more so as I've started a new job at Mozilla) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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-profile projects > that play hardball to require FFmpeg: Mplayer and mythtv. Neither of > those do that (again to the best of my knowledge) mainly because of > technical but rather very political reasons. The case of mplayer has > been elaborated extensively in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the > following "discussion" with Reimar - my conclusion from that is while > technically possible, nobody wants to make mplayer work with Libav - > and that's why it was removed, not because of the FFmpeg dependency). > For Mythtv I can only say that they didn't even bother engaging any > discussion. MythTV has always used its own internal fork of FFmpeg. I have been involved in this project for close to a decade, and not once during that time has MythTV been using a system libav*. What political reasons are you referring to? We were syncing against FFmpeg against before their childish fight started, we continued syncing against FFmpeg after that. No more no less. One of the core developer of LibAV is Janne Grunau, who was also a MythTV developer. He stopped being an active member of MythTV due to lack of time. MythTV do not work against stock FFmpeg and never will. We run a heavily modified version of FFmpeg, you can call it a fork. In particular, we use our own mpeg-ts demuxer, we support things like MHEG, DVB/ATSC/Teletext subtitles that FFmpeg do not. We have attempted for many years to get our changes merged in FFmpeg but gave up. You say MythTV didn't bother engaging any discussions? what discussions are you referring to ? I certainly have never been contacted by either teams. What I can recall however is me submitting an issue to both FFmpeg and LibAV trac. The problem was dismissed in LibAV and fixed within a couple of days in FFmpeg. LibAV had decided to totally remove some core APIs that we make use of (in this case it was fast mpeg decoding used by our commercial detection system). FFmpeg re-introduced it at our demand. FFmpeg also have kept the old VDPAU decoding API, LibAV removed it. As such, it is easier for us to sync against FFmpeg than it is against LibAV. I call this technical reasons. there's nothing political into it. FFmpeg cherry-pick or merge any changes occurring in LibAV in a matter of days. So by syncing against FFmpeg we enjoy the best of both worlds. To end this message: I fail to see how debian's decision on which version of FFmpeg or LibAV would have any impact on MythTV, we use neither ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
