Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2016

1 participants
62 discussions

ffmpeg-devel.log.20161230
by burek 31 Dec '16

31 Dec '16

[00:05:35 CET] <kierank> DC >> 6 is the "right looking" dc [00:05:47 CET] Action: kierank debugs steinar's idct [00:16:52 CET] <kierank> BBB: ok part of this is mpegvideo.c madness [00:23:43 CET] <BBB> muhahahaha [00:23:58 CET] <JEEB> mpegvideo.c - the gift that keeps on giving [00:26:46 CET] Action: kierank rips out all the mpegvideo.c block stuff and does it himself [00:30:46 CET] <cone-575> ffmpeg 03Matt Wolenetz 07master:fe7547d69e67: lavf/utils.c Protect against accessing entries[nb_entries] [00:32:13 CET] <kierank> https://usercontent.irccloud-cdn.com/file/71iOItat/luma.png [00:32:16 CET] <kierank> BBB: ^ luma looks good/correct now [00:32:28 CET] <kierank> broke chroma somehow but this is mpegvideo.c stuff again [00:51:41 CET] <Compn> kierank going to rewrite mpegvideo :D [00:55:13 CET] <kierank> BBB: does chroma need a different shift? [00:55:20 CET] <kierank> in general [00:55:54 CET] <kierank> all the chroma coeffs get clipped [01:21:37 CET] <kierank> BBB: never mind just needs some experimenting with shifts [01:37:54 CET] <kierank> strange artefacts on her arm https://usercontent.irccloud-cdn.com/file/Tu33WhWV/artefacts.png [01:37:59 CET] <kierank> at 400Mbit/s shouldn't really happen [01:48:03 CET] <iive> ac coefficients are still now scaled properly. i'd guess they are with higher amplitude than they should be. [01:50:56 CET] <iive> or dequant [03:49:40 CET] <cone-807> ffmpeg 03Michael Niedermayer 07master:ffc3337e0b84: avfilter/vf_pad: Add eval=frame support [04:03:24 CET] <cone-807> ffmpeg 03James Almer 07master:6993bb4eb6c3: configure: make the check for stdatomic.h stricter [04:37:27 CET] <BBB> kierank: luma also has some weird artifacts, it looks like a slight edge around each blocks [11:06:32 CET] <nevcairiel> j-b: neat, thanks [11:08:19 CET] <j-b> nevcairiel: 5.0.1 release this weekend [11:08:53 CET] <nevcairiel> i'll be on vacation as of sunday morning, so take your time = p [11:11:38 CET] <JEEB> 5.0.1 mingw-w64? [11:12:02 CET] <nevcairiel> yes [12:09:36 CET] <cone-621> ffmpeg 03Carl Eugen Hoyos 07master:ec2f3b1f57fd: lavc/psd: Remove an uninitialized variable. [16:14:51 CET] <durandal_1707> I think I got parsing qdmc working, still need to find way to generate vlc table [00:00:00 CET] --- Sat Dec 31 2016

1 0

ffmpeg.log.20161230
by burek 31 Dec '16

31 Dec '16

[00:41:54 CET] <rjp421> JEEB, tried with a vid file too, same thing.. http://pastebin.com/raw/VdRKu8fz [00:50:00 CET] <JEEB> yeah, it just creates a lot less unrelated input logging [00:50:18 CET] <JEEB> but yea, the output URL of yours is getting incorrectly parsed [00:50:23 CET] <ZexaronS> hey JEEB, youtube-dl has a major lack of ability, there's no real FMT code selection, according to the master readme, only some "format" setting which says only supports downloading best or worst video or audio, but i'll still try it readme could be old [00:50:39 CET] <JEEB> ZexaronS: -F lists all formats for a video [00:50:48 CET] <JEEB> youtube-dl -F "youtube url" [00:51:16 CET] <JEEB> and usually with command line apps you read the output of --help :P [00:51:36 CET] <ZexaronS> Yeah but I asked the guys on the channel if it's possible to pre-set the FMT option so it starts downloading that one by default into a default folder for the session [00:52:02 CET] <ZexaronS> looking at the readme didn't give me an impression there's actuall all the fmt codes available but yes i'll try it now [00:52:40 CET] <kepstin> the format codes available - at least on youtube, dunno about other sites - depends on the video [00:52:49 CET] <kepstin> google generates different formats for different uploads [00:57:02 CET] <ZexaronS> JEEB, I never found an utility to download fragmented videos efficiently, if this does the trick and combines them into a proper video file, i'll be very happy at least nonyoutube stuff [00:57:20 CET] <ZexaronS> a lot of US local news uses fragmentation [00:57:51 CET] <JEEB> ZexaronS: if you have ffmpeg in your PATH it can put the audio and video stuff together :P [00:58:13 CET] <JEEB> you should see regarding the sites youtube-dl supports of course [00:59:24 CET] <ZexaronS> your command doesn't work, says no url [01:01:35 CET] <ZexaronS> I'll probably need a separate utility imputting a lot of urls into the batch commands anyway [01:01:54 CET] <ZexaronS> or some batch script to take the list and run for-each [01:02:16 CET] <rjp421> JEEB, ohh i finally see what you mean by Parsed protocol/host/app.. sry lol [01:04:09 CET] <rjp421> i guess theres no way to trick it into parsing correctly, by escaping or nested escaped quotes [01:04:13 CET] <ZexaronS> JEEB, error downloading webpage, <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:600)> [04:07:46 CET] <JonFreed> Hello - Does this look like a good command line for having ffmpeg listen for a stream that I will be having OBS send to it? [04:08:39 CET] <JonFreed> ffmpeg -loglevel trace -listen 1 -timeout 60 -i rtmp://localhost/live/mystream rtmp://a.rtmp.youtube.com/live2/abcxyzabcxyz [04:14:45 CET] <JonFreed> That command seems to work just fine. But when I tell OBS to stream to it, then OBS just says <ip address>:1935 is offline. Try a different server. (ECONNREFUSED). [04:16:15 CET] <c_14> is obs running on the same computer? [04:18:18 CET] <JonFreed> Nope. OBS is on my laptop that I'm typing on. ffmpeg is running on an Amazon ec2 instance. I have "all [inbound] traffic" enabled for the instance, so I'm pretty sure the firewall isn't the problem. [04:18:26 CET] <c_14> then you can't use localhost [04:18:44 CET] <c_14> you have to bind to an address reachable from the outside [04:18:53 CET] <c_14> or 0.0.0.0 or :: [04:20:38 CET] <JonFreed> Oh..... ok. For the ffmpeg -i address I had only tried "localhost" and then also the ip address that I am entering into OBS. [04:20:56 CET] <JonFreed> (Incidentally, the latter resulted in this error message: Cannot assign requested address) [04:22:20 CET] <c_14> depending on magic" the internal address may not be the external one [04:22:29 CET] <c_14> check ifconfig or `ip l' [04:22:31 CET] <JonFreed> TADA! That works. Thank you so much @c_14. That's a pretty obvious solution, in retrospect. [04:22:32 CET] <c_14> or use 0.0.0.0 [04:22:57 CET] <JonFreed> I mean that 0.0.0.0 works [04:43:12 CET] <JeffATL> can someone explain to me about mpeg2 files coming right out my cap card have this artifact where edges that move from side to side seem to be different in time on alternating scan lines? [04:46:47 CET] <c_14> interlacing? [04:47:37 CET] <JeffATL> c_14: let me show a pic, hang on [04:51:06 CET] <JeffATL> c_14: have a look at this: http://picpaste.com/pics/XaF23vDE.1483069835.JPG [04:51:49 CET] <furq> yeah that's interlacing [04:52:23 CET] <JeffATL> is it because while field A and field B of each frame were scanned in the video camera 1/60th sec apart, the computer isn't displaying it that way? [04:53:06 CET] <furq> it's playing back 60i footage at 30p [04:53:48 CET] <furq> most players can deinterlace but i prefer to do it when encoding [04:53:55 CET] <furq> realtime deinterlacers usually aren't very good [04:54:49 CET] <JeffATL> furq: atm i'm trying to reencode with "yadif" included in the filter string - yea/nay? [04:55:06 CET] <furq> it's up to you [04:55:24 CET] <furq> yadif mode 1 is probably the best option available in ffmpeg [04:56:38 CET] <furq> i see a lot of people on forums insisting you should encode interlaced, but curiously i've never seen that in here [04:56:46 CET] <furq> and i trust people in here more than randos on videohelp or doom9 or whatever [04:57:03 CET] <c_14> there's plenty of deinterlacing filters to try out in ffmpeg, yadif is usually a decent choice [04:57:27 CET] <furq> yadif mode 0 (the default) looks pretty bad in my experience [04:57:30 CET] <furq> mode 1 is much better [04:57:43 CET] <furq> half-rate deinterlacers usually look pretty crap though [04:57:55 CET] <c_14> mode 1 should be default [04:58:09 CET] <furq> it isn't [04:58:11 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#yadif-1 [04:58:15 CET] <furq> The default value is send_frame. [04:59:11 CET] <c_14> Oh, I was reading the docs for bwdif because the description has the first match for yadif in the manpage... [04:59:38 CET] <furq> i don't think i've tried bwdif yet actually [04:59:48 CET] <c_14> nnedi is also in recent versions of ffmpeg if you're into that [04:59:55 CET] <furq> w3fdif looked much worse than yadif to me, so idk why you'd use parts of that [05:00:06 CET] <furq> also if that is what the bbc use internally then it definitely sucks [05:00:20 CET] <furq> lots of their iplayer stuff has terrible interlacing artifacts [05:01:00 CET] <furq> and yeah nnedi is good but the ffmpeg implementation is unusably slow [05:01:30 CET] <furq> and most people don't want to go through the hassle of setting up vapoursynth [05:04:11 CET] <JeffATL> oh wow - i think i have some pretty good-looking resukts here [05:04:56 CET] <JeffATL> movement interlace is gone [05:06:17 CET] <JeffATL> getting almost exactly 3:1 file compression [05:09:07 CET] <JeffATL> i have another thing going on maybe you can help me understand better [05:09:26 CET] <JeffATL> same rig but a different source beta tape [05:14:40 CET] <bornpilot> I am getting this error [nut @ 0x7fd22e01d600] No codec tag defined for stream 0 - with the follwing command [05:14:51 CET] <bornpilot> ffmpeg -i Canon/00011.MTS -f nut -c:v libx265 -preset medium -crf 28 -c:a copy nutty_test/nutty_test.nut [05:15:42 CET] <JeffATL> see how everything gets warped over to the right at the top of the image: http://picpaste.com/pics/mRcLS7zC.1483071277.JPG - that's how it comes out of the TBC. turn the TBC off and that goes away, [05:17:09 CET] <JeffATL> it also seems like the fields get swapped intermittently, as though something can't decide which is supposed to be which and there'll be a vertical interlacy-loking jitter [05:19:05 CET] <furq> i've never done any analog capture but apparently sometimes it's better to disable the tbc [05:19:06 CET] <JeffATL> needless to say, i can't really go forward with the TBC-on versioin but i was hoping to better understand the reasons behind it [05:36:19 CET] <JeffATL> sadly it looks like the vp8 encoder is not multithreaded [05:45:18 CET] <Jinx> i'm using ffmpeg 2.8.4 (win32 static) to try to convert video to thumbnail/slideshow GIFs... and i can't seem to get the framerate to convert just right; i can get it to output a frame every X seconds... but can't seem to speed up the GIF to play back those outputted frames much faster (e.g. extracting 1 frame every 60 seconds of source, but playing back each of those extracted frames at 1fps) [05:46:42 CET] <Jinx> i've looked here already: https://trac.ffmpeg.org/wiki/Create%20a%20thumbnail%20image%20every%20X%20s… [05:46:50 CET] <Jinx> any assistance would be appreciated :) [05:57:19 CET] <JeffATL> i'm gonna need a lot more CPU. [06:15:58 CET] <Kirito> Is there not a basic list of id3 metadata tags for video/audio somewhere out there? Somewhere. Anywhere. [06:16:01 CET] <Kirito> I ahve looked everywhere I can [06:16:19 CET] <furq> http://wiki.hydrogenaud.io/index.php?title=Tag_Mapping#Mapping_Tables [06:16:23 CET] <furq> for a given definition of "basic" [06:17:03 CET] <llamapixel> um Kirito http://id3.org/ [06:17:44 CET] <Kirito> So, what, do I just use "TENC" as the metadata key for "Encoded By"? I thought that was just "encoded_by", that's what I always see used in practice [06:17:58 CET] <Kirito> but if those acronym identifiers work sure, whatever works [06:18:11 CET] <furq> TENC is what's stored in the actual tag [06:18:21 CET] <furq> whatever editor you're using is probably giving you some human-readable alternative [06:19:27 CET] <Kirito> I'm encoding the video with -metadata encoded_by="John Doe", and it's being parsed by Windows and other video players as a valid attribute for the "Encoded By" property [06:20:01 CET] <Kirito> So maybe it is just some unofficial alternative, I just assumed each tag had some human readable key that is to be used [06:20:07 CET] <furq> http://jonhall.info/how_to/create_id3_tags_using_ffmpeg [06:20:13 CET] <furq> idk how authoritative that is but i don't see anything on ffmpeg.org [06:20:47 CET] <Kirito> I found that, but it's missing some of the more detailed/newer ones, like Encoder Settings [06:21:47 CET] <furq> oh [06:21:48 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/id3v2.c#L43-L84 [06:21:58 CET] <furq> that's probably as authoritative as you'll get [06:22:31 CET] <furq> i assume you can just use TSSE for encoder settings [06:22:52 CET] <Kirito> oh, okay, now that makes sense. FFMpeg is just mapping them to user friendly terms. I didn't realize that. I just thought the acronyms were for someting else entirely. Thank you [06:23:57 CET] <furq> yeah those names are the same for all tag formats afaik [08:28:07 CET] <Yen> I use "ffmpeg -i input0.webm -hls_segment_filename latest_%03d.ts out.m3u8" to make HLS playlist. Then I use Video.js on Chrome to play it. Only the first segment is playable. [08:28:17 CET] <Yen> Please help me [08:49:14 CET] <AlbertLu> I build ffmpeg on Ubuntu 16.04 LTS [08:49:59 CET] <AlbertLu> LD libavcodec/libavcodec.so.57 /usr/bin/ld: libavcodec/mqc.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC libavcodec/mqc.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status library.mak:102: recipe for target 'libavcodec/libavcodec.so.57' failed make: *** [libavcodec/libavcodec.so.57] Error 1 [08:50:50 CET] <AlbertLu> I have change config.mak, HOSTCFLAGS=-O3 -g -std=c99 -Wall -fPIC [08:50:57 CET] <AlbertLu> but not work [08:51:42 CET] <tdr> dont use -O3 for one thing [08:51:58 CET] <tdr> messes up way more than the "tweaks" you'd think you're getting from it [08:52:56 CET] <tdr> its not the cause of this error, but -O2 is way more likely to give you a binary without hidden broken/bad pieces [08:54:47 CET] <JeffATL> AlbertLu: i use gentoo linux almost exclusively and best practices among gentoo folks is, -O3 is almost never justified [08:55:52 CET] <tdr> same, it used to be fine, but many yrs ago that changed with a gcc version [08:57:23 CET] <JeffATL> basically if there is like *one binary* and every fraction of a second matters. try -O3 and test its brains out [08:58:41 CET] <tdr> test it against an -O2 one tho too because sometime -O3 makes bins that are slower [08:58:52 CET] <JeffATL> yes to that [08:59:59 CET] <JeffATL> if it's revenue-generating and it's the difference between a 3-bedroom in Monaco and a 4-bedroom in Monaco, then yes, go there :) [09:01:20 CET] <AlbertLu> :) [09:42:35 CET] <kerio> also try -Os [09:42:48 CET] <kerio> sometimes staying in cache is more important than anything else [10:46:08 CET] <sh3llc0d3> Hello guys [10:46:14 CET] <sh3llc0d3> some active users right now ? [10:46:26 CET] <kerio> nope [10:46:39 CET] <sh3llc0d3> Damn it, I'll try next time [10:46:44 CET] <sh3llc0d3> ... :) [10:47:35 CET] <sh3llc0d3> Well I got a simple question, I'm actually encoding stuff with libx264 to get mp4 containers, I'm looking to get the best quality possible on output, but without actually do the encoding in two phases [10:48:07 CET] <sh3llc0d3> is there any recommanded preset or something for this ? Or should I simply try and find what fits the best to me ? [12:03:26 CET] <zoli> hello [12:03:48 CET] <zoli> I would like to get hardware encoding work under Ubuntu 16.04 with nvidia gtx 770 [12:04:20 CET] <zoli> I tried it with ffmpeg as well directly after Handbrake and Transmageddon [12:04:50 CET] <zoli> ffmpeg tells me that: Unknown encoder 'libnvenc' [12:05:03 CET] <BtbN> nvenc [12:06:26 CET] <zoli> BtbN: if i change libnvenc to nvenc, it tells the same: Unknown encoder 'nvenc' [12:06:50 CET] <BtbN> Use an ffmpeg build which has the nvenc encoder enabled then. [12:06:57 CET] <zoli> ffmpeg -i file -c:v nvenc -profile:a high444p -pixel_format yuv444p -preset default output.mp4 [12:07:01 CET] <zoli> this is the command [12:07:07 CET] <BtbN> Which should be any somewhat recent one, as it's enabled by default. [12:07:43 CET] <zoli> ffmpeg version N-79139-gde1a0d4 [12:08:39 CET] <zoli> is it also enabled by default in the nvidia propriatery driver? I have this version: 367.57 [12:10:32 CET] <BtbN> There is nothing to be enabled/disabled in the driver. And the error is quite clear. Update your ffmpeg. [12:14:12 CET] <zoli> at pacckage level, I have 3.0.0, as I see the newest is 3.2.2 [12:14:33 CET] <zoli> trying to find a repo [12:40:55 CET] <DHE> high444p is not an audio profile [12:58:53 CET] <zoli> ok, thanks it seems to be working now [12:59:39 CET] <zoli> needed indeed the latest 3.2.2 ffmpeg, plus also needed to install one package: libcuda1-367 [13:00:13 CET] <BtbN> that's entirely up to the packager of your driver. [13:01:55 CET] <zoli> I wonder though why my gpu was only used till 8% and video engine utilization: 1005? [13:01:59 CET] <zoli> 100%* [13:02:14 CET] <zoli> I have checked it in nvidia-settings [13:04:15 CET] <BtbN> what's to wonder about that? Seems like what would happen if you fully use the video engine? [13:08:20 CET] <zoli> what is video engine exactly here? [13:08:43 CET] <zoli> and how can it be the bottleneck? [13:09:16 CET] <zoli> ffmpeg itself is the video engine? [13:12:10 CET] <darsain> how can one map streams based on language code? the docs say that to pick english audio, you do: -map 0:m:language:eng [13:12:40 CET] <darsain> but that leaves me baffled, since I'd expect it to be -map 0:a:language:eng, why is it 0:m... ? [13:12:54 CET] <darsain> and how do I adapt it for subtitle stream? [13:22:04 CET] <BtbN> zoli, it's the part of the card that does the video de/encoding. [13:29:27 CET] <zoli> is vp9 also supported by ffmpeg with hardware encoding? [13:39:08 CET] <olgson> Hello FFMPEG people. I've small problem with http://pastebin.com/ZRwWtg1Q OVERLAY. I was able to make video with avectorscope and sound / image and sound but I'm not able to combine them together. [13:39:14 CET] <olgson> Happy New Year! :) [13:41:24 CET] <olgson> I'm completely green in ffmpeg field. I believe I've lost some bitrate command / codec or sth else... [13:51:14 CET] <kepstin> olgson: what does ffmpeg print when you run it? [13:51:24 CET] <olgson> One sec [13:51:48 CET] <kepstin> hmm, you're overlaying a 1920x1080 thing on top of a 1920x120 thing, i'm not sure what you're expecting to happen... [13:52:53 CET] <olgson> http://pastebin.com/qjkUBiDh [13:53:00 CET] <olgson> nono - I've changed that to x1080 [13:53:31 CET] <olgson> anyway what I want to do is : Take MP3 -> create GenScope overlay that over image ;) [13:53:42 CET] <olgson> *AVectorScope [13:54:10 CET] <kepstin> ok, so it looks like the issue is that you're just not looping the image frame, so it's stopping encoding early [13:54:16 CET] <markvandenborre> zoli: kaby lake intel procs combined with... what was it again [13:54:27 CET] <markvandenborre> for hardware encoding at least have some patches ready [13:54:28 CET] <kepstin> add "-loop 1" before the image input, and "-shortest" before the output filename [13:54:51 CET] <kepstin> you might also want to set '-framerate' on the image input too [13:55:15 CET] <kepstin> (default is 25, and you might get weirdness if it doesn't match the overlayed stuff) [13:56:35 CET] <olgson> looks better with loop option (generation time is longer :D ) lets see ;) [13:56:45 CET] <olgson> 32 fps :) [13:57:12 CET] <kepstin> olgson: also you're using x264, so you should use '-crf' not '-q:v' (default is 23, lower values are higher quality/bigger) [14:11:39 CET] <olgson> kepstin, it loops whole video ;) and it's generated without stopping :) [14:17:22 CET] <zoli> markvandenborre: only for intel, not for nvidia? [14:18:30 CET] <zoli> markvandenborre: I have nvidia gtx770, I guess it wont support vp9 anyway, but only the latest pascal architecture? [14:18:40 CET] <olgson> kepstin, maybe it's there but there is transparency set and BG is just coverd with FG :) [14:19:14 CET] <olgson> kepstin, f... yeah ! was right :) [14:19:17 CET] <markvandenborre> zoli: kaby lake intel procs only, yes... [14:19:28 CET] <markvandenborre> and even then, the process is not very straightforward [14:19:29 CET] <olgson> kepstin, https://www.youtube.com/watch?v=QqNZ-KdHNqM :) [14:19:43 CET] <olgson> but still not an effect I wanted ... but I know it's working so I can play more around with it ;) [14:20:12 CET] <kepstin> olgson: maybe try the 'blend' filter instead of 'overlay' - you can get some neat effects with that [14:21:38 CET] <kepstin> 'lighten' or 'addition' blend modes would be good ones to try [14:23:18 CET] <markvandenborre> zoli: gstreamer-vaapi with intel kaby lake processors [14:24:24 CET] <zoli> markvandenborre: https://developer.nvidia.com/ffmpeg There is nice table, which says pascal should have vp9 encoding with ffmpeg? [14:26:31 CET] <ritsuka> I see only vp9 decoding in that table [14:30:44 CET] <markvandenborre> zoli: indeed; the only way right now seems to be gstreamer vaapi on kaby lake [14:30:55 CET] <markvandenborre> and good luck getting hold of those processors [14:32:20 CET] <markvandenborre> and libav does do it too it seems [14:32:23 CET] <markvandenborre> https://wiki.libav.org/Hardware/vaapi [14:35:36 CET] <zoli> what is the difference between vp9 and libvpx-vp9 coders? [14:35:56 CET] <BtbN> Isn't one the decoder? [14:37:09 CET] <zoli> (decoders: vp9 libvpx-vp9 ) (encoders: libvpx-vp9 ) [14:37:19 CET] <markvandenborre> vp9 is the codec, libvpx is a reference implementation in software [14:37:37 CET] <zoli> for decoders there is both [14:38:02 CET] <zoli> or is it just an alias? [14:42:27 CET] <BtbN> there is a native vp9 decoder in ffmpeg [14:42:32 CET] <BtbN> usually those are just named like the codec. [14:42:46 CET] <sh3llc0d3> it's like aac and libfdk_aac [14:42:57 CET] <sh3llc0d3> oh, hi :) [14:57:39 CET] <Dexstair> quick question - may be part of a larger question. What does -map do. Is it deprecated? [15:02:33 CET] <klaxa> it maps input streams to output streams, it is not deprecated [15:03:20 CET] <DHE> it lets you build your outputs using components of the inputs [15:03:22 CET] <klaxa> https://ffmpeg.org/ffmpeg.html#Advanced-options [15:12:42 CET] <Dexstair> Okay, when using tragtor with H264_nvenc it causes an error, but removing the -map option allows the encode to continue. [15:14:27 CET] <DHE> then it is likely using the map command incorrectly [15:18:11 CET] <Dexstair> -map 0.0 -map 0.1 -y -f matroska -ab 128k -ar 48000 -ac 2 -vcodec h264_nvenc is what Tragtor wants to do by default, and throws out "Stream map '0.0' matches no streams. To ignore this, add a trailing '?' to the map." [15:20:19 CET] <Dexstair> Vaapi used to take the stress off of the processor, but it seems that NVENC assists the encoding process rather than takes it off of the processor [15:20:35 CET] <Tom_B_> I'm trying to implement a 60 minute timeshift of a live HTTP stream. I've managed to get the stream recorded into multiple hour long segments (mpeg2-ts files) and I can open these in vlc/mplayer/whatever. The problems are 1) I can only rewind to the beginning of the file, 2) VLC will only play the stream for an hour because the next segment is in a different file. Is there any way to get ffmpeg to provide all the files as a single stream to vlc (an [15:20:35 CET] <Tom_B_> d allow rewinding back to the beginning of the first segment?... and not cause a problem when a segment is deleted?) [15:28:11 CET] <BtbN> nvenc is an asic on the nvidia GPU. It takes 100% of the load from the CPU. [15:28:33 CET] <BtbN> If you still have high CPU usage, that's something else doing stuff on it. [15:28:48 CET] <DHE> Dexstair: the -map syntax uses :colons:, not .periods. [15:32:35 CET] <Dexstair> ffmpeg -i "/mnt/f892940f-33f7-47ae-9fd5-140c53b4b697/Videos/Anime/DVD Rips/Manga Force/Urot/LOO.mp4" -map 0.0 -map 0.1 -y -f matroska -ab 128k -ar 48000 -ac 2 -vcodec nvenc_h264 "/home/dexter/Downloads/anime.mkv" is what is being passed to ffmpeg [15:33:16 CET] <Dexstair> my cpu usage is around 150% but on FFMPEG [15:34:34 CET] <Metamorfer> Hi, I'm having issues compiling ffmpeg latest version on OSX for distribution [15:34:59 CET] <Metamorfer> It works on the host machine and I can either manually compile it or use brew with no surprises [15:35:20 CET] <Dexstair> https://s28.postimg.org/nojj32zyl/Screenshot_from_2016_12_30_14_33_42.png encoding settings [15:35:25 CET] <Metamorfer> but when I move the libs to another mac with different hardware it crashes [15:35:43 CET] <DHE> Dexstair: well you still need to decode the video on the CPU, and encode the audio. for HD and better-than-realtime encoding you might be pushing the CPU there. [15:35:50 CET] <Metamorfer> I've been reading a lot and playing with ./configure but nothing so far [15:36:42 CET] <Dexstair> Ahh, my intel chip can decode the video too. I think ffmpeg can via nvenc with the right setting too. I'm having a dumb moment [15:36:52 CET] <Metamorfer> is there any recommendation/guide I can follow to compile ffmpeg that minimizes compatibility issues when running on a different machine? [15:37:12 CET] <DHE> Metamorfer: crashes how? illegal CPU instruction? [15:37:18 CET] <Metamorfer> yes [15:37:32 CET] <Metamorfer> libavcodec.57.dylib 0x000000010a7cf9d1 0x10a521000 + 2812369 1 libavcodec.57.dylib 0x000000010a99a408 avcodec_register + 26 [15:37:57 CET] <DHE> that shouldn't happen unless you used a custom configure line with -march=... [15:38:29 CET] <DHE> it's possible to force a compiler to target certain CPUs as well, but I'm not aware of any system that defaults to non-compatible settings [15:39:47 CET] <Metamorfer> I'm compiling OBS which relies on ffmpeg for most of the encoding/decoding processes. [15:40:11 CET] <Metamorfer> it's OBS the one making calls to the lib so maybe the problem is there. [15:41:48 CET] <JEEB> time to make sure you have enable-debug set in your configure [15:41:54 CET] <JEEB> and then oppan debugger time [15:42:22 CET] <Metamorfer> That's a good point JEEB [15:42:58 CET] <Metamorfer> I was wondering if someone else has more experience with OSX and point me to the right direction. [15:45:45 CET] <Metamorfer> to summarize, ffmpeg 3.x lib libavcodec.57.dylib crashes when executed on a mac with different hardware than the host used to compile the library. I want to fix that. [15:48:09 CET] <darsain> is it possible to configure libvpx to encode only based on quality level? i.e. something like crf, without me having to also configure a specific bitrate target? [15:49:09 CET] <darsain> bitrate is dependent on video dimensions, and I want to create a universal script into which I can throw videos of any size to be recoded, so I don't want to be setting bitrate targets anywhere [15:50:22 CET] <darsain> I've tried -b:v 0 as you do in libvpx-vp9, but that produces constantly giant videos, no matter what crf is set [15:53:07 CET] <kerio> Metamorfer: how different [15:53:49 CET] <kerio> and i second what DHE said, that sounds like a -march issue [15:55:05 CET] <JonFreed> Hello - What's the secret on a Windows box to getting ffmpeg to listen? The following works on Linux, but it does not work on Windows: ffmpeg -listen 1 -timeout 60 -i rtmp://0.0.0.0/live/mystream -c copy -f flv rtmp://us-east.restream.io/live/mysecretstreamkey [16:11:15 CET] <Metamorfer> not very different, both macs are running OSX 10.12, the biggest difference is the GPU one has an AMD and the other has an NVidia [16:16:52 CET] <kerio> which models are those? [16:23:25 CET] <spl33n> hello i need to mute audi file using ffmpeg but i dont know how i do this. someone help me ? [16:23:44 CET] <ritsuka> Metamorfer: same os version? what does it say in the crashlog? [16:27:00 CET] <kerio> Metamorfer: was it compiled on a newer model [16:39:36 CET] <hashworks> Hi! I'm currently encoding 4K x265 files with a bitrate of 18 Mbit/s to HEVC. What is a bitrate I should expect? I'm using the medium preset and a CRF of 17, and the current output is ~17 Mbit/s. Can I go for a much lower bitrate to get the same quality in HEVC? [16:40:41 CET] <DHE> so input is 18 megabit, and output is crf that turns out to be ~17 megabit? [16:41:12 CET] <hashworks> With -crf 17, yes, seems so frame= 1930 fps=3.7 q=-0.0 size= 174206kB time=00:01:20.69 bitrate=17685.5kbits/s speed=0.156x [16:42:49 CET] <hashworks> I'm not really sure what to expect from HEVC, I guess I just have to try out multiple settings. What is a good way to compare the quality of two files without watching them on a 4K monitor and "guessing it"? [16:43:25 CET] <kerio> crf 18 is supposed to be super good for x264 [16:43:46 CET] <hashworks> Ok, so 17 might be a overkill? [16:44:32 CET] <DHE> I wouldn't compare x264 and x265 too closely [16:47:13 CET] <kerio> yeah [16:47:28 CET] <kerio> but still, at the same crf x265 should look better [16:48:56 CET] <kerio> (slightly better, but still) [16:49:05 CET] <kerio> hashworks: i'd make some tests actually [16:49:49 CET] <hashworks> How would you compare those? By eye? I don't have a 4K monitor arround, and the only 4K monitor I have access to (in the next weeks) is only playing 4K content with HEVC codec [16:51:11 CET] <DHE> there are official metrics like PSNR but computer measurements don't usually directly equate to human perception. at the end of the day, it's human eyes watching the video [16:51:46 CET] <hashworks> Hm. I guess I'll have to with comparing them downscaled on a 1080p screen [16:51:52 CET] <hashworks> *go with [16:52:13 CET] <JEEB> kerio: you should never compare two different sets of settings or encoders at the same crf [16:52:55 CET] <kerio> hashworks: play it cropped, not downscaled [16:53:14 CET] <hashworks> hm good idea [16:53:32 CET] <JEEB> first of all with the same encoder the analysing parts differ between settings, and between two very different encoders that makes even less sense [16:55:15 CET] <JEEB> x was bigger or smaller file size wise with the same crf between settings or encoders just has nothing you can compare because crf just can't be compared that way [16:55:48 CET] <kerio> JEEB: but they're called in the same way ;< [16:55:55 CET] <kerio> and the encoder names are very very similar [16:56:05 CET] <JEEB> yes, but that means nothing. [16:56:27 CET] <JEEB> even between presets in one encoder the crf result is not stable [16:56:48 CET] <JEEB> and x265 is completely different to x264 [16:57:10 CET] <JEEB> so, uh, yeah. that's not how you compare [16:59:24 CET] <JEEB> what I did when I was doing testing is I maximized both encoders (to make something static), then encoded three crf values with x265 (as that is slow as molasses), and then I did 2pass encodes to the same file size with x264 (although the proper way woild have been to find the crf value that gives the same file size) [17:00:11 CET] <JEEB> the other alternative is to match speeds, and then encode to the same bit rate and compare (but that is much harder) [17:00:42 CET] <JEEB> because you have to find a spot where both encoders have very close speed [17:02:38 CET] <JEEB> naturally in both cases you also have to match stuff like max gop length etc [17:33:11 CET] <kepstin> JEEB: note that doing a 2-pass encode with x264 is literally the same as finding a crf value that gives the same file size [17:33:24 CET] <JEEB> not 100% the same [17:33:46 CET] <JEEB> but close enough that I consider it a valid alternative [17:33:50 CET] <kepstin> well, certainly very close. the crf mechanism is derived from the second pass of 2-pass mode. [17:33:59 CET] <JEEB> yes [17:34:33 CET] <JEEB> I mean, I've seen the bit allocations be different but in general if it's not a very specific type of content they should be similar enough [17:34:47 CET] <kepstin> iirc at the end of the first pass, it even prints out the selected crf value for the second pass [17:35:21 CET] <JEEB> but the analysis pass does affect the bit allocations and in certain cases it can be quite different [17:35:40 CET] <JEEB> but yeah, you're right that the results usually are quite close enough [17:36:40 CET] <JEEB> if I look at my old logs @ #x264 I'd probably be able to point towards some samples where it becomes evident, although I think you'll be able to see differences in overall bit allocation with pretty much everything [17:37:20 CET] <Threads> any reason why old ffmpeg versions write the x264 headers in the mkv but with ffmpeg 3.2.2 it doesnt [17:37:29 CET] <kagami_> Hi. Can ffprobe display bit_rate information per stream? Seems like it could before, but not anymore? I can't find bit_rate field for my test files. [17:37:36 CET] <Threads> i use to be able to preview the encoding settings while encoding [17:38:08 CET] <kagami_> Threads: seems like the same for libvpx. [17:38:20 CET] <kagami_> I can't play files while encoding to vp9. [17:39:04 CET] <JonFreed> Any ideas why I am getting the error "RTMP_Connect0, failed to connect socket. 10061 (Unknown error)" when I try the following command on Windows? (The same command works on Linux without any problems.) ffmpeg -listen 1 -timeout 60 -i rtmp://0.0.0.0/live/mystream -c copy -f flv rtmp://us-east.restream.io/live/mysecretstreamkey [17:39:30 CET] <kepstin> iirc not being able to play mkv/webm as it's being encoded is a pretty recent change, annoys me too. there's a couple of commits you can revert to get the old behaviour :/ [17:40:21 CET] <JEEB> I think it was brought up on the ML [17:42:20 CET] <kepstin> one of my friends says reverting commits 8c1342e631d6 and ee888cfbe777 would do the trick [17:42:58 CET] <kagami_> kepstin: cool, thanks [17:43:30 CET] <JonFreed> @spl33n , you said "i need to mute audi file". I think you meant that you want to mute the audio? If yes, then try the "-an" option before the output file. Your need was addressed on Stack Exchange here: http://superuser.com/a/268986/598718 [18:11:41 CET] <spl33n> JonFreed: yes i mean audio [18:53:55 CET] <JonFreed> Besides sneaker net, what encoding, muxing/container-format, and protocol would use the least amount of network bandwidth if you want to stream from ffmpeg on one box to ffmpeg on a second box? [20:01:56 CET] <DHE> so if encoding time were a non-issue, -threads 1 is the ideal setting for x264 encoding quality, right? (all other things being equal) [20:14:57 CET] <JEEB> DHE: it really doesn't affect quality with x264. disabling threads does make VBV/HRD work exactly the same way every time with the same clip, though [20:17:07 CET] <DHE> JonFreed: there's not much that meets all criteria ideally. mpegts over tcp is fairly reliable but mpegts overhead is pretty bad compared to other options [20:17:36 CET] <kerio> nut! [20:18:26 CET] <DHE> is that streamable? [20:18:40 CET] <kerio> i thought so [20:23:23 CET] <Threads> DHE tried auto instead of using a certain number ? [20:25:34 CET] <flux> dhe, how much is the mpegts overhead? I didn't know it was noticeale. [20:26:39 CET] <furq> about 10% or so [20:27:15 CET] <kerio> damn [20:27:24 CET] <furq> Threads: he's asking if frame multithreading results in quality loss [20:27:33 CET] <furq> i don't think it does [20:27:56 CET] <furq> slice multithreading definitely does, but you wouldn't use that unless you needed it anyway [20:28:14 CET] <kerio> for that 0 lag encoding [20:28:17 CET] <kerio> ;o [20:32:27 CET] <DHE> Threads: it's a machine two E5-2698v4 CPUs. that's 20 cores * hyperthreading (2) * sockets (2) = 80 [20:32:36 CET] <DHE> I am NOT allowing autodetection on this thing [20:33:21 CET] <kerio> DHE: that's a sweet-ass machine [20:33:24 CET] <kerio> ;o [20:33:41 CET] <kerio> i mean [20:33:46 CET] <kerio> if you're fine with only 20 cores [20:34:27 CET] <DHE> kerio: oh? you got something better? [20:34:42 CET] <kerio> well, the e7-8890v4 has 24 cores [20:34:44 CET] <kerio> :> [20:34:54 CET] <kerio> for only 7k monies [20:35:00 CET] <DHE> and the incremental 2699 with 22 cores also exists [20:35:20 CET] <kerio> the 8890 can be 8-socketed i think [20:35:21 CET] <DHE> but unless it has a base clock of 3 GHz (unlikely) along with all those cores, the price point is pretty bad [20:35:37 CET] <DHE> oh good, 56k monies for a full machine [20:41:16 CET] <DHE> Keridos: looked up that CPU on ark.intel.com. holy hell [20:41:37 CET] <nolaan> hello, I'm using ffmpeg to stream a webcam with rtp and ffplay to receive it. Can somebody tell me why ffplay is opening port+1 and how to avoid this behavior? [20:46:15 CET] <jkqxz> nolaan: RTP always uses two consecutive ports, the upper one is used for RTCP. [20:50:10 CET] <nolaan> okay my bad, thankss jkqxz [20:58:55 CET] <kerio> DHE: i want 8 of those ;-; [20:59:11 CET] <kerio> there's a supermicro mobo that can handle 8 of those at full ram [20:59:18 CET] <kerio> 192TB of ram ;Q_______ [20:59:20 CET] <DHE> kerio: I dunno, it's expensive as hell, needs a lot of RAM just to make it work properly [20:59:26 CET] <DHE> really? most I got was 24 TB [20:59:53 CET] <kerio> oh wait hm [20:59:56 CET] <kerio> maybe it's 24? [21:00:25 CET] <kerio> yeah i'm misremembering [21:00:32 CET] <kerio> it's 192 *cores* [21:00:39 CET] <kerio> 3TB per socket [21:00:46 CET] <kerio> so 24TB yea [21:02:13 CET] <DHE> it's like, i want one, but at the same time I don't want to have to pay for it or the upkeep (power, cooling, etc) for it. [21:12:33 CET] <JeffATL> pulled the audio off a vid and modified it in audacity (normalize, EQ, noise reduction - NOT timing). replaced it via "ffmpeg -i input.mkv -i modified_audio.mp2 -acodec copy -vcodec copy -map 0:v -map 1:a output.mkv" but now the a/v sync is off by about a second. why would this be, and is there a fix? [21:19:40 CET] <JeffATL> ffprobe says stream 0 duration is 42m02.586s, stream 1 is 49m49.032s [21:22:50 CET] <BtbN> maybe the audio stream starts late in the original file, and you didn't account for that? [21:25:26 CET] <furq> if nothing else you should have audacity export to wav and reencode it with ffmpeg [21:25:29 CET] <JeffATL> BtbN: i suppose that's possible. should i perhaps trim some unnecessary seconds off my input file? [21:25:49 CET] <furq> and if you're reencoding you might as well take the opportunity to use something that sucks less than mp2 [21:26:11 CET] <furq> ffprobe -show_streams (on the source file) will show track delays iirc [21:26:28 CET] <furq> i forget how you replicate those when remuxing, maybe -itsoffset or something [21:26:37 CET] <JeffATL> furq: for all i know audacity is using ffmpeg internally to export audio as mp2 [21:26:52 CET] <BtbN> you still don't want to encode anything as mp2. [21:27:03 CET] <furq> in my experience it's better to let ffmpeg do that while remuxing [21:27:15 CET] <furq> i've had some av sync issues in the past with stream copying that went away if i reencoded the audio at the same time [21:27:44 CET] <furq> and yeah mp2 is pretty awful [21:28:09 CET] <furq> if you're encoding the video to h264 then use aac audio [21:28:42 CET] <JeffATL> BtbN: that's how the a dn v come out of the cap card. mp2 is only "awful" for my purposes if it becomes impossible to read with future software/players or mangles the quality [21:29:03 CET] <furq> well yeah mp2 is the best option if you don't touch the audio after it comes out of the card [21:29:09 CET] <furq> but if you do, there's no reason to go back to it [21:34:37 CET] <JeffATL> when i use ffprobe -show_streams, stream 0 (v) has a start time of 0.400433 and stream 1 (a) has a start time of 0.189356 [21:34:59 CET] <JeffATL> that's on the file that came right out of the card [21:38:04 CET] <JeffATL> heck, let's see what happens if i pad the replacement audio in front by the sifference [21:38:08 CET] <JeffATL> difference [21:45:40 CET] <tab1293> im transcoding on the fly with ffmpeg and streaming directly to a browsers media source element using the x264 codec [21:46:17 CET] <tab1293> playback works but there are some stuttering happening. the odd thing is, the video only stutters as ffmpeg transcodes, once the transcoding completes the stuttering stops [21:46:48 CET] <tab1293> I know this is a pretty general question, but can anyone think of why this may be happening? [21:47:04 CET] <JeffATL> tab1293: how many cores you got? [21:47:27 CET] <tab1293> im running ffmpeg in the cloud on a two core machine, playback and transcoding are happening on separate machines [21:48:21 CET] <JeffATL> ah thank ah foun yer problum [21:48:38 CET] <tab1293> what the two core machine? [21:49:15 CET] <BtbN> what speed is ffmpeg running at? [21:49:25 CET] <BtbN> If it's not at 1x, you're going to get trouble [21:49:27 CET] <tab1293> averages at like 1.2x [21:49:47 CET] <JeffATL> you've got trans-internet hops in your ffmpeg i/o [21:49:48 CET] <tab1293> no it is, im using ultrafast preset, ive even seen it at 2x and the stuttering still occurs [21:50:29 CET] <tab1293> JeffATL: why would that not happen after the ffmpeg proccess finishes though? [21:50:54 CET] <tab1293> the packets are still being sent over the wire after the transcoding stops. the stuttering stops like immediately after ffmpeg finishes [21:53:19 CET] <JeffATL> tab1293: when ffmpeg is still running, there's still bidirectional traffic and those packets have to get acknowledged in some fashion, don't they? just the latency alone seems like enough to cause what you're seeing [21:54:48 CET] <tab1293> hmm Ive tested locally (both playback and transcoding on same machine) and still saw the stuttering, but that mightve just been because my cpu was at like 90% [21:55:25 CET] <tab1293> I guess I can test with a transcoding machine on my lan [21:57:40 CET] <tab1293> but im still not 100% convinced its internet latency. like ffmpeg is writing to stdout, which is piped to a websocket and then ingested by the client [21:58:03 CET] <tab1293> even when ffmpeg finishes, there is still data going across the wire [21:58:48 CET] <tab1293> so if it was a latency issue, wouldnt i still see the stuttering? i dont get what you mean by bidrectional traffice JeffATL [22:02:02 CET] <JeffATL> tab1293: my understanding of higher-level internet function is a little foggy but if you're using some sort of cloud service your packets are very likely getting there and back via multiple paths that are always shifting - packets arrive out of order and get reordered - delays accumulate while the reorderingn accumulates [22:04:19 CET] <JeffATL> tab1293: and while ffmpeg is running that process is taking place in TX and RCV at once on both ends - it's just not something i'd trust the timing for. also, that same 2-core VM, wherever/whatever it is , is trying to do a lot at once [22:05:12 CET] <JeffATL> AND do it with virtualized interfaces, which may mean that the packet reordering and so forth is happening in software, not interface firmware [22:05:28 CET] <tab1293> okay Im going to test right now on my LAN and see what playback looks like [22:07:42 CET] <JeffATL> tab1293: watch the stress on the ffmpeg machine as you do so. [22:07:59 CET] <tab1293> will do [22:11:37 CET] Action: JeffATL likes to have xosview up on everything he touches [22:18:24 CET] <JeffATL> well, that was a good try re delaying the audio but it's still not synced up. back to drawing board [22:25:48 CET] <tab1293> JeffATL: so my transcoding machine was fine and still seeing that stuttering across the LAN [22:25:57 CET] <tab1293> as soon as ffmpeg finishes stuttering gone [22:26:01 CET] <tab1293> like instantaneously [22:26:35 CET] <tab1293> on the end of the transcode, is anything sent that may have an effect on the stream? [22:28:19 CET] <tab1293> and to be clear, its not like the stuttering is super intense, just the occasional stutter. still very annoying though [22:33:56 CET] <JeffATL> tab1293: okay. how railed up was the ffmpegging machine while this was happening? [22:34:33 CET] <tab1293> around 80% cpu [22:34:43 CET] <tab1293> but it was going at +2x rate [22:35:54 CET] <JeffATL> i'd like to know what was taking up the 80% [00:00:00 CET] --- Sat Dec 31 2016

