Re: Changing timestamps in video files
On Wed 29 Apr 2020 at 13:16:17 (+0200), Anders Andersson wrote:
> On Wed, Apr 29, 2020 at 12:54 PM elvis <elvis@dogonfire.com> wrote:
> > On 29/4/20 8:29 pm, Anders Andersson wrote:
> > > On Tue, Apr 28, 2020 at 5:57 PM Steve Keller <keller.steve@gmx.de> wrote:
> > >> Is there any tool in Debian that is able to change the timestamp in
> > >> video files, e.g. .mov, .avi, .mp4, etc.?
> > >>
> > >> For image files I use jhead -ta<offset> <file> but I haven't found
> > >> anything for video.
> > > $ ls -gGh faked_evidence.avi
> > > -rw-r--r-- 1 700M Apr 29 12:26 faked_evidence.avi
> > > $ touch -t 0512241337 faked_evidence.avi
> > > $ ls -gGh faked_evidence.avi
> > > -rw-r--r-- 1 700M Dec 24 2005 faked_evidence.avi
> >
> > Don't try that on faked_evidence.pdf
> >
> > Pdfs have an internal timestamp you need to change as well.
> >
> >
> > I think this is what he wants for movie files, but I am not sure they
> > have the time encoded into them...
>
> Sure. We can only guess what goes on in OPs mind. Could be basically
> anything, so I imagine this list of replies will grow until OP tells
> us what they want.
Well, the OP wrote "in video files", which rules out touch.
It's pretty obvious that the OP is more interested in modifying
timestamps more like the one seen here, reading 210.718067.
$ ffprobe 2037DFB67323C9DBA31FA6AE9C27A2670855D94A
Input #0, mpegts, from '2037DFB67323C9DBA31FA6AE9C27A2670855D94A':
Duration: 00:00:07.57, start: 210.718067, bitrate: 4413 kb/s
Program 1
Metadata:
service_name : Service01
service_provider: FFmpeg
Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 102 kb/s
$
These are useful for splicing together fragments of video from a
browser's cache. When they're all set to zero, one has to rely on the
timestamps (which can lack precision) or order of writing (which can
be unreliable when files "overtake" each other in transit) to put
them in sequence.
This particular file, generated by streaming a video from a TV
station, actually has a lot of metadata at the end, including
GMT timestamps as text, and I think it's atypical in having a
non-zero start time. AFAICT the GMT timestamps are connected
with the fragment's transport rather than its content. The start
time is not obvious, so it's probably written as binary.
Cheers,
David.
Reply to: