Re: [FFmpeg-user] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]

[Jim DeLaHunt]

On 2020-08-21 03:28, Nicolas George wrote:


Jim DeLaHunt (12020-08-20):

Nicolas, do you remember this?

On 2020-05-01 03:01, Nicolas George wrote [1]:

Carl Eugen Hoyos (12020-05-01):

-The desired output frame rate. The default is @code{25}.
+The output frame rate, in frames per second. May be an integer, real, or
+rational number, or an abbreviation. The default is @code{25}.

I seriously wonder who really profits from this change but it may be ok.

I would argue: lazy beginners.
…

Now that you mention, it, I remember. The fact that I did not find it
while searching my archives is caused by a misconfiguration of Git in
your end:

From: list+ffmpeg-...@jdlh.com
From: Jim DeLaHunt 


I will observe that you didn't actually review the documentation patch which
led to that thread. You just latched on to Carl Eugen's "who really profits"
comment, and complained. That patch was not my only experience submitting a
documentation improvement and having the FFmpeg project's antibodies reject
it. But it did vividly clarify for me what the project values and what it
does not.

I stand by my assessment, and reading a little more of your proposal and
your attitude in this discussion confirms that you have the wrong
attitude to both submitting patches and writing documentation.
…[snip]…



Nicholas, I do not intend to relitigate a review of my patch rewriting 
the "fps" filter documentation[1] on the ffmpeg-user list. But also, I 
think your message gives a false impression of what blocked that patch, 
and I don't want to leave that false impression unchallenged.



There are many components, filters and others, that take a frame rate
option.…The proper way to document this option is to explain the syntax of a
frame rate at a central place, along with the syntax of a video size,
the syntax of a duration, etc., and to have a link to there in the
documentation of each option using that syntax.…



I actually agree 80% with you about how to document common options like 
frame rate or PTS, in an ideal situation. They should be well documented 
in a central location. Individual filter docs should link to the common 
documentation. We might have minor differences of opinion about whether 
to briefly spell out acronyms in the filter doc as part of the link. We 
could come to some compromise on that. I will observe that present 
FFmpeg documentation is not an idea situation. There is nothing to link 
to for most of the terms in the "fps" filter doc (e.g. PTS). You 
suggested adding all those other pieces: glossary, completing frame 
rate, etc. That grows the scope of the patch, and is against the 
development policy, "Do not commit unrelated changes together" [2]. But 
we could come to a compromise about that also.


What blocked the "fps" filter doc patch boiled down to two substantive 
objections[3]: 1. objection to a 6-times difference in completeness and 
length. 2. objection to places where new doc claimed different 
functionality than old doc. My claim that old doc was wrong about what 
the code did, and new doc was correct. A few developers raised objection 
#1. One developer reviewed the doc patch and raised objection #2. As far 
as I know, neither that developer nor anyone else read the `vf_fps.c` 
code[4] to determine whether the old doc or the new doc was correct. 
And, no other developer cared to give the patch a substantive review, or 
offer a different ruling on objections #1 and #2.




And this is where we come to your approach to submitting patches: you
were told, in a very succinct way, that you were wrong. You were
expected to understand how, but you were welcome to ask clarification. I
would have explained what I just explained, and pointed that the
documentation for the syntax of a frame rate already exists:
http://ffmpeg.org/ffmpeg-all.html#Video-rate



I believe this summary misrepresents the objections that blocked the 
patch. The obstacle was not linking to #Video-rate. It was the patch's 
completeness, and correction of mistaken descriptions[3] (or excessive 
length, and misreading the vf_fps.c, for those who disagree with me). 
The lack of other developers giving a review, and lack of feedback 
saying "it would be OK with these corrections", gave me no confidence of 
clearing the objections.


Now, the ffmpeg-user list is not the place to discuss patches. If there 
is a developer who has become interested in that patch, let me know, and 
I'll take this back to ffmpeg-devel.




… But instead, you attacked.…



I disagree with your word "attack". I would say I respectfully pushed 
back. And I did not push back against feedback on the merits of the 
patch. I pushed back[5] against your condescending label of the 
documentation audience as "lazy beginners"[6].


I still think the documentation should serve the needs of FFmpeg users 
who are not digital video experts, and who haven't read the FFmpeg 
documentation from end to end. And you used the word "lazy" again just 
now. I guess we still 

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Mark Filipak]

On 08/21/2020 11:08 AM, Gyan Doshi wrote:

On 21-08-2020 07:12 pm, Mark Filipak wrote:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:

On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:
FFmpeg's documentation is very incomplete. I had a rough roadmap at the start of the year for 
plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.


May I assist you?


Sure. Do you already have a set of tasks / actions in mind?


How about this? Until we get to know each other and you gauge my capabilities, I'll research and 
document whatever's important to you. I think that initially my most important role would be as an 
editor -- mostly grammar checking. I hope to also add some user perspective and I trust that you 
will not reject what I suggest without thinking about it.


This will be a long journey during which the path will unfold before us. I can 
be patient.

My experience has been to give users many, many examples having consistent structures with faith 
that they will see the important patterns. You know, humans are reported to be very good at seeing 
patterns.


Remember a while ago when I asked folks to post working ffmpeg command lines no matter the task or 
format? My request was rebuffed, but what I was trying to do was gain experience by looking for 
patterns -- Sort of a Krell mind boost. That's all I needed and I'm convinced that's all most people 
need.


Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Latency in UDP to HLS Conversion

[KRISHNAKUMAR N K]

Hi Barsnick

Thanks for your recommendation. I have cleaned up the *Options *which were
displayed in the logs, also i verified the *-preset fast* from the debug
log level. I ran the same ffmpeg command on 2 different servers, one
with *-preset
fast* and the other one with *-preset verfast*.  There was an improvement
in latency in playback. Initially the speed was 1x, later it was reduced to
0.9xxx after a few hours. I have also reduced the* fifo_size* to *500*
[Earlier it was *1000*] and i observed "*Circular buffer overrun.
Surviving due to overrun_nonfatal option*" on 24 CPU server and NOT
observing any error on 48 CPU server.