1 0

ffmpeg-devel.log.20161229
by burek 30 Dec '16

30 Dec '16

[00:01:59 CET] <kierank> BBB: yes that was intentional [00:02:21 CET] <kierank> https://usercontent.irccloud-cdn.com/file/sP9DDca9/two_ac_coeffs.png [00:02:29 CET] <kierank> two coefficients is quite objectionable [00:06:47 CET] <iive> kierank: have you taken into account the idct permutation? [00:07:29 CET] <iive> some DSP idct reorder ac coefficients, so they can load them in a single SIMD instruction. [00:08:00 CET] <iive> so the ordering is combined with the zigzag. [00:21:40 CET] <kierank> BBB: also gcc -fsanitize=undefined doesn't complain [00:25:38 CET] <BBB> hm... [00:25:42 CET] <BBB> is that 2x1 or 2x2 coeffs? [00:26:16 CET] <kierank> 1x DC and 2x AC [00:26:20 CET] <kierank> should I put another AC in? [00:26:21 CET] <BBB> from this, I would suggest that perhaps the ac is over-dequantized [00:27:04 CET] <kierank> ok [00:27:36 CET] <BBB> is it possible that theres different quantization tables for the dc vs. ac but youre using the same quantizer for both [00:27:37 CET] <BBB> ? [00:28:21 CET] <kierank> there could be a lot of things to be honest [00:28:28 CET] <kierank> but I've checked the dequant so many times [00:29:07 CET] <kierank> the bitstream sends a really strange quant matrix [00:30:27 CET] <kierank> let's try ignoring it and using default [00:30:34 CET] <BBB> :) [00:31:37 CET] <BBB> can you debug the dequant matrix also? maybe that helps [00:31:43 CET] <BBB> (debug as in printf() it) [00:34:43 CET] <kierank> http://pastebin.com/BCYSEUx7 [00:34:45 CET] <kierank> that's the quant matrix [00:34:51 CET] <kierank> that's sent in the bitstream [00:37:59 CET] <kierank> https://usercontent.irccloud-cdn.com/file/7AzrM8AB/SonyHDCAMSR [00:38:03 CET] <kierank> durandal_1707: ^ [00:38:07 CET] <kierank> that's the binary decoder [00:38:20 CET] <kierank> can you see if you can find dequant [01:24:53 CET] <BBB> kierank: that dequant table looks exceptionally weird [01:25:30 CET] <BBB> kierank: Im guessing that the dc is at a scale of 4 (so it should be 32) and all coeffs should be divided by 4 after the idct [01:26:07 CET] <kierank> the spec says the dc must be 8 [01:26:28 CET] <BBB> it might be scaled by fractional bits [01:26:43 CET] <BBB> the vp9 idct, for example, has two fractional bits [01:26:51 CET] <BBB> also, never trust the spec [01:27:00 CET] <kierank> ah yes there was something about fractional bits in the idct description [01:27:26 CET] <kierank> The coefficients are [01:27:26 CET] <kierank> represented in (n+7) bits including three fractional bits. [01:27:55 CET] <kierank> so divide by 8 after idct? [01:28:30 CET] <BBB> thats what it looks like then, yes [01:28:33 CET] <BBB> and that means the dc is 64 [01:29:16 CET] <kierank> do I need to modify the idct to do the divide or can I just do it afterwards? [01:29:55 CET] <BBB> you can do it whenever, really [01:30:03 CET] <kierank> I don't understand why dc-only looks correct then [01:30:07 CET] <kierank> surely it will be dark afterwardsd [01:30:17 CET] <BBB> because your dc is missing fractional adjustment, and so is your idct [01:30:25 CET] <BBB> the ac is fractionally adjusted, but the idct isn't [01:30:33 CET] <BBB> so all ac coefficients are scaled up by a factor 8 [01:30:39 CET] <BBB> you can divide idct coeffs by 8 and test that [01:30:42 CET] <BBB> ac coeffs [01:30:49 CET] <BBB> that should give almost-correct results [01:34:09 CET] <kierank> hmm looks much better but a bit weird still [01:34:12 CET] <kierank> lemme upload photo [01:36:28 CET] <kierank> https://usercontent.irccloud-cdn.com/file/TVIpLucG/better.png [01:38:14 CET] <kierank> If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse [01:38:14 CET] <kierank> transform is represented with (n+1) bits. [01:38:26 CET] <kierank> is there another shift I am missing [01:42:56 CET] <BBB> is that with all coefficients? [01:43:19 CET] <kierank> that picture is all ac coeffs [01:43:20 CET] <BBB> not bad -as in, better than before :) [01:43:29 CET] <kierank> yeah nearly there [01:44:34 CET] <kierank> ac coefficients shifted I mean [01:44:52 CET] <BBB> maybe [01:45:01 CET] <BBB> try different shifts, e.g. divide them by 16 or 32 [01:45:09 CET] <BBB> 32 may well be correct [01:45:10 CET] <BBB> given how far theyre still off [01:45:27 CET] <BBB> and fits the n+1 bits per 1d [01:45:27 CET] <BBB> (the bas eunit being 8, plus 1 bit per 1d idct, making 32) [01:47:17 CET] <kierank> 32 looks different, things are blurrier [01:47:23 CET] <kierank> wouldn't say it's better though [01:47:25 CET] Action: kierank tries 64 [01:47:29 CET] <kierank> and 8 [01:47:43 CET] <kierank> sorry just tried 16 [01:47:44 CET] <kierank> trying 32 [01:49:02 CET] <BBB> a potential issue might be that if youre dividing the ac coeffs by a high number, that a large portion of the signal actually gets lost, so blurry is potentially what you might expect then [01:49:22 CET] <BBB> (i.e. in the real solution, youd upscale the dc by that and divide the post-idct by that, rather than dividing the ac coeffs by that) [01:49:32 CET] <BBB> (but were just playing around here to find out the issue) [01:52:27 CET] <kierank> I think / 8 looks the best [02:06:05 CET] <BBB> 8 is the one from the screenshot? [02:06:16 CET] <kierank> yes [02:07:03 CET] <BBB> very odd artifacts at this point [02:07:32 CET] <kierank> let me go back to trying a few coeffs [02:07:49 CET] <BBB> did you try default quant tables? [02:07:55 CET] <kierank> yes looked really bad [02:08:02 CET] <kierank> shifting DC was bad too [02:08:04 CET] <BBB> but it looks like some artifacts are like as if its using horizontal interlacing [02:08:10 CET] <BBB> it looks pretty terrible [02:08:35 CET] <kierank> could be a bug in coefficient extraction [02:08:56 CET] <kierank> there might be some undocumented range limits in get_xbits and similar [02:27:25 CET] <kierank> michaelni: just to check is get_xbits enough to decode table b.46? [02:28:16 CET] <iive> once again, check the permutation [02:28:27 CET] <iive> the artifacts do look like ac in wrong positions [02:33:44 CET] <iive> well, if kierank have me on ignore, i guess he'll have to figure it out on his own. [02:53:15 CET] <kierank> BBB: also weird that the matrix sends 254 but the spec says that's reserved [02:56:19 CET] <BBB> is there a reference output that you can fdct to get the intended scaled coefficients? [02:58:48 CET] <atomnuker> 1D DCTs are no simpler [02:59:21 CET] <kierank> I have no reference decoder [02:59:47 CET] <kierank> I think this will become an IDA pro job :( [03:30:53 CET] <Compn> [20:28] <iive> once again, check the permutation [03:30:53 CET] <Compn> [20:28] <iive> the artifacts do look like ac in wrong positions [03:31:27 CET] <Compn> kierank ^ [04:09:42 CET] <jamrial> durandal_170: the two av_strdup() you added to avf_aphasemeter.c are leaking [04:21:32 CET] <kierank> BBB: damn the decoder binary application only lets you output rgb :( [04:22:03 CET] <BBB> thats ok right? [04:22:12 CET] <BBB> just convert to yuv, do fdct on the planes [04:22:17 CET] <BBB> it should be approximately correct [04:22:31 CET] <BBB> spec sounds very unhelpful though :( [04:22:37 CET] <kierank> dunno, I guess, would have been nice to have yuv though [04:24:52 CET] <kierank> can ffmpeg do rgb -> yuv bt709 conversion? [04:24:54 CET] <kierank> afaik it can't [04:33:58 CET] <atomnuker> kierank: vf_colorspace should, I think it just referred to rgb as something different for some reason [04:34:23 CET] <kierank> even rgb48? [04:34:26 CET] <kierank> to yuv422p10? [04:35:37 CET] <atomnuker> huh, srgb is only listed under input transfer characteristics [04:36:00 CET] <atomnuker> (I guess it doesn't make sense as colorspace/primaries?) [04:39:05 CET] <atomnuker> BBB: will vf_colorspace do the correct thing for RGB? [04:39:25 CET] <atomnuker> (what to set as iprimaries and ispace to make itrc=srgb work?) [04:40:43 CET] <BBB> vf_colorspace only handles yuv [04:40:57 CET] <BBB> theres no reason it cant handle rgb, but I havent implemented it [04:42:07 CET] <kierank> oh right the matrix is fine 254 is allowed [04:42:18 CET] <kierank> it's not allowed for the first dc [04:43:31 CET] <atomnuker> rgb* <-> yuv* is like the most common conversion, getting that working would be able to replace swscale for like 90% of all things [04:44:10 CET] <kierank> yeah but these things need to be thought through [04:44:18 CET] <kierank> otherwise we rebuild swscale v2 [04:44:52 CET] <wm4> atomnuker: and we'd need to use the lavfi API for it... no thanks [04:44:56 CET] <atomnuker> yeah, templating like libswscale isn't cool [04:45:16 CET] <kierank> wm4: that too [04:45:19 CET] <BBB> vf_colorspace isnt intended to be swscale [04:45:27 CET] <BBB> I know it does some things more correctly than swscale [04:45:30 CET] <BBB> thats why I built it [04:48:33 CET] <BBB> but its not a generic scaler [04:48:40 CET] <BBB> in fact it doesnt even scale at all [04:54:54 CET] <wm4> " libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7506000) [04:54:54 CET] <wm4> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf734f000) [04:54:54 CET] <wm4> /lib/ld-linux.so.2 (0x5658c000) [04:54:54 CET] <wm4> libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf7323000) [04:54:55 CET] <wm4> libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf731f000) [04:54:56 CET] <wm4> libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7316000) [04:54:58 CET] <wm4> vlx@debian:/mnt/doh/sandgrube/d3_2$ ls movies/ [04:55:00 CET] <wm4> sorry [04:55:08 CET] <wm4> so... "seek_frame_generic failed as this stream seems to contain no keyframes after the target timestamp, 1002 non keyframes found" [04:55:21 CET] <wm4> it shouldn't really do this [04:55:41 CET] <wm4> instead, it should seek to the first frame [04:56:04 CET] <wm4> but nice to see that ffmpef somehow supports decoding descent 3 in-game movies [04:58:02 CET] <BBB> wm4: http://trac.ffmpeg.org/ticket/4904 [04:58:18 CET] <BBB> (same bug) [04:58:51 CET] <wm4> yeah, same bug [04:59:01 CET] <wm4> ffmpeg and its stupid heuristics [04:59:19 CET] <wm4> because broken files are more important than sane ones that are "unexpected" [04:59:21 CET] <BBB> I agree it should search back or at least thats what the default behaviour should be with no specific flags to disallow that [04:59:29 CET] <BBB> but & thats not what we do now, obviously [05:01:13 CET] <wm4> the code is even worse [05:01:15 CET] <wm4> if (nonkey++ > 1000 && st->codecpar->codec_id != AV_CODEC_ID_CDGRAPHICS) { [05:01:20 CET] <wm4> cdgraphics?? [05:01:37 CET] <cone-753> ffmpeg 03Bela Bodecs 07master:9ec52a0a9b08: libavformat/hlsenc: fix delete_segments when use_localtime_mkdir [05:01:38 CET] <wm4> probably should add interplayvideo and vp9 here lol [05:03:49 CET] <kierank> lol [05:05:17 CET] <wm4> cdg.c (cdgraphics demuxer) actually has code to mark some keyframes [05:06:13 CET] <wm4> this commit adds the cdg codec id: "lavf: cdg has large non keyframe segments and should thus be exempt from the non keyframe check in seeking. Improves seeking for cdg files." [05:06:14 CET] <wm4> by michaelni [05:06:46 CET] <wm4> "improves seeking" => allow broken seeks? wat [05:07:24 CET] <wm4> the 1000 frames heuristic was added in the same year, by michaelni: "generic seeking: fail if there are 1000 non keyframes found with no keyframe. This avoids scanning through a whole file just to fail." [05:08:39 CET] <BBB> wm4: uhm yeah we all know utils.c has very questionable code [05:08:44 CET] <BBB> lets come up with something better [05:08:53 CET] <BBB> that works for vp9, cdf, interplay as well as h264/etc. [05:09:16 CET] <wm4> <wm4> "improves seeking" => allow broken seeks? wat <- actually I got this the wrong way around, the cdg exception was added after it was observed to break with the previously added 1000 frames heuristic [05:09:22 CET] <BBB> I agree the randomness is amusing [05:10:02 CET] <BBB> sounds like we need a way to mark streams as non-resumable without keyframes" [05:10:05 CET] <BBB> like vp9 etc. [05:10:08 CET] <kierank> BBB: http://pastebin.com/svLhKFyk fixed the DC dequant [05:10:58 CET] <BBB> cool [05:11:11 CET] <BBB> the post idct has a lot of zeroes in it [05:11:13 CET] <kierank> yeah [05:11:16 CET] <BBB> but I guess thats OK? [05:11:20 CET] <kierank> not doing any shifts [05:11:36 CET] <BBB> does it look alright? [05:11:37 CET] <kierank> no [05:11:44 CET] <kierank> worse but dc is correct i think now [05:12:14 CET] <BBB> its possible something overflows inside the idct now [05:12:25 CET] <BBB> 15328 is very large, almost outside int16_t range [05:12:32 CET] <BBB> so some multiplications could overflow 32bit [05:12:37 CET] <BBB> (31+sign) [05:12:55 CET] <kierank> the actual image is a really high frequency net [05:13:11 CET] <kierank> so I wonder if shifting the coefficients and getting weird artefacts is actually the correct result [05:13:26 CET] <BBB> probably not [05:13:38 CET] <BBB> I think the 15k is causing an overflow somewhere [05:13:48 CET] <BBB> possibly at the end of the first 1d idct when youre storing intermediates [05:14:02 CET] <BBB> you may have to downshift at the end of the first 1d idct already [05:14:24 CET] <BBB> its also still a horizontal mirror [05:16:00 CET] <wm4> just removing the heuristic from the generic seek code makes seeking backwards fail as well [05:16:25 CET] <kierank> BBB: yeah *row is an int16_t ... [05:17:13 CET] <kierank> do no other codecs store such a large dc? [05:22:50 CET] <BBB> they use int32_t for this bitdepth ;) [05:22:58 CET] <kierank> BBB: if I use the float dct then shift up two to go back to 10-bit, will that work? [05:23:06 CET] <wm4> crazy times when game developers made their own relatively advanced video and audio codecs and interleaved containers [05:23:07 CET] <BBB> sure [05:23:36 CET] <BBB> kierank: using float for testing is a great idea imo [05:24:36 CET] Action: BBB sleep [05:24:38 CET] <BBB> tty tomorrow [05:29:20 CET] <wm4> woah av_index_search_timestamp is public API [05:29:39 CET] <wm4> and av_add_index_entry too [05:37:02 CET] <kierank> atomnuker: do we have a float idct? [05:37:07 CET] <kierank> I can only find the fdct [05:40:41 CET] Action: wm4 stares at the dynarray_add macro in libavformat/internal.h [05:40:53 CET] Action: kierank tries octave [05:41:52 CET] <kierank> wm4: is that some kind of riced linked list? [05:42:13 CET] <wm4> it calls av_dynarray_add, but with additional type checking via #ifdef __GNUC__ [05:58:58 CET] <wm4> meh fixing this seems too much effort after all [10:17:54 CET] <fritsch> we currently hit some "funny" limits with kodi 32 bit and ffmpeg [10:18:17 CET] <fritsch> we found that the x64 bit version of ffmpeg (zerone build) is roughly 2 times faster when doing hevc decoding [10:18:28 CET] <fritsch> that's most likely caused by the intrinsics right? [10:18:51 CET] <fritsch> e.g. the 64 bit version can / may use sse4 and stuff automatically? [10:19:13 CET] <nevcairiel> automatically ? unlikely. but we do have a variety of asm thats only available on 64-bitz [10:19:14 CET] <nevcairiel> -z [10:20:05 CET] <fritsch> quite easy test [10:20:14 CET] <fritsch> download zerone's 32 bit build and his 64 bit build [10:20:17 CET] <fritsch> take this sample: [10:20:29 CET] <fritsch> http://fritsch.fruehberger.net/samples/future-live-tv-hevc-10bit.ts [10:20:31 CET] <fritsch> and run: [10:21:09 CET] <nevcairiel> it is somewhat known that 64-bit hevc is about twice as fast then 32-bit, most of that comes from the asm thats not available on 32 [10:21:26 CET] <fritsch> ffmpeg -i future-live-tv-hevc-10bit.ts -f null - [10:21:34 CET] <nevcairiel> even more pronounced if you imported the openhevc simd improvements that are not in mainline ffmpeg [10:22:06 CET] <fritsch> then it will be the same speed? [10:22:23 CET] <nevcairiel> it will never be the same speed [10:22:30 CET] <nevcairiel> x64 is just faster no matter what you do [10:22:38 CET] <fritsch> yeah [10:22:58 CET] <fritsch> double the data per instruction (depending on instruction) [10:23:27 CET] <nevcairiel> for h264, which is more thoroughly simd'ed even on 32-bit, the difference is around 10% [10:24:02 CET] <fritsch> do you think that's roughly the same difference possible for hevc? [10:24:08 CET] <fritsch> I cannot really believe that [10:24:21 CET] <nevcairiel> possible? maybe. but will anyone care to make it possible? unlikely [10:24:25 CET] <fritsch> as yeah, there are instructions when used with 64 bit are really twice as fast [10:24:49 CET] <fritsch> hehe, yeah. We are trying to go to kodi 64 bit on windows for the next release [10:24:57 CET] <fritsch> and will leave the 32 bit world behind [10:25:21 CET] <nevcairiel> the main difference comes from SIMD, which is mostly independent of the arch, with one exception - the number of registers available, which is the limiting factor why people don't write 32-bit SIMD ASM in the first place [10:25:52 CET] <fritsch> yesh, that was also my assumption as written in my intro [10:26:07 CET] <fritsch> oki, so we should not really bother but concentrate on going the 64 bit direction? [10:26:33 CET] <JEEB> except when people talk of intrinsics they usually mean intrinsics and not asm. upstream FFmpeg doesn't take in IA32/x86_64 intrinsics [10:26:45 CET] <nevcairiel> if you want to improve 32-bit performance, feel free, but other then windows any other platforms largely don't care anymore either way [10:27:17 CET] <fritsch> i thought ffmpeg uses yasm and this also generates quite optimized instructions, right JEEB? [10:27:24 CET] <JEEB> that's what is meant with asm [10:27:46 CET] <JEEB> intrinsics is something you sprinkle within the C code and hope your compiler can optimize it well enough [10:28:07 CET] <fritsch> yeah, we do that for our gpu memory copies to system memory [10:28:30 CET] <fritsch> but other than that, we removed most of that stuff and leave it to the pros :-) [10:28:37 CET] <fritsch> by e.g. using ffmpeg methods [10:29:02 CET] <JEEB> and asm is usually a whole function implemented in asm and exported from the assembled object [10:29:19 CET] <JEEB> less simple since you can't just dump some random instructions in the middle of a function ;) [10:29:50 CET] <fritsch> i think it's good for platform comaptibility [10:30:04 CET] <fritsch> as the optimizations can be clearly separated from common code [10:30:18 CET] <fritsch> not sure how ffmpeg does that, function ptrs? [10:30:22 CET] <JEEB> yup [10:30:29 CET] <fritsch> for different archs? [10:30:56 CET] <JEEB> I think intel arch and arm (?) are the two where having pure asm works [10:31:31 CET] <JEEB> otherwise it probably is intrinsics because there's no standard assembler for that arch [11:21:11 CET] <atomnuker> I think all of my asm is 32 bits compatible but its such a pain because when you run out of registers you have to resort to very hacky methods [11:25:54 CET] <nevcairiel> you can often save a reg here and there by being a bit smarter with parameter handling and whatnot, but once those tricks are all done and you still need more ... stack yoo [12:45:25 CET] <Compn> fritsch : its possible that zeranoe is disabling something for the 32bit build in order to get it to build... [12:46:16 CET] <Compn> fritsch : i would like to see some better benchmarks , compile yourself, on hevc 64bit vs x86.... [12:50:13 CET] <Compn> i also wonder if there is some software for converting the existing 64bit code to 32bit... [12:53:00 CET] <JEEB> Compn: don't confuse the person :P There's just less 32bit SIMD for HEVC [12:54:09 CET] <Compn> right [12:54:11 CET] <Compn> that too [12:54:21 CET] <Compn> did we ever steal anything from http://simd.sourceforge.net/ ? [16:20:20 CET] <nevcairiel> updated my build system to the latest mingw-w64 release, and they still didnt manage to include vp9 dxva headers in it, despite them being submitted to master almost 10 months before the release .. how slow can you work o.o [16:22:00 CET] <JEEB> funky, how long before release did they branch off o_O [16:22:14 CET] <nevcairiel> no clue [16:22:17 CET] <nevcairiel> but more then 10 months [16:22:27 CET] <j-b> yes, 5.0 was long to come [16:22:41 CET] <j-b> nevcairiel: we're doing a 5.0.1 release soon. Any sha1 you want to backport? [16:22:53 CET] <nevcairiel> its technically a feature, i guess, no clue how they work [16:23:17 CET] <j-b> depends on how nicely it is asked and how intrusive [16:23:37 CET] <j-b> just f94008512312a54d142e97868e7585d69a323a62 ? [16:23:46 CET] <nevcairiel> that should be all, yes [16:23:56 CET] <nevcairiel> its just data structures, not even any symbols [16:24:23 CET] <j-b> I will ask. [16:24:26 CET] <j-b> nevcairiel: anything else? [16:24:38 CET] <nevcairiel> not that i'm aware, just started using 5.0 today [16:25:10 CET] <j-b> you might not like it too much :) [16:25:21 CET] <nevcairiel> is it broke? [16:25:28 CET] <j-b> a bit. [16:25:47 CET] <nevcairiel> all i build with it is x264 and ffmpeg, so maybe i get by [16:25:51 CET] <j-b> but 5.0.1 is around the corner [16:26:02 CET] <j-b> nevcairiel: sure, don't hesitate to ask other things, if needed [16:40:07 CET] <Guest28924> Hello, my name is Ezequiel. I have some problems to build the lastest ffmpeg on TinyCore 7 x86_64. Can you help me? Thanks! [16:49:08 CET] <Chloe> Guest28924 you probably want #ffmpeg [16:50:14 CET] <Guest28924> I'm not sure. I'll try there. Thanks! [17:08:41 CET] <BBB> nevcairiel: remember that thing I said yesterday (building ffmpeg for win64 using msvc)? [17:08:45 CET] <BBB> nevcairiel: I learned something new [17:09:54 CET] <BBB> nevcairiel: not only am I a fake, Im also a swindler - fun discovery, no? [17:28:23 CET] <nevcairiel> Self discovery is always fascinating [17:54:53 CET] <BBB> nevcairiel: especially when prompted by trolls [17:58:39 CET] <Gramner> BBB: my favorite comment on that stackoverflow thread is "People are earning big bucks for building ffmpeg. That's why nobody is willing to explain how to do it." [17:58:50 CET] <Chloe> if only [17:59:00 CET] <BBB> can I have some of that money? [17:59:04 CET] <BBB> would be very useful [17:59:39 CET] <BBB> I think he did finally explain what his problem is. he edited his post a couple of times and now it says that it says 1000 times that features.h is missing" [17:59:55 CET] <BBB> I dont know when it says that or what hes doing [17:59:56 CET] <nevcairiel> people get paid for building ffmpeg? [17:59:58 CET] <nevcairiel> i should get on that [18:00:05 CET] <BBB> yeah yeah, didnt you know? youtube money dude [18:00:12 CET] <BBB> every build is worth 10 youtube dollars [18:00:16 CET] <nevcairiel> offer customized builds on request! [18:00:27 CET] <nevcairiel> just the things you need, nothing more! [18:00:28 CET] <nevcairiel> :D [18:01:08 CET] <RiCON> zeranoe used to have custom builds on request [18:01:17 CET] <nevcairiel> work was using zeranoe builds until i came along, was so nice to cut the binary bloat to like one third [18:01:18 CET] <RiCON> not sure if paid or not, but it's gone with the new design [18:01:37 CET] <nevcairiel> noone needs every external library in existance [18:01:51 CET] <nevcairiel> but thats the fate of a generic build for you [18:02:24 CET] <BBB> hey nevcairiel so you build ffmpeg right? you must be rich [18:02:50 CET] <BBB> I mean, only on windows of course, building on linux is for losers that dont have features.h [18:02:51 CET] <nevcairiel> rich enough to afford a cpu to build ffmpeg with! [18:02:57 CET] <BBB> o o o [18:03:06 CET] <BBB> can I get half of your cores to build ffmpeg also? [18:03:10 CET] <BBB> we could get twice as rich! [18:03:15 CET] <nevcairiel> (i dont even know what features.h is) [18:03:24 CET] <BBB> (neither do I) [18:03:46 CET] <Gramner> you need at least one core per source file for that optimal parallell benefits [18:04:16 CET] <nevcairiel> neither mingw nor msvc have a features.h that i can see [18:04:19 CET] <nevcairiel> so .. shrug [18:04:39 CET] <nevcairiel> back to cooking my lasagna, i guess [18:04:43 CET] <BBB> enjoy [18:04:50 CET] <RiCON> there's at least three maintained scripts for building ffmpeg with mingw, what are people crying about? [18:05:10 CET] <nevcairiel> you dont even need a "script" for a basic build [18:05:19 CET] <nevcairiel> those scripts just fetch all those pesky external libraries [18:06:31 CET] <RiCON> the one i maintain at least leaves the choice to the user of how much bloat they cram into ffmpeg [18:06:37 CET] <nevcairiel> hehe [18:07:09 CET] <RiCON> though most people making issues always use the one with at least the same libs as zeranoe [18:07:50 CET] <RiCON> people want their libschroedinger [18:16:21 CET] <nevcairiel> i only ever used the important ones, x264, lame, opus, and maybe twolame for extreme cases of legacy =p [18:17:31 CET] <BBB> libvpx? [18:17:49 CET] <nevcairiel> never had a need to encode vp8/9 [18:21:51 CET] <nevcairiel> but i suppose its common enough these days [18:21:57 CET] <RiCON> lame, opus, vorbis, vpx, x264, x265 and the built-ins nvenc, avisynth, schannel should be enough for most uses [18:23:07 CET] <jamrial> you forgot fdk-aac [18:23:18 CET] <RiCON> ffaac is good enough [18:23:33 CET] <nevcairiel> my decoder actually builds speex and opencore-amr, mostly because people asked at some point about samples and it was easy [18:23:37 CET] <jamrial> we removed faac [18:23:37 CET] <RiCON> fdk makes the build unredistributable too [18:23:40 CET] <nevcairiel> fdk-aac is also nonfree [18:23:49 CET] <nevcairiel> jamrial: ffaac, not faac [18:23:49 CET] <nevcairiel> :D [18:23:57 CET] <jamrial> oh right [18:24:02 CET] <jamrial> yeah, that's good enough [18:25:47 CET] <jamrial> 99% of users are good with x264+aac+mp4 [18:26:26 CET] <jamrial> i suppose someone out there still uses libxvid because h264 is too much for their netburst/k7 rig [18:26:33 CET] <nevcairiel> heh [18:26:45 CET] <nevcairiel> i let those people suffer with built-in mpeg4enc [18:27:04 CET] <nevcairiel> its not that terrible if you tweak its parameters some, it just has awful defaults [19:31:12 CET] <BBB> I still hear reports that ffaac isnt as good as fdk_aac. is that old/uninformed/legacy/dogma? or is that still true? [19:35:56 CET] <Chloe> atomnuker: ^ [19:37:29 CET] <aballier> i think fdk_aac remains the only encoder capable of doing any version of he-aac [19:38:13 CET] <aballier> (meaning it is probably much better at lower bitrates than ffaac) [19:39:59 CET] <nevcairiel> fdk is probably still better .. how much? much less then it used to be, for sure. [20:05:59 CET] <RiCON> BBB: listening tests by kamedo still put ffaac a bit behind fdk [20:06:17 CET] <BBB> a bit is not terrible for a redistributable binary [20:06:38 CET] <RiCON> http://d.hatena.ne.jp/kamedo2/20160215/1455552816 [20:07:17 CET] <RiCON> this was before some changes, i don't think there were any other tests [20:10:27 CET] <RiCON> more recent tests compare aac with other codecs but only QAAC [21:05:37 CET] <kierank> BBB: octave idct2 looks more sane, will find a float idct to port to ffmpeg [21:06:17 CET] <BBB> sounds good [21:47:55 CET] <atomnuker> BBB: depends on the sample and bitrate but yeah for the 96-82k range fdk_aac does slightly better if you can hear it [21:48:27 CET] <atomnuker> at around 48k we win on alot more samples since fdk_aac will never use PNS nor TNS [21:49:36 CET] <atomnuker> (we also adjust the lowpass filter based on the range if the lambda's in the gutter) [21:50:52 CET] <atomnuker> btw the opus encoder I have is better than anything else other than libopus we have supported [21:51:42 CET] <nevcairiel> is it just the opus features being so nice that its apparently so easy to w rite a decent encoder? [21:52:01 CET] <atomnuker> and I'm not even doing psychoacoustics, transients, vbr, TF switching, RDO, theta tweaking, IS analysis, MS analysis, alloc slope & band boosts [21:52:58 CET] <atomnuker> nevcairiel: its purely because of the quntization and the decoupling between band amplitude and bit allocation (aac/mp3 scalefactors) [21:54:58 CET] <BBB> atomnuker: so when will you implement psychoacoustics, transients, vbr, TF switching, RDO, theta tweaking, IS analysis, MS analysis, alloc slope & band boosts? [21:55:05 CET] <BBB> atomnuker: just wondering ;) [21:55:45 CET] <atomnuker> its going to be the best one day and I'll have to [21:56:13 CET] <atomnuker> (also add flexible framesizes if that experiment works out) [22:47:56 CET] <kierank> BBB: ported a float idct, looks interesting to say the least, not right though [22:48:03 CET] <kierank> is there a reference float idct somewhere? [22:48:20 CET] <BBB> just take the one from wikipedia [22:48:27 CET] <BBB> libvpx also has one [22:48:31 CET] <kierank> y is screwed, u looks much better [22:48:32 CET] <BBB> (in the tests directory) [22:55:06 CET] <kierank> BBB: do I need to add a bias as well? [22:55:10 CET] <kierank> or just shift? [22:55:25 CET] <BBB> for rounding? [22:55:42 CET] <BBB> its float right? [22:55:48 CET] <BBB> so no loss of precision, just exponent change [22:55:59 CET] <kierank> yes and I'm directly converting to uint16_t [22:56:01 CET] <kierank> not sure if that's right [22:56:13 CET] <kierank> so uint16_t foo = float_coeff[x]; [22:57:32 CET] <kierank> http://pastebin.com/1yHNZ4xV [22:57:39 CET] <kierank> get even weird coeffs [22:58:52 CET] <BBB> I think you need to divide by 4 [22:59:01 CET] <BBB> if the number of bits per 1d idct is 1 more than the bit depth [22:59:15 CET] <BBB> then you need to remove 2 bits for the pixel conversion for a 2d idct [22:59:28 CET] <kierank> In case of mpeg2_stream = 0, The coefficients are [22:59:29 CET] <kierank> represented in (n+7) bits including three fractional bits. [22:59:37 CET] <kierank> so 7 bits, right? [23:00:01 CET] <kierank> If each pixel is represented by n bits per pixel, the input to the forward transform and output from the inverse [23:00:01 CET] <kierank> transform is represented with (n+1) bits. [23:00:17 CET] <BBB> so 2x1 + 3, I think [23:00:20 CET] <BBB> so 5 [23:00:32 CET] <BBB> but it could be any number [23:00:40 CET] <BBB> also dont forget to clip in the domain [23:00:46 CET] <kierank> yeah I guess [23:00:57 CET] <BBB> so if x < 0 x else if x >= 1024 1023 else x [23:01:19 CET] <kierank> yeah [23:01:30 CET] <BBB> look forward to seeing what you cooked up ;) [23:02:47 CET] <kierank> https://www.irccloud.com/pastebin/ZmCxNktL/ [23:02:52 CET] <kierank> still weird [23:03:22 CET] <kierank> y looks okish [23:03:24 CET] <kierank> u and v terrible [23:03:33 CET] <kierank> ah perhaps u and v needs a bias [23:04:05 CET] <kierank> not sure how the octave idct looks sane [23:04:16 CET] <kierank> https://www.irccloud.com/pastebin/Gdm9wj9r/ [23:04:18 CET] <kierank> for comparison [23:06:16 CET] <BBB> 2048 is a high value for 10bits content [23:06:31 CET] <kierank> yeah I would guess it's /4 or something [23:06:36 CET] <kierank> but it's much smoother [23:06:41 CET] <kierank> like no random zeroes [23:06:44 CET] <BBB> right [23:07:03 CET] <BBB> is that u/v or y? [23:07:06 CET] <kierank> ah the zeroes are clipping [23:07:17 CET] <kierank> perhaps I will not use av_clip [23:07:23 CET] <kierank> might be an artefact of that [23:07:32 CET] <BBB> ? [23:07:40 CET] <BBB> you should clip while converting float->int [23:07:47 CET] <BBB> i.e. do the comparison in float [23:07:54 CET] <BBB> if you know what I mean [23:07:57 CET] <kierank> yeah just reaslised that... [23:08:00 CET] <BBB> :) [23:08:11 CET] <BBB> well get somewhere eventually ;) [23:09:55 CET] <kierank> https://www.irccloud.com/pastebin/xZILSih1/ [23:11:13 CET] <BBB> still very strange [23:13:48 CET] <BBB> what I find strange is that the dc is soooooo huge [23:14:00 CET] <BBB> yet the values within are wildly flunctuating [23:14:09 CET] <BBB> between whatever and whatever [23:14:29 CET] <BBB> 15326=1915.75 if theres 3 fractional bits [23:15:19 CET] <BBB> so if the idct only takes 1 bit off& then doesnt that mean it should have a dc of ~1000? [23:15:32 CET] <BBB> yet the average of the values youre pasting is 250 or 300 or so [23:15:38 CET] <BBB> so something is still very wrong [23:15:40 CET] <kierank> I also find that odd [23:17:33 CET] <kierank> could be a spec typo [23:18:26 CET] <BBB> oh I see [23:18:31 CET] <BBB> you ported the fdct [23:18:32 CET] <BBB> :-p [23:18:49 CET] <kierank> crap, yes I did [23:18:49 CET] <BBB> the test you copied the code from is a reference fdct (8x8) to test the integer 8x8 idct [23:19:00 CET] Action: kierank can't read [23:19:43 CET] <kierank> ok the original idct i think was ok, certainly it had interesting pictures [23:19:47 CET] <kierank> the old float one [23:20:25 CET] <kierank> ok that explains why the fdct was scaling up... [23:21:10 CET] Action: kierank copies mpeg idct [23:21:41 CET] <BBB> I always thought libvpx had a reference idct also [23:21:44 CET] <BBB> cant find it though :( [23:24:15 CET] <kierank> ok let's go back to steinar''s idct [23:26:32 CET] <kierank> let me check the dc falls within the range of spec [23:28:09 CET] <kierank> might be a bitstream parsing issue [23:33:56 CET] <BBB> or were scaling the dc wrong ;) [23:38:24 CET] <kierank> doesn't mpeg2 have a dc that's high precision than AC as well [23:41:04 CET] <BBB> I dont know, it depends on the scale factors in the implementation [23:41:13 CET] <BBB> if the dc is wrong, its easy to spot [23:41:13 CET] <j-b> nevcairiel: 23:20 <@jon_y> j-b: ordinarily I wouldn't but looks alright [23:41:18 CET] <j-b> nevcairiel: so, done for 5.0.1 [23:41:30 CET] <BBB> the differences are good, but the baseline is wrong [23:46:48 CET] <kierank> dc quantised: 1043, maximum is 4095 so that seems fine [23:47:15 CET] <kierank> multiplier is weird [23:48:28 CET] <kierank> and multiplier is (8 >> intra_dc_precision) x base_quantiser scale x 8 [23:48:56 CET] <kierank> where base_quantiser_scale is 1 / dct_precision [23:49:04 CET] <kierank> so in practice 8 >> dct_precision [00:00:00 CET] --- Fri Dec 30 2016

