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

[burek]

[04:27:40 CEST] <botik101> ok, guys, I have a major problem - I am using one ffmpeg statement to retrieve 100 frames and saves it to disk with filename%03d   ...how do I know which filename corresponds to whcih frame? and is there a better way>
[04:29:32 CEST] <Cracki> they're numbered sequentially?
[04:29:53 CEST] <Cracki> I don't see the problem
[04:44:42 CEST] <botik101> Cracki: I tried using %i and it is not working.....
[04:46:27 CEST] <botik101> why is it not adding numbers to the output filename here? %i shuld add the index of each time slot: ffmpeg_string is: ffmpeg -i /home/victor/Videos/FIFA/fox0-600.mp4 -filter:v "select='lt(prev_pts*TB\,250.710704)*gte(pts*TB\,250.710704) + 'lt(prev_pts*TB\,310.799771)*gte(pts*TB\,310.799771) + 'lt(prev_pts*TB\,235.889994)*gte(pts*TB\,235.889994)'" -frames:v 1 filename_%0000i.jpg
[04:47:23 CEST] <botik101> it has three timeframes to extract from, so I would expect three filenames each indlucing the timeoffset inside the name.
[04:52:09 CEST] <botik101> is there a way to add to the filenamethe  time-offset or the index of the frame that is being exported by ffmpeg? I can only get %d to work
[04:54:08 CEST] <furq_> botik101: -frames:v 1 is an output option, so it'll stop writing after one frame
[04:54:16 CEST] <furq_> but also you should just be able to add -frame_pts 1
[04:55:56 CEST] <furq_> i'm also not really sure why you're not doing select=t=250.710704 etc
[04:56:33 CEST] <botik101> furq: i am not doing it because i noticed that the frametime for some of the images are rounded off
[04:57:03 CEST] <botik101> furq_: so, this way I ensure that we get the right frame or the next closest frame to that timestamp
[04:57:10 CEST] <furq_> well yeah it's generally easier to work with frame numbers if you can
[04:58:00 CEST] <botik101> furq_: yeah, i wish this was the ccase... but how do you save the timeoffset or timestamp of the frame in the filename?
[04:58:07 CEST] <furq_> -frame_puts 1
[04:58:10 CEST] <furq_> -frame_pts 1
[04:58:25 CEST] <botik101> furq_: also, frame_pts 1 - i cant find a lot of information on it
[04:58:27 CEST] <furq_> https://www.ffmpeg.org/ffmpeg-formats.html#Options-6
[04:59:01 CEST] <furq_> iirc it just puts the pts in place of the sequence number
[04:59:35 CEST] <furq_> you can also mess around with the strftime stuff but i always found that to be needlessly complicated
[05:01:06 CEST] <botik101> furq_: hmmm.... ffmpeg -i /home/victor/Videos/FIFA/fox0-600.mp4 -filter:v "select='lt(prev_pts*TB\,250.710704)*gte(pts*TB\,250.710704) + 'lt(prev_pts*TB\,310.799771)*gte(pts*TB\,310.799771) + 'lt(prev_pts*TB\,235.889994)*gte(pts*TB\,235.889994)'" -frame_pts 1 filename_%di.jpg
[05:01:14 CEST] <botik101> not good
[05:02:31 CEST] <furq_> what's the problem
[05:02:47 CEST] <botik101> whole screen covered in red....
[05:03:57 CEST] <botik101> furq: this - ffmpeg -i /home/victor/Videos/FIFA/fox0-600.mp4 -filter:v "select='lt(prev_pts*TB\,250.710704)*gte(pts*TB\,250.710704) + 'lt(prev_pts*TB\,310.799771)*gte(pts*TB\,310.799771) + 'lt(prev_pts*TB\,235.889994)*gte(pts*TB\,235.889994)'" -frame_pts 1 filename_%d%i.jpg
[05:04:16 CEST] <botik101> results in this:
[05:04:18 CEST] <botik101> Unrecognized option 'frame_pts'. Error splitting the argument list: Option not found
[05:05:31 CEST] <botik101> oh god, do i need to recompile the whole ffmpeg
[05:06:23 CEST] <furq_> what ffmpeg version
[05:06:58 CEST] <furq_> https://www.johnvansickle.com/ffmpeg/
[05:07:04 CEST] <furq_> just use those if you're on an old ubuntu or something
[05:09:27 CEST] <botik101> furq: i am on ubuntu 16.04 ... hold on
[05:09:51 CEST] <botik101> ok, recompiled a different ffmpeg
[05:09:54 CEST] <botik101> ffmpeg.old -i /home/victor/Videos/FIFA/fox0-600.mp4 -filter:v "select='lt(prev_pts*TB\,250.710704)*gte(pts*TB\,250.710704) + 'lt(prev_pts*TB\,310.799771)*gte(pts*TB\,310.799771) + 'lt(prev_pts*TB\,235.889994)*gte(pts*TB\,235.889994)'" -frame_pts 1 filename_%d%i.jpg
[05:10:14 CEST] <botik101> this one is insanity:
[05:10:16 CEST] <botik101> image2 @ 0x28dd5c0] Cannot write filename by pts of the frames.av_interleaved_write_frame(): Invalid argument frame= 7082 fps=135 q=24.8 Lsize=N/A time=00:03:55.94 bitrate=N/A dup=7081 drop=0 speed=4.49x     video:417478kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown Conversion failed!
[05:13:32 CEST] <furq> remove %i from the filename
[05:19:46 CEST] <furq> also add -vsync vfr as an output option
[05:22:17 CEST] <botik101> furq - trying
[05:24:22 CEST] <botik101> furq - much better
[05:24:25 CEST] <botik101> filename_7081.jpg
[05:25:09 CEST] <botik101> but the values should be 250.710704
[05:25:32 CEST] <botik101> 7081 is the frame number right?
[05:25:44 CEST] <furq> it's the pts
[05:39:08 CEST] <botik101> furq:  I have only time_offset
[05:39:56 CEST] <botik101> I looked at ways to use pts to calculate time_offset but it is not realistic for 10000 frames
[05:40:53 CEST] <botik101> furq:  I have an array with time offset only in the system. I have access to file, but operation on it is very expensive, so I am trying to avoid unnecessary access
[05:43:17 CEST] <botik101> is there a way for ffmpeg to reutrn the list of filenames it has created?
[05:45:11 CEST] <furq> just divide the pts by the timebase shown by ffmpeg/ffprobe
[05:45:31 CEST] <botik101> I tried that - it drifts
[07:16:34 CEST] <botik101> it is the right way to get the timebase -  ffprobe -show_streams fox0-600.mp4  ? I am grepping time_base and I get 1/48000 and time_base=1/30015
[07:21:27 CEST] <furq> it should be under codec_time_base
[07:22:04 CEST] <furq> also add select_streams v:0 because those look like audio stream timebases to me
[07:22:10 CEST] <furq> 1/48000 is definitely the aac timebase
[07:22:24 CEST] <botik101> furq: yes i suspected as much
[07:23:08 CEST] <botik101> codec_time_base=300166/18019005 time_base=1/30015
[07:24:12 CEST] <botik101> furq:  do you rememebr i told you abotu the drift? well, here it is: the time offset is: 250.710704
[07:25:00 CEST] <botik101> furq:  the filename generated is filename_7081
[07:25:31 CEST] <botik101> 7081/30015 is 0.23591537564
[07:30:36 CEST] <botik101> furq - what I am missing here?
[07:38:12 CEST] <botik101> furq: so pts/time_base does not give me timeoffset
[07:44:00 CEST] <botik101> any ideas?
[09:45:59 CEST] <atbd> bahrom: "no more output stream", "EOF on sink link out"
[10:20:11 CEST] <keglevich> test
[10:22:10 CEST] <keglevich> hey all... I compiled ffmpeg 4.0 (latest trunk) with pthreads support. I used two parameters "--enable-pthreads" and "--disable-w32threads". Is this combination correct or should I maybe only use one of these parameters?
[10:22:51 CEST] <keglevich> Furthermore, I'm using the following command to produce perfect CBR UDP mpegts output:
[10:22:52 CEST] <keglevich> ffmpeg -re -i 1.mkv -c:v mpeg2video -r 25 -b:v 5000k -c:a mp2 -ac 2 -b:a 192k -ar 48000 -minrate 5000k -maxrate 5000k -bufsize 700k -pcr_period 30 -f mpegts -muxrate 5450k "udp://239.1.1.1:10000?pkt_size=1316&bitrate=5450000&burst_bits=100000&fifo_size=5450000"
[10:23:26 CEST] <keglevich> I know that "bitrate" and "muxrate" should be the same...that's fine... but what about "burst_bits" and "fifo_size"?
[10:23:32 CEST] <keglevich> which values should I use?
[10:24:13 CEST] <keglevich> there's practically no docs about these values anywhere...but they're crucial...without burst_bits and without fifo_size I get fatal errors
[10:27:04 CEST] <Nacht> Jeez, I've been trying for ages to get my text to rotate using an alpha channel, but it just didn't show up. Just downloaded the latest static, and now it works :/
[11:47:15 CEST] <keglevich> is there an option to get somehwere compiled ffmpeg shared .dll binaries with pthreads enabled (or in other words with w32threads disabled)?
[11:47:25 CEST] <keglevich> I'd need 4.0 32-bit binaries
[14:03:54 CEST] <keglevich> is it possible to compile official zeranoe ffmpeg 4.0 builds for windows somehow easily? I'd just like to recompile using one additional parameter (--disable-w32threads)
[14:31:34 CEST] <zap0> keglevich, does he not provide build scripts?
[14:32:00 CEST] <DHE> also, I read that question as "can I compile my own official 3rd party packages?"
[14:33:52 CEST] <keglevich> I downloaded the "dev" package for 4.0 as well from zeranoe, but I don't know what to do with it
[14:34:20 CEST] <keglevich> until now I just used mediawutobuild suite which does everything automatically...sets up the environment, mingw on windows, etc.
[14:35:15 CEST] <keglevich> but that one only compiles latest git versions, but now I'd like to recompile original zeranoe 4.0 w32 shared build, only with one additional paremeter so it will use pthreads instead of w32threads
[14:35:33 CEST] <keglevich> pthreads support I need for some specific UDP mpegts output parameters
[14:36:45 CEST] <keglevich> so I guess there's no third party packages envolved, just a different threading support
[16:21:38 CEST] <Case_Of> hi, how could i make ffmpeg copying audio from libcdio to different files for each tracks?
[16:26:55 CEST] <Cracki> ffmpeg can access the track info from libcdio: https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/libcdio.c
[16:27:16 CEST] <Cracki> it seems to translate that into chapter info
[16:27:27 CEST] <Cracki> so... you would want to "split a file by chapters"
[16:28:11 CEST] <Cracki> https://stackoverflow.com/questions/30305953/is-there-an-elegant-way-to-split-a-file-by-chapter-using-ffmpeg
[16:28:43 CEST] <Cracki> mkvmerge seems to do it
[16:29:11 CEST] <Cracki> another search result: https://gist.github.com/dcondrey/469e2850e7f88ac198e8c3ff111bda7c
[16:32:08 CEST] <atomnuker> Case_Of: you can use https://github.com/atomnuker/cyanrip
[16:32:08 CEST] <furq> Case_Of: use something better than ffmpeg for ripping cds
[16:32:27 CEST] <furq> eac on windows, xld on osx, https://github.com/JoeLametta/whipper/ on *nix
[16:33:36 CEST] <Case_Of> i was using libcdio-paranoia actually
[16:33:57 CEST] <Case_Of> i want something the most lossless
[16:36:10 CEST] <Case_Of> s/want/am looking for/
[16:37:24 CEST] <atomnuker> cyanrip then
[16:37:30 CEST] <Cracki> pcm wave or flac
[16:37:44 CEST] <Cracki> all these programs try their best to read every bit accurately
[16:38:20 CEST] <Cracki> and if your CD isn't scratched (much), you have a good chance of getting a bit-exact copy
[16:38:31 CEST] <furq> they also all check your disc against accuraterip
[16:38:35 CEST] <furq> and maybe ctdb if you're lucky
[16:39:12 CEST] <Cracki> also be aware that atomnuker promotes his own tool ;)
[16:39:57 CEST] <furq> whipper is supposedly The Best Thing right now on *nix
[16:40:22 CEST] <furq> but they're both using libcdio-paranoia so i doubt it'll make any difference which one you use
[16:40:48 CEST] <furq> just make sure not to get that confused with the old xiph cdparanoia which is less good
[16:41:08 CEST] <Case_Of> in flac
[16:43:53 CEST] <Case_Of> time to write ebuilds then
[16:46:10 CEST] <atomnuker> whipper is shit
[16:46:24 CEST] <atomnuker> needs shitstreamer and a ton of dependencies, and is written in python
[16:52:26 CEST] <furq> where does it say it needs gstreamer
[16:56:29 CEST] <atomnuker> well it does need it, it uses it to encode after all
[16:58:37 CEST] <Case_Of> i do not see where
[17:00:01 CEST] <Cracki> https://github.com/JoeLametta/whipper/blob/b5caf86cd2798f26f3503de2bcb4eb62e2791fd0/CHANGELOG.md#L119
[17:00:04 CEST] <Cracki> no more gst dep
[17:00:17 CEST] <Cracki> over a year ago
[17:01:10 CEST] <atomnuker> wow, its even worse
[17:01:22 CEST] <Case_Of> i do not understand why
[17:09:39 CEST] <atomnuker> its not a proper program, its a python script that glues together several loose pieces and hopes it works
[17:10:29 CEST] <atomnuker> cyanrip is a properly written program that will go to lengths to find the disc info so you don't have to fill anything in, properly encode the file with correct offsets, embed an image if you specify and give you a pretty log
[18:18:31 CEST] <Case_Of> atomnuker: the most important part is to make a perfect lossless rip
[18:20:25 CEST] <atomnuker> it does do a perfect lossless rips, that's the whole point
[18:33:32 CEST] <Case_Of> atomnuker: is there a version of cyanrip that works with ffmpeg 3?
[19:14:55 CEST] <keglevich> what would be the easiest way to re-compile original "Zeranoe ffmpeg 4.0 w32 shared" version? I'd need the exact same build, with only one extra parameter --disable-w32threads
[19:28:11 CEST] <BtbN> Why do you want to disable threads?
[19:37:01 CEST] <hrvoje> On Linux, you can do taskset -c 0 ffmpeg ... to limit execution on a single core, there might be a similar option under windows so you don't have to recompile
[19:37:19 CEST] <hrvoje> why dislike for threads?
[19:38:16 CEST] <hrvoje> limiting to a single core doesn't disable threads, but runs them all on the same cpu core which might be what you are after?
[19:44:13 CEST] <furq> he wants a build with pthreads instead
[19:44:19 CEST] <furq> for some specific reason i forget now
[19:44:50 CEST] <furq> 13:35:32 ( keglevich) pthreads support I need for some specific UDP mpegts output parameters
[19:45:03 CEST] <furq> anyway the easiest way would just be to copy the configure line from zeranoe when building it yourself
[19:45:04 CEST] <BtbN> Are pthreads even supported on windows anymore?
[19:45:07 CEST] <furq> there's no way of just patching that in
[19:45:43 CEST] <furq> BtbN: it works on win7 at least
[19:46:00 CEST] <BtbN> probably by just mapping them to w32threads
[19:46:09 CEST] <furq> i assume that's always how they've done it yeah
[19:46:37 CEST] <furq> keglevich: are you sure you need pthreads because i don't see that mentioned anywhere in the docs
[19:47:32 CEST] <DHE> the udp://....?bitrate=X feature requires pthreads specifically
[19:47:37 CEST] <DHE> for output
[19:47:39 CEST] <furq> oh fun
[19:47:57 CEST] <furq> that's not mentioned in the udp protocol docs or the mpegts muxer docs
[19:48:47 CEST] <keglevich> yeah...it's not mentioned anywhere...but the difference between using bitrate parameter and not using it is really BIG!
[19:49:05 CEST] <keglevich> with bitrate added, the output udp stream is perfect CBR, without that parameter so-so...
[19:49:41 CEST] <DHE> it's worse than that. if given, say, a 40kbyte AVPacket, the udp output driver will burst out ~30 packets as quickly as it can
[19:50:06 CEST] <DHE> I've seen major packet loss on networks when the sender has a gigabit port but the receiver has 100 meg ports even though the video bitrate is only 10 megabit
[19:50:24 CEST] <keglevich> that's something I spotted as well
[19:50:27 CEST] <DHE> typical switches have shitty small packet buffers unless you pay a lot of money for said switch
[19:51:02 CEST] <keglevich> but when I compiled the ffmpeg with --enable-pthreads and used bitrate, burst_bits, buffer_size parameters, the stream was actually perfect
[19:51:04 CEST] <DHE> iperf3 had this problem for a long time as well. its UDP throughput tester had the same problem. set a test bandwdith of 20 megabits, gigabit sender, 100megabit receiver, and watch the confusingly high packet loss
[19:51:48 CEST] <keglevich> so I'm just looking for he easies way to re-compile official zeranoe-ffmpeg-4.0-w32-shared with one single parameter added (--disable-w32threads)
[19:51:59 CEST] <keglevich> is there an easy option to do this?
[19:52:01 CEST] <furq> not really
[19:52:10 CEST] <furq> you really don't need half the crap zeranoe bundles though
[19:52:30 CEST] <furq> it's also not an official build
[19:52:48 CEST] <furq> it's just considered trustworthy enough to be linked on ffmpeg.org
[19:52:56 CEST] <keglevich> we're using it everywhere and it works ok..therefore I'd just like to use it and recompile it with this single parameter
[19:54:15 CEST] <furq> well last i checked he was charging for custom builds
[19:54:21 CEST] <furq> so obviously he's not sharing his build scripts
[19:54:50 CEST] <keglevich> huh...is there another (simple) option to just compile ffmpeg 4.0 with pthreads?
[19:55:03 CEST] <furq> didn't you already do that
[19:56:03 CEST] <keglevich> yes...I used "media autobuilt suite"... but that one only compiles the latest bleeding-edge packets into the build
[19:56:30 CEST] <keglevich> I'd like to use official 4.0 sources (if they even exist?) and compile it into production version
[19:57:03 CEST] <keglevich> I saw at zearone some "dev" packages, with lots of files inside...maybe they're build scripts? He also has some kind of 4.0 build scripts linked at his github
[19:57:09 CEST] <keglevich> I just don't know how to use them...
[19:57:33 CEST] <keglevich> https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=5036
[19:57:46 CEST] <keglevich> this is for 4.0 for instance...what can I do with it?
[19:58:13 CEST] <furq> that only runs on linux or cygwin
[19:58:19 CEST] <furq> so you'd need to run it in a VM or install cygwin
[19:58:32 CEST] <furq> i generally just cross-compile in a debian vm because it's less hassle than getting this shit working on windows
[19:58:32 CEST] <keglevich> I have ubuntu 16.04 up and running
[19:59:00 CEST] <keglevich> I ran that script there but it only made some folder and files inside...no ffmpeg versions
[19:59:12 CEST] <furq> do you have mingw-w64 installed
[19:59:52 CEST] <keglevich> yes...it installed that and compiled it I guess
[19:59:59 CEST] <keglevich> the script finished without any errors
[20:00:09 CEST] <hrvoje> keglevich: interesting observation, I've been trying for constant bitrate a while ago and gave up :) I'll try your suggestion and see how it goes
[20:00:19 CEST] <furq> oh it downloads all that for you
[20:00:20 CEST] <furq> weird
[20:00:37 CEST] <keglevich> hrvoje: believe me...it works...it's 100% straight line in each and every mpeg analyzer
[20:00:45 CEST] <keglevich> I also thought it can't be done
[20:01:21 CEST] <furq> oh lol
[20:01:26 CEST] <furq> ok so this script just builds mingw-w64
[20:01:35 CEST] <keglevich> probably
[20:01:39 CEST] <furq> i should've probably read it instead of assuming it built ffmpeg because it's on zeranoe's github
[20:02:10 CEST] <keglevich> ffmpeg -re -i 1.mkv -c:v mpeg2video -r 25 -b:v 5000k -c:a mp2 -ac 2 -b:a 192k -ar 48000 -minrate 5000k -maxrate 5000k -bufsize 700k -pcr_period 30 -f mpegts -muxrate 5450k "udp://239.1.1.1:10000?pkt_size=1316&bitrate=5450000&burst_bits=100000&fifo_size=5450000"
[20:02:42 CEST] <keglevich> use that line hrvoje...this one produces a perfect CBR udp mpegts stream...with ideal PCR (30ns) for hardware ts-muxers
[20:02:57 CEST] <keglevich> but you will need ffmpeg with pthreads support...and that's what I'm currently after
[20:03:47 CEST] <hrvoje> keglevich: I will try ... the best CBR I was able to do was using the Nvidia NVENC support, it works quite well, but nowhere near hardware FPGA based encoders (Harmonic, Appear TV ...)
[20:04:11 CEST] <keglevich> also...do note burst_bits and fifo_size are some random values I entered and they  seem to work ok...I don't know what these values should really be, there's no docs about them anywhere
[20:04:54 CEST] <keglevich> btw...maybe someone knows about these values (fifo_size, burst_bits)? I only know muxrate should be exactly the same as udp output bitrate
[20:05:34 CEST] <keglevich> hrvoje: I know...just try this, I also thought it can't be done...until yesterday when I compiled pthreads enabled version
[20:06:13 CEST] <keglevich> but as I said...compiling a simple 4.0 ffmpeg with pthreads enabled is a true project
[20:06:26 CEST] <keglevich> and I currently don't know how to do it
[20:07:09 CEST] <hrvoje> I sure will, thanks. For those options (burst_bits, fifo_size) source code holds the answer :)
[20:07:36 CEST] <keglevich> did you check it?
[20:07:59 CEST] <keglevich> I just know I received errors if burst_bits was too small...same goes for fifo_size
[20:09:29 CEST] <hrvoje> don't have the set-up to compile anything right now, but I will check it 100% because I spent way too much time trying to achieve a good, reliable constant bitrate
[20:09:34 CEST] <keglevich> DHE: and yes...you're right about ffmpeg's bad UDP output packet bursting...we changed around 7 switches...and ended with ubiquiti and mikrotik
[20:10:06 CEST] <DHE> keglevich: the bitrate thing is the true solution... that and QoS. :)
[20:11:03 CEST] <keglevich> yes it is, I'm aware of that now
[20:11:14 CEST] <keglevich> hrvoje: use this... https://we.tl/isiI7OQU1i
[20:11:44 CEST] <keglevich> hrvoje: it's bleeding-edge ffmpeg trunk with pthreads compiled for windows 32/64... use my command I pasted above...you'll be surprised
[20:12:38 CEST] <hrvoje> keglevich: but doing CBR only on transport stream and UDP transport level is not enough, the video payload also needs to have a fairly constant bitrate otherwise PTS/DTS variations would cause problems for the receiver
[20:12:40 CEST] <keglevich> DHE: do you maybe know about burst_bits and fifo_size suggested values?
[20:12:48 CEST] <hrvoje> at least from my experience
[20:13:30 CEST] <keglevich> hrvoje: that's why there's muxrate and pcr_period
[20:13:36 CEST] <keglevich> hrvoje: just test it...believe me
[20:15:13 CEST] <keglevich> I'm packing with muxrate of 5450k a video bitrate of 5000k + audio 192k and giving about 7% overhead...setting pcr to 30ns for DVB-t muxers...using same bitrate output as muxrate with UDP...the result is...perfect
[20:15:51 CEST] <keglevich> and this is something that's nowhere to be found on the net...nor documented anywhere...I just somehow ended with that result after LOTS of testing
[20:16:37 CEST] <DHE> keglevich: pkt_size and bitrate are all I ever set.
[20:17:07 CEST] <keglevich> DHE: I also tried only those two...but I received some errors (some fatal, some av_interleaved_frame...something)
[20:17:16 CEST] <keglevich> when I raised the values, the issues were gone
[20:20:19 CEST] <DHE> I can see the fifo size should be increased for high bitrate applications... plus I dunno what the default is
[20:20:41 CEST] <keglevich> yes, maybe the default value is too small...therefore overflows
[20:21:15 CEST] <keglevich> also there's no single line about burst_bits value anywhere...
[20:21:39 CEST] <keglevich> but I also had to set it at least to 100k, otherwise errors appeared as well
[20:22:30 CEST] <hrvoje> { "fifo_size",      "set the UDP receiving circular buffer size, expressed as a number of packets with size of 188 bytes",
[20:22:38 CEST] <hrvoje> { "burst_bits",     "Max length of bursts in bits (when using bitrate)", OFFSET(burst_bits)
[20:22:51 CEST] <hrvoje> source code always knows :)
[20:23:17 CEST] <keglevich> it seems so
[20:24:45 CEST] <keglevich> but it just seems no-one posted anything about these values anywhere until now, so I'm just guessing the values
[20:39:38 CEST] <hrvoje> keglevich: you work for a tv provider?
[20:40:16 CEST] <keglevich> kind of...we're streaming a few tv channels to some iptv providers
[20:41:48 CEST] <hrvoje> cool :)
[23:22:37 CEST] <chocolate-elvis> does anyone know more about the jp2k encode/decoding library in ffmpeg?
[00:00:00 CEST] --- Fri Aug  3 2018