[FFmpeg-user] cat advice

[Rick Corteza]

Hello,

Prior to joining files with cat I often convert them using ffmpeg -i inputFile 
-target ntsc-dvd -qscale 5 outputFile to make them similar quality before 
joining. The problem with doing this is often the aspect ratio even if I use 
the -aspect flag. Does anyone have a suggestion on how to do this better? 
Thanks,

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[Ron Sparks]

On 02/26/2017 07:49 PM, Reuben Martin wrote:

Set the output format to flv. You can play flv before it’s finished encoding.
If you decide you want to keep it, you can dump the video and audio streams
from the flv into an mp4 file. (generally only takes a few seconds).


Another option is to use something like -t 60 to encode a minute then 
check if the settings work for what you want.


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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[DopeLabs]

I utilize ffplay a lot for previewing encoding settings.. make you might find 
it handy as well =]


> On Feb 26, 2017, at 4:49 39PM, Reuben Martin  wrote:
> 
> On Sunday, February 26, 2017 5:44:56 PM CST JD wrote:
>> On Sun, Feb 26, 2017 at 4:07 PM, Cley Faye  wrote:
>>> 2017-02-26 23:32 GMT+01:00 JD :
 Are there any flags that will let me playback an unfinished transcode?
 Reason I am asking is that if my various options in the transcode
 command
 did not yield what I like, then I would like to abort the transcode.
>>> 
>>> ​mp4 files will never be playable without "finishing" them. But you can
>>> interrupt the process at anytime with 'q'; that will properly close the
>>> file so you can play it.​
>> 
>> ​Thanks - that is somewhat a panacea, especially if one
>> is not 50% or more into the transcoding - so that issuing
>> a 'q' will not lose too much is only say the transcoding is
>> into 10 minutes of the video.
>> 
>> Now how about ffplay? I mean is/are there options
>> to ffplay that would allow the playing of the unfinsihed
>> mp4 file (without quitting the trancoding)?
>> ​
> 
> Set the output format to flv. You can play flv before it’s finished encoding. 
> If you decide you want to keep it, you can dump the video and audio streams 
> from the flv into an mp4 file. (generally only takes a few seconds).
> 
> -Reuben
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[JD]

On Sun, Feb 26, 2017 at 5:49 PM, Reuben Martin  wrote:

> On Sunday, February 26, 2017 5:44:56 PM CST JD wrote:
> > On Sun, Feb 26, 2017 at 4:07 PM, Cley Faye  wrote:
> > > 2017-02-26 23:32 GMT+01:00 JD :
> > > > Are there any flags that will let me playback an unfinished
> transcode?
> > > > Reason I am asking is that if my various options in the transcode
> > > > command
> > > > did not yield what I like, then I would like to abort the transcode.
> > >
> > > ​mp4 files will never be playable without "finishing" them. But you can
> > > interrupt the process at anytime with 'q'; that will properly close the
> > > file so you can play it.​
> >
> > ​Thanks - that is somewhat a panacea, especially if one
> > is not 50% or more into the transcoding - so that issuing
> > a 'q' will not lose too much is only say the transcoding is
> > into 10 minutes of the video.
> >
> > Now how about ffplay? I mean is/are there options
> > to ffplay that would allow the playing of the unfinsihed
> > mp4 file (without quitting the trancoding)?
> > ​
>
> Set the output format to flv. You can play flv before it’s finished
> encoding.
> If you decide you want to keep it, you can dump the video and audio streams
> from the flv into an mp4 file. (generally only takes a few seconds).
>
> -Reuben
>

​Thanx a lot, Reuben!!!
That's and excellent tip!​
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[Reuben Martin]

On Sunday, February 26, 2017 5:44:56 PM CST JD wrote:
> On Sun, Feb 26, 2017 at 4:07 PM, Cley Faye  wrote:
> > 2017-02-26 23:32 GMT+01:00 JD :
> > > Are there any flags that will let me playback an unfinished transcode?
> > > Reason I am asking is that if my various options in the transcode
> > > command
> > > did not yield what I like, then I would like to abort the transcode.
> > 
> > ​mp4 files will never be playable without "finishing" them. But you can
> > interrupt the process at anytime with 'q'; that will properly close the
> > file so you can play it.​
> 
> ​Thanks - that is somewhat a panacea, especially if one
> is not 50% or more into the transcoding - so that issuing
> a 'q' will not lose too much is only say the transcoding is
> into 10 minutes of the video.
> 
> Now how about ffplay? I mean is/are there options
> to ffplay that would allow the playing of the unfinsihed
> mp4 file (without quitting the trancoding)?
> ​

