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

[burek]

[01:55:05 CET] <Retr0id> Sorry for repeating my question, I guess I'll open a bug report after this if nobody can help: Does anyone have advice on how to download a .mpd DASH stream while preserving the encryption metadata (senc atoms etc.)?
[01:56:24 CET] <Retr0id> (when the stream is CENC encrypted)
[10:15:08 CET] <scramblez> Hi All, I noticed some TV recordings won't play on a Sony TV (android OS) over DLNA. I used ffmpeg with '-codec: copy' so that no streams were altered and the resultant .ts file played fine on the TV. Would you know what changed to allow this to happen? Something in the .ts file headers?
[10:16:04 CET] <scramblez> Is there a bit I could flip in situ on such recordings so that DLNA won't stop them playing on the TV?
[10:42:41 CET] <ultramage> hi, with latest ffmpeg, -x264opts "range=full" gives "bad option 'range': 'pc'" even though x264 lists this option right next to other colorspace options that work.
[10:43:05 CET] <ultramage> (er... I tried full and pc, neither works, got them mixed up in the previous line)
[10:44:18 CET] <JEEB> lessee...
[10:46:33 CET] <ultramage> a thread from 2014 says input_range and rage are missing options from from ffmpeg/libx264... great...
[10:46:58 CET] <JEEB> x264-params should be passing it straight to libx264 btw, and most likely setting range in general might work as well
[10:47:06 CET] <JEEB> I'm just looking at x264's "param_parse"
[10:47:12 CET] <ultramage> ah, thank you
[10:47:16 CET] <JEEB> which is what's getting called with both opts and -params most likely
[10:47:26 CET] <JEEB> and I see an option called "fullrange"
[10:47:42 CET] <JEEB> yea
[10:47:53 CET] <JEEB> seems like it's not range=full if you want to pass it straight to libx264 API :P
[10:48:21 CET] <JEEB> and that takes off, on
[10:48:25 CET] <JEEB> as x264_fullrange_names
[10:48:40 CET] <ultramage> I'm having extreme issues trying to convinve ffmpeg/libx264 and libx265 to produce output that plays along with MPC-HC. Currently anything I try will appear washed out since it's decoding it as TV
[10:49:00 CET] <JEEB> full range YCbCr and MPC-HC can be fun depending on various factors
[10:49:06 CET] <JEEB> I recommend testing with something like mpv
[10:49:22 CET] <JEEB> but let's see the FFmpeg libx264 wrapper first for if you really need to use x264-params
[10:49:23 CET] <ultramage> it plays fine in everything except mpc-hc, the thing uses some shitty heuristic or something to decide
[10:49:40 CET] <ultramage> however, with x265 I set the output color range header to full and it still displayed wrong >_>
[10:49:45 CET] <JEEB> avctx->color_range == AVCOL_RANGE_JPEG
[10:49:56 CET] <JEEB> so that is another way in FFmpeg's libx264 wrapper to set range
[10:49:59 CET] <ultramage> I can go into its renderer settings and force 0-255, but I don't like that solution
[10:50:17 CET] <JEEB> well yea, limited and full range YCbCr is 100% up to your renderer in DirectShow
[10:50:22 CET] <JEEB> it's called "too bad, joe" :P
[10:50:35 CET] <JEEB> but anyways, the thing for you is to just flag the stream correctly
[10:51:13 CET] <JEEB> which in case of libx264 in FFmpeg is either -color_range pc or -x264-params "fullrange=on"
[10:51:21 CET] <JEEB> and that should output fullrange being enabled in the libx264 logging output
[10:51:34 CET] <JEEB> for libx265 people have implemented less mappings I think
[10:52:02 CET] <JEEB> yea, the libx265.c wrapper doesn't have a single entry for "range" if I ctrl+F
[10:52:25 CET] <ultramage> so far the only thing that worked was -pix_fmt yuvj444p. That 'j' convinced the whole pipeline to work right.
[10:52:51 CET] <JEEB> that's possibly needed if you want filtering because "lol swscale"
[10:52:59 CET] <ultramage> "fullrange=on" is the correct magic incantation, and it writes the correct header into the metadata, but it still decodes wrong.
[10:53:25 CET] <durandal_1707> ultramage: if you use filtering properly tag input with setrange filter....
[10:53:32 CET] <JEEB> if it shows right in mpv, then it's correctly encoded, but anyways with DirectShow you're shit out of luck :P
[10:53:37 CET] <ultramage> or maybe it's actually encoding wrong? :/
[10:53:59 CET] <ultramage> I'll try throwing in any range settings I can find
[10:54:11 CET] <JEEB> well, encoding is one part and then the possible filtering before that is another thing if you need to do filtering
[10:54:15 CET] <JEEB> the encoding part is simple
[10:54:21 CET] <JEEB> since you can verify the headers
[10:54:27 CET] <ultramage> that yuvj444p thing also makes it write the correct header. but it says it's deprecated and x265 doesn't even support that format.
[10:54:41 CET] <JEEB> yes, x265 wrapper doesn't take it in AFAICS
[10:55:29 CET] <JEEB> (and thus there could be an implicit swscale conversion somewhere which is always fun)
[10:55:34 CET] <ultramage> the fullrange and other color space options are just informative metadata settings only. I guess I'm missing an actual encoder toggle.
[10:55:48 CET] <JEEB> well there is nothing else in the encoder for full range than the flag
[10:55:57 CET] <JEEB> so if the flag is there, the encoder specifically is doing things right
[10:56:45 CET] <JEEB> now, with libx264 part of the problem is that since the J formats aren't really supposed t obe utilized any more, it doesn't take those in. (the range flag instead should be used instead - although the libx265 wrapper doesn't use that, either)
[10:57:12 CET] <JEEB> so it's highly likely that something that is before the *encoder* decides it needs to convert from pix_fmt X to Y
[10:57:17 CET] <ultramage> and the worst thins is that things seem to default to 'tv'
[10:58:03 CET] <durandal_1707> convert to tv, as pc is not supported
[10:58:40 CET] <JEEB> I really wonder if I should be responding that comment or not
[10:59:38 CET] <ultramage> Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv444p(pc), 576x988, q=-1--1, 4000 kb/s, 30 fps, 1k tbn, 30 tbc
[10:59:41 CET] <JEEB> anyways, one thing is now clear - for the *encoder* libx264 and libx265 can be clearly set to utilize the correct flag when you set it according to how the wrapper does it (libx264 it's either the range flag, or the fullrange=on api thing - for libx265 it's just the correct x265-params thing)
[11:00:13 CET] <JEEB> you should at the very least bump verbosity to -v verbose as that shows you (mostly) everything lavfi/swscale comes up with
[11:00:35 CET] <JEEB> + for libx265 specifically any hacks regarding the J pix_fmts will not work, since it doesn't take those in at all
[11:01:16 CET] <ultramage> -color_range pc ffmpeg option appears to do the right thing... at least libx264 reports yuv444p(pc), and the metadata header is set. mpc-hc still decodes it wrong <_>
[11:01:33 CET] <JEEB> yes, that only affects the libx264 *encoder*
[11:01:35 CET] <durandal_1707> but perhaps x265 encode wrapper should not ignore set color_range?
[11:01:52 CET] <JEEB> durandal_1707: yea you currently have to use x265-params to set the flag
[11:01:54 CET] <ultramage> hm, now it seems to work? so confused.
[11:02:25 CET] <ultramage> I'm going to do a bunch more tests to see if it behaves. Thank you for your help so far.
[11:02:35 CET] <JEEB> ultramage: basically most likely whatever's going bonkers for you is /before/ the encoder part. although I would really, really use mpv as a reference as opposed to mpc-hc
[11:02:44 CET] <JEEB> mpc-hc is so dependant on your driver and video rendere in directshow
[11:02:46 CET] <ultramage> ah, it doesn't. I just forgot the 'j' in the pix format.
[11:02:56 CET] <ultramage> okay I will do that
[11:03:15 CET] <JEEB> also that 'j' pix_fmt can actually kill your attempts at passing that stuff through :P
[11:03:18 CET] <JEEB> it really "depends"
[11:03:28 CET] <JEEB> and that's the stuff *before* encoding, the filtering
[11:03:40 CET] <JEEB> and as I said, -v verbose will help you poke at what on earth that thing's doing
[11:03:58 CET] <JEEB> the encoder is just one thing of the chain, and we *know* how you get the *encoder* to flag it as you want
[11:04:11 CET] <durandal_1707> ultramage: full uncut ffmpeg command and console output missing
[11:04:15 CET] <JEEB> now the thing to make sure is to make sure what gets *fed* to the encoder is correct
[11:04:38 CET] <JEEB> because there's umpteen things that may or may not go bonkers with this stuff :P
[11:04:59 CET] <JEEB> in theory if your input is already in the size and pix_fmt you want
[11:05:11 CET] <JEEB> you just want to minimize anything lavfi/swscale does to your input
[11:05:52 CET] <JEEB> and I hope I haven't confuzzled the heck out of you by trying to separate the *encoder* part in this whole mess from the rest of it that comes before it :P
[11:06:08 CET] <JEEB> because the *encoder* part is really simple to verify (the flag is set correctly)
[11:06:20 CET] <JEEB> then the rest is making sure that the correct input is fed to it
[11:06:37 CET] <JEEB> because unfortunately that part is what can go wrong in so many ways
[11:07:02 CET] <JEEB> and after that has been verified with something known to more or less do things right, then you can just sigh in despair if DirectShow doesn't support it properly :P
[11:07:15 CET] <JEEB> (read: whatever renderer you're using)
[11:07:18 CET] <ultramage> yeah I'm familiar with the concept of the input being read wrong
[11:07:36 CET] <JEEB> nah, more like it gets mungled after reading. reading itself is generally correct :P
[11:08:15 CET] <JEEB> the semi-automated (but also user-controllable if needed) filtering that is between "we got raw images from input" and "we got raw images fed into an encoder"
[11:08:36 CET] <JEEB> <input> - <filtering lol> - <encoder> - <muxing>
[11:09:46 CET] <ultramage> .\ffmpeg.exe -y -i %1 -t 1 -c:v libx264 -preset veryfast -color_range pc -pix_fmt yuv444p -b:v 4000k -an %1.mkv
[11:10:01 CET] <ultramage> the output of this appears washed out in mpv as well.
[11:10:35 CET] <JEEB> now add -v verbose there and read out the log :P if the windows cmd.exe sucks with that - " 2> out.log" should output stderr into out.log
[11:10:49 CET] <JEEB> and you can then read through that in a text editor
[11:11:07 CET] <durandal_1707> <input> - <demuxing> - <FANCY filtering> - <encoder> - <muxing> - <output>
[11:11:22 CET] <ultramage> I think I'll do a raw RGB capture and use that as input to first rule out any input recognition/conversion shenanigans
[11:11:22 CET] <JEEB> and yes, you're setting color range full and pix_fmt to non-j. that might trigger some funky conversions
[11:11:38 CET] <durandal_1707> oh, missed decoding part...
[11:11:52 CET] <JEEB> yea
[11:13:01 CET] <JEEB> ultramage: basically that sounds for me that the pix_fmt is causing a conversion to limited range in swscale, and then color_range of course sets the metadata in the encoder
[11:13:04 CET] <JEEB> thus the mismatch
[11:14:03 CET] <durandal_1707> i will repeat for last time, if input color range is not properly set the "-color_range pc" will do bad things
[11:14:25 CET] <JEEB> of course
[11:18:49 CET] <ultramage> mmm
[11:21:47 CET] <ultramage> what is the toggle for the input color range override?
[11:22:20 CET] <JEEB> there's probably one for lavfi and then there's the color_range for just input
[11:22:48 CET] <JEEB> (color_range et al mean different things before/after -i)
[11:23:06 CET] <JEEB> and yea, for lavfi filtering it'd be setrange filter
[11:24:32 CET] <ultramage> ugh, someone smarter than me should look into this, to me it seems like there are multiple stacking issues
[11:25:01 CET] <JEEB> possibly. that's what I was going after with the fact that the *encoder* being primed correctly for the range you'd want is simple :P
[11:25:42 CET] <JEEB> (and that the stuff that happens before it is really the "fun" part)
[11:28:45 CET] <ultramage> I created a small RGB avi from bmp files using vdub. I invoked 'ffmpeg -c:v libx264 -profile high444' to bypass any manual color fiddling. In mpv it looks fine, in mpc-hc it's washed out.
[11:29:04 CET] <JEEB> always use -v verbose
[11:29:25 CET] <JEEB> since that outputs stuff regarding any filter chains that might get utilized
[11:33:06 CET] <ultramage> https://paste.pfak.org/nqodlgsK
[11:33:58 CET] <JEEB> [auto_scaler_0 @ 000000000037b980] w:1920 h:1080 fmt:bgr24 sar:0/1 -> w:1920 h:1080 fmt:yuv444p sar:0/1 flags:0x4
[11:34:06 CET] <JEEB> what happened here is full->limited range conversion
[11:34:42 CET] <ultramage> yup... if I lie about the fullrange header, mpv will show it washed out. this implies that the video is indeed limited
[11:35:18 CET] <ultramage> this seems to match the x64 documentation which says that fullrange is off by default (although it says that only in the metadata docs)
[11:35:22 CET] <JEEB> but yea, since you set no real parameters in there, that's what happens by default
[11:35:29 CET] <JEEB> yes, limited range is default for YCbCr
[11:35:34 CET] <JEEB> and full range is default for RGB
[11:35:39 CET] <JEEB> almost everything works in that kind of setup
[11:35:56 CET] <JEEB> unless said otherwise, that's how those are taken in by applications
[11:37:14 CET] <ultramage> hm, my issue started once I switched to ffmpeg and asked it to encode as yuv444 instead of yuv420, and all my videos appeared washed out. I think mpc-hc decodes yuv444 as fullrange always.
[11:37:59 CET] <JEEB> mpc-hc is less simple but I would say nope at that since pretty much all YCbCr interactions are taken in as limited range unless otherwise tagged (and if the receiving part even acknowledges that)
[11:38:19 CET] <JEEB> like, even YCbCr colorspace tagging in directshow is 100% up to the renderer and/or driver
[11:38:32 CET] <JEEB> BT.601 vs BT.709 that is
[11:41:57 CET] <ultramage> so then, am I doomed? should I go back to x264rgb, or keep abusing yuvj444p?
[11:42:35 CET] <JEEB> I would say if you can utilize RGB, that's simpler
[11:42:43 CET] <JEEB> since you're encoding 4:4:4 anyways as far as I can see?
[11:43:53 CET] <ultramage> I'd rather not... I think I stopped using rgb after discovering that x265 doesn't support it, or something like that. I wanted to keep my settings as similar as possible
[11:44:26 CET] <JEEB> as far as I can see libx265's wrapper takes in GBRP as well
[11:44:28 CET] <ultramage> might be less of an issue now that youtube finally accepts x265
[11:44:52 CET] <JEEB> if you're uploading to youtube I don't see any reason to use x265 tbqh. you can just throw lossless at that thing anyways
[11:45:33 CET] <JEEB> anyways, AV_PIX_FMT_GBRP is in libx265's list of supported pix_fmts
[11:45:42 CET] <ultramage> it does take direct lagarith/dxtory captures, but they tend to get quite large and the youtube cutoff is somewhere around 10GB.
[11:46:23 CET] <JEEB> libx264 takes in BGR0,24 and RGB24
[11:46:35 CET] <JEEB> so somewhat different pix_fmts, but still RGB is supported in both
[11:46:49 CET] <JEEB> oh, they've got an upload size limti now? :P
[11:47:13 CET] <JEEB> that is awfully inconvenient given that generally you want to eff with your source the less as possible because their encoders will only barf *more* at them
[11:47:30 CET] <ultramage> well, a few years back when I was doing this, that was about as much as it'd take without breaking during upload.
[11:48:52 CET] <JEEB> anyways, personally I don't see any reason to use libx265 for youtube uploads. it's slower and last time I checked the detail retention at similar bit rates was worse off if you went out of the "both are crappy as hell" territory
[11:48:55 CET] <ultramage> this originally started because the game footage me and a friend were uploading was getting its color space distorted and causing other artifacts... it looked crap.
[11:49:39 CET] <ultramage> but god, it's been so long ago that I don't remember the cause anymore. We were using vdub's x264vfw back then, probably wihtout any fancy settings.
[11:53:05 CET] <ultramage> I used rgb after that for some time, but then switched to yuv because... I don't remember why. Either my new capture software was using yuv and I wanted to avoid any extra lossy colorspace conversions, or the rgb encoding was much slower / less optimized than yuv.
[11:53:38 CET] <JEEB> the encoding itself should be the same since it's 4:4:4 data (compared to 4:4:4 YCbCr)
[11:53:54 CET] <JEEB> RGB conversion could be adding something in there, but loldunno
[12:14:18 CET] <isimulate> Where is the FFMPEG documentation? I was able to navigate to https://www.ffmpeg.org/libavdevice.html, which appears to the be provided docs for libavdevice, btu there's no information there about how to use it, it just links you to user tools rather than any docs about the API. Where do you go to learn how to use this library?
[12:14:39 CET] <JEEB> site:ffmpeg.org doxygen trunk KEYWORD
[12:14:41 CET] <JEEB> is what I usually do
[12:24:22 CET] <JEEB> also there's the examples under doc/examples
[12:33:55 CET] <trfl> if a comment is added to a 2 year old issue on trac.ffmpeg.org, will it get bumped/noticed?
[12:34:31 CET] <JEEB> it will get posted on the -devel IIRC channel at the very least
[12:34:40 CET] <JEEB> whether someone does something about it is a different thing
[12:34:53 CET] <JEEB> I know at least one person is somewhat looking at updates in the tickets
[12:34:59 CET] <trfl> aight, that's good
[12:35:27 CET] <trfl> was about to start blaming my cd drive for truncating tracks but turns out there's one particular wav file which causes ffmpeg's flac encoder to generate an invalid bitstream or something :p
[12:35:37 CET] <trfl> so the file gets truncated depending on which decoder is used to read it
[12:36:14 CET] <JEEB> funky
[12:39:37 CET] <durandal_1707> shit
[12:41:43 CET] <ultramage> ... encoding RGB24 with -pix_fmt yuvj444p causes oversaturation, nnnnnnooooooooo D:
[12:42:46 CET] <durandal_1707> ultramage: full uncut ffmpeg command and console output missing
[12:43:40 CET] <ultramage> actually nvm, it seems like the act of encoding to any form of yuv causes a noticeable difference in brightness (or something)
[12:44:17 CET] <ultramage> I decided to take notes after each test and do a visual comparison of the input and output in mpc and mpv.
[12:52:38 CET] <ultramage> there is a noticeable increase of brightness when encoding to yuv(420, 444, j444) in both mpc and mpv... is this the result of the conversion?
[12:53:17 CET] <ultramage> (when encoding the testing rgb rawvideo)
[12:53:43 CET] <durandal_1707> swscale is crap
[12:54:02 CET] <durandal_1707> use zimg with zscale filter if you can
[12:54:22 CET] <JEEB> also with verbose verbosity make sure that no funky stuff happens
[12:54:43 CET] <ultramage> [auto_scaler_0 @ 00000000003fb9c0] w:1294 h:832 fmt:bgr24 sar:0/1 -> w:1294 h:832 fmt:yuv444p sar:0/1 flags:0x4
[12:54:52 CET] <JEEB> because while there's an option to disable implicit adding of swscale, I think you can't do that with ffmpeg.c :P
[12:55:25 CET] <durandal_1707> there is filtergraph option to disable auto insertion of filters
[12:55:30 CET] <JEEB> yes, that's what I meant
[12:55:34 CET] <JEEB> but I don't think you can use that from ffmpeg.c
[13:09:20 CET] <ultramage> strange, the options for zscale filter do not list any format options
[13:09:43 CET] <JEEB> for output format you set the pix_fmt with the format filter
[13:09:47 CET] <JEEB> which is a meta thing
[13:10:10 CET] <JEEB> zscale=blah=blah:blah2=blah2,format=bgrp for RGB conversion, for example
[13:10:24 CET] <JEEB> and then you set additional parameters in zscale as needed
[13:17:20 CET] <isimulate> Why are timestamps normalised to a time base in general? I wonder why they can't be stored as unnormalized seconds into a uint64_t and avoid the multiplications to convert them back into seconds. I am new to MM in general, so no trick question here, sorry if it's very stupid xD
[13:17:23 CET] <ultramage> I can't get it to work. zscale is missing documentation
[13:17:38 CET] <ultramage> and I have an extreme headache after messing with this for 4 hours straight
[13:19:46 CET] <ultramage> all I want is for the encoding process to retain as much of the original as possible. But it's immediately changing the brightness... that's not what I want
[13:20:22 CET] <JEEB> well the first question of course is if your build is even built with zimg :P
[13:20:32 CET] <ultramage> it is
[13:20:33 CET] <JEEB> which zscale is a wrapper around
[13:20:35 CET] <JEEB> ok
[13:21:58 CET] <JEEB> zimg can error out with non-clear erros but I've had it work nicely when I've tried things
[13:22:10 CET] <ultramage> I would like the magic incantation to make it do rgb->yuv444p conversion (maybe in bt709) so that when I encode the thing, there will be no perceivable difference between the input and output
[13:23:07 CET] <ultramage> swscale seems to be doing some weird color correction, or idk, and it causes an obvious difference between the input and output
[13:24:14 CET] <ultramage> hmmm maybe I should transcode it back to rgb to rule out any playback decoder interference
[13:27:38 CET] <isimulate> are there any books y'all can recommend for a background in multimedia?
[13:28:12 CET] <JEEB> it starts with "what is light", but there's EBU's "Circles of Confusion"
[13:28:18 CET] <JEEB> which somehow is an apt name :P
[13:28:26 CET] <JEEB> https://tech.ebu.ch/circles-of-confusion
[13:29:47 CET] <isimulate> Haha, thanks JEEB !
[13:34:13 CET] <JEEB> isimulate: also unfortunately we have things that need fractional time bases, such as 24/1.001 , 30/1.001, 60/1.001 and 120/1.001 to note a few rates :)
[13:34:25 CET] <JEEB> in which case your time base would be f.ex. 1001/24000
[13:34:37 CET] <JEEB> and then every picture in a constant frame rate stream would have a +1 PTS
[14:52:49 CET] <Redfoxmoon> does ffmpeg support building with -no-undefined on linux?
[14:54:08 CET] <JEEB> funny enough if you git grep for no-undefined, the symbian arch part of the configure script seems to contain "-Wl,--target1-abs,--no-undefined"
[14:54:11 CET] <JEEB> linker parameters
[14:54:21 CET] <JEEB> so at least something has had it by default :D
[14:56:41 CET] <Redfoxmoon> oh dear.
[14:57:20 CET] <Redfoxmoon> JEEB, does the symbian port still work though? :P
[14:58:24 CET] <JEEB> I have no idea
[14:58:38 CET] <JEEB> I haven't seen it in FATE at least
[14:58:42 CET] <JEEB> so it's not automagically tested
[14:58:47 CET] <JEEB> (and I'm totally not surprised)
[14:59:05 CET] <JEEB> http://fate.ffmpeg.org/ is FATE, for the record
[14:59:09 CET] <Redfoxmoon> fair enough, it's not exactly common:-)
[14:59:22 CET] <JEEB> well it's one of those things that used to be all around :P
[14:59:25 CET] <JEEB> but no more
[14:59:41 CET] <Redfoxmoon> indeed:-)
[14:59:46 CET] <Redfoxmoon> neat! @fate
[15:44:19 CET] <Redfoxmoon> Is it possible to disable building the x86 code in libavutil when targeting x86?
[15:44:47 CET] <Redfoxmoon> running into some issues attempting to port ffmpeg to a new platform :^)
[16:17:31 CET] <JEEB> Redfoxmoon: plethora of ways to do something like that. see how other archs work etc
[16:27:26 CET] <Redfoxmoon> taking libavcodec as an example, I don't see any links in either the root makefile or the libavcodec makefile to arch specific bits under libavcodec/
[16:27:27 CET] <Redfoxmoon> o_O
[16:29:52 CET] <Redfoxmoon> ah nevermind, I figured it out
[16:50:12 CET] <BenderRodriguez> why does ffplay segfault when trying to play music
[16:50:21 CET] <BenderRodriguez> I have pulse audio configured with a bluetooth receiver as the sink
[16:50:35 CET] <BenderRodriguez> mpg123 and other music player utilities work fine
[16:50:38 CET] <BenderRodriguez> but ffplay segfaults
[16:50:53 CET] <JEEB> ffplay is someone's favourite little thing, not generally developed thing
[16:51:03 CET] <JEEB> if you care enough, you could try getting a stack trace with gdb
[16:51:06 CET] <JEEB> and posting on trac
[17:22:31 CET] <analogical> can I somehow use FFmpeg to download flash video from a website?
[17:31:12 CET] <Mavrik> youtube-dl is your better bet I think.
[17:32:53 CET] <iive> BenderRodriguez, try `-an` to rule out other possible reasons than the audio output.
[17:40:18 CET] <wuOz> hi, I try to build ffmpeg 4.1. did you stop support libnut build and disabled the disable-ffserver option? Further it can't find xlib, but in version 3 build it could find it with my build options.
[17:41:10 CET] <JEEB> git grep "libnut"
[17:41:10 CET] <JEEB> Changelog:- remove the libnut muxer/demuxer wrappers
[17:41:32 CET] <JEEB> seems so (doesn't surprise me since libavformat is pretty much the de facto implementation for NUT)
[17:41:44 CET] <JEEB> and ffserver was removed quite a bit earlier
[17:41:57 CET] <JEEB> actually, I think both those changes are probably way back there in the change log
[17:42:05 CET] <wuOz> ffserver was great, what happened?
[17:42:11 CET] <JEEB> uhh
[17:42:42 CET] <JEEB> no, it was not great (only did very specific things), and it required quite not-pretty things to function in the libraries etc
[17:42:53 CET] <JEEB> plus pretty much nobody was maintaining it :P
[17:43:01 CET] <wuOz> streaming alway worked fine for me
[17:43:11 CET] <JEEB> well for streaming you generally didn't even need ffserver
[17:43:38 CET] <JEEB> for stuff like UDP multicast you could just use ffmpeg.c, and for HLS/DASH type of streaming you could just use ffmpeg.c feeding into a basic nginx or any of those media server things
[17:44:13 CET] <JEEB> and I think the best part was that almost nobody of the FFmpeg developers even knew how ffserver was even supposed to be utilized
[17:44:21 CET] <JEEB> as in, what would actually work with it :P
[17:44:36 CET] <JEEB> long story short it was a mess and it is out now after years of "we should remove it unless someone steps up"
[17:44:39 CET] <JEEB> and nobody stepped up
[17:44:41 CET] <JEEB> :P
[17:44:47 CET] <wuOz> well as application it was fine
[17:45:09 CET] <JEEB> I would put that in a lot of quotation marks
[17:45:24 CET] <wuOz> i quote myself
[17:45:34 CET] <JEEB> as in, """fine"""
[17:45:44 CET] <wuOz> alright
[17:45:52 CET] <JEEB> but yes, it probably worked for some use cases
[17:45:55 CET] <JEEB> unfortunately internally it was a mess
[17:46:05 CET] <JEEB> and it didn't even work with modern ways of streaming
[17:46:14 CET] <JEEB> which users tend to expect
[17:47:17 CET] <wuOz> hmm, it could broadcast as well as search the stream. don't know what else you could expect
[17:48:09 CET] <wuOz> but probably the code was messed up, if I got you right
[17:48:18 CET] <JEEB> anyways, there generally seemed to be better working alternatives for a lot of use cases, and nobody stepped up to improve it
[17:49:17 CET] <JEEB> some people have tried to write a new "ffserver" for the things that people tend to nowadays expect from HTTP streaming etc, but personally I would rather see those as modules for web servers and such (there already are a few, like nginx-rtmp and such)
[17:49:35 CET] <JEEB> or just plain nginx since libavformat can push a stream to a serving server with HTTP POST
[17:49:39 CET] <JEEB> (among other things)
[17:51:15 CET] <wuOz> ok
[18:22:46 CET] <wuOz> could fix building v4.1 and xlib with LDFLAGS="-L/way/to/libdir" flag
[18:23:29 CET] <wuOz> despite pkg_config_path was given
[18:25:38 CET] <JEEB> probably because xlib has no pkg-config check in configure
[18:26:10 CET] <JEEB> if there's a pc file for it, someone should add that :P
[18:26:44 CET] <JEEB> switch check_lib to check_pkg_config
[18:32:06 CET] <wuOz> xlib.pc is not there, but x11.pc and it could build without LDFLAGS in ffmpeg version 3
[18:33:16 CET] <JEEB> probably accidental from something else, because I'd be surprised if xlib configure steps would have changed
[18:33:49 CET] <JEEB> basically a lot of stuff before was globally added to a lot of checks, which made things accidentally work (but also add unnecessary flags for stuff)
[18:34:38 CET] <JEEB> oh, it was actually touched in May 2018. used to only check for func_headers before?
[18:35:11 CET] <wuOz> ok
[18:35:23 CET] <JEEB> also at 3.3 (2016) there was another change to xlib checks
[18:35:51 CET] <JEEB> because it seems back then it would way too easily try to link against xlib :P
[18:37:33 CET] <wuOz> as I remember it was 3.1.3 which could still build, so that could explain it
[18:39:10 CET] <JEEB> well that's quite a few years ago and tehre's been various changes/improvements to the configure script since
[18:39:29 CET] <JEEB> it might have poked the extra library search path from something else
[18:39:51 CET] <JEEB> nowadays the checks are more separated
[18:40:03 CET] <JEEB> (which is why pkg-config is 100% preferred)
[18:40:25 CET] <JEEB> I added a check for zlib through pkg-config because I got tired of having to add --extra-ldflags="-L/my/cross/prefix/lib"
[18:40:32 CET] <JEEB> (and since zlib has a pc file)
[18:58:44 CET] <cyberaesthetic> Anyone around to answer a question re: time skipping? Noticed something in emby, replicated it in VLC, speculation is that something is going on at the ffmpeg layer:
[18:58:46 CET] <cyberaesthetic> https://emby.media/community/index.php?/topic/57777-chromecast-time-skip-not-working/
[19:46:26 CET] <plexigras> how do i best compress a livestream i am recording?
[19:46:56 CET] <plexigras> example: `streamlink https://www.twitch.tv/riotgamesbrazil 480p --stdout | ffmpeg -i pipe:0 out.mp4`
[20:26:07 CET] <friendofafriend> plexigras: Sounds like you have the right idea.
[20:32:06 CET] <Redfoxmoon> do I need to go through a mailing list to get patches upstreamed for ffmpeg?
[20:34:43 CET] <Redfoxmoon> also wondering how HAVE_INLINE_ASM_DIRECT_SYMBOL_REFS, HAVE_INLINE_ASM_LABELS and HAVE_INLINE_ASM_NONLOCAL_LABELS are detected
[20:39:24 CET] <plexigras> friendofafriend: i would just love to know if there are some cool tricks i can use to save on disk space :)
[20:41:20 CET] <friendofafriend> plexigras: Yes, but you'll want to save on CPU time next!
[20:45:08 CET] <plexigras> friendofafriend: true, do you know where i can read about compression in the documentation?
[20:45:59 CET] <friendofafriend> When you say "compression", what do you mean?  Available codecs?
[20:48:02 CET] <plexigras> i am after reducing file size :)
[20:48:12 CET] <friendofafriend> Compression comes down to codec and quality settings.  It's mostly about how much CPU time you're willing to use, and how good looking the result needs to be.
[20:49:06 CET] <friendofafriend> The best recommendation would probably be to scale the video down to a lower resolution.
[20:49:56 CET] <friendofafriend> And then reencode with something hardware accelerated, like NVENC.
[21:07:39 CET] <plexigras> friendofafriend: i'm trying around with different codecs but i can't really see a difference in file size what codecs do you recommend i try?
[21:18:21 CET] <friendofafriend> plexigras: It would be best to use something hardware accelerated by your system.
[21:19:32 CET] <plexigras> okay i will keep looking and if nothing better comes up i will just stick with libx264
[21:20:04 CET] <friendofafriend> If you just need to reduce your file size, try scaling down.  You'll have to make a compromise somewhere.  ;)
[21:44:56 CET] <Mavrik> Umm.
[21:45:08 CET] <Mavrik> Does NVENC come close to x264 yet?
[21:45:53 CET] <pink_mist> how could it ever?
[21:46:10 CET] <pink_mist> isn't it hardware-based?
[21:46:35 CET] <pink_mist> literally replacing the hardware is the only way to improve it, isn't it?
[21:49:17 CET] <Mavrik> Well there are several generations of the encoding block.
[21:49:55 CET] <Mavrik> I was just wondering about the recommendation to use it for non-live content, since using HW encoders for that is usually a large waste of quality.
[21:50:46 CET] <pink_mist> I have no idea what improvements newer variants have made over older variants, but it is certainly not on par with x264 for quality
[21:51:41 CET] <Mavrik> "Sixth generation NVENC implements HEVC 8K encoding at 30FPS, HEVC B-Frames support and provides up to 25% bitrate savings for HEVC and up to 15% bitrate savings for H.264."
[21:51:50 CET] <Mavrik> Hm, wonder if anyone did an actual comparison somewhere.
[21:53:12 CET] <furq> "up to" doubtless doing a lot of work there
[21:55:34 CET] <Mavrik> Yeah, although considering the rather huge lag in quality, I wouldn't be surprised if they managed to fix some low hanging fruits.
[22:20:40 CET] <BtbN> Turing h264 nvenc is okayish, but it's still not x264
[23:14:09 CET] <scriptease> evenings
[23:14:45 CET] <scriptease> found some strange behavoiur with ffmpeg...maybe someone can help...
[23:15:20 CET] <scriptease> http://prntscr.com/m6r0ly
[23:16:13 CET] <scriptease> the movie contains a german stream and i transcoded with...
[23:16:14 CET] <scriptease> ffmpeg -hwaccel qsv -i "%%a" -metadata:s:a:0 language=ger -c:v hevc_qsv -load_plugin hevc_hw -preset slow -rc vbr_hq -b:v 3M -maxrate:v 6M -c:a copy -y "D:\Movie Convert\newfiles\%%~na.mkv"
[23:16:39 CET] <scriptease> i tried to force german language on stream 1 with "-metadata:s:a:0 language=ger"
[23:16:48 CET] <scriptease> but this didnt help
[23:16:58 CET] <scriptease> it still uses english language
[23:17:09 CET] <scriptease> any ideas?
[23:36:08 CET] <scriptease> ok found it
[23:36:14 CET] <scriptease> (missed "-map 0")
[23:36:24 CET] <scriptease> thx for your attention
[23:36:27 CET] <scriptease> ^
[23:38:56 CET] <Mavrik> Happy rubber duckies :)
[23:39:44 CET] <scriptease> :-)
[00:00:00 CET] --- Mon Jan 14 2019