When displaying a frame count number in the drawtext filter, the varying height
of the characters can make the text jitter vertically as they count. Its
possible to stop this by applying the ‘ascent' value to the y coordinate.
However when the drawtext filter contains a box, this element also
Is there or has there ever been any support for an invisible watermarking
filter in ffmpeg? Or perhaps there is an external project that supports this?
This (now closed) job posting that someone listed a while ago, outlines what I
would be looking for:
> On 8 Mar 2018, at 23:37, Mark Burton <mwjbur...@gmail.com> wrote:
>
> On 8 Mar 2018, at 22:29, Carl Eugen Hoyos <ceffm...@gmail.com
> <mailto:ceffm...@gmail.com>> wrote:
>> One possibility is that you run "git diff libavformat/movenc.h" to
On 8 Mar 2018, at 22:29, Carl Eugen Hoyos wrote:
> One possibility is that you run "git diff libavformat/movenc.h" to verify you
> have only changed this one value (this assumes you have originally done
> "git clone" and not "curl..."), then run "git commit
On 8 Mar 2018, at 17:21, Carl Eugen Hoyos wrote:
> You need a compiler, make and git. Iirc, all three are installed if you
> type something like "gcc -v" on the command line (but I assume they
> are now installed by brew).
Thank you very much! That filled in a few blanks for
On 8 Mar 2018, at 16:38, Carl Eugen Hoyos <ceffm...@gmail.com> wrote:
> 2018-03-08 15:57 GMT+01:00, Mark Burton <mwjbur...@gmail.com>:
>>
>> Understood. A better option would no doubt be the ability to specify this
>> value in the same way we can specif
On 8 Mar 2018, at 11:03, Carl Eugen Hoyos wrote:
> It is zero as long as nobody confirms that this would fix the issue you see.
Understood. A better option would no doubt be the ability to specify this value
in the same way we can specify the video_track_timescale value.
On 7 Mar 2018, at 00:45, Mark Burton <mwjbur...@gmail.com> wrote:
> Does it help if you edit MOV_TIMESCALE in libavformat/movenc.h?
What are the chances that this value could be changed to a much higher and more
useful value?
Does anyone know why 1000 w
On 7 Mar 2018, at 00:24, Carl Eugen Hoyos wrote:
> Could you elaborate a little?
> What kind of issues?
>
> Does it help if you edit MOV_TIMESCALE in libavformat/movenc.h?
The files are being used in software (Conformalizer) that seeks to specific
points in the Quicktime
When I run my 24fps Quicktime mov files through an FFmpeg transcode they are
coming out with a Movie Header timescale of 1000, when the source file has a
timescale of 24000. This low timescale value is causing issues in some
professional software tools when seeking the file.
In my case the
The latest nightly of Handbrake includes an option to add the sample group atom
as well as the edit list. This is much more successful than the current ffmpeg
mux when playing in QT X. Its still ignored in older QT decoders, but certainly
this would be an improvement if ffmpeg could follow the
On 1 Jul 2017, at 20:24, Sasi Inguva <isasi-at-google@ffmpeg.org> wrote:
>> On Sat, Jul 1, 2017 at 6:56 AM, Mark Burton [via FFmpeg-users]
>> How about this for a partial solution - ffmpeg supports the audiotoolbox
>> aac encoder on macOS. For the sake of being a
> On 28 Jun 2017, at 01:12, Sasi Inguva wrote:
> I have been helping Mark test Marton's patch. I looked at the test file Mark
> was using to test the sync. There are multiple reasons for audio being
> off-sync.
>
> i) That file doesn't contain a non-zero edit
On 19 Jun 2017, at 22:38, Marton Balint wrote:
> Can you measure how many samples are the delay before and after my patch? I'd
> rather do some additional testing now, instead committing something that is
> only half-correct.
I’ve reached out to the developer who was helping
On 16 Jun 2017, at 10:17, ffm...@me.com wrote:
> I agree with Mark here.
> Followed the issue now for a while and opened a similar (not went into this
> deep technical level) issue some time ago.
>
> I guess it should be marked as a bug and - if possible - should be fixed.
> Thanks, Andreas
> On 15 Apr 2017, at 13:25, Christian Ebert wrote:
> * Marton Balint on Saturday, April 15, 2017 at 12:25:58 +0200
>> On Sat, 15 Apr 2017, Christian Ebert wrote:
>>> * Marton Balint on Saturday, April 15, 2017 at 07:55:22 +0200
Last time I checked (a year ago or so),
I appreciate I don't fully grasp the complexities or know the full story here,
but do you not think its fair to say this should be considered a major ffmpeg
bug or issue? It seems clear to me, and others, that the current .mov muxer
produces a file which is incompatible with Quicktime itself.
On 26 May 2017, at 12:53, Christian Ebert > wrote:
> Yeah, filtering does not add an edit list (apparently the
> 'modern' solution):
>
On 23 May 2017, at 11:20, Christian Ebert wrote:
>> So I looked back at your above -af and realised that the 1024 should
>> actually be 2112 which is Apple’s chosen fixed encoding delay.
>>
On 15 Apr 2017, at 09:22, Christian Ebert wrote:
> Somewhat counterintuitive, but you never know:
>
> -filter:a aresample=async=1:first_pts=0,asetpts=PTS-STARTPTS+1024
>
> combined with the -t incantation.
Hi Christian,
It seems this issue is not going to garner much
On 9 May 2017, 15:42 +0100, Mark Burton <mwjbur...@gmail.com>, wrote:
> > > Do you not see the same behaviour?
> > No, unfortunately not.
> Can I ask - are you playing back your encoded file on macOS in either
> Quicktime Player 7.x or Quicktime Player 10.x?
>
On 9 May 2017, at 15:21, Carl Eugen Hoyos wrote:
>> Do you not see the same behaviour?
> No, unfortunately not.
Can I ask - are you playing back your encoded file on macOS in either Quicktime
Player 7.x or Quicktime Player 10.x?
I don’t believe you will see this unless you
> On 9 May 2017, at 15:16, Carl Eugen Hoyos wrote:
>> Is this patch likely to be applied in the near future? Thanks.
>
> The only comment I see above is that the patch does not fix
> any issue, so while I haven't looked at it, I consider this more
> of an argument against
On 15 Apr 2017, 11:26 +0100, Marton Balint , wrote:
> Hmm, a recent fix changed one of the hunk contexts... Could you try this
> new attached patch?
Is this patch likely to be applied in the near future? Thanks.
___
ffmpeg-user mailing
> On 28 Apr 2017, at 16:28, Paul B Mahol wrote:
>
> You need to use Parsed_drawtext_X instead of drawtext, replace X with
> number of filter in filtergraph.
>
> So if its 3rd filter in filtergraph its number will be 2. Because
> lavfi counts from 0.
Ah perfect. Many thanks
Using a single sendcmd to read text from an external file and command a single
drawtext, is working fine:
ffmpeg -i input.mov -c:v dnxhd -b:v 115M -pix_fmt yuv422p -vf
This caught me out today, so just as an FYI to anyone else this might affect,
the change to enable ‘optimal' huffman coding by default since Sunday 9th
April, does cause playback to break in Quicktime Player 7 on macOS. Since
Quicktime Player 7 is very old now this is understandable, but for
On 15 Apr 2017, 09:18 +0100, Mark Burton <mwjbur...@gmail.com>, wrote:
> On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos <ceffm...@gmail.com>, wrote:
> > 2017-04-14 23:44 GMT+02:00 Mark Burton <mwjbur...@gmail.com>:
> > > I find it hard having to accept an encod
On 15 Apr 2017, 09:22 +0100, Christian Ebert <blacktr...@gmx.net>, wrote:
> * Mark Burton on Friday, April 14, 2017 at 22:44:52 +0100
> > > On 14 Apr 2017, at 22:22, Christian Ebert <blacktr...@gmx.net> wrote:
> > > > > Also, when you run with
On 14 Apr 2017, 23:45 +0100, Carl Eugen Hoyos <ceffm...@gmail.com>, wrote:
> 2017-04-14 23:44 GMT+02:00 Mark Burton <mwjbur...@gmail.com>:
> > I find it hard having to accept an encode will always play out of
> > sync on certain players.
>
> Could you elabor
On 15 Apr 2017, 06:55 +0100, Marton Balint <c...@passwd.hu>, wrote:
> On Sat, 15 Apr 2017, Carl Eugen Hoyos wrote:
>
> > 2017-04-14 23:44 GMT+02:00 Mark Burton <mwjbur...@gmail.com>:
> > > I find it hard having to accept an encode will always play out
> On 14 Apr 2017, at 22:22, Christian Ebert wrote:
>>> Also, when you run with -v verbose, you'll see a delay (depends
>>> on audio codec), for you case it's probably 1024. Maybe try:
>>>
>>> -filter:a aresample=first_pts=0,asetpts=PTS-STARTPTS+1024
>>>
>>> Especially the
On 14 Apr 2017, 17:47 +0100, Christian Ebert <blacktr...@gmx.net>, wrote:
> * Mark Burton on Friday, April 14, 2017 at 16:57:06 +0100
> > I appreciate this is a tricky area and there appear to be different ways
> > that some encoders create AAC streams with r
> On 11 Apr 2017, at 22:39, Mark Burton <mwjbur...@gmail.com> wrote:
>
> One issue I am having is that as the numbers count the vertical position of
> the text changes ever so slightly, looks like a judder. I’m guessing this is
> due to the character size variations so the
> On 11 Apr 2017, at 21:51, Mark Burton <mwjbur...@gmail.com> wrote:
>> On 11 Apr 2017, at 21:13, Moritz Barsnick <barsn...@gmx.net
>> <mailto:barsn...@gmx.net>> wrote:
>> I haven't figured out how to format "12+6" as "12+06" though. Go
New here, hope this is an appropriate question layout...
I’ve been trying to learn more about expression evaluation and some of the more
complex aspects of controlling drawing text. I’m trying to achieve something
which is a bit far fetched, but I’d love to get any help I can and this would
be
36 matches
Mail list logo