Date taken tag for video files

[nonobio]

Hi, I often use the video file modification date which is often the same that date taken, but sometimes not. Is there any standard tags for video files ? In particular, is there a "date taken" tag, like for photo files ? (exif, iptc, xmp...) Some video players can sort video files by date (like synology video station) but i don't know which date is used... If it exist, can Digikam edit them ? If not, can you recommend me another application ? Thanks

---

Sent from the digikam-users mailing list archive at Nabble.com.

[AndriusWild]

Support for video files metadata was turned off due to some exiv2 related issues causing digikam crashes.

I process all my videos with a bash script that reads the creation date from metadata and writes it as file modify date (for linux systems).

That is the only way I found so far to make my video files show up in digikam with proper dates.

On Sat, Jan 13, 2018 at 7:41 AM, nonobio <[hidden email]> wrote:

Hi, I often use the video file modification date which is often the same that date taken, but sometimes not. Is there any standard tags for video files ? In particular, is there a "date taken" tag, like for photo files ? (exif, iptc, xmp...) Some video players can sort video files by date (like synology video station) but i don't know which date is used... If it exist, can Digikam edit them ? If not, can you recommend me another application ? Thanks

---

Sent from the digikam-users mailing list archive at Nabble.com.

[nonobio]

Hi,

Is your linux method a script you created yourself ? If not, can you give me
the name of tools used ? Maybe i could serach for an windows alternative ..

So you use the "created date" metadata. Is it generic "file" date or is it a
specific "taken date" tag ?

Is it planned in next digikam version to reintroduce video file taken date
editing ?

Thanks



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

Look for compress2mp4.sh here: https://github.com/AndriusWild/dam_scripts

Module #15 is responsible for writing the date. I take the data from the tag: QuickTime:CreateDate

I suggest you to check your videos with exiftool -a -G1 -s FILE and see which tag you can use.

If you have video file formats or videos created by different cameras, phones or processed with different software make sure to check every single type. For example (I am pretty sure) you won't find
QuickTime:CreateDate in *.avi files but you will find it in *.mp4 or *.mov files

Once you figured out your script you can add it to the Open With menu for the media type or create a service menu which will speed up your process in future.

Digikam appimage does not show "Open With" menu correctly on some distros/DEs though.

In that case you can either call the script from the file manager or call it from digikam via right click - open with - other - and then type (the following command will work on KDE only): konsole --noclose -e /path/to/your/script.sh %U

Digikam will remember that command from then.

Some people also use Batch Processing Tool in digikam for that but last time I tried it (probably ver. 4.12) it was crashing all the time. It is probably fixed by now but I already got used to my workflow so I never bothered to give it a second chance.

# 15. Writing FileModifyDate from QuickTime:CreateDate using exiftool

count="1"

for f in "$@"; do

if [ -e "${f%.*}_${suffix}_${suffix2}.mp4" ]; then

echo -e "${GREEN}Copying QuickTime.CreateDate to FileModifyDate using ExifTool for file ${count}/${#@} ${UNDERLINE}"$(basename "${f%.*}_${suffix}_${suffix2}.mp4")"${NC}"

echo -e "${BLUE}exiftool -api quicktimeutc=1 '-FileModifyDate<QuickTime:CreateDate' -overwrite_original ${UNDERLINE}"$(basename "${f%.*}_${suffix}_${suffix2}.mp4")"${NC}"

exiftool -api quicktimeutc=1 "-FileModifyDate<QuickTime:CreateDate" -overwrite_original "${f%.*}_${suffix}_${suffix2}.mp4" || exit 1

fi

((count++))

done

On Mon, Jan 15, 2018 at 5:37 AM, nonobio <[hidden email]> wrote:

Hi,

Is your linux method a script you created yourself ? If not, can you give me
the name of tools used ? Maybe i could serach for an windows alternative ..

So you use the "created date" metadata. Is it generic "file" date or is it a
specific "taken date" tag ?

Is it planned in next digikam version to reintroduce video file taken date
editing ?

Thanks



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Hi,

Sorry for my late reply.

Thanks a lot for your explanation, i keep a copy of it :)

So, if i understand, there isn't a  "standard" tag used in all video files
types and no easy way to edit these tags :(

Have a nice day





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Hi :)

