Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

October 2016

1 participants
62 discussions

ffmpeg-devel.log.20161005
by burek 06 Oct '16

06 Oct '16

[00:10:12 CEST] <Chloe> michaelni: fix sent [00:35:22 CEST] <Chloe> michaelni: Thanks. Someone else may push my patch, or I'll do it tomorrow. I'm not having a good day in terms of not fucking stuff up. [00:46:45 CEST] <cone-960> ffmpeg 03James Almer 07master:3cc9d6d3824f: avformat/matroska: write FlagInterlaced element in WebM [02:23:22 CEST] <cone-960> ffmpeg 03James Almer 07master:b33369b6128a: avformat/matroskaenc: don't reserve space for stream duration tags if the output is not seekable [03:29:27 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:69b00a7fb6fa: avcodec/cavsdsp: use av_clip_uint8() for idct [03:29:28 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:ab737ab31d4f: avcodec/ansi: Check dimensions [03:29:29 CEST] <cone-960> ffmpeg 03Sasi Inguva 07release/2.8:ca216c71c77d: lavc/movtextdec.c: Avoid infinite loop on invalid data. [03:29:30 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:a77261310051: avformat/avidec: Remove ancient assert [03:29:31 CEST] <cone-960> ffmpeg 03Michael Niedermayer 07release/2.8:239f75d6c3df: avformat/avidec: Check nb_streams in read_gab2_sub() [03:29:32 CEST] <cone-960> ffmpeg 03Ronald S. Bultje 07release/2.8:62b2b2195b7e: videodsp: fix 1-byte overread in top/bottom READ_NUM_BYTES iterations. [03:57:27 CEST] <cone-960> ffmpeg 03Josh de Kock 07master:5173ffb27f6e: doc/developer: remove duplicate policies and fix error [04:17:48 CEST] <rcombs> michaelni: thanks for the sample; confirmed and fixed issue (it was because I wrote the patch before the codecpar changes and didn't correctly update it to reflect them) [05:53:06 CEST] <philipl> BtbN: officially abandoning my crazy project. The complexity in no way justifies the tiny performance gain. [05:53:13 CEST] <philipl> I'll look at dynlink for nvcuvid next. [06:55:24 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/25bafc69e9bb13047cc0f30e31e5044420… [07:24:50 CEST] <rcombs> >double-checking that an invalid free() reported on an old version of one of my patches no longer happens [07:24:58 CEST] <rcombs> >enable malloc debugging and heap checking [07:25:05 CEST] <rcombs> >get crashes in szone_check_all() [07:25:20 CEST] <rcombs> >try setting it to sanity-check the heap on _every_ malloc/free [07:25:23 CEST] <rcombs> >still crashes there [07:25:28 CEST] <rcombs> >try building with asan [07:25:33 CEST] <rcombs> >still happens; no warnings from asan [07:30:04 CEST] <rcombs> tl;dr why me [10:09:13 CEST] <BtbN> philipl, which C++ leak? [11:36:27 CEST] <cone-901> ffmpeg 03wm4 07master:40fbf3204208: lavc: set best effort timestamp if unset when using new decode API [13:50:07 CEST] <cone-901> ffmpeg 03Carl Eugen Hoyos 07master:beb877bae026: lavc/tiff: Print compression debug information. [15:28:16 CEST] <BtbN> philipl, https://github.com/BtbN/FFmpeg/commits/master was more thinking about something like this. [15:38:54 CEST] <hawken> oh hey, that's what I'm talking about.. maybe you guys could make sure I don't make mistakes again [15:39:30 CEST] <hawken> I'll tell you what I'm about to change and you can just stop me if it's not going to be enough [15:40:02 CEST] <Chloe> hawken; what do you want to change? [15:40:37 CEST] <hawken> Well https://trac.ffmpeg.org/ticket/5472#comment:9 is the place. I'm about to do what he asks. Run the command, replace the file and this time make a post with everything that ffmpeg said [15:40:45 CEST] <hawken> that should be enough, right? [15:41:14 CEST] <hawken> But I feel that this is kind of stupid, because it's been half a year and it would still reproduce on any of your machines if you were to actually try to reproduce it [15:41:50 CEST] <Chloe> it's probably just because no one has [15:44:35 CEST] <hawken> There we go.. It should pop up here any second [15:49:38 CEST] <hawken> Well this must be enough. I guess I'm also spamming here because I'm trying to draw attention to it.. As of now you can't really mux pgs subtitles with ffmpeg.. [15:50:06 CEST] <hawken> And that's a big letdown if you are working with bluray etc. [15:56:34 CEST] <wm4> can't we make fflogger log to a different channel [15:56:38 CEST] <wm4> it's distracting [16:01:32 CEST] <iive> indeed, it might be good idea to log into #ffmpeg, it is the bugreport channel. [16:05:33 CEST] <hawken> O_o then I'm in the wrong channel.. sorry [16:08:31 CEST] <wm4> no, I mean fflogger and its issue tracker updates [16:22:26 CEST] <Chloe> gh [16:22:38 CEST] <Chloe> ugh* I cant upload samples because they're 500kb too big [16:30:47 CEST] <philipl> BtbN: yes, that was the other approach. [16:31:40 CEST] <philipl> i don't know if you noticed but there is c++ code in their cuviddec.h that isn't ifdef guarded properly. that was the 'leak' [17:07:09 CEST] <BtbN> philipl, ah. I think I just removed that. [17:07:18 CEST] <BtbN> all the C++ stuff [17:07:29 CEST] <BtbN> and some other invalid stuff, like cuvidInit [17:07:51 CEST] <philipl> Heh. [17:08:21 CEST] <philipl> Anyway, yours looks fine - although I'd personally do the headers as a single rename change to preserve a bit more history [17:10:25 CEST] <BtbN> I wanted to make sure every single commit compiles and works. [17:10:36 CEST] <BtbN> that's why it ended up in this order [17:10:47 CEST] <philipl> fair enough [17:11:09 CEST] <BtbN> you can get the history faily easy by calling log on the compat/cuda dir. [17:15:00 CEST] <philipl> true, true. [17:28:46 CEST] <cone-901> ffmpeg 03Philip Langdale 07master:e5bbedff826d: ChangeLog: Add latest CUVID changes [19:57:54 CEST] <cone-901> ffmpeg 03Burt P 07master:de9b23ac1f9d: af_hdcd: add mono as a supported channel layout [19:57:55 CEST] <cone-901> ffmpeg 03Burt P 07master:7e46bb80efa4: af_hdcd: allow all HDCD sample rates [19:57:56 CEST] <cone-901> ffmpeg 03Burt P 07master:80d89c19601f: af_hdcd: support s16p (WavPack) directly [19:57:57 CEST] <cone-901> ffmpeg 03Burt P 07master:4f94f0141468: af_hdcd: hdcd_scan() and hdcd_integrate() handle stereo and single channel [19:57:58 CEST] <cone-901> ffmpeg 03Burt P 07master:f51ddbf83cb7: af_hdcd: add experimental 20 and 24-bit decoding support [19:57:59 CEST] <cone-901> ffmpeg 03Burt P 07master:2c3d93648768: af_hdcd: disable auto-convert by default [21:46:01 CEST] <stephenwithav> how do I build graph2dot from the source code? (I'm using https://hub.docker.com/r/nachochip/ffmpeg-build/~/dockerfile/ as the base for my build.) [22:44:46 CEST] <philipl> BtbN: I got my crazy thing working. Also, I don't need to introduce a new hwcontext - just a new pix_fmt [22:45:04 CEST] <BtbN> just [22:45:13 CEST] <philipl> heh [22:45:18 CEST] <philipl> It doesn't look terrible. [22:45:32 CEST] <philipl> mostly because I'm not bothering to provide a frame pool implementation [22:45:36 CEST] <philipl> caller must provide it. [22:46:31 CEST] <philipl> One annoyance is I need an extra hwaccel declaration as those only support one pix_fmt [23:01:44 CEST] <nevcairiel> didnt you quit working on that hours ago =p [23:04:12 CEST] <philipl> I did, but then I got inspired again. [23:04:15 CEST] <philipl> And it works now. [23:13:45 CEST] <JEEB> 34 [23:23:57 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commits/cuvid [23:24:00 CEST] <philipl> hopefully acceptable. [23:24:24 CEST] <nevcairiel> adding yet another pixfmt for something you called 2% performance seems still rather pointless [23:24:53 CEST] <philipl> If we had the luxury of breaking compatibility, I'd say we should use just arrays all the time, but we don't have that luxury. [23:25:22 CEST] <philipl> You can argue that without my save-a-copy motivations. [23:25:29 CEST] <BtbN> I'm not a fan of another pix_fmt at all. Did you actually measure if it's faster at all? [23:25:50 CEST] <BtbN> Specially for presentation, where you are not memory bandwidth bound, it seems quite pointless [23:26:17 CEST] <nevcairiel> if its a on-gpu copy its not even bandwidth [23:26:25 CEST] <BtbN> It is, VRAM bandwidth [23:26:32 CEST] <BtbN> Not PCIe though [23:26:46 CEST] <nevcairiel> you have plenty of those when doing video processing [23:27:02 CEST] <BtbN> I'd guess you can copy frames around in-VRAM at several thousand frames per second, even for 4K stuff [23:27:32 CEST] <BtbN> So avoiding a copy there should not bring any noticable performance gains [23:30:02 CEST] <philipl> There's a CPU utilization improvement in my eyeballing-top testing. [23:30:36 CEST] <philipl> 20%->17% in one example. [23:32:35 CEST] <philipl> If you guys think it can't justify a new pixfmt, that's fine. I largely did it to prove it could be done. [23:33:48 CEST] <nevcairiel> doesnt seem worth it to me for the all the noise it causes, and near-duplicates in the API [23:37:49 CEST] <BtbN> reduced _cpu_ usage? [23:38:02 CEST] <philipl> yes. [23:44:55 CEST] <cone-136> ffmpeg 03Florian Diemer 07master:db4c1bee9620: avformat/riffenc: added possibility to set first to ninth audio language for RIFF taged files (e.g. avi files) [23:44:55 CEST] <cone-136> ffmpeg 03Shivraj Patil 07master:c1cc13cd2a9b: avutil/mips/generic_macros_msa: rename macro variable which causes segfault for mips r6 [00:00:00 CEST] --- Thu Oct 6 2016

1 0

ffmpeg.log.20161005
by burek 06 Oct '16

06 Oct '16