*On CPU load:* I did not observe any load on the servers and the load is
less than 10% on both the servers [one server has 24 cpu's and the other
one with 48 cpu's]

*At Present *: I am running the same ffmpeg commands with
*fifo_size = 1000.*
*ffmpeg Command Used:*





*ffmpeg -i "udp://230.1.1.15:1?fifo_size=500_nonfatal=1
"
-analyzeduration 25M -probesize 50M -threads 0 -vsync 1 -filter_complex
"[i:0xd49]yadif[vout];[vout]split=4[out0][out1][out2][out3];[out0]setdar=16/9[v0];[out1]setdar=16/9[v1];[out2]setdar=16/9[v2];[out3]setdar=16/9[v3];[i:0xd4a]aresample=async=1:min_hard_comp=0.10:first_pts=0[aout];[aout]asplit=4[a0][a1][a2][a3]"
\-vcodec:v libx264 -s:v:0 256x144 -tune:v:0 film -r:v:0 25 -b:v:0 10
-maxrate:v:0 10 -minrate:v:0 10 -bufsize:v:0 20 -acodec:a
libfdk_aac -ar:0 48000 -b:a:0 48000 -sc_threshold 0 -pix_fmt yuv420p -flags
+global_header+cgop -profile:v:0 baseline -level:v:0 3.0 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v0] -map [a0] \-s:v:1 512x288
-tune:v:1 film -r:v:1 25 -b:v:1 20 -maxrate:v:1 20 -minrate:v:1
20 -bufsize:v:1 40 -ar:1 48000 -b:a:1 48000 -sc_threshold 0 -flags
+global_header+cgop -profile:v:1 baseline -level:v:1 3.0 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v1] -map [a1] \-s:v:2 640x360
-tune:v:2 film -r:v:2 25 -b:v:2 70 -maxrate:v:2 70 -minrate:v:2
70 -bufsize:v:2 140 -ar:2 48000 -b:a:2 48000 -sc_threshold 0 -flags
+global_header+cgop -profile:v:2 main -level:v:2 3.1 -preset veryfast
-nal-hrd cbr -keyint_min 50 -g 50 -map [v2] -map [a2] \-s:v:3 1280x720
-tune:v:3 film -r:v:3 25 -b:v:3 100 -maxrate:v:3 100 -minrate:v:3
100 -bufsize:v:3 200 -ar:3 48000 -b:a:3 48000 -sc_threshold 0
-flags +global_header+cgop -profile:v:3 high -level:v:3 4.0 -preset
veryfast -nal-hrd cbr -keyint_min 50 -g 50 -map [v3] -map [a3] \-f hls
-var_stream_map "a:0,v:0,name:148k a:1,v:1,name:248k a:2,v:2,name:764k
a:3,v:3,name:1064k" -master_pl_name master.m3u8 -hls_list_size 3 -hls_time
6 -method PUT -ignore_io_errors 1 -hls_segment_filename
https://w...@mail.com:test...@domain.com:8043/httppush/1/media_%v_%03d.ts
-hls_flags delete_segments+independent_segments+discont_start
https://w...@mail.com:test...@domain.com:8043/httppush/1/playlist_%v.m3u8*

*Log Files for reference :*
*preset veryfast : *
https://drive.google.com/file/d/1738ELkQDelbPhlhPrJGiMdFLNj8bBZHi/view?usp=sharing
*preset fast : *
https://drive.google.com/file/d/1HcHR5Ye-lBjsIy2FIgsSlQl8vCqG3-xC/view?usp=sharing


Thanks

*KrishnaKumar **N K *

On Fri, 21 Aug 2020 at 11:57, Moritz Barsnick  wrote:

> On Fri, Aug 21, 2020 at 08:27:28 +0530, KRISHNAKUMAR N K wrote:
> > Thanks for your reply. I have uploaded the complete, uncut console output
> > to the below google drive. I didn't observe latency with one output. I
> > haven't tried a test without the yadif filter.
> >
> >
> https://drive.google.com/file/d/1g9KHOV41BmwEA0X-Urjao7jSQpOmGhfS/view?usp=sharing
>
> Wow, I'm happy that I for once didn't ask you to post to the list.
>
> > From the above logs, I can see "Circular buffer overrun. Surviving due to
> > overrun_nonfatal option" for the first time. I have started a new test
> with
> > increasing the fifo_size and without the yadif filter. Please go through
> > the above log file and let me know your observation. Thanks in Advance.
>
> What I can see that while your encoding starts in real time, it drops
> to slightly below:
>
> frame=1033708 fps= 24 q=33.0 q=37.0 q=24.0 q=31.0 size=N/A
> time=11:29:08.45 bitrate=N/A dup=56 drop=0 speed=0.962x
>
> A speed of 0.962x is not enough. You need to reach 1.0x. (You obviously
> cannot reach more, because the incoming stream doesn't serve frames at
> more than 1.0x.) The encoding began at 1.0x (slightly above, because it
> was consuming buffer), but then dropped on overall average.
>
> This explains the delay - ffmpeg is still encoding older stuff from 27
> minutes ago! (I'm calculating that 716 minutes have elapsed, but only
> 689 minutes of material have been encoded.) That would also explain
> buffer overruns - ffmpeg is buffering all that input data somewhere,
> for later consumption.
>
> (1033708 frames correspond to exactly 11h 29m at 25 fps, so the input
> is most likely perfectly constant 

[FFmpeg-user] A systematic effort for documentation? [was: Re: Why is format=rgb24 required after maskedmerge?]

[Jim DeLaHunt]

On 2020-08-21 08:08, Gyan Doshi wrote:


On 21-08-2020 07:12 pm, Mark Filipak wrote:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:


On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:

…
FFmpeg's documentation is very incomplete. I had a rough roadmap 
at the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.


May I assist you?


Sure. Do you already have a set of tasks / actions in mind?


Gyan, it's great to hear that you say that FFmpeg's documentation is 
very incomplete. Acknowledging the problem is a first step that not 
enough people are taking.


It's also great to hear that you are considering a systematic effort for 
documentation. I encourage you to set up a structure that allows others 
to contribute, and to ask for contributions. Consider offering to act as 
champion and mentor for the other contributors. Not everyone on the 
ffmpeg-devel list will be kind to them.


I have a few suggestions for tasks and actions to consider:

Scope is potentially quite large, including refactoring the structure of 
the documentation in a big way.  I'm in favour of breaking up the video 
filter documentation so that each filter has its own page and URL, for 
example. I expect that documentation which fully explains FFmpeg 
functionality would be about as sprawling as the Python language 
documentation [1], especially [2]. Consider how large of a scope you 
want to attempt. Consider how to divide large scope into incremental 
steps which are usable as work is under way.


Think about what you will do if you trigger immune responses. "It's 
different, it must be wrong" might be a reaction. You carry some weight 
and respect among FFmpeg committers, which helps. Consider if that will 
be enough, or if you need to take some steps to get buy-in to make the 
changes you want to make.


There is a great need for a glossary. It should be structured so that 
each term has an anchor, allowing references from anywhere in the 
documentation to the glossary. My nomination for entries: "fps", "GOP", 
"PTS", "time base".


An introduction to digital video concepts and vocabulary would be 
helpful. Writing something new would be great, but even links to some 
other documents and presentations with good concepts and vocab is a lot 
better than nothing. I nominate a link to /"/A Guide to MPEG 
Fundamentals and Protocol Analysis", by Tektronix [3].


Consider how you want to trade off the virtues of brevity and accuracy. 
Compare two descriptions of the fps video filter: the official doc at 
[4] (232 words) vs a rewrite at [5], in draft patch form at [6] (1258 
words).  The primary review response to the rewrite was: too many words, 
we don't want FFmpeg doc to be that detailed. I think the official doc 
is incomplete, it doesn't describe all of the fps filter functionality 
and parameters. How do you want to make that trade-off?


A minor pushback to the "fps" filter doc rewrite at [6] was that general 
terminology should link to a centralised descriptions instead of being 
spelled out where used. There is another trade off between here, between 
brevity overall, along with consistency guaranteed by structure, versus 
ease of having the description at point of use. How do you want to make 
that trade-off?  And, do you make the trade-off differently when the 
centralised descriptions (Glossary, AVOptions writeup) don't yet exist?  
For instance, should an "fps" filter rewrite just not attempt to explain 
or link general terminology until the glossary is in place, or should we 
accept in-place explanation for now, knowing that the glossary will make 
it redundant once it arrives?


The draft rewrite at [6] is of course available as a starting point for 
whoever wants to ride into that valley of death[7] again.


The syntax and behaviour of filterchains has documentation which is 
correct, but very terse and hard to follow. Rewriting this with clearer 
text, and better diagrams, would be a big improvement. This will make it 
longer as a consequence. That is a trade-off.


The syntax and behaviour of the `ffmpeg` general options is a jumble and 
very hard to follow. It would be easier to understand if it was broken 
into different sections by function.  This will make it longer as a 
consequence. That is a trade-off.


Consider all the pockets of documentation sprinkled throughout the 
FFmpeg corpus. There is a lot of documentation in the executable, 
reached by `ffmpeg -formats` and the like. Do you want to try to allow 
for a build process which injects this documentation into the HTML files 
as well?


Gyan, I respect you greatly for your helpfulness here, and also on 
StackOverflow, and for the way you avoid the negative behaviour of some 
other participants. You represent the better angels of this community. I 
hope these ideas are helpful for you. I wish you good fortune in this 
project. I'm glad to help, if there is 

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Carl Zwanzig]

On 8/21/2020 3:33 AM, Michael Koch wrote:
I never found that "General Documentation" file because I thought 
"ffmpeg-all" contains what the filename implies: All. This is obviously not 
the case. The filename is misleading, if the file doesn't contain all 
documentation. Wouldn't it be better to combine these two files into one 
file, which contains really all?


IMHO, it would make more sense to remove the -all file as it's unweildly and 
doesn't seem to contain to contain everything anyway. I might go so far as 
to start carving things up so there's little to no duplication at all (is 
there much? I don't know, that bears checking. One example is stream 
selection/specifiers.)


Later,

z!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 21:38 schrieb Gyan Doshi:



Git mystifies me, too. I also did a lot of reading but it was written 
my Martians.


For the purposes of only generating doc patches, you only need to know 
and apply a handful of git commands.
Most of the supposed difficulties of working with git revolves around 
nonlinear histories. I see very little potential for that with pure 
docs work.


You aren't tied to linux either.  ffmpeg is perfectly compile-able and 
testable on Windows. I do it regularly, but even that's not needed here.


It's nice to know help is available, and that's appreciated. But let 
me first look around at my old notes and see what all needs to be done.
What can be done in the meantime is for someone to start a wiki or 
blog or forum and solicit, collect & curate requests for documentation 
changes.

What do users most want answered or documented first?


I have collected some things in chapter 2.115 of my book:
http://www.astro-electronic.de/FFmpeg_Book.pdf

An important first step would be to re-write git-howto.html and explain 
the git commands more detailed, the whole workflow step by step with 
many examples. Only the handfull of commands that we really need. Also 
the new introduced terms should be explained (cloning, push back, remote 
repository, checkout, tracked branch, rebasing, local branches, commit, 
master tree, merge commits, patchset).


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Specify input options

[Paul B Mahol]