1 0

ffmpeg.log.20161229
by burek 30 Dec '16

30 Dec '16

[00:00:07 CET] <furq> it's a w3c thing [00:00:12 CET] <leibnizzle> Completely forgot that existed, thanks so much [00:16:19 CET] <klaxa> am i correct to assume that webrtc is based on neither tcp nor udp? [00:16:43 CET] <furq> it runs on top of either [00:16:55 CET] <furq> pretty much everything on the internet has to because that's what routers support these days [00:17:09 CET] <klaxa> i once read something about "raw sockets" [00:17:32 CET] <furq> that's why people have to implement sctp on top of udp, because routers will just block it [00:17:47 CET] <klaxa> oh [00:17:58 CET] <leibnizzle> udp lite is mainline linux now though so maybe it will open up [00:18:00 CET] <furq> raw sockets are often blocked as well [00:18:13 CET] <furq> except maybe ICMP [00:18:33 CET] <klaxa> i see [00:18:36 CET] <klaxa> thanks [00:18:58 CET] <furq> a lot of routing protocols use them, but i imagine they're blocked for general internet traffic [00:19:33 CET] <leibnizzle> they're used for other stuff than internet traffic too [00:20:40 CET] <furq> stuff like that is fine for lan stuff where you can set your routers up appropriately [00:20:46 CET] <leibnizzle> CAN traffic in cars for instance [00:20:59 CET] <furq> but if you want to use something over the internet, generally you need to stick to tcp and udp [00:21:16 CET] <leibnizzle> I really think that is bound to change at some point though [00:21:24 CET] <leibnizzle> but that does seem to be a sad fact [00:21:25 CET] <furq> i hope so because it sort of sucks [00:21:47 CET] <furq> although everything seems to be going the other way [00:22:00 CET] <leibnizzle> it just makes so little sense to protect the payload with a checksum [00:22:05 CET] <furq> all the fancy new streaming protocols (if you can call them protocols) are implemented on top of http [00:22:30 CET] <leibnizzle> Perhaps it is becoming more polarized [00:22:36 CET] <leibnizzle> Because that does seem true [00:22:58 CET] <leibnizzle> But at the same time, there's projects heading in way the other direction as well [00:23:01 CET] <furq> thanks a lot, corporate firewalls [00:24:03 CET] <leibnizzle> makes sense really because streaming a netflix movie and streaming the camera of the 18-wheeler in front of you to decide whether you should overtake or not are two pretty different things [00:24:46 CET] <leibnizzle> and i'll tell you that I'd rather not do the latter with TCP :D [00:25:14 CET] <furq> i've never dug too deep into this stuff but udp generally seems "good enough" [00:25:40 CET] <leibnizzle> it's good enough but just fundamentally gross [00:25:58 CET] <leibnizzle> imo anyway haha [02:49:43 CET] <nichego> hello. is there an ffmpeg invocation that tells me whether a particular mp4 file uses edit lists or not? [02:50:13 CET] <nichego> that information is not specified in 'ffmpeg -i' output. mediainfo is silent about it as well [04:53:08 CET] <bornpilot> queston about sws_flags my options look something like this -sws_flags area -sws_flags +print_info -sws_flags -full_chroma_int for the sws_flag value does the - or + mean add or negate the option? or would this be simple by -sws_flags flagOptionValue [04:54:46 CET] <bornpilot> related to this if I wanted to put this in filtergraph form would it be comma seperated vlaues i.e. sws_flags=area,print_info & [05:00:43 CET] <furq> bornpilot: iirc it'd be -sws_flags +print_info-full_chroma_int [05:03:57 CET] <bornpilot> furq thanks, so in the example what do the options + and - mean for the sws_flags value? [05:04:14 CET] <furq> add and remove [05:06:56 CET] <bornpilot> if no value is set for an sws_flags is it implied add or remove? [06:46:02 CET] <UV> Hi. I'm following the compilation guide for ffmpeg on debian testing from here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [06:48:09 CET] <UV> and I'm getting this error while making lib-x264: http://dpaste.com/3Q2HMJM [06:48:32 CET] <UV> any idea why this wouldbe occuring? [06:49:35 CET] <UV> this is on debian sid [06:50:20 CET] <UV> sorry, I meant debian testing, not sid. [06:50:59 CET] <furq> what's wrong with the ffmpeg in the repos [06:53:00 CET] <UV> nothing, but I was trying to compile against the newest lib-x264 [06:53:41 CET] <UV> and trying to fix this error [09:33:21 CET] <nirvanko> Hi everyone. top -H shows that ffmpeg has a lot of threads but only few of them are actually doing something for all others TIME+ is zero. Why? [09:34:33 CET] <IamTrying> https://www.amazon.com/FFmpeg-Basics-Multimedia-handling-encoder/dp/1479327… - Is this BOOK good? how to use the FFMpeg in Windows visual studio C++ or in C# which book covers somthing about it from build/compile [09:39:46 CET] <IamTrying> do you know "Frantisek Korbel" ? just bought his book, but did he wrote in the book how can i use the FFmpeg in Windows visual studio C++ or C#? [09:59:50 CET] <ahoo> hey there [10:00:46 CET] <ahoo> when extracting audio via -c:a from a youtube video, will re-encoding that aac to mp3 cause a noticeable loss in quality? [10:01:40 CET] <JEEB> -c:a copy you mean? yes, re-encoding it to a lossy format will incur loss. whether or not that loss will be notice'able is dependant on your parameters [10:04:09 CET] <ahoo> yeah, c:a copy [10:10:56 CET] <ahoo> ta [10:11:12 CET] <xeche> eh? codec copy will re-encoding? [10:11:18 CET] <xeche> uhhh.. english [10:11:24 CET] <xeche> re-encode* [10:11:55 CET] <xeche> i thought copy was a container only operation [10:12:29 CET] <pano> Hi all [10:23:26 CET] <pano> i have asked question yesterday... i get answer for it. Just in case anyone here need it :). The command should be: ffmpeg -i rtsp://{user}:{password}@{ip}:554/onvif1 -c copy -f ssegment -segment_time 20 -reset_timestamps 1 "capture-%03d.avi" . The main difference is: " -reset_timestamps 1 " . [10:23:31 CET] <markvandenborre> xeche: copy is a container only operation, but if you re-encode it afterwards from lossy aac to lossy mp3 [10:23:34 CET] <markvandenborre> ... [10:24:02 CET] <markvandenborre> pano: cool, thx [10:46:56 CET] <bencc> browsers support any sample_rate in mp3 and aac? [10:47:10 CET] <bencc> or should I use 48000 for best compatibility? [10:52:35 CET] <JEEB> xeche: no, he specifically asked if after -c copy re-encoding to MP3 would be lossy [11:10:22 CET] <bencc> how can I get the container with ffprobe? [11:10:36 CET] <bencc> like Matroska [11:11:29 CET] <bencc> -show_format [11:11:51 CET] <JEEB> yup [11:11:55 CET] <JEEB> "format_name": "matroska,webm" [11:11:55 CET] <bencc> thanks [11:11:57 CET] <JEEB> in json [11:12:27 CET] <bencc> do browsers support wav with adpcm_ms [11:12:29 CET] <bencc> ? [11:35:53 CET] <xeche> what does the "Speed" field signify when encoding [11:36:41 CET] <xeche> playback speed * x = speed ? [11:54:54 CET] <darsain> I'm trying to create a scaling command that will downscale-only to a specific megapixel value. I have this: [11:54:58 CET] <darsain> scale=min((921600/iw*ih)*iw, iw):min((921600/iw*ih)*ih, ih) [11:55:14 CET] <darsain> but I'm getting "*iw was unexpected at this time." [11:55:43 CET] <darsain> any pointers to what I'm doing wrong? :) [11:57:54 CET] <iive> xeche: you mean the text on the status bar? yes it shows how faster/slower is the encoder compared to real time. [12:02:14 CET] <xeche> iive: thanks. and the speed displayed at the end is the average speed compared to realtime playback then? [12:02:40 CET] <iive> yes [12:02:54 CET] <xeche> alrighty. sanity restored. :) [12:04:33 CET] <iive> :D [12:05:03 CET] <xeche> has anyone here ever been able to make hevc_qsv work via ffmpeg? (CLI or API) [12:05:52 CET] <xeche> reading Intel's documentation, it looks like hevc codecs are not available via the community edition [12:08:12 CET] <xeche> yeah, this is a dead end. Media Studio professional is $4000 [12:15:25 CET] <bencoh> $4000 to decode hevc in hw? [12:25:12 CET] <xeche> bencoh: encode [12:25:22 CET] <xeche> not sure if it makes a difference to be honest [12:25:34 CET] <xeche> but their docs on how to integrate with ffmpeg is littered with "you need the professional version" [12:28:37 CET] <jkqxz> What are you wanting to do with it? The hardware encoder is not very good. [12:30:58 CET] <xeche> that depends on you measure [12:31:05 CET] <xeche> how you measure, rather [12:31:27 CET] <xeche> libx265 (software) does not play nice with the CPU usage [12:32:00 CET] <xeche> to answer your question; i want to encode an HEVC stream in real time [12:35:05 CET] <jkqxz> And you don't care how good the result it? Use H.264 instead. [12:36:26 CET] <jkqxz> The hardware-only H.265 encoder on Intel (Skylake/Kaby Lake) is usable via VAAPI on Linux with the open source stuff, but it sucks. [12:37:22 CET] <xeche> jkqxz: I assume your measurement is quality. And that's a very subjective thing, so it's impossible for me to know what you mean by "good" [12:37:42 CET] <jkqxz> The proprietary Intel one has more magic (in software) which makes it better, but you end up trading off against CPU time again. [12:40:02 CET] <jkqxz> I mean the quality of the output image at the same bitrate is no better than the H.264 encoder. [12:41:15 CET] <jkqxz> In its favour, it easily manages >4K60 throughput using ~zero CPU. If this is the only thing you care about, then it's awesome. [12:47:18 CET] <xeche> jkqxz: it is very important in my use case. [12:47:43 CET] <xeche> bandwidth and CPU usage is the priority, compared to near zero compression artifacts [12:48:14 CET] <xeche> jkqxz: do you have any links to quality comparisons between 264 and 265? [12:48:44 CET] <xeche> i find it hard to believe that the 265 hw encoder does no better than a sw 264 encoder [12:52:12 CET] <jkqxz> Why? A hardware encoder doesn't have any opportunity to do anything clever at all. H.265 only gains over H.264 if you make use of the advanced features which require a lot more processing to squeeze value out of. [12:52:38 CET] <jkqxz> Also I was comparing the Intel hardware-only H.264 and H.265 encoders. x264 is better than either of those. [12:53:29 CET] <xeche> jkqxz: to get an idea of what you mean by comparable quality and good quality [12:53:44 CET] <xeche> and no, h265 by specification, does more than 264 [12:53:53 CET] <xeche> more passes, different algo, etc [12:54:40 CET] <jkqxz> All of which you can ignore and still create a valid stream. [12:54:57 CET] <xeche> then what you're saying is the QSV implementation is not standard compliant [12:55:02 CET] <jkqxz> The use of features there completely depends on the encoder which is using them. [12:55:55 CET] <jkqxz> What? No. The standard specifies how to decode the stream, it doesn't place any constraints on how you encode it. [12:59:15 CET] <xeche> it appears you're right about that part [12:59:22 CET] <xeche> at least according to wiki's write up on profiles [12:59:53 CET] <xeche> so yes, then your argument holds; 265 may well perform equal to 264 [13:01:00 CET] <JEEB> he is correct, the specification is just notes what constitutes a valid bit stream in that format [13:01:07 CET] <JEEB> it doesn't limit the encoder to do dumb or not dumb things [13:01:11 CET] <jkqxz> Profiles just add additional constraints to the set of features you are allowed to use. There is nothing which compels you to actually use them, though. [13:01:29 CET] <JEEB> as long as you can decode what an encoder produces according to the specification, it is valid [13:02:51 CET] <jkqxz> For example, you can make a trivial H.264 or H.265 encoder which encodes every macroblock as PCM. It's not very useful (the output is bigger than the input), but it is valid. [13:02:57 CET] <xeche> right. if i could actually make ffmpeg do the damned encodes, i could look for myself and compare the quality.. [13:03:22 CET] <xeche> jkqxz: point taken, technical terms aside. [13:03:37 CET] <jkqxz> Are you on Linux? [13:03:52 CET] <xeche> Windows. :P [13:06:05 CET] <jkqxz> My condolences. I have little clue, then. [13:06:22 CET] <xeche> Selected rate control mode is not supported by QSV runtime. I'm going around in circles... [13:06:51 CET] <nzbmets> Hi All, I'm having a problem compiling in chromaprint. Here's a trivial script to reproduce http://pastebin.com/s9afca2v . (It does not seem to be related to ticket #5997). I see no other open issue that may be related. [13:07:03 CET] <nzbmets> any help appreciated [13:07:33 CET] <jkqxz> I think you get that error if it doesn't load properly, since probing for a usable rate control mode with the encoder always fails if it isn't working. [13:07:37 CET] <jkqxz> Does H.264 work for you? [13:08:29 CET] <xeche> yeah, libx264 and h264_qsv both work [13:09:32 CET] <jkqxz> Right. The H.265 encode plugin really is required to get anywhere. [13:09:58 CET] <xeche> indeed it is. not statically linked to ffmpeg for licensing reasons, i assume [13:10:51 CET] <xeche> i do have that plugin installed, but I guess FFMPEG doesn't find it [13:11:03 CET] <xeche> trial version of the "professional" whatever their tool is called [13:12:02 CET] <xeche> ffmpeg -y -i MacGruber.mp4 -vcodec hevc_qsv -load_plugin hevc_hw -vcm 1 hevc_qsv.hevc [13:12:11 CET] <jkqxz> Hmm. On Linux I would suggest using strace to work out where it's looking for the plugin to load it. Maybe there is something similar on Windows? [13:12:51 CET] <xeche> does strace catch runtime linked libraries? [13:15:23 CET] <xeche> QSV uses a frontend library, the mfx dispatcher, to pick implementations [13:17:18 CET] <jkqxz> strace is below that sort of concern. It just prints system calls, so you can watch for an open() with the name of the plugin file and see where it was looking for it. [13:21:50 CET] <xeche> jkqxz: okay thanks. there is supposed to be something equivalent in WinDbg tools [13:32:31 CET] <xeche> well, it finds the dispatcher, but the dispatcher is the only intel DLL i can see [15:07:36 CET] <Tom_B_> hi all, I have a mpeg2-ts stream being written to a file continuously as a .ts file, is it possible to use ffmpeg to periodically slice the video so only the last hour or last video remains to prevent the file growing in size or will changing the file as it's being written cause a problem? [15:15:36 CET] <kerio> that's not how file descriptors work [15:16:30 CET] <markvandenborre> Tom_B_: what you want is a way to make ffmpeg record one hour slices continuously [15:16:34 CET] <kerio> you can't just make some other process seek [15:16:50 CET] <markvandenborre> then handle the deletion of the old files externally [15:16:50 CET] <markvandenborre> I guess [15:18:00 CET] <Tom_B_> yes, you're probably right. I'm trying to implement a timeshift type feature on a live stream that's being recorded as a .ts file [15:20:56 CET] <furq> https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [15:21:05 CET] <furq> that'll split the output every hour [15:21:14 CET] <furq> deleting everything else is probably doable with inotifywait or something [15:21:30 CET] <furq> or just a cron job [15:42:01 CET] <DHE> interestingly HLS is basically mpegts with a playlist file. you could probably abuse that as well. it has built-in rotation and stuff [15:43:06 CET] <kerio> that... is a very good point [15:43:07 CET] <DHE> including deleting the files [15:43:21 CET] <bencoh> Tom_B_: if you're recording stream "as-is" you might want to have a look at multicat [15:43:45 CET] <kerio> DHE: do you know if players accept mp4 in playlists rather than .ts [15:43:47 CET] <bencoh> (assuming this is indeed a udp or rtp encapsulated stream) [15:45:00 CET] <Tom_B_> I also have access to the raw data as it's received. I'm actually getting data from tvheaded using its bespoke HTSP protocol via a basic node.js interface I wrote [15:45:23 CET] <DHE> kerio: officially no [15:45:36 CET] <kerio> i didn't ask "is mp4 allowed in hls" [15:45:39 CET] <kerio> :^) [15:46:22 CET] <JEEB> fragmented ISOBMFF in HLS IIRC was recently added to the spec [15:46:29 CET] <JEEB> which Apple implements [15:55:57 CET] <furq> if "playlists" includes dash manifests then sure [16:11:31 CET] <dudududu> hi i've been getting inflate returned errors when concatenating large list (3000) of pngs. any ideas for a solution? it causes pretty big frame skips heres a screenshot http://i.imgur.com/mC43T4Q.png [16:13:51 CET] <JEEB> furq: https://tools.ietf.org/html/draft-pantos-http-live-streaming-20#section-3.3 [16:13:54 CET] <JEEB> HLS ;) [16:14:11 CET] <furq> 14:43:45 ( kerio) DHE: do you know if players accept mp4 in playlists rather than .ts [16:14:14 CET] <furq> i was responding to that [16:14:28 CET] <furq> it's cool that it's supported in hls now though [16:14:50 CET] <furq> maybe that means i'll be able to stop remuxing ts to mp4 in javascript, which is a concept that makes me feel ill [16:14:56 CET] <DHE> unfortunately my players aren't going to be new enough to meet those criteria... [16:15:38 CET] <JEEB> yeah, atm that is now only for iOS [16:15:52 CET] <JEEB> on android thankfully you have exoplayer [16:15:57 CET] <JEEB> I wonder if they added support already [16:16:16 CET] <JEEB> on embedded things you're out of luck unless you're developing the thing :P [16:20:22 CET] <__raven__> how to capture vbi data from a analogue capture card and save it to kind of teletext file? [16:30:51 CET] <dudududu> would you guys happen to know how i can tell exactly what png cause the error here? http://i.imgur.com/TLB9FVe.png [png @ 0000000004682940] [16:31:19 CET] <dudududu> i have them in a list of like 3000 so im trying to figure out which one is the problem [17:32:02 CET] <sagerdearia> What video codec is commonly used to record video of practically exact pixel colors from Xorg desktop? I want to extract specific frames during recording of pixel animation to reproduce them elsewhere. [17:34:28 CET] <kerio> it depends on how fast is your storage [17:34:31 CET] <kerio> and how fast is your cpu [17:36:23 CET] <Mavrik> yeah... huffyuv in RGB is usually resonable [17:36:33 CET] <Mavrik> or losless x264rgb [17:36:46 CET] <kerio> you mean ffvhuff [17:37:02 CET] <kerio> is lossless x264rgb actually fast enough to do realtime? [17:38:20 CET] <Mavrik> yeah [17:38:28 CET] <klaxa> depends on your cpu and throughput, but on a reasonably modern machine, yes [17:39:31 CET] <Mavrik> And I pretty much meant huffyuv :P [17:40:11 CET] <kerio> it is ;o [17:40:25 CET] <klaxa> on my laptop i get 25 fps at 3200x1800 [17:40:37 CET] <klaxa> with libx264rgb [17:40:58 CET] <klaxa> ultrafast preset, lossless [17:42:51 CET] <kerio> yea i'm getting a solid 30 at ultrafast [17:44:37 CET] <DHE> Keridos: yeah, ultrafast is just that. but if you use a slower preset you'll get a smaller file size while still being lossless [17:44:57 CET] <DHE> this is why disk throughput matters [17:45:00 CET] <kerio> wrong nickname tho [17:45:52 CET] <kerio> 100MB/s for a recording of a video tho [18:02:55 CET] <rjp421> "-f flv 'rtmp://test:ing@media.whohacked.me/live/livestream flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=1'" usually has worked, but now im getting "Problem accessing the DNS. (addr: test)" "rtmp://test:ing@media.whohacked.me/live/livestream live=1: Unknown error occurred" [18:04:55 CET] <rjp421> with the latest ffmpeg-git nightly for linux 64bit [18:07:24 CET] <rjp421> on centos6.7 [18:18:49 CET] <rhagu> Hi I would like to find out, whether ffmpeg on my ubuntu xenial machine supports multithreading, how can I do that? [18:22:30 CET] <thebombzen> rhagu: lscpu [18:22:38 CET] <thebombzen> if there is more than one "cpu" then yes [18:24:10 CET] <rhagu> thebombzen the problem is not about the number of cpus, but quite some time ago, ubuntu packaged ffmpeg without multithreading support although it was already available upstream. I am curious whether ubuntu compiles ffmpeg with multithreading enabled at the moment [18:24:33 CET] <Mavrik> uhh [18:24:45 CET] <Mavrik> Whatever they package is probably obsolete and broken. [18:24:53 CET] <Mavrik> I'd really really advise against using it :/ [18:24:58 CET] <Mavrik> Use static builds instead. [18:27:14 CET] <thebombzen> by "ubuntu packaged ffmpeg" do you mean "ubuntu packaged libav" [18:27:29 CET] <thebombzen> afaik debian derivatives still feel obligated to use the bad fork [18:27:55 CET] <thebombzen> either way rhagu the solution 98% of the time is to build it yourself [18:28:58 CET] <rhagu> thebombzen as far as I understand, ubuntu changed back to ffmpeg with 15.04 [18:30:46 CET] <thebombzen> huh. I didn't know that [18:30:59 CET] <thebombzen> as for your original question, you could try to check the build flags [18:31:12 CET] <thebombzen> afaik you disable threading with ./configure --disable-threads, so check for that flag somewhere [18:33:05 CET] <rhagu> https://paste.ubuntu.com/23707021/ as --disable-threads is not mentioned, I guess it is disabled by noww [18:39:26 CET] <furq> the recent ubuntu builds are fine afaik [18:39:59 CET] <furq> 16.10 is using 3.0.5 [18:40:15 CET] <furq> presumably the same one as debian testing from a few months ago, which was fine [18:40:43 CET] <furq> this is assuming you're using ubuntu 16.10 and not some LTS build from last century [18:41:34 CET] <rhagu> furq 16.04 [18:41:52 CET] <rhagu> version 2.8.10 [18:41:53 CET] <furq> 16.04 is on 2.8.10 which is still usable [18:42:27 CET] <rhagu> it is inside a lxc container, so I can switch to 16.10 if necessary, I want to use it as backend for emby media server [18:42:30 CET] <furq> they should just be the packages from debian testing cut at a particular date [18:42:38 CET] <furq> and those have been perfectly usable for a few years now [18:49:36 CET] <darsain> how can I make -c:v libvpx-vp9 utilize the whole CPU? it sits at around ~30% currently. the whole command looks like this: http://pastebin.com/0DpzRkMQ [18:51:16 CET] <furq> libvpx doesn't have frame multithreading, so you're limited by the resolution of the output [18:51:29 CET] <furq> also i'm pretty sure some of those options shouldn't be used any more [18:51:30 CET] <rjp421> ffmpeg wont parse the username part of the auth, "problem acccessing DNS addr user"; ./ffmpeg -loglevel info -re -i 'rtmp://jblive.videocdn.scaleengine.net/jb-live/play/jblive.stream' -vf "fps=24,scale=640x360,format=yuv420p" -c:v libx264 -profile:v main -level 30 -crf 23 -r 24 -g 48 -c:a copy -sn -f flv "rtmp://user:pass@media.whohacked.me/live/livestream flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) live=1" [18:51:39 CET] <furq> just -threads and -tile-columns are all you need now iirc [18:52:04 CET] <furq> also -movflags faststart definitely doesn't do anything with webm output [18:52:39 CET] <rjp421> i addes user/pass for auth if anyone can test that cmd [18:53:12 CET] <darsain> furq: most of that stuff is just copy pasted from recomendations in wiki and other documentation pages :) so there's no way how to speed it up? [18:53:19 CET] <furq> darsain: http://comments.gmane.org/gmane.comp.multimedia.webm.devel/1937 [18:53:31 CET] <furq> judging by that it won't use more than 4 threads for 720p [18:54:13 CET] <furq> and yeah a lot of information on libvpx is badly outdated [18:55:12 CET] <furq> you can make it faster with -speed but you'll lose quality obv [18:56:03 CET] <furq> maybe TD-Linux or someone else who actually uses libvpx can shed more light [18:56:40 CET] <TD-Linux> darsain, you mean use multiple threads? [18:57:24 CET] <darsain> TD-Linux: if it isn't doing so already, and that's why it only consumes 30% of my CPU atm, than yes [18:57:34 CET] <TD-Linux> what is "30% of your CPU" [18:58:08 CET] <TD-Linux> what resolution is this, how many cores do you have, how many is it using [18:58:58 CET] <darsain> TD-Linux: its 854x480, cpu: https://i.imgur.com/YRl8orX.png [18:59:50 CET] <TD-Linux> on windows is each of those boxes a thread? it does look odd then. you will probably only get 2 cores being used [19:00:39 CET] <TD-Linux> but I would expect to see two at 100% and the rest at 0. [19:00:40 CET] <darsain> I assume each of those boxes is a core, since its a 4 core CPU, and there are 4 boxes :) [19:00:51 CET] <TD-Linux> also I don't know what -movflags faststart does for webm, if anything, and what's the -c:v copy for [19:00:54 CET] <TD-Linux> *-c copy [19:00:59 CET] <furq> yeah windows' thread scheduling is weird like that [19:01:24 CET] <furq> idk if it's actually the scheduler or just task manager lying [19:01:35 CET] <darsain> -c copy is to set all streams to copy unless overriden by subsequent -c: commands. I got it from docs [19:01:46 CET] <furq> yeah that's fine [19:01:51 CET] <furq> movflags is only for mov/mp4 etc [19:01:58 CET] <furq> it does nothing for webm [19:02:03 CET] <darsain> k, I'll remove that [19:02:13 CET] <furq> and you should apparently remove frame-parallel now [19:03:06 CET] <furq> but yeah for 854*480 output you won't get more than two or three threads being used [19:05:31 CET] <markvandenborre> darsain: I checked if it would be possible at all to do live 720p on somewhat reasonable hardware [19:05:35 CET] <markvandenborre> the answer was no [19:05:41 CET] <markvandenborre> vp9 I mean [19:05:44 CET] <darsain> so it's encoding at 10 fps while using only 30% CPU and I can't speed it up? [19:06:07 CET] <markvandenborre> it's improved considerably between versions [19:06:07 CET] <darsain> is the encoder designed like that? so weird [19:06:11 CET] <furq> yeah this is why i don't use libvpx [19:06:29 CET] <furq> you can speed it up with -speed but you won't be able to increase the cpu utilisation [19:06:29 CET] <darsain> is there any other alternative to encode into VP9? [19:06:38 CET] <furq> there's a commercial encoder but idk how good that is [19:06:43 CET] <markvandenborre> haven't read your entire thing darsain, but vp9 encoding has only gained somewhat decent multithreading [19:06:48 CET] <markvandenborre> recently [19:06:53 CET] <furq> it's not really decent [19:06:53 CET] <markvandenborre> and it's not very efficient yet [19:07:01 CET] <markvandenborre> furq: +1 [19:07:19 CET] <furq> it won't be decent until it gets frame multithreading [19:07:30 CET] <TD-Linux> the problem is that most video sites implement threading at a higher level [19:07:30 CET] <markvandenborre> darsain: ronald bultje helped build something [19:07:32 CET] <furq> slice multithreading sucks for anything other than realtime [19:07:45 CET] <TD-Linux> so no one is really motivated to add it to libvpx [19:07:54 CET] <furq> it works for youtube because they're processing thousands of videos at a time, and they're the biggest user [19:07:57 CET] <TD-Linux> and ffmpeg doesn't support chunk threading [19:08:01 CET] <markvandenborre> https://blogs.gnome.org/rbultje/ [19:08:16 CET] <furq> and they don't encode the vp9 copy until after the initial processing is done anyway [19:08:19 CET] <TD-Linux> furq, no actually yt does really care about the speed to first playback. but they split the video into GOP-sized chunks and encode each separately [19:08:27 CET] <furq> the speed to first playback is h264 though [19:08:29 CET] <TD-Linux> they do this for the H.264 encodes too [19:08:55 CET] <furq> the speed to first vp9 playback is irrelevant if there's already an h264 stream ready to go [19:09:12 CET] <furq> and i'm pretty sure they do that first and then do the vp9 encodes after a certain view count is hit [19:11:31 CET] <furq> i guess chunk threading is at least better than slice threading though [19:12:37 CET] <jkqxz> If you want fast VP9 encode you basically have to go with hardware, though that of course compromises on the quality of the result somewhat. [19:14:48 CET] <darsain> damn. I wish h265 had a wider adoption. I'm quite all right with its results, and speeds are also decent. but can't use it if I can't play the video afterwards :/ [19:16:36 CET] <furq> x264 is still pretty good [19:17:56 CET] <darsain> but 265/vp9 cut almost half off of the filesize [19:20:58 CET] <TD-Linux> at some point I'm going to have to write my chunk threading software [19:22:00 CET] <rjp421> do i still have to rebuild ffmpeg manually with librtmp like http://sinclairmediatech.com/building-ffmpeg-for-adobe-media-server-akamai-… for the adobe rtmp user auth support? or has that been included? cause im using the latest git nightly static binary on centos6 x64, and ffmpeg doesnt like my URI :( [19:22:34 CET] <furq> the static builds have librtmp [19:22:40 CET] <klaxa> TD-Linux: inspiration, starting point, place to look for design flaws maybe? https://github.com/klaxa/Distributed-encoding [19:23:11 CET] <klaxa> wrote it a few years ago, it works generally (i think?) but it could use some polish and maybe even a general rewrite [19:23:19 CET] <furq> surely the default port should be 31337 [19:23:52 CET] <klaxa> >python2 [19:23:57 CET] <klaxa> okay, definitely needs a rewrite [19:24:17 CET] <furq> yeah you need to rewrite line 1 so it says #! /usr/bin/env python2 [19:24:24 CET] <furq> hth [19:25:37 CET] <iive> can you put options there? For some reason I though that it doesn't work like this... [19:25:52 CET] <furq> sure [19:26:23 CET] <furq> you should use env for pretty much anything that's not /bin/sh [19:26:50 CET] <c_14> You're allowed to put one option there. More than one is implementation defined. [19:27:02 CET] <furq> http://vpaste.net/zQraf [19:27:07 CET] <furq> because otherwise this will happen [19:27:23 CET] <markvandenborre> jkqxz: do you have any info on hardware vp9 encoding using foss tools? [19:27:39 CET] <rjp421> google shows this ffmpeg patch, but obviously it wasnt adopted? http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2013-January/058790.html :( [19:27:43 CET] <markvandenborre> from my quite extensive research, I was under the impression that this was not possible [19:27:55 CET] <furq> i don't think any consumer hardware supports it yet [19:28:24 CET] <furq> although if it's anything like nvenc hevc, you might as well just use libvpx -speed 8 or whatever the fastest is [19:30:04 CET] <TD-Linux> markvandenborre, yeah I think kaby lake will be the first intel chip with it [19:30:21 CET] <furq> and yeah if you're going to buy new cpus, you might as well just buy cpus with enough grunt to do it in software [19:30:58 CET] <markvandenborre> furq: :-) [19:31:14 CET] <markvandenborre> nah, for now, we stayed with h264 [19:31:32 CET] <TD-Linux> I think in general a chunk encoder would pay well. but I am curious to see how the kaby lake encoder does [19:31:33 CET] <markvandenborre> we have a budget to stay within... [19:31:39 CET] <furq> is libvpx with -speed 8 still not fast enough [19:31:58 CET] <furq> obviously you lose the bitrate benefit but it still satisfies the open-source requirement [19:32:09 CET] <furq> or license-free, rather [19:33:19 CET] <jkqxz> markvandenborre: The Kaby Lake VP9 encoder is already usable with the open-source VAAPI driver. There are some initial patches on the libav list <https://lists.libav.org/pipermail/libav-devel/2016-November/080821.html>; I'm intending to finish it off soon. [19:33:48 CET] <furq> you can't buy kaby lake desktop cpus yet can you [19:33:59 CET] <furq> although i guess it makes no difference if you only want the hw encoder [19:34:15 CET] <jkqxz> Yeah, the laptop ones are identical for this purpose. [19:34:25 CET] <furq> can you buy those yet if you're not an oem [19:34:33 CET] <jkqxz> Yes, they've been out for a few months. [19:35:28 CET] <markvandenborre> jkqxz: interesting, thank you for the info! [19:35:51 CET] <furq> guess it's time to buy one of these then [19:35:52 CET] <furq> https://www.youtube.com/watch?v=PjSThVKLbTo [19:37:55 CET] <iive> rjp421: this is main in *-cvslog" maillist. patches are sent there when they are committed. [19:38:03 CET] <iive> main/mail [19:38:16 CET] <Andulien> Hello all, if I read right, this is the chat where one might be able to receive some support on ffmpeg questions. [19:38:51 CET] <iive> Andulien: you can ask questions about ffmpeg. getting answers is ... definitely a posibility :D [19:39:08 CET] Action: iive hides [19:39:15 CET] <haroldp> trying to stream a 1280x720 webcam at a smaller size, but whatever I specify on the commandline (eg, -s 640x360), the video always seems to come out full size [19:39:27 CET] <furq> haroldp: pastebin the full command line [19:39:54 CET] <Andulien> Well let's try. I have ffmpeg installed on my Synology NAS for http streaming. Now the site has changed to https and as such I need to enable openssl and I don't know how. [19:40:10 CET] <furq> you'd need to recompile [19:40:20 CET] <haroldp> http://pastebin.com/AVJPuCFu [19:40:21 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [19:40:28 CET] <furq> or use those if there's one for the right arch [19:41:10 CET] <furq> haroldp: you can't resize if you're copying the video stream [19:41:30 CET] <furq> change -vcodec copy to -c:v lib264 [19:41:33 CET] <furq> change -vcodec copy to -c:v libx264 [19:42:16 CET] <Andulien> hmm.. ok, then I just need to figure out how to and what works for my Synology. [19:42:22 CET] <haroldp> thanks. [19:43:10 CET] <furq> Andulien: uname -m [19:43:41 CET] <iive> c_14, furq : Do you have idea why "#!/bin/bash -c" doesn't work? i tried with --version and it did work, but -c causes delay and strange message... [19:44:53 CET] <furq> bash -c expects the script as the next argument [19:45:06 CET] <furq> i'm pretty sure the shebang pipes the script to stdin [19:45:16 CET] <Andulien> armv5tel [19:45:20 CET] <furq> it would be a nightmare if it passed it as an argument [19:45:27 CET] <haroldp> hmmm, if I just drop -vcodec copy, it works (but looks awful). If I add "-c:v libx264", I can't connect with VLC anymore [19:45:30 CET] <iive> furq: i suspected that [19:45:39 CET] <furq> Andulien: i'm not sure any of those builds will work with armv5 [19:45:45 CET] <furq> you might have to build it yourself [19:46:24 CET] <furq> also you probably want gnutls rather than openssl, building with openssl was a nightmare last time i tried [19:46:37 CET] <furq> haroldp: the default codec for flv is flv1 or some other awful ancient codec [19:47:11 CET] <furq> i have no idea why it wouldn't work with h264, i assume that's what your source is and you said it worked fine when you were copying [19:48:06 CET] <haroldp> yeah, src is "Stream #0:0: Video: h264 (Baseline), yuv420p(progressive), 1280x720, 15 tbr, 90k tbn, 180k tbc" [19:48:50 CET] <c_14> furq: Are you sure? Because then #!/usr/bin/awk -f shouldn't work [19:50:38 CET] <markvandenborre> haroldp: I guess the -crf bit too is not very useful with -c copy [19:51:01 CET] <haroldp> that is true. [19:51:17 CET] <haroldp> I was trying various settings [19:51:26 CET] <Andulien> ok that's what I feared... I'll try to reach out then to the creator of the ffmpeg package in the hope that there will be an update in the future :( [19:51:37 CET] <c_14> furq, iive: it does get the filename (tested with #!/bin/echo) [19:51:53 CET] <furq> yeah i guess it does pass the filename [19:51:56 CET] <furq> that makes more sense [19:52:22 CET] <Andulien> and there is no way to enable this in the pipe I use as an option? [19:53:19 CET] <markvandenborre> Andulien: building yourself (which is not trivial, but not impossible either) or asking the packager of this ffmpeg package are the only options as far as I can see [19:53:39 CET] <markvandenborre> you might glean useful hints from the source package behind your current binary install maybe? [19:54:01 CET] <haroldp> aaaand now neither works, heh [19:57:33 CET] <Andulien> ok thank you. [19:58:27 CET] <Andulien> The strange thing is when I uninstall the package on my NAS the ffmpeg option is still there to use so it seems that ffmpeg also does not completely uninstall right? Maybe there might be more it as well uff. [19:59:41 CET] <chandoo> hi [20:01:03 CET] <chandoo> i created png from video file and i deleted before and after the image and left with images what i want, i want to create gif file out of the images, do i need to put them in sequence starting from 0000.png? [20:01:17 CET] <chandoo> my sequence starts from 0022.png it is not taking [20:01:45 CET] <chandoo> it says no file found [20:03:48 CET] <c_14> -start_image [20:03:50 CET] <c_14> iirc [20:04:19 CET] <c_14> -start_number [20:04:35 CET] <c_14> so in your case -start_number 22 [20:07:19 CET] <furq> Andulien: whereis ffmpeg [20:08:02 CET] <Andulien> -sh: whereis: command not found [20:08:24 CET] <furq> which ffmpeg [20:23:21 CET] <Andulien> hmm seems to be another installation on [20:23:23 CET] <Andulien> which ffmpeg /bin/ffmpeg [20:24:36 CET] <Andulien> is there an easy way to remove? [20:24:54 CET] <Andulien> maybe that's why it is not working, because it keeps referring to an older version? [20:53:37 CET] <Andulien> so it seems on my NAS are two instances of ffmpeg installed. Is it possible to point in my pipe to a specific one or do I need to try to uninstall both and then have just one on the system? [20:55:49 CET] <markvandenborre> Andulien: where is the other version of ffmpeg? [20:56:12 CET] <markvandenborre> (apart from the /bin/ffmpeg) [20:56:31 CET] <Andulien> Well I did a search: [20:56:44 CET] <Andulien> find / -type d -name 'ffmpeg' [20:58:12 CET] <markvandenborre> yes, so you found all directories named ffmpeg [21:00:56 CET] <markvandenborre> ? [21:03:44 CET] <markvandenborre> Andulien, the useful command was 'which ffmpeg' [21:04:05 CET] <markvandenborre> that shows you the version of the executable 'ffmpeg' currently on your path [21:04:24 CET] <markvandenborre> if you do a find, best to do at least a find / -type f -name 'ffmpeg' [21:04:46 CET] <markvandenborre> and exclude /proc and other funky pseudo filesystems [21:05:05 CET] <markvandenborre> though I'm not sure why you would want to do that [21:05:36 CET] <markvandenborre> if you have trouble finding the executable, your only option really is to wait for an updated package from the mainainter of whatever distro is running on this synology [21:06:14 CET] <markvandenborre> it's only when you've become quite a bit more fluent at *nix that building ffmpeg becomes an option [21:06:53 CET] <Andulien> Well I'm guessing that Synology has it's own downsized ffmpeg package which is used for it's Video and Audio station. Additionally I have installed from the syno community an ffmpeg package that should have the ssl option enabled but it seems that ffmpeg is only pointing to the older package [21:09:11 CET] <Andulien> ran your find and found the following [21:11:09 CET] <Andulien> are those all different installs? Or just each grabbing their part. and is there a way when running pipe:// to use a specific one? [21:18:56 CET] <ZexaronS> hello [21:19:02 CET] <Andulien> chacka that was the solution.... [21:19:10 CET] <Andulien> I just had to point it to the right ffmpeg :D [21:19:23 CET] <Andulien> Thanks for the help to troubleshoot it :D [21:19:34 CET] <ZexaronS> I found VP9 encoding super slow and I have Intel 3820 at 3.6 GHZ quad core [21:19:50 CET] <ZexaronS> so it's still kinda useless, I do all my YT downloads in WEBM now [21:20:28 CET] <ZexaronS> I was kinda resisting to use webm over mp4 but I kinda got to the point It does seem to be up to 30% better saving cost compared to H264 [21:20:58 CET] <ZexaronS> So I'm still forced to do my own stuff in x264, it's not that much tho, a few vids here and there [21:21:42 CET] <ZexaronS> I mentioned before how poor is the state of encoding industry, just because it's a niche doesn't mean it has to be totall shunned out [21:22:00 CET] <JEEB> there's theoretical improvements and then there's actual encoders [21:22:19 CET] <JEEB> like, VP9 is better than AVC, but libvpx as an encoder has some really bad issues [21:22:34 CET] <ZexaronS> Does intel QuickSync do any improvement, since this is an older Sandy Bridge-E CPU without any iGPU ... maybe new Intels have better encoding support or some actual VP/H265 HW support ? [21:22:54 CET] <ZexaronS> i mean VP9 there ... [21:23:10 CET] <JEEB> and always remember that youtube is not really indicative of anything :P they have to drink their own kool-aid no matter what. and let's not forget that they never were about transcoding with quality in mind [21:23:32 CET] <JEEB> and hardware encoders are hardware encoders, they might or might not match your use case [21:23:47 CET] <JEEB> they are usually geared for low latency and being just fast enough [21:24:14 CET] <ZexaronS> Youtube is very bad indeed, everything's ; I have a lot of experience with all kinds of DL utilities, but the ones that I settled for are CYS for Firefox addon and Chris PC Youtube Downloader, these two good ones have features I need and support DASH downloading [21:24:18 CET] <JEEB> not good compression ratios or very high speeds [21:24:33 CET] <JEEB> nobody told you about youtube-dl ? :P [21:24:41 CET] <JEEB> which is a python-based command line tool [21:24:43 CET] <ZexaronS> I think I heard it [21:24:47 CET] <ZexaronS> But never got to it [21:25:20 CET] <ZexaronS> So do you know the 2 I mentioned, does this phyton one have anything significantly better to offer ? [21:25:42 CET] <ZexaronS> One thing would be to download a custom list of URLs with a pre-defined FMT code [21:25:48 CET] <JEEB> no I do not, because all I need are the videos downloaded. it can download the DASH fragments and put them together with ffmpeg [21:26:04 CET] <JEEB> and yes, it can list formats and download the ones you need - it even has rules I think [21:26:06 CET] <ZexaronS> I have some stuff I'd like to get down at 360p Webm Dash i think the fmt is 245 [21:26:42 CET] <JEEB> anyways, yes - libvpx is slow as molasses (and has bad psychovisual optimizations and rate control) [21:26:50 CET] <JEEB> talking about VP9 that is [21:27:19 CET] <JEEB> although I think partially it might be because -threads 0 means -threads 1 @ libvpx, so you might want to put -threads XX after -i and see if that improves at all [21:27:35 CET] <JEEB> where XX is some random number of threads you want the encoder to use [21:28:01 CET] <ZexaronS> oh [21:29:42 CET] <ZexaronS> also long videos sometimes have many hours of delay for webm conversion, only mp4, i thought it was a bug at first [21:34:49 CET] <JEEB> well lol, not surprising :P [21:35:08 CET] <ZexaronS> speaking of youtube weirdness, I really don't like the whole gui terminology of resolution, it means nothing at all, and most videos that don't even have the proper resolution just get encapsulated and only after you download them you see the true resolution with mediainfo [21:35:10 CET] <JEEB> even with their encode-in-parts thing libvpx is much slower [21:36:01 CET] <ZexaronS> the whole 480p 720p 1080p thing ... this is some marketing hdtv terminology that has little use for techical stuff [21:36:16 CET] <rjp421> https://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=723 if ffmpeg includes the rtmp user-auth patch, why cant it parse -f flv rtmp://user:pass@server/app/stream ? http://pastebin.com/raw/Wz2DwQtp i get "Problem accessing the DNS. (addr: user)" [21:37:17 CET] <pbos> ZexaronS: Got any better terms? [21:37:31 CET] <JEEB> rjp421: did you quote the argument properly? :P [21:37:40 CET] <ZexaronS> this is like the words choice for youtube were there's ... as youtube targets the most support in codecs/audience, sites like twitch tv could be more suited for such terminology they could have a reason to limit broadcasters to these exact true 16:9 resolutions (divisable by 8) [21:37:41 CET] <pbos> To play devil's advocate, with all the 720p and 1080p buzz I think those are more commonplace than anything else [21:37:46 CET] <JEEB> ZexaronS: 1080p et al are actual resolutions tho :P [21:37:53 CET] <ZexaronS> words .. i meant worst [21:37:57 CET] <rjp421> JEEB, with single quotes, yes.. its in the paste [21:38:05 CET] <JEEB> "2K" and "4K" is where stuff got bad [21:38:21 CET] <JEEB> because 1920x1080 isn't 2K wide, and neither is 3840x2160 4K wide [21:38:30 CET] <JEEB> marketing, ho [21:38:30 CET] <ZexaronS> JEEB, it doesn't mean anything really, okay, I have here 1080p at 25 kb/s ... good luck [21:38:37 CET] <ZexaronS> and 5 fps [21:38:39 CET] <ZexaronS> hah [21:38:44 CET] <JEEB> yeah, sure - it has nothing to do with the quality of a thing [21:38:56 CET] <pbos> JEEB: 1920*1080/1000 is >=2k :| [21:39:16 CET] <JEEB> it just tells you the resolution, which is what those numbers are supposed to tell you in height [21:39:28 CET] <pbos> that'd make the other one 8k [21:39:33 CET] <pbos> I know nothing [21:39:53 CET] <ZexaronS> Because the wide public won't be respecting the HDTV bitrate standards, so why use HDTV monikers, it's very confusing and the actual quality is varies extremely [21:40:24 CET] <pbos> ZexaronS: What do you propose? res@ssim? [21:40:35 CET] <pbos> :) [21:42:11 CET] <ZexaronS> Well, something else, actual bitrate along with the resolution would help, or some kind of GUI meter, like the signal meter on a phone, customized per resolution according to HDTV standard, if a 1080p video has below 1000 kb/s that would be pretty low red bar sign [21:42:24 CET] <JEEB> "HDTV bit rate standards" [21:42:25 CET] <JEEB> pfft [21:42:34 CET] <JEEB> as if there are such things :P [21:42:42 CET] <ZexaronS> well if they want to use hdtv resolutuon monikers [21:42:57 CET] <ZexaronS> or get rid of them and show full resolution [21:42:58 CET] <JEEB> there are maximum bit rates over buffer in video standards' levels [21:43:31 CET] <rjp421> http://blog.mediacoderhq.com/h264-profiles-and-levels/ [21:43:40 CET] <kurufu> 1080p video of nothing happening would be just fine at <1000 kb/s [21:43:51 CET] <JEEB> but that's just the maximum values for a decoder that says it supports that level [21:44:06 CET] <DHE> There's also a summary on the wikipedia page for H264. easy to remember and find [21:44:25 CET] <ZexaronS> JEEB, i mean broadcast standards, they do have bitrates defined [21:44:29 CET] <ZexaronS> hdtv broadcast [21:44:37 CET] <JEEB> ZexaronS: broadcast standards have maximum bandwidth limits [21:44:49 CET] <JEEB> MAXIMUM that can be transferred [21:44:52 CET] <JEEB> :P [21:45:03 CET] <JEEB> be it DVB/ATSC/ISDB [21:45:20 CET] <DHE> broadcast are inherently constrained by the frequency and QAM settings they are transmitted through. though historically they are wide enough to allow MPEG-2 based 1080i [21:45:21 CET] <rjp421> ZexaronS, for reference https://support.google.com/youtube/answer/2853702 for yt live [21:48:50 CET] <DHE> dealing with broadcast TV, can confirm bitrates are all over. loosely speaking some providers will up the bitrate for sports channels, but there's no strict rules [21:49:27 CET] <ZexaronS> here's an example here from my isp http://pastebin.com/ctLQtpP2 [21:49:30 CET] <JEEB> yeah, you just have the maximum bandwidth for all of your muxes [21:49:40 CET] <JEEB> and then you fit as many or as few as you want in there [21:49:52 CET] <pbos> DHE: Not many samples, but I've seen extreme quantization in HDTV Sports [21:50:18 CET] <ZexaronS> rjp421, yes I saw those, but are those Youtube's own or have some similarity to hdtv = [21:50:19 CET] <pbos> Almost like the ball/handegg is a macroblock [21:50:19 CET] <ZexaronS> ? [21:51:02 CET] <DHE> pbos: no, I don't have a lot of samples either. and frankly people do horrible things like put interlaced SD through an upscaler to 720p and call it good [21:51:06 CET] <rjp421> ZexaronS, not sure, but i assume they are targeting the standards [21:51:11 CET] <ZexaronS> I just remember i saw once some broadcast papers and had some bitrates in, maybe just ITU recommendation [21:51:13 CET] <pbos> DHE: Technically HD, right? [21:51:27 CET] <DHE> pbos: sure, let's go with that. whatever helps them sleep at night [21:51:38 CET] <JEEB> ZexaronS: all broadcast and video format specs usually mention maximum bandwidth over a buffer [21:51:49 CET] <pbos> FWIW a lot of video chat apps switch over to HD before the bitrates on HD look better than VGA [21:51:52 CET] <JEEB> that's the maximum and how you use your bandwidth is up to them :P [21:51:56 CET] <ZexaronS> like 1080p at 8000 kb/s ... 720p at 4000 .... or maybe I read that on youtube [21:52:08 CET] <rjp421> s/standards/most commonly supported formats/ [21:52:54 CET] <JEEB> for example tokyo MX used to have a single higher bit rate 1080i channel in its ISDB-T mux, but now it has a lower bit rate 1080i channel and the rest of the bits get used onto a separate 480i mux :P [21:53:24 CET] <rjp421> i would expect youtube formatted shit to play on a smart tv etc [21:53:45 CET] <ZexaronS> but MPEG-TS is still MPEG2 ? [21:53:53 CET] <JEEB> container [21:53:57 CET] <JEEB> vs video or audio format [21:54:01 CET] <ZexaronS> ah sorry [21:54:03 CET] <DHE> MPEG-TS is a container. it typically holds H264 or MPEG2, at least in the broadcast world [21:54:06 CET] <JEEB> MPEG-2 Systems (H.222) contains MPEG-TS and MPEG-PS [21:54:27 CET] <ZexaronS> I meant, yes, they moved from MPEG2 to MPEG4 maybe that's why they moved 1080i to lower bitrate ? [21:54:35 CET] <JEEB> no [21:54:35 CET] <pbos> Recommended rates make no sense if you don't include the codec [21:54:43 CET] <ZexaronS> i mean AVC not MPEG-v4 [21:54:55 CET] <DHE> well, yes. 5.5 megabits of video in H264 is watchable [21:55:20 CET] <DHE> and the industry calls it MPEG4 even though it's MPEG4-part10 (or H264 to most people) [21:55:40 CET] <pbos> Also we're way skewed samples, maybe most people are fine with more quantization than us. [21:56:00 CET] <JEEB> anyways, minimum rates really don't make much sense in the great scale of things. people would just stuff their streams if there were such requirements or something :P [21:56:24 CET] <ZexaronS> DHE... a clusterfuck as always [21:56:46 CET] <JEEB> you'd have to standardize a whole encoding chain and in that case you'd probably just want to use something else than a static minimum bit rate [21:57:02 CET] <DHE> yeah, minimum rates are for people who have CBR issues. I avoid them and even raise the -qmin a little bit [21:57:15 CET] <ZexaronS> But not that of a big deal, I'm more pissed at 16:9 taking over 16:10 in the PC industry [21:59:10 CET] <rjp421> some devices are picky about the stream settings, be careful. for example yt says to have keyframes every 2 or 4s for best results... i prefer 24 fps with 48 gop [21:59:53 CET] <ZexaronS> with MPEG-v4 i mean the "Visual" one, i see now it's MPEG4-Part2 [22:00:03 CET] <rjp421> using 25 or 29.97 or 30fps only gave a black video on ustream and playing back on android [22:00:32 CET] <JEEB> yes, MPEG-4 Part 2 was the one where they let theoretical people have all the things they wanted to play with [22:00:42 CET] <ZexaronS> But I'm pleased they're getting rid of uneven framerates in newer connector standards [22:01:07 CET] <JEEB> hint: most features were not used in the end because they were overcomplicated and didn't actually bring the compression benefits [22:02:32 CET] <ZexaronS> so VP9 is the answer to all these ITU/IEC weirdness ... I guess it makes sense now [22:02:39 CET] <JEEB> wat [22:02:57 CET] <JEEB> no, AVC was the thing that then improved on the previous stuff [22:03:04 CET] <JEEB> because MPEG-4 Part 2 didn't work :P [22:03:14 CET] <JEEB> (hint: you can see which formats ITU-T took in as well) [22:03:19 CET] <ZexaronS> the EU borecraucy making "standards" on paper without actually having any programming skills to create an encoder [22:03:27 CET] <JEEB> ... [22:04:37 CET] <JEEB> ok, so let me set the stage a bit more correctly. HEVC standardization mailing list is open for everyone to register and even an idiot like me is on that list. their documents are all open. [22:04:42 CET] <DHE> "oh they'll make hardware encoders and it won't be an issue" (I imagine someone said) [22:04:45 CET] <ZexaronS> I was quite shocked when I found out that the H264 is only a specification on paper, without any code, and that x264 is just some 3rd-party group that made an encoder supposably more or less according to the specification [22:04:56 CET] <DHE> ZexaronS: there is a reference decoder [22:05:02 CET] <JEEB> there's a reference decoder and encoder [22:05:07 CET] <JEEB> for both AVC And HEVC [22:05:21 CET] <JEEB> how the hell else could they test their improvement theories!? [22:05:42 CET] <ZexaronS> but then nobody uses the references in practise right ? [22:05:43 CET] <JEEB> and how the hell do you think did they get their "this many % of theoretical improvements" (based on reference encoder results) [22:06:04 CET] <JEEB> ZexaronS: well x265 for example is based on the reference encoder code, except it is made faster [22:06:23 CET] <JEEB> (and it takes shortcuts of course in order to be faster) [22:06:44 CET] <JEEB> and I bet quite a few other commercial HEVC encoders started off by forking HM [22:07:12 CET] <ZexaronS> VP9 comment ... JEEB, I meant all the war between codecs it was widely reported [22:07:16 CET] <ZexaronS> with google in the mix [22:07:33 CET] <JEEB> but yes, the idea of a reference encoder and decoder package is to validate ideas, not to be production ready. if it is production ready, that's of course good - but it shouldn't be a requirement on a video format development thing [22:07:38 CET] <ZexaronS> and with royalties [22:07:57 CET] <JEEB> ZexaronS: let me get back to that. regarding "how bad the standardization stuff is". [22:08:08 CET] <JEEB> because while JCT-VC mailing list and document archives are open [22:08:14 CET] <JEEB> you know how Google did VP9? [22:08:26 CET] <JEEB> behind closed doors and I don't think anyone could contribute from the outside [22:08:51 CET] <JEEB> it also lacked a specification at all until like september, 2016 [22:09:05 CET] <JEEB> because that's when the google person at VDD said they had made one [22:09:08 CET] <JEEB> and got applause [22:09:58 CET] <JEEB> literally the only thing going for VP9 is that it's pretty much a slightly modified copy of HEVC and that el GOOG says it's royalty-free [22:10:20 CET] <ZexaronS> Well, see this is the weird thinking, it's not required, well, the market will eventually, they produce a specification, then they say it's not required to be production ready, that's their own thing they made up, everyone's going to move to VP9 and for whom will they be creating an encoder for, if it's for profit, I guess not, I guess it's just a boondoggle to get some "scientific progress" to spend money in EU borecraucy so they [22:10:20 CET] <ZexaronS> get taxpayer funding lol [22:10:48 CET] <ZexaronS> or what [22:11:16 CET] <ZexaronS> SO the whole opening up is because youtube/google wouldn't pay the royalty ? [22:11:24 CET] <JEEB> no? [22:12:18 CET] <ZexaronS> I meant to say, I didn't know HEVC is all open now, it supposed to be closed source right? --- but because YT wouldn't support it any other bailed out, they had to open it up, so is there still royalty now ? [22:12:22 CET] <JEEB> no? [22:12:33 CET] <JEEB> both AVC and HEVC are fully open source as far as the reference implementations go [22:12:39 CET] <JEEB> and both AVC and HEVC are freely available specifications [22:12:50 CET] <JEEB> also they always were [22:13:43 CET] <ZexaronS> Maybe I was in another dimension some years ago, or maybe you don't remember the royalty war? [22:13:44 CET] <JEEB> also royalties are a whole separate subject from the actual specs. MPEG-LA is completely separate from MPEG (part of ISO/IEC). [22:14:17 CET] <JEEB> there was no royalty war, the latest royalty thing I remember was HEVC getting raped by some of the corporations that designed it [22:14:23 CET] <pbos> open spec doesn't mean royalty free, but ianal [22:14:30 CET] <JEEB> well, d'uh [22:14:34 CET] <ZexaronS> Yes see how it's confusing, that's why I asked if google went on to make VP9 because of this weirdness from international organizations [22:14:35 CET] <pbos> I believe hevc have multiple patent pools [22:14:59 CET] <JEEB> pbos: three things which is what I mean with the whole rape business by the suits in the companies [22:15:16 CET] <JEEB> there's MPEG-LA (reasonable'ish), HEVC Advance (lol bring me the pop corn) and Technicolor [22:15:24 CET] <ZexaronS> VP9 slightly modified, how is that possible ... I guess because it's the specification it self was open? [22:15:46 CET] <pbos> ZexaronS: vp9 isn't really based on hevc as far as I'm aware [22:15:49 CET] <JEEB> ZexaronS: google went to make VP9 because they knew VP8 was a modified AVC and HEVC was being designed [22:15:58 CET] <JEEB> so they needed a better format [22:16:18 CET] <JEEB> pbos: I'm pretty darn sure they looked over the fence :P 64x64 blocks and all that other jazz. [22:17:16 CET] <pbos> JEEB: larger block sizes when hdtv etc is getting more popular doesn't seem like a shocker to me [22:17:55 CET] <pbos> also not sure if either vp9 or hevc were first with that, I wouldn't be surprised if academia touched it before [22:17:56 CET] <JEEB> it's not a shocker, but just look at the VP9 design and there are plenty of similarities with some differences in implementation (sometimes just not to use something described in a related patent) [22:18:07 CET] <ZexaronS> I'm thinking why doesn't some private company make their own codec and an encoder/decoder ready to use for production ... without this back and forth and with clear and simple terminology [22:18:20 CET] <JEEB> oh companies have tried that [22:18:31 CET] <JEEB> but usually they end up copying standard formats [22:18:32 CET] <JEEB> badly [22:18:46 CET] <JEEB> what do you think VP8 was if not On2's child :P [22:18:55 CET] <JEEB> On2 was then bought by el GOOG [22:19:52 CET] <JEEB> anyways, the net positive from the fact that HEVC got pretty much rolled into the dirt by some of its creators with regards to royalties is that we got the AOM thing [22:20:19 CET] <JEEB> so at the very goddamn least we don't have the next-gen thing being developed by a single entity behind closed doors (hi Google!) [22:20:57 CET] <JEEB> because with a single entity you have that single entity's business needs controlling the implementation and everything around it [22:21:07 CET] <JEEB> you can see that with libvpx [22:21:21 CET] <JEEB> rate control? youtube doesn't need it, goes out [22:21:35 CET] <JEEB> psychovisual optimizations? not a priority [22:21:53 CET] <JEEB> frame threading? we encode GOPs separately so not needed [22:22:47 CET] <JEEB> one of the original people behind VP9 did make a closed source encoder for VP9 that seems better than libvpx, just to show that it's not the format [22:23:05 CET] <JEEB> (and to of course try to make a living) [22:23:47 CET] <JEEB> https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-… [22:25:02 CET] <rjp421> JEEB, i found http://sinclairmediatech.com/building-ffmpeg-for-adobe-media-server-akamai-… and http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2013-January/058790.html im using the latest git nightly static binary on centos6 x64... is there some way to narrow down the cause? i tried installing librtmp and librtmp-devel, even though im using the static build, and it shouldnt matter.. [22:25:26 CET] <JEEB> rjp421: installing any external libraries most certainly won't help you :P [22:26:46 CET] <rjp421> i was thinking maybe i had too old a version, or was missing it.. but that shouldnt matter using the static build, i thought [22:26:57 CET] <ZexaronS> .. AOM? ... need to look that up [22:27:32 CET] <JEEB> rjp421: are you sure you're providing it the authentication parameters correctly? [22:27:36 CET] <pbos> ZexaronS: Alliance for Open Media [22:27:52 CET] <JEEB> ^ a bit of a misnomer, but still a very good thing [22:28:01 CET] <pbos> ZexaronS: Their effort is to make the nextgen codec a joint-effort one, it merges VP10, Thor and Daala efforts [22:28:06 CET] <pbos> iirc it's based on VP10 [22:28:08 CET] <JEEB> yea [22:28:15 CET] <JEEB> they forked the VP10 code base and are improving it [22:28:23 CET] <ZexaronS> JEEB, wow, so VP9 isn't even meant for much only what youtube datacenters need [22:28:23 CET] <pbos> adding ideas from Thor/Daala [22:28:25 CET] <JEEB> or well, it became the current VP10 code base I guess? [22:28:48 CET] <pbos> ZexaronS: We use it as a realtime codec in webrtc [22:29:00 CET] <JEEB> thor was the thing that caught me by surprised, and the fact that cisco sent people over to VDD in '15 [22:29:11 CET] <JEEB> like, cisco sending actual video format people [22:29:13 CET] <rjp421> JEEB, user/pass is valid atm for this testing.. and thats a cmd line i copies out of an old bash_history, where i know it was working (on the same os) [22:29:31 CET] <rjp421> im not sure what else is different, that could cause this [22:29:43 CET] <JEEB> so did you have your full command line log somewhere posted? [22:30:05 CET] <pbos> ZexaronS: https://aomedia.googlesource.com/aom/ fwiw [22:30:26 CET] <rjp421> JEEB, http://pastebin.com/raw/Wz2DwQtp [22:30:27 CET] <ZexaronS> so AOM will support a codec that has varius niches in mind ? [22:30:46 CET] <pbos> ZexaronS: Stakeholders for it have both realtime and YouTube in mind at least [22:30:53 CET] <JEEB> well, dunno if niches, but at least its design and implementation is not controlled by a single entity [22:30:55 CET] <ZexaronS> i mean, ... not purposelly denying some features to be at least somewhat good [22:31:00 CET] <pbos> I'm not closer to it in terms of that. [22:31:18 CET] <pbos> ZexaronS: I doubt that was done with VP9 either, prioritizations might have been different though [22:31:28 CET] <pbos> you can't throw all features into a codec and prioritize everything [22:31:33 CET] <pbos> assume good faith [22:31:35 CET] <JEEB> libvpx is the thing that got most of the issues, not VP9 [22:31:44 CET] <JEEB> as the blog entry I linked noted [22:32:04 CET] <JEEB> usually people have issues with libvpx, not the actual video format. the problem is that libvpx is pretty much the only VP9 encoder around. [22:32:43 CET] <JEEB> and libpvx revolves around el goog of course. and what I'm happy about is that libaom revolves just a wee bit less around el goog, although el goog is still probably the biggest contributor [22:33:04 CET] <ZexaronS> but youtube isn't using VPX right ? [22:33:17 CET] <ZexaronS> ah revolves around them .. [22:33:28 CET] <pbos> ZexaronS: YouTube uses libvpx [22:33:31 CET] <iive> what else is there to encode vp9? [22:33:32 CET] <ZexaronS> so it's only meant to work for youtube and what they need [22:33:42 CET] <JEEB> iive: eve by BBB, but that's not out there [22:33:45 CET] <ZexaronS> ah that really explains it now holy crap [22:33:53 CET] <JEEB> business needs 101 :P [22:33:58 CET] <pbos> ZexaronS: As does Chrome and Firefox, fwiw. [22:34:25 CET] <JEEB> if you don't need XYZ for business, it's not gonna get done unless there's free time and no bigger priorities [22:34:37 CET] <ZexaronS> Why don't we, FFMPEG people come up with something of our own then ... [22:34:52 CET] <JEEB> BBB did, but since he wants to make a living out of it it's closed source :P [22:35:00 CET] <JEEB> (it's the thing I linked) [22:35:23 CET] <ZexaronS> where, i was in batroom in the middle ... [22:35:32 CET] <JEEB> just scroll up :P [22:35:43 CET] <JEEB> the blogs.gnome.org one [22:35:52 CET] <ZexaronS> but it's not that, it's that Hexchat doesn't highlight urls [22:36:04 CET] <JEEB> just ctrl+F then [22:36:06 CET] <JEEB> xchat had that [22:36:17 CET] <JEEB> and hexchat is a fork of that :P [22:36:23 CET] <ZexaronS> Ronald guy? [22:36:26 CET] <JEEB> urd [22:36:28 CET] <JEEB> yes [22:37:15 CET] <JEEB> rjp421: well the best I can tell you is that you could try doing the same with -v debug [22:37:25 CET] <JEEB> it will spam you a lot more but you should get a bunch more logging [22:37:41 CET] <rjp421> ty, ill give it a shot [22:53:23 CET] <rjp421> JEEB, can i output this to a file? or even better, along with the colors so its easier to follow [22:55:25 CET] <JEEB> "2> ffmpeg.log" at the end [22:55:37 CET] <rjp421> ty again [22:55:42 CET] <JEEB> that redirects stderr (which is where ffmpeg cli outputs) to a file [23:05:52 CET] <rjp421> JEEB, 3.2MB txt :( https://media.whohacked.me/files/ffmpeg-rtmpauth.log [23:06:32 CET] <JEEB> wow, the rtmp demuxer sure is verbose [23:06:40 CET] <JEEB> might want to use a file as input for testing purposes [23:07:25 CET] <rjp421> everything was green except for the "Problem accessing the DNS. (addr: user)" [23:07:29 CET] <rjp421> ok, will do [23:07:58 CET] <JEEB> see the parsed protocol, host and app thing :P [23:14:31 CET] <ZexaronS> Found out I forgot to add moovatom faststart for all my encodes for the last ... year or so ... gah [23:15:19 CET] <ZexaronS> can moovatom be added ontop without reencoding ? [23:19:46 CET] <JEEB> ZexaronS: it's there already :P just at the end. and yes, you can do -movflags faststart with a -c copy run [23:21:19 CET] <salviadud> Hi there, I'm having trouble with ffmpeg right now... [23:21:32 CET] <salviadud> It complains about broken ffmpeg default settings detected [23:21:58 CET] <ZexaronS> cool thanks [23:22:04 CET] <salviadud> error while opnening codec for output stream #0.0 - maybe incorrect paramters such as bit_rate, rate, width or height [23:22:36 CET] <salviadud> codec rate differs from container framte rate [23:22:45 CET] <salviadud> frame * [23:23:42 CET] <salviadud> How do I create a preset? [23:23:49 CET] <salviadud> for libx264? [23:25:07 CET] <ZexaronS> emm, container's framerate, i don't think that exists [23:25:39 CET] <salviadud> dam [23:25:46 CET] <salviadud> I'm screwed I guess [23:26:04 CET] <ZexaronS> just post the details of your command [23:26:11 CET] <ZexaronS> what OS are you working with [23:26:18 CET] <salviadud> it's slackware [23:26:23 CET] <salviadud> an old linux machine [23:26:44 CET] <ZexaronS> Well, I have no idea if ffmpeg will even run over there, sorry I'm a Windows guy [23:26:44 CET] <salviadud> It's not connected to my network right now [23:26:58 CET] <ZexaronS> It doesnt need any network tho [23:27:08 CET] <salviadud> for me to post the command [23:27:14 CET] <salviadud> it be easier for me to connect to it [23:27:22 CET] <ZexaronS> how can you chat here? [23:27:26 CET] <salviadud> well, I'm gonna try something different... [23:27:34 CET] <salviadud> I'm not chatting via that computer [23:28:09 CET] <kepstin> if you're getting that 'broken ffmpeg default settings detected' message, it usually means your ffmpeg is out of date [23:28:26 CET] <kepstin> but if you could get actual copy/paste of the command line and the output, that would make it easier to help [23:28:46 CET] <salviadud> It is actually [23:28:53 CET] <salviadud> ffmpeg version 5 [23:29:08 CET] <salviadud> I might just need to compile an older version of h264 then [23:29:29 CET] <kepstin> well, that won't fix the fact that you're using broken ffmpeg default settings - it just won't complain about them [23:29:45 CET] <salviadud> good enough for me, hehe [23:29:59 CET] <kepstin> you should probably just try getting a static ffmpeg build of a newer version, and use that [23:30:46 CET] <salviadud> I'm trying out something that worked back in 2009 [23:31:00 CET] <salviadud> I guess libx264 got too advanced [23:31:15 CET] <ZexaronS> the syntax has changed in ffmpeg since yes [23:31:25 CET] <ZexaronS> bt I kinda wasn't much of a user back then [23:31:37 CET] <ZexaronS> unfortunately documentation is all outdated [23:31:57 CET] <salviadud> Maybe I'll get lucky [23:32:08 CET] <salviadud> I was trying x264 from 2016 [23:32:14 CET] <salviadud> I'm gonna go 2011 [23:33:58 CET] <salviadud> fails just the same... [23:33:59 CET] <salviadud> grrr [23:49:49 CET] <leibnizzle> Anyone know of any studies on the burstiness of bit errors over (non-wireless) IP? [00:00:00 CET] --- Fri Dec 30 2016

