> So whether or not you agree with the current licensing structure, if you>
>want to use ffmpeg components you have to play by those rules.
Well, of course, but that's not really my concern: it's more that even if you
were playing by the rules, it might actually be quite difficult to prove
As has been said, it would be essentially impossible to track down everyone
who's contributed to a project the size of ffmpeg and gain permission of each
to alter the licence, so the discussion is effectively moot. Another reason
it's moot is that open source is effectively a religion to a lot
Does anyone else have any idea what Paul's even talking about, at this point?
P
On Tuesday, 7 November 2023 at 18:41:55 GMT, Paul B Mahol
wrote:
On Tue, Nov 7, 2023 at 6:58 PM Carl Zwanzig wrote:
> On 11/7/2023 10:05 AM, Paul B Mahol wrote:
> > Documentation is there and its 99.99%
On Tuesday, 7 November 2023 at 17:28:58 GMT, Paul B Mahol
wrote:
> You are deeply confused, and make assumptions from no knowledge and from no>
> actual facts at all.
Oh, okay - are you telling us the options I listed aren't part of ffmpeg?
They're all listed in the documentation, on pages
So let me get this straight.
There's a command line option called colorspace.
There's a filter called colorspace which has options including "space," "trc"
(meaning "transfer characteristics") and "primaries," as well as several other
options which do not actually have anything to do with
I don't think you need to do this for a second - what's on the disc will be
709. That's how blu-rays work, unless they're the oddball Sony 4K thing.
The whole purpose of colour grading is to put whatever comes off the film
scanner into 709.
P
On Tuesday, 7 November 2023 at 12:04:34 GMT, Rob
On Tuesday, 7 November 2023 at 11:48:24 GMT,
wrote:
> I think it sets the color tags on the _input_
I'm not so sure, it specifically says "marks interlace and color range for the
output frames."
It then goes on to imply the filter does a bit more than set just interlacing
and colour range
y, 7 November 2023 at 10:52:53 GMT, Paul B Mahol
wrote:
On Tue, Nov 7, 2023 at 11:40 AM Phil Rhodes via ffmpeg-user <
ffmpeg-user@ffmpeg.org> wrote:
>
>
> On Tuesday, 7 November 2023 at 10:30:33 GMT, Paul B Mahol <
> one...@gmail.com> wrote:
> > Use setpara
On Tuesday, 7 November 2023 at 10:30:33 GMT, Paul B Mahol
wrote:
> Use setparams filter to properly tag inputs colorspace related metadata.
Y'know, I've been dealing with this stuff for twenty-plus years, and I'm not
very clear on exactly what you're trying to suggest Mark does here.
I have no idea how colour handling in x265 works so I can't really advise on
specifically how to set it up. Possibly it's documented somewhere. One of the
problems with this (which comes up in some high end post production software
quite often) is that it's sometimes not very clear whether
A number of potentially complex interactions govern what's going on here.
FFmpeg has never been particularly smart about how it interprets colour and
brightness encoding, and it is not very well documented in that regard, but to
be fair, files are not always (or even often) marked correctly
> We removed cinepak encoder and decoder long time ago.
Boo! Vector compression is beautiful!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email
Did they remove the Cinepak encoder?
It was slow, but it was great for simulating bad old codecs for creative
purposes.
P
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link
> is there a good reason to throw a video file through ffmpeg when you> don't
>want to touch it?
I guess you might want to touch the audio but not the video, maybe?
In general, I suspect the reason it's not easy to implement the requested
feature is that it isn't often trivial, or even
Hi,
I have no information on how Lepton actually works, but it's presumably making
use of redundancy inherent to JPEG which make it possible for lossless
compression to reduce their size so dramatically. JPEG is a very old standard,
developed at a time of very limited computer resources, and
Hi Natalia
This gets complicated, but in general it depends on the compression settings.
"libx265" is capable of doing many different things. It's probably best if you
look up some examples of how that works because it's too much to explain here,
and examples will help.
Also, it depends what
Hello;
I would advocate a light touch. Frankly, the rules have not been meaningfully
enforced here for years - more than a decade, in my experience. As such, list
users might very reasonably work on the assumption that they never would be,
and it may not be entirely fair to reproach people for
Hi Dan and all.
Much as I agree with most of what you've said, I've never once seen anyone
enforce any rules on this mailing list - it's possibly happening without public
announcement, but there's certainly no sign of it. I've been a member here for
more than a decade and I still have no idea
A word of sanity.
If you're someone new to the ffmpeg-user list who's reading this thread and
frowning with concern at Reindl's behaviour, believe me, you're not alone. I've
never met him nor anyone who has met him, but I have occasionally met groups of
people who are familiar with his
> 2) to add filler material (writing and other places) "let's pad that out
> to10 minutes"> 3) an electronic contact surface ""solder the red wire to pad
> #2"
> ...
> In the case of ffmpeg _filters_, it looks like #3 is closest as a point of>
> interconnection but #2 could apply to 'pad'
"Pad" in audio engineering usually means "to attenuate."
"Pad that down a bit," meaning "reduce the volume."
P
On Thursday, 27 October 2022 at 21:18:46 BST, Michael Koch
wrote:
Am 27.10.2022 um 21:57 schrieb Clay via ffmpeg-user:
> Dumb ffmpeg question alert:
>
> What is a "pad" in the
I suppose there's a couple of other things to be said about raw video, or in
fact any less-complex codec.
First, it requires less CPU time to play it back. If for some reason you're
storage-rich but CPU poor in some very specific application, especially some
piece of embedded electronics where
Producing objective metrics of the performance of video codecs is notoriously
difficult. Or at least it isn't - given enough access, you can calculate a
signal-to-noise ratio through the codec, but that sometimes doesn't do a very
good job. Wavelet codecs are sort of notorious for producing
> I did NOT, I repeat, NOT write the message below.
I had that happen last week, in the thread titled "Re: [FFmpeg-user] asubboost
and asupercut"
> On Sun, Nov 29, 2020 at 6:07 PM Phil Rhodes via ffmpeg-user
> wrote:
...no, he didn't.
P
On Friday, 8 July 2022 at
> On Saturday, 16 April 2022, 21:50:32 BST, Christian David
wrote:
> FFMPEG only supports open codecs.. i also miss the NDI codec, but what can
> we do?
Well, theoretically, this is supposed to be open source, and we could write our
own and have it included, but...
...back in reality
Apropos of nothing, and it might just be me, but it seems to me that MXF has
not been entirely a success as a file format.
P
On Wednesday, 13 April 2022, 09:10:34 BST, Bouke / Videotoolshed
wrote:
On 12 Apr 2022, at 21:24, Paul B Mahol wrote:
>
>> do cause an error on the Avid side
> On 2022-02-08 00:19, Paul B Mahol wrote:
> Your "nice" words will not help you gain any credibility here, instead it
> will just make users leave list.
At some point I start to question whether some people on this list are speaking
some private, special language that looks like English but in
In an attempt to actually help solve the problem:
Most Windows machines have, for a long time, had the commandline Javascript
interpreter cscript.exe which I tend to bust out for moments like this, when
batch files become a bit miserable. A lot of people have at least touched
Javascript, given
I'll confirm what other people have said - this is basically a conversation
which has been continuing on this mailing list for years, even decades.
I don't know what's really behind it - I've often wondered whether there's
neurodevelopmental disorders at play, whether it's a language problem,
I tried to do something a bit like this some years ago for audio only. Don't
ask me for the details as it's been a while, but we tried several solutions and
never really got it to work. This was under Windows.
The idea was to create a wireless free space link using off the shelf wifi gear.
P
On Thursday, 30 December 2021, 14:06:15 GMT, Bouke / edit 'B
wrote: >> On 30 Dec 2021, at 14:58, Reindl Harald
wrote:
>>
>> it's amazing that you
> Hey Harald,
> Are you allright? You almost sound polite!
Quick, mark it on the calendar!
I must reinforce Carl's interpretation here.
To define the problem more formally, timestamps are a necessary and perfectly
reasonable approach to timing video playback in a variable frame rate
environment. They're not a particularly good way of looking up specific images
in a sequence in a
I had this problem running it under C# once. I can't remember what the
solution was, but I seem to recall that it was something to do with the fact
that ffmpeg writes most of its status information not to standard output, but
to standard error, presumably so as to keep standard output free for
It's very difficult to figure out with any accuracy because codecs aren't
really testable outside the application that's using them, but my impression is
that the ffmpeg prores encoder - while very helpful and a massive timesaver -
is fairly CPU-hungry compared to the commercial options.
P
> a TBC on the playback deck output
Did anyone ever write a TBC filter in software?
It might be a bit dependent on picture content, but it strikes me it ought to
be possible to do something that would match up the horizontal position of rows
of pixels by minimising contrast between adjacent
> I believe that Nicolas is correct, Phil. I know that 24pps cinema is encoded
>at 24000/1001fps and> therefore running time is extended by about 0.4%.
Lots of cinema stuff is or at least was shot at 23.976, or at least that's the
way the frame rate is often labelled in the cameras.
The reason
, 23:19:28 BST, Nicolas George
wrote:
Phil Rhodes via ffmpeg-user (12021-03-29):
> Are you contending that there is no such thing as video at 24000/1001 fps?
Are you capable of understanding a simple phrase made of less ten words?
--
Nicolas Geo
Are you contending that there is no such thing as video at 24000/1001 fps?
On Monday, 29 March 2021, 22:08:03 BST, Nicolas George
wrote:
Phil Rhodes via ffmpeg-user (12021-03-29):
> What?
I have nothing to add to what I have written. Get a clue.
--
Nicolas Geo
On Monday, 29 March 2021, 19:03:43 BST, Nicolas George wrote:
Phil Rhodes via ffmpeg-user (12021-03-29):
>> For the sake of being really rigorously correct, yes, 24.0 or 24000/1001.
> Once again, you are wrong. The 1000/1001 factor is an artifact of color TV.
What?
24-frame
On Monday, 29 March 2021, 18:05:00 BST, Carl Zwanzig
wrote:
> Please be careful with the words- "movies" (made for theatrical release) are
> filmed at 24.0 fps.
For the sake of being really rigorously correct, yes, 24.0 or 24000/1001.
Makes very little difference to the current
One of the other issues with this is that nobody ever seems to bother
enforcing any rule whatsoever on this list in any case, so I view the entire
discussion as pointless.
P
On Tuesday, 9 March 2021, 20:08:09 GMT, Carl Zwanzig
wrote:
On 3/9/2021 11:52 AM, Jim DeLaHunt wrote:
> Yes,
I hit this once some time ago when creating an application which was intended
to assign start timecodes to recorded video files and for which we needed a
frame-accurate count. In that case the files were AVIs, which theoretically may
have a header including a frame count, but in practice we
Email.
‐‐‐ Original Message ‐‐‐
On Thursday, 4 March 2021 17:01, Phil Rhodes via ffmpeg-user
wrote:
> Hi Laura
> OK.
> Ordinarily I'd say unless the filenames literally contain your home address
> and phone number, don't obfuscate them, because that's exactly the sort of
>
Hi Laura
OK.
Ordinarily I'd say unless the filenames literally contain your home address and
phone number, don't obfuscate them, because that's exactly the sort of place
the wet can get in.
Still, in this case it does look like it's seeing the input audio and then
writing about 4.5MB of audio
Hi there
Can I suggest you post for us the actual commandline that ends up getting
executed, and the output from ffmpeg, at least until it gets down to the
serious number crunching? The problem may be in the way the command is being
assembled.
P
On Thursday, 4 March 2021, 16:18:15 GMT,
On Saturday, 27 February 2021, 22:41:36 GMT, Carl Zwanzig
wrote:
> Other countries may be different, but in the US saying "you will be sued">
> can be considered a threat of imminent suit; saying "you may be sued" is>
> only informational.
Quite.
Also, I suspect most people are
On Saturday, 27 February 2021, 01:27:22 GMT, Mark Filipak (ffmpeg)
wrote:
> No, it has a constant frame rate of 30/1.001 frames/second.
I'm not really following this, but one question which may be worth asking is
where did you get this file, and what is its provenance?
The reason I
On Monday, 15 February 2021, 13:58:30 GMT, Michael Koch
wrote:
> A few developers (not all!)
> are actively fighting against any changes in the documentation. It seems>
> they are really convinced that the documentation is perfect as it is.
Agreed. I think it's an extension of a situation
On Monday, 15 February 2021, 11:39:05 GMT, Chris Angelico
wrote:
> > and then 'frame' would be a pointer to an in-memory structure of that
> > type. When you refer to 'frame->pts', that means 'look at the spot in
> > memory three words in from where frame points, and assign to that'.
>
How does all this interact with files from cameras with very stable timing,
such as broadcast and cinema cameras?
Is there not a risk of long-term rounding errors?
P
On Monday, 15 February 2021, 01:13:37 GMT, Paul B Mahol
wrote:
On Mon, Feb 15, 2021 at 1:46 AM Mark Filipak (ffmpeg)
On Friday, 5 February 2021, 20:00:27 GMT, Mark Filipak (ffmpeg)
wrote:
>> Can ffmpeg interface/use SVPflow?
>
> Please read a little about OpenSource software and
> please understand that OpenSource has nothing to
> do with "no payment" or whatever you may be thinking
> of.
>
> Carl
On Tuesday, 2 February 2021, 20:29:44 GMT, Michael Koch
wrote:
> In my opinion, it would be best to have all documentation in a wiki.
I think that's probably a good idea. For something the size and complexity of
ffmpeg, trying to embed the documentation into the executable is crazy.
>
On Tuesday, 2 February 2021, 10:17:11 GMT, Reindl Harald
wrote:
(snip)
Well, you just keep telling yourself all that, and we'll keep admiring the
fantastic documentation ffmpeg has. Obviously, it's a brilliant endorsement of
whatever your approach is.
You have people offering to do free
On Tuesday, 2 February 2021, 10:04:44 GMT, Reindl Harald
wrote:
> sorry but in most cases when someone comes up with word/excel files> instead
> of pure plaintext things only become worser and that will not> change in 100
> years
I'm going to assume from that you've never worked on
On Tuesday, 2 February 2021, 06:30:35 GMT, Reindl Harald
wrote:
> muhahaha - a word document is how writers work?
Yeah. I mean, think about it - how else are you going to track changes in a
document?
I guess you could improvise some sort of solution by, I don't know, sending
each
On Monday, 1 February 2021, 23:36:19 GMT, Jim DeLaHunt
wrote:
> In many projects, "instead of complaining, submit a patch" is good
> advice. It turns users into contributors. But FFmpeg is not just any> project.
Quite. Knowing what I know, I'd sooner eat catfood than submit changes to
On Sunday, 31 January 2021, 13:24:39 GMT, Rodney Baker
wrote:
> See man ffmpeg for detailed description of the options... > try typing "man
> ffmpeg" into a google search and see what comes up... >
> http://manpages.org/ffmpeg...> Look for the section titled "Generic Options".
> > There
On Saturday, 30 January 2021, 08:24:10 GMT, Moritz Barsnick
wrote:
> Please don't throw dirt around here. Carl Eugen is trying to help.
I think it's worth being clear that it sometimes isn't very easy to tell
whether Carl Eugen is trying to help.
P
>You can technically, but minterpolate is not very user friendly - It's too>
>slow for real work and feedback, and you cannot keyframe the settings on>
>different scenes very easily. It's barely usable unless you program your own>
>GUI around libavfilter
Yes - this is somewhere that
On Friday, 29 January 2021, 09:43:09 GMT, Mark Filipak (ffmpeg)
wrote:
> Try 'ffmpeg -h type=filter.
> It fails. Why? Because "filter" is a "type", not a "name" -- never mind that
> the details says "...
> named decoder/encoder ..."
Yes, this is the sort of thing that causes the
> I didn't know I could get help on individual filters.
To be completely fair, that is actually in the docs, but it's not exactly on
the front page.
P
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user
On Wednesday, 27 January 2021, 10:31:35 GMT, Paul B Mahol
wrote:
> ffmpeg -h filter=minterpolate
Y'know, I've been using ffmpeg for a really long time, and I had no idea you
could do that.
P
___
ffmpeg-user mailing list
On Tuesday, 26 January 2021, 19:10:38 GMT, Chris Angelico
wrote:
> Do you realise how toxic you make the FFMPEG community look?
To answer your last point first, either they don't know how toxic it looks, or
they don't care. It's been like this for so long that if it's an elaborate
trolling
On Monday, 25 January 2021, 22:34:35 GMT, Mark Filipak (ffmpeg)
wrote:
> Your comments, Leo, are quite correct. However, there is no F*ing Manual.
> There is only man-style
> documentation that supplies usage reminders to those who are already familiar
> with ffmpeg and its > usage, but
On Monday, 25 January 2021, 14:41:36 GMT, Paul B Mahol
wrote:
> You are very ignorant of mentioned demuxer options in documentation.
You've got to be kidding.
Paul, you are coming off as unbelievably unpleasant. Again, I'm trying to help
you. Please, please, moderate your tone.
P
-devel/2016-June/195315.html
So I guess that's OK then!
P
On Sunday, 24 January 2021, 00:49:32 GMT, Bouke wrote:
> On 24 Jan 2021, at 01:42, Phil Rhodes via ffmpeg-user
> wrote:
>
> Happened to me in August 2011.
> http://mplayerhq.hu/pipermail/ffmpeg-user/2011-August.tx
Happened to me in August 2011.
http://mplayerhq.hu/pipermail/ffmpeg-user/2011-August.txt
P
On Sunday, 24 January 2021, 00:26:50 GMT, Bouke wrote:
> On 23 Jan 2021, at 19:21, Phil Rhodes via ffmpeg-user
> wrote:
>
> Carl Eugen has threatened
When?
Proof or it di
> I see that if I use
> the Colours -> Components -> Channel Mixer tool and supplement the blue>
>channel (1.0) with the green channel (1.0) https://i.imgur.com/Q0qqgSP.png>
>the result is desaturated but usable https://i.imgur.com/t19QU4U.png
I'd be a little cautious about this; have you tried
>> I am not the moderator of any mailing list.
> I beg your pardon, Carl Eugen. What is your functional title?
Good question. Carl Eugen has threatened to have people banned, which I would
call the behaviour of a moderator. You would be forgiven for assuming he was.
One of the problems with the
On Sunday, 6 December 2020, 10:41:57 GMT, Reindl Harald
wrote:
> In 2020 you have containers, virtualization and WSL
You possibly do, but good grief, it's a pain in the arse compared to just, you
know, running a native binary.
P
___
Hi folks
Just to throw a further spanner in the works, this may be well known, but it's
worth saying anyway.
There's a pretty large difference between compiling "ffmpeg" and the "ffmpeg"
that you will get from, say, a website that offers a binary.
The very basic core of ffmpeg is probably not
I think it's worth asking a simple question, here. Who's actually in charge of
this mailing list - who has the authority to enforce the code of conduct? Who
actually owns any of this stuff?
It's never been clear.
P
On Wednesday, 2 December 2020, 09:34:30 GMT, Simon Brown
wrote:
>
On Tuesday, 1 December 2020, 20:05:29 GMT, Dave Stevens
wrote:
> can this be taken off-list? nobody needs to hear this
Actually I think exactly the opposite; it's long past due that the terrible
conduct of a few list members here was given a public airing, for the benefit
of everyone,
On Tuesday, 1 December 2020, 19:56:39 GMT, Chris Angelico
wrote:
> I'm not really a member of this community but you're really standing out here.
I know how you feel. We've got a few of them, on this list.
The ffmpeg user list has always been a place which more or less defines the
worst
On Sunday, 29 November 2020, 15:55:29 GMT, Michael Koch
wrote:
> The name "feedback" is misleading because this signal isn't going back.> It
> would make sense to rename "feedback" to "wet".> What's now "wet" could be
> renamed "gain", or it could be removed because > it's
On Saturday, 28 November 2020, 15:49:09 GMT, Simon Roberts
wrote:
> So... the term "field" isn't used to describe one half of an interlaced>
> frame? 'coz I have devices that claim to output progressive and interlaced>
> as a choice, and they're not CRTs..
This is a somewhat vexed
On Sunday, 22 November 2020, 10:37:29 GMT, Paul B Mahol
wrote:
> There is a solution, but I gave up teaching unteachable.
I'm torn between knowing that there's almost no meaningful way to respond to
this, and feeling that Mahol's continued, completely unnecessary unpleasantness
must
Hi Steve and all
This is the second time in as many days that I've had to apologise for the
behaviour of people on this mailing list, although I have no standing here
other than having been here a long time, and having seen it a lot.
As I said in a message yesterday, this level of spite and
On Monday, 2 November 2020, 10:33:21 GMT, Reindl Harald
wrote:
> lack of common sense... stupid... LAZYNESS and IMPUDENCE... wasting others
> time
Linus! Is that you?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
Hi Marc
I can only reiterate the regrets you've already received and assure you it was
ever thus and it's not your fault.
For the benefit of any new people or anyone who reads this thread in future,
ffmpeg is for every practical purpose a Linux-community project. The Linux
community is
I don't know who's in charge of this glossary project, but can I please
propose something on the difference between colourspace, subsampling and
luminance encoding. And all the other things people constantly confuse.
P
___
ffmpeg-user mailing list
Anyone got any idea why?
This could be a pretty significant pain.
P
On Wednesday, 2 September 2020, 19:56:45 BST, Vincent Torri
wrote:
Hello
On Wed, Sep 2, 2020 at 8:29 PM Michael Koch wrote:
>
> "ffmpeg.zeranoe.com will close on Sep 18, 2020, and all builds will be
> removed."
>
>
the help.
P
On Tuesday, 1 September 2020, 10:15:01 BST, Paul B Mahol
wrote:
On 9/1/20, Phil Rhodes via ffmpeg-user wrote:
> I've seen both ap10 and apl0 in the wild, presumably based on exactly the
> same misreading of indistinct fonts, but it doesn't seem to matter
I've seen both ap10 and apl0 in the wild, presumably based on exactly the same
misreading of indistinct fonts, but it doesn't seem to matter anyway.
And if it is in the documentation, you are recommending it.
P
On Tuesday, 1 September 2020, 09:26:27 BST, Paul B Mahol
wrote:
On 9/1/20,
On Sunday, 30 August 2020, 23:21:16 BST, Edward Park
wrote:
> I'm not sure what you are referring to, what's there to spread fud about??
I'm not sure what he's referring to, either, but just be aware you're talking
mainly to software engineers here and they have a well-deserved
On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol wrote:
>
>http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.h;hb=HEAD
>
>http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb=HEAD
>
The ProRes implementation is not likely to be perfect in terms of Apple's
internal spec. They do not publish the spec so we don't know. In general, it
has been shown to be reasonably reliable when used with most software decoders.
It has had problems in the past (I haven't checked for years)
On Monday, 24 August 2020, 19:28:11 BST, Jim DeLaHunt
wrote:
> agree about the value of narrative descriptions. For instance, in
> reading the DirectShow "How to Play a File" article, I think of how very >
> helpful it would be to have a narrative description of "How FFmpeg calls >
On Sunday, 23 August 2020, 21:27:17 BST, Carl Zwanzig wrote:
> I think we'll have to disagree on that, most of the basic logic should be >
> fairly clear to someone who knows the 'c' language.
That tends to be true for, say, one function, or a few functions. And sure, OK,
if you want to
One of the things about man pages is that users invariably lack the man
command under windows, and you don't get the man pages with most windows builds
of ffmpeg anyway.
The executable emits messages about man pages, which I've always viewed as
practically a bug on Windows builds which will
On Friday, 21 August 2020, 15:01:00 BST, Michael Koch
wrote:
> I'm also ready to help, if it can be done without git.
I feel much the same way.
P
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
> Re pointers- consider them an assembly language address.
The concept is simple enough; I always thought that the C syntax for them was
unnecessarily opaque.
P
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
On Friday, 21 August 2020, 08:49:13 BST, Jim DeLaHunt
wrote:
> I believe a lot of the FFmpeg developers do read this list.
Yes, and I think they hold this sort of discussion in nothing but complete
scorn.
> We are holding a mirror up to the project, and inviting them to take a look.
I don't
People;
This is not a new issue and I'm really rather tired of hearing it discussed.
The open source software movement is notorious for creating an absolutely
horrible user experience and one of the reasons that happens is because of poor
or effectively nonexistent manuals.
Most of the people
> Your both theories are fully correct. They want to make money for living.
That's perfectly fine, but at least admit it, and stop trying to defend the
indefensible (and then claim it's all about open source egalitarianism, when it
emphatically isn't.)
For what it's worth this has been obvious
it somehow produces technical
rigour.
P
On Monday, 17 August 2020, 16:12:37 BST, Reindl Harald
wrote:
Am 17.08.20 um 16:47 schrieb Eduardo Alarcón:
> El lun., 17 ago. 2020 a las 7:19, Reindl Harald ()
> escribió:
>
>> Am 17.08.20 um 10:53 schrieb Phil Rhodes
For christ's sake.
People, be polite. Harald, you are incredibly impolite. This is a user list. It
is reasonable for people to ask basic questions here. Your assumption that
everyone is an expert is unreasonable.
P
On Monday, 17 August 2020, 07:24:33 BST, Reindl Harald
wrote:
Am
> AFAICT, no video tool has solved this without running the entire stream. You
>might take one approach for fixed-rate containers/encodings and another for
variable-rate.
It might be worth adding that there is a frame-count field available in several
container formats, but it is very rarely
A long time ago I hit this and as far as I was then able to tell, there is not
a lightweight way to get the precise number of frames in a video file. I seem
to recall (don't ask me how) there was a way to effectively have it "play" the
file, to parse the container, without actually doing the
From what I've seen, it is functionally an expansion on 265 in the same way
that 265 was an expansion on 264.
And yes, the same political problems attend it that also attended 265, and no
real effort has been made to solve those problems.
As such it's probably irrelevant how good it is because
1 - 100 of 113 matches
Mail list logo
