[FFmpeg-user] flame about confusing command line options.

[Roger Pack]

As a note, I just had to get this off my chest, and I'll only say this
once.  Some of FFmpeg's command line syntax is *confusing* and *super
confusing* for beginners.

For instance this:

ffmpeg -r 30 -i input_file

specifies a framerate *override* for the input, however if you specify
it for the output, its just the "normal" output frame rate...:

ffmpeg -i input -r 10 output

and this:
ffmpeg -i input -f rawvideo -f nut output.nut

Using (or being able to use)  "-f"
typically using two "-f" s would be an override.  But in this case it
isn't.  In fact, its using "-f" to specify two entirely different
aspects of the output file.  It's hard to see, but to beginners, this
is *super* confusing.

Being able to specify global settings "in the middle of an input file"
is also confusing..

Not that much can be done, but just so you're aware...the command line
syntax is  confusing to people just getting started with FFmpeg.
After using FFmpeg for like 5 years I'm only finally figuring it out
myself LOL.
Cheers, no offense intended of course, just a gripe.
-roger-
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Carl Eugen Hoyos]

Roger Pack  gmail.com> writes:

> ffmpeg -i input -f rawvideo -f nut output.nut
> 
> Using (or being able to use)  "-f"
> typically using two "-f" s would be an override. 
> But in this case it isn't.  In fact, its using 
> "-f" to specify two entirely different aspects of 
> the output file.

I have no idea what this email is about (and it would 
be super-nice if you would not continue this thread) 
but please understand that in your command line the 
second -f is overriding the first -f option, so 
instead of being rawvideo, the output has format nut.
(Which it would also have if you had not specified 
any "-f" option as the extension "nut" defaults to 
the format "nut".)

Note that the input option "-r" is mostly a debug 
option with limited use and often does not work 
and that I consider it extremely useful that many 
input options (like -f) have the same name as the 
matching output options.

Finally, I don't think there is anything wrong with 
having codecs with the same name as formats, this 
includes "opus", "mp3" and "rawvideo" (and many 
others).

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:


Strange, unless there is something in the pngs that causes a
different viewer to produce different output.

I looked again (display from ancient imagemagic) and can't see any
difference - psnr/ssim agree.

The pngs are not the same md5sum wise


OK - you’re definitely getting way over my head, but you’re right, it
is strange.  My Mac OS viewers definitely show the three pngs as
different, although it is a bit subtle and you have to switch between
them in place to see it.

However, I opened them in Photoshop.  Here, master.png and
yuv-709.png look the same, and slightly brighter than yuv.png.

I ran the histogram in Photoshop and it shows master and yuv-709 as
identical, and with a bit higher luminosity than yuv as you
expected.

Somehow, the Mac OS viewer is seeing something that other viewers
don’t!

However I think you’ve found the solution with the colormatrix bt709
business.  That should fix it.  I’ll confirm and post again.
Thanks!


Should be that, the png is a different issue/feature - I don't know
what's correct or not. I guess you saw my other post that showed the
gamma difference. Whether you see it or not is going to be down to the
viewer/ICC/OS setup. I haven't got a clue which is correct - I mean we a
re likely seeing 709 on an srgb monitor so not the same as a 709  TV -
perhaps the "corrected" version is the correct one. Not that when
playing the movie you would be using a png viewer anyway. What you get
from players may be a bit pot luck! Even with the same player there can
be differences between output types (xv,vdpau,opengl).

If you really want playback colour perfection, mpv can do correction
using ICC profiles for different displays.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Carl Eugen Hoyos]

Matthew Adams  matthewadams.me> writes:

> goo.gl/Bb6tQW

Which player plays this file at the correct speed?

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Ingest of SMPTE-377M

[Mark Nelson]

>But my question was if there is a receiver
>that plays the eac3 spdif file you uploaded:

So the specific file that I posted here:
https://www.dropbox.com/s/tec7al5bcmihwey/sample.eac3.337.wav?dl=0

Works fine in my configuration, which is: File playing in AJA Control Room,
which generates an SDI signal for ingest on a video encoder. Similarly
encoded files from the Dolby test kit in both eac3 and ac3 formats work
with AJA Control Room. I'm not sure what other tools Dolby targets for
files in this format. (Similar files with AC3 content work fine also, and
I'm not entirely clear on what you mean when you say this process can only
work with eac3. But that's a different issue.)

When I compare the Dolby WAV file to the ffmpeg-created WAV file, by
extracting the raw spdif:

ffmpeg -i sample.eac3.337.wav -f s16le -acodec pcm_s16le  sample.eac3.spdif

The payloads look fine, but I see a difference is in the burst_info and
length_code field of the SMPTE 377M headers.

header created by ffmpeg: 72 f8 1f 4e 15 00 00 03
header stripped from dolby WAV file: 72 f8 1f 4e 10 00 00 18

The interesting thing here is that there is a discrepancy in the location
of the burst_info and length_code data in these two files. One of them is
broken (I have a feeling I know which one you suspect.)

The EAC3 frame in the ffmpeg created spdif file has a length of 672 bytes,
or 5376 bits, giving a length code of 0x1500
The EAC3 frame in the spdif file extracted from the dolby WAV file has a
length of of 768 bytes, or 6144 bytes, giving a length code of 0x1800

So the dolby file and the ffmpeg created file have different endian layouts
of just that section of the SMPTE-377M the data. Both have a reserved data
type, but one is 0x03 and one is 0x10.

Maybe the problem here is that we are comparing apples and oranges? S/PDIF
vs. AES3?



--

Mark Nelson – ma...@ieee.org - http://marknelson.us
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 16:32 schrieb Paul B Mahol:

On 1/5/16, Reindl Harald  wrote:



Am 05.01.2016 um 16:21 schrieb Michael Koch:

For example, Harald Reindl just wrote:
"and when you specify something twice the right one wins"

Is this already in the FFmpeg documentation?


that's common sense


for you, but not for a beginner


well, then i ask the question different

"--width=600 --width=300" - what would you expect?

900? why?



600 + 300 = 900, obviously


and you see a + sign somewhere?
well, then try to calc "-codec:a x -codec:a y" to a number
in the whole computerworld overrides are from left to right



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> On 2016 Jan 5, at 8:38 AM, Andy Furniss  wrote:
> 
> Should be that, the png is a different issue/feature - I don't know
> what's correct or not. I guess you saw my other post that showed the
> gamma difference. Whether you see it or not is going to be down to the
> viewer/ICC/OS setup. I haven't got a clue which is correct - I mean we a
> re likely seeing 709 on an srgb monitor so not the same as a 709  TV -
> perhaps the "corrected" version is the correct one. Not that when
> playing the movie you would be using a png viewer anyway. What you get
> from players may be a bit pot luck! Even with the same player there can
> be differences between output types (xv,vdpau,opengl).
> 
> If you really want playback colour perfection, mpv can do correction
> using ICC profiles for different displays.
> ___

I’m not really looking for perfection, just don’t want the transcodes to be
darker on any device.

So my testing has shown, for both libx264 and libx265, the problem is
solved (meaning the pngs come out with the same luminosity, which
is good enough for me) either of two ways, using ffmpeg options:

-color_primaries bt709 -color_trc bt709 -colorspace bt709

or using x264/5 params:

-x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709

These alternatives are not quite parallel, I know.  Frankly I don’t
really understand them.  I’m guessing colormatrix is the only one
needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
this direction.

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Matthew Adams]

Wow thanks Carl.  Two questions.

1. Is 1.65s consistent on both ends of the video & in both videos?
2. If so, can cut (on both ends), transcode & merge be scripted with bash &
ffmpeg?


On Tue, Jan 5, 2016 at 10:32 AM, Another Sillyname <
anothersn...@googlemail.com> wrote:

