On 09/12/15 08:43, 浪漫﹀ァ旋律 wrote:
> I'm sorry, my English is not good.The error information in the appendix.For
> help
I'm not sure what your build system is, but rake is a ruby program and
nothing to do with ffmpeg.
As such this must be a specialist set up, and you are unlikely to find
anyone he
On 17/11/15 18:12, Leonard Bogard wrote:
> Looks like you're not blind as I also can't find a download link to the
> source he's using to compile the binaries on his site.
>
> On Tue, Nov 17, 2015 at 9:55 AM, John Pilgrim wrote:
>
>> Thanks, but I'm looking for the source code not the binaries.
On 16/09/15 07:12, Irfan Saleem wrote:
> Hi,
>
> I am facing a issue while playing and converting a media taken from Ikegami
> GFPack. Please find below FFPLAY and FFMPEG consoles:
>
> *FFPLAY: *
> C:\Program Files\ffmpeg\ffmpeg-20150629\bin>ffplay.exe
> "D:\data\irfans\Downloads
> \0001V002(1).M
On 21/07/15 13:28, Moritz Barsnick wrote:
> Hi Zsolt,
>
> On Tue, Jul 21, 2015 at 14:10:13 +0200, Osztrovszky Zsolt wrote:
>> As you can see in line 20, the input video is hevc Main 10, but the encoder
>> still coding it to Main profile, 8 bit (line 27).
>> It also says in line 23: incompatible p
On 21/07/15 09:15, Osztrovszky Zsolt wrote:
> Hello Guys,
> I’d like to create an h265 video with Main10 profile (10 bits).
> However ffmpeg keeps saying that profile=main10 is an unknown option.
ISTR that x265 profiles are not yet supported, however you can still
make a MAIN10 file by setting oth
On 16/06/15 12:20, Christoph Gerstbauer wrote:
>>> Hello Tim,
>>>
>>> for IMX30 PAL/NTSC I have the same values like you.
>>>
>>> whats your buffers/init_occupancy for IMX50 NTSC?
>>>
>> Not sure I've ever had to do it, but a colleague uses an exact 5000
>> bit rate which gives a 1668334 buffer
On 16/06/15 09:33, Christoph Gerstbauer wrote:
>
>>> 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50 for PAL
>>> and NTSC? I want to compare it to mine.
>> Mine look remarkably similar to yours except for the ommission of 'ilme'
>> which makes no sense for an I frame only format.
>>
On 15/06/15 09:39, Christoph Gerstbauer wrote:
>
>>> 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50 for PAL
>>> and NTSC? I want to compare it to mine.
>> Mine look remarkably similar to yours except for the ommission of 'ilme'
>> which makes no sense for an I frame only format.
>
On 14/06/15 22:39, Christoph Gerstbauer wrote:
i seem to have missed this reply, my question is basicylly the same
as tims, where does the limit resulting in 3920 come from ?
>>> Hi, I compared different encoder IMX40 formats, and all of these format
>>> has a pkt size of 166833bytes
On 08/06/15 17:53, Christoph Gerstbauer wrote:
>
>
> Am 08.06.15 um 17:24 schrieb Michael Niedermayer:
>> On Wed, Jun 03, 2015 at 04:28:48PM +0200, Christoph Gerstbauer wrote:
> yes, this happens because 50mbit/sec is not correct
> a max framesize of 208541 results in a bit rate of max
>>
On 08/06/15 16:24, Michael Niedermayer wrote:
> On Wed, Jun 03, 2015 at 04:28:48PM +0200, Christoph Gerstbauer wrote:
yes, this happens because 50mbit/sec is not correct
a max framesize of 208541 results in a bit rate of max
49.999840 mbit/sec, IIUC thats what the spec means by 50mbi
On 08/06/15 15:19, Christoph Gerstbauer wrote:
>
>
> [..]
> Hello Michael, hello Tim!
>
> I have still a little problem with IMX40 with NTSC:
>
> I need to set the paketsize (framesize) at IMX40 NTSC to 166833bits.
> For that I need a bitrate of: 3920
>
> FFmpeg fails because this bitrate
On 04/06/15 12:58, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>>> Why do you want to lie, anyway?
>>
>> In my case I was using codec copy, so I was simply
>> trying to represent the original coder, rather than
>> just the mux
On 04/06/15 12:06, Kuban Altan wrote:
> On Tue, May 5, 2015 at 8:41 AM, tim nicholson <
> nichot20-at-yahoo@ffmpeg.org> wrote:
>
>> On 05/05/15 15:52, Christoph Gerstbauer wrote:
>>>
>>>
>>> Am 05.05.2015 um 09:06 schrieb tim nicholson:
>>
On 02/06/15 14:38, Moritz Barsnick wrote:
> On Fri, May 22, 2015 at 14:53:52 +, Kevin Wells wrote:
>
>> [..]
>> Output #0, mov, to 'out.mov':
>> Metadata:
>> major_brand : qt
>> minor_version : 537199360
>> compatible_brands: qt
>> encoder : Lavf56.33.101
>>
On 01/06/15 19:53, Michael Niedermayer wrote:
> On Mon, Jun 01, 2015 at 04:43:12PM +0200, Christoph Gerstbauer wrote:
>> Hello
>>
>> I am testing the standard "conformness" of ffmpegs IMX50 (Mpeg2
>> I-frame, MXF) encoder.
>>
>> I mentioned via ffprobe or via encoding that ffmpeg does encode a
>> N
On 21/05/15 09:05, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>>> It seems to me that the scale filter is so smart
>>> that it doesn't scale if the input and output
>>> resolution and input and output colourspace
>>> are
On 19/05/15 22:06, Carl Eugen Hoyos wrote:
> Christoph Gerstbauer gmail.com> writes:
>
>> C:\Windows\System32>ffmpeg -i
>> C:\Users\Administrator\Desktop\big_buck_bunny_ffvhuff.avi -vf
>> "scale=in_range=full:out_range=tv" -vcodec ffvhuff
>
> It seems to me that the scale filter is so smart
> t
On 17/05/15 13:05, Carl Eugen Hoyos wrote:
> Christoph Gerstbauer gmail.com> writes:
>
>>> do you realise that valid (specification-compliant)
>>> broadcast-range video may contain values < 16 and > 235?
>>
>> Hello Carl, no, I don´t.
>> Can you explain this to me?
>> I always thought that SD br
On 11/05/15 12:59, tim nicholson wrote:
> Thanks for the confirmation that it s not ffmpeg.
>
>[..]
In fact it is related to:-
http://sourceforge.net/p/graphicsmagick/bugs/131/
and for some bizzare reason Ubuntu/Mint do not build it with 16 bit
support, my SuSE box is fine...
--
On 11/05/15 12:32, Moritz Barsnick wrote:
> On Mon, May 11, 2015 at 10:59:45 +0100, tim nicholson wrote:
>>>> identify -verbose dpx-HD-0001.dpx
>>> Image: dpx-HD-0001.dpx
>>> Format: DPX (SMPTE 268M-2003 (DPX 2.0))
>>> Geometry: 1920x1080
>&
On 11/05/15 10:54, tim nicholson wrote:
> The default -pix_fmt for dpx when provided with a yuv422p10le source
> file appears to be rgb48be, which seems reasonable enough.
>
> However upon inspection of the created dpx it appears to be only rgb24
> which is not what I would hav
The default -pix_fmt for dpx when provided with a yuv422p10le source
file appears to be rgb48be, which seems reasonable enough.
However upon inspection of the created dpx it appears to be only rgb24
which is not what I would have expected. Can anyone shed light on this?:-
>ffmpeg -i "prores-HD.
On 05/05/15 15:52, Christoph Gerstbauer wrote:
>
>
> Am 05.05.2015 um 09:06 schrieb tim nicholson:
>> [...]
>>
>> The tricky bit is to decide what to do if the values aren't manually
>> specified. According to the specs there is no "default" valu
On 02/05/15 14:38, Christoph Gerstbauer wrote:
>
>
> Am 01.05.15 um 11:21 schrieb tim nicholson:
>> [..]
>> Christoph do you actually require the mxf metadata setting (as it really
>> ought to be, and what I thought you were after) or are you content with
>> it
On 30/04/15 22:03, Marton Balint wrote:
>
> On Wed, 29 Apr 2015, Christoph Gerstbauer wrote:
>
>> I found out that a IMX50 mxf file encoded with FFmbc and the IMX50 mxf
>> file encoded with actual ffmpeg builds are different in these mxf
>> metadata flags (by reading out via ffprobe - show_stream
On 30/04/15 07:20, Christoph Gerstbauer wrote:
> Hello
>
> I am making tests with IMX50/MXF encodings with FFMBC and FFMPEG. (with
> 24bit audio and 16bit audio)
> [...]
Reeatedly asking the same question in a new thread, without waiting a
resonable time for a reply, is begining to get tedious a
On 29/04/15 22:22, Christoph Gerstbauer wrote:
> I found out that a IMX50 mxf file encoded with FFmbc and the IMX50 mxf
> file encoded with actual ffmpeg builds are different in these mxf
> metadata flags (by reading out via ffprobe - show_streams)
>
> FFMBC IMX FILE stream 0:0:
> color_range=tv
>
On 28/04/15 18:02, Mohammadtorabi wrote:
> Hi,I have created an iFrame only MXF file by the command below using
> [...snipped densely packed forest of words]
Was there a question in there somewhere? I couldn't see the wood for the
trees due to the lack of formating.
--
Tim.
Key Fingerprint 38CF
On 28/04/15 09:20, Christoph Gerstbauer wrote:
> Hello
>
> I am making tests with IMX50/MXF encodings with FFMBC and FFMPEG. (with
> 24bit audio)
> The tests compare the final files with the IRT MXF Analyzer Pro tool to
> be shure to be IRT conform.
> (My used syntax is at the bottom of this mail)
On 23/04/15 09:54, Marco Porsch wrote:
> Hi,
>
> when encoding an 8bit grayscale video using the commandline
> # ffmpeg.exe -f rawvideo -vcodec rawvideo -pix_fmt gray -s 1280x960 -r 30 -i
> out8.yuv -c:v libx264 -qp 0 -preset ultrafast -y out8.mkv
> and decoding using
> # ffmpeg.exe -i out8.mkv -
On 13/04/15 11:48, Christoph Gerstbauer wrote:
>>
>> Therfore I think the only sane approach would be to have them as user
>> settable flags which would take more careful thinking about...
> Yes, sorry, I didnt said it detailed: Yes a flag which can be enabled by
> the user would be the best soluti
On 13/04/15 08:34, Christoph Gerstbauer wrote:
>
> Hello Tim,
>
> do you think that these flags can also be implemented into the IMX
> encoding of ffmpeg?
>
> + SIGNAL STANDARD = 1
> (ITU 601)
> + Color siting = 4
> (Rec 601)
>
> [..]
They could easily be hardcoded in, however they could t
On 08/04/15 15:27, Thomas Seilund wrote:
> Hi All
>
>
What has this to do with "[FFmpeg-user] Faster vp9" ?
If you want to start a new subject, then please start a new thread, do
*not* hijack an existing thread and simply change the Subject, it
confuses thread following email clients.
If you w
On 07/04/15 15:18, Matt Zagrabelny wrote:
> On Mon, Apr 6, 2015 at 11:10 PM, Andrew Sinclair wrote:
>> Hi,
>>
>> Does anyone have any suggestions for faster vp9 encoding?
>
> Hi Andrew,
>
> I don't have the ffmpeg technical chops to analyze your command-line,
> but I just came across a Google VP
On 05/04/15 10:23, Roee Kashi wrote:
> just mentioning, adding " | OUT_INPUT" to vtag option indeed sort it out.
> i hope it will get into git-master one day :)
>
I think you will find it happened the same day :)
> thanks
>
> [..]
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0
On 02/04/15 16:45, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>>> "ffmpeg.exe -f rawvideo -vcodec rawvideo -s 704x576
>>> -r 25 -pix_fmt yuv420p -vtag YV12 -i raw.yuv -f avi
>>> -qscale 0 out.avi"
>>
>> Ahh, so yo
On 02/04/15 16:11, Roee Kashi wrote:
> first, since my rawvideo input is YV12 and there's no such pix_fmt, yuv420p
> without vtag results with a blue-pink video output.
I guess because its decoding it as yuv not yvu
> second, before vtag supported input files, i had to convert the file first
> to
On 02/04/15 15:22, Roee Kashi wrote:
> Hi,
>
> with the older ffmpeg version (described earlier), my command line looks
> like this:
> "ffmpeg.exe -f rawvideo -vcodec rawvideo -s 704x576 -r 25 -pix_fmt yuv420p
> -vtag YV12 -i raw.yuv -f avi -qscale 0 out.avi"
Ahh, so you are using the pix_fmt to
On 02/04/15 13:56, Roee Kashi wrote:
> Hi,
>
> back in 2012 I could use -vtag on an input rawvideo file, thus tell ffmpeg
> the pixel format is YV12.
>
> at a certain point there was a regression in that feature so vtag is again
> allowed only for outputs.
>
> currently since I have to convert Y
On 02/04/15 11:00, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>>
> http://mdsh.com/patches/ffmbc_0.7rc8/FFmbc-0.7-rc8_vf_framerate-2013051301.patch
>
> Is there a reason you are not sending a pull request
> from your git repository?
> (t
On 31/03/15 17:11, Robert Krüger wrote:
> On Tue, Mar 31, 2015 at 5:58 PM, Carl Eugen Hoyos wrote:
>
>> Robert Krüger lesspain.de> writes:
>>
>>> I think Mark mentioned once the intent to port it to
>>> ffmpeg but I am not sure. If you're in a hurry, you
>>> can apply it to ffmbc and use that (I
On 23/03/15 09:45, Christoph Gerstbauer wrote:
>>
>> If it works for you I will submit a tidied up version, with revised fate
>> checksums, but that will have to wait awhile as I'm away next week...
>
> Hello Tim!
> thank you, it works for PAL and NTSC (720x512/720x480) but there is a
> [..]
A (m
On 30/03/15 09:44, tim nicholson wrote:
> On 30/03/15 08:33, Christoph Gerstbauer wrote:
>>>> Hello Tim!
>>>> thank you, it works for PAL and NTSC (720x512/720x480) but there is a
>>>> just little bug for NTSC when encoding to 720x486 in "stored
On 30/03/15 08:33, Christoph Gerstbauer wrote:
>>> Hello Tim!
>>> thank you, it works for PAL and NTSC (720x512/720x480) but there is a
>>> just little bug for NTSC when encoding to 720x486 in "stored dimension"!
>> My patch only deals with the addition of the display y offset metadata,
>> it shoul
On 23/03/15 09:45, Christoph Gerstbauer wrote:
>>
>> If it works for you I will submit a tidied up version, with revised fate
>> checksums, but that will have to wait awhile as I'm away next week...
>
> Hello Tim!
> thank you, it works for PAL and NTSC (720x512/720x480) but there is a
> just littl
On 20/03/15 15:21, tim nicholson wrote:
> On 20/03/15 09:19, tim nicholson wrote:
>> On 19/03/15 15:48, Christoph Gerstbauer wrote:
>>>
>>>> Shame, don't understand the qmax issue. but if you look at:-
>>>>
>>>> tests/lavf_regression.sh
On 20/03/15 09:19, tim nicholson wrote:
> On 19/03/15 15:48, Christoph Gerstbauer wrote:
>>
>>> Shame, don't understand the qmax issue. but if you look at:-
>>>
>>> tests/lavf_regression.sh line 90
>>>
>>> you will see an IMX30 example whi
On 19/03/15 15:48, Christoph Gerstbauer wrote:
>
>> Shame, don't understand the qmax issue. but if you look at:-
>>
>> tests/lavf_regression.sh line 90
>>
>> you will see an IMX30 example which uses -qmax 12 and my other other
>> parameters. However not sure what difference closed/open gop makes o
On 19/03/15 13:38, Christoph Gerstbauer wrote:
>> Don't know if its relevant but your coding parameters are slightly
>> different to the one's I use for D10, and I wonder if this affects the
>> automatic metadata insertion..
>>
>>
>> "-flags +ildct+ilme+low_delay"
>>
>> Well ilme seems kind of redu
On 18/03/15 09:46, Christoph Gerstbauer wrote:
> Hello
>
> I am testing with ffmpeg the IMX50 D10 encoding, and I am very close to
> my target but I have to create 3 metadata values in the MXF header which
> is standard in most IMX50 MXF ecndodings:
>
> + SIGNAL STANDARD = 1 (ITU 601)
> + display
On 16/03/15 11:54, Christoph Gerstbauer wrote:
>> Yes, smpte S268 refers to field 66 as "Temporal sampling rate or frame
>> rate (Hz)".
>>
>> Pity the two projects use different labels for the standard fields its
>> easy to miss which matches what as it stands
>>
>>
> Do you have an more actual
On 16/03/15 11:17, Christoph Gerstbauer wrote:
>> Imagemagick claims to support:-
>>
>> dpx:film.frame_rate
>> dpx:television.frame_rate
>>
>> Graphicsmagick:-
>>
>> dpx:mp.frame.rate
>>
> Thank you, Tim!
>
> I found also two at graphics magick:
>
> dpx:mp.frame.rate
> tv.temporal.sampling.rate
On 14/03/15 11:35, Christoph Gerstbauer wrote:
>> ISTR that imagemagick/graphicsmagick have quite good DPX metadata
>> extraction
>>
>> "$ [gm] identify -verbose some-file.dpx"
>>
>> see:-
>>
>> http://www.imagemagick.org/script/motion-picture.php
>>
>> and
>> http://www.graphicsmagick.org/motion-p
On 12/03/15 16:09, Christoph Gerstbauer wrote:
>
> [..]
> There exist one DPX metadata reader/editor only for MAC OS.
> Which this tool I checked the FrameRate values in the DPX: most DPX had
> no value written, so ffmpeg GUESSES the fps I think.
> One DPX had the value 24fps, but FFmpeg also show
On 03/02/15 08:23, Moritz Barsnick wrote:
> Hi Hany,
>
> On Tue, Feb 03, 2015 at 01:01:57 +, Eng.Hany Ahmed wrote:
>
>> Helloi have videos have logo in the top of the corner i want make
>> pixelate blur for this logo like in the photo
>
> In which photo?
>
>> i tried to using water mark bu
On 23/01/15 16:14, Christian Foerster wrote:
> Hi all,
>
>
> I'm trying to convert a file to DNxHD 120 (as DNxHD 85 doesn't seem to be
> supported). It fails because I'm apparently using some wrong parameter. Can
> anyone point me to where I went wrong?
>
> Thanks a lot,
> Christian
>
>
> This
On 22/01/15 14:04, Kevin Wells wrote:
> Hi, I am downscaling an HD movie from 1920x1080 to 720x576 and want to make
> sure the color conversion is done correctly, which with my current settings I
> am sure it is not. I am coming from an HD Prores HQ, going to an SD Prores
> HQ.With my current co
On 09/01/15 15:30, Valentin NOEL wrote:
> 2015-01-09 15:29 GMT+01:00 tim nicholson :
>
>> [...]
>> It means that I was making a pragmatic suggestion for something you
>> could try immediately to solve your issue, rather than trying to get
>> bogged down
eeded ?
>
It means that I was making a pragmatic suggestion for something you
could try immediately to solve your issue, rather than trying to get
bogged down in technical details too early.
> Thanks.
>
> 2015-01-09 12:56 GMT+01:00 tim nicholson :
>
>> On 09/01/15 10:06
On 09/01/15 10:06, Valentin NOEL wrote:
> Hi to all,
>
> I would like to encode MPEG-2 video with closed GOP of 12 frames, and a
> structure like IBBPBBPBBPBB.
>
> For doing this, I am using these options :
> *-g 12* to set the GOP size
> *-bf 2* to set the max B frames between reference frames
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/14 19:02, Clément Bœsch wrote:
> On Mon, Dec 01, 2014 at 08:01:13PM +0100, Clément Bœsch wrote:
>> On Mon, Dec 01, 2014 at 04:46:36PM +0000, tim nicholson wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/14 18:39, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIII, tim nicholson a écrit :
>> Whilst acknowledging that this patch works (thanks), I am trying to
>> understand why package config is failing in this case,
er starttime than
> zero?
I suspect its just convenient for Premiere to do it that way, maybe due
to where an I frame sits on the originsal material.
>
> it's not always trivial to me :-)
>
> thanks
>
> 2014-12-01 8:49 GMT+01:00 tim nicholson :
>
>> On 28/1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/12/14 16:09, Nicolas George wrote:
> Le primidi 11 frimaire, an CCXXIII, tim nicholson a écrit :
>> Whilst acknowledging that this patch works (thanks), I am trying to
>> understand why package config is failing in this case,
>
On 28/11/14 09:55, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>> Thought I'd have a go at this, but suffered an odd epic fail.
>
> Use this patch as a work-around:
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178167
>
Whilst ack
On 28/11/14 14:50, Guido Holz wrote:
> my problem is after exporting from Adobe Premiere and postwork with ffmpeg
> I get more frames of each mp4-footage. I minimalized it to the following
> example:
>
> [...]
> :\> ffmpeg.exe -i before.mp4
> [...]
> Duration: 00:02:00.00, start: 0.04, bitra
On 28/11/14 09:55, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>> Thought I'd have a go at this, but suffered an odd epic fail.
>
> Use this patch as a work-around:
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/178167
>
thanks Carl,
Thought I'd have a go at this, but suffered an odd epic fail.
x265 builds and installs fine, and the standalone at least responds to
x265 -h.
there are the expected:-
/usr/local/lib64/x265.a
/usr/local/lib64/pkgconfig/x265.pc
/usr/local/include/x265.h
/usr/local/include/x265_config.h
however ./c
On 14/10/14 13:07, Celal Yasar Sahinoz wrote:
> Dear All,
> Just joined the mailing list.
Then please take a moment to check on the ml etiquette.
Specifically please do not:-
1/. top post
2/. Hijack existing threads
In order to avoid further pollution of the existing thread please do
*not* repl
On 10/10/14 23:46, Alex wrote:
> Thats absolutely clear, but I want to use ffmpeg to solve that issue.
>
Have you actually tried a later version of ffmbc? Baptiste said the
issue would be fixed in the next version...
> Alex
> [...]
--
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC4
On 09/10/14 15:16, Alex wrote:
> Ok, I've found the cause. Sometimes it is nesscary to trim the first 5
> seconds of videofile. Therefor I use "-ss 00:00:05". The result is:
>
> Output #0, mxf, to 'C:\Users\FiebigA\Desktop\File_MXF.mxf':
> Metadata:
> encoder: FFmbc 0.7
Two observations, fi
On 25/09/14 21:05, Steve Smith wrote:
> Is there a way using ffprobe or ffmpeg to view the atom metadata that is
> viewable using the AtomicParsley utility? I have a mp4 file that is causing
> AtomicParsley to crash when I try to pull the metadata. I've opened the file
> in a hex editor and I can s
On 25/09/14 22:16, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>> I have also found using vframes problematical in that
>> you tend to get inconsistent mvhd and mdhd atoms unless
>> you also use -shortest, while using -t is fine.
>
> This
On 23/09/14 19:47, Carl Eugen Hoyos wrote:
> César Sepúlveda mediastre.am> writes:
>
>> $ ffmpeg -y -i gop_10.mp4 -acodec aac -strict -2
>> -vcodec libx264 -ss 5.00500 -vframes 60 -level 31
>> -profile:v baseline 1.mp4
>
> You may try -vsync 0 or another container because
> our mov muxer tends
On 17/09/14 11:05, Peter B. wrote:
> Hello,
>
> I've noticed that using ffprobe to analyze an FFV1/AVI file, it only
> utilizes a part of the available CPU power.
> For example, the following command:
>
> //--
> $ ffprobe_git -f lavfi -i
> "movie=qctool
On 10/09/14 07:59, Carl Eugen Hoyos wrote:
> Dave Rice dericed.com> writes:
>
>>> h264 in avi is not going to be understood
>>> by much other than ffmpeg...
>
> Since this was quoted a few times, I'd like to
> repeat that H264 in avi works fine with WMP.
> (Contrary to any other output contain
On 08/09/14 09:19, Carl Eugen Hoyos wrote:
> tim nicholson ffmpeg.org> writes:
>
>>>> I want to take a video at 60fps and convert it
>>>> to 24fps, without adding or dropping frames.
>>>
>>> Use the input option -r.
>>
>> which
On 07/09/14 15:01, Carl Eugen Hoyos wrote:
> Elliott Balsley gmail.com> writes:
>
>> I want to take a video at 60fps and convert it to 24fps,
>> without adding or dropping frames.
>
> Use the input option -r.
>
which is ignored if using stream copy...
or was in my testing:-
ffmpeg -r 25 -i "
On 03/09/14 16:59, Elliott Balsley wrote:
> Hello,
> I want to take a video at 60fps and convert it to 24fps, without adding or
> dropping frames. So the duration would be 2.5 times longer and the video
> would play in slow motion. I realize the setpts filter can do this, but I’d
> like to avo
On 02/09/14 17:11, Andy Young wrote:
>>> On Tuesday, September 2, 2014 2:21 AM, Damian Głodny
>>> wrote:
>
>>> Hi, Arno. Thank you for advice, I will check it. I also found some
>>> information
>>> about converting videos from 29.970 to 23.976:
>>>
>>> https://documentation.apple.com/en/finalcu
81 matches
Mail list logo