Since my last message i didn't tried anything new : i just use the file name
as it is the best "taken date" info i have.

I just updated Digikam to version 6.0.0 and as it have a new video files
management, i make a new try.

After analyse a video file metadata with Digikam 6.0.0, it find a new field
displayed in file view : "dititalized date". It seems to display the same
date that "created date".

Anyway, this is what i see and understand about differents date fields in
list view :

<http://digikam.1695700.n4.nabble.com/file/t376394/gfH5Sh1.png> 

1- File name : file is named with the actual date as soon as i start video
capture. It isn't a metadata but it is the real "taken date".
2- Last modified. File date attribute is writed at the end of the capture.
It isn't the good "date taken" because it is the "end" of the video, not the
"start". I think it have more sense to use "beginning date".
3- Created date : it is the end of the video but not the good : it has an
error of "one hour". I think it is about "GMT" ?
4- Digitalized date : new field sinc Digikam 6.0.0 but same problem that
created date (one hour less).

Because the "file name" is the only good "taken time", i only use it and not
the others fields. For that i just rename it to match my others file names
preferences (yyyymmddhhmmss). It is ok but when i explore my videos, i have
to sort them by "name", not by "date"...

My questions : 

1- Am i wrong about what i understand for the different dates ?
2- Why is there a delta of one hour for created and digitalized date, and how
to correct it ?
3- Is there a way to have "start date" for video metadata ?
4- Can Digikam write date metadata using filename mask ?

Thanks

--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Hi,

The video file metadata are extracted, with... ffmpeg libraries.

So, the difference can be relevant of codec implementation in ffmpeg. In fact we ask to fmmpeg to extract all metadata and pass the result that we parse to populate the database.

If you want to compare yourself, open a console, go to your video file and run ffmpeg -i file. Exemple :

[gilles@localhost Video]$ ffmpeg -i small.mp4 

ffmpeg version 3.3.9 Copyright (c) 2000-2018 the FFmpeg developers

  built with gcc 5.5.0 (Mageia 5.5.0-1.mga6)

  configuration: --prefix=/usr --enable-shared --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include --disable-stripping --enable-postproc --enable-gpl --enable-pthreads --enable-libtheora --enable-libvorbis --disable-encoder=vorbis --enable-libvpx --enable-runtime-cpudetect --enable-libdc1394 --enable-libschroedinger --enable-librtmp --enable-libspeex --enable-libfreetype --enable-libnut --enable-libgsm --enable-libcelt --enable-libopus --enable-libopencv --enable-libopenjpeg --enable-libtwolame --enable-libxavs --enable-frei0r --enable-libmodplug --enable-libass --enable-gnutls --enable-libcdio --enable-libpulse --enable-libv4l2 --enable-avresample --enable-opencl --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3 --enable-libx264 --enable-libx265 --enable-libvo-amrwbenc --enable-libxvid

  libavutil      55. 58.100 / 55. 58.100

  libavcodec     57. 89.100 / 57. 89.100

  libavformat    57. 71.100 / 57. 71.100

  libavdevice    57.  6.100 / 57.  6.100

  libavfilter     6. 82.100 /  6. 82.100

  libavresample   3.  5.  0 /  3.  5.  0

  libswscale      4.  6.100 /  4.  6.100

  libswresample   2.  7.100 /  2.  7.100

  libpostproc    54.  5.100 / 54.  5.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'small.mp4':

  Metadata:

    major_brand     : mp42

    minor_version   : 0

    compatible_brands: mp42isomavc1

    creation_time   : 2010-03-20T21:29:11.000000Z

    encoder         : HandBrake 0.9.4 2009112300

  Duration: 00:00:05.57, start: 0.000000, bitrate: 551 kb/s

    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p(tv, bt709), 560x320, 465 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default)

    Metadata:

      creation_time   : 2010-03-20T21:29:11.000000Z

      encoder         : JVT/AVC Coding

    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 83 kb/s (default)

    Metadata:

      creation_time   : 2010-03-20T21:29:11.000000Z

At least one output file must be specified

Look the "creation_time" tags.

Gilles Caulier

Le mer. 27 févr. 2019 à 15:39, nonobio <[hidden email]> a écrit :

Hi :)

Since my last message i didn't tried anything new : i just use the file name
as it is the best "taken date" info i have.