[00:30:03 CEST] <ozette> furq: thanks for your -skip_frame nokey tip by the way, that really really helped, processing now takes about 1 minute to 7 minutes where it took 1.5 to 3 hours first [02:45:16 CEST] <stah0121> can anyone help me properly compile ffplay on its own ? [02:45:17 CEST] <stah0121> followed the compilation guide for ffmpeg and tried a handful of different things, but I still can't get the ffplay binary to be generated [02:46:27 CEST] <stah0121> everything else compiles just fine [02:53:45 CEST] <klaxa> stah0121: well what kind of errors are you getting? [02:53:50 CEST] <klaxa> and what have you tried [02:54:08 CEST] <klaxa> if necessary (it will be) use pastebin to paste large chunks of text [02:55:08 CEST] <stah0121> I'm currently doing 'gcc ffplay.c -o ffplay' [02:55:19 CEST] <klaxa> oh [02:55:35 CEST] <klaxa> you should maybe use the build system? [02:55:53 CEST] <stah0121> I've googled for instructions and haven't come up with anything, so I went basic haha [02:56:44 CEST] <stah0121> I've tried a ton of variations for the configure script and subsequent make commands but haven't been able to get ffplay to come out of it [02:56:52 CEST] <klaxa> huh [02:56:57 CEST] <klaxa> it's built by default though [02:57:22 CEST] <stah0121> I know, I can see in the makefile its part of the core binaries [02:57:30 CEST] <stah0121> so I'm pretty stumpted [02:57:40 CEST] <klaxa> if you *only* want ffplay (and especially care that ffmpeg, ffprobe and ffserver are not built) you can use the --disable-ff<component> flags [02:58:01 CEST] <stah0121> $ ls ~/bin/ [02:58:02 CEST] <stah0121> ffmpeg ffprobe ffserver [02:58:02 CEST] <stah0121> [xxx@xxx ffmpeg]$ [02:58:03 CEST] <klaxa> but that won't make ffplay magically appear out of thin air [02:58:24 CEST] <klaxa> you set the path for configure and ran make install? [02:58:53 CEST] <stah0121> yep. the compilation guide is pretty solid. I just followed the steps on there [02:59:31 CEST] <stah0121> if I have everything else built, I should be able to compile ffplay by itself, but I'm thinking the commands for compile aren't exactly intuitive [03:00:26 CEST] <klaxa> hmm [03:00:54 CEST] <klaxa> can you pastebin your config.log? [03:01:26 CEST] <stah0121> sure .. give me a couple min (never used pastebin before and food almost ready :) ) [03:03:14 CEST] <stah0121> hm, weird [03:03:55 CEST] <stah0121> so I tried to git-clone the repo and only did a couple of the steps in the install guide in a custom directory .. and that attempt created a config.log .. but when I followed the compile guide to the letter, it didn't generate a config.log [03:04:15 CEST] <stah0121> the config.log file I do have is about 12,000 lines long, so I'll just look for a few relevant sections and pastebin that [03:08:31 CEST] <stah0121> okay I think this should work -- http://pastebin.com/vf6E3Ndb [03:09:14 CEST] <klaxa> well what the hell it already says ffplay in there [03:09:36 CEST] <klaxa> oh, you also only copied the lowest part, well it's exactly the one i was interested in [03:09:58 CEST] <stah0121> hah nice [03:10:21 CEST] <stah0121> but yeah, very strange stuff. [03:10:38 CEST] <klaxa> what happens if you run make again? [03:11:40 CEST] <stah0121> make: Nothing to be done for `all'. [03:12:00 CEST] <klaxa> are you in the correct directory? [03:12:08 CEST] <klaxa> one sec [03:13:06 CEST] <DHE> if you want ffplay, you'll need the SDL devel package installed [03:13:47 CEST] <stah0121> okay wtf .. the custom git-clone directory lets me run 'make' manually and says 'nothing to be done' ... the ~/ffmpeg_sources directory doesn't even let me 'make [03:14:39 CEST] <klaxa> DHE: but would that be recognized at ./configure time? [03:14:46 CEST] <klaxa> and ffplay would not be built [03:15:24 CEST] <klaxa> huh, it gets built on my server [03:15:25 CEST] <DHE> that's configure's job - see what is (and isn't) available on the system and build only what would succeed [03:15:48 CEST] <stah0121> so this is the package that I installed per the compilation guide -- 'libsdl1.2-dev' [03:15:53 CEST] <stah0121> that should be the dev right ? [03:15:57 CEST] <DHE> looks right [03:17:09 CEST] <stah0121> I'm on ubuntu 14.04 LTS btw [03:18:48 CEST] <stah0121> be back in a min [03:24:07 CEST] <stah0121> back [03:29:05 CEST] <stah0121> this is the compile guide I'm using -- https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [03:30:04 CEST] <DHE> do you have a program called sdl-config installed? [03:30:25 CEST] <stah0121> ]$ which sdl-config [03:31:12 CEST] <stah0121> '/usr/bin/sdl-config' [03:31:18 CEST] <stah0121> ^^ that's the path it generated [03:31:36 CEST] <klaxa> is there an ffplay in ~/ffmpeg_build/ ? [03:31:52 CEST] <klaxa> wait [03:31:55 CEST] <klaxa> that wouldn't make sense [03:32:25 CEST] <stah0121> just did a search from root, only ffplay files are the .c files and the .texi files [03:35:56 CEST] <klaxa> well make doesn't really log, does it? [03:36:14 CEST] <stah0121> I don't think so [03:36:18 CEST] <stah0121> if it does, probably not by default [03:37:53 CEST] <stah0121> does this mean anything to anyone ? [03:37:55 CEST] <stah0121> ]$ cat config.mak | grep -i "ffplay*" [03:37:55 CEST] <stah0121> CFLAGS-ffplay= [03:37:55 CEST] <stah0121> LIBS-ffplay= [03:37:55 CEST] <stah0121> !CONFIG_FFPLAY=yes [03:38:15 CEST] <stah0121> do I need to add a CFLAGS-ffplay flag or something ? [03:43:04 CEST] <DHE> can you pastebin the whole damned config.log ? [03:43:51 CEST] <stah0121> sure [03:47:27 CEST] <stah0121> http://pastebin.com/CsZsiHev [03:49:20 CEST] <DHE> it's looking for SDL 2.0, not 1.2 [03:53:39 CEST] <stah0121> hm, yeah that's probably a problem [04:00:19 CEST] <stah0121> installed SDL 2 dev package and recompiling now [04:15:45 CEST] <stah0121> well that fixed it [04:16:06 CEST] <stah0121> thanks DHE, much appreciated [04:28:55 CEST] <moneylotion> anyone have a bitrate or rf recommendation for blueray rip? [05:32:03 CEST] <radia> Does anyone know if there is a special command in ffmpeg that calculates all that is necessary to make a webm so it will be in good quality based on the .mp4 [05:47:02 CEST] <strongcoffee> radia, CRF mode using VP9 will do that. [07:01:23 CEST] <teratorn> hi all, I'm trying to pull out the 100th frame of a testsrc2 video stream, and duplicate this frame at 30fps for 5 seconds... this is what I have so far (not working, only makes a video with one frame in it): ffmpeg -f lavfi -i testsrc -filter_complex "[0:v]trim=start_frame=100:end_frame=101[v0];[v0]fps=fps=30[v1];[v1]trim=duration=5[v2]" -map "[v2]" test_out.mp4 [07:02:32 CEST] <teratorn> this cmd, actually: ffmpeg -f lavfi -i testsrc2 -filter_complex "[0:v]trim=start_frame=100:end_frame=101[v0];[v0]fps=fps=30[v1];[v1]trim=duration=5[v2]" -map "[v2]" out.mp4 [07:03:27 CEST] <teratorn> any clues? :) [08:29:21 CEST] <c_14> teratorn: you'll probably want the loop filter in there somewhere [08:30:17 CEST] <teratorn> c_14: thanks, I was thinking I needed to investigate that one already, so now I will :) [08:32:37 CEST] <c_14> Either after, or in place of the fps filter [08:32:45 CEST] <c_14> Also, you don't need separate filterchains for that [08:32:56 CEST] <c_14> you can just queue the filters by separating them with commas [08:38:38 CEST] <teratorn> c_14: riiight [08:39:02 CEST] <c_14> ie trim=start_frame:end_frame,fps,loop,trim [08:43:51 CEST] <teratorn> c_14: then I concat that to the end or the orignal stream? [08:44:00 CEST] <teratorn> to produce the pause effect? [08:44:10 CEST] <teratorn> s/or/of/ [08:44:27 CEST] <c_14> hmm? [08:44:37 CEST] <c_14> What are you trying to accomplish? [08:44:51 CEST] <teratorn> extend the duration of a video by fabricating copies of the last frame at 30fps for 5 seconds [08:45:46 CEST] <teratorn> oh wait [08:45:51 CEST] <teratorn> just the damn loop filter can do it... [08:45:58 CEST] <c_14> I think you could just use -vf fps=30,loop=150:start=100 [08:46:36 CEST] <teratorn> why start=100 ? [08:47:11 CEST] <c_14> Because the 100th frame is the frame you want looped, no? [08:48:00 CEST] <teratorn> oh, well no, the last frame, but i already calculate what number it is elsewhere, so I got it... [08:48:29 CEST] <kiwi_banal> On OX_X El Capitan is it possible with "ffmpeg -f avfoundation ..." to capture a particular window as with gdigrab on a Microsoft Windows system? [08:48:41 CEST] <kiwi_banal> err OS_X [08:48:58 CEST] <teratorn> which could also be accomplished by duplicating the last frame once and adding 5 seconds to it's pts, I guess [08:50:05 CEST] <kiwi_banal> I'm looking to screencast say just a terminal window... without needing to maximise it to fullscreen [08:51:49 CEST] <teratorn> c_14: well it's sleep time, I'll tinker with this more tomorrow... thanks for your help, g'night [12:29:53 CEST] <szulak> Hello, I am looking for any information how could I merge two audio tracks in video file programatically. Could anyone share some info with me? [12:31:20 CEST] <bencoh> you'd have to define "merge" [12:32:27 CEST] <szulak> I have a track 0 which is a song, and track 1 which is a micro - I would like to "merge" it into one track, and when played - hear both of these [12:35:30 CEST] <Spring> szulak, do you mean have two separate audio tracks playing simultaneously or permanently combine the tracks? [12:35:56 CEST] <szulak> permanently combine the tracks [12:36:59 CEST] <Spring> this seems like what you're after: https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a2stereostereo [12:38:07 CEST] <Spring> the video stream would need to also be included in the mapping [12:38:35 CEST] <furq> you can just use amix [12:38:42 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#amix [12:38:51 CEST] <szulak> alright, but how about doing it programatically? (without calling ffmpeg binary) [12:39:17 CEST] <furq> https://ffmpeg.org/doxygen/trunk/filtering_audio_8c-example.html [12:40:29 CEST] <szulak> thank you, that's what I was looking for :) [13:04:12 CEST] <n4zarh> any1 knows how to encode raw pcm data (from android-phone speaker) to pcm-mulaw frame by frame? [13:07:09 CEST] <nonex86> n4zarh: check /doc/examples/transcode_aac.c [13:07:22 CEST] <nonex86> n4zarh: its good place for start [13:12:49 CEST] <n4zarh> yeah, but my problem seems to start with line: (*frame)->nb_samples = frame_size; [13:13:16 CEST] <n4zarh> since as far as I understand alaw and mulaw codec contexts have frame_size==0 [13:17:00 CEST] <n4zarh> and I just don't know where to find value for nb_samples for those two encoders [13:24:50 CEST] <nonex86> n4zarh: on initialized alaw/mulaw encode, what is the value of AvCodecContext->frame_size? [13:25:05 CEST] <nonex86> n4zarh: are you sure its zero? [13:25:47 CEST] <n4zarh> codec inited: pcm_mulaw [13:25:47 CEST] <n4zarh> channels 1, framesize 0, samplefmt 1, buffersize -22 [13:25:56 CEST] <n4zarh> its from logcat [13:26:47 CEST] <n4zarh> don't mind buffersize, tried to use av_samples_get_buffer_size from decoding_encoding.c example, I guess it won't be needed (might be wrong) [13:29:18 CEST] <n4zarh> I read somewhere in documentation that frame_size might be 0 if codec has flag set with variable frame size [13:29:50 CEST] <nonex86> n4zarh: http://stackoverflow.com/questions/37134003/ffmpeg-encoding-pcm-16-audio-da… [13:31:01 CEST] <n4zarh> oh. [13:31:09 CEST] <nonex86> :) [13:33:54 CEST] <n4zarh> so, if I get it right, if I get 640B frame as input, I should pass 640 to nb_samples? [13:34:16 CEST] <n4zarh> sorry for asking stupid questions, I never needed stuff like this before [13:37:18 CEST] <nonex86> n4zarch: guess it depends on number of channels and sample format, isnt it? :) [13:52:50 CEST] <trfl> say you've got an h264 video with a keyframe every 10sec and you're seeking to somewhere in the middle of two keyframes... is it possible to create a .ts file or an rtmp stream which would instruct clients to skip the first 5sec when decoding? [14:09:07 CEST] <furq> trfl: the output will start on a keyframe regardless [14:12:16 CEST] <kepstin> trfl: with an rtmp stream, you could theoretically make a custom flash player that doesn't display the first part of the stream, maybe [14:22:05 CEST] <CodecDev> Hi, Need quick help on ffmpeg hang issue on specific scenario on windows machine. [14:23:01 CEST] <CodecDev> I am running multiple instance of ffmepg transcode in parallel on windows. Out of 5 instance 1-2 are getting hung in the middle of transcoding. And they will never resume back. [14:23:36 CEST] <CodecDev> my source is 4k 10Mbps and target bitrates are 800, 1600, 2500, 3500, 5000. [14:23:52 CEST] <CodecDev> has anyone seen similar behaviour before? [14:24:39 CEST] <furq> no, but you should probably be doing all that with one ffmpeg instance so you don't have to decode a 4k stream five times [14:25:16 CEST] <furq> particularly if the source is hevc [14:25:29 CEST] <CodecDev> Yes thats true, but 800k stream has wait untill 5000k stream transcode completes. [14:25:50 CEST] <furq> how are you running multiple instances in parallel then [14:26:25 CEST] <CodecDev> But interesting thing If I make multiple copies of ffmpeg and use different binary for each command it never hangs !!! [14:27:19 CEST] <CodecDev> I am suspecting, there could be some shared resouce, which is leading to deadlock among multiple instace of same ffmpeg binary ?? Please correct me If I sound wrong here. [14:29:46 CEST] <CodecDev> I am running one command for each output bitrate. 1 in 1 out transcode. [14:31:08 CEST] <nonex86> when you said "hangs" what do you mean? [14:32:01 CEST] <nonex86> never used several instances of ffmpeg cli on windows, but i heavily using ffmpeg for decoding multiple streams in my software on windows without any problem [14:32:20 CEST] <nonex86> lets say its about 16 fullhd h264 streams [14:32:27 CEST] <CodecDev> here are my complete commands: http://pastebin.com/mwCweJdq [14:32:34 CEST] <furq> i still don't understand why you need to run one command per stream [14:32:51 CEST] <nonex86> i doubt ffmpeg have any global shared kernel objects that may lead to deadlock or something [14:33:00 CEST] <nonex86> this makes no sense [14:33:17 CEST] <nonex86> deadlock between the processes i mean [14:33:41 CEST] <nonex86> what do you mean by saying "hangs"? [14:33:48 CEST] <CodecDev> what I mean by "hangs" is, ffmpeg indefinitely waits.. cpu usage 0%/ [14:34:00 CEST] <nonex86> you can try to find out exact place [14:34:05 CEST] <nonex86> where it hangs [14:34:10 CEST] <nonex86> download process explorer [14:34:20 CEST] <nonex86> and check call stack of the "hanged" process [14:35:02 CEST] <nonex86> on thread tab [14:35:28 CEST] <CodecDev> these ffmpeg build dont have symbols.. downloaded from https://ffmpeg.zeranoe.com/builds/ [14:35:55 CEST] <nonex86> can you build it yourself with symbols enabled? [14:36:05 CEST] <CodecDev> I can try that. [14:36:41 CEST] <CodecDev> But as I mentioned earlier, when I make different copy of ffmpeg and use one copy for each commands, I will not see this hang behaviour. [14:37:17 CEST] <nonex86> i have my build of ffmpeg 3.0 with libx264 compiled with ms vc from visual studio 2013 [14:37:22 CEST] <CodecDev> if I use same ffmpeg binary for all 5 commands then only this issue in happening. [14:37:32 CEST] <nonex86> really strange, yes [14:37:52 CEST] <CodecDev> can u share that build ? [14:37:54 CEST] <furq> if this is for streaming then don't use nal-hrd [14:37:57 CEST] <furq> it's just a waste of bits [14:37:58 CEST] <nonex86> so if you cant build it yourself i can share with you [14:38:01 CEST] <CodecDev> I can quickly try using that. [14:38:04 CEST] <furq> nal-hrd cbr, that is [14:38:11 CEST] <nonex86> sure [14:39:02 CEST] <CodecDev> thank you furq. I will follow that. [14:46:10 CEST] <trfl> alright thanks furq, kepstin - good to know it's essentially not possible :) [14:47:07 CEST] <furq> i mean it might be possible, but afaik the ffmpeg cli won't let you start a cut on a non-keyframe [14:47:20 CEST] <furq> it'll just seek to the nearest [14:49:09 CEST] <furq> i'm pretty sure most players will discard everything before the first IDR frame in a stream anyway [14:50:29 CEST] <nonex86> vlc is not :) [14:50:39 CEST] <furq> most good players, then [14:51:22 CEST] <nonex86> good remark ;) [14:51:36 CEST] <CodecDev> Just wondering without IDR how VLC is able to understand stream characteristics?? [14:52:00 CEST] <nonex86> h264? sps+pps from codec_private field [14:52:10 CEST] <nonex86> you dont need idr for this [14:52:12 CEST] <furq> it's not that good. most of one player probably wouldn't work at all [14:52:23 CEST] <nonex86> you can just take extra_data [14:52:27 CEST] <nonex86> extract sps/pps [14:52:36 CEST] <nonex86> and got your stream properties [15:06:47 CEST] <geeky> what is the command to convert .avi to .mpg files that will work on a dvd video player [15:07:48 CEST] <geeky> ffmpeg -i 1.avi 1.mpg generates a file that doesn't play [15:14:48 CEST] <CodecDev> are u able to play 1.mpg on vlc? [15:18:58 CEST] <relaxed> CodecDev: something like, ffmpeg -i input -target ntsc-dvd -q:v 3 output.mpg [15:27:52 CEST] <geeky> CodecDev: yes [15:28:04 CEST] <geeky> relaxed: ok thanks [16:55:08 CEST] <szulak> I have a simple question about licensing - I've FFmpeg binaries (built as "--enable-version3" aka LGPL 3) - can I distribute this shared binary (single ffmpeg.exe) file with my application and call from my application? [16:55:53 CEST] <szulak> I am not linking my application with FFmpeg libraries - instead just calling it's binary to perform some work on video file [16:56:46 CEST] <furq> szulak: https://www.ffmpeg.org/legal.html [16:57:06 CEST] <furq> it's debatable whether you need to do that if you're calling the binary, but it's best to be on the safe side [16:57:15 CEST] <szulak> "The following is a checklist for LGPL compliance when linking against the FFmpeg libraries." [16:57:28 CEST] <szulak> but I am not linking with FFmpeg, that's why I am confused :( [16:57:48 CEST] <furq> the same thing applies [17:01:56 CEST] <hawken> Hi.. I'm having issues with getting this bug handled... [17:02:00 CEST] <hawken> https://trac.ffmpeg.org/ticket/5472#comment:12%3E [17:02:29 CEST] <hawken> Apparently he wants the output file, but he doesn't want output files [17:03:07 CEST] <hawken> And my example isn't okay for him. He wants the original bug reporter [17:03:30 CEST] <hawken> I should open a dupe bug so he has to accept it.. [17:04:04 CEST] <hawken> oh wait, then it will be a dupe. so, closed. [17:04:21 CEST] <hawken> I'm really stuck between two chairs here [17:04:51 CEST] <furq> i am glad i've never had dealings with carl-eugen hoyos [17:10:02 CEST] <hawken> I don't want to get emotional about this but oh man... [17:44:58 CEST] <Spring> would I be correct in saying that ffmpeg obeys the encoding quality in the following order: 1. qmin/qmax, 2. max bitrate cap, 3. CRF ? [17:46:08 CEST] <Spring> as it seemed that way when encoding with libvpx, since qmax would override both CRF and any max bitrate cap. While the max bitrate would override CRF. [17:46:25 CEST] <furq> i imagine it depends on the codec [17:47:08 CEST] <Spring> any idea if h.264 behaves similarly? [17:47:25 CEST] <Spring> haven't done any tests with it using qmax to know [17:48:13 CEST] <Spring> in fact I left it out entirely since it does a good enough job without it [17:50:30 CEST] <kepstin> Spring: libx264 encoder uses crf, but max bitrate cap (implemented via vbv) can override the bitrate crf picks, then the -max-crf option can override that, and you should basically not ever set qmin/qmax. [17:50:53 CEST] <furq> looks like crf takes precedence with libx264 [17:51:00 CEST] <furq> over -b and -q [17:51:24 CEST] <kepstin> (any stuff you see saying to set qmin/qmax with libvpx is probably referring to old versions of libvpx/ffmpeg where the default qmin/qmax values were poorly chosen) [17:52:42 CEST] <Spring> furq, -b and -q being the quantization options? [17:52:53 CEST] <furq> b is bitrate [17:53:13 CEST] <kepstin> I'm not even sure what -q maps to with libx264; the way to do constant quantizer is with -qp. [17:53:17 CEST] <furq> actually it looks like -q is ignored [17:53:32 CEST] <kepstin> (imo, -q should have been mapped to crf with libx264...) [17:54:09 CEST] <furq> i can imagine people would think it mapped to -qp though [17:54:17 CEST] <furq> i can imagine that because one of those people was me, just now [17:54:52 CEST] <Spring> In my case I'm capping the CRF bitrate using -maxrate + bufsize, which works. I should try some tests later with qp or whichever it is. [17:55:00 CEST] <kepstin> Spring: using -crf, -b (bitrate) and -qp are three mutually exclusive ways to select the bitrate control algorithm x264 uses. [17:55:53 CEST] <furq> don't use qp for that [17:56:17 CEST] <kepstin> you can't use any bitrate controls with -qp, since qp enables constant quantizer mode [17:56:40 CEST] <kepstin> the -qp option is mostly useful if either you want to use lossless mode, or you already know why you'd want to use it. [17:56:44 CEST] <Spring> so it's an entirely different mode in lib264 then [17:58:16 CEST] <kepstin> there's basically 3 modes in x264 - crf mode (constant quality), average bitrate target (set with -b:v), and constant quantizer [17:58:25 CEST] <kepstin> and you can use vbv stuff with crf mode and abr mode. [17:59:38 CEST] <Spring> for libvpx I've found it benefits from defining qmax, even with the latest versions [18:00:50 CEST] <Spring> thanks for the detailed explanations of lib264 [18:01:32 CEST] <furq> libvpx's rate control is pretty bad [18:01:44 CEST] <furq> i still wouldn't expect qmin/qmax to do anything but who knows [18:28:51 CEST] <Spring> I also have in my notes that -ss and -to before -i can be wildly inaccurate. I think at that time I was testing libvpx exclusively so it's probably different for lib264. [18:29:40 CEST] <furq> no, that depends solely on the input format [18:29:58 CEST] <furq> and also whether you're stream copying [18:30:53 CEST] <Spring> I was always transcoding both video/audio. My sources were h.264 in MKVs, mostly. [18:31:23 CEST] <Spring> still, I've been told it's frame accurate placing it after -i as it's processed on the decoding level. [18:32:31 CEST] <klaxa> yes, see: https://trac.ffmpeg.org/wiki/Seeking [18:33:03 CEST] <klaxa> you can even combine -ss before and after -i to skip in the demuxer first and then in the decoder [18:34:10 CEST] <Spring> that last bit flew over my head. So it can be beneficial duplicating the -ss both before/after -i? [18:34:51 CEST] <klaxa> yes, see the page i posted, it explains it pretty well i think [18:35:13 CEST] <klaxa> oh actually, let me read that again [18:35:46 CEST] <c_14> It better, took me enough effort to update. [18:36:37 CEST] <Spring> I see how it works, you need two different -ss values, one to get there fast the other for accuracy (if I'm understanding it correctly) [18:36:43 CEST] <klaxa> when transcoding you can just use -ss in front of -i and it does what i explained but with only one command (since 2.1) [18:37:02 CEST] <klaxa> >As of FFmpeg 2.1, combined seeking is still possible but I have yet to find a valid use case for it since -ss as an input option is now both fast and accurate. [18:37:25 CEST] <Spring> mmm, I'll stick with the -ss after -i method. Seems fast to me anyway. [21:43:00 CEST] <stephenwithav> how do I build graph2dot from the source code? (I'm using https://hub.docker.com/r/nachochip/ffmpeg-build/~/dockerfile/ to build.) [22:02:46 CEST] <thebigbean> I got some old PAL video 720x576 from 1990 with that should be 4:3. The pixels are not square and it is messing up image stabilizing. Is there a good way to resample the video to use square pixels? [22:03:07 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar [22:04:27 CEST] <thebigbean> thx furq but I did try -vf setdar=4:3 thing is that the headers dont get passed right and it becomes 5:4 [22:04:57 CEST] <furq> you probably want setsar [22:05:38 CEST] <thebigbean> what is the sar for PAL that is from the 1990s. [22:06:02 CEST] <furq> probably 12:11 [22:07:16 CEST] <thebigbean> Is there any way to test what the sar should be? [22:07:18 CEST] <furq> either use setdar=15/11 or setsar=1,setdar=4:3 [22:07:29 CEST] <furq> or 4/3, either works [22:11:15 CEST] <thebigbean> So you saying I should set both sar and dar like -vf setsar=1,setdar=4:3 ? [22:11:29 CEST] <furq> if you want square pixels, sure [22:11:36 CEST] <furq> i normally just use setdar [22:12:44 CEST] <thebigbean> I do want square pixels. Reason is the VirtualDubs Deshaker is good but it really hates pixels that are not square. The rotation gets weird and jelly like. [22:13:11 CEST] <furq> ffmpeg has a deshake filter [22:13:14 CEST] <furq> i've not used it though [22:13:43 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#vidstabdetect-1 [22:14:16 CEST] <thebigbean> its ok-ish but sadly VirtualDubs Deshaker is freaking good. I have 150+- frames in my temporal image restoring for the edges etc [22:14:21 CEST] <furq> fair enough [22:58:06 CEST] <stephenwithav> is there a better source for learning about filters than that documentation? [23:10:09 CEST] <llogan> stephenwithav: not really. there are some articles on the wiki. [23:10:28 CEST] <llogan> but i'm not surwe what you mean by "better" [23:11:27 CEST] <llogan> as for graph2dot: make tools/graph2dot [23:11:42 CEST] <llogan> i guess [23:18:33 CEST] <stephenwithav> thanks. make alltools worked [23:20:06 CEST] <stephenwithav> by better, that's hard to quantify. reading through the wiki now. more examples with pictures of the results would be nice. [23:21:44 CEST] <BtbN> well, reading the source is a better source. [23:24:06 CEST] <stephenwithav> agreed. I'm trying to understand the overlay filter with multiple inputs, how it works. once I figure that out, I think I'll be okay. [23:31:15 CEST] <llogan> overlay accepts two inputs and outputs one output. if you need more you can do something like: [0:v][1:v]overlay[bg];[bg][2:v]overlay [00:00:00 CEST] --- Thu Oct 6 2016

1 0

ffmpeg-devel.log.20161004
by burek 05 Oct '16

05 Oct '16

[00:31:44 CEST] <Compn> i've moderated that mmx guy btw [00:31:47 CEST] <Compn> llogan ^^ [00:32:11 CEST] <Compn> if he has a patch, ok. otherwise he needs to move to ffmpeg-user [00:32:33 CEST] <Compn> our developers are too easily distracted by other software projects to deal with bugreports :D [00:33:00 CEST] <Compn> so we need to keep em seperated to ensure more work on ffmpeg and less 'your software sucks' 'nuh uh' type threads [00:34:16 CEST] <Compn> guess i should send him a mail... no one likes silent moderation [00:43:47 CEST] <cone-172> ffmpeg 03Steven Liu 07master:be1d32492e58: avformat/hlsenc: support multi level path in m3u8 with filename [00:51:56 CEST] <Chloe> Compn: aha, I think there were actually a few other devs looking into fixing musl as well. [00:52:20 CEST] <Chloe> well, 'fixing'. [00:56:24 CEST] <Compn> i talked to dalias (musl creator) , he said it was ffmpeg bug [00:56:37 CEST] <llogan> Compn: i wasn't really following that discussion. you moderated the aetey.se guy? [00:56:47 CEST] <Compn> there might be something that can be done in musl to make it fail better, but ... [00:56:48 CEST] <Compn> llogan : ya [00:57:00 CEST] <llogan> did you simply set the mod flag on his account? [00:57:03 CEST] <Compn> yes [00:57:13 CEST] <Compn> is that what i should do ? [00:58:00 CEST] <Compn> Chloe : feel free to join #musl and learn through osmosis :P [00:58:10 CEST] <llogan> Compn: sure, if you think there is sufficient reason to do so and if you are willing to moderate each message from him in the queue [00:58:33 CEST] <Compn> posting off topic on devel list, yep [00:58:50 CEST] <Chloe> Compn: I know it's an ffmpeg bug. It's even in the sysv spec. [00:58:53 CEST] <Chloe> and I'm already in #musl [00:58:56 CEST] <Compn> :) [00:59:12 CEST] <Chloe> their bin_index function is funky, now that I actually understand it [00:59:37 CEST] <Compn> submit patch if you want :P [00:59:53 CEST] <Chloe> (not that I can think of a better way to do it) [01:03:44 CEST] <Compn> entirely too much time spent on this already :E [01:03:45 CEST] <Compn> ehe [01:04:22 CEST] <Compn> we might need to scan the rest of the codebase for similar spec violations [01:04:33 CEST] <Compn> i wonder if we could script it or what we would need to do. [01:04:54 CEST] <Compn> Chloe : any ideas? [01:05:17 CEST] <Compn> where there is one bug... there are duplicate bugs :D [01:05:48 CEST] <Chloe> we could make sure the standard library uses floats in every function [01:05:51 CEST] <Chloe> and then run fate [01:06:18 CEST] <Chloe> that's just one violation though, but it'd cover it across the codebase [01:06:20 CEST] <Compn> hmmmmmm sounds like a plan [01:06:35 CEST] <Compn> or just run fate with musl [01:06:50 CEST] <Chloe> but not every musl standard library function uses floats [01:06:55 CEST] <Compn> ah [01:07:14 CEST] <Chloe> this was you'd be able to check everywhere, but then again idk the benefit of that [01:07:17 CEST] <Chloe> way* [01:08:58 CEST] <Chloe> (I don't seriously suggest doing this, it sounds like more effort than it's worth) [01:11:48 CEST] <iive> Compn: the thing is that musl is using a lame hack [01:12:13 CEST] <atomnuker> rcombs: PCE patch for the aac encoder's on the ML, which layouts do you need support for? [01:12:33 CEST] <iive> it might be clever, but it is quite hard to figure out what it does and on top of that - it is probably a lot slower than doing an naive implementation. [01:12:49 CEST] <Chloe> iive: the offer to replace it with something faster is there [01:13:06 CEST] <iive> Chloe: i didn't see the patch. [01:13:45 CEST] <Chloe> iive: I mean, the musl people said they would replace it if someone write something faster [01:13:51 CEST] <Chloe> wrote* [01:14:03 CEST] <rcombs> atomnuker: BD-style 7.1, primarily [01:14:36 CEST] <atomnuker> what's different in the bd 7.1? [01:14:50 CEST] <iive> Chloe: i think there is gcc built-in that actually turns into single asm op on 686+ [01:14:51 CEST] <Compn> rcombs : do you have the bd 7.1 spec for atomnuker to map ? [01:15:24 CEST] <Chloe> iive: I dont think that function does what you think it does [01:15:58 CEST] <rcombs> atomnuker: AV_CH_LAYOUT_7POINT1 vs AV_CH_LAYOUT_7POINT1_WIDE_BACK [01:17:39 CEST] <atomnuker> oh, ok [01:18:50 CEST] <iive> Chloe: log2? Nicolas mentions that. And there is asm op that returns the location of first bit or something.... [01:19:37 CEST] <rcombs> atomnuker: also, would be nice to distinguish between 5POINT1 and 5POINT1_BACK [01:19:39 CEST] <Chloe> iive: it's similar to a log2. It's actually a log2()*4 where it's linear in-between the powers of two [01:26:05 CEST] <iive> yeh, that would need like 2 more asm ops [01:32:38 CEST] <microchip_> rcombs: is BD 7.1 wide_back ? [01:32:53 CEST] <rcombs> no, AAC's native 7.1 layout is [01:32:59 CEST] <microchip_> oh ic [01:33:09 CEST] <rcombs> for ~some reason~ [01:33:35 CEST] <rcombs> though some decoders treat the AAC layout like regular 7.1 because nobody actually uses wide_back [01:33:55 CEST] <rcombs> so if you want reliable wide_back you need PCE and if you want reliable regular 7.1 you need PCE [01:34:11 CEST] <rcombs> if you use the native layout, it depends what the decoder's assumptions are [01:40:48 CEST] <JEEB> oh yes, the case of 7.1 AAC [01:40:54 CEST] <JEEB> always the fun one [01:44:43 CEST] <atomnuker> I don't think PCEs can help you here [01:45:21 CEST] <atomnuker> or wait, maybe they can [01:45:39 CEST] <atomnuker> if the wide channels are still considered back channels [01:46:14 CEST] <atomnuker> so if you have "LB WLB CB WRB RB" in the back row and you signal 2 CPEs and once SCE [01:46:36 CEST] <atomnuker> but the thing is the decoder will still have to somehow map that arrangement to wide back [01:46:59 CEST] <atomnuker> so really, nothing's changed in terms of the decoder having to guess [02:06:06 CEST] <Chloe> if anyone wants to optimise a non-float bin_index, http://sprunge.us/MTAJ [02:06:42 CEST] <Chloe> oops missing the macro, http://sprunge.us/EgQM [02:42:55 CEST] <rcombs> is upload.ffmpeg.org down? [02:44:02 CEST] <rcombs> I'd like to get https://puu.sh/rsOdK/e9eca8a945.ts placed somewhere less ephemeral; filename could be e.g. "long-incorrect-duration.ts" [05:21:27 CEST] <Compn> rcombs : yes down. waiting on j-b [05:34:39 CEST] <rcombs> thanks [08:17:33 CEST] <rcombs> michaelni: do you have that file you mentioned in https://patchwork.ffmpeg.org/patch/507/? [08:18:55 CEST] <cone-296> ffmpeg 03Rodger Combs 07master:63fbeebf6ecb: configure: add linker export script support on Darwin [08:20:39 CEST] <cone-296> ffmpeg 03Rodger Combs 07master:14fe54bbfb98: lavf/mpegtsenc: fix autobsf when the first NAL is 0x1<XX> bytes [08:25:42 CEST] <rcombs> ubitux: re: https://patchwork.ffmpeg.org/patch/524/ , ASS text between {}s that doesn't match a tag is treated as a "comment" (not displayed), but { and everything after it is displayed normally if there's no matching } [08:25:52 CEST] <rcombs> so the test is wrong [08:27:43 CEST] <ubitux> but this is textenc from srt [08:28:08 CEST] <ubitux> if you have {foo} in a srt, you don't want to drop it [08:28:37 CEST] <ubitux> (especially not in a text export) [08:29:16 CEST] <rcombs> SubRip_capability_tester.srt is super wacky [08:29:27 CEST] <rcombs> it's got a bunch of ASS syntax that's clearly targeting libass or VSFilter [08:31:14 CEST] <ubitux> what happens to {{{ hello }}}? [08:31:21 CEST] <rcombs> I don't know what would display it as the text implies (with e.g. {foo} displayed) [08:31:26 CEST] <rcombs> ubitux: that would render as }} [08:31:58 CEST] <rcombs> there's no nesting [08:32:03 CEST] <rcombs> you can pull up Aegisub and try it [08:32:52 CEST] <rcombs> there's also no escaping mechanism, so there's no way to display e.g. "{}" in a single event without a custom font or fullwidth characters or rendering the characters out to vector drawings [08:33:00 CEST] <ubitux> OK so; do we really want to honor ASS comments in SRT? or do we prefer to honor random patterns by user (that also means following the specs) [08:33:22 CEST] <ubitux> that is, do you think there is more ppl using {foo} as a comment mechanism in srt, or as a fancy ascii styling [08:33:44 CEST] <rcombs> so, the question there is what renderer they're targeting [08:33:56 CEST] <ubitux> ah; you can't escape {}? [08:33:58 CEST] <rcombs> what do people use to display subtitles other than VSFilter and libass [08:34:08 CEST] <rcombs> (both of which have identical behavior around this) [08:34:19 CEST] <rcombs> (VSFilter came first and libass mimics it very carefully) [08:35:31 CEST] <rcombs> there are also MicroDVD-style tags in this, which VSFilter handles (i.e. the style they indicate is applied) but libass does not (neither executed nor displayed as text) [08:35:31 CEST] <JEEB> I still remember the stories of VSFilter coming to life [08:35:58 CEST] <JEEB> or actually I might only remember ASS, VSFilter might be even older [08:36:34 CEST] <rcombs> and then there are HTML-style tags, which are all well and good in SRT since the parser is expected to handle them, but if you put them in ASS then VSFilter will handle them (though I don't know what it does about unrecognized ones) and libass will display them as text [08:37:10 CEST] <JEEB> :D [08:37:22 CEST] <rcombs> ubitux: my point with that patch was that if you have {}-style comments in ASS and you convert to SRT, the comments should be dropped [08:38:47 CEST] <ubitux> yes i understand [08:38:49 CEST] <rcombs> it only affects SRT since we use ASS as an intermediate [08:39:01 CEST] <rcombs> (SRT input, that is) [08:39:58 CEST] <rcombs> maybe the intermediate should be an alternate form of ASS that has backslash escapes for \ and {}, which we drop on ASS output [08:40:19 CEST] <ubitux> yeah sure; i still think they should be displayed verbatim, as it's more likely to have them used that way [08:40:27 CEST] <ubitux> (IMO) [08:40:57 CEST] <rcombs> that would imply that there's a SRT renderer somewhere that handles {\an8} but also displays {foo} [08:41:19 CEST] <rcombs> or that the test sample has mutually incompatible expectations [08:41:42 CEST] <ubitux> i thought it was a good trade of [08:42:03 CEST] <ubitux> because writing "{\an8}" in a srt is very unlikely to mean something else than ass markup [08:42:17 CEST] <ubitux> but writing {foo} could really meant displaying it as such in a srt [08:42:34 CEST] <rcombs> so it's the latter (mutually incompatible expectations)? [08:42:49 CEST] <rcombs> (I guess that'd be pretty ~subtitles~) [08:42:51 CEST] <ubitux> we're punishing users writing valid srt here [08:43:17 CEST] <rcombs> SRT or whatever other input format that happens to have ASS-like markup [08:52:01 CEST] <rcombs> ubitux: so, seems like our best route is probably to add functions for handling input that "might contain ASS tags but also might contain {}s expected to be treated as plaintext", and convert that to a backslash-escaped internal form, and then handle the backslashes in ass_split [11:56:47 CEST] <jdskcn> compn: you there ? [12:18:00 CEST] <michaelni> rcombs, i think it was this: http://samples.ffmpeg.org/mov/c3226e01-83b5-49a2-4279-14ac6e9a9ac3 [13:06:39 CEST] <cone-587> ffmpeg 03Timo Rothenpieler 07master:5d4fea88d485: avcodec/cuvid: don't align frame size [13:09:06 CEST] <wm4> libavutil.pc has completely broken library deps if hwcontext impls are enabled [13:10:20 CEST] <BtbN> in what way broken? [13:14:29 CEST] <jkqxz> Yes, they are. [13:16:35 CEST] <jkqxz> There was resistance to the obvious fix (just change to "$extralibs"), so it stayed like that. [13:17:01 CEST] <BtbN> what exactly is broken in there? It looks fine to me. [13:18:04 CEST] <jkqxz> The package config files don't give you a dependency on libva*, libvdpau, etc. [13:19:02 CEST] <BtbN> hm [13:19:25 CEST] <jkqxz> ("$extralibs" includes everything, so it would make lavu depend on things like libx264, hence the resistance to that answer.) [13:28:35 CEST] <BtbN> Anyone happens to know where in ffmpeg*.c the InputStream framerate is set? [13:28:43 CEST] <BtbN> I can't find it anywhere, is it set at all? [13:33:26 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg_opt.c;hb=HEAD#l740> ? [13:33:53 CEST] <BtbN> hm, so the input stream framerate is completely unset unless parsed from cli [13:36:11 CEST] <BtbN> that even seems to work... [13:38:04 CEST] <ubitux> https://ispc.github.io/ispc.html [13:38:06 CEST] <ubitux> opinions? [13:46:02 CEST] <BtbN> Yes, it does work. So explicitly setting the doubles input framerate makes the cuvid deinterlacer work with the ffmpeg cli. [13:46:24 CEST] <BtbN> So, "./ffmpeg -r 50 -deint adaptive -c:v h264_cuvid -i /mnt/union/videos/whatislife-creditroll.mkv ...", with the video being 25 fps. [13:48:54 CEST] <dskjb> \msg [13:50:24 CEST] <BtbN> philipl, ^ [13:54:08 CEST] <nevcairiel> ubitux: the entire concept behind that is not entirely well suited for traditional cpus, so probably targeted at high-core co-processors [14:27:33 CEST] <BtbN> Isn't there also some gcc project that create OpenCL kernels automatically, and runs normal code on the GPU whenever it makes sense? [15:28:33 CEST] <dskjb> what does ticket closed means ? what more info is required regarding #5875 ? whole story is written there [15:33:33 CEST] <BtbN> The actual video files. [15:38:55 CEST] <dskjb> BtbN: they can be downloaded. links are listed [15:39:02 CEST] <BtbN> where? [15:40:10 CEST] <dskjb> whole page starts with original page video link [15:40:26 CEST] <BtbN> that's some website which asks me to install Flash [15:40:27 CEST] <nevcairiel> there is no video link in there, just flash links [15:40:36 CEST] <BtbN> And then a deeplink to the swp object [15:41:00 CEST] <dskjb> yea, original page link and video playing link [15:41:14 CEST] <dskjb> a person needs to download from there [15:41:28 CEST] <dskjb> steps to download are also listed [15:41:46 CEST] <BtbN> For the ticket to be valid it needs all the input files used [15:41:57 CEST] <dskjb> video file is big [15:42:19 CEST] <dskjb> are video files kept along with bug reports ? [15:42:38 CEST] <BtbN> If they are smaller than 5MB, trac accepts them [15:42:50 CEST] <BtbN> If not, some persistent file hoster or upload.ffmpeg.org has to be used [15:43:31 CEST] <dskjb> combined size 153 MB [15:43:49 CEST] <BtbN> that's not what I'd call big, but it's too big for trac. [15:44:22 CEST] <dskjb> files can be downloaded very easily from deep link [15:46:53 CEST] <dskjb> BtbN: upload.ffmpeg.org is not opening [15:46:59 CEST] <dskjb> some problem [15:47:21 CEST] <BtbN> It's an FTP server [15:47:53 CEST] <BtbN> which does seem to be down... [16:18:24 CEST] <wm4> wow google devs messing again with gapless stuff [16:20:13 CEST] <atomnuker> google encode mp3 stuff? [16:20:14 CEST] <wm4> and at this point I have no idea what their changes do, and they keep changing the FATE tests which were supposed to make verifying simple in the first place [18:45:48 CEST] <Compn> wm4 : are you talking about chromium google changes ? or a different repo? [18:46:12 CEST] <wm4> patches [18:46:18 CEST] <wm4> on ffmpeg-devel [18:46:42 CEST] <wm4> I feel like nobody has an idea how gapless works in ffmpeg (including possibly myself) [19:00:08 CEST] <philipl> BtbN: yay [19:01:24 CEST] <BtbN> well, he got his answers twice I'd say [19:03:40 CEST] <BtbN> philipl, did you start any work regarding CUDA SDK independence, btw.? [19:43:45 CEST] <cone-587> ffmpeg 03Adriano Pallavicino 07master:21d3f0c0201a: lavc/ivi_dsp.c: fix warnings due to indentation [19:43:46 CEST] <cone-587> ffmpeg 03Josh de Kock 07master:36fa3d880717: doc/developer: reword some of the policies [19:43:47 CEST] <cone-587> ffmpeg 03Josh de Kock 07master:ee72b6d1874d: doc/developer: add sections for policies [19:49:18 CEST] <Chloe> Why is SCTE still happening, didn't we establish that libav* wasn't the correct place for it? [19:50:24 CEST] <nevcairiel> try to tell that to this guy [19:51:14 CEST] <Chloe> err, I'll dig through the masses of SCTE threads tonight. plsdunmerge before I can commet [19:54:21 CEST] <wm4> > + AV_CODEC_ID_SCTE_35,/**< Contain no valid time stamp in DTS PTS of avpacket, avpacket data contain time stamp [19:54:21 CEST] <wm4> > + in scte-35 format which is relative to DTS/PTS of video stream */ [19:54:22 CEST] <wm4> lolwut [19:56:18 CEST] <ubitux> no please no [19:56:22 CEST] <ubitux> no timestamp in payload [19:56:44 CEST] <wm4> it says "relative" [19:56:49 CEST] <wm4> but relative to what, where? [19:57:10 CEST] <wm4> unless it somehow contains the full video timestamp too... [19:57:37 CEST] <wm4> anyway, the post I'm copied this from questioned whether this is still accurate [20:02:39 CEST] <philipl> BtbN: not yet. [20:03:10 CEST] <philipl> I've been chasing this "save a copy in mpv" thing down. [20:03:20 CEST] <philipl> I know how to do it now, but I'm pretty sure it's too complicated to worth it. [20:03:38 CEST] <BtbN> Is one VRAM copy really that bad? [20:06:33 CEST] <philipl> BtbN: Almost certainly not :-) [20:06:59 CEST] <philipl> I'd need to add a new hwcontext for cuda arrays - then define a custom pool in mpv. [20:07:16 CEST] <philipl> I think it saves 1-2% CPU based on my proof-of-concept [20:07:38 CEST] <nevcairiel> not worth it, then [20:07:39 CEST] <nevcairiel> :D [20:07:58 CEST] <philipl> Yes, but I'm far enough down this hole that I think I'll finish it and see what it looks like. [20:08:09 CEST] <philipl> BtbN: You want me to work on the dynlink cuda stuff? [20:08:41 CEST] <BtbN> I'd like to leave that out for now. As CUDA is the problematic part of that. [20:09:26 CEST] <philipl> K. dynlink nvcuvid? [20:09:46 CEST] <philipl> There's a small advantage there compiling on Ubuntu where they don't put the library in a place the linker will find it by default. [20:10:10 CEST] <BtbN> Yeah. So basically, revert the non-dynlink changes to the header, and load the functions. [20:10:21 CEST] <philipl> Pretty much [21:27:32 CEST] <Chloe> nevcairiel: well... It could have gone better. [21:35:22 CEST] <Chloe> Anyone going to 33c3? [22:24:30 CEST] <kierank> I want to go but it's over christmas [22:31:41 CEST] <Chloe> kierank: it's after christmas [22:32:04 CEST] <kierank> Like 2 days [22:32:22 CEST] <Chloe> yes :) Flights are still cheap now as well [23:00:03 CEST] <Chloe> michaelni: wasnt the correct output for the vf_fps change to drop a frame? [23:02:40 CEST] <michaelni> Chloe, why would it be correct to drop a frame when converting 30fps to 30fps as in thr fate test ? [23:03:43 CEST] <Chloe> From what dwbuiten is saying it looks like before it was outputting one too many frames. (maybe I misunderstand) [23:05:59 CEST] <michaelni> the fate sample has a timebase of 1/3000 all timestamps are multiplies of 100 so its basically 30fps and vf fps=30 is whats used [23:06:06 CEST] <michaelni> why should it drop a frame ? [23:07:46 CEST] <nevcairiel> the fate samples has 5 frames [23:09:44 CEST] <Chloe> oh right ok, yeah, I misunderstood :) [23:21:58 CEST] <Chloe> michaelni: this is the sample derek used: http://chromashift.org/60fps.mp4 (command being: ffmpeg -i 60fps.mp4 -vf fps=30 out.avi) [00:00:00 CEST] --- Wed Oct 5 2016

1 0

ffmpeg.log.20161004
by burek 05 Oct '16

05 Oct '16

[00:06:42 CEST] <Wilawar> In summary, normal video but long audio cut-outs on VLC, shorter audio cut-outs and video slowdowns with MPC-HC and almost unnoticable audio problems but still video slowdowns with FFplay. Sorry but I think its a problem with FFmpeg [00:07:20 CEST] <c_14> open an issue on trac? [00:08:39 CEST] <Wilawar> If Im the only one to be able to reproduce it, Im not sure thats the way to go yet. Id feel better with confirmation from someone that its not something Ive been dumb about [00:21:23 CEST] <NobCat> hi guys [00:21:45 CEST] <NobCat> anyone around to help me recover some video? [00:21:48 CEST] <NobCat> http://pastebin.com/sJRLG3qe [00:26:07 CEST] <Polochon_street> is there any way to obtain the specific error of a failed avcodec_open2 error? I passed a perfectly fine codec to it ("PCM signed 16-bit little-endian"), but it fails :\ [00:26:18 CEST] <Polochon_street> (the same code works with every of my other audio files) [00:29:27 CEST] <Polochon_street> besides, the previous avcodec_alloc_context() seemed to have worked fine :\ [00:31:33 CEST] <Wilawar> Another thing I tried: Opening it in Audacity 2.1.0. I do remember installing some FFmpeg codec thing for it, I dont know whether it has been used, but the audio is fine as far as I can tell [01:33:20 CEST] <qmr> https://www.youtube.com/watch?v=3GJUM6pCpew may be relevent to your interests [02:34:22 CEST] <SchrodingersScat> qmr: that is interesting actually [02:42:39 CEST] <klaxa> >ntcs: not the smartes choice [02:42:39 CEST] <klaxa> heh [02:42:43 CEST] <klaxa> true [06:51:36 CEST] <wallbroken> hi [08:42:40 CEST] <wallbroken> is there any important difference between mp4 and mov? [08:45:47 CEST] <sunny26> Hi I have added a support for a hardware decoder in ffmpeg version 2.8 as I have to hook it up with chroimum, how can I upstream this changes to version 2.8 of ffmpeg? [08:46:17 CEST] <sunny26> latest version is 3.1.2, do support added in 2.8 will be upstreamed to 3.1.2 ! [08:46:40 CEST] <sunny26> I am new to upstreaming and its SOP, so please someone help [09:35:39 CEST] <c_14> sunny26: clone ffmpeg git, rebase your patch on master head, send the rebased patch to the ffmpeg-devel mailing list https://ffmpeg.org/developer.html [09:37:33 CEST] <sunny26> <c_14>: ok thanks [09:39:22 CEST] <Spring> I read on Bugzilla that Chromium uses ffmpeg internally for decoding, anyone know if this is correct? [09:39:47 CEST] <Spring> surprisingly google shows exactly 0 results for 'ffmpeg chromium' [09:40:48 CEST] <spaam> i found several [09:41:03 CEST] <sunny26> <Spring> Suprisingly it exit here, https://chromium.googlesource.com/chromium/third_party/ffmpeg.git [09:41:46 CEST] <Spring> sunny26, where did you find the link btw? [09:42:01 CEST] <spaam> google: "ffmpeg chromium" [09:42:10 CEST] <spaam> second hit [09:42:11 CEST] <sunny26> google. [09:42:23 CEST] <Spring> I have, that result doesn't display [09:43:00 CEST] <Spring> https://a.uguu.se/llP5LCQkql5O.png [09:43:16 CEST] <sunny26> I think we discuss ffmpeg related problems and issuses here, not related to google search results. [09:43:51 CEST] <sunny26> anyways the link I provided is accurate [09:44:02 CEST] <Spring> I realize that, it was showing that I can't find this myself using the same query is all [09:44:20 CEST] <Spring> or anything related for that matter [09:44:33 CEST] <sunny26> Ya that's fine [09:46:31 CEST] <sunny26> searching 'ffmpeg chromium' gives the link i sent you in second result, check this https://www.google.co.in/search?client=ubuntu&channel=fs&q=ffmpeg+chromium&… [09:48:27 CEST] <Spring> odd. After relaunching Firefox the same query displays the results. [11:17:43 CEST] <oakwhiz> Question: Can this type of video be made using filters in ffmpeg? https://www.youtube.com/watch?v=P5g-lCsOoNs [11:19:10 CEST] <oakwhiz> I was thinking of using setpts, a colorkey, and an overlay, and that would get 1 copy of the same video but delayed. The recursion is confusing however [11:20:20 CEST] <oakwhiz> Extending it to an arbitrary number of copies would seem to require an ever-expanding command line [11:59:01 CEST] <Bernmeister> I've read https://trac.ffmpeg.org/wiki/Seeking and am confused by the first (of three) example in "Cutting small sections". Why does "-ss 00:01:00 ... -to 00:02:00" yield a total duration of 3 minutes rather than 2 minutes (as per the other two examples)? I have tested this myself and indeed I get three minutes...but why? [12:01:56 CEST] <furq> it doesn't [12:05:17 CEST] <n4zarh> I need to be able to add adpcm_ima_oki encoder to my project, but ffmpeg allows only for decoding this format. Is there any way to add that decoder to list? If not, can anyone tell me what codec should I look for? [12:06:00 CEST] <c_14> furq: Bernmeister, it does when -ss is an input option because using -ss as an input option adjusts the timestamps by that amount (unless -copyts is used) [12:06:24 CEST] <furq> that wouldn't give a duration of three minutes though [12:06:31 CEST] <furq> it'd cut from 1:00 to 3:00 [12:06:41 CEST] <c_14> eh, yeah [12:06:43 CEST] <c_14> right [12:06:53 CEST] <furq> n4zarh: it doesn't look like there's an encoder for that format [12:07:06 CEST] <c_14> Arithmetic is hard [12:07:26 CEST] <n4zarh> yeah, that's why I ask, I'm not 100% sure but I might need that encoder [12:07:35 CEST] <furq> Bernmeister: the other two examples give a duration of 1:00, the first one is 2:00 [12:07:59 CEST] <furq> if that's what you meant then it's explained just above the examples [12:19:30 CEST] <Bernmeister> c_14, furq: Thanks - I've run a few tests just now and I suppose the simplest solution for me is to use the -t option in lieu of -to when -ss is used as an input option. Otherwise I get audio but no video at the start OR I get more time/duration that I expect. [12:35:47 CEST] <n4zarh> I seem to have problem with filling audio frame while trying to encode audio, does anyone know something about that function? [12:38:44 CEST] <n4zarh> I try to get data from mic on android, encode it and send it to ip camera; definitely tries to encode data for adpcm codecs (but they are not what I need), but fail with -22 error code on pcm_mulaw/alaw encoders, not sure what am I missing [12:39:54 CEST] <BtbN> send audio to an IP camera? oO [12:40:28 CEST] <n4zarh> it has some kind of speaker [12:41:29 CEST] <n4zarh> it can record video and audio, but also it can play audio sent with it's API [12:43:33 CEST] <n4zarh> so I need to encode PCM data from my smartphone microphone to pcm_mulaw codec (since camera uses this one); and that's where I fail, I can't encode any frame, because my code crashes on avcodec_fill_audio_frame function [12:46:54 CEST] <n4zarh> or actually av_samples_get_buffer_size fails [12:56:08 CEST] <n4zarh> I think I've got reason for error - why frame_size for pcm_mulaw context equals 0? [12:56:44 CEST] <n4zarh> it has specific sizes for every ADPCM codec I tried using, but it's always 0 for alaw/mulaw [13:15:01 CEST] <Mavrik> hmm :/ [13:15:13 CEST] <Mavrik> It's usually worth looking at the source in these cases [15:03:28 CEST] <wallbroken> what's the diff between mp4 and mov? [15:05:06 CEST] <BtbN> the file extension [15:07:21 CEST] <ritsuka> and some things are a bit different in the file format [15:07:30 CEST] <iive> mp4 is standard based on apple mov [15:16:05 CEST] <JEEB> but there are things defined differently between 14496-12 and qtff.pdf [15:16:07 CEST] <wallbroken> not clear answers [15:16:13 CEST] <JEEB> so while they are similar, they are not the same [15:16:29 CEST] <wallbroken> mp4 does not accept some metadata that mov does [15:16:35 CEST] <JEEB> mov is what was used as the base for ISOBMFF (which is called "mp4" colloquially) [15:16:44 CEST] <JEEB> not surprising :P [15:16:51 CEST] <JEEB> mov was never standardized [15:17:06 CEST] <JEEB> ISOBMFF is actually standardized so you shouldn't be able to put random crap in it [15:17:19 CEST] <JEEB> also *how* those tags are put there can differ [15:17:43 CEST] <wallbroken> JEEB, mp4 is standard or apple proprietary? [15:17:50 CEST] <JEEB> ISOBMFF is an ISO standard [15:18:01 CEST] <JEEB> they took apple's QT File Format and made it intot a standard file format [15:18:25 CEST] <JEEB> QT File Format also has an Apple document of course, which is why I said qtff.pdf :P [15:18:33 CEST] <JEEB> you can think of MOV as Apple's AVI [15:18:42 CEST] <wallbroken> ffmpeg -i input.mov -vf "hflip,vflip,scale=1024:-2" -map_metadata 0 -metadata:s:v rotate="" -c:a copy output.mov [15:18:43 CEST] <wallbroken> it's ok [15:18:47 CEST] <wallbroken> ffmpeg -i input.mov -vf "hflip,vflip,scale=1024:-2" -map_metadata 0 -metadata:s:v rotate="" -c:a copy output.mp4 [15:18:51 CEST] <wallbroken> gives to me an error [15:21:39 CEST] <furq> were you planning on sharing the error with us [16:46:51 CEST] <transhuman> hi is there a sample program anywhere anyone knows about that works from a local web server that uses ffmpeg to translate from different formats like raw to mp3 and mp3 to raw?9(for example) [16:47:44 CEST] <transhuman> also recording the formats would be a nice part of it if I could have such a thing...I am trying to work on apache with audio [16:50:21 CEST] <ozette> is there any documentation about -skip_frame nokey ? [16:51:08 CEST] <furq> https://www.ffmpeg.org/ffmpeg-codecs.html#Codec-Options [16:51:12 CEST] <furq> ozette: it's listed in there [17:06:53 CEST] <ozette> furq: thansk [19:18:42 CEST] <Check_> Hello [19:21:54 CEST] <pgorley> hi, is there a way to disable vaapi x11 but not vaapi drm? [19:34:01 CEST] <pgorley> nvm, found my answer, if you configure with disable-xlib and enable-vaapi, drm is enabled and x11 isn't [20:50:56 CEST] <cowai> Anybody know why the bitrate is ever increasing throughout the render when using CRF? [20:51:29 CEST] <BtbN> Because the video is getting more complex. [20:51:31 CEST] <cowai> 24minutes in, its triple the bitrate as it was the first five minutes. [20:51:40 CEST] <cowai> Its never going down [20:51:52 CEST] <furq> that's the average for the whole file [20:51:55 CEST] <cowai> Ah [20:52:05 CEST] <furq> if the first two minutes are credits or something then it'll keep increasing [20:52:07 CEST] <cowai> So its the average. [20:52:10 CEST] <cowai> yes. [20:52:13 CEST] <cowai> That explains it [20:53:02 CEST] <furq> a rolling average would be nice [20:53:23 CEST] <furq> right now it's just size / duration [20:53:40 CEST] <cowai> Average last 10 sec or something would be nice. [21:31:13 CEST] <teratorn> how would one go about generating a testsrc video of, say 9 seconds in length 30fps, but split in to precisely 3 different video files of 90 frames each? [21:31:41 CEST] <teratorn> I guess I can just generate it, then cut it? but I'm not sure how, and not sure about keyframe boundaries being a problem... [21:32:40 CEST] <llogan> you could use trim filter [21:33:43 CEST] <teratorn> llogan: I'll check it, thank you! [21:36:03 CEST] <DHE> segment output? [21:36:28 CEST] <llogan> that too probably [21:36:28 CEST] <DHE> so many ways, it makes me feel sorry for the cat [21:39:51 CEST] <llogan> teratorn: you'll probably need to add setpts=PTS-STARTPTS after each trim [21:39:59 CEST] <llogan> IIRC [21:44:21 CEST] <teratorn> I can just use frame numbers, not timestamps [21:45:57 CEST] <AlVal> freebsd, getting ERROR: opencv-core not found using pkg-config [21:47:09 CEST] <AlVal> using portmaster to upgrade from 2.8.8_2,1 to 2.8.8_3,1 [21:48:15 CEST] <AlVal> interestingly opencv2-core just had an update too [21:51:13 CEST] <teratorn> llogan: so I figured out how to do this using 3 different invocations of ffmpeg with different trim parameters... but I suppose I can use a complex filtergraph to do it in one invocation, right? :) [21:51:49 CEST] <teratorn> ie, one testsrc input, 3 -vf trim outputs? [21:52:42 CEST] <llogan> teratorn: ffmpeg -y -f lavfi -i testsrc=d=9:r=30 -filter_complex "[0:v]trim=start_frame=0:end_frame=90,setpts=PTS-STARTPTS[v0];[0:v]trim=start_frame=90:end_frame=180[v1];[0:v]trim=start_frame=180:end_frame=270,setpts=PTS-STARTPTS[v2]" -map "[v0]" out0 -map "[v1]" out1 -map "[v2]" out2 [21:53:00 CEST] <llogan> assuming you actually want 30 frame rate instead of ntsc [21:53:48 CEST] <llogan> you need to setpts because trim doesn't reset the timestamps [21:54:28 CEST] <llogan> unless you want it to do that... [21:54:48 CEST] <teratorn> oh, so my files that I created with separate invocations of trip have non-zero starting pts's.. the 2nd and 3rd files that is... I guess most players don't care.. :/ [21:54:54 CEST] <teratorn> s/trip/trim/ [21:55:26 CEST] <teratorn> llogan: awesome, thanks [21:55:32 CEST] <llogan> you can check with "ffprobe -v error -show_frames input" [21:55:52 CEST] <teratorn> curious.. I built ffmpeg from source but I did not get an ffplay binary... [21:56:00 CEST] <llogan> it requires SDL2 [21:56:07 CEST] <teratorn> ah, must have forgot that options [21:56:55 CEST] <llogan> http://ffmpeg.org/index.html#sdl1 [21:57:16 CEST] <llogan> ^ SDL1 support was dropped recently in favor of SDL2 [21:57:35 CEST] <teratorn> SDL2 doesn't even support the nice YUVOverlay thingo that SDL1 has [21:57:46 CEST] <teratorn> or at least it didn't, last I checked... :/ [21:57:53 CEST] Action: llogan has no clue about SDL* [21:58:11 CEST] <teratorn> would be educational to see how ffplay utilizes SDL2 for rendering yuv and/or rgb frames [22:01:45 CEST] <llogan> AlVal: did you install opencv-core? [22:02:39 CEST] <llogan> alternatively, use OPENCV=off. but i'm going to blame your build script/ports system unless you can show that it is a ffmpeg problem [22:03:11 CEST] <AlVal> llogan: The graphics/opencv-core port moved to graphics/opencv2-core ===>>> Reason: Renamed [22:03:44 CEST] <llogan> seems like a freebsd issue [22:04:13 CEST] <AlVal> ok so its not like thats something that ffmpeg hardcodes or anything [22:04:47 CEST] <AlVal> but rather the os or ports management system should be responsible for maintaining the references to [22:06:20 CEST] <llogan> you have to explicitly tell ffmpeg you want to --enable-libopencv. how you provide the required headers is up to you/your package management system [22:07:35 CEST] <AlVal> llogan: thanks [22:07:51 CEST] <teratorn> llogan: perfect, you just forgot the setpts for the middle video ;) [22:08:38 CEST] <llogan> inconveivable. must have been packet loss. [22:09:04 CEST] <teratorn> and indeed, ffplay did not start playing frames until the pts said so... it doesn't care what the first frame's pts is I guess... I think other players are perhaps more forgiving [22:09:27 CEST] <teratorn> even though it rendered the first frame immediately... [22:09:51 CEST] <teratorn> which is cool, I guess. it's made for testing purposes, mostly, I guess. [22:20:49 CEST] <teratorn> hmm, is there any problem with having a huge gap in timestamps for a h264 video stream that is nominally 30fps, for example? [22:21:14 CEST] <teratorn> i.e. will players just sit on the last displayed frame during the gap? [22:21:46 CEST] <teratorn> use-case is overlaying a static image on top of a given frame and "pausing" there for a few seconds [22:42:58 CEST] <kepstin> teratorn: assuming you're storing the video in a container that supports vfr, that should work fine. And you can have ffmpeg duplicate the frame to fill in the gap by using the fps filter if you prefer. [22:43:26 CEST] <teratorn> kepstin: mp4 [22:45:34 CEST] <teratorn> kepstin: but what about "pausing" the input video at a given frame... duplicating that frame with fps filter *and* overlaying another stream during that pause period (the static frame duplicated with the fps filter) ? ;) [22:46:20 CEST] <teratorn> I don't mind writing code, if the ffmpeg command line can't quite handle this... :/ right now I'm trying to figure out if it's possible from the command-line or not [22:46:47 CEST] <teratorn> I guess one approach would be to "steal" a frame from the input video, at the right offset where I want the pause/overlay to happen [22:47:02 CEST] <teratorn> ie in a separate ahead-of-time step [22:47:05 CEST] <kepstin> teratorn: if you put the fps filter after everything else, it'll convert the video to constant framerate by duplicating frames. You can do the "pause" with careful use of the setpts filter, I guess. be tricky to time the overlay but it should be doable. [22:47:56 CEST] <kepstin> like many things, it can be done in a single ffmpeg invocation, but you have to be clever about writing your filters :) [22:48:08 CEST] <teratorn> hmm ok, well to finish my idea... I can generate an intermediate stream with my stolen frame for the duration of the pause period, overlay my static-frame-generated-stream on top of it. [22:48:14 CEST] <teratorn> if that makes any sense at all... :) [22:52:34 CEST] <teratorn> well, in my use-case, the videos are already separate files... ie. the "pause and overlay" happens at the end of one video, for some number of seconds... then they are all cat'ed together :) [00:00:00 CEST] --- Wed Oct 5 2016

1 0

ffmpeg-devel.log.20161003
by burek 04 Oct '16

04 Oct '16

[00:17:03 CEST] <Chloe> jamrial: thanks for the review [01:17:33 CEST] <cone-979> ffmpeg 03Josh de Kock 07master:441d15b7c0a0: doc/t2h: use container [01:45:00 CEST] <cone-979> ffmpeg 03Michael Niedermayer 07master:cced8394b6e0: fate: Add PSP copy test [02:46:04 CEST] <Chloe> BBB: the musl thing is an issue on our side though, isn't it? [02:46:45 CEST] <BBB> depends [02:46:46 CEST] <Chloe> no need to report it upstream, afaik we should be clearing the x87 state before calling an external function [02:47:02 CEST] <BBB> I disagree [02:47:23 CEST] <BBB> youre free to have that opinion btw, Im by no means the teller of absolute truth [02:47:53 CEST] <BBB> Id rather expect these kind of functions to not use x87 functions [02:49:17 CEST] <Chloe> I just thought it was part of the cdecl calling convention [02:52:09 CEST] <Chloe> 'If the function does not return a floating-point value, then this register must be empty. This register must be empty before entry to a function.' (in regards to the floating point registers) [02:52:26 CEST] <Chloe> http://sco.com/developers/devspecs/abi386-4.pdf page 37-38 [02:53:06 CEST] <Chloe> we're in violation of this atm [02:55:23 CEST] <wm4> yeah, I agree it's ffmpeg's fault, even if musl is doing ridiculous things [02:55:43 CEST] <wm4> BBB: I think it's a log2, not a hash function [03:01:26 CEST] <BBB> oh is that the old-fashioned log2 without lut? [03:02:55 CEST] <wm4> whoops posted the same thing as Chloe [03:03:02 CEST] <wm4> BBB: looks like it [03:03:14 CEST] <Chloe> wm4: it seems we do this a lot [03:04:22 CEST] <BBB> maybe we should send them a speed-up [03:04:28 CEST] <BBB> (make it lut-based) [03:11:30 CEST] <Chloe> they have a lut log2 just above the float stuff, it's just macro'd out [03:12:22 CEST] <Chloe> we're all talking about bin_index/bin_index_up right? [03:12:33 CEST] <Chloe> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114 [03:13:51 CEST] <BBB> yes [03:14:01 CEST] <BBB> carl eugen suggested that that is likely the offending code [03:14:23 CEST] <BBB> it seems to be the only explicit float variable in there [03:14:31 CEST] <BBB> (or double) [03:15:46 CEST] <Chloe> I'm confused, why are you talking about a log2? [03:26:04 CEST] <wm4> we're thinking the float trickery is a log2 [03:37:44 CEST] <BBB> a very limited one at best... [03:38:38 CEST] <BBB> I dont see the macroed out log2 btw [03:39:12 CEST] <Chloe> just above [03:39:27 CEST] <Chloe> BBB: http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n91 [03:39:38 CEST] <BBB> thats not a log2 :-p [03:39:43 CEST] <Chloe> ;_; [03:39:46 CEST] <Chloe> what is it [03:39:52 CEST] <BBB> a debruijn [03:40:21 CEST] <Chloe> so I saw a debruijn in the answer to a question asking how to log2 [03:40:25 CEST] <BBB> an algo for counting trailing zeroes [03:40:40 CEST] <BBB> but its not used in the function itself [03:41:07 CEST] <Chloe> ok maybe I didnt [03:41:12 CEST] <BBB> ok I see [03:41:13 CEST] <Chloe> idk how I got them confused [03:41:38 CEST] <BBB> first_set is a log2, yes [03:41:50 CEST] <BBB> Im still not sure what bin_index does [03:42:46 CEST] <Chloe> so ctz is used in log2 [03:42:47 CEST] <Chloe> god I need a good algorithms book [03:42:55 CEST] <Chloe> I also need to learn wtf a log2 is [03:45:34 CEST] <Chloe> oh right. It just solves 2^n = x for n [04:20:49 CEST] <Compn> i think we know the musl dev [04:21:05 CEST] <Compn> its dalias :P [04:21:27 CEST] <Compn> if you wanted to bug him direct haha [05:04:09 CEST] <Compn> oh theres a #musl too [06:51:47 CEST] <cone-238> ffmpeg 03James Almer 07master:eb60256c2083: fate: add bitexact decode flag to fate-svq3-watermark [13:52:12 CEST] <wm4> where do we still have mmx code that matters? [13:52:25 CEST] <wm4> I mean, I'd expect _at_least_ half of them being meaningless [13:52:52 CEST] <nevcairiel> some algorithms using small datasets that probably dont benefit much from bigger regs [13:52:56 CEST] <nevcairiel> and old code [14:02:51 CEST] <kierank> some prediction [14:03:42 CEST] <nevcairiel> you could probably re-build all the mmx code in sse2 only using half the register size, and wouldnt notice any performance changes [14:04:33 CEST] <kierank> iirc x264's checkasm disagrees [14:04:49 CEST] <nevcairiel> may depend on the cpu generation, of course [14:05:14 CEST] <nevcairiel> but iirc i heard some people say that mmx execution is getting slightly slower on newer cpus, presumably because they are moving those to be executed with the sse2 units anyway [14:05:46 CEST] <nevcairiel> and save hardware [14:18:01 CEST] <cone-426> ffmpeg 03Matthieu Bouron 07master:68822da8ff7d: lavc/mediacodecdec_h2645: fix nalu data_size type [14:20:39 CEST] <BBB> a lot of modern SIMD code is still MMX, wm4 [14:21:35 CEST] <BBB> wm4: on medium-end CPUs, xmm instructions are one cycle slower than mmx instructions (and handle double the data, indeed), but that means if you dont need double data (small blocksizes), then mmx is actually faster than xmm on these CPUs [14:34:48 CEST] <Chloe> BBB: wm4: 'It's roughly log2(x), but with 4 linearly spaced bins for each logarithmic step' [14:35:29 CEST] <BBB> ok [14:42:07 CEST] <wm4> Chloe: fascinating [14:43:12 CEST] <Chloe> I assume they wouldn't mind a patch which speeds it up, and just happens to fix our issue as well, assuming the patch still follows the standard/complies. [14:43:26 CEST] <Chloe> (as BBB suggested earlier) [15:00:37 CEST] <Gramner> punpckh* instructions in particular are very common and behave differently on mmx and xmm registers, also memory operands require 16-byte alignment with sse2 and no alignment with mmx (although 8-byte alignment is beneficial) which is an issue on 8x8 blocks for example [15:01:09 CEST] <Gramner> so simply straight up porting mmx code to use lower half of xmm registers isn't possible [15:02:58 CEST] <wm4> thanks for the mess, intel [15:02:59 CEST] <Gramner> some instructions are faster with xmm registers than mmx registers on skylake, but this really only affects a small subset of existing code anyway [15:21:31 CEST] <Gramner> BBB: mmx is often faster than xmm on 10+ year old cpus (e.g. conroe). when it comes to more modern chips though the situation isn't really the same. I know that shifts with variable amount (specified in vector reg) is slower with xmm than mmx but is there actually anything else? [15:24:42 CEST] <Gramner> mmx does have the advantage of more compact instruction encoding which saves cache [15:28:22 CEST] <BBB> Gramner: from my testing, on medium-end cpus, mmx is still faster (not by much, but by some) for small-block functions [15:32:49 CEST] <BBB> whether that difference is important is an interesting question [15:32:52 CEST] <BBB> anyway [15:33:23 CEST] <BBB> the more pressing issue is that we have a ton of legacy mmx code and thats unlikely to be converted to sse2 anytime soon even if we wanted to convert it [15:33:25 CEST] <BBB> its like inline asm [15:33:27 CEST] <Gramner> hmm, could be size-related. e.g. bottlenecked by instruction decoding [15:33:28 CEST] <BBB> nice long-term quest [15:33:41 CEST] <BBB> but short-term, were stuck with the status quo and have to accept that as-such [15:34:02 CEST] <Gramner> yes, any potential rewrite would take plenty of time [15:34:12 CEST] <BBB> Gramner: maybe, yes. I never looked very deeply at it. I assumed it was b/c mmx is one cycle faster according to that instruction cycle counter thing you guys always use [15:34:16 CEST] <BBB> but I didnt prove that [15:34:52 CEST] <BBB> (mostly because I didnt care why (I just cared that) it was faster [16:05:09 CEST] <cone-426> ffmpeg 03Timo Rothenpieler 07master:a0d7ce140662: avutil/hwcontext_cuda: align allocated frames [16:05:10 CEST] <cone-426> ffmpeg 03Timo Rothenpieler 07master:c4b78f966223: MAINTAINERS: add myself for hwcontext_cuda [16:47:29 CEST] <cone-426> ffmpeg 03Adriano Pallavicino 07master:f4e692a0e90b: lavf/bink.c: fix warning due to misleading indentation [18:29:56 CEST] <lehar> @michaelni [20:01:15 CEST] <kierank> ==18388== 32 bytes in 1 blocks are definitely lost in loss record 14 of 41 [20:01:15 CEST] <kierank> ==18388== at 0x5630899: posix_memalign (jemalloc.c:1062) [20:01:15 CEST] <kierank> ==18388== by 0x4DF62C: av_malloc (mem.c:95) [20:01:15 CEST] <kierank> ==18388== by 0x4DF7ED: av_mallocz (mem.c:252) [20:01:15 CEST] <kierank> ==18388== by 0x4D65A1: av_dict_set (dict.c:85) [20:01:15 CEST] <kierank> ==18388== by 0x4E2FB8: av_opt_set_dict2 (opt.c:1467) [20:01:16 CEST] <kierank> ==18388== by 0x456AFB: avcodec_open2 (utils.c:1413) [20:01:20 CEST] <kierank> how do I deal with that? [20:03:39 CEST] <BtbN> kierank, did you build jemalloc with --enable-valgrind? [20:03:54 CEST] <kierank> does it need that? [20:04:11 CEST] <BtbN> without that, valgrind gets terribly confused by what it's doing and reports nonsense/misses stuff. [20:04:27 CEST] <BtbN> It makes it _a lot_ slower though [20:04:49 CEST] <kierank> i have a ton of valgrind spam from ioctls anyway [20:04:58 CEST] <kierank> it's just leaks that are of interest really [21:14:18 CEST] <Chloe> I dont really get this guy "you have no experience or say at all because this is ffmpeg, but err, no offence" [21:18:52 CEST] <philipl> Odd chap. [21:21:49 CEST] <kierank> atomnuker: https://www2.iis.fraunhofer.de/AAC/multichannel.html [21:25:24 CEST] <lehar_> quit [22:12:25 CEST] <TD-Linux> if you're referring to the musl thing, fwiw I think adding emms is the "correct" solution (it was added to libtheora) [22:16:04 CEST] <ubitux> yes it is [22:16:11 CEST] <Gramner> the strictly "correct" solution is to add emms between every single use of mmx and calling any third party functions (memcpy, memset, memcmp et. al). the problem is that doing so will hurt performance because emms is very expensive on many cpus. plus it would be a nightmare to maintain. [22:18:07 CEST] <BtbN> Why is the ffmpeg mmx code even doing memory allocations? [22:18:14 CEST] <BtbN> Can't that just be moved outside of the loop? [22:21:34 CEST] <ubitux> jemalloc seems to have doubles in its profiling code [22:22:02 CEST] <ubitux> pretty sure we can find floats in others [22:23:46 CEST] <Gramner> the libc function call doesn't have to be in an inner loop for it to be a potential issue. it's quite common to have some inner loop simd asm followed by some c code that calls memcpy or whatever. you need to identify every single case in the codebase where this occurs and add an emms [22:24:16 CEST] <ubitux> we're just talking about the allocator currently [22:27:41 CEST] <Gramner> we could guard only mallocs with emms and ignore everything else, sure. but that's a hack, not a "correct" solution (which doesn't necessarily mean it's a bad idea though) [22:28:37 CEST] <ubitux> https://github.com/jemalloc/jemalloc/blob/dev/src/prof.c#L836 [22:28:44 CEST] <ubitux> > workaround for versions of glibc that don't properly save/restore floating point registers [22:28:47 CEST] <ubitux> heh [22:29:29 CEST] <ubitux> and indeed i guess compilers that generate simd could be an issue [22:29:35 CEST] <ubitux> but in that case, it could happen... anyway [22:29:39 CEST] <ubitux> anywhere* [22:30:41 CEST] <TD-Linux> Gramner, well, it's closer to correct. I agree guarding every C library call is more correct [22:30:43 CEST] <jkqxz> Any C library call can be hooked by the user, so you really do have to do everything. memcpy() is totally fatal because the compiler can insert it anywhere and you can imagine someone doing some sort of instrumentation on it which happens to use floating point. [22:34:52 CEST] <cone-172> ffmpeg 03Marton Balint 07master:2face3e7b568: lavc/utils: disallow zero sized packets with data set in avcodec_send_packet [22:34:52 CEST] <cone-172> ffmpeg 03Marton Balint 07master:fbf8ac7d2a37: lavd/openal: don't return zero sized packet if no samples are available [22:37:08 CEST] <BBB> memcpy is indeed an issue [22:37:15 CEST] <BBB> according to the standard, we cant use memcpy [22:37:25 CEST] <BBB> (without preceeding the call to it with a call to emms) [22:37:40 CEST] <nevcairiel> according to the standard, we cant call any function with a mmx fpu state [22:37:46 CEST] <BBB> right [22:37:47 CEST] <nevcairiel> C library or something else [22:37:59 CEST] <nevcairiel> the cdecl calling convention forbids it [22:38:18 CEST] <nevcairiel> of course if its our own functions, we can do what we want [22:38:24 CEST] <ubitux> maybe we should have our av_memcpy etc [22:38:35 CEST] <ubitux> :) [22:38:39 CEST] <Gramner> libavc [22:38:51 CEST] <nevcairiel> the real problem I see is not fixing those cases, but actually finding relevant places [22:38:59 CEST] <nevcairiel> often it can probably just be fixed by moving an existing emms [22:39:02 CEST] <nevcairiel> or something alike [22:40:43 CEST] <wm4> like jkqxz mentioned, some compilers replace plain C code with memcpys and you can't control that [22:41:08 CEST] <nevcairiel> we cant control that, and we cant fix that [22:41:22 CEST] <Gramner> simply "fixing" it is easy. modify x86inc.asm to add emms before returning from an mmx function and add emms to any inline mmx asm. doing it in a way that minimizes the performance impact on the other hand by only using emms it when it's actually required is hard [22:41:26 CEST] <TD-Linux> wm4, actual calls to libc memcpy or the compiler intrinsic memcpy? [22:41:38 CEST] <jkqxz> TD-Linux: Actual calls to libc memcpy. [22:41:41 CEST] <nevcairiel> its ludicrious to assume anything can convert into a compiled inserted libc call and try to fix those [22:42:03 CEST] <TD-Linux> jkqxz, ah. I seem to recall a clang bug where they screwed that up. [22:42:17 CEST] <jkqxz> You can suppress it with compiler options, I think. [22:44:09 CEST] <nevcairiel> can you assert for a proper fpu state, somehow? [22:44:11 CEST] <jkqxz> It is "fixable" without that, though. You can force resolution of the possibly-generated symbols to somewhere inside lav* (either real memcpy(), etc. implementations or state reset + actual library call). [22:46:44 CEST] <rcombs> does the required emms defeat the advantage of MMX's smaller instruction encoding? [22:47:09 CEST] <nevcairiel> not really if its used properly, you would only fire it once after the whole processing is done [22:51:25 CEST] <Gramner> emms is like 30+ µops or something crazy like that on many cpus, probably microcoded. probably slower then many entire mmx functions. so you'd want to avoid using it more than necessary [22:53:16 CEST] <nevcairiel> is it only this slow when the fpu is in mmx mode, or always? [22:54:40 CEST] <Gramner> I don't know, but I would guess always. it's 31 µops on sandy bridge - broadwell according to agner and no indication of it being variable. they improved it to 10 on skylake [22:55:36 CEST] <wm4> at this level wouldn't the function call overhead matter too? [22:55:47 CEST] <nevcairiel> which function? [22:55:49 CEST] <TD-Linux> for the memcpy() case it is pretty tempting to ether pick some amount of reliance on implementation specific behavior, or implement jkqxz's solution [22:56:26 CEST] <BtbN> there could be one "generic" implementation, that's safe. And one that issues emms whenever it might be required. [22:56:27 CEST] <jkqxz> I think the compiler-injected code case isn't actually relevant. If anything fails there then it is an error in the toolchain and must be fixed there - the compiler and libc do not have the same beliefs about the effect of memcpy() (in a extra-standard sense here, but the FPU rounding mode will have an equivalent problem in a fully standard situation). [22:56:55 CEST] <jkqxz> So we only need to worry about explicit calls. [22:56:59 CEST] <BtbN> And then the current one, for libcs where it's known to work. [22:58:20 CEST] <jkqxz> But memcpy() is still technically a problem. (Except not if we can guarantee that the compiler /does/ generate it, because that forces the appropriate contract onto the libc.) [22:59:26 CEST] <wm4> nevcairiel: most asm functions are called via function pointer, right [22:59:57 CEST] <nevcairiel> sure, anything that processes entire blocks etc [23:00:16 CEST] <nevcairiel> we do have some legimate inline asm thats inline for speed, not because someone couldnt write yasm [23:47:06 CEST] <cone-172> ffmpeg 03Stephan Holljes 07master:d0be0cbebc20: lavf/aviobuf.c: Adapt avio_accept and avio_handshake to new AVIOContext API [00:00:00 CEST] --- Tue Oct 4 2016

1 0

ffmpeg.log.20161003
by burek 04 Oct '16

04 Oct '16

[00:43:23 CEST] <SchrodingersScat> stah0121: http://ronja.twibright.com/pitchotron.php [01:42:34 CEST] <ferdna> why does my image looks like this: [01:42:35 CEST] <ferdna> http://i66.tinypic.com/afjwvl.jpg [01:42:42 CEST] <ferdna> that is on my tv... on burnt dvd... [01:42:46 CEST] <ferdna> on my dvd player [02:13:59 CEST] <SchrodingersScat> ferdna: very modern art [02:14:08 CEST] <ferdna> SchrodingersScat, lol... yes [03:42:15 CEST] <mrelcee> having a curious x11 issue.. is there an X11 channel here or does anyone mind me asking it here? (yes it's on freebsd :) [03:46:22 CEST] <mrelcee> wrong channel too. soddy [04:02:01 CEST] <waltz> hey folks! i want to loop a video for 30 seconds. how would i do that? [05:21:01 CEST] <eduardo> hi [05:22:33 CEST] <eduardo> oh well, i have a problem installing the ffmpeg in linux mint [05:23:46 CEST] <eduardo> i followed his guide here: https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [05:25:06 CEST] <eduardo> and whe i get to the part when i should install fmpeg [05:26:52 CEST] <ferdna> eduardo, [05:27:08 CEST] <SchrodingersScat> now two people are doing it ;_; [05:27:58 CEST] <SchrodingersScat> eduardo: what you absolutely must do is [05:30:37 CEST] <eduardo> i get this error message: ERROR: x265 not found using pkg-config [05:31:04 CEST] <eduardo> im new on linux yet so i dont know what that means [05:32:37 CEST] <noobe1> hello, I'd like to use ffmpeg to decompress context of an mp4 video file into individual raw yuyv422 format. I tried ffmpeg -i video.mp4 -c:v rawvideo -pix_fmt yuyv422 out%d.dat but it outputs to a single file. [05:32:55 CEST] <eduardo> the line that returns that message is "PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [05:32:55 CEST] <eduardo> --prefix="$HOME/ffmpeg_build" \ [05:32:55 CEST] <eduardo> --pkg-config-flags="--static" \ [05:32:55 CEST] <eduardo> --extra-cflags="-I$HOME/ffmpeg_build/include" \ [05:32:55 CEST] <eduardo> --extra-ldflags="-L$HOME/ffmpeg_build/lib" \ [05:32:57 CEST] <eduardo> --bindir="$HOME/bin" \ [05:32:59 CEST] <eduardo> --enable-gpl \ [05:33:01 CEST] <eduardo> --enable-libass \ [05:33:03 CEST] <eduardo> --enable-libfdk-aac \ [05:33:05 CEST] <eduardo> --enable-libfreetype \ [05:33:07 CEST] <eduardo> --enable-libmp3lame \ [05:33:09 CEST] <eduardo> --enable-libopus \ [05:33:13 CEST] <eduardo> --enable-libtheora \ [05:33:15 CEST] <eduardo> --enable-libvorbis \ [05:33:17 CEST] <eduardo> --enable-libvpx \ [05:33:19 CEST] <eduardo> --enable-libx264 \ [05:33:21 CEST] <eduardo> --enable-libx265 \ [05:33:23 CEST] <eduardo> --enable-nonfree" [05:37:31 CEST] <relaxed> eduardo: use http://pastebin.com/ , don't paste in the channel. Show the end of ffmpeg's config.log [05:37:50 CEST] <eduardo> oh sorry [05:38:04 CEST] <eduardo> how do i do that? [05:40:22 CEST] <relaxed> go to the website and paste the info, click "create new paste", then paste the url here [05:40:56 CEST] <eduardo> mmm sorry i meant the config.log [05:41:10 CEST] <eduardo> nvm i got a tutorial [05:41:22 CEST] <eduardo> when i get it ill use the website [05:43:23 CEST] <eduardo> i thin i don't ave a confi.lo on ffmpeg because i didnt finished intalling it [05:44:02 CEST] <eduardo> as i wrote, i got an error message when i input that lin of comand on th terminal [05:44:57 CEST] <eduardo> this is the line of command: http://pastebin.com/uNNGzVJb [05:46:40 CEST] <SchrodingersScat> eduardo: did you do this bit? https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu#libx265 [05:46:49 CEST] <relaxed> running ffmpeg's ./configure creates config.log [05:47:38 CEST] <SchrodingersScat> noobe1: out%02d.dat ? [05:47:48 CEST] <relaxed> it's in the ffmpeg source dir [05:48:54 CEST] <eduardo> yes i did. [05:49:00 CEST] <noobe1> SchrodingersScat, I tried, it's not outputing individual files, it's outputing a single file named "out%02d.dat" [05:49:08 CEST] <ferdna> eduardo, use pre-compiled packages... [05:49:14 CEST] <ferdna> apt-get install ffmpeg [05:49:20 CEST] <ferdna> apt-get install x264 [05:49:22 CEST] <ferdna> apt-get install x265 [05:50:01 CEST] <noobe1> is the raw file just yuv frames back-to-back? I mean I guess I can calculate actual nubmer of bytes per raw frame using format+resolution and just read the file continously [05:50:18 CEST] <noobe1> but I wanted to load individual frames into photoshop [05:51:27 CEST] <eduardo> the x264 is fine [05:51:54 CEST] <eduardo> but ffmpeg and x265 are mising form the repositories list [05:52:02 CEST] <eduardo> :S [05:52:14 CEST] <relaxed> eduardo: https://www.johnvansickle.com/ffmpeg/ [05:52:57 CEST] <eduardo> oh and relaxed: i couldnt rin ./configure on ffmpeg, shoots me the error i just described [05:53:34 CEST] <relaxed> error or not, config.log is still created [05:54:30 CEST] <eduardo> i see, let me look for it [05:56:14 CEST] <relaxed> noobe1: I think you want out%04d.Y [05:58:35 CEST] <relaxed> eduardo: cd to the ffmpeg source dir and run the following: tail -n 50 config.log | curl -F 'sprunge=<-' http://sprunge.us [05:59:38 CEST] <eduardo> i found it already, ill pass the pased copy in a sec [06:00:40 CEST] <eduardo> here it is [06:00:42 CEST] <eduardo> http://pastebin.com/PPMFFgmC [06:02:47 CEST] <eduardo> http://sprunge.us/gMTc [06:03:33 CEST] <ferdna> eduardo, no they are not.. [06:03:36 CEST] <noobe1> I just tried it, it still outputs single file file (named out%04d.Y" [06:03:40 CEST] <ferdna> make sure your mirrors are up to date... [06:04:35 CEST] <noobe1> my full command line is: ffmpeg.exe -i video.mp4 -c:v rawvideo -f rawvideo -pix_fmt yuyv422 out%04d.Y [06:05:10 CEST] <relaxed> remove -f rawvideo [06:05:22 CEST] <noobe1> damn, that does it!! Thanks a bunch!! [06:06:15 CEST] <eduardo> maybe need to add some mirrors??? i just installed this distro [06:06:32 CEST] <relaxed> eduardo: did you install libx265-dev? [06:07:08 CEST] <eduardo> i think so, let me double check [06:09:00 CEST] <eduardo> i installed libx265 [06:10:57 CEST] <eduardo> i used this command sequence: http://pastebin.com/3DhgNkKP [06:23:21 CEST] <noobe1> relaxed, I ran an experiment, took a test.mp4 files (with a ball moving horizontally across screen), dumped the mp4 to video.yuv raw. Then took the video.yuv and converted it back to test.mp4. Now test.mp4 does not play as smooth as original file (ball stutters at times) Any ideas? Here is 2nd command I used: ffmpeg -f rawvideo -pix_fmt yuyv422 -s:v 1920x1080 -r 30 -i video.yuv -c:v libx264 output.mp4 [06:31:33 CEST] <noobe1> never mind, it was probably a computer loading from disk glitch...playing the file over and over is smooth. Thanks. [10:09:54 CEST] <Evert___> Hello! [10:10:49 CEST] <Evert___> I need some help. I'm building an app for a client and that app needs ffmpeg with its non-free features. So my client will need to pay ffmpeg license costs, but I can't find anywhere how much that is. [10:11:22 CEST] <Evert___> Can anybody tell me where I can find that? My client needs to know to decide whether they want to move forward with ffmpeg or try another strategy. [10:11:47 CEST] <furq> that's not what non-free means [10:12:07 CEST] <furq> non-free means the binary is no longer gpl compatible [10:12:47 CEST] <Evert___> which means what exactly? I thought that meant that the binary requires another license, a payed license. [10:13:26 CEST] <Evert___> On this page (http://www.ffmpeg.org/legal.html) it says: [10:13:34 CEST] <Evert___> Q: Is it perfectly alright to incorporate the whole FFmpeg core into my own commercial product? A: You might have a problem here. There have been cases where companies have used FFmpeg in their products. These companies found out that once you start trying to make money from patented technologies, the owners of the patents will come after their licensing fees. Notably, MPEG LA is vigilant and diligent about collecting for MPEG-relate [10:13:44 CEST] <furq> yeah that's distinct from nonfree [10:14:00 CEST] <furq> e.g. x264 only requires --enable-gpl, but you need a license to encode h.264 [10:14:13 CEST] <furq> certainly to do that in a commercial product [10:14:34 CEST] <furq> nonfree just means you'll be violating the gpl if you distribute binaries [10:14:37 CEST] <Evert___> and that license comes from ffmpeg? or mpeg itself? [10:14:48 CEST] <furq> from whomever issues the license for h264 these days [10:14:53 CEST] <furq> i think it's mpeg-la [10:14:58 CEST] <furq> ffmpeg doesn't issue any licenses [10:15:24 CEST] <Evert___> hmm okay, I'm slowly starting to get it [10:15:49 CEST] <Evert___> I'm a little but confused about one thing, what's the difference between x264 and h.264? [10:15:56 CEST] <furq> x264 is an h264 encoder [10:16:07 CEST] <Evert___> ah oké [10:16:18 CEST] <Evert___> *okay (oké is my language) [10:16:35 CEST] <Evert___> Thank you [10:16:41 CEST] <furq> i'm not sure what you'd do if you need nonfree components [10:18:17 CEST] <furq> if your client isn't distributing binaries then i guess it's not an issue [10:18:44 CEST] <furq> if they are then i don't know how you'd make that gpl compliant [10:19:23 CEST] <Evert___> To give you an idea of what we're doing: we have an app for iOS and Android and in that app users can upload a video to our server. Then other users can play that video. But we found out that Android users can [10:20:07 CEST] <Evert___> *Android users can't play all the videos coming from iOS. So we were planning on converting all the videos on the server after uploading, to a format that both operating systems can play. [10:20:15 CEST] <Evert___> Which would be h.264 [10:20:30 CEST] <furq> if you're just using ffmpeg on the backend then you don't need to care about gpl compliance (afaik) [10:20:45 CEST] <furq> you'll probably need to care about licensing h264 though [10:20:51 CEST] <Evert___> Are you sure? Because we're still using it for commercial reasons. [10:21:05 CEST] <Evert___> Yes okay, that's what I meant [10:21:32 CEST] <Evert___> Okay, then I'll try to find out who we need to pay for h264 and how much. [10:22:02 CEST] <furq> nonfree is used for libraries which have a gpl-incompatible license, which means you can't distribute binaries [10:22:46 CEST] <Evert___> Yes I think I get that now :-) [10:22:47 CEST] <furq> if you're not doing that then it should be fine [10:23:45 CEST] <furq> you'll probably also need a license for aac [10:23:56 CEST] <furq> those are issued by via afaik [10:23:57 CEST] <Evert___> we're using mp3 [10:24:00 CEST] <furq> oh [10:24:02 CEST] <furq> never mind then [10:24:12 CEST] <Evert___> does that have no license costs? [10:24:18 CEST] <furq> i don't know about mp3 [10:24:21 CEST] <furq> most of the patents have expired now [10:24:26 CEST] <Evert___> cool [10:24:31 CEST] <furq> you'll obviously want to check though [10:24:36 CEST] <Evert___> Too bad that the question "how much do I need to pay for h264?" isn't easy to answer apparently [10:24:45 CEST] <Evert___> yes of course [10:24:46 CEST] <furq> yeah codec licensing is a pain [10:25:00 CEST] <furq> just be glad you're not using h265, there are three different licensing bodies for that [10:25:06 CEST] <furq> and i think you need all three licenses [11:14:47 CEST] <Spring> is there any downside to using -static-thresh to '0' for regular, moving videos? [11:15:28 CEST] <Spring> by moving I mean videos with a standard amount of movement in the scene [11:16:22 CEST] <Spring> using libvpx [13:31:57 CEST] <Heniek> Hi guys. If I am using only decoding part of ffmpeg is it possible for me to get to the original data of a frame? I mean, I am receiving a h264 stream and I would like to save its contents to disk, does any pointer in AVFrame contains original data? [13:34:27 CEST] <nonex86> AVPacket contains original data [13:34:46 CEST] <nonex86> if you are using ffmpeg api for demuxing [13:35:06 CEST] <nonex86> AVFrame is a result of decoding original data [13:36:03 CEST] <nonex86> if you are using any other api to get the real data, guess you already have it :) [13:38:14 CEST] <Heniek> thank you:) [14:07:02 CEST] <hamidi> hi [14:07:28 CEST] <hamidi> please give me a way to generate or download FFmpegInvoke.cs [14:07:50 CEST] <hamidi> i'm going to change the version of ffmpeg in our project to the latest. [14:08:01 CEST] <hamidi> i replaced ffmpeg dll's [14:08:20 CEST] <hamidi> but it seems that it's required to replace FFmpegInvoke.cs too. [14:08:27 CEST] <hamidi> i don't know much about it though [14:14:14 CEST] <hamidi> no one knows? [14:47:40 CEST] <nonex86> this is some kind of ffmpeg interop wrapper? [14:47:47 CEST] <nonex86> why dont you just google this name? [16:21:04 CEST] <bornpilot> Greetings I was looking the difference between the video file in AVCHD and mp4 files both were h264 compresssion using a JVC camcorder [16:21:21 CEST] <bornpilot> I used the following command to get the stream information. [16:21:42 CEST] <bornpilot> ffmpeg -i file.mts and ffmpeg -i file.mp4 [16:22:02 CEST] <bornpilot> here were the difference in the stream info about h264 [16:22:03 CEST] <bornpilot> h264 (high) (avc1 / 0x31637661) [16:22:04 CEST] <bornpilot> h264 (high) (HDPR / 0x332D4341) [16:22:20 CEST] <bornpilot> my question is what is avc1 and HDPR? [16:23:28 CEST] <bornpilot> I searched through the ITUs document on h264 and could not find avc1 nor HDPR. [16:23:52 CEST] <bornpilot> avc1 came from the mp4 file and HDPR came from the AVCHD file [16:42:12 CEST] <c_14> That's the codec tag [16:45:01 CEST] <bornpilot> c_14 so h264 is the compression and HDPR/avc1 would be the codec? [16:45:19 CEST] <c_14> no [16:45:43 CEST] <ozette> is there any way to make ffmpeg -ss operate faster on large files? [16:46:29 CEST] <Spring> ozette, which order do you have the command in within the full command? [16:46:46 CEST] <c_14> h264 is the codec (and stands for mpeg-4 part 10/mpeg-4 avc) and HDPR/avc1 is the tag, much like xvid is a tag for mpeg-4 part 2 video <- bornpilot [16:47:23 CEST] <c_14> ozette: https://trac.ffmpeg.org/wiki/Seeking [16:47:34 CEST] <bornpilot> thanks c_14 [16:48:18 CEST] <Spring> the wiki doesn't mention it but there's also the trim filter [16:48:25 CEST] <ozette> Spring: i can't see the full command at this moment, i will have to log it in my application, but it starts like ffmpeg -ss 162 -i file.mp4 [16:48:38 CEST] <Spring> so before the input, right. [16:48:43 CEST] <ozette> yes [16:49:48 CEST] <Spring> should be the fastest method using -ss. Could try the trim filter, alternatively. Not sure speed wise how it compares. [16:50:21 CEST] <Spring> I'd imagine since it's a filter it would be slower though [16:50:32 CEST] <bornpilot> c_14 so would it be correct that avc1 and HDPR are two subtypes withing h264? [16:50:37 CEST] <bornpilot> ^within [16:50:53 CEST] <ozette> i must say that i run it on a machine with 1gb ram, but 'top' shows me the command is only taking 5% of the mem [16:51:23 CEST] <kepstin> yeah, trim filter is slower since it decodes the whole stream, and just throws away frames that don't match the condition. But on some files where seeking doesn't work well, trim is handy to have. [16:51:28 CEST] <ozette> but really it has taken 94 minutes already to generate 20 thumbnails for a 5Gb video file [16:51:33 CEST] <ozette> and it's still not done [16:52:08 CEST] <Spring> geez [16:53:06 CEST] <ozette> yes.. [16:53:49 CEST] <kepstin> bornpilot: better to say that "avc1 and HDPR are two different ways of storing h264 video in an mp4/iso/mov type container" [16:54:40 CEST] <kepstin> bornpilot: those tags are defined by the container specifications, not the codec specs. [16:55:19 CEST] <c_14> ozette: what codec is the input? [16:55:38 CEST] <bornpilot> I see, so they dont refelct on the how of the encoding proecess but the the container storage mechanisim? [16:56:20 CEST] <ozette> mpeg4 [16:56:49 CEST] <Spring> that doesn't sound right, unless it's a /really/ slow system or the command has been interrupted (I've had this happen where pressing a key in the command prompt has caused ffmpeg to stall indefinitely) [16:57:16 CEST] <ozette> i've had this before as well, but i'm quite sure the command will return [16:57:48 CEST] <c_14> Something must be weird with the command it's using. [16:57:53 CEST] <ozette> it's part of an application, which is supposed to go to production, and two video were uploaded, one of 1.5Gb and 5Gb [16:58:06 CEST] <ozette> the 1.5Gb took about 1 hour [16:58:44 CEST] <c_14> ozette: check top/ps to get the full commandline it's using [16:58:46 CEST] <ozette> the command is generated by some library and from what i remember, it's pretty standard, i'd have to log the command again to see what it's doing [16:59:16 CEST] <ozette> c_14: the command is cut off by the screen [16:59:39 CEST] <ozette> any other way to see it? [16:59:54 CEST] <furq> ozette: if you're generating thumbnails you probably want -skip_frame nokey -vf thumbnail [17:00:00 CEST] <Spring> you could use the -report option to log to file, AFAIK it includes the command used [17:00:15 CEST] <ozette> furq: interesting [17:00:16 CEST] <furq> you'll definitely want -skip_frame nokey because it makes decoding much faster [17:00:24 CEST] <c_14> ozette: cat /proc/$pid/cmdline [17:00:33 CEST] <furq> -vf thumbnail will potentially use a ton of memory [17:00:45 CEST] <ozette> what does -vf do [17:00:50 CEST] <furq> video filter [17:00:51 CEST] <ozette> c_14: will try [17:00:53 CEST] <ozette> ah [17:01:05 CEST] <furq> thumbnail is a bit awkward to use but it gives good results [17:02:17 CEST] <ozette> nice, will share the cmdline in a second [17:07:37 CEST] <ozette> ok this is kind of silly, but it's one very l7ong line: http://paste.debian.net/853899/ [17:09:33 CEST] <ozette> there's no whitespace between those flags, didn't know that was possible [17:09:45 CEST] <c_14> This has got to be one of the most inefficient ways to get at thumbnails I have yet to see [17:09:52 CEST] <c_14> ozette: /proc/cmdline is stripped of spaces [17:09:56 CEST] <ozette> oh [17:10:13 CEST] <ozette> i see -map [17:10:23 CEST] <c_14> You can get at the line with spaces somehow but I don't know how right now and the ps man page is terrible [17:10:33 CEST] <furq> this looks like it's been cut off [17:10:34 CEST] <ozette> haha nvm :) [17:10:38 CEST] <ozette> cut off? [17:10:49 CEST] <ozette> it goes all the way to the right [17:10:50 CEST] <furq> it ends in the middle of filter_complex [17:10:58 CEST] <c_14> furq: https://paste.debian.net/plain/853899 [17:11:01 CEST] <c_14> use the raw paste [17:11:21 CEST] <ozette> oh right thanks [17:11:29 CEST] <furq> oh nvm i was reading it wrong [17:11:35 CEST] <furq> that's -map [17:11:37 CEST] <c_14> It basically splits the input into 20 copies and then seeks to arbitrary timestamps in each output and outputs one frame with -vframes 1 [17:11:38 CEST] <ozette> the plain is much better [17:12:20 CEST] <furq> yeah i assume this is decoding the first 162 seconds 20 times [17:12:24 CEST] <furq> and so forth [17:12:42 CEST] <ozette> aren't the timestamps 'precise'? shouldn't that make it more fast? [17:13:21 CEST] <c_14> any seeking that happens in the output is slow because every frame is decoded and then the timestamps are checked on each frame [17:13:44 CEST] <furq> yeah -ss after -i is slower [17:13:47 CEST] <ozette> so there's no way to make thumbnails in a more efficient way? [17:13:48 CEST] <Spring> can the .MSS even extend that far?I thought it was only three digits [17:13:53 CEST] <furq> ozette: the thumbnail filter [17:14:08 CEST] <furq> the issue with it is that you can't tell it how many thumbnails to spit out [17:14:21 CEST] <furq> or you can, but only by dividing the total number of frames [17:15:33 CEST] <c_14> furq: can't you use -frames:v number_of_frames wanted [17:15:35 CEST] <c_14> ? [17:15:51 CEST] <ozette> in this case it says -ss first and then -i and then more -ss [17:15:55 CEST] <furq> yeah but i assume he wants an even distribution [17:16:14 CEST] <ozette> in this case, i use a library and i just say i want 20 thumbs [17:16:19 CEST] <c_14> yeah, then you'll have to count input frames (or guess input frames) and average [17:16:25 CEST] <furq> ozette: http://vpaste.net/GKtlx [17:16:31 CEST] <furq> that's more or less what i ended up with when i was doing something similar [17:16:37 CEST] <ozette> i can provide additional flags, but the way it works now i leave that up to the library [17:16:45 CEST] <furq> er [17:16:46 CEST] <ozette> oh thanks [17:16:52 CEST] <furq> change $file to $1 [17:17:01 CEST] <furq> also that will use a lot of memory [17:17:06 CEST] <c_14> And you might want to adjust the scale [17:17:20 CEST] <furq> putting scale before thumbnail is slower but uses less memory [17:17:58 CEST] <bornpilot> so is there or difference in quality between AVCHD h264 and mp4 h264? [17:18:31 CEST] <ozette> what does skip_frame nokey do exactly? [17:18:40 CEST] <furq> it skips non-keyframes [17:18:52 CEST] <c_14> bornpilot: in general, no [17:18:58 CEST] <ozette> ah [17:19:09 CEST] <furq> it makes decoding much faster [17:19:19 CEST] <furq> it will also use less memory with thumbnail [17:19:30 CEST] <furq> if it still uses too much memory then use the select filter as well [17:21:25 CEST] <bornpilot> thanks c_14 [17:22:48 CEST] <ozette> okay, thanks i will add -skip_frame nokey to the command and see if there's a significant difference [17:23:45 CEST] <furq> if you mean the command you pasted then i would just throw that in the bin [17:23:54 CEST] <furq> you'll have to print it out first but it'll be worth it [17:23:55 CEST] <ozette> i can't imagine why scale before thumbnail would be slower, unless the command is interpretted from right to left [17:24:11 CEST] <furq> scale after thumbnail only scales the output frames [17:24:35 CEST] <furq> thumbnail=50 will keep 50 raw frames in memory so it can pick the "best" one [17:24:52 CEST] <furq> you can imagine that eats memory pretty quickly with higher numbers [17:33:52 CEST] <ozette> so if scale is before thumbnail, it'd scale all raw frames? [17:34:11 CEST] <furq> yes [17:34:18 CEST] <ozette> ah [17:40:21 CEST] <trueroll> hi, I'm trying to build ffmpeg 3.1.3 Android with the NDK r12b Clang compiler [17:41:02 CEST] <trueroll> I'm getting a compiler test error from configure file [17:42:10 CEST] <trueroll> any help would be great! (btw I can build w/ gcc but Google is not including gcc in the NDK in the next version) [17:42:45 CEST] <c_14> trueroll: upload the last 50 or so lines from your config.log to a pastebin service [17:43:35 CEST] <trueroll> ok just a sec [17:45:38 CEST] <trueroll> http://pastebin.com/guj2Bkqk [17:49:15 CEST] <c_14> Can you upload your configure line to a pastebin as well? [17:49:32 CEST] <trueroll> sure [17:51:01 CEST] <trueroll> http://pastebin.com/QG7aihW7 [17:55:29 CEST] <c_14> I'd start by getting rid of all the extra-cflags that don't list extra include dirs [17:56:15 CEST] <furq> i assume you want to change -mcpu=armv7-a [17:57:23 CEST] <trueroll> @furq yeah I'll try that real quick [17:57:37 CEST] <trueroll> @c_14 you mean all the enable/disables? [17:57:47 CEST] <c_14> Also, can you check config.log for "defined __ARM_ARCH_" [17:58:18 CEST] <c_14> trueroll: no, the --extra-cflags stuff, specifically the -marm, -mcpu=, -mfpu= ones [17:58:22 CEST] <c_14> ffmpeg _should_ set those itself [17:58:50 CEST] <trueroll> __ARM_ARCH_ appears a lot [17:59:00 CEST] <trueroll> ah ok I'll remove those [18:01:12 CEST] <c_14> I'm mainly interested in what probe_arm_arch() returns in the configure script, you could just add `echo "$cpu"' to line 4298 [18:02:24 CEST] <trueroll> k [18:05:56 CEST] <flux> hmm, I wonder if ffmpeg's mov fragmentation and http post uploading should work together? [18:07:47 CEST] <flux> oh, user error. it does! why would anyone use rtmp over this.. :) [18:08:46 CEST] <flux> doesn't seem like it flushed the last segment, though.. could be another user error ;) [18:21:50 CEST] <trueroll> @c_14 that never gets hit I think [18:25:49 CEST] <TwinTailed> flux: I made the debugging steps you told me to do. avcodec_send_frame receives and successfully processes all audio frames, but avcodec_receive_packet doesn't process all frames, there is a missing one [18:26:07 CEST] <TwinTailed> flux: and I guess it is getting missed in an AVERROR(EAGAIN) error [18:31:31 CEST] <TwinTailed> flux: or maybe getting lost in EOF [18:35:34 CEST] <trueroll> @c_14 I think this might be the problem http://pastebin.com/wh8QAJZU [18:38:03 CEST] <trueroll> __ARM_ARCH_7A_ is not getting set and neither is __TARGET_ARCH_7_A [19:01:10 CEST] <c_14> yeah, something's weird there [19:01:18 CEST] <c_14> I don't know much about arm though [19:10:42 CEST] <trueroll> thanks for taking a look though [19:11:33 CEST] <c_14> have you tried asking on the ffmpeg-user mailing list? [19:15:15 CEST] <trueroll> not yet, that's a good next step though right? [19:15:24 CEST] <c_14> yes [19:16:14 CEST] <trueroll> ok I'll do that soon [21:26:33 CEST] <TwinTailed> flux: I made the debugging steps you told me to do. avcodec_send_frame receives and successfully processes all audio frames, but avcodec_receive_packet doesn't process all frames, there is a missing one [21:26:34 CEST] <TwinTailed> flux: or maybe getting lost in EOF [21:26:45 CEST] <TwinTailed> flux: I made the debugging steps you told me to do. avcodec_send_frame receives and successfully processes all audio frames, but avcodec_receive_packet doesn't process all frames, there is a missing one [21:29:08 CEST] <Polochon_street> Hi! I use ffmpeg to decode songs into raw arrays, but I've encountered a case where ffprobe says the file is « pcm_s16le ([1][0][0][0] / 0x0001) » which I assume is already RAW data. So it obviously fails at the avcodec_open() step; what should I do to handle these kind of files ? [21:31:30 CEST] <c_14> avcodec_open2 should work just fine [21:31:36 CEST] <c_14> There is AV_CODEC_ID_PCM_S16LE [21:57:10 CEST] <Polochon_street> c_14: okay, so I need to look for other clues then. Thanks! [22:58:34 CEST] <Wilawar> I tried to reverse a video (including audio) with ffmpeg.exe. The command I used is >> ffmpeg.exe -i '.\dj quicksilver ameno en reversa-jiRAePUYlvM.webm' -vf reverse -af reverse -vcodec vp8 -acodec libvorbis Ameno_Quicksilver_Rw.webm << [22:59:02 CEST] <c_14> you will most likely run out of memory on that [22:59:13 CEST] <c_14> and I'm not sure it works for audio [22:59:28 CEST] <c_14> ah, areverse insteod of reverse for audio [22:59:48 CEST] <Wilawar> When I tried it with the build dated 2016-04-25, the video I got stuttered in VLC (I just remembered I wanted to try it in some other player; sorry, will do that now) & [23:00:14 CEST] <Wilawar> but when I used the 2016-10-03 build from Zeranoe (Im on Vista), it outright crashed [23:00:51 CEST] <c_14> Like I said, if your video is long enough or of high enough resolution you'll run out of memory and the kernel will kill it [23:01:42 CEST] <Wilawar> So, Ill try it in MPC, then if it doesnt work paste the log. There was no weird stuff in it besides "[libvorbis @ 0207d700] Queue input is backward in time", which I got very often and "[webm @ 02116c60] Non-monotonous DTS in output stream 0:1; previous: 38780, current: 38763; changing to 38780. This mayresult in incorrect timestamps in the output file." [23:01:58 CEST] <Wilawar> c_14: First, the Windows kernel wont do that, second, its short enough [23:02:02 CEST] <Wilawar> :) [23:02:22 CEST] Action: c_14 doesn't actually know what the windows kernel does when it runs out of memory but it's got to do something [23:02:54 CEST] <Wilawar> It will make the machine come to a halt through paging [23:03:09 CEST] <c_14> What's it do when your hdd runs out of space? [23:03:14 CEST] <Wilawar> Also, the video is rather low res; as this was just for a quickly done try out of curiousity, I requested the 360p version [23:03:51 CEST] <Wilawar> c_14: The program will get an error from the WriteFile call!? [23:04:38 CEST] <c_14> Shouldn't it get an error from malloc? [23:05:21 CEST] <Wilawar> What does malloc have to do with the HDD? [23:05:35 CEST] <c_14> well, if you run out of ram the kernel starts paging [23:05:43 CEST] <c_14> So what if it runs of out space for the pagefile [23:06:18 CEST] <Wilawar> The program will get an error response to VirtualAlloc (or whatever it used to allocate memory) [23:06:40 CEST] Action: c_14 is pondering if he can completely lock a windows system by requesting infinite memory and not responding to errors [23:06:44 CEST] <Wilawar> If Windows really runs out of commit space, then yes, it might kill programs, though I havent seen this happening [23:07:03 CEST] <c_14> Out of purely scientific curiosity, of course. [23:08:23 CEST] <Wilawar> Getting the physical memory used percentage into the realm of over 95% has the same effect and since Im always short on RAM (only 4GiB here and not even patched my kernel for PAE), I experience this way too frequently :| [23:08:51 CEST] <Wilawar> Btw, the video is still stuttery in MPC-HC, though it doesnt outright drop out as with VLC [23:09:49 CEST] <Wilawar> Windows does a very shitty job on taming ill-behaving programs [23:10:32 CEST] Action: c_14 is testing the command on one of his videos [23:10:36 CEST] <c_14> I keep forgetting how slow vp8 is [23:11:13 CEST] <Wilawar> Like, I dont think it even attempts at all. Setting the priority to Idle in Process Hacker or even the IO priority to Very Low (which the Task Manager, the one that comes with Windows, doesnt even offer) can do wonders [23:13:02 CEST] <c_14> Output video works fine here [23:13:19 CEST] <Wilawar> Ill retry with the MP4 version. If you wanted to try it on the video Ive got: I grabbed it with 'youtube-dl.exe --no-mtime https://www.youtube.com/watch?v=jiRAePUYlvM -f 43' [23:13:30 CEST] <Wilawar> -f 18 is the MP4 version [23:14:47 CEST] <c_14> All these fun libvorbis warnings [23:16:26 CEST] <c_14> output works fine here [23:16:30 CEST] <c_14> no stuttering no nothing [23:16:33 CEST] <Wilawar> Hm :| [23:17:02 CEST] <Wilawar> At least libx264 and aac arent giving off warnings all the time [23:17:34 CEST] <c_14> https://dl.c-14.de/t/out.webm [23:17:42 CEST] <c_14> try playing that in your player to see if it causes the same problems [23:18:14 CEST] <c_14> That way we can find out if it's the player or your version[s] of ffmpeg [23:18:19 CEST] <Wilawar> The mpeg4 one seems to be fine [23:18:57 CEST] <Wilawar> It just occured to me, maybe my CPU isnt strong enough to do the SW decode? [23:19:11 CEST] <Wilawar> But its very low-res & [23:19:12 CEST] <c_14> for vp8? [23:19:16 CEST] <c_14> don't think that should be an issue [23:19:52 CEST] <Wilawar> I can watch h264 720p video in Firefox although it doesnt use my GPU [23:20:05 CEST] <Wilawar> But I do have to make sure nothing else is running in the background [23:20:18 CEST] <Wilawar> But yeah, MP4 seems to be fine [23:20:26 CEST] <Wilawar> Ill grab your file [23:22:14 CEST] <Wilawar> Ach, a Deutscher! ;) [23:22:33 CEST] <Wilawar> <-- Frange [23:24:38 CEST] <Wilawar> c_14: Yours cuts out, too [23:24:46 CEST] <Wilawar> (in VLC) [23:25:31 CEST] <Wilawar> Its only the audio, however, the video continues to run [23:26:05 CEST] <Wilawar> Since the other one worked fine, maybe I should take this to #videolan? [23:26:34 CEST] <c_14> probably [23:26:39 CEST] <Wilawar> Lots of "core warning: playback way too early (-1624945): playing silence" in the logs [23:27:27 CEST] <Wilawar> CPU usage was in check during playback [23:27:48 CEST] <Wilawar> Do you mind linking to your version? [23:28:09 CEST] <Wilawar> Or is your monthly bandwith use restricted? [23:28:26 CEST] <c_14> I don't mind [23:28:35 CEST] <c_14> But it gets deleted in 6 hours [23:28:43 CEST] <c_14> If you think you need it for longer I can create a permanent link [23:28:46 CEST] <Wilawar> Hmm, should suffice) [23:30:51 CEST] <Wilawar> On the other hand, there are also audio cutouts in MPC & [23:32:06 CEST] <Wilawar> So maybe it _is_ ffmpeg that fails encoding the file properly. Im undecided [23:32:32 CEST] <Wilawar> c_14: Did you get errors about wrong timestamps, too? [23:32:39 CEST] <c_14> yep [23:32:43 CEST] <c_14> warnings [23:32:48 CEST] <Wilawar> Right [23:36:17 CEST] <Wilawar> Oh, didnt know WMP could play back webm [23:36:35 CEST] <Wilawar> Less errors than VLC [23:37:34 CEST] <Wilawar> Any other media player (which doesnt rely on FFmpeg) to try? [23:39:16 CEST] <TD-Linux> a web browser [23:40:02 CEST] <c_14> recent chrome uses libav* though, doesn't it? [23:40:14 CEST] <c_14> so firefox or ie I guess [23:41:04 CEST] <TD-Linux> for vp8 and vp9? chromium uses libvpx, firefox uses ffvp8/9, but sounds like you have a container issue [23:44:01 CEST] <Wilawar> TD-Linux: Good point, no issues in Firefox 51.0a2 (Dev Edition) [23:50:09 CEST] <Wilawar> Other than trying to destroy my hearing (seriously, why is 100% volume the default everywhere!?) and my speakers, it doesnt cut out with ffplay, though the video seems to slow down often [23:53:21 CEST] <Wilawar> (if you wonder, I wanted to write 'its fine with ffplay when I noticed the slowdowns 'Other than [&] it doesnt cut out' doesnt make sense, of course) [23:58:27 CEST] <Wilawar> Ok, I opened the MP4 one for comparison (that ones truly fine) and I found that whereas the video slowdowns are rather easily noticable with ffplay, there are, indeed, short audio cut-outs with it, though I didnt notice them on the first go. [23:59:51 CEST] <Wilawar> I & think [00:00:00 CEST] --- Tue Oct 4 2016

