Hi,
Am 31.03.20 um 02:25 schrieb Ulf Zibis:
As you can see, I need to increase the ftyp box by 4 bytes to insert CEAP and
to insert the udta box of the original at the bebinning of the moov box as a
next step.
Is there a ffmpeg command to do this including the valid updating of the index
Am Mi., 1. Apr. 2020 um 01:18 Uhr schrieb Ulf Zibis :
>
>
> Am 01.04.20 um 00:47 schrieb Carl Eugen Hoyos:
> > Am Mi., 1. Apr. 2020 um 00:45 Uhr schrieb Ulf Zibis :
> >
> >> Am 31.03.20 um 01:02 schrieb Carl Eugen Hoyos:
> >>> But the relevant test - imo - is not to change the file that does not
> Here is the atom structure of the original file from the camera:
>
> $ MP4Box -v MVI_1324.MOV
> [iso file] Starting to parse a top-level box at position 0
> [iso file] Read Box type ftyp size 24 start 0
> [iso file] Starting to parse a top-level box at position 24
> [iso file] Read Box type
Am 01.04.20 um 00:47 schrieb Carl Eugen Hoyos:
Am Mi., 1. Apr. 2020 um 00:45 Uhr schrieb Ulf Zibis :
Am 31.03.20 um 01:02 schrieb Carl Eugen Hoyos:
But the relevant test - imo - is not to change the file that does not play
but instead change the playing file and find out which change breaks
Am Mi., 1. Apr. 2020 um 00:45 Uhr schrieb Ulf Zibis :
> Am 31.03.20 um 01:02 schrieb Carl Eugen Hoyos:
> > But the relevant test - imo - is not to change the file that does not play
> > but instead change the playing file and find out which change breaks
> > playback.
> >
> > You can overwrite
Hi,
Am 31.03.20 um 01:02 schrieb Carl Eugen Hoyos:
But the relevant test - imo - is not to change the file that does not play
but instead change the playing file and find out which change breaks
playback.
You can overwrite each atom name with "free" and the file stays a
valid (but possible
Am 31.03.20 um 14:46 schrieb Carl Eugen Hoyos:
Am Di., 31. März 2020 um 02:30 Uhr schrieb Ulf Zibis :
As you can see, I need to increase the ftyp box by 4 bytes to insert CEAP
Didn't you already verify that this is not the culprit?
Well, I only zeroed the 4 Bytes, but didn't shorten the
Am Di., 31. März 2020 um 02:30 Uhr schrieb Ulf Zibis :
> As you can see, I need to increase the ftyp box by 4 bytes to insert CEAP
Didn't you already verify that this is not the culprit?
Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
Am 14.03.20 um 20:39 schrieb Ted Park:
Maybe you should consider the possibility that it isn’t a technical limitation
of the decoder capability but something else introduced by proprietary metadata
or implementation detail.
There’s a huge user data box in the moov, upon a quick glance it
Am 16.03.20 um 01:43 schrieb Ulf Zibis:
I now inserted the following:
1. "CEAP" to ftyp (0x18 instead 0x14 bytes)
2. moov atom with qt-fast
3. udta atom from original at the start of moov atom (increases it from 0x1340E
to 0x1344A)
Result:
Instead of a big "?" I now see a the preview picture
Am Mo., 16. März 2020 um 01:43 Uhr schrieb Ulf Zibis :
>
>
> Am 14.03.20 um 21:08 schrieb Carl Eugen Hoyos:
> > Am Sa., 14. März 2020 um 20:39 Uhr schrieb Ted Park
> > :
> >
> >> Did you already test the following?
> >> $ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
> >
Am 16.03.20 um 09:10 schrieb Ted Park:
I took a look at the DCIM hierarchy on a canon point and shoot I found, and
there seems to be some sort of index type metadata stored separately in a
folder named (in my case) CANONMSC.
I don’t know what it is, or if it’s used, but see if deleting those
On Mon, Mar 16, 2020 at 04:10:57 -0400, Ted Park wrote:
> I’m not sure if you were asking about playback on the camera,
That's the whole point of the thread...
> Just curious, but what are you trying to do? Are you looking to play
> footage from other cameras? Or watch completely unrelated
Hi,
>> There’s a huge user data box in the moov, upon a quick glance it has the
>> camera model, firmware version, etc. I have to imagine it is used somehow.
>
> Same question:
> Is the (original) file still playable if you edit this atom?
I’m not sure if you were asking about playback on the
Am 16.03.20 um 01:43 schrieb Ulf Zibis:
Am 14.03.20 um 21:08 schrieb Carl Eugen Hoyos:
Am Sa., 14. März 2020 um 20:39 Uhr schrieb Ted Park :
Did you already test the following?
$ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
Then the codec time base remains
Of course.
The
Am 14.03.20 um 21:08 schrieb Carl Eugen Hoyos:
Am Sa., 14. März 2020 um 20:39 Uhr schrieb Ted Park :
Did you already test the following?
$ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
Then the codec time base remains
Of course.
The question is if the file is still playable
Am Sa., 14. März 2020 um 20:39 Uhr schrieb Ted Park :
> Did you already test the following?
> $ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
> >>> Then the codec time base remains
> >> Of course.
> >>
> >> The question is if the file is still playable after remuxing.
> > It
Am Sa., 14. März 2020 um 16:26 Uhr schrieb Ulf Zibis :
>
>
> Am 14.03.20 um 15:34 schrieb Carl Eugen Hoyos:
> > Am Sa., 14. März 2020 um 15:09 Uhr schrieb Ulf Zibis :
> >> Am 14.03.20 um 11:51 schrieb Carl Eugen Hoyos:
> >>> Did you already test the following?
> >>> $ ffmpeg -i MVI_1324.MOV
Hi,
>> Did the OP have the chance to upload some working camera-generated preview
>> files?
>
> I didn't ask for one because I don't have the necessary hardware to test...
I was the one who asked for them, I was thinking I would sort of inspect it for
some properties, like if the bitstream
Hi,
>> Here it is: https://cloud.disroot.org/s/fBeePRoA4JGZNMB
Ah, yes I did, thank you, sorry, I must have made a mental note to download it
after 15 mins then forgot about it because I have the attention span of a
goldfish.
Regards,
Ted Park
___
Am 14.03.20 um 15:34 schrieb Carl Eugen Hoyos:
Am Sa., 14. März 2020 um 15:09 Uhr schrieb Ulf Zibis :
Am 14.03.20 um 11:51 schrieb Carl Eugen Hoyos:
Did you already test the following?
$ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
Then the codec time base remains
Of course.
Hi Ted,
according a sample, didn't you receive this message?
-Ulf
Am 12.03.20 um 02:04 schrieb Ulf Zibis:
Am 12.03.20 um 01:40 schrieb Ted Park:
This particular error is because it parsed as video_track_timescale =
-map_metadata and output file named “0”.
... and how can I avoid this, or
Am Sa., 14. März 2020 um 15:41 Uhr schrieb Ted Park :
> Did the OP have the chance to upload some working camera-generated preview
> files?
I didn't ask for one because I don't have the necessary hardware to test...
Carl Eugen
___
ffmpeg-user mailing
Morning, ffmpeg-user
Did the OP have the chance to upload some working camera-generated preview
files? I did ask for some if possible, but mail delivery from this list has
been funky for my email for some reason the last few days...
Regards,
Ted Park
Am Sa., 14. März 2020 um 15:09 Uhr schrieb Ulf Zibis :
>
> Am 14.03.20 um 11:51 schrieb Carl Eugen Hoyos:
> >
> > Did you already test the following?
> > $ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
>
> Then the codec time base remains
Of course.
The question is if the file is
Am 14.03.20 um 11:51 schrieb Carl Eugen Hoyos:
Am Do., 12. März 2020 um 01:11 Uhr schrieb Ulf Zibis :
Am 12.03.20 um 00:07 schrieb Carl Eugen Hoyos:
Am Mi., 11. März 2020 um 23:56 Uhr schrieb Ulf Zibis :
compatible_brands: qt CAEP
What happens if you remove CAEP with a binary
Am 14.03.20 um 11:51 schrieb Carl Eugen Hoyos:
Did you already test the following?
$ ffmpeg -i MVI_1324.MOV -acodec copy -vcodec copy out.mov
Then the codec time base remains (but it does not compress the video, which is
my main purpose):
ffprobe MVI_1324_copy_git.mov
ffprobe version
Am Do., 12. März 2020 um 01:11 Uhr schrieb Ulf Zibis :
>
>
> Am 12.03.20 um 00:07 schrieb Carl Eugen Hoyos:
> > Am Mi., 11. März 2020 um 23:56 Uhr schrieb Ulf Zibis :
> >
> >> compatible_brands: qt CAEP
> > What happens if you remove CAEP with a binary editor?
>
> When I replace CAEP in the
On 2020-03-12T10:38:43+0100, Ulf Zibis wrote:
> Am 12.03.20 um 02:24 schrieb Ted Park:
>>> ... and how can I avoid this, or which argument should I pass to
>>> -video_track_timescale ?
>> Passing the timescale to that option would work I think.
> And which value should I choose?
See
Hi,
Am 12.03.20 um 10:38 schrieb Ulf Zibis:
Am 12.03.20 um 02:24 schrieb Ted Park:
Hi,
... and how can I avoid this, or which argument should I pass to
-video_track_timescale ?
Passing the timescale to that option would work I think.
And which value should I choose? (difficult to know,
Am 12.03.20 um 00:07 schrieb Carl Eugen Hoyos:
You can also try -video_track_timescale, this often was the
reason for incompatibilities.
Carl Eugen, can you please tell me how to get a reasonable value to use with
option -video_track_timescale ?
I don't find any hint in the docs.
-Ulf
Am 12.03.20 um 02:24 schrieb Ted Park:
Hi,
... and how can I avoid this, or which argument should I pass to
-video_track_timescale ?
Passing the timescale to that option would work I think.
And which value should I choose? (difficult to know, as "video_track_timescale"
is nowhere
Hi,
> ... and how can I avoid this, or which argument should I pass to
> -video_track_timescale ?
Passing the timescale to that option would work I think.
> frame= 32 fps=0.0 q=0.0 size= 0kB time=00:00:01.42 bitrate=
> 0.2kbits/sframe= 47 fps= 40 q=0.0 size= 0kB
On 03/11/2020 09:04 PM, Ulf Zibis wrote:
Am 12.03.20 um 01:40 schrieb Ted Park:
This particular error is because it parsed as video_track_timescale =
-map_metadata and output file named “0”.
... and how can I avoid this, or which argument should I pass to
-video_track_timescale ?
Did you
Am 12.03.20 um 01:40 schrieb Ted Park:
This particular error is because it parsed as video_track_timescale =
-map_metadata and output file named “0”.
... and how can I avoid this, or which argument should I pass to
-video_track_timescale ?
Did you upload a working sample file already? I
Hi,
> [NULL @ 0x56293d1e4d80] Unable to find a suitable output format for '0'
> 0: Invalid argument
This particular error is because it parsed as video_track_timescale =
-map_metadata and output file named “0”.
Did you upload a working sample file already? I want to see how basic the
camera
Am 12.03.20 um 00:07 schrieb Carl Eugen Hoyos:
You can also try -video_track_timescale, this often was the
reason for incompatibilities.
This results in an error (and I too can't find video_track_timescale in
the docs :-( ):
$ ffmpeg -i MVI_1324.MOV -c:a copy -profile:v baseline -level 4.1
Am 12.03.20 um 00:07 schrieb Carl Eugen Hoyos:
Am Mi., 11. März 2020 um 23:56 Uhr schrieb Ulf Zibis :
compatible_brands: qt CAEP
What happens if you remove CAEP with a binary editor?
When I replace CAEP in the original video with 4 0x00 it is still playable.
Here are the first 32
Am Mi., 11. März 2020 um 23:56 Uhr schrieb Ulf Zibis :
> compatible_brands: qt CAEP
What happens if you remove CAEP with a binary editor?
You can also try -video_track_timescale, this often was the
reason for incompatibilities.
Carl Eugen
___
Am 11.03.20 um 17:28 schrieb Ulf Zibis:
Am 11.03.20 um 13:50 schrieb Moritz Barsnick:
On Wed, Mar 11, 2020 at 13:25:45 +0100, Ulf Zibis wrote:
Anyway, does my command line have the right syntax?
ffmpeg -i MVI_1324.MOV -c:a copy -c:v h264_vaapi -profile:v
constrained_baseline -level 4.1
Am 11.03.20 um 13:50 schrieb Moritz Barsnick:
On Wed, Mar 11, 2020 at 13:25:45 +0100, Ulf Zibis wrote:
Anyway, does my command line have the right syntax?
ffmpeg -i MVI_1324.MOV -c:a copy -c:v h264_vaapi -profile:v
constrained_baseline -level 4.1 MVI_1324.mov
It's syntactically correct, but
On Wed, Mar 11, 2020 at 13:25:45 +0100, Ulf Zibis wrote:
> Anyway, does my command line have the right syntax?
> ffmpeg -i MVI_1324.MOV -c:a copy -c:v h264_vaapi -profile:v
> constrained_baseline -level 4.1 MVI_1324.mov
It's syntactically correct, but it won't suffice. You need some more
Am 11.03.20 um 13:05 schrieb Moritz Barsnick:
On Wed, Mar 11, 2020 at 00:47:42 +0100, Ulf Zibis wrote:
It looks like it was built without support?
What is the difference, if I build it myself concerning support?
When configuring and building, you need the (development support for)
libva
On Wed, Mar 11, 2020 at 00:47:42 +0100, Ulf Zibis wrote:
> > It looks like it was built without support?
> What is the difference, if I build it myself concerning support?
When configuring and building, you need the (development support for)
libva present. ./configure has this check:
> enabled
Am 10.03.20 um 23:52 schrieb Ted Park:
Hi,
This profile is only available with VAAPI encoder, see
libavcodec/vaapi_encode_h264.c
or amfenc encoder, see libavcodec/amfenc_h264.c
So I tried:
$ ~/Projects/ffmpeg/ffmpeg-git-20200211-amd64-static/ffmpeg -i MVI_1324.MOV
-c:a copy -c:v h264_vaapi
Hi,
> This profile is only available with VAAPI encoder, see
> libavcodec/vaapi_encode_h264.c
> or amfenc encoder, see libavcodec/amfenc_h264.c
>
> So I tried:
> $ ~/Projects/ffmpeg/ffmpeg-git-20200211-amd64-static/ffmpeg -i MVI_1324.MOV
> -c:a copy -c:v h264_vaapi -profile:v
Am 29.02.20 um 00:50 schrieb Ulf Zibis:
I tried with "-profile:v baseline -level 3.0" from here;
https://trac.ffmpeg.org/wiki/Encode/H.264#Compatibility
Unfortunately this didn't help.
As I don't find any documentation on this at
Am Mi., 4. März 2020 um 13:12 Uhr schrieb Ulf Zibis :
>
>
> Am 04.03.20 um 04:51 schrieb Tom Sparks:
> > On 04/03/2020, Ulf Zibis wrote:
> >> Anyway, isn't x264 part of ffmpeg?
> >>
> >> To me it looks it is:
> >> https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
> > no, x264 is
Am 01.03.20 um 09:56 schrieb Paul B Mahol:
On 3/1/20, Moritz Barsnick wrote:
Well, the wiki claims:
If you want your videos to have highest compatibility with ancient
devices (e.g., old Android phones):
-profile:v baseline -level 3.0
and regarding iOS compatability of these
Am 04.03.20 um 04:51 schrieb Tom Sparks:
On 04/03/2020, Ulf Zibis wrote:
Anyway, isn't x264 part of ffmpeg?
To me it looks it is:
https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
no, x264 is done by the VLC community
Following your argumentation, ffmpeg should not document
On 04/03/2020, Ulf Zibis wrote:
>
> Am 04.03.20 um 00:52 schrieb Carl Eugen Hoyos:
>> Am Mi., 4. März 2020 um 00:50 Uhr schrieb Ulf Zibis :
>>> Am 01.03.20 um 18:13 schrieb Carl Eugen Hoyos:
Both the level and the profile options are mentioned in the
documentation.
>>> But not it's
Am Mi., 4. März 2020 um 00:50 Uhr schrieb Ulf Zibis :
>
> Am 01.03.20 um 18:13 schrieb Carl Eugen Hoyos:
> > Both the level and the profile options are mentioned in the
> > documentation.
> But not it's possible values :-(
As you found out (I didn't know), the ones that are related to
FFmpeg are
Am 01.03.20 um 18:13 schrieb Carl Eugen Hoyos:
Both the level and the profile options are mentioned in the
documentation.
But not it's possible values :-(
People knowing how h264 works know about "levels" and "profiles"
May be.
The FFmpeg documentation should not explain what levels and
Am Sa., 29. Feb. 2020 um 01:17 Uhr schrieb Carl Eugen Hoyos
:
>
> Am Sa., 29. Feb. 2020 um 00:50 Uhr schrieb Ulf Zibis :
>
> > As I don't find any documentation on this at
> > https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
> > maybe there are more levels and variations ... where
On 3/1/20, Moritz Barsnick wrote:
> Ulf Zibis wrote:
>> I tried with "-profile:v baseline -level 3.0" from here;
>
> On Sat, Feb 29, 2020 at 01:17:29 +0100, Carl Eugen Hoyos wrote:
>> "This" will encode a video that is not compatible with any player
>> except FFmpeg-based software.
>
> Well,
Ulf Zibis wrote:
> I tried with "-profile:v baseline -level 3.0" from here;
On Sat, Feb 29, 2020 at 01:17:29 +0100, Carl Eugen Hoyos wrote:
> "This" will encode a video that is not compatible with any player
> except FFmpeg-based software.
Well, the wiki claims:
If you want your videos to
Am Sa., 29. Feb. 2020 um 00:50 Uhr schrieb Ulf Zibis :
> As I don't find any documentation on this at
> https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
> maybe there are more levels and variations ... where do I find more or
> complete documentation on this?
"This" will encode
I tried with "-profile:v baseline -level 3.0" from here;
https://trac.ffmpeg.org/wiki/Encode/H.264#Compatibility
Unfortunately this didn't help.
As I don't find any documentation on this at
https://www.ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
maybe there are more levels and
Hey Moritz,
much thanks for your great suggestions. They sound really good. I'll try
all that.
-Ulf
Am 16.02.20 um 13:53 schrieb Moritz Barsnick:
On Sun, Feb 16, 2020 at 13:49:56 +0100, Moritz Barsnick wrote:
Note the "Constrained Baseline".
Alas, I don't know how to tell ffmpeg/libx264 to
On Sun, Feb 16, 2020 at 13:49:56 +0100, Moritz Barsnick wrote:
> Note the "Constrained Baseline".
>
> Alas, I don't know how to tell ffmpeg/libx264 to use this profile -
> only "Baseline".
D'uh, I just noticed that using "-profile:v baseline" will get you a
Contrained Baseline output. I still
On Sun, Feb 16, 2020 at 09:58:16 +0100, Ulf Zibis wrote:
> When I copy them back to the camera, they are no more playable on the
> camera. Damn, I wanted to save space on the memory card.
>
> Does anyone have an idea, which options maybe could help to get a
> compatible format for my camera?
Hi,
on my Canon PowerShot A2200 I have some movies in Quicktime format.
I can compress them 5x without any visible quality lost.
When I copy them back to the camera, they are no more playable on the
camera. Damn, I wanted to save space on the memory card.
Does anyone have an idea, which
62 matches
Mail list logo