I just updated Digikam to version 6.0.0 and as it have a new video files
management, i make a new try.

After analyse a video file metadata with Digikam 6.0.0, it find a new field
displayed in file view : "dititalized date". It seems to display the same
date that "created date".

Anyway, this is what i see and understand about differents date fields in
list view :

<http://digikam.1695700.n4.nabble.com/file/t376394/gfH5Sh1.png>

1- File name : file is named with the actual date as soon as i start video
capture. It isn't a metadata but it is the real "taken date".
2- Last modified. File date attribute is writed at the end of the capture.
It isn't the good "date taken" because it is the "end" of the video, not the
"start". I think it have more sense to use "beginning date".
3- Created date : it is the end of the video but not the good : it has an
error of "one hour". I think it is about "GMT" ?
4- Digitalized date : new field sinc Digikam 6.0.0 but same problem that
created date (one hour less).

Because the "file name" is the only good "taken time", i only use it and not
the others fields. For that i just rename it to match my others file names
preferences (yyyymmddhhmmss). It is ok but when i explore my videos, i have
to sort them by "name", not by "date"...

Am i wrong about what i understand for the different dates ?
Why is there a delta of one hour for created and digitalized date, and how
to correct it ?
Do you have any recommandations ?

Thanks






--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

I have similar issues with some video files.

I think it has to deal with UTC conversion.

I am 6(7) behind UTC and some videos shown with 6(7) hours difference.

Sent from my Samsung Galaxy smartphone.

-------- Original message --------

From: Gilles Caulier <[hidden email]>

Date: 2019-02-27 10:09 AM (GMT-07:00)

To: digiKam - Home Manage your photographs as a professional with the power of open source <[hidden email]>

Subject: Re: [digiKam-users] Date taken tag for video files

Hi,

The video file metadata are extracted, with... ffmpeg libraries.

So, the difference can be relevant of codec implementation in ffmpeg. In fact we ask to fmmpeg to extract all metadata and pass the result that we parse to populate the database.

If you want to compare yourself, open a console, go to your video file and run ffmpeg -i file. Exemple :

[gilles@localhost Video]$ ffmpeg -i small.mp4 

ffmpeg version 3.3.9 Copyright (c) 2000-2018 the FFmpeg developers

  built with gcc 5.5.0 (Mageia 5.5.0-1.mga6)

  configuration: --prefix=/usr --enable-shared --libdir=/usr/lib64 --shlibdir=/usr/lib64 --incdir=/usr/include --disable-stripping --enable-postproc --enable-gpl --enable-pthreads --enable-libtheora --enable-libvorbis --disable-encoder=vorbis --enable-libvpx --enable-runtime-cpudetect --enable-libdc1394 --enable-libschroedinger --enable-librtmp --enable-libspeex --enable-libfreetype --enable-libnut --enable-libgsm --enable-libcelt --enable-libopus --enable-libopencv --enable-libopenjpeg --enable-libtwolame --enable-libxavs --enable-frei0r --enable-libmodplug --enable-libass --enable-gnutls --enable-libcdio --enable-libpulse --enable-libv4l2 --enable-avresample --enable-opencl --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-version3 --enable-libx264 --enable-libx265 --enable-libvo-amrwbenc --enable-libxvid

  libavutil      55. 58.100 / 55. 58.100

  libavcodec     57. 89.100 / 57. 89.100

  libavformat    57. 71.100 / 57. 71.100

  libavdevice    57.  6.100 / 57.  6.100

  libavfilter     6. 82.100 /  6. 82.100

  libavresample   3.  5.  0 /  3.  5.  0

  libswscale      4.  6.100 /  4.  6.100

  libswresample   2.  7.100 /  2.  7.100

  libpostproc    54.  5.100 / 54.  5.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'small.mp4':

  Metadata:

    major_brand     : mp42

    minor_version   : 0

    compatible_brands: mp42isomavc1

    creation_time   : 2010-03-20T21:29:11.000000Z

    encoder         : HandBrake 0.9.4 2009112300

  Duration: 00:00:05.57, start: 0.000000, bitrate: 551 kb/s

    Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuv420p(tv, bt709), 560x320, 465 kb/s, 30 fps, 30 tbr, 90k tbn, 60 tbc (default)

    Metadata:

      creation_time   : 2010-03-20T21:29:11.000000Z

      encoder         : JVT/AVC Coding

    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, mono, fltp, 83 kb/s (default)

    Metadata:

      creation_time   : 2010-03-20T21:29:11.000000Z

