XPost: rec.photo.digital
On Wed, 10/16/2024 12:23 AM, Oliver wrote:
On Tue, 15 Oct 2024 09:53:20 -0400, Alan Browne <bitbucket@blackhole.com> wrote
exiftool -all= <filename>
Filename can be a complete path; or in terminal (CMD on Windows), navigate to the folder (sub directory?) and run the command.
exiftool -all= *.mp4
exiftoll -all= *.MP4 <- it may be case sensitive - don't recall
https://exiftool.org
Thank you for that suggestion of exiftool-12.98_64 which I installed, renamed, and ran in the command line (noting that spaces are critical).
copy with_exif_data.mp4 no_exif_data.mp4 exiftool<space>-all=<space>no_exif_data.mp4
1 image files updated
The problem is now I need to test what the difference is in exif data.
The first program I tried was MediaInfo Version 24.06 from https://mediaarea.net/en/MediaInfo
Certainly there was a difference but the need is for a program to reliably spit out ALL the metadata so that we can be sure any remaining identifying metadata is wiped clean before a video is uploaded to the web.
Is there an offline program to spit out all the metadata in a comparable format (like csv or text) so that two outputs can be compared side by side?
If you want to study video, you can have your video dumped as packets.
Since your video sample is short, the output won't take up a lot of space.
If you try this on a two hour movie, you'll run out of space on D: :-)
C:\FFMPEG\bin\ffprobe -show_packets -show_data F:\high.mp4 > D:\Temp\high_ffprobe_out.txt
When you do "show_packets", there should be audio packets and video packets,
as separate items. The packets are interleaved (so the sound track follows
the video and is lip-synced after a fashion).
If there are any packet types other than those, that you can see, those
packets could be metadata.
The larger size of one of the video packets, is the key frame. Every 12th or 15th frame,
should be a key frame. The frames in between, are encoded as differences and the size of those frames should be smaller.
It's hard to say where the metadata would be. The beginning and end of the recording are logical places, but not a guarantee they won't try something else.
If the packets have 4CC codes, you can use those to sort the packets, with
grep perhaps.
Start with the un-stripped video first, so you have a "rich" sample
to analyze. Then move to the stripped video, to see what remains.
Even if someone were to write the tool you describe, chances are it
would not be complete. How many years did the ExifTool person work
on that software, honing it ? It took forever, to do a good job. Any
of the other developers who just dash off some code in half-an-hour,
they won't even be remotely close to being thorough.
You have to decide, whether the "Title" inside the video, is worth
chasing or not. That might not be as easy to access or view in a trace
or with a hex editor. It's always possible that in-band metadata could
be compressed, but generally, developers don't like to do that. There
is a preference for easier to parse presentations. But it's childs play
for them, to stream decoders for that sort of thing, and not a problem
to compress the stuff anyway. But historically, a preference for readable fields is there.
You can look at Mozilla bookmarks as an example. Started as .json,
ended up as .jsonlz4 , which means the text is compressed with a
light compressor. The compressor is inefficient enough, you can
still read the text! Now, why would an idiot do that ??? Fuck knows.
Either you compress the living shit out of something... to save space.
Or, you don't compress something (it's too small to bother).
Well, why would you half-compress something ? I couldn't figure that out.
Paul
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)