1 0

ffmpeg-devel.log.20161228
by burek 29 Dec '16

29 Dec '16

[00:09:12 CET] <kierank> durandal_1707: can you help me find VLCs in binary? [00:11:10 CET] <durandal_1707> sure . sleeping now. send email with binary and specification [00:13:06 CET] <kierank> ok maybe bug found [00:13:08 CET] <kierank> thanks [00:32:39 CET] <iive> nevcairiel: compiler should be using cmov, when using march that supports it. [00:32:50 CET] <nevcairiel> compilers arent always smart [00:33:36 CET] <iive> they better be, for the cpu power they are wasting :D [00:39:24 CET] <llogan> kierank: want me to retweet that? [00:39:30 CET] <kierank> llogan: yes please :) [00:40:24 CET] <ubitux> https://godbolt.org/g/dD86ee [00:40:54 CET] <ubitux> i see some cmov here, but i guess you're talking about another implementation? :p [00:51:54 CET] <nevcairiel> shorter then https://godbolt.org/g/SV5JgX :p [00:52:50 CET] <nevcairiel> inline asm seems to generate a whole lot of boilerplate around it [00:53:29 CET] <nevcairiel> oh adding O2 makes it nicer [00:53:46 CET] <nevcairiel> silly default [00:55:22 CET] <nevcairiel> clang actually uses more cmov and makes it branchless [01:30:10 CET] <kierank> what does this mean [01:30:10 CET] <kierank> Input stream #0:0 frame changed from size:1920x1088 fmt:yuv422p10le to size:1920x1080 fmt:yuv422p10le [01:30:10 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination [01:30:10 CET] <kierank> Error reinitializing filters! [01:30:10 CET] <kierank> Conversion failed! [01:38:43 CET] <llogan> how did you get that? [01:40:05 CET] <kierank> In the decoder I am writing: [01:40:05 CET] <kierank> ./ffmpeg_g -threads 1 -i A003C002_SR_Lite_23.98p.mxf -f rawvideo -y /dev/null [01:40:22 CET] <kierank> seems to be reading 1920x1088 from the container perhaps [01:40:23 CET] <kierank> not sure [01:47:22 CET] <kierank> michaelni: do you know why this is the case? [01:47:23 CET] <kierank> FF_ALLOCZ_OR_GOTO(s->avctx, s->blocks, 64 * 12 * 2 * sizeof(int16_t), fail) [01:47:32 CET] <kierank> is there already an mpegvideo codec that is doing 10-bit? [02:11:35 CET] <iive> kierank: 12 is for yuv444 [02:13:17 CET] <iive> but indeed i don't know what the *2 is about. [02:25:14 CET] <michaelni> kierank, i think the encoder uses the 2nd set [02:26:09 CET] <kierank> michaelni: can a 10-bit decoder can use it? [02:27:26 CET] <kierank> also where are the mpeg-4 dcts setup? [02:28:03 CET] <kierank> oh mpv_decode_mb_internal perhaps [02:29:35 CET] <michaelni> a 10 in 32bit decoder can maybe use it [02:33:28 CET] <kierank> michaelni: any idea what this is? [02:33:28 CET] <kierank> Input stream #0:0 frame changed from size:1920x1088 fmt:yuv422p10le to size:1920x1080 fmt:yuv422p10le [02:34:00 CET] <kierank> why the hell does it care about 1920x1088 from the container [02:34:01 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination [02:35:28 CET] <kierank> there's so much magic code in mpegvideo [02:44:06 CET] <kierank> commenting out the codecpar crap in mxfdec stops the first error [02:44:09 CET] <kierank> now to deal with this [02:44:09 CET] <kierank> Output pad "default" with type video of the filter instance "Parsed_null_0" of null not connected to any destination [02:44:56 CET] <nevcairiel> the first is no error, it just informs you if something changes [02:45:27 CET] <nevcairiel> if it doesnt stop the second from happening, then you might as well just leave it [02:45:57 CET] <kierank> I didn't know that [04:29:49 CET] <kierank> michaelni: what does the -1U mean in ff_init_block_index [04:29:50 CET] <kierank> s->dest[0] = s->current_picture.f->data[0] + (int)((s->mb_x - 1U) << mb_width); [04:29:50 CET] <kierank> s->dest[1] = s->current_picture.f->data[1] + (int)((s->mb_x - 1U) << (mb_width - s->chroma_x_shift)); [04:29:50 CET] <kierank> s->dest[2] = s->current_picture.f->data[2] + (int)((s->mb_x - 1U) << (mb_width - s->chroma_x_shift)); [04:31:41 CET] <kierank> atomnuker: any idea what's causing this? https://usercontent.irccloud-cdn.com/file/YTZ9723B/frame000000.bmp [04:31:43 CET] <kierank> the transform or the coefficients? [04:31:55 CET] <kierank> durandal_1707: also ping when you are awake [04:45:27 CET] <kierank> hmm dc coefficients look ok [04:45:31 CET] <kierank> must be something wrong with AC [04:47:45 CET] <atomnuker> yep, it's the ac [04:48:43 CET] <kierank> https://usercontent.irccloud-cdn.com/file/u9sSbQg9/dc.bmp [04:48:45 CET] <kierank> atomnuker: dc coeffs ^ [04:48:52 CET] <kierank> atomnuker: does that imply that the idct scaling is ok? [05:24:03 CET] <atomnuker> yep, dc looks fine [05:24:17 CET] <kierank> crap [05:24:24 CET] <kierank> so close yet so far [06:34:56 CET] Action: kierank loses the will to live [09:14:35 CET] <atomnuker> seriously, why a linked list? [09:16:10 CET] <atomnuker> I don't think I've ever had to use a linked list in any of my programs ever (except in an octree structure, but that only went one way) [09:17:03 CET] <atomnuker> is that something only people who had formal education in computer science do? [09:34:19 CET] <durandal_1707> atomnuker: what? [09:34:30 CET] <durandal_1707> kierank: pong [09:34:40 CET] <atomnuker> durandal_1707: the mjpegenc patch on the ML [10:23:13 CET] <ubitux> atomnuker: it's very common to promote linked list in formal CS, it's often presented with only advantages over arrays (even speed) [10:25:55 CET] <nevcairiel> its more common in object oriented languages though, where fancy language features make it far easier to access elements in them [10:26:57 CET] <nevcairiel> and if you have huge individual elements but an uncontrolled amount of them, its probably better then reallocing an array [10:28:38 CET] <atomnuker> no wonder CS people scream null pointer dereferences are the number one source of crashes when they use C, they dug themselves into this hole [10:29:13 CET] <atomnuker> linked lists won't be faster than an array if all you do is you loop over the elements sequentially [10:29:50 CET] <atomnuker> its an extra dereference to get the next address rather than just an add [10:35:09 CET] <JEEB> yup [10:35:51 CET] <JEEB> "- use of ++var instead of var++. this is not a c++ project." <- also, did C++ do something fancy with pre-addition? [10:36:20 CET] <JEEB> I remember people saying there was some "possible optimization" with ++var but I don't think it was C++ specific [10:36:21 CET] <nevcairiel> there are some reasons to use ++var in c++ on dumb compilers, but any decent compiler just optimizes that away [10:39:42 CET] <nevcairiel> personally i just find it ugly [10:39:43 CET] <nevcairiel> :D [10:41:13 CET] <JEEB> yes, that it is [10:48:45 CET] <cone-380> ffmpeg 03Burt P 07master:f31708002464: af_hdcd: more FATE tests [12:50:57 CET] <michaelni> kierank, the -1U subtracts 1, the U is needed to avoid some undefined behavior with the shift [14:44:14 CET] <kierank> michaelni: yes, why subtract 1 [14:58:31 CET] <michaelni> so its correct after ff_update_block_index(), and it was faster this way than in some other order of operations [16:05:24 CET] <cone-380> ffmpeg 03Thomas Turner 07master:d7a3c7427f95: avutil/tests/audio_fifo.c: Corrected test error messages [16:05:25 CET] <cone-380> ffmpeg 03Michael Bradshaw 07master:616513ef6e6d: avcodec/libopenjpegdec: Set key frame metadata [16:19:11 CET] <cone-380> ffmpeg 03Jan Sebechlebsky 07master:7c91ee01cc8b: libavformat/tee: Add fifo support for tee [17:04:16 CET] <cone-380> ffmpeg 03Paul B Mahol 07master:49abd5dbb8d1: avfilter/avf_aphasemeter: make video output optional [17:48:24 CET] <kierank> michaelni: i have problems with the idct writing before the allocated buffer, that's why i ask [17:49:15 CET] <kierank> BBB: ping [17:49:23 CET] <BBB> pong [17:51:12 CET] <kierank> BBB: so I've tried with some success getting the 10-bit dct into mpegvideo, but the picture looks ok-ish but weird. With only the dc coefficients the picture looks like I would expect. Do you have any suggestions about how to debug AC? [17:51:31 CET] <kierank> dc https://usercontent.irccloud-cdn.com/file/U4l7FE9d/dc.png [17:52:36 CET] <kierank> also the idct writes before the allocated buffer [17:53:37 CET] <kierank> I suspect this is mpegvideo.c madness though [17:54:47 CET] <BBB> the white/black patches look like near-infinite dc values in some frequency [17:55:00 CET] <BBB> assuming the input coefficients are reasonable, Id assume that means theres an overflow somewhere [17:55:09 CET] <BBB> probably intermediates not being wide enough somewhere [17:55:16 CET] <BBB> (try sanitize=integer) [17:55:52 CET] <BBB> easiest way to debug this is to take one of these blocks and print out coefficients in a 8x8 array (right?) and then print out the 8x8 residual, compare that to a standard matrix float 8x8 idct and see whats different and why [17:56:10 CET] <BBB> maybe write a checkasm function to do that with synthetic input using only 1 or 2 dc values [17:56:19 CET] <BBB> and then go from there [17:56:24 CET] <kierank> it's intra without any prediction so no residual but yes, 8x8 [17:56:45 CET] <BBB> residual is literally diff[]=idct(coeff) [17:56:58 CET] <kierank> yeah [17:57:00 CET] <kierank> michaelni: s->dest[0] = s->current_picture.f->data[0] + (int)((s->mb_x - 1U) << mb_width); [17:57:17 CET] <kierank> when s->mb_x = 0 what happens? [17:57:35 CET] <BBB> if you can give a coeff[8x8] and diff[8x8] and compare that to a float matrix idct we can start from there [17:57:47 CET] <kierank> BBB: I will fix these mpegvideo segfaults first [17:57:55 CET] <BBB> okiedokie [17:58:06 CET] <kierank> mpegvideo has been most of my problems implementing this... [17:58:17 CET] <kierank> ah I can use a float dct, that's a good point [18:01:24 CET] <kierank> michaelni: yes, that line is definitely causing the segfault for me [18:08:04 CET] <kierank> frame start 0x114b0080 write location 0x114b0060 [18:13:30 CET] <michaelni> maybe you dont do the equivalent of ff_update_block_index() [18:14:13 CET] <kierank> as far as I can tell it's done in h263 [18:14:49 CET] <michaelni> "mb_width" is correct for 10bit ? [18:15:10 CET] <michaelni> block_size in ff_update_block_index() [18:15:25 CET] <kierank> - const int mb_size= 4 - s->avctx->lowres; [18:15:25 CET] <kierank> + const int mb_width= 5 - s->avctx->lowres; [18:15:25 CET] <kierank> + const int mb_height= 4 - s->avctx->lowres; [18:16:09 CET] <kierank> I believe i've handled all the width = height assumptions [18:18:30 CET] <durandal_1707> adding big structures into Ida makes it very slow [18:19:39 CET] <kierank> michaelni: http://pastebin.com/5N9fhKLh [18:19:43 CET] <kierank> those are my current mpegvideo.c changes [18:19:52 CET] <kierank> mainly removing inter for now [18:19:57 CET] <kierank> for ease of reading [18:20:13 CET] <kierank> and dealing with the two cases where width is assumed = to height [18:23:46 CET] <kierank> forcing 1920x1088 for now seems to shut valgrind up [18:24:03 CET] <kierank> oh maybe not [18:24:06 CET] <kierank> just doesn't segfault... [18:38:33 CET] <mjbshaw> I'm making a video filter source for ffmpeg. I see the width/height need to be set in AVFilterPad.config_props. The width and height of my video source is dynamic and may change from frame to frame. Is that problematic? Does the frame size change need to be signaled at all? [18:40:03 CET] <nevcairiel> dynamic reconfig is one of the silly areas of avfilter, its not supported well, there is somewhere a whitelist of filters known to handle it, iirc [18:48:20 CET] <durandal_1707> mjbshaw: why would it change from frame to frame? [18:48:35 CET] <kierank> durandal_1707: why not [18:53:39 CET] <mjbshaw> durandal_1707: The video frame is dynamically generated based on some user-specified rules. I plan on using heuristics to estimate the initial size of the output frames and will try to adhere to the estimated size, but some frames just might require a larger size to avoid information loss. [18:54:36 CET] <mjbshaw> nevcairiel: Thanks for that info. I think I'll try following buffersrc.c's behavior and permit frame size changes but log an INFO message. [18:55:11 CET] <nevcairiel> you can probably do it but expect scale filters to show up in many cases to "fix" it =p [19:01:00 CET] <BBB> nevcairiel: want to help a user get msvc 64bit working? [19:02:01 CET] <BBB> I was just called a n00b by someone who says its theoretically impossible to compile ffmpeg on msvc/64bit [19:02:26 CET] <nevcairiel> and you then want to help them? seems odd [19:02:32 CET] <BBB> good point [19:06:12 CET] <BBB> stackoverflow is interesting that way; I just stumbled on a question which is more popular: cabac or cavlc [19:06:17 CET] <BBB> which would be an interesting question [19:06:53 CET] <BBB> but the question is about an already-encoded video that he doesnt want to modify, he just wants to overlay a watermark and then encode only the watermark in cavlc/cabac (again, without re-coding the source) [19:06:55 CET] <nevcairiel> cabac probably, you only use cavlc if you are very concerned about performance I wager [19:07:00 CET] <BBB> o_O [19:13:45 CET] <nevcairiel> i see similar questions like that all the time, I want to somehow process a h264 video in its encoded form [19:13:49 CET] <nevcairiel> seems like a very crazy idea [19:19:49 CET] <cone-380> ffmpeg 03Michael Niedermayer 07master:a830ab3f3b1d: ffmpeg: remove stop_encoding variable and related code, it is dead / unused code [19:50:54 CET] <jkqxz> ~. [23:16:18 CET] <kierank> BBB: does that look sane http://pastebin.com/yYf6CzwQ [23:17:06 CET] <kierank> the dct coeffs are already zigzagged [23:17:07 CET] <BBB> not really [23:17:24 CET] <BBB> the coeff array looks sane [23:17:28 CET] <BBB> the idcted residual doesn't [23:18:28 CET] <BBB> I mean, theres a lot of zeroes, which suggests overflows& the concentration of zeroes in line 4 and 5 is also veyr suspicious [23:18:51 CET] <kierank> would explain the black patterns I get [23:19:29 CET] <BBB> I would say that horizontally, the data is essentially mirrored [23:19:41 CET] <BBB> look at line 1: imagine a divider in position 5 [23:19:46 CET] <BBB> left is 219, right is 220 [23:19:50 CET] <BBB> one step, both 117 [23:19:54 CET] <BBB> one step, 119/118 [23:19:59 CET] <BBB> one step, 662/659 [23:20:05 CET] <BBB> same is true for all following lines [23:20:14 CET] <BBB> I dont think thats right [23:20:42 CET] Action: kierank tries with only one AC coefficient [23:22:30 CET] <BBB> can you give the intermediates after the first 1d idct also? if thats not a ton of trouble [23:23:05 CET] <kierank> http://pastebin.com/SGyWFnm7 [23:23:08 CET] <kierank> that's one ac coefficient [23:23:33 CET] <BBB> yeah that makes sense [23:23:41 CET] <BBB> and if you do the ac in the other direction? same? [23:23:49 CET] <BBB> (but vertically) [23:26:14 CET] <kierank> one sec, that's a bit more fiddly to memset [23:28:57 CET] <kierank> BBB: http://pastebin.com/eNpbcetG [23:29:18 CET] <BBB> still looks good [23:30:07 CET] <BBB> I dont know if you can run this on a complete picture, but this should visibly improve the picture relative to the dc-only case [23:30:37 CET] <BBB> I guess at this point itd make sense to try the 2x2 and 4x4 topleft coefficients non-zero, and zero the rest, and see what happens [23:31:06 CET] <BBB> if the picture shows artifacts with the 1-ac coefficient (whereas the dc-only looked fine), then maybe we need to look at something else :/ [23:31:18 CET] <kierank> yes I thought the dc looked better throughout [23:31:25 CET] <kierank> but let me get some pictures [23:33:54 CET] <kierank> https://usercontent.irccloud-cdn.com/file/xHjD3nu1/dc_singleblock.png [23:34:20 CET] <BBB> whats the blackness? [23:36:39 CET] <kierank> I only did one 8x8 block in case I got something wrong in my mpegvideo.c hacking and were overlapping [23:39:14 CET] <BBB> I mean, the dc_singleblock.png looks like a mosaic tile of (obviously) dc blocks on an otherwise black background, but only ever 2nd block hor/ver is actually drawn (so 25% of total), is that intended? [23:51:09 CET] <BBB> brb - gotta run home [00:00:00 CET] --- Thu Dec 29 2016

