Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

September 2017

1 participants
60 discussions

ffmpeg-devel.log.20170909
by burek 10 Sep '17

10 Sep '17

[01:05:24 CEST] <cone-256> ffmpeg 03James Almer 07master:27b7800ba907: avformat/matroskaenc: also write tags when output is WebM [01:43:10 CEST] <atomnuker> michaelni: could you remove all if (res_bits >= RSIZE_BITS) checking in dirac_vlc and instead change N ## _bits to 64 bits and AND it in append residue [01:43:41 CEST] <atomnuker> so its never larger than 64 bits [01:45:59 CEST] <atomnuker> that function must run very fast and I'm not sure what those extra jumps do for branch prediction [02:13:59 CEST] <michaelni> atomnuker, will check if that works once i figure out why building the fuzzer is really slow now [02:17:13 CEST] <atomnuker> ok, tnx [02:33:38 CEST] <cone-256> ffmpeg 03Steven Liu 07master:96d70694aea6: avformat/dashdec: add dash demuxer base version [02:34:27 CEST] <atomnuker> RiCON^^ [02:35:40 CEST] <cone-256> ffmpeg 03Steven Liu 07master:ab96e2ca81d7: avformat/dashdec: free resource allocated by xml [02:43:55 CEST] <jamrial> oh boy, libxml2 finally made it to ffmpeg [02:44:53 CEST] <atomnuker> its only an external library [02:45:58 CEST] <J_Darnley> I am saddened that nobody NIH their own. [02:46:02 CEST] <jamrial> i know, and i remember people fighting tooth and nail against implementing any xml library whatsoever [02:46:04 CEST] <J_Darnley> It is only xml [02:46:16 CEST] <J_Darnley> :) [02:47:22 CEST] <J_Darnley> Oh god! Why did the entire changelog of the patch get commited? [03:48:36 CEST] <michaelni> libavcodec/vp9.c:1631: undefined reference to `ff_slice_thread_execute_with_mainfunc' [03:51:53 CEST] <michaelni> thats with --disable-pthreads [03:53:57 CEST] <michaelni> need to go to bed otherwise id fix it [12:08:32 CEST] <cone-105> ffmpeg 03Petri Hintukainen 07master:7a6bd541528b: Add SUP/PGS subtitle muxer [12:32:13 CEST] <cone-105> ffmpeg 03Jun Zhao 07master:a918f16f7ccc: lavc/vaapi_encode_mpeg2: fix frame rate calc error when use time_base. [13:49:22 CEST] <rcombs> oh, a SUP muxer, nice [16:41:20 CEST] <jkqxz> Hmm. Apparently Odroid XU4 wasn't such a good choice to test V4L2 - it hard reboots under nontrivial load. (Pretty much instantly with libx264 on all threads, parallel make gets it after a while.) [17:12:37 CEST] <cone-129> ffmpeg 03Paul B Mahol 07master:4d41db7a31db: avfilter: add generic FFT video convolve filter [17:16:03 CEST] <RiCON> atomnuker: nice [17:24:22 CEST] <jamrial> jkqxz: temp related? [17:28:29 CEST] <jkqxz> Probably? (But unclear, because there is no feedback whatsoever.) [17:29:47 CEST] <atomnuker> michaelni: doesn't N ## _bits = (N ## _bits + (M ## _bits)) & 63 only limit to 63 dec? e.g. the lowest 6 bits? [17:29:48 CEST] <nevcairiel> if its heat, you might be able to help that [17:30:30 CEST] <jkqxz> It dies a bit too quickly and consistently for me to blame heat immediately. [17:31:18 CEST] <jkqxz> Like, doing H.264 -> libx264 with all default settings dies after ~five frames. [17:33:28 CEST] <jkqxz> Power draw is also a possibility, but I'm using their default 5V*4A supply, so it seems unlikely. [17:33:32 CEST] <michaelni> atomnuker, yes, i thought thats what you want me to do [17:35:25 CEST] <jkqxz> Just trying again with a cold boot after letting it cool down it managed 60 frames on that test before dying, and the heatsink is not yet warm. [17:36:01 CEST] <jkqxz> Maybe the heatsink isn't attached properly. [17:36:54 CEST] <atomnuker> michaelni: no, this limits golomb codes to 7 bits, it probably won't even pass fate, you need to limit it to the largest number such that no underfined behaviour will happen [17:37:40 CEST] <atomnuker> the max number of bits each APPEND_RESIDUE will append is 8 beucause the function reads bytes [17:39:34 CEST] <atomnuker> if you AND it with ((1 << 63) - 1) it should guarantee that the shift amount will never be larger than the type [17:40:21 CEST] <atomnuker> wait, nevermind everything [17:41:17 CEST] <atomnuker> michaelni: patch looks good to me, feel free to push [17:42:30 CEST] <jkqxz> Hmm, it seems ok for a while with the CPU speed manually turned right down with cpufreq. I thought that was meant to happen automatically, though. [17:45:17 CEST] <michaelni> atomnuker, you are confusing me ;) but ill push after quick retest [17:53:54 CEST] <atomnuker> michaelni: I got confused because I never think of using AND to limit to a decimal number [17:55:27 CEST] <atomnuker> in 99.9% of asm you use and as a bitmask and in dirac_vlc I only deal with raw bits [17:55:40 CEST] <BtbN> jkqxz, nothing surprises me on those boards anymore. Even the RPi has proven to be very unreliable to me [17:56:12 CEST] <BtbN> Like, the oney I still use all have a cronjob that reboots them every day. As they tend to hard-freeze if they are up for too long [17:56:22 CEST] <atomnuker> michaelni: if the 63 was in hex form I wouldn't have been confused, could you make it hex before you push it? [17:57:12 CEST] <jamrial> the odriod and similar boards were most likely mainly tested to make sure video playback worked fine using the gpu [17:57:15 CEST] <jamrial> i wouldn't find it odd if they never stress tested the cpu like you're doing [17:57:17 CEST] <BtbN> for a 64 bit number, the 63 seems more naturl to me than the same in hex? [18:01:39 CEST] <atomnuker> BtbN: 63 is 00111111, hex makes more sense to me when its limiting to a given number of bits [18:01:58 CEST] <BtbN> but it's 1 << 63 [18:02:17 CEST] <atomnuker> numbers only work when they're exactly a power of two - 1 [18:02:45 CEST] <BtbN> but that's what the (1 << x) - 1 is for? [18:03:07 CEST] <atomnuker> I don't get it, what are you referring to? [18:07:03 CEST] <michaelni> atomnuker, i can make it anything you want, just say how it should look [18:08:50 CEST] <atomnuker> just make it hex [18:10:04 CEST] <michaelni> ok [18:14:24 CEST] <jkqxz> I wasn't meaning to stress test the CPU. It just died instantly when I accidentally encoded with libx264 the first time. [18:15:09 CEST] <jkqxz> In comparison, the Rockchip I have has been fine. (It slows down quite a bit at load because it can't get rid of all the heat, but nothing ever dies.) [19:09:25 CEST] <cone-129> ffmpeg 03Michael Niedermayer 07master:d98d29a775d6: avcodec/dirac_vlc: limit res_bits in APPEND_RESIDUE() [22:49:41 CEST] <jkqxz> gh0st__: <https://www.phoronix.com/scan.php?page=news_item&px=FFmpeg-VP9-GSoC-Faster> [22:57:39 CEST] <gh0st__> jkqxz: Oh god, wut? I didn't expect this much attention. ) [22:59:22 CEST] <gh0st__> The main AVX2 optimizations are still to come, particularly the for loopfilter and the rest of the ipred functions that are left. [22:59:43 CEST] <nevcairiel> tile threading doesnt really make it faster for the majority of users, does it. most people are going to stick to frame threading, which from what I understand is still faster? [23:00:42 CEST] <JEEB> yea, frame threading generally tends to be faster in various formats. I had a similar experience with ut video which is why I think that didn't get merged in 2012 [23:00:48 CEST] <gh0st__> nevcairiel: More benchmarking is needed to state this fact for sure. [23:01:14 CEST] <gh0st__> But yes, from what I see frame threading is faster. [23:01:47 CEST] <nevcairiel> for hevc some people had the idea to combine both, tile and frame, so that the "expensive" I frames could be decoded faster and therefor increasing the scaling of frame threading as well [23:01:56 CEST] <nevcairiel> i wonder how horrible that would be in code [23:02:10 CEST] <JEEB> would have to have two pools of threads then I guess? [23:02:32 CEST] <iive> how is tile different from slice? [23:02:50 CEST] <nevcairiel> its the same thing, some codecs just call it tiles, some slices [23:03:05 CEST] <nevcairiel> tiles and slices might be organized differently [23:03:19 CEST] <nevcairiel> slices are typically full-width and limited height, while tiles are limited in both directions i believe [23:03:28 CEST] <jkqxz> And H.265 has both, of course. [23:03:36 CEST] <JEEB> yup [23:03:55 CEST] <jkqxz> Because why wouldn't you add more features? [23:04:24 CEST] <JEEB> the MPEG next-gen R&D guy at NHK was already talking about diminishing returns with regards to a lot of features [23:04:28 CEST] <JEEB> which is kind of telling [23:05:07 CEST] <nevcairiel> well, the main problem with those codecs is that there isnt a good way to determine if a feature really helps, other then trying it and seeing if its smaller [23:05:10 CEST] <jamrial> mpeg ng? [23:05:19 CEST] <nevcairiel> so costs increase exponentially w ith every feature, more or less [23:05:26 CEST] <iive> h267 [23:05:34 CEST] <JEEB> ugh, stop using the ITU-T names [23:05:39 CEST] <nevcairiel> isnt 266 next [23:05:41 CEST] <JEEB> because they're not given to the format until it's ready [23:05:42 CEST] <JEEB> and yes [23:05:57 CEST] <nevcairiel> noone uses mpeg names anymore [23:05:59 CEST] <JEEB> I mean, people were calling HEVC H.265 before it got the name officially [23:06:02 CEST] <iive> i like itu names [23:06:02 CEST] <jamrial> any tentative non itu name for it yet? [23:06:06 CEST] <iive> nevcairiel: because of mpeg4 [23:06:17 CEST] <nevcairiel> MPEG-H Part 8, who uses that [23:06:21 CEST] <nevcairiel> H.265 is much nicer =p [23:06:27 CEST] <JEEB> you mean part 2 [23:06:28 CEST] <nevcairiel> actually Part 2 [23:06:29 CEST] <nevcairiel> got confused [23:06:36 CEST] <JEEB> also HEVC is still valid, no? [23:06:39 CEST] <jamrial> HEVC is much nicer :p [23:06:54 CEST] <JEEB> it's not me disliking the ITU-T names, but just that they're not set yet. f.ex. ITU-T switched H.whatever to H.265 in like late 2013 officially [23:07:05 CEST] <JEEB> (it's of course obvious'ish what the next name will be but still) [23:07:11 CEST] <jkqxz> H.265 is much nicer, because the free specification you can download is called that. [23:07:58 CEST] <nevcairiel> indeed, ITU doesnt rip you off as much =p [23:08:08 CEST] <JEEB> yea [23:08:13 CEST] <nevcairiel> mpeg still tries to sell you the same spec [23:08:15 CEST] <jkqxz> (I wonder how many people have ever paid for ISO/IEC 23008-2.) [23:08:33 CEST] <iive> companies probably [23:09:45 CEST] <JEEB> yea that's really weird how ISO wants CHF 198 for effectively the same document [23:26:47 CEST] <kierank> bureaucrats will be bureaucrats [23:45:36 CEST] <BBB> nevcairiel: is fairly easy; horizontal synchronization already exists for the loopfilter, so if you do the signaling for the frame thread progress in the loopfilter thread, that would work [23:46:22 CEST] <BBB> nevcairiel: I dont think its useful since vp9 decoding is so ridiculously fast that only a calculator would need it for realtime decoding - anything else already does realtime vp9 decoding wiht a single threading type [23:53:46 CEST] <hanna> judging by https://www.youtube.com/watch?v=aT-oXygGf24 the minterpolate video filter produces some pretty convincing results; could anybody provide a brief description of the algorithm? [23:53:50 CEST] <hanna> would be interesting to try and implement it on the GPU [23:54:28 CEST] <hanna> seems like that was done using mode obmc, which does a block motion search? [23:55:11 CEST] <hanna> What's the bottleneck in this code? the block search or the actual pixel interpolation? [23:55:25 CEST] <JEEB> perf should able to tell I guess? [23:56:52 CEST] <durandal_1707> hanna: it have artifacts [23:57:07 CEST] <JEEB> yes, all such things have artifacts [23:59:32 CEST] <atomnuker> hanna: there's no SIM at all [23:59:37 CEST] <atomnuker> *SIMD [00:00:00 CEST] --- Sun Sep 10 2017

1 0

ffmpeg.log.20170909
by burek 10 Sep '17

10 Sep '17

[00:23:07 CEST] <m4t> hi, am am recording an h.264/pcm_mulaw stream to .mkv with -acodec flac -vcodec copy. i see a lot of '[matroska @ 0x568d23b820] Non-monotonous DTS in output stream 0:1;...' during recording. i tested alac instead of flac, and it doesn't do it at all. is that a limitation of flac (i guess when the framerate varies?) or is there something i can do to make it not give those warnings? [00:31:40 CEST] <m4t> hmm...actually. my testing may be flawed. it's not doing it with flac at the moment, either. :( [00:32:16 CEST] <m4t> wait..there it went :) heh. i need to run alac for longer to see if it's really not an issue there, though. [00:41:38 CEST] <m4t> ok. so i fired up 4 instances of ffmpeg recording flac, and another 5 recording alac. the flac ones were outputting the 'Non-monotonous DTS in output stream' frequently (once every few seconds?) but the alac ones are silent. it looked like i was able to trigger it by turning the infrared on/off on the camera, which changes the framerate from 15/10fps, respectively. the messages seemed to stop when i turned [00:41:40 CEST] <m4t> off the lights back off, and thus the camera exited infrared mode. [03:23:28 CEST] <redrabbit> well. all i needed was -qp 21 -maxrate 4500k [03:25:58 CEST] <redrabbit> well, i guess i need vbr for maxrate [04:12:04 CEST] <lunaaa> Hi :) [04:12:41 CEST] <lunaaa> I'm getting this error trying to run ffmpeg -i infile.mkv -codec copy outfile.mp4 and with -acodec copy -vcodec copy instead [04:12:43 CEST] <lunaaa> Unrecognized option 'acodec copy'. [04:13:00 CEST] <lunaaa> What's causing that? Ubuntu 16.04.3 [04:13:07 CEST] <lunaaa> is there a package i'm missing, or...? [04:23:27 CEST] <lunaaa> i'm using it programatically from golang [04:23:38 CEST] <lunaaa> i think it's to do with how the arguments are passed to ffmpeg [04:40:01 CEST] <Diag> For everyone on the suncoast (like me) http://tyronesbeefarm.com/images/2017231739.jpg\ [04:40:10 CEST] <Diag> well i screwed that up [04:40:12 CEST] <Diag> http://tyronesbeefarm.com/images/2017231739.jpg [04:40:18 CEST] <Diag> ignore the extra slash :( [04:46:13 CEST] <commande`> i'm using an older version of ffmpeg and I'm trying to encode with aac codec but I get an error about it being experimental. i suspect this is something that maybe could be set with AVOptions, with strict or experimental flags. i'm not exactly sure where to start. any pointers? [04:47:17 CEST] <Diag> commande`: is there any specific reason youre using old ffmpeg? [04:48:16 CEST] <commande`> i'm using humble-video and it uses older ffmpeg [04:49:05 CEST] <commande`> from what i've read the newer versions of ffmpeg dont mark aac as experimental [04:51:43 CEST] <redrabbit> allright... -c:v h264_nvenc -b:v 4000k -maxrate 4500k -rc vbr_2pass -rc-lookahead 32 [04:51:52 CEST] <redrabbit> this is the best so far [04:52:19 CEST] <redrabbit> image is crisp, it doesnt go above 4.8M [04:56:36 CEST] <redrabbit> seems like maxrate has no effect though [04:59:13 CEST] <commande`> nevermind. i ended up getting it to work [04:59:33 CEST] <commande`> i was trying to set flag on muxer and i should've been doing it to encoder [05:14:52 CEST] <redrabbit> in fact maxrate works [05:15:05 CEST] <redrabbit> wew. took me a while to get it right [06:24:46 CEST] <kepstin> lunaaa: I assume the api you're using takes a list of strings? It has to be "-acodec", "copy" not "-acodec copy" [06:25:26 CEST] <lunaaa> i'm not using an API, i'm executing the shell command programatically [06:25:29 CEST] <lunaaa> and yes it does [06:25:32 CEST] <lunaaa> and i was using that [06:26:25 CEST] <lunaaa> for some reason "-i infile", "-i", "infile", "-codec", "copy", "outfile" works but not with only "-i", "infile", "-codec", "copy", "outfile" [06:26:31 CEST] <lunaaa> that's what i'm using at present [06:26:37 CEST] <lunaaa> (first one) [06:27:11 CEST] <lunaaa> https://www.irccloud.com/pastebin/ypNNoFoZ/ [06:32:26 CEST] <kepstin> line 12 you have a + which should be a , [06:32:57 CEST] <kepstin> (and remove the space after the -i) [08:06:54 CEST] <thebombzen> I have some video that was de-interlaced rather than inverse telecined (I believe) so it's got two problems: it's 30 fps but every 5th frame is duplicated, and also there's deint artifacts (whoever deinterlaced it probably did a poor job) [08:07:43 CEST] <thebombzen> I can fix the first problem with -vf decimate=5,dejudder=4, but I'm not sure what to do about the second one. I'm considering interlacing it to get it back to where it was, and then applying inverse telecine properly. [08:08:33 CEST] <thebombzen> this is what I mean by de-interlacing artifacts: https://0x0.st/R5r.png [08:31:35 CEST] <furq> thebombzen: qtgmc does a decent job of repairing deinterlacing artifacts [08:31:59 CEST] <furq> those look particularly bad though [08:33:11 CEST] <furq> that sort of looks like the artifacts were present when this was upscaled [10:33:42 CEST] <thebombzen_> furq: I'm going to find a new source on this :P [10:33:49 CEST] <thebombzen_> so apparently it's also crazy Unsharped [10:35:19 CEST] <thebombzen_> look at this stupid unsharp masking http://0x0.st/R5w.png [10:35:43 CEST] <thebombzen_> this is what happens when you let normies encode video [10:53:52 CEST] <furq> lol [10:53:55 CEST] <furq> what's the source of tht [15:05:32 CEST] <Cracki> that's not so bad... [15:07:39 CEST] <Cracki> at least the height isn't a prime number [15:53:39 CEST] <Commander_Cody> How do you generate thumbnails for videos? I tried `ffmpeg -i inputfile -vf 'select=gt(scene,0.25)' -vsync vfr -vframes 20 inputfile_thumbnail_%02.png` [15:54:06 CEST] <Commander_Cody> The results are not as spectacular as I'd like. [15:58:12 CEST] <BtbN> by using the thumbnail filter [15:58:51 CEST] <BtbN> and no idea what spectacular things you expect to happen? [16:14:15 CEST] <Commander_Cody> BtbN: That thumbnails filter produces better results. Thanks for the tip. [17:20:27 CEST] <SITM> hi! [17:20:39 CEST] <SITM> I think I discovered a bug -- the glob matching appears broken: ffmpeg -r 30 -pattern_type glob -i "goes-16_*_rgbhybrid_conus.gif" test.mp4 [17:21:36 CEST] <relaxed> SITM: did you try without the quotes? [17:21:50 CEST] <SITM> let me try that [17:22:09 CEST] <relaxed> that should be -framerate 30, not -r 30 [17:22:11 CEST] <SITM> I just get "Option pattern_type not found." error [17:22:45 CEST] <SITM> I changed it to framerate and still get that error [17:23:14 CEST] <relaxed> try glob_sequence [17:24:20 CEST] <SITM> "Option pattern_type not found." [17:25:08 CEST] <relaxed> ffmpeg -f image2 -framerate 30 -pattern_type glob -i goes-16_*_rgbhybrid_conus.gif test.mp4 [17:25:15 CEST] <SITM> maybe my version of ffmpeg is older [17:25:18 CEST] <SITM> let me try yours [17:25:35 CEST] <DHE> no you'll need quotes of some kind. ffmpeg needs to see the star [17:25:52 CEST] <relaxed> oh right, the shell will expand the * [17:25:59 CEST] <DHE> does .gif work? since a gif isn't necessarily a frame but can be a short video [17:26:24 CEST] <SITM> getting closer -- [image2 @ 0x75b420] Could not find codec parameters for stream 0 (Video: none, none): unknown codec [17:26:24 CEST] <SITM> Consider increasing the value for the 'analyzeduration' and 'probesize' options [17:26:24 CEST] <SITM> goes-16_*_rgbhybrid_conus.gif: could not find codec parameters [17:26:25 CEST] <relaxed> it may be using the gif demxuer [17:26:41 CEST] <relaxed> SITM: quote the input [17:26:55 CEST] <SITM> I did put quotes around the input gifs part [17:26:58 CEST] <relaxed> pastebin.com the command and all console output [17:27:11 CEST] <SITM> ok [17:27:58 CEST] <relaxed> are these animated gifs? [17:28:04 CEST] <SITM> https://pastebin.com/2Rktw8Cu [17:28:13 CEST] <SITM> they are single frame gifs [17:29:04 CEST] <SITM> is it complaining that it doesn't have the codecs to create an mp4? [17:32:31 CEST] <DHE> I don't think the image2 demuxer supports GIF files. can you convert them to other formats? [17:32:52 CEST] <relaxed> for i in *gif; do ffmpeg -i "$i" "${i%.*}".png; done [17:32:55 CEST] <DHE> honestly gif is a poor choice. it's limited to 256 colours. use [almost] anything else. PNG is preferred [17:33:38 CEST] <SITM> I put -c:v gif after image2 and it seems to be working now [17:34:00 CEST] <SITM> let me see if we have pngs [17:35:33 CEST] <SITM> it only used the first gif for the mp4 -- lol [17:35:46 CEST] <SITM> thanks relaxed I'll try that [17:37:09 CEST] <relaxed> your ffmpeg version is pretty old. https://www.johnvansickle.com/ffmpeg/ [17:37:09 CEST] <SITM> we have jpgs and this works perfectly: ffmpeg -f image2 -framerate 30 -pattern_type glob -i "goes-16_*_rgbhybrid_conus.jpg" test3.mp4 [17:37:20 CEST] <SITM> yeah, I'll upgrade it [18:02:25 CEST] <_Vi> How do I specify finishing position instead of length in `-t`? `-to` seems to be no that. I can't even insert formula into `-t`'s argument. [18:02:54 CEST] <_Vi> How do I snip fragment from XX:XX:XX to YY:YY:YY without manually calculating length from XX:XX to YY:YY? [18:30:54 CEST] <c_14> _Vi: you write a script that calculates it for you [18:33:44 CEST] <_Vi> Would a patch to make `-to` also work for input files (for convenience) welcome? [18:34:05 CEST] <c_14> probably [18:34:39 CEST] <c_14> Only reason nobody's done it yet is probably laziness [23:22:56 CEST] <SavinaRoja> per https://trac.ffmpeg.org/wiki/Map#Example4 , I would think that I could choose to re-encode only one video stream by using "-c:v:N ..." as opposed to "-c:v ...". but instead I am gettting output that drops the additional video streams [23:25:08 CEST] <jkqxz> I think you need to explicitly copy the others, or it will think you just want that one video stream. [23:26:24 CEST] <SavinaRoja> jkqxz: I will try listing them explicitly and report back [23:51:42 CEST] <SavinaRoja> jkqxz: listed them explicitly, but also learned that you have to go from general to specific with codec opts [00:00:00 CEST] --- Sun Sep 10 2017

1 0

ffmpeg-devel.log.20170908
by burek 09 Sep '17

09 Sep '17