At least one output file must be specified

Look the "creation_time" tags.

Gilles Caulier

Le mer. 27 févr. 2019 à 15:39, nonobio <[hidden email]> a écrit :

Hi :)

Since my last message i didn't tried anything new : i just use the file name
as it is the best "taken date" info i have.

I just updated Digikam to version 6.0.0 and as it have a new video files
management, i make a new try.

After analyse a video file metadata with Digikam 6.0.0, it find a new field
displayed in file view : "dititalized date". It seems to display the same
date that "created date".

Anyway, this is what i see and understand about differents date fields in
list view :

<http://digikam.1695700.n4.nabble.com/file/t376394/gfH5Sh1.png>

1- File name : file is named with the actual date as soon as i start video
capture. It isn't a metadata but it is the real "taken date".
2- Last modified. File date attribute is writed at the end of the capture.
It isn't the good "date taken" because it is the "end" of the video, not the
"start". I think it have more sense to use "beginning date".
3- Created date : it is the end of the video but not the good : it has an
error of "one hour". I think it is about "GMT" ?
4- Digitalized date : new field sinc Digikam 6.0.0 but same problem that
created date (one hour less).

Because the "file name" is the only good "taken time", i only use it and not
the others fields. For that i just rename it to match my others file names
preferences (yyyymmddhhmmss). It is ok but when i explore my videos, i have
to sort them by "name", not by "date"...

Am i wrong about what i understand for the different dates ?
Why is there a delta of one hour for created and digitalized date, and how
to correct it ?
Do you have any recommandations ?

Thanks






--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Gilles Caulier-4 wrote
> Hi,
>
> The video file metadata are extracted, with... ffmpeg libraries.
>
> So, the difference can be relevant of codec implementation in ffmpeg. In
> fact we ask to fmmpeg to extract all metadata and pass the result that we
> parse to populate the database.
>
> If you want to compare yourself, open a console, go to your video file and
> run ffmpeg -i file.

Hi,

I'm on Windows, i didn't know where open the command so i downloaded binary
ffmpeg  here <https://ffmpeg.zeranoe.com/builds/>   ; opened cmd in the same
folder as ffmpeg.exe; copied my video file in the same place and it worked
(but maybe you was asking me to do that somewhere else ? i didn't found the
ffmpeg used by digikam). Anyway, this is my result :

Gilles Caulier-4 wrote

Hi,

The video file metadata are extracted, with... ffmpeg libraries.

So, the difference can be relevant of codec implementation in ffmpeg. In
fact we ask to fmmpeg to extract all metadata and pass the result that we
parse to populate the database.

If you want to compare yourself, open a console, go to your video file and
run ffmpeg -i file.

Hi,

I'm on Windows, i didn't know where open the command so i downloaded binary ffmpeg here ; opened cmd in the same folder as ffmpeg.exe; copied my video file in the same place and it worked (but maybe you was asking me to do that somewhere else ? i didn't found the ffmpeg used by digikam). Anyway, this is my result :

G:\Téléchargements\ffmpeg-20190225-f948082-win64-static\bin>ffmpeg -i 2019013017
1535.mp4
ffmpeg version N-93252-gf948082e5f Copyright (c) 2000-2019 the FFmpeg developers

  built with gcc 8.2.1 (GCC) 20190212
  configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfi
g --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libb
luray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enab
le-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --e
nable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable
-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 -
-enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enab
le-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --en
able-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-amf --en
able-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --e
nable-dxva2 --enable-avisynth --enable-libopenmpt
  libavutil      56. 26.100 / 56. 26.100
  libavcodec     58. 47.102 / 58. 47.102
  libavformat    58. 26.101 / 58. 26.101
  libavdevice    58.  6.101 / 58.  6.101
  libavfilter     7. 48.100 /  7. 48.100
  libswscale      5.  4.100 /  5.  4.100
  libswresample   3.  4.100 /  3.  4.100
  libpostproc    55.  4.100 / 55.  4.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '20190130171535.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 0
    compatible_brands: isommp42
    creation_time   : 2019-01-30T16:24:05.000000Z
    location        : +47.9707-001.5506/
    location-eng    : +47.9707-001.5506/
    com.android.version: 6.0
  Duration: 00:07:16.24, start: 0.000000, bitrate: 12156 kb/s
    Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1280x
720, 11993 kb/s, SAR 1:1 DAR 16:9, 29.98 fps, 30 tbr, 90k tbn, 180k tbc (default
)
    Metadata:
      creation_time   : 2019-01-30T16:24:05.000000Z
      handler_name    : VideoHandle
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, flt
p, 155 kb/s (default)
    Metadata:
      creation_time   : 2019-01-30T16:24:05.000000Z
      handler_name    : SoundHandle
At least one output file must be specified


Creation_time is the wrong : "16:24" instead of "17:24" (this last is also "wrong" as it is the end of the capture : see my others questions).

So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?

Thanks


Creation_time is the wrong : "16:24" instead of "17:24" (this last is also
"wrong" as it is the end of the capture : see my others questions).

So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?

Thanks




--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Remco Viëtor]