1 0

ffmpeg.log.20161228
by burek 29 Dec '16

29 Dec '16

[00:00:40 CET] <__raven__> does anyone know why yadif produces colour artifacts in the examples? [00:02:29 CET] <pbos> __raven__: yadif is not a perfect filter [00:02:39 CET] <pbos> fwiw you can expect artefacts, especially from realtime filters [00:03:48 CET] <__raven__> from visual point of view yadif would be acceptable if it would not add some more problems to the image [00:04:52 CET] <__raven__> it seems like magenta and cyan components so might i get some issues with subsampling here? [00:05:10 CET] <pbos> probably the U,V components of your input [00:05:16 CET] <__raven__> yes [00:05:35 CET] <pbos> assuming you're not doing RGB video which would be baller [00:05:57 CET] <__raven__> ingest is yuv422p at the moment [00:06:39 CET] <pbos> no idea how this is stored on tapes, but you could also consider converting to RBG to see if the filter behaves differently [00:06:49 CET] <pbos> it's also possible that yadif doesn't support rgb [00:07:01 CET] <pbos> but I'd not be surprised if you have bleeding [00:07:28 CET] <__raven__> pbos: i think vhs is capable of something like 4.1.1 but i thought it would be better to do kind of oversampling due to analogue ways [00:08:32 CET] <furq> there's no harm using 4:2:2 [00:12:23 CET] <pbos> Don't think your codec supports 4:1:1 either way [00:13:12 CET] <pbos> __raven__: Try the slow filter, and see if it's cool [00:13:15 CET] <pbos> w/r/t bleeding [00:38:52 CET] <pbos> __raven__: This is tricky because it's a tricky problem, you're generating data out of thin air by interpolating between frames [00:38:54 CET] <pbos> FWIW [00:53:46 CET] <__raven__> yes thats why i do not want to do any real processing and are looking for a bob like method with doubled lines and bobbing filter :/ [01:00:59 CET] <pbos> __raven__: Any reason why you're satisfied/OK with the artifacts that generates but not the color bleed? [01:02:23 CET] <__raven__> i am not but i have to accept that mpeg will reduce structure information but those are not as visible as the seen colour problems [01:03:00 CET] <pbos> Did you try the slow filters furq mentioned? [01:06:55 CET] <__raven__> pbos: i tried pp=fd preset and wd3fdif but i think the results are even more worse due to wrong interpolated movement [01:12:31 CET] <furq> nnedi is the filter i mentioned [01:14:44 CET] <__raven__> nnedi similar to w3fdif [01:44:15 CET] <koldbrutality> does ffmpeg support mpeg dash with the lastest code? [01:44:24 CET] <koldbrutality> i mean with ffplay [01:50:32 CET] <jcath> friends, with avs script as input to ffmpeg, it read as raw video and cant detect the field dominance info, how i may force ffmpeg assume input as TFF or BFF ?thanks [01:55:36 CET] <furq> jcath: https://ffmpeg.org/ffmpeg-filters.html#setfield-1 [01:58:34 CET] <jcath> furq: thanks:) [02:49:02 CET] <fahadash> I have 10 .MOV files by the names 1.MOV, 2.MOV, 3.MOV, I would like to remove audio from all and save them as n_an.MOV where n is the file name. Before I write a bash script to do it, is there any ffmpeg way of doing it? [02:49:53 CET] <c_14> Not without using an external scripting language [02:50:02 CET] <klaxa> it's a one-liner really though [02:50:04 CET] <fahadash> Thanks [03:12:32 CET] <Modern13> what container supports x264/aac other than mp4/mkv/flv [03:12:40 CET] <c_14> nut [03:12:48 CET] <c_14> mpeg-ts? [03:12:48 CET] <Modern13> c_14 huh [03:13:02 CET] <Modern13> does ffmpeg support muxing to ts container? [03:13:10 CET] <c_14> sure [03:13:19 CET] <Modern13> thanks [03:13:25 CET] <c_14> yep, mpeg-ts works [03:13:29 CET] <Modern13> what about .mov [03:13:35 CET] <c_14> yep [03:13:54 CET] <c_14> afaik mov supports a superset of what .mp4 supports [03:15:03 CET] <Modern13> i jsut did .ts muxing its plays audio but not video [03:15:14 CET] <c_14> .avi should work as well [03:15:15 CET] <Modern13> are you sure .ts support x264 [03:15:25 CET] <c_14> works here [03:15:27 CET] <c_14> What player? [03:15:40 CET] <Modern13> okay let me try other players [03:17:19 CET] <Modern13> doesn't work with mpc or vlc [03:17:29 CET] <furq> it works fine with mpc [03:18:02 CET] <furq> and i'm pretty sure it works with vlc [03:18:15 CET] <furq> i don't have it installed but i've definitely watched streams in vlc which were h264 in ts [03:19:03 CET] <c_14> Well, isn't that basically all hls? [03:19:20 CET] <furq> i meant over rtsp, but yeah [03:19:31 CET] <furq> h264 in ts is incredibly commonplace [03:22:56 CET] <Modern13> wow i muxed to avi and it works [03:23:04 CET] <Modern13> avi support x264 and aac ? [03:23:08 CET] <Modern13> i didn't nkow [03:26:38 CET] <Modern13> if avi support h264/aac , why don't people use avi on them [03:31:37 CET] <c_14> Because avi is a terrible old container and everybody tries to forget it ever existed [03:32:21 CET] <Modern13> how is avi terrible [03:32:25 CET] <Modern13> it works [03:32:26 CET] <Modern13> fine [03:35:31 CET] <c_14> lots of hacks [03:41:30 CET] <Modern13> [avi @ 00000000025f7600] H.264 bitstream malformed, no startcode found, use the video bitstream filter 'h264_mp4toannexb' to fix it ('-bsf:v h264_mp4toannexb' option with ffmpeg) [03:41:31 CET] <Modern13> av_interleaved_write_frame(): Invalid data found when processing input [03:42:16 CET] <Modern13> what does -bsf:v h264_mp4toannexb do [03:43:30 CET] <c_14> There's several ways to pack H.264 NAL packets [03:43:33 CET] <c_14> AnnexB is one way [03:43:36 CET] <c_14> mp4 uses a different one [03:44:00 CET] <Modern13> what is NAL packets [03:44:18 CET] <Modern13> how come i don't get that error [03:44:27 CET] <Modern13> how come i don't get that error on my other video [03:45:03 CET] <c_14> probably because the other one was in annexb form [03:46:02 CET] <Modern13> and this one is in which form? [03:46:14 CET] <Modern13> the one with the error [03:46:43 CET] <c_14> I don't know what it's called, I just know it exists and isn't AnnexB [03:47:30 CET] <DHE> annex B specifies a bit pattern ahead of NALs. MP4 uses a length prefix instead [03:48:13 CET] <DHE> a bsf is a bitstream filter. one of them as indicated will convert mp4 to annex B notation [03:49:42 CET] <Modern13> DHE what is better? video with annexB form or video with no aneexB [03:53:29 CET] <DHE> it's not a matter of better or worse. you use the right format for the container the video goes in [03:58:18 CET] <Modern13> i get this error : [mpegts @ 00000000025db0a0] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly [03:58:31 CET] <Modern13> when i try to mux to .ts [04:07:44 CET] <gudenau> Hello! [04:09:58 CET] <gudenau> I am attempting to create a program that uses FFMPEG as a library and I would like to use hardware decoding/encoding. I'm not finding much in the way of documentation on how to use hardware for this task, just that it is possible. [04:10:38 CET] <gudenau> H264 by the way. [04:24:57 CET] <gudenau> Ping me in an answer please. [05:12:42 CET] <Modern13> anybody know how i can download this video: http://www.ipernity.com/doc/wiini/4857811 [05:14:15 CET] <gudenau> Click the download button. [05:15:38 CET] <Modern13> how do i download by wget [05:17:26 CET] <gudenau> wget dowloadButtonURL.mp4 [05:17:41 CET] <Modern13> huh [05:28:04 CET] <JeffATL> i just did this: "ffmpeg -i input.mpg -f mpeg2 -vf crop=690:470:20:0,pad=720:480:15:5 output.mpg" in order to remove some edge artifacts from a videotape rip. why did the output file become about 1/6th the size and is full of pixelly compression artifacts?? [05:36:50 CET] <JeffATL> the input was mpeg2video, yuv420p, 720x480 [05:38:54 CET] <fahadash> I am working in my filter graph, I added a output tag (or whatever the word is for labels), and I am trying to subsequently use my output tag and getting a Invalid stream specifier: tagname [05:39:09 CET] <furq> JeffATL: that command outputs mpeg2video with the default encoder settings [05:39:13 CET] <furq> idk what those are but they probably suck [05:39:53 CET] <JeffATL> furq: i'm surprised that defaults make any changes esp lossy ones [05:40:26 CET] <furq> the default is to reencode [05:40:31 CET] <JeffATL> furq: that being said, where to begin disabling? [05:40:43 CET] <furq> although if you're filtering then you have to reencode [05:41:15 CET] <JeffATL> i assume cropping/padding is a form of filtering [05:41:39 CET] <furq> they sure are [05:41:55 CET] <JeffATL> is there a way i can explicity tell ffmpeg to not do anything lossy? [05:44:08 CET] <furq> you can use a lossless output codec [05:44:15 CET] <furq> that doesn't seem like what you want to do though [05:45:02 CET] <JeffATL> furq: i'm mostly seeking to archive from tape so what i really want is clean video without regard to file size [05:45:54 CET] <furq> if file size is no issue then use something lossless [05:46:09 CET] <furq> certainly don't use mpeg2video, it's ancient and it was never much good anyway [05:46:25 CET] <furq> ffv1 and x264 lossless seem like decent choices [05:47:05 CET] <JeffATL> fair enough. the hauppauge card appears to produce mpeg2video in hardware and i don't think i have any control over that [05:47:28 CET] <furq> well yeah there's no benefit to keeping the same codec if you're filtering [05:47:56 CET] <furq> with that said i think some containers let you crop in metadata [05:48:04 CET] <furq> not sure how widespread support for that is though [05:48:45 CET] <JeffATL> also i have no idea what sw/hw might be used to edit or display in the future so i have to keep to widely implemented protocols [05:49:40 CET] <furq> well lossless is going to be huge and not supported as well as something like regular x264 [05:50:03 CET] <furq> if you're not doing further processing on these videos, x264 at crf 16 or so should look visually lossless [05:50:19 CET] <furq> 16 is probably overkill but it'll be a lot smaller than qp 0 [05:50:37 CET] <fahadash> I found my problem, I was outputting something to a labelled stream, and then using that labelled stream in two places as input, it apparently allows it to be used once... but WHY :( [05:51:30 CET] <furq> fahadash: https://ffmpeg.org/ffmpeg-filters.html#split_002c-asplit [05:51:41 CET] <furq> if you want to use the same output as an input to multiple filters [05:53:07 CET] <fahadash> furq: It's really silly that I can do [0:v] something [out]; [0:v] something more [out1]; but I cannot do [0:v] something [useful]; [useful] something1[out]; [useful]something2[out1]; [05:53:19 CET] <fahadash> Now I have to split it, give it two more different labels, and use those split labels [06:23:40 CET] <JeffATL> furq: even without using a filter - just -ss and -to to edit - it applies horrific encoding [06:24:43 CET] <furq> -c:v copy [06:25:03 CET] <JeffATL> furq: i'll try it [06:25:04 CET] <furq> or -c copy if you want to copy all streams [06:25:40 CET] <JeffATL> furq: do need stereo audio to come through [06:25:59 CET] <furq> by default ffmpeg picks codecs based on the output filename [06:26:14 CET] <furq> for mpg i assume it's mpeg2video and mp2 [06:26:27 CET] <furq> you have to specify copy if you don't want to reencode [06:29:23 CET] <JeffATL> furq: ahh, that's *much* more like it! [06:44:17 CET] <JeffATL> furq: trying now with x.264, -crf 16 along with the cropping and padding. [06:45:07 CET] <JeffATL> whew. i'm really thinking i need more CPU - 11 fps, two AMD64 cores railed up [06:45:27 CET] <furq> try with -preset faster [06:45:45 CET] <furq> that sounds awfully slow for sd though [06:46:10 CET] <JeffATL> furq: what effect does that have on the compression? [06:50:15 CET] <furq> it makes it worse [06:50:35 CET] <furq> 16 is already very high quality though [06:50:45 CET] <furq> i normally use 20 for sd stuff [07:07:43 CET] <fahadash> How do I pick one frame from a stream and show it for 5 seconds? I am thinking this: [source]trim=frame_start=x:frame_end=x+1,setpts=(PTS-STARTPTS)*5000 [07:08:08 CET] <fahadash> Basically a pause [07:15:38 CET] <markvandenborre> fahadash: how exact does this need to be? [07:16:12 CET] <markvandenborre> you might get something more cpu efficient [07:16:29 CET] <markvandenborre> when pulling only key frames from it? [07:21:06 CET] <markvandenborre> fahadash: https://github.com/FOSDEM/video/blob/master/software/ansible/playbooks/role… [07:21:11 CET] <markvandenborre> is how we do it [07:22:01 CET] <fahadash> the problem is... I don't have a start_frame... I want to start trimming at some point in timeline and pick one frame [07:23:32 CET] <markvandenborre> you don't have a start frame, which means you're just picking one frame from the stream as it is passing at this very moment, right? [07:24:23 CET] <markvandenborre> or maybe I'm misunderstanding you [07:24:59 CET] <fahadash> I want to pick the first frame at 00:00:28.0000 and I can may be loop it using loop filter [07:25:34 CET] <markvandenborre> ah... yeah, we did it this way because we had basicly an endless stream and not enough cpu [07:25:41 CET] <markvandenborre> to decode the entire stream [07:25:57 CET] <markvandenborre> so we just look at the stream every now and then [07:26:00 CET] <markvandenborre> and pick whatever [07:26:13 CET] <markvandenborre> we find as the first frame [07:27:21 CET] <markvandenborre> then loop this external command [07:27:37 CET] <markvandenborre> it was the only option for us cpu wise [07:27:44 CET] <fahadash> what does -vframe do? It is a filter? [07:28:17 CET] <markvandenborre> it sets the number of vframes to output [07:28:48 CET] <markvandenborre> https://ffmpeg.org/ffmpeg.html#Video-Options [07:32:55 CET] <markvandenborre> fahadash: so your goal is to create a 5 second movie, right? [07:33:20 CET] <markvandenborre> with an image in standstill? [07:33:58 CET] <markvandenborre> one 5 second movie from an existing animation? or multiple? [07:36:11 CET] <markvandenborre> fahadash: https://github.com/FOSDEM/video/blob/master/software/ansible/playbooks/role… is how we made a simple loop of one image [07:36:32 CET] <markvandenborre> continuously outputting as raw video on a tcp prot [07:36:33 CET] <markvandenborre> port [07:42:58 CET] <markvandenborre> fahadash: hope my hints gave you at least some inspiration [07:43:54 CET] <fahadash> switches aren't going to work for me, but thanks [07:44:29 CET] <fahadash> I am heavily relying on filter-graph to do my stuff, I have a labelled stream in my filter graph of which I need a single frame captured into another [07:44:49 CET] <fahadash> I have tried combining switches with filter-graph and have had tough luck [07:44:58 CET] <fahadash> filter-graph and switches don't mix [07:45:40 CET] <fahadash> What I ended up doing was, I trimmed 0.1 seconds of that portion, and used setpts to turn it into a super duper slo-mo [09:33:43 CET] <JeffATL> i am trying to make archival rips of videotapes using a hauppauge card that outputs mpeg2. apparently i have to tell ffmpeg to use an encoding if i use any kind of filter (i'm cropping and padding to remove edge artifacts). it was suggested earlier i use x.264 but i'm left with something that neither VLC or quicktime can play. alternative? [09:58:24 CET] <d> hi [09:59:45 CET] <Guest96715> question: Is it possible to get ffmpeg's image to webm feature working on google app script [10:00:06 CET] <Guest96715> been tinkering with it but its been kinda hazy [10:18:48 CET] <JeffATL> can anyone explain why this command, when issued on another computer, works just fine but on this one it errors as shown: https://pastebin.mozilla.org/8956852 [10:20:27 CET] <JeffATL> also, should i be putting yadif ahead of crop and pad? computer on which this command works is only managing about 3fps [10:34:51 CET] <JeffATL> think i figured my 1st question out - lack of x264 library [10:35:04 CET] <JeffATL> it's just that the error message is obtuse [10:49:41 CET] <JEEB> JeffATL: "preset" is a module-specific option so when you have no modules selected that utilize that option I'm not sure if there could be a better error. that said, yes. unfortunately that error as a global option parsing error has is something we end up before the values for options are evaluated [10:50:07 CET] <JEEB> so if you removed the -preset option it would probably complain about not having the libx264 encoder [10:50:10 CET] <JeffATL> JEEB: ok - thanks [10:50:21 CET] <JeffATL> JEEB: ah, i see [14:08:55 CET] <rivarun> hello. i'm using input from ffmpeg's showinfo with a v4l input to control a loop (is this a terrible idea to begin with?). because i want my look to run at 30 fps i use this: `-filter:v "fps=fps=30, showinfo" ` looking at the timestamps in my loop however the frames come in chunks (say 4 frames at second 53.82xxx and then a jump to 53.96xxx). is there a way to get ffmpeg to print the frame information in a [14:08:57 CET] <rivarun> stricter way or should i use a different mechanism for my loop altogether? [14:09:37 CET] <rivarun> *loops *in stricter timing [14:37:33 CET] <__raven__> hi [14:38:24 CET] <__raven__> how to capture /dev/vbi0? which data format? how to get all lines available? [16:53:14 CET] <fahadash> Is there any way in the filter-graph to sink a labelled stream just for debugging purposes? [17:37:54 CET] <durandal_1707> fahadash: nullsink? [18:19:55 CET] <pandaadb> Hello - i was wondering if someone could give me a pointer as to why my ffmpeg processes started hanging (all on the same file) [18:20:30 CET] <pandaadb> I have a python script that downloads and mp4 file and then converts it. This worked fine for the most part but then it started hanging endlessly and i ended up with a couple hundred processes just sitting there (it runs in cron every hour) [18:21:16 CET] <pandaadb> I then killed all processes to get it working again. It returned and then my python script output the stderr of the process. But i can't tell if there was something wrong with the file (and if that should cause infinite hanging) [18:22:01 CET] <pandaadb> This is the ffmpeg output: http://pastebin.com/TGFCXiv0 [18:23:32 CET] <pandaadb> I now fixed it by executing ffmpeg in a thread and adding a 5 minute timeout (my videos are max 1 min long) that then kills the ffmpeg process if it hasn't returned but i am still curious as to what was wrong. I can't reproduce it by manually running the ffmpeg however I can reproduce it by running it through python (which makes me wonder if it is something else) [18:24:49 CET] <AndrewUnmuted> I am encoding 4k ProRes HQ 4:2:2 sources for playback in VR headsets via libx264. The sources are equirectangular spherical projections. Sometimes the x264 output exhibits a good deal of temporal noise, especially on bright textures and backgrounds. What filter(s) can I invoke in FFmpeg to help reduce these artifacts? [18:26:58 CET] <pandaadb> hm, i am reading that it might the problem that the pipe is full and it can't write anymore so it starts hanging, could taht be it? [18:50:22 CET] <JeffATL> i'm trying to make archival rips of videotape using a conexant-based cap card, output is mpeg2. I take the original file and do some cropping and padding to remove edge artifacts. but why is my output file about four times bigger than input file? command is ffmpeg -i original_tape_part_1.mpg -c:v ffv1 -vf "yadif,crop=690:470:20:0,pad=720:480:15:5" test_part_1.mkv [18:51:32 CET] <kerio> ...output is ffv1 [18:54:46 CET] <JeffATL> kerio: recommend a better option? I'm not opposed to any lossy compression at all but far bigger files than input i can't hang with [18:55:06 CET] <kerio> i mean [18:55:15 CET] <kerio> i honestly don't get why you're surprised [18:55:24 CET] <kerio> that ffv1 yields bigger results than mpeg [18:55:44 CET] <kerio> why is the input mpeg, anyway? [18:56:10 CET] <JeffATL> kerio: the card encodes to mpeg2 in hardware [18:56:18 CET] <kerio> can't you leave it as is, then? [18:56:30 CET] <kerio> how good is it? [18:56:38 CET] <JeffATL> kerio: you'll have to excuse me - this is a very broad field and i'm new to it. [18:56:50 CET] <kerio> like, what's the input file's bitrate? [18:57:13 CET] <JeffATL> kerio: if i specifty no encoding, what comes out is much smaller and looks horrible [18:57:25 CET] <JeffATL> let me see if i can find that for you [18:57:29 CET] <kerio> -c:v x264 -qp 18 [18:57:36 CET] <kerio> er, make that libx264 [18:57:43 CET] <JEEB> > -qp/q:v for libx264 [18:57:50 CET] <JEEB> > for anything else than lossless [18:57:53 CET] <kerio> JEEB: fuck crf [18:58:02 CET] <JEEB> lol [18:58:04 CET] <kerio> crf killed my pet hamster [18:58:10 CET] <JEEB> have fun with that [18:58:29 CET] <kerio> i like constant qp :3 [18:58:59 CET] <JEEB> it's not really constant tho :P P and B have their offsets anyways in any mode [18:59:11 CET] <JeffATL> kerio: ffprobe on an original output file says max 8000kb/s [18:59:13 CET] <kerio> JeffATL: -crf 18 is also probably fine [18:59:15 CET] <kerio> JeffATL: lmao what [18:59:29 CET] <kerio> ...well ok that's standard def video [18:59:36 CET] <kerio> so i guess it kinda works? [18:59:50 CET] <kerio> anyway ffmpeg -i whatever.mpg -c:v libx264 -crf 18 whatever.mkv [18:59:54 CET] <JEEB> anyways, the idea of CRF is to just find the highest value that still looks good enough. same with QP but QP just is much less adaptive [19:00:11 CET] <JeffATL> kerio: yeah, and i have a TBC in front [19:00:33 CET] <kerio> also add some setting for audio i guess [19:01:11 CET] <kerio> i guess aac? [19:02:56 CET] <JeffATL> kerio: i have to be careful as i need to make sure present and future editors and players can read the files [19:03:38 CET] <kerio> maybe vp8/opus would be better then? [19:06:09 CET] <pano> hi [19:08:11 CET] <pano> i need some help please :) [19:11:26 CET] <pano> i'm trying to read rtsp stream from Sricam SP009 (Software: 14.0.0.52, System version: 24, uBoot version: 4, CPU version: 5). [19:11:51 CET] <pano> i'm using ffmpeg and running next command: [19:12:28 CET] <pano> ffmpeg -i rtsp://{user}:{password}@{ip}:554/onvif1 -c copy -f segment -segment_time 10 "capture-%03d.avi" [19:14:05 CET] <pano> the output is: [19:14:12 CET] <pano> ffmpeg version 3.0.5-0ubuntu0.16.10.1 Copyright (c) 2000-2016 the FFmpeg developers [19:14:12 CET] <pano> built with gcc 6.2.0 (Ubuntu 6.2.0-5ubuntu12) 20161005 [19:14:12 CET] <pano> configuration: --prefix=/usr --extra-version=0ubuntu0.16.10.1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --cc=cc --cxx=g++ --enable-gpl --enable-shared --disable-stripping --disable-decoder=libopenjpeg --disable-decoder=libschroedinger --enable-avresample --enable-avisynth --enable-gnutls --enable-ladspa --enable-libass --enable-libbluray --enable-libbs2b --enable-l [19:14:14 CET] <pano> ibcaca --enable-libcdio --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libmodplug --enable-libmp3lame --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-librubberband --enable-librtmp --enable-libschroedinger --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwol [19:14:16 CET] <pano> ame --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxvid --enable-libzvbi --enable-openal --enable-opengl --enable-x11grab --enable-libdc1394 --enable-libiec61883 --enable-libzmq --enable-frei0r --enable-chromaprint --enable-libx264 [19:14:18 CET] <pano> libavutil 55. 17.103 / 55. 17.103 [19:14:20 CET] <pano> libavcodec 57. 24.102 / 57. 24.102 [19:14:22 CET] <pano> libavformat 57. 25.100 / 57. 25.100 [19:14:24 CET] <pano> libavdevice 57. 0.101 / 57. 0.101 [19:14:26 CET] <pano> libavfilter 6. 31.100 / 6. 31.100 [19:14:28 CET] <pano> libavresample 3. 0. 0 / 3. 0. 0 [19:14:30 CET] <pano> libswscale 4. 0.100 / 4. 0.100 [19:14:32 CET] <pano> libswresample 2. 0.101 / 2. 0.101 [19:14:34 CET] <pano> libpostproc 54. 0.100 / 54. 0.100 [19:14:36 CET] <pano> [h264 @ 0x55da7a0a6a60] concealing 2650 DC, 2650 AC, 2650 MV errors in P frame [19:14:38 CET] <pano> [h264 @ 0x55da7a0a6a60] Increasing reorder buffer to 1 [19:14:40 CET] <pano> [h264 @ 0x55da7a0a6a60] out of range intra chroma pred mode at 53 9 [19:14:42 CET] <pano> [h264 @ 0x55da7a0a6a60] error while decoding MB 53 9 [19:14:44 CET] <pano> [h264 @ 0x55da7a0a6a60] concealing 2876 DC, 2876 AC, 2876 MV errors in P frame [19:14:46 CET] <pano> [h264 @ 0x55da7a0a6a60] mb_type 39 in P slice too large at 62 0 [19:14:48 CET] <pano> [h264 @ 0x55da7a0a6a60] error while decoding MB 62 0 [19:14:50 CET] <pano> [h264 @ 0x55da7a0a6a60] concealing 3587 DC, 3587 AC, 3587 MV errors in P frame [19:14:52 CET] <pano> [h264 @ 0x55da7a0a6a60] cbp too large (58) at 19 1 [19:14:54 CET] <pano> [h264 @ 0x55da7a0a6a60] error while decoding MB 19 1 [19:14:56 CET] <pano> [h264 @ 0x55da7a0a6a60] concealing 3550 DC, 3550 AC, 3550 MV errors in P frame [19:14:58 CET] <pano> [h264 @ 0x55da7a0a6a60] Reinit context to 640x368, pix_fmt: yuv420p [19:15:00 CET] <pano> Guessed Channel Layout for Input Stream #0.1 : mono [19:15:01 CET] <JeffATL> pano: ffs [19:15:02 CET] <pano> Input #0, rtsp, from 'rtsp://{user}:{password}@{ip}:554/onvif1': [19:15:04 CET] <pano> Metadata: [19:15:06 CET] <pano> title : H.264 Video, RtspServer_0.0.0.2 [19:15:08 CET] <pano> Duration: N/A, start: 0.000000, bitrate: N/A [19:15:09 CET] <JeffATL> don't do this [19:15:10 CET] <pano> Stream #0:0: Video: h264 (Baseline), yuv420p, 640x360, 19.92 tbr, 90k tbn, 180k tbc [19:15:12 CET] <pano> Stream #0:1: Audio: pcm_alaw, 8000 Hz, 1 channels, s16, 64 kb/s [19:15:12 CET] <JeffATL> pastebin this [19:15:14 CET] <pano> Output #0, segment, to 'capture-%03d.avi': [19:15:16 CET] <pano> Metadata: [19:15:18 CET] <pano> title : H.264 Video, RtspServer_0.0.0.2 [19:15:20 CET] <pano> encoder : Lavf57.25.100 [19:15:22 CET] <pano> Stream #0:0: Video: h264, yuv420p, 640x360, q=2-31, 19.92 tbr, 600 tbn, 90k tbc [19:15:24 CET] <pano> Stream #0:1: Audio: pcm_alaw, 8000 Hz, mono, 64 kb/s [19:15:24 CET] <JeffATL> must...ignore...you... [19:15:26 CET] <pano> Stream mapping: [19:15:28 CET] <pano> Stream #0:0 -> #0:0 (copy) [19:15:30 CET] <pano> Stream #0:1 -> #0:1 (copy) [19:15:32 CET] <pano> Press [q] to stop, [?] for help [19:15:34 CET] <pano> frame= 646 fps= 10 q=-1.0 Lsize=N/A time=00:01:05.19 bitrate=N/A speed=1.05x [19:15:36 CET] <pano> video:931kB audio:509kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown [19:15:40 CET] <pano> as a result i get number of files like [19:15:44 CET] <pano> oh, sorry [19:15:46 CET] <pano> :) as you wish [19:18:11 CET] <DHE> need a bot to auto-kick people or something... :/ [19:24:04 CET] <pano> so as i said above, as a result i get number of files with video inside. But there is an issue which i cannot overcome. files capture-001.avi and next (capture-002.avi, capture-003.avi ... etc) has some empty space in front of video ( capture-001.avi has 10 sec of empty, capture-002.avi has 20 sec and so far). [19:24:53 CET] <pano> the question is: how should i change command to remove this empty space from capture? [19:28:15 CET] <JeffATL> kerio: actually i would be just fine with keeping the encoding just as the input was encoded - i would just rather store the tape rips with the frame edge artifacts already masked out [19:28:39 CET] <pano> http://pastebin.com/iWDXCc8Z [19:29:33 CET] <pano> this is output :). I DO SORRY for posting this as message [19:32:57 CET] <JeffATL> kerio: and also, i need to encode a and v in a way that is going to be pretty universal from now onward [19:35:07 CET] <kerio> vp8/opus maybe [19:58:11 CET] <aarwine> I"m working on creating a timelapse of some pictures of have with this command: cat *.jpg | ffmpeg -f image2pipe -r 15 -vcodec mjpeg -s 1280x720 -i - -vcodec libx264 timelapse.mp4 - The issue is that the resulting file appears to be at a huge resolution: 3280x2464 [20:02:23 CET] <aarwine> ah, it had something to do with the ordering of the flags [20:02:59 CET] <AndrewUnmuted> I am encoding 4k ProRes HQ 4:2:2 sources for playback in VR headsets via libx264. The sources are equirectangular spherical projections. Sometimes the x264 output exhibits a good deal of temporal noise, especially on bright textures and backgrounds. What filter(s) can I invoke in FFmpeg to help reduce these artifacts? [20:17:54 CET] <llogan> aarwine: you can use the glob pattern and get rid of the cat. ffmpeg -framerate 15 -pattern_type glob -i "*.jpg" -vf "scale=1280:-2,format=yuv420p" output.mp4 [20:28:37 CET] <adayzdone> Hi All [20:28:40 CET] <adayzdone> Does anyone know how to output multiple files at once using the same encoding with ffmpeg? [20:28:48 CET] <adayzdone> usr/local/bin/ffmpeg -y -i '/Users/me/input.MP4' -s hd480 -c:v libx264 -crf 23 -c:a aac -strict -2 '/Users/me/output.MP4' [20:28:56 CET] <adayzdone> I want to also export to '/Users/me/output2.MP4' [20:29:04 CET] <adayzdone> I didn't understand this page: https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs [20:29:32 CET] <llogan> is each output supposed to be different (width x height, etc)? [20:29:52 CET] <llogan> or the same? [20:29:54 CET] <adayzdone> llogan No... same exact output in two different locations [20:30:06 CET] <llogan> then you should use the tee muxer [20:30:37 CET] <adayzdone> I read about it, I didn't understand how to use the command [20:30:49 CET] <adayzdone> All of the examples were streams [20:31:20 CET] <adayzdone> llogan using the command above, what would be the sytax for tee? [20:32:39 CET] <llogan> ffmpeg -i input -map 0 -f tee -vf scale=-2:480 -c:v libx264 -crf 23 -c:a aac "output1.mp4|output2.mp4" [20:33:06 CET] <llogan> you don't need "-strict -2" unless your ffmpeg is old, which you shouldn't use [20:33:48 CET] <adayzdone> llogan Thank you. I got that online. Is there a better default command to encode a local file to 480? [20:33:58 CET] <llogan> i just gave it to you [20:34:11 CET] <adayzdone> llogan Thanks again [20:34:32 CET] <llogan> you can adjust -crf and -preset to your needs [20:34:43 CET] <llogan> https://trac.ffmpeg.org/wiki/Encode/H.264 [20:39:08 CET] <adayzdone> Strange... it output to files with a black screen and audio [20:39:12 CET] <adayzdone> two* [20:39:22 CET] <adayzdone> The first command did not [20:49:28 CET] <adayzdone> llogan http://pastebin.com/gLzh6DQG [20:53:17 CET] <adayzdone> Does that help? [20:57:47 CET] <llogan> adayzdone: use -vf "scale=-2:480,format=yuv420p" [21:03:55 CET] <adayzdone> llogan no luck [21:03:59 CET] <adayzdone> http://pastebin.com/D3itSGhH [21:04:09 CET] <adayzdone> black video, has audio [21:08:53 CET] <adayzdone> llogan even when I use the original command and add tee to it, both files have no video [21:09:02 CET] <adayzdone> ffmpeg -i '/Users/me/input.MP4' -s hd480 -c:v libx264 -crf 23 -c:a aac -strict -2 -map 0 -f tee "/Users/me/test.MP4'|'/Users/me/test2.MP4'" [21:12:12 CET] <llogan> you're ignoring my suggestions [21:12:46 CET] <adayzdone> how so? [21:15:59 CET] <adayzdone> llogan Which suggestion did I ignore? [21:30:58 CET] <llogan> i got mapping wrong. if he comes back tell him to do: ffmpeg -i input -filter_complex "[0:v]scale=-2:480,format=yuv420p[v]" -map "[v]" -map 0:a -c:v libx264 -c:a aac -f tee "output1.mp4|output2.mp4" [23:00:35 CET] <Dududu> hi [23:00:56 CET] <Dududu> is there a google app script library for ffmpeg [23:15:20 CET] <leibnizzle> Hey guys, I just discovered ffmpeg and it looks like a really cool project [23:15:58 CET] <leibnizzle> Would be fun to get in and contribute [23:17:32 CET] <leibnizzle> I'm curious though, does ffmpeg lay off everything re: the transmission? [23:17:49 CET] <leibnizzle> forward error correction and so forth [23:24:44 CET] <Mavrik> not sure I follow your question [23:26:52 CET] <leibnizzle> I'd like to build a full stack that includes video compression, channel coding, transmission protocol, channel decoding and decompression [23:27:28 CET] <leibnizzle> Do I understand it correctly that ffmpeg does not concern itself with channel coding? [23:39:34 CET] <klaxa> not sure that is needed in times of tcp? [23:39:41 CET] <klaxa> or i don't understand the question either [23:42:46 CET] <leibnizzle> I'm interested in realtime streaming [23:43:18 CET] <leibnizzle> with v low latency [23:44:27 CET] <klaxa> maybe this can serve as a starting point: https://trac.ffmpeg.org/wiki/StreamingGuide [23:46:49 CET] <leibnizzle> yeah that's really neat but it kind of ducks the question [23:47:37 CET] <leibnizzle> Or answers it indirectly, I guess [23:47:56 CET] <leibnizzle> Seems there is no support for forward error correction [23:48:56 CET] <klaxa> as far as i can tell, forward error correction is for data transmission, this is abstracted by the protocols implemented [23:49:15 CET] <leibnizzle> abstracted in the case of tcp, ignored in the case of udp [23:49:52 CET] <leibnizzle> But that's essentially what I was wondering [23:50:00 CET] <leibnizzle> It's an entirely reasonable design choice obviously :) [23:51:48 CET] <klaxa> you should be able to write your own server and client with some sort of error correction in the application logic and integrate ffmpeg or video streams or data streams in general into that [23:52:07 CET] <klaxa> but i'm not sure if creating yet another protocol will magically make everything great [23:52:52 CET] <leibnizzle> It would be on top of UDP [23:53:11 CET] <klaxa> yes, with tcp there is no reason to do that :) [23:53:24 CET] <klaxa> rtsp and rtp already use udp afaik [23:53:42 CET] <klaxa> rtmp is tcp [23:53:50 CET] <leibnizzle> I don't think it would be of much use in the "common" applications [23:54:09 CET] <leibnizzle> Where the packets are large and the latency is kind of whatever [23:54:22 CET] <leibnizzle> That is true [23:54:46 CET] <klaxa> maybe you can take a look at µTP used in bittorrent [23:54:48 CET] <klaxa> https://en.wikipedia.org/wiki/Micro_Transport_Protocol [23:55:46 CET] <leibnizzle> I was thinking UDP Lite actually [23:56:17 CET] <leibnizzle> Doesn't seem supported either, but that is prob easy to do [23:57:10 CET] <klaxa> ah that seems useful too [23:59:00 CET] <klaxa> if you can get a hold of a network engineer of one of these cloud gaming services, i bet they can give even better advice [23:59:21 CET] <furq> webrtc is probably worth looking at [23:59:39 CET] <leibnizzle> oh right, that's googles thing right? [00:00:00 CET] --- Thu Dec 29 2016