1 0

ffmpeg-devel.log.20161002
by burek 03 Oct '16

03 Oct '16

[00:09:46 CEST] <Chloe> Anyone got comments on my latest developer guidelines cleanup/restructure patch? I'd like to get some input from other devs as well, as it's meant to be for us anyway [00:26:47 CEST] <Chloe> jamrial: yes >.< I did notice that just after I asked for comments [01:10:49 CEST] <Chloe> hopefully this version's changes are more legible [01:25:12 CEST] <philipl> BtbN: which hardware are you testing your alignment change with? [01:25:22 CEST] <BtbN> GTX 1060 [01:25:27 CEST] <philipl> With my 1080 I'm not seeing a difference [01:25:34 CEST] <philipl> I'm getting ~500 either way [01:26:10 CEST] <BtbN> hm, there should not be any difference between those card [01:26:16 CEST] <philipl> might just be raw horsepower [01:26:28 CEST] <philipl> memcpy could be faster. [01:26:30 CEST] <BtbN> It's the exact same video engine silicon on both [01:26:40 CEST] <philipl> Yes, but it's the memcpy that you're speeding up, right? [01:27:02 CEST] <BtbN> Probably, and encoding. [01:27:17 CEST] <BtbN> As it operates on 256byte blocks of data [01:27:36 CEST] <BtbN> so it needs at least a 256 bytes alignment for optimal performance [01:27:59 CEST] <BtbN> The memcpy should also benefit from it [01:27:59 CEST] <philipl> Makes sense. [01:28:24 CEST] <philipl> Well, I get 500fps and 100% video utilization (according to nvidia-settings) either way. [01:28:29 CEST] <philipl> For whatever it's worth. [01:28:44 CEST] <BtbN> Are you running the card on native PCIe 3.0? [01:28:47 CEST] <philipl> yes [01:28:49 CEST] <BtbN> Cause my board only supports 2.0 [01:29:00 CEST] <BtbN> so the interface is only half as fast [01:29:17 CEST] <philipl> Yeah, but that's only for pushing the frames to cuvid. After that it should stay on the card in both cases. [01:29:24 CEST] <BtbN> And a 1080 has _way_ faster RAM, GDDRX5 instead of just GDDR5 [01:29:55 CEST] <philipl> Right. So I suspect the memory operations are so fast that it is encoder limited without optimal alignment. [01:29:56 CEST] <BtbN> And I can see that making a difference for copying the frame around in VRAM [01:30:24 CEST] <philipl> Anyway, no harm. Just curious as to the difference between our configurations. [01:30:43 CEST] <BtbN> Aligning it does no harm, except for a tiny bit of wasted VRAM [01:31:52 CEST] <philipl> Right. [01:32:11 CEST] <philipl> If you want to see VRAM consumption - cuvid + 8k video in mpv is 2+ GB [01:34:18 CEST] <BtbN> Yeah, 8K frames are huge [02:10:25 CEST] <Chloe> Timothy_Gu: would .container work on the website as well? I found myself having to set margin: 0 auto; to get it to center on ffmpeg.org [03:29:44 CEST] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:635a89b0bb36: Changelog: Compress slightly to improve readability. [05:23:07 CEST] <Timothy_Gu> Chloe: IIRC the website doesn't use the FFmpeg build system [05:23:16 CEST] <Timothy_Gu> i.e. it has its own init files, etc. [05:23:45 CEST] <Chloe> right ok, I'll look into it in ffmpeg-web as well then [05:24:05 CEST] <Timothy_Gu> Chloe: the actual build scripts are actually not public [05:24:30 CEST] <Chloe> heresy [05:24:48 CEST] <Timothy_Gu> It was more for security reasons (which sound dubious) [05:25:13 CEST] <Chloe> can I PM you quick (unrelated)? [05:25:18 CEST] <Timothy_Gu> sure [07:18:09 CEST] <cone-075> ffmpeg 03James Almer 07master:42111e8543b1: avcodec: fix arguments on xmm/neon clobber test wrappers [11:49:15 CEST] <ubitux> Chloe: you have something that eat your trailing space after '--' in your mail signature [12:57:01 CEST] <wm4> how is multimedia so fucking broken that even timestamps have to be considered as noisy, unreliable data that needs to be filtered and smoothed before it's useful [14:06:37 CEST] <Chloe> ubitux: in patches, or just normal replies? because I type my signature every time for normal replies. (didn't know I needed a space after '--') [14:07:31 CEST] <ubitux> normal replies [14:07:39 CEST] <ubitux> yes you need a space or it's not recognized as a signature [14:09:33 CEST] <Chloe> I'll try set it up as an actual signature, I couldnt get it working before but I'll give it another shot [14:20:50 CEST] <michaelni> BBB, should 0f88b3f82fafd536979993aeaafcb11a22266dbd be backported to any releases like 2.8 ? [14:23:58 CEST] <BBB> your choice. I dont think it would hurt [14:24:12 CEST] <BBB> but its a relatively crazy case since it only affects very tiny images [14:24:34 CEST] <BBB> and one-byte overreads are not generally very interesting for taking over a computer because they only give you one byte to take over [14:24:40 CEST] <BBB> which is typically not enough [14:25:05 CEST] <BBB> but since it doesnt hurt I guess yes if you want to backport, I would support that [14:26:38 CEST] <michaelni> ok [14:30:41 CEST] <michaelni> locally backported to releases 2.8 .. 2.2 (does not apply to 2.1) [14:53:01 CEST] <Chloe> >Since you are not an idiot, you will use it. [15:01:50 CEST] <wm4> who wants to accuse him of CoC violation, since if you not follow his "advice" he implicitly called you an idiot? [15:40:47 CEST] <Compn> wm4 : vendor lock in [15:41:44 CEST] <wm4> not the correct reply [15:45:46 CEST] <Chloe> So I give him an *example* an he's like 'no this example isnt real', I'm just going to ignore advice from him (does this sound reasonable?). [15:46:06 CEST] <wm4> yes [15:47:14 CEST] <ubitux> ffmpeg devs nitpicking about web development practice [15:47:21 CEST] <ubitux> what an era to be in [15:49:47 CEST] <wm4> considering the era, it's a wonder there's no official ffmpeg js port yet [15:50:57 CEST] <BtbN> I think Twitch uses an emscripten compiled ffmpeg to make browsers capable of HLS [15:56:18 CEST] <Chloe> Using the container class works nicely (and also uses pixels); Timothy_Gu, thanks for the suggestion. [15:56:54 CEST] <cone-067> ffmpeg 03Marton Balint 07master:d14b240ecfc5: ffplay: use decoder avctx for decoded subtitle width/height [15:56:54 CEST] <cone-067> ffmpeg 03Marton Balint 07master:4fdcd2f1889a: ffplay: remove unused viddec_width/viddec_height [16:55:14 CEST] <bencoh> BtbN: hm, really? but do they actually decode in software using the resulting emscripten-compiled avcodec, or do they somehow pass it to the "native" browser decoder? [16:57:17 CEST] <BtbN> they remux from mpeg-ts to segmented mp4 with it. [16:57:28 CEST] <bencoh> and how do they pass the result? [16:57:32 CEST] <BtbN> MSE [16:57:38 CEST] <bencoh> nice [16:57:41 CEST] <BtbN> Browsers do support mp4, but not ts [16:57:45 CEST] <bencoh> yeah [16:57:56 CEST] <wm4> lol [16:57:58 CEST] <BtbN> So intead of making their backend support DASH, they translate from HLS to DASH in JavaScript [16:59:02 CEST] <BtbN> Because of that stupidity Microsoft Edge is now the best Browser to watch Twitch in. [16:59:21 CEST] <BtbN> It's, except for Safari, the only Browser which natively plays HLS, so they don't need the JS remuxer. [16:59:41 CEST] <bencoh> I actually thought about something like that back in early-MSE age, but for live mpeg-ts .... but never had the time to implem anything [16:59:46 CEST] <ritsuka> btw apple now supports fragmented mp4 in hls, so they could just use mp4& [16:59:47 CEST] <bencoh> (and I kinda hate web dev) [17:00:08 CEST] <BtbN> bencoh, Twitch is live? [17:00:43 CEST] <Chloe> BtbN: it's a livestreaming site [17:00:44 CEST] <bencoh> no I mean, real live TS stream, not some hls/hds/dash/progressive-like thing [17:00:48 CEST] <BtbN> ritsuka, aparently they don't want to touch their CDN and stuff to make it use segmented mp4/DASH instead of HLS. [17:01:22 CEST] <BtbN> HLS is a live ts stream. Just downloaded in fragments via http. [17:01:42 CEST] <bencoh> except you'd have to cut it right, or .... [17:02:04 CEST] <BtbN> No need for that. You don't even have to cut at keyframes [17:02:10 CEST] <kierank> 3:59 PM <bencoh> (and I kinda hate web dev) [17:02:11 CEST] <kierank> amen [17:02:23 CEST] <BtbN> Starting the stream might take a few segments to pass by, but it generally works [17:02:25 CEST] <bencoh> BtbN: you'd need to if you want to properly remux it as mp4 [17:02:37 CEST] <bencoh> at least I'd suppose so, I never went down that road [17:02:49 CEST] <BtbN> The clean solution for Twitch would have been to migrate from HLS to DASH [17:02:57 CEST] <BtbN> Every browser supports that. [17:03:07 CEST] <BtbN> But they seem to be affraid to touch their backend [17:03:14 CEST] <wm4> no dash demux impl. in ffmpeg yet? [17:03:34 CEST] <bencoh> kierank: :-) [17:32:34 CEST] <cone-067> ffmpeg 03Timo Rothenpieler 07master:b7bd5b979422: configure: define posix source on cygwin [17:39:52 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/e68383408e591c5bd006def60a06509d14534… does someone have a better algorithm/idea for this? [17:43:03 CEST] <wm4> is ++a+a even defined? [17:43:42 CEST] <BtbN> hm, good question. I'm expecting a++; a += (a == 0); [17:46:07 CEST] <wm4> also it should happen what happens with av_next_pow2(0) or av_next_pow2(higher than 2^ 63) [17:46:27 CEST] <BtbN> that's what the + (a == 0) is for. [17:46:39 CEST] <BtbN> It makes it return the next power of two even for 0. Which is 1. [17:50:37 CEST] <BtbN> Also works, kind of, as expected for UINT64_MAX - x [17:50:39 CEST] <BtbN> returning 1. [17:51:20 CEST] <wm4> should be documented then [17:51:45 CEST] <wm4> also I guess you could reuse the code for log2, and then simply check if it's a power of 2 or not [17:52:57 CEST] <BtbN> To return immediately if it is a power of two? [17:54:35 CEST] <kierank> isn't it a case of doing something like clz [17:54:52 CEST] <kierank> and then flipping all the other bits [17:54:55 CEST] Action: kierank thinks out loud [17:56:09 CEST] <BtbN> hmm [17:56:21 CEST] <BtbN> that would be limited to 32bit I think, but enough for my use [17:56:45 CEST] <wm4> for 64 bit you do it just twice [17:56:45 CEST] <kierank> iirc there is a 64-bit clz [17:57:22 CEST] <kierank> i wrote one but can't rmeember if it was for x264 or ffmpeg [17:58:21 CEST] <BtbN> well, I'm using it for aligning a resolution [17:58:30 CEST] <BtbN> those exceeding 32bit is quite unlikely [17:59:52 CEST] <jamrial> kierank: yeah, ff_ctz and ff_ctzll [18:00:23 CEST] <jamrial> wait no, my bad, that's ctz [18:00:49 CEST] <jamrial> there's ff_clz but no 64bit one it seems [18:01:25 CEST] <jamrial> pretty trivial to add if needed i guess [18:04:12 CEST] <BtbN> ff_clz returns strange value for 0. [18:04:17 CEST] <BtbN> Aparently that's not well defined. [18:04:27 CEST] <BtbN> ff_clz(0) -> 4195756 [18:07:25 CEST] <nevcairiel> clz with zero has no really defined meaning, no [18:08:12 CEST] <BtbN> a <= 1 ? 1 : 1 << (32 - ff_clz(--a)) [18:08:15 CEST] <BtbN> that seems to do it. [18:08:22 CEST] <jamrial> BtbN: you're using gcc? that's the output of __builtin_clz(0) then. try ff_clz_c [18:09:08 CEST] <BtbN> a resolution of 0 rarely ever happens. So I'll not care about that special case. [18:12:43 CEST] <kierank> bencoh: there is FFALIGN [18:12:49 CEST] <kierank> BtbN: [18:13:08 CEST] <BtbN> kierank, that doesn't align to the next power of two though, which is where CUDA is fastest [18:13:27 CEST] <kierank> oh i see [18:18:30 CEST] <BtbN> kierank, actually, i need both... [18:19:05 CEST] <BtbN> also needs to be 256 byte aligned. Which is a given for large resolutions with next_pow2, but not for small ones [18:48:27 CEST] <BtbN> wm4, what do you mean, "No decoder should ever have set the pts field [18:48:27 CEST] <BtbN> before"? [18:48:51 CEST] <BtbN> I think most of them do [18:49:12 CEST] <BtbN> oh wait, that's purely about audio. [18:50:36 CEST] <nevcairiel> no, decoders dont typically set that field [18:50:39 CEST] <nevcairiel> not e ven video [18:51:40 CEST] <nevcairiel> i tried t ofind occurances that set it, and it was only like or two external library ones that did it weirdly [18:51:40 CEST] <BtbN> hm, so cuvid and openh264 are the exceptions? [18:52:32 CEST] <wm4> if they do, they should be fixed [18:52:50 CEST] <wm4> also, does cuvid or something similar use the new decode API? [18:52:51 CEST] <BtbN> cuvid kind of has to set the pts itself, because of the opaque reordering [18:52:59 CEST] <BtbN> wm4, yes, cuvid uses it. [18:53:05 CEST] <BtbN> So far the only decodoer from what i know. [18:53:07 CEST] <wm4> because the new decode API doesn't set best_effort_timestamp from pkt_pts [18:53:15 CEST] <wm4> so ffmpeg.c behavior might be confusing [18:53:25 CEST] <wm4> I'll probably post a patch to change this [18:53:32 CEST] <BtbN> cuvid sets both pts and pkt_pts [18:53:46 CEST] <wm4> yeah but ffmpeg.c only reads best_effort_timestamp [18:54:00 CEST] <wm4> and only the "old" decode API sets best_effort_timestamp automatically [18:54:18 CEST] <BtbN> So that's just another field I should fill the pts in? [18:56:57 CEST] <wm4> BtbN: well, patch sent [18:59:30 CEST] <BtbN> so for cuvid to behave correctly, I should ignore frame->pts exists, set only pkt_pts, and copy that value to best_Effort_timestamp? [19:01:50 CEST] <philipl> It's great to have so many wrong ways to do things. [19:02:17 CEST] <BtbN> Why does the pts field even exist if nothing uses it? [19:02:42 CEST] <nevcairiel> its used for encoding [19:02:46 CEST] <wm4> and libavfilter [19:02:59 CEST] <wm4> Libav changed it so that decoding also sets this field [19:03:18 CEST] <BtbN> so if one is to use libavcodec for transcoding, he has to manually transfer pkt_pts to pts in between? [19:03:30 CEST] <nevcairiel> you also have to rescale the timebase and whatnot [19:03:35 CEST] <nevcairiel> so manual steps are required anyway [19:06:11 CEST] <Chloe> we allow random cosmetic patches, right? [19:06:21 CEST] <Chloe> (provided they are separate, and look like they have some use) [19:30:30 CEST] <Chloe> ubitux: regression as of 2.0.4 then? [19:30:41 CEST] <Chloe> SDL2 ffplay 'f' key thing [19:30:44 CEST] <ubitux> seems so [19:31:15 CEST] <ubitux> or misusage revealed by it [19:31:18 CEST] <ubitux> dunno [19:34:10 CEST] <jkqxz> BtbN: That cuda align-to-power-of-two patch feels dubious to me in the large cases (going up to 2048 or 4096?). Explicitly forcing that alignment has nasty effects on associative caches because nearby pixels all end up using the same cache index, and so evict each other. [19:34:44 CEST] <jkqxz> Does performance really continue to increase above 256-byte alignment? [19:36:18 CEST] <nevcairiel> 256 uses 2048 or 4096 for popular sizes anyway (1920 / 3840) [19:37:06 CEST] <nevcairiel> or not, 3840 is aligned [19:37:26 CEST] <BtbN> For 1280x720, where it has probably by far the largest impact, yes. [19:38:27 CEST] <BtbN> It's the difference between 80% and 100% Video Engine load. [19:38:54 CEST] <BtbN> Keep in mind that this aligns GPU Memory, not normal CPU memory [19:52:13 CEST] <philipl> BtbN: We seem to be beating the performance numbers in the nvidia docs. That's always nice. [19:56:24 CEST] <BtbN> sure they just weren't ever updated for pascal? [19:59:32 CEST] <philipl> they have a pascal column [20:39:28 CEST] <BtbN> Watching Twitch in Edge and using cuvid + nvenc at the same time is not something the driver likes. [20:39:30 CEST] <BtbN> It crashed. [21:04:12 CEST] <philipl> heh. [21:07:23 CEST] <BtbN> philipl, there's a new undocumented symbol in the nvcuvid.dll [21:07:27 CEST] <BtbN> cuvidResetDecoder [21:44:41 CEST] <philipl> BtbN: intriguing. [21:50:13 CEST] <philipl> BtbN: Well, it's not a trivial function. I guess it takes some flags to indicate how much to reset it. [21:50:46 CEST] <BtbN> Google has litteraly nothing about it [21:51:30 CEST] <philipl> I guess it's not a surprise. The implementation is distributed with the driver and so can get updated before there's an SDK release to go with it. [21:51:40 CEST] <philipl> Hopefully the next one documents it and flush can become less heavyweight [22:08:05 CEST] <BtbN> Hm, using Cuda from cygwin is... complicated [22:08:16 CEST] <BtbN> The cuda header thinks it's on linux, and thus uses cdecl instead of stdcall [22:08:48 CEST] <rcombs> >i386 calling conventions [22:10:01 CEST] <BtbN> fixed it by just editing cuda.h to hardcode it to stdcall. [22:11:00 CEST] <philipl> send a patch... [22:11:27 CEST] <BtbN> patch for what? [22:11:29 CEST] <BtbN> The NVidia? [22:11:32 CEST] <philipl> a joke. [22:11:37 CEST] <nevcairiel> screw cygwin and its "I'm linux" and "I'm windows" at the same time =p [22:11:56 CEST] <nevcairiel> it breaks so many things that actually work on windows natively otherwise [22:12:04 CEST] <BtbN> I wonder if ffmpeg would build in cygwin if It's put in the mode where it defined _WIN32 [22:12:17 CEST] <BtbN> Probably not [22:18:40 CEST] <BtbN> "cuvidCreateDecoder(&cudec, &cuinfo) failed -> CUDA_ERROR_NOT_SUPPORTED: operation not supported" [22:18:42 CEST] <BtbN> nope [22:18:47 CEST] <BtbN> something's still not right. [22:18:56 CEST] <BtbN> And I don't feel like finding out what [22:19:19 CEST] <Timothy_Gu> BtbN: what are you trying to do? [22:19:27 CEST] <BtbN> Use cuvid from cygwin [22:20:00 CEST] <BtbN> Getting it to builds needs a lot of hackery already [22:20:05 CEST] <Timothy_Gu> lol [22:20:06 CEST] <BtbN> But then it doesn't even work with said error [22:21:04 CEST] <BtbN> Had to generate new cuda implibs, because the ones coming with the CUDA sdk don't work with gcc. Not even mingw [22:21:36 CEST] <Timothy_Gu> sounds tedious [22:23:44 CEST] <BtbN> they generate a strange linker error with gcc, "relocation truncated to fit R_X86_64_PC32 against symbol cuInit" [22:24:52 CEST] <BtbN> And the usual way of generating one by generating a def from the dll with dlltool doesn't work either [22:25:03 CEST] <BtbN> because according to dlltool, nvcuda.dll does not have any symbols. [22:25:43 CEST] <BtbN> dependency walker can generate a list of imports though, so I made a .def from that, implib via dlltool, and it works. [22:27:18 CEST] <RiCON> BtbN: the .lib files work with mingw here [22:27:19 CEST] <RiCON> weird [22:27:29 CEST] <BtbN> From CUDA SDK 8? [22:27:42 CEST] <RiCON> pretty sure [22:27:47 CEST] <RiCON> i'm using msys2 though, not cygwin [22:28:01 CEST] <BtbN> I have the same issue with my mingw crosscompiler on native linux [22:28:12 CEST] <BtbN> So I guess it's a general issue with gcc and those libs [22:28:26 CEST] <RiCON> aren't you trying to use 32-bit libs in 64-bit or something? [22:28:30 CEST] <BtbN> no [22:28:56 CEST] <RiCON> i'll try again, just --enable-{cuda,cuvid}, right? [22:29:27 CEST] <BtbN> just --enable-cuda --enable-nonfree [22:29:34 CEST] <BtbN> and extra-cflags/ldflags for it to find stuff [22:32:04 CEST] <philipl> BtbN: You inspired me to run strings on libnvcuvid. There are references to P016 and NV24 conversions internally. [22:32:07 CEST] <philipl> Someday. [22:32:43 CEST] <BtbN> They are probably there to convert them to NV12 internally [22:32:49 CEST] <philipl> Yep. That's what it says :-) [22:32:50 CEST] <BtbN> Which it obviously has to be doing [22:38:53 CEST] <RiCON> BtbN: configure and make worked fine [22:39:00 CEST] <BtbN> strange [22:39:03 CEST] <BtbN> which gcc you got there? [22:39:17 CEST] <RiCON> 6.2.1 [22:39:18 CEST] <BtbN> x86_64-w64-mingw32-gcc (GCC) 5.4.0 [22:40:24 CEST] <RiCON> https://i.fsbn.eu/MDLZ.txt [22:42:36 CEST] <BtbN> I'll just stick to msvc for now. [22:43:13 CEST] <BtbN> colors and keyboard interaction, and cygwin paths, would just have been nice to have [22:43:37 CEST] <RiCON> that's what winpty is for [22:47:03 CEST] <BtbN> Do I just put those in my cygwin bin dir, and stuff works if prefixed with winpty? [22:48:19 CEST] <RiCON> yes [22:49:23 CEST] <RiCON> it should even convert unix paths to windows in arguments [22:50:14 CEST] <BtbN> cygwin should package that. [22:51:50 CEST] <BtbN> It doesn't convert the paths [22:51:58 CEST] <BtbN> but colors and keyboard interaction work [22:52:54 CEST] <RiCON> maybe it's just msys2's that does that then [22:53:23 CEST] <RiCON> until a few months it even tried to convert URLs so it was kinda useless [22:54:47 CEST] <Chloe> michaelni: did you see the split version of the the developer guidelines patch? [23:00:53 CEST] <BtbN> hm, I'm indeed unable to find any difference in speed/engine load compared to a plain FFALIGN 256 now. Probably something else was messing up the comparison [00:00:00 CEST] --- Mon Oct 3 2016