On jeudi 28 février 2019 09:00:26 CET nonobio wrote:
>
> Creation_time is the wrong : "16:24" instead of "17:24" (this last is also
> "wrong" as it is the end of the capture : see my others questions).
>
What is the problem with using the end of capture in your particular use case?
I don't think there are many cameras that can take several videos in parallel,
so the videos will always be sorted in the order in which they are recorded,
even when using the 'end of recording' as creation time.

> So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?

It looks like a *camera* issue, in that the camera doesn't record the starting
time of a file. The filename is not a reliable source for date/time
information seen from a programmer's viewpoint.

For the 1h offset, best check first what are the settings on the camera and
your computer related to time zones. (E.g. camera set to French time, records
as UTC, computer set to UTC or GMT -> you'll see the wrong time).
If there's no time zone designation somewhere in the metadata, ffmpeg (or any
other library) can only read and return the time as recorded...

Remco

[Gilles Caulier-4]

Le jeu. 28 févr. 2019 à 09:00, nonobio <[hidden email]> a écrit :

Gilles Caulier-4 wrote
> Hi,
>
> The video file metadata are extracted, with... ffmpeg libraries.
>
> So, the difference can be relevant of codec implementation in ffmpeg. In
> fact we ask to fmmpeg to extract all metadata and pass the result that we
> parse to populate the database.
>
> If you want to compare yourself, open a console, go to your video file and
> run ffmpeg -i file.

Hi,

I'm on Windows, i didn't know where open the command so i downloaded binary
ffmpeg  here <https://ffmpeg.zeranoe.com/builds/>   ; opened cmd in the same
folder as ffmpeg.exe; copied my video file in the same place and it worked
(but maybe you was asking me to do that somewhere else ? i didn't found the
ffmpeg used by digikam). Anyway, this is my result :

There is no ffmpeg executable in digiKAm. We use the share ffmpeg libraries as well. It's so far faster, as the call is done in C++...

Remember that digiKam is 1.5 M of c++ lines of codes

Creation_time is the wrong : "16:24" instead of "17:24" (this last is also
"wrong" as it is the end of the capture : see my others questions).

So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?

Yes it is...

Gilles Caulier

[nonobio]

Hi,


Remco Viëtor wrote

> On jeudi 28 février 2019 09:00:26 CET nonobio wrote:
>>
>> Creation_time is the wrong : "16:24" instead of "17:24" (this last is
>> also
>> "wrong" as it is the end of the capture : see my others questions).
>>
> What is the problem with using the end of capture in your particular use
> case?
> I don't think there are many cameras that can take several videos in
> parallel,
> so the videos will always be sorted in the order in which they are
> recorded,
> even when using the 'end of recording' as creation time.

Even if you collect videos from only one device i think it have more sense
to see the "starting" date of a video instead of "finish"date; especially
when it is "long" videos : Imagine you record an event starting the 11 of
march 2019 at 20:00 and finishing at 23:00. When i browse my videos per
date, i want to see my video date displayed as  "11 march 2019 20:00"
corresponding to the beggining, not the end.

But in my case, i centralize videos taken from my family (we are 4) so i can
have videos taken in "parallel" at the same time.