Set the output format to flv. You can play flv before it’s finished encoding. 
If you decide you want to keep it, you can dump the video and audio streams 
from the flv into an mp4 file. (generally only takes a few seconds).

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[Reindl Harald]

Am 27.02.2017 um 00:44 schrieb JD:

On Sun, Feb 26, 2017 at 4:07 PM, Cley Faye  wrote:


2017-02-26 23:32 GMT+01:00 JD :


Are there any flags that will let me playback an unfinished transcode?
Reason I am asking is that if my various options in the transcode command
did not yield what I like, then I would like to abort the transcode.



​mp4 files will never be playable without "finishing" them. But you can
interrupt the process at anytime with 'q'; that will properly close the
file so you can play it.​



​Thanks - that is somewhat a panacea, especially if one
is not 50% or more into the transcoding - so that issuing
a 'q' will not lose too much is only say the transcoding is
into 10 minutes of the video.

Now how about ffplay? I mean is/are there options
to ffplay that would allow the playing of the unfinsihed
mp4 file (without quitting the trancoding)?


just read about what "faststart" does - it moves important information 
so that a file can start playing before it is completly loaded which are 
normally only available after encoding is finished fro the end of the 
file at the begin


since that informations just don't exist before that you can answer that 
yourself


here you go:
http://www.adobe.com/devnet/video/articles/mp4_movie_atom.html
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[JD]

On Sun, Feb 26, 2017 at 4:07 PM, Cley Faye  wrote:

> 2017-02-26 23:32 GMT+01:00 JD :
>
> > Are there any flags that will let me playback an unfinished transcode?
> > Reason I am asking is that if my various options in the transcode command
> > did not yield what I like, then I would like to abort the transcode.
> >
>
> ​mp4 files will never be playable without "finishing" them. But you can
> interrupt the process at anytime with 'q'; that will properly close the
> file so you can play it.​
>

​Thanks - that is somewhat a panacea, especially if one
is not 50% or more into the transcoding - so that issuing
a 'q' will not lose too much is only say the transcoding is
into 10 minutes of the video.

Now how about ffplay? I mean is/are there options
to ffplay that would allow the playing of the unfinsihed
mp4 file (without quitting the trancoding)?
​
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[Cley Faye]

2017-02-26 23:32 GMT+01:00 JD :

> Are there any flags that will let me playback an unfinished transcode?
> Reason I am asking is that if my various options in the transcode command
> did not yield what I like, then I would like to abort the transcode.
>

​mp4 files will never be playable without "finishing" them. But you can
interrupt the process at anytime with 'q'; that will properly close the
file so you can play it.​
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -movflags faststart revisited

[JD]

Thanx.
Are there any flags that will let me playback an unfinished transcode?
Reason I am asking is that if my various options in the transcode command
did not yield what I like, then I would like to abort the transcode.

Kind regards,

JD

On Sat, Feb 25, 2017 at 9:28 PM, Geek.Song  wrote:

> On Sun, Feb 26, 2017 at 11:28 AM, JD  wrote:
> > I retried to use this flag as it was indicated in a previous response by
> a
> > user.
> > Sorry that I was unable to continue on the original thread, because the
> > gmail web
> > interface deletes original message sent to this list by the OP, when the
> OP
> > deletes the
> > response from the list.
> >
> > So, even though I corrected the usage of the flag, I am still unable to
> > play the output
> > file before ffmpeg finishes the transcoding :( :(
>
> '-movflags faststart'  will just move the header information from file
> bottom to file top, it is only take effect after you have finished
> encoding/muxing.
>
> So you can not use this flag  in real time encoding and playback.
>
> >
> > $ ~/bin/ffmpeg.d/ffmpeg -i video_Z11.mp4 -movflags faststart -vb 8000k
> -ab
> > 384k -s 1920x1080 -y video_Z11-1920x1080.mp4
> > ffmpeg version 3.2.4-static http://johnvansickle.com/ffmpeg/  Copyright
> (c)
> > 2000-2017 the FFmpeg developers
> >   built with gcc 5.4.1 (Debian 5.4.1-5) 20170205
> >   configuration: --enable-gpl --enable-version3 --enable-static
> > --disable-debug --disable-ffplay --disable-indev=sndio
> > --disable-outdev=sndio --cc=gcc-5 --enable-fontconfig --enable-frei0r
> > --enable-gnutls --enable-gray --enable-libass --enable-libfreetype
> > --enable-libfribidi --enable-libmp3lame --enable-libopencore-amrnb
> > --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus
> > --enable-librtmp --enable-libsoxr --enable-libspeex --enable-libtheora
> > --enable-libvidstab --enable-libvo-amrwbenc --enable-libvorbis
> > --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265
> > --enable-libxvid --enable-libzimg
> >   libavutil  55. 34.101 / 55. 34.101
> >   libavcodec 57. 64.101 / 57. 64.101
> >   libavformat57. 56.101 / 57. 56.101
> >   libavdevice57.  1.100 / 57.  1.100
> >   libavfilter 6. 65.100 /  6. 65.100
> >   libswscale  4.  2.100 /  4.  2.100
> >   libswresample   2.  3.100 /  2.  3.100
> >   libpostproc54.  1.100 / 54.  1.100
> > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'video_Z11.mp4':
> >   Metadata:
> > major_brand : isom
> > minor_version   : 512
> > compatible_brands: isomiso2avc1mp41
> > creation_time   : 2016-11-29T13:42:34.00Z
> > encoder : Lavf56.1.0
> >   Duration: 02:22:55.48, start: 0.00, bitrate: 379 kb/s
> > Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p,
> > 480x360 [SAR 1:1 DAR 4:3], 246 kb/s, 29.95 fps, 29.97 tbr, 90k tbn, 59.91
> > tbc (default)
> > Metadata:
> >   creation_time   : 2016-11-29T13:42:34.00Z
> >   handler_name: VideoHandler
> > Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz,
> > stereo, fltp, 125 kb/s (default)
> > Metadata:
> >   creation_time   : 2016-11-29T13:42:34.00Z
> >   handler_name: SoundHandler
> > [libx264 @ 0x5a3c240] using SAR=3/4
> > [libx264 @ 0x5a3c240] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
> > [libx264 @ 0x5a3c240] profile High, level 4.0
> > [libx264 @ 0x5a3c240] 264 - core 148 r333 90a61ec - H.264/MPEG-4 AVC
> codec
> > - Copyleft 2003-2017 - http://www.videolan.org/x264.html - options:
> cabac=1
> > ref=3 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=7 psy=1
> psy_rd=1.00:0.00
> > mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0
> deadzone=21,11
> > fast_pskip=1 chroma_qp_offset=-2 threads=3 lookahead_threads=1
> > sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0
> > constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1
> > weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40
> > intra_refresh=0 rc_lookahead=40 rc=abr mbtree=1 bitrate=8000 ratetol=1.0
> > qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 ip_ratio=1.40 aq=1:1.00
> > Output #0, mp4, to 'video_Z11-1920x1080.mp4':
> >   Metadata:
> > major_brand : isom
> > minor_version   : 512
> > compatible_brands: isomiso2avc1mp41
> > encoder : Lavf57.56.101
> > Stream #0:0(und): Video: h264 (libx264) ([33][0][0][0] / 0x0021),
> > yuv420p, 1920x1080 [SAR 3:4 DAR 4:3], q=-1--1, 8000 kb/s, 29.97 fps, 30k
> > tbn, 29.97 tbc (default)
> > Metadata:
> >   creation_time   : 2016-11-29T13:42:34.00Z
> >   handler_name: VideoHandler
> >   encoder : Lavc57.64.101 libx264
> > Side data:
> >   cpb: bitrate max/min/avg: 0/0/800 buffer size: 0 vbv_delay: -1
> > Stream #0:1(und): Audio: aac (LC) ([64][0][0][0] / 0x0040), 44100 Hz,
> > stereo, fltp, 384 kb/s (default)
> > Metadata:
> >   creation_time   : 

Re: [FFmpeg-user] Using the flags -movflags +faststart

[Frank Tetzel]

> > The '+' sign in front of the flags is not going to work? I disagree.
> > ffmpeg's command line parser doesn't care whether the first flag is
> > prepended with a '+' or not:  
> 
> Actually, I found this comment
> (http://stackoverflow.com/questions/23419351/ffmpeg-using-movflags-faststart#comment60936769_23440682):
> 
>   The + sign indicates that ffmpeg should set the specified value in
>   addition to any values that the MOV/MP4 muxer will automatically set
>   during the course of executing the command. Omitting it means ffmpeg
>   will reset the flags to their default values, and only toggle the
>   state of faststart. Most MP4s generation doesn't involve the other
>   flags so usually it doesn't make a difference.
> 
> I couldn't find this in ffmpeg's source or docs though.

Mhmm, maybe not anymore. I think I read about it some years ago in the
docs or wiki. In some of the examples it's still in, but no explanation.

https://ffmpeg.org/ffmpeg-formats.html#Examples-9
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

2017-02-26 13:59 GMT+01:00 Katherine Frances :

> Both of us think the other a little rude.

As far as I am concerned: No.

But thanks for calling me rude, Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

On Mon, Feb 27, 2017 at 12:56 AM, Carl Eugen Hoyos 
wrote:

> Note that yadif is not the only deinterlacing filter, see the
documentation
> (I personally only used yadif for a very long time).
Yes, I've seen. I chose yadif since I like

> So to make sure you have exactly one filter chain (with a defined order)
> use the format filter.
> If you don't need specific filters (like scale and yadif), using -pix_fmt
> allows a simpler syntax.

Okay, I see the distinction and I think I have a handle on it now. Updated
basic script:

ffmpeg -i input.mov -c:v libx264 -vf 'yadif,format=pix_fmts=yuv420p'
access.mp4

It's working nicely.

> No, and I am really surprised how this is possible given the many
> examples you have already seen in this very thread.

Both of us think the other a little rude. Now I understand about the
'interleaved' style replies, so it's sorted. Mea culpa.

Thanks very much for your help,

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

2017-02-26 12:44 GMT+01:00 Katherine Frances :
> On Mon, Feb 27, 2017 at 12:19 AM, Carl Eugen Hoyos 
> wrote:

>> >2. If used in the same script, *scale* must precede *yadif. *Although
>> > it seems rather redundant.
>>
>> I would suggest the opposite since giving yadif more information could
>> help. There may be a performance trade-off though.
>
> If the order is yadif -> scale, how is yadif getting more information?
> Sorry, I think I'm missing something here.

The scale filter in general does something destructive with the video
so calling yadif first (which does something fuzzy) means giving yadif
the best chance to produce best output.

If you downscale, calling swscale first can improve performance but
it comes at the cost of possibly worse yadif output.

Note that yadif is not the only deinterlacing filter, see the documentation
(I personally only used yadif for a very long time).

>> You should not use a (non-trivial) filter-chain and -pix_fmt since iirc,
>> the output (the filter order) is not defined. (But it is a bad idea anyway.)
>
> I'm not clear on your meaning here. It's not possible to do both of these
> operations (deinterlace + chroma-downsample to 4:2:0) in one script?

On the contrary:
If you do "-vf something -pix_fmt ..." there is no guarantee if scale (needed
for "pix_fmt") or "something" is called first. (Even if I am wrong and the order
is documented, it is still not ideal imo to use this syntax.)
So to make sure you have exactly one filter chain (with a defined order)
use the format filter.
If you don't need specific filters (like scale and yadif), using -pix_fmt
allows a simpler syntax.

> I hope this post is formatted correctly.

No, and I am really surprised how this is possible given the many
examples you have already seen in this very thread.

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

On Mon, Feb 27, 2017 at 12:19 AM, Carl Eugen Hoyos 
wrote:

> 2017-02-26 12:11 GMT+01:00 Katherine Frances :
> > Thanks again, Andy.
> > So if I understand correctly:
> >
> >1.  *-vf scale=interl=1* registers to libx264 that the input is
> >interlaced and to be 'aware' of that in future operations.
>
> No, the option is meant to tell the scale filter that it has to
> adapt its operations for interlaced content.
>
> > *yadif*, of course, does the actual deinterlacing.
>
> Yes.
>
> >2. If used in the same script, *scale* must precede *yadif. *Although
> it
> >seems rather redundant.
>
> I would suggest the opposite since giving yadif more information could
> help. There may be a performance trade-off though.
>
> >3. If deinterlacing with *yadif*, *yadif* should precede chroma
> >downsampling
>
> Same reasoning as above.
>
> > (via *-pix_fmt yuv420p*)
>
> You should not use a (non-trivial) filter-chain and -pix_fmt since
> iirc, the output (the filter order) is not defined. (But it is a bad idea
> anyway.)
>
> "Scaling" and "Chroma-downsampling" are the same insofar as
> they are both done by the scale filter.
>
> Did you already tell us if the content you see is actually interlaced?
>
> As said, please find out what top-posting means and avoid it
> here.
>
> Carl Eugen


Hi Carl,

Thank you for your answer.

Here I'm confused:

>2. If used in the same script, *scale* must precede *yadif. *Although
> it
> >seems rather redundant.
> I would suggest the opposite since giving yadif more information could
> help. There may be a performance trade-off though.


If the order is yadif -> scale, how is yadif getting more information?
Sorry, I think I'm missing something here.

You should not use a (non-trivial) filter-chain and -pix_fmt since iirc,
> the output (the filter order) is not defined. (But it is a bad idea anyway.)


I'm not clear on your meaning here. It's not possible to do both of these
operations (deinterlace + chroma-downsample to 4:2:0) in one script?

"Scaling" and "Chroma-downsampling" are the same insofar as they are both
> done by the scale filter.


I didn't realize that scale also takes care of the 4:2:2 -> 4:2:0 change.
Thank you for telling me.

Did you already tell us if the content you see is actually interlaced?
>

Yes, the source file is definitely interlaced.

I hope this post is formatted correctly. Thank you for your help,

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

2017-02-26 12:11 GMT+01:00 Katherine Frances :
> Thanks again, Andy.
> So if I understand correctly:
>
>1.  *-vf scale=interl=1* registers to libx264 that the input is
>interlaced and to be 'aware' of that in future operations.

No, the option is meant to tell the scale filter that it has to
adapt its operations for interlaced content.

> *yadif*, of course, does the actual deinterlacing.

Yes.

>2. If used in the same script, *scale* must precede *yadif. *Although it
>seems rather redundant.

I would suggest the opposite since giving yadif more information could
help. There may be a performance trade-off though.

>3. If deinterlacing with *yadif*, *yadif* should precede chroma
>downsampling

Same reasoning as above.

> (via *-pix_fmt yuv420p*)

You should not use a (non-trivial) filter-chain and -pix_fmt since
iirc, the output (the filter order) is not defined. (But it is a bad idea
anyway.)

"Scaling" and "Chroma-downsampling" are the same insofar as
they are both done by the scale filter.

Did you already tell us if the content you see is actually interlaced?

As said, please find out what top-posting means and avoid it
here.

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Carl Eugen Hoyos]

2017-02-25 23:54 GMT+01:00 Katherine Frances :

> Do you think that 'progressive' is default for libx264

Fortunately yes.
(As for any other useful encoder I can think of.)

Please avoid top-posting here, Carl Eugen
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] -pix_fmt yuv420p and deinterlacing

[Katherine Frances]

Thanks again, Andy.
So if I understand correctly:

   1.  *-vf scale=interl=1* registers to libx264 that the input is
   interlaced and to be 'aware' of that in future operations. *yadif*, of
   course, does the actual deinterlacing.
   2. If used in the same script, *scale* must precede *yadif. *Although it
   seems rather redundant.
   3. If deinterlacing with *yadif*, *yadif* should precede chroma
   downsampling (via *-pix_fmt yuv420p*). In other words, the subsampling
   scheme should be changed after the deinterlacing step.
  - like this, for example?: ffmpeg -i uncompressed_master.mov -c:v
  libx264 -vf yadif -pix_fmt yuv420p -c:a libfdk_aac -b:a 128k
access_copy.mp4
  4. If using all three of these options, deinterlacing must be
   preceded by chroma downsampling *and *-vf scale=interl=1
  - Is the correct order then *scale *-> *pix_fmt* -> *deinterlace* ?

As for yadif mode, I'm only interested in frame rate output (send_frame
, which is the default
anyway).

