write output of find_rect to a file?

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

write output of find_rect to a file?

Michael Koch
Hello,

I want to track an object and need the x,y coordinates of this object
for each frame.
Is it possible to write the output of the find_rect filter to a file?

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Moritz Barsnick
Hi Michael,

On Mon, Jun 29, 2020 at 13:24:30 +0200, Michael Koch wrote:
> Hello,
>
> I want to track an object and need the x,y coordinates of this object
> for each frame.
> Is it possible to write the output of the find_rect filter to a file?

I don't have any good command line for find_rect handy, but it should
work with something like this (untested, of course):

$ ffprobe -f lavfi -i movie=input.mp4,find_rect=options -show_entries frame=pkt_pts_time:frame_tags=lavfi.rect.w,lavfi.rect.h,lavfi.rect.x,lavfi.rect.y -of csv

In other words, let ffprobe show you each frame's metadata.

You can redirect this output, or have the logging write a report file.

Cheers,
Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Michael Koch
Hi Moritz,

>
> I don't have any good command line for find_rect handy, but it should
> work with something like this (untested, of course):
>
> $ ffprobe -f lavfi -i movie=input.mp4,find_rect=options -show_entries frame=pkt_pts_time:frame_tags=lavfi.rect.w,lavfi.rect.h,lavfi.rect.x,lavfi.rect.y -of csv
>
> In other words, let ffprobe show you each frame's metadata.
>
> You can redirect this output, or have the logging write a report file.

Very good, that's exactly what I need. I did already make some tests
with -show_entries before I posted this question. But I didn't know the
names of the variables "lavfi.rect.x" and "lavfi.rect.y". Are these
variables documented somewhere? Is there also a variable for the quality
of the find_rect result, I mean the number that's compared against the
detection threshold?

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Moritz Barsnick
On Mon, Jun 29, 2020 at 17:35:50 +0200, Michael Koch wrote:
> Very good, that's exactly what I need. I did already make some tests
> with -show_entries before I posted this question. But I didn't know the
> names of the variables "lavfi.rect.x" and "lavfi.rect.y". Are these
> variables documented somewhere?

Good point. It's not in the documentation, I got this from the source.
Apparently, the filter was designed mainly for use with another filter.

> Is there also a variable for the quality of the find_rect result, I
> mean the number that's compared against the detection threshold?

No, that value is not exposed.

(You could try modifying the source yourself, or, if you make a very
good point about it, make a feature request.)

Moritz
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Michael Koch
Am 29.06.2020 um 22:28 schrieb Moritz Barsnick:

> On Mon, Jun 29, 2020 at 17:35:50 +0200, Michael Koch wrote:
>> Very good, that's exactly what I need. I did already make some tests
>> with -show_entries before I posted this question. But I didn't know the
>> names of the variables "lavfi.rect.x" and "lavfi.rect.y". Are these
>> variables documented somewhere?
> Good point. It's not in the documentation, I got this from the source.
> Apparently, the filter was designed mainly for use with another filter.
>
>> Is there also a variable for the quality of the find_rect result, I
>> mean the number that's compared against the detection threshold?
> No, that value is not exposed.
>
> (You could try modifying the source yourself, or, if you make a very
> good point about it, make a feature request.)

Unfortunately I can't compile ffmpeg myself on my Windows system.
Ticket 8766   (I've also added some other things that are missing in the
documentation)

It's important to also have the "best_score" value to the log file,
because it contains valuable information about how reliable the x,y
coordinates are.

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Valentin Schweitzer
> Unfortunately I can't compile ffmpeg myself on my Windows system.

If you are comfortable with compiling FFmpeg in general but lack
the tools on Windows, you could try the media-autobuild suite.
https://github.com/m-ab-s/media-autobuild_suite

If you need to recompile FFmpeg you can keep your ffmpeg_options.txt,
mpv_options.txt and media-autobuild_suite.ini files to reuse your
settings.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Michael Koch
In reply to this post by Moritz Barsnick
Hi Moritz,