1 0

ffmpeg.log.20161002
by burek 03 Oct '16

03 Oct '16

[00:00:49 CEST] <iive> but they cover different things. [00:01:27 CEST] <iive> one covers expression, the other covers ideas. [00:25:10 CEST] <iive> hum, can't find good article on when mpeg2 patents expire. mpeg2 has been published at 1996, so 20 years have passed. [00:26:44 CEST] <iive> however, things are never so simple. e.g. mp3 was published in 1995 and it's last patent expires Decemper 2017, because it's been granted a few years after been filled in (and publication) [00:27:17 CEST] <iive> mpeg-la does publish list of expired patents, but i couldn't find list of when the rest would expire... [00:27:28 CEST] <iive> didn't look too hard. [02:59:49 CEST] <woodbeatstz> Can anyone suggest how to livestream from Linux?? [03:00:30 CEST] <woodbeatstz> I have ffmpeg installed on my remote server [03:00:52 CEST] <krs_> woodbeatstz: google ffmpeg streaming, you'll find some examples for twitch and others [03:01:50 CEST] <woodbeatstz> I have tried that and what I need is someone to set it up [03:02:17 CEST] <woodbeatstz> I am not a Linux guy I apoligize [03:04:37 CEST] <woodbeatstz> What would help is real samples of a Linux server running FFmpeg and doing a live stream [03:05:40 CEST] <woodbeatstz> I mean like a You Tube thing or LiveStream is that do able on a linux server? [03:09:21 CEST] <woodbeatstz> well thanks anyway [04:18:23 CEST] <fypz> hi, I need some help, I always followed the guides available on trac.ffmpeg.org and easily did it, but this new guide to integrate x265 in it is breaking my balls [04:19:57 CEST] <fypz> I follow all the steps, almost nothing to compile, but the command to compile ffmpeg says there has to be a configure file here : /home/me/ffmpeg_build/lib/pkgconfig [04:20:03 CEST] <fypz> well, there isn't [04:20:33 CEST] <fypz> so I can't do "PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \" [04:21:34 CEST] <furq> which guide are you following [04:21:45 CEST] <fypz> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [04:21:47 CEST] <fypz> this [04:21:53 CEST] <fypz> i'm on Linux Mint 17.3 [04:22:00 CEST] <fypz> so it should work [04:24:22 CEST] <fypz> only thing that was sketch was the compiling of libvpx, not sure if that was made right, some errors in make and make install, where it installed 6-7 things then said nothing to install [04:24:34 CEST] <fypz> after doing that : PATH="$HOME/bin:$PATH" make make install [04:24:42 CEST] <furq> do you have anything in $PREFIX/lib/pkgconfig [04:24:42 CEST] <fypz> for libvpx [04:25:49 CEST] <fypz> well, before it's in the lib directory, it's in ffmpeg_build which has "bin" "include" and "lib" [04:27:11 CEST] <furq> by $PREFIX i mean $HOME/ffmpeg_build [04:27:18 CEST] <furq> or whatever prefix you're installing to [04:28:13 CEST] <fypz> the ffmpeg I have running right now did not need those prefix and PATH things, I'm savvy enough to compile other programs generally, I made my own avidemux2.6.10-qt for example [04:28:29 CEST] <fypz> it's home/me/ffmpeg_build [04:31:01 CEST] <fypz> but whenever those show up, I didn't grasp what this kind of stuff ever meant, like I compiled the svn of kvirc, version 4.3.1, and I was copy pasting the cmake command because it was a long cmake command which I didn't understand, other than adding in some parameters to it, which is all in the txt for that one [04:32:48 CEST] <fypz> so excuse my ignorance, thankfully the x264 supporting ffmpeg guide did not have those PREFIX$ and PATH things, I got a vague idea of what they mean, especially PATH [04:33:50 CEST] <furq> i've never understood why debian/ubuntu guides complicate themselves with all that [04:33:59 CEST] <furq> the default prefix is fine there [04:34:02 CEST] <fypz> I modified VLC with a hg command I found somewhere to be able to play x265 files, but I need a x265-able ffmpeg for avidemux and other video programs [04:35:07 CEST] <furq> but yeah do you have [lib]x265.pc in $HOME/ffmpeg_build/lib/pkgconfig [04:35:56 CEST] <fypz> there's x265.pc there yes [04:36:16 CEST] <furq> pastebin your ffmpeg config.log then [04:36:17 CEST] <fypz> with fdk-aac.pc and vpx.pc [04:36:21 CEST] <furq> preferably the last 100 lines or so [04:37:30 CEST] <fypz> uhm, I don't where that is, and I don't think the ffmpeg I compiled myself logged anything like operations in a folder where it's own update is attempted to be compiled [04:38:10 CEST] <fypz> i mean, why would it [04:39:07 CEST] <furq> there should be a config.log in $HOME/ffmpeg_sources [04:39:23 CEST] <fypz> right, I'll open that [04:39:49 CEST] <furq> if the error message is "x265 not found using pkg-config" then it normally doesn't actually mean that [04:41:47 CEST] <fypz> no logs in ffmpeg_sources, just a x254 folder a libvpx-1.5.0 folder and the ffmpeg folder itself [04:42:04 CEST] <fypz> x265* [04:42:25 CEST] <furq> in ffmpeg/ then [04:42:43 CEST] <fypz> config.log ? [04:42:48 CEST] <furq> yes [04:42:52 CEST] <fypz> alright [04:45:11 CEST] <fypz> https://www.pastecry.pt/zCkzUV#Az5Ym4Faq0Nes7Zem2Nea0Geg9Pev [04:45:23 CEST] <fypz> the last 110 lines or so [04:45:57 CEST] <furq> there's no error there [04:47:32 CEST] <fypz> okay, but you've seen that the configure file that should be in home/me/ffmpeg_build/lib/pkconfig isn't there [04:47:41 CEST] <fypz> which prevents compilation from even happening [04:48:08 CEST] <furq> you just said it was there [04:48:12 CEST] <fypz> /ffmpegsources $ PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure \ [04:48:14 CEST] <fypz> > ^C [04:48:16 CEST] <fypz> fypz@fypz-desktop ~/ffmpegsources $ PATH="$HOME/bin:$PATH" PKG_CONFIG_PATH="$HOME/ffmpeg_build/lib/pkgconfig" ./configure --prefix="$HOME/ffmpeg_build" --pkg-config-flags="--static" -extra-cflags="-I$HOME/ffmpeg_build/include" --extra-ldflags="-L$HOME/ffmpeg_build/lib" --bindir="$HOME/bin" --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype--enable-libmp3lame --enable-libopu --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx2 [04:48:16 CEST] <fypz> 64 --enable-libx265 --enable-nonfree [04:48:18 CEST] <fypz> bash: ./configure: No such file or directory [04:48:20 CEST] <fypz> fypz@fypz-desktop ~/ffmpegsources $ [04:48:35 CEST] <fypz> no, I said it was missing lol [04:48:38 CEST] <furq> yeah configure is in ~/ffmpegsources/ffmpeg [04:48:49 CEST] <furq> i assume the guide thought you'd extract it directly in ~/ffmpegsources [04:48:55 CEST] <fypz> I just follow the guide [04:49:35 CEST] <fypz> the things you compile that you can't download from your distro all go into ffmpeg_build [04:50:37 CEST] <fypz> so you're saying I should ignore the whole PATH=@HOOME/bin:$PATH thing and just compile straight in the ffmpeg folder? [04:50:46 CEST] <fypz> with the parameters I want [04:50:51 CEST] <furq> no [04:51:00 CEST] <furq> cd ffmpeg [04:51:02 CEST] <furq> then run that command again [04:53:41 CEST] <fypz> that worked...I think I forgot to go back to the ffmpeg folder [04:53:43 CEST] <fypz> lol [04:53:53 CEST] <fypz> well, thanks a lot [04:54:24 CEST] <fypz> i'm on sick leave with real bad bronchitis, the hydrocodone cough syrup is making feel woozy [04:55:10 CEST] <furq> codeine is bad stuff [04:55:12 CEST] <fypz> thanks again for your time [04:55:16 CEST] <furq> or fun stuff, depending on which one of my friends you ask [04:55:28 CEST] <fypz> hydrocodone is different than codeine [04:56:09 CEST] <fypz> but they are both weak opiates, i just get a small 4oz bottle from my doc whenever I get those recurring fall bronchitis [04:56:20 CEST] <fypz> not enough to get hooked to [04:57:05 CEST] <fypz> cocktail of antibiotic/anti-tussive/antihistamine [04:58:00 CEST] <fypz> thankfully this time, I went to get rid of it fast, a few years ago it turned into pneumonia, had to take prednisolone on top of that to help breathing [04:58:11 CEST] <furq> nice [04:59:14 CEST] <fypz> but yeah, coughing so hard your rib bones hurt will likely get you a codeine or hydrocodone script and at least in Canada they are pure, in the US they add in things that are unneeded only to punish someone who would take more teaspoons than needed [04:59:24 CEST] <fypz> mostly that stuff is the real danger [05:00:09 CEST] <fypz> like that promethazine/codeine syrup..they get anticholinergic delerium from the promethazine if they try to misuse it [05:00:52 CEST] <fypz> but yeah, still glad it's illegal in Canada to add compounds to a medication only to punish or even kill an abuser [05:01:52 CEST] <fypz> alright, thanks again for your time [05:02:25 CEST] <fypz> that deserves a little money for your project, any way to support you [05:04:07 CEST] <fypz> oh last question, I've made a .deb from the ffmpeg I have in use right now using checkinstall, is that discouraged? I remember older guides using checkinstall [05:04:26 CEST] <fypz> a personal .deb for your own machine is always practical [07:07:41 CEST] <mccc> Hi, I'm using ffmpeg to constantly record segments (-f segment) to a directory I'm watching with systemd (DirectoryNotEmpty) so I can transfer them with rsync. My problem is I need to not transfer files until they are complete. [07:07:49 CEST] <mccc> Is there a way to get ffmpeg to write segments to a temporary file, and move the temporary file when complete? I'm not an expert in ffmpeg but looking through the docs, could that be implemented as a muxer? [07:41:37 CEST] <EugenA> hi, I'm trying to do streaming to rtmp server. I'm reading file, which is growing. ffmpeg cannot continuously read the file, but it stops. Can I avoid it somehow? [08:52:26 CEST] <mccc> I'm looking through segment.c and it seems to support this for the list file, but not for the segments. Unless I'm wrong I don't think this is supported. I'd love to hear confirmation either way if anyone knows. Thanks :) [09:04:31 CEST] <orge> http://pastebin.com/raw/g3xgcCsg if you look at the first two commands, you'll see that by advancing the seek point from 10.513 to 10.515 decreases the frame count from 374 to 125. since this is copying rather than transcoding, you would think this is casued by a key frame between those two seek points, right? but the third command shows that the only nearby key frame isn't between those time points [15:46:43 CEST] <Mumee> Hey :) I have a little question. I want to convert a mkv file to a mp4 file with the video and one audio stream. But I want the it have always the same language, now to my problem: if the source file dont have this language, how can I tell ffmpeg that it should use the first one? [16:08:42 CEST] <furq> Mumee: i don't think you can do that with a single command [16:08:48 CEST] <furq> you'd probably have to check ffprobe first [16:13:50 CEST] <Mumee> Ok thanks but is there a way to make a batch script that can select it automatically with ffprobe? [16:14:59 CEST] <furq> http://vpaste.net/1YNsR [16:15:02 CEST] <furq> that's how you'd do it in shell [16:15:05 CEST] <furq> no idea about batch [16:17:34 CEST] <Mumee> Sorry i think i ment shell (the cli in linux?), but i will try to understand what you write [16:19:07 CEST] <furq> http://vpaste.net/ga6yk [16:19:22 CEST] <furq> if you're just remuxing then that should work [16:22:06 CEST] <Mumee> also now I am using this command: http://pastebin.com/raw/P0e3cWRa I also want to convert the video [16:22:27 CEST] <Mumee> and I dont really understand your code... [16:24:40 CEST] <furq> http://vpaste.net/H3JZe [16:25:01 CEST] <furq> save that as convert.sh, run `chmod +x convert.sh`, then run `./convert.sh input.mkv output.mp4` [16:26:16 CEST] <oerg866> Hello there, I have a question about the -ss and -to parameters. How do they work when I have multiple input files and -map parameters? [16:27:18 CEST] <oerg866> say my command was this: [16:27:18 CEST] <oerg866> ffmpeg -i "ofc_monnem.avi" -i "ofc_monnem.wav" -map 0:0 -map 1:0 -vcodec libx264 -acodec aac -pix_fmt yuv420p -preset medium -b:v 5000k -b:a 256k -vf yadif=1,setdar=4:3 C:\temp\ofc_monnem.mp4 [16:27:43 CEST] <oerg866> where would i have to place the -ss and -to commands and do i have to do them multiple times? [16:27:58 CEST] <furq> it'll seek both files if you use it as an output option [16:28:19 CEST] <oerg866> But wouldn't that be very slow? [16:28:44 CEST] <oerg866> I read about that on the ffmpeg wiki and it says [16:28:45 CEST] <c_14> very is relative, but it'll have to decode everything up to the seek point in all input files [16:28:46 CEST] <oerg866> ""Here, the input will be decoded (and discarded) until it reaches the position given by -ss. This will be done very slowly, frame by frame. " [16:29:04 CEST] <furq> it'll take as long as it takes to decode that much of the files [16:29:21 CEST] <oerg866> It'll take a long time then, since the .avi files are lossless [16:29:35 CEST] <furq> you can specify it once for each input if you prefer [16:29:46 CEST] <furq> s/for/before/ [16:29:54 CEST] <oerg866> Ahh so that's how it works! [16:30:02 CEST] <oerg866> many thanks, that just spared me a lot of headaches :) [16:30:57 CEST] <furq> i can't help but notice that ffprobe selects subtitle streams with m:language:eng [16:31:07 CEST] <furq> is there a way to get that stream specifier for just audio streams [16:33:06 CEST] <c_14> I think I had something like 0:m:language:jpn:a at one point [16:33:10 CEST] <c_14> Not sure if it worked though [16:33:38 CEST] <furq> that doesn't seem to work [16:33:42 CEST] <Mumee> I tested the code you send me.. but could it be that you forget the map in my conversion command? [16:33:52 CEST] <furq> oh [16:33:53 CEST] <furq> yeah i did [16:34:19 CEST] <Mumee> and i dont know if it helps but what about this for your problem: -sn [16:35:13 CEST] <furq> that doesn't work either [16:36:48 CEST] <furq> i guess it's back to a distressingly long ffprobe command [16:37:51 CEST] <Mumee> hmm :/ but can you tell me how i add the mapping thing in my command? i am relay bad at scripting.. [16:39:03 CEST] <c_14> furq: -sn should work (as long as it's after the positive mapping) [16:39:11 CEST] <c_14> At least -map -0:s seems to disable the subtitle streams [16:39:34 CEST] <furq> it works but you'll then just get no video [16:39:40 CEST] <furq> i was hoping for an error [16:39:57 CEST] <furq> Mumee: http://vpaste.net/IzPQe [16:40:37 CEST] <furq> speaking of ffprobe, that "stream_disposition=0" should probably be documented somewhere [16:41:17 CEST] <furq> 15:39:34 ( furq) it works but you'll then just get no video [16:41:19 CEST] <furq> s/video/audio/ [16:54:18 CEST] <Mumee> furq i tested the code... and it works :3 thank you very much [17:11:28 CEST] <s0126h> does ffmpeg support h265 encoding [17:13:25 CEST] <c_14> If built with --enable-libx265 [17:13:58 CEST] <s0126h> does binary in ffmpeg website use enable libx265 [17:14:32 CEST] <c_14> This one does https://www.johnvansickle.com/ffmpeg/ [17:14:47 CEST] <c_14> As does the windows one from zeranoe [17:14:57 CEST] <fritsch> just run: ffmpeg -encoders [17:14:58 CEST] <fritsch> and see [17:27:03 CEST] <TwinTailed> [libav], when transcoding to h264, i am getting a missing audio frame (last frame) [17:34:27 CEST] <Mumee> I am trieng to understand your code.. but i dont understand this part "[ "$type" != "audio" ] && map="0:a:0"" I understand the part in the square brackets, but what does the rest mean? [17:35:04 CEST] <SchrodingersScat> assigning 0:a:0 to $map [17:36:03 CEST] <SchrodingersScat> if it's successful then it continues [17:37:42 CEST] <Mumee> you mean if the code in the brackets is successful it ignores the assigning? [17:38:03 CEST] <SchrodingersScat> Mumee: no, && is 'and' so both have to be evaluated as true [17:38:50 CEST] <lexileo> it should be map==, not map= [17:39:08 CEST] <SchrodingersScat> who's that? [17:39:11 CEST] <SchrodingersScat> why [17:39:22 CEST] <Mumee> ok.. then i dont understand why that code works.. [17:39:27 CEST] <lexileo> because == compares, = assigns [17:39:29 CEST] <SchrodingersScat> is it being evaluated or assigned? [17:39:42 CEST] <SchrodingersScat> if it's being evaluated then that looks wrong in other ways too [17:40:14 CEST] <c_14> It's being assigned [17:40:27 CEST] <c_14> If $type is not audio, then map is 0:a:0 [17:40:29 CEST] <Mumee> also the complete code ist from furq... http://vpaste.net/IzPQe [17:41:11 CEST] <SchrodingersScat> basically that looks like shorthand for an if, because if $type != audio then the second bit is ran [17:41:22 CEST] <c_14> It is shorthand for an if [17:41:23 CEST] <SchrodingersScat> so saves declaring it later, i think [17:41:43 CEST] <SchrodingersScat> okie dokie then [17:42:09 CEST] <Mumee> also the && is a replacement for then? [17:43:05 CEST] <SchrodingersScat> Mumee: for a &&, bash should stop if the first test is negative, is what's happening. [17:44:20 CEST] <Mumee> But it doesnŽt stop... it sets map to map="0:a:0" [17:44:24 CEST] <SchrodingersScat> I guess I don't see []'s being used outside of if/while/for/etc much. && is pretty standard. [17:44:36 CEST] <SchrodingersScat> Mumee: was type != audio? [17:45:10 CEST] <Mumee> i posted the code: http://vpaste.net/IzPQe [17:47:12 CEST] <SchrodingersScat> Mumee: I'm saying that if it didn't stop, then $type != audio [17:48:45 CEST] <Mumee> Sorry.. my english is not the best... :/ But you are just talking from that line? the code after that will be run anyway? [17:49:05 CEST] <SchrodingersScat> Mumee: if the condition evaluates as true [17:49:30 CEST] <SchrodingersScat> Mumee: basically if the exit code is 0 for 'successful' [17:50:44 CEST] <Mumee> Thanks.. i hope i have understand it now :) [17:51:15 CEST] <TwinTailed> Does anyone know why I am getting a missing last frame from audio stream when transcoding with libav? [17:52:47 CEST] <furq> Mumee: it's exactly the same as if [ "$type" != "audio" ]; then map="0:a:0"; fi [17:54:26 CEST] <Mumee> Ok then i understood it [17:54:47 CEST] <furq> i could have also done [ "$type" == "audio" ] || map="0:a:0" [17:56:50 CEST] <Mumee> Is this anywhere documented? because till today i never saw this.. [17:58:52 CEST] <furq> http://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html#ta… [17:59:01 CEST] <SchrodingersScat> Mumee: it's bash, man bash [17:59:35 CEST] <SchrodingersScat> Mumee: oh, or sh [17:59:50 CEST] <furq> the same text is in bash's manpage [18:00:54 CEST] <Mumee> Well.. i said i am not good in this.. [18:14:51 CEST] <TwinTailed> Does anyone know why I am getting a missing last frame from audio stream when transcoding with libav? [18:17:51 CEST] <classy_cameltoe> what are the pros and cons of utvideo vs huffyuv ? [18:19:03 CEST] <classy_cameltoe> reason I am asking is utvideo seems to crash vspipe a lot. [18:19:15 CEST] <furq> ut video should be faster and give better compression but it's less widely supported [18:19:24 CEST] <furq> i'd pick ffv1 over either of them [18:20:39 CEST] <classy_cameltoe> gonna take a look at ffv1. Do you know if it is fully supported by VapourSynth? [18:20:57 CEST] <furq> as an input? [18:21:03 CEST] <classy_cameltoe> output [18:21:35 CEST] <furq> the output codec shouldn't make any difference [18:22:43 CEST] <classy_cameltoe> Just had a look at my convoluted way of doing this. Going to be piping the video out of VS with VSpipe into ffmpeg to mux in the sound. Guess the best way to try is to test it. [18:23:19 CEST] <classy_cameltoe> but yeah, ut video crashed way to much. huffyuv is not crashing... [18:23:41 CEST] <classy_cameltoe> C:\VideoStuff\VS\VSPipe.exe -y C:\VideoStuff\VS\PART_2.vpy - | C:\VideoStuff\ffmpeg.exe -i - -i D:\Videos\tape_1_dalerna_LA_dahab.avi -c:v utvideo -c:a copy -map 0:0 -map 1:1 -vf setdar=4:3 D:\Videos\ALL_finished.avi -y [18:24:46 CEST] <classy_cameltoe> ohhhh spiffy. ffv1 works very nicely. [18:28:00 CEST] <classy_cameltoe> Is there any consensus on a archival format for the preservation of video? [18:28:43 CEST] <furq> ffv1 seems like a good choice [18:29:11 CEST] <furq> good compression, open-source, widely supported and will exist for at least as long as ffmpeg does [18:31:41 CEST] <furq> https://en.wikipedia.org/wiki/FFV1 [18:31:46 CEST] <furq> apparently a few institutions are already using it [18:31:47 CEST] <classy_cameltoe> yeah reading that now [18:32:06 CEST] <classy_cameltoe> As of 2015, standardization of FFV1 through the Internet Engineering Task Force (IETF) is work in progress as part of the European PREFORMA Project [18:32:38 CEST] <JEEB> the only issue is that FFV1 is not as well supported in video editors (commercial), the only thing that supported it was the VFW component in FFDShow-tryouts, and that thing is unfortunately a mess and I don't think it has been developed for ages now [18:32:40 CEST] <furq> there are other lossless codecs with better compression but they're mostly/all patent-encumbered or closed-source [18:32:50 CEST] <JEEB> and it lacks a QT component methinks [18:32:56 CEST] <furq> the only competitor i know of as far as compatibility is huffyuv [18:32:57 CEST] <JEEB> (for mac editors) [18:33:38 CEST] <JEEB> basically if you're OK with transcoding into ut video or something for editing, then ffv1 archival should be OK [18:35:06 CEST] <furq> it's part of lav filters isn't it [18:35:14 CEST] <JEEB> that's DShow [18:35:19 CEST] <JEEB> DShow is generally not used by video editors [18:35:25 CEST] <furq> apparently premiere uses dshow [18:35:32 CEST] <classy_cameltoe> Prefer to stick with something that will be around in say 20 years. Seems ffv1 might be a good one to use. [18:35:33 CEST] <JEEB> ok, color me surprised [18:35:38 CEST] <furq> according to that page anyway [18:35:47 CEST] <JEEB> I'd be really surprised if it does, though :D [18:36:05 CEST] <JEEB> since all of those editors have worked really hard to only have QT/VfW/custom internal stuff available for input/output [18:36:18 CEST] <JEEB> and output with DShow doesn't really exist although it definitely is possible [18:36:21 CEST] <furq> does ut video work with quicktime [18:36:25 CEST] <JEEB> yes [18:36:28 CEST] <JEEB> it has a QT component [18:36:36 CEST] <furq> how annoying [18:36:40 CEST] <classy_cameltoe> lol [18:36:43 CEST] <JEEB> the umezawa guy made a thing for VfW, DShow, MF, QT [18:37:15 CEST] <furq> it's not an issue if you're not using a commercial editor anyway [18:37:28 CEST] <JEEB> true [18:37:45 CEST] <TwinTailed> JEEB: Have you got any idea why I am having a missing last frame from the audio stream when transcoding using libav? [18:38:07 CEST] <JEEB> in like 2013 or so ffv1 was still much less usable, I remember encoding some stuff with it and then the decoding was *slow* [18:38:11 CEST] <JEEB> that seems to have been fixed since [18:38:17 CEST] <JEEB> but left a really bad aftertaste [18:38:29 CEST] <furq> decoding is pretty fast in my experience [18:38:33 CEST] <furq> i've not compared it to ut though [18:38:58 CEST] <JEEB> ut has no real optimizations so if whatever was happening with my encodes isn't happening any more it should be quite fast [18:39:05 CEST] <JEEB> although ut video is pretty darn simple :D [18:39:09 CEST] <classy_cameltoe> I guess long term standards are not practical. I have to dick around with Ada all day at work since they wont let it go... [18:39:17 CEST] <furq> i vaguely remember decoding speed being a selling point of ut [18:39:23 CEST] <JEEB> (I was able to implement as my babby's first encoder) [18:39:30 CEST] <JEEB> yes, the official components are optimized very well [18:39:45 CEST] <JEEB> the libavcodec encoder isn't really :P [18:40:02 CEST] <JEEB> (and I couldn't just grab the optimizations from original as it's GPL) [18:40:12 CEST] <JEEB> (although I could have just asked if it was OK or something) [18:40:17 CEST] <furq> thanks richard [18:42:33 CEST] <classy_cameltoe> Get this every now and then... [18:42:37 CEST] <classy_cameltoe> [yuv4mpegpipe @ 0000000000dd6860] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [18:42:50 CEST] <classy_cameltoe> what it mean? [18:45:35 CEST] <classy_cameltoe> somebody on the Internet (gotta be correct) says to use this -thread_queue_size 512. Any truth to this? [18:55:24 CEST] <furq> it doesn't make any difference in my experience [18:57:25 CEST] <furq> there's no harm in using it though [18:59:17 CEST] <classy_cameltoe> thx furq. Kinda wondering what is meant by queue blocking of threads. I got a hella lot cores on this machine. [18:59:49 CEST] <classy_cameltoe> A duel Xeon 2630v3 setup. [19:00:13 CEST] <TwinTailed> when do i use avcodec_flush_buffers after EOF? [19:09:24 CEST] <flux> twintailed, ..did you its documentation? you don't: http://ffmpeg.org/doxygen/trunk/group__lavc__misc.html#gaf60b0e076f822abcb2… [19:09:38 CEST] <TwinTailed> did [19:09:59 CEST] <TwinTailed> flux: I wanted to know whether after sending NULL or when getting EOF from decoder [19:11:01 CEST] <flux> well, none of the doc/examples/*.c use it [19:11:24 CEST] <flux> ffmpeg.c itself uses it once, when seeking [19:12:06 CEST] <flux> apparently ffplay.c uses it once, but the conditions it uses it in are a bit unclear to me.. [19:14:22 CEST] <TwinTailed> flux: no idea what causes missing last audio frame? [19:15:04 CEST] <flux> twintailed, as I said, you should just keep internal counters and determine how many frames of audio data you receive and output [19:15:21 CEST] <flux> twintailed, and then find if and why there is a discrepancy [19:15:23 CEST] <TwinTailed> flux: how can i get which frame i am writing? [19:15:47 CEST] <TwinTailed> flux: pkt->pos;? [19:15:50 CEST] <flux> you don't need to keep track of frame numbers. just if (frame type == audio) { ++number_of_audio_frames; } [19:16:33 CEST] <flux> also other suggestions: try to use input material that ONLY has a video track, and input material that ONLY has an audio track [19:16:46 CEST] <flux> I sort of expect that it's always the last frame you drop, not just the last audio frame [19:17:00 CEST] <flux> next you could generate test material that ie. has only 1 frame [19:17:04 CEST] <flux> or two frames [19:17:18 CEST] <flux> and just step through your code with it and get better understanding of the problem.. [19:17:28 CEST] <TwinTailed> flux: ffprobe showed that all video frames are there [19:18:38 CEST] <flux> welll, let's say you have two audio tracks [19:18:47 CEST] <flux> do you expect that both of the tracks will miss the last frame? [19:19:35 CEST] <TwinTailed> flux: i don't know tbh [19:20:26 CEST] <flux> well, find out ;) [19:22:30 CEST] <khdsfbads> how to extract audio frommp4 file and save it as webm audio ? and how to convert m4a file to webm audio ? [19:24:51 CEST] <khdsfbads> *from mp4* [19:53:13 CEST] <TwinTailed> flux: the has_b_frames is 0 for the original video file, but is 2 for the generated [19:53:19 CEST] <TwinTailed> flux: would it cause anything? [20:07:01 CEST] <Ponder1787> I have cleaned up a bunch of temporal noise in some video8 that I had. Looks good but I now have what looks like a non moving screen superimposed. Any idea what that can be? Seen this before when using temporal "cleaning" [20:07:46 CEST] <Ponder1787> Or better yet. How would I clean that up. Using a mix of VapourSynth and ffmpeg [20:14:44 CEST] <TwinTailed> flux: number of successfully decoded audio frames is 5205, number of frames passeing avcodec_send_frame is also 5205, but the number of frames passing avcodec_receive_packet is 5204 [20:15:57 CEST] <TwinTailed> by passing i mean the function returns success (0) [20:27:46 CEST] <TwinTailed> flux: the function failing in that frame is returning AVERROR(EAGAIN) [20:33:33 CEST] <mizux> hi [20:34:26 CEST] <mizux> due my home video player limitation -_- do you know how to change the compatible_brands ? [20:34:32 CEST] <mizux> from isomiso2avc1mp41 to isommp42 [20:34:46 CEST] <mizux> it seems the first one is not recognize [20:35:08 CEST] <mizux> also minor version is 512 for the first and 0 for the later [20:55:33 CEST] <TwinTailed> mizux: ffmpeg doesn't support mp42 [20:58:32 CEST] <mizux> TwinTailed, do you mean i can convert isom/isomiso2avc1mp41 to mp42/isommp42 ? [20:58:37 CEST] <mizux> can't* [21:07:39 CEST] <TwinTailed> mizux: I doubt, but why would you anyways? [21:10:04 CEST] <mizux> the first one is not recongize by my home video player -_- [21:10:17 CEST] <mizux> but the second yes [21:14:26 CEST] <brrz> dont know if this is the right channel, but I am trying to get VAAPI with intelHD to work. vainfo seems to work but ffmpeg exits with No VA display found for device: /dev/dri/card0 [21:17:25 CEST] <brrz> whole ffmpeg command: http://pastebin.com/8NGDFJXz [21:21:13 CEST] <mizux> MP4Box -brand mp42 file.mp4 [21:21:26 CEST] <mizux> (package gpac) Thanks all [21:53:18 CEST] <nutopic> hello [21:53:54 CEST] <nutopic> trying to encode bink video to x264 [21:54:09 CEST] <nutopic> ffprobe and ffmpeg don't like it [21:54:16 CEST] <nutopic> "a1_p1_paul_presentation.bk2: Invalid data found when processing input" [21:54:21 CEST] <nutopic> i thought it was supported? [21:59:19 CEST] <TwinTailed> nutopic: x264 is supported by ffmpeg [21:59:31 CEST] <TwinTailed> using libx264 [22:18:57 CEST] <orge> http://pastebin.com/raw/g3xgcCsg the first two commands show that by advancing the seek point from 10.513 to 10.515 the frame count decreases from 374 to 125. since this is copying rather than transcoding, you would think this is caused by a key frame between those two seek points, right? but the third command shows that the only nearby key frame isn't between those time points. can someone explain? am i misunderstanding something? [22:27:39 CEST] <DHE> seek position is open to a bit of interpretation. audio and video frames often aren't exactly time synchronized, and some formats have a third pure timestamp set of metadata. [22:28:26 CEST] <DHE> that is, if you run "ffprobe -show_frames" the pts and dts won't be strictly monotonic when not filtering between audio and video [22:38:43 CEST] <nutopic> yeah i know twintailed my issue was with the input [22:42:54 CEST] <orge> DHE, i don't entirely understand what you're saying, but this is just video, no audio [22:47:55 CEST] <DHE> no audio in the stream? [22:49:57 CEST] <orge> DHE, no. the only stream 0:0 is video. although it's from a mkv with video audio subtitles, etc [22:53:33 CEST] <oerg866> If I split videos using -ss and -t, what do I have to do to make sure that i can join them together again? [22:53:43 CEST] <oerg866> (I'm editing commercials out of some old TV recordings) [22:54:52 CEST] <stah0121> hello. just wanted to say I think ffmpeg is an amazing project and I'm thankful for everyone who has contributed. I plan to send a donation soon [22:55:06 CEST] <ericwooley> I'm getting an ffmpeg error: ': Input/output error' when I try to list the devices using: `ffmpeg -f avfoundation -list_devices true -i ""` ===> full output http://pastebin.com/rD1ZWHup [22:55:15 CEST] <ericwooley> anyone have any idea what might be going on [22:57:50 CEST] <rkern> ericwooley: I can reproduce it. Let me see if it's something easy. [22:58:10 CEST] <ericwooley> @rkern Thank you sir [22:58:41 CEST] <ericwooley> @oerg866 I'm no expert, but I don't think you need to do anything special to be able to rejoin them [23:02:22 CEST] <stah0121> is there some kind of standardized documentation for all the different AV codecs ? [23:04:56 CEST] <ericwooley> @stah0121 Someone can correct me if I am wrong, but my understanding is that codecs follow a pretty string api, so ffmpeg can interact with them the same way no matter what codec it is. So the standard doc would be just the ffmpeg docs. Anything special for a specific codec would be, by definition, non-standardizable [23:05:09 CEST] <ericwooley> and by string i mean strick [23:05:11 CEST] <ericwooley> strict [23:05:16 CEST] <stah0121> if I wanted to create an application that handles encoding or decoding of 1 kind of codec, where would I find info on how to implement it? [23:05:16 CEST] <ericwooley> oh man, bad typing day for me [23:05:44 CEST] <DHE> stah0121: there's a doc/examples directory with a handful of narrow use case but still useful applications [23:06:26 CEST] <ericwooley> what do you mean by encoding/decoding? [23:07:32 CEST] <DHE> are you planning to write a codec or just write a frontend using libav? [23:08:45 CEST] <stah0121> I'm partially trying to get a better understanding of how everything fits together, because for example there are lots of apps that can handle things like transcoding wav to mp3 and spitting out a file. [23:09:30 CEST] <stah0121> I am trying to do some research on creating my own home media type server, and I'd like to take advantage of some of the ffmpeg libraries but I am trying to get a feel for ffmpeg itself, and the things its implemented to do [23:10:01 CEST] <DHE> most common parameters are available in the AVCodecContext structure. bitrate, quality caps, keyframe intervals, image resolution, etc. [23:10:22 CEST] <DHE> that's a vast oversimplification... [23:10:27 CEST] <stah0121> ha, yeah I hear ya [23:10:36 CEST] <stah0121> I just cloned the main git repo and have been browsing the code [23:11:28 CEST] <stah0121> my background is in network protocols and following RFC's and things, and for audio/video stuff it sort of seems like codecs are sort of like protocol definitions ? or am I wrong [23:11:42 CEST] <DHE> failing that, there is an AVDictionary which allow passing arbitrary key=value pairs for codec-specific or even generic options [23:14:23 CEST] <DHE> a decoder codec is responsible for taking an AVPacket (variable size payload from disk) and producing an AVFrame (raw video frame, fixed size, width * height * bytes_per_pixel) [23:14:27 CEST] <DHE> and the encoder does the reverse [23:15:14 CEST] <DHE> while codecs are specified by standards and there are reference encoders/decoders, there tends to be a lot of work in making a good codec that performs well and produces good image quality [23:15:19 CEST] <ericwooley> rkern: find anything? It's not so bad, except it's causing output to go through stderr, not stdout. So I can listen to both streams, but it's just adding complication. Any idea if it's something I need to fix on my system or if it's an error with ffmpeg? [23:16:25 CEST] <ericwooley> If you think it would be a relatively easy thing to do, I can try to put together my first PR that fixes it [23:16:41 CEST] <rkern> ericwooley: you can ignore it - an error is returned in all cases when you list devices [23:17:20 CEST] <ericwooley> K, for now I will just list on stderr and stdout then. Thanks for checking into it [23:18:08 CEST] <ericwooley> I'll create a github issue for it [23:18:13 CEST] <rkern> The issue is in avfoundation.m in avf_read_header. When it lists devices, it does a "goto fail;" to clean up instead of initializing. [23:18:36 CEST] <ericwooley> err, never mind, there doesn't seem to be issues on ffmpeg [23:18:48 CEST] <ericwooley> interesting [23:19:34 CEST] <ericwooley> is there an ffmpeg bug tracker? and rkern: would you like me to open an issue, it seems like you have tracked it down already [23:19:51 CEST] <DHE> part of the wiki, see the topic [23:20:49 CEST] <ericwooley> ah yes, always read the header. My bad. [23:21:39 CEST] <rkern> ericwooley: not sure if you've contributed before, but if you'd like to, this is something easy to start with. [23:22:25 CEST] <ericwooley> ffmpeg is such an awesome project, I would love to contribute. I am currently trying to figure out what the whole process is [23:22:48 CEST] <ericwooley> I have done little more than install a binary, so this might take me a while haha [23:23:54 CEST] <Ponder1787> lol, cool the linux environment in Windows 10 actually works. Try something like watch -n1 'grep MHz /proc/cpuinfo |sort -k4rn' and it works. raw sockets too... finally! [23:24:14 CEST] <ericwooley> I don't know if I have time until next weekend though rkern. If you want it to be fixed sooner rather than later, it might not be a good idea to wait on me [23:25:04 CEST] <rkern> Not a problem. There's a ton of good info at https://ffmpeg.org/developer.html#Contributing and new devs are always welcome. [23:25:33 CEST] <rkern> If I'm around I'd be happy to help you out. [23:26:19 CEST] <stah0121> Thanks for the info DHE. [23:26:54 CEST] <stah0121> If someone were to start contributing, what area would you say needs the most help ? [23:26:55 CEST] <ericwooley> Awesome thanks! This will be my new project over the week (if I get a free minute) and into next weekend [23:27:25 CEST] <DHE> dunno, I am but a user. a power user maybe, but a user all the same [23:28:37 CEST] <Dresk|Dev> So ffmpeg is pretty darn slow on my Pixel C tablet (Tegra X1 SoC) and my NVIDIA Shield Tablet (Tegra K1 SoC), we're using 2.8.6, we've got NEON enabled and I believe as much GL stuff as we can do, obviously we're not hardware decoding, but have the recent versions of ffmpeg improved Android performance at all? [23:30:15 CEST] <Ponder1787> Talk about The Pixel. The Pixel phone is coming out in two days right? [23:30:35 CEST] <Ponder1787> Google Pixel that is. [23:31:01 CEST] <Dresk|Dev> Yeah they are announcing them, gonna be using Snapdragon 820 SoCs, not the best things out there, the Tegra X1 is definitely more powerful, but it's at 2560x1800 [23:31:12 CEST] <Ponder1787> Not the 821? [23:31:19 CEST] <Dresk|Dev> Doesn't look like it [23:31:48 CEST] <Ponder1787> Hope they keep a sane price point on them. Been using Nexus for years. [23:32:18 CEST] <Dresk|Dev> The prices actually are said to start at $650 [23:32:24 CEST] <Ponder1787> ouch [23:32:47 CEST] <Ponder1787> ... reluctantly reaches into wallet. [23:33:31 CEST] <Dresk|Dev> So, any idea on my question? [23:34:04 CEST] <Ponder1787> You sure NEON is working? [23:34:35 CEST] <stah0121> anyone got any books they recommend on ffmpeg and/or low level audio/video development ? [23:34:52 CEST] <ossifrage> I'm having troubles with my 'drawtext' jumping around by a few pixels, even tough I'm using a fixed width font... [23:35:12 CEST] <JEEB> Dresk|Dev: feel free to check if this works any better :) https://github.com/mpv-android/mpv-android/releases/tag/mpv-android-2016-09… [23:35:28 CEST] <JEEB> (there's now basic mediacodec integration in FFmpeg which that is utilizing) [23:36:32 CEST] <ossifrage> I'm using 'x=w-tw-4:y=4' for the text position. Any ideas? (the font is Roboto-Bold.ttf) [23:37:01 CEST] <ericwooley> stah0121 Well, i know of one easy bug haha [23:37:52 CEST] <stah0121> haha [23:38:08 CEST] <Dresk|Dev> Ponder1787: For Neon, we have #define HAVE_NEON 1 , #define HAVE_NEON_EXTERNAL 1 , #define HAVE_NEON_INLINE 0 , #define HAVE_INTRINSICS_NEON 1 , #define CONFIG_NEON_CLOBBER_TEST 0 [23:38:20 CEST] <stah0121> what sort of development environment is common for ffmpeg stuff ? [23:38:36 CEST] <stah0121> I'm used to vim, ctags, gcc, etc [23:38:43 CEST] <JEEB> your usual gcc/shell/yasm (last for IA32/x86_64) [23:38:45 CEST] <Ponder1787> then you will be fine [23:39:00 CEST] <JEEB> as for editor everyone uses what they're comfy with [23:39:09 CEST] <JEEB> I use vim and a more graphical editor usually [23:39:24 CEST] <Ponder1787> I use everything from emacs to nopepad [23:39:31 CEST] <Ponder1787> notepad [23:39:43 CEST] <stah0121> I was doing a bit of reading on yasm, I'm not familiar. Seems powerful though. Do you sort of use it in place of doing like a gcc compile ? [23:39:59 CEST] <stah0121> JEEB what sort of graphical editor ? [23:40:12 CEST] <JEEB> no, it's for stuff where people go and write highly optimized versions of a part of a decoder/encoder/filter [23:40:18 CEST] <DHE> anything. eclipse, gedit... [23:40:52 CEST] <JEEB> sublime text is currently what I use since it kind of got me, although for non-FFmpeg stuff I use stuff from intellij [23:41:20 CEST] <stah0121> gotcha [23:42:57 CEST] <stah0121> I sometimes wonder if I should switch to emacs haha, but vim has done well for me and overall seems fairly straight forward for how complex you can get with it [23:43:58 CEST] <Ponder1787> once use start using emacs you will prolly stick to it. I love it. Use a nice solorized theme. [23:44:29 CEST] <ossifrage> The problem is tw isn't a constant value for a fixed length string and a fixed with font... [23:45:00 CEST] <ossifrage> I just gave up and used 'x=w-max_glyph_w*12' for my 12 character string [23:48:15 CEST] <stah0121> does ffprobe rely on any graphical component ? [23:48:34 CEST] <BtbN> depends on what you link it against. [23:49:10 CEST] <stah0121> when I was reading about ffprobe I kept thinking about the spectrum analyzer in DAW programs like ableton [23:49:33 CEST] <stah0121> if I hooked it into some graphic lib, would I be able to get a similar sort of realtime graphical window ? [23:50:10 CEST] <BtbN> no [23:52:35 CEST] <stah0121> ok [00:00:00 CEST] --- Mon Oct 3 2016