Exemple :
I  record my cat sleeping from 10:00 to 10:15.
My daughter record the same thing from 10:14 to 10:20.

If my video are sorted by "finishing" date : my daughter video will come
before mine, it isn't logical.


Remco Viëtor wrote
> For the 1h offset, best check first what are the settings on the camera
> and
> your computer related to time zones. (E.g. camera set to French time,
> records
> as UTC, computer set to UTC or GMT -> you'll see the wrong time).
> If there's no time zone designation somewhere in the metadata, ffmpeg (or
> any
> other library) can only read and return the time as recorded...

I checked my android device and my windows PC where i store my videos : both
are GMT+1 (Paris).

It seems to be the same setting on my others android devices; i should check
my others video captures devices...


AndriusWild wrote
> I have similar issues with some video files.I think it has to deal with
> UTC conversion.I am 6(7) behind UTC and some videos shown with 6(7) hours
> difference.Sent from my Samsung Galaxy smartphone.
> --
> Sent from:
> http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html


Gilles Caulier-4 wrote
> Le jeu. 28 févr. 2019 à 09:00, nonobio &lt;

> nonobio@

> &gt; a écrit :
>
>> Nonobio wrote
>
>> Creation_time is the wrong : "16:24" instead of "17:24" (this last is
>> also
>> "wrong" as it is the end of the capture : see my others questions).
>>
>> So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?
>
>>Gilles Caulier-4 wrote
> Yes it is...
>
> Gilles Caulier

Ok, i will try to see if i find something about that on ffmpeg but if at the
end i can only get the "finishing" video date, i'm not sure i will use it.

Thanks





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[meku]

My camera records useful information in the video container including the camera settings and DateTimeOriginal which is the start date of filming. According to exfitool some of this is in EXIF data and some appears to be manufacturer specific.

ffmpeg/ffprobe does not appear to support EXIF in video containers, at least with this manufacturer.

On Mon, 11 Mar 2019 at 20:17, nonobio <[hidden email]> wrote:

Hi,


Remco Viëtor wrote
> On jeudi 28 février 2019 09:00:26 CET nonobio wrote:
>>
>> Creation_time is the wrong : "16:24" instead of "17:24" (this last is
>> also
>> "wrong" as it is the end of the capture : see my others questions).
>>
> What is the problem with using the end of capture in your particular use
> case?
> I don't think there are many cameras that can take several videos in
> parallel,
> so the videos will always be sorted in the order in which they are
> recorded,
> even when using the 'end of recording' as creation time.

Even if you collect videos from only one device i think it have more sense
to see the "starting" date of a video instead of "finish"date; especially
when it is "long" videos : Imagine you record an event starting the 11 of
march 2019 at 20:00 and finishing at 23:00. When i browse my videos per
date, i want to see my video date displayed as  "11 march 2019 20:00"
corresponding to the beggining, not the end.

But in my case, i centralize videos taken from my family (we are 4) so i can
have videos taken in "parallel" at the same time.

Exemple :
I  record my cat sleeping from 10:00 to 10:15.
My daughter record the same thing from 10:14 to 10:20.

If my video are sorted by "finishing" date : my daughter video will come
before mine, it isn't logical.


Remco Viëtor wrote
> For the 1h offset, best check first what are the settings on the camera
> and
> your computer related to time zones. (E.g. camera set to French time,
> records
> as UTC, computer set to UTC or GMT -> you'll see the wrong time).
> If there's no time zone designation somewhere in the metadata, ffmpeg (or
> any
> other library) can only read and return the time as recorded...

I checked my android device and my windows PC where i store my videos : both
are GMT+1 (Paris).

It seems to be the same setting on my others android devices; i should check
my others video captures devices...


AndriusWild wrote
> I have similar issues with some video files.I think it has to deal with
> UTC conversion.I am 6(7) behind UTC and some videos shown with 6(7) hours
> difference.Sent from my Samsung Galaxy smartphone.
> --
> Sent from:
> http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html


Gilles Caulier-4 wrote
> Le jeu. 28 févr. 2019 à 09:00, nonobio &lt;

> nonobio@