>
>> Hello,
>>
>> I want to track an object and need the x,y coordinates of this object
>> for each frame.
>> Is it possible to write the output of the find_rect filter to a file?
> I don't have any good command line for find_rect handy, but it should
> work with something like this (untested, of course):
>
> $ ffprobe -f lavfi -i movie=input.mp4,find_rect=options -show_entries frame=pkt_pts_time:frame_tags=lavfi.rect.w,lavfi.rect.h,lavfi.rect.x,lavfi.rect.y -of csv

The above command works fine, but is it possible to print the number of
the frame instead of the timestamp?
I did search the documentation for a list of variables, but didn't find
any. Also "pkt_pts_time" seems to be undocumented.

Michael

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Hans Carlson-2
On Sat, 11 Jul 2020, Michael Koch wrote:

>> $ ffprobe -f lavfi -i movie=input.mp4,find_rect=options -show_entries
>> frame=pkt_pts_time:frame_tags=lavfi.rect.w,lavfi.rect.h,lavfi.rect.x,lavfi.rect.y
>> -of csv
>
> 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.

If you're processing this via a script of some kind, you might consider
the JSON output format.  With JSON, the output is an ARRAY of OBJECTS
where the frame number would be based on the ARRAY index.  Converting the
JSON structure to various programming languages is usually quite simple.
In perl for instance, it's one line of code and you now have a perl LIST
of HASHES.

> 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.  It would be nice if
there was a "ffprobe -entries [section]" option that listed all entries
(optionally for a specific section), along with a brief description of
each entry. I have no idea if it would be possible for that to be
auto-generated based on information already available in the existing
code.
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Mark Filipak
On 07/11/2020 05:52 PM, Hans Carlson wrote:
> On Sat, 11 Jul 2020, Michael Koch wrote:
-snip-
>> 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.  It
> would be nice if there was a "ffprobe -entries [section]" option that listed all entries (optionally
> for a specific section), along with a brief description of each entry. I have no idea if it would be
> possible for that to be auto-generated based on information already available in the existing code.

I'm very interested in pkt_pts_time, too (and also pkt_duration_time). I assume both are computed
based on SCR (or PTS or DTS) but the formula I have (below) doesn't produce sensible frame
durations. Note that my only source is for MPEG.

For example: First 10 bytes of a pack header:
[0]   pack_id 00 00 01 BA
               44 00 05 24 94 D1
[4]   marker  01-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
[4.2] SCR     --00 0-00 0000 0000 0000 0-01 0010 0100 1001 0--- ---- ----
[4.5] marker  ---- -1-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
[6.5] marker  ---- ---- ---- ---- ---- -1-- ---- ---- ---- ---- ---- ----
[8.5] marker  ---- ---- ---- ---- ---- ---- ---- ---- ---- -1-- ---- ----
[8.6] SCR_ext ---- ---- ---- ---- ---- ---- ---- ---- ---- --00 1011 000-
[9.7] marker  ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---1

formula: ((SCR)(300)+SCR_ext)/27000000 seconds
          ((146)(300)+85)/27000000 seconds

The above is from an MPEG program stream, and match the numbers in the nav pack, but the frame
durations are a little more than 3x too short, producing FPSs that are a little more than 3x too
high. Compounding this is that nav packs and PES headers (which contain the numbers) only exist (in
MPEG) for GOPs -- though ffprobe reports them for every frame (but how ffprobe does it is undocumented).

Mark.

_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: write output of find_rect to a file?

Moritz Barsnick
In reply to this post by Hans Carlson-2
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

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

Jim DeLaHunt-2
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:
<http://ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261468.html> and
thread.

And:
<https://ffmpeg.org/pipermail/ffmpeg-devel/2017-November/220538.html>
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

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

Carl Eugen Hoyos-2
Am So., 12. Juli 2020 um 22:14 Uhr schrieb Jim DeLaHunt
<[hidden email]>:
>
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

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

Jim DeLaHunt-2
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".