I really appreciate you taking the time to help me. I'm learning a lot!

Best, K.


On Sun, Feb 26, 2017 at 11:34 PM, Andy Furniss  wrote:

> Katherine Frances wrote:
>
>> Kia ora,
>>
>> *Andy*: thanks very much for this tip! Will add that filter to the script
>> as I definitely want to deinterlace.
>> Do you recommend this over *yadif*, or do I need to combine *scale* with a
>> deinterlacing filter?
>>
>
> -vf scale=interl=1 Has nothing to do with de-interlacing it would be
> needed more if you wanted to keep the interlacing.
>
> yadif can de-interlace 422 input so if you used that *first* it
> shouldn't matter. It would be wrong to convert 422 to 420 without
> -vf scale=interl=1 if you then later de-interlaced, so the order
> of filters matters.
>
> yadif can produce field rate or frame rate output. It's field rate
> that will look worse if you mess up the 422 to 420 conversion.
>
> What to do depends on your content. If there's lots of motion then
> field rate de-interlace (yadif=1) will look better. If it's interlaced
> but low motion you will get away with frame rate (yadif=0).
> Depending on what the masters are they may not be interlaced to start
> with.
>
> The right thing to do depends on what the output is for and what the
> input really is - there is no right way as such.
>
>
>
> ___
> ffmpeg-user mailing list
> ffmpeg-user@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-user mailing list
ffmpeg-user@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-user] Help about decoder-encoder ffmpeg