On 8/21/20, Simon Brown  wrote:
> Hi,
> is it possible to stop FFmpeg from probing the input and just to tell it
> exactly what it is getting (and obviously suffering the consequences if
> it's different)?  I can reduce probesize but I want essentially zero delay
> through ffmpeg (no encoding, just repackaging a transport stream as MP4).

Yes, It is possible.

ffmpeg -f mkv -i input.mkv 

It is also possible to override decoder used.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Gyan Doshi]

On 21-08-2020 11:27 pm, Mark Filipak wrote:

On 08/21/2020 12:34 PM, Michael Koch wrote:

Am 21.08.2020 um 17:06 schrieb Gyan Doshi:

On 21-08-2020 07:30 pm, Michael Koch wrote:

Am 21.08.2020 um 15:42 schrieb Mark Filipak:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:

On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:
FFmpeg's documentation is very incomplete. I had a rough 
roadmap at the start of the year for plugging the gaps, but 
other events transpired.


I hope to start a systematic effort in September.


May I assist you?


I'm also ready to help, if it can be done without git.


It would be cumbersome, having someone else merge the changes in a 
git repo.


What concerns do you have about using git?


I don't understand how git works. Have tried it some time ago, but 
didn't work, so I gave up. No good instructions available. A second 
computer with Linux seems to be required. Too complicated. I have no 
experience with Linux. I know C and C# programming, but I'm not a 
professional programmer. The page 
https://www.ffmpeg.org/git-howto.html was obviously not written for 
beginners. Many terms are introduced without explaining them, and 
examples are missing.


Michael


Git mystifies me, too. I also did a lot of reading but it was written 
my Martians.


For the purposes of only generating doc patches, you only need to know 
and apply a handful of git commands.
Most of the supposed difficulties of working with git revolves around 
nonlinear histories. I see very little potential for that with pure docs 
work.


You aren't tied to linux either.  ffmpeg is perfectly compile-able and 
testable on Windows. I do it regularly, but even that's not needed here.


It's nice to know help is available, and that's appreciated. But let me 
first look around at my old notes and see what all needs to be done.
What can be done in the meantime is for someone to start a wiki or blog 
or forum and solicit, collect & curate requests for documentation changes.

What do users most want answered or documented first?

Gyan
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Phil Rhodes via ffmpeg-user]

 

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
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Problem while converting DNG sequnece to video file

[Michael Koch]

Am 20.08.2020 um 09:57 schrieb Masala Kentaro:

hello!

I have problems using FFmpeg, while trying to convert DNG-sequence
into mp4/mov/avi video file.
While converting, I also need to downgrade the resolution of the video
from original 6016x3200 to 2030x1080.

First problem: I got almost black screen in the resulting video. Had
to play with gamma and brightness options, but there were still
obvious problems with saturation and contrast after that.
(I tried simple DNG to PNG conversion of a single file, and it also
results in almost black screen, command:
ffmpeg -v 9 -loglevel 99 -i e:\12345\sample_r1.dng e:\output.tga)



Let's not forget that the original poster of this thread had a question. 
I can't answer it, but I did try to reproduce it.
I took a RAW CR2 image from my Canon 6D, converted it to DNG with Adobe 
DNG Converter 12.4, and then tried to convert it to JPG with FFmpeg:


ffmpeg -i IMG_3459.dng out_6D.jpg

This didn't work, see the console output below.
I also tested with a RAW image from a Canon 5D-MK4, with the same 
negative result.


Michael


C:\Users\astro\Desktop\dng>c:\ffmpeg\ffmpeg -i IMG_3459.dng out_6D.jpg
ffmpeg version git-2020-08-21-412d63f Copyright (c) 2000-2020 the FFmpeg 
developers

  built with gcc 10.2.1 (GCC) 20200805
  configuration: --enable-gpl --enable-version3 --enable-sdl2 
--enable-fontconfig --enable-gnutls --enable-iconv --enable-libass 
--enable-libdav1d --enable-libbluray --enable-libfreetype 
--enable-libmp3lame --enable-libopencore-amrnb 
--enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus 
--enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt 
--enable-libtheora --enable-libtwolame --enable-libvpx 
--enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 
--enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib 
--enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis 
--enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex 
--enable-libxvid --enable-libaom --enable-libgsm --enable-librav1e 
--enable-libsvtav1 --disable-w32threads --enable-libmfx 
--enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va 
--enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth 
--enable-libopenmpt --enable-amf

  libavutil  56. 58.100 / 56. 58.100
  libavcodec 58.100.100 / 58.100.100
  libavformat    58. 51.100 / 58. 51.100
  libavdevice    58. 11.101 / 58. 11.101
  libavfilter 7. 87.100 /  7. 87.100
  libswscale  5.  8.100 /  5.  8.100
  libswresample   3.  8.100 /  3.  8.100
  libpostproc    55.  8.100 / 55.  8.100
[tiff @ 01f73e39f440] Assuming black level pattern values are identical
[tiff @ 01f73e39f440] Tiled TIFF is not allowed to strip
[tiff_pipe @ 01f73e39d400] Stream #0: not enough frames to estimate 
rate; consider increasing probesize

[tiff_pipe @ 01f73e39d400] decoding for stream 0 failed
[tiff_pipe @ 01f73e39d400] Could not find codec parameters for 
stream 0 (Video: tiff, none): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 
'probesize' (500) options

Input #0, tiff_pipe, from 'IMG_3459.dng':
  Duration: N/A, bitrate: N/A
    Stream #0:0: Video: tiff, none, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
  Stream #0:0 -> #0:0 (tiff (native) -> mjpeg (native))
Press [q] to stop, [?] for help
[tiff @ 01f73e3a5f80] Assuming black level pattern values are identical
[tiff @ 01f73e3a5f80] Tiled TIFF is not allowed to strip
Error while decoding stream #0:0: Invalid data found when processing input
Cannot determine format of input stream 0:0 after EOF
Error marking filters as finished
Conversion failed!


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Phil Rhodes via ffmpeg-user]

 > 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
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Carl Zwanzig]

