Am Mi., 29. Apr. 2020 um 13:04 Uhr schrieb Mark Filipak
:
> When ffmpeg decodes a soft telecined video, does the
> decoder output 24 FPS progressive?
I don't think so, I would have expected 24000/1001 fps
Carl Eugen
___
ffmpeg-user mailing list
Am Sa., 25. Apr. 2020 um 04:20 Uhr schrieb Mark Filipak
:
>
> On 04/24/2020 01:22 PM, Carl Eugen Hoyos wrote:
> >
> >
> >> Am 24.04.2020 um 11:10 schrieb Mark Filipak
> >> :
> >>
> >> I've been told that, for soft telecined video the decoder is fully
> >> compliant
> >> and therefore outputs
Sorry, the p24 "source" *is* soft telecine.
On 04/24/2020 11:06 PM, pdr0 wrote:
Mark Filipak wrote
If you take a soft telecine input, encode it directly to rawvideo or
lossless output, you can confirm this.
The output is 29.97 (interlaced content) .
When I do 'telecine=pattern=5', I wind
On 04/24/2020 11:06 PM, pdr0 wrote:
Mark Filipak wrote
If you take a soft telecine input, encode it directly to rawvideo or
lossless output, you can confirm this.
The output is 29.97 (interlaced content) .
When I do 'telecine=pattern=5', I wind up with this
Mark Filipak wrote
>
>>
>> If you take a soft telecine input, encode it directly to rawvideo or
>> lossless output, you can confirm this.
>> The output is 29.97 (interlaced content) .
>>
>>> When I do 'telecine=pattern=5', I wind up with this
>>>
>>>
On 04/24/2020 01:28 PM, pdr0 wrote:
Mark Filipak wrote
I've been told that, for soft telecined video
the decoder is fully compliant and therefore outputs 30fps
I've also been told that the 30fps is interlaced (which I found
surprising)
Is this correct so far?
Yes
If you take a soft
On 04/24/2020 01:22 PM, Carl Eugen Hoyos wrote:
Am 24.04.2020 um 11:10 schrieb Mark Filipak
:
I've been told that, for soft telecined video the decoder is fully compliant
and therefore outputs 30fps
(“fps” is highly ambiguous in this sentence.)
This is not correct.
I believe I told you
On 04/24/2020 11:30 AM, Edward Park wrote:
Hi,
I don't know if the decoder outputs 30fps as is from 24fps soft telecine, but if it does,
it must include the flags that you need to reconstruct the original 24 format or set it
as metadata because frame stepping in ffplay (using the "s" key on
Carl Eugen Hoyos-2 wrote
>> e.g
>> ffmpeg -i input.mpeg -c:v rawvideo -an output.yuv
>
> (Consider to test with other output formats.)
What did you have in mind?
e.g.
ffmpeg -i input.mpeg -c:v utvideo -an output.avi
The output is 29.97, according to ffmpeg and double check using official
> Am 24.04.2020 um 19:34 schrieb pdr0 :
>
> Carl Eugen Hoyos-2 wrote
>>> Am 24.04.2020 um 11:10 schrieb Mark Filipak
>
>> markfilipak.windows+ffmpeg@
>
>> :
>>>
>>> I've been told that, for soft telecined video the decoder is fully
>>> compliant and therefore outputs 30fps
>>
>> (“fps” is
Hi,
> Output is actually 29.97p with 5th frame duplicates . The repeat field flags
> are not taken into account.
> If you use direct encode, no filters, no switches, the output from soft
> telecine input video is 29.97p, where every 5th frame is a duplicate
>
> e.g
> ffmpeg -i input.mpeg -c:v
pdr0 wrote
> If you take a soft telecine input, encode it directly to rawvideo or
> lossless output, you can confirm this.
> The output is 29.97 (interlaced content) .
So my earlier post is incorrect
Output is actually 29.97p with 5th frame duplicates . The repeat field flags
are not taken
Carl Eugen Hoyos-2 wrote
>> Am 24.04.2020 um 11:10 schrieb Mark Filipak
> markfilipak.windows+ffmpeg@
> :
>>
>> I've been told that, for soft telecined video the decoder is fully
>> compliant and therefore outputs 30fps
>
> (“fps” is highly ambiguous in this sentence.)
>
> This is not
Mark Filipak wrote
>> I've been told that, for soft telecined video
>> the decoder is fully compliant and therefore outputs 30fps
>> I've also been told that the 30fps is interlaced (which I found
>> surprising)
>> Is this correct so far?
Yes
If you take a soft telecine input, encode it
> Am 24.04.2020 um 11:10 schrieb Mark Filipak
> :
>
> I've been told that, for soft telecined video the decoder is fully compliant
> and therefore outputs 30fps
(“fps” is highly ambiguous in this sentence.)
This is not correct.
I believe I told you some time ago that this is not how the
Hi,
I don't know if the decoder outputs 30fps as is from 24fps soft telecine, but
if it does, it must include the flags that you need to reconstruct the original
24 format or set it as metadata because frame stepping in ffplay (using the "s"
key on the keyboard) goes over 1/24 s progressive
On 04/24/2020 05:10 AM, Mark Filipak wrote:
Hello,
I've been told that, for soft telecined video
|<--1/6s-->|
[A/a__][B/b__][C/c__][D/d__] source
the decoder is fully compliant and therefore outputs 30fps
Michael Koch (12020-04-21):
> If the blend filter gets two input frames with different timestamps, then
> what's the timestamp of the output frame?
To understand how it works, you need to think of frames not as punctual
instant in time, it is an interval going from the frame's PTS to the
next
On 4/21/20, Michael Koch wrote:
> Am 21.04.2020 um 11:07 schrieb Paul B Mahol:
>> On 4/21/20, Michael Koch wrote:
> I now appreciate that 'blend' has a "preferred" input similar to
> 'overlay',
> but that behavior is not
> documented. In the case of 'overlay', the name "main"
Am 21.04.2020 um 11:07 schrieb Paul B Mahol:
On 4/21/20, Michael Koch wrote:
I now appreciate that 'blend' has a "preferred" input similar to
'overlay',
but that behavior is not
documented. In the case of 'overlay', the name "main" doesn't convey that
meaning, and in the case
of 'blend', that
On 4/21/20, Michael Koch wrote:
>
>>> I now appreciate that 'blend' has a "preferred" input similar to
>>> 'overlay',
>>> but that behavior is not
>>> documented. In the case of 'overlay', the name "main" doesn't convey that
>>> meaning, and in the case
>>> of 'blend', that behavior is not
I now appreciate that 'blend' has a "preferred" input similar to 'overlay',
but that behavior is not
documented. In the case of 'overlay', the name "main" doesn't convey that
meaning, and in the case
of 'blend', that behavior is not documented at all. Both documentations
should explain how
On 4/20/20, Mark Filipak wrote:
> Hi, Ted,
>
> On 04/20/2020 06:20 AM, Edward Park wrote:
>> Hey,
>>
I don't understand what you mean by "recursively".
>>>
>>> Haven't you heard? There's no recursion. There's no problem. The 'blend'
>>> filter just has some fun undocumented features. Hours
Hi, Ted,
On 04/20/2020 06:20 AM, Edward Park wrote:
Hey,
I don't understand what you mean by "recursively".
Haven't you heard? There's no recursion. There's no problem. The 'blend' filter
just has some fun undocumented features. Hours and hours, days and days of fun.
So much fun I just
Hey,
>> I don't understand what you mean by "recursively".
>
> Haven't you heard? There's no recursion. There's no problem. The 'blend'
> filter just has some fun undocumented features. Hours and hours, days and
> days of fun. So much fun I just can't stand it. Too much fun.
There's no
Hi Michael,
On 04/19/2020 03:31 PM, Michael Koch wrote:
Am 19.04.2020 um 20:44 schrieb Mark Filipak:
I'm hooking into this to reply in order to get the message below into the
thread.
But first, I'd like to say that I had no idea this would be controversial. I asked whether ffmpeg
traversed
pdr0 wrote
> As Paul pointed out, interleave works using timestamps , not "frames". If
> you took 2 separate video files, with the same fps, same timestamps, they
> won't interleave correctly in ffmpeg. The example in the documentation
> actually does not work if they had the same timestamps. You
Am 19.04.2020 um 20:44 schrieb Mark Filipak:
I'm hooking into this to reply in order to get the message below into
the thread.
But first, I'd like to say that I had no idea this would be
controversial. I asked whether ffmpeg traversed filter complexes
recursively because that was not
I'm hooking into this to reply in order to get the message below into the
thread.
But first, I'd like to say that I had no idea this would be controversial. I asked whether ffmpeg
traversed filter complexes recursively because that was not happening. Apparently it does recurse,
but only if
Carl Eugen Hoyos-2 wrote
> Am So., 19. Apr. 2020 um 18:46 Uhr schrieb Mark Filipak
>
> markfilipak.windows+ffmpeg@
> :
>>
>> On 04/19/2020 12:31 PM, Carl Eugen Hoyos wrote:
>> > Am So., 19. Apr. 2020 um 18:11 Uhr schrieb pdr0
> pdr0@
> :
>> >
>> >> In his specific situation, he has a single
Am So., 19. Apr. 2020 um 18:46 Uhr schrieb Mark Filipak
:
>
> On 04/19/2020 12:31 PM, Carl Eugen Hoyos wrote:
> > Am So., 19. Apr. 2020 um 18:11 Uhr schrieb pdr0 :
> >
> >> In his specific situation, he has a single combed frame. What he
> >> chooses for yadif (or any deinterlacer) results in a
On 04/19/2020 12:31 PM, Carl Eugen Hoyos wrote:
Am So., 19. Apr. 2020 um 18:11 Uhr schrieb pdr0 :
In his specific situation, he has a single combed frame. What he chooses for
yadif (or any deinterlacer) results in a different result - both wrong - for
his case.
If the selects "top" he gets
Am So., 19. Apr. 2020 um 18:11 Uhr schrieb pdr0 :
> In his specific situation, he has a single combed frame. What he chooses for
> yadif (or any deinterlacer) results in a different result - both wrong - for
> his case.
> If the selects "top" he gets an "A" duplicate frame. If he selects
>
Carl Eugen Hoyos-2 wrote
> Am So., 19. Apr. 2020 um 16:31 Uhr schrieb pdr0
> pdr0@
> :
>>
>> Carl Eugen Hoyos-2 wrote
>> > Am 19.04.2020 um 08:08 schrieb pdr0
>
>> >> Other types of typical single rate deinterlacing (such as yadif) will
>> >> force you to choose the top or bottom field
>> >
>>
Am So., 19. Apr. 2020 um 16:31 Uhr schrieb pdr0 :
>
> Carl Eugen Hoyos-2 wrote
> > Am 19.04.2020 um 08:08 schrieb pdr0
> >> Other types of typical single rate deinterlacing (such as yadif) will
> >> force you to choose the top or bottom field
> >
> > As already explained: This is not true.
>
>
Carl Eugen Hoyos-2 wrote
>> Am 19.04.2020 um 08:08 schrieb pdr0
> pdr0@
> :
>>
>> Other types of typical single rate deinterlacing (such as yadif) will
>> force
>> you to choose the top or bottom field
>
> As already explained: This is not true.
How so ? Assuming you're actually applying it
> Am 19.04.2020 um 08:08 schrieb pdr0 :
>
> Other types of typical single rate deinterlacing (such as yadif) will force
> you to choose the top or bottom field
As already explained: This is not true.
Carl Eugen
___
ffmpeg-user mailing list
On 04/19/2020 02:08 AM, pdr0 wrote:
Mark Filipak wrote
My experience is that regarding "decombing" frames 2 7 12 17 ...,
'pp=linblenddeint' (whatever it is) does a better job than 'yadif'.
"lb/linblenddeint
"Linear blend deinterlacing filter that deinterlaces the given block by
filtering all
Mark Filipak wrote
> My experience is that regarding "decombing" frames 2 7 12 17 ...,
> 'pp=linblenddeint' (whatever it is) does a better job than 'yadif'.
>
> "lb/linblenddeint
> "Linear blend deinterlacing filter that deinterlaces the given block by
> filtering all lines with a
> (1 2 1)
On 04/18/2020 10:36 PM, Carl Eugen Hoyos wrote:
Am So., 19. Apr. 2020 um 04:12 Uhr schrieb Mark Filipak
:
On 04/18/2020 10:02 PM, Carl Eugen Hoyos wrote:
Am So., 19. Apr. 2020 um 03:43 Uhr schrieb Mark Filipak
:
My experience is that regarding "decombing" frames 2 7 12 17 ...,
Am So., 19. Apr. 2020 um 04:12 Uhr schrieb Mark Filipak
:
>
> On 04/18/2020 10:02 PM, Carl Eugen Hoyos wrote:
> > Am So., 19. Apr. 2020 um 03:43 Uhr schrieb Mark Filipak
> > :
> >
> >> My experience is that regarding "decombing" frames 2 7 12 17 ...,
> >> 'pp=linblenddeint' (whatever it is) does a
Oops. "(n+1)%5=3" should have been "(n+1)%5==3".
"On 04/18/2020 10:02 PM, Carl Eugen Hoyos wrote:
Am So., 19. Apr. 2020 um 03:43 Uhr schrieb Mark Filipak
:
My experience is that regarding "decombing" frames 2 7 12 17 ...,
'pp=linblenddeint' (whatever it is) does a better job than 'yadif'.
On 04/18/2020 10:02 PM, Carl Eugen Hoyos wrote:
Am So., 19. Apr. 2020 um 03:43 Uhr schrieb Mark Filipak
:
My experience is that regarding "decombing" frames 2 7 12 17 ...,
'pp=linblenddeint' (whatever it is) does a better job than 'yadif'.
(Funny that while I always strongly disagreed some
Am So., 19. Apr. 2020 um 03:43 Uhr schrieb Mark Filipak
:
> My experience is that regarding "decombing" frames 2 7 12 17 ...,
> 'pp=linblenddeint' (whatever it is) does a better job than 'yadif'.
(Funny that while I always strongly disagreed some people also
said this when yadif was new - this
On 04/18/2020 08:44 PM, Carl Eugen Hoyos wrote:
Am Sa., 18. Apr. 2020 um 21:32 Uhr schrieb Mark Filipak
:
Regarding deinterlace, Carl Eugen, I'm not trying to deinterlace.
pp=linblenddeint is a (very simple) deinterlacer, once upon a
time it was the preferred deinterlacer for some users,
Am Sa., 18. Apr. 2020 um 21:32 Uhr schrieb Mark Filipak
:
> Regarding deinterlace, Carl Eugen, I'm not trying to deinterlace.
pp=linblenddeint is a (very simple) deinterlacer, once upon a
time it was the preferred deinterlacer for some users, possibly
because of its low performance requirements.
On 04/18/2020 01:01 PM, Carl Eugen Hoyos wrote:
Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
:
I'm not using the 46 telecine anymore because you introduced me to
'pp=linblenddeint'
-- thanks again! -- which allowed me to decomb via the 55 telecine.
Why do you think that pp is a
On 2020-04-18 02:08, Paul B Mahol wrote:
[Mark Filipak] is just genuine troller, and do not know better, I
propose you just ignore his troll attempts.
I disagree. What I see from Mark's messages is that he is genuinely
using ffmpeg for reasonable purposes. He runs into limitations of the
Sorry, the previous post got sent accidentally by my email program. Kindly
ignore it.
On 04/18/2020 01:01 PM, Carl Eugen Hoyos wrote:
Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
:
I'm not using the 46 telecine anymore because you introduced me to
'pp=linblenddeint'
-- thanks
Carl Eugen Hoyos-2 wrote
> Am Sa., 18. Apr. 2020 um 19:27 Uhr schrieb pdr0
> pdr0@
> :
>>
>> Carl Eugen Hoyos-2 wrote
>> > Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
>> >
>>
>> > markfilipak.windows+ffmpeg@
>>
>> > :
>> >
>> >> I'm not using the 46 telecine anymore because you
Am Sa., 18. Apr. 2020 um 19:27 Uhr schrieb pdr0 :
>
> Carl Eugen Hoyos-2 wrote
> > Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
> >
>
> > markfilipak.windows+ffmpeg@
>
> > :
> >
> >> I'm not using the 46 telecine anymore because you introduced me to
> >> 'pp=linblenddeint'
> >> --
Carl Eugen Hoyos-2 wrote
> Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
>
> markfilipak.windows+ffmpeg@
> :
>
>> I'm not using the 46 telecine anymore because you introduced me to
>> 'pp=linblenddeint'
>> -- thanks again! -- which allowed me to decomb via the 55 telecine.
>
> Why
Paul B Mahol wrote
> On 4/18/20, pdr0
> pdr0@
> wrote:
>> Mark Filipak wrote
>>> Gee, pdr0, I'm sorry you took the time to write about 'interleave' not
>>> working because it is working
>>> for me.
>>
>>
>> Interleave works correctly in terms of timestamps
>>
>> Unless I'm misunderstanding the
Am Sa., 18. Apr. 2020 um 00:53 Uhr schrieb Mark Filipak
:
> I'm not using the 46 telecine anymore because you introduced me to
> 'pp=linblenddeint'
> -- thanks again! -- which allowed me to decomb via the 55 telecine.
Why do you think that pp is a better de-interlacer than yadif?
(On hardware
On 4/18/2020 2:08 AM, Paul B Mahol wrote:
On 4/18/20, pdr0 wrote:
Mark Filipak wrote
Gee, pdr0, I'm sorry you took the time to write about 'interleave' not
working because it is working for me.
Interleave works correctly in terms of timestamps
Unless I'm misunderstanding the point of this
On 4/18/20, pdr0 wrote:
> Mark Filipak wrote
>> Gee, pdr0, I'm sorry you took the time to write about 'interleave' not
>> working because it is working
>> for me.
>
>
> Interleave works correctly in terms of timestamps
>
> Unless I'm misunderstanding the point of this thread, your "recursion
Mark Filipak wrote
> Gee, pdr0, I'm sorry you took the time to write about 'interleave' not
> working because it is working
> for me.
Interleave works correctly in terms of timestamps
Unless I'm misunderstanding the point of this thread, your "recursion issue"
can be explained from how
On 04/17/2020 06:19 PM, pdr0 wrote:
Paul B Mahol wrote
Interleave filter use frame pts/timestamps for picking frames.
I think Paul is correct.
@Mark -
Everything in filter chain works as expected, except interleave in this case
The only problem I have with 'interleave' is that it doesn't
Paul B Mahol wrote
> Interleave filter use frame pts/timestamps for picking frames.
I think Paul is correct.
@Mark -
Everything in filter chain works as expected, except interleave in this case
You can test and verify the output of each node in a filter graph,
individually, by splitting and
On 04/17/2020 02:35 PM, Ted Park wrote:
Hi,
"split[A][B],[A]select='eq(mod((n+1)\,5)\,3)'[C],[B]datascope,null[D],interleave"
Though the [B][D] branch passes every frame that is presented at [B], datascope
does not appear for frames 2 7 12 17 etc.
That reveals that traversal of ffmpeg
On 04/17/2020 02:46 PM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
Another cogent point:
Suppose I put 'datascope' before a filter that would pass the original frame
(say, based on a
color), but that the filter won't pass the 'scope' image (because it doesn't
contain that color). I
On 4/17/20, Mark Filipak wrote:
> Another cogent point:
>
> Suppose I put 'datascope' before a filter that would pass the original frame
> (say, based on a
> color), but that the filter won't pass the 'scope' image (because it doesn't
> contain that color). I
> haven't tried it, but I'll bet that
Hi,
> "split[A][B],[A]select='eq(mod((n+1)\,5)\,3)'[C],[B]datascope,null[D],interleave"
>
> Though the [B][D] branch passes every frame that is presented at [B],
> datascope does not appear for frames 2 7 12 17 etc.
>
> That reveals that traversal of ffmpeg filter complexes is not recursive.
Another cogent point:
Suppose I put 'datascope' before a filter that would pass the original frame (say, based on a
color), but that the filter won't pass the 'scope' image (because it doesn't contain that color). I
haven't tried it, but I'll bet that the 'scope' image doesn't appear at all
Another revealing example:
"split[A][B],[A]select='eq(mod((n+1)\,5)\,3)'[C],[B]datascope,null[D],interleave"
Though the [B][D] branch passes every frame that is presented at [B], datascope does not appear for
frames 2 7 12 17 etc.
That reveals that traversal of ffmpeg filter complexes is not
Sigh.
On 4/17/2020 5:39 AM, Mark Filipak wrote:
On 04/17/2020 06:34 AM, Monex wrote:
Please do not use complicated phrases or words like "germane" - many
ffmpeg-users are not native English speakers and you are causing
confusion; it is not necessary on a technical list.
Actually, they
For example,
In the select branch that contains
datascope=size=1920x1080:x=45:y=340:mode=color2,not(eq(mod((n+1)\,5)\,3))
datascope appears for frames 0 1 3 4 5 6 8 9 10 11 13 14 15 16 18 19 etc.
whereas in the select branch that contains
On 04/17/2020 11:23 AM, Paul B Mahol wrote:
-snip-
datascope appears if you switch order of interleave pads, or use
hstack/vstack filter instead of interleave filter.
Thank you, but I've had no difficulty using datascope. It does not appear in the output video if no
frames flow through it.
On 4/17/20, Mark Filipak wrote:
> I reran the tests with these command lines:
>
> SET FFREPORT=file=FOO-GH.LOG:level=32
>
> ffmpeg -i %1 -filter_complex
>
I reran the tests with these command lines:
SET FFREPORT=file=FOO-GH.LOG:level=32
ffmpeg -i %1 -filter_complex
On 04/17/2020 06:34 AM, Monex wrote:
On 17/04/2020 11:52, Mark Filipak wrote:
On 04/17/2020 05:48 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
On 04/17/2020 05:38 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
On 04/17/2020 05:03 AM, Paul B Mahol wrote:
-snip-
That is
On 17/04/2020 11:52, Mark Filipak wrote:
> On 04/17/2020 05:48 AM, Paul B Mahol wrote:
>> On 4/17/20, Mark Filipak wrote:
>>> On 04/17/2020 05:38 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
> On 04/17/2020 05:03 AM, Paul B Mahol wrote:
> -snip-
>> That is not filter
Argh! I keep making mistakes. I'm working too quickly. You see, I had 2 differing versions: one
using 'telecine=pattern=5' and one using 'telecine=pattern=46'. They tried to do the same thing, but
by differing methods (differing filter graphs). It's really easy to get them mixed up.
Here is a
On 04/17/2020 03:56 AM, Michael Koch wrote:
Am 17.04.2020 um 09:44 schrieb Mark Filipak:
On 04/17/2020 02:41 AM, Michael Koch wrote:
Am 17.04.2020 um 08:02 schrieb Mark Filipak:
Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect) p24-to-p60
transcode has concluded.
But remaining
On 04/17/2020 03:56 AM, Michael Koch wrote:
Am 17.04.2020 um 09:44 schrieb Mark Filipak:
On 04/17/2020 02:41 AM, Michael Koch wrote:
Am 17.04.2020 um 08:02 schrieb Mark Filipak:
Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect) p24-to-p60
transcode has concluded.
But
On 04/17/2020 05:48 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
On 04/17/2020 05:38 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
On 04/17/2020 05:03 AM, Paul B Mahol wrote:
-snip-
That is not filter graph. It is your wrong interpretation of it.
I can not dechiper it
On 4/17/20, Mark Filipak wrote:
> On 04/17/2020 05:38 AM, Paul B Mahol wrote:
>> On 4/17/20, Mark Filipak wrote:
>>> On 04/17/2020 05:03 AM, Paul B Mahol wrote:
>>> -snip-
That is not filter graph. It is your wrong interpretation of it.
I can not dechiper it at all, because your
On 04/17/2020 05:38 AM, Paul B Mahol wrote:
On 4/17/20, Mark Filipak wrote:
On 04/17/2020 05:03 AM, Paul B Mahol wrote:
-snip-
That is not filter graph. It is your wrong interpretation of it.
I can not dechiper it at all, because your removed crucial info like ','
My filtergraph is slightly
On 4/17/20, Mark Filipak wrote:
> On 04/17/2020 05:03 AM, Paul B Mahol wrote:
> -snip-
>> That is not filter graph. It is your wrong interpretation of it.
>> I can not dechiper it at all, because your removed crucial info like ','
>
> My filtergraph is slightly abbreviated to keep within a 70
On 04/17/2020 05:03 AM, Paul B Mahol wrote:
-snip-
That is not filter graph. It is your wrong interpretation of it.
I can not dechiper it at all, because your removed crucial info like ','
My filtergraph is slightly abbreviated to keep within a 70 character line limit.
The important thing is
On 4/17/20, Mark Filipak wrote:
> Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect) p24-to-p60
> transcode has concluded.
>
> But remaining is an ffmpeg behavior that seems (to me) to be key to
> understanding ffmpeg
> architecture, to wit: The characteristics of frame traversal
Hi,
> no, I meant replace [F][G]blend[D] by [G][F]blend[D] and leave everything
> else as it is.
I thought the latter was the intended order (or maybe it's just the order my
brain read it in). The other one results in a ton of duplicate timestamp errors
and the correction cancels something
Am 17.04.2020 um 09:44 schrieb Mark Filipak:
On 04/17/2020 02:41 AM, Michael Koch wrote:
Am 17.04.2020 um 08:02 schrieb Mark Filipak:
Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect)
p24-to-p60 transcode has concluded.
But remaining is an ffmpeg behavior that seems (to me) to
On 04/17/2020 02:41 AM, Michael Koch wrote:
Am 17.04.2020 um 08:02 schrieb Mark Filipak:
Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect) p24-to-p60
transcode has concluded.
But remaining is an ffmpeg behavior that seems (to me) to be key to understanding ffmpeg
architecture,
Am 17.04.2020 um 08:02 schrieb Mark Filipak:
Thanks to pdr0 -at- shaw.ca, My quest for the (nearly perfect)
p24-to-p60 transcode has concluded.
But remaining is an ffmpeg behavior that seems (to me) to be key to
understanding ffmpeg architecture, to wit: The characteristics of
frame
85 matches
Mail list logo