1 0

ffmpeg-devel.log.20161001
by burek 02 Oct '16

02 Oct '16

[01:33:16 CEST] <cone-729> ffmpeg 03Steven Liu 07master:0d2dd5d96d0d: avformat/hlsenc: support mkdir_p for use_localtime_mkdir [01:41:07 CEST] <jamrial> uh, was that patch really reviewed as the commit implies? [01:45:11 CEST] <Chloe> jamrial: not by anyone else [01:46:36 CEST] <iive> have the patch been sent 2-3 days ago? [01:47:37 CEST] <Chloe> 26th [01:47:43 CEST] <Chloe> (originally) [01:48:03 CEST] <iive> well, he's waited planty of time then. [01:48:58 CEST] <wm4> why can't it show who pushed a commit [01:49:00 CEST] <Chloe> err, it was reviewed, just not explicitly approved. [01:49:12 CEST] <wm4> also does this guy have push access? [01:49:34 CEST] <Chloe> how many people have push access anyway? [01:49:55 CEST] <Chloe> wm4: I would say he does, he's in MAINTAINERS [01:50:16 CEST] <Chloe> I guess I can answer my own question here :) [01:50:25 CEST] <wm4> why do we hand put push access like cookies [01:50:36 CEST] <wm4> "we" [01:51:52 CEST] <Chloe> good question [01:52:20 CEST] <iive> how else do you solve lack of man power problem? [01:52:52 CEST] <jamrial> well, if he's maintaining something, it makes sense [01:53:04 CEST] <Chloe> yeah hlsenc or soemthing [01:53:39 CEST] <jamrial> which is what he just modified [01:53:42 CEST] <jamrial> still, he should have pinged the patch because it was never really approved or reviewed [01:54:15 CEST] <Chloe> jamrial: the issue is that these practises arent really documented very well [01:54:39 CEST] <wm4> more importantly, there are no practices [01:55:05 CEST] <wm4> some devs just push what they want (I'll try that too) [01:55:15 CEST] <jamrial> he mentioned michaelni as reviewer when he never did. he pointed some faults in the first version of the patch, but never said anything else [01:55:42 CEST] <iive> well, it used to be a rule, that you have to wait 2 days before committing something yourself, if nobody reviews it. [01:56:08 CEST] <rcombs> maybe mailing lists suck [01:56:15 CEST] <iive> so if he had addressed michael points... [01:56:26 CEST] <rcombs> patchwork is slightly less bad than just the list [01:56:27 CEST] <iive> maybe everybody should relax [01:56:38 CEST] <Chloe> I think it would be a good idea to define these rules somewhere [01:56:51 CEST] <Chloe> or guidelines at least [01:56:57 CEST] <rcombs> but people will need to actually use it, and it doesn't provide a good way to ping on something [01:57:21 CEST] <Chloe> I use patchwork to get patches, because I still dont know how to do it from my mail client [01:57:36 CEST] <Chloe> that's pretty much it though [01:57:42 CEST] <iive> i think ffmpeg got patchwork [01:57:50 CEST] <rcombs> yes [01:57:56 CEST] <Chloe> iive: https://patchwork.ffmpeg.org/project/ffmpeg/list/ [01:58:43 CEST] <iive> anyway, don't drink too much member berry wine. [01:59:07 CEST] <Chloe> .-. [02:04:32 CEST] <Chloe> oh, we do have guidelines [02:04:53 CEST] <Chloe> https://www.ffmpeg.org/developer.html#Development-Policy see 12 [02:05:46 CEST] <wm4> fascinating [02:05:57 CEST] <Chloe> too bad probably no one reads them [02:06:16 CEST] <Chloe> they're also not very legible [02:09:03 CEST] <BtbN> Does setting _GNU_SOURCE have any bad side effects? [02:13:46 CEST] <Chloe> I assume it might break some posix functions [02:20:57 CEST] <michaelni> GNU_SOURCE can hide non posix code use [02:22:36 CEST] <michaelni> i have 2 new fate tests locally (ticket186 and a svq3 watermark one, they break with the pending ffmpeg patches), should i push them or should i post them to the ML ? [02:23:06 CEST] <michaelni> i think they break similarly as the cavs one [02:23:36 CEST] <Chloe> post them to the ML [02:24:07 CEST] <Chloe> why do they break with the new ffmpeg patches? [02:24:31 CEST] <michaelni> i didnt really investigate [02:26:12 CEST] <wm4> wait until the new patches are in [02:28:34 CEST] <michaelni> i would have liked to document the changes the patches cause to the tests in git history [02:30:08 CEST] <wm4> well if you're fine with me changing them just to newly generated refs... [02:31:02 CEST] <michaelni> i definitly prefer to push them before and have the refs changed shortly after than pushing them after the patches [02:31:21 CEST] <Chloe> As long as they don't block wm4's patches, I dont see an issue with this [02:36:08 CEST] <michaelni> ok, ill wait a bit and then push them before going to bed unless people want me to wait longer [02:38:59 CEST] <wm4> I just don't want to rewrite this patch again [02:44:19 CEST] <michaelni> the effect your patches have on the tests is the disappearance of the last frame. [03:10:21 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:c8c5f66b42ed: avformat/avidec: Remove ancient assert [03:10:22 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:622ccbd8ab89: avformat/avidec: Check nb_streams in read_gab2_sub() [03:10:23 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07release/3.1:c2ea70628215: Changelog: update [03:37:47 CEST] <cone-729> ffmpeg 03Steven Liu 07n3.1.4:HEAD: avformat/hlsenc: support mkdir_p for use_localtime_mkdir [03:56:32 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07master:588c2355a6f5: fate: Add fate-svq3-watermark [03:56:33 CEST] <cone-729> ffmpeg 03Michael Niedermayer 07master:68d619a31cd7: fate: Add regression test for Ticket 186 [03:59:25 CEST] <Chloe> michaelni: while it wasn't as explicit as it could have been, I added a note in-case people question you pushing the tests so soon seemingly without a review/approval. [10:20:13 CEST] <ubitux> this hls patch is really horrible [10:21:12 CEST] <ubitux> strncmp for comparing 1 char? really? [10:22:49 CEST] <nevcairiel> just because someone claims to be a maintainer doesnt mean they are good at their job =p [10:42:11 CEST] <cone-096> ffmpeg 03Clément BSsch 07master:0fbd42390532: doc/libav-merge: complete TODO section [12:29:30 CEST] <BtbN> michaelni, so defining _XOPEN_SOURCE would be preferred? [12:29:49 CEST] <michaelni> BtbN, IMHO yes [12:30:02 CEST] <BtbN> it's just about one missing function on cygwin [12:30:11 CEST] <BtbN> sigaction is missing without XOPEN_SOURCE or GNU_SOURCE [12:39:50 CEST] <michaelni> nevcairiel, if you see a problem with someones commit, best to talk to him, if you want to volunteer to take over any maintaince or know of someone who wants to iam very interrested, we always need more volunteers and manpower. Do we have anything were there are 2 competing volunteers both wanting to maintain ? [13:24:44 CEST] <Chloe> michaelni: what do you think of negating the testing policy so that it's: you must not commit unless it passes fate, works for you, and all reviewers. (I think that's more clear than what it was before) [13:52:15 CEST] <nevcairiel> michaelni: the point is that even if someone volunteers to maintain a component, we should hopefully still be able to expect a certain degree of quality, otherwise maybe they shouldn't be a maintainer and go through proper reviews [13:52:39 CEST] <nevcairiel> quality of the code affects us all, in all areas [13:53:47 CEST] <michaelni> Chloe, maybe both would make most sense. I think the old text was intended to draw a line were the comitter is no longer responsible for breaking obscure corner cases he couldnt even know about like some obscure platform [13:54:18 CEST] <michaelni> nevcairiel, yes [13:54:57 CEST] <iive> still talking about that commit? [13:55:23 CEST] <iive> did it broke anything? was is of low quality? [13:55:30 CEST] <michaelni> have to go afk [13:56:57 CEST] <nevcairiel> its a general point to make, just because someone sent a handful of patches to a certain quality, should we just hand them maintainer status? maybe a bit more time of contributions might be sensible first. [13:57:06 CEST] <nevcairiel> certain component* [14:01:22 CEST] <iive> yes and yes [14:01:28 CEST] <iive> do you have other questions? [14:02:56 CEST] <iive> stop worring about imaginary things. [14:19:36 CEST] <ubitux> do we still need the packet split side data hack? [14:20:31 CEST] <nevcairiel> not sure why we ever really needed it [14:21:20 CEST] <ubitux> prevent leaks in random applications iirc [14:26:06 CEST] <wm4> I hate this hack so much [14:26:30 CEST] <ubitux> btw [14:26:31 CEST] <wm4> ubitux: not leaks, just stupid applications which might discard side data even if using both lavf and lavc [14:26:39 CEST] <ubitux> we're going to have to deal with 100+ commits from libav pretty soon [14:27:06 CEST] <ubitux> we might hit the 500 commits delay [14:27:28 CEST] <nevcairiel> as long as they go the sane way and make it possible to gradually migrate [14:27:47 CEST] <nevcairiel> but i think in the end they went with that [14:28:18 CEST] <ubitux> yeah but we're accumulating too much delay IMO [14:28:42 CEST] <ubitux> it would be fine if we were on par commits wise [14:29:37 CEST] <ubitux> but we have a bunch of avconv patches and more hevc that continues to pill up [14:30:39 CEST] <nevcairiel> the next big project will be the avconv changes that make the early-init problem go away, after that it should be a bunch of "normal" patches for a long while [14:31:20 CEST] <ubitux> what's blocking right now? [14:31:27 CEST] <ubitux> we're on qsv stuff [14:31:29 CEST] <nevcairiel> right now? some qsv stuff [14:31:41 CEST] <ubitux> is there a wip or sth? [14:32:11 CEST] <nevcairiel> for qsv i see two routes to take - skip them and hope our qsv "maintainers" do something with them, or revert qsv to the libav variant and just merge everything as-is (currently, i would argue theirs is better anyway) [14:32:48 CEST] <ubitux> who are our maintainers? random externs that pop up at times? [14:32:54 CEST] <nevcairiel> pretty much [14:32:57 CEST] <nevcairiel> these nablet guys [14:33:05 CEST] <wm4> (lol) [14:33:30 CEST] <ubitux> are they aware of this? because waiting for them might not be the best approach [14:33:41 CEST] <nevcairiel> jamrial posted on the ML to let them know [14:33:49 CEST] <nevcairiel> no clue if thats enough to wake them up [14:34:14 CEST] <ubitux> i wouldn't mind looking at all of this but i was just back on the subtitles api [14:34:24 CEST] <ubitux> and honestly, this delaying is frightening me more and more [14:34:58 CEST] <nevcairiel> we can just skip the qsv stuff and decide later if we want to do something more drastic, like clean up the stuff and get more similar to libav again [14:35:06 CEST] <nevcairiel> its just new features, nothing critical [14:35:35 CEST] <nevcairiel> it would need quite a bunch of refactoring to adapt to ours, i think [14:35:40 CEST] <ubitux> will the QSV scaling filter work? [14:35:59 CEST] <nevcairiel> probably not, i would think it needs the context things the first two patches implement [14:36:21 CEST] <ubitux> is there any benefit to our version? [14:36:42 CEST] <nevcairiel> i think we support like mjpeg decoding which they dont have? or something like that. nothing of consequence [14:38:22 CEST] <nevcairiel> the primary reason it went desync is that our guys were impatient and didnt want to adapt the avcodec infrastucture to be able to use parsers for qsv [14:38:26 CEST] <ubitux> so mmh, just to be clear; the story is that we merged a dubious qsv support, then libav nihed it, then we forced our maitainers to clean it up a bit to keep it somehow in par, and now it's blocking the progress of current merges? [14:38:29 CEST] <nevcairiel> so ours use more of the mfx stuff for parsing [14:38:38 CEST] <nevcairiel> and libav stuff uses more of avcodec [14:43:36 CEST] <ubitux> wasn't vaapi the intel thing btw? [14:43:37 CEST] <nevcairiel> i dont quite remember the very first history, libav may have even had it first, and ours was then changed to add more codec support "quickly" [14:44:58 CEST] <Chloe> ubitux: yes [14:45:11 CEST] <ubitux> so why qsv? [14:45:45 CEST] <ubitux> i don't even have that mfx lib [14:46:20 CEST] <iive> vaapi is the xorg api. Intel use only vaapi for their cards, afair [14:46:27 CEST] <nevcairiel> they all want a cross-platform variant with more features, instead of maintaining some open-source stuff [14:46:37 CEST] <nevcairiel> vaapi was initially pushed by intel though [14:47:11 CEST] <ubitux> oh well fuck this shit, i have a big enough turd to deal with already [14:47:12 CEST] <wm4> vaapi is basically an exclusive intel thing [14:47:29 CEST] <wm4> and ubitux is quite right [14:48:09 CEST] <nevcairiel> ubitux: anyway my suggestion for now would be to skip the three qsv things and put them on the list for later, they dont entangle with anything else in avcodec, so we can either let the nablet people deal with it later if they want, or if someone else comes along to take over qsv let them do whatever, but for merging purposes keeping it blocked seems silly [14:48:25 CEST] <Chloe> wm4: it looks like it was designed to be an open hwaccel platform, but it just didnt take off [14:48:43 CEST] <wm4> Chloe: just like vdpau [14:48:59 CEST] <Chloe> rip. why are there two [14:49:09 CEST] <nevcairiel> because vdpau is nvidia [14:49:17 CEST] <wm4> two? there's a great number of hwdec APIs on Linux [14:49:44 CEST] <nevcairiel> its the typical linux problem, without a central driving force, there is several parallel attempts at this and none manage to succeed fully [14:50:35 CEST] <iive> mesa gallium provides vdpau for radeon cards, so you get amd and nvidia covered with vdpau [14:51:04 CEST] <nevcairiel> last i heard thats still rather buggy, but maybe it improved now, been a while [14:51:32 CEST] <wm4> well windows also has at least 4 APIs or so [14:51:32 CEST] <iive> i've been using it for years... [14:52:11 CEST] <nevcairiel> windows has one central API for decoding thats supported by everyone, nevermind the ve ndors own cross-platform APIs, you dont really need those to handle decoding =p [14:55:11 CEST] <ubitux> nevcairiel: fine with me; if you do, please update the TODO in doc/libav-merge.txt doc [14:55:42 CEST] <ubitux> i won't work on the merge until i'm done with the final blow on subtitles [14:55:50 CEST] <ubitux> +api [15:06:26 CEST] <jamrial> ubitux: i emailed the qsv maintainer to deal with this [15:06:37 CEST] <jamrial> just skip these two merges, they are not blockers [15:06:56 CEST] <nevcairiel> probably the third one as well, i mean it wont exactly break, but it will just not be usable [15:07:08 CEST] <jamrial> guess i'll have to ping him since he probably didn't notice my first email some days ago [15:09:00 CEST] <jamrial> nevcairiel: with the third you mean the filter? it shouldn't depend on the other two commits [15:09:43 CEST] <nevcairiel> how would it get the shared hwcontext if the decoder and encoder cant use one? [15:09:48 CEST] <ubitux> wm4: you're merging the move to the new api in ffmpeg soon, aren't you? [15:10:12 CEST] <ubitux> it would be somehow helpful for my tests :p [15:10:35 CEST] <jamrial> ah, fair enough [15:10:57 CEST] <nevcairiel> its technically not required to skip it, but its untestable and unusable right now [15:11:07 CEST] <nevcairiel> so I would rather not include it yet [15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:a0524d9b1e1b: qsvdec: support getting the session from an AVHWFramesContext [15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:ad9c9440d592: qsvenc: support getting the session from an AVHWFramesContext [15:21:55 CEST] <cone-087> ffmpeg 03Anton Khirnov 07master:ac7bfd69678f: lavfi: add a QSV scaling filter [15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:130e1f1df23e: Merge commit 'a0524d9b1e1bb0012207584f067096df7792df6c' [15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:04b17ff9e819: Merge commit 'ad9c9440d592e4d53d6bec9961b4b22e25387d70' [15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:62c58c59d54f: Merge commit 'ac7bfd69678f3966e38debdb27f4bde94dc0345c' [15:21:55 CEST] <cone-087> ffmpeg 03Hendrik Leppkes 07master:3c18188f9f3e: doc/libav-merge: add a note for the skipped QSV functionality [15:56:49 CEST] <nevcairiel> so apparently there is disagreement which timebase AVFrame.pts uses between ffmpeg and libav, libavs recent changes seem to suggest its the same timebase as pkt_pts/dts, ie. the stream timebase, while ffmpeg assumes its the AVCodecContext.time_base .. of course its not documented either way [15:57:18 CEST] <nevcairiel> (from a decoder) [15:57:27 CEST] <wm4> decoding should always use pkt_timebase [15:57:32 CEST] <wm4> in ffmpeg [15:57:42 CEST] <wm4> or if that is not set, it's implicitly defined by the API user [15:58:04 CEST] <nevcairiel> but then you have a bit of an odd inconsistentcy as decoding would use stream timebase for AVFrame, but encoding uses codec timebase again, afaik [15:59:30 CEST] <wm4> well yes encoding uses AVCodecContext.time_base for some reason [15:59:58 CEST] <nevcairiel> for encoding it makes sense that encoders need to know about timestamps and timebases [16:00:02 CEST] <nevcairiel> as there is ratecontrol involved [16:00:36 CEST] <nevcairiel> having AVFrame.pts be in different timebases based on decoding or encoding just sounds wrong though [16:00:58 CEST] <wm4> it's how it is [16:01:05 CEST] <wm4> encoding: time_base, decoding: pkt_timebase [16:01:19 CEST] <nevcairiel> well but it isnt [16:01:28 CEST] <wm4> it isn't? when? [16:01:35 CEST] <nevcairiel> ffmpeg.c assumes that if a decoder uses AVFrame.pts, then its in time_base [16:01:46 CEST] <nevcairiel> but until now most decoders didnt actually set AVFrame.pts [16:01:51 CEST] <nevcairiel> unitl libav wants to makee it so [16:02:09 CEST] <wm4> that's a very broken assumption [16:02:18 CEST] <wm4> decoders never set AVFrame.pts AFAIK [16:02:25 CEST] <wm4> could just be some absurd dead code [16:02:44 CEST] <wm4> (I know these exist in ffmpeg.c, I restored one once to fix a bug) [16:03:20 CEST] <nevcairiel> that is of course the question, do they really not, and this condition in ffmpeg.c can just be removed? [16:03:48 CEST] <wm4> various user code might have copied these incorrect assumption [16:03:57 CEST] <wm4> *assumptions [16:04:19 CEST] <wm4> maybe deserves a note in APIchanges [16:04:25 CEST] <nevcairiel> even has one [16:04:36 CEST] <nevcairiel> although might be extended to indicate the timebase relationship [16:04:37 CEST] <wm4> about the incorrect assumption ffmpeg.c makes? [16:04:44 CEST] <wm4> yeah [16:04:57 CEST] <nevcairiel> lets see if something breaks if i remove this check [16:08:46 CEST] <nevcairiel> its only in the audio path, too [16:09:03 CEST] <nevcairiel> not sure why audio decoders should even make up timestamps [16:13:25 CEST] <ubitux> wm4: do you have a remote branch with the use of the new decoding(/encoding?) api in ffmpeg*c? [16:14:01 CEST] <wm4> not really [16:14:52 CEST] <ubitux> actually no tool use that new api yet [16:16:02 CEST] <wm4> I can try to merge it now [16:16:40 CEST] <nevcairiel> patch for the pts thing on the ml [16:16:51 CEST] <nevcairiel> doesnt break pre-merge and fixes post-merge [16:17:05 CEST] <ubitux> since i plan to have the new subtitles decoding api work with that new api only, it would help me to have at least one thing in the codebase that uses it :p [16:17:18 CEST] <nevcairiel> avformat find_stream_info does! [16:17:19 CEST] <nevcairiel> :D [16:17:21 CEST] <JEEB> lol [16:17:29 CEST] <ubitux> heh [16:18:05 CEST] <wm4> (mpv also does, that probably makes them all) [16:18:32 CEST] <jamrial> mpd also uses it [16:18:53 CEST] <nevcairiel> i was too lazy to migrate yet [16:18:56 CEST] <jamrial> they seem to dislike deprecation warnings so they port things as soon as they show up, hehe [16:18:57 CEST] <wm4> jamrial: woah [16:19:23 CEST] <wm4> I think I also have a branch somewhere to convert ffprobe.c [16:19:42 CEST] <wm4> having done a few of such conversions, I have to say supporting both old and new APIs sucks ass [16:19:55 CEST] <ubitux> avcodec_send_packet() and avcodec_receive_frame() are not thread safe, aren't they? [16:20:01 CEST] <ubitux> mutually* [16:20:45 CEST] <wm4> no [16:20:49 CEST] <wm4> of course not [16:24:39 CEST] <mateo`_> is it possible for a decoder to implement both APIs ? [16:24:49 CEST] <wm4> I guess so [16:27:13 CEST] <jamrial> cuvid did [16:27:34 CEST] <jamrial> does, rather [17:24:30 CEST] <cone-087> ffmpeg 03wm4 07master:b2fea2fdee46: ffmpeg: move subframe warning to libavcodec [17:24:31 CEST] <cone-087> ffmpeg 03wm4 07master:8f6f2322285f: ffmpeg: use new decode API [17:24:32 CEST] <cone-087> ffmpeg 03wm4 07master:4f8262e37309: ffmpeg: use new encode API [17:25:49 CEST] <wm4> ubitux: done [17:25:50 CEST] <JEEB> yayifications [17:32:47 CEST] <mateo`_> \o/ [17:37:45 CEST] <cone-087> ffmpeg 03Marton Balint 07master:d946424f1933: lavfi/metadata: fix setting metadata values [17:37:46 CEST] <cone-087> ffmpeg 03Marton Balint 07master:7ef3e5b593fb: lavfi/metadata: allow deleting all metadata [17:40:42 CEST] <nevcairiel> who the f' would think its a good idea to use floating point in malloc [17:42:00 CEST] <kierank> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c [17:42:10 CEST] <wm4> yeah, musl does it for log2 (lol) [17:42:12 CEST] <kierank> not sure exactly why [17:42:18 CEST] <kierank> oh [17:42:56 CEST] <wm4> it converts an integer to a float, and then extracts the mantissa using questionable code [17:43:17 CEST] <wm4> oh just saw the ML post [17:51:49 CEST] <nevcairiel> personally I think its not unreasonable to expect basic libc functions that do nothing externally with floats (or even math) to not internally use floats for such things [17:52:04 CEST] <nevcairiel> wonder if there is some word from the C standard or posix about such things [17:52:24 CEST] <wm4> actually I think it's reasonable that a libc user doesn't trash the execution environment, even if it's just the FPU [17:52:35 CEST] <wm4> good question [17:53:01 CEST] <BtbN> Isn'T the C standard is usually written in a way that it does not need to care about implementation details like assembly specifics? [17:53:13 CEST] <nevcairiel> of course its probably not all that common to have mmx with allocs mixed, most of the time it'll just be small self-contained stuff [17:53:30 CEST] <nevcairiel> BtbN: could still have some generic language about such th ings [17:55:02 CEST] <ubitux> wm4: thx! [17:58:52 CEST] <wm4> I don't get why ffmpeg.c gets 0 sized packets from iv32/OPENINGH.avi, but everything else (including ffprobe) does not [18:00:42 CEST] <BtbN> voodoo magic. [18:01:45 CEST] <wm4> so, should a decoder be allowed to return errors during draining (on EOF)? [18:01:55 CEST] <wm4> e.g. return a few errors, then a frame, then some more errors [18:02:04 CEST] <nevcairiel> shouldnt it just skip the errors then [18:02:09 CEST] <nevcairiel> and return whatever frames it has [18:02:11 CEST] <nevcairiel> or can [18:03:24 CEST] <wm4> there should probably be some way to report errors, but I guess libavcodec has no nice concept for that [18:03:29 CEST] <wm4> other than spamming log messages [19:02:51 CEST] <BtbN> turns out CUDA is faster if you go for crazy memory alignments. [19:03:06 CEST] <BtbN> 512 seems to be where it's at [19:06:36 CEST] <BtbN> nevcairiel, using / instead of \ for the paths fixes the issue btw. [19:06:45 CEST] <nevcairiel> gpus sometimes even like power of 2 alignment [19:07:08 CEST] <BtbN> per line? [19:07:22 CEST] <BtbN> seems a bit excessive [19:07:36 CEST] <nevcairiel> yeah [19:07:42 CEST] <nevcairiel> cant really align memory pointers that much =p [19:08:02 CEST] <nevcairiel> its not that bad , 2048 for 1920, or 4096 for 3860 [19:08:16 CEST] <BtbN> does ffmpeg have a convenient function to do that? [19:08:58 CEST] <BtbN> 512 might just happen to be what pushes my 1080p test video there [19:10:48 CEST] <cone-087> ffmpeg 03James Almer 07master:449f263f9fbd: avcodec: add missing xmm/neon clobber test wrappers for the new encode API [19:13:59 CEST] <BtbN> doesn't seem like there is [19:45:30 CEST] <philipl> BtbN: Have you considered using cuda arrays? [19:45:41 CEST] <philipl> That does implicit alignment. nvenc can consume them [19:45:53 CEST] <BtbN> that would be a major rewrite of... almost everything [19:46:10 CEST] <philipl> I did a quick experiment here last night. I got cuvid working fine [19:46:18 CEST] <philipl> It's not major. [19:46:45 CEST] <philipl> It's interesting for me because a mapped GL texture is an array - so I could theoretically provide a custom pool of textures and skip a copy [19:46:54 CEST] <BtbN> The hwcontext stuff needs to be changed, as it does all the allocation now. And you can't just do pointer arith with CUDA Arrays [19:47:07 CEST] <philipl> You can't, but why do you need to? [19:47:19 CEST] <philipl> You make the allocated frame be a struct of arrays, one for each plane. [19:47:26 CEST] <BtbN> Because the current hwcontext implementation assumes it to work like a normal pointer [19:47:40 CEST] <philipl> If it's a pointer to a struct... [19:47:46 CEST] <philipl> I did this. It works. [19:47:54 CEST] <philipl> Can put the diff up if you want [19:48:08 CEST] <BtbN> sure [19:48:23 CEST] <BtbN> but just properly aligning the memory is way easier to do [19:48:53 CEST] <philipl> https://github.com/philipl/FFmpeg/commit/670864a8f9f395117289b8b12583f63ee6… [19:49:31 CEST] <philipl> It's not finished by any stretch. I just assumed always nv12, but it was enough to prove it works for cuvid. Didn't look at nvenc, but I verified you can say an input resource is an array [19:51:07 CEST] <BtbN> what's with the linesize for that? [19:52:22 CEST] <philipl> What do you mean? [19:52:26 CEST] <BtbN> it should also be aligned [19:52:41 CEST] <philipl> linesize doesn't mean anything - the array alignment is internal and not actually knowable. [19:53:13 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/8f9fb837e8dba4283e048a7dc463e584542a0… [19:53:44 CEST] <BtbN> I just tested it, and power of two aligning each single line made a transcode go faster [19:53:59 CEST] <philipl> The memcpy, when given an array, doesn't need any other information. [19:54:18 CEST] <philipl> I have no idea if an array is faster than aggressive alignment, but I'd have thought that it would be comparable. [19:54:44 CEST] <philipl> A big point of the array is to let cuda handle alignment - so I'd hope they do it right. [19:55:50 CEST] <philipl> Change looks fine. If it works, go for it. [19:56:07 CEST] <BtbN> so the linesize of the frame becomes meaningless, hm [19:56:12 CEST] <philipl> Yeah. [19:56:26 CEST] <BtbN> This change can't be just gone for [19:56:29 CEST] <BtbN> it breaks public API [19:56:37 CEST] <philipl> YEs, that's the main problem. [19:56:49 CEST] <philipl> Could define a new PIX_FMT and hwcontext to get around that. [19:57:08 CEST] <philipl> Unfortunately one hwcontext can't do two formats. [19:58:24 CEST] <BtbN> I'd much rather just fix the alignment. [19:58:49 CEST] <philipl> Of course. [19:58:58 CEST] <philipl> I only care because of the potential to save a copy in mpv. [19:59:13 CEST] <philipl> Of course, my prototype exploded generating textures in my buffer alloc. [19:59:23 CEST] <philipl> probably calling GL on the wrong thread... [19:59:53 CEST] <philipl> Could probably avoid that by implementing a fixed pool. [20:00:56 CEST] <philipl> What sort of speed up did you see? [20:21:13 CEST] <BtbN> 1080p, -preset slow -global_quality 22, went from somewhat stable ~242 FPS to heavily fluctuating between 380-450 FPS. [20:22:00 CEST] <BtbN> if it's left running for a while it stabilizes, almost climbing up to 500 [20:27:54 CEST] <philipl> impressive [20:59:55 CEST] <Chloe> atomnuker: will you still push the libfaac patch today, or shall I? [21:00:33 CEST] <atomnuker> I literaly just applied it, just need to push it [21:00:40 CEST] <Chloe> ok :) [21:01:15 CEST] <cone-087> ffmpeg 03Josh de Kock 07master:dc0f711459e0: lavc: remove libfaac wrapper [21:02:11 CEST] <atomnuker> now I just need to crawl through trac and figure out what needs a fate test [21:02:25 CEST] Action: wm4 sounds canned applause [21:03:10 CEST] <atomnuker> haasn: arithmetic coding for jpeg is some messed up shit [21:03:25 CEST] <atomnuker> I have 2 books and 3 loose pdf "specs" which all say a different thing [21:04:11 CEST] <atomnuker> seems the truth is somewhere between those, the current decoder and mozjpeg [21:06:00 CEST] <wm4> isn't that what they mean by not bitexact? [21:06:46 CEST] <atomnuker> no, it's bitexact, it's a coding process, doesn't affect quantization [21:07:06 CEST] <wm4> also, 2 prores encoders, 1 prores decoder, and (final boss) 1 resample lib left to delete [21:08:29 CEST] <atomnuker> rock paper scissors tournament to determine which prores encoder stays? winner decides [21:11:10 CEST] <mateo`_> wm4: which resample lib would you delete ? swr* or avr* ? [21:11:45 CEST] <Gramner> randomly flip bits in the object files and see which one can go one longest without segfaulting [21:17:35 CEST] <wm4> mateo`_: let rock paper scissors decide [21:19:31 CEST] <haasn> +1 for Gramner's suggestion [21:19:52 CEST] <haasn> atomnuker: if in doubt, libjpeg? [21:20:27 CEST] <atomnuker> libjpeg supports it? [21:21:22 CEST] <haasn> well libjpeg-turbo does [21:21:28 CEST] <haasn> not sure about IJG libjpeg but I would have assumed so [21:22:05 CEST] <atomnuker> huh, so the distributions never enable the flag I guess [21:22:25 CEST] <haasn> yes IJG libjpeg does too [21:22:27 CEST] <haasn> atomnuker: yeah [21:22:34 CEST] <haasn> every major browser would support it too [21:22:37 CEST] <haasn> they just disable it at compile time [21:22:50 CEST] <haasn> likely this has been supported for years [21:22:55 CEST] <atomnuker> my chromium decodes them fine though [21:22:57 CEST] <Chloe> what's the difference between prores-ks and prores-aw? [21:23:13 CEST] <haasn> In version 7, support for arithmetic coding was introduced, which earlier has been rejected because of the patent situation [21:23:41 CEST] <haasn> 2009 [21:23:45 CEST] <haasn> so it's been supported for 6 years [21:38:04 CEST] <wm4> can libavcodec be used for jpg encoding in practice yet? [21:38:49 CEST] <durandal_1707> off course you can use it [21:39:35 CEST] <BtbN> hm, kind of want to push the cygwin configure fix. Nobody seems to care [21:40:24 CEST] <iive> BtbN: ping the thread first... [21:40:56 CEST] <BtbN> I think I might be the only one actually using cygwin [21:41:29 CEST] <durandal_1707> why? Use mysys [21:41:53 CEST] <BtbN> msys isn't nearly as nicely integrated as cygwin is [21:42:09 CEST] <durandal_1707> huh? [21:42:16 CEST] <BtbN> And I don't think msys has stuff like an X server and Windows Shell integration? [21:42:23 CEST] <iive> BtbN: do cygwin binaries still require a cygwin library? [21:42:37 CEST] <BtbN> iive, of course. That's kind of the whole point. [21:42:48 CEST] <wm4> durandal_1707: does it have useful rate control? good quality? usable quality vs. size control? [21:42:55 CEST] <BtbN> You can "cross compile" from cygwin, using mingw64-gcc, and get a normal binary. [21:43:13 CEST] <BtbN> Or just msvc [21:43:56 CEST] <durandal_1707> wm4: use -q 0 [21:43:58 CEST] <BtbN> But the nice thing about a cygwin-aware ffmpeg is that I can give it cygwin paths, and the tty emulation from cygwin makes the cli way nicer, with colors and keyboard interaction and stuff [21:47:57 CEST] <Chloe> BtbN: are you sure POSIX_SOURCE only needs to be defined for cygwin? [21:48:19 CEST] <Chloe> how does sigaction work on mingw? [21:48:33 CEST] <BtbN> Chloe, it's defined for most other systems. But the libc autodetection fails for cygwin [21:49:11 CEST] <Chloe> So has the cygwin build failed up until now? [21:49:28 CEST] <BtbN> No, it definitely worked in the past. [21:49:40 CEST] <BtbN> I guess since ffserver started using sigaction it's broken? [21:50:09 CEST] <BtbN> hm [21:50:11 CEST] <BtbN> "2002-06-10 02:44:36 +0000" [21:50:14 CEST] <BtbN> nope, must be something else [21:50:24 CEST] <Gramner> iirc _POSIX_C_SOURCE is required for mingw to use the C99/POSIX printf family implementations instead of the ancient microsoft ones [21:50:55 CEST] <BtbN> _XOPEN_SOURCE is what sigaction is hidden behind on cygwin [21:51:01 CEST] <Chloe> BtbN: It just seems odd that it suddenly requires _POSIX_C_SOURCE (hence me just inquiring a little) [21:51:22 CEST] <BtbN> I think some change just made ffserver on cygwin start using sigaction [21:51:31 CEST] <BtbN> Or some cygwin update put it behind that macro, also possible. [21:51:49 CEST] <Gramner> sometimes using one feature test macro implicitly defines other ones as well [21:52:40 CEST] <BtbN> It most likely was a cygwin update that broke it [21:53:25 CEST] <jamrial> BtbN: don't use mintty from msys2 if you want colors and keyboard interaction. try defterm or conemu [21:53:41 CEST] <jamrial> alternatively, winpty from within mintty [21:53:48 CEST] <BtbN> I'm using MinTTY from Cygwin [21:54:16 CEST] <BtbN> colors work fine if ffmpeg is built as cygwin binary [22:03:34 CEST] <RiCON> winpty's also needed for keyboard interaction in ffmpeg/mpv [22:05:20 CEST] <BtbN> cygwin has tty emulation built in, that's why it just works there [22:06:55 CEST] <BtbN> I was kinda hoping the Ubuntu-On-Win10 thing would be interesting. But without the ability to launch windows applications from it, it's not too interesting for me. [22:24:09 CEST] <flux> I would assume someone has written a launcher to do that.. seems like such a basic need. [22:30:25 CEST] <Gramner> yeah, I'm not seing much point of the windows 10 bash implementation in it's current state. might as well run a VM if you can't interact with native windows applications anyway [23:00:34 CEST] <BtbN> That's what's so nice about cygwin. [23:00:43 CEST] <BtbN> For what it's worth, it looks like a linux API wise [23:00:51 CEST] <BtbN> but nothing stopy you from dlopen'ing a dll [23:54:54 CEST] <BtbN> Doesn't ffmpeg use yasm/nasm on pretty much all platforms? [23:55:41 CEST] <BtbN> Because I just discovered that on Gentoo it's tied to x86/amd64 and mmx support for some reason: https://github.com/gentoo/gentoo/blob/master/media-video/ffmpeg/ffmpeg-9999… [23:56:03 CEST] <Chloe> BtbN: i thought it was x86(_64) only [23:56:05 CEST] <jamrial> nasm/yasm is x86 only [23:56:15 CEST] <BtbN> what's used on arm and the like? [23:56:36 CEST] <jamrial> gas probably [23:57:06 CEST] <BtbN> hm, so the mmc dependency is probably a hack for not having to specify it twice :D [23:57:08 CEST] <BtbN> *mmx [23:58:21 CEST] <jamrial> no, it's probably a remnant from old ebuilds [23:59:06 CEST] <jamrial> afaik, --{dis,en}able-mmx is older than --{dis,en}able-asm and --{dis,en}able-yasm [23:59:41 CEST] <BtbN> I can't immediately think of a good check for amd64 || x86 [23:59:49 CEST] <BtbN> so the mmx check is quite a nice workaround [00:00:00 CEST] --- Sun Oct 2 2016

1 0

ffmpeg.log.20161001
by burek 02 Oct '16

02 Oct '16

[00:01:19 CEST] <TwinTailed> flux: that has to do with EOF? ^ [00:02:13 CEST] <flux> perhaps [00:03:00 CEST] <flux> you could ie. dump both those audio tracks and compare in audacity if it's the last frame that's missing. I guess it likely is. [00:03:11 CEST] <flux> audacity or an audio editor of your choice [00:03:17 CEST] <TwinTailed> flux: did u see the state machine code? its exacly 70 lines in total [00:04:07 CEST] <TwinTailed> flux: how do i dump audio as WAV or MP4 using ffmpeg cli? [00:05:13 CEST] <flux> ffmpeg -i foo.mp4 -map 0:1 foo.wav perhaps if audio is stream id 1 [00:06:26 CEST] <TwinTailed> flux: on my video, it says [mov,mp4,m4a,3gp,3g2,mj2 @ 01dc1780] moov atom not found [00:06:49 CEST] <TwinTailed> flux: invalid data found when processing input [00:06:59 CEST] <flux> well, that's a broken file. [00:07:08 CEST] <TwinTailed> flux: isn't ffmpeg libav supposed to be the one dealing with atoms/boxes? [00:07:16 CEST] <flux> how did you get all those dump_streams work with that? [00:07:45 CEST] <TwinTailed> flux: they just worked it seems [00:07:53 CEST] <flux> and what is giving that error? [00:08:06 CEST] <TwinTailed> flux: nvm [00:08:25 CEST] <TwinTailed> flux: it seems i have ctrl+c while transcoding [00:08:46 CEST] <TwinTailed> flux: so there exists a 700kb file :P my bad [00:09:18 CEST] <TwinTailed> flux: done, will compare them now [00:10:20 CEST] <flux> so it seems your code keeps sending avcodec_send_packet(pC[pkts->stream_index], NULL); in state 1 [00:10:41 CEST] <flux> I don't know if that's harmful, but certainly it's not required. it's expected yo send the NULL exactly once. [00:11:25 CEST] <flux> and after determining the stream is in EOF state you should stop reading from it [00:13:33 CEST] <TwinTailed> flux: https://s22.postimg.org/um4uu62m9/lastframe.png [00:13:44 CEST] <TwinTailed> flux: audacity screenshot, seems last frame is missing [00:13:53 CEST] <flux> maybe you should do these tests with much shorter files, like 3 frames, so you can step it through manually and see that it works as you expect.. [00:14:26 CEST] <TwinTailed> flux: as if i know how to hexedit atoms :P [00:14:46 CEST] <flux> you could use ffmpeg to make a shorter test file.. [00:24:05 CEST] <TwinTailed> flux: For encoding, call avcodec_receive_packet(). On success, it will return an AVPacket with a compressed frame. Repeat this call until it returns AVERROR(EAGAIN) or an error. [00:24:13 CEST] <TwinTailed> flux, thats from the doxygen doc [00:24:21 CEST] <TwinTailed> flux: what does it mean? [00:28:29 CEST] <flux> it has a special mention about AVERROR_EOF in the text describing its use [00:28:50 CEST] <TwinTailed> flux: read that long ago [00:29:15 CEST] <flux> so I'm not quite sure what you are asking.. seems pretty clear to me? [00:29:21 CEST] <flux> on success, it will return a frame [00:29:25 CEST] <flux> hmm, a packet that is [00:29:33 CEST] <flux> and if it returns EAGAIN, it has no data [00:29:35 CEST] <TwinTailed> what does it mean "repeat this call" [00:29:56 CEST] <flux> for example in a while loop [00:30:12 CEST] <flux> I don't believe it's essential to do it right away, but it's probably helpful for performance [00:30:29 CEST] <TwinTailed> oh [00:32:31 CEST] <TwinTailed> flux: might [libx264 @ 01f9d940] forced frame type (3) at 2045 was changed to frame type (1) warning be the cause? [00:32:37 CEST] <TwinTailed> many of those warnings [00:33:57 CEST] <trueroll> hi can anyone tell me how to configure to build with clang? it looks for g++ and fails (cause it's clang++) [00:34:34 CEST] <c_14> --cc=clang --cxx=clang++ [00:34:36 CEST] <c_14> probably [00:34:41 CEST] <flux> twintailed, no, because they come from the video codec, not the audio codec [00:34:54 CEST] <TwinTailed> flux: yeah, true [00:34:59 CEST] <trueroll> @c_14 I'll try that real quick [00:38:02 CEST] <trueroll> hmm now I'm getting a different error but it's using the right compiler now thx [00:39:24 CEST] <TwinTailed> flux: have u got anything for me to try to fix this missing frame from audio stream? [00:46:12 CEST] <trueroll> ah darn, still fails the C compiler test [00:48:01 CEST] <trueroll> oh the config.log has errors in it [00:50:31 CEST] <trueroll> is CPU=armv7-a invalid? [00:51:49 CEST] <trueroll> sorry I mean -march=armv7-a [00:52:56 CEST] <flux> twintailed, I suggest you log each invocation of your functions, keep track of the number of frames processed per track, and see where the discrepancy comes from [00:53:10 CEST] <flux> twintailed, I mean, in the end it means you write one audio track frame too ltitle to the file [00:53:30 CEST] <TwinTailed> flux: will do, thanks for your time :) [00:53:51 CEST] <TwinTailed> trueroll: are using a raspberry pi or an ARM device? [00:54:19 CEST] <TwinTailed> trueroll: if you are using a normal pc, then yes using -march=armv7 is invalid [00:54:39 CEST] <trueroll> I'm cross compiling from mac to android (arm) [00:54:46 CEST] <TwinTailed> ah [00:54:58 CEST] <TwinTailed> then its ok [00:55:02 CEST] <TwinTailed> but what are the errors? [00:55:11 CEST] <trueroll> error: unknown target CPU 'armv7-a' [00:59:09 CEST] <trueroll> take a look? http://pastebin.com/yMRDe8t3 [01:04:57 CEST] <TwinTailed> trueroll: CLang supports armv7, so i don't know why its failing [01:05:45 CEST] <trueroll> hmm [01:06:47 CEST] <TwinTailed> trueroll: shouldnt u use ./configure before make? [01:08:11 CEST] <TwinTailed> trueroll: https://github.com/taka-no-me/android-cmake/issues/1 [03:42:46 CEST] <Keridos> is it normal if I convert a RGB x264 video to x264 with yuv444p it has normal colors (like the original had) but if I select yuv420p the colors change dramatically? [03:43:18 CEST] <Keridos> even if I upscale the video I can clearly see a difference, but upscaling should completely remove the subsampling loss [03:59:49 CEST] <klaxa> Keridos: even with yuv444p it is ever so slightly different [04:00:12 CEST] <klaxa> the answer is yes, this is normal, rgb <-> yuv conversion is not lossless [04:00:24 CEST] <klaxa> they store information quite differently [04:06:49 CEST] <Keridos> yuv444p looks very good though [04:07:13 CEST] <Keridos> but yuv420 looks weird although I almost doubled the resolution and it downscales on my screen [04:07:34 CEST] <Keridos> technically it should look almost like the 444 output when downscaled [04:18:24 CEST] <TwinTailed> Keridos: Many video players only support yuv420p, so if compatibility is a concern, use 420p [04:19:14 CEST] <Keridos> twintailed, I am testing uploading to youtube [04:19:36 CEST] <Keridos> apparently auv444 uploads are much better in color than my own yuv420p tests [04:19:57 CEST] <Keridos> my own tests had a brighter appearence [04:20:20 CEST] <Keridos> interestingly I guess that youtube *should* automatically convert to yuv420p [04:21:06 CEST] <Keridos> so my best guess is that when I convert to yuv420p and scale the video it seems to first do the color conversion then the scaling [04:21:48 CEST] <Keridos> if it was the other way round i should technically see almost no difference since afaik yuv444p and yuv420p just decrease the resolution of the colors in pixels, not the color range itself [05:48:42 CEST] <Keridos> is there any good free video editing software for 4k 60fps yuv444 workflow? [06:16:11 CEST] <Keridos> ah i finally got the yuv420p stuff upscaled to look fine [06:51:07 CEST] <jesseg> Hmmm.. slackware linux 64, 14.2.. How do I get ffmpeg to register in pkg-config when I build/install it? [06:55:40 CEST] <Keridos> that sounds like it belongs in the slackware linux channel tbh [06:56:09 CEST] <furq> by ffmpeg do you mean libavcodec etc [06:56:11 CEST] <furq> there is no ffmpeg.pc iirc [07:03:56 CEST] <jesseg> furq, Keridos yeah I'm trying to build something that needs to find libavformat via pkg-config [07:04:38 CEST] <jesseg> ffmpeg builds, installs, and runs, but does not seem to be found in pkg-config [07:04:59 CEST] <jesseg> so other apps that need libavformat can't find it [07:05:41 CEST] <furq> do you have anything under $PREFIX/lib/pkgconfig [07:06:37 CEST] <jesseg> 358 files which seem to end in the name .pc [07:06:59 CEST] <jesseg> one of which is libavformat.. [07:07:02 CEST] <jesseg> .pc [07:07:02 CEST] <orge> i want to split h264 video without recording, as close as possible to some desired time points. so is it possible to do something like search for all keyframes, get the best pair for my desired video section (i'm assuming ffmpeg doesn't do this - i would), then split the video based on those keyframes? [07:07:22 CEST] <orge> s/recording/reencoding/ [07:09:56 CEST] <jesseg> furq, so maybe my pkg-config is just broken? [07:10:52 CEST] <furq> maybe the default pkg-config path is different on slackware [07:11:54 CEST] <furq> what do you get if you just run `pkg-config --libs libavcodec` [07:12:55 CEST] <jesseg> furq, hmmm, you know what, I have a /usr/lib and a /usr/lib64, and PKG_CONFIG_PATH lists only /usr/lib64 while libavformat.pc is in /usr/lib/pkgconfig/ [07:13:01 CEST] <jesseg> so I bet that's my problem [07:13:23 CEST] <furq> PKG_CONFIG_PATH is normally unset, although idk how slackware does things [07:13:29 CEST] <furq> but yeah you should just be able to add /usr/lib to it [07:13:42 CEST] <jesseg> I probably got a slight scramble when I set up for 32/64 bit program support [07:14:42 CEST] <jesseg> furq, ha! Now it's listing (Added it to path.) Thanks! [07:16:18 CEST] <furq> orge: i'm pretty sure ffmpeg just cuts at the closest keyframe to the specified time [07:24:21 CEST] <jesseg> furq, How can I compile libavcodec (and all of ffmpeg's libraries) with -fPIC? mlt seems to need it. [08:19:38 CEST] <furq> jesseg: you probably just want --enable-shared [09:46:10 CEST] <orge> mkv containing audio, video, and subtitles are inputted. `ffmpeg -ss 40 -i in.mkv -t 5 -map 0 -c copy out.mkv` is the command. output is then ~20s of nothing followed by the 5s region i'm looking for. it's not because the video or audio keyframes are that far back though, it seems to because the last subtitle [09:46:36 CEST] <orge> was about 20s ago. this seems like strange behavior [09:51:55 CEST] <orge> (the subtitle from 20s ago doesnt persist into the region where the audio/video starts and if i just map audio and video then i get what i want) how can i fix this? [11:13:55 CEST] <Snicksie_> hi all, I'm trying to convert some videos from x265 to x264, but the resulting quality is not satisfiable at all (crf=23). Can I find out from existing videos (from another source, that I only have in x264) what their crf value is, so I can use that same value for my x265 videos? [11:14:44 CEST] <furq> mediainfo will show you [11:14:51 CEST] <furq> just use 18-20 though [11:15:14 CEST] <furq> 23 is quite low even for hd stuff [11:17:15 CEST] <Snicksie_> allright, I'll take a look at mediainfo :) [11:21:24 CEST] <Snicksie_> nice thanks, that works furq :) [11:57:35 CEST] <Snicksie> so I tried to convert a video once more with crf=18, but the quality is still as bad as ever... even with a crf of 10 or lower there's no difference... is there anything wrong in the way I execute ffmpeg? :) [11:57:53 CEST] <Snicksie> ffmpeg -i $i -c:s copy -crf 18 -c:a copy $newname [11:59:36 CEST] <Snicksie> filesize doesn't seem to change depending on the crf, which is also unexpected [12:02:09 CEST] <furq> what's $newname [12:02:25 CEST] <furq> if it's not a container which defaults to x264 then you need to specify -c:v libx264 [12:04:03 CEST] <Snicksie> $newname is something.mkv, but your right, aparently the output format is Format settings, Matrix : Default (H.263) [12:04:11 CEST] <Snicksie> that seems incorrect [12:04:59 CEST] <furq> matroska should default to x264 [12:05:49 CEST] <furq> there's no harm in specifying though [12:06:54 CEST] <Snicksie> that resulted in Unknown encoder 'libx264' [12:07:27 CEST] <furq> your ffmpeg wasn't built with libx264 then [12:08:28 CEST] <Snicksie> yeah, I'll rebuild, as soon as I find where I compiled it last time :p [12:10:15 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [12:10:18 CEST] <furq> just use that if you're on linux [12:13:44 CEST] <Snicksie> apparently last time I used the git repo, any harm in that? :p [12:14:18 CEST] <Snicksie> ah this one is as well, seems perfect [12:14:19 CEST] <furq> if you really want to compile it yourself then sure [12:14:28 CEST] <furq> but unless you need some weird libs then those static builds are pretty much fine [12:16:34 CEST] <Snicksie> allright, that seems to be reencoding slower, so I hope this will give me the quality I've been looking for :) [12:20:53 CEST] <Snicksie> thanks, quality looks great so far! [12:32:03 CEST] <markvandenborre> does anyone know about ways to accelerate vp9 encoding significantly [12:32:30 CEST] <markvandenborre> from the standard "throw a file at the libvpx encoder" method? [12:32:37 CEST] <markvandenborre> that one is horrendously slow [12:34:37 CEST] <markvandenborre> if possible, we would like to offer vp9 streaming of our FOSS conference [12:35:04 CEST] <markvandenborre> but it looks as if nothing much comes even close to allowing that [12:35:34 CEST] <markvandenborre> there's a recent mali gpu that offers hardware acceleration, but no FOSS support for that [12:35:50 CEST] <markvandenborre> and few others seem to do it [12:37:18 CEST] <markvandenborre> the only option I could think of would be an experiment with somewhat delayed streaming [12:37:55 CEST] <markvandenborre> where one could put multiple cores to work by feeding them slices [12:38:11 CEST] <markvandenborre> then cobbling things back together afterwards [12:38:26 CEST] <markvandenborre> is there any option for that kind of crude peudo-multithreading? [12:38:29 CEST] <markvandenborre> in ffmpeg? [12:39:16 CEST] <markvandenborre> or am I thinking stupid things? [12:58:03 CEST] <markvandenborre> is there anything better for vp8? [13:17:43 CEST] <ChocolateArmpits> markvandenborre: new line of intel processors support hardware encoding [13:19:38 CEST] <ChocolateArmpits> Simple slicing won't work as you can't just simply combine encoded frames afterwards [13:19:48 CEST] <ChocolateArmpits> I mean parts of a frame [13:19:51 CEST] <furq> the intel vp9 stuff is only partially accelerated afaik [13:20:03 CEST] <furq> but you can use sliced multithreading with libvpx [13:21:51 CEST] <furq> markvandenborre: use -tile-columns and -threads [13:22:10 CEST] <furq> -tile-columns 2 -threads 4 is recommended for 720p and 1080p according to an old mailing list post [13:22:46 CEST] <furq> you lose a bit of encoding efficiency but it should be much faster (which shouldn't be difficult) [13:23:15 CEST] <radia> What do I write if i don't want to use VP9? I want to use VP8 instead. [13:23:22 CEST] <furq> -c:v libvpx [13:23:39 CEST] <furq> or -c:v vp8 might work these days [13:25:20 CEST] <furq> markvandenborre: there's also -speed which is something like x264 -preset [13:25:27 CEST] <furq> -speed 4 is the fastest, 0 is the slowest [13:26:35 CEST] <ChocolateArmpits> Do these options while increasing speed not throw the video quality down to the stone age? [13:26:49 CEST] <furq> they sure do [13:29:37 CEST] <furq> well, -speed does [13:29:49 CEST] <furq> sliced multithreading isn't that bad [13:32:28 CEST] <markvandenborre> furq: ChocolateArmpits : thanks a lot [13:32:35 CEST] <markvandenborre> will experiment with those! [13:37:21 CEST] <furq> -speed 4 actually looks pretty much fine with -crf [13:37:39 CEST] <furq> i'm guessing this is going to be mostly static shots of guys standing awkwardly near laptops [13:38:18 CEST] <furq> explaining why enlightenment 17 is actually good and not bad like you thought it was [13:47:05 CEST] <markvandenborre> heh, this is about https://fosdem.org [13:47:27 CEST] <markvandenborre> so some of the developers behind that project might be there, yes :p [13:49:53 CEST] <ritsuka> you should fund a FOSS conference to speed up vp9 ;) [13:50:04 CEST] <markvandenborre> and not a lot of changes in camera view expected [13:50:24 CEST] <markvandenborre> ritsuka: there is an actual open media devroom at fosdem [13:50:52 CEST] <markvandenborre> so the joke is not as far fetched as you would think :-) [13:53:08 CEST] <markvandenborre> I know that for h264, there are some projects that do hardware acceleration with dedicated c66x asicswith a FOSS patch to ffmpeg [13:53:26 CEST] <markvandenborre> just making sure noone knows about anything like that for vp8 or vp9? [13:58:05 CEST] <markvandenborre> we have a few rather powerful servers, but they're mostly powerful due to them beingr quad hexacore multithreaded... [14:04:29 CEST] <Mavrik> markvandenborre, libvpx should have a speed option for both VP8 and VP9 [14:04:38 CEST] <Mavrik> which kinda determines CPU usage vs. quality [14:04:49 CEST] <Mavrik> tweaking that should at least get you to 30fps on a decent quad core [14:05:11 CEST] <furq> 25, you mean [14:06:55 CEST] <Mavrik> Whatever he's targeting. [14:17:59 CEST] <PannenkoekenNL> How do I set the language of audio stream 1 to Chinese (chi) and audiostream 2 to Malay (may) for 150 .mp4 files in one folder? [14:29:24 CEST] <markvandenborre> Mavrik: will have a look [14:30:05 CEST] <markvandenborre> these machines are rather old (Xeon E7530) [14:30:14 CEST] <markvandenborre> but they have a lot of cores available [14:32:38 CEST] <markvandenborre> which is what I was looking to optimise encoding of live streams for [14:33:18 CEST] <markvandenborre> since we have 24 rooms in parallel, some optimisation effort is warranted... [14:34:03 CEST] <furq> if you can get tile-columns working then i'd expect you to get 25fps at 720p [14:35:10 CEST] <markvandenborre> furq: that's exactly what we're targetting [14:37:07 CEST] <furq> i guess if all else fails you could look for some westmere-ep chips with a higher base clock [14:37:32 CEST] <furq> actually nvm that's a different socket [14:38:11 CEST] <markvandenborre> yeah, we're trying to get the most out of the existing hardware [14:38:23 CEST] <furq> i guess if all else fails you would actually just use h264 [14:38:34 CEST] <markvandenborre> if we can reliably squeeze webm/vp9 out of it, we wil [14:38:36 CEST] <markvandenborre> l [14:38:54 CEST] <markvandenborre> otherwise it will be h264 streams and reencoding webm afterwards [14:39:39 CEST] <markvandenborre> cpu time is ridiculously cheap nowadays [14:40:06 CEST] <furq> i guess westmere-ex would fit but i bet those are still expensive [14:40:10 CEST] <furq> westmere-ep stuff is really cheap now [14:40:26 CEST] <markvandenborre> the problem is mainly that for our solution, we really need the initial encoding to be on site [14:40:56 CEST] <markvandenborre> and we know we can do the h264 stuff with existing hardware... [14:41:16 CEST] <markvandenborre> with almost zero expenses for post conference webm reencoding [15:43:30 CEST] <markvandenborre> furq: so if we would need new hardware, this might be hard to justify [15:43:48 CEST] <markvandenborre> furq: thx again for your hints [15:43:50 CEST] <furq> i only suggested upgrading because westmere-ep is really cheap now [15:44:04 CEST] <furq> i imagine westmere-ex isn't because it's a rarer socket [15:44:12 CEST] <markvandenborre> k [15:44:19 CEST] <markvandenborre> will keep that in mind [15:45:03 CEST] <furq> ep is lga1366 which is no good [18:53:40 CEST] <Cork> anymore know if there is a program to clean up white buzz from video copied from old vhs tapes? [18:56:50 CEST] <Spring> Cork, there's probably some AviSynth script for that [18:57:03 CEST] Action: Spring is afk [19:06:48 CEST] <Cork> thx, will look [19:53:03 CEST] <TwinTailed> [libav], when transcoding to h264, i am getting a missing audio frame (last frame) [19:53:17 CEST] <TwinTailed> i am dealing with EOF correctly I guess [19:53:33 CEST] <TwinTailed> video frames are all there, just the audio frame is missing [20:06:10 CEST] <ChocolateArmpits> TwinTailed: Maybe the audio stream lasts longer than the video stream? [20:06:26 CEST] <ChocolateArmpits> Did you try updating your build of ffmpeg ? [20:06:48 CEST] <ChocolateArmpits> You can try -longest command, it will encode until the longest stream [20:06:49 CEST] <orge> it seems that `ffmpeg -ss 40 -i "out5.mkv" -t 5 -map 0 -c:v copy -c:a flac out6.mkv` will have video starting from the closest keyframe before 40s, and audio starting from exactly 40s. is there a way to make the audio seek match the video seek, if that makes sense [20:07:10 CEST] <TwinTailed> ChocolateArmpits: avformat read_packet should read me all packets, regardless which is more, and i am not looping depending on the number of frames [20:07:19 CEST] <ChocolateArmpits> orge: Use -ss after the input [20:07:22 CEST] <TwinTailed> and yes i am using yesterday's build [20:07:40 CEST] <TwinTailed> ChocolateArmpits: I am using Libav not ffmpeg CLI [20:07:49 CEST] <TwinTailed> ffmpeg's libav of course [20:07:52 CEST] <ChocolateArmpits> TwinTailed: sorry can't help with api [20:09:34 CEST] <orge> ChocolateArmpits, it seems that this changes the behavior so that the video starts at the closest key frame AFTER the specified time, and audio audio still starts at the specified time [20:10:21 CEST] <ChocolateArmpits> orge: Well then you need to transcode the video frames [20:10:44 CEST] <orge> ChocolateArmpits, i'm trying to copy video frames and transcode audio, for speed [20:11:16 CEST] <ChocolateArmpits> You frames copied from a middle of a gop will be garbled on playback [20:11:21 CEST] <ChocolateArmpits> frames copied * [20:12:44 CEST] <orge> i'm not trying to copy the video from a specific frame [20:13:18 CEST] <ChocolateArmpits> So you want the audio to match the video frame ? [20:13:55 CEST] <orge> yeah, i want the audio frames to be the exact same window as the video frames, which are determined by the keyframes [20:14:10 CEST] <orge> i feel like this should be possible with transcoded audio, but maybe ffmpeg just doesn't support it? [20:14:46 CEST] <ChocolateArmpits> They behave separately [20:15:22 CEST] <ChocolateArmpits> I did something similar a few times, you will have to get the closest keyframe location using ffprobe and then use the time there as the seek point [20:15:50 CEST] <orge> okay. can you throw some helpful commands my way? :p [20:21:27 CEST] <ChocolateArmpits> orge: hmm before anything, try -async 1 [20:23:54 CEST] <ChocolateArmpits> it -should- cut off audio frames at the very start [20:24:01 CEST] <ChocolateArmpits> Haven't tested it [20:25:10 CEST] <orge> doesn't seem to do anything at all. according to the docs "This option has been deprecated. Use the aresample audio filter instead. " [20:28:57 CEST] <orge> but it stretches/squeezes instead of cutting, so i'm gonna go with the ffprobe method [21:26:54 CEST] <TwinTailed> [libav], when transcoding to h264, i am getting a missing audio frame (last frame) [22:27:28 CEST] <krs_> Is there any PPA for Ubuntu 16.04 providing FFmpeg with libvpx and libopus ? [22:46:22 CEST] <twizz> Hi - i'm looking to have a polling volumedetect (every second) on a running RTMP stream, that outputs to a file. Possible with FFMPEG? [23:04:07 CEST] <Snicksie> /wc [23:29:26 CEST] <s0126h> is it true no computer/CPU is powerful enough to decode 8K video [23:30:52 CEST] <JEEB> heavily depends on the format as well as the decoder's amount of optimizations as well as what picture rate is used with the content [23:31:24 CEST] <JEEB> like, let's take the HEVC decoder there is in libavcodec. it's slow, so even 2160p30 is hard pressed on many quad cores [23:31:27 CEST] <s0126h> so it's a yes ro some 8k video [23:31:29 CEST] <s0126h> for* [23:31:52 CEST] <JEEB> it's so generic that it doesn't make sense :P [23:32:21 CEST] <s0126h> so nothing can decode 4k hevc video? [23:32:28 CEST] <JEEB> no? [23:32:44 CEST] <s0126h> other than getting special hardware decoders [23:32:47 CEST] <JEEB> ugh [23:33:30 CEST] <JEEB> you seem to not grasp the idea of "there's different types of content, there's different picture rates, there's different systems, there's different implementations of a format" [23:34:30 CEST] <Spring> is HEVC more taxing for decoding than AVC currently? [23:35:02 CEST] <Spring> as it's already possible to capture at resolutions like 4K in games currently using the latter [23:35:20 CEST] <JEEB> that's encodin [23:35:22 CEST] <JEEB> *encoding [23:35:44 CEST] <JEEB> the best example lately for decoding is the HEVC decoder which is currently slow, if you were dumb to think that's the only decoder around you'd say that 2160p30 and 2160p60 are really hard to achieve on it with many systems. but you can't say something is impossible. a good example of that is the fact that there are patches that optimize the decoder in a way that certain types of systems handle 2160p60 just [23:35:45 CEST] <Spring> I know, two different comments [23:35:50 CEST] <JEEB> fine [23:36:35 CEST] <JEEB> so in general people who say "X is impossible with CPUs" are the marketing people who know they're making an overbroad statement and who might not be afraid to lie [23:36:55 CEST] <JEEB> but of course if you start discussing details that's no longer as raffing for marketing [23:37:38 CEST] <s0126h> jeeb why do you keep using 2160 example most people use 1080p or 4k or 8k [23:37:59 CEST] <JEEB> 2160p usually refers to 16:9 2160p [23:38:06 CEST] <JEEB> while 4K refers to something wider than 16:9 [23:38:10 CEST] <JEEB> same for 8K [23:38:41 CEST] <JEEB> of course the marketing people don't care and utilize the wording "4K" for 3840x2160 [23:39:47 CEST] <JEEB> and 2160p is the current high-end of end user production encodes [23:39:57 CEST] <JEEB> 2160p60 being a thing [23:40:10 CEST] Action: Spring takes thing [23:40:46 CEST] <Spring> HEVC sounds like it has ways to go [23:41:28 CEST] <JEEB> HEVC as a format is good, but it's currently being killed off by the sales/marketing/whatever folk who thought they didn't get enough from AVC licensing [23:41:42 CEST] <JEEB> and libavcodec-wise nobody really cares to optimize things :P [23:41:52 CEST] <s0126h> what is cheaper to use right now? avc or hevc [23:42:01 CEST] <JEEB> in what sense cheaper? [23:42:08 CEST] <s0126h> licensing ee [23:42:09 CEST] <s0126h> fee [23:42:32 CEST] <JEEB> probably AVC I'd say, HEVC is kind of in the middle of bullshit because we have multiple patent pools and then some lone actors doing licensing [23:42:45 CEST] <JEEB> one of the main things for AVC was that if you needed a license you got it from a single place [23:42:53 CEST] <s0126h> is mpeg2 expired now and free? [23:43:01 CEST] <JEEB> dunno, haven't looked at that stuff :P [23:43:02 CEST] <Spring> AV1 is the chosen 1 [23:43:23 CEST] <JEEB> Spring: yeah - different companies sure picked up on that as the HEVC mess started rolling [23:43:30 CEST] <JEEB> we'll see how it ends [23:43:47 CEST] <s0126h> jeeb i see, sounds like hevc is in mess right now with all the patent/licensing [23:44:14 CEST] <JEEB> almost would make me feel sorry for the format if it was a person :P [23:44:24 CEST] <JEEB> because HEVC does have good things in it [23:45:18 CEST] <s0126h> with all the patents/licensing how is x264/x265 completely free then [23:58:51 CEST] <JEEB> s0126h: software licenses and patent licensing are a completely different thing [23:59:18 CEST] <JEEB> esp. if you don't provide binaries. neither x264 or x265 do that [23:59:29 CEST] <s0126h> why? both makes money for the author/inventor [00:00:00 CEST] --- Sun Oct 2 2016

1 0