On 8/21/2020 10:59 AM, Paul B Mahol wrote:

I think git usage is far less complicated than ffmpeg.
Also git should be better documented too.


Both of those are true :), but still can be mystifying.

For those on windoze, there are git GUIs available that take some of the 
pain out; I generally use "Tortoise GIT". (Otherwise, I really don't like 
git/hg/svn/cvs/etc (the no-server SCMS's), but those are what too many 
people use.)


Re pointers- consider them an assembly language address.


z!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Paul B Mahol]

On 8/21/20, Michael Koch  wrote:
> Am 21.08.2020 um 18:41 schrieb Nicolas George:
>> Michael Koch (12020-08-21):
>>> The page https://www.ffmpeg.org/git-howto.html  was obviously not written
>>> for beginners. Many terms are introduced without explaining them, and
>>> examples are missing.
>> I think it was written for people who were familiar with subversion.
>> Have you considered following a general-purpose Git tutorial?
>
> yes, I did read that some time ago, without success.

I think git usage is far less complicated than ffmpeg.
Also git should be better documented too.

Please consider trying again and report where you fail.

>
> Michael
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Mark Filipak]

On 08/21/2020 12:34 PM, Michael Koch wrote:

Am 21.08.2020 um 17:06 schrieb Gyan Doshi:

On 21-08-2020 07:30 pm, Michael Koch wrote:

Am 21.08.2020 um 15:42 schrieb Mark Filipak:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:

On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:
FFmpeg's documentation is very incomplete. I had a rough roadmap at the start of the year for 
plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.


May I assist you?


I'm also ready to help, if it can be done without git.


It would be cumbersome, having someone else merge the changes in a git repo.

What concerns do you have about using git?


I don't understand how git works. Have tried it some time ago, but didn't work, so I gave up. No 
good instructions available. A second computer with Linux seems to be required. Too complicated. I 
have no experience with Linux. I know C and C# programming, but I'm not a professional programmer. 
The page https://www.ffmpeg.org/git-howto.html was obviously not written for beginners. Many terms 
are introduced without explaining them, and examples are missing.


Michael


Git mystifies me, too. I also did a lot of reading but it was written my 
Martians.

Also, pointers in 'C' confound me; that's what stops me reading source. 'C' programmers tell me they 
are like assembly language, and I know 4 or 5 assembly languages (in addition to about 7 HLLs), but 
"like assembly language" doesn't work with me. It doesn't make sense to me that authors should need 
to remember which variables are pointers to variables and which are actual variables. I don't know 
why anyone would think that two references with two different names is useful. I know that 'C' has 
'.h' files but I don't see why those '.h' files don't fix-up the pointer references automatically.


Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] ffmpeg_g

[Ashim Tom]

thanks

On Thu, 20 Aug 2020 at 23:16, Dennis Mungai  wrote:

> On Thu, 20 Aug 2020, 20:35 Ashim Tom,  wrote:
>
> > what is ffmpeg_g?
> >
>
> This is the ffmpeg binary with the debug symbols present.
> When stripped (without debug symbols) you get the ffmpeg binary.
>
> Debug symbols are useful for function tracing when attached to a debugger,
> such as troubleshooting CUDA based filter performance with nvidia's NSIGHT
> tools, etc.
>
> >
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 18:41 schrieb Nicolas George:

Michael Koch (12020-08-21):

The page https://www.ffmpeg.org/git-howto.html  was obviously not written
for beginners. Many terms are introduced without explaining them, and
examples are missing.

I think it was written for people who were familiar with subversion.
Have you considered following a general-purpose Git tutorial?


yes, I did read that some time ago, without success.

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Nicolas George]

Michael Koch (12020-08-21):
> The page https://www.ffmpeg.org/git-howto.html  was obviously not written
> for beginners. Many terms are introduced without explaining them, and
> examples are missing.

I think it was written for people who were familiar with subversion.
Have you considered following a general-purpose Git tutorial?

Regards,

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 17:06 schrieb Gyan Doshi:



On 21-08-2020 07:30 pm, Michael Koch wrote:

Am 21.08.2020 um 15:42 schrieb Mark Filipak:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 
20.9 image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, 
JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are 
read-only),

PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap 
at the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.


May I assist you?


I'm also ready to help, if it can be done without git.


It would be cumbersome, having someone else merge the changes in a git 
repo.


What concerns do you have about using git?


I don't understand how git works. Have tried it some time ago, but 
didn't work, so I gave up. No good instructions available. A second 
computer with Linux seems to be required. Too complicated. I have no 
experience with Linux. I know C and C# programming, but I'm not a 
professional programmer. The page https://www.ffmpeg.org/git-howto.html  
was obviously not written for beginners. Many terms are introduced 
without explaining them, and examples are missing.


Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Specify input options

[Simon Brown]

Hi,
is it possible to stop FFmpeg from probing the input and just to tell it
exactly what it is getting (and obviously suffering the consequences if
it's different)?  I can reduce probesize but I want essentially zero delay
through ffmpeg (no encoding, just repackaging a transport stream as MP4).

Regards,
Simon
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Gyan Doshi]

On 21-08-2020 07:12 pm, Mark Filipak wrote:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 
20.9 image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, 
PAM,

PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at 
the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.


May I assist you?


Sure. Do you already have a set of tasks / actions in mind?

Gyan
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Gyan Doshi]

On 21-08-2020 07:30 pm, Michael Koch wrote:

Am 21.08.2020 um 15:42 schrieb Mark Filipak:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 
20.9 image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, 
JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are 
read-only),

PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap 
at the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.


May I assist you?


I'm also ready to help, if it can be done without git.