[Carl Eugen Hoyos]

2017-02-24 21:40 GMT+01:00 ANGEL BOHORQUEZ (GMAIL) :
> Hello to everyone, I'm new in this forum. I would like to please help me to
> solve a need. I have several ip cameras in different locations, I want to
> get via rtsp to the live video stream for several cameras to send the
> multiplexed stream to the main site where a monitoring system is located. I
> have a raspberry pi3 to be able to perform decoder-encoder on the same
> computer, I want to know if this is possible.

Look at the hstack and vstack filters but I fear you will need a
faster computer.

Very generally, you will have to show us what you tried (command line and
console output) if you want support here, we for example don't know if
FFmpeg is able to read your input streams or not.

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

To unsubscribe, visit link above, or email
ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-user] Error: av_interleaved_write_frame(): Broken pipe

[Aakash Gupta]

 Hello,

I have made a rails app that can stream live videos to facebook rtmp server and 
deployed it on Digital Ocean. I have used nginx as web server and using a linux 
OS. The major problem that I am encountering after viewing log files of FFMpeg 
processes is that after streaming for some time(that keeps on varying) FFmpeg 
process gives the error

av_interleaved_write_frame(): Broken pipe

This is the command that I am using:

$HOME/bin/ffmpeg -loop 1 -re -y -f image2 -i 
'public/uploads/post/25/frame1.png' -acodec copy -bsf:a aac_adtstoasc -pix_fmt 
yuv420p -profile:v high -s 1280x720 -vb 400k -maxrate 400k -minrate 400k 
-bufsize 600k -deinterlace -vcodec libx264 -preset veryfast -g 30 -r 30 -t 
14400 -strict -2 -f flv "rtmp_link" 2> "logfile"

