Re: [FFmpeg-user] Help in improving the documentation is always welcome? [was: write output of find_rect to a file?]

[Jim DeLaHunt]

On 2020-07-12 14:07, Carl Eugen Hoyos wrote:

…The size of such a change [to the documentation] often gives a good 
indication of its usefulness. 



That rule of thumb might apply in some cases, especially where the 
current documentation is so close to the peak of perfection that any 
step is more likely to be downhill than uphill. But it sure doesn't 
apply to the FFmpeg documentation today.


FFmpeg documentation is inadequate due to several causes, including:

1. Only some was accurate, complete, and well-written to start with,
   while some was inaccurate, incomplete, and/or poorly-written when
   contributed.
2. The executable code changes constantly, and the documentation
   sometimes (usually?) does not change to describe the changed code
   behaviour accurately, completely, in well-written prose.
3. The structure of the documentation, which might have been adequate
   years ago for a simpler product with a smaller volume of
   documentation, does not improve to meet the needs of a larger, more
   complex volume of documentation.
4. The project has few cultural or structural mechanisms for
   encouraging documentation contributions, no metrics for measuring
   the quality and adequacy of new or existing documentation, and a
   proven track record of rejecting documentation contributions not
   connected to code changes.

Thus, the project now ratchets downward in adequacy of documentation 
over time.


You know, Carl Eugen, you could have replied with "Better documentation 
is good. I wish we had more good documentation patches. I encourage 
people to make them. I will help to improve them and help get them 
committed. But not all changes are good." Instead you replied with just 
the snark. That is an example of #4, in my opinion.


But I do thank you for the help you give on this list. Best regards,
 —Jim DeLaHunt, software engineer, Vancouver, Canada


___
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] Documentation of chromanr filter

[Carl Eugen Hoyos]

Am Sa., 11. Juli 2020 um 19:58 Uhr schrieb Carl Zwanzig :
>
> On 7/11/2020 1:39 AM, Paul B Mahol wrote:
> > Can you elaborate what you tried and what failed?
>
> Why does it matter???

I believe you misunderstand that the only limiting
factor of FFmpeg development is time, therefore
reacting to patch suggestions that took as much
time to write as an actual patch is not sustainable.

Note that I know that git is a very powerful tool
but I only use it to create patches that I send as
attachments, so I know (better than other FFmpeg
developers) how easy it is to prepare a patch if
you don't want to deal with the specifics of git.

Carl Eugen
___
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] Help in improving the documentation is always welcome? [was: write output of find_rect to a file?]

[Carl Eugen Hoyos]

Am So., 12. Juli 2020 um 22:14 Uhr schrieb Jim DeLaHunt
:
>
> On 2020-07-12 05:21, Moritz Barsnick wrote:
>
> > …(Help in improving the documentation is always welcome….

Useful help in improving the documentation is welcome.

The size of such a change often gives a good indication
of its usefulness.

Carl Eugen
___
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] Help in improving the documentation is always welcome? [was: write output of find_rect to a file?]

[Jim DeLaHunt]

On 2020-07-12 05:21, Moritz Barsnick wrote:

…(Help in improving the documentation is always welcome…. 



I wish it were so, Moritz. But in my experience, improving the 
documentation is not always welcome.


For example: 
 and 
thread.


And: 
 
and thread, and conflict, and actual vote to accept doc change.


And the absence of documentation improvement patches which are not part 
of new code on ffmpeg-devel for the last forever.


It's a pity, because I think that the FFmpeg documentation is 
inadequate, that the inadequacy creates obstacles for users, and as a 
result there is more support work to do on the ffmpeg-users mailing 
list. If help in improving the documentation were more welcome, then I 
think both the developers and the users of FFmpeg would have better 
experiences.


I realise it is not in your individual power to fix this, Moritz. 
However, I want to be sure you are realistic about the actual situation.


Thank you for your help on this list, and for all you do for FFmpeg. 
Best regards,

 —Jim DeLaHunt, software engineer, Vancouver, Canada


___
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] Transcode udp stream

[CRD5014]

I am with a volunteer emergency service organization and a novice ffmpeg 
user. We would like to transcode & stream real time udp ts mpeg2 video 
(no audio) from a LAN IP address to my PC localhost via rtsp mp4. From 
the localhost I will re-stream via another application. Can someone help 
me get started with that quest using FFmpeg?

Thank you very much,
Chris
___
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] write output of find_rect to a file?

[Moritz Barsnick]

On Sat, Jul 11, 2020 at 14:52:43 -0700, Hans Carlson wrote:
> > The above command works fine, but is it possible to print the number of
> > the frame instead of the timestamp?
> I might be wrong, but I believe you need to infer the frame number based
> on where it appears in the output.  Given your example, with "frame"
> section and "csv" output, the 1st line is the 1st frame, the 2nd line is
> the 2nd frame, etc.

I agree with this. ffprobe doesn't do the counting for you. (I'm not
saying I believe or don't believe it could or should.)

> > I did search the documentation for a list of variables, but didn't find
> > any. Also "pkt_pts_time" seems to be undocumented.
>
> I've never found any documentation for this either.  The closest is the
> output of "ffprobe -sections", but that only lists the possible
> "sections", not the "entries" within each section.

The XML output format has a proper XML schema file ffprobe.xsd, which
describes the fields and the hierarchy. It's installed under
$prefix/share/ffmpeg/ffprobe.xsd, and in the ffmpeg source tree, it's
under doc/ffprobe.xsd. The JSON output should align with that (but
formatted as JSON), I don't know about the CSV output.

Regarding what pkt_pts_time represents or how it is calculated, you
would have to look it up in the source, if it isn't documented
anywhere. (Help in improving the documentation is always welcome,
either as a patch, or as a modification of the wiki.)

Cheers,
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".