[Ffmpeg-devel-irc] ffmpeg.log.20170225

[burek]

[00:23:50 CET] <thebombzen> is there an equivalent of -crf for libvpx-vp8?
[00:39:29 CET] <TD-Linux> thebombzen, yes, -b:v 0 -crf x
[00:39:42 CET] <TD-Linux> two pass still recommended though
[01:08:53 CET] <thebombzen> TD-Linux: do you mean two-pass ABR or do you mean two-pass -b:v 0 -crf X?
[01:09:21 CET] <thebombzen> and how do the CRF scales translate to the corresponding ones for libx264?
[01:09:55 CET] <thebombzen> and does libvpx-vp9 do that as well? (in case I have time to kill)
[01:11:37 CET] <furq> he means two-pass crf, i don't know, and yes
[01:12:00 CET] <furq> iirc something like 30 is reasonable quality
[01:12:13 CET] <thebombzen> "resonable" is sort of arbitrary
[01:12:23 CET] <thebombzen> to some people, libx264's crf 23 is "reasonable" but I don't like it
[01:12:27 CET] <furq> shrug
[01:12:31 CET] <furq> try it and see i guess
[01:12:37 CET] <thebombzen> lol usual compsci answer
[01:12:41 CET] <thebombzen> "what happened when you tried it"
[01:12:54 CET] <thebombzen> it's very dissatisfying but I guess knowing where to start (30) is good enough lol
[01:13:02 CET] <furq> also i don't know how 2-pass crf could possibly make things better, but apparently it does
[01:13:10 CET] <thebombzen> yea that seems weird to me idk
[01:13:27 CET] <thebombzen> do I use the usual method, which is on the first pass use -pass 1 -f null -
[01:13:32 CET] <thebombzen> and then -pass 2 -f ...
[01:13:34 CET] <furq> i know libvpx's ratecontrol is bad but apparently it defies physics as well
[01:13:42 CET] <furq> and yeah i think so
[01:13:59 CET] <furq> i've avoided libvpx as much as possible because it's uselessly slow for sd
[01:14:09 CET] <thebombzen> sd?
[01:14:13 CET] <furq> standard def
[01:14:25 CET] <thebombzen> doesn't that mean it's even more slow for HD?
[01:14:36 CET] <furq> well yeah but not linearly
[01:14:42 CET] <thebombzen> ah
[01:14:47 CET] <furq> it only has slice threading and there's a minimum slice width
[01:14:57 CET] <furq> so at 720 width it'll only use two threads
[01:15:07 CET] <furq> which is less than ideal
[01:15:09 CET] <thebombzen> is there any alternative to this suckiness? because it seems like the truly best reasonable alternative is to just use x264
[01:15:16 CET] <furq> yes, it's to use x264
[01:15:36 CET] <furq> vp9 itself isn't bad but libvpx is not great
[01:15:41 CET] <TD-Linux> thebombzen, vp9 will generally work much better for crf
[01:15:51 CET] <furq> and i wouldn't expect much more development on the vp8/vp9 stuff in libvpx
[01:15:55 CET] <TD-Linux> its rate control is a separate codebase
[01:16:05 CET] <thebombzen> why is vp10 happening?
[01:16:08 CET] <thebombzen> or just av1 stuff
[01:16:14 CET] <TD-Linux> vp10 is dead, av1 is new
[01:16:19 CET] <furq> vp10 and av1 are much of a muchness
[01:16:31 CET] <thebombzen> well av1 isn't even frozen yet, right?
[01:16:37 CET] <TD-Linux> av1 has a theora and x264-style rate controller landed recently
[01:17:14 CET] <thebombzen> but again it's not even frozen, so we shouldn't expect it anytime soon
[01:17:23 CET] <furq> i'm perfectly happy with x264 until av1 lands
[01:17:42 CET] <TD-Linux> correct
[01:17:49 CET] <TD-Linux> in the meantime someone should really write a GOP parallel encoder
[01:18:08 CET] <TD-Linux> this is why libvpx's threading is so bad, most companies don't use it
[01:21:21 CET] <TD-Linux> er I think boram can actually do GOP parallel
[01:23:42 CET] <TD-Linux> er no it can't
[01:45:15 CET] <JEEB> TD-Linux: now try to do relatively low-latency live streaming with GOP parallelism
[01:45:38 CET] <TD-Linux> JEEB, well frame parallel doesn't work for that either (unless you're talking about twitch latency)
[01:45:39 CET] <JEEB> (without losing a whopping amount of compression)
[01:45:52 CET] <JEEB> TD-Linux: within 5-10 seconds
[01:46:03 CET] <JEEB> which is "bearable as you don't know the source"
[01:50:52 CET] <thebombzen> is there an easy way to tell if a subtitle codec is a text-based codec or image-based codec on the fly?
[01:51:24 CET] <thebombzen> cause I just tried -vf subtitles for a pgssub file and it said that it only supports text-based subs, but how would I check in advance (say, in a script) so I can switch between -vf subtitles and -vf overlay?
[01:59:12 CET] <c_14> ffprobe the input format?
[01:59:27 CET] <furq> ffprobe and codec_name is the best thing i can think of
[01:59:37 CET] <furq> there's no flag in there that tells you if it's a text format
[01:59:53 CET] <furq> but there aren't a great deal of text formats that you'll actually encounter
[02:00:12 CET] <c_14> I think it might be easier to match for image formats
[02:00:14 CET] <c_14> Not that many of those
[02:00:35 CET] <c_14> It's easier to invent a new text-based format than an image based one
[02:00:41 CET] <furq> i guess
[04:28:15 CET] <llamapixel> file can determine ascii or binary
[05:20:11 CET] <thebombzen> llamapixel: extracting the subs and checking if it's a binary file isn't the sort of thing I"m looking for
[05:20:35 CET] <thebombzen> given that I could just attempt using -vf subtitles and parsing the ffmpeg output for "Only text based subtitles are currently supported"
[05:21:35 CET] <thebombzen> especially since that doesn't work unless you can mux the raw stream
[05:21:54 CET] <llamapixel>  Extracting seems like overkill but ok
[05:22:59 CET] <thebombzen> well how else am I supposed to use file to check that
[05:23:10 CET] <thebombzen> given that it's muxed inside a binary container with a binary video and a binary audio
[05:24:06 CET] <thebombzen> llamapixel: if you don't extract it, file will report "matroska data" or something useless
[05:29:07 CET] <llamapixel> Which is just a zip file right?
[05:30:48 CET] <llamapixel> Isn't Mkv just a container file in case that is incorrect?
[05:39:55 CET] <llamapixel> Touchy
[06:47:22 CET] <Aakash> 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:
[06:47:35 CET] <Aakash> $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"
[06:48:00 CET] <kepstin> Aakash: all that error means is that the rtmp connection got dropped
[06:48:20 CET] <kepstin> probably the best you can do is restart it, unless you can figure out the network issue
[06:48:44 CET] <Aakash> Thans kepstin for your answer
[06:48:49 CET] <Aakash> I am copying my logs
[06:48:54 CET] <Aakash> please have alook at them
[06:49:13 CET] <Aakash> 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 --e
[06:49:14 CET] <kepstin> heh, it's past midnight here, I'm off now.
[06:49:19 CET] <kepstin> and don't paste in the channel
[06:49:39 CET] <Aakash> okay
[06:49:44 CET] <Aakash> I'll keep that in mind
[06:54:03 CET] <Aakash> http://pastebin.com/vC1vLDEg
[06:54:23 CET] <Aakash> this is the link having the command that I'm using and logs of ffmpeg process
[07:07:30 CET] <Aakash> After combining things together, 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 problem is that after streaming for some time(that keeps on varying) FFmpeg process gives the error  av_interleaved_write_frame(): Broken pipe  Pastebin link of command and logs: http://pastebin.com/vC1vLDEg
[09:43:36 CET] <Diag> Anyone here Chinese
[10:31:33 CET] <IamTrying> Is there any knowledgeable person? what is i420 frames (my video renderer RTCEAGLVideoView.h renders i420 frames, and after certrain period of time its frozen)
[10:31:46 CET] <IamTrying> i am trying to understand i420 anyone have some knowledge about it?
[10:32:55 CET] <IamTrying> it use OpenGLES 2.0
[10:51:50 CET] <IamTrying> What the fuck? no body has fucking knowledge about it.
[11:03:57 CET] <Ekho> does anyone happen to know how to properly add cover art to .opus/ogg files using ffmpeg? (https://wiki.xiph.org/VorbisComment#METADATA_BLOCK_PICTURE ?)
[16:19:51 CET] <ben__> Hi, I'm trying to do livestreaming with ffmpeg. I'm using libavformat to produce an mkv output stream. The muxer has a is_live option. How can you set this option using libavformat?
[16:23:15 CET] <JEEB> if it's an AVOption, yes
[16:24:34 CET] <ben__> how can you set this option? Do I have to pass it in the dictionary when calling av_format_write_header()?
[16:26:53 CET] <JEEB> according to how avformat/tests/movenc.c seems to do it, yes
[16:40:02 CET] <ben__> JEEB thanks for your tip. haven't looked at this file before, seems to contain a lot of useful information. is there a way to very that the option has been set?
[16:40:44 CET] <JEEB> other than checking if it's doing what you've requested, not sure
[16:47:11 CET] <ben__> JEEB thanks again for your answer. It helped a lot :)
[16:48:01 CET] <JEEB> no problemo
[16:54:02 CET] <DHE> ben__: the AVDictionary you pass will be eaten, and any options NOT consumed will be left behind
[16:54:55 CET] <DHE> you can imagine that's how ffmpeg works. your command-line is turned into AVDictionary options and given to the avformat_* functions. Anything left over goes to the avcodec_* functions. And so on. anything ultimately left over is a user error
[17:01:25 CET] <ben__> DHE: great tip, thx. my options have all been consumed so they must have been correct. yeah :)
[17:07:58 CET] <JEEB> coolio
[17:08:05 CET] <JEEB> DHE: nice, I actually never thought of that
[17:08:10 CET] <JEEB> or checked the implementation
[17:08:11 CET] <JEEB> lol
[17:11:42 CET] <DHE> JEEB: it's a bit more complicated since there -param:v:0 suffixes to be parsed, but still
[17:11:59 CET] <JEEB> well, yeah. I was mostly talking about the avdictionary passage part
[17:13:23 CET] <TerNer> JEEB, can I continue a question in this channel?
[17:13:35 CET] <JEEB> yes
[17:14:00 CET] <JEEB> anyways, yes - fragmented isobmff is something you can pass to a client in a streaming manner
[17:14:49 CET] <TerNer> but JEEB, fragmented mp4 also have 'duration' data
[17:15:02 CET] <TerNer> I want to streaming a video infinitly
[17:15:03 CET] <JEEB> as instead of a single moov you get various other boxes that happen for each fragment
[17:15:06 CET] <JEEB> uhh
[17:15:11 CET] <JEEB> that's exactly what it is for
[17:15:32 CET] <TerNer> fragmented mp4 not have duration data?
[17:15:58 CET] <JEEB> it has all the data required to play a fragment after a fragment
[17:16:21 CET] <JEEB> and whatever field you're talking of it is not limited by that
[17:16:47 CET] <JEEB> the main thing with fragmented ISOBMFF is that you need to make sure your clients support it, though :P
[17:16:55 CET] <JEEB> since the boxes are different from non-fragmented content
[17:17:25 CET] <TerNer> so how does player realize end of stream/video if fragmented mp4 doesn't have duration data?
[17:17:36 CET] <JEEB> end of stream means no more fragments
[17:17:41 CET] <TerNer> oh
[17:17:43 CET] <JEEB> or no more data from stream
[17:18:14 CET] <TerNer> well, I'm trying to have streaming to chromium browser
[17:18:41 CET] <JEEB> I have a hunch you will want something that is either HLS or DASH, since for that you have already done libraries
[17:19:09 CET] <JEEB> DASH uses fragmented ISOBMFF
[17:19:30 CET] <JEEB> but anyways, in other words it will work
[17:19:31 CET] <JEEB> :P
[17:19:41 CET] <JEEB> how well depends on how much effort you put into it
[17:20:18 CET] <TerNer> :o
[17:54:15 CET] <Darby_> hi guys, i need another little help
[17:55:25 CET] <Darby_> i want compile a static ffmpeg binary and add some library with static library
[17:55:58 CET] <Darby_> Debian Jessie don't have static library for some packet
[17:56:38 CET] <Darby_> i must compile every library for have static .a files
[17:57:31 CET] <Darby_> how can i compile ffmpeg binary with those library compiled by myself?
[19:06:32 CET] <forgon> I'd like to compress a 13G lossless *.mkv file to the utmost without losing quality. How should I proceed?
[19:06:59 CET] <forgon> Both flac audio and libx264 video are included.
[19:07:27 CET] <JEEB> without losing quality already means that you have to be using something lossless
[19:07:43 CET] <JEEB> thus you can use either ffv1 or libx264 with a very long GOP length
[19:07:53 CET] <JEEB> and with libx264 the slowest preset you can take
[19:08:21 CET] <forgon> JEEB: What compression could I reasonably expect if going from -ultrafast to -veryslow?
[19:08:40 CET] <JEEB> depends on what your other parameters such as GOP length are?
[19:08:48 CET] <JEEB> before/after
[19:09:12 CET] <forgon> JEEB: Do you mean the framerate?
[19:09:31 CET] <JEEB> no
[19:09:42 CET] <JEEB> for how long the encoder goes without having to do an IRAP
[19:10:48 CET] <JEEB> libx264 by default sets the GOP length to about 10 seconds and is dynamic about it, but of course if you set the thing to infinite you will get gains
[19:14:41 CET] <furq> you also won't be able to seek
[19:14:43 CET] Action: forgon doesn't know :|
[19:15:29 CET] <furq> just reencode it with veryslow
[19:15:55 CET] <furq> i doubt you'll get massive gains but from what i've seen it'll be a noticeable difference
[19:17:26 CET] <forgon> furq: Okay, what is the command? Can I just run `ffmpeg -i inputfile -vcodec copy -acodec copy -qp 0 -preset veryslow outputfile`?
[19:17:32 CET] <furq> no
[19:17:40 CET] <furq> -vcodec libx264
[19:17:54 CET] <forgon> furq: The rest is correct?
[19:17:56 CET] <furq> yes
[19:18:08 CET] <furq> if you really want to squeeze every byte then you can set -g and -x264-params keyint-min
[19:18:16 CET] <furq> the default is 250 frames
[19:18:31 CET] <furq> i wouldn't bother messing with those though
[19:18:55 CET] <furq> and of course you can also use a more efficient audio codec, but again i wouldn't bother with that
[19:19:05 CET] <furq> you could maybe do -acodec flac -compression_level 12
[19:19:21 CET] <forgon> I'll use that acodec, thank you.
[19:19:42 CET] <furq> there are more efficient lossless codecs than flac, but they're mostly not worth bothering with
[19:20:05 CET] <furq> you're looking at 2-3% space savings with the tradeoff of much slower decoding and/or much worse decoder support
[19:20:23 CET] <furq> i'm also not sure if libavcodec has encoders for any of them
[19:20:33 CET] <furq> it definitely doesn't have ape or tak
[19:20:42 CET] <forgon> Okay, I'll drop flac improvement then.
[19:20:55 CET] <furq> -compression_level 12 should be fine
[19:25:30 CET] <forgon> A noob question: How do I know how long it will take? does the redrawn line at the tail of program output as it is running give this info?
[19:25:55 CET] <forgon> Currently it says `speed=0.144x` at the end
[19:26:45 CET] <furq> then it's probably going to be the length of the video * 0.144
[19:27:46 CET] <forgon> Thanks.
[19:40:10 CET] <DHE> furq: divided by, not multiplied by.
[19:40:42 CET] <DHE> which is ballpark 7x the duration of the video
[23:58:34 CET] <klaxa> so, has AVStream->codec beem deprecated in favor of AVStream->codecpar?
[23:58:48 CET] <durandal_1707> yes
[23:59:27 CET] <klaxa> and all the write functions definitely do not rely on AVStream->codec?
[23:59:54 CET] <durandal_1707> yes
[00:00:00 CET] --- Sun Feb 26 2017