It would be cumbersome, having someone else merge the changes in a git repo.

What concerns do you have about using git?

Gyan
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 15:42 schrieb Mark Filipak:

On 08/21/2020 06:44 AM, Gyan Doshi wrote:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 
20.9 image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, 
PAM,

PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at 
the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.


May I assist you?


I'm also ready to help, if it can be done without git.

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 12:44 schrieb Gyan Doshi:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 20.9 
image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, 
PAM,

PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at 
the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.

Gyan

P.S. ffmpeg supports roughly a few dozen image formats. I'll add the 
missing ones to https://ffmpeg.org/general.html#Image-Formats


That's very interesting. I never found that "General Documentation" 
file because I thought "ffmpeg-all" contains what the filename 
implies: All. This is obviously not the case. The filename is 
misleading, if the file doesn't contain all documentation. Wouldn't 
it be better to combine these two files into one file, which contains 
really all?


ffmpeg-all consolidates the documentation for all component options 
and the options of the ffmpeg core binary. tool. Start exploring at 
https://ffmpeg.org/documentation.html


It would be helpful if you add a link in ffmpeg-all.html, chapter 20.9 
(image2) which points to general.html, chapter 2.2 where the supported 
image formats are listed.


Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Mark Filipak]

On 08/21/2020 06:44 AM, Gyan Doshi wrote:



On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:

Please add this to the documentation (for example in chapter 20.9 image2)

FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at the start of the year for 
plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.


May I assist you?

Mark.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" [was: Re: Why is format=rgb24 required after maskedmerge?]

[Alexander Strasser]

On 2020-08-20 14:03 -0700, Jim DeLaHunt wrote:
> On 2020-08-20 09:03, Alexander Strasser wrote:
>
> > I will bring up a point that has become clear to me.
> >
> > Good documentation in general and especially for software is
> > incredibly hard to write and get right!
>
> I very much agree: it is incredibly hard.
>
> An important companion observation: it is valuable. It multiplies the value
> of the executable code, because it makes users and other developers able to
> get more value from the existing executable code by using it better.

I very much agree too. There has probably never been a widely
successful software without the critical amount of docs needed.

That docs weren't always written in the software projects
themselves, but it has always been written AFAICT.

So yes, good documentation is very valuable in multiple ways!


> > In general you have to be a good writer and have sufficient
> > insight into the tech you are documenting. And this means for
> > FFmpeg you need to understand C enough, so you can roughly
> > read the code and are able to ask the right questions.
> >
> > You need to have enough multimedia knowledge and experience
> > so you can try things yourself and write things in sufficiently
> > understood language.
>
>
> True, but also don't underestimate the power of collaboration. A subject
> matter expert can empower a writer (or a software developer for that matter)
> who is not expert, through suggestion of introductory reading material on
> the subject, through explaining the subject, and through reading draft
> documentation (or reviewing proposed code changes). Someone who is both
> subject matter expert and writer (developer) is a bit of a unicorn, but with
> collaboration you don't have to wait for unicorns to appear.
>
> Also, you need a project which sees documentation as a necessary and
> valuable part of the complete product. You need champions who will support
> the writers in making their contribution and will review patches. You need
> patch-review gatekeepers who will not veto better documentation. You need
> general project agreement that better will be different than current, and
> that different is OK.

Good point. I intended to mention collab initially, but seems I
ditched it to keep my reply short.

I have occasionally seen this model work for some time, but it's
nothing to be taken for granted. Especially in a big distributed
open source project environment.


> > You need to cope with (gradual and sometimes sweeping) change and
> > especially for projects like FFmpeg that means big restructurings
> > in the documentation every so often.
>
>
> True, but I believe this is no different than preserving runtime
> performance, or memory use, or avoidance of memory leaks, or avoidance of
> functionality regressions. Coping boils down to insisting that contributions
> need to be more than just code which compiles and runs. They need to have
> unit tests, they need to pass functionality and memory tests, they need to
> have documentation. And the project needs to track technical debt in
> documentation, and be prepared to pay it down from time to time.

No disagreement in general.

Though trade-offs are always needed.


> How does the FFmpeg project cope with these other desirable features? How
> well does it work?

Mostly good I would say. In short FFmpeg isn't used in such a wide
variety of software on different hardware by so many users for such
a long time for no reason.

Is FFmpeg perfect? No, it isn't for sure.
Is FFmpeg's documentation perfect? Surely not.

I hope the documentation can be improved for good. There is always
tension in a project like FFmpeg and there is no one voice of the
project, which is actually not bad thing.

The FFmpeg documenation isn't exactly bad, and it has been rather
gracefully extended over the years.

So help in improving the docs is welcome, just don't expect it to
be easy or all proposed changes to be immediately accepted. The FFmpeg
project insists very much on review of patches and therefore things
may need some arguing and iterations, or sometimes will be dropped.


Best regards,
  Alexander
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]

[Alexander Strasser]

On 2020-08-21 12:28 +0200, Nicolas George wrote:
[...]
>
> They belong in an introduction chapter, with links from places where it
> is relevant. If you do it that way, and the contents makes sense, it
> will be accepted.

I agree on this in principle.

We use AVOptions implementation for interpreting this input mostly
everywhere.

I think for filters and probably everywhere else where AVOptions are
used we should add a *linked* type information. Readers can immediately
recognize what possible inputs are or if they don't they can quickly
follow the link and read it up.


[...]


  Alexander
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Gyan Doshi]

On 21-08-2020 04:03 pm, Michael Koch wrote:

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 20.9 
image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at 
the start of the year for plugging the gaps, but other events 
transpired.


I hope to start a systematic effort in September.

Gyan

P.S. ffmpeg supports roughly a few dozen image formats. I'll add the 
missing ones to https://ffmpeg.org/general.html#Image-Formats