1 0

ffmpeg-devel.log.20161227
by burek 28 Dec '16

28 Dec '16

[00:27:19 CET] <kierank> durandal_1707: ping [00:52:35 CET] <kierank> boooom [01:26:16 CET] <cone-054> ffmpeg 03Marton Balint 07master:89a1471a72cb: avdevice/decklink_dec: properly initialize no_video variable [01:26:16 CET] <cone-054> ffmpeg 03Marton Balint 07master:a7946c896469: avdevice/decklink_enc: do not reference this after freeing it [02:41:31 CET] <kierank> michaelni: what does this mean [02:41:32 CET] <kierank> int b8_stride; ///< 2*mb_width+1 used for some 8x8 block arrays to allow simple addressing [02:42:19 CET] <kierank> I'm trying to figure out where to put my dc predictor value but the addressing is very confusing [02:48:39 CET] <cone-054> ffmpeg 03Michael Niedermayer 07master:b347ca93412f: avformat/matroskadec: Fix OOM on long streams [02:50:09 CET] <michaelni> some of the strides are choosen so that theres a border of blocks outside the image [02:58:52 CET] <kierank> michaelni: how should I address s->dc_val[a][b] then? [02:59:09 CET] <kierank> the prediction is simple, I just need a place to store the data [03:01:51 CET] <kierank> actually maybe i'll just put it in my own place [03:01:56 CET] <kierank> and then later on merge it if necessary [03:12:36 CET] <cone-054> ffmpeg 03Jesper Ek 07master:c7c0046efc3a: Fix bug when incrementing initial_prog_date_time when removing segments [03:25:52 CET] <michaelni> dc_val[1] and [2] will probably need bigger strides for 422/444 [03:31:58 CET] <kierank> I just need one value per component, dc_val seems excessive for what I need actuall [03:32:02 CET] <kierank> I just made a new variable for now [03:42:02 CET] <cone-054> ffmpeg 03Bodecs Bela 07master:0ff8c6b6d524: avformat/hlsenc: strftime identifiers and segment index in filenames [04:00:29 CET] <kierank> crap my dc coefficient is wrong [05:35:34 CET] <kierank> michaelni: yeah i need 32-bit coefficients [05:35:44 CET] <kierank> see A.1.1 [05:36:08 CET] <kierank> In case of mpeg2_stream = 0, The coefficients are [05:36:08 CET] <kierank> represented in (n+7) bits including three fractional bits. [06:13:38 CET] <durandal_170> kierank: you need to ping me multiple times to wake me up [06:13:53 CET] <kierank> I solved that problem [06:13:59 CET] <kierank> now i have much bigger problem [06:28:40 CET] <durandal_170> kierank: when you sleep? [06:30:39 CET] <kierank> I was sleeping now until you woke me up =p [09:10:02 CET] <torroid> Hi! I would like to contribute.. Please could I get a starting point [09:10:42 CET] <JEEB> just start with compiling, then poking around and finding your niche :P not sure if there's a clear-cut list of things doable by a newcomer. most people work either on what they like or what they need for their $dayjob [09:13:02 CET] <atomnuker> whoa, its a huge mjpegenc patch! [09:15:22 CET] <rcombs> JEEB: or both! [09:16:09 CET] <rcombs> atomnuker: wow, wonder what for [09:17:15 CET] <JEEB> rcombs: that'd be nice :D [09:17:22 CET] <JEEB> and to be honest, for a while I did that [09:17:26 CET] <rcombs> also, at a quick glance, it looks& not awful? [09:17:38 CET] <atomnuker> rcombs: the ethernal strife of encoding: quality improvements [09:18:02 CET] <rcombs> atomnuker: yeah, I see, I'm wondering why the hell anyone would put significant effort into making MJPEG better [09:30:06 CET] <atomnuker> I'd put effort into making the vorbis encoder better if vorbis was to be the standard for web audio for the next 20 years or so [09:30:41 CET] <atomnuker> (I should do it anyway, vorbis has huge huge window sizes which makes it interesting) [09:51:25 CET] <rcombs> atomnuker: I sure hope MJPEG isn't going to be the standard for web video for the next 20 years or so [09:51:50 CET] <rcombs> though it might remain the standard for DCPs until the end of time [09:53:30 CET] <atomnuker> it isn't the standard for web video, ip cams don't really classify as maistream web video [09:54:00 CET] <atomnuker> MJPEG = JPEG to me [10:03:28 CET] <j-b> 'morning [11:20:39 CET] <ubitux> http://www.ipol.im/pub/art/2016/130/ [14:16:18 CET] <Compn> hmm [14:16:23 CET] <Compn> looking at encoders.texi [14:16:39 CET] <Compn> are there more encoders with options that are not documented ? [14:16:48 CET] <Compn> i see mjpeg isnt listed [14:17:05 CET] <Compn> amongst others. feels like a bunch are not documented :\ [14:53:15 CET] <RiCON> i'd have no idea ffflacenc supported 0-12 compression_level unless i read the code [15:22:24 CET] <raphael29_> hi [15:22:30 CET] <raphael29_> I am a 3rd year CS student looking for participating in GSoC 2017. While browsing through the 2016 GSoC list, I found this project which caught my attention. Can someone give me some more details about it? [15:23:31 CET] <Compn> sure [15:23:39 CET] <Compn> what details are you looking for raphael29_ ? [15:23:58 CET] <Compn> ffmpeg is a multimedia toolkit for processing audio and video related media [15:24:17 CET] <Compn> currently ffmpeg is installed on more than a billion computers, smart tvs, cell phones etc [15:24:37 CET] <Compn> mostly written in C with a lot of assembly in nasm/yasm format [15:25:17 CET] <Compn> we have participated in GSoC in multiple years with success and failures [15:25:48 CET] <raphael29_> Compn: it sounds cool. Do you intend to participate this year too? [15:26:09 CET] <Compn> skills useful for the project include reverse engineering, reading specifications, C/C++ and asm writing... [15:26:22 CET] <Compn> i am not a student :) [15:26:49 CET] <raphael29_> Compn: you ==FFMPEG project :D [15:27:16 CET] <iive> Compn is our PR person :D [15:27:25 CET] <Compn> i just here to answer questions on irc [15:29:05 CET] <kierank> 8:51 AM <rcombs> though it might remain the standard for DCPs until the end of time [15:29:08 CET] <kierank> nop that's jpeg2k [15:29:40 CET] <raphael29_> Compn: ok, so I meant "Do FFMPEG project intend to participate in GSoC 2017"? [15:30:12 CET] <Compn> possibly ffmpeg will be in gsoc 2017, it depends if we come up with tasks and have mentors and google accepts us [15:30:40 CET] <Compn> since we have been in a lot of past gsoc, they might pick other projects instead to sponsor [15:30:56 CET] <Compn> we will probably try again in 2017 [15:31:21 CET] <Compn> raphael29_ : if you work on ffmpeg now, it will increase your chances of getting picked for student spot :) [15:34:16 CET] <raphael29_> Compn: it sounds great. I will start digging in and come back if I have any questions :) [15:35:23 CET] <Compn> ok, please do. [15:35:38 CET] <Compn> although, before you ask, we dont really have any specific things to work on for new contributors [15:36:04 CET] <Compn> so try reviewing code or patches or bug reports... maybe just figure out git and patches and read the developer documentation [15:36:16 CET] <kierank> michaelni: ping [15:36:24 CET] <Compn> have you worked with open source before? [15:36:28 CET] <Compn> lots to learn :) [15:36:49 CET] Action: Compn afk bbl [15:40:49 CET] <michaelni> kierank, pong [15:41:00 CET] <kierank> 4:35 AM <"kierank> michaelni: yeah i need 32-bit coefficients [15:41:00 CET] <kierank> 4:35 AM <"kierank> see A.1.1 [15:41:00 CET] <kierank> 4:36 AM <"kierank> In case of mpeg2_stream = 0, The coefficients are [15:41:00 CET] <kierank> 4:36 AM <"kierank> represented in (n+7) bits including three fractional bits. [15:41:09 CET] <kierank> michaelni: any advice on how to add 10-bit to mpegvideo.c [15:41:14 CET] <kierank> 32-bit coefficients [15:41:15 CET] <kierank> i mean [15:41:55 CET] <kierank> I have coefficient decoding working now and need to add dequant which is reasonably simple [15:44:12 CET] <michaelni> the functions need to pass 32bit coeffs then. i assume decode, dequant (if seperate) and idct all need to be different so i guess they wont get mixed with the 16bit variants [15:45:46 CET] <kierank> it's just idct that matters [15:45:57 CET] <kierank> can't I keep the same function pointers and then just cast to int32_t? [15:46:03 CET] <kierank> for the block data [15:46:23 CET] <kierank> and expand the array of existing int16_t? [15:47:27 CET] <michaelni> yes that seems simplest [15:47:51 CET] <kierank> that's what h264 does at least [15:48:12 CET] <kierank> I guess I need to ask BBB which DCT is the best to use [15:48:18 CET] <kierank> hopefully I don't need to write my own [15:48:20 CET] <BBB> ? [15:48:25 CET] <BBB> whats the problem? [15:48:35 CET] <kierank> I'm adding 10-bit support to mpegvideo.c [15:48:41 CET] <kierank> to decode 10/12-bit mpeg-4 video files [15:49:08 CET] <BBB> just do what we did for h264, add a template for the mpegvideo dsp and change the types of idct from int16_t to dctcoef and uint8_t to pixel [15:49:20 CET] <kierank> yeah, that's fine, I don't know which DCT is best to use. prores? [15:49:29 CET] <kierank> IDCT* [15:49:46 CET] <BBB> depends on the idct defined or expected in the bitstream [15:49:53 CET] <BBB> I thought mpegvideo uses simple_idct? [15:50:04 CET] <BBB> so prores could probably work yes [15:50:28 CET] <BBB> theres something funky in the prores idct I dont recall exactly what it is [15:50:32 CET] <michaelni> IIUC the new profile uses the withdrawn IEEE nn bitexact idct [15:50:47 CET] <michaelni> nOn bitexact [15:51:07 CET] <BBB> dont all mpegs use non-bitexact idct? [15:51:12 CET] <BBB> (pre-h264) [15:51:14 CET] <michaelni> yes [15:51:22 CET] <BBB> so no surprise there I suppose [15:51:45 CET] <kierank> The N by N inverse discrete transform shall conform to IEEE Standard Specification for the Implementations of 8 by [15:51:46 CET] <kierank> 8 Inverse Discrete Cosine Transform, Std 1180-1990, December 6, 1990. [15:52:01 CET] <BBB> raphael29_: yes were likely participating in the gsoc 2017 [15:52:22 CET] <BBB> raphael29_: well have some standard projects, but if you want to do a project of your own, thats fine also, just find your own mentor [15:52:30 CET] <kierank> maybe I should write my own idct as an exercise [15:52:40 CET] <BBB> its a fun exercise [15:52:52 CET] <BBB> but its probably faster to use the existing one and template it for 10bit [15:53:05 CET] <BBB> the prores idct should work okish and already has simd [15:53:13 CET] <BBB> merging code like that is always good [15:57:13 CET] <kierank> BBB: thanks I will try with the existing idct and see if I get pictures first [16:01:37 CET] <BBB> very well [16:03:42 CET] <BBB> Gramner: do you have push access? [16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:1c8fbd7b9046: checkasm/vp9: benchmark all sub-IDCTs (but not WHT or ADST). [16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:992cb15e6713: wmavoice: move wmavoice_flush() up. [16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:3deb4b54a24f: wmavoice: disable bitstream checking. [16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:b011bb5f8b2c: wmavoice: reindent. [16:04:06 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:7b27dd5c16de: wmavoice: move overflow handling to common code. [16:04:07 CET] <cone-931> ffmpeg 03Ronald S. Bultje 07master:33d7f822f8ed: wmavoice: protect against zero-energy in adaptive gain control. [16:04:35 CET] <iive> you'll get picture, but there might be effects like green tilt [16:04:59 CET] <Gramner> BBB: yes [16:05:23 CET] <BBB> (just checking if youre waiting for one of us to push that x86inc.asm patch) [16:05:51 CET] <Gramner> not like it's in a hurry since it doesn't affect any existing ffmpeg code [16:10:26 CET] <raphael29_> BBB: thanks for your answer. [17:38:02 CET] <kierank> haasn: nice blog post [17:38:49 CET] <durandal_170> BBB: i have frequency of simbols used in qdmc. how can I convert it to vlc? [17:39:54 CET] <BBB> huffman? [17:40:47 CET] <BBB> kierank: link missing [17:41:02 CET] <kierank> BBB: https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-believe-about-%5B… [17:43:10 CET] <BBB> so much stuff there ;) [18:05:15 CET] <durandal_170> BBB: most likely [18:10:43 CET] <durandal_1707> BBB: see qdmc page on wiki.multimedia.cx [18:12:03 CET] <ubitux> haasn: where is the audio now? [18:12:44 CET] <nevcairiel> there is a whole bunch in there one might argue with though =p, ie. a h264 decoder that does impact quality is just flat out broken [18:13:00 CET] <kierank> yes but he's saying don't make the assumption [18:13:35 CET] <JEEB> the H.264 thing was mostly about HW decoding APIs that for RGB output on your and whatsoever [18:13:37 CET] <kierank> there's also "don't assume a hardware encoder is better than a software one" [18:13:41 CET] <JEEB> I herped a derp at him quite a bit [18:13:46 CET] <JEEB> for the original wording of it [18:14:24 CET] <ubitux> "every hardware acceleration can be abstracted with a generic interface" [18:14:34 CET] <ubitux> +common [18:14:43 CET] <nevcairiel> that was fine until apple was being apple [18:14:44 CET] <nevcairiel> :D [18:15:57 CET] <ubitux> "software subtitle rendering can not possibly be the playback speed bottleneck" [18:16:21 CET] <JEEB> :D [18:16:40 CET] <JEEB> "my ASS tracks can't possibly be *this* slow to render!" [18:16:45 CET] <fritsch> hehe [18:16:50 CET] <ubitux> "a subtitle format can not include markup from multiple other formats" [18:17:02 CET] <ubitux> "or at least not in the same file" [18:18:54 CET] <ubitux> "rendering modern subtitles doesn't require a browser engine" [18:18:56 CET] <kierank> can we get rid of mpeg1_fast_decode_block_inter? [18:19:18 CET] <nevcairiel> some people probably like the fast mode for obscure reasons [18:19:24 CET] <kierank> for mpeg1 [18:19:42 CET] <kierank> it also crashes on corrupt stream [18:22:13 CET] <nevcairiel> fast is known to be insecure, thats probably what makes it fast =p [18:26:37 CET] <iive> "since H.264 decoding is bit-exact, the decoder used does not affect the quality", could somebody explain me why this is falsehood? [18:26:52 CET] <JEEB> oh yes, I noted that [18:26:57 CET] <JEEB> he mostly meant HW decoding interfaces [18:27:10 CET] <JEEB> which force a specific YCbCr->RGB conversion on you [18:27:17 CET] <JEEB> before you get the data, that is [18:27:32 CET] <JEEB> I did note it that most people probably won't read it like he'd think :P [18:27:36 CET] <kierank> I am bored of people telling me about quicksync [18:27:39 CET] <cone-931> ffmpeg 03Christophe Gisquet 07master:e3312b3746ef: MAINTAINERS: update [18:28:01 CET] <Gramner> even so, color space conversion isn't really a part of the actual decoder though [18:28:07 CET] <JEEB> yes [18:28:26 CET] <iive> :) [18:31:04 CET] <JEEB> iive: basically when I pointed the way we read it he replied with [18:31:05 CET] <JEEB> < haasn> ¬(AB) is not the same as ¬A [18:31:49 CET] <JEEB> and then pointed out that he meant those specific HW decoding APIs which don't necessarily give you the YCbCr surfaces [18:33:29 CET] <atomnuker> some actually give you 2 separate fields instead of 3 solid planes (hi vdpau) even for progressive content [18:34:05 CET] <kierank> looool [18:34:13 CET] <iive> nv12 ? [18:34:16 CET] <kierank> atomnuker: you must have loved that :) [18:34:17 CET] <iive> hm12? [18:34:25 CET] <Gramner> if a decoding API does additional stuff in addition to decoding then it's a bit of a misnomer to call it a decoding API. "video processing API" or whatever would be more accurate [18:35:46 CET] <atomnuker> kierank: not me, wm4 since he had to deal with it :) [18:41:44 CET] <iive> JEEB: i do not accept his explanation, because he have a whole separate section for color conversions... [18:42:52 CET] <iive> or you can say 3 or 4 sections... [18:43:03 CET] <JEEB> yeah but you can clearly see it being on top of the "HW decoders are faster" and "HW decoders can decode everything you can feed 'em" [18:43:28 CET] <JEEB> but yeah, I don't like the wording but at this point I've given up because I can't come up with anything that's jazzy enough for him :P [18:43:35 CET] <iive> well, this only makes it more confusing [18:43:56 CET] <JEEB> and/or in his opinion I'm just reading it wrong :D [18:44:04 CET] <iive> because he clearly states hardware decoders, when he talks about hardware decoders. [18:44:13 CET] <nevcairiel> it kinda makes sense, if some decoder cant give you access to the unmodified image, then its clearly worse then other decoders [18:44:31 CET] <nevcairiel> and its certainly possible someone might build a software decoder with similar sillyness [18:45:56 CET] <JEEB> sure, the point itself is valid, I think it's just worded in a way that makes it seem as if H.264 isn't spec-wise bitexact [18:46:01 CET] <kierank> nevcairiel: it's not silly [18:46:24 CET] <kierank> being able to do some kind of transform when the data is in cache is a good idea [18:46:43 CET] <nevcairiel> "being able to" is quite some ways from "not being able to not do that" [18:46:46 CET] <Alex2001> Hi guys [18:47:04 CET] <kierank> meh, closed source, deal with it [18:47:05 CET] <nevcairiel> if its the only mode it knows, someone build sillyness [18:47:13 CET] <nevcairiel> if its optional, great, features! [18:48:20 CET] <nevcairiel> (and somehow i dont think video images are particularly nice on caches in general) [18:48:25 CET] <Alex2001> Could anyone here take a minute and help me out a little bit on a project? I'm having difficulties in getting the end time for DVB subtitles... [18:49:12 CET] <iive> Alex2001: I might remember wrongly, but you render empty subtitle to hide them [18:49:20 CET] <iive> or you use the timeout [18:49:46 CET] <j-b> is Christophe Gisquet around? [18:49:51 CET] <Alex2001> Well, I'm currently working on a subtitle extraction program [18:50:04 CET] <Alex2001> and I was wondering if it's actually possible to get the end time for a subtitle [18:50:06 CET] <nevcairiel> j-b: he doesnt often come to irc [18:50:10 CET] <kierank> atomnuker: if i recall correctly it is undefined [18:50:16 CET] <kierank> Alex2001: i mean [18:50:23 CET] <j-b> nevcairiel: yeah, I thought that too. but I wanted to check. [18:50:33 CET] <Alex2001> as far as I can see I am only provided with a PTS for each subtitle [18:50:35 CET] <nevcairiel> he goes by the name kuroso i think [18:51:36 CET] <j-b> nevcairiel: thx [18:52:43 CET] <nevcairiel> Alex2001: as far as i can see, there is no end time for dvb subtitles, and instead you get a "empty" subtitle that clears the screen when necessary, as iive said [18:52:59 CET] <Alex2001> the problem seems to be that after a bitmap says "display" we write it to file and that's not the way to do it [18:53:04 CET] <Alex2001> Oh, empty subtitle? [18:54:16 CET] <jamrial> j-b, nevcairiel: it's kurosu [18:54:23 CET] <nevcairiel> well, close! [18:54:27 CET] <j-b> jamrial: thx man. [18:55:12 CET] <jamrial> nevcairiel: you can't start a query if you don't have it right :P [18:55:34 CET] <nevcairiel> you cant start a query either way if he isnt there :D [19:06:22 CET] <durandal_1707> michaelni: do you have an idea how to get vlc tables from frequencies? [19:07:14 CET] <kierank> durandal_1707: I would guess you make the most probable frequency have the shortest code [19:09:16 CET] <durandal_1707> higher number bigger probability or vice versa? [19:10:51 CET] <kierank> dunno [19:12:44 CET] <atomnuker> durandal_1707: highest probabilities -> shorter symbols makes sense [19:13:16 CET] <atomnuker> question is: is 10 shorter than 11? [19:13:47 CET] <durandal_1707> and how I could convert those to codes and lengths? manually? [19:14:09 CET] <durandal_1707> smaller tables have 8 elements [19:14:36 CET] <kierank> perhaps using rice codes or similar [19:15:28 CET] Action: kierank curses mpeg specs [19:15:28 CET] <kierank> ( QF[v][u] * W[0][v][u] * quantiser_scale * base_quantiser scale * 8 * 2 ) / 32; [19:17:41 CET] <atomnuker> oh hey it's the vp9 school of dequantization [19:19:34 CET] <kierank> same as mpeg-2 [19:19:53 CET] <kierank> actually a bit different [19:24:21 CET] <wm4> <atomnuker> some actually give you 2 separate fields instead of 3 solid planes (hi vdpau) even for progressive content <- even better, vdpau doesn't for hevc, which makes no sense, i.e. nvidia left it buggy for ages and just doesn't give a shit anymore [19:25:06 CET] <michaelni> durandal_1707, i think the stuff in libavcodec/huffman.h did one variant of that [19:26:49 CET] <durandal_1707> michaelni: already tried that one [20:05:29 CET] <durandal_1707> michaelni: have any idea? [20:49:12 CET] <kierank> durandal_1707: I am stuck like you now :( [20:50:19 CET] <durandal_1707> kierank: i think I got it just need to test idea [20:50:39 CET] <kierank> I can't get VLCs to work on some MBs [20:50:40 CET] <kierank> :( [21:07:39 CET] <Alex2001> Could someone please tell me if the save_subtitle_set() call is necessary in the parse_page_segment() function? I'm having trouble getting the end time of DVB subtitles for a subtitle extractor program and I think it's because I don't call that function [21:10:49 CET] <Alex2001> The part of the program used for DVB extraction is based a lot on the ffmpeg source (it's almost copy paste), specifically the decoding of the segments part [21:11:26 CET] <Alex2001> And I believe my program might have this problem because I don't call save_subtitle_set [21:16:24 CET] <kierank> michaelni: what does it mean when get_vlc2 returns -1? [21:28:45 CET] <iive> invalid code? [21:33:12 CET] <durandal_1707> kierank: i can't get little endian vlc generation [21:34:58 CET] <michaelni> kierank, as iive said, invalid code aka not a valid code [21:35:32 CET] <kierank> :( [21:50:50 CET] <haasn> iive: I pretty much meant what I meant: even though H.264 decoders should all produce the result, you can't use all hardware decoders without quality loss *in practice* [21:50:58 CET] <haasn> because the APIs are shit and won't give you the actual result [21:51:02 CET] <haasn> but rather some postprocessed version [21:51:18 CET] <iive> haasn: quality loss where? [21:51:33 CET] <haasn> even if you can get the YCbCr planes, for example, some APIs will dither 10 bit content to 8 bit textures [21:51:38 CET] <haasn> or pull 4:2:0 up to 4:2:2 (yes) [21:51:45 CET] <iive> well, then you can say that... [21:52:37 CET] <iive> the point is, the decoder as specified by the standard will decode to the correct image [21:52:43 CET] <haasn> also lol I'm surprised that that's the only statement that basically every decoder person is taking extreme offense to :p [21:53:23 CET] <haasn> my statement doesn't contradict that [21:53:27 CET] <haasn> in fact it uses that as an assumption [21:53:30 CET] <iive> yes it does [21:53:43 CET] <iive> it basically says that this is fallacy [21:54:00 CET] <iive> you may want to say something else, but that is what you've written. [21:54:03 CET] <haasn> ¬(AB) is not the same as (A¬B)'¬A [21:54:32 CET] <haasn> I wrote ¬(AB), which is true; and we know A is true; so the only thing I've said here is ¬B [21:54:35 CET] <haasn> which is also definitely true [21:54:47 CET] <haasn> and part of the reason why --hwdec is so strongly discouraged in mpv [21:54:51 CET] <iive> i'm not sure what these things mean [21:55:29 CET] <haasn> A = all decoders produce the same result, B = hwdec = swdec in terms of quality, A is clearly true (nobody's trying to argue against that), B is clearly false (--hwdec loses you quality in most cases) [21:55:31 CET] <haasn> So clearly A can't imply B [21:55:36 CET] <haasn> even though the naive logic would say yes [21:55:42 CET] <iive> and i'm not even sure what is A and B in your case. [21:55:47 CET] <haasn> if all decoders produce the same result, surely it must not matter what decoder I use is a reasonable assumption [21:55:51 CET] <haasn> which is false, because the APIs are shit [21:56:02 CET] <haasn> and that's my point [21:56:07 CET] <haasn> sorry you're reading too much into it [21:56:10 CET] <kierank> https://www.reddit.com/r/programming/comments/5kkmww/falsehoods_programmers… [21:56:13 CET] <kierank> reddit is lulz [21:56:27 CET] <iive> haasn: i think the problem here is what do you consider a decoder [21:56:49 CET] <haasn> iive: the API is part of the decoder, for me [21:56:57 CET] <haasn> I mean all the algorithms in the world won't help me if I can't actually use them to decode stuff [21:57:18 CET] <iive> haasn: but you are not talking about API, you are talking about decoder [21:57:37 CET] <iive> so you say A is false [21:59:18 CET] <iive> "since H.264 decoding is bit-exact, you will be able to get the bit-exact image from it" [21:59:32 CET] <haasn> I'll add a footnote, I guess, since I'm getting so many people who misunderstand what I wrote [22:03:41 CET] <JEEB> haasn: I wonder if it's a linguistic structure that Germans are used to because nevcairiel seemed to parse it similarly to you [22:03:54 CET] <JEEB> that, or I just fail at English :P [22:04:47 CET] <iive> I actually would like to ask why this is falsehood, too: "rendering subtitles at the output resolution is always better than rendering them at the video resolution" [22:06:51 CET] <JEEB> iive: with only text that might work, but depending on your artisticity the end result might be incorrect if you scale things differently in the subtitle renderer compared to the video renderer [22:07:48 CET] <iive> doesn't render kind of hint about text subtitles? [22:07:59 CET] <JEEB> it can be vectors etc [22:08:16 CET] <JEEB> and you're correct, it could even be so with text if it's stylized enough [22:08:16 CET] <iive> fonts are vectors :D [22:08:29 CET] <iive> well, mostly [22:08:31 CET] <JEEB> well yes, but I mean the crazy shit you get with ASS, for example [22:08:37 CET] <JEEB> and yes, bitmaps in fonts are a thing as well [22:08:42 CET] <JEEB> (mostly for small sizes) [22:09:17 CET] <iive> "theres an ASS specification" that has a point :D [22:09:23 CET] <haasn> iive: https://haasn.xyz/posts/2016-12-25-falsehoods-programmers-believe-about-%5B… how's this? [22:10:09 CET] <haasn> iive: somebody else asked about that comment, and I clarified a few points here: https://news.ycombinator.com/item?id=13260826 [22:10:38 CET] <haasn> That one is probably footnote-worthy as well [22:10:54 CET] <haasn> but I think it's a valid point, especially the part where softsubbed signs can look out of place at the full screen res [22:11:40 CET] <iive> well, this happens for 2 reasons: [22:11:41 CET] <haasn> all of those points only apply to softsubbed signs, I'm sure [22:12:02 CET] <iive> 1. ass specs are never followed, instead vobsub bugs are replicated. [22:12:04 CET] <haasn> hence why I wish we had a distinction between signs and text [22:12:43 CET] <iive> 2. the display resolution is not properly mapped to the video, probably because of #1 [22:13:47 CET] <haasn> when I say out of place I don't mean in the wrong position, I mean they don't feel right / blend in [22:13:57 CET] <haasn> Obviously there are bugs where stuff like transformations are not properly scaled to screen space [22:14:13 CET] <haasn> but I mean if you have a blurry video and a sign on that video is suddenly sharp instead of blurry, it doesn't fit [22:14:19 CET] <iive> oh, you mean, they look better than the video? [22:14:22 CET] <haasn> yeah [22:14:31 CET] <haasn> I've noticed that a few times in practice [22:14:41 CET] <haasn> and it always makes me wish I could distinguish between signs and text in code [22:14:43 CET] Action: iive adds blur image to ass.2.1 [22:14:49 CET] <haasn> because it would be trivial to render signs on top of the video and text on top of the final output [22:15:05 CET] <haasn> that way it would also the best of all worlds [22:15:14 CET] <haasn> signs would get affected by video color management and stuff like motion interpolation [22:15:31 CET] <JEEB> PGS subs for signs and an ASS track for text? :P [22:15:47 CET] <JEEB> PGS is even YCbCr (although libavcodec converts it to RGB) [22:16:00 CET] <JEEB> so you can just literally overlay PGS subs on top of yer YCbCr :D [22:16:19 CET] <JEEB> because the spec just says that the video's colorimetry applies. that's it [22:18:03 CET] <haasn> yeah I would love something like that [22:18:16 CET] <haasn> I would also love it if we had a second transparent H.264 track so we could hardsub all signs but still toggle them :p [22:18:24 CET] <haasn> (and without having to re-encode the video track) [22:18:32 CET] <haasn> of course that's a pipe dream [22:18:38 CET] <haasn> even though the H.264 specs do support it (I think) [22:18:57 CET] <iive> mpeg4 in higher profiles actually supports object and compositions [22:19:18 CET] <nevcairiel> noone ever used that, hence why it went away again [22:19:38 CET] <iive> e.g. you can encode the frame, but without the human face, the face is separate object ... [22:19:53 CET] <JEEB> haasn: so basically you want two tracks and the player to be able to enable multiple at once :P [22:20:14 CET] <iive> yeh, it involves a lot of complications in the decoder and even more in the encoder. [22:21:03 CET] <JEEB> haasn: and if you don't remember, PGS are paletted video resolution based (usually) subpictures [22:21:08 CET] <JEEB> vOv [22:21:19 CET] <ubitux> fun fact: clamping like clip(x, min, max) in a spreadsheet is MEDIAN(min, x, max) [22:22:15 CET] <iive> median sorts by value and takes the middle [22:22:24 CET] <atomnuker> haasn: that's a shit dream, softsubbing signs sucks [22:23:00 CET] <JEEB> didn't he want hardsubs as a subpicture track? [22:23:08 CET] <atomnuker> yeah, and that's mental [22:23:40 CET] <ubitux> iive: yes, which has the same result, so it's cool [22:23:46 CET] <iive> ubitux: :) [22:24:05 CET] <ubitux> it's like a clip function where you can shuffle all the args [23:15:01 CET] <durandal_1707> kierank: i kind of have vlc lens but codes may be incorrect for cases when lens are same [23:16:40 CET] <durandal_1707> what was the name of application that used qt api on Windows it was handy encoder [23:16:41 CET] <kierank> I got problems my with my vlcs as well [23:18:50 CET] <durandal_1707> are tables mentioned in specifications? [23:20:11 CET] <kierank> durandal_1707: in my spec, yes [23:20:17 CET] <kierank> but I can't decode some macroblocks [23:20:57 CET] <durandal_1707> do you get any sensible output? [23:21:19 CET] <kierank> I am just decoding the coefficients at the moment [23:21:38 CET] <kierank> but I hang on some samples after a few hundred macroblocks but on another sample within 2 macroblocks [23:22:46 CET] <durandal_1707> no need to align bits? [23:22:59 CET] <kierank> dunno [23:24:16 CET] <durandal_1707> well I would try to get some output to be sure at least basic stuff works [23:25:07 CET] <kierank> i am a long way from that [23:38:18 CET] <ubitux> http://sprunge.us/FEVL anything faster to suggest? [23:41:50 CET] <nevcairiel> dont we have median3 [23:43:13 CET] <nevcairiel> mid_pred should be median3 [23:44:40 CET] <ubitux> nice! [23:45:00 CET] <ubitux> (should we define av_clip on mid_pred? :-°) [23:46:06 CET] <ubitux> ah unfortunately it's in libavcodec [23:46:15 CET] <ubitux> i wonder if that's ok to include it in libavfilter [23:46:15 CET] <nevcairiel> has arch optimizations though [23:46:30 CET] <ubitux> should be fine as it's an inline though [23:46:38 CET] <nevcairiel> mid_pred has a cmov variant [23:46:43 CET] <iive> ubitux: i'd think that median might be a bit slower [23:49:03 CET] <atomnuker> _clip* needs all the speed it can get, it's very frequently used on entire frames [23:51:58 CET] <cone-608> ffmpeg 03Clément BSsch 07master:571a36015738: lavfi/transpose: add missing const options flags [23:52:30 CET] <jamrial> av_clip* for integers have asm optimization on arm only. x86 has no saturate gprs instructions [23:53:03 CET] <jamrial> they would be a nice addition for a potential future set, though (BMI3?) [23:53:57 CET] <jamrial> one could maybe use packss* but moving from gpr to xmm and back to gpr is probably too slow to make a difference [23:54:54 CET] <nevcairiel> maaybe a cmov thing like median3 could be used? [23:58:18 CET] <cone-608> ffmpeg 03Clément BSsch 07master:afaaf8db1847: lavfi/selectivecolor: simplify crazy mid val computations [23:58:23 CET] <ubitux> ok now i'm happy [00:00:00 CET] --- Wed Dec 28 2016

