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

[burek]

[00:00:43 CEST] <TAFB> http://pastebin.com/UUE1Nzi0
[00:01:05 CEST] <TAFB> ffplay "udp://127.0.0.1:1234"
[00:14:21 CEST] <Spring> can av_log_force_nocolor be set via a batch script?
[00:15:03 CEST] <Spring> edit, forgot to add set... doy
[00:15:07 CEST] <Spring> works now
[00:16:53 CEST] <Spring> av_log_force_color on the other hand doesn't seem to be affected
[00:18:47 CEST] <Spring> oh, I see. That option doesn't set the color it only re-enables it if it has been disabled.
[00:21:07 CEST] <Spring> btw MediaInfo has always reported that files are encoded with the original source filename as a 'Movie name' metadata
[00:21:27 CEST] <Spring> can that be disabled via a flag?
[00:32:25 CEST] <Spring> I've tried -metadata name= and movie_name but neither work
[00:40:56 CEST] <TAFB> i noticed the audio/video sync is off by about 200/250ms or so, how can I fix it with the ffmpeg live streaming?
[00:50:58 CEST] <Spring> turns out it was 'title' not 'name'. MediaInfo fail.
[00:53:28 CEST] <odious> Hi! I just upgraded to ffmpeg 3.1 and am excited about the inclusion of Apple's AudioToolbox AAC encoder. I've looked pretty hard to find documentation but haven't been able to find any. Is VBR implemented in it?
[00:54:35 CEST] <JEEB> "check the code in libavcodec/relevant_file.c" is how I'd say it :)
[00:55:07 CEST] <JEEB> if it maps q or so around, it should have VBR
[00:55:43 CEST] <odious> Yeah I looked briefly but most of that stuff goes over my head.
[00:56:07 CEST] <odious> q does seem to pass through in my test files but I have no way of knowing what the resulting target bitrate is
[00:56:16 CEST] <odious> I have no sense of scale
[00:59:10 CEST] <JEEB> the scale is different for each encoder, so don't worry
[00:59:39 CEST] <JEEB> also with video encoders q is usually quantizer, which is suboptimal unless constant quantizer is the only VBR mode
[01:00:18 CEST] <odious> Right I've been able to find the -q scale for a bunch of different audio encoders but not aac_at
[01:00:33 CEST] <odious> And it does seem to differ from aac to aac_at
[01:00:46 CEST] <JEEB> is it limited to any range in the encoder wrapper?
[01:00:53 CEST] <c_14> 0-14
[01:00:55 CEST] <JEEB> if not, it might just be passed to the library
[01:01:07 CEST] <c_14> and then it does 127 - q * 9
[01:01:11 CEST] <c_14> and passes that to the library
[01:01:35 CEST] <odious> Doesn't seem like it, i just input 9999999 and it just let it through
[01:02:08 CEST] <c_14> odious: it should warn that it's out of range (if I'm reading this right)
[01:02:45 CEST] <odious> Nope! Just lets it through lol: ffmpeg -i test.mkv -c copy -c:a aac_at -aq 99999999 -ac 2 test-at-vbr.mkv
[01:03:57 CEST] <c_14> It does clip it (but it should also warn)
[01:04:20 CEST] <odious> Gotcha
[01:06:17 CEST] <odious> So if I want to target ~128k I should pass -q 7?
[01:11:05 CEST] <c_14> No idea, I can't seem to find any info about what that value corresponds to in the audiotoolbox documentation except for the fact that: 'VBR quality in the range 0&127'
[01:12:02 CEST] <odious> It seems to correlate to the afconvert library shipped with macOS
[01:12:18 CEST] <odious> Trying to find what 1-127 maps to
[01:12:48 CEST] <odious> 1=lowest bitrate, 127=highest bitrate it seems like
[01:18:02 CEST] <odious> Thanks for your help by the way!
[01:24:56 CEST] <odious> So!
[01:25:01 CEST] <odious> I think I've got it
[01:25:57 CEST] <odious> In the AudioToolbox vbr scale 0 results in ~40kbps and 127 typically results in ~320kbps
[01:26:43 CEST] <odious> Extrapolating from that ~256 is around 110, so ~128 should be around 55 which is -q 8!
[01:27:11 CEST] <odious> Which my test encodes seem to bear out coming in consistently slightly lower than 128kbps cbr
[01:57:07 CEST] <hooni> hello
[01:58:02 CEST] <hooni> Will building ffmpeg with configure option --enable-libsoxr will change the internal resampling algorithm used in libswresample?
[01:59:16 CEST] <hooni> i mean building libswresample
[05:26:04 CEST] <Spring> wish I had a clue how to display a loading/progress animation for ffmpeg in batch, to replace the regular output
[07:14:50 CEST] <totallyserious> Hey if I do a ffmpeg -i "concat:1.MTS|2.MTS" output.mp4 is the conversion by default at maximum quality?
[07:17:51 CEST] <furq> no
[07:18:13 CEST] <furq> the conversion is at the default for mp4, which is x264 at crf 23 and aac at some bitrate or other
[07:18:40 CEST] <furq> you probably want -c copy if the streams are compatible with mp4
[07:46:58 CEST] <blindwolf> Hy
[07:47:19 CEST] <blindwolf> Morning everybody
[14:50:55 CEST] <utack> is there a good educational article somewhere that explains what all the things set in the "colorspace" filter mean (colorspace, transfer characteristics, color primaries, and color format)?
[15:00:03 CEST] <JEEB> basically stuff to convert YCbCr<->RGB and the EOTF to use during playback
[15:01:11 CEST] <JEEB> also the colorspace filter is one of the greatest examples of how people don't want to touch the mess that is swscale
[15:01:21 CEST] <JEEB> and instead just make random filters for the specific functionality they want :D
[15:01:40 CEST] <JEEB> not that it's bad, it just shows how people don't want to fix/touch/use swsacle
[15:01:42 CEST] <JEEB> *swscale
[15:02:12 CEST] <JEEB> also first of all you should check the FFmpeg docs on the filter for the actual variables and what they mean
[15:02:16 CEST] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#colorspace
[15:02:25 CEST] <JEEB> then you can look up what those things mean
[15:03:16 CEST] <JEEB> "The filter converts the transfer characteristics, color space and color primaries to the specified user values. The output value, if not specified, is set to a default value based on the "all" property. If that property is also not specified, the filter will log an error. The output color range and format default to the same value as the input color range and format. The input transfer characteristics,
[15:03:22 CEST] <JEEB> color space, color primaries and color range should be set on the input data. If any of these are missing, the filter will log an error and no conversion will take place."
[15:19:44 CEST] <mechahop> if while ffmpeg is reading in a rtmp stream waht happens if the stream breakes for a second?
[15:23:15 CEST] <klaxa> define "break"
[15:23:26 CEST] <klaxa> if it's like EOF ffmpeg will probably finish writing
[15:23:41 CEST] <klaxa> if it's just waiting for IO ffmpeg will probably wait
[15:24:32 CEST] <mechahop> if there is a problem with the stream then rtmpdump quits and writes the file
[15:24:49 CEST] <mechahop> but sometimes when recording a live stream you get "blips" :)
[15:25:12 CEST] <mechahop> tried a infinite loop writing multiple files with rtmpdump and then joining them up
[15:25:13 CEST] <mechahop> works okay
[15:25:22 CEST] <klaxa> that's what i would probably do too
[15:26:34 CEST] <mechahop> fair enought i will stick with it then
[15:32:31 CEST] <mechahop> would -stream_loop -1 work int he same way but output to one file?
[15:42:51 CEST] <utack> JEEB yes i have looked up what it works with, and what you can specify
[15:43:32 CEST] <utack> i have one video i want to convert, and a reference, and it the colors are off when ffmpeg converts it. so i am assuming it guesses one of the parameters wrong, and i would need to guess which one
[15:44:07 CEST] <JEEB> post command line and terminal output and make sure you test your output with mpv the opengl renderer of which is currently the "reference" correctness for many things
[15:44:16 CEST] <JEEB> and when I say post, post on pastebin or so
[15:44:18 CEST] <JEEB> and then link here
[15:44:24 CEST] <JEEB> no long logs on the IRC channel kthx
[15:44:55 CEST] <JEEB> and as a piece of text on some of these things that some people recommend is http://lurkertech.com/lg/video-systems/
[15:45:08 CEST] <utack> thanks
[15:47:17 CEST] <utack> i was primarily interested in reading what might be happening, it might occur again
[15:47:54 CEST] <JEEB> that's why I wanted your command line and terminal output
[15:48:19 CEST] <JEEB> and possibly the `ffprobe`/`ffmpeg -i` output of the output file
[16:02:21 CEST] <utack> ok i think i got it all. input, conversion paramters to get the test frame, and output file information  https://paste.ubuntu.com/18388693/
[16:11:06 CEST] <JEEB> utack: I would guess gbrap121e gets somehow converted to 4:2:0 YCbCr with swscale with that
[16:11:34 CEST] <JEEB> and since you didn't define any values I don't expect that conversion to do what you expect
[16:12:02 CEST] <JEEB> also of course after the conversion it didn't actually specify the colorspace/trc it used for the conversion so the player is left guessing
[16:12:41 CEST] <JEEB> you can see the actual automatic filter chain if you do -v debug when doing the re-encode
[16:15:06 CEST] <utack> and that is why i have to read about this stuff, because i can't really understand all of what you just said. i will try to get that filter chain, one second
[16:15:49 CEST] <JEEB> let's just say that the general concensus is that you want to keep swscale doing as little things as possible in your filter chains
[16:16:00 CEST] <JEEB> because there's a really huge possibility of it just doing things wrong
[16:16:09 CEST] <JEEB> or in a non-specified way
[16:18:55 CEST] <utack> does this tell you what it is doing at the moment https://paste.ubuntu.com/18390172/
[16:19:56 CEST] <JEEB> yeah, it just says that it's [auto-inserted scaler 0 @ 0x15a6ec0] w:4096 h:2304 fmt:gbrap12le sar:0/1 -> w:4096 h:2304 fmt:yuv420p10le sar:0/1 flags:0x4
[16:20:03 CEST] <JEEB> which just says that swscale is "handling" it
[16:20:18 CEST] <utack> so how could i get it right, that the output looks visually as similar as possible to the imput? i don't want to waste your time, but i would not know where to start making things better
[16:21:08 CEST] <utack> and thanks for the info so far, it is already helping me to understand why it goes wrong
[16:21:18 CEST] <JEEB> well you'd have to know the filters that you can use (probably colorspace and zscale that uses the zscale/zlib library), and then find out the closest colorspace that those two can handle
[16:21:36 CEST] <JEEB> so that you minimize what swscale does and define the actual RGB-to-YCbCr conversion
[16:21:46 CEST] <JEEB> I wish the scale filter would output which steps it actually takes within itself
[16:24:29 CEST] <JEEB> ok, it seems like zscale supports AV_PIX_FMT_GBRP10 input (?)
[16:24:50 CEST] <JEEB> or wait it also takes in 12bit because yours is 12bit
[16:24:58 CEST] <JEEB> see the array @ https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_zscale.c#L157
[16:25:37 CEST] <utack> so build ffmpeg with zscale, tell it to use zscale, and it should work?
[16:25:42 CEST] <JEEB> so you have to have swscale shuffle some bytes from gbrap12le to gbrp12
[16:26:10 CEST] <JEEB> that shouldn't be a bit depth conversion so that shoul only be a shuffle of bytes
[16:26:49 CEST] <JEEB> then you proceed to using zscale so that you define for example BT.709 everywhere and then also make sure the encoder outputs that metadata into the stream so that players don't have to guess
[16:30:14 CEST] <JEEB> so something a la -vf "format=gbrp12le,zscale=r=limited:p=709:t=709:m=709,format=yuv420p10"
[16:30:31 CEST] <JEEB> this instead of just the pix_fmt
[16:30:57 CEST] <JEEB> post -v debug of that either it fails or not
[16:31:57 CEST] <JEEB> that first should make swscale convert to gbrp12 that zscale possibly should support according to the latest master code, and then should convert into limited range and BT.709 everything YCbCr, 10bit
[16:32:19 CEST] <JEEB> zscale itself doesn't take the output format itself so you have to specify another format after zscale for it to know what output format you want
[16:33:06 CEST] <JEEB> and yes it's ugly as hell to try and work around the crappiness of swscale. it's an ancient monstrocity that does so many things that people don't want to throw it away
[16:33:17 CEST] <JEEB> yet it does many things wrong
[16:34:28 CEST] <utack> zscale complains about "code 3074: no path between colorspaces" now and does not want to generate an output
[16:35:10 CEST] <JEEB> just post the full thing with -v debug and let me see
[16:36:55 CEST] <JEEB> on a pastebin I mean :P
[16:37:46 CEST] <utack> one second, it takes a while
[16:39:17 CEST] <utack> http://pastebin.com/26SySZG1
[16:39:27 CEST] <JEEB> thanks
[16:39:29 CEST] <utack> i filtered all the cfhd debug messages out, it was chaotic otherwise
[16:39:48 CEST] <utack> brb
[16:40:21 CEST] <friki2015> i'm doing a multibitrate encoding. why ffmpeg doesn't use all cpu? (only 3 cpu used of 8 available)
[16:41:28 CEST] <JEEB> ugh, why was gbrp12 on the list if it isn't supported >:|
[16:46:47 CEST] <JEEB> "< Arwen> if you set p/t on the output, you need to set it on the input as well"
[16:46:54 CEST] <JEEB> from the author of zimg
[16:49:43 CEST] <JEEB> utack: try out -vf "format=gbrp12le,zscale=rin=full:pin=709:tin=709:r=limited:p=709:t=709:m=709,format=yuv420p10"
[16:49:59 CEST] <JEEB> that sets input p/t as well
[16:50:25 CEST] <JEEB> or...
[16:50:25 CEST] <JEEB> 17:45 < Arwen> You can also just not set p/t. Then it will perform a matrix-only conversion, which is probably what you're after.
[16:50:28 CEST] <JEEB> 17:45 < Arwen> well, zlib will, idk what zscale does
[16:50:38 CEST] <JEEB> I guess for now we can just define those and see what zscale does
[17:04:42 CEST] <utack> JEEB that seems to have done it, it looks quite similar to what i expected in mpv :)
[17:04:53 CEST] <utack> and does not complain about anything while doing the conversion
[17:05:35 CEST] <JEEB> nice
[17:06:05 CEST] <utack> thanks for taking all that time. i will still have to read about what your filter chain does, my understanding of it is not great, but it works for now
[17:06:20 CEST] <JEEB> hopefully gbrap12le to gbrp12le is not dumb in swscale but if it looks correct that's good
[17:06:27 CEST] <JEEB> now just make sure your output got properly marked
[17:06:43 CEST] <JEEB> so please provide a ffprobe file or ffmpeg -i file of your output
[17:06:58 CEST] <JEEB> so we can see if the output file contains all the required tagging for players not having to guess
[17:07:09 CEST] <utack> ffprobe?
[17:07:17 CEST] <JEEB> either one is fine
[17:07:26 CEST] <JEEB> either just `ffprobe file` or `ffmpeg -i file`
[17:07:38 CEST] <JEEB> neither will do anything but only show info on the file
[17:07:53 CEST] <JEEB> the file being the output file you created with the command line that worked
[17:08:06 CEST] <utack> seems like it is missing
[17:08:09 CEST] <utack>   Duration: 00:00:10.00, start: 0.000000, bitrate: 371 kb/s
[17:08:09 CEST] <utack>     Stream #0:0: Video: hevc (Main 10), yuv420p10le(tv), 4096x2304, SAR 1:1 DAR 16:9, 0.10 fps, 0.10 tbr, 1k tbn, 0.10 tbc (default)
[17:08:09 CEST] <utack>     Metadata:
[17:08:09 CEST] <utack>       ENCODER         : Lavc57.48.101 libx265
[17:08:10 CEST] <utack>       DURATION        : 00:00:10.003000000
[17:08:14 CEST] <utack> hope the 3 line paste is ok here
[17:08:27 CEST] <JEEB> kind of much but I'll let it slip for now ;)
[17:08:39 CEST] <JEEB> yeah, that misses the stuff we set in zscale
[17:08:57 CEST] <JEEB> you'll have to use x264-params to set it once more
[17:09:01 CEST] <utack> ok
[17:09:16 CEST] <JEEB> or well, x265-params since that's what you're using atm
[17:11:25 CEST] <JEEB> -x265-params "colorprim=bt709:colormatrix=bt709:transfer=bt709"
[17:11:27 CEST] <JEEB> it seems
[17:11:41 CEST] <utack> yes trying that now, i will have the ffprobe in a second
[17:11:42 CEST] <JEEB> because we set bt709 in zscale with the "709" parameters
[17:12:14 CEST] <JEEB> I kind of had wished zscale's output flags would have affected the encoder, but unfortunately that doesn't seem to be the case
[17:12:58 CEST] <JEEB> but by setting those values any player shouldn't have to guess things when playing the video, instead the colorspace values are all written in the file
[17:13:13 CEST] <utack> http://pastebin.com/e7RG8gSt
[17:13:23 CEST] <utack> color range full is missing i guess?
[17:13:32 CEST] <JEEB> no, YCbCr should be limited
[17:13:38 CEST] <utack> ok then it is all set
[17:13:41 CEST] <JEEB> unless you specifically are aiming for players that can handle it
[17:13:52 CEST] <utack> thanks again for your help
[17:13:53 CEST] <JEEB> mpv can, but unfortunately the rest of the world doesn't :D
[17:14:01 CEST] <JEEB> (esp. plastic boxes)
[17:14:32 CEST] <JEEB> but yeah, that looks good
[17:15:45 CEST] <bencoh> :]
[18:00:33 CEST] <smitb> hello everyone, I am new to open source development...so can anyone help me get started with FFMPEG development?
[19:56:09 CEST] <kubrickdave> can anyone comment on the quality of the new native aac encoder compared to fdk-aac?
[19:57:20 CEST] <furq> does "there is no consensus about how good it is" count as a comment
[19:57:45 CEST] <furq> for lc-aac, anyway
[19:58:52 CEST] <JEEB> kubrickdave: I'd say it's "good enough"
[19:59:10 CEST] <kubrickdave> ok. thanks!
[19:59:13 CEST] <furq> it's definitely better than faac
[19:59:19 CEST] <furq> in much the same way that i am taller than warwick davis
[19:59:28 CEST] <kubrickdave> furq: haha!
[19:59:30 CEST] <JEEB> yeah, faac was just bad :P
[20:00:42 CEST] <furq> if you already have a build with fdk then use that
[20:01:24 CEST] <furq> if not then the native encoder is probably fine at 128k and above
[20:03:50 CEST] <kubrickdave> yeah. i would use the native encoder just for the convenience of not having to compile with fdk-aac support.
[20:28:32 CEST] <DHE> but I don't think it does HE mode yet
[20:28:39 CEST] <DHE> oh he's gone
[22:37:49 CEST] <sor_> Zucca, when I resize  with the player I can adjust it and it maintains quality... I just want it to open like that
[22:38:05 CEST] <sor_> is there a way to set the window size without and degradation in the file. scale= always lowers the quality, I just want the same file quality but have it open in a smaller window
[22:38:36 CEST] <sor_> sorry Zucca wrong paste
[00:00:00 CEST] --- Mon Jul  4 2016