That's very interesting. I never found that "General Documentation" 
file because I thought "ffmpeg-all" contains what the filename 
implies: All. This is obviously not the case. The filename is 
misleading, if the file doesn't contain all documentation. Wouldn't it 
be better to combine these two files into one file, which contains 
really all?


ffmpeg-all consolidates the documentation for all component options and 
the options of the ffmpeg core binary. tool. Start exploring at 
https://ffmpeg.org/documentation.html


Gyan
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 12:09 schrieb Gyan Doshi:



On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 20.9 
image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at 
the start of the year for plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.

Gyan

P.S. ffmpeg supports roughly a few dozen image formats. I'll add the 
missing ones to https://ffmpeg.org/general.html#Image-Formats


That's very interesting. I never found that "General Documentation" file 
because I thought "ffmpeg-all" contains what the filename implies: All. 
This is obviously not the case. The filename is misleading, if the file 
doesn't contain all documentation. Wouldn't it be better to combine 
these two files into one file, which contains really all?


Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]

[Nicolas George]

Jim DeLaHunt (12020-08-20):
> Nicolas, do you remember this?
> 
> On 2020-05-01 03:01, Nicolas George wrote [1]:
> > Carl Eugen Hoyos (12020-05-01):
> > > > -The desired output frame rate. The default is @code{25}.
> > > > +The output frame rate, in frames per second. May be an integer, real, 
> > > > or
> > > > +rational number, or an abbreviation. The default is @code{25}.
> > > I seriously wonder who really profits from this change but it may be ok.
> > I would argue: lazy beginners.
> > …

Now that you mention, it, I remember. The fact that I did not find it
while searching my archives is caused by a misconfiguration of Git in
your end:

From: list+ffmpeg-...@jdlh.com
From: Jim DeLaHunt 

> I will observe that you didn't actually review the documentation patch which
> led to that thread. You just latched on to Carl Eugen's "who really profits"
> comment, and complained. That patch was not my only experience submitting a
> documentation improvement and having the FFmpeg project's antibodies reject
> it. But it did vividly clarify for me what the project values and what it
> does not.

I stand by my assessment, and reading a little more of your proposal and
your attitude in this discussion confirms that you have the wrong
attitude to both submitting patches and writing documentation.

There are many components, filters and others, that take a frame rate
option. How should it be documented? Should we add a little information
about these values in the documentation at each place?

It would be terrible for developers, who would have to update dozens of
places each time something changes about it. It would be terrible for
users, who would be exposed to subtly inconsistent information depending
on which part of the documentation they read. Inconsistency is one of
the worst forms of bad documentation, and redundancy invariably devolves
into inconsistency. This is what you were proposing.

The proper way to document this option is to explain the syntax of a
frame rate at a central place, along with the syntax of a video size,
the syntax of a duration, etc., and to have a link to there in the
documentation of each option using that syntax.

If it is done that way, it is best for most users:

- Confirmed users already know the syntax of a frame rate, they do not
  need to waste their time re-reading it just in case there is a subtle
  difference there.

- Confirmed users who need to refresh their memory follow the link.

- Beginners realize they need to learn the syntax of a frame rate,
  follow the link and learn it. They would have their solution, and it
  would work for all similar filters. They would have learnt something
  and made a step towards becoming confirmed users.

- As for users who just want the answer right now to their tiny
  question, without realizing there is a bigger picture, a consistency
  in syntax of options, I call them lazy and I stick with it. We are
  talking about following a link, not "having to become an FFmpeg
  developer" nor "read the source" as you strawmanishly put it.

The same issue applies to most of your proposal: you wanted to explain
basic concepts about video streams. These concepts deserve to be
explained, BUT NOT IN THE DOCUMENTATION OF A SPECIFIC FILTER.

They belong in an introduction chapter, with links from places where it
is relevant. If you do it that way, and the contents makes sense, it
will be accepted.

And this is where we come to your approach to submitting patches: you
were told, in a very succinct way, that you were wrong. You were
expected to understand how, but you were welcome to ask clarification. I
would have explained what I just explained, and pointed that the
documentation for the syntax of a frame rate already exists:
http://ffmpeg.org/ffmpeg-all.html#Video-rate
But instead, you attacked.

This is up to you: you can contribute, or you can not contribute. But if
you decide not to and still criticize, do not be surprised to get
scorned. And if you do, learn to take criticism. And, in the case of
documentation, learn to think it as a whole. Good documentation should
not contain the answer to users' questions, it should contain the tools
for users to answer their own questions. Those who refuse to use these
tools are lazy, do not cater for them.

-- 
  Nicolas George


signature.asc
Description: PGP signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Gyan Doshi]

On 21-08-2020 02:36 pm, Michael Koch wrote:

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:
Please add this to the documentation (for example in chapter 20.9 
image2)


FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.


FFmpeg's documentation is very incomplete. I had a rough roadmap at the 
start of the year for plugging the gaps, but other events transpired.


I hope to start a systematic effort in September.

Gyan

P.S. ffmpeg supports roughly a few dozen image formats. I'll add the 
missing ones to https://ffmpeg.org/general.html#Image-Formats

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Am 21.08.2020 um 10:50 schrieb Paul B Mahol:

On 8/21/20, Michael Koch  wrote:

Please add this to the documentation (for example in chapter 20.9 image2)

FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
PGM (binary P5 files are read/write, ascii P2 files are read-only),
PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.


Then please add what's missing.

Michael

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]

[Phil Rhodes via ffmpeg-user]

 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 think they care, or if they do, only in the sense of becoming angry 