> &gt; a écrit :
>
>> Nonobio wrote
>
>> Creation_time is the wrong : "16:24" instead of "17:24" (this last is
>> also
>> "wrong" as it is the end of the capture : see my others questions).
>>
>> So it seems to be an ffmpeg issue. Should i submit the issue to ffmpeg ?
>
>>Gilles Caulier-4 wrote
> Yes it is...
>
> Gilles Caulier

Ok, i will try to see if i find something about that on ffmpeg but if at the
end i can only get the "finishing" video date, i'm not sure i will use it.

Thanks





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Hi,

I made complete tests with my different video recording devices and
applications.

Issues (start video not used and difference of time) are present only with
my Android Devices, not with my "real" camera devices.

You can consult my sheet comparative  here
<https://docs.google.com/spreadsheets/d/1vHiruk7Y0XZmNdMOSt0ifCuassatx0LwbW-xLHCpTPE/edit?usp=sharing>
.

I will make some search about that; your infos are welcomed.

Bye



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Gilles Caulier-4]

Nonobio,

This data sheet is very interesting. But unfortunately, i'm not able to make investiguation without the video file samples shared somewhere in the cloud to try to reproduce the mesurements and look is the digiKam code can be improved in ffmpeg metadata parser.

Perhaps also, it's fully relevant of ffmpeg codecs. ffmpeg code is huge and as i seen, each codec implement a metadata parsing not fully unified everywhere.

So, i recommend to :

1/ Share your data sheet in a bugzilla entry (a gdoc link is enough)

2/ share your video file in the same bugzilla entry (a link to gdrive for ex is perfect).

3/ copy and paste your results from this email to the bugzilla entry.

I don't have enough time to investigate now this problem. I'm very busy to fix the AppImage bundle. It take more time than expected. So archiving your results in bugzilla is safe in time (better than to use mailing list).

Best

Gilles Caulier

Le ven. 15 mars 2019 à 23:50, nonobio <[hidden email]> a écrit :

Hi,

I made complete tests with my different video recording devices and
applications.

Issues (start video not used and difference of time) are present only with
my Android Devices, not with my "real" camera devices.

You can consult my sheet comparative  here
<https://docs.google.com/spreadsheets/d/1vHiruk7Y0XZmNdMOSt0ifCuassatx0LwbW-xLHCpTPE/edit?usp=sharing>
.

I will make some search about that; your infos are welcomed.

Bye



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Hi,

I will do that, but video files are very bigs (about 4 GB all).

Can i compress them without affecting metadatas or is it better to untouch
them ?

Thanks



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

No I don't think you can either compress or trim a video file without affecting metadata. The only way I think of is to check a short video file straight out of the camera.

On Monday, March 18, 2019, nonobio <[hidden email]> wrote:

> Hi,
>
> I will do that, but video files are very bigs (about 4 GB all).
>
> Can i compress them without affecting metadatas or is it better to untouch
> them ?
>
> Thanks
>
>
>
> --
> Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html
>

--

Best regards,

[Gilles Caulier-4]

https://video.stackexchange.com/questions/19176/how-to-cutting-a-video-and-keep-all-format-and-metadata

Gilles caulier

Le mar. 19 mars 2019 à 03:03, nonobio <[hidden email]> a écrit :

Hi,

I will do that, but video files are very bigs (about 4 GB all).

Can i compress them without affecting metadatas or is it better to untouch
them ?

Thanks



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[nonobio]

Hi,

Thanks for the suggestions but i finally uploaded my original files. You can
found the link on the bug report :

https://bugs.kde.org/show_bug.cgi?id=405589
<https://bugs.kde.org/show_bug.cgi?id=405589>  

Bye





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[Anders Kamf]

Hello!

The timestamp of video files differs depending on each device used for recording. It is quite common that the timestamp is in UTC, it can be start time or stop time. Older cameras using AVI file format often  created a .THM beside the movie with correct timestamp.

It is also different which exif parameter that is used for the timestamp.

I do not believe there is a common used standard, you need to the recording the device and how it handles metadata (timestamp) for video.

Regards

Anders

Den fre 22 mars 2019 kl 13:21 skrev nonobio <[hidden email]>:

Hi,

Thanks for the suggestions but i finally uploaded my original files. You can
found the link on the bug report :

https://bugs.kde.org/show_bug.cgi?id=405589
<https://bugs.kde.org/show_bug.cgi?id=405589> 

Bye





--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html