[00:05:00 CEST] <J_Darnley> WTF! [00:07:09 CEST] <BBB> poor J_Darnley... [00:07:15 CEST] <BBB> are you trying to udnerstand MpegEncContext? [00:07:25 CEST] <BBB> its a rabbit hole! beware [00:08:44 CEST] <J_Darnley> Heh. Might be better than dirac. [00:09:10 CEST] <J_Darnley> Well atleast that *is* identical now. [00:19:31 CEST] <atomnuker> jkqxz: one thing I don't get is why a wrapped avframe codec is needed? [00:19:57 CEST] <atomnuker> is lavd only able to output packets? [00:20:04 CEST] <nevcairiel> its basically a demuxer [00:20:05 CEST] <nevcairiel> so yes [00:20:06 CEST] <jkqxz> Yes. lavd is lavf. [00:20:37 CEST] <nevcairiel> didnt we also have this concept of raw packets [00:22:31 CEST] <nevcairiel> maybe that was only supported for muxing [00:24:17 CEST] <kierank> it's basically a hack to avoid memcpy [00:24:25 CEST] <kierank> and shuffle between avformat and avcodec [00:25:19 CEST] <atomnuker> what's going to be the pix_fmt of the decoded avframe? [00:25:38 CEST] <atomnuker> AV_PIX_FMT_DRM_PRIME? [00:26:14 CEST] <jkqxz> It's representing a DRM object in GPU memory. See the first patch. [00:26:20 CEST] <atomnuker> (so you'd have to hwdownload it if you wanted to feed it into a cpu encoder?) [00:26:21 CEST] <jkqxz> (This is why it can't use rawvideo at all.) [00:26:28 CEST] <jkqxz> Yes, you would. [00:26:31 CEST] <atomnuker> cool [00:26:54 CEST] <jkqxz> (And this might be hard if it's tiled somehow.) [00:43:25 CEST] <wm4> why am I getting compilation errors in simple_idct.c [00:43:46 CEST] <wm4> int vs. ptrsdiff_t [00:44:26 CEST] <wm4> oh, this file was removed and was somehow stale in my checkout? then why is it compiled [00:44:57 CEST] <nevcairiel> simple_idct.c still exists in libavcodec/, just not in libavcodec/x86/ [00:45:10 CEST] <wm4> this was the x86 one [00:45:38 CEST] <nevcairiel> the makefile just references a .o file, maybe it got confused what source to use [00:46:39 CEST] <kierank> i had the same problem [00:46:56 CEST] <nevcairiel> how do you even end up with a stale .c file, git should just delete it when you update [00:48:43 CEST] <kierank> it was the .d file [00:49:40 CEST] <nevcairiel> thats a different problem then =p [02:52:26 CEST] <jamrial> jkqxz: check my fix for ticket 6644. your coded bitstream api is also unable to parse this weird/broken VUI syntax where default_display_window is not present at all [09:06:10 CEST] <cone-460> ffmpeg 03Tobias Rapp 07master:d47159a42d8a: fate: add test for asetnsamples filter with padding disabled [10:35:15 CEST] <cone-460> ffmpeg 03Nicolas George 07master:f5a9c63401c8: lavfi: guess a timestamp for compat status change. [10:35:16 CEST] <cone-460> ffmpeg 03Nicolas George 07master:dfed8e2cbb48: ffmpeg: rename a variable. [10:35:16 CEST] <cone-460> ffmpeg 03Nicolas George 07master:36c111c40f4b: ffmpeg: use reordered duration for stream PTS. [10:35:17 CEST] <cone-460> ffmpeg 03Nicolas George 07master:5ba2aef6ec47: lavfi/buffersrc: add av_buffersrc_close(). [10:35:18 CEST] <cone-460> ffmpeg 03Nicolas George 07master:8043d8eb3bf5: ffmpeg: send EOF pts to filters. [11:23:31 CEST] <durandal_1707> wm4: will you apply sup muxer?? [13:16:25 CEST] <ubitux> so& should i push the perf patchset? [13:46:05 CEST] <BBB> ubitux: I think so, if you like it [13:51:08 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:2e79813a8ec7: avcodec/mips: Improve vp9 lpf msa functions [13:51:09 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:c75b23cbea79: avcodec/mips: Improve vp9 idct msa functions [13:51:10 CEST] <cone-058> ffmpeg 03Kaustubh Raste 07master:9b2c3c406fdd: avcodec/mips: Improve vp9 mc msa functions [13:51:11 CEST] <cone-058> ffmpeg 03Mark Wachsler 07master:fde5c7dc79eb: libavcodec/h264_parse: don't use uninitialized value when chroma_format_idc==0 [14:10:15 CEST] <kierank> BBB: ubitux: do you have any comments on the number differences? [14:10:18 CEST] <kierank> i.e which one is right? [14:11:08 CEST] <BBB> number difference? [14:11:15 CEST] <BBB> sorry, need context [14:28:49 CEST] <ubitux> kierank: the kernel perf api has an overhead due to i guess various function calls internally [14:29:22 CEST] <ubitux> whether our heuristics are better than the one in the kernel, i can't say [14:29:31 CEST] <kierank> BBB: difference between the old measurement and the perf one [14:29:50 CEST] <BBB> oh, dont ask me, I dont know :-p [14:30:07 CEST] <wbs> well as long as direct inlined instruction measurement is noiseless (no scheduler interruptions etc) that's obviously always better and correct [14:30:12 CEST] <ubitux> someone should probably make a graph of the two so we can see if they are at least proportionnal, or if it's a relatively constant overhead, etc [14:31:02 CEST] <wbs> ubitux: I thought about implementing the same, but you beat me to it - in general I guess it makes sense on arm, although the previous one that requires kernel enabling always should be preferred if usable [14:31:40 CEST] <wbs> I guess the main question is if the perf based one is noiseless enough to be usable for benchmarking/tuning of asm implementations [14:31:46 CEST] <wbs> and I think it is [14:32:03 CEST] <ubitux> current politic is to only weakly enable it on arm and aarch64 [14:32:40 CEST] <ubitux> the perf results are actually passed through the same ffmpeg heuristics [14:32:48 CEST] <ubitux> maybe that should be avoided? [14:32:55 CEST] <wbs> I don't think it matters [14:33:03 CEST] <ubitux> i'm assuming it helps for the first cold runs [14:33:12 CEST] <wbs> possibly yeah [14:33:19 CEST] <ubitux> with checkasm it also helps removing the "nop" cost [14:34:31 CEST] <ubitux> atomnuker suggested to use another PERF_COUNT_HW [14:34:34 CEST] <ubitux> i don't remember which [15:58:42 CEST] <BBB> ubitux: do you need further testing for your patchset? or is it waiting on something to be applied other than formal review? [15:59:16 CEST] <ubitux> which one? perf? [15:59:23 CEST] <ubitux> i don't mind further testing [15:59:26 CEST] <BBB> autodetect [15:59:31 CEST] <BBB> or, rather, disable-autodetect [15:59:42 CEST] <BBB> sorry, that was confusing [15:59:46 CEST] <ubitux> ah, well, i tested it, but that might not cover all the cases [16:00:00 CEST] <ubitux> disable-autodetect is upstream [16:00:09 CEST] <ubitux> what's left is the apple things [16:00:11 CEST] <BBB> yes [16:00:19 CEST] <ubitux> it tested with --disable-autodetect --enable-xxx individually and it worked [16:00:31 CEST] <ubitux> now i don't know, maybe it doesn't work with old osx, or even cross compile [16:00:34 CEST] <ubitux> i didn't test those [16:26:44 CEST] <cone-058> ffmpeg 03Ilia Valiakhmetov 07master:83c12fefd22f: avcodec/pthread_slice: add ff_slice_thread_execute_with_mainfunc() [16:26:45 CEST] <cone-058> ffmpeg 03Ilia Valiakhmetov 07master:e59da0f7ff12: avcodec/vp9: Add tile threading support [17:25:58 CEST] <gh0st__> Should I update the libavcodec/version.h for vp9 tile threading feature? [17:27:47 CEST] <gh0st__> And in general how libavcodec/version.h is updated? What criteria should be met for it to be updated? [17:29:34 CEST] <jamrial> gh0st__: version is updated usually if api or anything facing the user is affected. new/removed modules bump minor, new/removed options bump micro, etc [17:30:05 CEST] <jamrial> gh0st__: i don't think this requires a version bump, but it could use a changelog entry [17:30:43 CEST] <gh0st__> jamrial: ok, thanks for explanation. [17:39:09 CEST] <BBB> slice-threading is auser-facing feature [17:39:15 CEST] <BBB> I think micro bump might be ok [17:44:29 CEST] <BBB> gh0st__: your commit message is strange - youre adding a note to changelog about adding tile threading, not actually adding tile threading ;) [17:44:43 CEST] <BBB> changelog: mention vp9 tile threading feature [17:44:45 CEST] <BBB> (or so) [17:46:50 CEST] <jkqxz> jamrial: Did you try it and something actually goes wrong? It correctly says that the bitstream is invalid for me. [17:47:06 CEST] <gh0st__> BBB: Your right, duh. =) [17:48:12 CEST] <gh0st__> BBB: I'll be careful next time. [17:48:15 CEST] <jkqxz> (More generally, I'm against adding absurd hacks to parse consistently broken bitstreams - it's just wrong, say so and discard it. [17:48:19 CEST] <jkqxz> But I think I'm in a minority on that one, and I don't want to start a fight on the ML.) [17:48:19 CEST] <jamrial> jkqxz: it gets values all wrong and aborts as it tries to read vui display window information from bits that are from vui timing information [17:48:48 CEST] <jamrial> jkqxz: just pointing it out. the decoder needs to handle these since they are real world samples [17:48:54 CEST] <jkqxz> Ah, the one from the ML is still lacking overread detection. [17:48:58 CEST] <jamrial> but you're not forced to support them in your reader api [17:49:00 CEST] <jkqxz> That exists in newer versions. [17:50:19 CEST] <jkqxz> (Ends on "[AVBSFContext @ 0x277a9a0] Invalid ue-golomb code at max_bytes_per_pic_denom: bitstream ended.".) [17:51:10 CEST] <jamrial> with trace_headers bsf i get "max_bytes_per_pic_denom out of range: 1023, but must be in [0,16]." [17:51:40 CEST] <jamrial> but yeah, that's because the entire display window stuff is missing, so your reader is looking at the wrong stuff [17:51:42 CEST] <jkqxz> Yeah, it'll be reading over the end of the stream with that version. [17:52:08 CEST] <jamrial> i wonder what encoder is writing these files with truncated sps... [17:52:11 CEST] <jkqxz> There is some stuff pending in libav and once that is crystallised I'll re-merge and send it again. [17:53:03 CEST] <jkqxz> Do we know of any other decoders containing crazy hacks to handle these files? [17:53:29 CEST] <jamrial> not that i'm aware. i tried a hevc bitstream browser and it handled it much like your cbs reader [17:54:27 CEST] <jamrial> but since the file is fully playable if you workaround the missing bits, the best option is to try to parse them right, at least for the decoder [17:56:41 CEST] <jkqxz> I guess whoever made that encoder must have only tested with decoders which just stop at vui_parameters_present_flag, since nothing after that point is actually necessary for normal decode. [17:58:33 CEST] <jamrial> it is for raw bitstreams, since you wouldn't be able to get framerate without reading the vui timing information part [17:58:43 CEST] <jamrial> afaik [17:59:34 CEST] <jkqxz> Framerate sounds unnecessary for decoding... [17:59:52 CEST] <jamrial> playback then [18:01:27 CEST] <ubitux> michaelni: any other comment on the perf patchset? [18:06:12 CEST] <BBB> jamrial: the vps also contains timing info [18:08:08 CEST] <jkqxz> It doesn't in the sample file for this problem. [18:08:26 CEST] <jamrial> BBB: at least with sample (or rather, the raw bitstream extracted out of the matroska container), before my patch, were sps vui timing info is not parsed, libavcodec reports a generic 25fps. with my patch it reads the timing information and gets the correct 29.97 [18:08:59 CEST] <BBB> sps vui timing info != vps timing info [18:09:03 CEST] <BBB> it contains the same information [18:09:08 CEST] <BBB> but its not the same bits in the bitstream [18:09:15 CEST] <BBB> whether the file contains it is indeed a different matter ;) [18:09:33 CEST] <jamrial> s/least with/least with this/ [18:10:17 CEST] <jamrial> that's the thing, vps timing info is evidently not present in this file :p [18:10:24 CEST] <jkqxz> <http://sprunge.us/HddR>, vps_timing_info_present_flag = 0. [18:10:44 CEST] <BBB> I was commenting more generally about you wouldnt be able to get framerate w/o reading the vui timing [18:10:52 CEST] <BBB> you can, if the file contains vps timing ;) [18:11:09 CEST] <BBB> anyway, youre right, this file doesnt contain it so not ueful for this conversation [18:11:23 CEST] <jamrial> ah, true [18:11:55 CEST] <doublya> I'm trying to encore a video with a gt 1030 with hevc_nvenc. nvenc_open_session(avctx) on line 381 of nvenc.c is failing. "unsupported device (2)" [18:12:15 CEST] <BtbN> a 1030 does not have a hardware encoding unit. [18:12:38 CEST] <BtbN> also not a question for this channel. [18:14:59 CEST] <michaelni> ubitux, no more comments from me about perf, i seems to build fine on all i tested [18:15:25 CEST] <ubitux> alright, thanks [18:15:33 CEST] <ubitux> i'll push it then [18:15:45 CEST] <ubitux> i'll push the configure OSX stuff too pretty soon [18:15:51 CEST] <ubitux> unless someone wants to review it [18:16:56 CEST] <doublya> Thanks. Well I asked here because I was under the impression it did have an encoding unit. I was debugging the src to see why it was failing. Thanks. [18:30:55 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:cf0eed2525bd: avfilter: add Haas stereo enhancer [18:42:38 CEST] <kurosu> regarding the hevc vui stuff, when looking why it would look like this, I wound up on a development version of hevc, ie non-standard but pretty much like those many mpeg4 part2 bastardized implementations that each needs its own quirks [18:43:25 CEST] <kurosu> hard to identify, except "that didn't look right", which is what's being done/about to be done [18:47:13 CEST] <jamrial> maybe we should abort on these files if err_detect is set to compliant, for that matter [18:52:54 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:e0d56f097f42: checkasm: use perf API on Linux ARM* [18:52:55 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:9c0d823a7c2c: lavu/timer.h: factor out timer report [18:52:56 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:dc27df47ff99: lavu/tests/des: rename crypt to crypt_ref [18:52:57 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:e0b9b3e60ea3: lavu/tests: move timer.h include earlier [18:52:58 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:f61379cbd45a: lavu/timer.h: add Linux Perf API support [18:56:23 CEST] <atomnuker> ubitux: should have used PERF_COUNT_HW_REF_CPU_CYCLES [18:57:06 CEST] <ubitux> isn't 3.3 a bit too recent? [18:57:19 CEST] <ubitux> do you observe a difference in results? [18:57:33 CEST] <atomnuker> good point, didn't notice [18:57:45 CEST] <atomnuker> nope, didn't have time to benchmark [18:59:36 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:b476e7720c06: build: fix objcc header check [18:59:37 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:f8519529cfed: lavfi/coreimage: reduce dependency scope from QuartzCore to CoreImage [18:59:38 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:b6dce64a8ea5: build: add check_apple_framework() [18:59:39 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:97d8013582f5: build: add --disable-avfoundation autodetect switch [18:59:40 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:496d0178b0ed: build: add --disable-coreimage autodetect switch [18:59:41 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:1cf23e3fddd1: build: cleanup audiotoolbox handling [18:59:42 CEST] <cone-058> ffmpeg 03Clément BSsch 07master:260ea7a7b395: build: cleanup videotoolbox [19:02:22 CEST] <kurosu> jamrial, dunno, I guess the user-friendliness of mpeg4p2 quirk handling must be continued - if that's at least frequent, it's not unwarranted [19:03:25 CEST] <kurosu> pinged j-b about vdd, but he probably has bigger fish to fry [19:03:50 CEST] <kurosu> would anyone in here know whom I could ask for more details ? [19:03:54 CEST] <kierank> jamrial: [19:03:57 CEST] <kierank> j-b: ^ [19:03:58 CEST] <kierank> sorry [19:05:00 CEST] <kurosu> I queried/private messaged him already a day ago, don't want to bother him further [19:05:06 CEST] <BBB> kurosu: what do you want to know? [19:05:12 CEST] <BBB> kurosu: you can ask felix [19:06:03 CEST] <kurosu> will probably need housing accommodations and wanted to know who would be my "hostelmate" [19:06:10 CEST] <kurosu> also a more precise location [19:07:02 CEST] <kierank> I wonder when "who can't share with whom" will become NP hard [19:07:53 CEST] <kurosu> I know nobody enough to have any preference or for someone to have such a preference [19:08:28 CEST] <kurosu> ok, the location was added since 2 days ago, it seems [19:10:32 CEST] <atomnuker> I'm just wondering if thursday night is sponsored too [19:10:42 CEST] <atomnuker> j-b said it probably would be but that was over a month ago [19:11:23 CEST] <kurosu> I'd be arriving on friday afternoon at best [19:11:56 CEST] <kurosu> but that's likely an interesting thing for a lot of (more regular) attendees [21:42:48 CEST] <durandal_1707> Compnn: did you knew that you can have opengl display in console? [21:46:45 CEST] <atomnuker> durandal_1707: that's how wayland compositors work, lol [21:51:34 CEST] <Compnn> durandal_1707 : egl or the other gl i'm forgetting about ? [21:51:42 CEST] <Compnn> cant remember the name [21:51:48 CEST] <Compnn> mesagl ... no, another one [21:51:56 CEST] <durandal_1707> atomnuker: i have ffmpeg displaying stars in console, it can be screensaver [21:52:49 CEST] <durandal_1707> Compnn: backend of some sort [21:55:32 CEST] <jkqxz> Does SDL have a KMS backend? [21:55:40 CEST] <atomnuker> never worked [21:57:52 CEST] <atomnuker> durandal_1707: you mean a VT (e.g. ctrl+alt+f1), right? [21:58:09 CEST] <JEEB> drm stuff [21:58:39 CEST] <durandal_1707> atomnuker: yes [21:59:00 CEST] <durandal_1707> JEEB: drm vo drops frames [21:59:32 CEST] <JEEB> k [23:38:40 CEST] <BBB> michaelni: 22553U typo? [23:38:54 CEST] <BBB> michaelni: Im assuming that should be (unsigned)i_ict_params[1]? [23:45:01 CEST] <michaelni> BBB, yes, ill change it [00:00:00 CEST] --- Sat Sep 9 2017

1 0

ffmpeg.log.20170908
by burek 09 Sep '17

09 Sep '17

[00:18:39 CEST] <cryptodechange> Did that work for you kepstin? [00:29:34 CEST] <kepstin> I'm busy atm, will take a look later [02:22:22 CEST] <koyglreg> Why is it that using "fieldmatch=mode=pcn_ub,yadif=0:-1:1,decimate" on a mixed telecine and interlaced video succeeds in detelecining but fails to deinterlace? That is, the originally-24p "movie" in the video is successfully detelecined, but the 30i video segments/commercials before and after are still interlaced? [02:25:43 CEST] <kepstin> koyglreg: probably the fieldmatch filter incorrectly thinks that the interlaced sections aren't combed, so it doesn't mark them as interlaced, so yadif doesn't run on them [02:26:10 CEST] <kepstin> there are various thresholds in fieldmatch that can be tweaked. [02:26:54 CEST] <kepstin> in particular, combmatch=full might help [02:42:35 CEST] <koyglreg> kepstin: I just tried using "combmatch=full" but it seemed to make little or no difference on the interlaced section. [02:46:38 CEST] <koyglreg> I wonder if my yadif settings are wrong. [02:51:01 CEST] <koyglreg> The first two minutes are a video introduction to the movie, and ffmpeg indeed does complain "Frame X at Y is still interlaced". [02:51:38 CEST] <koyglreg> It gives errors like this for the first two minutes: [Parsed_fieldmatch_0 @ 000001ee399cbbe0] Frame #4583 at 152.919 is still interlaced [03:47:39 CEST] <kepstin> yeah, if you see messages like that, then those should be the frames that yadif is running on [03:48:17 CEST] <kepstin> I think your yadif command is correct, but using the named options will make it a bit more obvious [03:54:30 CEST] <koyglreg> kepstin: i might use tivtc in avisynth instead... [10:12:31 CEST] <crow> does someone here transcode live to to rtsp ? i am having problem with high cpu usage even this is an xeon cpu (only cpu avaiable as this is an VM). it work only with -preset ultrafast but here the video quality is bad [12:48:11 CEST] <vlt> crow: Assuming you're encoding to libx264: afaik, the speed related presets only affect the *size* of the output, not the quality which is specified by "-crf", for example. [13:01:29 CEST] <sfan5> vlt: since the presets restrict (or allow) x264's usage of certain features it will always result in worse (or better) quality for a given bitrate [13:02:14 CEST] <sfan5> if you use -crf you will get the same quality at a way higher bitrate [13:23:07 CEST] <thebombzen> sfan5: only with faster presets [13:23:24 CEST] <thebombzen> with the slower ones, the features aren't restricted enough to matter [13:24:28 CEST] <sfan5> yea forgot to mention that [14:15:22 CEST] <sybariten> hello fellow video lovers [14:16:05 CEST] <sybariten> i am re-encoding (i believe) a 350 meg 50 minute wmv file. But i mean it takes some time to run that just as a test, so is there some way i can work on only the first two minutes ... like "cropping" the length of the video? [14:17:05 CEST] <jkqxz> -t 2:00 [14:26:06 CEST] <sybariten> jkqxz: thank you! [16:21:26 CEST] <przemoc> does anyone remember or have a list somewhere: what codecs exactly windows 7 support out-of-the-box? I'm mailing with someone from the support who may seem complete computer illiterate and she wasn't able to play my video. I've figured out she used internet explorer, because if it was Firefox or Chrome, it would be simply shown in the browser... [16:34:14 CEST] <przemoc> oh, I had microsoft's VM IE8 - Win7 (that they provide for free) and video works there in windows media player. what the heck. [17:20:59 CEST] <crow> vlt sfan5 thebombzen with current cmdline only using veryfast and -crf 24 with -scale=hd720 is posible, faster/fast etc are causing high cpu usage, here is cmd line i am currently using https://defuse.ca/b/ac0Sl9bx [17:22:17 CEST] <sfan5> you can't expect much with baseline + veryfast profile [17:22:31 CEST] <sfan5> though at 1280x720 a xeon cpu should really not have a problem [17:23:26 CEST] <thebombzen> crow you probably don't want this: -filter:vf yadif:0:-1:0 -filter:v scale=hd720 [17:23:42 CEST] <thebombzen> you probably want -filter:v yadif=0:-1:0,scale=hd720 [17:24:40 CEST] <thebombzen> you probably also want -af aresample rather than -async [17:25:08 CEST] <crow> sfan5 it is an E3-1230 v2, and faster or fast == 100% cpu load and video unwatchable [17:25:34 CEST] <thebombzen> well yea, preset veryfast crf 24 is going to be very smudged [17:25:55 CEST] <thebombzen> especially with -profile baseline [17:26:01 CEST] <thebombzen> are you sure you want -profile baseline? [17:26:40 CEST] <sfan5> how many fps is the input? [17:26:44 CEST] <thebombzen> crow, also you probably want to add -re before -i [17:26:57 CEST] <thebombzen> the -re option causes ffmpeg to read from the file at 1.0x spee [17:26:58 CEST] <thebombzen> speed [17:27:07 CEST] <thebombzen> rather than as fast as possible, which it would normally do [17:27:14 CEST] <crow> thebombzen no i am not sure, i would just have nice live stream to watch while on vacation, hd720 should be enough, but picture quality wasnt that good [17:27:27 CEST] <thebombzen> then you don't want -profile:v baseline. [17:29:13 CEST] <crow> sfan5 Stream #0:0[0x780], 167, 1/90000: Video: h264 (High), 1 reference frame ([27][0][0][0] / 0x001B), yuv420p(progressive, left), 1280x720 [SAR 1:1 DAR 16:9], 0/1, 50 fps, 50 tbr, 90k tbn, 100 tbc [17:30:07 CEST] <thebombzen> try this: ffmpeg -re -f mpegts -i http://localhost:3000/S19.2E-1-1007-4911.ts -map v -map a -vf yadif=0:-1:0,scale=hd720 -c:v libx264 -preset:v fast -crf:v 21 -maxrate 4000k -bufsize 1024K -c:a aac -b:a 128k -f rtsp -rtsp_transport tcp rtsp://localhost:8089/live/stream [17:30:48 CEST] <thebombzen> crow: the -re option causes ffmpeg to only read the input at 1.0x speed. I dropped a lot of unnecessary options too [17:31:08 CEST] <sfan5> why are you scaling it to 720p when it's already 720p? [17:31:29 CEST] <crow> sfan5 currently, mostly it is 1080i [17:32:29 CEST] <sfan5> crow: my i5-4590 manages a comfy 222 fps with the settings in your pastebin [17:32:42 CEST] <sfan5> (and no it's not better than your xeon: https://www.cpubenchmark.net/compare.php?cmp[]=1189&cmp[]=2234 ) [17:33:56 CEST] <crow> thebombzen it was not posible to watch this stream, cpu 98% https://defuse.ca/b/xiQjekBt [17:34:32 CEST] <crow> sfan5 huh, well i am not sure what is then the problem. [17:34:43 CEST] <sfan5> you mentioned it's a vm, maybe it's that [17:35:25 CEST] <crow> sfan5 is they and cmd argument to skip scaling if already 720p? it is not always like that. [17:35:44 CEST] <sfan5> the scaler should be smart enough to skip scaling if possible [17:35:45 CEST] <crow> sfan5 yes but only two VMs, and this one is using whole CPU, running on SSD Datastore. [17:35:55 CEST] <thebombzen> crow: something is wrong with your input [17:36:03 CEST] <thebombzen> you're duping lots of frames [17:36:43 CEST] <thebombzen> either way, try setting the preset to faster and see what happens [17:36:45 CEST] <thebombzen> or even veryfast [17:37:05 CEST] <thebombzen> I find it hard to believe that you're only getting 42 frames per second though [17:37:20 CEST] <thebombzen> crow: threads=3 lookahead_threads=1 [17:37:28 CEST] <thebombzen> are you sure you set the right number of threads for the VM? [17:38:48 CEST] <crow> thebombzen playing this -i ..ts local with VLC is working fine. so video/audio input should be fine [17:39:34 CEST] <thebombzen> are you sure you set the correct number of threads in your VM? [17:40:52 CEST] <thebombzen> crow: for example, in VirtualBox, you need to change this setting. [17:40:53 CEST] <thebombzen> http://0x0.st/R0S.png [17:42:16 CEST] <thebombzen> http://0x0.st/R01.png [17:42:44 CEST] <thebombzen> I suspect that your virtual machine is restricted cpu-wise [17:44:36 CEST] <crow> let me double check that [17:44:40 CEST] <sfan5> htop output could also help [17:49:37 CEST] <crow> sfan5 well top shows me 4 cpus so it should be ok [17:57:20 CEST] <sfan5> are tose 100% used when encoding? [17:57:23 CEST] <sfan5> those* [18:02:10 CEST] <crow> sfan5 thebombzen seems after one cold boot of vm cpu is fine on the thebombzen example ffmpeg cmd line. https://defuse.ca/b/POeHelx1 [18:02:36 CEST] <sfan5> yeah that looks way better [18:03:01 CEST] <sfan5> aren't the two audio tracks always identical though? [18:03:18 CEST] <crow> probably, i am not sure [18:04:19 CEST] <crow> sfan5 thebombzen cpu usage is going to 70% (not all of 4 cores) [20:32:15 CEST] <doublya> I'm playing a video file with ffplay. Audio works on windows, but on Ubuntu 16.04 I'm getting SDL_OpenAudio: No such audio device [20:35:23 CEST] <ZexaronS> hello [20:35:54 CEST] <ZexaronS> moov atom faststart is to make it streaming ... but what if it's streaming already and I want to make it nonstreaming, what's the reverse command ? compatability issue fix [20:38:17 CEST] <JEEB> lol [20:38:34 CEST] <JEEB> you have to understand what the faststart actually does [20:38:44 CEST] <JEEB> there's an index structure in non-fragmented mp4 [20:38:55 CEST] <JEEB> and since it's an index it has to be written last [20:38:57 CEST] <JEEB> now [20:39:12 CEST] <JEEB> faststart just moves that index into the beginning of the file [20:39:30 CEST] <JEEB> thus I would say that it's highly unlikely that it's the faststart that broke your thing [20:39:44 CEST] <JEEB> I haven't found a single thing reading mp4 that would work with a moov atom in the back, but not in the front [20:42:34 CEST] <JEEB> s/atom/box/ , darn movspeak [20:43:08 CEST] <durandal_1707> doublya: use mpv [20:43:16 CEST] <ZexaronS> I don't know yet which way it doesn't work https://github.com/Helioviewer-Project/JHelioviewer-SWHV/issues/44#issuecom… [20:44:02 CEST] <JEEB> uhh [20:44:34 CEST] <ZexaronS> if it doesn't work with faststart then I would like to know how to reverse it, so the guy can use ffmpeg to fix the clips until jvhelioviewer supports both options [20:44:49 CEST] <JEEB> yea, these kind of issues are real fun with software that will not tell you what it didn't like, and people who have no fucking idea about multimedia [20:45:12 CEST] <JEEB> you should rather use ffprobe or L-SMASH's boxdumper [20:45:26 CEST] <ZexaronS> for what purpose? [20:45:40 CEST] <JEEB> to get information on the mp4 file and compare [20:46:01 CEST] <ZexaronS> oh okay, just wanted to be sure [20:46:09 CEST] <JEEB> blindly thinking that it's whatever faststart does is not really realistic [20:46:34 CEST] <JEEB> let's just say that there can be plenty of differences [20:46:55 CEST] <ZexaronS> But anyway, I was asking in general, I still wish to know how to reverse faststart with a command ... [20:46:55 CEST] <JEEB> with the tracks themselves or the container [20:47:14 CEST] <ZexaronS> I just never thought of wondering that until now [20:47:25 CEST] <JEEB> just don't set the parameter when remuxing [20:47:39 CEST] <JEEB> but to be honest, you are then demultiplexing and re-multiplexing [20:47:46 CEST] <JEEB> as in, the original file structure is not kept [20:47:47 CEST] <JEEB> at all [20:48:03 CEST] <JEEB> all the faststart mov muxer flag does is then move the moov index box to the beginning of the file [20:48:14 CEST] <ZexaronS> My phone outputs standard MP4 without web optimization, I run copy copy and faststart with no recoding just remux, but how come there is no reverse option to undo the faststart ... [20:48:40 CEST] <JEEB> just don't set faststart and the moov gets written at the end [20:48:59 CEST] <JEEB> and in any case remux will change the file structure completely because ffmpeg does not try to replicate the original structure [20:49:16 CEST] <JEEB> it takes the streams, demultiplexes them, then starts creating a completely new file [20:49:19 CEST] <ZexaronS> well I didn't realize that so that's what I was looking for, thanks [20:49:20 CEST] <doublya> @durandal_1707: Thanks. But I need ffplay for what I'm doing. Was hoping to get some help figuring out what it can't find an audio device. I have alsa insatlled. [20:50:04 CEST] <JEEB> ZexaronS: and that's why f.ex. "I had a file written with X, then I remuxed with ffmpeg.c with faststart and now it doesn't work" is not a valid comparison [20:50:22 CEST] <JEEB> because FFmpeg's libraries make no attempt at keeping the file structure the same [20:50:31 CEST] <JEEB> there are tools for the moov moving that supposedly only do that [20:50:41 CEST] <ZexaronS> Well I'm just pitching in, I'm not so sure about the maintainer of the git repo [20:51:48 CEST] <ZexaronS> the other guy seems he has no idea, but I just took the maintainer seriously ... maybe I shouldn't have but really no need to make a big deal about that [20:52:29 CEST] <JEEB> well many newcomers come here like you and misunderstand what these tools do [20:52:33 CEST] <ZexaronS> These are more scientific community folks, not so much computer heads [20:52:41 CEST] <JEEB> which is why I try to now explain it to you [20:53:09 CEST] <ZexaronS> Yes I have a problem that you're now putting this on me like it's all my fault, I get your point, just don't put it on me [20:53:42 CEST] <JEEB> well since you brought the thing up and since you thus wanted information on it, no? [20:53:48 CEST] <JEEB> that's what I'm trying to do - explain [20:54:16 CEST] <JEEB> first of all fix the misunderstandings and then start explaining regarding possible better ways of finding out differences [20:54:29 CEST] <JEEB> but in the worst case it will be really painful if you have closed source software in the loop [20:54:34 CEST] <JEEB> (that doesn't tell you anything) [20:54:46 CEST] <JEEB> I've been there with windows media player :P [20:55:05 CEST] <ZexaronS> Well if I posted the link, then the frustration should be directed there, I thought this would be an easy thing but hey I know I was wrong, I'm a computer geek (not the stereotype one) so I know how small things turn into several hour of brainstorming [20:55:30 CEST] <JEEB> well I'm not going to get involved in something like that :P [20:55:42 CEST] <JEEB> I have enough lusers here that pop up and I'm masochistic enough to help [20:55:58 CEST] <ZexaronS> Well I mentioned it how things usually go, not necessairly this case [20:56:50 CEST] <ZexaronS> Actually I never meant to ask you to help the git repo lol cmon [20:56:58 CEST] <JEEB> anyways, I think the qt-faststart tool in FFmpeg's code base is trying to do some of the minimal amount of changes [20:57:01 CEST] <JEEB> https://ffmpeg.org/doxygen/trunk/qt-faststart_8c_source.html [20:57:16 CEST] <JEEB> so if you care about that issue you can point those people towards it instead [20:57:24 CEST] <ZexaronS> I simply didn't thought of using ffprobe at the moment I saw the guy talking about web optimization [20:57:38 CEST] <JEEB> instead of file they should use ffprobe or L-SMASH's boxdumper --box [20:57:44 CEST] <JEEB> ffprobe gives very general info [20:57:51 CEST] <JEEB> and boxdumper --box gives you the whole structure [20:59:22 CEST] <ZexaronS> But depending on their skill, I'll do it for them, I simply hoped it wouldn't get to that point ;) I wanted to tell him to use ffmpeg to test the file he gets from JHelioviewer by enabling/disabling faststart, but I didn't knew what's the undo command, and you told me, so that's it [20:59:54 CEST] <JEEB> and yea, now you also found out that FFmpeg has a tool in the code base that is supposed to do the minimal change [21:00:10 CEST] <JEEB> because going through ffmpeg.c is fully destructive on the original structure of the mp4 [21:00:19 CEST] <ZexaronS> But I'm not a newbie around here, why are you thinking I am ? [21:01:00 CEST] <JEEB> because you haven't yet learned that ffmpeg.c is destructive on the original file structure and thus not necessarily representative of a minimal set of changes been done to the file? [21:01:55 CEST] <JEEB> (also your question about 'reversing faststart because it broke my breakfast') [21:02:17 CEST] <ZexaronS> It's more complicated than that, I didn't explain it but I can, it's one of those things when you know something, but you don't realize the consequence, I never thought that the output file is built according to the input file, it's a toally new file, but when it get's tricky like that, that realization isn't present in consciousness, and don't tell me you haven't experienced this kind of example in life [21:02:44 CEST] <JEEB> everyone does mistakes [21:03:35 CEST] <ZexaronS> I just don't agree it's a mistake, it may be less experience with the program, obviously I'm not a ffmpeg expert, and this was one of the more deeper tricks which simply aren't as obvious, that's probably it [21:04:09 CEST] <JEEB> well yea, definition of mistake. you missed a thing, I miss a thing. everyone can and probably will miss a thing at some point :P [21:05:03 CEST] <ZexaronS> but i don't know about boxdumper ... something new [21:05:58 CEST] <JEEB> yea, L-SMASH isn't a well-known thing [21:06:15 CEST] <JEEB> I've personally found it very useful when debugging mov/mp4-type files [21:06:35 CEST] <JEEB> as it lets you basically go through the structures' contents that it knows from the file [21:27:00 CEST] <redrabbit> hi, i'm trying to wrap my mind around analyzeduration [21:27:58 CEST] <JEEB> how far is the thing going to be reading the input timestamp-wise [21:28:09 CEST] <JEEB> probesize is similar, but regarding how many bytes it reads from the input [21:28:18 CEST] <redrabbit> from what i gathered highier value will yield better quality but more delay for the clients [21:28:28 CEST] <redrabbit> in the case of on-demand TV transcoding [21:28:51 CEST] <JEEB> not really quality - the only thing it's useful with if there are streams popping up later [21:29:01 CEST] <redrabbit> allright [21:29:05 CEST] <JEEB> or packets for those streams [21:29:09 CEST] <redrabbit> so it doesnt affects quality [21:29:17 CEST] <redrabbit> in that case im going to keep it as low as possible [21:29:26 CEST] <JEEB> mostly useful for ffmpeg.c because unlike the API it wants to do a single static probe and decide everything [21:30:21 CEST] <JEEB> if you have a dynamic piece of input like broadcast you will then at some point notice "oh btw, there was a packet for this new stream but since it wasn't there originally we are just going to ignore it" [21:30:30 CEST] <JEEB> (since ffmpeg.c logs it) [21:30:56 CEST] <JEEB> but yes, nothing to do with "quality" :P [21:31:49 CEST] <redrabbit> thanks [21:32:51 CEST] <redrabbit> well, i reduced it to zero, its still working and channels change faster [21:41:30 CEST] <doublya> Fixed the ffplay audio problem. Built sdl2 from source, worked with libsdl2-dev. Must be a lib I was missing. Probably pulse [22:19:59 CEST] <redrabbit> i cant find if the intel Z3735F has hardware support for HEVC decoding ? [22:22:10 CEST] <jkqxz> It doesn't. [22:25:12 CEST] <redrabbit> ok [23:11:30 CEST] <redrabbit> with NVenc AVC, if you use -preset, does it stops you from using the other options ? it dosent goes above 3/4Mbps bitrate wise and drops as low as 1Mbps [23:11:49 CEST] <redrabbit> id like to keep it behind 3 and 4.5Mbps [23:11:56 CEST] <redrabbit> between* [23:12:16 CEST] <redrabbit> using preset high [23:13:47 CEST] <redrabbit> goal is, i want to get the highest quality possible from h264_nvenc [23:21:52 CEST] <redrabbit> http://dpaste.com/2NZ7CRG [00:00:00 CEST] --- Sat Sep 9 2017

1 0

ffmpeg-devel.log.20170907
by burek 08 Sep '17

08 Sep '17

[00:03:17 CEST] <cone-652> ffmpeg 03Pavel Koshevoy 07master:edb4ba5bd4e7: Revert "lavfi/atempo: avoid false triggering an assertion failure" [00:03:18 CEST] <cone-652> ffmpeg 03Pavel Koshevoy 07master:25b5096400b2: lavfi/atempo: Avoid false triggering an assertion failure [00:17:11 CEST] <peloverde> BBB: I'm not attending VDD this year. The timing is too tough with my new job. I'll probably come next year. I will be at demuxed though. [00:18:02 CEST] <kierank> oh you left vp9 team [00:19:36 CEST] <peloverde> I'm at twitch.tv now [00:21:06 CEST] <kierank> ah nice, they need the help i think [00:21:45 CEST] <BtbN> the worst parts that need work are web stuff though [00:22:21 CEST] <kierank> BtbN: https://blog.twitch.tv/segment-based-rate-control-of-video-encoder-for-live… [00:22:26 CEST] <kierank> that blog post was very very wtf [00:22:36 CEST] <kierank> let's hold a competition to implement x264's default ratecontrol [00:25:58 CEST] <BtbN> I'm experiencing how great that works on my PS4 every time I watch something [00:26:10 CEST] <BtbN> every time it switches quality it jumps backwards in time by a few seconds [00:56:41 CEST] <Compn> peloverde : is twitch going to take over youtube y/n ? :P [01:21:53 CEST] <iive> Compn: I thought that twitch is mostly about live streaming. Are there archives of past content? [02:31:45 CEST] <cone-652> ffmpeg 03Steven Liu 07master:ef7fe81b8554: flvdec: Check the avio_seek return value after reading a metadata packet [02:33:57 CEST] <BBB> kierank: it sounds very much like lets have a 100s of poor grad students fight over who gets a free slice of pizza tomrrow to fix issues our engineers dont know how to fix [02:34:14 CEST] <BBB> kierank: why dont they hire a few PhD students? theyd be delighted to eat real food for a few months [02:34:21 CEST] <BBB> (and be paid well in the process) [02:48:32 CEST] <atomnuker> what good would a phd do, they'd still need years to get the skills needed to do a good job [03:20:54 CEST] <iive> about that twitch blog. It seems they do not understand what VBV is for. It is kind of absurd to claim that you can have VBV of unlimited size and then turn it off. [03:22:52 CEST] <iive> well, it smooths bitrate with trading it for latency, and that variable misses completely from their task. [03:26:45 CEST] <jamrial> oh nice, clang fixed the mjpeg miscompiling bug [03:28:11 CEST] <jamrial> nevcairiel: can you test "[PATCH 2/2] avformat/fitsenc: fill header line with spaces"? [03:47:49 CEST] <atomnuker> and yet a 6 day old gcc snapshot still can't compile the kernel [03:49:43 CEST] <cone-652> ffmpeg 03Paras Chadha 07master:b07faf39ed10: avcodec/fitsdec: write output to frame directly [03:50:20 CEST] <jamrial> atomnuker: sounds crazy, that'd be tagged as a blocker bug [03:50:23 CEST] <jamrial> was it reported? [03:50:59 CEST] <atomnuker> must have been [03:52:40 CEST] <atomnuker> yep, its been reported and people are complaining [03:54:31 CEST] <jamrial> bug #? [03:54:50 CEST] <cone-652> ffmpeg 03James Almer 07master:cf42f316c525: fate: fix fate-lavf-fits dependencies [03:58:12 CEST] <atomnuker> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81318 [04:01:27 CEST] <jamrial> "Any prospect of getting this fixed? I haven't been able to build Linux for ~a month now because of this." [04:01:46 CEST] <jamrial> have you considered not using a mid development build? [04:03:07 CEST] <jamrial> gcc trunk is not meant for production during stage 1 [04:04:03 CEST] <atomnuker> yep, that's what I'm using to compile the kernel [04:04:31 CEST] <atomnuker> there was a period of around 2 years during which I used gcc trunk and I can't recall it ever failing to compile the kernel [04:04:42 CEST] <atomnuker> which ended I guess around a few months ago [04:06:20 CEST] <jamrial> gcc trunk fails to compile ffmpeg once a year or so during stage 1 [04:06:23 CEST] <jamrial> if we're lucky, because of an ICE (like it happened a montha go) [04:07:09 CEST] <jamrial> if we're not, because of miscompilation of a module, which are a pain to report with test case and all [05:24:16 CEST] <Compn> https://www.amazon.com/MECOOL-Latest-Android-7-1-1-Amlogic/dp/B073Z7X7KV/ [05:25:01 CEST] <Compn> vp9 box haha [05:30:48 CEST] <atomnuker> probably requires kernel 3.10 and custom proprietary closed source kernel modules [05:36:49 CEST] <jamrial> Compn: that's just standard feature of mali 450 [05:37:06 CEST] <jamrial> weird that they mention vp9 instead of hevc for such a product, though [05:38:43 CEST] <Compn> hevc is listed later :) [05:38:59 CEST] <Compn> but yeah [05:39:02 CEST] <Compn> who knows [05:39:15 CEST] <Compn> youtube uses vp9 , i wonder if that means more vp9 content than hevc... [05:40:43 CEST] <jamrial> vp9 10bit hdr content on youtube is minimal afaik [05:42:03 CEST] <jamrial> but then, hevc 10bit hdr is probably limited to smartv demos, unless enough blu ray UHD movies using it are already out [05:43:20 CEST] <jamrial> oh nice, guardians of the galaxy vol 2 has a blu ray uhd release. I need to see how that looks [05:44:09 CEST] <Compn> i prefer valerian :) [05:44:29 CEST] Action: Compn watches far far too many films [05:45:09 CEST] <jamrial> haven't seen that yet [05:45:32 CEST] <Compn> its not as good as 5th element , but its the closest thing [05:45:44 CEST] <jamrial> in any case, gotg vol 2 blu ray 4k: "Resolution: 2160p (upscaled from 2K master)" [05:45:46 CEST] <jamrial> lol [05:45:58 CEST] <Compn> heh [05:46:23 CEST] <Compn> think they filmed it at 2k originally ? [05:46:24 CEST] <Compn> hmm [05:46:30 CEST] <Compn> i think probably not [05:46:40 CEST] <Compn> 8k no doubt [05:47:10 CEST] <jamrial> why would they have a 2k master then? [05:47:20 CEST] <Compn> because they lie to you, of course [05:47:38 CEST] <Compn> Digital Intermediate (2K) (master format) [05:47:38 CEST] <Compn> Dolby Vision [05:47:38 CEST] <Compn> Redcode RAW (8K) (source format) [05:47:43 CEST] <Compn> raw 8k , i figured :) [05:48:25 CEST] <Compn> probably their editing rigs are setup for 2k intermediate [05:48:40 CEST] <Compn> how come we dont have any redcode people in the group ? [05:48:48 CEST] <Compn> j-b : you should invite red people to vdd [05:51:04 CEST] <jamrial> it would seem that disney, fox and warner are all using dolby truehd/atmos for their blu ray 4k releases [05:51:20 CEST] <Compn> whats this arri raw format [05:51:29 CEST] <Compn> bayer 12bit [05:51:44 CEST] <jamrial> guess dts-x wasn't a good alternative to atmos for them [05:52:42 CEST] <jamrial> watch everyone move to dolby now that we finally got a dts-ma decoder, heh [05:53:19 CEST] <jamrial> not that it matters since we have a truehd decoder as well, and no way to handle atmos/dts-x anyway [05:55:06 CEST] <Compn> i would like to get decoders for all professional formats :D [05:56:20 CEST] <jamrial> oh shit, Labyrinth blu ray 4k [06:08:44 CEST] <rcombs> jamrial: Your Name got a "4K HDR" BD release, but it was upscaled from a BT709 1920x1080 RGB master [06:09:26 CEST] <jamrial> not surprising, i guess [06:09:32 CEST] <rcombs> apparently the BD authoring people took the edited master and re-color-graded it [06:10:24 CEST] <rcombs> also the scale looks CTEC [06:10:28 CEST] <rcombs> erm, QTEC [06:16:43 CEST] <Compn> i have no idea why bluray pressings are color corrected and denoised [06:16:55 CEST] <Compn> i guess... screw you and the film colors you remembered :) [10:10:33 CEST] <wbs> stevenliu: when cherrypicking patches from libav, I would appreciate if you'd keep the author line intact in git, especially if the patch doesn't need to do much modifications [10:11:02 CEST] <wbs> just referenceing the commit hash of the cherrypicked patch does little to inform the reader of who was the original author of it [10:12:25 CEST] <nevcairiel> it was even posted on the ML with the author line kind-of still there, but then pushed without it [10:12:47 CEST] <wbs> yeah [10:21:06 CEST] <stevenliu> keep the author info when commit? [10:21:36 CEST] <stevenliu> ok, do i need revert the commit this time? [10:22:52 CEST] <stevenliu> wbs: ? [10:23:32 CEST] <wbs> no, but keep it mind next time [10:24:00 CEST] <stevenliu> Ok, Sorry for that. [10:24:16 CEST] <wbs> git has got the author field; if you take a commit, try using "git cherry-pick" initially, and it will keep the original author name and commit message intact. if the patch doesn't fit perfectly you might need to do some fixing of conflicts [10:24:18 CEST] <stevenliu> i just think keep the commit id from libav, too simple, sorry. [10:24:40 CEST] <nevcairiel> isnt even more work to get rid of the original author, git itself usually keeps it [10:24:56 CEST] <wbs> if you manually apply the changes and do a new commit, you can do "git commit --author="John Doe <foo@baz>" to record it, or "git commit -c <hash of original commit>" to keep the metadata [10:25:22 CEST] <stevenliu> i usually use patch -p1 < xxxx.patch ;git commit -a [10:25:41 CEST] <stevenliu> and if need modify the author, git commit --author ""; [10:25:49 CEST] <stevenliu> ...... [10:25:58 CEST] <nevcairiel> you should learn about cherry-pick then :) [10:26:05 CEST] <wbs> absolutely [10:26:10 CEST] <stevenliu> mhmm, ok,haha [10:26:30 CEST] <nevcairiel> it also resolves some simple conflicts for you [10:27:30 CEST] <stevenliu> i will try to use git cherry-pick :D [11:01:19 CEST] <ubitux> ideally, we would be doing merges instead [11:01:34 CEST] <ubitux> still no one to deal with that dash stuff? [11:15:20 CEST] <mateo`> can't we just skip thoses dash patches ? [11:15:46 CEST] <mateo`> I mean for now, until someone cares [11:18:01 CEST] <ubitux> we should revert our stuff and apply the new one [11:18:30 CEST] <ubitux> i'm just way too tired/lazy/busy to try to figure out what's they're really all about and test them [11:18:58 CEST] <ubitux> btw, ETA: 530+ commits [11:19:13 CEST] <ubitux> what happened to the bitstream thing? [11:19:16 CEST] <CoreX> jesus christ.. [11:25:35 CEST] <durandal_1707> ubitux: foo86 said it is asserting for some scenario [11:29:10 CEST] <ubitux> the dash thing? in its current state or post patch? [12:41:01 CEST] <cone-790> ffmpeg 03Timo Rothenpieler 07master:a56d0497cbab: avcodec/nvenc: migrate to new encode API [12:41:02 CEST] <cone-790> ffmpeg 03Timo Rothenpieler 07master:d0961d30692a: avcodec/nvenc: sanitize variable names [13:30:03 CEST] <cone-790> ffmpeg 03Tobias Rapp 07master:912b6af26e0d: ffprobe: use consistent string for unspecified color_range value [13:32:21 CEST] <stevenliu> mateo`: you mean dashdec? [14:03:21 CEST] <BBB> gh0st__: do you have an update for the execute3 patch? [14:19:41 CEST] <gh0st__> BBB: I'll upload it in an hour or so, I have to make some tests. [14:19:45 CEST] <BBB> ok [15:03:22 CEST] <BBB> shall I oick up the msa vp9 optimizations in my push also? anyone against them? [15:03:38 CEST] <BBB> I really cant review them because -enoclue, but Im happy to merge them [15:04:09 CEST] <durandal_1707> have you tested it? [15:05:15 CEST] <BBB> nope [15:12:43 CEST] <durandal_1707> does it introduce security risks? [15:15:35 CEST] <BBB> dunno [15:16:57 CEST] <durandal_1707> is it libav cherry pick? [15:18:19 CEST] <BBB> no [15:20:08 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:913feb6263e0: avformat/gdv: Make FixedSize static [15:20:09 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:9cb4eb772839: avformat/mov: Fix DoS in read_tfra() [15:20:10 CEST] <cone-790> ffmpeg 03Michael Niedermayer 07master:afc9c683ed9d: avformat/asfdec: Fix DoS in asf_build_simple_index() [15:20:21 CEST] <durandal_1707> you may still apply it if its tested by at least one person [15:41:21 CEST] <BtbN> that amf implementation that guy did is horrible [15:41:36 CEST] <BtbN> There is now more actual code in compat than in the rest of ffmpeg [15:41:47 CEST] <wm4> I was just looking slightly at it, and that compat thing stood out, yes [15:42:08 CEST] <BtbN> That SDK should be an external dependency [15:42:15 CEST] <BtbN> but it's nice that it's MIT licensed [16:54:20 CEST] <cone-790> ffmpeg 03Paul B Mahol 07master:e1524de4546b: avfilter/vf_zoompan: fix specific corner case when no frame was ever requested from input [17:34:17 CEST] <durandal_170> anyone want retro star field source? [20:59:30 CEST] <BBB> hm, SlicethreadContext is also exposed in the header now [21:00:19 CEST] <BBB> gh0st__: WDYT if we move thread_execute3 to be non-static instead of thread_execute, and then re-move ThreadContext back privately into the .c file? [21:00:36 CEST] <BBB> gh0st__: and then rename it to ff_slice_thread_execute_with_mainfunc() or so [21:00:55 CEST] <BBB> gh0st__: I think thats a better idea, Im not the biggest fan of exposing SliceThreadContext into the .h file [21:01:06 CEST] <BBB> (even if its not exported, someone will eventually abuse it) [21:01:17 CEST] <gh0st__> BBB: okay, let's do that way. [21:01:37 CEST] <BBB> sorry for going in circles here, I just didnt realize wed need the struct ... [21:02:50 CEST] <atomnuker> tbh I'd rather not have 3 slice threading functions too [21:03:02 CEST] <gh0st__> I wasn't sure myself until the end if SliceThreadContext needed to be moved to .h [21:03:09 CEST] <atomnuker> since API users would need to fill in all 3 with their own implementation [21:07:27 CEST] <BBB> atomnuker: feel free to suggest alternatives in the ML thread [21:07:50 CEST] <BBB> atomnuker: or get rid of the old one (execute1) [21:10:24 CEST] <gh0st__> BBB: I am starting to think that we don't even touch the existing threading API, because it should be clearly modified only for vp9 at the moment. [21:10:36 CEST] <BBB> right, thats what we do now, right? [21:10:40 CEST] <BBB> so thats fine [21:11:02 CEST] <gh0st__> Well, yes, kind of. ) [21:12:33 CEST] <jya> I don't have access to the mp4 ISO spec right now, is there something in the metadata specifying the average frame rate of a video? [21:14:29 CEST] <JEEB> you can get that from the composition timestamps and durations [21:14:44 CEST] <JEEB> http://standards.iso.org/ittf/PubliclyAvailableStandards/index.html [21:14:49 CEST] <JEEB> also, just search 14496-12 in this :P [21:15:07 CEST] <JEEB> that's the ISOBMFF spec [21:16:44 CEST] <jya> JEEB: yeah, but I don't want to demux the content yet.. I only have the moof to work with [21:27:47 CEST] <gh0st__> BBB: Huh, I wanted to see how libav maybe had done the same thing, but their pthread_slice is different. [21:28:10 CEST] <BBB> yeah [21:28:16 CEST] <BBB> ffmpeg/libav split off too long ago [21:28:19 CEST] <BBB> the two have diverged too far [21:28:26 CEST] <BBB> I wouldnt waste too much time looking how they did things [21:53:34 CEST] <Compnn> is this 18if anime any good ? [21:54:38 CEST] <durandal_1707> Compnn: wut [21:54:53 CEST] <Compnn> durandal_1707 : new anime of crazytown [21:55:38 CEST] <durandal_1707> its for 18 years and higher, you are too young [22:06:29 CEST] <Compnn> durandal_1707 : i just thought it had an interesting cover. dunno what its about. kinda looks terrible from what i'm watching it right now [22:35:27 CEST] <gh0st__> BBB: check this out https://pastebin.com/UPD8imYV [22:35:52 CEST] <gh0st__> Is this what meant? [22:36:02 CEST] <BBB> perfect [22:36:03 CEST] <BBB> thnx [22:55:02 CEST] <BBB> gh0st__: michael is right that the pthread_slice patch should come first, and the vp9 patch second [22:55:39 CEST] <gh0st__> BBB: oops, my mistake. [22:55:54 CEST] <BBB> its ok, it happens [22:56:13 CEST] <BBB> you also need to submit a new vp9 patch since the way it calls into the pthread_slice api changed slightly, right? [22:56:24 CEST] <BBB> (I know its like a 1- or 2-line change, but still...) [22:59:28 CEST] <gh0st__> yeah sure [23:00:08 CEST] <gh0st__> Oh, god, I wanted to send that patch v8 patch for tile threading, but instead I sent garbage. [23:00:58 CEST] <gh0st__> Well, it's a patch, but not a full one./ [23:32:41 CEST] <J_Darnley> WTF? Who's been renaming things in the blend filter? [23:36:45 CEST] Action: J_Darnley swears a whole lot [23:38:33 CEST] <BBB> michaelni: I think you need to first apply [PATCHv2 2/2] avcodec/pthread_slice: add ff_slice_thread_execute_with_mainfunc(), and then [PATCH 1/2] avcodec/vp9: Add tile threading support [v8] [23:38:43 CEST] <BBB> michaelni: its very confusing, but that should work [23:46:44 CEST] <J_Darnley> WTF is going on here? Why isn't this lossless? [23:46:57 CEST] <J_Darnley> Who has been dicking with master? [23:48:01 CEST] <kierank> J_Darnley: dirac master? [23:48:11 CEST] <J_Darnley> No, ffmpeg master. [23:48:29 CEST] <kierank> ffmpeg master encoding dirac? [23:48:42 CEST] <J_Darnley> yes, either the encoder or decoder [23:50:14 CEST] <J_Darnley> Well I see a few silly changes from fuzzing. [23:50:29 CEST] <J_Darnley> But nothing else [23:50:36 CEST] Action: J_Darnley checks out an old master [00:00:00 CEST] --- Fri Sep 8 2017

1 0

ffmpeg.log.20170907
by burek 08 Sep '17

08 Sep '17

[01:43:09 CEST] <cryptodechange> Still having no luck with detelecine :(, either leaving interlaced like results or elements in motion have some merged blotching [01:43:19 CEST] <cryptodechange> https://pastebin.com/hUqiC5Pg [01:44:42 CEST] <cryptodechange> not sure if it's against the rules, but happy to drop $20 of BTC to whoever helps me solve it [01:59:24 CEST] <cryptodechange> it seems the 2 interlaced frames are actually in motion, doing pullup,fps=24000/1001 causes interlaced artifacts... doing fieldmatch,yadif,decimate causes some motion judder in the moving elements [03:10:25 CEST] <kepstin> cryptodechange: it's really hard to say without knowing what your source is like, but it sounds like you have blended fields [03:10:41 CEST] <kepstin> might have been a framerate conversion from pal to ntsc? [05:06:11 CEST] <alexpigment> hey guys: I don't know the ins and outs of AC3 audio, but is there a metadata option for the volume? [05:06:36 CEST] <dystopia_> i don't believe so [05:06:37 CEST] <alexpigment> I notice that sometimes when I preserve the original 5.1 ac3 stream and move to a new container, the volume drops considerably [05:06:52 CEST] <dystopia_> what container? [05:06:54 CEST] <alexpigment> I think that AC3 inherently has some sort of normalization parameter [05:06:55 CEST] <alexpigment> MKV [05:07:07 CEST] <dystopia_> i do that but don't notice a diffrence [05:07:28 CEST] <alexpigment> I'm going from TS to MKV via Handbrake fwiw [05:07:48 CEST] <dystopia_> hmm just tested an encode against my ts [05:07:52 CEST] <dystopia_> the volume sounds the same [05:08:47 CEST] <alexpigment> maybe it's just the way WMP plays it [05:08:55 CEST] <alexpigment> perhaps it's ignoring the dialog normalization parameter [05:10:18 CEST] <dystopia_> i do ffmpeg -i %input% -vn -sn -acodec copy %output%.ac3 [05:10:22 CEST] <dystopia_> after encoding the video [05:10:26 CEST] <alexpigment> i always avoid VLC because it has really dumb scaling artifacts and doesn't deinterlace properly [05:10:30 CEST] <dystopia_> then use mkvmerge to mux video and audio [05:10:37 CEST] <alexpigment> what is -wn again? [05:10:37 CEST] <dystopia_> i use mpc for playback [05:10:45 CEST] <alexpigment> er [05:10:49 CEST] <alexpigment> -sn i mean [05:11:04 CEST] <dystopia_> -sn strips any subtitles [05:11:07 CEST] <alexpigment> gotcha [05:11:27 CEST] <dystopia_> which is kinda pointless for .ac3 but force of habbit [05:11:32 CEST] <alexpigment> what benefits do you see from using mkvmerge vs ffmpeg? [05:11:43 CEST] <dystopia_> in your .ts you will probably have dvbsubs and teletext subs [05:11:53 CEST] <dystopia_> again just habbit [05:12:08 CEST] <dystopia_> it's the way i scripted it, to use mkvmerge long ago [05:12:10 CEST] <alexpigment> nah, i always record things from my dvr via a capture device, so no subs or teletext [05:12:20 CEST] <alexpigment> gotcha [05:12:26 CEST] <dystopia_> oh [05:12:28 CEST] <dystopia_> ahdtv [05:12:42 CEST] <alexpigment> yeah. everything on my cable is encrypted [05:12:46 CEST] <alexpigment> no way to get it without capture [05:12:52 CEST] <dystopia_> are you .uk? [05:12:53 CEST] <alexpigment> but I can capture with the original ac3 audio [05:13:02 CEST] <alexpigment> nope, 'murica [05:13:06 CEST] <dystopia_> ahh [05:13:20 CEST] <dystopia_> well in america you can use cablecard and hdhomerun iirc [05:13:36 CEST] <alexpigment> the channels are encrypted though [05:13:43 CEST] <alexpigment> no way to reverse that to my knowledge [05:13:55 CEST] <dystopia_> your cablecard handls the decryption [05:14:01 CEST] <dystopia_> cam module [05:14:02 CEST] <alexpigment> are you sure? [05:14:04 CEST] <dystopia_> yes [05:14:10 CEST] <alexpigment> what is the cam module? [05:14:12 CEST] <dystopia_> 100% certain [05:14:14 CEST] <alexpigment> does it just capture the screen? [05:14:15 CEST] <dystopia_> the cable card [05:14:26 CEST] <dystopia_> no, it lets you access the raw transport stream [05:15:21 CEST] <alexpigment> I mean I've researched this quite a bit, and all signs point to the contrary [05:15:25 CEST] <dystopia_> in europe it's much more difficult as you can't just insert your card into a third party reciever or capture device [05:15:32 CEST] <alexpigment> the CCI flag is still a thing [05:15:36 CEST] <dystopia_> you have to hack the stb and get the box pairing key [05:15:44 CEST] <dystopia_> and then set up a local sharing network [05:16:18 CEST] <alexpigment> well, if you have any info on this, pm me. I'd like to avoid the hassle of secondary recording if possible [05:16:42 CEST] <alexpigment> most everything I watch on tv has no life after broadcast. no online streaming, no DVD/Blu-ray, no digital purchase options [05:16:44 CEST] <dystopia_> https://www.silicondust.com/product/hdhomerun-prime/ [05:16:58 CEST] <dystopia_> "Access premium cable subscription channels using CableCARD"" [05:17:13 CEST] <dystopia_> https://en.wikipedia.org/wiki/Conditional-access_module [05:17:28 CEST] <dystopia_> im about to sleep but just google, all the info is public [05:18:31 CEST] <alexpigment> I'm not trying to get into anything illegal - just recording for myself as if VCRs still exist :) [05:18:47 CEST] <alexpigment> Anyway, I'll look it up. I had just always assumed that cablecards passed on the CCI flag [05:19:01 CEST] <alexpigment> which my ISP puts on EVERYTHING now, including OTA channels [05:19:12 CEST] <dystopia_> it's legal [05:19:30 CEST] <dystopia_> in america they let you use your cable card in third party devices for decryption [05:19:31 CEST] <alexpigment> no, i meant joining a scene release group :) [05:20:02 CEST] <dystopia_> in europe it's also legal but you have to hack your device to do it and goes against terms of service with cable/satellite providers [05:20:55 CEST] <alexpigment> https://forums.plex.tv/discussion/267947/hdhomerun-prime-time-warner-spectr… [05:23:42 CEST] <dystopia_> you wouldnt use plex [05:23:49 CEST] <dystopia_> you would use a proper application [05:23:54 CEST] <alexpigment> so i can use WMC [05:23:59 CEST] <dystopia_> like dvbviewer or npvr [05:24:05 CEST] <alexpigment> or NPVR [05:24:05 CEST] <dystopia_> yes you can use windows media center [05:24:10 CEST] <alexpigment> but doesn't it pass on the CCI? [05:24:14 CEST] <dystopia_> but your better off with a propwe app [05:24:20 CEST] <dystopia_> cci? [05:24:42 CEST] <alexpigment> CCI flag is what says the stream can be "copied freely", "copied once" or "copied never" [05:25:00 CEST] <dystopia_> thats not in the transport streams [05:25:07 CEST] <alexpigment> "copied freely" = this is good. but Spectrum / Time Warner doesn't have any channels that are copy freely anymore [05:25:08 CEST] <dystopia_> that is set at your dvr/stb level [05:25:23 CEST] <dystopia_> if you have access to the transport stream you can record whatever [05:25:37 CEST] <alexpigment> Ok, I'll look into this again [05:25:53 CEST] <alexpigment> I mean I trust your own experience. I just read a lot about this online before my current setup [05:30:00 CEST] <dystopia_> http://i.imgur.com/jHQLnCe.jpg [05:30:05 CEST] <dystopia_> decryption is fun :) [05:31:13 CEST] <alexpigment> It doesn't sound like you live in America, and I'm doubting you've dealt with the DRM/CCI stuff [05:31:25 CEST] <alexpigment> it's not just a matter of decrypting, really [05:31:38 CEST] <dystopia_> i have friends in america that use hdhomerun and cablecards [05:31:45 CEST] <alexpigment> Under what ISP? [05:31:54 CEST] <alexpigment> ISPs here are monopolies [05:32:19 CEST] <alexpigment> If your ISP isn't a major player, they probably don't have DRM on all of the channels [05:32:30 CEST] <alexpigment> Spectrum / Time Warner has it on *all* channels [05:32:48 CEST] <alexpigment> Meanwhile, I have friends who live 10 miles away who don't deal with the same thing on their ISP [05:33:08 CEST] <alexpigment> They can get the streams directly from their DVR via firewire, actually [05:34:10 CEST] <dystopia_> i sent him a message but he is afk atm it seems [05:34:18 CEST] <dystopia_> but i will let you know when he replies [05:34:40 CEST] <dystopia_> here anything thats recorded via dvr is locked to the box [05:34:50 CEST] <dystopia_> so i gues thats the cci stuff your on about [05:34:52 CEST] <alexpigment> Where are you? [05:34:55 CEST] <dystopia_> .uk [05:35:05 CEST] <alexpigment> UK apparently is pretty easy to get the raw streams from [05:35:14 CEST] <alexpigment> A lot of TV rips come from there [05:35:26 CEST] <dystopia_> but if you just hook your cable or sat feed up to a linux reciever like an enigma2 box, or a pc you can just get the transport stream directly [05:35:27 CEST] <alexpigment> Via satellite at least [05:37:01 CEST] <alexpigment> I mean I'm still reading. Everything I'm reading confirms what I'm saying [05:37:19 CEST] <alexpigment> Spectrum (in my area at least), puts the DRM/CCI on everything [05:37:40 CEST] <alexpigment> You can't use anything that isn't sanctioned, which limits you to WMC or a few other devices [05:37:46 CEST] <dystopia_> the link you posted says you just need a cable card [05:37:55 CEST] <alexpigment> But there is no way to do anything with those streams outside of watching it on the apps [05:38:05 CEST] <alexpigment> http://www.dslreports.com/forum/r31203271-CATV-HDHomeRun-Prime-cable-card-S… [05:41:06 CEST] <alexpigment> to be clear, this is the relevant post: http://www.dslreports.com/forum/r31203610- [05:42:46 CEST] <dystopia_> i read the whole thred :| [05:43:01 CEST] <alexpigment> then you will see that copy freely channels can pass on without drm [05:43:16 CEST] <alexpigment> copy-once channels must pass on the DRM via playready [05:43:25 CEST] <dystopia_> i will ask my friend when he is around [05:43:29 CEST] <alexpigment> all Spectrum channels in my area are either copy-once or copy-never [05:43:29 CEST] <dystopia_> how he is doing it [05:43:54 CEST] <dystopia_> you could just hack the box and set up a local card share server [05:44:01 CEST] <alexpigment> well, your friend is in a different market, and probably with a smaller ISP that doesn't set CCI on anything but On Demand and premium channels [05:44:17 CEST] <dystopia_> nah cuz he caps premium channels [05:44:22 CEST] <alexpigment> the channels MUST be marked at copy-freely [05:44:37 CEST] <alexpigment> well, his ISP must be pretty relaxed [05:44:44 CEST] <alexpigment> (i.e. not a major company) [05:44:56 CEST] <alexpigment> OR [05:45:04 CEST] <alexpigment> he caps via capture on premium channels [05:45:37 CEST] <alexpigment> anyway, let me know later I guess :) [05:45:57 CEST] <dystopia_> nah cuz that would be ahdtv [05:46:05 CEST] <dystopia_> and no one does that [05:46:14 CEST] <alexpigment> ahdtv? [05:46:18 CEST] <alexpigment> does the a mean analog? [05:46:25 CEST] <dystopia_> analog hdtv [05:46:26 CEST] <dystopia_> yes [05:46:37 CEST] <alexpigment> well, does that encompass hdmi capture? [05:46:45 CEST] <alexpigment> because it's all digital technically [05:46:50 CEST] <alexpigment> it doesn't go out to component [05:47:24 CEST] <alexpigment> (and yes, lots of people do that in the US :)) [05:48:09 CEST] <alexpigment> you can strip HDCP from HDMI, btw [05:48:12 CEST] <alexpigment> that's easy [05:48:20 CEST] <dystopia_> yes with a splitter [05:48:21 CEST] <alexpigment> and that's how most capture works [05:48:25 CEST] <dystopia_> but that is analogue and sucky [05:48:47 CEST] <alexpigment> again, "analog" seems like a weird description there, but I get your point [05:48:58 CEST] <alexpigment> you have to basically re-encode raw HDMI frames [10:11:32 CEST] <mozzarella> guys [11:27:55 CEST] <Commander_Cody> I'd like to record only a specific window. [11:29:07 CEST] <Commander_Cody> Tried the options '-f gdigrab -i title="Warzone 2100"' instead of the usual '-f x11grab -i $DISPLAY' and FFmpeg exited with a warning 'Unknown input format: 'gdigrab'. [11:29:29 CEST] <Commander_Cody> I use ArchLinux with the i3 tiling window manager in case that matters. [11:40:48 CEST] <dystopia_> @ alexpigment he uses fios [11:43:57 CEST] <furq> Commander_Cody: gdigrab is for windows [11:46:50 CEST] <Commander_Cody> furq: I *do* know the coordinates of what I want to record. [11:47:00 CEST] <Commander_Cody> Could I give those? [11:47:12 CEST] <furq> with x11grab, sure [11:47:48 CEST] <Commander_Cody> furq: Mind telling me how ? :) [11:48:27 CEST] <furq> !indev x11grab @Commander_Cody [11:48:28 CEST] <nfobot> Commander_Cody: http://ffmpeg.org/ffmpeg-devices.html#x11grab [11:50:46 CEST] <blap> then there's the fun of setting up your alsa loopback for the record [11:51:12 CEST] <fsphil> that really doesn't like my dual screen setup, with the screens not being the same size. some weird stuff going in in the null space :) [11:52:35 CEST] <redrabbit> wait for 2018 the year of linux desktop [11:52:44 CEST] Action: redrabbit has zero double screen issues on win10 [11:54:26 CEST] <Commander_Cody> Only noobs want a desktop :| [11:54:35 CEST] <Commander_Cody> window managers are still a superior concept. [11:55:16 CEST] <JonG> What is the best way to slow down an audio track without applying a pitch correction? The atempo filter seems to always apply a pitch correction. I would want that tempo 0.5 would slow down the audio, but also make e.g. voices deeper. I think if I pre-calculate the audio rate, apply asetrate with that value divided by 2, and then aresample back to [11:55:16 CEST] <JonG> the original rate, I will get the desired effect, but requiring multiple stages. [11:56:19 CEST] <furq> JonG: probably rubberband if your ffmpeg was built with it [11:56:22 CEST] <fsphil> https://www.youtube.com/watch?v=vGICEQ5gspQ [11:56:43 CEST] <furq> asetrate,aresample is the best way i know of without rubberband [11:57:55 CEST] <fsphil> reminds me of a migraine [11:58:41 CEST] <JonG> Ah OK thanks furq. I will try building with rubberband and see how that goes. https://ffmpeg.org/ffmpeg-filters.html#rubberband [11:59:11 CEST] <fsphil> is there a way of using x11grab with just a url, without the -f argument? [12:29:50 CEST] <nwoki_> hi all. I have a problem streaming images. What i do is use the following command: "ffmpeg -f image2 -loop 1 -i /tmp/image.jpg -pix_fmt yuv420p -f flv rtmp://dev-cube6:1935/live/webcam" to stream an image. All goes well. But when i change the image by saving another one over it, the stream is not updated. Any clues why? [12:46:27 CEST] <Nacht> nwoki_: ffmpeg loads all the inputs before hand, and then outputs them. Changing them won't make a difference, as it's already in its buffer [12:46:50 CEST] <nwoki_> is there a way to tell ffmpeg to constantly clear its buffer? [12:46:54 CEST] <nwoki_> Nacht: [12:47:33 CEST] <BtbN> no [12:47:59 CEST] <BtbN> use image2pipe and just keep piping the file into ffmpeg [12:48:27 CEST] <nwoki_> was doing that but the stream to rtmp results to be quite slow [12:48:53 CEST] <nwoki_> that's why I tried to change solution [12:49:06 CEST] <nwoki_> by streaming the same file and constantly updating that file with new data [12:49:30 CEST] <BtbN> what? [14:20:24 CEST] <maxhap> Hi guys, I'm trying to build FFmpeg with libass using the MSVC compiler but have been unable to correctly link the libraries, I have added a detailed explanation to this shared document. https://1drv.ms/t/s!AlxIO9rf94uPtOEf9Q_Uw-MEQRlNog If anyone could be so kind as to give me some pointers where I might be going wrong I would be extremely greatfull [14:30:22 CEST] <SudoSu> Hi, by some reasons my FFMPEG stucks at start. I'm trying to get an UDP MPEG2 stream, I see the network load on my VLAN interface but the transcoding of the input stream (with HLS) is not starting. I'm using Ubuntu 16.04 server and the most recent FFMPEG build with NVIDIA Cuda support. With CPU transcoding on my other server it's working fine (Debian). I can't switch to newer Ubuntu/Debian because NVIDIA not [14:30:24 CEST] <SudoSu> supports newer versions. If I can't see the answer here, could you mail me please? husudosu94[at]gmail.com. Thanks! [14:31:55 CEST] <stevenliu> SudoSu: Hello? [14:32:43 CEST] <stevenliu> Can you record a mpegts file to me? ffmpeg -i input -c copy -t 60 output.ts [14:32:52 CEST] <stevenliu> and send the output.ts to me [14:33:48 CEST] <SudoSu> I'm here [14:34:09 CEST] <SudoSu> I try it from my other server it's okay for you? [14:34:58 CEST] <SudoSu> Or I can provide a FFPROBE too, if it's better for you. [14:36:03 CEST] <stevenliu> No, Just mpegts file to me [14:36:21 CEST] <stevenliu> ffmpeg -i input -c copy -t 60 output.ts or let me login your server try the nvenc [14:40:22 CEST] <SudoSu> TS file: https://1drv.ms/u/s!AlIDARy55xh43zz-Sbcd3lGeZR2o [14:43:22 CEST] <SudoSu> There's no problem with the NVIDIA Encoder if I'm trying local file. But when I try to get an UDP stream, FFMPEG got stuck, there's no error message. [14:43:44 CEST] <SudoSu> But with my other server it works just fine [14:48:45 CEST] <stevenliu> Is this record by the nvenc server? [14:49:51 CEST] <SudoSu> Nope, but I'll explain the whole problem in E-mail okay? [14:50:00 CEST] <stevenliu> ok [14:56:42 CEST] <mozzarella> guys [15:04:36 CEST] <durandal_1707> lads [15:06:56 CEST] <mozzarella> how can I limit the cpu usage of ffmpeg [15:07:12 CEST] <mozzarella> I want to convert some file but I don't want the fan to make too much noise [15:07:18 CEST] <durandal_1707> you dont [15:07:24 CEST] <durandal_1707> reduce threads [15:07:34 CEST] <mozzarella> even with one thread it's too much [15:10:39 CEST] <durandal_1707> are you using filters? [15:12:27 CEST] <mozzarella> what's that [15:13:53 CEST] <durandal_1707> mozzarella: processing video and audio effects [15:14:44 CEST] <mozzarella> no [16:06:08 CEST] <alexpigment> @dystopia_ that's kinda what I figured. Fios has their CCI flag set to "copy freely" for almost everything, according to what I'm seeing online [16:18:40 CEST] <mozzarella> durandal_1707: no [16:18:58 CEST] <mozzarella> you went quiet on me [16:19:56 CEST] <durandal_1707> mozzarella: are you on linux? [16:28:29 CEST] <spalpeen> i am interested in modifying the decoding section of ffmpeg to only decode a certain region [16:28:54 CEST] <JEEB> not possible in decoder [16:28:57 CEST] <spalpeen> is this possible? I find multiple references to decode_mb which looks like the multiblock decoding. [16:29:06 CEST] <JEEB> as in, most formats do not let you do those blocks separately [16:29:13 CEST] <spalpeen> i am searching for a loop over multiblocks but so far do not find [16:29:47 CEST] <spalpeen> the loop over multiblocks to produce image would be inside the codec then? [16:30:02 CEST] <spalpeen> for instance if i am intstd in h264 i need to mod that codec? [16:31:14 CEST] <BtbN> you can't do that [16:31:21 CEST] <BtbN> That's not how video codecs work. [16:31:56 CEST] <BtbN> The frames two frames after the one you just decoded uses one of the outside blocks as reference. You didn't decode it, so can't use it. [16:34:29 CEST] <spalpeen> i am willing to allow errors creep into edges of the region [16:35:14 CEST] <spalpeen> so i would ignore the motion corrections coming from neighbor blocks outside of the region of interest [16:35:24 CEST] <BtbN> It would entirely wreck the entire decode [16:35:30 CEST] <BtbN> It's not possible [16:35:53 CEST] <mozzarella> durandal_170: yes [16:36:00 CEST] <BtbN> Might be for some more simple codec, but definitely not for h264 [16:39:33 CEST] <spalpeen> i dont see a h264 decoder section at https://www.ffmpeg.org/ffmpeg-codecs.html, only the encoder? [16:41:47 CEST] <spalpeen> under libavcodec I find h264_direct.c , also around 20 other files with h264 in the name [16:43:13 CEST] <BtbN> the Video Decoders section looks broken. [16:44:53 CEST] <spalpeen> can you give a heads up where e.g. a loop over macroblocks in the decoder would be ? there's quite a few h264 .c and .h files [16:45:13 CEST] <BtbN> You are thinking of this way too simple. [16:45:26 CEST] <BtbN> Multiple people have told you that it's not going to work. [16:46:59 CEST] <spalpeen> i'm curious to try and see the reproduction error [16:52:26 CEST] <spalpeen_> . [17:14:35 CEST] <pupek> Hi everyone, i have a question regarding decoding of h264. [17:14:51 CEST] <pupek> My h.264 stream is encapsulated inside MPEG-2 TS stream. [17:16:04 CEST] <pupek> What i desire to do: looking at a payload of MPEG-2 TS packet i want to tell if there is an ending of h.264 frame inside. How i'm doing it now: i search for the beginning of next h.264 frame in next ts packets. When i find it, i know, that previous ts packet of the same pid must contain the end of the h.264 frame. [17:17:03 CEST] <pupek> I heard there is a function in ffmpeg that does just this - searches endings of frames, do you guys know what it could be or where to find it? [17:31:17 CEST] <BtbN> it could also just be filler data [17:37:25 CEST] <pupek> you mean in previous ts packet? It would contain filler data to make it 188 bytes long and the ending of the frame. There are no ts packets that consist entirely of filler data in my stream afaik [17:44:49 CEST] <fsphil> packets with PID 8191 are entirely padding [17:50:45 CEST] <pupek> i operate in the limits of one known video PID [17:51:12 CEST] <pupek> that is certain to contain h264 stream [17:51:27 CEST] <rmk0> 'lo. i'm using ffmpeg to produce a video from a sequence of PNG images produced by Blender. this works well (see: http://ataxia.io7m.com/2017/09/06/chemriver_night_20170906_0000.mkv) but i'd like to add a title card that lingers for ~5 seconds before the video starts playing, and i'd like to fade the video to black over the final second or so. is it possible to do this from the command line? [17:51:42 CEST] <rmk0> i could edit the video in kdenlive or whatever, but that'd (i believe) involve a lossy re-encoding [17:51:59 CEST] <pupek> and in ts packets of that pid there is a need to find the endings of h.264 frames [18:09:13 CEST] <pihpah> Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 517 kb/s, 23.98 fps, 23.98 tbr, 24k tbn, 47.95 tbc (default) [18:09:22 CEST] <pihpah> 517 kb/s is that bits or bytes ? [18:10:30 CEST] <jkqxz> Bits. [18:11:45 CEST] <pihpah> jkqxz: that not much, thought it would have been much greater for 720p videos. [18:12:06 CEST] <jkqxz> Depends how you encode it and what the content is. [18:15:53 CEST] <BtbN> And that value there is just a pure guess [18:19:27 CEST] <pihpah> I am justing wondering how many users I would be able to serve per day, I mean serving 720p videos, having 100 Mbit/s bandwidth so that they won't experience any lags or video stuttering. [18:19:58 CEST] <pihpah> I am just* [18:23:54 CEST] <BtbN> depends entirely on the bitrate you encode them with [18:39:03 CEST] <voip_> Hello guys, as i know GPU's like Nvidia GTX1060 has limitation up 2 live streams with transcoding. [18:39:03 CEST] <voip_> Is it possible unlock and run ore streams ? [18:40:49 CEST] <BtbN> That's called buying a Quadro Card [18:42:16 CEST] <voip_> I have 1060, so is it possible ? [18:43:05 CEST] <jkqxz> Quadro P2000 is the same chip without that limit. (Slightly different stats, but the same hardware.) [18:43:05 CEST] <BtbN> no [18:43:15 CEST] <voip_> :( [18:44:00 CEST] <voip_> so limitation comes from drivers ? [18:44:22 CEST] <BtbN> Or it's burned into the silicion, who knows. [18:44:44 CEST] <Fenrirthviti> Likely the drivers, but good luck trying to break in there. [18:45:11 CEST] <voip_> :) [18:45:58 CEST] <furq> i'd have thought it'd be in firmware [18:46:04 CEST] <furq> but yeah, good luck with that [18:49:21 CEST] <DHE> I suspect it's the drivers. as I understand it mixing and matching the cards will cause the 2 stream limit to suddenly show up and affect the quadro [18:49:43 CEST] <furq> oh really [18:49:44 CEST] <Fenrirthviti> yeah, I've heard that too. [18:50:06 CEST] <Fenrirthviti> having a non-quadro card in the system at all basically cripples everything that makes quadro cards worth it [18:50:15 CEST] <furq> it's amazing how quickly i stopped being surprised by how stupid that is [18:50:26 CEST] <Fenrirthviti> well "worth it" meaning more "the extra things quadros can do" [18:51:44 CEST] <Fenrirthviti> My fav stupid thing they do is that if any card on the system has CUDA active, it just kills everything else trying to use CUDA, even on a different GPU. [18:51:56 CEST] <Fenrirthviti> Have Premiere open? Sorry, you can't use nvenc. [18:52:44 CEST] <Fenrirthviti> Recent change, too. Running into people who do video editing tutorials and all of a sudden can't record [18:53:16 CEST] <Fenrirthviti> With the very awesome and helpful "out of memory" error [18:54:49 CEST] <BtbN> that sounds more like a bug [18:55:06 CEST] <BtbN> They probably never test the Quadros on the normal drivers [19:25:45 CEST] <doublya> Building ffmpeg with cuda. /usr/bin/ld: cannot find -lGL [20:00:12 CEST] <saml_> is ffmpeg scale? [20:53:20 CEST] <DHE> saml_: what do you mean? [20:56:48 CEST] <saml_> DHE, no idea. it looks like a good program [21:46:42 CEST] <technick> Anybody have a cheat sheet for re-encoding media to save space? [21:50:31 CEST] <vlt> technick: Usually not worth it. [21:50:58 CEST] <vlt> technick: What media do you have currently? [21:52:22 CEST] <technick> A bunch of concert bootlegs, averaging 10+ gigs for one hour of footage. [21:52:45 CEST] <technick> and high quality bootlegs, sound is coming off mixer [21:54:18 CEST] <vlt> technick: In 10GB/h? In DNxHD or something like that? [21:54:47 CEST] <technick> MTS files [21:56:52 CEST] <vlt> technick: You could try libx264 codec for video with a quite low value for "-crf". [21:57:20 CEST] <vlt> Or x265 (but I personally have never tried that before). [21:57:31 CEST] <kepstin> 10gb/h is about 24mbit/s which is a bit high, yeah [21:57:33 CEST] <durandal_1707> technick: encode to gif [21:57:50 CEST] <furq> he said he wanted to make it smaller [21:58:22 CEST] <technick> lol [21:58:49 CEST] <durandal_1707> than encode it to xface [21:58:54 CEST] <technick> I'm doing a test encode now using libx264 with a crf of 18 [21:59:03 CEST] <kepstin> technick: but yeah, it basically comes down to "re-encode with x264 in crf mode with a slow preset" [21:59:03 CEST] <furq> 18 is pretty high [21:59:17 CEST] <kepstin> and if the audio is pcm or something, compress that. [22:00:22 CEST] <technick> Do I need to demux the audio first? [22:00:56 CEST] <vlt> technick: No. [22:01:10 CEST] <iive> furq: you mean low. [22:01:19 CEST] <furq> i mean both [22:01:39 CEST] <vlt> technick: ffmpeg -i srcfile -preset veryslow -crf 18 -codec:a copy -t 300 out.mkv [22:02:00 CEST] <vlt> technick: This will encode the first 5 minutes. (-t 300) [22:02:54 CEST] <technick> I'll give it a whirl, thanks for the info [22:34:30 CEST] <przemoc> hi, is there anyone who could help me answering the question why video sped up (25fps -> 50fps) with ffmpeg (ffmpeg -i a.mp4 -c copy -f h264 a.h264; ffmpeg -r 50 -i a.h264 -c copy b.mp4) is jerky in chrome browser? (it plays fine in ffplay, mpv or MPC) [22:36:05 CEST] <JEEB> raw H.264 muxing into certain containers can go wrong [22:36:11 CEST] <JEEB> try L-SMASH's muxer [22:36:19 CEST] <JEEB> https://github.com/l-smash/l-smash [22:37:10 CEST] <przemoc> oh, I used to use it ages ago. are there windows binaries? [22:37:19 CEST] <przemoc> you provided them in the past IIRC [22:37:47 CEST] <cryptodechange> What's the best way to help color loss when using nlmeans? [22:37:59 CEST] <JEEB> which would be `muxer -i "a.h264?fps=50" -o out.mp4 (and maybe with --optimize-pd) [22:38:16 CEST] <przemoc> or maybe it was ffmpeg with l-smash patches, too long ago to remember [22:38:26 CEST] <JEEB> no l-smash patches for FFmpeg :) [22:38:52 CEST] <durandal_1707> cryptodechange: what kind of color loss? [22:40:42 CEST] <przemoc> JEEB: sorry, you provided something on your site long time ago, some patched ffmpeg, don't remember details [22:42:11 CEST] <cryptodechange> durandal_1707: https://i.imgur.com/8sdbRfG.png [22:42:32 CEST] <cryptodechange> left has nlmeans=s=2:p=3:rc=1 [22:44:02 CEST] <przemoc> cannot find L-SMASH for windows, so it seems I have to build it myself on Linux [22:45:07 CEST] <JEEB> it really has little in the way of deps so should be simple enough. even on windows just grab the mingw-w64 toolchain on msys2 and it should Just Work [22:45:14 CEST] <cryptodechange> a 480p DVD convert produces only 80% of the original filesize using CRF=15 [22:45:21 CEST] <cryptodechange> Without any denoising [22:46:00 CEST] <przemoc> JEEB: oh, haven't checked deps yet, thanks. I have up-to-date msys2 on my laptop. [22:46:06 CEST] <przemoc> will try [22:46:42 CEST] <furq> i have windows git builds here if you want them [22:47:50 CEST] <przemoc> I'd be glad to take them. it will save me a few minutes, I guess. [22:48:02 CEST] <furq> http://b23.be/lsmash/lsmash_20170305_a660f91_x86_64.tar.xz [22:48:24 CEST] <przemoc> thanks! [22:51:29 CEST] <przemoc> BTW it indeed built flawlessly on MSYS2 on up-to-date MinGW-w64 [22:57:50 CEST] <przemoc> yeah, no jerkiness [22:58:07 CEST] <przemoc> JEEB: thanks! [22:58:36 CEST] <przemoc> so it's still better to not use ffmpeg for muxing mp4s? [22:58:44 CEST] <przemoc> I mean: at all? [22:59:24 CEST] <przemoc> BTW I didn't use --optimize-pd. [23:04:41 CEST] <przemoc> maybe other question, if L-SMASH is better at muxing MP4, aren't there anyone versed in both ffmpeg and L-SMASH who would be able to improve ffmpeg's part responsible for handling that? [23:05:13 CEST] <przemoc> or are there some fundamental architectural differences that make it impossible? [23:05:26 CEST] <przemoc> s,impossible,very hard, [23:06:20 CEST] <JEEB> it's IIRC more to do with using more information from the H.264 parsing and having the user define a frame rate [23:06:35 CEST] <JEEB> -39 [23:07:28 CEST] <przemoc> ENOTEMPTY? [23:13:31 CEST] <cryptodechange> How does ffmpeg/x264 calculate the maximum number of reference frames? [23:14:51 CEST] <furq> preset or level [23:15:12 CEST] <furq> or -refs, but hopefully that one is obvious [23:22:31 CEST] <cryptodechange> do grainy/old sources generally need a much higher CRF than non-grainy/clean? [23:22:52 CEST] <cryptodechange> The bitrate difference is quite large [23:23:36 CEST] <przemoc> AFAIK if you want to preserve grain, then you do need higher CRF, therefore you get higher bitrate. [23:23:53 CEST] <kepstin> if you encode a video with more detail at the same crf & other settings as one with less detail, there will be a large bitrate difference, yes [23:24:28 CEST] <cryptodechange> But the perceived quality difference between typical crf differences [23:25:09 CEST] <cryptodechange> e.g. some people can notice some degradation between a 18 CRF and 22 CRF using the same settings [23:25:21 CEST] <cryptodechange> but to get an acceptable bitrate, I will need to use 22 CRF, or even higher [23:25:40 CEST] <kepstin> crf acts as a quality-based encoding setting, yes [23:25:48 CEST] <kepstin> lower crf = higher quality, therefore more bits [23:25:57 CEST] <kepstin> (assuming same video source) [23:26:36 CEST] <cryptodechange> I suppose for the purpose of plex media transcoding, a dragged out encode will always be better than live, no matter the crf [23:26:39 CEST] <przemoc> oops, I menat s/higher CRF/lower CRF/ of course [23:26:46 CEST] <przemoc> s/menat/meant/ [23:26:47 CEST] <kepstin> if you need a specific bitrate, then do a 2-pass encode. [23:27:22 CEST] <cryptodechange> For consistent grain, I wonder what the difference would be for a high crf or a 2pass with similar bitrates [23:27:25 CEST] <kepstin> a single-pass encode done in crf mode should be almost exactly the same quality as a 2-pass encode which ends up at the same size [23:27:27 CEST] <cryptodechange> end result bitrates* [23:28:24 CEST] <cryptodechange> So just up the CRF when testing encode segments until I'm happy with the overall bitrate [23:29:18 CEST] <kepstin> well, if you do that, simple/less grainy stuff will undershoot your target bitrate and not look as good as it could [23:29:54 CEST] <cryptodechange> but wouldn't i be in the same predicament with 2pass? [23:30:10 CEST] <kepstin> normally you want either "everything should be min this quality -> use crf" or "everything should meet this bitrate/size spec -> use 2pass" [23:30:28 CEST] <cryptodechange> I've tinkered with denoising filters, but I am noticing some colour juddering (e.g. flat or static backgrounds), general judder from frame shake and colour loss in darker/finer details [23:32:27 CEST] <kepstin> "juddering" has a specific meaning in video encoding regarding frame timing, are you sure that's what you mean? [23:32:54 CEST] <cryptodechange> No that's not it, the closest I can describe it is when you look through the fumes of a fire [23:33:07 CEST] <cryptodechange> and it distorts the image, but a bit more subtle [23:33:32 CEST] <kepstin> denoising filters will often cause some amount of smearing of details [23:33:33 CEST] <cryptodechange> it's more noticeable in gradients [23:34:25 CEST] <kepstin> you'd probably have to provide an image or video of what you're describing, I'm not sure I understand. [23:35:15 CEST] <cryptodechange> For the detailed colours being smeared: https://i.imgur.com/8sdbRfG.png [23:35:22 CEST] <cryptodechange> Let me grab a sample of the gradients [23:43:38 CEST] <cryptodechange> what's the best way to share a sample video kepstin? [23:44:47 CEST] <kepstin> hmm, I dunno, a couple of frames would probably be enough here? Don't put it on youtube or whatnot, they re-encode the video and it might either mask or exaggerate the effect [23:46:38 CEST] <cryptodechange> Try this [23:46:41 CEST] <cryptodechange> https://drive.google.com/file/d/0B6rDPzFC8IitdnUxUVVpb19qN2M/view?usp=shari… [23:46:46 CEST] <cryptodechange> Will need to download the original file [23:47:33 CEST] <blap> We are divided [23:47:34 CEST] <blap> The enemy rules [00:00:00 CEST] --- Fri Sep 8 2017

1 0

ffmpeg-devel.log.20170906
by burek 07 Sep '17

07 Sep '17

[01:33:03 CEST] <atomnuker> we don't support mixed-depth formats (e.g. luma is 10 bit but chroma planes are 8), right? [01:44:51 CEST] <nevcairiel> right [01:45:11 CEST] <nevcairiel> i have never seen anyone try to use them, even if h264 and hevc have both supported that [01:54:40 CEST] <BBB> Im sure something supports them [01:54:49 CEST] <BBB> it would be utter frankenstein [01:54:58 CEST] <BBB> its also possible with h264/hevc to get limited-range rgb [01:55:05 CEST] <BBB> I have no idea what that means [01:57:35 CEST] <atomnuker> I think there's a law somewhere, texas maybe, where if someone gives you limited range rgb you can shoot him [01:58:29 CEST] <atomnuker> maybe you had to be drunk too and fire a warning shot beforehand, I'm not sure [02:57:45 CEST] <cone-420> ffmpeg 03Michael Niedermayer 07master:d8bc198d0979: avfilter/vf_overlay: Restore shorthand option order [04:00:40 CEST] <atomnuker> jkqxz: why does hwcontext need a million and one private and public contexts? [04:01:05 CEST] <atomnuker> why does the AVHWFramesContext struct need refcounting at all? its a few bytes [04:01:40 CEST] <atomnuker> I'm getting a segfault because hw_frames_ctx->data is missing and I'm trying to figure what I changed to make it segfault [04:03:25 CEST] <atomnuker> wait, this makes no sense, there's a check to see if dst->hw_frames_ctx exists [04:03:43 CEST] <atomnuker> and since it does exists how does ctx = (AVHWFramesContext*)dst->hw_frames_ctx->data; fail at all [04:09:07 CEST] <atomnuker> seems like I've corrupted my memory somewhere [04:50:00 CEST] <atomnuker> nevermind, I was casting the wrong thing in get_buffer [09:46:44 CEST] <ubitux> rcombs: audiotoolbox_extralibs="-framework CoreFoundation -framework AudioToolbox -framework CoreMedia" [09:46:51 CEST] <ubitux> afaict you only need -framework AudioToolbox [09:46:58 CEST] <ubitux> i tested and it seems to work [09:47:04 CEST] <ubitux> the framework contains all the deps [09:47:13 CEST] <ubitux> and you end up with a binary that link to all the others [10:14:17 CEST] <ubitux> so yeah, just tested on my branch with --disable-autodetect --enable-audiotoolbox [10:14:24 CEST] <ubitux> this adds only -framework AudioToolbox [10:14:43 CEST] <ubitux> this is confirmed by otool -L which raise only this framework [10:14:51 CEST] <ubitux> and i can still decode with the _at decoders [10:18:13 CEST] <BtbN> philipl, could you, or pretty much anyone who has some experience with the new encode/decode API, take a look at the nvenc patch to change it to the new API? It works fine when I test it, but I'd like to have another pair of eyes check my logic before I push. [10:18:36 CEST] <BtbN> https://patchwork.ffmpeg.org/patch/4953/ [11:04:23 CEST] <wm4> atomnuker: it's refcounted because it has shared state and further frame refs [11:50:55 CEST] <cone-826> ffmpeg 03Paul B Mahol 07master:eea69a9f250e: avfilter/af_dcshift: add direct path [14:41:33 CEST] <BBB> wm4: about execute3, do we know why execute1/2 are part of the public API? [14:42:28 CEST] <BBB> wm4: I genuinely dont know, ilia just followed existing design [14:42:29 CEST] <nevcairiel> presumably at one point you could put your own callback there [14:42:33 CEST] <wm4> I don't [14:42:54 CEST] <BBB> nevcairiel: apart from mplayer, do we know anyone actually using that feature and getting specific utility from it? [14:43:22 CEST] <nevcairiel> probably not [14:45:06 CEST] <wm4> why mplayer [14:47:04 CEST] <BBB> wm4: everyone has this crazy uncle that shouldnt be used to justify silly behaviour; our crazy uncle is mplayer :) [15:00:42 CEST] <BBB> ok, so, going back to the original situation [15:00:49 CEST] <BBB> what do we do with execute3 then? [15:06:57 CEST] <wm4> make it ff_? [15:10:37 CEST] <BBB> I think part of the problem is that execute3 is in AVCodecContext, maybe it shouldnt be [15:13:16 CEST] <jkqxz> AVCodecInternal? [15:13:52 CEST] <BBB> what I mean is why do we call avcodec->execute3() instead of just calling avpriv/ff_mythread_cute_function() [15:14:07 CEST] <BBB> again, I dont know, hence my question, but we currently do that for execute1/2 [15:14:12 CEST] <gh0st__> I think it would better to move it from AVCodecContext, because only vp9 would utilize the execute3 [15:14:59 CEST] <gh0st__> Maybe in the future we can put it in AVCodecContext when more codecs would need it. [15:15:55 CEST] <gh0st__> I am not sure [15:19:09 CEST] <BBB> ok, can we rewrite this so there is only changes in vp9.c? [15:20:16 CEST] <BBB> e.g. we can remove execute3 entirely, and the mainfunc cap [15:20:22 CEST] <gh0st__> Yes, I think for the current state of things that would the best choice, I think. [15:20:38 CEST] <BBB> and then either add thread_execute3 as a non-static function with ff prefix and call that instead of avctx->execute3 [15:21:04 CEST] <BBB> or alternatively make thread_execute non-static with ff prefix, add thread_execute3 in vp9.c, and do it like that [15:21:05 CEST] <gh0st__> yes [15:21:21 CEST] <BBB> wm4: which one do you prefer? [15:22:18 CEST] <BBB> I think the second is better, since execute3 is currently vp9-specific [15:22:24 CEST] <BBB> shall we do that then? [15:22:51 CEST] <wm4> maybe the latter [15:23:33 CEST] <BBB> ok [15:23:48 CEST] <BBB> gh0st__: that still requires the cap then, but in caps_internal instead of caps (public) [15:24:09 CEST] <BBB> gh0st__: since otherwise pthread_slice.c doesnt know whether to allocate the main thread as one slice worker or for the main_func [15:24:19 CEST] <BBB> but the rest should be straightforward, and it removes the need for execute2 [15:24:26 CEST] <BBB> sorry, execute3 [15:24:37 CEST] <BBB> and thus also avcodec_default_execute3 [15:25:11 CEST] <gh0st__> Sure, I think that's better. [15:40:34 CEST] <ubitux> BBB: http://sprunge.us/MGiD [15:40:38 CEST] <ubitux> with the patchset [15:40:51 CEST] <BBB> *tears in my eyes* [15:40:54 CEST] <BBB> so beautiful [15:40:59 CEST] <BBB> tnx! [15:41:02 CEST] <JEEB> najs [15:41:42 CEST] <nevcairiel> nice cleanup :) [15:41:58 CEST] <wm4> did we get rid of the SDL dep yet [15:42:06 CEST] <JEEB> --disable-autodetect [15:42:10 CEST] <JEEB> and it fscks off [15:42:21 CEST] <JEEB> "fly away~ fly away now~" [15:44:05 CEST] <ubitux> someone needs to do it for windows btw [15:44:10 CEST] <ubitux> for that one, i can't help [15:44:23 CEST] <JEEB> which type of windows? [15:44:32 CEST] <JEEB> mingw-w64 or MSVC? [15:44:53 CEST] <ubitux> both i guess, but i could try mingw [15:45:05 CEST] <ubitux> i have a build but didn't check if it autodetected stuff by default [15:50:26 CEST] <mateo`> yeah, I successfuly booted an Odroid-C2 with an upstream kernel (4.13 - ArchLinux) [15:50:40 CEST] <ubitux> atomnuker ^ [15:50:41 CEST] <mateo`> atomnuker: ^ [15:50:49 CEST] <JEEB> cool [15:52:13 CEST] <mateo`> using the base image, you just need to pacman -S uboot-odroid-c2-mainline linux-aarch64 [15:52:17 CEST] <mateo`> then cd /boot; ./sd_fusing.sh /dev/mmcblk0 [15:53:03 CEST] <ubitux> jamrial: can you rebase you audiotoolbox patches so i can test them? [15:53:09 CEST] <ubitux> (do you have them in a branch?)_ [15:53:31 CEST] <jamrial> ubitux: they don't apply? ok, i'll do it in a bit and push to github [16:22:06 CEST] <philipl> BtbN: I will look [16:35:21 CEST] <atomnuker> mateo`: oh hey they finally did it then, huh [16:38:00 CEST] <jamrial> ubitux: https://github.com/jamrial/FFmpeg/commits/audiotoolbox it applied cleanly with git am here [16:39:04 CEST] <jamrial> first two commits are memleak fixes in different scenarios, third is a rewrite of the bsf stuff [16:45:39 CEST] <ubitux> jamrial: builds without warning and decode seems fine; anything i should test in particular? [16:48:53 CEST] <flying_toaster> hi there [16:49:22 CEST] <flying_toaster> I have an issue with ITU 35 closed caption extraction in H264 [16:50:32 CEST] <flying_toaster> it seems the h264 codec extracts closed captions correctly with 1 thread, but I do see inversions/corrupted 708 bitstream if the h264 codec works using several threads [16:50:56 CEST] <flying_toaster> I tried to analyze the code, but it is a bit complex [16:51:18 CEST] <flying_toaster> any idea to solve this ? [16:54:02 CEST] <BBB> is it stored as frame side-data? [16:55:05 CEST] <flying_toaster> source CC is in the SEI, extracted CC is in side data, in the output AVFrame [17:04:38 CEST] <kierank> BBB: it's probably the same thread bug i had [17:04:51 CEST] <kierank> with fields [17:04:55 CEST] <BBB> oh, aha [17:07:25 CEST] <BBB> that bug is annoying& you should really fix that :-p [17:07:44 CEST] <ubitux> tsan is still not green? :( [17:08:07 CEST] <ubitux> meh, utvideo still yellow? [17:08:20 CEST] <kierank> BBB: well i sent a patch [17:08:29 CEST] <kierank> but i was told not to modify the previous thread [17:08:32 CEST] <kierank> so I dunno how to fix [17:08:51 CEST] <BBB> modifying the previous thread is a recipe for disaster [17:09:02 CEST] <kierank> I emergency fixed it by forcing single thread at the time but I would like to fix it properly [17:09:04 CEST] <BBB> its like the ground changing under you, it is the definition of a race condition :-p [17:09:12 CEST] <kierank> perhaps a discussion for VDD [17:09:16 CEST] <BBB> agreed [17:12:34 CEST] <jamrial> ubitux: aac adts audio, use valgrind to look for memleak, and make sure the packets are filtered [17:12:50 CEST] <flying_toaster> kierank : is your patch available somewhere ? [17:12:52 CEST] <jamrial> but if audiotoolbox didn't complain about weird data guess it's being filtered alright [17:13:16 CEST] <jamrial> unless it recently started supporting adts encapsulated frames [17:14:03 CEST] <ubitux> valgrind is broken [17:14:41 CEST] <ubitux> (on garbageOS) [17:14:49 CEST] <ubitux> can't really use it [17:14:51 CEST] <jamrial> ah [17:15:05 CEST] <ubitux> it segfaults randomly, raise false positive etc [17:15:25 CEST] <jamrial> ok, then as long as adts frames are decoded fine after the bsf rewrite patch then i guess it should be fine [17:15:52 CEST] <ubitux> mmh what sample i can use for adts? [17:16:41 CEST] <jamrial> ubitux: aac/id3v1.aac and aac/foo.aac i think, from the fate suite [17:17:08 CEST] <jamrial> also ct_faac-adts.aac, judging by the name :p [17:23:43 CEST] <ubitux> jamrial: http://sprunge.us/NFVj [17:23:57 CEST] <ubitux> jamrial: pts looks different in aac/ct_faac-adts.aac [17:24:46 CEST] <ubitux> -c:a aac vs -c:a aac_at [17:25:35 CEST] <jamrial> but did the output of aac_at change between pre and post patchset? that's what i care about [17:25:53 CEST] <jamrial> if the output differs between aac and aac_at, that's something the maintainer would have to check [17:26:59 CEST] <ubitux> no, doesn't seem to change [17:27:59 CEST] <jamrial> ok, thanks a lot for testing :D [17:28:05 CEST] <ubitux> np :) [17:30:53 CEST] <J_Darnley> I hate interlacing shit. Why can't everyone who has ever touched it just die? [17:31:11 CEST] <ubitux> won't be enough for the files in the wild [17:31:54 CEST] <J_Darnley> If you discover one, you are included. [17:32:42 CEST] <ubitux> aren't you complaining because you're dealing with one currently? :-° [17:32:42 CEST] <nevcairiel> does that include you then [17:33:20 CEST] <J_Darnley> Yes! [17:33:28 CEST] <J_Darnley> I wouldn't have to work on this shit anymore. [17:33:40 CEST] <nevcairiel> but you would be dead [17:33:54 CEST] <J_Darnley> Oh no! [18:05:51 CEST] <cone-826> ffmpeg 03James Almer 07master:7273e234dee5: avcodec/audiotoolboxdec: always use a copy of the AVCodecContext extradata [18:05:51 CEST] <cone-826> ffmpeg 03James Almer 07master:e49338a9c062: avcodec/audiotoolboxdec: add FF_CODEC_CAP_INIT_CLEANUP to the decoder capabilities [18:05:53 CEST] <cone-826> ffmpeg 03James Almer 07master:3242babf64a2: avcodec/audiotoolboxdec: switch to the new generic filtering mechanism [18:05:54 CEST] <cone-826> ffmpeg 03James Almer 07master:f4e593f7b51f: avcodec/audiotoolboxdec: use av_freep() [20:26:10 CEST] <stripes416> .win 6 [20:26:40 CEST] <stripes416> sorry, ignore my faulty keyboarding :/ [20:28:35 CEST] <gnafu> Unacceptable. [20:34:14 CEST] <iive> just change your password [21:22:24 CEST] <spalpeen> hello [21:23:12 CEST] <spalpeen> i would like to decode only a small crop of incoming stream, can someone point me to what section of code I should look at [21:32:59 CEST] <ubitux> so about that developer error message thing [21:33:23 CEST] <ubitux> how about a ff_devlog or whatever that is void on CONFIG_SMALL [21:33:30 CEST] <ubitux> and av_log at DEBUG level otherwise? [21:33:59 CEST] <ubitux> BBB ^ [21:34:03 CEST] <BtbN> I still wonder: Is that message in question only displayed on catastrophic decode failure, or is it one of those not overly important runtime errors that just happen with slightly corrupted files? [21:34:41 CEST] <ubitux> both i guess; the point is to help the developer identify quickly the code [21:34:42 CEST] <BBB> ubitux: I think were over-complicating something really trivial here [21:34:50 CEST] <BtbN> from looking at the patch it seemed like a hard error. [21:35:07 CEST] <BtbN> In which case, why the hell would you not always print the error then? If a user comes up with such a file, it saves everyone time. [21:35:10 CEST] <ubitux> BBB: not so sure [21:35:40 CEST] <ubitux> there are definitely different expectations [21:35:48 CEST] <BBB> BtbN: its what you said earlier, slightly corrupt files (e.g. from a network source) will indeed spam the stderr [21:36:06 CEST] <BBB> I think source code pollution is at least as big an issue [21:36:26 CEST] <BtbN> I don't see verbose debug logging as pollution [21:36:34 CEST] <BtbN> I have _tons_ of trace logs in cuvid [21:36:43 CEST] <BBB> not to mention the quality of his earlier log messages; hes committed 100s of these kind of patches, and the quality of the message is generally appaling [21:36:44 CEST] <jamrial> but those are trace [21:36:46 CEST] <BtbN> it basically gives you a full function call graph if you run it in trace mode [21:36:50 CEST] <BBB> trace is fine; he made it a hrd error [21:36:58 CEST] <BtbN> but all the strings are still in the code and binary [21:36:58 CEST] <BBB> AV_LOG_ERROR is displayed to our end users [21:37:00 CEST] <BBB> by default! [21:37:04 CEST] <BBB> thats not the same as trace [21:37:16 CEST] <ubitux> yes, most ppl agree this is not appropriate [21:37:23 CEST] <ubitux> the question is what alternative we agree on [21:37:34 CEST] <BBB> so there were multiple levels of concern from me, I can try to list them: [21:37:34 CEST] <BtbN> Yeah, for a mostly unimportant runtime hickup, LOG_ERROR is a bit much [21:37:37 CEST] <ubitux> i personally don't like ff_dlog [21:37:38 CEST] <BtbN> LOG_DEBUG seems appropiate [21:37:54 CEST] <BBB> A) the quality of the message was appaling; that needs fixing no matter what (he did that in the one patch, I hope he will continue keeping that up in subsequent patches) [21:38:13 CEST] <BBB> B) the level of stderr spam for slightly corrupted files (e.g. network source) is an issue (on default settings) [21:38:18 CEST] <BBB> C) the binary size [21:38:25 CEST] <BBB> D) source code polution (and size) [21:38:38 CEST] <BBB> D2) especially concerning stuff that is really fuzz-only [21:38:52 CEST] <BBB> D+D2 sort of go together in my mind, but you may disagree [21:39:01 CEST] <BBB> so, in terms of what would I be OK with: [21:39:22 CEST] <BBB> - Im fine with errors (AV_LOG_ERROR) for stuff that happens in real life, and assists the user in resolving it [21:39:40 CEST] <ubitux> when debugging, i agree with BtbN, having a trace is useful [21:39:41 CEST] <BBB> for example, sps/pps errors typically mean you mis-parsed the stream as an API user or something [21:39:58 CEST] <BBB> so it can be exceptionally helpful for everyone to get these under AV_LOG_ERROR [21:40:14 CEST] <ubitux> we could have some kind of MS error id though [21:40:39 CEST] <BBB> - I think for generic your file is broken, the end result will always be the same: test latest version, upload file, create ticket, ask devs for help [21:40:47 CEST] <BBB> I dont think we need more debug than that [21:41:03 CEST] <BtbN> Well, some debug output would still be useful for a fatal failure [21:41:18 CEST] <BBB> useful to who? [21:41:31 CEST] <BtbN> The dev reading the ticket and potentially not having to download the sample [21:41:34 CEST] <BBB> to the dev? or the user? [21:41:40 CEST] <BtbN> and to the user, as it saves time [21:41:42 CEST] <ubitux> #define TRACE_ERR(l) av_log(l,AV_LOG_TRACE,"err @ %s #%d\n",__FILENAME__,__LINE__); [21:41:50 CEST] <ubitux> always small binary size ^ [21:42:09 CEST] <ubitux> (fmt string is shared) [21:42:28 CEST] <ubitux> code is not that poluted (only "TRACE_ERR(avctx)" in error paths) [21:42:44 CEST] <BtbN> I'd put the version in there somehow [21:42:45 CEST] <ubitux> debuggable with a command line switch [21:42:57 CEST] <ubitux> yeah that's just an example so you get the idea [21:43:12 CEST] <ubitux> you flag every error path with that [21:43:17 CEST] <BBB> BtbN: version is first line of a proper ffmpeg commandline output :-p [21:43:42 CEST] <ubitux> anyway, i'll leave the brainstorming room for tonight [21:44:15 CEST] <BBB> and yes I know Im being an ass ATM, I think Ive given some good reasons for that: weve gone WAY overboard in the past few months in creating a new monster [21:44:18 CEST] <BBB> we need to tame it [21:44:33 CEST] <BBB> if Im sweet and cute about it, well go another 6 months creating a worse monster that nobody wants to deal wtih [21:44:43 CEST] <BBB> hopefully in a week well all agree on something and it wont get worse [21:45:00 CEST] <BBB> because seriously, the quality of the logs displayed by default to our end users was utterly appaling [21:45:06 CEST] <BBB> and thats unacceptable [21:45:21 CEST] <BBB> so lets improve this, and well all be happier [21:45:30 CEST] <BBB> and then Ill apologize for being an ass for a week [21:45:39 CEST] <BBB> sometimes a project needs an ass [21:45:51 CEST] <BtbN> Well, the _real_ endusers won't see any messages at all. As they use ffmpeg embedded into something else they use. [21:46:07 CEST] <BtbN> Everyone using ffmpeg directly is at least to some degree an advanced user [21:46:42 CEST] <BBB> UI users? oh goodness, if they saw these messages, theyd instantly file bug reports that their computer was overtaken by russian hackers [21:46:56 CEST] <BBB> (the bug reports would go to their local police office, not the software developers) [21:47:27 CEST] <BBB> Im sorry mam, you downloaded a new video viewer and it was taken over by russians? Im not sure we can help with that mam [21:47:48 CEST] <jamrial> "Application attempted to do an illegal operation" error popups are always a fun way to scare your aunt [21:47:49 CEST] <BBB> but I still feel the user presentation of ffmpeg-the-tool is also important [21:48:04 CEST] <BBB> is it -1 that was converted to permission denied? [21:48:13 CEST] <BBB> I had a lot of permission denieds in earlier versions [21:48:21 CEST] <iive> ubitux: I had a patch that did the same, but it replaced AVERROR, so it kind of was automatic for most usage [21:48:41 CEST] <BBB> yes! /usr/include/sys/errno.h:#define EPERM 1 /* Operation not permitted */ [21:48:46 CEST] <BBB> gotta love that [21:49:08 CEST] <iive> of course, AVERROR is used on some places as constant, so I needed to change these to something else. [21:52:16 CEST] <iive> ubitux: btw, It would be better if you have a separate function, so it could do more complicated things, like provide human-readable error codes and ignore EAGAIN, and do other more complicated logic. [22:02:03 CEST] <kierank> wm4: are you going to vdd [22:07:42 CEST] <wm4> kierank: no [22:07:58 CEST] <kierank> a shame [22:09:09 CEST] <wm4> I still don't understand the point of vdd [22:10:15 CEST] <j-b> meeting other geeks IRL [22:18:30 CEST] <durandal_1707> how that can be interesting? [22:22:41 CEST] <wm4> yeah, why would you go through so much trouble just to meet other people [22:23:16 CEST] <j-b> so much trouble? [22:24:56 CEST] <wm4> the timing is inconvenient too: I have to spend the entire next week abroad (due to my job), and the weekend after that (same as vdd) we have elections here [22:25:56 CEST] <BBB> aka lazy [22:26:07 CEST] <BBB> Im flying over all the way from the US, as is compn [22:26:21 CEST] <BBB> I believe peloverde usually also attends, hes from westcoast [22:26:32 CEST] <BBB> you europeans talking about how much effort it is, bunch of lazies [22:26:44 CEST] <j-b> I ain't lazy :) [22:26:49 CEST] <BBB> youre attending [22:26:52 CEST] <BBB> of course youre not lazy [22:26:54 CEST] <j-b> I do IBC-VDD-FOMS-Demuxed-GSoC [22:26:56 CEST] <BBB> non-attenders are lazy [22:27:11 CEST] <BBB> wm4 is lazy, durandal_1707 is lazy, michaelni is lazy [22:27:27 CEST] <j-b> I don't call anyone lazy. I understand the fear of travelling. [22:27:31 CEST] <atomnuker> wm4: going to the us? [22:27:32 CEST] <BBB> cehoyos is not lazy, thilo is not lazy, youre not lazy, compn is not lazy, peloverde is not lazy, atomnuker is not lazy [22:27:47 CEST] <j-b> I just think it's a shame, because it is always nicer with an IRL beer [22:28:29 CEST] <BBB> I appreciate how youre being such an incredible gentleman about these things [22:28:43 CEST] <wm4> atomnuker: not quite but similarly far [22:28:50 CEST] <atomnuker> j-b: I still remember the cone beer we had in 2015, it was very nice [22:28:57 CEST] <wm4> j-b: it's less than fear than a big annoyance [22:29:10 CEST] <BBB> my kids still play with the cone head we got 2 years ago [22:29:13 CEST] <j-b> atomnuker: I am re-brewing some for FOSDEM [22:29:17 CEST] <atomnuker> wm4: america or asia? [22:29:23 CEST] <wm4> atomnuker: america [22:29:54 CEST] <wm4> especially flying means waiting a shit ton being stuck somewhere [22:31:53 CEST] <atomnuker> exactly, that's why you take the train [22:31:54 CEST] <jkqxz> Flying is awful. At least Paris is somewhere I can get the train to. [22:31:55 CEST] <kierank> wm4: take the train [22:32:01 CEST] <jkqxz> Haha. [22:32:04 CEST] <atomnuker> city center to city center [22:32:12 CEST] <wm4> train to paris would take half a day, literally [22:32:39 CEST] <j-b> take a laptop, take the train, code. [22:32:39 CEST] <wm4> trains aren't even necessarily more comfortable than planes too [22:32:47 CEST] <wm4> but at least you don't have to wait this long [22:32:56 CEST] <wm4> (I mean, outside of the vehicle) [22:33:05 CEST] <atomnuker> they usually are because train companies understand why people take trains instead of planes [22:33:19 CEST] <wm4> this security bullshit in travel by air is going too far [22:33:36 CEST] <atomnuker> there is usually a cafe or a restaurant carrige [22:33:46 CEST] <kierank> the eurostar cafe is nice [22:33:48 CEST] <ubitux> BBB: i'm "lazy" too o/ [22:33:55 CEST] <BBB> booh! why? [22:34:23 CEST] <wm4> I probably should have gone last year - that was more convenient in a number of ways [22:34:23 CEST] <ubitux> i don't see the point either [22:34:27 CEST] <atomnuker> kierank: food and space in business class for a few quid more is well worth it too [22:34:36 CEST] <kierank> atomnuker: nah it was crap when i went [22:34:44 CEST] <atomnuker> I guess I got lucky [22:34:51 CEST] <kierank> atomnuker: on the new train perhaps it's better [22:34:53 CEST] <kierank> i went on the old one [22:35:10 CEST] <atomnuker> thought that was 2 years ago, can't remember if it was on an old or new train [22:35:46 CEST] <BBB> ubitux: Ill be amenable to resolving the logging issue with michael if you and jamrial attend (you dont have to convince me, just show up and Ill resolve it) [22:35:49 CEST] <BBB> enough reason? [22:36:29 CEST] <ubitux> i don't care enough about that issue [22:37:12 CEST] <kierank> https://code.facebook.com/posts/1537144479682247/finding-inter-procedural-b… [22:37:23 CEST] <BBB> Ill give you a I fix any one bug you want credit that I tend to give cehoyos every year? [22:37:49 CEST] <kierank> fix swscla [22:37:51 CEST] Action: kierank runs [22:37:54 CEST] <kierank> :( [22:38:18 CEST] <BBB> fix what specific issue? [22:38:47 CEST] <kierank> all of it :) [22:39:00 CEST] <BBB> hm... [22:39:19 CEST] <wm4> you can't even get rid of the self-modifying code for MMX that is used for a broken obscure scaler only [22:39:46 CEST] <BBB> one of my main issues with swscale is that it solves so many problems (really, it does) that at some point it becomes hard to functionally replace it without losing at least some feature or performance gap [22:40:02 CEST] <JEEB> yea, it's really a big big smorgåsbord [22:40:04 CEST] <JEEB> of features [22:40:30 CEST] <BBB> thats why I wrote the colorspace filter; its not better than swscale, but it solves some issues in swscale that I personally encountered directly [22:40:34 CEST] <wm4> I never got why libswscale does both conversion and scaling [22:40:44 CEST] <BBB> wm4: because in most cases conversion = scaling [22:41:04 CEST] <BBB> yuv422->yuv420 conversion is vertical chroma rescaling [22:41:08 CEST] <wm4> not really... for e.g. yuv420p->rgb, you actually convert to 4:4:4 at some point [22:41:09 CEST] <BtbN> It'd probably a massive performance hit to do that seperately as well [22:41:21 CEST] <wm4> (just do it in slices or so) [22:41:26 CEST] <BBB> BtbN: yes [22:42:50 CEST] <BBB> anyway, you want me to work on a part of swscale? come to vdd :-p [22:43:00 CEST] <BBB> is jamrial attending this year? [22:47:04 CEST] <jamrial> BBB: no. too many reasons why i can't or feel uncomfortable about it [22:47:18 CEST] <BBB> :( [22:52:39 CEST] <atomnuker> jamrial: do you live in argentina? [22:52:51 CEST] <jamrial> yes [22:56:25 CEST] <atomnuker> yeah, travelling is why I'm not going to demuxed, its too far away [22:57:14 CEST] <kierank> atomnuker: i doubt you'd like demuxed [22:57:18 CEST] <kierank> not that i've been [22:57:51 CEST] <atomnuker> I saw the schedule is filled with traditional talks from companies too [22:58:09 CEST] <kierank> FOSDEM is better tbh [22:58:12 CEST] <kierank> but not hipster enough [22:58:38 CEST] <kierank> vdd is more technical [22:58:49 CEST] <atomnuker> yeah, VDD and FOSDEM are the only places where multimedia people can give talks about things they've done out of interest [23:00:51 CEST] <kierank> that reminds me i need to do something about my mpeg4video 10-bit patches [23:06:46 CEST] <j-b> kierank: that actually exists? [23:06:57 CEST] <kierank> yes, there are samples [23:07:18 CEST] <j-b> oh boy. [23:07:21 CEST] <kierank> but mpeg4video is too heavily tied into mpegvideoenc crap and divx stuff to easily put in 10-bit [23:07:38 CEST] <JEEB> yea, mpeg-4 part 2 10bit is A Thing [23:07:45 CEST] <JEEB> and some pro stuff seems to create it [23:07:52 CEST] <kierank> if(a)do_a. if(b) do_b if(c) do_c [23:07:54 CEST] <kierank> totally pointless [23:08:57 CEST] <j-b> oh, that gives me a great idea for VDD: [23:09:13 CEST] <j-b> a competition of the worst multimedia abomination [23:09:20 CEST] <JEEB> MMT(P) [23:09:29 CEST] <JEEB> I'm just thankful I don't see that anywhere [23:09:35 CEST] <j-b> (with samples) [23:12:50 CEST] <kierank> mmtp yeah [23:12:52 CEST] <kierank> that's awful [23:13:14 CEST] <kierank> i might be able to get a sample of j2k in mxf over rtp [23:13:17 CEST] <kierank> that's also terrible [23:13:18 CEST] <JEEB> :D [23:13:22 CEST] <JEEB> aaa [23:14:56 CEST] <mateo`> kierank: bonus points if the j2k stream is interlaced and stored using the separate field layout [23:15:00 CEST] <rcombs> worst multimedia abomination? [23:15:05 CEST] <kierank> mateo`: yup of course it is [23:15:05 CEST] <rcombs> could be the super mario bros movie [23:21:50 CEST] <BBB> demuxed is definitely more corporate [23:22:18 CEST] <BBB> I think the primary reason for that is just geographical proximity to the bay area, so most people that live there with an interest in multimedia will be working for one of those big tech corps [23:26:00 CEST] <durandal_1707> why you guys are still working this, you should be fired already [23:33:11 CEST] <BBB> why do you still have a job, you should be fired? [23:33:16 CEST] <BBB> uhm [23:33:18 CEST] <BBB> right [23:33:46 CEST] <BtbN> Because they don't work for Oracle. [23:50:43 CEST] <Compn> BBB : i do not think i am attending vdd this year. [23:50:51 CEST] <BBB> ;( [23:51:13 CEST] <Compn> i am busy this year :( [23:51:18 CEST] <Compn> but please have fun without me [00:00:00 CEST] --- Thu Sep 7 2017

1 0

ffmpeg.log.20170906
by burek 07 Sep '17

07 Sep '17

[00:00:17 CEST] <blap> Susan Wojcicki intensifies [00:02:06 CEST] <jya> I don't know what ffmpeg is doing when creating files, but that's now the 3 files it has created with a size of 0 which I can no longer delete [00:02:20 CEST] <jya> permission denied [00:03:03 CEST] <durandal_1707> how you managed that....? [00:03:17 CEST] <jya> cannot get attributes for "c:\Users\mozilla\Work\Mozilla\mozilla-central\toolkit\components\gfx\content\test2.mp4": Access Denied [00:03:33 CEST] <jya> durandal_1707: I have no ideas :) [00:03:43 CEST] <jya> got some error at some stage about streams [00:03:52 CEST] <iive> jya: windows? [00:03:55 CEST] <jya> just trying the various options , often wrongly [00:04:02 CEST] <jya> yes on windows [00:04:10 CEST] <iive> probably a ffmpeg is still holding the files open [00:04:22 CEST] <jya> even on a privileged finder; delete option has been removed [00:04:43 CEST] <jya> no ffmpeg process running [00:05:13 CEST] <iive> then something else is holding them. sysinternal suite from microsoft have some utils that might help. [00:05:43 CEST] <iive> i guess you've run scandisk already [00:05:54 CEST] <jya> ah it was chrome holding the file even if it has finished playing it [00:06:04 CEST] <jya> can reproduce the issue in chrome too [01:07:18 CEST] <kmax> Hello [01:07:50 CEST] <kmax> looking for advice about making hls stream start faster [01:08:06 CEST] <kmax> using FFMPEG to create m3u8 and play it via Clappr Player [01:08:13 CEST] <kmax> takes about 15 seconds right now [01:08:18 CEST] <kmax> to start playing [01:08:35 CEST] <kmax> keyframes and chunks are set to 5 seconds [01:10:48 CEST] <bencc> 5*3=15 so that makes sense [01:10:55 CEST] <bencc> you can try using 2 seconds segment [01:11:10 CEST] <kmax> we did... was not much different [01:11:34 CEST] <kmax> how do people use HLS then? that seems like a really long connect time [01:11:47 CEST] <kmax> the other platforms we use connect in seconds... :) [01:11:56 CEST] <bencc> kmax: https://www.wowza.com/blog/hls-latency-sucks-but-heres-how-to-fix-it [01:12:12 CEST] <bencc> depends on your use case [01:12:13 CEST] <kmax> hey thank you! [01:12:27 CEST] <furq> kmax: are you sure you're actually getting 2-second chunks [01:12:46 CEST] <bencc> you'll always get 3*chunk-time latency [01:12:58 CEST] <furq> yeah it's at least two chunks and potentially way more [01:13:28 CEST] <bencc> kmax: wowza says you can even use 0.5 second. not sure if it'll work [01:13:32 CEST] <furq> but iirc with the segment muxer you still need to set the gop size when encoding [01:13:46 CEST] <furq> otherwise it'll just cut at gop boundaries [01:14:36 CEST] <bencc> that's the command I'm using [01:14:38 CEST] <bencc> https://pastebin.com/WVpEvYWL [01:14:38 CEST] <kmax> you mean it needs at least 2 chunks before it will start? [01:14:43 CEST] <bencc> yes [01:14:48 CEST] <bencc> for buffering [01:14:49 CEST] <furq> the player won't start until it's buffered two chunks [01:14:53 CEST] <furq> or more, depending on the player [01:14:55 CEST] <bencc> otherwise it won't be stable [01:15:19 CEST] <bencc> furq: does my command correctly set the gop size? [01:15:58 CEST] <furq> idk i've never used force_key_frames [01:16:13 CEST] <furq> when i've had to do this i just used -g and -x264-params keyint-min [01:16:33 CEST] <JEEB> hint: scenecut=0 is what you see x264's mailing list note [01:16:38 CEST] <JEEB> -g and that [01:16:42 CEST] <furq> does it make any difference [01:16:44 CEST] <JEEB> yes [01:16:50 CEST] <furq> oh really [01:16:57 CEST] <JEEB> keyint-min does different things and is strictly not recommended on the x264 ML [01:17:01 CEST] <JEEB> you can find details there [01:17:02 CEST] <furq> fair enough [01:17:13 CEST] <JEEB> just disable scenecut if you need static GOPs [01:17:14 CEST] <furq> that seems odd [01:17:19 CEST] <bencc> JEEB: do you have a complete command example? [01:17:42 CEST] <furq> i assume force_key_frames gets passed to the encoder somehow [01:18:00 CEST] <furq> but if not, -r 25 -g 125 -x264-params scenecut=0 -segment_time 5 [01:18:18 CEST] <furq> or whatever as long as -g is -r * -segment_time [01:18:45 CEST] <kmax> i got lost here... what does this command do? [01:19:06 CEST] <DHE> I thought it was no-scenecut [01:19:18 CEST] <JEEB> in cli yes [01:19:26 CEST] <DHE> also the HLS muxer uses -hls_time instead of -segment_time [01:19:46 CEST] <DHE> kmax: you're not encrypting the segments are you? [01:19:48 CEST] <JEEB> also no-scenecut=1 might work in libx264 API as well [01:19:54 CEST] <kmax> no [01:20:19 CEST] <JEEB> but if you look at the x264 ML you will see scenecut=0 being the usually recommended way of setting the parameter [01:21:13 CEST] <DHE> yeah a quick source scan says that's probably right [01:25:17 CEST] <kmax> let me make sure I have this... [01:25:27 CEST] <kmax> this is the command we should try. correct? [01:25:28 CEST] <kmax> -r 25 -g 125 -x264-params scenecut=0 -segment_time 5 [01:25:57 CEST] <DHE> -r 25 changes the output framerate. is that what you want? [01:26:41 CEST] <kmax> just trying to make the video start quicker... [01:26:53 CEST] <kmax> hoping to create the m3u8 quicker [01:26:59 CEST] <kmax> by making shorter files [01:27:15 CEST] <kmax> but setting the keyframes lower has not helped... [01:27:59 CEST] <kmax> yeah i am sure we would leave the -r flag out [01:34:09 CEST] <DHE> just to clarify, the issue is that the delay between the player starting up and the video actually beginning to play is too long? [01:35:32 CEST] <kmax> no the issue is how long it takes the m3u8 to be created [01:35:53 CEST] <kmax> you can look in chrome console... and the m3u8 cannot be reached... [01:35:57 CEST] <kmax> for about 15 seconds... [01:36:12 CEST] <kmax> then once it is created... the player starts right up [01:36:59 CEST] <kmax> seems like thats just how long it takes for the m3u8 to be created... [01:37:17 CEST] <kmax> we tried different combos of settings for keyframes and chunk size [01:37:23 CEST] <kmax> 2, 4,5 etc [01:37:49 CEST] <kmax> when we set it to 10 the delay is like 30 seconds [01:38:02 CEST] <kmax> Clappr player wants to buffer 3 chunks before starting [01:49:54 CEST] <DHE> oh... well that's not going to help. it sounds like you're generating the m3u8 on the fly and the client has to wait around for it to start [01:50:11 CEST] <DHE> which is just the wrong way to do it [02:00:57 CEST] <cryptodechange> still telecined/interlaced frames with fieldmatch,yadif=deint=interlaced,decimate :( [02:01:19 CEST] <cryptodechange> lots of 'Frame #X at X is still interlaced' messages [02:02:17 CEST] <kepstin> cryptodechange: yeah, fieldmatch can in some cases flag frames that still have combing as progressive, which means that yadif will skip them [02:03:11 CEST] <kepstin> there's a bunch of thresholds you can tweak in fieldmatch [02:03:43 CEST] <kepstin> or you can also try throwing in an idet filter after it to re-check the frames [02:04:43 CEST] <kepstin> seeing a bunch of 'Frame #X at X is still interlaced' is expected - those are the ones that are flagged for yadif to fix. It's the ones where you don't see that message which are the problem :) [02:14:20 CEST] <cryptodechange> Yeah it seems the frames I'm noticing were not logged [02:17:28 CEST] <CoreX> cryptodechange what type of content are you trying to encode with fieldmatch [02:25:09 CEST] <cryptodechange> DVD animation [02:25:15 CEST] <cryptodechange> @CoreX [02:51:46 CEST] <kmax> DHE are you still here? [02:51:55 CEST] <kmax> yes we are generating the M3u8 on the fly [02:52:15 CEST] <kmax> its that time to create it that is causing the delay in the video starting. [02:52:21 CEST] <kmax> once the hls play list is made... [02:52:27 CEST] <kmax> the video starts instantly from then on [02:52:37 CEST] <kmax> but we cant have all the streams going all the time [02:52:48 CEST] <kmax> so we have to start them as they are requested [02:53:01 CEST] <kmax> it is RTSP video from surveillance IP cameras [02:54:47 CEST] <kmax> @DHE are you still on? [02:55:03 CEST] <kmax> #DHE I dont know how to tag someone in this chat [02:55:24 CEST] <DHE> no tags. just say their name [02:55:33 CEST] <DHE> # is a channel. @ is a channel-op [02:55:34 CEST] <kmax> thanks [02:55:46 CEST] <kmax> you were saying something about us going about this the wrong way [02:56:07 CEST] <kmax> creating the m3u8 on the fly... [02:56:10 CEST] <DHE> you're trying to generate an HLS playlist on the fly and it's not possible to run them all the time instead [02:56:41 CEST] <kmax> right. [02:56:57 CEST] <kmax> they do generate on the fly... and it works well... but the start time is more than we would like [02:57:13 CEST] <DHE> does the video need to be transcoded? is there a limiting factor preventing them from running all the time? [02:57:17 CEST] <DHE> that's what HLS is really intended for [02:57:42 CEST] <kmax> yeah... the limiting factor is that most the clients have low bandwidth [02:57:51 CEST] <kmax> and if all cameras are streaming at the same time it is too much [02:57:57 CEST] <kmax> for the upload speed they have [02:57:58 CEST] <DHE> so you need to transcode which is killing the CPU? [02:58:14 CEST] <kmax> so we need to just start the cameras that are requested.. and being viewed at that time [02:58:29 CEST] <kmax> out of 16 cams they might only have 4 being watched at any given time [02:58:51 CEST] <kmax> actually the cpu and memory are doing well [02:59:07 CEST] <kmax> it would be great to just let them all stream all the time... [02:59:15 CEST] <kmax> but it would tax the clients internet too much [02:59:24 CEST] <kmax> so can only play the cameras on demand [02:59:45 CEST] <kmax> and it has to be html5... so there is no plugin and it will work on all devices [03:00:03 CEST] <kmax> this is working... and we are near "completion" :) [03:00:17 CEST] <kmax> but i really need to lower the start time if i can possibly find a way [03:06:31 CEST] <kmax> [03:07:18 CEST] <DHE> you're transoding with libx264? [03:08:01 CEST] <kmax> yes [03:08:15 CEST] <kmax> i admit i am working with a developer... [03:08:24 CEST] <kmax> but i have been in the code some with him... [03:08:32 CEST] <kmax> i am fairly sure the answer is yes. [03:08:40 CEST] <DHE> for experimentation purposes, try adding -tune:v zerolatency [03:08:50 CEST] <DHE> it'll have a negative quality impact, but see if it improves startup delays. [03:08:56 CEST] <kmax> he seems to have run out of ideas...so i am trying to find something :) [03:09:30 CEST] <kmax> thanks so much for the idea! [03:55:07 CEST] <cryptodechange> trying 'dejudder,fps=30000/1001,fieldmatch,yadif=deint=interlaced,decimate' [03:55:11 CEST] <cryptodechange> though I don't think that will change anything [04:37:28 CEST] <kepstin> use dejudder after the decimate if anything, it'll fix the frame timestamps [04:37:48 CEST] <kepstin> but that won't make any difference to whether interlaced frames pass through [04:55:41 CEST] <cryptodechange> should I bother with fps=30000/1001? [04:56:16 CEST] <kepstin> if you have a good source it's not necessary, but it won't hurt [05:03:47 CEST] <cryptodechange> it seems every 4th and 5th frame is interlaced, should I set the mode to pcn? [07:06:17 CEST] <cryptodechange> still no luck :( [07:06:19 CEST] <cryptodechange> https://imgur.com/a/R19yp [08:14:06 CEST] <bray90820> Would this be a good place to get help with general video editing?\ [09:24:59 CEST] <stevenliu> Hello everyone, it there have any facedetect filter? [09:25:24 CEST] <stevenliu> or it need develop by my self? [09:37:01 CEST] <alone> stevenliu, i guess to early for answering here [09:37:38 CEST] <stevenliu> [09:38:55 CEST] <alone> 8:38 UK time, US - 03:38 [09:39:00 CEST] <alone> (EST) [09:39:06 CEST] <alone> r u from Asia? [09:56:24 CEST] <bigx> hello there, anyone with nvenc experience? [09:56:35 CEST] <bigx> actually, nvdec, to be precise [09:57:27 CEST] <bigx> in the doc (https://developer.nvidia.com/nvidia-video-codec-sdk#NVDECFeatures) vp8 can be hw decoded when the pixel format is yuv420 [09:57:57 CEST] <bigx> does it mean vp8 with yuva420 pixel format will not be hw decoded? [09:58:31 CEST] <bigx> (vp8 with yuva420, is a vp8 video with an alpha channel) [09:59:50 CEST] <JEEB> from hwdec you generally get either 8 or 10 bit 4:2:0 YCbCr, pronto [10:00:11 CEST] <JEEB> that said alpha in VPx formats is IIRC separate so you can try to handle it separately, but generally that means decoding the whole stream :D [10:00:30 CEST] <JEEB> since the alpha-only decoding generally isn't available as a separate [10:00:32 CEST] <JEEB> thing [10:14:39 CEST] <wondiws> I have to set "extern "C" around my avcodec.h etc includes when using C++, is this correct? [10:14:52 CEST] <JEEB> yes [10:14:56 CEST] <JEEB> since FFmpeg's libraries are C [10:15:04 CEST] <JEEB> and you want to use them from C++ [10:15:38 CEST] <wondiws> JEEB, you're not going to put #ifdef CPP in the ffmpeg headers? :) [10:16:05 CEST] <JEEB> I think that was decided at some point so that's how it works with FFmpeg [10:16:16 CEST] <JEEB> and has for more than 10 years by now I think [10:19:10 CEST] <alone> JEBB hello [10:19:51 CEST] <alone> i am still trying to understand, it's not possible to grab screen with right colors via nvenc [10:19:57 CEST] <alone> but without success [10:20:20 CEST] <alone> yes, i am understand nvenc can only 420p for Kepler Core [10:20:35 CEST] <alone> this is meaning i can't recording right colors? [10:25:35 CEST] <BtbN> nvenc is not involved with screen capture [10:26:05 CEST] <alone> BtBn what you mean? [10:26:12 CEST] <BtbN> nvenc is an encoder. [10:26:19 CEST] <BtbN> It does not capture anything, it just gets fed frames [10:26:20 CEST] <alone> yes, i know [10:26:39 CEST] <bigx> Thanks JEEB , but I dont get it, look at this picture: https://developer.nvidia.com/sites/default/files/akamai/designworks/images/… [10:26:45 CEST] <BtbN> And I never heard of anyone complaining about bad colors with nvenc. So I highly suspect it's something else messing up. [10:27:09 CEST] <alone> thank you. but may be you know when, how can i grab screen with nvenc 264? [10:27:24 CEST] <alone> for CPU my line is: [10:27:25 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast E:\Screen.Capturing\%yyyymmhhmmss%.mkv [10:27:31 CEST] <alone> it's perfect. [10:27:50 CEST] <alone> for GPU: [10:27:51 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:0:0 -c:v h264_nvenc -qp 0 -pix_fmt rgb0 h264-nVidia.mkv [10:28:15 CEST] <alone> this have wrong colors. [10:28:24 CEST] <BtbN> Use the lossless preset if you want lossless with nvenc. [10:28:40 CEST] <alone> yes, but with Kepler Cores there is no lossless. [10:28:44 CEST] <alone> only with Maxwell [10:28:48 CEST] <BtbN> And I'd recommend against passing rgb to nvenc. [10:28:51 CEST] <alone> from 1st generation. [10:29:04 CEST] <BtbN> Just pass it normal yuv, ffmpeg is better at converting [10:29:32 CEST] <BtbN> And how do you define "wrong colors" [10:29:51 CEST] <alone> with yuv420p will be even worst, then with rgb0 [10:30:06 CEST] <alone> i tryed all - yuv420p nv12 p010le yuv444p yuv444p16le bgr0 rgb0 cuda [10:30:28 CEST] <alone> 444p of course not working with Kepler cores ;-(( [10:30:48 CEST] <BtbN> yuv420 does not mess up colors. [10:31:15 CEST] <alone> 420 only one colorspace for kepler ;( [10:31:37 CEST] <alone> i have 32bit screen. with 16 bit screen is same. [10:31:47 CEST] <BtbN> You still haven't even told me what is wrong... [10:31:48 CEST] <alone> i have only 3 colors - red, green and white. [10:31:56 CEST] <BtbN> That's not how screens work. [10:32:16 CEST] <alone> BtbN, just a moment [10:32:44 CEST] <BtbN> You mean there is no blue in the picture? [10:32:49 CEST] <BtbN> But white, which contains blue? [10:33:04 CEST] <alone> 1 sec [10:33:06 CEST] <alone> i will show [10:34:36 CEST] <alone> can u see this? https://ibin.co/3ZR3WwZgFZor.png [10:35:12 CEST] <BtbN> I don't see anything that seems immdiately wrong [10:37:12 CEST] <alone> https://ibin.co/3ZR4KtmGbiWU.png [10:37:18 CEST] <alone> can u see this? [10:37:28 CEST] <alone> first - with nvenc [10:37:32 CEST] <alone> second - with CPU [10:37:55 CEST] <alone> i know, my red = 255,0,0. My green - 0,255,0. [10:38:18 CEST] <alone> with CPU this is will be same after grabbing. with nvenc - no. [10:38:21 CEST] <BtbN> All the colors are there. It's just a lower quality encode. [10:38:53 CEST] <alone> i thought about it. yes. this is not fully lossless. [10:38:55 CEST] <alone> but [10:39:16 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast output.mkv [10:39:24 CEST] <alone> this is via CPU encoding. [10:39:36 CEST] <alone> this is perfect (#2 screen shot) [10:39:44 CEST] <alone> HOW can i do SAME with NVenc? [10:39:56 CEST] <BtbN> There is no color missing, and no color obviously swapped. I don't see anything wrong, except for the picture quality. [10:40:49 CEST] <BtbN> And the quality hit in this case can very well come from the halved color resolution of yuv420 compared to 444 [10:41:32 CEST] <alone> yes, i am "understand" that, becouse 444 - this is profile with CPU and it's perfect [10:41:47 CEST] <alone> but it's impossible to have this via nvenc? [10:41:50 CEST] <alone> right? [10:42:01 CEST] <BtbN> not on Kepler, no [10:42:05 CEST] <alone> yes. [10:42:08 CEST] <alone> guess same. [10:42:22 CEST] <alone> thank you very much BtbN [10:42:45 CEST] <alone> just 80% with CPU and 55% with GPU is different ;)) [10:42:54 CEST] <BtbN> 55% with nvenc is still way too much [10:42:58 CEST] <BtbN> should be closer to 0 [10:43:05 CEST] <alone> why? [10:43:15 CEST] <BtbN> Because it's full hardware offload [10:43:23 CEST] <alone> well, i have GTX 640 [10:43:27 CEST] <BtbN> so? [10:43:35 CEST] <BtbN> The encoding is still 100% offloaded to the card [10:43:42 CEST] <alone> it's 2012 card. may be it's too old? [10:44:00 CEST] <BtbN> I'd recommend just getting a 1050 [10:44:09 CEST] <BtbN> it's not expensive and has the best nvenc encoder around currently [10:44:37 CEST] <alone> this is Maxwell 1st generation? [10:44:42 CEST] <alone> processor? [10:44:43 CEST] <BtbN> That's Pascal 2nd gen [10:44:47 CEST] <alone> wow. [10:45:59 CEST] <alone> 1 sec [10:46:05 CEST] <alone> trying to search a tables [10:46:23 CEST] <BtbN> A 1050 will _by far_ outperform your 640 in every possible aspect [10:46:29 CEST] <alone> https://developer.nvidia.com/nvidia-video-codec-sdk [10:46:30 CEST] <alone> this one [10:47:15 CEST] <alone> ok, BtbN, of course i see you [10:47:46 CEST] <alone> i guess same. i am not too familiar with cores, specs etc before yearsterday. sorry please for my.. unknowing [10:48:46 CEST] <alone> this Pascal card [10:48:53 CEST] <alone> can even do h265 lossless [10:48:54 CEST] <alone> right? [10:49:14 CEST] <BtbN> I think so, but hevc hardware encoding is pointless [10:49:20 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx265 -preset ultrafast -x265-params lossless=1 output.mkv [10:49:23 CEST] <BtbN> It's not better then h264 at all [10:49:40 CEST] <alone> i use this for h265, but it's 100% [10:49:43 CEST] <alone> of CPU. [10:49:46 CEST] <alone> of my ;) [10:49:59 CEST] <alone> i can working with this, but.. 100%.. [10:50:19 CEST] <alone> 264 have NATIVE lossless mode? [10:50:22 CEST] <BtbN> x265 needs 8 cores or more to be able to encode in realtime [10:50:31 CEST] <alone> 8 corers of CPU? [10:50:36 CEST] <alone> cores. [10:50:48 CEST] <alone> GPU i guess - hunderents cores.. [10:50:49 CEST] <BtbN> My 8 core Ryzen can barely handle 1080p60 in realtime [10:51:03 CEST] <BtbN> GPUs aren't useful for video encoding. It's a dedicated encoder chip. [10:51:27 CEST] <furq> x265 lossless isn't particularly good is it [10:51:29 CEST] <alone> well, to be honest, my only goal have a screen capturing what I AM doing with lossless and not big size [10:51:43 CEST] <BtbN> I never bothered with lossless hevc. [10:51:43 CEST] <furq> try ffv1 or x264 lossless [10:51:57 CEST] <BtbN> Even when hardware encoded, I don't see the point over h264 [10:52:21 CEST] <alone> ffv1 have lossless too? [10:52:27 CEST] <furq> ffv1 is lossless [10:52:33 CEST] <alone> just a moment [10:52:41 CEST] <BtbN> if you want player compatiblity, it's not the best idea though [10:52:52 CEST] <furq> the same is true of x265 lossless though [10:53:01 CEST] <alone> no, i am fun on mplayer, now - on MPV [10:53:02 CEST] <alone> ;) [10:53:04 CEST] <alone> it's only for me. [10:53:07 CEST] <furq> mpv will be fine [10:53:12 CEST] <alone> for my post analisys. [10:53:20 CEST] <alone> internal usage. [10:53:53 CEST] <furq> also qtrle might be worth looking into for screen capturing [10:53:54 CEST] <alone> yes, h265 not so.. distributed yet. [10:54:05 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:5:0 -vcodec qtrle -strftime 1 capture.mov [10:54:12 CEST] <alone> for qrtle i have this line. [10:54:16 CEST] <alone> this is working. [10:54:17 CEST] <furq> qtrle will either be surprisingly good or total shit [10:54:25 CEST] <furq> depending on what you're capturing [10:54:33 CEST] <alone> but sizes.. [10:54:40 CEST] <furq> yeah if it's massive then stick with ffv1 [10:55:06 CEST] <alone> i mean megabyes, no - GIGAbytes. of course 7zip will be compressing qrtle files VERY VERY good - 10 times. [10:55:42 CEST] <alone> ffv1 - dont know about it. [10:55:45 CEST] <alone> thank you [10:56:27 CEST] <alone> well, h265 lossless it's good ration with size. and after recording, i can always 7zip it to 1|2 or even 1|3 [10:56:36 CEST] <alone> it's OK but CPU!!!! 100% [10:56:37 CEST] <alone> ;) [10:56:43 CEST] <furq> it's probably not a good sign if you can compress it further [10:57:46 CEST] <alone> ok, of course i would to have something other codec with ffmpeg for my 3-4 colors, but i dont know [10:58:38 CEST] <alone> i guess ffv1 CAN be compressing VERY well with 7zip [10:58:56 CEST] <furq> i should hope not [10:59:10 CEST] <alone> hm... [10:59:35 CEST] <alone> do u have working line for ffv1? [11:00:56 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v ffv1 E:\Screen.Capturing\%yyyymmhhmmss%.mkv [11:01:09 CEST] <alone> ;) it's generated MKV but ... [11:01:39 CEST] <alone> oh! [11:01:47 CEST] <alone> mpv does not read it properly [11:01:52 CEST] <alone> my mplayer - does! [11:01:59 CEST] <alone> but mplayer does [11:02:21 CEST] <alone> mpv showing only gray and white squares ;) [11:02:23 CEST] <alone> funy. [11:02:27 CEST] <alone> funny. [11:02:29 CEST] <furq> weird [11:02:31 CEST] <furq> mpv should play it fine [11:02:48 CEST] <alone> yes, but it's seems some times [11:02:57 CEST] <alone> yes, i am agree. mpv - cool. but [11:03:45 CEST] <alone> well, 4 sec - 18MB [11:03:53 CEST] <alone> after 7zip - 8 mb [11:04:55 CEST] <durandal_1707> alone: pastebin your mpv output of playing that file [11:05:17 CEST] <alone> mpv myfile.mkv >123.txt [11:05:19 CEST] <alone> so? [11:06:15 CEST] <durandal_1707> alone: you dont know how to copy terminal output? [11:06:37 CEST] <alone> i am at windows 7 64. but >123.txt it's ok? [11:06:51 CEST] <durandal_1707> nope [11:06:57 CEST] <furq> what mpv version [11:07:04 CEST] <alone> https://pastebin.com/L4EPB3Yf [11:07:11 CEST] <alone> just a moment [11:07:47 CEST] <furq> bgra ffv1 works fine here in 0.26 [11:08:01 CEST] <alone> mpv --version? [11:08:02 CEST] <furq> so probably upgrade if you're on an older build [11:08:10 CEST] <furq> sure [11:08:48 CEST] <alone> empty ontput ;( with mpv --version [11:10:41 CEST] <alone> no! [11:11:13 CEST] <alone> with LATEST (i am downloaded it 1 minutes ago) - this is same [11:11:22 CEST] <alone> squres... white and gray [11:11:24 CEST] <alone> really. [11:12:35 CEST] <alone> well, may be windows issue [11:12:38 CEST] <alone> i dont know [11:15:03 CEST] <alone> BtbN, why 55% of CPU usage with nvenc? [11:15:13 CEST] <alone> if it's dedicated chip for encoding? [11:22:38 CEST] <alone> . [11:23:38 CEST] <alone-y> BtbN, why 55% of CPU usage with nvenc? [11:23:40 CEST] <alone-y> if it's dedicated chip for encoding? [11:24:02 CEST] <BtbN> Because you're doing something else on the CPU, or are not actually using nvenc. [11:24:56 CEST] <alone-y> but without ffmpeg it's 5-8% [11:24:58 CEST] <alone-y> not more. [11:25:15 CEST] <alone-y> with encoding 55% [11:27:49 CEST] <alone-y> i am closing all , besides mIRC [11:27:52 CEST] <alone-y> it's 25% [11:27:56 CEST] <alone-y> i guess Mozilla [11:29:55 CEST] <alone-y> interesting [11:30:05 CEST] <alone-y> mozilla was even at OTHER monitor [12:20:54 CEST] <wondiws> is it easy to update deprecated code? What do I need to use instead of avcodec_encode_audio2? [12:26:17 CEST] <durandal_1707> its in headers [12:26:44 CEST] <DHE> you use avcodec_send_frame and avcodec_receive_packet [12:27:05 CEST] <wondiws> DHE, that is what I should use instead? [12:27:50 CEST] <DHE> check the docs for details. the semantics have changed a bit since one end may accept multiple inputs/outputs or may block if overfilled [12:31:48 CEST] <bigx> hello there, I have some troubles running a ffmpeg command [12:32:00 CEST] <bigx> here it is : ffmpeg -y -i result.png -hwaccel cuvid -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -b:v 10M -pix_fmt yuv420p -r 30 -an -filter_complex "[0:v][1:v]overlay=eval='init'[merge];[merge]lut3d=lut.cube" testResult.mp4 [12:32:42 CEST] <bigx> and here is the result: https://pastebin.com/hWyVvaaL [12:34:25 CEST] <bigx> from what I see, it seems a function is not implemented (Failed to inject frame into filter network: Function not implemented) [12:34:45 CEST] <jkqxz> bigx: You asked for hardware surface output from the decoder but your filter graph is software. Remove the "-hwaccel cuvid" [12:36:07 CEST] <bigx> jkqxz: thanks I try asap, so I will end up in a case as mentinned here (partial hw transcode case here) https://trac.ffmpeg.org/wiki/HWAccelIntro#CUDACUVIDNvDecode [12:37:10 CEST] <bigx> thanks jkqxz it works [12:37:26 CEST] <bigx> (but at 10fps on a Tesla M60 gpu :( ) [12:39:30 CEST] <bigx> one other stange thing is that: ffmpeg -y -hwaccel cuvid -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -b:v 10M -pix_fmt yuv420p -r 30 -an testResult.mp4 [12:39:36 CEST] <bigx> raises the same error [12:42:50 CEST] <jkqxz> -pix_fmt yuv420p is forcing a conversion in software. [12:42:58 CEST] <jkqxz> Remove it if you don't want that. [12:43:12 CEST] <bigx> yes just noticed it [12:49:03 CEST] <bigx> darn, i feel sad, because I top at 10 fps because of the filters :( [12:49:28 CEST] <bigx> does anyone see any improvements here ? [12:49:36 CEST] <bigx> ffmpeg -y -i result.png -c:v vp8_cuvid -i test.webm -c:v h264_nvenc -preset llhq -filter_complex "[0:v][1:v]overlay=eval='init'[merge];[merge]lut3d=lut.cube" testResult.mp4 [13:15:54 CEST] <deepak> Hi! I am trying to understand this command ffmpeg -f concat -safe 0 -i mylist.txt -c copy output [13:16:04 CEST] <deepak> I am unable to get what -f means [13:16:08 CEST] <JEEB> demuxer [13:16:18 CEST] <deepak> and what concat as a filter mean? [13:16:28 CEST] <JEEB> so there's a special "demuxer" called "concat" [13:16:36 CEST] <JEEB> it's not a filter :) [13:16:41 CEST] <JEEB> although there's also a filter [13:17:05 CEST] <JEEB> (there's like three different concat things in FFmpeg, all of which work for some specific use case) [13:17:14 CEST] <JEEB> concat protocol, concat demuxer, concat filter [13:17:18 CEST] <q66> concat filter lets you concat wildly different streams [13:17:30 CEST] <q66> demuxer when the codec/params are the same [13:18:02 CEST] <deepak> so how can I identify is the given command using it concat as demux/filter or protocol? [13:18:26 CEST] <q66> by reading the wiki page [13:18:28 CEST] <deepak> q66:thanks [13:18:51 CEST] <q66> https://trac.ffmpeg.org/wiki/Concatenate [15:39:03 CEST] <bigx> hello, it seems vp8_cuvid decoder doesnt handle transparency?? [15:39:30 CEST] <JEEB> not surprising. it's a specific feature of VPx formats and not required for the actual base YCbCr [15:39:46 CEST] <JEEB> also HW decoders generally don't output data formats with alpha [15:40:05 CEST] <JEEB> you either get 8bit YCbCr or 10bit YCbCr, 4:2:0 [15:40:31 CEST] <JEEB> so if you need the alpha from the encoded file, then SW decoding from libvpx I think is the only alternative? [15:40:41 CEST] <JEEB> since I don't know if the libavcodec decoder supports the alpha stuff [15:53:52 CEST] <bigx> JEEB: yes libvpx preserves alpha [16:00:54 CEST] <alqemyst> hi, does anybody knows what 3.3.x changes to quick sync in comparison with 3.2.x? [16:01:08 CEST] <alqemyst> e.g. ffmpeg -y -i udp://239.192.120.102:1234 -map 0:v:0 -map 0:a:0 -c:v h264_qsv -profile:v high -preset:v veryfast -b:v 2M -maxrate:v 2M -c:a libfdk_aac -b:a 64k -f rawvideo /dev/null [16:01:25 CEST] <alqemyst> works with 3.2.7, but with 3.3.3 it throws [16:01:33 CEST] <alqemyst> Selected ratecontrol mode is not supported by the QSV runtime. Choose a different mode. [16:01:33 CEST] <alqemyst> Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height [18:24:42 CEST] <thebombzen> alqemyst: why are you using -f rawvideo [18:24:56 CEST] <thebombzen> I believe you're trying to use -f null - [18:26:53 CEST] <alqemyst> yes, but that's not too important now [18:27:04 CEST] <alqemyst> thanks for correction [18:27:30 CEST] <thebombzen> either way [18:27:36 CEST] <alqemyst> whatever you specify as output it will fail on 3.3.x [18:27:56 CEST] <alqemyst> oki [18:44:11 CEST] <alqemyst> 3.2.7: https://pastebin.com/XGbg1w02 [18:44:23 CEST] <alqemyst> 3.3.3: https://pastebin.com/WKTynFdL [18:47:03 CEST] <c_14> set -look_ahead 0 [18:48:10 CEST] <alqemyst> then it seems like it is encoding, but console is filled with: [18:48:11 CEST] <alqemyst> [h264_qsv @ 0x29db760] Warning during encoding: incompatible video parameters (5) [18:49:34 CEST] <alqemyst> also [18:49:36 CEST] <alqemyst> [h264_qsv @ 0x3934840] Warning in encoder initialization: partial acceleration (4) [18:51:48 CEST] <c_14> can you bisect? [18:52:02 CEST] <c_14> or try a git-master build [18:52:13 CEST] <alqemyst> sure [18:57:08 CEST] <alqemyst> with git master it is even worse [18:57:11 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] No device available for encoder (device type qsv for codec h264_qsv). [18:57:11 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Encoder will work with partial HW acceleration [18:57:12 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Warning in encoder initialization: partial acceleration (4) [18:57:27 CEST] <alqemyst> and then again filled with: [18:57:29 CEST] <alqemyst> [h264_qsv @ 0x2da0ce0] Warning during encoding: incompatible video parameters (5) [18:58:21 CEST] <c_14> Try a bisect between 3.3.3 and 3.2.7 and/or create a bugreport with as much information (and terminal output) as possible [18:58:25 CEST] <c_14> seems like a regression [18:59:01 CEST] <alqemyst> I thought so [18:59:05 CEST] <alqemyst> it seems like [18:59:06 CEST] <alqemyst> https://trac.ffmpeg.org/ticket/6418 [18:59:57 CEST] <c_14> 3 months ago might fit, if you can find the commit and add info to the tracker it should help [19:00:21 CEST] <mozzarella> guys [19:00:27 CEST] <alqemyst> thanks [19:00:38 CEST] <mozzarella> why do I keep getting "Past duration too large"? [19:11:51 CEST] <IchGucksLive> hi what is the oposit argument to -shortest [19:12:05 CEST] <mozzarella> -longest [19:12:08 CEST] <IchGucksLive> -r 25 -filter:v "setpts=6*PTS" -shortest [19:12:55 CEST] <IchGucksLive> Unrecognized option 'longest'. [19:16:13 CEST] <kepstin> IchGucksLive: the opposite to -shortest is to not use -shortest [19:16:25 CEST] <kepstin> the default is to make the output the length of the longest stream [19:16:55 CEST] <kepstin> (it won't extend any streams to that length, you have to use filters for that if desired) [19:45:46 CEST] <Peste_Bubonica> Hi folks. I'm trying to stream rtsp through ffserver. The stream is a 1280x720 VP8, 30fps. In FFServer, i'm using webm format, with libvpx, with same resolution, but with 23fps. The problem is that its very slow. ffmpeg sends only 9fps to ffserver and many frames is lost. The connection with the rtsp source is good. I can watch the stream very well with mpv. [19:46:45 CEST] <Peste_Bubonica> this is the feed configuration: https://pastebin.com/AgLgHuBi [19:47:03 CEST] <Peste_Bubonica> and ffmpeg command line: ffmpeg -threads 8 -rtsp_transport tcp -i "rtsp://admin:1234@192.168.0.44:554" http://localhost:8090/feed.ffm [20:09:22 CEST] <thunfisch> Peste_Bubonica: Is your machine capable of encoding to webm in realtime? last I checked it's pretty slow. [20:09:55 CEST] <thunfisch> also ffserver is deprecated afaik [20:10:07 CEST] <thunfisch> might want to take a look at nginx-rtmp or the likes [20:10:44 CEST] <Peste_Bubonica> thunfisch, its a i7 4790 @ 3.6-4.0 ghz [20:11:08 CEST] <Peste_Bubonica> do you think that its no capable to produce 23fps? [20:12:30 CEST] <thunfisch> Peste_Bubonica: could very well be, afaik webm can only use a single core for encoding [20:12:55 CEST] <thunfisch> have you tried just encoding a file with these specs and seeing if it can do realtime? [20:13:16 CEST] <thunfisch> my i5-7200U @ 2.5ghz is doing 0.8x right now [20:13:44 CEST] <Peste_Bubonica> thunfisch, thanks for the tip of nginx. I will check. Can I continue to use ffmpeg to send the stream to nginx? [20:14:26 CEST] <thunfisch> Peste_Bubonica: yes, you can easily send the stream with ffmpeg. you can even use ffmpeg to transcode the incoming streams. the module allows to launch commands that read from the server, transcode to your desired format and push back [20:15:54 CEST] <Peste_Bubonica> very nice. ffserver can't stream h264 right? This camera sends h264, so i'm in hope that I don't even need to transcode if possible [20:16:10 CEST] <furq> ffserver can't really stream anything [20:16:17 CEST] <Peste_Bubonica> lol :) [20:16:28 CEST] <furq> but yeah you can just send h264 directly to nginx-rtmp [20:16:37 CEST] <thunfisch> don't know. but with nginx-rtmp you don't reencode at all [20:16:42 CEST] <thunfisch> it just spits out what it is given [20:16:57 CEST] <Peste_Bubonica> I will try. [20:16:59 CEST] <furq> x264 is much faster than libvpx anyway [20:17:05 CEST] <furq> in case you need to reduce the bandwidth, filter etc [20:17:05 CEST] <thunfisch> ^ [20:17:23 CEST] <furq> you can use multiple cores with libvpx but it's a nightmare getting it to work [20:17:27 CEST] <thunfisch> yeah, x264 is just fine for streaming. you can fiddle around with the settings to reach desired bitrate [20:27:09 CEST] <Peste_Bubonica> if I can, I will use x264. Its possible that some devices may not send h264. In this case, I will try to encode it using the nvidia encoder [20:27:35 CEST] <thunfisch> why not using the cpu? [20:27:39 CEST] <Peste_Bubonica> I will try with nginx now. i've already compiled it here with rtsp module.. [20:28:11 CEST] <Peste_Bubonica> thunfisch, in my tests, using my vga was faster [20:28:42 CEST] <Peste_Bubonica> localtests of course, i was not using rtmp, only encoding some videos [20:30:36 CEST] <Peste_Bubonica> using ffmpeg with hevc_nvenc I was able to produce 68fps converting a 4k h264, with 8000k bitrate, hq preset and 2pass [20:30:46 CEST] <squarecircle> ohai [20:31:54 CEST] <squarecircle> as I have soon access to two Xeon Phi: Does is there a way to accellerate the video decoding with these coprocessors? [20:33:35 CEST] <DHE> as I understand it they're not very good for that sort of thing. the Xeon Phi is supposed to be half way between a regular CPU and a GPU, but basically doesn't do either very well [20:37:08 CEST] <furq> they're incredibly good at very specific workloads afaik [20:37:14 CEST] <furq> and mediocre at everything else [20:38:55 CEST] <squarecircle> They support openmp [20:39:01 CEST] <squarecircle> and openCL [20:39:09 CEST] <squarecircle> that sounds promising [20:39:31 CEST] <squarecircle> as the normal ffmpag decoder is CPU based afaik [20:39:42 CEST] <squarecircle> if not escpecially told to use a gpu [20:40:47 CEST] <DHE> well ffmpeg doesn't have opencl or openmp for decoding or encoding. x264 opencl is weak at very best [20:40:53 CEST] <JEEB> GPUs' actual computing parts are useful for either graphics, or heavily threadable and low sync ratio work [20:41:02 CEST] <JEEB> and IIRC xeon phi is similar [20:41:11 CEST] <JEEB> at least regarding the last part [20:41:30 CEST] <DHE> yes, but as I recall it's just a ~72 core x86 CPU with some advanced AVX-type instructions. (including AVX-512) [20:41:40 CEST] <JEEB> thus trying to expect any sort of magical result from them for use cases which don't have heavy threading or low sync ratio [20:41:58 CEST] <JEEB> DHE: I think by now there's like multiple of them, too. the older was even more specific [20:42:30 CEST] <JEEB> the newer might be like that, but video decoding or encoding is not necessarily something where many low-speed cores can help you a lot [20:42:52 CEST] <JEEB> such things are very good with heavily threadable and NUMA-aware workloads [20:42:53 CEST] <jkqxz> Xeon Phi is completely useless for video because all of its power is floating point. Video is pretty much entirely fixed point. [20:42:59 CEST] <JEEB> yes, that too [20:44:01 CEST] <DHE> I just threw some E5-2698 v4 chips at my software video encoding and made sure my NUMA settings were good [20:45:25 CEST] <furq> doesn't xeon phi use some weird custom simd format as well [20:45:41 CEST] <furq> so any sse/avx stuff won't work [20:46:18 CEST] <DHE> depends. the first generation of phi was actually a pentium1 modified with the advanced instructions, so I can imagine some old generation stuf like SSE 1 might not work [20:46:25 CEST] <JEEB> yea [20:46:30 CEST] <JEEB> the first gen was much more special [20:46:35 CEST] <DHE> that and a further reading of the spec sheet turned me off it [20:46:50 CEST] <JEEB> I had some general looks and quickly noticed it wouldn't help my use cases [20:46:58 CEST] <JEEB> => no further detailed looks [20:47:29 CEST] <jkqxz> Buying huge chips made to maximise floating point throughput to do video is really not a good idea. This would apply to graphics cards as well, except that the consumer volume pushes the price down such that the small amount of video cicuitry on the side starts to look quite attractive even when you know that 95% of the chip will be idle. [20:48:32 CEST] <JEEB> GPUs could actually be used for stuff like actual colorspace conversions and scaling - like they are used with players. of course also depends on how much time goes into up/download [20:48:51 CEST] <JEEB> but video players clearly show that if you give actual image processing to a GPU it actually works :D [20:48:56 CEST] <JEEB> compression, though, nope [20:49:01 CEST] <JEEB> (other than the ASICs) [20:51:23 CEST] <DHE> but isn't the nvenc chip one of said ASICs? (probably not a good one but still) [20:51:29 CEST] <furq> wake me up when ffmpeg has opencl nnedi3 [20:51:31 CEST] <jkqxz> Yeah, the rest of the chip can be useful for peripheral things so it isn't completely idle, but generally that wasn't the bit which you were really optimising for in server-type applications. [20:51:40 CEST] <JEEB> yup [20:51:46 CEST] <JEEB> which is why FFmpeg doesn't have that stuff :) [20:51:58 CEST] <JEEB> DHE: yes, nvenc uses the ASICs on the boards [20:52:39 CEST] <DHE> oh you mean in the context of opencl encoding vs ASIC encoding [20:53:04 CEST] <JEEB> no, I was speaking of stuff where the (f.ex. GPU) would actually be useful [20:53:12 CEST] <JEEB> as opposed to trying to use it for actual encoding [20:55:17 CEST] <DHE> I guess my question is, if someone wanted to build the "optimal" encoder farm for a site like Twitch.tv, what's the best way to go? Not xeons, not opencl GPUs, what's left? [20:56:25 CEST] <furq> why not xeons [20:56:44 CEST] <DHE> that should say xeon phis [20:56:52 CEST] <jkqxz> It probably is densest normal Xeons. (Or EPYC - that does look like it will be pretty good for this, though I don't know of any good benchmarks yet.) [20:56:55 CEST] <furq> oh [20:57:00 CEST] <furq> well yeah it is probably xeons then [20:57:05 CEST] <furq> or EPYC THREADRIPPER [20:57:14 CEST] <DHE> Epyc looks very appealing, but the site I normally buy servers from sold out of them recently... [20:57:16 CEST] <DHE> dunno if that's good or bad [20:58:03 CEST] <furq> i still can't believe they called it that [20:58:17 CEST] <furq> i'm surprised it doesn't have rgb leds [20:58:51 CEST] <furq> the die should be in the shape of a gun [20:58:52 CEST] <DHE> I'm curious though. Someone needs to do a really in-depth review of an Epyc. right now all I have are like cinebench scores [20:59:24 CEST] <DHE> Ryzen (Conusmer) is 2-channel RAM and has 1 Zen die. Threadripper is 4-channel memory and has 2 Zen dies. Epyc has 8-channels memory and 4 Zen dies. [20:59:41 CEST] <DHE> so... is Epyc going to be a 4-way NUMA machine in each socket? [21:00:19 CEST] <BtbN> I don't think it will behave like NUMA [21:00:28 CEST] <BtbN> after all, they all still access the same memory [21:00:39 CEST] <jkqxz> Certainly to some degree (not clear how much), but video is very amenable to NUMA so that's just fine. [21:01:00 CEST] <BtbN> An Intel System with 4 Sockets is also not NUMA [21:01:03 CEST] <DHE> BtbN: testing has shown an access latency penalty when communicating between the Zen dies [21:01:17 CEST] <BtbN> why would a Zen one with 4 dies in one chip be any different? [21:01:24 CEST] <DHE> BtbN: but a 2-socket Intel system is NUMA... (which is all I have access to) [21:01:34 CEST] <BtbN> The ones I have are not [21:01:35 CEST] <jkqxz> Er, what? Yes it is. What does NUMA even mean if you define that as not? [21:01:56 CEST] <jkqxz> Clearly there are different regions of Memory to which the Access is Non-Uniform. [21:02:29 CEST] <DHE> socket-to-socket is obvious. my question is, is core-to-core? it depends whether the chip is 4x 2-channel memory controllers, or a single 8-channel controller [21:02:40 CEST] <DHE> http://imgur.com/a/1b9zd <-- Epyc with the heatspreader cover removed [21:03:02 CEST] <BtbN> The memory controler is connected to the same infinity fabric as all the Chips. So it definitely could be a single big one [21:03:19 CEST] <BtbN> but unless AMD or testing reveals it, nobody will know for sure [21:03:42 CEST] <BtbN> The two CCXs in a single Zen die definitely have only one memory controler [21:03:57 CEST] <furq> does epyc infinity fabric give +60 to cast speed [21:04:13 CEST] <BtbN> depends on your RAM clock! [21:07:57 CEST] <squarecircle> thanks [21:08:25 CEST] <squarecircle> I'll still do the ffpmeg stuff on cpus [21:08:45 CEST] <squarecircle> and search for some cool stuff I can fo with the Xeon Phis [21:14:15 CEST] <DHE> furq: well, the inter-socket infinityfabric is made of 64 PCI-E lanes... so that's ballpark 64 GB/sec of data available there [21:14:35 CEST] <DHE> I definitely want one [21:15:45 CEST] <BtbN> How much does Intel have? [21:15:55 CEST] <BtbN> Between Sockets I mean [21:15:59 CEST] <BtbN> 9.6 something QPI [21:17:14 CEST] <DHE> intel has a dedicated lane running at 9.6 giga-transactions per second. gotta find the size of a transaction though [21:17:16 CEST] <DHE> also I think it's 2 lanes [21:21:26 CEST] <BtbN> Will there be multi socket Epyc? [21:21:32 CEST] <BtbN> And what will be between the sockets then? [21:21:37 CEST] <DHE> dual sockets exist, yes [21:21:37 CEST] <BtbN> Not 64 lanes I assume [21:22:01 CEST] <DHE> each CPU supports 128 PCI lanes. In single socket you get them all for normal use (though there are limits to breaking them down, so you can't have 128 connections of 1x each) [21:22:26 CEST] <DHE> or in dual socket, 64 lanes from each form their interconnect and you still get 128 total lanes available to the motherboard [21:24:59 CEST] <BtbN> damn, that's pretty overkill [21:26:08 CEST] <spalpeen> i would like to decode only a small crop of incoming stream, can someone point me to what section of code I should look at [21:26:21 CEST] <BtbN> "decode a small crop"? [21:26:28 CEST] <BtbN> You cannot crop the image before decoding. [21:26:58 CEST] <spalpeen> i would like to decode only a small section of image [21:27:12 CEST] <spalpeen> e.g. ignore all macroblocks outside a certain region [21:27:21 CEST] <BtbN> that's not possible [21:27:38 CEST] <spalpeen> i am willing to have some error on edge blocks [21:27:52 CEST] <kepstin> AMD definitely has the memory controllers attached to specified dies; going to off-die memory requires going through the infinity fabric and has a latency hit. [21:28:23 CEST] <spalpeen> somewhere in the decoding there is a loop over macroblocks i assume [21:28:36 CEST] <spalpeen> i would like to recode this to only loop over macroblocks in ROI [21:28:57 CEST] <kepstin> I've only seen details about threadripper, but I assume epyc is similar; they have both interleaved memory modes with consistent average latency for all ram and numa configurations there. [21:29:17 CEST] <kepstin> (via bios switch) [21:31:28 CEST] <kepstin> the linkage between sockets in epyc looks interesting; each die in one socket appears to get a 16 lane link to the corresponding die in the other socket, assuming I understand what I've read correctly. [21:33:28 CEST] <kepstin> so it's a max of 2 hops from any particular die to the memory controller on any other die. [22:03:03 CEST] <DHE> kepstin: that is correct [22:31:51 CEST] <Peste_Bubonica> thunfisch, i'm trying to send a stream to nginx, but i receive got this error: handshake: unexpected RTMP version: 80 [22:32:12 CEST] <Peste_Bubonica> this error is from nginx. I can't find any tips googling it. [22:33:20 CEST] <Peste_Bubonica> this is the error on ffmpeg: Error writing trailer of http://localhost:1935/mytv: Connection reset by peer [22:36:51 CEST] <kepstin> Peste_Bubonica: You need to use an rtmp:// url in ffmpeg... [22:37:26 CEST] <Peste_Bubonica> kepstin, oh man, sorry for this noob error [22:37:45 CEST] <Peste_Bubonica> I was using http with ffserver, and keep usint if after switch to nginx [22:37:57 CEST] <Peste_Bubonica> thanks for your answer [22:51:51 CEST] <kiroma> Can you accelerate filters? [22:53:17 CEST] <DHE> opencl is available for 2 filters. but that's all... [22:57:31 CEST] <BtbN> it's also not very effective, due to heavy copying back and forth [00:00:00 CEST] --- Thu Sep 7 2017

1 0

ffmpeg-devel.log.20170905
by burek 06 Sep '17

06 Sep '17

[00:04:00 CEST] <nevcairiel> is it just me, or does the v4l2 api sound terrible [00:09:34 CEST] <jkqxz> I don't think it's terrible in this aspect, I think the submitter is just not very clueful in some places. [00:09:52 CEST] <jkqxz> (Certainly it is terrible in other places.) [00:14:51 CEST] <nevcairiel> i guess that might also be a reason, i havent really read up on it, just taken his explanations [00:17:30 CEST] <jamrial> jkqxz: "Feel free to submit a patch to avcodec.h which changes the definition of the API." [00:17:32 CEST] <jamrial> y tho [00:18:40 CEST] <nevcairiel> the api design is fine [00:20:13 CEST] <nevcairiel> and we cant just change how the api works anyway [00:20:27 CEST] <jkqxz> Implicitly, "... and everyone will reject it." [00:21:11 CEST] <nevcairiel> not sure he'll understand it that way [00:21:28 CEST] <jkqxz> But I don't think they have actually read it at all, and having to write something there would require reading and understanding it. [00:22:21 CEST] <jkqxz> At which point hopefully it would clear up the issue. [04:13:13 CEST] <stevenliu> wm4: hello? [08:49:07 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:6faa1275a2e1: avfilter: add despill filter [10:40:41 CEST] <wm4> oh, we also have 2 ASF demuxers [10:40:47 CEST] <wm4> fucking insane [10:44:10 CEST] <durandal_1707> both have good and bad points [11:09:25 CEST] <LongWork> jkqxz: i talked to wm4 about removing the hwaccels stuff i nthe rockchip decoder and it seems that would break mpv as well ... [11:09:46 CEST] <LongWork> i'm not sure what the reason is , maybe he can comment [11:10:13 CEST] <wm4> get_format excludes opaque pixfmts if there's no aVHWAccel entry [11:11:15 CEST] <wm4> so it would break opaque decoding completely [11:11:39 CEST] <LongWork> he also asked to remove that : https://github.com/LongChair/FFmpeg/blob/5bb3e264e67c8ea53ecd60050dd6ece891… [11:11:50 CEST] <LongWork> as this seemed to lead to some crash on debian [11:12:13 CEST] <LongWork> and replace it with avctx->pix_fmt = AV_PIX_FMT_DRM_PRIME [11:12:43 CEST] <nevcairiel> you always need an ordinary software format if you're going to call ff_get_format [11:13:16 CEST] <nevcairiel> if you can only output an opaque hardware format and nothing else (which seems like it would make the thing basically useless, imho), you shouldnt call get_format [11:17:57 CEST] <wm4> hm yeah, if there's no sw format, calling get_format would be pointless [11:18:27 CEST] <nevcairiel> i think the code might even expect there to be one [11:19:01 CEST] <nevcairiel> (and as a bonus, if you dont need ff_get_format, you also dont need the dummy hwaccel) [11:20:45 CEST] <wm4> you could argue the avhwaccel should be there to inform the API user that support is present [11:21:08 CEST] <wm4> (although I'm not using that in mpv, because AVHWAccel is completely useless due to being incomplete) [11:24:47 CEST] <stevenliu> wm4: is that dashdec ok? [11:25:10 CEST] <jkqxz> The code has an assert that there is an sw format. It's at level 2 so you don't see it normally, but it is a hard requirement of how it works. [11:25:16 CEST] <stevenliu> will push if ok :D [11:25:57 CEST] <wm4> stevenliu: my ok was for the change av_free -> xmlFree [11:26:16 CEST] <stevenliu> mhmm, others? [11:26:20 CEST] <wm4> stevenliu: I don't think others would be comfortable with dashdec in its current state yet [11:26:30 CEST] <wm4> but not sure [11:26:49 CEST] <jkqxz> Anyway, there is exactly one format and the hwaccel does nothing, so IMO the lavc implementation should reflect that. [11:26:51 CEST] <wm4> I also pointed out loads of code duplication with hls.c, which probably wasn't fixed [11:27:29 CEST] <jkqxz> Callers can adapt if they have weird hard requirements on get_format() being called. [11:27:57 CEST] <wm4> jkqxz: the only reason we keep adding AVHWaccels for full-stream decoders is because ff_get_format wants it [11:27:57 CEST] <stevenliu> I think the code duplication with hls.c maybe make a fragutils.c willl ok? [11:28:13 CEST] <wm4> stevenliu: that might be much better [11:29:15 CEST] <stevenliu> I'll do it this weekend :D [11:30:40 CEST] <wm4> great [11:32:22 CEST] <wm4> jkqxz: so I agree that AVHWAccels could probably be skipped if they have no function, but still it'd be nice if there were some meta information about hw decoders [11:34:25 CEST] <LongWork> wm4, jkqxz: thanks, that answers the questions i had for now :) [11:36:11 CEST] <stevenliu> rcombs: hello? is the dashdec have the printf fmt problem now? [11:37:24 CEST] <stevenliu> i have apply Timo Rothenpieler's suggestion. [11:47:04 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:2c10f054c2bc: avfilter/avf_avectorscope: add possibility to auto zoom [11:56:53 CEST] <cone-076> ffmpeg 03Paul B Mahol 07master:a5e6cd79ec34: avfilter/avf_avectorscope: fix mistake in previous commit [12:13:14 CEST] <jkqxz> wm4: By meta information, do you mean like the hw_configs thing in the RFC patch a few weeks ago? Or do you want more than that? [12:14:12 CEST] <wm4> I don't remember that patch, what was the title? [12:14:50 CEST] <jkqxz> <https://lists.libav.org/pipermail/libav-devel/2017-August/084592.html> [12:18:59 CEST] <wm4> jkqxz: ah yes [12:19:23 CEST] <wm4> as long as AVCodecHWConfig.device_type can be NONE [12:20:15 CEST] <jkqxz> NONE with a non-NONE format? [12:21:10 CEST] <wm4> yes [12:21:32 CEST] <wm4> there's some legacy crap around that, like mmal and crystalhd [12:21:52 CEST] <jkqxz> I'm not sure that's meaningful. It might as well be in the pix_fmts list. [12:22:19 CEST] <jkqxz> (Is it in the pix_fmts list?) [12:22:36 CEST] <jkqxz> For MMAL, yes. [12:23:17 CEST] <wm4> what I'd actually like to know about a codec is: is it hardware accelerated? what API does it belong to (like vaapi, vdpau, mmal)? does it need a hw device and which? does it supported hwaccel style decoding (initiating decoding with get_format)? [12:23:53 CEST] <wm4> I guess the pixfmt is interesting too [12:24:04 CEST] <wm4> at least for true hwaccels [12:24:37 CEST] <jkqxz> get_format() seems orthogonal. It will be called if there are multiple choices or you might need hw_frames_ctx, otherwise it need not. [12:24:54 CEST] <jkqxz> The hw device part is what I'm trying to solve here. [12:25:18 CEST] <jkqxz> It also solves the formats for things with devices, but there is a hole for the things without. [12:26:15 CEST] <jkqxz> If we said that the AV_PIX_FMT_FLAG_HWACCEL formats must appear in the pix_fmts list, would that be sufficient? [12:28:33 CEST] <wm4> I mean, for true hwaccels, I could switch between real decoder and hwaccel on demand [12:28:49 CEST] <wm4> can't do that with a full stream decoder, I'd have to setup everything when the codec is opened [12:37:37 CEST] <jkqxz> If you have a non-hw_device_ctx full-stream decoder then you don't know anything about the context it has used internally until the first frame comes out of it. [12:43:10 CEST] <cone-076> ffmpeg 03Clément BSsch 07master:516ac7bcc761: build: consistent spacing between lists (cosmetics) [15:25:53 CEST] <rcombs> stevenliu: looks to be safe now, yes [15:40:21 CEST] <ubitux> any reason to hold on VDA or it's still too early? [15:40:38 CEST] <ubitux> it's really causing me trouble with my configure changes because i can't test it [15:40:48 CEST] <ubitux> since the osx i have doesn't even have it [15:41:08 CEST] <ubitux> and it looks like we have 2 legacy layers of vda [15:45:33 CEST] <wm4> yes we do [15:45:41 CEST] <wm4> and it mixes with videotoolbox in bad ways [15:55:51 CEST] <BBB> ubitux: I think we can probably remove it [15:56:14 CEST] <BBB> ubitux: new updates for osx are free anyway, so theres not many systems out there that dont support vtb [15:57:31 CEST] <ubitux> RFC on the ml [16:00:07 CEST] <nevcairiel> whats the OS requirements for vtb? [16:00:49 CEST] <BBB> 10.8+? [16:00:51 CEST] <BBB> says apple docs [16:00:56 CEST] <BBB> https://developer.apple.com/documentation/videotoolbox [16:01:13 CEST] <BBB> macOS 10.8+; iOS 6.0+; etc. [16:08:56 CEST] <jamrial> ubitux, BBB: whenever you have time, could you check the audiotoolboxdec patches i sent some months ago? [16:09:17 CEST] <jamrial> rcombs is too lazy [16:09:27 CEST] <BBB> I can try... [16:09:36 CEST] <rcombs> I thought I checked those [16:10:20 CEST] <ubitux> jamrial: Subject? [16:10:21 CEST] <jamrial> rcombs: you didn't reply to the ml patchset, and i don't recall you commenting here [16:10:33 CEST] <jamrial> sorry if you did the latter and i missed it [16:10:56 CEST] <jamrial> ubitux: "[PATCH 1/2] avcodec/audiotoolboxdec: always use a copy of the AVCodecContext extradata" [16:11:20 CEST] <jamrial> it's three patches. the first two are memleak fixes, the third is a port to the autobsf at the decoder level [16:11:40 CEST] <jamrial> it's all guesswork since i have no way to test it :p [16:12:10 CEST] <rcombs> oh yeah, I looked over them but didn't get a chance to test at the time, and then forgot about it [17:23:12 CEST] <durandal_1707> ubitux: that film grain that you linked is extremly slow [17:24:39 CEST] <ubitux> you mean the example program? that's usually just a PoC with stupid code [17:24:49 CEST] <ubitux> i mean, just a demo [17:25:01 CEST] <ubitux> you think the logic has flaw speed wise? [17:27:32 CEST] <durandal_1707> its very complicated, qcif takes 6 seconds to filter [17:32:29 CEST] <cone-076> ffmpeg 03Karthick J 07master:837c55e07271: avformat/hlsenc: Added configuration to override HTTP User-Agent [17:33:18 CEST] <ubitux> okay, too bad then [17:35:20 CEST] <atomnuker> film grain filter? [17:41:17 CEST] <ubitux> is it me or check_header_objcc is broken? [17:41:25 CEST] <ubitux> enable_safe $headers [17:41:32 CEST] <ubitux> it's not setting $headers [17:41:42 CEST] <ubitux> currently, if i shuffle some stuff a little [17:41:52 CEST] <ubitux> it ends up adding psapi.h and window.h [17:41:55 CEST] <ubitux> & [17:41:59 CEST] <ubitux> how can this even work currently [17:42:33 CEST] <ubitux> atomnuker: http://www.ipol.im/pub/art/2017/192/ [17:59:39 CEST] <ubitux> lol wtfffff [18:00:34 CEST] <ubitux> header=AVFoundation/AVFoundation.h headers=math.h [18:00:36 CEST] <ubitux> header=QuartzCore/CoreImage.h headers=CoreGraphics/CoreGraphics.h [18:00:41 CEST] Last message repeated 1 time(s). [18:00:41 CEST] <ubitux> so header is the tested header [18:00:47 CEST] <ubitux> and headers is the enabled header [18:01:02 CEST] <ubitux> i guess i understand now why these check are in some random places [18:01:07 CEST] <ubitux> and the deps completely broken [18:01:25 CEST] <ubitux> their positions were probably shuffled randomly til it worked [18:01:29 CEST] <ubitux> kill me now [18:01:31 CEST] <ubitux> T_T [18:02:06 CEST] <mateo`> killing your Apple laptop should be enough [18:13:45 CEST] <wm4> ubitux: well it's so complex that nobody really understands it [18:13:56 CEST] <wm4> that's what happens if you try to do such things in shell [18:45:32 CEST] <nevcairiel> the shell thing isnt a reason to write confusing code, the objcc stuff was probably just a hackjob and back in that time noone cared [19:22:45 CEST] <cone-076> ffmpeg 03James Almer 07master:9a174d203ae4: avfilter/lavfutils: remove usage of AVStream->codec [19:25:12 CEST] <jamrial> fate doesn't cover the above function, btw [19:25:26 CEST] <jamrial> showcqt, removelogo, cover_rect, etc, are all untested [19:25:38 CEST] <durandal_1707> jamrial: try them, test them [19:25:47 CEST] <jamrial> durandal_1707: i did before pushing [19:26:17 CEST] <jamrial> what i mean is that a fate test should be added by someone familiar with these filters [19:46:29 CEST] <durandal_1707> this nobody wants ^ [21:15:23 CEST] <doublya> Is there a way I can retrieve the srcFilter and dstFilter that were passed to sws_getContext() [22:16:46 CEST] <cone-076> ffmpeg 03Kaustubh Raste 07master:fa805df060ae: libavcodec/mips: Improve avc idct8 msa function [00:00:00 CEST] --- Wed Sep 6 2017

1 0

ffmpeg.log.20170905
by burek 06 Sep '17

06 Sep '17

[00:01:16 CEST] <markmedes2> klaxa: Beautiful, it worked!!! Thank you! [00:01:22 CEST] <klaxa> :) [11:12:10 CEST] <Ingvix> hey, I'm trying to convert mp4 with dvd_subtitles to mkv but when trying to include the subs I'm getting this error https://pastebin.com/0KsyucJ0 What could I try to get them work or is there some incompatibility issue that can't be easily overcome? [11:22:29 CEST] <Ingvix> I added -scodec dvdsub and now it's converting it [11:22:36 CEST] <Ingvix> not sure if the right way yet [16:09:19 CEST] <alone> hello, anyone know is it possible to have h264 screen capturing "lossless" with right colors? [16:09:50 CEST] <DHE> you should run libx264rgb then [16:10:48 CEST] <alone> i can do it by CPU with [16:11:01 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast output.mkv [16:11:10 CEST] <alone> but with nvenc - no [16:11:41 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:0:0 -c:v h264_nvenc -qp 0 -pix_fmt yuv420p h264-nVidia.mkv [16:12:22 CEST] <alone> this is near colors, but... i have almost only two colors at screen - red and green. [16:12:28 CEST] <alone> with first line - it's fully ok [16:13:02 CEST] <alone> with nvenc - near, but .. i dont know why. may be becouse it's not lossless already.. [16:13:28 CEST] <alone> just trying to do less CPU usage with nvenc [16:20:54 CEST] <c_14> alone: h264_nvenc should support yuv444p if you set the correct profile as well [16:21:02 CEST] <c_14> Assuming that's enough to give you correct colors [16:21:24 CEST] <c_14> Though you might also want to look into something like using zscale to convert colorspaces if you want 420p [16:22:17 CEST] <alone> c_14, i have Kepler core - GTX 640 card. i am scaring may be it's not possible to do a screen grabbing with "lossless" ? [16:23:56 CEST] <c_14> You can try what I said with -profile high444p -pix_fmt yuv444p, but if that doesn't work you'll have to look into using zscale to transform pixel formats which should prevent color degredation [16:24:15 CEST] <alone> "-profile high444p" says 0 invalid params, may be incorrect bit rate or width [16:25:18 CEST] <alone> thank you, but kepler can underspand only yuv420p [16:25:43 CEST] <alone> and profile - "high" [16:25:50 CEST] <alone> but not "high444p" [16:26:26 CEST] <alone> i have a little bit of understanding with colors, but you right, this is degradation [16:26:31 CEST] <c_14> ok, then you'll have to try https://ffmpeg.org/ffmpeg-filters.html#zscale-1 [16:26:57 CEST] <alone> with CPU i have two strings working for me VERY good: [16:27:06 CEST] <alone> @ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx265 -preset ultrafast -x265-params lossless=1 E:\Screen.Capturing\%yyyymmhhmmss%.mkv [16:27:17 CEST] <alone> ffmpeg -loglevel quiet -f gdigrab -i desktop -vf crop=1600:900:5:0 -c:v libx264 -profile:v high444 -crf 0 -preset:v ultrafast E:\Screen.Capturing\%yyyymmhhmmss%.mkv [16:27:23 CEST] <alone> for 264 and 265 [16:27:45 CEST] <alone> but for nvenc, 265 not working on Kepler cores [16:27:55 CEST] <alone> 264 - working, but without lossless supporting. [16:28:28 CEST] <alone> well, ok. crf 0 or qp 0 - will be near. but colors ;(((((( [16:29:14 CEST] <alone> it's not red (255,0,0) but dark red, it's not green (0,255,0) - it's light green [16:29:31 CEST] <c_14> Yeah, that's due to the RGB->YUV conversion [16:30:06 CEST] <c_14> Using zscale to do the RGB->YUV conversion should prevent that [16:30:17 CEST] <c_14> Since the internal converter is tuned for speed more than accuracy [16:30:58 CEST] <alone> sorry, for i am asking, do u have a working example of such conversation? [16:31:33 CEST] <alone> before this day, i has never know about colorspace ;) [16:31:47 CEST] <c_14> You mean an ffmpeg command? [16:32:04 CEST] <alone> yes? [16:32:11 CEST] <alone> i am trying to grabbing text [16:32:19 CEST] <c_14> -vf zscale,format=yuv420p should do it [16:32:35 CEST] <alone> with several colors - black. white.. green, red. that's all [16:33:03 CEST] <alone> just a moment i will try [16:33:47 CEST] <JEEB> (do note that zscale will angrily derp at you if you don't have the colorspace defined in the input ;) [16:34:15 CEST] <alone> fffmpeg -f gdigrab -i desktop -vf crop=1600:900:0:0 -c:v h264_nvenc -qp 0 -pix_fmt yuv420p -vf zscale,format=yuv420p h264-nVidia.mkv [16:34:16 CEST] <alone> ? [16:34:26 CEST] <JEEB> use only one vf [16:35:08 CEST] <alone> "NO NVenc capavle devices found " ;) no path beetween colorspaces [16:35:16 CEST] <alone> between. [16:36:56 CEST] <alone> ffmpeg -f gdigrab -i desktop -vf crop=1600:900:0:0 -c:v h264_nvenc -qp 0 -pix_fmt yuv420p -vf zscale h264-nVidia.mkv [16:37:00 CEST] <alone> same errors [16:46:12 CEST] <c_14> -vf crop,zscale,format=yuv420p [16:46:21 CEST] <c_14> you can only have one -vf in the command [16:50:52 CEST] <alone> ops [16:52:09 CEST] <alone> well, i guess it's not possible to use nvenc with right colors ;-(( [16:52:15 CEST] <alone> thank you guyz [16:54:21 CEST] <DHE> yuv444 support will vary by GPU [16:55:43 CEST] <alone> DHE - not Kepler [16:56:33 CEST] <alone> https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCFeatures [16:56:37 CEST] <DHE> that's the oldest generation isn't it? [16:57:04 CEST] <alone> well, 2012 year [16:57:17 CEST] <alone> fermi, kepler, maxwell [16:57:22 CEST] <alone> i guess so [16:58:06 CEST] <alone> i dont understand, i cant do some conversation for right color - or it's impossible? may be after conversation.. dont know [16:58:53 CEST] <alone> if you know something about it, please give me a link or cmd line ;-( [16:58:55 CEST] <alone> thank a lot [17:04:12 CEST] <DHE> colourspaces besides 444 means that multiple pixels will share at least some colour information with each other. but at the same time with H264 a lot of players (quicktime, many hardware players) only support 420 [18:33:32 CEST] <dafna_> hi, I use the ffmpeg library for decoding [18:34:03 CEST] <dafna_> can someone explain what is the field repeat_pict of AVFrame ? [18:34:39 CEST] <JEEB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#aef11fd783ad17b6841af82… [18:36:23 CEST] <JEEB> ah, it's used for stuff like soft telecine [18:37:04 CEST] <dafna_> so I can ignore it ? [18:37:48 CEST] <JEEB> or actually not sure... but at least in my code I don't touch that field since post-decode PTS is pretty much all I generally care about [18:38:02 CEST] <JEEB> (and duration if available) [18:40:16 CEST] <dafna_> ok , another question, there is the flag AV_PKT_FLAG_KEY in the packet flags [18:40:53 CEST] <dafna_> does this flag is mandatory as an input for dome decoders before calling avcodec_decode_video2 ? [18:41:08 CEST] <dafna_> or is it an output flag set by the decoder itself ? [18:43:22 CEST] <dafna_> do I need to check myself if the current packet contain a key frame and then set this flag accordingly ? [18:45:39 CEST] <JEEB> dafna_: that flag in the AVPacket generally means that it might be a random access point [18:46:04 CEST] <JEEB> generally I just tend to feed decoders things until I get a decoded picture successfully [18:51:38 CEST] <dafna_> amm, a key frame is the same as intra frame ? [18:51:58 CEST] <JEEB> yes, but in reality that flag often means IRAP [18:52:03 CEST] <JEEB> intra random access picture [18:52:04 CEST] <dafna_> what if I set this flag on all frames automaticlly ? [18:52:16 CEST] <JEEB> uhh [18:52:33 CEST] <JEEB> it doesn't make sense :P why would *you* be touching it [18:52:39 CEST] <JEEB> you're demuxing/decoding [18:52:43 CEST] <JEEB> it tells you about the input [18:53:22 CEST] <dafna_> so it's a data I get from the demuxer or the decoder ? [18:53:55 CEST] <JEEB> AVPackets are demuxed things (the function in lavf is called "read_frame" for some reason, but it's really "read_packet"), and AVFrames are decoded things [18:54:21 CEST] <JEEB> so you feed a decoder AVPackets and you receive AVFrames [18:54:25 CEST] <JEEB> and the other way with encoding [18:55:01 CEST] <dafna_> ok, so, in general my question is if I should set this flag ? [18:55:22 CEST] <dafna_> and if so , how can I know it's a key frame ? [18:55:54 CEST] <JEEB> your demuxer or encoder will know what to set it to [18:56:01 CEST] <JEEB> you do not override it [18:56:13 CEST] <JEEB> it's info for you, not something you can adjust with that specific flag [18:56:50 CEST] <dafna_> ok, [18:58:48 CEST] <dafna_> my senario is that I get encoded frame buffer from another function and I create the packet my self and set it every time with av_init_packet and av_packet_from_data [18:59:42 CEST] <JEEB> > encoded frame buffer [19:00:00 CEST] <JEEB> first word notes it's compressed, second is usually assigned to uncompressed stuff [19:00:15 CEST] <JEEB> at least I don't hear the wording "frame buffer" being used for compressed images [19:01:23 CEST] <dafna_> oh, ok , so whats the jargon ? [19:01:44 CEST] <JEEB> well what I meant is "actually tell me what you're talking about" [19:04:02 CEST] <dafna_> ok , so I get a buffer, this buffer that starts with 00 00 00 01 [19:04:20 CEST] <JEEB> that sounds like encoded AVC or HEVC [19:04:39 CEST] <dafna_> yap [19:04:48 CEST] <JEEB> sounds like you will want to pass it through the raw AVC or HEVC stream demuxer [19:04:52 CEST] <dafna_> and I have to decode it with avcodec_decode_video2 [19:04:53 CEST] <JEEB> that will then separate the NAL units etc [19:05:04 CEST] <JEEB> and no, you don't want to use decode_video2 [19:05:09 CEST] <JEEB> if you are writing code *now* [19:05:23 CEST] <JEEB> you want to use the push/pull (feed/receive) API [19:05:33 CEST] <dafna_> yes, I know it's deprecated [19:05:41 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__decoding.html [19:05:44 CEST] <dafna_> whats the difference ? [19:06:04 CEST] <JEEB> works better considering what you're doing, more straightforward [19:06:22 CEST] <JEEB> you feed until you can't feed a decoder any more, and you receive from it until it tells you to feed it more [19:06:26 CEST] <dafna_> amm, in what way it works better ? [19:06:28 CEST] <dafna_> faster ? [19:06:45 CEST] <JEEB> the logic you can put around it is much better [19:06:53 CEST] <JEEB> since it separates sending and receiving data [19:07:16 CEST] <JEEB> esp. since often with many formats the amount of things going in and out doesn't match [19:07:51 CEST] <JEEB> also it lets you use the same functions with audio, video and subtitles [19:08:00 CEST] <JEEB> instead of having separate functions and separate logic [19:08:44 CEST] <dafna_> but if I use this two functios one directly after the other [19:08:49 CEST] <dafna_> then does it metter ? [19:09:03 CEST] <dafna_> and my video has not audio anyway [19:09:14 CEST] <JEEB> because the logic is less simple even with just video [19:09:30 CEST] <JEEB> but suit yourself [19:09:41 CEST] <JEEB> I really prefer the way the send/receive APIs work [19:10:58 CEST] <dafna_> I guess I dont understand it enough to appriciate it [19:11:08 CEST] <dafna_> are you from the ffmpeg developers ? [19:11:19 CEST] <JEEB> I do work on the insides as well [19:11:29 CEST] <dafna_> for me it's like magic anyway [19:12:10 CEST] <dafna_> and the result of the 2 API for the outside user seems the same [19:12:38 CEST] <JEEB> https://www.ffmpeg.org/doxygen/trunk/group__lavc__encdec.html [19:12:43 CEST] <JEEB> this is a general overview of it [19:13:05 CEST] <JEEB> anyways, open a demuxer for the raw AVC or HEVC - whichever you're dealing with, and that will then cut it into AVPackets [19:13:05 CEST] <dafna_> thanks [19:13:20 CEST] <JEEB> then feed those AVPackets into the decoder [19:13:32 CEST] <JEEB> at some point you will start getting AVFrames back [19:13:57 CEST] <bencc> when encoding a video with -b:a -b:v and maxrate options, will the bitrate be the max or might be much lower? [19:14:14 CEST] <JEEB> depends on the encoder completely [19:14:16 CEST] <bencc> I'm encoding a video file for several HLS variants [19:14:22 CEST] <bencc> libx264 encoder [19:14:31 CEST] <JEEB> with libx264 you need to set both maxrate and bufsize [19:14:37 CEST] <JEEB> and that will keep you under the VBV/HRD limits [19:14:55 CEST] <JEEB> it will not use more bit rate than required by the general rate control, though [19:15:16 CEST] <JEEB> so your basic rate control mode controls the encoder, and then maxrate+bufsize limit the base rate control [19:15:25 CEST] <bencc> JEEB: so the final bitrate might be much lower than my maxrate and buffsize? [19:15:35 CEST] <JEEB> if using f.ex. CRF and the content is pure black [19:15:38 CEST] <JEEB> then yes [19:15:40 CEST] <bencc> what is the "basic rate control"? [19:15:48 CEST] <JEEB> basic rate control modes [19:15:54 CEST] <JEEB> either ABR, CRF etc [19:16:02 CEST] <JEEB> it's the basic rate control mode of libx264 [19:16:21 CEST] <JEEB> maxrate+bufsize is then to limit that to specific VBV/HRD parameters [19:17:11 CEST] <bencc> https://pastebin.com/WVpEvYWL [19:17:15 CEST] <bencc> this is the command I'm using [19:17:50 CEST] <JEEB> well, I've said all there is regarding maxrate&bufsize [19:18:08 CEST] <JEEB> also just fyi CRF and ABR don't go together [19:18:11 CEST] <JEEB> it's one or the otehr [19:18:12 CEST] <bencc> and this is one variant https://pastebin.com/x03W7Wcs [19:18:33 CEST] <bigx> hello there, do you know if the overlay filter can be gpu accelerated? [19:19:35 CEST] <bencc> JEEB: in my command I only use "-crf 23". I don't use ABR [19:19:56 CEST] <JEEB> well you wanted seemingly to have me look at your shit that I have no interest in and I saw both the ABR and CRF be set [19:20:00 CEST] <bencc> should I use different CRF per variant or is it ok to use -crf 23 for all variants/resolutions [19:20:00 CEST] <JEEB> -b:v sets ABR in libx264 [19:20:01 CEST] <durandal_1707> bigx: why? is it slow, how big overlay is [19:20:06 CEST] <JEEB> and -crf is CRF [19:20:27 CEST] <JEEB> so most likely whatever the fuck gets there last is the one that gets effectively used, but the fuck do I know [19:20:41 CEST] <bencc> ok. thanks for the head up [19:21:13 CEST] <bencc> I wish there was a reference implementation of encoding for several HLS variants [19:21:15 CEST] <bigx> durandal_1707: yes, 3328×1664 pixels [19:21:17 CEST] <bencc> it's probably common [19:22:23 CEST] <durandal_1707> bigx: overlay or main video? [19:23:22 CEST] <ChocolateArmpits> bencc, what do you mean variants? You want to encode different qualities at the same time or something? [19:23:56 CEST] <bigx> durandal_1707: I have an image (png) 3328×1664 pixels and a video (vp8 with alpha channel) the video will be on top of the image [19:25:13 CEST] <durandal_1707> bigx: how much fps you get, and what fps you expect instead? [19:25:26 CEST] <bigx> and Im trying to use nvdec/nvenc for fast video creation [19:25:50 CEST] <bigx> durandal_1707: Im getting around 10fps on a Tesla M60 gpu [19:26:07 CEST] <ChocolateArmpits> bigx, please benchmark the overlay filter only [19:26:14 CEST] <bigx> (on amazon ec2, g3.4xlarge instance) [19:27:38 CEST] <ChocolateArmpits> To benchmark properly, replace the output and encoder for "-vcodec rawvideo -f null -" and use the bench filter to get accurate timing [19:28:02 CEST] <bencc> ChocolateArmpits: yes. for example,encode the same video to 540p, 720p and 1080p [19:28:18 CEST] <bencc> like recommended here https://developer.apple.com/library/content/technotes/tn2224/_index.html#//… [19:28:31 CEST] <ChocolateArmpits> bencc, I'll be back in a sec [19:28:55 CEST] <durandal_1707> bigx: there is overlay for some other hw in preparation [19:29:26 CEST] <bencc> ChocolateArmpits: thanks [19:29:36 CEST] <durandal_1707> but i doubt its for nvidia hw [19:29:39 CEST] <bigx> durandal_1707: good, to know :) but my deadline is in 10 days :) [19:30:18 CEST] <bigx> durandal_1707: is there a place where I can find which filters can be hw accelerated? [19:31:38 CEST] <durandal_1707> bigx: they are separate filters with name and name of hw [19:32:02 CEST] <bigx> that simple :) thanks durandal_1707 [19:34:13 CEST] <bigx> durandal_1707: are you a ffmpeg developer? [19:34:52 CEST] <durandal_1707> bigx: yea and i might write overlay simd [19:35:09 CEST] <bigx> cool, I see this page https://www.ffmpeg.org/consulting.html [19:36:01 CEST] <bigx> and I would definitely get in touch for my problem with some experts, I have some budget for a day or two [19:38:49 CEST] <bigx> it feels weird to ask for a contractor on the ffmpeg-devel mailing list [19:40:21 CEST] <durandal_1707> what problems? [19:50:55 CEST] <bigx> well I need to create a 360° video from a png image and an alpha video on top of it [19:51:05 CEST] <MarkedOne> Hello good ppl, i am confused what happens in two pass encoding h264 when target file size is 2GB and source file have only 50MB? Will this 2GB be maximum allowed or will it be enforced? [19:51:05 CEST] <bigx> as fast as I can [19:51:38 CEST] <kepstin> MarkedOne: the encoder will do its best to make a 2GB file, but it might end up undershooting if it can't figure out a way to make the video big enough. [19:52:33 CEST] <MarkedOne> kepstin: So it is possible that 50Mb will be stretched to 2GB even if there is not enough quality.. [19:52:48 CEST] <bigx> durandal_1707: it works pretty ok on cpu, but my probem is to porting it on gpu [19:53:10 CEST] <MarkedOne> kepstin: So one shuld use 2 pass encoding when it is sure that targeted file size is lesser than source right? [19:54:59 CEST] <MarkedOne> kepstin: might does mean, I have used maximum quality I can get.. so I finish here... Lets say.. 50MB source file will be converted in 100MB and 99% quality possible? [19:55:55 CEST] <kepstin> MarkedOne: well, absolute "best" quality would be to just use a lossless mode - but it sounds like you should be using crf mode instead of 2-pass mode [19:58:12 CEST] <vlt> Hello. Is it possible to take a VIDEO_TS directory with .VOB files as input and create one .mkv file with "-codec:v copy"? [19:59:20 CEST] <ChocolateArmpits> vlt, "concat:VTS_01.VB|VTS_02.VOB" works most of the time [19:59:34 CEST] <ChocolateArmpits> as an input that is [19:59:37 CEST] <vlt> ChocolateArmpits: Thank you :-) [20:01:10 CEST] <MarkedOne> kepstin: Final encoding will be 2 passed cuz I need to put 8GB into DVD... But DVD player is old and I want to see which preset, profile, level it can handle. So i created 20MB strip and want to test it... with different combinations.. [20:03:03 CEST] <MarkedOne> So I dont want CRF because in the end I will encode with 2 pass... So i need to test with 2 pass too. But how to target filesize I could make it large enough so 2 pass will go at maximum quality.... [20:05:55 CEST] <bencc> ChocolateArmpits: you told me to wait :) [20:06:06 CEST] <ChocolateArmpits> bencc, testing something atm [20:07:18 CEST] <bencc> thanks [20:08:02 CEST] <ChocolateArmpits> bencc, you can do multiple encodings of a single source by first splitting the input using the split filter into multiple streams and then specifying their parameters using an index postfix i.e. -b:v:1 320k [20:09:03 CEST] <ChocolateArmpits> between the encoder and the split filter you can insert additional scale filters to adjust for each respective resolution [20:09:13 CEST] <ChocolateArmpits> bencc, are you familiar with filter_complex ? [20:09:38 CEST] <bencc> ChocolateArmpits: I don't mind encoding multiple times for now for simplicity [20:09:54 CEST] <bencc> ChocolateArmpits: but I don't know how to encode each variant [20:12:06 CEST] <bencc> ChocolateArmpits: for each variant/resolution I want to limit audio bandwidth, video bandwidth and total bitrate [20:12:34 CEST] <ChocolateArmpits> bencc, if I understand correctly hls stores each variant separately ? [20:12:45 CEST] <bencc> ChocolateArmpits: and if possible encode as efficient as possible. If the input is 1Mbps 720p, the is no reason to increase the bitrate for the same resolution [20:13:23 CEST] <bencc> ChocolateArmpits: yes. today it's much simpler. you can have one ts or mp4 file for each variant or multiple chunks [20:13:56 CEST] <bencc> you have a master playlist file that tells the client about available variants and a playlist per each variant with the list of chunks [20:14:45 CEST] <ChocolateArmpits> bencc, this is what you most likely need https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs#Onefilteringinst… [20:15:40 CEST] <ChocolateArmpits> as I said before, split is used to split the input, each duplicate stream gets filtered and mapped to separate encoding+output instances [20:16:03 CEST] <bencc> ChocolateArmpits: again, that's not my issue. lets say I only need one variant [20:16:09 CEST] <bencc> without filter_complex [20:16:22 CEST] <bencc> I'm trying to limit audio_bandwidth, video_bandwidth and maxbitrate [20:16:32 CEST] <ChocolateArmpits> yeah [20:16:37 CEST] <bencc> yeah [20:19:44 CEST] <MarkedOne> btw how to know audio bitrate if it has only 44khz writen? [20:19:45 CEST] <ChocolateArmpits> bencc, have you predefined your target rates? [20:21:08 CEST] <bencc> ChocolateArmpits: yes. this is one example https://pastebin.com/x03W7Wcs [20:21:43 CEST] <ChocolateArmpits> bencc, and the problem is what exactly? [20:22:22 CEST] <bencc> ChocolateArmpits: I don't know how to use the limits to encode mp4 with libx264 [20:22:42 CEST] <bencc> this is what I was using https://pastebin.com/WVpEvYWL [20:23:07 CEST] <bencc> but it uses both -crf and -b:v and JEEB said it's wrong [20:26:06 CEST] <ChocolateArmpits> bencc, read this for different ways to control the rate http://slhck.info/video/2017/03/01/rate-control.html [20:26:56 CEST] <bencc> thanks. looks nice [20:28:37 CEST] <ChocolateArmpits> For internet streaming, vbv is probably most prefered because it's the only real way to balance between buffering and playback. [20:30:32 CEST] <bencc> ok. I'll try vbv [20:37:10 CEST] <MarkedOne> Btw what is good aac bitrate? [20:40:47 CEST] <ChocolateArmpits> MarkedOne, anything above 128kbps [20:42:54 CEST] <MarkedOne> ChocolateArmpits: should I multiply it by number of channels? Btw what do you reccomend for movie? [20:45:23 CEST] <furq> if the source is ac3 then just keep that [20:50:58 CEST] <MarkedOne> hmm thanks [20:51:35 CEST] <redrabbit> -vcodec libx264 -bufsize 3600k -maxrate 1800k -crf 22 [20:51:53 CEST] <redrabbit> i use theses settings for streaming [20:53:09 CEST] <redrabbit> i tried other methods but if you are on a limited link (mobile stuff) you cant really afford big bitrate spikes [20:56:51 CEST] <MarkedOne> Pls.. is bitrate -b:a 128k k here means power of 2 or 10? 1k means 1000 or 1024? Im not sure.. And also it is in Bytes or bits? Probably bits [20:57:49 CEST] <ChocolateArmpits> MarkedOne, bits, "k" stands for kilobits [20:58:02 CEST] <ChocolateArmpits> actually, kibibits [20:58:05 CEST] <ChocolateArmpits> :) [20:58:14 CEST] <MarkedOne> ChocolateArmpits: oh thanks.. :) [21:01:50 CEST] <kmax> Hello! [21:01:57 CEST] <kmax> anyone chatting? [21:31:50 CEST] <kmax> hello? [21:36:01 CEST] <kmax> i am looking for some help with ffmpeg [21:36:16 CEST] <kmax> trying to speed up the creation of m3u8 for HLS streaming [21:36:36 CEST] <kmax> using clappr player... right now it takes about 15 seconds for the video to start playing [21:36:45 CEST] <kmax> we need to at least cut that in half [21:36:57 CEST] <kmax> the chunks are set to 3 seconds each [21:37:13 CEST] <kmax> i believe clappr has to download 3 of them to start buffering [21:53:19 CEST] <MarkedOne> Sorry guyz another question.. How to find supported levels for h264 in ffmpeg? [21:54:44 CEST] <BtbN> ffmpeg supports all of them [21:55:04 CEST] <MarkedOne> BtbN: Thanks [21:55:26 CEST] <thebombzen> I'm getting a segfault with zscale's bilinear scaling algorithm, but I don't want to submit a bug report unless it's a bug in libavfilter and not an actual bug in zimg [21:55:37 CEST] <thebombzen> it occurs when downscaling with zscale set to bilinear [21:56:14 CEST] <thebombzen> you can reproduct the segfault with: ffmpeg -f lavfi -i testsrc2=s=hd1080 -vf zscale=hd720:f=biliniear -f null - [21:56:22 CEST] <thebombzen> do you have any tips on figuring out where the bug would be? [22:00:56 CEST] <kmax> Any other sources of ffmpeg support online anywhere? [22:01:03 CEST] <thebombzen> the mailing list [22:01:42 CEST] <thebombzen> see this: https://ffmpeg.org/contact.html [22:02:32 CEST] <BtbN> kmax, set your keyframe interval properly [22:23:43 CEST] <MarkedOne> Thank you guyz all for help :) [22:26:44 CEST] <MarkedOne> Btw what happens when i do 2pass encoding and resolution and bitrate is bigger than preset with level allows? [22:26:58 CEST] <kmax> @BtbN can you explain more about that? [22:35:23 CEST] <DHE> kmax: each video file HLS makes starts with a keyframe. you can use the -g setting to specify how often (in frames) keyframes occur [22:36:01 CEST] <DHE> if each file is 15 seconds of video and runs at 60fps, then that means you have a default of -g 900 and you should bring that down [22:39:18 CEST] <durandal_1707> thebombzen: use copy before zscale [22:41:01 CEST] <thebombzen> durandal_1707: ffmpeg -f lavfi -i testsrc2=s=hd1080 -vf copy,zscale=hd720:f=bilinear -f null - [22:41:03 CEST] <thebombzen> still segfaults [22:41:36 CEST] <JEEB> ah yea, I've had that kind of stuff too before [22:41:45 CEST] <JEEB> with lavfi source and zscale [22:42:04 CEST] <thebombzen> but it's only with f=bilinear [22:42:07 CEST] <thebombzen> every other algorithm works [22:42:10 CEST] <JEEB> funky [22:42:16 CEST] <thebombzen> here's my log. not exciting, but here it is: http://sprunge.us/PjBH [22:42:18 CEST] <JEEB> I do know that anon32 did some fixes recently [22:42:30 CEST] <JEEB> so if you haven't pulled recently you might want to re-check [22:43:25 CEST] <thebombzen> I built ffmpeg this morning [22:43:36 CEST] <thebombzen> but zimg I have installed from the package manager [22:44:09 CEST] <JEEB> although I don't know any specifics wrt bilinear. I just know that very recently there were some asm bugs found [22:44:29 CEST] <thebombzen> it's also not unique to libavfilter input. that is, it segfaults with: ffmpeg -i some_1080p_video_file.mkv -vf zscale=hd720:f=bilinear -f null - [22:44:37 CEST] <JEEB> right [22:44:46 CEST] <JEEB> sounds like an issue with zimg (or zscale) then [22:46:29 CEST] <thebombzen> let's build zimg from master and see what happens [22:52:54 CEST] <MarkedOne> THank you all for help. Good night. [22:56:21 CEST] <thebombzen> JEEB: yep, zimg's git master fixed it [23:13:07 CEST] <jya> hi there. I have a video made of a single video frame [23:13:22 CEST] <jya> how can I make this video so it's made of the same frame, but multiple times ? [23:29:31 CEST] <durandal_1707> jya: use stream looop or loop filter [23:30:51 CEST] <jya> durandal_1707: yeah, i just found that out, but unfortunately; it doesn't help like I had hoped to [23:31:26 CEST] <durandal_1707> jya: really? how so? [23:32:24 CEST] <jya> the video (made of a single frame) I have exposes a bug in the AMD H264 dxva decoder [23:32:33 CEST] <jya> it is decoded as green [23:33:00 CEST] <redrabbit> ffmpeg -loop 1 -i x.jpg -i x.mp3 -shortest -q 15 -acodec copy out.mp4 [23:33:13 CEST] <redrabbit> i use that to make a vid with a pic + audio [23:33:22 CEST] <redrabbit> idk if its what you want [23:33:34 CEST] <jya> I'm trying to make a video that doesn't reproduce that bug; yet satisfy the reasons on why we made that simplistic video in the first place (which is checking if decoding h264 works) [23:34:00 CEST] <redrabbit> single frame and picture sounds like the same to me [23:37:00 CEST] <jya> redrabbit: I hadthought the issue was to do wih the fact that this video is made of a single I frame [23:37:35 CEST] <redrabbit> get a pic out of that frame and try my cmd [23:37:50 CEST] <redrabbit> idk what you want to acheive exactly [23:40:57 CEST] <jya> Option loop not found. [23:41:53 CEST] <durandal_1707> pastebin full command output [23:45:11 CEST] <redrabbit> i used that same exact command dozens of times no issue [23:45:38 CEST] <redrabbit> i do that for youtube when i need to post audio content [23:45:57 CEST] <redrabbit> wasting gogole BW me likey [23:47:03 CEST] <jya> I typed " ffmpeg.exe -loop 1 -i videotest.mp4 -shortest -q 15 -y test.mp4" [23:47:21 CEST] <redrabbit> you dont get it lol [23:47:29 CEST] <jya> that gives me the error "Option loop not found." [23:47:29 CEST] <redrabbit> a picture [23:47:41 CEST] <redrabbit> you are supposed to use a picture [23:47:51 CEST] <jya> i don't have to give it a picutre, i have no picture to give it [23:47:58 CEST] <redrabbit> cmon [23:47:59 CEST] <jya> forget it [23:48:03 CEST] <redrabbit> what is a single frame [23:48:05 CEST] <redrabbit> its a picture [23:48:09 CEST] <redrabbit> just extract it [23:49:25 CEST] <durandal_1707> for video there us stream-loop option [23:53:08 CEST] <durandal_1707> redrabbit: that would be pointless as he is testing hw decoder for specific codec [23:53:29 CEST] <redrabbit> ok [23:54:19 CEST] <jya> well, regardless on the parameter I use to encode, how may frames I put in that video, the output still always crap out with the amd decoder [23:55:08 CEST] <jya> i guess I'll have to wait for AMD to come up with some ideas on how to encode this video so their cards aren't blacklisted [23:59:33 CEST] <blap> youtube is really messing with some live streams [23:59:35 CEST] <blap> [ffmpeg] tls: The TLS connection was non-properly terminated. [23:59:37 CEST] <blap> [ffmpeg] tls: The specified session has been invalidated for some reason [00:00:00 CEST] --- Wed Sep 6 2017

1 0