that people are bringing up things they'd see as a criticism.
> In due time I think project participants may see something they perhaps don't 
> look at often.
It's been like this effectively forever; certainly for more than a decade. They 
don't care. They really don't. It's an ego thing; any suggestion that the 
project needs something that it doesn't have is seen as a criticism and 
responded to with anger.
> Maybe they will want to stop what you rightly describe as "massively 
> [reducing] the value of the work they're doing."
They don't see it that way. They simply write off anyone who doesn't fully 
understand the software as stupid or lazy, because that allows them to maintain 
the belief that the project is perfect and incapable of improvement.
Yes, it's catastrophically stupid, completely unnecessary, and terribly sad, 
but I don't think there's much that can be done about it. Honestly, ffmpeg 
works for most of the things I do with it so my interest in trying to move the 
mountain is limited.
P


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".  
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Paul B Mahol]

On 8/21/20, Michael Koch  wrote:
> Please add this to the documentation (for example in chapter 20.9 image2)
>
> FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM,
> PGM (binary P5 files are read/write, ascii P2 files are read-only),
> PGMYUV, PNG, PPM, TGA, TIFF.

Sorry but that list is incomplete.

>
> Michael
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Why is format=rgb24 required after maskedmerge?

[Michael Koch]

Please add this to the documentation (for example in chapter 20.9 image2)

FFmpeg supports the following image formats: BMP, DNG, GIF, JPG, PAM, 
PGM (binary P5 files are read/write, ascii P2 files are read-only), 
PGMYUV, PNG, PPM, TGA, TIFF.


Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] "documented implicitly" part 2 [was: Re: Problem while converting DNG sequnece to video file]

[Jim DeLaHunt]

On 2020-08-20 17:13, Phil Rhodes via ffmpeg-user wrote:


  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 involved seem to view the involvement of 
non-software-engineers as inappropriate, even though that massively reduces the 
value of the work they're doing.



I won't disagree with you about concerning this project. However, it is 
not true for all projects. The Python community is an example of a free 
software project that has done quite a good job with documentation, and 
with welcoming contributions beyond executable code. This project can do 
better if it chooses to.




It's not that hard to solve. Speaking as someone who makes a reasonable amount 
of money out of technical writing, documenting software is the next best thing 
to busywork. It does not require a knowledge of software engineering. It may 
require consultation with software engineers.



Speaking as a software engineer who frequently writes as part of the 
craft of designing and applying software, and as someone who has worked 
with professional technical writers, I hear what you are saying.


To improve this project's documentation, yes, a lot of writing may turn 
out to be straightforward. However, this project will require special 
skills in a few ways: 1. extracting the information by reading the 
source code, because consultation with software engineers will be hard 
to come by; 2. designing the structure and tooling of improved 
documentation, because I think the current structure and tooling is not 
up to the task; and 3. dealing with all the cases in which the code 
doesn't do what the developers think it does, and the documenting the 
code's actual behaviour will bring this to light.




The ffmpeg project will find a way to reject any offer of help with 
documentation; it has been repeatedly offered and turned down (for no good 
reason.)
At some point you're not really negotiating with a human being, you're just 
being told off by someone's ego.
We can't force them.



Maybe I have more optimism about this than you do. I believe a lot of 
the FFmpeg developers do read this list. We are holding a mirror up to 
the project, and inviting them to take a look. In due time I think 
project participants may see something they perhaps don't look at often. 
Maybe they will want to stop what you rightly describe as "massively 
[reducing] the value of the work they're doing."



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Latency in UDP to HLS Conversion

[Moritz Barsnick]

On Fri, Aug 21, 2020 at 08:27:28 +0530, KRISHNAKUMAR N K wrote:
> Thanks for your reply. I have uploaded the complete, uncut console output
> to the below google drive. I didn't observe latency with one output. I
> haven't tried a test without the yadif filter.
>
> https://drive.google.com/file/d/1g9KHOV41BmwEA0X-Urjao7jSQpOmGhfS/view?usp=sharing

Wow, I'm happy that I for once didn't ask you to post to the list.

> From the above logs, I can see "Circular buffer overrun. Surviving due to
> overrun_nonfatal option" for the first time. I have started a new test with
> increasing the fifo_size and without the yadif filter. Please go through
> the above log file and let me know your observation. Thanks in Advance.

What I can see that while your encoding starts in real time, it drops
to slightly below:

frame=1033708 fps= 24 q=33.0 q=37.0 q=24.0 q=31.0 size=N/A time=11:29:08.45 
bitrate=N/A dup=56 drop=0 speed=0.962x

A speed of 0.962x is not enough. You need to reach 1.0x. (You obviously
cannot reach more, because the incoming stream doesn't serve frames at
more than 1.0x.) The encoding began at 1.0x (slightly above, because it
was consuming buffer), but then dropped on overall average.

This explains the delay - ffmpeg is still encoding older stuff from 27
minutes ago! (I'm calculating that 716 minutes have elapsed, but only
689 minutes of material have been encoded.) That would also explain
buffer overruns - ffmpeg is buffering all that input data somewhere,
for later consumption.

(1033708 frames correspond to exactly 11h 29m at 25 fps, so the input
is most likely perfectly constant frame rate. Just to sanity-check the
numbers.)

You need to make your encoding faster. Use a faster CPU, spread it to
more cores. Or improve your encoding options.

First, clean up your options. This from your log:

> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 0, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 0, only the last option 
> '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 1, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 2, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 2, only the last option 
> '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 3, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 4, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 4, only the last option 
> '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 5, only the last option '-c:a libfdk_aac' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 6, only the last option '-c:v libx264' will be used.
> Multiple -pix_fmt options specified for stream 6, only the last option 
> '-pix_fmt yuv420p' will be used.
> Multiple -c, -codec, -acodec, -vcodec, -scodec or -dcodec options specified 
> for stream 7, only the last option '-c:a libfdk_aac' will be used.

and make sure that the "-preset fast" option is really applied for all
encodings. (You can check with a higher loglevel, I believe. Or ba
validating the x264 debug output.)

Choose "veryfast" to see if it encodes faster.

Drop one of the four output streams, to see if that reduces CPU load.

Those are the things I can come up with quickly.

Good luck,
tell us how it goes,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".