> It's at 1.65 seconds it goes into 'slo mo' mode, but there's no change
> in framerate reported by either ffmpeg or mplayer and 'proper' speed
> would appear to need it to be run at about 220 fps after 1.65 seconds.
>
> Bit weird.
>
> Can't see an immediate way to do this without manual cut, transcode and
> merge.
>
>
>
> On 5 January 2016 at 16:10, Matthew Adams  wrote:
> > No video player does.  It starts out in regular motion, then goes to
> super
> > slow motion, then reverts back to regular motion.
> >
> > I've viewed the file on Mac OS X El Capitan using VLC 2.2.1 & QuickTime
> > 10.4.  If I create a new project in iMovie 10.1, import the file, then
> add
> > the entire clip to the project, it still renders regular speed, then
> fast,
> > then regular.  If I could easily identify how many frames are in regular
> > speed at either end of the clip, I might be able to fix them, but that
> > won't scale to the 100+ rallies I have to edit.  I'm not willing to
> assume
> > the same number of frames are in regular v. slow motion across files or
> on
> > either end of the clip.  [sigh]
> >
> > I uploaded one more file to comparison:  goo.gl/YVyBfp
> >
> > -matthew
> >
> > On Tue, Jan 5, 2016 at 9:37 AM, Carl Eugen Hoyos 
> wrote:
> >
> >> Matthew Adams  matthewadams.me> writes:
> >>
> >> > goo.gl/Bb6tQW
> >>
> >> Which player plays this file at the correct speed?
> >>
> >> Carl Eugen
> >>
> >> ___
> >> ffmpeg-user mailing list
> >> ffmpeg-user@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >>
> >
> >
> >
> > --
> > mailto:matt...@matthewadams.me 
> > skype:matthewadams12
> > googletalk:matt...@matthewadams.me
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> > ___
> > ffmpeg-user mailing list
> > ffmpeg-user@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>



-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Phil Rhodes]

> thinking one can develop a GUI which is usable and supports all of the > 
>features of ffmpeg or even a large part of them is naive
Well, possibly, but the problem is that the CLI doesn't do a very good job of 
it either. Inasmuch as CLI discoverability is effectively zero, it doesn't do 
any job of it.
Yes, there need to be possibly different GUIs, or a GUI with different pages, 
for various tasks. But it's madness to completely decry the idea on the basis 
that it can't include everything.
Phil
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 17:00 schrieb Phil Rhodes:

  thinking one can develop a GUI which is usable and supports all of the > 
features of ffmpeg or even a large part of them is naive

Well, possibly, but the problem is that the CLI doesn't do a very good job of 
it either. Inasmuch as CLI discoverability is effectively zero, it doesn't do 
any job of it.
Yes, there need to be possibly different GUIs, or a GUI with different pages, 
for various tasks. But it's madness to completely decry the idea on the basis 
that it can't include everything.


no - the idea is to provide ffmpeg
that is what the developers are doing

when you want a GUI you can write one just sticking together the CLI 
params based on whatever forms and dialogs


or just use google and download one of the existing GUIs

http://avanti.arrozcru.org/#links
http://www.myffmpeg.com/



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Another Sillyname]

It's at 1.65 seconds it goes into 'slo mo' mode, but there's no change
in framerate reported by either ffmpeg or mplayer and 'proper' speed
would appear to need it to be run at about 220 fps after 1.65 seconds.

Bit weird.

Can't see an immediate way to do this without manual cut, transcode and merge.



On 5 January 2016 at 16:10, Matthew Adams  wrote:
> No video player does.  It starts out in regular motion, then goes to super
> slow motion, then reverts back to regular motion.
>
> I've viewed the file on Mac OS X El Capitan using VLC 2.2.1 & QuickTime
> 10.4.  If I create a new project in iMovie 10.1, import the file, then add
> the entire clip to the project, it still renders regular speed, then fast,
> then regular.  If I could easily identify how many frames are in regular
> speed at either end of the clip, I might be able to fix them, but that
> won't scale to the 100+ rallies I have to edit.  I'm not willing to assume
> the same number of frames are in regular v. slow motion across files or on
> either end of the clip.  [sigh]
>
> I uploaded one more file to comparison:  goo.gl/YVyBfp
>
> -matthew
>
> On Tue, Jan 5, 2016 at 9:37 AM, Carl Eugen Hoyos  wrote:
>
>> Matthew Adams  matthewadams.me> writes:
>>
>> > goo.gl/Bb6tQW
>>
>> Which player plays this file at the correct speed?
>>
>> Carl Eugen
>>
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>
>
>
> --
> mailto:matt...@matthewadams.me 
> skype:matthewadams12
> googletalk:matt...@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> I’m not really looking for perfection, just don’t want the transcodes to be
> darker on any device.
> 
> So my testing has shown, for both libx264 and libx265, the problem is
> solved (meaning the pngs come out with the same luminosity, which
> is good enough for me) either of two ways, using ffmpeg options:
> 
> -color_primaries bt709 -color_trc bt709 -colorspace bt709
> 
> or using x264/5 params:
> 
> -x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709
> 
> These alternatives are not quite parallel, I know.  Frankly I don’t
> really understand them.  I’m guessing colormatrix is the only one
> needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
> this direction.
> 
Well I’m really confused now.  When I went back to the full source
file (rather than the 1 minute clipped from  it, which was a
stream copy), the transcode with x265-params came out BRIGHTER
than the source.  My head’s about to explode.  I’m just going
to stick with this result.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Another Sillyname]

Only d/loaded one...am away from machine now.

Are you running IOS on your desktop machine?

On 5 January 2016 at 17:09, Matthew Adams  wrote:
> Wow thanks Carl.  Two questions.
>
> 1. Is 1.65s consistent on both ends of the video & in both videos?
> 2. If so, can cut (on both ends), transcode & merge be scripted with bash &
> ffmpeg?
>
>
> On Tue, Jan 5, 2016 at 10:32 AM, Another Sillyname <
> anothersn...@googlemail.com> wrote:
>
>> It's at 1.65 seconds it goes into 'slo mo' mode, but there's no change
>> in framerate reported by either ffmpeg or mplayer and 'proper' speed
>> would appear to need it to be run at about 220 fps after 1.65 seconds.
>>
>> Bit weird.
>>
>> Can't see an immediate way to do this without manual cut, transcode and
>> merge.
>>
>>
>>
>> On 5 January 2016 at 16:10, Matthew Adams  wrote:
>> > No video player does.  It starts out in regular motion, then goes to
>> super
>> > slow motion, then reverts back to regular motion.
>> >
>> > I've viewed the file on Mac OS X El Capitan using VLC 2.2.1 & QuickTime
>> > 10.4.  If I create a new project in iMovie 10.1, import the file, then
>> add
>> > the entire clip to the project, it still renders regular speed, then
>> fast,
>> > then regular.  If I could easily identify how many frames are in regular
>> > speed at either end of the clip, I might be able to fix them, but that
>> > won't scale to the 100+ rallies I have to edit.  I'm not willing to
>> assume
>> > the same number of frames are in regular v. slow motion across files or
>> on
>> > either end of the clip.  [sigh]
>> >
>> > I uploaded one more file to comparison:  goo.gl/YVyBfp
>> >
>> > -matthew
>> >
>> > On Tue, Jan 5, 2016 at 9:37 AM, Carl Eugen Hoyos 
>> wrote:
>> >
>> >> Matthew Adams  matthewadams.me> writes:
>> >>
>> >> > goo.gl/Bb6tQW
>> >>
>> >> Which player plays this file at the correct speed?
>> >>
>> >> Carl Eugen
>> >>
>> >> ___
>> >> ffmpeg-user mailing list
>> >> ffmpeg-user@ffmpeg.org
>> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> >>
>> >
>> >
>> >
>> > --
>> > mailto:matt...@matthewadams.me 
>> > skype:matthewadams12
>> > googletalk:matt...@matthewadams.me
>> > http://matthewadams.me
>> > http://www.linkedin.com/in/matthewadams
>> > ___
>> > ffmpeg-user mailing list
>> > ffmpeg-user@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>
>
>
> --
> mailto:matt...@matthewadams.me 
> skype:matthewadams12
> googletalk:matt...@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Phil Rhodes]

I think in general a lot of problems with commandline software in general exist 
when the software begins to exceed the ability of a commandline to act as a 
workable UI.
Naturally there are reasons to provide serialised instructions to a piece of 
software, but in many cases that isn't really intended as a user interface, 
it's intended as an API. The discoverability of a CLI is near zero, and the 
lack of examples in the documentation doesn't help.
For many tasks, software with as many complexities as ffmpeg desperately needs 
a GUI.
P
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 16:03 schrieb Michael Koch:

What part of this mailing list thread is not
documented in your opinion?


For example, Harald Reindl just wrote:
"and when you specify something twice the right one wins"

Is this already in the FFmpeg documentation?


that's common sense



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Paul B Mahol]

On 1/5/16, Reindl Harald  wrote:
>
>
> Am 05.01.2016 um 16:21 schrieb Michael Koch:
 For example, Harald Reindl just wrote:
 "and when you specify something twice the right one wins"

 Is this already in the FFmpeg documentation?
