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

[burek]

[00:03:37 CEST] <BtbN> HEVC is h265.
[01:15:14 CEST] <roman_> hello
[01:15:33 CEST] <roman_> are there any ffmpeg binaries out there that contain just the LGPL libs
[01:15:45 CEST] <roman_> and not the GPL libs (i.e. libx264 libx265 etc.)
[01:16:12 CEST] <roman_> im trying to find one for macos without having to compile mine, so it will work on all versions and not just sierraq
[01:17:11 CEST] <thebombzen> roman_: if you're looking for static builds (i.e. the command-line tools) there is minimal practical difference between the GPL and LGPL versions
[01:17:31 CEST] <thebombzen> if you're interested in the dynamic libraries, then you will probably have to compile them yourself
[01:17:55 CEST] <roman_> yes but this is for commercial distribution and in order to keep the product closed source i cant have the gpl
[01:18:09 CEST] <thebombzen> only with linking
[01:18:47 CEST] <roman_> right i know
[01:18:56 CEST] <roman_> im going to do dynamic link
[01:19:17 CEST] <roman_> and include ffmpeg's src as well i just want to see if there's a place where this has been built already
[01:19:24 CEST] <thebombzen> You will probably have to compile it yourself. This is not a bad thing though because compiling it yourself lets you enable exactly what you need
[01:19:40 CEST] <roman_> right, but how do i make it work on all versions though?
[01:19:46 CEST] <roman_> because when i compile it does it for just my environment
[01:20:07 CEST] <thebombzen> for a commercial distribution, compiling your own dynamic LGPL verisons and disalbing components you don't need is probably the best bet
[01:20:15 CEST] <roman_> ok
[01:20:21 CEST] <roman_> how do i ensure backwards compatibility?
[01:20:22 CEST] <thebombzen> as for what compiler flags on macOS you need to ensure compatibility?
[01:20:27 CEST] <thebombzen> it depends on what version you want to target
[01:20:34 CEST] <roman_> like 10.8+
[01:20:39 CEST] <thebombzen> good options are --enable-runtime-cpudetect
[01:20:45 CEST] <roman_> and im building on 10.12
[01:21:07 CEST] <roman_> i mean the problem is that the macos compiler defaults it to minimum sdk version 10.12
[01:21:13 CEST] <roman_> and i need it at 10.8ish
[01:21:18 CEST] <thebombzen> I'm not exactly familiar with macOS's compilers but, if they're GCC compatible you can use -march=x86_64 -mtune=generic
[01:21:32 CEST] <thebombzen> this eliminates the CPU issue
[01:21:51 CEST] <roman_> its not really a cpu issue, but an os version issue
[01:22:10 CEST] <roman_> because the environment its built in = the minimum environment it can run in
[01:22:20 CEST] <roman_> so if i build it in 10.12 then it sets minimum version requirement to 10.12
[01:22:37 CEST] <thebombzen> there is a way to do this, I am certain. I just don't know what it is seeing as I don't use macOS. However someone here does know so you can wait for them to answer
[01:22:56 CEST] <roman_> alright
[01:22:59 CEST] <roman_> thank you thebombzen ;)
[01:41:10 CEST] <JEEB> roman_: yea I definitely recommend you building yourself. and yes, you'll have to build on a VM of 10.8 or so if you want to keep compat with 10.8
[01:41:21 CEST] <JEEB> it's a pain in the arse but you will definitely want to have that knowledge
[01:42:11 CEST] <roman_> ok
[01:42:18 CEST] <roman_> ive done command line and all that stuff before
[01:42:23 CEST] <roman_> i just want to ensure max compatibility
[01:42:33 CEST] <JEEB> and yes, apple doesn't make that simple
[01:42:49 CEST] <roman_> what about downloading the different codecs i.e. libvpx
[01:42:50 CEST] <JEEB> some people even made tools to get old xcodes around to newer macoses
[01:42:59 CEST] <JEEB> roman_: include only what you really need
[01:43:06 CEST] <roman_> yea
[01:43:07 CEST] <JEEB> 99% of all decoders are in FFmpeg itself
[01:43:19 CEST] <JEEB> only include encoders you need
[01:43:27 CEST] <roman_> ok
[01:43:34 CEST] <JEEB> in other words, find out which formats you need to encode to
[01:43:42 CEST] <roman_> right i already know which libs i need
[01:43:48 CEST] <JEEB> ok
[01:44:12 CEST] <roman_> so when i download those libs, do i just get it from homebrew or do i have to compile those too
[01:44:28 CEST] <roman_> in other words i dont want the compiler to target my specific system, but allow compatibility  with all macos systems
[01:44:42 CEST] <JEEB> if you are going to distribute those, I definitely recommend not on relying on someone else's binaries
[01:44:58 CEST] <roman_> so the only thing i need to worry about is my os version or do i need to worry about stuff like cpu architecture etc etc
[01:45:01 CEST] <roman_> ok
[01:45:31 CEST] <JEEB> xcode contains the toolchain so I would guess it's actually more about the xcode version installed than macos? no idea though, I have such a limited view into macos :P
[01:45:36 CEST] <kepstin> I think the typical way people do mac os builds like that is find a mac mini or something running the oldest mac os version they want to support :/
[01:45:42 CEST] <JEEB> yes
[01:46:00 CEST] <thebombzen> haha
[01:46:06 CEST] <roman_> ok
[01:46:09 CEST] <thebombzen> can't you create a VM or something as well?
[01:46:12 CEST] <JEEB> yes
[01:46:16 CEST] Action: JEEB has VMs
[01:46:30 CEST] <roman_> so when im compiling
[01:46:35 CEST] <JEEB> so a mac can run an older version of macos/OS X
[01:46:38 CEST] <JEEB> in a VM
[01:46:55 CEST] <JEEB> often the macs just lack the RAM for that, though :P
[01:46:58 CEST] <thebombzen> is this built-in technology or do you need something 3rd party like virtualbox?
[01:47:08 CEST] <furq> JEEB: is that seriously the only way you can target older OSX versions
[01:47:10 CEST] <furq> because that fucking sucks
[01:47:23 CEST] <JEEB> furq: I hear running older xcode *can* work
[01:47:26 CEST] <JEEB> but that requires hacks
[01:47:29 CEST] <furq> i was expecting like a compiler flag or something
[01:47:36 CEST] <furq> not "run the version you want to target in a VM"
[01:47:41 CEST] <thebombzen> furq: apple explicitly and deliberately rejects supporting older versions of the operating systems
[01:47:48 CEST] <JEEB> newer xcode lets you only target newer macos
[01:47:58 CEST] <roman_> so when im compiling i just need to go to the lowest macos version i want to support and compile that way? I don't have to worry about anything else?
[01:48:05 CEST] <JEEB> yes
[01:48:13 CEST] <roman_> ok
[01:48:14 CEST] <JEEB> just test all the versions upwards you care about, of course
[01:48:19 CEST] <roman_> ok
[01:48:27 CEST] <thebombzen> furq: for example if you own an iPhone it's impossible to downgrade your firmware. Because the phone has a call-home feature where Apple has to sign the firmware (gs.apple.com) and if they don't the phone will reject it
[01:48:30 CEST] <JEEB> and some libraries will not be available for you if they were added later
[01:48:54 CEST] <roman_> i just wanted to make sure clang didnt do any other stuff like only target specific chipsets or whatever
[01:49:04 CEST] <JEEB> for macos that generally doesn't happen
[01:49:11 CEST] <JEEB> unless you built for iOS or something
[01:49:16 CEST] <JEEB> but even that is ARM
[01:49:21 CEST] <roman_> so generally when im compiling on macOS, it will work for all the macs that version and above?
[01:49:24 CEST] <thebombzen> furq: you can get around this by requesting a signature from Apple and stashing it, so you can always use the stashed version to downgrade, but that's it
[01:49:26 CEST] <roman_> yeah im just doing macs no iphone
[01:49:37 CEST] <thebombzen> Apple actively rejects supporting older versions of hte OS for new software
[01:50:24 CEST] <roman_> also how do i get xcode
[01:50:27 CEST] <roman_> do i need a developer account
[01:50:33 CEST] <roman_> or do i just download it from the apple store
[01:51:19 CEST] <roman_> or is there an alternative way to get command line tools to save me from downloading the 5gb file
[01:51:39 CEST] <JEEB> it's available from either itunes or the developer downloads (just apple account, though). post-10.6 versions have been free so even if login is required it should be good enough to go
[01:51:57 CEST] <JEEB> anyways, read up the documentation on the OS X/macos version you'll be supporting :P
[01:55:04 CEST] <roman_> ok
[01:55:07 CEST] <roman_> thank you guys
[02:05:16 CEST] <roman_> one last question
[02:05:19 CEST] <roman_> when installing the libs i need
[02:05:21 CEST] <roman_> do i use homebrew
[02:05:25 CEST] <roman_> or do i have to compile them manually too
[02:28:30 CEST] <roman_> also JEEB how do i get xcode on an older version again?
[02:46:49 CEST] <thebombzen> one last question
[02:47:22 CEST] <thebombzen> roman_: it doesn't matter how you install dependencies but if you're planning on shipping builds of dynamic libraries you should probably build them yourself
[02:47:25 CEST] <thebombzen> rather than homebrew them
[02:49:09 CEST] <roman_> ok
[02:49:12 CEST] <roman_> once again thank you
[02:49:17 CEST] <roman_> and i figured out the xcode thank you
[02:49:38 CEST] <roman_> one last thing
[02:50:03 CEST] <roman_> if I am to comply with LGPL, all I have to do is ship binary, ship source tarball, and include a text file saying how I compiled it? thebombzen
[02:50:57 CEST] <thebombzen> I am not sure exactly what is needed. I do know that if you dynamically link to an LGPLed library, your own code doesn't have to be LGPLed
[02:51:47 CEST] <thebombzen> I believe that LGPLed libraries, if you distribute them, a source tarball, and a copy of the LGPL about them, with relevant copyright info that should be enough, but I Am Not A Lawyer and you should not take my word as the final say
[02:52:28 CEST] <thebombzen> Perhaps you don't need to distribute a source tarball with the binaries but host a source tarball and provide a pointer to where a user can download them, but I do not know if this is sufficient.
[02:52:45 CEST] <thebombzen> Before you publish your commerical product you should consult your lawyer about exactly what is necessary
[03:23:07 CEST] <roman_> right
[03:23:08 CEST] <roman_> thank you!
[03:48:48 CEST] <rmbeer> hello
[03:49:07 CEST] <rmbeer> i want playing a stream video in real time, how to playing with ffmpeg?
[03:49:47 CEST] <kiroma> ffplay
[03:58:03 CEST] <rmbeer> ok, i can't view with ffplay...
[03:58:14 CEST] <rmbeer> the link is https://www.youtube.com/c/SolarLune/live
[03:58:42 CEST] <rmbeer> and want view in other format with very low size, like 95 or 94
[04:46:24 CEST] <kittyfoots> hey guys, im seeing memory errors in valgrind in avcodec_decode_video2.  Using ffmpeg 3.3.3 on ubuntu 16.04 via apt.  Is there a version of ffmpeg where these errors are fixed?  My program is occasionally crashing in the decoder and I've been going through it with a fine-tooth comb trying to suss out any potential issues, but the memory errors in ffmpeg are..problematic.
[04:46:57 CEST] <kittyfoots> (im actually using the new decode api, but i guess it uses decode_video2 under the hood)
[05:05:52 CEST] <timofonic> Hello
[05:06:15 CEST] <timofonic> What's this? What advantages does it provide? Is it merged in ffmpeg? https://github.com/qeek-dev/ffmpeg_libyami/
[07:43:48 CEST] <thebombzen> is there any real harm in appending two of the same fps filters in a row
[07:44:00 CEST] <thebombzen> suppose a script ends up producing a filterchain of fps=60,fps=60
[07:44:19 CEST] <thebombzen> similar with format=yuv420p10le,format=yuv420p10le
[07:44:21 CEST] <thebombzen> is this bad?
[07:45:40 CEST] <thebombzen> or is it relatively harmless
[07:55:30 CEST] <timofonic> Anyone is under qemu/kvm/xen and wants GPU virtualization with Intel GPUs? I sent an email to the igvt-g mailing list. Anyone is interested on merging to upstream? https://lists.01.org/pipermail/igvt-g/2017-August/001262.html
[07:55:35 CEST] <timofonic> OOs
[07:55:40 CEST] <timofonic> Wrong channel! hAHA
[07:55:42 CEST] <timofonic> Sorry
[12:26:46 CEST] <ultrav1olet> could anyone comment on bug 6574? I smell something extremely wrong is going on but I don't understand what
[12:30:31 CEST] <ultrav1olet> also since upload.ffmpeg.org is down, what's the best place to upload samples?
[12:47:28 CEST] <ultrav1olet> ffmpeg from GIT exhibits the same problem :(
[13:07:50 CEST] <BtbN> looks fine to me?
[13:34:14 CEST] <nahsi> Anyone used mpdecimate?
[13:36:31 CEST] <kepstin> thebombzen: in the particular cases you mentioned: Extra 'format' filters should be basically no-ops, extra fps filters will add some overhead but do nothing to the video, other filters? depends on the filter...
[13:37:05 CEST] <thebombzen> I thought that this was approximately the case
[13:37:33 CEST] <thebombzen> format requests from the previous filter, but I wasn't sure if libavfilter was smart enough to stack consecutive formats without inserting ,scale, between
[13:37:57 CEST] <thebombzen> as for fps, I assumed there'd be some overhead, but I meant to the actual video
[13:38:03 CEST] <thebombzen> but thanks for clearing that up that it's "safe"
[13:38:43 CEST] <kepstin> if you can avoid the dup filters, i'd recommend doing that, just in case you end up adding one that's not "safe" at some point
[13:39:36 CEST] <thebombzen> I have a segmented script, one of them necessarily spits out 60 fps video and the other one requires 60 fps video
[13:40:02 CEST] <thebombzen> I want to be able to use each scripts independently so the first one just appends ,fps=60 and the second one prepends fps=60,
[13:40:18 CEST] <thebombzen> I wasn't sure if this would actually change the video or just have a minor performance hit
[13:40:21 CEST] <thebombzen> I can live with that
[13:40:27 CEST] <thebombzen> but yea, it appears you cleared that up, thanks
[14:17:16 CEST] <viric> Hello
[14:17:51 CEST] <viric> I think that my camera records to MTS files adding some kind of "void-time" at the beginning, below 1 second
[14:18:01 CEST] <viric> does anybody recall the MTS format having that thing?
[15:27:35 CEST] <disappear> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks
[17:26:33 CEST] <Bear10> I finally have a "workable" solution for my filter, I'm just wondering if someone knows how to create a AVFrame and read an image into it?
[17:27:00 CEST] <Bear10> right now I'm doing AVFrame *out = in; (but I don't want to be referencing the in frame, or if I do I want to be completely removing it's current data and replacing it with a jpeg of my choice)
[17:28:24 CEST] <Bear10> it's "somewhat" working when I use ff_load_image(...) and then copy it to the out with av_image_copy(...) but because it still has a lo of information from the original image it shows up with the wrong masks, and the old image still present
[17:30:17 CEST] <pgorley> hi, is there another way to get the number of frames in an audio file than to count them one by one?
[17:32:14 CEST] <pgorley> Bear10: https://www.ffmpeg.org/doxygen/trunk/group__lavu__frame.html#gaec4e92f6e1e75ffaf76e07586fb0c9ed
[17:32:49 CEST] <pgorley> you could use av_frame_copy after allocating your output frame
[17:32:59 CEST] <Bear10> pgorley: i tried that to no avail
[17:33:51 CEST] <Bear10> I would actually get a segment fault when using this approach, but even then according to the method it copies the contents of data which is something I'm trying to avoid
[17:35:02 CEST] <pgorley> so you want to replace the frame's image?
[17:35:14 CEST] <Bear10> pgorley: correct
[17:35:44 CEST] <Bear10> pgorley: so here's a pastebin of the idea basically https://pastebin.com/mZNJV9sD
[17:35:49 CEST] <Bear10> line 45 you see the issue
[17:36:00 CEST] <Bear10> with the current "approach"
[17:37:16 CEST] <pgorley> do you want to apply a filter to the frame or do you want to load an image file into the frame? i'm confused
[17:37:22 CEST] <Bear10> the latter
[17:37:45 CEST] <pgorley> so why the filter?
[17:38:00 CEST] <Bear10> it's the only way that occured to me to replace the data in the current overlay filter
[17:38:53 CEST] <pgorley> you're using curl to save the image to disk, right?
[17:39:15 CEST] <Bear10> pgorley: right now yes, in the future it might be memory but let's work off the assumption its on disk
[17:40:47 CEST] <pgorley> https://github.com/jnicklas/ffmpeg_test/blob/master/test.c
[17:41:11 CEST] <pgorley> that shows an example of using ff_load_image to get your file into an AVFrame
[17:41:23 CEST] <Bear10> great! let's give that a shot!
[17:44:43 CEST] <zerodefect> Looking for some help using the C-API. I have some decoded binary video data that I wish to encode.  I'm guessing I need to allocate an AVFrame and set the pointers to the original data (instead of making a deep copy).  Once I've passed the AVFrame to encoder, I'm concerned about data lifetime. How do I know that the encoder is finished with the input data?
[17:47:46 CEST] <atomnuker> zerodefect: you don't just set the data pointers of each frame to the data you have
[17:48:23 CEST] <atomnuker> avframes have an avbufferref which is what describes the buffer(s) backing the data planes
[17:48:42 CEST] <atomnuker> there you have a callback which gets called once the encoder's done with the frame
[17:49:13 CEST] <atomnuker> so you need to allocate avbufferrefs at each avframe allocation and fill in the structure including the release function pointer
[17:49:36 CEST] <atomnuker> which is what'll get executed with the opaque context you give when making the avbufferref
[17:50:04 CEST] <zerodefect> atomnuker: Terrific. I'll take a look. Thanks!
[17:50:24 CEST] <atomnuker> it'll be from another thread too so make sure its threadsafe
[17:50:58 CEST] <atomnuker> if you've got the file memmapped then the release function should do nothing
[17:52:12 CEST] <atomnuker> (memmapping rules and people with small address space don't know what they're missing)
[17:52:40 CEST] <zerodefect> atomnuker: Yeah, was about to ask about thread safety
[18:01:20 CEST] <zerodefect> atomnuker: so once I've allocated AVFrame, do I set the AVFrame->buf[AV_NUM_DATA_POINTERS] with the allocated AVBufferRefs?
[18:03:08 CEST] <atomnuker> yes, that's up to you
[18:03:19 CEST] <atomnuker> keep in mind you generally only need 1 avbufferref
[18:05:13 CEST] <zerodefect> Out of curiosity, is the size in the AVBufferRefs important?
[18:05:15 CEST] <atomnuker> so you have 1 buffer with either planar or non-planar pixels, and your avbufferref will point to the base and the data planes in the avframe will point to offsets for each plane
[18:05:27 CEST] <atomnuker> zerodefect: not really
[18:06:32 CEST] <zerodefect> Yes, will use single AVBufferRef with planar pixels. Thanks again for your help :)
[18:06:33 CEST] <atomnuker> so you only really need one avbufferref unless you have some crazy crazy file
[18:06:41 CEST] <zerodefect> No, nothing crazy here
[18:07:12 CEST] <atomnuker> (where you have like 30 frames of luma, then thirty frames of u and then 30 frames of v if your file has 30 frames)
[18:07:35 CEST] <zerodefect> yeah, cool.
[18:07:45 CEST] <atomnuker> rather than as standard where you have luma, u and v following (if you have a planar format) or a yuvyuvyuv or something else interleaved
[18:17:27 CEST] <pgorley> could i call av_read_frame in a loop to count the number of frames in an audio file?
[18:23:54 CEST] <DHE> depends what you mean by number of frames
[18:27:58 CEST] <pgorley> DHE: i'm replacing sndfile with ffmpeg and i've got to replace SndfileHandle->frames()
[18:28:53 CEST] <pgorley> .frames() sorry, though it shouldn't make a difference
[18:29:53 CEST] <durandal_1707> yes, just make sure you do not leak frames
[18:30:24 CEST] <DHE> just wondering if, depending on the file format, there's a better way that you could get from the AVFormatContext data after doing a guess-format
[18:30:36 CEST] <DHE> it might lose some accuracy, but may be a lot faster
[18:32:27 CEST] <pgorley> well there's AVStream->nb_frames but it's not always nonzero
[18:32:47 CEST] <pgorley> counting the number of frames one by one is more of a backup method
[18:35:50 CEST] <pgorley> durandal_1707: as long as i free the frame after av_read_frame it should be fine, right?
[18:36:23 CEST] <durandal_1707> yes, i dont see the code though
[18:37:12 CEST] <pgorley> haven't finished writing it yet
[18:44:16 CEST] <pgorley> do i need to call avcodec_open2 before av_read_frame or can i skip that?
[18:53:55 CEST] <DHE> reading a frame (raw data from container) does not require decoding capability
[18:54:21 CEST] <DHE> it's a known misnomer that av_read_frame should probably be called av[format]_read_packet
[19:00:13 CEST] <JEEB> yea
[19:00:38 CEST] <JEEB> it is totally misleading
[19:10:30 CEST] <pgorley> tools/pktdumper.c seems to do exactly what i need
[19:12:09 CEST] <Lirk> hi
[19:12:45 CEST] <Lirk> is there some input bitrate value for building expression?
[19:13:04 CEST] <Lirk> input bitrate variable
[19:21:07 CEST] <alexpigment> Lirk: you're better off using ffprobe to get the bitrate of a source video
[19:21:13 CEST] <alexpigment> having said that, what is your goal?
[19:21:59 CEST] <alexpigment> If you'd like to maintain a certain amount of quality without having to calculate the source bitrate, it's best to use -crf
[20:33:49 CEST] <Mista_D> can FFmpeg add "Bit rate atom"  to MP4 (btrt in MOOV https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFChap3/qtff3.html )
[20:36:20 CEST] <durandal_1707> open bug report
[20:49:41 CEST] <Mista_D> Is there a GMANE alternative for FFmpeg mail list searching please?
[20:50:58 CEST] <c_14> There's the archives, but not sure they're that searchable https://ffmpeg.org/pipermail/ffmpeg-devel/
[20:51:09 CEST] <c_14> You can check if google or whoever indexed them
[20:52:17 CEST] <thebombzen> Mista_D: did you try going to ffmpeg.org/contact.html (which has the mailing list info)
[20:52:48 CEST] <thebombzen> gg, never mind, there's something wrong haha
[20:54:12 CEST] <thebombzen> I was going to suggest this button, but it's a 404. http://0x0.st/d2f.png
[20:54:53 CEST] <Mista_D> Yeah, gmane's broken for last year or two...
[20:57:42 CEST] <pgorley> how do i convert AVStream->duration to seconds?
[20:57:50 CEST] <JEEB> timebase
[20:58:22 CEST] <JEEB> time base is how many ticks is a single (second)
[20:59:46 CEST] <pgorley> JEEB: so AVStream->duration * av_q2d(AVStream->time_base) ?
[21:26:58 CEST] <DarkElement> Is there any way to get the quality of a video made from individual frames to match the quality of the individual frames? With ffmpeg
[21:27:50 CEST] <DarkElement> I've been using this so far `ffmpeg -threads 8 -pattern_type glob -i "*.jpg" -vcodec libx264 -vb 20M 0_predictions.avi` on a bunch of images, however this is the original frame https://gyazo.com/43bdf55b928f946380d315b53b17352b and this is the resulting video https://gyazo.com/6f69c06ba9c78efef3a89789a4652d85, which is just worse enough to be annoying
[21:32:12 CEST] <viric> How can I know what parameters does a codec want from AVCodecContext?
[21:54:24 CEST] <RandomCouch> Hello, can someone tell me the difference between these 2 streams?
[21:54:29 CEST] <RandomCouch> Stream #0:1(eng): Audio: aac (LC), 8000 Hz, mono, fltp
[21:54:34 CEST] <RandomCouch> Stream #0:1(eng): Audio: aac (LC) ([64][0][0][0] / 0x0040), 8000 Hz, mono
[21:59:06 CEST] <alexpigment> RandomCouch - is the second one 16-bit and the first one not?
[21:59:27 CEST] <RandomCouch> I actually don't know lol, that's why I'm asking
[21:59:30 CEST] <JEEB> it just doesn't say and to be honest, AAC doesn't have bitdepth when coding
[21:59:37 CEST] <alexpigment> doesn't fltp (granted, I have no experience with this weird format) mean not 16-bit?
[22:00:00 CEST] <JEEB> AAC is always decoded to float because that's the closest representation you can get from the lossy coding
[22:00:34 CEST] <alexpigment> JEEB: then why does this post (and its reply) exist? https://stackoverflow.com/questions/32392571/how-to-make-sdl-play-fltp-samples-aac
[22:00:35 CEST] <JEEB> anyways, that just looks like verbosity being different and whether the decoder was initialized or not
[22:01:02 CEST] <JEEB> alexpigment: because not everything that takes in audio takes in floating point numbers
[22:01:09 CEST] <JEEB> which is why you have resamplers
[22:01:38 CEST] <JEEB> the lossily coded audio is decoded into floating point because that's the closest representation. if your next thing requires something else, you resample
[22:02:17 CEST] <alexpigment> ok, well I guess I'll retire back to the shadows. the "FLTP" just stood out to me as being weird
[22:02:58 CEST] <JEEB> my WASAPI audio API in windows takes in floating point numbers just fine (and most likely does a global mix in the end), and maybe some other audio API like SDL doesn't maybe support that? (although it seems like the copypasta'd example code specifically sets the format to AUDIO_S16SYS)
[22:04:31 CEST] <JEEB> RandomCouch: basically according to those lines there's no difference
[22:04:42 CEST] <RandomCouch> hm alright thanks
[22:04:59 CEST] <JEEB> the most likely explanation for the difference in output (if that is the same version of ffprobe or so) is that there's container specific stuff there and that the decoder wasn't started in the latter?
[22:05:11 CEST] <JEEB> but hte profile is the same LC
[22:05:17 CEST] <JEEB> rate is same, 8000Hz
[22:05:23 CEST] <JEEB> mono and mono
[22:06:33 CEST] <BtbN> one is with the extradata info
[22:06:45 CEST] <BtbN> so either the other doesn't have extradata, or it's not parsed yet
[22:06:49 CEST] <JEEB> yes
[22:08:25 CEST] <RandomCouch> hm alright, again, I'm still using ffmpeg on android lol, and on a Nexus 6 specifically, I try to merge 2 videos, when I playback the result video, the second part of it (which is the second video that got concatenated) has no audio, although I am transcoding the whole result video using aac
[22:08:56 CEST] <RandomCouch> also using -bsf:a aac_adtstoasc for the result
[22:10:33 CEST] <RandomCouch> I'm gonna try without the bitstream filter
[22:21:56 CEST] <RandomCouch> Yeah it didn't change anything
[22:51:42 CEST] <RandomCouch> Ahhh I finally fixed it! :D oh man I'm so happy
[22:51:55 CEST] <RandomCouch> and I also realized how dumb I am to not have found the solution sooner
[22:56:26 CEST] <ultrav1olet> I've found out that the scaler in ffmpeg generates very blurry output when downscaling the source. Is there a workaround or I've found an actual bug?
[22:56:44 CEST] <JEEB> try zscale
[22:56:55 CEST] <ultrav1olet> I've filed bug 6574 but perhaps I'm missing something
[22:57:08 CEST] <JEEB> zscale requires https://github.com/sekrit-twc/zimg
[22:57:13 CEST] <JEEB> and --enable-libzimg
[22:57:38 CEST] <JEEB> otherwise it has a very similar command interface filter-wise to the scale filter
[22:57:46 CEST] <BtbN> I still think your downscaled image looks perfectly fine.
[22:58:02 CEST] <ultrav1olet> compare source.png and result.png
[22:58:12 CEST] <ultrav1olet> the difference is staggering
[22:58:38 CEST] <JEEB> if zimg produces something similar, then either zimg is wrong or your expectations are wrong
[22:59:12 CEST] <ultrav1olet> his chain armour is completely destroyed
[22:59:41 CEST] <DHE> you could also compare different algorithms. lazncos (sp?) is worth giving a shot
[22:59:45 CEST] <BtbN> the images are the same size
[22:59:50 CEST] <BtbN> Did you scale it down and back up?
[22:59:57 CEST] <ultrav1olet> also look at his left cheek - the result is smooth and the texture is lost
[23:00:37 CEST] <durandal_1707> nice guy
[23:00:57 CEST] <ultrav1olet> just downscaled
[23:01:09 CEST] <BtbN> oh, both are downscaled
[23:01:11 CEST] <ultrav1olet> did nothing else
[23:01:15 CEST] <ultrav1olet> exactly
[23:01:16 CEST] <BtbN> Yeah, try one of the other scalers
[23:01:29 CEST] <BtbN> zimg is said to be very good
[23:01:40 CEST] <BtbN> no idea what algorithm sws uses
[23:01:42 CEST] <ultrav1olet> I think the problem is not in the type of scaler but in something else
[23:02:02 CEST] <ultrav1olet> mplayer/Xv uses a very basic scaler and it looks miles better
[23:02:06 CEST] <BtbN> https://ffmpeg.org/ffmpeg-scaler.html
[23:02:12 CEST] <BtbN> default is bicubic it seems
[23:02:26 CEST] <BtbN> set it to lanczos for a test
[23:02:43 CEST] <ultrav1olet> I've already tried lanczos
[23:03:01 CEST] <ultrav1olet> In fact I've always used it until yesterday when I discovered this bug
[23:03:28 CEST] <BtbN> lanczos really shouldn't produce results like this
[23:03:57 CEST] <ultrav1olet> does this look correct? -vf scale=768x342 -sws_flags lanczos
[23:05:07 CEST] <ultrav1olet> lanczos looks almost exactly like result.png
[23:05:40 CEST] <JEEB> anyways, I recommend testing with zscale
[23:07:19 CEST] <BtbN> I think it's -vf scale=w=1234:h=1234:flags=lanczos ?
[23:08:27 CEST] <JEEB> -vf "zscale=w=768:h=342,format=gbrp"
[23:08:31 CEST] <JEEB> with zscale, IIRC
[23:09:24 CEST] <JEEB> since you have to hint what you want as output with the format pseudo-filter
[23:09:54 CEST] <ultrav1olet> -vf scale=w=1234:h=1234:flags=lanczos ? => the same result
[23:10:15 CEST] <JEEB> unsurprising
[23:12:30 CEST] <ultrav1olet> JEEB: why "
[23:12:31 CEST] <ultrav1olet> gbrp
[23:12:33 CEST] <ultrav1olet> force planar RGB output
[23:12:34 CEST] <ultrav1olet> ?
[23:13:34 CEST] <ultrav1olet> and it doesn't work: code 3074: no path between colorspaces
[23:14:01 CEST] <JEEB> you don't have colorspace information in your input then
[23:14:09 CEST] <JEEB> for YCbCr at the minimum you need...
[23:14:41 CEST] <JEEB> min
[23:14:52 CEST] <JEEB> if it's bt.709 set min=bt709
[23:15:07 CEST] <ultrav1olet> zscale without options produces the same blurry result
[23:15:08 CEST] <JEEB> if it's 470bg you set min=bt470bg
[23:15:27 CEST] <ultrav1olet> my source is yuv420p
[23:15:29 CEST] <JEEB> ok, then most likely your expectations are wrong. if you truly believe you're right file a bug in zimg
[23:15:46 CEST] <JEEB> ultrav1olet: yes but there's different colorspaces even within YCbCr
[23:15:55 CEST] <ultrav1olet> Why mplayer/Xv works miles better without using any special algorithms?
[23:15:56 CEST] <JEEB> matrix etc
[23:16:16 CEST] <ultrav1olet> I smell something is terribly wrong with ffmpeg
[23:16:34 CEST] <ultrav1olet> like it applies some additional filter after scaling
[23:16:41 CEST] <ultrav1olet> gauss maybe
[23:16:47 CEST] <JEEB> if zscale gives you issues then if there was an issue it'd be in zimg as well
[23:17:01 CEST] <JEEB> feel free to make an issue in zimg if you want, that's used by multiple professional pieces of software
[23:17:24 CEST] <JEEB> (because the license is very liberal etc)
[23:17:37 CEST] <JEEB> in addition to as far as I know Very Correct
[23:17:54 CEST] <JEEB> that's why it doesn't let you convert YCbCr to RGB when you don't have any color metadata, either :P
[23:17:55 CEST] <ultrav1olet> ffmpeg's output is not indicative of using any filters - is this how it works?
[23:18:16 CEST] <JEEB> there most likely are no magical filters in the middle
[23:18:30 CEST] <JEEB> make an issue with zimg if you want a 3rd party opinion unrelated to FFmpeg
[23:18:31 CEST] <JEEB> :P
[23:20:22 CEST] <ultrav1olet> are there any applications using z.lib other than ffmpeg? I cannot find any
[23:20:35 CEST] <JEEB> in open source vapoursynth is one
[23:21:33 CEST] <JEEB> there's also contributions from netflix related people so according to discussions I've had IRL they're using it as well
[23:21:58 CEST] <JEEB> closed source software doesn't have to advertise zimg so (´4@)
[23:23:24 CEST] <JEEB> and /34
[23:23:32 CEST] <BtbN> I somehow have doubts about this being a scaling issuer
[23:23:34 CEST] <BtbN> -r
[23:23:45 CEST] <BtbN> I just can't imagine swscale being that bad
[23:23:53 CEST] <BtbN> specially with other algorithms
[23:24:41 CEST] <ultrav1olet> the source is yours
[23:24:47 CEST] <ultrav1olet> the result is all yours
[23:24:53 CEST] <ultrav1olet> I'm using ffmpeg from GIT
[23:24:58 CEST] <ultrav1olet> it is that bad
[23:25:08 CEST] <BtbN> Yes, but I suspect it's not the scaler making it bad
[23:25:12 CEST] <ultrav1olet> I can upload the source PNG if you're interested
[23:25:23 CEST] <ultrav1olet> to make your life easier
[23:25:41 CEST] <JEEB> also when using FFmpeg's API there's a function in libavfilter to dump a "graphical" representation of the libavfilter filter chain, not sure if there's a command line parameter to do it too
[23:26:06 CEST] <JEEB> http://up-cat.net/p/cbfdf4f9
[23:26:09 CEST] <BtbN> Yeah, attach it to the ticket. Would be very handy to have. And once carl finds the ticket, he will demand it anyway.
[23:26:43 CEST] <ultrav1olet> I've posted a link to a source video ;-)
[23:27:05 CEST] <JEEB> avfilter_graph_dump
[23:27:09 CEST] <JEEB> let's see if that's used anywhere
[23:27:42 CEST] <ultrav1olet> https://image.ibb.co/i2XXuv/source1080p.png
[23:28:14 CEST] <JEEB> meh, ok. seems like ffmpeg.c doesn't have a way of calling that dumper
[23:28:25 CEST] <JEEB> that would have just made it 100% clear what sort of filter chain ffmpeg.c is creating
[23:28:30 CEST] <JEEB> although -v debug should also tell you
[23:28:39 CEST] <JEEB> albeit in less straightforward terms
[23:28:49 CEST] <JEEB> (although not like the "dump" is visually well readable)
[23:28:58 CEST] <BtbN> The -f lavfi format as output should be able to do it
[23:29:31 CEST] <JEEB> if it's like the graph I posted then that should be OK
[23:29:31 CEST] <ultrav1olet> I've just used resize in the simplest image editor and the result is better than what ffmpeg generates
[23:29:38 CEST] <BtbN> It calls that function
[23:30:00 CEST] <BtbN> Hm, but it's only the lavfi demuxer
[23:30:06 CEST] <BtbN> Can't act as output
[23:31:04 CEST] <ultrav1olet> -v debug gives it all
[23:31:22 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] Setting 'w' to value '768x342'
[23:31:29 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] Setting 'flags' to value 'lanczos'
[23:31:35 CEST] <ultrav1olet> [Parsed_scale_0 @ 0x93e28c0] w:768 h:342 flags:'lanczos' interl:0
[23:31:52 CEST] <ultrav1olet> what is [graph 0 input from stream 0:0 @ 0x93e10a0] Setting 'sws_param' to value 'flags=2' ?
[23:33:20 CEST] <JEEB> I would guess 2 is "lanczos"
[23:33:44 CEST] <JEEB> internal values, ho
[23:34:15 CEST] <ultrav1olet> this is madness.
[23:34:25 CEST] <ultrav1olet> When I encode an image alone the result is perfect.
[23:34:44 CEST] <ultrav1olet> When I downscale the source video the result is horrible.
[23:34:46 CEST] <JEEB> anyways, I'd be more interested in the dump of the filtering chain with zscale because the role with the automated scale filter should only be doing GBRP to RGB24
[23:36:02 CEST] <JEEB> basically to check if the automated scale filter is doing anything else than bgrp->rgb24 or so, in which case it just packs the planar values
[23:36:16 CEST] <JEEB> (I thought about adding libp2p support into zscale but :eff:)
[23:36:47 CEST] <ultrav1olet> https://pastebin.com/Rus7VAWH
[23:37:12 CEST] <ultrav1olet> raw https://pastebin.com/raw/Rus7VAWH
[23:39:37 CEST] <JEEB> ok, so in this case there shouldn't even be an auto-inserted scale filter since planar 4:2:0 can be gotten from zimg
[23:39:46 CEST] <JEEB> [Parsed_zscale_0 @ 0x59086c0] w:1920 h:800 fmt:yuv420p sar:1/1 -> w:768 h:342 fmt:yuv420p sar:171/160
[23:40:52 CEST] <JEEB> have you by chance tried a resolution that is 1:1 SAR on the output side as well? or setting ",setsar=1" after zscale to tell the encoder to not set aspect ratio data?
[23:41:40 CEST] <JEEB> anyways, if you think this is incorrect then just make a ticket on zimg's side btw
[23:41:50 CEST] <JEEB> this is now 100% zimg
[23:42:21 CEST] <ultrav1olet> JEEB: why there's no bug when encoding a single image?
[23:42:30 CEST] <JEEB> with scaling?
[23:42:33 CEST] <ultrav1olet> yep
[23:42:39 CEST] <JEEB> as image or as H.264?
[23:42:46 CEST] <ultrav1olet> I'm 100% sure the problem is not with zscaler but with some additional filter ffmpeg applies
[23:42:53 CEST] <ultrav1olet> as a PNG image
[23:43:17 CEST] <JEEB> ok, so in that case RGB
[23:43:35 CEST] <JEEB> you can output RGB with libx264 if you want
[23:43:53 CEST] <ultrav1olet> color space or not, blurriness stems from something completely different
[23:44:03 CEST] <ultrav1olet> since I'm encoding at crf=0
[23:44:20 CEST] <ultrav1olet> um
[23:44:33 CEST] <ultrav1olet> that makes me thinking, what if the x264 is the culprit
[23:44:44 CEST] <BtbN> try some other encoder
[23:44:45 CEST] <ultrav1olet> I must try another codec
[23:44:52 CEST] <JEEB> try utvideo for example
[23:45:01 CEST] <JEEB> supports both YCbCr and RGB
[23:45:06 CEST] <JEEB> into, say, avi
[23:45:10 CEST] <ultrav1olet> does MPEG2 have a lossless mode?
[23:45:14 CEST] <JEEB> no
[23:45:29 CEST] <JEEB> -c:v utvideo and check with mpv
[23:45:38 CEST] <JEEB> (least retarded opengl renderer around)
[23:46:21 CEST] <BtbN> might also be the player you used to look at the video
[23:46:29 CEST] <BtbN> x264 with -crf 0 should really not touch the picture at all
[23:47:03 CEST] <ultrav1olet> Stream #0:0: Video: utvideo (ULY0 / 0x30594C55), yuv420p - blurriness persists
[23:47:21 CEST] <JEEB> and ut video doesn't do any bullshit
[23:47:29 CEST] <ultrav1olet> the problem is with ffmpeg itself
[23:47:33 CEST] Action: JEEB wrote the encoder back in the day
[23:47:44 CEST] <ultrav1olet> and only when encoding videos and _not_ single images
[23:47:52 CEST] <JEEB> try with RGB and ut video :P
[23:48:03 CEST] <ultrav1olet> What's the command?
[23:48:18 CEST] <ultrav1olet> I suck at remembering ffmpeg's options
[23:48:36 CEST] <JEEB> "<zscale>,format=gbrp" should be enough I think
[23:48:45 CEST] <JEEB> zscale part being the zscale scaling
[23:49:00 CEST] <ultrav1olet> doesn't work as I said earlier
[23:49:13 CEST] <ultrav1olet> code 3074: no path between colorspaces
[23:49:14 CEST] <JEEB> that's because your input lacks colorspace information then
[23:49:18 CEST] <JEEB> set min as well
[23:49:25 CEST] <JEEB> to either bt709 or bt470bg
[23:49:29 CEST] <ultrav1olet> treat me as a stupid please
[23:49:30 CEST] <JEEB> according to your source's information
[23:49:33 CEST] <JEEB> ok
[23:49:35 CEST] <JEEB> zimg is anal
[23:49:43 CEST] <JEEB> if you don't have required data about what sort of YCbCr it is
[23:49:51 CEST] <JEEB> it will barf at you
[23:49:54 CEST] <ultrav1olet> actually the source is all yours: https://mega.nz/#!bp0jwCoJ!--QLIwVLvDnFfNWdVyYH6zkE0pUApN6tjhVNq0xylPc
[23:49:55 CEST] <JEEB> the one value it at the very least needs
[23:50:00 CEST] <JEEB> is min
[23:50:09 CEST] <JEEB> if it's from blu-ray or something set min=bt709
[23:50:11 CEST] <JEEB> :P
[23:50:27 CEST] <JEEB> which sets the input color matrix to BT.709
[23:51:28 CEST] <JEEB> FFmpeg's swscale is happy to do the guessing for you, while zimg is made to stop you from doing stuff you don't think you're doing
[23:52:16 CEST] <BtbN> ultrav1olet, https://btbn.de/public/scrn/1502229107.png
[23:52:42 CEST] <BtbN> this is generated with: ffmpeg.exe -i source.mkv -vf scale=768:-2 -c:v utvideo result.mkv
[23:53:05 CEST] <ultrav1olet> BtbN: yours looks exactly how it should be
[23:53:19 CEST] <JEEB> just out of interest, which player are you using for preview? :P
[23:54:02 CEST] <BtbN> ultrav1olet, https://btbn.de/public/scrn/1502229220.png this is what I get when using your resolutions
[23:54:04 CEST] <ultrav1olet> MPV
[23:54:04 CEST] <BtbN> same blur
[23:54:16 CEST] <ultrav1olet> sorry, mplayer
[23:54:22 CEST] <BtbN> you are just breaking aspect ratio, and the stretching is what causes the blurr
[23:54:44 CEST] <JEEB> mplayer is completely different, and yes - that's why I noted setsar
[23:54:51 CEST] <JEEB> if the aspect ratio compensation was causing it :P
[23:55:00 CEST] <ultrav1olet> both MPV and mplayer produce the same result here
[23:55:06 CEST] <JEEB> since when you code a picture most image formats don't have a way of coding that in
[23:55:12 CEST] <JEEB> while video formats have aspect ratio flags
[23:55:22 CEST] <JEEB> and your output resolution was 170/160 or so
[23:55:30 CEST] <ultrav1olet> BtbN: I used your command right now - the same blurriness
[23:55:30 CEST] <JEEB> so it asks the player to widen it a wee bit
[23:56:09 CEST] <ultrav1olet> BtbN: could you upload your result.mkv?
[23:56:33 CEST] <BtbN> of what?
[23:56:34 CEST] <BtbN> with -2?
[23:56:37 CEST] <ultrav1olet> yep
[23:56:51 CEST] <ultrav1olet> is the screenshot you've just posted is from it
[23:56:54 CEST] <ultrav1olet> if
[23:57:16 CEST] <JEEB> if you want to ignore input aspect ratio add ",setsar=1" at the end of your filter chain
[23:57:24 CEST] <ultrav1olet> I don't see how I'm stretching anything guys
[23:57:30 CEST] <JEEB> during playback
[23:57:37 CEST] <ultrav1olet> I'm watching the result as is without upscaling it
[23:57:38 CEST] <JEEB> I saw in your logs sar 170/160
[23:57:55 CEST] <JEEB> so the player should automagically scale according to aspect ratio
[23:57:57 CEST] <JEEB> which is a bit wider
[23:58:05 CEST] <BtbN> You're scaling to 768x342
[23:58:15 CEST] <BtbN> the correct downscale is 768x320 though
[23:58:18 CEST] <ultrav1olet> yeah: source:  Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x800 [SAR 1:1 DAR 12:5], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)
[23:58:22 CEST] <BtbN> if you want to keep aspect ratio
[23:58:24 CEST] <JEEB> that's the input
[23:58:29 CEST] <JEEB> https://pastebin.com/raw/Rus7VAWH
[23:58:31 CEST] <ultrav1olet> result: Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), yuv420p, 768x342 [SAR 171:160 DAR 12:5], q=-1--1, 23.98 fps, 1k tbn, 23.98 tbc (default)
[23:58:34 CEST] <JEEB> 768x342 [SAR 171:160 DAR 12:5]
[23:58:47 CEST] <JEEB> yes, so the players will apply aspect ratio fixing
[23:58:54 CEST] <ultrav1olet> so what am I doing wrong and how I can avoid this problem in the future?
[23:58:55 CEST] <BtbN> Just put -2 as one of the parts of the scale, and it will pick the correct one
[23:58:57 CEST] <JEEB> that explains why image formats were OK
[23:59:08 CEST] <JEEB> because those don't have a flag for SAR/DAR
[23:59:09 CEST] <JEEB> usually
[23:59:10 CEST] <ultrav1olet> -2 generates the same blurry file
[23:59:10 CEST] <JEEB> :P
[23:59:25 CEST] <BtbN> https://btbn.de/public/result.mkv
[23:59:32 CEST] <ultrav1olet> (ffmpeg -i source.mkv -vf scale=768:-2 -c:v utvideo result.mkv)
[23:59:45 CEST] <BtbN> That's the exact commandline I used to generate that
[23:59:49 CEST] <BtbN> no blur for me at all
[23:59:58 CEST] <JEEB> check the command line output
[00:00:00 CEST] --- Wed Aug  9 2017