Logs of this process:

ffmpeg version N-83442-gdac51d2 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3)
  configuration: --prefix=/root/ffmpeg_build --pkg-config-flags=--static 
--extra-cflags=-I/root/ffmpeg_build/include 
--extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --enable-gpl 
--enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame 
--enable-libopus --enable-libtheora --enable-libvorbis --enable-libvpx 
--enable-libx264 --enable-nonfree
  libavutil      55. 46.100 / 55. 46.100
  libavcodec     57. 75.100 / 57. 75.100
  libavformat    57. 66.101 / 57. 66.101
  libavdevice    57.  2.100 / 57.  2.100
  libavfilter     6. 73.100 /  6. 73.100
  libswscale      4.  3.101 /  4.  3.101
  libswresample   2.  4.100 /  2.  4.100
  libpostproc    54.  2.100 / 54.  2.100
Input #0, image2, from 'public/uploads/post/25/frame1.png':
  Duration: 00:00:00.04, start: 0.00, bitrate: N/A
    Stream #0:0: Video: png, rgba(pc), 720x405, 25 fps, 25 tbr, 25 tbn, 25 tbc
[aac @ 0x2916fa0] Estimating duration from bitrate, this may be inaccurate
Input #1, aac, from 'public/silent.aac':
  Duration: 05:16:16.43, bitrate: 3 kb/s
    Stream #1:0: Audio: aac (LC), 44100 Hz, mono, fltp, 3 kb/s