>>>
>>> that's common sense
>>
>> for you, but not for a beginner
>
> well, then i ask the question different
>
> "--width=600 --width=300" - what would you expect?
>
> 900? why?
>
>

600 + 300 = 900, obviously
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Moritz Barsnick]

On Tue, Jan 05, 2016 at 07:04:11 -0700, Roger Pack wrote:
> As a note, I just had to get this off my chest, and I'll only say this
> once.  Some of FFmpeg's command line syntax is *confusing* and *super
> confusing* for beginners.

That may be the case. :-) Feel free to suggest improvements to
documentation and wiki.

> specifies a framerate *override* for the input, however if you specify
> it for the output, its just the "normal" output frame rate...:

No, in either case, it's an override. By default, ffmpeg processes the
timestamps on the input frames, and uses them (where possible) for the
output. For some cases, when there are no timestamps, it assumes a
default.

> Using (or being able to use)  "-f"
> typically using two "-f" s would be an override.  But in this case it
> isn't.  In fact, its using "-f" to specify two entirely different
> aspects of the output file.

That's not true. It specifies only one aspect, and your second use
overrides the first. (Yes, there could be a warning about that.) If I
use your nut example, "-f rawvideo" is ignored. (If you mean the
content, you need to use "-c:v rawvideo". Format and codec are very
well separated in ffmpeg. Some correlations apply.)

> Being able to specify global settings "in the middle of an input file"
> is also confusing..

What are you saying? That you can drop globally valid flags inbetween
input or output file flags? It would be confusing not to except them
*anywhere*, as they are *global*.

> Not that much can be done, but just so you're aware...the command line
> syntax is  confusing to people just getting started with FFmpeg.
> After using FFmpeg for like 5 years I'm only finally figuring it out
> myself LOL.

When going from mencoder to ffmpeg, it took me about five minutes to
grasp the syntax. Some of the details (more like: What is an input,
what an output, what a global option? Oh, I can specify multiple
outputs? Which flags are valid when?) came later.

I suggest you try to use cvlc for transcoding. For a simple case, I was
recently stuck for an hour! It may be *logical*, but nowhere as
intuitive as ffmpeg. :-)

> Cheers, no offense intended of course, just a gripe.

Of course.

As mentioned, documentation improvements are *always* welcome.

Cheers,
Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 15:43 schrieb Phil Rhodes:

I think in general a lot of problems with commandline software in general exist 
when the software begins to exceed the ability of a commandline to act as a 
workable UI.
Naturally there are reasons to provide serialised instructions to a piece of 
software, but in many cases that isn't really intended as a user interface, 
it's intended as an API. The discoverability of a CLI is near zero, and the 
lack of examples in the documentation doesn't help.
For many tasks, software with as many complexities as ffmpeg desperately needs 
a GUI


thinking one can develop a GUI which is usable and supports all of the 
features of ffmpeg or even a large part of them is naive - it would be a 
completly weird application with a million dropdowns nobody understands 
how they work together depending of mediatypes or just support a small 
piece of ffmpeg


breaking news: you can write a GUI calling the ffmpeg-binary

we made a PHP wrapper as library-class years ago for ffmpeg which is 
then used by our cms-system as a GUI


but you can not to the other direction when you have a GUI software





signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 16:21 schrieb Michael Koch:

For example, Harald Reindl just wrote:
"and when you specify something twice the right one wins"

Is this already in the FFmpeg documentation?


that's common sense


for you, but not for a beginner


well, then i ask the question different

"--width=600 --width=300" - what would you expect?

900? why?



signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Carl Eugen Hoyos]

Michael Koch  t-online.de> writes:

> For many questions, it might be better not to answer 
> them here. Instead, please add the answers to the 
> documentation and then just post a link.

What part of this mailing list thread is not 
documented in your opinion?

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] Need help; willing to pay

[Matthew Adams]

Hi,

I'm a software developer myself, but just don't have the time to fix a
problem that I'm having.

I grabbed some videos recorded by Coach's Eye on iOS from my phone, and
they seem to use variable bitrates within the video.  A sample video file
(.mov format) is available via my Google Drive account at goo.gl/Bb6tQW
(or, if you already have Coach's Eye on iOS, just take a video at 720p @
240 fps, then use iExplorer to grab the file off of the iOS device).

A small set of frames at the beginning of the video seems to be recorded in
normal, 30 fps.  Then, it switches to the parameters I set in the app,
which was 720p @ 240 fps.  Then, then a small set of frames at the end of
each video seems to be set back to 30 fps.

I need to convert the hundred or so short videos of my kids' volleyball
rallies I took so that they don't play in regular motion for the first
second or so, then super-slow motion for the brunt of the video, then
regular motion for the last second or so.  Instead, I want them to play in
normal speed for the entirety of the video, minimizing any loss in image
fidelity.

If there were a single ffmpeg command or series of ffmpeg commands that I
could get from someone knowledgeable so that I can create a bash script and
just let 'er rip on all of my files, I'd be willing to pay like $25.  Audio
preservation would be a bonus, but is not required.

Anybody knowledgeable willing to knock this out for me?

TIA,
Matthew

-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Michael Koch]

As mentioned, documentation improvements are *always* welcome. 


I agree with Roger that for a beginner FFmpeg's documentation leaves 
many questions unanswered. It would be great to have more details and 
especially more examples in the documentation.
Many questions are answered in this user list, but later it's difficult 
to find these answers. So the same questions are asked again and again.
For many questions, it might be better not to answer them here. Instead, 
please add the answers to the documentation and then just post a link.


Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Michael Koch]

For example, Harald Reindl just wrote:
"and when you specify something twice the right one wins"

Is this already in the FFmpeg documentation?


that's common sense


for you, but not for a beginner.

Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Carl Eugen Hoyos wrote:

Andy Furniss  gmail.com> writes:


I think it's because the master is flagged as rec709 but the yuv
and I guess hevc aren't.


While this is at least likely (sorry for my original comment, I don't
know what I looked at), the source code seems to disagree:
colour_primaries etc. are read from both h264 and hevc files and are
written both when encoding with libx264 and libx265. You could test
to set them with the following: -color_primaries bt709 -color_trc
bt709 -colorspace bt709 (with a faster preset), it shouldn't make a
difference but who knows...

And please also test with -vcodec x264, Carl Eugen


With Jims command line neither libx264 or libx265 pass through the 709
(it's not shown by ffmpeg -i ...).

With the three options above both do show 709.

Haven't had time to think more about the png "issue" yet ie. why does
ffmpeg (seem to) make pngs with two gamma values coded in when the
source is 709 flagged (but not from yuv when 709 is stated as
in_color_matrix).
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Michael Koch]

What part of this mailing list thread is not
documented in your opinion?


For example, Harald Reindl just wrote:
"and when you specify something twice the right one wins"

Is this already in the FFmpeg documentation?

Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Ingest of SMPTE-377M

[Mark Nelson]

Hi Carl,

I am unable to recreate the results you are describing here.

Starting with the sample.ac3 file I posted a copy of earlier:
https://www.dropbox.com/s/ripe53oci6wz7t6/sample.ac3?dl=0

Packaging it with smpte 337M:

ffmpeg -i sample.ac3 -acodec ac3 -f spdif sample.ac3.spdif

Gives this file:
https://www.dropbox.com/s/zksgfvavopi4qdq/sample.ac3.spdif?dl=0

It looks correct, it has SMPTE377 headers wrapped around AC3 frames with
lots of null space in between, as I would expect.

Converting this to a WAV file using your command as an example:

ffmpeg -f s16le -ac 2 -ar 192k -i sample.ac3.spdif -acodec copy
sample.ac3.spdif.wav

Creates this wav file:
https://www.dropbox.com/s/awoqe8l078ppezm/sample.ac3.spdif.wav?dl=0

That WAV file looks correct - it is more or less identical to the ones in
the Dolby SDK sample files, however it appears to have a little bit of
extra information in the WAV header that is not present in the Dolby
version.

Attempting to play this with mplayer doesn't work - it treats the input as
if it were PCM so you hear garbage:

*Playing Desktop/sample.ac3.spdif.wav.*
*libavformat version 54.20.4 (external)*
*Mismatching header version 54.20.3*
*Audio only file format detected.*
*Load subtitles in Desktop/*
*==*
*Opening audio decoder: [pcm] Uncompressed PCM audio decoder*
*AUDIO: 192000 Hz, 2 ch, s16le, 6144.0 kbit/100.00% (ratio: 768000->768000)*
*Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)*
*==*
*AO: [pulse] 192000Hz 2ch s16le (2 bytes per sample)*
*Video: no video*


So I am guessing that the SPDIF decoding is not being done by mplayer, it
is in the ALSA drivers you have on your system - and maybe specific to the
hardware they are driving.

Does this sound as though it is the likely reason for me not seeing your
results? And can I replicate your configuration with the proper
installation of alsa drivers?

--

Mark Nelson – ma...@ieee.org - http://marknelson.us

On Mon, Dec 28, 2015 at 1:34 PM, Carl Eugen Hoyos  wrote:

> Mark Nelson  ieee.org> writes:
>
> > Same file wrappred in SMPTE-377M headers and packaged
> > in a WAV file as if it were 1536 kbps PCM:
> >
> > https://www.dropbox.com/s/tec7al5bcmihwey/sample.eac3.337.wav
>
> Is this really valid?
> My receiver cannot play this, the following plays as
> expected here (showing that eac3-over-spdif works
> fine on my equipment):
> $ ffmpeg -i input -acodec eac3 -f spdif out
> $ ffmpeg -f s16le -ac 2 -ar 192k -i out -acodec copy out.wav
> $ mplayer out.wav -ao alsa:device=hw=1.7
>
> I can make your file play but I wonder if I should...
> (And yes, I do remember that this isn't your issue
> but I would still like to understand the issue first.)
>
> Carl Eugen
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Michael Koch]

well, then i ask the question different

"--width=600 --width=300" - what would you expect?



before I saw your answer, it was unclear to me if it's 300 or 600.

Michael
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:

I’m not really looking for perfection, just don’t want the transcodes to be
darker on any device.

So my testing has shown, for both libx264 and libx265, the problem is
solved (meaning the pngs come out with the same luminosity, which
is good enough for me) either of two ways, using ffmpeg options:

-color_primaries bt709 -color_trc bt709 -colorspace bt709

or using x264/5 params:

-x264-params colormatrix=bt709:colorprim=bt709:transfer=bt709

These alternatives are not quite parallel, I know.  Frankly I don’t
really understand them.  I’m guessing colormatrix is the only one
needed but haven’t tested.  In any case, it seems ffmpeg or libx26* needs
this direction.


Well I’m really confused now.  When I went back to the full source
file (rather than the 1 minute clipped from  it, which was a
stream copy), the transcode with x265-params came out BRIGHTER
than the source.  My head’s about to explode.  I’m just going
to stick with this result.


Ouch, did the new file show as 709 with

ffmpeg -i newfile.mkv

I can't reproduce this one myself x265-params seems to work.
If for some reason the newfile didn't get flagged as 709 then it could 
be possible to get brighter with different colours in a scene.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Matthew Adams]

No, I'm not running iOS on my desktop.  It's a MacBook Pro w/El Capitan.

I pulled the files off of the iPhone using iExplorer, a nice little tool to
get at the iOS filesystem.

On Tue, Jan 5, 2016 at 11:14 AM, Another Sillyname <
anothersn...@googlemail.com> wrote:

> Only d/loaded one...am away from machine now.
>
> Are you running IOS on your desktop machine?
>
> On 5 January 2016 at 17:09, Matthew Adams  wrote:
> > Wow thanks Carl.  Two questions.
> >
> > 1. Is 1.65s consistent on both ends of the video & in both videos?
> > 2. If so, can cut (on both ends), transcode & merge be scripted with
> bash &
> > ffmpeg?
> >
> >
> > On Tue, Jan 5, 2016 at 10:32 AM, Another Sillyname <
> > anothersn...@googlemail.com> wrote:
> >
> >> It's at 1.65 seconds it goes into 'slo mo' mode, but there's no change
> >> in framerate reported by either ffmpeg or mplayer and 'proper' speed
> >> would appear to need it to be run at about 220 fps after 1.65 seconds.
> >>
> >> Bit weird.
> >>
> >> Can't see an immediate way to do this without manual cut, transcode and
> >> merge.
> >>
> >>
> >>
> >> On 5 January 2016 at 16:10, Matthew Adams 
> wrote:
> >> > No video player does.  It starts out in regular motion, then goes to
> >> super
> >> > slow motion, then reverts back to regular motion.
> >> >
> >> > I've viewed the file on Mac OS X El Capitan using VLC 2.2.1 &
> QuickTime
> >> > 10.4.  If I create a new project in iMovie 10.1, import the file, then
> >> add
> >> > the entire clip to the project, it still renders regular speed, then
> >> fast,
> >> > then regular.  If I could easily identify how many frames are in
> regular
> >> > speed at either end of the clip, I might be able to fix them, but that
> >> > won't scale to the 100+ rallies I have to edit.  I'm not willing to
> >> assume
> >> > the same number of frames are in regular v. slow motion across files
> or
> >> on
> >> > either end of the clip.  [sigh]
> >> >
> >> > I uploaded one more file to comparison:  goo.gl/YVyBfp
> >> >
> >> > -matthew
> >> >
> >> > On Tue, Jan 5, 2016 at 9:37 AM, Carl Eugen Hoyos 
> >> wrote:
> >> >
> >> >> Matthew Adams  matthewadams.me> writes:
> >> >>
> >> >> > goo.gl/Bb6tQW
> >> >>
> >> >> Which player plays this file at the correct speed?
> >> >>
> >> >> Carl Eugen
> >> >>
> >> >> ___
> >> >> ffmpeg-user mailing list
> >> >> ffmpeg-user@ffmpeg.org
> >> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > mailto:matt...@matthewadams.me 
> >> > skype:matthewadams12
> >> > googletalk:matt...@matthewadams.me
> >> > http://matthewadams.me
> >> > http://www.linkedin.com/in/matthewadams
> >> > ___
> >> > ffmpeg-user mailing list
> >> > ffmpeg-user@ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >> ___
> >> ffmpeg-user mailing list
> >> ffmpeg-user@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >>
> >
> >
> >
> > --
> > mailto:matt...@matthewadams.me 
> > skype:matthewadams12
> > googletalk:matt...@matthewadams.me
> > http://matthewadams.me
> > http://www.linkedin.com/in/matthewadams
> > ___
> > ffmpeg-user mailing list
> > ffmpeg-user@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>



-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Matthew Adams]

Here is a link to zipped copies of originals placed on my dropbox account.
I zipped them in order to reduce the likelihood that they're changed by the
file hosting service.

https://www.dropbox.com/s/31civbxpe1utote/2016-01-02%2C%20Tour%20Warm%20Up.zip?dl=0



On Tue, Jan 5, 2016 at 2:08 PM, Moritz Barsnick  wrote:

> On Tue, Jan 05, 2016 at 13:30:07 -0600, Matthew Adams wrote:
> > I pulled the files off of the iPhone using iExplorer, a nice little tool
> to
> > get at the iOS filesystem.
>
> Hmm. Something tells me this isn't the raw video as it comes from your
> device, but it was manipulated by Google (Drive) after your upload:
>
> $ sha1sum variable-bitrate-sample.mov
> 3820bb93784835f2257299008fed2fafeaacd5c5  variable-bitrate-sample.mov
> $ ffmpeg -i variable-bitrate-sample.mov
> ffmpeg version 2.6.5 Copyright (c) 2000-2015 the FFmpeg developers
> [...]
> Metadata:
>   creation_time   : 2016-01-03 05:53:31
>   handler_name: IsoMedia File Produced by Google, 5-11-2011
>
> I don't think any Apple product inserts such metadata. ;-)
>
> Googl(ouch!)ing a bit, it does seem iOS creates variable frame rate
> videos. But usually, they are detected as such, or in other words, the
> headers and timestamps properly reflect that.
>
> So I think Google Drive ruined your video by doing some bad CFR magic
> to it.
>
> The video as *I* get it from your Google drive is not fixable without
> manual analysis of the timeline. Likely the original video which is (or
> has remained) on your iPhone is different. If it doesn't play fine
> there either, the video recording software fooled you, or did this
> effect on purpose due to some configuration. If it does play correctly
> on the iPhone though, you may need to find a different way to get that
> file to us. You probably wouldn't even need to fix it if Google Drive
> (your way to share the videos with others?) didn't mess it up.
>
> ffmpeg *can* convert VFR to CFR if need be (for the sake of players
> which can't handle the former).
>
> Moritz
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>



-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Reindl Harald]

Am 05.01.2016 um 15:04 schrieb Roger Pack:

As a note, I just had to get this off my chest, and I'll only say this
once.  Some of FFmpeg's command line syntax is *confusing* and *super
confusing* for beginners.

For instance this:

ffmpeg -r 30 -i input_file

specifies a framerate *override* for the input, however if you specify
it for the output, its just the "normal" output frame rate...:


what else would you expect?


ffmpeg -i input -r 10 output

and this:
ffmpeg -i input -f rawvideo -f nut output.nut

Using (or being able to use)  "-f"
typically using two "-f" s would be an override.  But in this case it
isn't.  In fact, its using "-f" to specify two entirely different
aspects of the output file.  It's hard to see, but to beginners, this
is *super* confusing.


it *is* a override


Being able to specify global settings "in the middle of an input file"
is also confusing..


there is NOTHING "in the middle"

since it's *after* "-i" it's no longer for the input file and when you 
specify something twice the right one wins, the same for GCC because 
otherwise you would not be able to override at all





signature.asc
Description: OpenPGP digital signature
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Moritz Barsnick]

On Tue, Jan 05, 2016 at 13:30:07 -0600, Matthew Adams wrote:
> I pulled the files off of the iPhone using iExplorer, a nice little tool to
> get at the iOS filesystem.

Hmm. Something tells me this isn't the raw video as it comes from your
device, but it was manipulated by Google (Drive) after your upload:

$ sha1sum variable-bitrate-sample.mov
3820bb93784835f2257299008fed2fafeaacd5c5  variable-bitrate-sample.mov
$ ffmpeg -i variable-bitrate-sample.mov 
ffmpeg version 2.6.5 Copyright (c) 2000-2015 the FFmpeg developers
[...]
Metadata:
  creation_time   : 2016-01-03 05:53:31
  handler_name: IsoMedia File Produced by Google, 5-11-2011

I don't think any Apple product inserts such metadata. ;-)

Googl(ouch!)ing a bit, it does seem iOS creates variable frame rate
videos. But usually, they are detected as such, or in other words, the
headers and timestamps properly reflect that.

So I think Google Drive ruined your video by doing some bad CFR magic
to it.

The video as *I* get it from your Google drive is not fixable without
manual analysis of the timeline. Likely the original video which is (or
has remained) on your iPhone is different. If it doesn't play fine
there either, the video recording software fooled you, or did this
effect on purpose due to some configuration. If it does play correctly
on the iPhone though, you may need to find a different way to get that
file to us. You probably wouldn't even need to fix it if Google Drive
(your way to share the videos with others?) didn't mess it up.

ffmpeg *can* convert VFR to CFR if need be (for the sake of players
which can't handle the former).

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> 
> Ouch, did the new file show as 709 with
> 
> ffmpeg -i newfile.mkv
> 
> I can't reproduce this one myself x265-params seems to work.
> If for some reason the newfile didn't get flagged as 709 then it could be 
> possible to get brighter with different colours in a scene.

Yes.  The ORIGINAL source file gives
Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 
23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

The transcode with the x265-params gives
Stream #0:0(eng): Video: hevc (Main), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 
DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Could the problem be that the input is not recognized as bt709, even though it 
is?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> Yes, that's probably it.
> 
> Maybe you could try below to see if the original shows 709 -
> 
> ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts
> 
> FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg 
> doesn't work for libx265.
> 
> It does work if you use it via -x265-params pass=

No, the original m2ts with the analyze/probe options gives
Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 
1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc

So is it possible to use the -colormatrix and other color options 
as input options?  Is that what I should be doing?  Incidentally, 
those don’t seem to be in the documentation at all.

pass has been working for me - maybe they fixed that in x265 v. 1.8?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Matthew Adams]

Moritz & Steve,

Thanks for your ffmpeg commands.  On my MacBook Pro Retina 15", I ran them
(took less than 30 secs or so) and then viewed the resulting files in both
VLC & QuickTime.

Both of the resulting videos did *exactly* what I was trying to get rid of:
 a second or so of real-time action at the beginning, then a long super
slow-motion middle, then a second or so of real-time action at the end.

I just want the whole video to be in real time.  Size is of secondary
concern.  Interestingly, QuickTime actually *shows *where the three
sections are with two delimiters -- I wish I could show you the screen
shot, but I can't get a screen shot of the QuickTime controls overlay (it
keeps disappearing).  Even more interestingly, VLC plays some of the videos
choppily but in real time with no slow motion; QuickTime shows the
different frame rates, but lets me speed things up to real-time.  I admin
to being at a bit of a loss to determine why VLC is in choppy real-time &
QuickTime always honors the recorded frame rates.

Any more suggestions/sample commands?  Will I need to cut the real-time
portions out, then convert the middle slo-mo to match the real-time
portions' frame rates, then concatenate the three parts all back together?
If so, how do I (1) find the 2 spots to cut at, (2) actually cut the file
into 3 parts, (3) convert the slo-mo to real-time, then (4) concatenate
them all back together again?

-matthew

PS: FWIW, with a 10.7 Mb original video, Steve's command resulted in a 13.7
Mb video, Moritz's, 9.3 Mb.

On Tue, Jan 5, 2016 at 8:52 PM, Steve Boyer <steveboye...@gmail.com> wrote:

> On Tue, Jan 5, 2016 at 6:56 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> > Matthew Adams wrote:
> >>
> >> On Tue, Jan 5, 2016 at 3:07 PM, Moritz Barsnick <barsn...@gmx.net>
> >> wrote:
> >>
> >>> Anyway, it should be possible to convert those to something sane.
> >>> As Carl Eugen mentions: What's your goal?
> >>>
> >>
> >> My goal is to convert these videos a fixed, relatively standard (30
> >> fps? 60 fps?) frame rate while retaining the highest image quality
> >> possible so that pretty much any playback hardware & software can
> >> play them normally. Bonus for preserving audio as well in the
> >> converted videos.
> >
> >
> > Well I am impressed that a phone can record 240fps.
> >
> > Personally I would go for 60 fps, fast paced stuff looks terrible @30fps.
> >
> > I suppose it depends on what you intend to play it on.
> >
> > If the quality is too low for you you can always get higher bitrates
> > with eg. -crf 20.
> >
> > FWIW testing the master direct mpv by default does a good job playing it
> > on my PC.
> >
> > ___
> > ffmpeg-user mailing list
> > ffmpeg-user@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> Tested on the windows 10 side of my laptop with the command:
> "C:\Users\Steve\Desktop\ffmpeg-20160105-git-68eb208-win64-static\bin>ffmpeg
> -i C:\Users\Steve\Desktop\Jan22016-150PM-b6cs7K.mov -vf fps=fps=30
> -c:a copy -vcodec libx264 -crf 20 -preset slow asdf.mp4"
>
> and it spits out a fixed frame rate 30fps video and looks purdy. VLC
> plays it no problems. This will preserve the audio feed exactly, and
> only re-encodes the video using x264 at a pretty decent quality. Final
> size is 9 MB.
>
> Steve
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>



-- 
mailto:matt...@matthewadams.me <matt...@matthewadams.me>
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Can FFmpeg fetch a title from a DVD?

[Andy Civil]

Thank you for all the suggestions.

I want to stick to open-source if possible, on principle.

I tried MPlayer, but I got an error; libdvdread complained that it couldn't open the file with 
libdvdcss. Not sure why. It seemed to open the DVD OK, because it told me the correct number of 
titles on it.


I'm guessing that FFmpeg can't do it, since I got the alternative suggestions.

I've found somewhat of a workaround with VLC (not sure if that's technically FOSS or not) that I can 
live with, if there's no FFmpeg solution.


Thanks!

--
Andy
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Can FFmpeg fetch a title from a DVD?

[Steve Boyer]

On Tue, Jan 5, 2016 at 5:59 PM, Nicholas Robbins
 wrote:
> You might also want to take a look at makemkv (makemkv.com)
Second the nomination of MakeMKV. Not free, but it has a linux version
that you can "compile" and install. In my experience, MakeMKV is the
only program that can successfully backup DVDs from a *ahem* parent
company of a certain mouse.
> -N
Steve
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Steve Boyer]

On Tue, Jan 5, 2016 at 6:56 PM, Andy Furniss <adf.li...@gmail.com> wrote:
> Matthew Adams wrote:
>>
>> On Tue, Jan 5, 2016 at 3:07 PM, Moritz Barsnick <barsn...@gmx.net>
>> wrote:
>>
>>> Anyway, it should be possible to convert those to something sane.
>>> As Carl Eugen mentions: What's your goal?
>>>
>>
>> My goal is to convert these videos a fixed, relatively standard (30
>> fps? 60 fps?) frame rate while retaining the highest image quality
>> possible so that pretty much any playback hardware & software can
>> play them normally. Bonus for preserving audio as well in the
>> converted videos.
>
>
> Well I am impressed that a phone can record 240fps.
>
> Personally I would go for 60 fps, fast paced stuff looks terrible @30fps.
>
> I suppose it depends on what you intend to play it on.
>
> If the quality is too low for you you can always get higher bitrates
> with eg. -crf 20.
>
> FWIW testing the master direct mpv by default does a good job playing it
> on my PC.
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Tested on the windows 10 side of my laptop with the command:
"C:\Users\Steve\Desktop\ffmpeg-20160105-git-68eb208-win64-static\bin>ffmpeg
-i C:\Users\Steve\Desktop\Jan22016-150PM-b6cs7K.mov -vf fps=fps=30
-c:a copy -vcodec libx264 -crf 20 -preset slow asdf.mp4"

and it spits out a fixed frame rate 30fps video and looks purdy. VLC
plays it no problems. This will preserve the audio feed exactly, and
only re-encodes the video using x264 at a pretty decent quality. Final
size is 9 MB.

Steve
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Can FFmpeg fetch a title from a DVD?

[y...@yzf888.com]

You would try Free DVD ripper at   
http://www.free-star.org/free-dvd-ripper-freeware.html
 










At 2016-01-06 10:42:13, "Steve Boyer"  wrote:
>On Tue, Jan 5, 2016 at 5:59 PM, Nicholas Robbins
> wrote:
>> You might also want to take a look at makemkv (makemkv.com)
>Second the nomination of MakeMKV. Not free, but it has a linux version
>that you can "compile" and install. In my experience, MakeMKV is the
>only program that can successfully backup DVDs from a *ahem* parent
>company of a certain mouse.
>> -N
>Steve
>___
>ffmpeg-user mailing list
>ffmpeg-user@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-user
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Steve Boyer]

On Tue, Jan 5, 2016 at 10:15 PM, Matthew Adams <matt...@matthewadams.me> wrote:
> Moritz & Steve,
>
> Thanks for your ffmpeg commands.  On my MacBook Pro Retina 15", I ran them
> (took less than 30 secs or so) and then viewed the resulting files in both
> VLC & QuickTime.
>
> Both of the resulting videos did *exactly* what I was trying to get rid of:
>  a second or so of real-time action at the beginning, then a long super
> slow-motion middle, then a second or so of real-time action at the end.

Matthew,
One quick sanity-check -- are you running the commands on
"variable-bitrate-sample.mov" or on the raw
"Jan22016-150PM-b6cs7K.mov"? I downloaded all three files and here are
the commands used (jumped back to the linux side with an older version
of FFmpeg compiled [built on Nov 16 2014 15:41:37 with gcc 4.8 (Ubuntu
4.8.2-19ubuntu1], but should still work in newest version):

ffmpeg -i Jan22016-150PM-b6cs7K.mov -c:a copy -c:v libx264 -vf
fps=fps=30 -crf 20 -preset slow Jan22016-150PM-b6cs7K.mp4
ffmpeg -i Jan22016-151PM-g8drtF.mov -c:a copy -c:v libx264 -vf
fps=fps=30 -crf 20 -preset slow Jan22016-151PM-g8drtF.mp4
ffmpeg -i variable-bitrate-sample.mov -c:a copy -c:v libx264 -vf
fps=fps=30 -crf 20 -preset slow variable-bitrate-sample.mov

Running the FFmpeg commands, I get:
...150PM... filesizes: MOV: 61M, MP4: 8.9M
...151PM... filesizes: MOV: 27M, MP4: 3.9M
variable... filesizes: MOV: 11M, MP4: 14M

"150PM" and "151PM" are both in real-time, audio preserved, in 30fps
wonder (easy to change this to 60 fps if you desire by mucking around
in the commands above). The "variable" file does not have audio and
plays for a few seconds in realtime, then goes into slow-motion.

> I just want the whole video to be in real time.  Size is of secondary
> concern.  Interestingly, QuickTime actually *shows *where the three
> sections are with two delimiters -- I wish I could show you the screen
> shot, but I can't get a screen shot of the QuickTime controls overlay (it
> keeps disappearing).  Even more interestingly, VLC plays some of the videos
> choppily but in real time with no slow motion; QuickTime shows the
> different frame rates, but lets me speed things up to real-time.  I admin
> to being at a bit of a loss to determine why VLC is in choppy real-time &
> QuickTime always honors the recorded frame rates.
>
> Any more suggestions/sample commands?  Will I need to cut the real-time
> portions out, then convert the middle slo-mo to match the real-time
> portions' frame rates, then concatenate the three parts all back together?
> If so, how do I (1) find the 2 spots to cut at, (2) actually cut the file
> into 3 parts, (3) convert the slo-mo to real-time, then (4) concatenate
> them all back together again?
>
> -matthew
>
> PS: FWIW, with a 10.7 Mb original video, Steve's command resulted in a 13.7
> Mb video, Moritz's, 9.3 Mb.
>
> On Tue, Jan 5, 2016 at 8:52 PM, Steve Boyer <steveboye...@gmail.com> wrote:
>
>> On Tue, Jan 5, 2016 at 6:56 PM, Andy Furniss <adf.li...@gmail.com> wrote:
>> > Matthew Adams wrote:
>> >>
>> >> On Tue, Jan 5, 2016 at 3:07 PM, Moritz Barsnick <barsn...@gmx.net>
>> >> wrote:
>> >>
>> >>> Anyway, it should be possible to convert those to something sane.
>> >>> As Carl Eugen mentions: What's your goal?
>> >>>
>> >>
>> >> My goal is to convert these videos a fixed, relatively standard (30
>> >> fps? 60 fps?) frame rate while retaining the highest image quality
>> >> possible so that pretty much any playback hardware & software can
>> >> play them normally. Bonus for preserving audio as well in the
>> >> converted videos.
>> >
>> >
>> > Well I am impressed that a phone can record 240fps.
>> >
>> > Personally I would go for 60 fps, fast paced stuff looks terrible @30fps.
>> >
>> > I suppose it depends on what you intend to play it on.
>> >
>> > If the quality is too low for you you can always get higher bitrates
>> > with eg. -crf 20.
>> >
>> > FWIW testing the master direct mpv by default does a good job playing it
>> > on my PC.
>> >
>> > ___
>> > ffmpeg-user mailing list
>> > ffmpeg-user@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>> Tested on the windows 10 side of my laptop with the command:
>> "C:\Users\Steve\Desktop\ffmpeg-20160105-git-68eb208-win64-static\bin>ffmpeg
>> -i C:\Users\Steve\Desktop\Jan22016-150PM-b6cs7K.mov -vf fps=fps=30
>> -c:a copy -vcodec libx264 -cr

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> On 2016 Jan 5, at 3:13 PM, Jim Worrall  wrote:
> 
>> Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as slow as 
>> pass 2. As expected he result is worse as well.
>> 
> Uh-oh, I thought that’s what was supposed to happen (except for the worse 
> result part).  I thought libx264 worked that way.  I better try it the other 
> way!

I just tested doing pass both ways.  It is true that ffmpeg’s log appears to 
remain empty, while x265’s does not.  But the output is identical as near as I 
can tell, and putting pass as an ffmpeg option was actually slightly faster 
(both passes about the same speed as opposed to pass 1 being a bit slower via 
x265-params.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Carl Eugen Hoyos]

Matthew Adams  matthewadams.me> writes:

> https://www.dropbox.com/s/31civbxpe1utote/2016-01-02%2C%20Tour%20Warm%20Up.zip

These videos can be decoded with FFmpeg, you just 
have to define what you want to do with them.

Please do not top-post here, Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] Can FFmpeg fetch a title from a DVD?

[Andy Civil]

Can anyone tell me if there's a command to fetch a title (this is DVD-speak for a 'track') from a 
DVD file structure? I have a DVD structure in a VIDEO_TS folder, and I want to fetch title #7 from 
it, and convert it to something. This requires FFmpeg to be aware of the DVD menu structure, and I'm 
not sure that it is. (I've been trying to use VLC which definitely can, but I've had other issues 
there.)


I know that FFmpeg can work directly with the VOB files, but that doesn't help me when I don't know 
where Title #7 starts, or ends.  Sometimes, there are multiple VOB files, and I don't even know 
which VOB Title #7 is in...


Thanks!

--
Andy

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] flame about confusing command line options.

[Carl Eugen Hoyos]

Reindl Harald  thelounge.net> writes:

> when you specify something twice the right one wins

I fear it's not that easy: It is actually undefined 
behaviour to specify an option twice (that is not 
supposed to be specified more than once), so for 
example ticket #4184.

Carl Eugen

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Moritz Barsnick]

On Tue, Jan 05, 2016 at 14:51:46 -0600, Matthew Adams wrote:
> > https://www.dropbox.com/s/31civbxpe1utote/2016-01-02%2C%20Tour%20Warm%20Up.zip?dl=0

Ah, those are indeed different. They are true VFR.

> Don't forget that these videos were created by Coach's Eye
>  for iOS.  I don't know anything about their
> internals WRT recording videos.

Oh yeah, I forget that you had mentioned that. Well, their YouTube
explanation videos don't mention the funny effect you have been seeing.

The problem with the videos you provided is that they are well over 200
fps, and my laptop doesn't play them well. ffplay repeatedly stalls for
a few seconds, mplayer plays almost okay if I enable "hard skipping" of
frames. ;-) But generally, they are totally sane.

Anyway, it should be possible to convert those to something sane. As
Carl Eugen mentions: What's your goal?

(My simplest approach, guessing your goal as previously written:
 $ ffmpeg -i Jan22016-150PM-b6cs7K.mov -c:v libx264 -c:a copy -r 30 
Jan22016-150PM-b6cs7K.r30.mov
)

Moritz
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:

Yes, that's probably it.

Maybe you could try below to see if the original shows 709 -

ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts

FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg doesn't 
work for libx265.

It does work if you use it via -x265-params pass=


No, the original m2ts with the analyze/probe options gives
 Stream #0:0[0x1011]: Video: h264 (High) (HDMV / 0x564D4448), yuv420p, 
1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 90k tbn, 47.95 tbc


Oh, I hadn't noticed that before - it's the same if I test my own m2ts 
files.




So is it possible to use the -colormatrix and other color options
as input options?  Is that what I should be doing?  Incidentally,
those don’t seem to be in the documentation at all.


For the transcode they should be OK as output options - AFAIK all they 
do is set some metadata.


For making a png from the input they do seem to work as input options.

They do show in ffmpeg -h full.


pass has been working for me - maybe they fixed that in x265 v. 1.8?


I'll have to try that - I was using some old Hg now on new Hg (not 
videolans as that doesn't seem to get updated anymore).


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as slow as 
pass 2. As expected he result is worse as well.



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Andy Furniss]

Matthew Adams wrote:

On Tue, Jan 5, 2016 at 3:07 PM, Moritz Barsnick 
wrote:


Anyway, it should be possible to convert those to something sane.
As Carl Eugen mentions: What's your goal?



My goal is to convert these videos a fixed, relatively standard (30
fps? 60 fps?) frame rate while retaining the highest image quality
possible so that pretty much any playback hardware & software can
play them normally. Bonus for preserving audio as well in the
converted videos.


Well I am impressed that a phone can record 240fps.

Personally I would go for 60 fps, fast paced stuff looks terrible @30fps.

I suppose it depends on what you intend to play it on.

If the quality is too low for you you can always get higher bitrates
with eg. -crf 20.

FWIW testing the master direct mpv by default does a good job playing it
on my PC.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> On 2016 Jan 5, at 5:17 PM, Andy Furniss  wrote:
> I snipped some other "evidence" in my last post.
> 
> If you want to check outputs between the two ways look at the last
> lines of the larger block of x265 [info].
> 
> with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -
> 
> x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
> x265 [info]: tools: deblock sao
> 
> with x265-params they are different and refer to reading/writing stats.
> 
> x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
> x265 [info]: tools: strong-intra-smoothing deblock sao stats-write
> 
> 
> x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
> x265 [info]: tools: deblock sao stats-read
> 

OK, something’s wrong with my setup then.  When I put pass into 
x265-params, I get the same thing in both passes, with stats-write
both times:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

What could be going on?
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:



On 2016 Jan 5, at 5:17 PM, Andy Furniss  wrote:
I snipped some other "evidence" in my last post.

If you want to check outputs between the two ways look at the last
lines of the larger block of x265 [info].

with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -

x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

with x265-params they are different and refer to reading/writing stats.

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write


x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao stats-read



OK, something’s wrong with my setup then.  When I put pass into
x265-params, I get the same thing in both passes, with stats-write
both times:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write

What could be going on?


I would double check your command line(s) - if they seem OK paste 
it/them along with the full output(s).



___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> On 2016 Jan 5, at 6:06 PM, Andy Furniss  wrote:
> I would double check your command line(s) - if they seem OK paste it/them 
> along with the full output(s).
> 
You are so right.  I had pass=1 twice (I’m going to hide under
a rock now).  Now I get:

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-write
encoded 719 frames in 108.41s (6.63 fps), 3099.37 kb/s, Avg QP:24.68

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock stats-read
encoded 719 frames in 103.39s (6.95 fps), 2990.00 kb/s, Avg QP:24.61

Still getting ~the same time in both passes (this is preset ‘superfast’).

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

[FFmpeg-user] ffplay and increasing delay (latency)

[Ilya Matveychikov]

Hello,

I'm using ffplay to play an RTMP stream from the nginx/rtmp server. The
stream
from the microphone is being captured with ffmpeg as follows:

ffmpeg -fflags nobuffer -re -f alsa -i hw:0,0 -c:a nellymoser \
-ar 11025 -ab 8k -ac 1 -f flv rtmp://192.168.88.244/live/1

Next, I have rtmp nginx (192.168.88.244) plugin configured as:

rtmp {
server {
application live {
live on;
record off;
}
}
}

And finally, I'm using ffplay to play the stream (from the localhost):

ffplay -probesize 32 rtmp://127.0.0.1/live/1

Everything works fine except the growing latency of ffplay. The more
it plays the
more delay is produced. I'm sure that the problem at the ffplay end as
restarting
the player solves the problem for a while.

Hope someone knows how to solve the problem.

Thanks in advice.
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:



On 2016 Jan 5, at 4:28 PM, Andy Furniss  wrote:

Jim Worrall wrote:



On 2016 Jan 5, at 3:13 PM, Jim Worrall 
wrote:


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.


Uh-oh, I thought that’s what was supposed to happen (except for the
worse result part).  I thought libx264 worked that way.  I better
try it the other way!


I just tested doing pass both ways.  It is true that ffmpeg’s log
appears to remain empty, while x265’s does not.  But the output is
identical as near as I can tell, and putting pass as an ffmpeg option
was actually slightly faster (both passes about the same speed as
opposed to pass 1 being a bit slower via x265-params.


Hmm I just tried release x265 and with ffmpeg both my passes were the
same time, with x265-parans pass 1 was twice as fast. Quality was a bit
better min psnr wise with x265. Visually I could only really tell on the
first 10 frames - it seemed much the same after that. stats below show
that more was spent on I frames with x265-params.


OK, I bow to your greater knowledge and experience, and will start
using ‘pass’ in x265-params.  Thank you!


I snipped some other "evidence" in my last post.

If you want to check outputs between the two ways look at the last
lines of the larger block of x265 [info].

with ffmpeg the last 2 lines of both pass 1 and 2 are the same for me -

x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

with x265-params they are different and refer to reading/writing stats.

x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write


x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao stats-read

___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:


Ouch, did the new file show as 709 with

ffmpeg -i newfile.mkv

I can't reproduce this one myself x265-params seems to work.
If for some reason the newfile didn't get flagged as 709 then it could be 
possible to get brighter with different colours in a scene.


Yes.  The ORIGINAL source file gives
Stream #0:0(eng): Video: h264 (High), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 
23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc

The transcode with the x265-params gives
Stream #0:0(eng): Video: hevc (Main), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 
DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 23.98 tbc (default)

Could the problem be that the input is not recognized as bt709, even though it 
is?


Yes, that's probably it.

Maybe you could try below to see if the original shows 709 -

ffmpeg -analyzeduration 100M -probesize 100M -i original.m2ts

FWIW I just noticed another issue - using pass 1 and pass 2 via ffmpeg 
doesn't work for libx265.


It does work if you use it via -x265-params pass=


___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Need help; willing to pay

[Matthew Adams]

Don't forget that these videos were created by Coach's Eye
 for iOS.  I don't know anything about their
internals WRT recording videos.

On Tue, Jan 5, 2016 at 2:50 PM, Matthew Adams 
wrote:

> Here is a link to zipped copies of originals placed on my dropbox
> account.  I zipped them in order to reduce the likelihood that they're
> changed by the file hosting service.
>
>
> https://www.dropbox.com/s/31civbxpe1utote/2016-01-02%2C%20Tour%20Warm%20Up.zip?dl=0
>
>
>
> On Tue, Jan 5, 2016 at 2:08 PM, Moritz Barsnick  wrote:
>
>> On Tue, Jan 05, 2016 at 13:30:07 -0600, Matthew Adams wrote:
>> > I pulled the files off of the iPhone using iExplorer, a nice little
>> tool to
>> > get at the iOS filesystem.
>>
>> Hmm. Something tells me this isn't the raw video as it comes from your
>> device, but it was manipulated by Google (Drive) after your upload:
>>
>> $ sha1sum variable-bitrate-sample.mov
>> 3820bb93784835f2257299008fed2fafeaacd5c5  variable-bitrate-sample.mov
>> $ ffmpeg -i variable-bitrate-sample.mov
>> ffmpeg version 2.6.5 Copyright (c) 2000-2015 the FFmpeg developers
>> [...]
>> Metadata:
>>   creation_time   : 2016-01-03 05:53:31
>>   handler_name: IsoMedia File Produced by Google, 5-11-2011
>>
>> I don't think any Apple product inserts such metadata. ;-)
>>
>> Googl(ouch!)ing a bit, it does seem iOS creates variable frame rate
>> videos. But usually, they are detected as such, or in other words, the
>> headers and timestamps properly reflect that.
>>
>> So I think Google Drive ruined your video by doing some bad CFR magic
>> to it.
>>
>> The video as *I* get it from your Google drive is not fixable without
>> manual analysis of the timeline. Likely the original video which is (or
>> has remained) on your iPhone is different. If it doesn't play fine
>> there either, the video recording software fooled you, or did this
>> effect on purpose due to some configuration. If it does play correctly
>> on the iPhone though, you may need to find a different way to get that
>> file to us. You probably wouldn't even need to fix it if Google Drive
>> (your way to share the videos with others?) didn't mess it up.
>>
>> ffmpeg *can* convert VFR to CFR if need be (for the sake of players
>> which can't handle the former).
>>
>> Moritz
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-user@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>
>
>
>
> --
> mailto:matt...@matthewadams.me 
> skype:matthewadams12
> googletalk:matt...@matthewadams.me
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
>



-- 
mailto:matt...@matthewadams.me 
skype:matthewadams12
googletalk:matt...@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Jim Worrall]

> On 2016 Jan 5, at 4:28 PM, Andy Furniss  wrote:
> 
> Jim Worrall wrote:
>> 
>>> On 2016 Jan 5, at 3:13 PM, Jim Worrall 
>>> wrote:
>>> 
 Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
 slow as pass 2. As expected he result is worse as well.
 
>>> Uh-oh, I thought that’s what was supposed to happen (except for the
>>> worse result part).  I thought libx264 worked that way.  I better
>>> try it the other way!
>> 
>> I just tested doing pass both ways.  It is true that ffmpeg’s log
>> appears to remain empty, while x265’s does not.  But the output is
>> identical as near as I can tell, and putting pass as an ffmpeg option
>> was actually slightly faster (both passes about the same speed as
>> opposed to pass 1 being a bit slower via x265-params.
> 
> Hmm I just tried release x265 and with ffmpeg both my passes were the
> same time, with x265-parans pass 1 was twice as fast. Quality was a bit
> better min psnr wise with x265. Visually I could only really tell on the
> first 10 frames - it seemed much the same after that. stats below show
> that more was spent on I frames with x265-params.

OK, I bow to your greater knowledge and experience, and will start
using ‘pass’ in x265-params.  Thank you!
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] Can FFmpeg fetch a title from a DVD?

[Nicholas Robbins]

> On Tuesday, January 5, 2016 4:25 PM, Matt Zagrabelny  
> wrote:

> > On Tue, Jan 5, 2016 at 3:20 PM, Andy Civil  wrote:
>>  Can anyone tell me if there's a command to fetch a title (this is 
> DVD-speak
>>  for a 'track') from a DVD file structure? I have a DVD structure in 
> a
>>  VIDEO_TS folder, and I want to fetch title #7 from it, and convert it to
>>  something. This requires FFmpeg to be aware of the DVD menu structure, and
>>  I'm not sure that it is. (I've been trying to use VLC which 
> definitely can,
>>  but I've had other issues there.)
>> 
>>  I know that FFmpeg can work directly with the VOB files, but that 
> doesn't
>>  help me when I don't know where Title #7 starts, or ends.  Sometimes, 
> there
>>  are multiple VOB files, and I don't even know which VOB Title #7 is 
> in...
> 
> I use:
> 
> mplayer -dumpstream -dumpfile dvd_title_7.vob dvd://7
> 
> That will dump title 7 to the file dvd_title_7.vob.
> 
> 
> -m


You might also want to take a look at makemkv (makemkv.com)

-N
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

Re: [FFmpeg-user] ffmpeg makes some sources darker

[Andy Furniss]

Jim Worrall wrote:



On 2016 Jan 5, at 3:13 PM, Jim Worrall 
wrote:


Currently I just get an empty ffmpeg2pass-0.log and pass 1 is as
slow as pass 2. As expected he result is worse as well.


Uh-oh, I thought that’s what was supposed to happen (except for the
worse result part).  I thought libx264 worked that way.  I better
try it the other way!


I just tested doing pass both ways.  It is true that ffmpeg’s log
appears to remain empty, while x265’s does not.  But the output is
identical as near as I can tell, and putting pass as an ffmpeg option
was actually slightly faster (both passes about the same speed as
opposed to pass 1 being a bit slower via x265-params.


Hmm I just tried release x265 and with ffmpeg both my passes were the
same time, with x265-parans pass 1 was twice as fast. Quality was a bit
better min psnr wise with x265. Visually I could only really tell on the
first 10 frames - it seemed much the same after that. stats below show
that more was spent on I frames with x265-params.


ffmpeg pass 1

frame= 1461 fps=2.8 q=-0.0 Lsize=   22424kB time=00:01:00.85 
bitrate=3018.8kbits/s speed=0.116x
video:22412kB audio:0kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.056528%

x265 [info]: frame I:  9, Avg QP:16.66  kb/s: 31133.07
x265 [info]: frame P:331, Avg QP:17.87  kb/s: 9346.73
x265 [info]: frame B:   1121, Avg QP:22.43  kb/s: 916.00
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 523.55s (2.79 fps), 3012.18 kb/s, Avg QP:21.36

ffmpeg pass 2

frame= 1461 fps=2.8 q=-0.0 Lsize=   23468kB time=00:01:00.85 
bitrate=3159.2kbits/s speed=0.116x
video:22412kB audio:1024kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.137361%

x265 [info]: frame I:  9, Avg QP:16.66  kb/s: 31133.07
x265 [info]: frame P:331, Avg QP:17.87  kb/s: 9346.73
x265 [info]: frame B:   1121, Avg QP:22.43  kb/s: 916.00
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 523.83s (2.79 fps), 3012.18 kb/s, Avg QP:21.36

x265 pass 1

frame= 1461 fps=6.0 q=-0.0 Lsize=   22471kB time=00:01:00.85 
bitrate=3025.0kbits/s speed=0.248x
video:22458kB audio:0kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.056320%

x265 [info]: frame I:  9, Avg QP:16.61  kb/s: 30834.66
x265 [info]: frame P:331, Avg QP:17.90  kb/s: 9711.25
x265 [info]: frame B:   1121, Avg QP:22.56  kb/s: 818.87
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 245.17s (5.96 fps), 3018.40 kb/s, Avg QP:21.47

x265 pass 2

frame= 1461 fps=2.9 q=-0.0 Lsize=   23364kB time=00:01:00.85 
bitrate=3145.3kbits/s speed=0.122x
video:22308kB audio:1024kB subtitle:0kB other streams:0kB global 
headers:1kB muxing overhead: 0.137916%

x265 [info]: frame I:  9, Avg QP:14.11  kb/s: 38589.83
x265 [info]: frame P:331, Avg QP:17.94  kb/s: 9318.05
x265 [info]: frame B:   1121, Avg QP:22.52  kb/s: 846.47
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 2.1% 0.3% 26.5% 8.2% 62.9%

encoded 1461 frames in 500.53s (2.92 fps), 2998.27 kb/s, Avg QP:21.43
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user