1 0

ffmpeg.log.20161227
by burek 28 Dec '16

28 Dec '16

[00:38:31 CET] <Modern13> if i use crf=0, is it lossless ? [00:42:51 CET] <furq> with 8-bit x264, es [00:42:52 CET] <furq> yes [00:52:52 CET] <Modern13> with 10bit x264 it's not? [00:53:29 CET] <Modern13> furq with 10bit x264 it's not? [00:54:53 CET] <JEEB> it isn't [00:55:05 CET] <JEEB> because crf values go to negative values with >8 [00:56:16 CET] <CoJaBo> Modern13: -qp 0 [02:13:24 CET] <miketo> can ffmpeg split a file into segments based on chapter metadata? [02:39:54 CET] <Modern13> how come i cannot play some incomplete mp4 files but sometimes i CAN play incomplete mp4 file [02:40:18 CET] <Modern13> note( i can always play incomplete mkv file) [02:43:38 CET] <Modern13> how come i cannot play some incomplete mp4 files but sometimes i CAN play incomplete mp4 file ( i can ALWAYS play incomplete mkv file) [02:56:47 CET] <miketo> Modern13: has to do with how the mp4 format was designed. [02:57:01 CET] <Modern13> explain why sometimes plays sometimes don't [02:57:08 CET] <Modern13> with mkv , it always plays [02:58:14 CET] <miketo> mkv is different from mp4. in mp4 there's important metadata (i think called moov atom) usually at the end of file. it can be put in beginning of file but that requires more work. [02:59:33 CET] <Modern13> miketo and with MKV , it's forced to put atom in the beginning? [02:59:48 CET] <miketo> Modern13: here's an old discussion that might be relevant: http://forum.doom9.org/showthread.php?t=169815 [03:00:25 CET] <Modern13> can you put "atom at the end" with MKV file [03:00:49 CET] <miketo> i don't think moov atom exists in mkv. remember it's different. [03:00:54 CET] <Modern13> i see [03:01:24 CET] <Modern13> if mp4 cannot play incomplete file, how is mp4 even such a popular format: this make no sense [03:02:06 CET] <miketo> according to official sources here: it looks like the seeking/meta info is always in the header (beginning of file) [03:02:09 CET] <miketo> https://matroska.org/technical/diagram/index.html [03:02:38 CET] <Modern13> can you imagine if youtube cannot play unless you download the whole file [03:03:08 CET] <miketo> popular doesn't mean perfect. mp4 weren't designed to be streamed. [03:03:26 CET] <Modern13> what does youtube use then [03:04:32 CET] <miketo> lots of things. the webpage player (or app) can choose different audio/video formats [03:05:12 CET] <miketo> each video on youtube is transcoded into different qualities/formats. that way it can play on different connections(quality) and different devices (format) [03:05:12 CET] <Modern13> youtube can always play incomplete video files though [03:07:15 CET] <Modern13> miketo are you certain that mp4 with atom at the end are way more popular? [03:08:01 CET] <miketo> the #1 trending video on youtube now is available as (12 video streams, 5 audio streams, and 5 combined streams) formats are: webm, mp4, m4a, 3gp [03:09:32 CET] <miketo> no, i'm not certain. but from what i've read, it looks like that was the "older, established, or easiest" way. it can't be moved to beginning until *after* entire file has already been finished once [03:10:16 CET] <Modern13> but it can always play in youtube [03:10:59 CET] <miketo> yes, it would make sense that youtube would be smart enough to move the atom to the front. i'll download a mp4 video file and check if you want [03:11:33 CET] <Modern13> i have about 30 mp4 files, how do i check if atoms are front or end [03:12:15 CET] <miketo> Modern13: see here http://superuser.com/questions/559372/using-ffmpeg-to-locate-moov-atom [03:16:56 CET] <miketo> also, small correction. it looks like youtube doesn't use mp4 container. it uses DASH (a stream-able container) for all of the non-combined streams. i'm downloading an older format mp4 (audio+video) version of the same video now to check [03:18:44 CET] <miketo> yep. the mp4 youtube format does has moov atom at the beginning of file. [03:19:30 CET] <Modern13> ffplay.exe -faststart test.mp4 doesn't work [03:19:52 CET] <miketo> you can use youtube-dl to list the formats (-F) of a video, then download the one you want (-f ##). you can use AtomicParsley -T to list the mp4 atom tree [03:20:09 CET] <Modern13> atomicparsley, is that part of ffmpeg ? [03:20:27 CET] <miketo> don't think so. i came here for a different question. [03:21:36 CET] <miketo> http://atomicparsley.sourceforge.net/ "AtomicParsley is a lightweight command line program for reading, parsing and setting metadata into MPEG-4 files" [03:22:38 CET] <furq> dash isn't a container, it uses fragmented mp4 afaik [03:23:07 CET] <furq> at least on youtube it does [03:25:39 CET] <Modern13> i just did AtomicParsley input.mp4 -T [03:25:49 CET] <Modern13> how do i tell if it's on beginning or end [03:26:03 CET] <Modern13> i cannot tell from all the numbers it shows on display [03:26:09 CET] <furq> also browsers can play an mp4 with the moov atom at the end without downloading the whole thing if the http server supports range requests [03:26:51 CET] <miketo> thanks furq. i wasn't trying to be precise. it does seem to be some sort of container or stream format. MediaInfo shows "Format DASH, Codec ID DASH" even though the data is avc1 [03:27:42 CET] <Modern13> http://pastebin.com/yP9Avb9L is this end or beginning? [03:27:54 CET] <furq> mpeg-dash is a streaming protocol, like hls [03:28:20 CET] <furq> except hls uses mpegts fragments [03:29:15 CET] <miketo> Modern13: second line says mov is at byte 24, and size 931974 (about 910kb) [03:29:49 CET] <Modern13> miketo i see, thanks [03:29:54 CET] <Modern13> so safe to say that's beginning? [03:30:17 CET] <miketo> yes, [03:32:28 CET] <miketo> furq: cool, thanks. [03:35:33 CET] <Modern13> You must be off your block thinking I'm going to tag a file that is at LEAST 4005456973 bytes long. [03:35:33 CET] <Modern13> AtomicParsley doesn't have full 64-bit support [03:36:33 CET] <Modern13> what is this error message [03:37:33 CET] <miketo> furq: looking at hexdump i can see the the string 'ftypedash' after a few nulls at beginning of file. it doesn't seem entirely honest to say it's only a protocol since it persists into on-disk storage. media player don't have a problem with it [03:39:47 CET] <Modern13> how do i use option faststart with ffmpeg ? [03:40:07 CET] <Modern13> or ffplay [03:41:12 CET] <miketo> Modern13: did you check here: https://www.ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv [03:41:38 CET] <miketo> Modern13: what are you trying to accomplish? [03:42:03 CET] <Modern13> i want to see if mp4 is beginning or end by using ffplay [03:42:08 CET] <Modern13> atom* [03:43:10 CET] <Modern13> atomicparsley is too buggy [03:53:46 CET] <miketo> Modern13: try this command to see if the moov atom is in the file: strings <FILE> | grep "moov" [03:54:07 CET] <Modern13> would that work in cmd.exe ? [03:54:47 CET] <miketo> probably not. those are unix utilities, but there are versions available for windows [03:56:05 CET] <Modern13> miketo i think i found a better app [03:56:25 CET] <Modern13> MP4Box from the gpac package can do that. [03:56:26 CET] <Modern13> Code: [03:56:26 CET] <Modern13> MP4Box -info -v file.mp4 [03:56:26 CET] <Modern13> If you only need to check that moov is before mdat, -v (verbose) is not even necessary : MP4Box -info will display "File suitable for progressive download (moov before mdat)". [03:57:05 CET] <miketo> cool, thanks for the info. hope that's what you needed [04:03:48 CET] <Modern13> if i do ffmpeg -i input.mkv -vcodec copy -acodec copy output.mp4 does that create mp4 with moov in the beginning or end [04:04:34 CET] <miketo> there are no moov atoms in mkv files. the atoms are part of how mp4 container works [04:04:51 CET] <Modern13> i know [04:04:59 CET] <Modern13> but look at the question i am asking carefully [04:05:03 CET] <miketo> oh sorry ^^; [04:05:20 CET] <miketo> read backwards. it will (almost certainly!) put it at the end [04:05:56 CET] <miketo> there's a setting to move it to the beginning that defaults to "disabled" [04:05:59 CET] <Modern13> does fmpeg support putting in the beginning ? [04:06:09 CET] <Modern13> oh? how? [04:06:47 CET] <miketo> did you even skim the link i gave about faststart? ( [04:06:47 CET] <miketo> https://www.ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv ) [04:07:59 CET] <miketo> " it can be moved to the start for better playback by adding faststart to the movflags " also scroll down to "-movflags faststart" [04:09:18 CET] <Modern13> ffmpeg -i input.mkv qt-faststart -vcodec copy -acodec copy output.mp4 [04:09:20 CET] <Modern13> is this correct [04:11:12 CET] <miketo> i can't imagine [04:11:45 CET] <miketo> use "-movflags faststart" [04:12:00 CET] <Modern13> oh okay [04:12:47 CET] <Modern13> is there disadvantage of putting in the beginning? [04:12:51 CET] <Modern13> or using -movflags faststart [04:14:06 CET] <Modern13> miketo didn't work: Option movflags not found. [04:14:28 CET] <Modern13> ffmpeg -movflags faststart -i R:\4-1.mkv -vcodec copy -acodec copy R:\output.mp4 [04:14:36 CET] <miketo> from how i understand it: the file itself might be better, but it takes more work to make it. [04:15:40 CET] <miketo> i just tested with "ffmpeg -i input.mkv -c copy -movflags faststart test.mp4" and it worked fine [04:16:07 CET] <miketo> i'd bet it's an output option (has to be before the output file name *NOT* before the "-i" [04:16:14 CET] <Modern13> oh [04:17:46 CET] <Modern13> thanks, it worked [04:18:09 CET] <miketo> np ^^; [04:19:51 CET] <Modern13> i see more mp4 files that has movflag in the beginning than end [04:24:05 CET] <Modern13> i thought end is more popular [04:24:58 CET] <miketo> i have no idea about popular. the end is more "natural" [04:26:07 CET] <miketo> you can't make the moov atom until you know details like the exact length of the other data. since you have this information when you're done, it's natural to write it at the end. [04:29:43 CET] <Modern13> then why do i see more mp4 files that has movflag in the beginning than end [04:30:13 CET] <Modern13> i just randomly downloaded bunch of mp4 to test [04:31:59 CET] <miketo> if it's at the front of the file, then the file had to have (at least one) extra processing step. i'm not surprised that many places will go through the extra step to make files that stream better. depending on where the file is from, i'd expect it [04:32:46 CET] <miketo> for example, it seems all youtube mp4 have moov in front. that's not surprising since we know youtube already spends a lot of cpu to re-encode every uploaded file for the best user experience [04:34:55 CET] <Hello71> lol, downloaded bunch from youtube [04:35:36 CET] <Modern13> Hello71 no none of them from youtube [04:35:48 CET] <Modern13> because that will be pointless, they all will be on the front [04:36:04 CET] <Modern13> what other container supports x264/aac other than mp4 and mkv [04:38:08 CET] <miketo> Modern13: lots. https://en.wikipedia.org/wiki/Comparison_of_video_container_formats [04:38:59 CET] <Modern13> what would you recommend to use if "mp4/mkv" wasn't the one of the choice [04:39:22 CET] <Modern13> and that ffmpeg supports muxing to [04:40:42 CET] <miketo> i'm no expert. but i use mkv. it supports so much. if you can't use mkv for some reason, then that reason will probably tell you which to use (example: device doesn't support mkv, but does support mp4) [04:41:11 CET] <Modern13> miketo i heard webm is popular, but i don't see that in that wiki site [04:42:24 CET] <miketo> i'm likely to be wrong, but i think webm is a subtype of mkv (simpler version for mobile or something) [04:42:49 CET] <Modern13> i never heard that [04:42:58 CET] <Modern13> does ffmpeg support webm [04:43:37 CET] <miketo> it seems to decode webm perfectly, but i don't think to can encode into webm [04:44:32 CET] <miketo> from wiki: "The WebM container is based on a profile of Matroska" matroska is the name for mkv extension [04:45:51 CET] <Modern13> miketo what about mux mp4 to webm [04:49:10 CET] <miketo> from ffmpeg "Only VP8 or VP9 video and Vorbis or Opus audio and WebVTT subtitles are supported for WebM" [04:50:07 CET] <miketo> so you'd have to re-encode if not using those codecs, but it does seem to work [04:53:12 CET] <Modern13> ok [04:57:09 CET] <miketo> i need to go. good luck [05:03:21 CET] <jay_> hello~! [05:03:45 CET] <jay_> Somebody help me. [05:04:13 CET] <jay_> Unrecognized option 'tune'. Error splitting the argument list: Option not found [05:05:31 CET] <jay_> ffmpeg -i 'pipe:0' -acodec copy -vcodec copy -preset ultrafast -tune zerolatency -f flv rtmp://loacalhost:1935/src/ [05:06:45 CET] <jay_> Can anyone help? I have no idea what to do. [05:07:11 CET] <jay_> ffmpeg version N-82166-g894e7ef Copyright (c) 2000-2016 the FFmpeg developers built with gcc 4.8.3 (GCC) 20140911 (Red Hat 4.8.3-9) configuration: --prefix=/usr/local/ffmpeg_build --extra-cflags=-I/usr/local/ffmpeg_build/include --extra-ldflags=-L/usr/local/ffmpeg_build/lib --bindir=/usr/local/bin libavutil 55. 35.100 / 55. 35.100 libavcodec 57. 65.100 / 57. 65.100 libavformat 57. 57.100 / 57. 57.100 libavdevice [06:03:13 CET] <miketo> jay_: -tune isn't an option for flv format [06:04:08 CET] <miketo> it's an x264 option, but you're not using x264 [08:18:09 CET] <Janos__> Hi, I am trying to figure out why ffmpeg started to make recording in slower speed and pitch than the original source? [08:19:37 CET] <Janos__> I've been using kazam to do some screen capturing, I first thought it's an issue with kazam, but now I've tried a few different screen capture tools, and they all produce the same slowed down video/audio [08:24:39 CET] <Janos__> Has anyone here had a similar experience and knows what to do? I've been searching for a solution but found nothing.. [09:07:05 CET] <torroid> Hi! Im would like to contribute.. Please could I get a starting point? [09:08:04 CET] <Janos__> maybe try the Development channel [09:08:16 CET] <Janos__> at: #ffmpeg-devel [09:09:44 CET] <torroid> thanks a lot! [09:10:02 CET] <JEEB> just start with building [09:11:59 CET] <Janos__> I did some cli tests, and the problems seems to be linked to recording from the analog-stereo monitor [09:12:38 CET] <Janos__> ffmpeg -y -f pulse -i default -r 30 -f x11grab -s 1920x1080 -i ${DISPLAY} -c:v libx264rgb -crf 0 -preset:v ultrafast -c:a pcm_s16le -af aresample=async=1:first_pts=0 out1.mkv [09:13:00 CET] <Janos__> records from the microphone with perfect speed [09:13:11 CET] <Janos__> ffmpeg -y -f pulse -i alsa_output.pci-0000_00_14.2.analog-stereo.monitor -r 30 -f x11grab -s 1920x1080 -i ${DISPLAY} -c:v libx264rgb -crf 0 -preset:v ultrafast -c:a pcm_s16le -af aresample=async=1:first_pts=0 out2.mkv [09:15:57 CET] <Janos__> records from the analog-stereo, the sound is slow and low pitch [09:51:01 CET] <Janos__> https://ubuntuforums.org/showthread.php?t=2347599 [09:51:43 CET] <Janos__> I started a thread, so I can provide more details and make it easier to discuss the issue... if someone feels like taking a look and/or help me out, I'd greatly appreciate it :) [09:58:31 CET] <pomaranc> that may be a problem with pulseaudio [09:58:46 CET] <pomaranc> because pulseaudio sucks [13:12:49 CET] <zetheroo> I have these videos taken with my DSLR at 1080p. They are pretty big - 1GB = @6 min. I would like to downsize them without loosing quality ... as much as possible. I have been trying with WinFF but the output files are just as larger, or larger, than the originals. [13:16:53 CET] <ikevin> zetheroo, you can't compress a video without loosing quality [13:19:10 CET] <zetheroo> ikevin: Handbrake seems to do the trick, except that there is no audio on the file after conversion [13:20:03 CET] <zetheroo> video is still 1080p and near to the same quality as the original but is less than half the size of the original [13:20:33 CET] <zetheroo> YouTube seems to also keep the quality while compressing video quite a bit [13:21:42 CET] <zetheroo> how can I compress my video's with ffmpeg? [13:22:44 CET] <BtbN> youtube keeping the quality? If you mean getting rid of any quality that might have been in the original video, maybe. [13:22:47 CET] <DHE> yes. how much to compress is a bit of a black art... [13:23:06 CET] <zetheroo> I guess so [13:23:11 CET] <DHE> and yes, BtbN is right. youtube bitrate is actaully rather low. maybe fine for talking faces, but horrible for motion [13:23:19 CET] <kerio> they keep the quality for themselves [13:23:22 CET] <zetheroo> there is always going to be a tradeoff I suppose [13:23:29 CET] <DHE> zetheroo: pastebin the output of "ffprobe $inputfile" [13:23:30 CET] <BtbN> Unless you go loessless [13:23:36 CET] <BtbN> -e [13:23:41 CET] <DHE> just want to see what you're getting. for example you might be getting PCM audio [13:24:06 CET] <BtbN> x264 with crf 20-22 should be fine for you though, and not too huge [13:26:36 CET] <zetheroo1> DHE: https://paste.ubuntu.com/23694041/ [13:29:39 CET] <zetheroo1> yes, it does seem to have PCM audio [13:30:41 CET] <DHE> alrighty then. as an off-the-top-of-my-head command, ffmpeg -i DSC_0265.MOV -c:v libx264 -crf:v 21 -c:a aac -b:a 128k output.mp4 [13:31:00 CET] <zetheroo1> ok, will give that a whirl [13:31:13 CET] <BtbN> -c:a aac -b:a 196k -c:v libx264 -crf 21 out.mp4 [13:31:44 CET] <BtbN> maybe add -movflags faststart [13:32:00 CET] <zetheroo1> got some message: [13:32:01 CET] <zetheroo1> [aac @ 0x15e6cc0] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it. [13:32:01 CET] <zetheroo1> [aac @ 0x15e6cc0] Alternatively use the non experimental encoder 'libvo_aacenc'. [13:32:09 CET] <DHE> oh you have an old version of ffmpeg [13:32:17 CET] <zetheroo1> :P [13:32:32 CET] <BtbN> update it first. [13:32:44 CET] <DHE> still, you should be able to just replace "aac" with "libvo_aacenc" as indicated and at least have it go [13:33:00 CET] <zetheroo1> I think it's the latest in the Ubuntu repos [13:33:16 CET] <zetheroo1> ok, trying with libvo_aacenc [13:33:47 CET] <DHE> one thing to keep in mind is that distros will often keep the same version (or version branch) as long as possible so as to avoid breaking applications dependent on version-specific features and syntax [13:33:54 CET] <BtbN> that encoder is even worse [13:33:58 CET] <BtbN> forget about it, and update ffmpeg. [13:34:04 CET] <DHE> oh... yeah that makes sense actually [13:34:19 CET] <zetheroo1> looking for an ffmpeg PPA ;) [13:34:33 CET] <BtbN> just download a static binary [13:34:45 CET] <DHE> just make sure it has x264 in it. most do though [13:36:44 CET] <zetheroo1> updating [13:38:00 CET] <zetheroo1> ok, updated - how do you see the version etc? [13:38:11 CET] <BtbN> run without arguments [13:38:45 CET] <zetheroo1> https://paste.ubuntu.com/23694081/ [13:38:53 CET] <zetheroo1> is that better? [13:39:02 CET] <BtbN> still just a stable release, but should get the job done [13:39:05 CET] <DHE> quite a bit better [13:39:25 CET] <DHE> 2016-12-02 vs... probably 2015 something I'd bet [13:39:43 CET] <zetheroo1> ok, so going to try again with aac [13:39:54 CET] <zetheroo1> it's going ... [13:46:59 CET] <zetheroo1> ok, so the output file is about half the size [13:47:15 CET] <DHE> raising the crf value will give smaller files but lower image quality [13:47:23 CET] <zetheroo1> ok [13:49:43 CET] <zetheroo1> I can't really tell the difference in quality between the orig and the converted video ... [13:50:47 CET] <zetheroo1> is there any way to see in the file stats/info what the difference in quality is? [13:54:35 CET] <DHE> not really. it's all perceptual. x264 prints various technical stats but technical reports and what your eyes think don't necessarily relate [13:55:35 CET] <zetheroo1> ok [14:01:04 CET] <zetheroo1> is there a way to queue several videos for conversion? [14:01:14 CET] <BtbN> use your shells capabilities to run loops. [14:22:08 CET] <xeche> hey guys [14:22:31 CET] <xeche> anyone seen this before? [hevc_qsv @ blahblah] Could not load the requested plugin: 2fca99749fdb49aeb121a5b63ef568f7 [14:23:38 CET] <xeche> I've been digging around the source code a bit, and it looks like FFMPEG assumes the hash of a dynamically linked plugin (?) should be the hash mentioned above, but there's very little in the Intel Media SDK that suggests a plugin with that hash even exists? [16:06:10 CET] <FlyingBot> Hello there. I'm trying to burn a timecode using milliseconds and starting at hour '01' (e.g.: '01:00:00.344'). Right now I'm using "text='%%{pts \\: hms}'", but it starts at hour '00'. How could I change that? [18:19:13 CET] <pbos> Hi, is there a good way to print resolution/fps of a y4m file, I'm automating codec quality comparisons [18:19:39 CET] <fritsch> mediainfo + grep [18:19:43 CET] <pbos> and am currently relying on the format file_1280_720.yuv which is a little clunky [18:19:45 CET] <fritsch> or ffprobe + grep [18:20:00 CET] <pbos> thanks [18:24:54 CET] <JEEB> ffprobe can output json [18:24:59 CET] <JEEB> and you can use whatever scripting language [18:25:01 CET] <JEEB> but uhh [18:25:12 CET] <JEEB> .yuv files generally have no headers or anything [18:25:14 CET] <pbos> json + bash are bffs, right? [18:25:24 CET] <pbos> yeah, hence I figure y4m would be better [18:25:33 CET] <pbos> it's also what most (all?) of the derf set is in [18:25:36 CET] <JEEB> yes [18:25:49 CET] <JEEB> just noted that if it was raw YCbCr without anything else you wouldn't get any info [18:26:01 CET] <JEEB> but yes, y4m gives you a few pieces of info [18:26:08 CET] <pbos> thanks :) [18:43:20 CET] <FlyingBot> Hello there. I'm trying to burn a timecode using milliseconds and starting at hour '01' (e.g.: '01:00:00.344'). Right now I'm using "text='%%{pts \\: hms}'", but it starts at hour '00'. How could I change that? [20:47:51 CET] <pbos> Running ffmpeg in a bash script deep in somewhere changes my stty -a, can I make ffmpeg not touch this, am I wielding it wrong? [20:48:07 CET] <pbos> manifests itself as not being able to echo characters [20:49:24 CET] <pbos> python script runs shell script using subprocess, the shell script runs ffmpeg, after running ffmpeg -i foo.y4m foo.yuv my tty no longer echoes characters [20:50:10 CET] <pbos> diff: https://www.diffchecker.com/13srhuhf [20:50:15 CET] <pbos> -loglevel quiet doesn't help [20:50:40 CET] <llogan> try adding "-nostdin" ffmpeg option [20:51:56 CET] <pbos> no luck, even if the shell script calls exit just after that [20:53:18 CET] <pbos> ffmpeg -i foo bar < /dev/null did it [20:53:27 CET] <pbos> since I have a shell that's alright [20:53:57 CET] <llogan> by "did it" you mean it fixed your issue? [20:54:11 CET] <pbos> yep, stopped mucking up my terminal [20:54:55 CET] <llogan> -nostdin should have had the same result [20:55:17 CET] <llogan> i guess [20:55:38 CET] <pbos> let me double check [21:00:38 CET] <pbos> nope, -nostdin mucks it, < /dev/null doesn't [21:35:18 CET] <__raven__> hi [21:35:23 CET] <__raven__> how to save the best possible quality of 25i pal video captured from analogue input into mp4? to avoid interlacing artifacts into 25p converted mp4 i would like to have a 50p output with doubled odd and even lines. how to do that? [21:37:04 CET] <pbos> __raven__: Doesn't that simply render out the interlacing artifacts? [21:37:24 CET] <pbos> __raven__: Have you looked at yadif or any other deinterlacing filter? [21:39:02 CET] <furq> yadif mode 1 will do that [21:39:32 CET] <furq> if you want "best possible quality" then you probably want to use a slower deinterlacer like nnedi [21:39:41 CET] <furq> nnedi in ffmpeg is incredibly slow, though [21:39:57 CET] <furq> you can use it multithreaded in avisynth/vapoursynth if yadif isn't good enough for you [21:41:24 CET] <furq> http://avisynth.nl/index.php/QTGMC [21:41:42 CET] <furq> i use the vapoursynth port of that for interlaced sd stuff, it's great if you can tolerate how slow it is [21:41:50 CET] <furq> yadif will probably be fine for hd [21:43:44 CET] <__raven__> furq: main problem now is: mpeg2@25mbits kind of blurs and "washes" out the image and adds artifacts from the encoded lines. transcoding to mpeg4 with yadif is even worse due to a blended deinterlacing instead of doing it linear by just double the lines and putting the "full frame fields" into a 50p [21:44:30 CET] <__raven__> so the main issue here is to find a deinterlacer which does not modify the image by blending lines but just double the lines [21:45:20 CET] <Mavrik> em [21:45:29 CET] <Mavrik> shouldn't there be a setting for yadif to do that? [21:47:30 CET] <pbos> __raven__: If it does exactly what you're describing then you'll probably have bobbing artifacts [21:47:46 CET] <__raven__> i actually have 1,-1,0 what should "output a frame for a field" but those frames have a blended output. i checked agains a drop-method: those pics are "clean" [21:47:47 CET] <pbos> or I'm misunderstanding it [21:48:38 CET] <__raven__> what are those? [21:50:00 CET] <furq> like i said, yadif mode 1 will give frame-per-field output [21:50:21 CET] <furq> -vf yadif=1 [21:51:03 CET] <furq> i think it's slightly more smart than just outputting double-height fields, but i couldn't tell you how [21:51:24 CET] <furq> since that's what -vf bob would do, and it'd be a fair bit faster [21:51:30 CET] <pbos> if it's just duplicating lines there'll be significant artifacts [21:52:17 CET] <__raven__> furq: but something is just wrong. in moving sequences with stepping trough the frames i see a frame which seems to be blend together by two "moving" fields. thats not there when i just drop the frames but of course i loose resolution [21:52:26 CET] <furq> oh wait was there ever a -vf bob [21:52:41 CET] <pbos> furq: bwdif maybe? [21:52:51 CET] <furq> either way that's what a bob filter does, and those never look great [21:52:56 CET] <furq> so i assume yadif is doing some additional magic [21:53:02 CET] <pbos> otherwise I'll stop googleguessing [21:53:09 CET] <furq> yadif is designed for playback, though, so it's not the best for non-realtime [21:53:38 CET] <__raven__> hmmm [21:53:57 CET] <furq> qtgmc does a great job with that kind of source, but it's slow and it's a lot of work to set it up [21:54:16 CET] <__raven__> ok so half size would be ok too [21:54:34 CET] <furq> ffmpeg has a nnedi implementation, but it's really slow because libavfilter doesn't have frame multithreading [21:54:49 CET] <furq> slow enough to severely bottleneck x264 veryslow [21:55:07 CET] <__raven__> anything what sorts out artifacts from mpeg suffering trying to encode interlaced frames would be fine for me :) [21:55:23 CET] <furq> that's more or less what qtgmc was designed to do [21:55:47 CET] <furq> it uses nnedi as the deinterlacer but it does a lot of additional stuff that's designed for transcoding messy mpeg2 sources [21:55:59 CET] <furq> i use it for all my interlaced dvd rips, it works a treat [21:56:48 CET] <__raven__> ingest material is huffyuv now so the first problem is solved by now. next mpeg4 needs to avoid that effect [21:58:58 CET] <__raven__> so the actual goal should be not more than basically "just" doubling every existing frame to 50p and half even and odd frames next [21:59:09 CET] <__raven__> correct me if i am wrong [21:59:56 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#separatefields-1 [22:00:01 CET] <furq> you could try that and scale afterwards [22:00:21 CET] <furq> i guess there's no need for a regular bob filter when you can do that and pick your resize filter [22:00:53 CET] <pbos> You should notice artifacts. :) [22:01:13 CET] <furq> well yeah i'm not saying it'll look good [22:01:28 CET] <furq> that's what was asked for, though [22:01:34 CET] <pbos> true [22:01:47 CET] <pbos> __raven__: look at it then reconsider reconsidering :) [22:02:03 CET] <furq> yeah there's only one way to find out if it does the job [22:02:12 CET] <furq> also when you say "mpeg4" do you mean x264 [22:02:28 CET] <__raven__> right [22:02:35 CET] <furq> ok good [22:02:49 CET] <furq> that rules out the problem being that mpeg4 sucks [22:03:01 CET] <pbos> if you have only k*25hz motion it's probably the best deinterlacing filter ever [22:03:25 CET] <__raven__> how have broadcast stations been doing this by imx for example? they had 25 - 50mbits mpeg2 and interlaced sd and i never noticed any artifacts? [22:04:04 CET] <furq> if you mean on your tv, it's because your tv probably has a good deinterlacer [22:04:23 CET] <__raven__> did they use a 25p mpeg2 fullsize or a 50p halfsize? [22:04:33 CET] <furq> they use both afaik [22:04:39 CET] <furq> sport is usually 50i [22:04:51 CET] <__raven__> furq: sorry i have to say that i was working on a tv station but never had any insights into the playout servers [22:05:40 CET] <furq> if you mean the theory behind how the good deinterlacer works, i'm not really the man to ask [22:06:11 CET] <furq> i just hang out in places for long enough to hear about what the best words to type into ffmpeg are [22:06:14 CET] <Threads> what about -r 50.000 -vf yadif=1,scale=720:404,setsar=1:1,format=yuv420p [22:06:17 CET] <furq> (or vapoursynth) [22:06:30 CET] <Threads> im not a quality whore but i use that for 50fps output [22:06:38 CET] <furq> quite a lot of that seems redundant [22:06:52 CET] <__raven__> not the interlacer! it was a "natively" sd-pal sdi environment so the only question is, how did they sort out any line artifacts on the files? [22:07:02 CET] <furq> -vf yadif=1 will already set the output framerate to 50 and scale it correctly [22:07:10 CET] <furq> and also it won't change the pixel format [22:07:20 CET] <Threads> furq i like to go the long way round [22:07:42 CET] <Threads> you say 2 lines i say 15lines [22:08:14 CET] <furq> well yeah but that'll needlessly fuck up non-25fps sources [22:08:35 CET] <furq> there is often no harm in being verbose but that just makes your command more specific for no good reason [22:08:46 CET] <furq> more specific wrt what inputs it'll take [22:09:12 CET] <furq> __raven__: i'm pretty sure they just broadcasted it interlaced and let the customers' tvs sort it out [22:09:19 CET] <furq> that's fairly standard [22:09:38 CET] <furq> s/broadcasted/broadcast/ [22:10:04 CET] <__raven__> furq: i am talking about the mpeg2 files on the broadcast servers. those already had interlaced material "in it" [22:10:14 CET] <furq> yeah they would just broadcast those as-is [22:10:23 CET] <MonicleLewinsky> Okay, I've got a stumper (at least for me). I'm trying to remux a .ts video with Closed Captions (EIA-608) into an mkv. ffmpeg keeps losing the captions [22:10:50 CET] <furq> at least in my limited experience [22:11:07 CET] <furq> i know all the hd content i get is 50i [22:11:39 CET] <Threads> MonicleLewinsky tried -c copy ? [22:11:43 CET] <MonicleLewinsky> Threads: Yes [22:11:50 CET] <__raven__> so what approach would work for me if i want to have a 720*288@50p output from the given 25p interlaced input? [22:12:12 CET] <furq> if your input is 576p then just use -vf separatefields [22:12:12 CET] <pbos> __raven__: probably frame by frame, e.g. just stored in half-height frames with some metadata describing which frame is upper and which frame is the lower fields [22:12:49 CET] <MonicleLewinsky> Threads: -i movie.ts -map 0 -c copy movie.mkv [22:12:57 CET] <MonicleLewinsky> ^ Is what I've tried [22:13:05 CET] <furq> closed captions are some kind of side data in the video stream iirc [22:13:11 CET] <furq> i forget if ffmpeg handles those properly [22:13:14 CET] <pbos> __raven__: Any reason why you believe yadif would not do it? [22:13:19 CET] <furq> it's not just a subtitle stream though [22:13:24 CET] <furq> pbos: he asked for half-height output [22:13:51 CET] <pbos> oh, uuh, isn't that what you suggested as separatefields? [22:13:55 CET] <furq> yeah [22:14:00 CET] <furq> that's exactly what separatefields does [22:14:01 CET] <pbos> __raven__: ^ [22:14:07 CET] <pbos> -vf separatefields [22:14:15 CET] <pbos> if my very-beginner ffmpeg foo holds [22:14:25 CET] <furq> 21:12:12 ( furq) if your input is 576p then just use -vf separatefields [22:14:28 CET] <furq> looks fine to me [22:14:48 CET] <pbos> for some definition of fine [22:14:55 CET] <MonicleLewinsky> furq: How would I check if it handles that? [22:14:56 CET] Action: pbos ducks. [22:15:10 CET] <__raven__> yadif did mix two fields and caused kind of ghosting any way [22:15:21 CET] <pbos> try one of the non-realtime filters [22:15:25 CET] <__raven__> i will try some of the options and investigate it. tnx so far :) [22:15:58 CET] <pbos> __raven__: https://ffmpeg.org/ffmpeg-filters.html#nnedi was also suggested [22:16:13 CET] <pbos> not sure if it doubles your fps or not [22:16:21 CET] <pbos> consider looking into that though [22:16:37 CET] <furq> it does by default [22:16:42 CET] <furq> it's incredibly slow, though [22:16:50 CET] <furq> i'd never use the ffmpeg implementation until it gets frame multithreading [22:17:05 CET] <pbos> you could split the input, do it in parallel and merge [22:17:12 CET] <furq> i think last time i tried to use it i was getting ~3fps encoding sd mpeg2 [22:17:42 CET] <pbos> I'm taking Threads' complicated route. [22:18:09 CET] <furq> well the complicated route would be setting up vapoursynth and using a multithreaded implementation [22:18:33 CET] <furq> 15fps is at least tolerable [22:20:40 CET] <furq> MonicleLewinsky: there appears to be a closed caption decoder but i can't tell how you actually use it [22:20:57 CET] <MonicleLewinsky> Whoa. 'ffmpeg -f lavfi -i "movie=./video.ts[out0+subcc]" -map s video.srt' seems to be doing something [22:21:26 CET] <MonicleLewinsky> The time estimates are really jumping around though [22:22:32 CET] <furq> you might need ffmpeg with libzvbi? [22:25:42 CET] <MonicleLewinsky> furq: Does that just involve a re-compile with a flag I'm missing? [22:35:03 CET] <Tommi> hi all... requesting some help on my attempt to compile kdenlive, where ./configure in ffmpeg can't seem to find libtheora. the package shows as installed. recompiled ffmpeg with the latest build, and the problem persists [22:35:37 CET] <c_14> do you have the -dev version installed? [22:35:39 CET] <JEEB> check the results of the configure checks [22:35:50 CET] <JEEB> and yes, if your distro packages the development library and headers separately... [22:35:53 CET] <JEEB> make sure they are installed [22:36:12 CET] <furq> MonicleLewinsky: yeah, but bear in mind i have no idea whether that'll do anything [22:36:29 CET] <furq> google isn't coming back with much of any use [22:37:25 CET] <Tommi> c_14: the -dev for which package? [22:37:34 CET] <c_14> libtheora [22:38:16 CET] <Tommi> let me check! [22:42:02 CET] <Tommi> let me check!; https://cloud.kjuicer.com/index.php/s/pdfyXglpmDlxp8W [22:42:27 CET] <Tommi> whoops: the above is the link to my config.log [22:42:50 CET] <Tommi> the message got messed up, sorry [22:44:36 CET] <Tommi> JEEB: yesterday I checked the config.log but could not understand/identify what went wrong. the version of libtheora that shows up is libtheora-1.1.1-13.fc23.x86_64 [22:46:22 CET] <JEEB> Tommi: it's the libtheora-devel package then that you need :P [22:46:53 CET] <JEEB> and you search config.log for theora basically, it does a couple of checks for if the thing is around and usable [22:47:08 CET] <Tommi> intuitively it does not look like a -dev. does libetheora come from compiling ffmpeg-3.2.2.tar.bz2 or it is a separate package? [22:48:05 CET] <Tommi> JEEB: ok let me try to install that version + check the log [22:48:14 CET] <Tommi> thanks! [22:48:42 CET] <JEEB> libtheora is the library that provides the theora decoding and encoding library, the -devel package of that provides the headers and non-versioned library :P [22:48:53 CET] <JEEB> FFmpeg can use libtheora to encode theora video [22:49:09 CET] <JEEB> if you don't need theora video encoding the libtheora is literally useless for you [22:50:27 CET] <Tommi> mmm... unsure. but I need ffmpeg for kdenlive, which is video [22:50:39 CET] <__raven__> i made some more tests. results are those: http://picpaste.com/EdMcvmYe.png [22:50:57 CET] <stringtheory> Hi, I just installed ffmpeg I'm running it through the windows 7 terminal, how do I pull 3rd party libraries? [22:51:07 CET] <JEEB> Tommi: kdenlive just uses ffmpeg's libraries to encode its output. and theora is probably one of the formats it will give you as the alternative :P [22:51:19 CET] <JEEB> stringtheory: you have to do that during build time [22:51:30 CET] <JEEB> at least for most things [22:51:47 CET] <JEEB> some things like avisynth and cuvid have dynamic loading support I think? [22:51:58 CET] <__raven__> as you can see, yadif processes the image itself and adds some slightly blur and colour artifacts and separatefields aso seems to be no option due to broken motion [22:52:55 CET] <stringtheory> @JEEB thanks, so I need the source code, and compile my own build? [22:53:23 CET] <JEEB> yes [22:53:36 CET] <pbos> __raven__: Strange clip to use for quality, fwiw [22:54:02 CET] <__raven__> pbos: thats the best i am able to generate now. thats from the internal character generator of the vhs player [22:55:20 CET] <pbos> __raven__: This clip will heavily skew you towards wanting to duplicate all the lines [22:55:27 CET] <pbos> you have no horizontal/vertical motion at all [22:55:41 CET] <__raven__> pbos: yes [22:56:47 CET] <stringtheory> JEEB: what language is ffmpeg written in? Python? [22:56:53 CET] <pbos> __raven__: I'd generate an interleaved clip from 60fps example video, see https://ffmpeg.org/ffmpeg-filters.html#interleave_002c-ainterleave [22:57:00 CET] <pbos> stringtheory: a lot of c, python is slow [22:57:46 CET] <__raven__> pbos: i wanted to include the analogue path to add some "stress" to the codec [22:57:59 CET] <pbos> __raven__: might also be -vf il [22:58:09 CET] <pbos> I have no ffmpeg experience, more general video stuff [22:58:20 CET] <__raven__> il? [22:58:21 CET] <stringtheory> JEEB: Makes sense, good to know I don't need anything extra to compile builds [22:58:22 CET] <pbos> __raven__: How do you reckon that stresses the codec? [22:58:28 CET] <pbos> __raven__: https://ffmpeg.org/ffmpeg-filters.html#il [22:58:34 CET] <pbos> I'm just googling at this point [22:58:46 CET] <__raven__> pbos: its at least a bit noise in the image [22:59:48 CET] <pbos> __raven__: There should be some handycam example files that you could find that are interleaved [22:59:49 CET] <Tommi> JEEB+c_14: well, compiling went much further :) not it seems to be stuck on mlt, which is some progress. thank you [23:00:00 CET] <Tommi> *now [23:00:05 CET] <pbos> I don't think the derf set contains any interleaved files [23:01:32 CET] <pbos> __raven__: or -vf smooth, -vf noise if you want to mess with it [23:02:01 CET] <pbos> __raven__: Since you're doing this at all, don't you have a clip that you want to solve this for? [23:03:08 CET] <__raven__> pbos: of course - i need to digitize about 83 vhs tapes 4h each so i need to test the workflow [23:03:29 CET] <furq> yeah it's best to use a representative sample [23:03:42 CET] <furq> if you're doing that much stuff then i'd look into vapoursynth and qtgmc [23:03:49 CET] <furq> it's worth the initial setup costs [23:23:53 CET] <pbos> __raven__: Can you digitize the first 30 seconds of a VHS tape then use that as your test clip? [23:23:59 CET] <pbos> I'd also do multiple test clips [23:24:41 CET] <__raven__> pbos: yes i did already. ff also produces good test interlaces ^^ [23:24:55 CET] <__raven__> but i am not anything near a final solution [23:25:07 CET] <pbos> __raven__: Then use those as your comparison clips when testing deinterlacing [23:25:25 CET] <pbos> and you can't do single-frame comparisons if you want to be fair, there's plenty of temporal artifacts when deinterlacing. [23:25:49 CET] <__raven__> still the drop method had the most clearest image but i do not want to loose half of the lines [00:00:00 CET] --- Wed Dec 28 2016

1 0

ffmpeg-devel.log.20161226
by burek 27 Dec '16

27 Dec '16

[00:07:05 CET] <kierank> the headers that the parser uses as far as I can tell don't need vlc codes [00:44:38 CET] <michaelni> the parser could call code that calls mpeg4_decode_sprite_trajectory() i think [00:45:08 CET] <kierank> ah crap, didn't see that one [03:26:17 CET] <kierank> michaelni: any idea what this 0*1 notation means? Some kind of run level thing but I don't get it [03:26:20 CET] <kierank> https://usercontent.irccloud-cdn.com/file/6PrM23D6/ [03:38:29 CET] <kierank> durandal_1707: around? [03:49:23 CET] <michaelni> the 0*n look like they are meant as n times a 0 value [03:50:46 CET] <michaelni> that is a run of n zeros [03:55:14 CET] <kierank> michaelni: ah yes that make sense, thanks [03:55:49 CET] <kierank> fyi code i am working on is here [03:55:49 CET] <kierank> https://github.com/kierank/ffmpeg-sstp [03:56:05 CET] <kierank> the dc prediction stuff I think is very broke but I'd like to decode a MB cleanly first [06:02:27 CET] <atomnuker> how to declare exposed private things, the libfftw3 way: [06:02:34 CET] <atomnuker> enum fftw_r2r_kind_do_not_use_me { [06:02:45 CET] <atomnuker> struct fftw_iodim_do_not_use_me { [06:02:54 CET] <atomnuker> typedef void (*fftw_write_char_func_do_not_use_me)(char c, void *); [07:44:32 CET] <rcombs> the correct answer being, of course, "don't" [10:39:33 CET] <durandal_1707> atomnuker: why you use fftw3? [10:42:06 CET] <atomnuker> I don't [10:42:30 CET] <atomnuker> I read 2 books on ffts, wrote my own 15x2 and finally got enough knowledge to know what the current fft does [10:43:16 CET] <atomnuker> I fixed it so it's now working correctly as a forward transform and I want to kill the bastard who didn't comment his code [10:46:44 CET] <atomnuker> at least now I'm one of the elite few who can write a cooley-tukey fft without looking and an mdct [10:46:57 CET] <atomnuker> (btw why is fftw3 so fast?) [10:47:12 CET] <atomnuker> (btw WHY THE FUCK IS FFTW3 SO FUCKING FAST?) [10:47:43 CET] <atomnuker> granted, it's a small transform which takes microseconds but still, fftw3 is 10x faster [10:47:48 CET] <nevcairiel> because one of its Fs stands for fastest [10:47:51 CET] <atomnuker> hell, more [10:48:03 CET] <atomnuker> 400 000 transforms (960 len) per second [10:48:10 CET] <atomnuker> mine can barely do 4 000 [10:48:42 CET] <nevcairiel> i've been meaning to migrate work software from kissfft to fftw since we had some performance issues on small arm devices, in the hope that it makes a real difference [10:49:00 CET] <atomnuker> kiss_fft does 7 000 [10:49:34 CET] <atomnuker> so yeah, it'll be a drastic change, if fftw3's NEON is as good as its x86 assembly [10:49:47 CET] <atomnuker> no, forget that, even without assembly [10:50:19 CET] <atomnuker> how is the universe didn't explode when fftw3 become so fast is beyond me [10:50:20 CET] <nevcairiel> fftw uses threaded parallel processing if you let it, most dont do that [10:50:39 CET] <atomnuker> multithreading? no, it won't [10:50:47 CET] <atomnuker> you need to compile it with openmp (ugh) [10:51:01 CET] <nevcairiel> it claims to work with posix threads [10:51:08 CET] <nevcairiel> but i didnt try [10:51:27 CET] <atomnuker> well, debian's libfftw3 is compiled without threading support, the functions to init threading aren't there [10:54:24 CET] <nevcairiel> even more fascinating then [10:55:13 CET] <atomnuker> give me a minute and I'll send you the program with all 3 implementations so you can benchmark [11:17:09 CET] <atomnuker> nevcairiel: https://pars.ee/temp/fft_bench.tar [11:17:17 CET] <nevcairiel> nice, thanks [11:17:27 CET] <atomnuker> compile with "gcc -O3 -g prog.c kiss/kiss_fft.c -lm -lrt -lfftw3f -Wall" [11:18:08 CET] <atomnuker> adjust SSA for the size (15 * (1 << SSA)) and ITER for the number of fft->iffts to do [11:19:25 CET] <cone-292> ffmpeg 03Bela Bodecs 07master:e7fbd7018932: avformat/hlsenc: detecting duplicated segment filenames ffmpeg-devel [11:20:03 CET] <atomnuker> you can just set SIZE to other numbers and benchmark powers of two, e.g., run_new will simply give an incorrect result [16:03:09 CET] <cone-546> ffmpeg 03James Almer 07master:c3d822855cb5: avcodec/lossless_videodsp: fix output of add_hfyu_left_pred_int16_c() [16:14:57 CET] <cone-546> ffmpeg 03Ruta Gadkari 07master:67db4ff3b66e: NVENC: Update check for Lookahead [17:36:29 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:12461636ea8c: avcodec/magicyuv: export colorspace and color_range for YUV [18:30:49 CET] <cone-546> ffmpeg 03Bela Bodecs 07master:ce5c7260df2d: flv demuxer supports live rtmp inputs but there is no any info about it in the docs. [18:30:50 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:89d4d7d759a5: doc/examples/http_multiclient: Fix resource leak [20:44:28 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:341d3ee44147: avcodec/ylc: do not leak memory at uninit [20:44:29 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:31bf37cba8ff: avcodec/ylc: add frame threading support [20:44:30 CET] <cone-546> ffmpeg 03Paul B Mahol 07master:2f347c17d646: avcodec/ylc: thread safe initialization is possible with this codec [20:45:51 CET] <cone-546> ffmpeg 03Michael Niedermayer 07master:11103a493de5: ffmpeg: Check avcodec_parameters_to_context() for failure [00:00:00 CET] --- Tue Dec 27 2016

1 0

ffmpeg.log.20161226
by burek 27 Dec '16

27 Dec '16

[00:51:08 CET] <Airwave> I have an mpeg1video stream in a mov container than I'm trying to convert to h264. When I try to convert, the encoding stops at frame 3 and quits. The video plays just fine with ffplay. [01:13:52 CET] <Airwave> kepstin: https://paste.fedoraproject.org/512892/27112201/ [01:16:52 CET] <kepstin> hmm, that's really weird. It's complaining about giant image sizes (possibly due to the strange sar/dar) and possibly some issue with timestamps too [01:18:45 CET] <kepstin> it's detected the video framerate as 0.08 fps, do you know if that's anywhere close to what it should be? [01:21:08 CET] <kepstin> this is a pretty nasty file, I suspect you might have to rewrite the timestamps using filters to get it to encode. I'm kind of surprised the players are able to do something reasonable [01:22:41 CET] <kepstin> I suspect you will probably be able to get it to encode reasonably by using the "-r" input option (before the input file) to override the incorrect detected framerate. [01:26:40 CET] <kepstin> since there's no audio to sync to you just have to pick something that looks reasonable, probably one of 24, 25, or 30 would be decent. [01:38:53 CET] <Airwave> kepstin: 0.08 is definitely not correct. There's no audio to sync to. I'll try with -r. [01:47:48 CET] <Airwave> kepstin: It encoded the entire thing when I specified frame rate with -r. I'm not sure how to actually figure out the correct frame rate though. ffplay also reports 0.08. [01:48:01 CET] <Airwave> mpv says "[vd] Container reported FPS: 0.084986" [01:51:01 CET] <Airwave> Looks like 30 FPS is correct. When I encode with that, ffmpeg reports the same duration for both files. [01:55:55 CET] <Airwave> kepstin: That solves my issue. Thank you very much! [08:31:18 CET] <beauty> hello [08:31:38 CET] <beauty> how to seek mp4 video using byte? [08:32:06 CET] <beauty> who can help me? sos [08:43:43 CET] <nonex86> beauty: rtfm on avformat_seek_file [08:45:46 CET] <beauty> can you give me a example? [08:46:17 CET] <beauty> I use av_seek_frame ,but it's not sucessful [08:47:24 CET] <nonex86> beauty: no, just the manual, thats enough [08:53:28 CET] <beauty> nonex86 thanks [11:02:23 CET] <Pandela> >tfw I cant find a single working windows application that accepts IP camera streams and renders to a virtual webcam driver that can be picked up by video chat applications [11:43:49 CET] <DelphiWorld> sup guys [11:44:05 CET] <DelphiWorld> i am trying to analise a dvb mpeg2ts stream that contain dvdsub [11:44:10 CET] <DelphiWorld> but the analisys is pretty slow [11:44:30 CET] <DelphiWorld> sometime poes packet size missing [12:17:05 CET] <dossantosfranz> Hello [12:17:09 CET] <dossantosfranz> can someone help me [12:17:27 CET] <dossantosfranz> how can i force rtsp over tcp vu+ openpli [12:33:18 CET] <oaps> hello! [12:34:31 CET] <oaps> i have a bunch of .ts files with H.264 video and AAC audio with the same framerate, width and height, and i'd like to join them together one after the other into a single stream, without transcoding - only changing the frame times. is that possible? [12:38:43 CET] <kerio> oaps: can't you just concatenate them [12:39:29 CET] <oaps> kerio: yes, but the resulting file has the time reset every time a new original file starts. [12:39:34 CET] <kerio> oic [12:40:22 CET] <JEEB> you can try remuxing of course, but I think even with the timestamp wraps or whatever eeeeeeeit should generally be "OK" for MPEG-TS [12:41:25 CET] <JEEB> remuxing mpeg-ts can be "fun" though, since the last time I tried it the whole system only finished the timestamp calculations after decoding (which with remuxing will never happen) [12:41:38 CET] <JEEB> although granted, that will only be an issue with certain types of streams [20:35:38 CET] <fbnts> Hi, I'm trying to hardcode subtitles onto a video by using the -vf subtitles=test.srt options. Is there a way I can have ffmpeg extend the video canvas and encode the srt file onto the new blank area? [21:06:27 CET] <DHE> fbnts: expand the canvas first, then use the subtitles filter [21:07:09 CET] <fbnts> DHE: I think I have done it now. ffmpeg -i test.mp4 -vf "pad=width=1200:height=576:x=0:y=0:color=white,subtitles=test.srt:force_style='FontName=Courier,FontSize=10,Alignment=7'" test2.mp4 [21:07:12 CET] <fbnts> seems to work [21:07:45 CET] <DHE> conceptually that looks right.... though white for the subtitle area? [21:10:51 CET] <fbnts> Yeah, that was just my testing. What I am actually doing is trying to overlay EPOS journal to the right of some CCTV [21:47:01 CET] <FrogCast> I need to automate the creation of videos for youtube. The videos I will be creating will consist of still pictures in a slide show format and an audio track. Is this something I want to be doing in the commandline with ffmpeg, or do I need another tool? [21:48:52 CET] <furq> sounds easy enough with ffmpeg [00:00:00 CET] --- Tue Dec 27 2016

1 0