[libx264 @ 0x291e8e0] using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX 
AVX2 FMA3 LZCNT BMI2
[libx264 @ 0x291e8e0] profile High, level 3.1
[libx264 @ 0x291e8e0] 264 - core 142 r2389 956c8d8 - H.264/MPEG-4 AVC codec - 
Copyleft 2003-2014 -"some link to be removed because of forum policy" - 
options: cabac=1 ref=1 deblock=1:0:0 analyse=0x3:0x113 me=hex subme=2 psy=1 
psy_rd=1.00:0.00 mixed_ref=0 me_range=16 chroma_me=1 trellis=0 8x8dct=1 cqm=0 
deadzone=21,11 fast_pskip=1 chroma_qp_offset=0 threads=1 lookahead_threads=1 
sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0 
constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=1 b_bias=0 direct=1 weightb=1 
open_gop=0 weightp=1 keyint=30 keyint_min=3 scenecut=40 intra_refresh=0 
rc_lookahead=10 rc=cbr mbtree=1 bitrate=400 ratetol=1.0 qcomp=0.60 qpmin=0 
qpmax=69 qpstep=4 vbv_maxrate=400 vbv_bufsize=600 nal_hrd=none filler=0 
ip_ratio=1.40 aq=1:1.00
Output #0, flv, to 'rtmp_link':
  Metadata:
    encoder         : Lavf57.66.101
    Stream #0:0: Video: h264 (libx264) ([7][0][0][0] / 0x0007), yuv420p, 
1280x720, q=-1--1, 400 kb/s, 30 fps, 1k tbn, 30 tbc
    Metadata:
      encoder         : Lavc57.75.100 libx264
    Side data:
      cpb: bitrate max/min/avg: 40/0/40 buffer size: 60 vbv_delay: 
-1
    Stream #0:1: Audio: aac (LC) ([10][0][0][0] / 0x000A), 44100 Hz, mono, 
fltp, 3 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (png (native) -> h264 (libx264))
  Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
[image2 @ 0x2914ae0] Thread message queue blocking; consider raising the 
thread_queue_size option (current value: 8)
frame=   12 fps=0.0 q=44.0 size=       0kB time=00:00:00.00 bitrate=N/A speed=  
 0x    
frame=   17 fps= 16 q=43.0 size=      22kB time=00:00:00.13 
bitrate=1359.9kbits/s speed=0.13x    
frame=   28 fps= 18 q=42.0 size=      25kB time=00:00:00.56 bitrate= 
367.1kbits/s speed=0.363x    
frame=   38 fps= 18 q=38.0 size=      41kB time=00:00:00.97 bitrate= 
346.4kbits/s speed=0.465x    
frame=   48 fps= 18 q=38.0 size=      82kB time=00:00:01.37 bitrate= 
490.0kbits/s speed=0.525x    
frame=   62 fps= 20 q=35.0 size=      96kB time=00:00:01.93 bitrate= 
405.0kbits/s speed=0.617x    
frame=   71 fps= 19 q=30.0 size=     101kB time=00:00:02.27 bitrate= 
363.9kbits/s speed=0.617x    
frame=   82 fps= 20 q=38.0 size=     150kB time=00:00:02.73 bitrate= 
449.8kbits/s speed=0.651x    
frame=   97 fps= 21 q=28.0 size=     154kB time=00:00:03.33 bitrate= 
379.5kbits/s speed=0.708x    
frame=  106 fps= 20 q=36.0 size=     209kB time=00:00:03.66 bitrate= 
465.5kbits/s speed=0.702x    
frame=  121 fps= 21 q=36.0 size=     214kB time=00:00:04.27 bitrate= 
409.6kbits/s speed=0.741x    
frame=  135 fps= 21 q=36.0 size=     269kB time=00:00:04.83 bitrate= 
456.3kbits/s speed=0.768x    
frame=  144 fps= 21 q=36.0 size=     270kB time=00:00:05.20 bitrate= 
425.4kbits/s speed=0.765x    
frame=  159 fps= 22 q=35.0 size=     273kB