Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2016

1 participants
58 discussions

ffmpeg-devel.log.20160223
by burek 24 Feb '16

24 Feb '16

[00:00:11 CET] <j-b> michaelni: well, I'm fighting with my Rémi over this issue, atm [00:00:27 CET] <j-b> pfff, pain in the neck, some people are, over semantics [00:01:09 CET] <wm4> check the processname, if it's vlc, don't print the message [00:01:27 CET] Action: wm4 runs [00:01:42 CET] <michaelni> j-b, ok, thanks, ill wait [00:02:08 CET] <j-b> wm4: lol [00:02:34 CET] <JEEB> were there any other "wallclock as timestamp" kind of things than that one parameter added in 2012 or so? [00:03:00 CET] <JEEB> basically I was thinking of something like itsoffset except having it get current time [00:03:13 CET] <JEEB> and have that as the initial offset for timestamps [00:04:16 CET] <JEEB> as some livestreaming thingies seem to like such [00:21:37 CET] <cone-628> ffmpeg 03Carl Eugen Hoyos 07master:44cf5b41d33a: lavfi/nnedi: Fix a memleak. [00:24:05 CET] <cone-628> ffmpeg 03Carl Eugen Hoyos 07master:37afeabd1b83: lavfi/nnedi: Fix a compilation warning. [01:22:44 CET] <cone-628> ffmpeg 03James Almer 07master:45d3af90593a: x86/dcadec: add ff_lfe_fir1_float_{sse3,avx} [01:40:20 CET] <JEEB> I guess I'll throw this for review tomorrow https://github.com/jeeb/ffmpeg/commits/isml_improvements [01:51:33 CET] <ethe> JEEB: how do I test an output avdevice? [02:00:34 CET] <ethe> got it: ffmpeg -i movie.mkv -f sdl2 "title" -f sdl2 "SDL2 test title" [02:17:01 CET] <ethe> so, I mostly got SDL2 avdevice output working, but it seems to be playing at 3x speed [02:17:47 CET] <ethe> looks like it's not getting rate limited or something like that [02:26:05 CET] <Timothy_Gu> ethe: try ffmpeg -re -i movie.mkv -f sdl2 bleh [02:26:53 CET] <ethe> that works a lot better [02:27:08 CET] <ethe> well, it's at the right fps now [02:29:11 CET] <ethe> Timothy_Gu what exactly is the sdl output meant to do? [02:36:14 CET] <Timothy_Gu> ethe: well& it's supposed to display video using libSDL? [02:37:19 CET] <Timothy_Gu> From man page: -re Read input at native frame rate. By default ffmpeg attempts to read the input(s) as fast as possible. This option will slow down the reading of the input(s) to the native frame rate of the input(s). [02:37:53 CET] <ethe> ah, so -f sdl is like a raw output kinda thing [02:47:38 CET] <ethe> Timothy_Gu do you know if the window should be able to be dynamically resized? [02:48:07 CET] <Timothy_Gu> ethe: you should focus on getting feature parity at this point [02:48:13 CET] <Timothy_Gu> did sdl support dynamic resizing? [02:48:29 CET] <Timothy_Gu> I didn't check but I don't think so, so I'd say no [02:48:56 CET] <ethe> maybe? "case SDL_VIDEORESIZE" [02:49:27 CET] <ethe> I'm not sure, I only have 1080p video, but my screen resolution is lower, so I can't get to the bottom right corner of the video to test resizing [02:49:43 CET] <ethe> which is a bad excuse, I should just get some lower res video [02:51:34 CET] <Timothy_Gu> ethe: you can use -f lavfi -i testsrc [02:51:58 CET] <Timothy_Gu> i.e. using the testsrc video source filter [02:52:22 CET] <ethe> yeah, anyway to output yuv420p, yuyv422, or uyvy422 with that? [02:52:42 CET] <ethe> input* [02:55:34 CET] <ethe> got it. -pix_fmt yuyv422 [03:18:48 CET] <ethe> Oddly enough there seems to be two output 'files' which seems to be messing up the threads [03:19:54 CET] <ethe> .-. that might be because I set two outputs... [03:44:58 CET] <Timothy_Gu> ethe: how? [03:45:06 CET] <Timothy_Gu> don't tell me SDL is not thread-safe... [05:24:26 CET] <cone-628> ffmpeg 03James Zern 07master:7586b3adf229: libvpxenc: quiet unused-variable warning [08:56:25 CET] <JEEB> wbs: when you have the time could you check these two patches (since you IIRC originally made these) https://github.com/jeeb/ffmpeg/commits/isml_improvements [08:56:42 CET] <JEEB> (these muxers) [09:03:59 CET] <ethe> Timothy_Gu it doesn't look like the original SDL device is (not that I've tested it) [11:55:54 CET] <ubitux> http://b.pkh.me/psysrc.webm mixing up chroma can be artistic [12:10:26 CET] <JEEB> yeah, I remember the times when hw decoders and renderers mismatched each other [12:10:32 CET] <JEEB> led to some pretty fabulous results [12:10:46 CET] <JEEB> (add corrupted decoding results to the mix, too) [12:12:31 CET] <ubitux> here the glitch was because the chroma linesizes were used 4x instead of 2 (yuv420p); i like the wave effect it has on testsrc2 pattern [12:13:41 CET] <ubitux> i wonder if i can reproduce this with a filter [12:13:52 CET] <ubitux> anyway. [12:14:06 CET] <JEEB> oh right, the wave update effect [12:15:16 CET] <ubitux> there is also a libvpx fuckery in the process [12:15:34 CET] <ubitux> which is actually probably responsible for this wave effect [12:27:49 CET] <jkqxz> ^ what? Application-Specific Integrated Circuits are application-specific, maybe. [12:41:14 CET] <nevcairiel> people just read that ASICs are super fast for one task and think, hey why cant it be fast for another task! [12:43:35 CET] <ubitux> when are we going to stop allowing markup on the trac :( [12:43:46 CET] <ubitux> users are so dumb :( [12:44:21 CET] <ubitux> we need to make stats, but i feel like it's something around 4/5 users fail at markup [13:53:48 CET] <JEEB> wbs: thanks for the comments :) [13:54:16 CET] <JEEB> I might have been a bit tired [13:55:43 CET] <JEEB> funny how I didn't see edts in the boxdumper (when doing ISM at least). I was trying to see where else timestamps could be written [13:56:17 CET] <JEEB> but yes, if we are making a generic option it should also work with those [15:03:50 CET] <Timothy_Gu> https://trac.ffmpeg.org/ticket/5259#comment:10 ugh [15:13:16 CET] <nevcairiel> Timothy_Gu: also http://pastebin.com/NN2A0nGG configure with --cpu=haswell on x86_32 [15:14:02 CET] <nevcairiel> inline asm and autovec dont like each ohter [15:37:08 CET] <ubitux> http://pastie.org/pastes/10734275/text i fucking hate gdb somet^Wall the time [15:48:38 CET] <Timothy_Gu> nevcairiel: would a patch adding a function attribute asking gcc to skip vectorizing such a function be acceptable? [15:48:59 CET] <Timothy_Gu> av_novectorize [15:52:26 CET] <cone-175> ffmpeg 03Carl Eugen Hoyos 07master:2aa21eec1adc: postproc: fix unaligned access [15:58:59 CET] <cone-175> ffmpeg 03Carl Eugen Hoyos 07release/3.0:449ff0e3fd47: postproc: fix unaligned access [15:59:00 CET] <cone-175> ffmpeg 03Oliver Collyer 07release/3.0:b80083a5c17a: ffserver&ffm: Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming. [16:04:19 CET] <wm4> this shit is so inconsistent... try_decode_frame() in libavformat/utils.c also tries partial video packet decoding [16:04:46 CET] <wm4> even though it explicitly prevents it for subtitles [16:19:05 CET] <cone-175> ffmpeg 03Muhammad Faiz 07master:6eb4021d47cc: avfilter/avf_showcqt: use lrint [16:19:08 CET] <BBB> why do we have autovec anyway [16:19:21 CET] <BBB> in cases where autovec helps, isnt that an indication we should hand-write some simd? [16:19:28 CET] <BBB> its not like we have a shortage of x86 simd authors [16:21:17 CET] <J_Darnley> Some on us are pretty mediocre though. [16:21:27 CET] <J_Darnley> *of [16:22:07 CET] <J_Darnley> Well, I know at least one of us is. [16:31:09 CET] <durandal_1707> you? [16:31:55 CET] <J_Darnley> yes [16:32:11 CET] <durandal_1707> it helps for vf_phase dunno how much compared to hand written one [16:32:55 CET] <durandal_1707> BBB: write utvideo SIMD? [16:32:58 CET] <wm4> I say our asm should be robust enough that this should not happen? modulo compiler bugs [16:38:38 CET] <nevcairiel> well inline asm walks all over compiler smarts and really restricts what it can do, so its not unheard of that it causes all sorts of problems [16:39:20 CET] <nevcairiel> yasm is of course unaffected [17:17:20 CET] <wm4> evil plan 2 was pushed in Libav [17:17:37 CET] <nevcairiel> see me care this much: || :P [17:17:50 CET] <durandal_1707> so merge it [17:18:03 CET] <nevcairiel> like i said over there, its extremely underwhelming, its only for his need of cleanliness, as an api user it doesnt benefit me [17:24:49 CET] <iive> is that renaming of codec into codecpar in 300 files? [17:25:09 CET] <iive> and having separate patch for every file? [17:25:25 CET] <nevcairiel> that was only for review purposes [17:26:51 CET] <iive> yeh, 300 mails really make things easier to review :Z [17:30:53 CET] <ubitux> so we're going to need to rush a merge? [17:31:12 CET] <nevcairiel> why [17:31:15 CET] <ubitux> or can it be done progressively? [17:31:21 CET] <nevcairiel> no [17:31:24 CET] <nevcairiel> well kinda [17:31:32 CET] <nevcairiel> you can fix it in some other git repo and push it once its done =p [17:31:41 CET] <ubitux> yeah right, so just like last time [18:00:31 CET] <cone-175> ffmpeg 03Mats Peterson 07master:3ba57bfe8ddc: lavf/riffenc: Handle AV_PIX_FMT_MONOBLACK [18:32:35 CET] <ethe> hmm, does sdl outdev currently work on OSX? (it doesn't work for me) [18:33:29 CET] <nevcairiel> i doubt many people use these outdevs, they are rather obscure [18:38:48 CET] <JEEB> such audio/video rendering avdevices are quite weird [18:52:57 CET] <ethe> indeed, I cannot see a point for them other than maybe a live preview [18:56:14 CET] <ethe> JEEB: I just wanted a baseline for SDL2, because I'm not quite sure how SDL looked/performed. So I tried to revert back to SDL to check, and it doesn't even work :( I'm just trying to find out: did it have window borders, was it resizable? [18:56:56 CET] <cone-175> ffmpeg 03Stefano Sabatini 07master:14f7a3d55a43: lavc/lavf: transmit stream_id information for mpegts KLV data packets [19:08:33 CET] <Timothy_Gu> ethe: for window borders etc. it's usually platform-dependent [19:09:19 CET] <ethe> Timothy_Gu: SDL2 standardises it iirc, you either set them on or off. [19:09:33 CET] <Timothy_Gu> then add an option [19:09:45 CET] <Timothy_Gu> i'd default to true [19:12:49 CET] <Timothy_Gu> also what do you mean it doesn't work? [19:13:45 CET] <ethe> it doesnt display the window, and throws no errors (event with -v trace) [19:18:09 CET] <Timothy_Gu> works fine on windows (I'm at school so I' don't have access to linux but it probably works too) [19:19:11 CET] <Timothy_Gu> it does have window borders, and though it's "resizeable," it's broken, (pixels outside of the image are not zeroed) [19:19:16 CET] <ubitux> ok, finally able to reproduce yuv420p-to-rgba mmx code in C using the generic yuv2rgb constants [19:19:23 CET] <ubitux> here it is for the record http://pastie.org/10734602 before i lost it [19:19:46 CET] <ubitux> now i can make the arm/aarch64 consistent with this [19:19:54 CET] <ubitux> by fixing the current 16-bit path and dropping the 32 [20:01:49 CET] <jamrial> ubitux: you mean there was no c version already? only mmx? [20:02:07 CET] <ubitux> bitexact with mmx there isn't any [21:04:29 CET] <ubitux> "pcmpeqd %%mm"REG_ALPHA", %%mm"REG_ALPHA"\n\t" /* set alpha to 0xFF */ [21:04:40 CET] <ubitux> heh, funny way of doing that [21:04:46 CET] <JEEB> wait what [21:05:32 CET] <ubitux> pcmpeqd m0,m0 [21:05:34 CET] <JEEB> oh right, "If a pair of data elements is equal, the corresponding data element in the destination operand is set to all 1s" [21:12:36 CET] <nevcairiel> its pretty common way of 1'ing a reg [21:13:22 CET] <J_Darnley> I must keep that trick in mind. [21:20:21 CET] <Mavrik> Hmm, I have stream checkers going a bit crazy around PCR jitter for ffmpeg generated MPEG-TS streams. Is that considered ticket worthy? [21:22:18 CET] <JEEB> it is, unless there's already a ticket for that. generally the libavformat muxer has so far been barely usable for the dumber scenarios (HLS et al) [21:23:35 CET] <Mavrik> Yeah :/ [21:23:42 CET] <Mavrik> I guess we have no OSS alternatives? [21:26:44 CET] <JEEB> see VLC's muxer I guess? or kierank's? [21:27:01 CET] <JEEB> there are multiple libraries (libdvbpsi, whatever that other thing was?) [21:27:06 CET] <JEEB> biTStream? [21:29:28 CET] <ubitux> is it OK in x86 to alter the stack area where the arguments of the function are? [21:30:00 CET] <Mavrik> JEEB, ah, I'll take a poke and make a ticket for ffmpeg as well :) [21:30:04 CET] <Mavrik> thanks [21:30:13 CET] <J_Darnley> ubitux: sometimes [21:30:23 CET] <ubitux> "sometimes"? :( [21:30:38 CET] <J_Darnley> see the problem with my recent h264 patch [21:31:08 CET] <J_Darnley> If you don't ask for stack space then it is fine [21:31:08 CET] <nevcairiel> stack handling is tricky when considering all available platforms [21:31:27 CET] <nevcairiel> its also fine if oyu have enough regs for a stack pointer [21:31:38 CET] <nevcairiel> but that leaves only 6 to work with on x86 [21:33:03 CET] <ubitux> sadness [21:33:18 CET] <ubitux> i'm going to have a bad time with these 13 args [21:33:28 CET] <nevcairiel> probably [21:33:36 CET] <nevcairiel> should re-think the signature if you really need them all =p [21:33:43 CET] <J_Darnley> if you do need stack space then adjust manually and remember it can be unaligned. [21:33:49 CET] <ubitux> nevcairiel: yeah i really do unfortunately [21:34:07 CET] <ubitux> OR, i could add a struct to contain them all [21:34:17 CET] <nevcairiel> that doesnt really change anything [21:34:25 CET] <nevcairiel> now the "struct" is the stack [21:34:37 CET] <ubitux> there are helper to access the struct field [21:34:56 CET] <ubitux> i can have like 3 args, including a pointer to the struct params, and directly access fields [21:35:01 CET] <ubitux> and still have a bunch of reg to play with [21:35:05 CET] <ubitux> maybe i should do that [21:35:13 CET] <nevcairiel> i dont see how that changes anything [21:35:31 CET] <nevcairiel> right now you can just access all fields from the stack when you need them [21:35:57 CET] <nevcairiel> afterwards you need an extra layer of indireciton to load the address and then load the entry [21:36:11 CET] <nevcairiel> or keep the address in a reg permanently, but same deal [21:36:18 CET] <ubitux> but many reg are used to contain parameters by default, right? [21:36:39 CET] <ubitux> so even though i can access directly extra args on the stack, i have my reg "saturated" [21:37:50 CET] <ubitux> anyway, i'm goign to try without a struct first [21:38:58 CET] <nevcairiel> x86 cdecl ABI passes all arguments on the stack iirc [21:39:24 CET] <kurosu_> yes [21:39:42 CET] <nevcairiel> x64 is a bit weirder, it passes a few in regs, and also depending on win64 or unix64 [21:39:48 CET] <kurosu_> WIN64 and ??? (SYSV64?) behave differently [21:40:51 CET] <wm4> amazing, something as simple as vf_copy is broken [21:41:10 CET] <wm4> it accepts hwaccel formats, without treating them correctly [21:41:27 CET] <nevcairiel> sounds like its "too simple" =p [21:41:28 CET] <ubitux> hwaccel were recently allowed in lavfi [21:41:33 CET] <ubitux> they weren't previously [21:41:41 CET] <ubitux> poke anton [21:41:43 CET] <wm4> whatever that means [21:41:50 CET] <ubitux> hwaccel pixfmts* [21:41:53 CET] <nevcairiel> lavfi blocked them entirely before [21:42:09 CET] <ubitux> see ae25413d [21:42:21 CET] <wm4> ah, makes sense [21:43:11 CET] <wm4> is there a vf_nop? [21:43:23 CET] <nevcairiel> whats it do, eat your frames? [21:43:30 CET] <ubitux> passthrough? [21:43:37 CET] <wm4> like vf_copy, except not copying [21:43:40 CET] <ubitux> try select=1 [21:43:44 CET] <nevcairiel> why would that exist :D [21:43:52 CET] <nevcairiel> but yeah select can probably fake that =p [21:44:00 CET] <wm4> ubitux: that works [21:44:14 CET] <ubitux> maybe a bit slow [21:44:28 CET] <ubitux> lemme check if we have another one& [21:44:35 CET] <wm4> nevcairiel: well, sometimes you might want to be able to have the user to specify a "connection" between a src and a sink, without any actual filters [21:44:53 CET] <wm4> since the graph parser can't connect them directly, you need a dummy filter (apparently) [21:45:57 CET] <ubitux> ah, null! [21:46:07 CET] <ubitux> vf_null should do that [21:46:38 CET] <wm4> ah, indeed [21:47:15 CET] <wm4> I would think of null something that eats all input, though [21:48:06 CET] <Timothy_Gu> wm4: that's nullsink [21:49:20 CET] <wm4> makes sense [22:45:26 CET] <kierank> what happened to __gb__ [22:52:30 CET] <wm4> good question [23:10:24 CET] <ethe> where are AV_PIX_FMT_*s defined? [23:10:36 CET] <nevcairiel> avutil/pix_fmt.h or something [23:10:38 CET] <nevcairiel> maybe pixfmt.h [23:10:41 CET] <nevcairiel> one of thsoe [23:10:47 CET] <wm4> really just takes a grep... [23:11:06 CET] <nevcairiel> or my favorite, an IDE =P [23:12:44 CET] <ethe> ah I was looking in pixdesc.h for some reason, thanks. [23:13:30 CET] <wm4> but IDEs are evil and immoral [23:13:48 CET] <wm4> grep and sed are the best refactoring tools [23:14:10 CET] <wm4> and gdb... well let's not go this way [00:00:00 CET] --- Wed Feb 24 2016

1 0

ffmpeg.log.20160223
by burek 24 Feb '16

24 Feb '16

[00:03:51 CET] <kyleogrg> I have a Firewire input on my laptop, and I have an FFmpeg command that will pipe a live display of it into ffplay. This works pretty well (just some latency). Now I added a color key effect so that I could have a live "green screen" effect, and replace the background. But since I added this effect, now it won't open in ffplay -- the encoding time code is always at 00:00:00.00. [00:04:04 CET] <kyleogrg> Here's the command line: http://pastebin.com/hvYYxdVU [00:05:18 CET] <kyleogrg> Any clue as to why this might happen? Is it because I added a JPG as an input, and this has no "duration"? [01:43:31 CET] <Graduating> ffmpeg -ss 00:5:10 -t 1 is it possible to use frame number instead of time -ss offset? [02:06:38 CET] <FlorianBd> Hi there :) [02:07:20 CET] <Wildefyr> what the hell does the -crf option do? [02:07:26 CET] <FlorianBd> by default, saving a movie clip to png files creates a flatten image (no alpha channel. How to force the alpha channel even though it won't be used yet? [02:07:31 CET] <Wildefyr> I can't find it anywhere in the manpage [02:08:28 CET] <FlorianBd> Wildefyr: https://superuser.com/questions/677576/what-is-crf-used-for-in-ffmpeg [02:09:10 CET] <Wildefyr> it's great that there is an answer (google wasn't helping much) but something like that really should be in the manpages [02:09:28 CET] Action: FlorianBd found this in 10s with google :) [02:09:55 CET] <Wildefyr> dunno why it wasn't being forthcoming for me [02:13:31 CET] <FlorianBd> ok I found the answer to my question: -pix_fmt rgba -c:v png [02:14:10 CET] <furq> Wildefyr: it's in the x264 manpage [02:14:18 CET] <Wildefyr> ah [02:14:24 CET] <furq> or ffmpeg -h encoder=libx264 [02:18:53 CET] <Wildefyr> yeah but as a new person to ffmpeg I had no idea that -crf was an option of libx264 specifally [03:56:54 CET] <k_sze[work]> For libx264 and ffv1 level 1, is the GOP size fixed or is it allowed to change throughout the encoding? [03:57:30 CET] <J_Darnley> libx264 has variable [03:57:39 CET] <J_Darnley> ffv1 is intra-only (I think) [04:12:55 CET] <t4nk404> I am trying to use ffprobe to determine if an in progress download/save of an mpg file has completed. Is there any identifying information in the probe data which would indicate this so I can skip currently downloading mpgs in an tool i'm building? [05:17:06 CET] <k_sze[work]> hmm, then I need a way to extract the index of keyframes from my .nut files. [05:18:23 CET] <k_sze[work]> Efficiently, of course. I know I can basically get that information using ffprobe but it seems to require reading the whole file when in fact the index of keyframes should be stored at the end of the .nut file already. [05:54:32 CET] <k_sze[work]> ugh, I just used ffprobe on a libx264/.nut file, somehow the display_picture_number for all frames are 0. [10:04:50 CET] <smolleyes> hello [10:05:59 CET] <smolleyes> no way to do/add a visualisation liek this thru ffmpeg ? https://www.youtube.com/watch?v=JI0Ws6rOJws [10:06:25 CET] <smolleyes> i use the waveform filter for the moement but spectrum might be cool [10:54:22 CET] <smolleyes> no idears ? showcqt filtr seems right without the letters and with the spectrograph... just want the "bars" [11:10:18 CET] <smolleyes> ok found showfreqs in the doc :) [12:23:22 CET] <bencc1> can ffmpeg play rtp from a file? [12:23:26 CET] <bencc1> in what format? [14:16:25 CET] <ented> Hello I have some problems with decoding of video file. I decoded yuv frame and need to dump them. What is the fastest way to do so? I am using C interface. [14:17:56 CET] <ented> That is I need to debug them, does ffmpeg has an api to dump them to say jpegs for debugging purposes. I do not want to establish entire avformat context just for temporary debugging [14:18:17 CET] <ented> ? [14:25:09 CET] <J_Darnley> fwrite [14:26:11 CET] <J_Darnley> jpeg features are only availble through avformat [17:34:43 CET] <iGeni> how do i take screenshots of a .m3u8 file [17:39:41 CET] <DHE> m3u8 still plays like most regular video files or live streams. same way you would anything else [17:39:46 CET] <J_Darnley> Open it in a text editor and press printscreen? [17:59:15 CET] <lroe> My goal here is to take an rtsp stream from an IP camera buffer it locally, and reshare it to whomever wants to consume it via a web-friendly link. I'm working on configuring FFserver as I think this is the right tool, however, I'm a bit hazy on which stream format I should use and how to get ffmpeg to 'feed' ffserver with the rtsp stream from the ip camera. For reference i'm using version 2.6.5 [17:59:43 CET] <lroe> Any pointers would be appreciated [18:39:13 CET] <DHE> lroe: ffserver is actually not well supported. you are encouraged to try... well, anything else really. nginx with the rtmp module, HLS or MPEG-DASH are alternatives [19:32:15 CET] <andrey_utkin> \me wondering why generation of placeholder video from image and silence with filter sources "movie" and "aevalsrc" behaves so weird [19:39:02 CET] <durandal_1707> andrey_utkin: command example? [19:42:40 CET] <andrey_utkin> ffmpeg -f lavfi -graph "movie=filename=test.jpg:loop=1882,settb=100/2997,setpts=N[out0]; aevalsrc=0:sample_rate=48000[out1]" -i nullsrc -map 0 -t 62.81 -vcodec libx264 -acodec aac -strict -2 -y /tmp/placeholder.mp4 [19:42:51 CET] <andrey_utkin> durandal_1707: --^ [19:43:51 CET] <andrey_utkin> maybe i don't get something, but it's quite much harder to obtain than with just "testsrc" [19:45:12 CET] <durandal_1707> andrey_utkin: weird? [19:47:11 CET] <Mavrik> hmm. [19:47:29 CET] <Mavrik> Is there a precedent for FDK-AAC not holding to low bitrate? [19:47:45 CET] <Mavrik> (E.g. encoding what should be 64kbit audio to 90-100)? [19:47:49 CET] <andrey_utkin> durandal_1707: it's weird how much time it takes, even if it works [19:47:59 CET] <andrey_utkin> have you tried it? [19:49:38 CET] <durandal_1707> No, but you can loop images also with loop filter, with correct pts [19:55:07 CET] <andrey_utkin> Cool, but still this gives less than 1 FPS of output on Core i5 [19:55:10 CET] <andrey_utkin> ffmpeg -f lavfi -graph "movie=filename=test.jpg,loop,settb=100/2997,setpts=N[out0]; aevalsrc=0:sample_rate=48000[out1]" -i nullsrc -t 62.81 -vcodec libx264 -acodec aac -strict -2 -y /tmp/placeholder.mp4 [19:55:35 CET] <andrey_utkin> test.jpg isjust default-sized testsrc frame [19:58:01 CET] <durandal_1707> you haven't set any parameters for loop, with no params it does nothing [19:58:33 CET] <durandal_1707> andrey_utkin: ^ [20:01:38 CET] <bencc1> is it possible to play rtp packets from a file? [20:01:43 CET] <bencc1> or only from udp socket? [20:02:37 CET] <andrey_utkin> durandal_1707: wow. As long as I set all the params to "loop", it starts working fast. [20:02:41 CET] <andrey_utkin> ffmpeg -f lavfi -graph "movie=filename=test.jpg,loop=loop=1882:start=0:size=32767,settb=100/2997,setpts=N[out0]; aevalsrc=0:sample_rate=48000[out1]" -i nullsrc -t 62.81 -vcodec libx264 -acodec aac -strict -2 -y /tmp/placeholder.mp4 [20:03:35 CET] <andrey_utkin> I still wonder what is "Set maximal size in number of frames for loop filter" and why max is 32767 [20:04:17 CET] <durandal_1707> duration of loop, for 1 image input its always 1 [20:04:56 CET] <andrey_utkin> ok, but it is not clear at all from the doc [20:05:00 CET] <andrey_utkin> thanks a lot [20:06:07 CET] <andrey_utkin> another question: is there a ./configure option to include default set of filters after --disable-everything? [20:11:14 CET] <durandal_1707> what's default set of filters? [20:11:43 CET] <ethe> durandal_1707: the filters which are enabled with no options I'd presume [20:11:45 CET] <andrey_utkin> the set which you get with ./configure without additional options [20:12:34 CET] <durandal_1707> enable-filters? [20:12:47 CET] <andrey_utkin> will try that [20:16:03 CET] <andrey_utkin> yes, --enable-filters work. Thank you durandal_1707 [20:30:17 CET] <Rajko> the h264_mp4toannexb bsf will 'inject' SPS/PPS NALs if they arent present in the source stream but are in extradata, right ? [20:55:57 CET] <Mavrik> yp [20:57:08 CET] <Rajko> Mavrik, hi ? [21:31:25 CET] <James123> Hi! Does anyone know how to extract keyframes from a video, say from timeA to timeB? [21:34:35 CET] <J_Darnley> use the select filter, maybe twice. [21:47:31 CET] <hunternet93> I can't get ffserver to stream h.264/aac over RTSP. I can start the sender just fine and receive over HTTP, but both ffplay and vlc just sit there when trying to receive over RTSP. Here's my ffserver config: https://gist.github.com/hunternet93/e85c2b805d7e2f73475f [22:23:10 CET] <proxima> i have installed ffmpeg libraries on ubuntu successfully. But unable to compile the example codes. When compiled with gcc it gives following errors http://pastebin.com/7MSQcQsX, and in case g++ gives this error: http://pastebin.com/73XnrjWz. any help or suggestion? what changes or improvement i need to do? [22:24:54 CET] <J_Darnley> perhaps you should actually link to the libraries. [22:26:27 CET] <proxima> the linking problem doesn't show up when compiled with g++ [22:26:55 CET] <J_Darnley> because it errors out long before linking [22:27:40 CET] <J_Darnley> that in fact looks like the preprocessor [22:27:51 CET] <proxima> okay [22:41:17 CET] <proxima> thanks J_Darnley, its working now!! [23:04:47 CET] <salviadud> I want to comment on my failed attempts at deciphering this hidden message [23:05:31 CET] <salviadud> Since I'm at work I get all the electricity I can get, and therefore, all the attempts possible. [23:06:51 CET] <salviadud> My latest attempt was to invoke ffmpeg with -cpuflags 0 [23:06:51 CET] <salviadud> That slowed everything down, and was not cool. [23:06:52 CET] <salviadud> So, what I decided to do, was to compile the x264 library with the SSE flag, but disabling asm. And to recompile ffmpeg without sse [23:08:05 CET] <salviadud> So, the ffmpeg is now invoked without any cpuflag alterations. [23:08:05 CET] <salviadud> I noticed that I already rendered 1 minute and 20 seconds worth of frames at 2448 kb [23:08:05 CET] <salviadud> In 227 mins, which is 3.78 hours [23:08:39 CET] <salviadud> So, I have sped up my rendering time by 4 hours. [23:10:01 CET] <salviadud> The idea is that the video file itself should invoke the optimization when needed and only done by the library. [23:10:02 CET] <salviadud> And that is the key to deciphering this thing. [23:10:02 CET] <salviadud> I feel like Frankenstein, and that thing right there, is my monster. [23:12:32 CET] <J_Darnley> I remember you [23:17:01 CET] <salviadud> hehe [23:17:01 CET] <salviadud> I'm trying to crack a really hard cookie [23:19:44 CET] <salviadud> I also ran mediainfo on the file to make sure I used the same version of the library [23:19:44 CET] <salviadud> All I could get was a date, so I had to aproximate, hopefully that one is it. [23:19:46 CET] <salviadud> Before I tried cpuflags 0, I tried it out by just disabling asm, and keeping sse on both ffmpeg and x264, it took a week to render, but I didn't get the result I was expecting. [23:23:26 CET] <lroe> wow. Resharing an rtsp stream should not be this difficult [23:24:03 CET] <lroe> my goal is to serve an rtsp stream via a website so that the source of the rtsp stream doesn't get overloaded by 100s of people hitting it [23:24:05 CET] <J_Darnley> You mean like copy-pasting the URL? [23:24:19 CET] <furq> lroe: use nginx-rtmp and hls [23:24:41 CET] <lroe> at the moment I have rtsp stream -> nginx rtmp but I can't get the rtmp stream to show up in a browser [23:24:50 CET] <lroe> I can view it fine via vlc or mplayer [23:25:46 CET] <furq> you're using flash, right [23:25:53 CET] <lroe> no flash [23:26:00 CET] <furq> rtmp is flash only [23:26:09 CET] <furq> if you want browser support then use hls and hls.js [23:26:21 CET] <lroe> ok, that's good to know [23:26:21 CET] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#hls [23:26:40 CET] <JEEB> oh, that thing supports hls now as well [23:26:42 CET] <furq> you can serve rtmp and flash from the same location if you still want decent player support [23:26:52 CET] <furq> s/flash/hls/ [23:27:15 CET] <lroe> how do I connect the rtsp stream to it? [23:27:20 CET] <furq> exec_pull [23:27:25 CET] <furq> https://github.com/arut/nginx-rtmp-module/wiki/Directives#exec_pull [23:27:51 CET] <lroe> but instead of rtmp:// I use hls://? [23:28:04 CET] <furq> hls is over http [23:28:07 CET] <JEEB> woah, and that's under a nice license [23:28:18 CET] <furq> it'll generate an m3u8 playlist, you just serve that [23:29:42 CET] <JEEB> I always somehow thought that nginx-rtmp only supported rtmp(e) [23:29:50 CET] <lroe> http://paste.debian.net/402869/ [23:29:56 CET] <lroe> so that's what I'm currently doing [23:29:57 CET] <furq> it's supported hls for ages and it nominally supports dash as well [23:30:00 CET] <JEEB> but I guess if it uses lavf dash/hls become rather simple (not really) [23:30:07 CET] <furq> but i'm told (by someone in here whose name i forget) that the dash muxer is broken [23:30:50 CET] <furq> lroe: that should still work [23:30:59 CET] <furq> the server always takes rtmp as input [23:31:23 CET] <JEEB> if it's lavf it should be possible to fix, since lavf's DASH by itself isn't broken. it uses positive CTS offsets which aren't liked by some livestreaming servers, but should otherwise be OK [23:31:48 CET] <JEEB> because I'm dealing with some of those livestreamers I'm currently working on implementing those darn negative CTS offsets as well [23:32:03 CET] <furq> i don't think it uses lavf at all but i could be wrong [23:32:17 CET] <furq> i'm pretty sure the workaround was to exec ffmpeg for dash muxing [23:32:20 CET] <JEEB> well of course you could implement your own stuff... but you'd have to put a lot more effort into it [23:32:35 CET] <JEEB> and most probably the result wouldn't be as pretty [23:32:55 CET] <lroe> http://paste.debian.net/hidden/263a82ef/ [23:33:00 CET] <JEEB> gesus christ [23:33:02 CET] <lroe> and that is what my site looks like [23:33:04 CET] <JEEB> https://github.com/arut/nginx-rtmp-module/blob/master/dash/ngx_rtmp_mp4.c [23:33:12 CET] <JEEB> someone really went and implemented it [23:33:46 CET] <furq> oh hey, rtmp_control [23:33:47 CET] <furq> that's new [23:34:05 CET] <furq> or maybe not. i guess i just didn't see it [23:35:04 CET] <lroe> this is the whole rtmp {} section: http://paste.debian.net/hidden/8e76749d/ [23:35:21 CET] <furq> lroe: if you have rtmp working then you can just add "hls on;" to that application block [23:35:32 CET] <lroe> right I did [23:35:46 CET] <lroe> but how do I serve the hls? that's the part I don't understand [23:35:59 CET] <furq> it'll generate an m3u8 file in /tmp/hls [23:36:07 CET] <furq> serve that over http and point a <video> tag to it [23:36:36 CET] <furq> https://github.com/dailymotion/hls.js/ [23:36:38 CET] <furq> you'll need that as well [23:36:40 CET] <lroe> should that m3u8 file exist? [23:36:55 CET] <lroe> so if it doesn't exist something is wrong? [23:37:14 CET] <furq> actually i wonder if exec_pull will work with hls because no play request is made [23:37:41 CET] <furq> you might need to have the html player make a request to the rtmp_control handler or something [23:37:58 CET] <furq> but yeah the m3u8 will only exist when a stream is active [23:38:54 CET] <lroe> this hls.js thing is a node.js package? [23:38:56 CET] <Rajko> isnt it better to use video.js with the hls source ? [23:39:01 CET] <Rajko> instead of just raw hls.js [23:39:18 CET] <Rajko> you get an actual player and such [23:39:19 CET] <furq> lroe: https://raw.githubusercontent.com/dailymotion/hls.js/master/dist/hls.min.js [23:39:32 CET] <furq> Rajko: there's an actual player in my browser, why not use that [23:39:35 CET] <Rajko> (its based on hls.js) [23:39:47 CET] <Rajko> furq, it has things like flash fallback for browsers without MSE etc [23:40:11 CET] <Rajko> controls on the video for pause and volume and such [23:40:34 CET] <furq> the builtin player has controls, and it's not particularly difficult to add a fallback manually [23:40:56 CET] <furq> i mean you can use video.js if you want but the builtin player works fine for me [23:41:00 CET] <Rajko> it only has controls if youre playing from a mp4 file, not with MSE [23:41:13 CET] <JEEB> why wouldn't it have controls with MSE? [23:41:15 CET] <furq> it definitely does have controls with hls.js [23:41:20 CET] <Rajko> ok then [23:41:26 CET] <JEEB> I mean, I've used MSE with dash.js [23:41:27 CET] <Rajko> their sample page doesnt [23:41:31 CET] <furq> lroe: you can also use exec_static instead of exec_pull [23:41:41 CET] <JEEB> (which sucks, but I've tried it) [23:42:37 CET] <furq> that'll work regardless of whether there are any clients [23:43:45 CET] <lroe> so with exec_static and hls_path /var/www/hawk/; I should have an m3u8 file in /var/www/hawk? [23:43:58 CET] <furq> i should have thought so [23:44:01 CET] <furq> i've never used exec_* though [23:45:03 CET] <furq> er [23:45:13 CET] <furq> it'll be in /tmp/hls/hawk unless you changed it [23:46:10 CET] <lroe> right, I changed it to /var/www/hawk/ but nothing was created there [23:55:04 CET] <Rajko> can MSE decode intra-refresh streams ? [23:55:26 CET] <JEEB> I think that depends more on the actual decoder than the MSE demuxing [23:55:36 CET] <Rajko> because flash just waits for a intra frame [23:55:38 CET] <JEEB> MSE is just the input/demuxing [23:55:50 CET] <JEEB> it then feeds to the browser's decoder(s) [23:56:03 CET] <JEEB> whatever they do is then up to the gods [23:56:25 CET] <Rajko> ppapi in chrome exposes the decoder, you can feed it annex-b NALs [23:56:50 CET] <Rajko> it uses ffmpeg-sumo.dll or DXVA internally [23:56:56 CET] <JEEB> what I meant is that it depends on the decoder, not MSE [23:57:15 CET] <Rajko> can you answer this [23:57:16 CET] <Rajko> <Rajko> the h264_mp4toannexb bsf will 'inject' SPS/PPS NALs if they arent present in the source stream but are in extradata, right ? [23:57:32 CET] <JEEB> it will convert the AVCc extradata to Annex B [23:57:35 CET] <JEEB> which is in-band [23:58:06 CET] <Rajko> so if the first frame isnt sps/pps but there is some in extradata... the first frame will become sps/pps ? [00:00:00 CET] --- Wed Feb 24 2016

1 0

ffmpeg-devel.log.20160222
by burek 23 Feb '16

23 Feb '16

[00:04:56 CET] <nevcairiel> jkqxz: its really not that hard to track that yourself, you need to setup get_format and get_buffer2 callbacks anyway, so you can just check in those calls if hwaccel is used, return errors otherwise, which will also make the decode call error out [00:10:16 CET] <michaelni> j-b, nevcairiel would the warning i had suggested initially "Hardware accelerated decoding with frame threading does require drivers and hw acceleration APIs to be thread save and or requires complex locking to be done by the user application otherwise It can result in artifacts or crashes. This combination is thus discouraged" solve this ? [00:10:51 CET] <j-b> michaelni: I'll ask courmisch, yes. [00:11:18 CET] <iive> this reminds me I have a draft that i haven't sent... [00:11:27 CET] <nevcairiel> how does more text change anything, still contains the same base elements "can have bugs, discouraged" [00:12:02 CET] <nevcairiel> courmisch isnt a person known for his spirit of cooperation, so [00:12:23 CET] <iive> inho, the problem is how hackish the threading is implemented. [00:14:02 CET] <iive> for example, cloning and merging context is something that should be avoided. [00:14:22 CET] <atomnuker> how come the s302m encoder is still experimental? [00:14:34 CET] <nevcairiel> iive: thats not really related to hwaccel problems [00:14:38 CET] <iive> all things for decoding a frame/slice should be in their own (sub)context [00:14:57 CET] <iive> nevcairiel: it is, because threading is started, before get_format is called [00:15:23 CET] <nevcairiel> strictly speaking hwaccel could turn itself on in the middle of a file when the format changes [00:15:31 CET] <nevcairiel> you would always be in threading mode then [00:15:55 CET] <j-b> nevcairiel: courmisch is _my_ problem... [00:16:23 CET] <iive> nevcairiel: format change is similar to decoder reinit [00:16:52 CET] <iive> it could change everything, including resolution [00:17:06 CET] <nevcairiel> sure, and it does that just fine even in threading mode [00:17:29 CET] <iive> can you turn threading mode on and off, during decoder work? [00:17:35 CET] <nevcairiel> no [00:17:39 CET] <iive> why not? [00:17:44 CET] <wm4> enabling hwaccel midstream seems like an exceptionally obscure case anyway [00:17:56 CET] <nevcairiel> because its not designed to be able to do that [00:18:05 CET] <nevcairiel> it has a fixed size thread pool, and it cant change [00:18:09 CET] <iive> that's because threading is a hack [00:18:32 CET] <nevcairiel> but thats unrelated to every thread having its own codec context [00:18:43 CET] <nevcairiel> you are smushing all things together without logic =p [00:19:09 CET] <iive> you didn't let me finish... [00:19:19 CET] <iive> whatever... [00:19:24 CET] <nevcairiel> this method allows intra only codecs to multithread with extremely little effort [00:19:47 CET] <iive> why is the threaded pool fixed size? [00:19:58 CET] <nevcairiel> because its easier this way [00:20:06 CET] <nevcairiel> also because of our decode API [00:20:16 CET] <nevcairiel> its not very flexible about such things [00:21:36 CET] <nevcairiel> creating an over-engineered perfect solution isnt hard in theory, in practice you have to rewrite everything [00:21:56 CET] <iive> bingo [00:22:06 CET] <nevcairiel> well, feel free to start [00:22:11 CET] <nevcairiel> we'll see you in a decade or two [00:22:11 CET] <nevcairiel> :D [00:22:20 CET] <iive> do you know of a project that wants to rewrite everything ffmpeg ? [00:23:27 CET] <nevcairiel> rewriting everything is not a good goal for anyone, you have to do incremental improvements otherwise nothing is going to get finished ever [00:24:05 CET] <nevcairiel> people have been planning to revise the decode API for ages now, once such an API may exist one could start thinking about how to use it to make internals more elegant [00:24:26 CET] <wm4> lol I'll try [00:25:18 CET] <iive> the decode API is fine.. it can handle much more abuse. [00:25:43 CET] <nevcairiel> no, its far too rigid [00:26:04 CET] <nevcairiel> for example you couldnt lower the thread count because there is no way to output the excess frame [00:26:11 CET] <wm4> lacks the ability to output >1 frames per packet [00:26:20 CET] <iive> you don't have to output them [00:26:28 CET] <iive> just don't start new ones... [00:26:30 CET] <nevcairiel> buffering them for ever is hardly ideal [00:27:21 CET] <iive> wm4: it allows calling with NULL input? [00:27:30 CET] <nevcairiel> not in the middle of the stream [00:27:33 CET] <wm4> that enters flush mode [00:27:33 CET] <nevcairiel> NULL is only for EOF [00:27:37 CET] <iive> why not... [00:29:22 CET] <wm4> hm I don't even know how that'd interact with normal decoding or our threading, but those hw wrappers aren't going to like it [00:30:15 CET] <nevcairiel> i bet there is a bunch of things that really wont like it, not to mention that it sounds like weird-ass API to call it with NULL all the time [00:31:10 CET] <wm4> it sounds like even if it works, it'd make threading less efficient [00:31:16 CET] <iive> well, i did mention that it is abuse. [00:31:57 CET] <michaelni> the previous call could return a special return code to indicate that there are more frames ready or that could be retrieved without additional input [00:32:37 CET] <wm4> michaelni: yes [00:32:48 CET] <nevcairiel> thats also terrible api design =p [00:33:10 CET] <wm4> just introducing decoupled in/output would be ideal [00:33:15 CET] <nevcairiel> indeed [00:33:38 CET] <iive> that also have problems on its own. [00:49:30 CET] <cone-318> ffmpeg 03Mats Peterson 07master:cf85a20d920f: lavc/rawdec: Align AV_PIX_FMT_RGB24 correctly [00:49:31 CET] <cone-318> ffmpeg 03Josh de Kock 07master:67f8a0be5455: configure&avdevice/jack: Fixed issue #43 JACK indev support on OSX [00:50:17 CET] <ethe> thanks for your help michaelni :) [00:50:25 CET] <michaelni> np [01:41:39 CET] <michaelni> we need backup mentors for GSoC, I mean if you add yourself in a week thats after we would have been rejected for lack of backup mentors [01:42:07 CET] <michaelni> 6 out of 10 projects have no backup mentor listed [01:46:45 CET] <michaelni> they complained about backups in the past IIRC and we had much more backup mentors back then [01:48:00 CET] <michaelni> is it really needed for me to ask people privately each year one by one ? [01:50:49 CET] <durandal_1707> put me as backup for swscale and I dunno what else [01:52:07 CET] <durandal_1707> is truehd project really still active? [01:52:46 CET] <michaelni> added you for swscale [01:53:13 CET] <durandal_1707> michaelni: is it me or xyz output looks buggy? [01:53:25 CET] <jamrial> durandal_1707: the encoder? there's supposedly a wip from some years ago, but nobody touched it since then. It's been a gsoc project but no student every chose it [01:53:51 CET] <michaelni> truehd lacks a backup mentor [01:54:07 CET] <michaelni> how can i test reproduce xyz bug ? [01:54:53 CET] <durandal_1707> from rgba to xyz and back it should be exact same output [01:56:06 CET] <durandal_1707> well reasonable same, not bitexact [01:57:20 CET] <michaelni> philipl, are you available as mentor or backup mentor ? we still need 5 backup mentors: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [01:59:12 CET] <durandal_1707> michaelni: add me for mxf too [02:00:11 CET] <jya> nevcairiel: looking against at this yadif filter, so I send a NULL AVFrame to drain the graph, but is there a way to flush it so it can be fed more AVFrame or do I must recreate one ? [02:01:22 CET] <jya> I would like to avoid reparsing the string with avfilter_graph_parse2 if it can be avoided [02:01:48 CET] <durandal_1707> its fast [02:03:18 CET] <durandal_1707> michaelni: so how going from rgba to xyz to rgba back looks like? [02:04:34 CET] <durandal_1707> ubitux/michaelni: #ffmpeg stills list 2.8 in wall msg [02:04:40 CET] <jya> durandal_1707: if it's in relation to my question, it does look efficient. But seeing it's just to use a replacement for avpicture_deinterlace and i see it in our code being used in a loop, i don't want to take on the risk to have regression speed-wise [02:05:45 CET] <michaelni> durandal_1707, lena.png -vf format=rgba,format=xyz12le,format=rgba looks reasonable to the eye [02:05:59 CET] <durandal_1707> jya: how/when you flush? [02:07:06 CET] <jya> durandal_1707: our stuff expect one frame (interlaced) in and one out immediately. as yadif won't output a frame immediately, nevcairiel suggested I simply pass a NULL frame to drain the filter. [02:07:21 CET] <jya> but then i just realised I can't reuse the filter after than [02:07:32 CET] <michaelni> fixed #ffmpeg topic [02:07:52 CET] <jya> i was hoping there was a way to flush the filter/graph and be able to restart [02:09:07 CET] <durandal_1707> jya: it does output one frame immediately [02:09:28 CET] <durandal_1707> do you mean field mode? [02:09:29 CET] <jya> didn't see that, on the first frame I got EAGAIN [02:09:50 CET] <jya> that was the same regardless of the yadif mode (tried all of them 0,1,2,3,4) [02:10:03 CET] <durandal_1707> that's for first and second frame only IIRC [02:10:35 CET] <jya> sure, but i want a frame to come out immediately , just really to replace avpicture_deinterlace [02:10:53 CET] <jya> as there are cases where we only create a filter for a single frame [02:11:33 CET] <durandal_1707> not possible with yadif as it needs three frames [02:11:55 CET] <jya> i just found out that it was used elsewhere in our code, and this time in a loop (still expecting a frame to always come out from first input). but then I get -22 on the 2nd av_buffersrc_add_frame [02:12:47 CET] <jya> durandal_1707: well, feeding it as 2nd frame NULL, I get a picture out, and it certainly looks deinterlaced to me [02:12:51 CET] <durandal_1707> it is possible with nnedi, it only needs 1 frame, but because of pts in ask for more [02:13:24 CET] <atomnuker> michaelni: added myself as a TrueHD encoder backup mentor [02:14:13 CET] <atomnuker> could also serve as main mentor if the ramiro doesn't show up [02:14:31 CET] <jya> durandal_1707: sorry, I don't get what you mean with "pts in ask for more" [02:15:08 CET] <durandal_1707> jya: presentation timestamps for frame [02:15:33 CET] <jya> i know what pts means, what does "ask for more" means [02:16:22 CET] <michaelni> atomnuker, thanks alot! [02:16:23 CET] <jya> oh, maybe you meant "it asks for me" [02:16:24 CET] <durandal_1707> needs next frame to interpolate pts for second field frame [02:17:55 CET] <jya> ok, so if feeding EOS to the filter isn't the right approach, what filter should I use to replace and simulate avpicture_deinterlace . The doc stated to use yadif instead. I need something behaving in the exact same fashion, one frame in, one frame out, and no latency [02:19:08 CET] <durandal_1707> michaelni: in chromascope filter on ml lavfi converts yuv to xyz and it looks differen from yuv to rgb to xyz [02:20:05 CET] <durandal_1707> jya: what that code did? [02:20:35 CET] <durandal_1707> just did dumb interpolation? [02:20:41 CET] <jya> yep [02:21:03 CET] <jya> the aim is to present a thumb image , a screen grab [02:22:50 CET] <michaelni> durandal_1707, do you have a testcase / commandline that shows the bad/difference/buggy case ? [02:23:59 CET] <durandal_1707> michaelni: just try yuv input with and without format filter to rgba before chromascope [02:24:30 CET] Action: jya thinks that just getting the old code of avpicture_deinterlace is going to be the easiest rather than messing with filters [02:24:40 CET] <durandal_1707> without case will show very different output [02:29:34 CET] <jya> sigh, and where am I going to find weights for that nnedi filter [02:29:53 CET] <durandal_1707> its slow very [02:30:11 CET] <durandal_1707> you need dumb bober [02:31:48 CET] <jya> durandal_1707: so back to my question, what filter should be used (and is there one) to replace avpicture_deinterlacer ? [02:32:37 CET] <durandal_1707> not currently, try field filter for fun [02:33:37 CET] <jya> durandal_1707: and there's no equivalent to avcodec_flush_buffers for graph/filter ? [02:35:57 CET] <durandal_1707> jya: no, they are stream based, and some filters need multiple frames to output single frame, but perhaps one could write deinterlacer that just do cube? interpolation [02:36:52 CET] <jya> that's unfortunate that you need to recreate the entire filters/graph just to reuse one once it hits EOF [02:36:54 CET] <durandal_1707> michaelni: tried to reproduce xyz issue? [02:38:35 CET] <durandal_1707> well nobody know that you need such latency [02:41:20 CET] <michaelni> durandal_1707, i see the difference [02:41:46 CET] <jya> durandal_1707: is issue is more realted to the removal of avpicture_deinterlace in 3.0, and with nothing available to provide exact same functionality. sure it had been marked as deprecated a long time ago, but it had its use [02:45:40 CET] <durandal_1707> well I may write replacement [02:46:04 CET] <jya> that would be nice thank you. [02:50:58 CET] <durandal_1707> michaelni: the yuv to xyz doesnt make sense so I would just change negotiation [02:51:58 CET] <jamrial> atomnuker, kierank: "./ffmpeg -f rawvideo -s 352x288 -pix_fmt yuv420p -i tests/data/vsynth1.yuv -c:v vc2 -s 1920x1080 -r 24000/1001 -pix_fmt yuv422p10 vc2.mov" the output can't be decoded [02:53:47 CET] <michaelni> durandal_1707, does your code handle gamma in rgb vs xyz correctly ? it looks different from what sws does [02:54:22 CET] <atomnuker> jamrial: does it work with a framerate of exactly 24 and -strict -1? [02:55:10 CET] <durandal_1707> michaelni: you mean for xyz input? [02:55:53 CET] <durandal_1707> afaik its not needed [02:57:28 CET] <jamrial> atomnuker: yes [02:57:32 CET] <durandal_1707> its multiplication to all components [02:57:33 CET] <michaelni> i mean sws does rgb->gamma->matrix->gamma->xyz but your code seems to do just the linear matrix [02:58:40 CET] <durandal_1707> well the yuv to xyz show out of tongue values [02:59:19 CET] <durandal_1707> the gamma correction if needed may come later [03:00:37 CET] <Compn> does anyone have a complete list of pixel formats / colorspaces ? idont mean in ffmpeg, but all software, combined. [03:00:45 CET] <Compn> just wondering how many there are. [03:00:47 CET] <durandal_1707> the rgba/yuv values should be inside triangle [03:03:16 CET] <durandal_1707> Compn: colorspace or color primaries/system [03:05:34 CET] <Compn> durandal_1707 : it just seems weird (to me) that there is no definitive list. maybe theres something on wikipedia... [03:06:43 CET] <durandal_1707> everyone invents own [03:07:20 CET] <Compn> durandal_1707 : one of my hobbies is collecting this type of information. its why i try to maintain the ultimate fourcc list :) [03:08:39 CET] <durandal_1707> there are magicyuv fourcc, you know? [03:09:04 CET] <Compn> you are talking about packed yuv format fourccs ? like nv12, yuy2 ? [03:09:28 CET] <durandal_1707> or planar [03:10:30 CET] <Compn> yes i know of them. i've been trying to document all fourccs... http://wiki.multimedia.cx/index.php?title=Category_talk:Video_FourCCs [03:12:15 CET] <Compn> and trying to get samples, binary decoders, maybe even some RE work done on the simpler codecs- or encourage RE simple codecs as qualification tasks [03:14:08 CET] <durandal_1707> so you installed magicyuv codec? [03:15:25 CET] <Compn> i dont think so [03:15:36 CET] <michaelni> durandal_1707, the triangle assume linear xyz, AV_PIX_FMT_XYZ12 is not linear [03:18:09 CET] <durandal_1707> michaelni: the xyz mxf sample displayed fine [03:21:48 CET] <michaelni> durandal_1707, your code divides by 0 [03:21:58 CET] <michaelni> Assertion sum>0 failed at libavfilter/vf_chromascope.c:988 [03:22:59 CET] <durandal_1707> ahh... [03:23:27 CET] <michaelni> ill try to figure out what the pixfmt negotiation is doing wrong [03:50:31 CET] <cone-920> ffmpeg 03Michael Niedermayer 07master:1ec7a7038060: avutil/pixdesc: Make get_color_type() aware of CIE XYZ formats [04:40:26 CET] <Compn> https://github.com/edanvoye/zoe-lossless-codec [04:41:09 CET] <jamrial> for avi [04:50:59 CET] <philipl> michaelni: Sorry, not this year. I'm going to have a busy summer with other things going on. [05:04:02 CET] <michaelni> philipl, ok, thanks anyway [10:10:44 CET] <ubitux> "MMX implied by specified flags" [10:10:54 CET] <ubitux> i don't think we want this when running aarch64 code :p [10:21:04 CET] <JEEB> :D [10:55:55 CET] <ubitux> - git describe [10:55:57 CET] <ubitux> n2.9-dev-3743-g1ec7a70 [10:56:09 CET] <ubitux> should be 3.0 [10:57:26 CET] <nevcairiel> the dev tags are made after the previous release, after 2.8 it wasnt really known that it would be 3.0 instead [10:57:43 CET] <nevcairiel> git master should be called 3.1-dev now [10:59:50 CET] <ubitux> is it something wrong on my side? [11:00:26 CET] <ubitux> oh, i didn't fetch the tags for some reason [11:00:28 CET] <ubitux> ok [11:09:06 CET] <ubitux> libavdevice/libavdevice.so: undefined reference to `dispatch_release' [11:09:08 CET] <ubitux> libavdevice/libavdevice.so: undefined reference to `dispatch_walltime' [11:09:10 CET] <ubitux> libavdevice/libavdevice.so: undefined reference to `dispatch_semaphore_signal' [11:09:12 CET] <ubitux> fuck. [11:16:48 CET] <wm4> sounds like the configure check was actually wrong [11:23:03 CET] <ubitux> yay, just got the hikey board [11:23:42 CET] <ubitux> board ~100¬, +50¬ taxes [11:25:12 CET] <wbs> ubitux: there's the new pine a64 that you can get for $15 as well :P [11:25:35 CET] <wbs> (but I also got a dragonboard for slightly less than what you seem to have paid for the hikey one) [11:26:48 CET] <fritsch> allwinner ... [11:27:02 CET] <wbs> yeah, that's of course an issue [11:27:13 CET] <ubitux> wbs: so it's out? [11:27:19 CET] <ubitux> i thought it was planed for march or sth [11:27:38 CET] <wbs> but if you just want it as a cheap aarch64 cpu and don't care about the rest it might not be quite as bad. modulo potential gpl infringments and such ofc :P [11:27:55 CET] <wbs> ubitux: dunno, I just saw that it's possible to order it and earlier orders should ship in march [11:49:33 CET] <wm4> so I tried to fix autodetection for this videotoolbox patch [11:49:44 CET] <wm4> but... it's just too much of a fucked up mess [11:49:49 CET] <wm4> our configure, I mean [11:51:34 CET] <durandal_170> anyone have some xyz samples? [13:49:46 CET] <ubitux> in ff8c2c410, why /.5 instead of *2? [13:50:50 CET] <nevcairiel> probably to match the documentation [13:58:50 CET] Action: JEEB is trying to wrap his head around what seems to be the current Industry Standard with negative CTS offsets in fragmented ISOBMFF [14:27:03 CET] <JEEB> ok, has anyone else wanted to stab MS for their special snowflake MSDN-defined boxes? [14:27:16 CET] <JEEB> like, using the wording "absolute timestamp" [14:27:29 CET] <JEEB> instead of composition or decoding time stamp [14:29:32 CET] <J_Darnley> There's so much I would stab MS for but that isn't one reason I have personally encountered yet. [14:31:51 CET] <JEEB> I'm currently trying to understand the effects of using negative CTS offsets with that piece of shit's tfxd (https://msdn.microsoft.com/en-us/library/ff469354.aspx) [15:18:10 CET] <ubitux> stupid q: i420==yuv420p right? what do we do with yv12? "yvu420"? [15:18:25 CET] <wm4> yeah [15:18:41 CET] <wm4> for yv12 you simply swap the planes and then treat it as yuv420p [15:19:09 CET] <ubitux> sws seems to use the yv12 naming for both i420 and yv12 [15:19:12 CET] <wm4> so, what's a good way to circumvent get_buffer2, but still get a correctly setup AVFrame? use ff_decode_frame_props? [15:19:20 CET] <ubitux> which is actually i420 internally [15:19:21 CET] <wm4> ubitux: yes [15:19:28 CET] <wm4> not like it matters [15:19:37 CET] <ubitux> right, ok [15:19:55 CET] <andrey_utkin> how to trigger h264_parse as breakpoint? I run "-c copy" and "-c rawvideo" commands on MP4/H.264 file, using --enable-debug --disable-stripping statically-linked ffmpeg binary, but my breakpoint is never triggered. Any clue? [15:21:26 CET] <ubitux> ffmpeg -i <in> -f null - [15:21:29 CET] <andrey_utkin> or, parser is not used when h264 stream is decoded? [15:21:50 CET] <ubitux> copy doesn't decode, rawvideo should though [15:25:16 CET] <andrey_utkin> actually, what I am investigating now, is whether I can to distinguish H.264 I-frames from IDR-frames at application level. I'd need to. Maybe by reaching parser context through API during decoding or demuxing (whatever is possible), or by patching ffmpeg [15:26:11 CET] <wm4> I'm still wondering what the avpacket keyframe flag actually means [15:26:51 CET] <andrey_utkin> h264_parse is triggered on .ts file, on .mp4 it is still not [15:29:28 CET] <jkqxz> Doesn't it just mean "the muxer should mark this point as seekable to"? (With no comment on what that actually means for the underlying format.) [15:29:35 CET] <nevcairiel> Parser only runs when needed, you can always run it manually if you want it for extracting information [15:32:46 CET] <wm4> jkqxz: that's usually the closest meaning from what I can see [15:40:23 CET] <andrey_utkin> in context of our previous discussion on #ffmpeg (that only IDRs are valid seek points for H.264), is it so in case of MP4(mov demuxer)+H.264 and MPEGTS(demuxer)+H.264? I would be very grateful for any help in figuring this out from code or knowledge, and not by accident some time later. [15:41:45 CET] <JEEB> ok, do I understand correctly that the stuff in track->cluster[i].cts is not really the CTS but rather the CTS offset [15:41:50 CET] <JEEB> because that's how it seems [16:05:19 CET] <JEEB> also is it just me or is mov_read_trun kind of hard to read if you want to know how it handles the CTS offsets? [16:05:25 CET] <JEEB> (in lavf/mov.c) [16:06:37 CET] <JEEB> all it seems to do is dts -= sc->ctts_data[sc->ctts_count].duration; [16:06:50 CET] <JEEB> under if (flags & MOV_TRUN_SAMPLE_CTS) [16:35:54 CET] <andrey_utkin> [bounty] could somebody please make up a patch which logs a warning when demuxer or decoder encounters H.264 non-key frame which references any frame prior to latest I-frame? I am happy to pay. [16:36:14 CET] <andrey_utkin> this patch is not necessarily something subject to upstreaming [16:47:21 CET] <BBB_> but isnt that allowed? [16:47:30 CET] <BBB_> @andrey_utkin [16:49:00 CET] <andrey_utkin> what is(n't) allowed? publishing/upstreaming of patch? everything is allowed in this regard [16:53:33 CET] <nevcairiel> such frames are allowed, is what BBB_ means [16:55:09 CET] <BBB> if you dont want such references, simply force IDR instead of I frames (iirc) in the encoder [16:55:27 CET] <andrey_utkin> BBB: the files which are processed are encoded elsewhere [16:59:09 CET] <andrey_utkin> Just to recap: as it was discussed a few hours ago on #ffmpeg, only IDR frames are considered safe seek points by design of H.264. AFAIU H.264 has two kinds of pictures which are mapped to AV_PICTURE_TYPE_I: NAL_IDR_SLICE and some other NAL_SLICE. And referencing is arbitrary and GOP concept is not strict in H.264, as jkqxz has explained. I my usecase, I need to be sure about slicing the file and not breaking any references. So some in [17:00:32 CET] <andrey_utkin> and in case of cross-GOP weird refs it could be investigated quickly and resolved that files should be reencoded, or my custom application must be reworked to support that case. [17:14:09 CET] <BBB> ah I see, you want to slice files [17:15:09 CET] <BBB> I think in practice you can just parse slice headers and print poc. if after a keyframe, p frames follow with p_poc < i_poc, youve got a stream with issues [17:15:11 CET] <BBB> (most likely) [17:15:25 CET] <BBB> this isnt scientiifcally definitive, but it is practically always correct I think [17:23:37 CET] <jamrial> patch v17 [17:26:13 CET] <andrey_utkin> BBB: how exactly your propose to parse slice hearders? to which degree I can leverage existing ffmpeg (parser) code? What about B-frames (you have just explained the case of P-frames)? [17:26:31 CET] <BBB> b frames are p frames [17:26:41 CET] <BBB> for this purpose [17:27:41 CET] <BBB> to whihc degree can you leverage existing code & hmmm & itd take some fiddling [17:27:53 CET] <BBB> you cannot access it simply via api right now [17:28:33 CET] <andrey_utkin> thank you for proposing a solution, but still I'd be happy (to fund it) if somebody proficient would implement that. [17:29:47 CET] <andrey_utkin> I think I'll post such request on ffmpeg-devel... [17:30:59 CET] <JEEB> cool, I think I just implemented negative CTS offsets in trun [17:31:14 CET] <JEEB> now to see what else I have to poke [17:31:53 CET] <cone-564> ffmpeg 03Xiaolei Yu 07master:5a9158947609: swscale/arm: re-enable neon rgbx to nv12 routines [17:55:16 CET] <cone-564> ffmpeg 03James Almer 07master:26034929d574: checkasm: bench each vf_blend mode once [17:57:25 CET] <ubitux> tracing the precision of a value in sws... [17:58:10 CET] <ubitux> so you start with an unknown precision which you up by 13bits, which is then set to the asm which will reduced it by 8 bits, then re-up it immediately by 3 bits [17:58:27 CET] <ubitux> s/set/sent/ [17:59:19 CET] <ubitux> then you have an identical value, which is also of unknown precision, which is in one code path up by 9-bit, but in the other by 3 bits, and in that second case it's sent to the asm where it's changed again [17:59:32 CET] <ubitux> aaaaaah [17:59:34 CET] <ubitux> :(( [18:00:11 CET] <nevcairiel> dont let sws mess with your mind [18:04:17 CET] <cone-564> ffmpeg 03Paul B Mahol 07master:5d93437e4612: avfilter/vf_waveform: add 12bit depth support [18:25:25 CET] <cone-564> ffmpeg 03Rostislav Pehlivanov 07master:1387f3a0510c: vc2enc: set quantization ceiling to 50 [18:34:02 CET] <BBB> ubitux: I worked on sws at some point in my life, y'know [18:34:09 CET] <BBB> ubitux: I stopped for a reason, it was eating me [18:34:15 CET] <JEEB> https://kuroko.fushizen.eu/patches/0001-movenc-support-negative-CTS-offsets… enjoy the evil [18:35:32 CET] <JEEB> this *seems* to create correct stuff in trun [18:36:36 CET] <J_Darnley> Does that log want to be ERROR? [18:36:41 CET] <JEEB> no [18:36:46 CET] <JEEB> I just forgot to change it to DEBUG [18:37:53 CET] <J_Darnley> Will the user know what "trun" is when they want to be using this option? [18:38:02 CET] <JEEB> they should [18:38:19 CET] <JEEB> also this is only trun changed, it possibly would have to be poked somewhere else as well [18:38:27 CET] <JEEB> but that's something for tomorrow [18:38:41 CET] <JEEB> for fragmented stuff trun is probably the most important part [18:39:10 CET] <J_Darnley> In that case I don't have any other comments [18:39:21 CET] <J_Darnley> (mostly because I don't know what any of this is) [18:39:34 CET] <JEEB> is the usage of uint for both unsigned and signed with the bit mask sane or insane? [18:39:44 CET] <JEEB> and changing the print like that [18:40:01 CET] <JEEB> I blame the spec for doing the flip of unsigned/signed [18:40:13 CET] <J_Darnley> :) [18:40:14 CET] <JEEB> if version == 0 => unsigned, else => signed [18:40:49 CET] <JEEB> also have an actual example of the difference in output [18:40:50 CET] <JEEB> http://up-cat.net/p/c8f918fc [18:41:05 CET] <JEEB> that's an AVC stream at 25fps, timescale 10000000, single picture duration 400000 [18:41:52 CET] <JEEB> you get a zero CTS offset by being able to use negative values [18:41:58 CET] <JEEB> I mean in the first sample [18:49:28 CET] <cone-564> ffmpeg 03Muhammad Faiz 07master:bfc61b0fcc77: avfilter: add firequalizer filter [19:07:59 CET] <cone-564> ffmpeg 03Muhammad Faiz 07master:76377d66b7b8: avfilter/avf_showcqt: remove unneeded headers [19:23:40 CET] <ethe> what's the standing point on deprecated APIs (say for example, Carbon on OSX), is it acceptable to create a ticket which asks for the API to be updated? [19:23:58 CET] <Timothy_Gu> ethe: which part of ffmpeg? [19:24:03 CET] <ethe> ffplay [19:25:00 CET] <nevcairiel> carbon might be deprecated, but if the only alternative is ObjC, i wouldnt hold my breath for improvement =p [19:26:47 CET] <ethe> Is that because it wont be allowed, or no one will do it? [19:27:16 CET] <Timothy_Gu> the latter I believe [19:27:49 CET] <Timothy_Gu> also will Apple ever remove Carbon? [19:28:01 CET] <nevcairiel> apple likes screwing over their users, so probably [19:28:05 CET] <ethe> eventually [19:28:07 CET] <ethe> yeah lol [19:28:26 CET] <ethe> I'll create a ticket then, as it doesnt seem like there'll be any harm in doing so [19:28:28 CET] <nevcairiel> it will be announced as a big feature somehow improving the overall mac experience [19:28:51 CET] <Timothy_Gu> where in ffplay is carbon used? [19:28:51 CET] <nevcairiel> Finally the evil Carbon is gone! [19:30:43 CET] <ethe> the word "carbon" cant be found in the project according to sublime text, but OSX seems to think it uses carbon [19:30:52 CET] <ethe> I'll look into it before creating a ticket [19:31:17 CET] <nevcairiel> might be through SDL [19:31:24 CET] <nevcairiel> which probably uses carbon to create the window [19:32:24 CET] <nevcairiel> but thats out of our control [19:33:27 CET] <ethe> that sounds about right https://github.com/spurious/SDL-mirror/search?p=10&q=carbon&utf8=%E2%9C%93 [19:33:47 CET] <Timothy_Gu> http://forums.libsdl.org/viewtopic.php?t=8325&sid=d2526f6ec18afb7c44681bfc6… [19:34:24 CET] <Timothy_Gu> plus ffplay is still using SDL 1.x [19:35:04 CET] <nevcairiel> i thought someone talked about updating that [19:41:30 CET] <ethe> I recently worked a bit with SDL(2), I could take a look but maybe see what other people think first [20:36:13 CET] <ubitux> do we have any yasm mmx functions with many arguments? [20:41:40 CET] <ubitux> like, i'd like to do a mmx function which take like 13 args if possible [20:42:05 CET] <ubitux> and if i'm not asking for troubles wrt calling convention [20:42:20 CET] <nevcairiel> not sure how thats necessarily related to mmx, but i'm sure we have some yasm function that takes this many [20:42:25 CET] <nevcairiel> the arguments will just be stored on the stack [20:42:37 CET] <ubitux> do you have one in mind? [20:42:38 CET] <J_Darnley> It would work if you ask for them to be loaded. [20:42:44 CET] <J_Darnley> *don't ask [20:43:51 CET] <nevcairiel> on 64-bit you could even load them all, couldnt you [20:44:10 CET] <ubitux> i need to support 32 [20:44:11 CET] <J_Darnley> oh yes [20:44:23 CET] <J_Darnley> 32 now? [20:44:28 CET] <J_Darnley> bit [20:44:29 CET] <ubitux> 32-bit sorr [20:45:16 CET] <J_Darnley> yeah, reading the source shows me that 15 arguments are currently supported [20:45:46 CET] <J_Darnley> I don't know where we might use that many though [20:45:51 CET] <ubitux> great [20:45:59 CET] <ubitux> swscale [20:47:28 CET] <nevcairiel> such functions are relatively rare, but yeah it should be possible [20:47:48 CET] <ubitux> so any example in mind? [20:48:44 CET] <J_Darnley> none spring to mind [20:49:03 CET] <J_Darnley> grep shows some hevc deblock functions too [20:53:01 CET] <nevcairiel> vf_maskedmerge has 8 params, 3 of which it loads from the stack on 32-bit, you should be able to expand from that to 13 [20:53:16 CET] <nevcairiel> same pattern applies [20:53:28 CET] <ubitux> - git grep 'cglobal[^,]*,[^0-9]*9,' [20:53:30 CET] <ubitux> libavcodec/x86/h264_deblock.asm:cglobal h264_loop_filter_strength, 9, 9, 0, bs, nnz, ref, mv, bidir, edges, \ [20:53:36 CET] <ubitux> 9 args mmh, but probably x86? [20:53:59 CET] <ubitux> git grep 'cglobal[^,]*,[^0-9]*1[0-9],' nothing >= 10 :( [20:54:39 CET] <durandal_170> stereo3d asm uses many regs, and stack [20:55:06 CET] <ubitux> heh, why h264_loop_filter_strength declares 9 args/local but has 10? [20:55:30 CET] <nevcairiel> the 10th is always used from the stack, so it doesnt get any reg [20:55:43 CET] <nevcairiel> the first number isnt actual number of parameters, its number of parameters to load into regs [20:56:05 CET] <ubitux> how many reg i'm allowed max? [20:56:10 CET] <nevcairiel> 7 on 32-bit [20:56:16 CET] <nevcairiel> and 8 SIMDs [20:56:26 CET] <ubitux> and 64? [20:57:12 CET] <ubitux> that h264_loop_filter_strength seems to be built on 32 as well [20:57:19 CET] <nevcairiel> 15 and 16 [20:57:20 CET] <ubitux> i suppose the >7 are ignored [20:57:34 CET] <nevcairiel> it automatically cuts doen GPRs if you request too many [20:57:44 CET] <ubitux> ok perfect [20:57:45 CET] <nevcairiel> not sure why exactly, but probably to make code easier to reuse [20:57:55 CET] <ubitux> thanks a lot [20:58:28 CET] <kurosu_> like for xmm regs [20:59:07 CET] <kurosu_> not sure what's the maximum for x86_64, probably 15 because of RIP/GOT [20:59:42 CET] <nevcairiel> note that if you need extra stack space, you will lose another registers [20:59:50 CET] <nevcairiel> so only 6 left [21:00:09 CET] <ubitux> heh [21:00:31 CET] <ubitux> i forgot how x86 simd was actually pretty annoying compared to arm [21:00:44 CET] <nevcairiel> x86 is also ancient [21:01:50 CET] <kurosu_> libswresample/x86/resample.asm:275:cglobal resample_linear_%1, 0, 15, 5, ctx, phase_mask, src, phase_shift, index, frac, <- 15 does seem the maximum [21:02:16 CET] Action: ubitux confused at first arg being 0 [21:02:23 CET] <kurosu_> none is loaded [21:02:27 CET] <kurosu_> only manual loads [21:02:42 CET] <ubitux> i see, ok [21:02:54 CET] <kurosu_> oh, in that function - I'm just guessing, not that I verified that [21:09:57 CET] <kurosu_> the most troublesome abi stuff for asm is float (eg aac/dts iirc), as even the x64 abis are rather different [21:10:36 CET] <nevcairiel> if you dont do too much magic, the abstraction should hide everything else from you [21:10:38 CET] <kurosu_> I bet there's weirder, but x86_32 stuff for dts required some time to get right [21:11:01 CET] <nevcairiel> speaking of dts, want to expand the synth filter for 64 wide and fixed point? :) [21:11:58 CET] <kurosu_> is the former that easily found ? when I looked at the previous decoder, I don't think there was even a fate test [21:12:19 CET] <nevcairiel> we replaced the entire dts decoder, all 4 modes should be tested [21:12:34 CET] <kurosu_> fixed point will be a mess with those 32x32->64 things - at least the loops are wider and more likely to benefit from sse4 than mlp [21:12:57 CET] <nevcairiel> synth64 should be rather trivial, the differences in the C code look minimal [21:13:10 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/synth_filter.c;h=… [21:13:19 CET] <jamrial_> synth filter fixed mode is necessary to get dts-ma decoding at a decent speed, but yeah, 32x32 -> 64 = annoying [21:15:03 CET] <jamrial_> nevcairiel: synth64 float is not nearly as useful as synth fixed [21:15:10 CET] <jamrial_> because it's used by that x96 extension only afaik [21:15:19 CET] <kurosu_> my point [21:15:23 CET] <kurosu_> I usually just use the core part anyway [21:15:29 CET] <nevcairiel> jamrial_: but its infinitely easier to just adapt from the existing synth [21:15:35 CET] <jamrial_> true [21:16:00 CET] <ubitux> michaelni: strides can be negative in sws? [21:16:01 CET] <jamrial_> btw, i wrote lfe1 simd today. will be sending it later [21:16:30 CET] <michaelni> ubitux, yes [21:16:38 CET] <ubitux> michaelni: how can i trigger this scenario? [21:16:39 CET] <jamrial_> the fate suit doesn't test it, but that one weird dts-in-wav file that blocked the decoder for a bit uses it [21:17:26 CET] <michaelni> ubitux, hmm, iam not sure [21:17:47 CET] <michaelni> maybe writing a testcase or filter that triggers that could make sense [21:18:24 CET] <ubitux> mh. ok [21:29:07 CET] <ubitux> michaelni: another question, http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libswscale/x86/yuv2rgb_templ… is this check still necessary? [21:29:24 CET] <ubitux> assuming the case with depth=4 for a start [21:29:31 CET] <ubitux> (typically, rgba) [21:29:45 CET] <ubitux> i feel like the stride will always be enough [21:30:25 CET] <ubitux> i couldn't trigger this case [21:32:00 CET] <ubitux> the imgutils seems to make sure the linesize is actually large enough [21:33:01 CET] <wm4> lol assuming everything just uses ffmpeg stuff [21:33:12 CET] <wm4> a frame could be allocated by something else [21:34:58 CET] <ubitux> ok [21:35:18 CET] <ubitux> so much constraints :( [21:35:43 CET] <wm4> in theory, you could know how much padding there is with AVFrame, though [21:35:52 CET] <wm4> or maybe the stride [21:36:18 CET] <wm4> uh, I guess, if it's about the line width, the stride tells you [21:37:22 CET] <ubitux> it's checking that stride e align(w,8)*depth [21:37:35 CET] <ubitux> but if it's not the case it seems to be doing some kind of magic [21:38:38 CET] <wm4> huh, why does it mix mmx code with normal C code, and expects the compiler knows that it can't touch the registers [21:38:47 CET] <ubitux> faith [21:39:17 CET] <ubitux> let's hope it's not going to ftree vectorize this loop ;) [21:39:39 CET] <ubitux> i'm trying to rewrite this to yasm but it's madness [21:43:39 CET] <wm4> compile it, disassemble it, and git add it [21:43:50 CET] <ubitux> that's exactly what i did [21:43:56 CET] <ubitux> but there are issues [21:44:12 CET] <ubitux> typically, there is this struct access [21:44:35 CET] <ubitux> where there is coefficient specially scaled for this simd code in some other common part of the code [21:44:54 CET] <ubitux> these fields have a special scaling which is then changed in the asm itself, even though it's the only place where it's used [21:50:20 CET] <ubitux> http://pastie.org/pastes/10733277/text hi framecrc [21:52:19 CET] <jamrial_> heh, framecrc uses adler32. crc would never give you that :p [21:53:24 CET] <jamrial_> nevcairiel: can you reproduce this? http://pastebin.com/NN2A0nGG configure with --cpu=haswell on x86_32 [21:54:10 CET] <jamrial_> seems to be a problem with tree vectorize [21:55:19 CET] <ubitux> speaking of the devil.. :) [21:55:34 CET] <jamrial_> yep [21:56:46 CET] <michaelni> ubitux, i suspect its still needed but i dont know / dont have a testcase [21:57:22 CET] <ubitux> ok [21:59:01 CET] <wm4> why not just kill mmx asm [21:59:37 CET] <ubitux> still better than nothing [21:59:51 CET] <jamrial_> most of it is inline micro optimizations like cabac at this point [22:00:22 CET] <ubitux> is cabac really simd? [22:00:28 CET] <ubitux> i thought it wasn't possible [22:02:28 CET] <jamrial_> look at x86/cabac.h [22:02:44 CET] <jamrial_> but no, it's not simd [22:03:05 CET] <jamrial_> my bad [22:04:38 CET] <wm4> but this is in swscale [22:05:56 CET] <ubitux> if someone can make sense to the usage of x86_reg index = -h_size / 2 in that file, it will be helpful [22:06:04 CET] <ubitux> s/to/of/ [22:09:28 CET] <J_Darnley> I would almost certainly make a .i first then try to understand that. [22:30:05 CET] <ethe> hmm regarding #5261 I did search "SDL" and #3604 didn't come up [22:30:06 CET] <ethe> odd [22:30:40 CET] <ubitux> there is a patchset for sdl2 [22:30:55 CET] <ethe> not yet ;) [22:31:09 CET] <ubitux> no there is [22:31:34 CET] <ubitux> https://github.com/cus/ffplay/commits/sdl2 [22:32:30 CET] <ethe> was about to say: It might be a good shout to google first (as in, I should probably check before saying anything) [22:35:14 CET] <ubitux> btw, i will push the subtitles patchset by the end of the week [22:35:38 CET] <ubitux> i'll probably ping mid week and apply this week end [22:36:39 CET] <ubitux> after this we can seriously consider moving the thing to lavu (or consider again using AVFrame), and then work on its integration within lavfi [22:37:02 CET] <ethe> I'm gonna see if I can extract a patch, and modify it to allow either sdl2 or sdl (can I do this? I'm just thinking about licensing, idk if that is allowed) [22:37:30 CET] <ubitux> no, supporting both sdl and sdl2 is going to be maintainance nightmare [22:37:39 CET] <ubitux> sdl2 is everywhere we care anyway [22:37:55 CET] <ubitux> cus is Marton btw, the ffplay maintainer [22:38:17 CET] <ubitux> the patchset was mentioned (posted?) not long ago [22:38:26 CET] <ethe> oh right >.< I wonder why it wasn't merged then [22:38:33 CET] <ubitux> ask him :) [22:39:00 CET] <ubitux> maybe he's wondering about porting the sdl device as well [22:39:09 CET] <ubitux> so we can drop the sdl1 dependency [22:39:27 CET] <ubitux> maybe you could work on that [22:39:29 CET] <ubitux> just mail him [22:39:59 CET] <ethe> through the mailing list? [22:40:06 CET] <ubitux> or private [22:40:36 CET] <ubitux> git log --author=Marton ffplay.c to get the mail [22:51:15 CET] <nevcairiel> jamrial_: confirmed, happens here as well [22:53:22 CET] <nevcairiel> someone should come up with a really smart way to handle cabac better :D [23:59:52 CET] <michaelni> j-b, should i replace the hwaccel-mt warning by something, or you have another suggestion? [00:00:00 CET] --- Tue Feb 23 2016

1 0

ffmpeg.log.20160222
by burek 23 Feb '16

23 Feb '16

[00:03:05 CET] <yeryry> I'm trying to use rtmp with ffplay under Windows, and it seems that the parameter parsing doesn't properly understand " " around a parameter, and still splits it at a space. Is there some other syntax for this, or maybe this is a windows-build anomaly or something? [05:36:39 CET] <solrize> current master with default config gets many compilation warnings like: [05:36:42 CET] <solrize> libavcodec/h264_cavlc.c:605:46: warning: array subscript is above array bounds [-Warray-bounds] [05:36:42 CET] <solrize> ((type*)block)[*scantable]= level[i]; \ [05:36:42 CET] <solrize> ^ [05:36:45 CET] <solrize> should i care ? [07:12:59 CET] <c_14> solrize: as long as "many" isn't several hundred/thousand and it doesn't break compilation you can probably ignore them [07:13:11 CET] <solrize> hmm ok thanks [07:13:19 CET] <solrize> it might have been a dozen or so [07:13:45 CET] <c_14> Oftentimes they're false positives that require more effort to get rid of than they're worth. [07:26:23 CET] <solrize> fair enough [10:57:54 CET] <Shadow42085> ffmpeg can not find libass which i compilied myself and installed it [10:58:51 CET] <__jack__> Shadow42085: find, for compiling, or at runtime ? [10:59:14 CET] <Shadow42085> during ./configure [10:59:14 CET] <__jack__> in any case, seems to be a location issue [10:59:24 CET] <__jack__> (at runtime, ldconfig) [11:00:06 CET] <Shadow42085> its saved at /usr/local/lib/ass [11:00:39 CET] <__jack__> Shadow42085: any interesting stuff at the tail of config.log ? [11:02:04 CET] <Shadow42085> I will pastebin the log [11:04:45 CET] <Shadow42085> www.pastebin.com/Xq9S8dd [11:07:18 CET] <Shadow42085> its even in /usr/local/lib [11:07:32 CET] <__jack__> This page has been removed! [11:08:52 CET] <Shadow42085> www.pastebin.com/jXq9S8dd [11:08:58 CET] <Shadow42085> forgot one letter [11:09:25 CET] <JEEB> see config.log [11:09:37 CET] <JEEB> that should tell you what it tried to check for and how it failed [11:11:07 CET] <Shadow42085> i pastebin the log and i can make heads or tails of since I installed libass by compiling it [11:11:56 CET] <Shadow42085> the compile process with libass had no errors [11:12:16 CET] <Shadow42085> unless i didnt compile it right [11:12:29 CET] <Shadow42085> i am running Slackware [11:19:12 CET] <Shadow42085> so jack any ideas [11:24:17 CET] <__jack__> Shadow42085: well, how did you installed libass ? its located on /usr/local/lib/ass, or /usr/local/lib ? pkg-config looks for that: check_pkg_config libass ass/ass.h ass_library_init [11:24:21 CET] <relaxed> Shadow42085: PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure ... [11:24:34 CET] <__jack__> according to man-page, pkg-config search .pc files, find them [11:28:44 CET] <Shadow42085> i compiled it using ./configure then make then make install [11:41:53 CET] <Shadow42085> libass.pc is in /usr/local/lib/pkgconfig [11:45:52 CET] <Shadow42085> so do i need to include /usr/local/lib in my confiure ptch [11:46:00 CET] <Shadow42085> path? [11:49:16 CET] <relaxed> Shadow42085: run ffmpeg's configure like the following, PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ./configure <enable ffmpeg external libs here> [11:52:25 CET] <Shadow42085> there we go [11:52:56 CET] <Shadow42085> so i need to make pkg-config to look there as well? [11:54:05 CET] <Shadow42085> i mean to say add /usr/local/lib/pkgconfig to pkg-config search paths? [11:54:26 CET] <relaxed> PKG_CONFIG_PATH=/usr/local/lib/pkgconfig tells it to look there [11:55:04 CET] <Shadow42085> is there a way to tell it to do that automanically? [11:55:53 CET] <BtbN> use propper packages instead of manualy installing stuff in non-default paths. [11:56:00 CET] <Shadow42085> its compiling now so will know soon [11:56:47 CET] <Shadow42085> well some of the files are not part of the repos [11:59:19 CET] <Shadow42085> and I am not using slackbuild or sbo those just reaks of what I am used to in debian/ubuntu, Arch, FreeBSD [12:00:01 CET] <Shadow42085> it will be easier to compile once some of these packages become part of slacks repos [12:00:32 CET] <Shadow42085> not as a slackbuild or easy mode builds [12:02:02 CET] <andrey_utkin> do H.264 B-frames reference _following_ I-frames? If yes, can this be worked around somehow so that I could remove the following GOP entirely or replace it? [12:02:42 CET] <BtbN> they probably can, but usualy don't. [12:04:21 CET] <andrey_utkin> Thanks for replying! What could I check in ffmpeg code (I mean patching libavcodec) to printout whether this happens? Or which free utilite is available to view this information of media file? [12:13:32 CET] <jkqxz> andrey_utkin: That's more an x264 question rather than an ffmpeg question, I think (for the changing behaviour, at least). What are you actually trying to do? (Do you have a broken decoder which doesn't work on some conforming streams?) [12:15:13 CET] <andrey_utkin> jkqxz, I am implementing timerange-wise transcoder/remuxer for video files. The current approach is to replace GOPs, and I wonder can it end up with breaking B-frames which reference _next_ I-frame which was replaced. [12:15:33 CET] <andrey_utkin> so far I haven't noticed this [12:15:57 CET] <andrey_utkin> but those B-frames feel dangerous in this regard [12:16:30 CET] <andrey_utkin> so I wonder if there could be a "bitstream filter" to make such B-frames usual P-frames for example :) [12:18:51 CET] <__jack__> yep, reencode :p [12:19:42 CET] <jkqxz> Those B frames are after the I frame in stream/decode order anyway (but not in display order), so won't you already be removing them when splicing? [12:22:44 CET] <andrey_utkin> oh indeed. So given B-frame is demuxed before the I-frame, B cannot reference the I... so my concern is not real [12:23:11 CET] <Mavrik> andrey_utkin, IDR frames are what you're looking for [12:23:57 CET] <andrey_utkin> Mavrik, is there a way to distinguish IDR frames in ffmpeg API? [12:23:58 CET] <jkqxz> As long as you never rearrange the stream order, then yes you are always ok on this problem. [12:24:13 CET] <Mavrik> andrey_utkin, no idea [12:24:17 CET] <Mavrik> check libx264.c [12:25:26 CET] <andrey_utkin> thanks, will check [12:25:55 CET] <andrey_utkin> so is it safe to assume that GOPs (I-frame + all following non-I-frames sequence) are self-contained and can be replaced? Or this is true only in terms of "IDR-frame + all following non-IDR-frames sequence"? [12:26:50 CET] <Mavrik> Only true in terms of IDR frames. [12:27:05 CET] <Mavrik> Frames that follow an IDR frame may not reference frame before an IDR frame. [12:27:31 CET] <jkqxz> No. There still might be something after another I frame which references something in the section you've removed. [12:27:56 CET] <jkqxz> (Unless the end of the section is also at an IDR frame.) [12:29:06 CET] <jkqxz> That is, you can have exactly the same problem as you initially described at the end as well as at the beginning. [12:29:14 CET] <Mavrik> Indeed. [12:29:24 CET] <Mavrik> So essentially you slice on IDR boundaries. [12:30:00 CET] <jkqxz> (And you aren't saved by decode order, because the problematic frame is after the next I frame in decode order but before in display order.) [12:34:09 CET] <andrey_utkin> ok so the problem is actually about P/B frames which may reference previous GOPs? [12:34:56 CET] <Mavrik> "GOP" is a useless distinction when dealing with H.264 streams. [12:35:12 CET] <jkqxz> If you have a well-defined GOP structure, yes. (The problem is really that H.264 allows arbitrary referencing and there isn't any external information to work out what's going on.) [12:35:17 CET] <Mavrik> All the references care about is frame count and existence of IDR frames. [12:35:44 CET] <Mavrik> Usually a GOP is bounded by a pair of IDR frames, but static GOPs aren't really a thing. [12:39:06 CET] <andrey_utkin> great, thank you so much for support. Is anybody of you ok to consult me further in person on this subject, if the need arise? I am happy to pay. Asking on IRC sucks when it's weekend or an evening or nigh, that's why I'd like more stable contact with people who can consult me. [12:39:23 CET] <jkqxz> (H.265 solves this problem by introducing lots of different NAL unit types to distinguish these cases - the specific case here is exactly RASL frames, which you can then see as a NAL unit type and drop easily.) [12:45:20 CET] <||arifaX> I want to create a 'silent' mp3 on windows. I tried ffmpeg.exe -ar 48000 -t 60 -f s16le -acodec pcm_s16le -i NUL -acodec libmp3lame -aq 4 "C:\temp\test.mp3" but it does not work, any ideas how to get /dev/zero in place here using Windows? [12:50:56 CET] <||arifaX> found it myself, thanks anyway: ffmpeg.exe -f lavfi -i anullsrc=r=44100:cl=mono -t 60 -q:a 9 -acodec libmp3lame "C:\temp\test.mp3"" [12:53:16 CET] <andrey_utkin> arifaX, you could use ffmpeg -f lavfi -i aevalsrc=0 ... [12:53:26 CET] <andrey_utkin> See http://ffmpeg.org/ffmpeg-filters.html#aevalsrc [12:55:11 CET] <||arifaX> andrey_utkin: you are right, works, too! - Thanks saves some bits in code :) [13:08:45 CET] <andrey_utkin> __jack__ > yep, reencode :p [13:08:45 CET] <andrey_utkin> I wonder if this is possible to reencode just one non-key H.264 frame, so that it still correctly references other frames which are already encoded and which are left unmodified. Of course converting it to I-frame should work. [13:23:56 CET] <jkqxz> andrey_utkin: It is certainly possible in theory, but I don't know of any tools which would help you do it. x264 does not have a way to get the stateless single-frame encode (given reference frames, etc.) which you need here. [13:25:13 CET] <jkqxz> Encoding it entirely as IDR would be easier (just put the single frame into x264), but will also inflate the bitstream by probably an unreasonably large amount. [14:34:30 CET] <hseg> Hi. How do I get a dump of the encodings used on a file? [14:35:27 CET] <hseg> What I'm trying to do is the following. Windows Movie Maker only likes some of my .VOB files, so I'm trying to figure out what commonalities exist between the videso [14:36:23 CET] <BtbN> I'd guess it only likes the ones that are not "encrypted" [14:37:47 CET] <firewated> ffprobe can output json i think [14:37:52 CET] <hseg> I have some logs from a while back when I first started this project: This works: http://sprunge.us/WjeB, This doesn't: http://sprunge.us/QjZF And this one has another error: http://sprunge.us/gLhB [14:38:16 CET] <hseg> The comments below give the bitrates seen among other files with similar output [14:39:18 CET] <hseg> I note that the first group have 4-digit bitrates, whereas the third group have 6-digit bitrates. [14:39:44 CET] <swaggerboi> Hello [14:40:02 CET] <swaggerboi> Could somebody please compile the latest ffmpeg for Windows with --enable-libass ? [14:40:13 CET] <swaggerboi> I don't have MinGW or Cygwin installed at the moment. [14:40:23 CET] <swaggerboi> And I really need this to hardcode some subtitles. [14:40:57 CET] <J_Darnley> http://ffmpeg.org/download.html [14:41:14 CET] <BtbN> Did zeranoe stop building with libass? [14:41:37 CET] <hseg> Ah, seems that I was using ffprobe to obtain these logs [14:42:26 CET] <hseg> Doh. Can't be ffprobe, given that the logs start with the line "ffmpeg version..." [14:42:29 CET] <J_Darnley> hseg: I see no obvious reason why one works and the other two don't [14:42:44 CET] <BtbN> It's Windows Movie Maker after all [14:43:01 CET] <BtbN> It doesn't need good reasons not to work. [14:43:17 CET] <hseg> Yeah. Problem is I already have quite a bit of work invested in Movie Maker [14:43:29 CET] <hseg> I suppose I'd have less trouble with Cinerella? [14:43:38 CET] <BtbN> remux to something else then and try your luck again. [14:43:50 CET] <swaggerboi> J_Darnley is there a command to list installed libraries in ffmpeg? [14:43:55 CET] <BtbN> The worst thing with WMM is that it can only output to shitty wmv [14:43:59 CET] <J_Darnley> ./ffmpeg [14:44:06 CET] <J_Darnley> or just ffmpeg in this case [14:44:20 CET] <J_Darnley> they're always printed [14:45:31 CET] <swaggerboi> Oh wow, seems like I already have libass [14:45:35 CET] <swaggerboi> Carry on fellas [14:45:38 CET] <swaggerboi> thanks [14:47:00 CET] <hseg> The three differences I can find between the first and second paste are the presence of bt470bg in the parentheses following yuv420p, a max of 9282kb/s vs. 4756kb/s on the video stream, and a max of 384kb/s vs 256kb/s on the audio stream [14:47:43 CET] <hseg> The third paste in addition also has messages of the form "Invalid frame dimensions 0x0" [14:48:58 CET] <J_Darnley> did I miss that? [14:49:29 CET] <J_Darnley> i see [14:49:45 CET] <J_Darnley> I guess it just has a little junk at the begining [14:50:06 CET] <J_Darnley> You'll see that ffmpeg gets it right (probably) [14:50:18 CET] <hseg> ? [14:50:35 CET] <J_Darnley> Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p(tv, bt470bg), 720x576 [SAR 16:15 DAR 4:3], max. 9282 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc [14:51:24 CET] <hseg> So how do I transcode so that bt470bg is dropped, video max is dropped to 4756kb/s and audio max is dropped to 256kb/s [14:51:26 CET] <hseg> ? [14:51:40 CET] <J_Darnley> Why would you want to do that? [14:51:58 CET] <Mavrik> Yeah, don't drop color space definition, it'll make colors f00 [14:51:59 CET] <J_Darnley> -b:v and -b:a [14:52:23 CET] <hseg> Because that's what the working files look like [14:52:54 CET] <Mavrik> Having color space defined isn't going to make a file nonworking. [14:53:25 CET] <hseg> Although... There are a couple of files that seem to work since the last time I checked, so I'll check what they look like [14:54:44 CET] <hseg> OK, they have *very* different metadata than I was expecting. [14:59:17 CET] <hseg> Blergh. OK, let's step back. What I want is a program that will permit me to concatenate and temporally crop video files, and a program that will allow me to create a DVD from video files, with that funky chapter thing. [14:59:26 CET] <hseg> Any suggestions, given that WMM is crap? [15:00:11 CET] <firewated> temporarily crop? [15:00:26 CET] <J_Darnley> I don't know about the dvd creating thing but I might use ffmpeg to do the rest. [15:00:56 CET] <hseg> i.e. delete from time 10:20 to 12:40 [15:01:49 CET] <hseg> Preferably, the program would be graphical in order to permit viewing the video I'm editing while I'm editing it. [15:02:20 CET] <hseg> My osmotic knowledge suggests Cinerella would be a match for this job. [15:03:47 CET] <firewated> i probably wouldn't do any of it with ffmpeg because then you'd be encoding twice [15:04:09 CET] <BtbN> WMM encodes to WMV, that's even worse. [15:04:36 CET] <BtbN> And that's what lossless intermediate codecs are for [15:05:37 CET] <firewated> i assumed the video would be too big to store in a lossless format [15:06:46 CET] <BtbN> There is no such thing as "too big" [15:06:59 CET] <BtbN> Only too small disks [15:07:20 CET] <BtbN> Or not enough of them [15:07:22 CET] <hseg> So what are you suggesting? [15:09:22 CET] <andrey_utkin> how to trigger h264_parse as breakpoint? I run "-c copy" and "-c rawvideo" commands on MP4/H.264 file, using --enable-debug --disable-stripping statically-linked ffmpeg binary, but my breakpoint is never triggered. Any clue? [15:09:40 CET] <hseg_> Sorry, connection dropped. You were saying? [15:11:41 CET] <firewated> unless you have enough storage to store the video(s) you're working on in a lossless format, you're better of just doing everything in a program in one go [15:14:04 CET] <BtbN> Most professional video editing tools probably unpack to a huge intermediate format anyway [15:19:49 CET] <firewated> know any good intermediate formats btw? i usually use huffyuv [15:24:15 CET] <hseg_> Egads. All I wanted was to concatenate and crop some videos. I don't know what my options are, I don't know what the various formats are, and I don't know whether I should care. [15:24:45 CET] <hseg_> Sorry, I'm just getting frustrated at this seemingly-simple project becoming one hell of a yak-shaving exercise. [15:24:45 CET] <J_Darnley> If you want to use some graphical tool then go ahead. [15:24:59 CET] <hseg> Any recommendations? [15:25:07 CET] <J_Darnley> no [15:25:13 CET] <J_Darnley> I haven't used one for years [15:25:14 CET] <hseg> Cinelerra OK? [15:26:03 CET] <hseg> Dammit, they don't build for windows. [15:26:41 CET] <hseg> How would you do this without graphical tools? [15:27:33 CET] <firewated> i don't know how you'd do the chapter graphics and stuff, but the clipping and concatenating is pretty simple [15:27:37 CET] <J_Darnley> probably ffmpeg's concat demuxer and select filter [15:28:03 CET] <J_Darnley> or I would go back to avisynth [15:28:15 CET] <hseg> Have no idea what you mean by that. [15:28:28 CET] <hseg> Can skip the DVD part for now. [15:32:08 CET] <firewated> there's a page for concatenating https://trac.ffmpeg.org/wiki/Concatenate [15:32:46 CET] <firewated> for clipping you can use the arguments "-ss" to specify start time and "-to" to specify end time of a clip you want to extract from a video [15:36:32 CET] <hseg> OK... So I cut and paste the videos together using that... then transcode to some output format, then find a dvd solution? [15:37:14 CET] <firewated> yep [15:39:26 CET] <hseg_> Damn connection. [15:39:53 CET] <hseg_> OK. Any suggestions on output format? Caveats I should be aware of? [15:41:25 CET] <firewated> i'd recommend h264 and mp4 with the parameter -crf=18 so you don't lose much detail between encodes [15:41:44 CET] <firewated> maybe even lower than -crf=18 for the intermediate encodes, and 18 for the final one [15:43:16 CET] <hseg_> What's -crf? [15:43:57 CET] <firewated> https://trac.ffmpeg.org/wiki/Encode/H.264 [15:44:17 CET] <firewated> i don't know the technicals but 18 it says 18 is visually lossless and the lower the higher the quality [15:44:55 CET] <hseg_> OK, not really sure what I'm doing here. [15:45:32 CET] <firewated> if you don't specify anything, the output is likely to look noticeably worse than your source [15:48:18 CET] <hseg> Still confused. This is not a domain I'm comfortable in. [15:51:48 CET] <J_Darnley> If you're going to make a dvd of the output then use mpeg2video! [15:52:05 CET] <J_Darnley> There's even a handy -target option for just that case. [15:52:54 CET] <firewated> does it matter what the intermediate format is? [15:53:41 CET] <J_Darnley> Yes [15:53:59 CET] <J_Darnley> Only a crap dvd authoring program will blindly encode the input video [15:54:42 CET] <J_Darnley> And as an intermediate format I would not suggest crf 18 [15:56:40 CET] <firewated> lol, how about saying what you would actually suggest and why [15:57:09 CET] <J_Darnley> Fucking higher quality. [15:57:24 CET] <J_Darnley> crf 18 is a final quality level [15:57:41 CET] <J_Darnley> And I wouldn't be doing this in the first place. [15:58:35 CET] <hseg> Guys... This is getting really confusing for me [15:59:04 CET] <J_Darnley> Then I'll piss off [16:00:14 CET] <hseg> So I'll ask this once and for all: How do I concatenate a heterogeneous collection of videos and obtain one video file in a recommended format, and what format would you recommend? [16:00:16 CET] <hseg> J_Darnley: I appreciate your input, but I'm getting confused and frustrated. [16:01:37 CET] <andrey_utkin> hseg: 1) Reencode clips to same file format, video resolution, video framerate, video codec settings (e.g. default ones). 2) Use concat demuxer to obtain merged video. [16:02:35 CET] <hseg> OK. What format do you suggest? [16:04:42 CET] <Fjorgynn> wmv [16:04:44 CET] <jkqxz> The intermediate format should ideally be lossless to avoid compounding errors from differences in encoding schemes. [16:04:58 CET] <foonix> for intermediate format? something lossless like utvideo, ffvhuff, ffv1 ... [16:05:08 CET] <jkqxz> ffv1 is the ffmpeg answer to this, though it also supports a lot of random other intermediates used by other programs. If you are only using ffmpeg, use ffv1. [16:05:40 CET] <foonix> i think you can play all of them on windows with LAV filters oke [16:06:08 CET] <hseg> OK. So ffmpeg -i file.vob -f ffv1 on all file.vob, then use https://trac.ffmpeg.org/wiki/Concatenate to concat the files I want? [16:07:13 CET] <jkqxz> Yes. [16:09:43 CET] <hseg_> Thank you. Once I've obtained the final concatenated video, what do I transcode it to? [16:12:20 CET] <jkqxz> After your other operations (cropping, etc.)? Generally H.264 with CRF selected based on your quality/size requirements, though it depends what you are going to do with the completed video. [16:12:59 CET] <andrey_utkin> hseg: you don't need any special intermediate format. You can just prepare your clips in the desired format and codec (at last this is true for e.g. H.264 and VP8 codec and file formats such as MPEG TS, MP4, WEBM, Matroska) [16:13:39 CET] <andrey_utkin> at concatenation step and after it, you don't need to reencode/transcode it [16:14:08 CET] <hseg> andrey_utkin: Unsure what you mean. Keep in mind the originals are heterogeneous. [16:14:09 CET] <hseg> I'm going to be making a DVD with the concatenated video file as one of the chapters. [16:14:52 CET] <hseg> (In fact, I'm gathering up several heterogeneous collections into the various chapters of the DVD, but that's irrelevant data) [16:15:51 CET] <andrey_utkin> hseg i am not experienced exactly in making DVD [16:16:16 CET] <andrey_utkin> but i think my point is generally applicable unless some very specific issue with selected format/codec [16:16:19 CET] <jkqxz> A traditional 2000-era DVD? I think there are settings to make exactly the right thing (MPEG-2, etc.) for specific constraints of the medium, but I'm not familiar with them. [16:17:56 CET] <hseg> Again, I don't need much fanciness. All I want is that the chapters will follow one another when playing back the DVD, and that there be a chapter selection menu. [16:17:57 CET] <andrey_utkin> "Keep in mind the originals are heterogeneous." - in my offer, first step is to reencode so there's no more heterogenity. [16:18:12 CET] <hseg> I don't care about the graphics of the menu [16:18:25 CET] <hseg> OK. What do I reencode to? ffv1? [16:19:07 CET] <techtopia> "Past duration 0.999977 too large" [16:19:15 CET] <techtopia> i see hundreds of these errors [16:19:18 CET] <techtopia> what do they mean? [16:19:56 CET] <foonix> so .ts or .m2ts with chapters using mpeg2+ac3 is probably what you want to achieve, hrmz for menu you need some authoring software [16:22:00 CET] <foonix> hmmz otoh ifo+vobs are probably needed for the standalone player ;/ [16:23:08 CET] <hseg> How about mp4+h.264? [16:23:18 CET] <foonix> thats not DVD [16:23:49 CET] <foonix> but it would be much better if you can use something actual h264+aac mp4/mkv ... [16:25:53 CET] <hseg> Well, DVD flick seems to support mp4+h.264, so I think I'll go with that. [16:28:57 CET] <hseg> How do I do that though? [16:31:08 CET] <esby> I got a random question i have lpcm mp4 files from my gh4 panasonic camera. they use pcm_s16be (twos / 0x736F7774) for the audio. [16:31:57 CET] <esby> i can transcode them to mkv files, but i can't do the reverse operation, as ffmpeg says that pcm_s16be is not supported in the mp4 container. [16:32:22 CET] <andrey_utkin> hseg: for step one: for x in clips/*; do ffmpeg -i $x -codec:v libx264 -codec:a aac clips_prepared/$x.mp4; done [16:32:34 CET] <esby> so are the panasonic mp4 files legit according to the mp4 format? is this some king of bugs? or is there an hack to do the reverse operation ? [16:33:52 CET] <JEEB> raw audio was only recently standardized in 14496-12 [16:34:00 CET] <JEEB> and I'm not sure if what you're seeing is legit according to that [16:34:03 CET] <hseg> andrey_utkin: And then ffmpeg -f concat -i chapterN.txt -c copy chapters/chapterN.mp4 ? [16:34:07 CET] <JEEB> it could be something done a la mov [16:35:20 CET] <hseg> andrey_utkin: With some ffmpeg -i chapterN.mp4 -ss starttime -to endtime chapterN-segment.mp4 to cut out unwanted bits? [16:35:50 CET] <JEEB> according to comments it seems like lavf only supports muxing raw PCM into mov [16:36:11 CET] <JEEB> that said, I haven't tried because I've never had the requirement for LPCM in ISOBMFF [16:36:51 CET] <hseg> And what's the difference between -c:v -codec:v and -vcodec? [16:39:44 CET] <JEEB> -vcodec is oldest and the former two are newer ways of noting it with a suffix [16:39:51 CET] <JEEB> -c:v is just the most short one [16:40:10 CET] <JEEB> the suffix capabilities were added to a lot of other things as well [16:40:39 CET] <JEEB> with "codec" it used to be there in the form of special parameters like {a,v,s}codec, but other options might have not had it [16:40:44 CET] <J_Darnley> Someone thought that the options weren't complicated enough. [16:40:49 CET] <hseg_> Ah, OK. Is the command sequence I posted correct? [16:41:47 CET] <J_Darnley> it should work [16:42:04 CET] <hseg> Well, you can never have too many equivalent ways of specifying the same option. Seemingly equivalent, but slightly different options, now... [16:42:11 CET] <hseg> Excellent. [16:42:38 CET] <esby> JEEB: thanks for the comments. [16:42:43 CET] <hseg> Hopefully, it will Just Work (TM) [16:43:52 CET] <hseg> So to recap: ffmpeg -i $x -codec:v libx264 -codec:a aac clips_prepared/$x.mp4, then ffmpeg -f concat -i chapterN.txt -c copy chapters/chapterN.mp4 and I should be good to go? [16:44:37 CET] <esby> JEEB: so the quick fix/hack would be reencoding the audio for now i guess if an mp4 format is needed as final result ? [16:44:59 CET] <J_Darnley> hseg: it should work [16:45:26 CET] <hseg> Gotta go now. [16:45:27 CET] <J_Darnley> esby: the usual suggestion is to use mov if you want pcm, otherwise encode into a format mp4 supports [16:45:37 CET] <hseg> Excellent. Thank you so much. [16:49:33 CET] <esby> J_Darnley: i want to keep the mp4 format, i don't use mov usually, since the person on the other end can't use mkv. [16:49:50 CET] <esby> but maybe using mov could be a work around, dunno actually, never used it [16:53:35 CET] <esby> anyway, not sure the mp4 conversion will be possible [16:54:05 CET] <esby> s/mp4/mov/ [18:31:57 CET] <__raven> hi [18:49:29 CET] <__raven> do you know about a way to do a r128 (loudness) plot of a livestream? [18:55:24 CET] <ethe> https://ffmpeg.org/ffmpeg-filters.html#ebur128-1 maybe? [18:59:45 CET] <ethe> __raven if you take a look at the first example, that should give you some guidance on what you're trying to achieve [19:05:42 CET] <podman> hmm, so using NVENC doesn't seem much faster than not [19:06:26 CET] <BtbN> depends entirely on your settings [19:07:06 CET] <podman> BtbN: true. I also can't seem to get it to work with 60fps video :\ [19:07:16 CET] <BtbN> 4K stuff? [19:07:35 CET] <BtbN> anything up to 1080p shouldn't be an issue to get 60 fps with, if you don't select the most demanding quality settings [19:07:52 CET] <podman> I'm downscaling to 1080p from 4k60fps [19:08:13 CET] <BtbN> I'd guess nvenc is not the slow part in that, but the downscaling is [19:08:25 CET] <podman> but i'm getting "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height" [19:08:34 CET] <podman> works fine with libx264 though [19:10:22 CET] <podman> oh, nvm, it had problems with the video filter for some reason [19:11:48 CET] <podman> was having problems with the scale filter. shrug [19:12:41 CET] <__raven> ethe: yes thats nearly bang on tnx :) [19:16:17 CET] <podman> BtbN: not really sure, but it doesn't seem to make enough of a difference to be worth exploring further as far as I can tell [19:16:48 CET] <BtbN> if downscaling 4K is already slower than your CPU can handle encoding with x264, sure [19:18:03 CET] <podman> BtbN: Yeah, just limited by EC2 Hardware I guess [19:20:12 CET] <podman> The CPU on the G2 instances is a bit slower than the C4 instances [19:20:15 CET] <podman> that might be the issue [19:24:00 CET] <podman> I guess for some kinds of video where it might be faster. hmm [19:26:52 CET] <BtbN> it's not about beeing faster anyway [19:27:21 CET] <podman> faster transcoding speed was my goal [19:30:00 CET] <kepstin> imo: if you want faster transcoding, use a faster x264 preset and/or throw more cpu at it. If you want to transcode video while the cpu's busy doing something else, use nvenc [19:30:57 CET] <podman> kepstin: makes sense. i guess I just thought that maybe nvenc would be a little more efficient. it does seem to be in some cases [19:31:22 CET] <BtbN> you trade lower CPU usage for worse quality, nothing more [20:05:08 CET] <noxee> Hi, I'm writing an IP camera streaming program using Qt and QtAV for video playback (QtAV uses ffmpeg as its underlying playback library). The cameras should all be streaming with the following settings: [20:05:08 CET] <noxee> - Video codec: H.264 [20:05:08 CET] <noxee> - Resolution: 1280x720 [20:05:08 CET] <noxee> - Max FPS: 7 [20:05:08 CET] <noxee> - GOP: 14 [20:05:10 CET] <noxee> - VBR: high [20:05:12 CET] <noxee> The issue I'm having is that the streams become choppy (I believe either skipping frames or trying to catch up) after varying lengths of time. Apparently QtAV supports all the options in the libavformat/options_table.h and I'm currently using the following format options: [20:05:16 CET] <noxee> fmt_opt["tune"] = "zerolatency,fastdecode"; [20:05:18 CET] <noxee> fmt_opt["video_size"] = "1280x720"; [20:05:20 CET] <noxee> fmt_opt["pixel_format"] = "yuv420p"; [20:05:22 CET] <noxee> fmt_opt["probesize"] = 4096; [20:05:24 CET] <noxee> I'm quite new to all of this so I'm not 100% what I'm doing and I've been trying to work with the developer of QtAV to try and resolve the issues but I'm trying to do some additional troubleshooting to see if I can resolve the issue myself so any suggestions would be greatly appreciated. [20:06:33 CET] <llogan> i don't know what QtAV is, but are you using the ffmpeg cli tool? [20:07:35 CET] <kepstin> noxee: are you just decoding and displaying the video, or are you transcoding it? [20:07:55 CET] <noxee> I'm just trying to decode and display it [20:09:42 CET] <noxee> llogan: This is the QtAV project https://github.com/wang-bin/QtAV it's not using the cli tool [20:09:59 CET] <J_Darnley> If you're just decoding then changing encoding settings won't help [20:11:48 CET] <kepstin> and setting video size and pixel format on an input usually doesn't make sense, that should be autodetected by the format unless you're doing raw video. [20:12:41 CET] <kepstin> what protocol is the camera using for streaming? Are you having any issues with cpu usage or network bandwidth as a bottleneck? [20:13:21 CET] <__raven> ethe: is this lavfi "pipeable" anyway? [20:13:47 CET] <noxee> ah crap, one additional not, they cameras are all being re-streamed through evostream and they're coming out as an rtsp stream [20:14:20 CET] <noxee> cpu usage on the machine seems fine (when the application is running and streaming 18 cameras it's only using about 50% overall) network bandwidth should be alright as well [20:15:23 CET] <noxee> when I playback through something like VLC there doesn't seem to be any choppiness to the playback. It only seems to happen when I'm using QtAV (and by extensions ffmpeg) and the application has been running for a little while (choppiness doesn't usually happen straight away) [20:16:23 CET] <kepstin> well, vlc is also using ffmpeg for decoding :) [20:16:48 CET] <kepstin> (although i dunno if the network code is different; the display code almost certainly is) [20:16:53 CET] <noxee> well that's a positive, eliminates one variable [20:25:34 CET] <noxee> what does the option "use_wallclock_as_timestamps" do exactly. Does it just set the computers clock as the clock for ffmpeg to use for timing? [20:27:22 CET] <kepstin> noxee: looks like instead of using the timestamps read from the format, it rewrites the timestamps by setting them to the time that a particular frame was read. Its exact effect might depend on the input format, not sure [20:28:06 CET] <kepstin> probably not something generally useful; most of the formats where it would be useful (e.g. screengrabbers) do that anyways. [20:28:09 CET] <noxee> ok thanks [20:43:37 CET] <noxee> so this is a sample of the log output of the application running http://pastebin.com/gN8AskNh. I've not just got the format hash set to: [20:43:38 CET] <noxee> fmt_opt["tune"] = "zerolatency,fastdecode"; [20:43:38 CET] <noxee> fmt_opt["probesize"] = 200000; [20:44:13 CET] <noxee> that output also only has four cameras involved [20:45:32 CET] <kepstin> noxee: That 'tune' option makes no sense. It's not an input option - it's not even a format option. It's an option for the x264 encoder. [20:45:34 CET] <furq> those are encoding settings [20:45:41 CET] <furq> yeah. what he said [20:46:01 CET] <kepstin> that said, it should just be ignored, I think. [20:46:02 CET] <noxee> ah ok, I was just going off what was in the documents for the QtAV library [20:49:12 CET] <noxee> also I forgot to mention it's using VA-API for hardware accelerated decoding and it's set the display mode to "X11" and the copymode to "ZeroCopy" [22:29:17 CET] <ethe> __raven what do you mean? [22:34:31 CET] <__raven> ethe: -f lavfi -i "amovie=master.ts,ebur128=video=1:meter=18 [out0][out1]" i would need any way to use it "realtime" but amovie does not seem to work with pipes or localhost stream or something. any idea? [22:34:59 CET] <ethe> you can use ffmpeg and pipe it into another command [22:35:35 CET] <__raven> yes i tried but it does not work at place of master.ts [22:37:56 CET] <kepstin> why are you using -f lavfi there? you could better do that with a plain -i and -filter_complex, which would let you use a pipe or stdin [22:38:56 CET] <__raven> kepstin: sry i am new to such kind of filter. how would that r128 "generator" look like then? [22:39:51 CET] <kepstin> this should be equivalent: -i master.ts -filter_complex '[0]ebur128=video=1:meter=18[out0][out1]' [22:40:05 CET] <kepstin> except that you can replace the filename with e.g. - to read stdin [22:40:27 CET] <kepstin> might need to add some -map later in your command-line tho, i'd have to see the whole thing [22:45:32 CET] <__raven> kepstin: hm that syntax only gives me Failed to set value 'ebur128=video=1:meter=18 [out0][out1]' for option 'filter_complex': Option not found :( [22:46:32 CET] <kepstin> __raven: ummm.... what ffmpeg version are you running? [22:46:48 CET] <kepstin> (first line of the output should say) [22:47:15 CET] <__raven> ffplay version 2.7.6-0ubuntu0.15.10.1 [22:47:43 CET] <kepstin> oh, you're using ffplay, not ffmpeg? [22:48:13 CET] <kepstin> hmm. kind of a pity that ffplay doesn't have the -filter_complex option [22:48:25 CET] <__raven> just a moment [22:48:57 CET] <kepstin> if you're running on linux, and you want to read from stdin, you can always do hack of "amovie=/dev/stdin,..." [22:50:25 CET] <kepstin> but i'm not totally sure that'll work with ffplay, since it might try to read keystrokes for commands (like seeking, quit, etc) from stdin. [22:51:09 CET] <__raven> kepstin: no ffmpeg would be just fine. i want to merge the plot with a video into a pip later [22:51:40 CET] <__raven> Output pad "out0" with type video of the filter instance "Parsed_ebur128_0" of ebur128 not connected to any destination [22:51:51 CET] <__raven> this is with ffmpeg and -filter_complex [22:52:25 CET] <kepstin> yeah, you'll want to add the two options "-map out0 -map out1" to the ffmpeg command to say to use those two filter pads in the output file [22:55:30 CET] <__raven> oh but stdin does work for the moment [23:05:32 CET] <__raven> kepstin: seems to work so far tnx :) i just have to find a way to buffer/cache it right [00:00:00 CET] --- Tue Feb 23 2016

1 0

ffmpeg-devel.log.20160221
by burek 22 Feb '16

22 Feb '16

[00:31:07 CET] <rcombs> ubitux: lavf exports a eia_608 stream [00:31:25 CET] <rcombs> I'm looking at that and getting not much of use [00:32:02 CET] <rcombs> (`ffmpeg -i sample.wtv -f ass -`) [00:32:51 CET] <michaelni> Hi everyone, ive switched trac DNS over to the telepoint server, it should all just work like before in theory, if something breaks tell me (we can also easily switch back quickly if there are non trivial problems) [00:33:21 CET] <michaelni> as long as the old server is alive with its disk that is ... [00:33:27 CET] <kierank> it has raid 1 [00:33:32 CET] <kierank> it'll survive [00:33:43 CET] <michaelni> yes [00:34:59 CET] <kierank> how are you syncing the two severs? [00:36:41 CET] <Timothy_Gu> michaelni: https://github.com/FFmpeg/FFmpeg/pull/178/files is ok right? [00:37:01 CET] <ubitux> rcombs: yeah, extracting cc doesn't work that way [00:37:10 CET] <michaelni> kierank, rather primitively, running beastds bak-daily script (which does all he hot copy magic) then plain rsync of that and same manual fixup [00:37:20 CET] <ubitux> rcombs: you need to use the trick i used above (see ()) [00:37:31 CET] <michaelni> this should work fine both directions btw [00:37:36 CET] <ubitux> rcombs: don't ask me why it's done that way, it's probably because of bad reasons [00:38:27 CET] <rcombs> ubitux: so why does lavf expose a stream at all, then? [00:38:34 CET] <rcombs> ubitux: and it outputs packets [00:38:48 CET] <rcombs> (the CC decoder doesn't like those packets, but it does output them) [00:39:45 CET] <ubitux> really? [00:40:06 CET] <rcombs> also I'd imagine it's because of the subtitle data being embedded in the H.264 bitstream and output from the decoder as side data, but that's awful design at every level [00:40:23 CET] <ubitux> yeah [00:40:28 CET] <ubitux> but what are these packets then? [00:40:38 CET] <michaelni> Timothy_Gu, if it builds, yes [00:40:40 CET] <rcombs> that was my question [00:42:32 CET] <rcombs> gotta run now, though [00:43:22 CET] <Timothy_Gu> michaelni: yeah it builds. Ill push it soon [00:46:05 CET] <cone-479> ffmpeg 03Reto Kromer 07master:f8d685270e58: avienc: Remove unused variable 'ret' [00:48:38 CET] <ubitux> rcombs: so it looks like they're missing encapsulation somehow [02:27:55 CET] <atomnuker> ubitux: what happened with the patch that set thread names? [03:45:43 CET] <cone-479> ffmpeg 03Mats Peterson 07master:a51d82b85c83: lavf/avienc: Add palette after BITMAPINFOHEADER [03:45:44 CET] <cone-479> ffmpeg 03Michael Niedermayer 07master:bb629792a275: avformat/avienc: Fix assertion failure with 256 palette entries [04:02:26 CET] <cone-479> ffmpeg 03Mats Peterson 07master:100167451af5: lavc/rawdec: Remove monowhite switching code for 1 bpp AVI without a palette [05:07:31 CET] <michaelni> We still need more backup mentors: https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2016 [07:20:15 CET] <rcombs> ubitux: that stream allegedly works in Windows Media Center [09:46:27 CET] <jya> is there a documentation slightly more expansive for libavfilter than https://ffmpeg.org/libavfilter.html ? i found one on libav.org but I get parsing error when I follow it [09:47:58 CET] <nevcairiel> easiest probably is reading the example [09:48:34 CET] <jya> nevcairiel: and where would that example be ? :) [09:48:46 CET] <nevcairiel> doc/examples/filtersomething [09:49:01 CET] <nevcairiel> filtering_video.c [09:49:05 CET] <nevcairiel> or audio [09:49:08 CET] <nevcairiel> whichever you like [09:49:23 CET] <jya> avfilter_graph_parse2 looked like quite easy to use, all done through a string. more so than creating each filter and input / output manually and linking them [09:50:07 CET] <nevcairiel> thats how the examples work too, they declare input/output explicitly and then use graph parsing to connect them [09:52:53 CET] <jya> ok, i must be looking at something else then.. I had started with the doc there: https://libav.org/documentation/libavfilter.html#yadif not realising that it was the libav.org [10:31:49 CET] <ubitux> atomnuker: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2016-January/188334.html [10:36:26 CET] <jya> nevcairiel: LOL, my code didn't work because I had never called avfilter_register_all [12:57:43 CET] <jya> is it expected that regardless of the yadif filter mode set, you always need to pass two frames to get one out ? after the first one I always get EAGAIN [13:02:09 CET] <iive> jya: are you sure it is yadif issue? not b-frame decoder lag? [13:02:40 CET] <nevcairiel> yadif is temporal, it always works on more frames [13:02:54 CET] <nevcairiel> if you only have one frame overall, you can EOF the filtergraph and get it out [13:03:04 CET] <jya> iive: i passed decoded yuv420 frames (from an mpeg2 recordings) [13:04:20 CET] <jya> my aim is only to replace avpicture_deinterlace. [13:04:45 CET] <jya> the replacement provided is a million times more complicated to use (this is to generate the preview picture of a recording) [13:05:10 CET] <jya> nevcairiel: thanks, i'll try eof the thing then [13:05:27 CET] <jya> (after i found out how it is i can do that) [13:08:57 CET] <jya> nevcairiel: the yadif filter doc states "Output one frame for each frame. " ; it's a bit misleading [13:09:19 CET] <nevcairiel> that doesnt mean there is no delay [13:09:51 CET] <ubitux> aaaand i'm done [13:10:56 CET] <atomnuker> ubitux: so is there really no way to test for whether the functions exist reliably? [13:11:13 CET] <ubitux> i didn't find a way [13:11:36 CET] <atomnuker> mpv has had that feature for a while [13:11:38 CET] <ubitux> there is probably a solution [13:11:54 CET] <ubitux> feel free to give it a try :) [13:12:07 CET] <jya> nevcairiel: to send EOF to the filter, do you use avfilter_graph_queue_command ? [13:12:21 CET] <nevcairiel> no you just feed NULL frames through the graph [13:12:24 CET] <nevcairiel> like flushing a decoder [13:12:31 CET] <jya> oh I see. [13:13:13 CET] <jya> only one null to send? [13:16:57 CET] <ubitux> no, as much as you can [13:17:17 CET] <ubitux> frames can be stuck in batches anywhere in the graph [13:19:17 CET] <jya> ubitux: so I feed this to the graph until I can read one out ? [13:20:57 CET] <nevcairiel> one NULL frame is enough [13:21:07 CET] <nevcairiel> buffersrc wont accept anymore [13:21:13 CET] <nevcairiel> it just sets the EOF flag anyway [13:21:19 CET] <ubitux> oh wait i thought you wanted to flush [13:21:29 CET] <ubitux> and get all the remaining frames [13:21:49 CET] <nevcairiel> you send one NULL frame and then keep polling buffersink until it stops giving you frames [13:21:50 CET] <jya> ubitux: i have one frame (interlaced) to feed, and just want one out. [13:22:04 CET] <jya> the image out is rather small anyway, just to display in the list of recordings made [13:29:23 CET] <michaelni> kierank, your trac server is timing out, i wanted to check some configs on it [13:30:04 CET] <michaelni> ssh: connect to host fftrac-gb.ffmpeg.org port 22: Connection timed out [13:34:24 CET] <jya> nevcairiel: thank you for your help, I have my picture now.. Was just about to give up and copy the old code of avpicture_deinterlace [13:37:19 CET] <kierank> michaelni: I pressed reset [13:41:24 CET] <michaelni> ok login works again, thanks [14:34:53 CET] <durandal_1707> kierank: whats happening with your servers? [14:35:09 CET] <kierank> durandal_1707: disk failure [14:36:04 CET] <durandal_1707> how old? [15:01:11 CET] <iive> single disk? [15:02:08 CET] <cone-318> ffmpeg 03Oliver Collyer 07master:a2f8beef2dfa: ffserver&ffm: Fixed issues preventing ffserver write_index and files_size from being set correctly which was breaking ffserver streaming. [15:02:08 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:0910488a1621: avformat/riffenc: Also check codec tag before setting raw_pal_avi [16:08:23 CET] <ubitux> Timothy_Gu: MongoError: document is larger than the maximum size 16777216 [16:08:29 CET] <ubitux> seems i can't submit to fate anymore :P [16:08:33 CET] <ubitux> (drd) [16:08:44 CET] <JEEB> so we got mongo and no proper db? [16:08:59 CET] <ubitux> no idea [17:28:15 CET] <durandal_1707> why vc2enc includes ffversion.h? [17:28:47 CET] <durandal_1707> its getting recompiled all the time [17:30:19 CET] <atomnuker> durandal_1707: to output the ffmpeg version as a comment to the bitstream [17:32:29 CET] <jamrial> shouldn't you use libavcodec version instead? [17:32:54 CET] <JEEB> that isn't generally as useful [17:32:55 CET] <rcombs> call av_version_info()? [17:33:04 CET] <JEEB> and yes, av_version_info() could be a better one [17:33:13 CET] <JEEB> unless it has too much info [17:33:16 CET] <JEEB> or whatever [17:33:24 CET] <rcombs> literally returns FFMPEG_VERSION [17:33:38 CET] <atomnuker> will replace it in a few minutes [17:33:39 CET] <rcombs> i.e. the contents of ffversion.h [17:34:43 CET] <rcombs> alternately, lavc/utils.c provides `const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;` [17:35:45 CET] <jamrial> i insist, the library is what encoded the video. why should the bitstream report the git repo revision (or the ffmpeg version if it's a release) instead of avcodec's version? [17:36:18 CET] <atomnuker> jamrial: that's what I'd like to use too [17:36:26 CET] <atomnuker> but I couldn't find a header which provides that version [17:37:01 CET] <jamrial> LIBAVCODEC_IDENT [17:37:08 CET] <rcombs> ^ [17:37:23 CET] <jamrial> libavcodec/version.h [17:37:25 CET] <rcombs> <lib>/version.h [17:37:45 CET] <jamrial> plenty of macros for different needs. stringified or not [17:41:29 CET] <cone-318> ffmpeg 03Rostislav Pehlivanov 07master:dc0481f2fbae: vc2enc: use LAVC_INDENT instead of FFMPEG_VERSION for encoder comment [17:41:33 CET] <atomnuker> done [17:51:27 CET] <jamrial> great, thanks [17:54:35 CET] <jamrial> atomnuker: this should for that matter be hardcoded to "Lavc" when bitexact output is requested [17:54:55 CET] <jamrial> for when you add vsynth tests [18:32:21 CET] <cone-318> ffmpeg 03James Almer 07master:778439b69a63: avcodec/webp: move exif_metadata outside of WebPContext [19:19:19 CET] <Timothy_Gu> ubitux: you can ignore that error [19:19:41 CET] <ubitux> sounds good to me [19:21:19 CET] <Timothy_Gu> ubitux: I started migrating data to a mongo db so that when I want to extract some data i don't have to write a CSV parsing function every single time [19:24:56 CET] <Timothy_Gu> and so far it's only your DRD (and TSan) instances that's causing this error :P [19:25:46 CET] <ubitux> drd, helgrind, and tsan yes [19:25:59 CET] <ubitux> mongo is not reliable though... but whatever [19:26:11 CET] <ubitux> not sure why you want to write your own csv parsing lib [19:26:31 CET] <Timothy_Gu> because right now every report is stored as two different CSV files [19:26:42 CET] <Timothy_Gu> one has all the metadata [19:27:21 CET] <Timothy_Gu> the other is called "report" and contains all the tests in the format "<testname>:<status>:<base64-encoded diff>:<base64-encoded stderr" [19:27:29 CET] <Timothy_Gu> (report is xz'd) [19:27:41 CET] <ubitux> i mean csv parsing libs already exist and are probably less overkill than mongo [19:29:08 CET] <Timothy_Gu> well say I want to see which commit broke a commit, in a shell. It's either a line of mongo query or a well-thought out line of xz+grep+awk/cut [19:29:41 CET] <Timothy_Gu> plus mongo is about 7x smaller than the existing architecture [19:43:48 CET] <beastd|2> Timothy_Gu: I am not arguing because I don't understand what you wnat to accomplish. But if your CSV data (is strictly restricted, never needs quoting) just decompress and awk should be quite effective. In other cases using a real CSV tool/module to process the files might make more sense. [20:09:30 CET] <cone-318> ffmpeg 03Alex Agranovsky 07master:6dc1d5f87ced: lavf/mpjpeg: probe should not depend on Content-Length MIME header being present [20:09:31 CET] <cone-318> ffmpeg 03Michael Niedermayer 07master:0028da36cdb9: avformat/mpjpegdec: add AVFMT_NOTIMESTAMPS [20:28:43 CET] <jamrial> j-b: why haven't you guys removed the ffmpeg libavcodec blacklist on vlc yet? the hwaccel change has been reverted on git head for a few weeks now and made it on time for ffmpeg 3.0 [20:40:36 CET] <ubitux> what's the purpose of the sws alpha config? [20:40:50 CET] <ubitux> why wouldn't you want alpha support? [20:41:03 CET] <ubitux> just smaller binary size? [20:51:25 CET] <wm4> jamrial: troll payback, maybe [20:59:01 CET] <Gramner> jamrial: go poke courmisch [21:27:30 CET] <jamrial> wm4: for what? [21:35:11 CET] <cone-318> ffmpeg 03Paul B Mahol 07master:2b5b0011823c: doc/filters: fix nnedi typos [22:07:15 CET] <j-b> jamrial: see the ticket. [22:15:44 CET] <jamrial> j-b: yes, i see it's being tracked. my question is why it hasn't been done already. five days since the trac task was added is more than enough to revert a single commit, or change the version check range if deemed necessary [22:15:58 CET] <jamrial> distros are doing crazy stuff to workaround this, like Arch who nows ships both ffmpeg 2.8 and 3.0 and forces vlc 2.2.2 to use the former when it shouldn't be necessary [22:16:27 CET] <j-b> jamrial: sorry, but I do not care [22:17:08 CET] <j-b> The ticket is quite clear why the current situation is worse than before [22:18:28 CET] <j-b> "That does not make much difference. This is even worst. Now instead of failing, the application will execute unsupported code. (And users will file bugs here that VLC triggers warnings.) " [22:18:38 CET] <jamrial> i don't agree. the hwaccel infrastructure is now the same as it was months ago, except it now emits a warning [22:19:17 CET] <jamrial> said "unsupported code" was executed before, and it would be executed now [22:19:26 CET] <j-b> it was not unsupported before. [22:19:28 CET] <j-b> now it is. [22:19:36 CET] <j-b> and now any commit can break it. [22:19:53 CET] <j-b> and your answer will be "it's unsupported, we don't care" [22:20:14 CET] <jamrial> no, i'm not among the people that give that kind of answer [22:22:01 CET] <j-b> maybe not you, but other will [22:23:01 CET] <jamrial> j-b: we rolled back a change for the sole purpose of undoing a downstream breakage. it's disingenuous to assume we would carelessly break it again [22:24:00 CET] <j-b> If it is now unsupported, it means it's ok to break it [22:25:06 CET] <wm4> well who cares, vlc can stay on 2.8 forever [22:25:12 CET] <jamrial> if it were ok to break it, we wouldn't have rolled back anything to being with [22:25:18 CET] <wm4> clearly they're not interested in actually solving this situation [22:26:04 CET] <j-b> jamrial: then what is this warning about? [22:26:46 CET] <j-b> wm4: indeed, who cares? [22:27:30 CET] <ubitux> unless i'm mistaken, it just means vlc is doing something it shouldn't do, so it's now warning, just like we would emit a warning for use of deprecated stuff [22:27:42 CET] <jamrial> j-b: a request for downstreams to do the right thing. but if they don't, it's clear after the revert commit that the intention is not to break people's shit [22:27:58 CET] <j-b> jamrial: ubitux just said the opposite. [22:28:05 CET] <j-b> either it works or it does nto [22:28:26 CET] <ubitux> where did i say it doesn't work? [22:28:45 CET] <j-b> You just said VLC shouldn't do that. [22:28:56 CET] <ubitux> that doesn't mean it doesn't work [22:28:58 CET] <j-b> So, disabling the feature sounds correct to me. [22:29:06 CET] <jamrial> it shouldn't, like it shouldn't have done it since hwaccel was first implemented. it doesn't mean it will not work [22:29:13 CET] <jamrial> since it has always worked [22:29:40 CET] <j-b> It's funny, it's exactly not what the people who implemented hwaccel in the first place said, but fine [22:29:59 CET] <cone-318> ffmpeg 03Zalewa 07master:2ac5a1a28ece: ffserver: NoVideo and NoAudio flags weren't cleared between streams. [22:30:18 CET] <wm4> vlc gives bullshit attitude == we don't have to care [22:30:50 CET] <j-b> sorry, I don't really see what's the bullshit about. [22:31:00 CET] <j-b> but if you want to believe this, sure. no pb for me. [22:36:59 CET] <nevcairiel> j-b: nowhere in the message does it even say "unsupported", in fact BBB even went out of his way to make sure it works in the vp9 hwaccel, but the fact remains that its not a recommended mode because it adds certain constraints which can easily result in bugs [22:38:34 CET] <wm4> plus it's not any different in ffmpeg 2.8, LOL [22:38:45 CET] <j-b> "its use is discourage" [22:39:20 CET] <j-b> nevcairiel: agreed. [22:39:28 CET] <Compn> j-b : you want someone to document the feature and mark it supported? [22:39:31 CET] <Compn> that can be arranged. [22:39:34 CET] <Compn> jamrial : right ? [22:39:56 CET] <j-b> Compn: tbh, I don't really care about Linux anymore, as I already told you. [22:40:08 CET] <Compn> i dont remember this, but ok [22:40:27 CET] <Compn> i'm not a big fan of distro stuff anyway :P [22:40:35 CET] <jamrial> dxva2 is not linux [22:40:55 CET] Action: Compn doesnt remember saying word 'linux' [22:41:25 CET] <j-b> IIRC, the problem is that when you ask for hw accel, it can fallback to software, but you can't know that in advance (which is expected). [22:42:30 CET] Action: Compn only looking for solution to problem [23:27:11 CET] <jkqxz> Is there some way to indicate to lavc that it /must/ use the hwaccel you've given it, and return an error rather than falling back to software if it can't? [23:27:56 CET] <cone-318> ffmpeg 03Marton Balint 07master:3a4232a1a025: avformat/asfenc: write group_mutual_exclusion_objects for audio on multiple languages [23:30:21 CET] <jkqxz> (Working around the hwaccel/threading problem, given slightly more effort from the user to close and reinit in their preferred software-only mode after getting the error return from a decode call.) [00:00:00 CET] --- Mon Feb 22 2016

1 0

ffmpeg.log.20160221
by burek 22 Feb '16

22 Feb '16

[00:05:00 CET] <qwertzsqwert> JEEB: nothing there I'm afraid. [00:05:08 CET] <qwertzsqwert> Never mind. [00:05:52 CET] <DHE> If I want to specify multiple text-style flags for an option, how do I separate them? commas didn't work. [00:05:54 CET] <J_Darnley> Isn't it a system lib that will get auto detected? [00:06:07 CET] <qwertzsqwert> My laptop speakers are dead. Is there a way I can use ffmpeg to tap the playback device and set up an RTP stream? [00:06:24 CET] <J_Darnley> DHE: depends on the option I'm afraid, some take colons [00:06:41 CET] <DHE> that didn't work either [00:07:00 CET] <DHE> I'm using -hls_flags. I need multiple options. specifying -hls_flags multiple times seems to disable previous options [00:07:18 CET] <J_Darnley> oh, those flags might be + and - ones [00:07:52 CET] <J_Darnley> as in: -hls_flags +a+b+c-d-e-f [00:07:56 CET] <qwertzsqwert> J_Darnley: Jack is installed. libjack.so is present on the system. [00:08:10 CET] <DHE> J_Darnley: that did it... [00:08:10 CET] <J_Darnley> And the headers? [00:08:16 CET] <DHE> qwertzsqwert: and the -devel package? [00:08:23 CET] <DHE> J_Darnley: thx [00:08:33 CET] <J_Darnley> DHE: isn't the amount of different syntax here just amazing? [00:09:37 CET] <qwertzsqwert> DHE: Are you talking about *devel package for Jack or ffmpeg. I'm using Arch, neither packages have a devel build in the repo. [00:11:59 CET] <DHE> qwertzsqwert: on my system (centos 6) there's a package called jack-audio-connection-kit-devel [00:12:11 CET] <DHE> which you would need to build ffmpeg with JACK support [00:13:13 CET] <furq> i don't think arch uses -dev packages, the headers should come with the library itself [00:13:31 CET] <J_Darnley> neat! [00:13:49 CET] <J_Darnley> i made the right choice then [00:13:58 CET] <furq> what, to not use arch? [00:14:03 CET] <J_Darnley> no to use it [00:14:08 CET] <furq> oh [00:14:13 CET] <furq> you have my condolences [00:15:42 CET] <qwertzsqwert> DHE: these are the Jack specific packages in the Arch repo - https://ptpb.pw/cQO2. No devel releated. [00:16:08 CET] <qwertzsqwert> DHE: It's cool. It doesn't matter. [00:16:33 CET] <DHE> hmm.. interesting [00:16:57 CET] <J_Darnley> What does "ffmpeg -devices" list? [00:18:44 CET] <qwertzsqwert> J_Darnley: Already tried that. Nothing Jack is listed - https://ptpb.pw/JlMn [00:19:11 CET] <J_Darnley> Then it is time to stop fumbling in the dark. Please post the full output. [00:19:46 CET] <qwertzsqwert> Full output of ffmpeg -f jack -i ffmpeg -y out.wav ? [00:19:58 CET] <J_Darnley> That will do [00:20:18 CET] <furq> if you're using pulse then you can have that broadcast an rtp stream [00:20:45 CET] <furq> https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Net… [00:22:02 CET] <qwertzsqwert> J_Darnley: It's irrelevant. I explained above. I think the devs @ Arch haven't built ffmpeg with jack support, as durandal_170 mentioned. [00:22:08 CET] <J_Darnley> No it isn't [00:22:19 CET] <J_Darnley> oh that might be [00:22:21 CET] <qwertzsqwert> furq: I was hoping I wouldn't need to install PulseAudio. [00:22:27 CET] <J_Darnley> I thought you were compiling yourself [00:22:32 CET] <qwertzsqwert> Just a quit ffmpeg one liner. [00:23:17 CET] <qwertzsqwert> J_Darnley: I was going to, but having now pulled the source there's no mention of Jack in the ./configure --help [00:23:26 CET] <qwertzsqwert> For the switch. [00:23:29 CET] <J_Darnley> ./configure --list-indevs [00:23:45 CET] <J_Darnley> as I said [00:23:46 CET] <J_Darnley> [Sun 00:05] <J_Darnley> Isn't it a system lib that will get auto detected? [00:26:34 CET] <qwertzsqwert> I'm leaving it. Are you aware of a way to set up an RTP stream with ffmpeg for the default playback device? [00:26:54 CET] <J_Darnley> not me, sorry [00:27:36 CET] <qwertzsqwert> OK. [00:28:20 CET] <furq> https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplication [00:28:22 CET] <furq> there's that [00:28:29 CET] <furq> idk if that really does what you want though [00:37:43 CET] <qwertzsqwert> I'll give pulseaudio a look. [00:57:32 CET] <Interrogator> is there any ffmpeg app [ COMPILED ] with all known Libs : in a past session i got just the url of src code of ffmpeg ? [00:58:39 CET] <JEEB> no [00:58:49 CET] <JEEB> not to mention that that request is impossible from the get-go [00:58:56 CET] <JEEB> since some libraries are OS-specific [01:00:13 CET] <Interrogator> i understand thanks [01:01:14 CET] <JEEB> also generally the stuff you require is generally well known to you before :P (esp. since you get pretty much all the decoders in FFmpeg itself) [01:01:14 CET] <jkqxz> Also, were someone to make the most complete set possible for a given platform, the result would probably not be distributable at all due to conflicting licence requirements. [01:12:16 CET] <Interrogator> how to hide the console when using OR creating a ffmpeg UI ? [04:17:14 CET] <cortexman_> where can i find an example .raw file [04:26:31 CET] <cortexman_> which audio file is a list of floats? [04:26:34 CET] <cortexman_> *format [04:27:41 CET] <fahadash> How do I install mpeg4 codec? [04:40:12 CET] <fahadash> Encoder (coded mpeg4) not found for output stream #0:0 [04:40:21 CET] <fahadash> What does this mean? [04:40:47 CET] <fahadash> Trying to copy mpeg4 file as mkv [05:52:56 CET] <fahadash_> Here is my output, http://pastebin.com/n94pcuZk [05:53:06 CET] <fahadash_> I am trying to convert one format to the other [09:13:11 CET] <fengshaun> is it possible to have ffmpeg transcode a particular byte-range rather than time-range? [09:13:52 CET] <fengshaun> I'm trying to do on the fly transcoding while avoiding having to use libavcodec and libavformat directly [09:14:09 CET] <fengshaun> I can't find anything on this [12:52:44 CET] <PlanC> I'm using ffprobe to get info about a few MP3s [12:52:56 CET] <PlanC> one of the things I'm looking for is the bitrate [12:52:59 CET] <PlanC> but I'm seeing two bitrates [12:53:39 CET] <PlanC> one is in the duration line [12:53:52 CET] <PlanC> Duration: 00:01:11.26, start: 0.021057, bitrate: 132 kb/s [12:54:00 CET] <PlanC> the other is in the line below [12:54:06 CET] <PlanC> Stream #0:0: Audio: mp3, 44100 Hz, stereo, s16p, 128 kb/s [12:54:15 CET] <PlanC> one says 128 kb/s the other says 132 kb/s [12:54:22 CET] <PlanC> does anyone know which one is the right one? [12:58:04 CET] <__jack__> PlanC: what command line ? [13:00:01 CET] <jkqxz> PlanC: It depends what you want it for and how the file was encoded. The 132 is the total size of everything divided by the total time. The 128 is the intended bitrate of the encoded data, which need not be exactly correct if it was encoded with some form of variable bitrate. [13:00:35 CET] <__jack__> isn't it some overhead, due to the container or something ? [13:02:53 CET] <PlanC> jack: just "ffprobe $MP3_LOCATION" [13:03:13 CET] <PlanC> jkqxz: ah, that's a perfect explanation [13:03:14 CET] <PlanC> thanks [13:03:47 CET] <__jack__> PlanC: you may like ffprobe -show_streams -print_format json file.mp3, maybe more precise ? [13:08:19 CET] <jkqxz> The distinction between the two in ffprobe output is easier to see if you look at a file with both audio and video. It will tell you the total bitrate (total size / total time, including the container overhead), the audio bitrate, and the video bitrate separately. [13:10:55 CET] <PlanC> jack: ah, it's pretty useful to see it in JSON [13:11:01 CET] <PlanC> now I can just parse it with a script, thanks [14:28:39 CET] <TuxOholic> hello, ffmpeg 3.0 question: when I convert a video to vp8/webm I lose the metainfo tag "bitrate", ffprobe then shows "bitrate N/A" insead of the new bitrate in kbit/s ... how can I add it again? Is it possible to use -metadata bitrate="1024 kbit/s" ? [14:32:45 CET] <J_Darnley> Most formats don't explicitly store a bitrate anywhere [14:33:15 CET] <J_Darnley> While you could add arbitrary metadata it wouldn't be accurate ot shown whereever you want it. [14:35:13 CET] <TuxOholic> J_Darnley: I use vp8/cbr encoding, so could I set a bitrate value that is correct by average, right? [14:35:52 CET] <J_Darnley> No there is no guarantee the that encoder can get near what you ask [14:36:11 CET] <TuxOholic> true, but it is close enough [14:36:35 CET] <JEEB> the only way is to write the info after the fact by looking at how many bits were used for the whole clip's each stream. that way you get the abr for each of them [14:37:07 CET] <TuxOholic> that would be nice, can you point me to an example? [14:37:19 CET] <JEEB> nfi if ffmpeg can do it for you :P [14:37:33 CET] <BtbN> why do you care about the exact bitrate? Nothing needs it [14:37:54 CET] <JEEB> and if you just want the abr of the whole file with all tracks and container overhead, just use the file size and the length of the thing in seconds [14:37:56 CET] <BtbN> Even CBR mode doesn't strictly stick to a certain bitrate, so that info is pretty much useless anyway [14:38:37 CET] <JEEB> BtbN: if you are doing actual CBR (you need more than one parameter with most encoders since you don't generally want real CBR), then it should stick to such [14:39:01 CET] <JEEB> within some limitation of course depending on your VBV/HRD calculation blargh blargh [14:39:25 CET] <TuxOholic> all true, most meta info tools I use don't calculate the bitrate , they use the bitrate flag [14:41:13 CET] <JEEB> which is generally useless other than being "some value a user can see and feel happy even though it could be off by whatever" [14:41:29 CET] <TuxOholic> it' s all about getting a quick summary in konqueror file/info , so I can quickly see what video what frame rate [14:41:33 CET] <J_Darnley> How can a tool be so lazy? [14:41:41 CET] <J_Darnley> bitrate = filesize / length [14:41:49 CET] <JEEB> ^ this, for all tracks [14:41:58 CET] <JEEB> like, you get an overall bit rate [14:42:06 CET] <JEEB> not perfect for shit like mpeg-ts, but fuck it [14:42:08 CET] <JEEB> :D [14:42:20 CET] <JEEB> (things where you just don't have the length basically) [14:42:52 CET] <J_Darnley> Only shit-tier streaming formats suffer from that. [14:43:05 CET] <JEEB> and the one audio format that was picked without a container [14:43:10 CET] <JEEB> for whatever reason [14:43:20 CET] <J_Darnley> oh yes [14:43:40 CET] <JEEB> which is why most audio players actually play mp3 files in the background before showing the info on screen [14:43:58 CET] <JEEB> (you can do it N times realtime so they kind of get away with it) [14:44:25 CET] <JEEB> or at least I hope most players do that, har har - otherwise you are just going to have "fun" [14:45:01 CET] <JEEB> and of course seeking in such is fun as well unless you index it in some way [14:45:08 CET] <J_Darnley> I bet the xing header stores the length [14:45:20 CET] <JEEB> true that [14:45:47 CET] <J_Darnley> Just tack more data on. It'll fix everything(!) [14:45:56 CET] <JEEB> but it still never ceases to amaze me that something as unwieldly was decided to be The Thing for audio for so many years [14:46:14 CET] <J_Darnley> I guess it was good enough [14:47:17 CET] <JEEB> it was good enough for absolute CBR [14:47:30 CET] <JEEB> that way you got the length and seeking kind of right [14:47:41 CET] <JEEB> otherwise it was happy indexing time [14:47:52 CET] <JEEB> (or just playing from the beginning each time you seeked) [14:49:09 CET] <JEEB> also this reminds me that in 2016 mp3 in ISOBMFF (what we colloquially call "mp4", and which is a container) is still a point of discussion on mp4-sys [14:49:53 CET] <bencoh> :] [14:50:50 CET] <JEEB> http://up-cat.net/p/0bb3a4e6 [14:51:16 CET] <BtbN> JEEB, never seen libvpx do that. x264, yes. [14:51:34 CET] <JEEB> BtbN: yes, I was speaking on a general level [14:51:52 CET] <JEEB> libvpx rate control has sucked for years [14:52:57 CET] <TuxOholic> okay, it can't do it, that's fine with me ... I have another problem with the vidstabtransform and the deshake filter: they both are not working enough on my dash cam recordings ... can I upload a sample somewhere and show you the results? [15:00:20 CET] <JEEB> that sounds like a case of the default parameters not working for you [15:00:44 CET] <JEEB> welcome to the wonderful world of poking at some switches that look like they might do something for you [15:01:10 CET] <JEEB> https://www.ffmpeg.org/ffmpeg-all.html#vidstabtransform-1 [15:01:23 CET] <JEEB> and https://www.ffmpeg.org/ffmpeg-all.html#deshake [15:01:28 CET] <JEEB> glhf [15:04:06 CET] <TuxOholic> JEEB: I've been through most of these parameters (zoom/optzoom in particular) and the did not help much [15:04:55 CET] <JEEB> also for debugging why something doesn't work too well the output is often much less useful than your input [15:07:06 CET] <JEEB> you might possibly be helped by making an issue with the source @ the trac, but it could just be that the filters are just bad with whatever you're throwing at them [15:08:53 CET] <TuxOholic> i've seen several youtube videos where it worked quite okay, but my dash cam videos just don't improve in the same way [15:09:58 CET] <JEEB> how do you know that those videos went through the same filter chain? [15:09:58 CET] <TuxOholic> I might try filing a mailing list question after I've uploaded a sample to upload.ffmpeg.org [15:11:07 CET] <TuxOholic> I havw two videos before/after > downloaded before and followed the OP's recommended parameters and I got good results similiar with them th OP has got [15:11:20 CET] <JEEB> ok [15:12:17 CET] <TuxOholic> okay thank you , bye ... [15:21:18 CET] <ghartz> hi [15:35:43 CET] <ghartz> since version 3, I can't anymore use "http source file" as input for the concat protocol [15:36:07 CET] <ghartz> the following error is pop-up: Protocol not on whitelist 'concat,file,subfile'! [15:36:09 CET] <dystopia_> yeah lots of things broke in v3 :| [15:36:13 CET] <ghartz> :( [15:36:32 CET] <dystopia_> im using old versioin for http stuff, and v3 for encoding [15:36:47 CET] <ghartz> I was able to "-i "concat:http://<my url>|http://<url2..>" [15:37:25 CET] <ghartz> dystopia_, there are doing something about that or they don't care ? [15:37:47 CET] <ghartz> using "http" as source file is not really an exotic usecase [15:41:20 CET] <durandal_1707> because it is security issue, set whitelist [15:41:45 CET] <ghartz> I tried but don't understand which value I should set [15:42:00 CET] <durandal_1707> its selfrevelating if you have enough IQ [15:42:06 CET] <ghartz> .... [15:42:12 CET] <ghartz> really ? [15:43:27 CET] <durandal_1707> -protocol_whitelist [15:43:31 CET] <ghartz> yep [15:44:15 CET] <ghartz> I already found this argument but when I set to -protocol_whitelist http still not working [17:01:44 CET] <durandal_1707> ghartz: you need to add all protocols nit just one [17:04:48 CET] <ghartz> durandal_1707, "all" is not working, nor "concat,http"... I ended up by comment the line https://github.com/FFmpeg/FFmpeg/blob/fe3fed0b143ef6bf2d9b65ce05d55aba42244… [17:04:54 CET] <ghartz> and it's working fine.. [21:05:50 CET] <Fyr> guys, has anybody compared quality of ffmpeg AAC and Fraunhofer AAC? [21:06:04 CET] <Fyr> or QAAC? [21:06:44 CET] <Mavrik> I think there are some graphs in the ticket [21:06:55 CET] <Mavrik> FDK is still better in quite a few cases. [21:07:03 CET] <Fyr> oh [21:08:06 CET] <JEEB> Mavrik: the general consensus with the latest master is that you might as well use ffaac for LC-AAC and fdk-aac in case of HE-AAC needs [21:08:16 CET] <Mavrik> mhm [21:08:46 CET] <JEEB> of course if you've already got systems in production with fdk-aac it's not something you have to change right away [21:09:07 CET] <JEEB> just that if you're setting up new things you might not need fdk-aac for LC-AAC any more [00:00:00 CET] --- Mon Feb 22 2016

1 0

ffmpeg-devel.log.20160220
by burek 21 Feb '16

21 Feb '16

[00:30:39 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:e6cbe3ffef8b: configure: Fix webm_dash_manifest demuxer standalone compilation. [01:44:11 CET] <michaelni> nevcairiel, kfreebsd should be fixed [02:57:19 CET] <cone-088> ffmpeg 03Mark Harris 07master:1b4fbf808082: avformat/icodec: ico probe with unknown data [02:57:20 CET] <cone-088> ffmpeg 03Mark Harris 07master:56e2cd9c042e: avformat/icodec: Fix crash probing fuzzed file [04:59:53 CET] <llogan> kierank: just in case nobody else mentioned it, and if you're up at this hour, trac is down. [05:00:18 CET] <llogan> i would restart stuff myself, but i am unable to connect [05:01:56 CET] <michaelni> llogan, what happened? [05:02:07 CET] <llogan> unknown [05:02:22 CET] <llogan> i can ping the machine but that's it. [05:02:49 CET] <michaelni> if trac is down when google looks at our ideas page then we are disqualified [05:02:55 CET] <michaelni> for gsoc [05:03:15 CET] <llogan> when will they look at it? [05:04:04 CET] <michaelni> 20-26 IIUC [05:04:55 CET] <llogan> would they really be that dismissive if the server is down? [05:05:07 CET] <michaelni> yes [05:05:50 CET] <llogan> i suppose we can make a copy on multimedia.cx and inform them of the new address. [05:06:20 CET] <llogan> or request that they look after tomorrow [05:06:28 CET] <michaelni> if you can make a copy somewhere, it surely doesnt hurt to make one [05:09:13 CET] Action: Compn tries fixing wikipedia article again [05:09:34 CET] Action: llogan tried to remember stupid password [05:09:44 CET] <llogan> ..and username [05:09:52 CET] <Compn> why bother just make another or edit without name [05:10:31 CET] <llogan> lol. "unknown error in PHP's mail() function" [07:59:14 CET] <kierank> Works here [09:49:49 CET] <michaelni> kierank, check mail, its possibly a failing disk [09:57:03 CET] <michaelni> anyway, ill go back to bed, just woke up and checked IRC, trac seems working currently [11:17:17 CET] <wm4> claws' shitty behavior is getting unacceptable, what should I do... [11:18:06 CET] <wm4> like it decides to redownload 40000 mail headers instead of letting me read mails [11:23:23 CET] <flux> seems like you have three options: 1) file a bug report 2) fix it yourself 3) switch programs :-). [11:25:50 CET] <wm4> 1 does nothing, 2 would likely require rewriting the thing or they would have fixed it after all these years [11:27:11 CET] <flux> there's also a fourth option, split your 40k mails into multiple folders :) [13:18:39 CET] <BBB> wm4: Im not sure I understand your comment [13:18:52 CET] <BBB> wm4: are you suggesting zero-sized packets *are* a good way to signal skips, or not? [13:19:07 CET] <wm4> that they're not [13:19:18 CET] <BBB> ok, so, how shall I do it then? [13:19:29 CET] <wm4> well I guess everything is ok if the decoder explicitly handles this [13:19:35 CET] <wm4> and can't confuse it with an actual flush [13:19:36 CET] <BBB> its for muxing [13:19:41 CET] <wm4> oh [13:19:46 CET] <BBB> so decoders arent part of it [13:19:49 CET] <wm4> then nevermind, it probably doesn't apply there [13:19:53 CET] <BBB> its the interaction between an app and the muxer [13:20:12 CET] <BBB> app says heres a packet and the bsf says hold on a moment, dont write this yet [13:20:16 CET] <BBB> Id like a way to do that [13:20:25 CET] <BBB> maybe I should just redesign BSFs [13:20:45 CET] <BBB> their current API is kind of pathetic [13:21:16 CET] <BBB> (parsers arent any better btw) [13:21:19 CET] <wm4> so does the bsf want to output another packet? [13:21:24 CET] <wm4> or just not output a packet yet [13:21:34 CET] <wm4> i.e. do 2 input packets become 1 output, or the other way around [13:21:37 CET] <BBB> this particular BSF wants to merge two packet into 1 [13:21:43 CET] <wm4> ok [13:22:14 CET] <BBB> but we have no way for a call to BSF.filter() to signal that there should be no further actual output to the muxer [13:22:25 CET] <wm4> in theory you could have a flag in AVBitStreamFilterContext for compatibility... [13:22:33 CET] <BBB> and to make matters worse, ffmpeg.c has all kind of hacks around it also :( [13:22:52 CET] <wm4> sure sucks [13:22:59 CET] <wm4> we should converzt everything to gstreamer [13:23:15 CET] <wm4> s/gstreamer/lavfi/ [13:23:30 CET] <wm4> (a clean API would literally work like a filter) [13:23:49 CET] <BBB> push or pull? [13:24:49 CET] <wm4> state machine [13:25:16 CET] <wm4> feed input until it outputs something, then read output until it needs input again [14:49:30 CET] <pengvado> ubitux: every pixel depend on the previous. but png operates on packed rgba. 4 colorplanes is enough to fill an mmxreg. [14:50:59 CET] <cone-327> ffmpeg 03Rostislav Pehlivanov 07master:029c069c6d98: vc2enc: add support for Haar wavelet transforms [15:38:09 CET] <jya> quick question. after upgrading to FFmpeg 3.0; For the DTS decoder, rather than getting FLTP format, I get S32P with bits_per_sample = 24. Does that make that a S24P and is that LSB or MSB? the weird thing is that regardless of that, the value returned for each decoded sample is > 2^24 [15:43:39 CET] <kierank> 8 bits of lsb padding [15:43:57 CET] <kierank> the opposite to video but I guess that's the convention in audio [15:44:32 CET] <jya> ok so sample >> 8 [15:44:39 CET] <kierank> Yes [15:45:11 CET] <jya> hmmmm... so code was correct... i still get something very noisy. [15:45:44 CET] <jya> i can distinguish dialog etc... but there's lot of whitish noise over it [15:45:59 CET] <nevcairiel> it might be different if we actually had a S24P format, but since its all in S32P we have to have the audio in the msb otherwise it would be super quiet when using "naive" logic (ie. ignoring bits_per_sample) [15:46:57 CET] <J_Darnley> suddenly it makes a little sense. [15:47:02 CET] <jya> the 8 bits aren't 0 in there, not sure if that indicates that something else is happening with those samples [15:51:51 CET] <BBB> jya: why not just convert it to fltp with libswresample? [15:52:05 CET] <BBB> jya: or do you want to send s24p straight to the soundcard? [15:53:13 CET] <jya> BBB: I'm resyncing FFmpeg on mythtv; there we check what the audio card support and request libavcodec so that there's minimum amount of conversion occurring [15:53:43 CET] <BBB> aha ok [15:54:17 CET] <jya> since resyncing to 3.0, my DTS sample sound crap, the only difference I can see is that in 2.8, I used to get FLTP, and now I get S32P with bits_per_raw_sample = 24 [15:54:43 CET] <BBB> and if you read it as s32p and ignore bits_per_raw_sample? [15:54:45 CET] <BBB> does it work then? [15:54:50 CET] <BBB> (so as if it were 32 bit) [15:55:09 CET] <jya> even when I request fltp, I still get S32P out with this decoder (I'm testing on mac, which support fltp so I would prefer fltp) [15:55:21 CET] <BBB> typically decoders only output one format [15:55:25 CET] <jya> that's the first thing I tried, but it still sound crap [15:55:28 CET] <BBB> conversion is in libswresample [15:55:35 CET] <BBB> ok, I dont know then I guess, sorry :( [15:56:09 CET] <jya> sample_fmts for the dcadec was updated and in 2.8 had fltp only, now it has S16P, S32P and FLTP [15:56:38 CET] <jya> seems to always set avctx->sample_fmt = AV_SAMPLE_FMT_S32P; in the init [15:56:50 CET] <nevcairiel> the output depends on the type of dts file [15:56:59 CET] <nevcairiel> it doesnt honor any requests, it gives you what the file contains [15:57:29 CET] <jya> nevcairiel: I was definitely getting fltp with the previous dcadec [15:57:50 CET] <nevcairiel> thats irrelevant, the decoder was entirely replaced with a new one [15:58:01 CET] <jya> nevcairiel: hmmmmm ffprobe gives me Audio: dts (DTS), 48000 Hz, 5.1(side), fltp, 1536 kb/s (default) [15:58:33 CET] <jya> so maybe it is fltp, and AVCodecContext incorrectly states S32P [15:58:45 CET] <jya> it's 2AM it doesn't help me seeing things clearly [16:00:54 CET] <nevcairiel> I use the decoder myself, I'm quite sure it works correctly [16:01:14 CET] <jya> ok.. that's good to know... [16:01:17 CET] <nevcairiel> you arent reading the sample_fmt once and then never looking at it again, are you? because it can and will change [16:01:43 CET] <wm4> ideally you'd only ever look at AVFrame.format [16:02:02 CET] <nevcairiel> as you noted, it always inits to s32p, but thats really only because it has no clue what kind of format its going to be [16:02:09 CET] <nevcairiel> so it could be s32p, s16p or fltp [16:02:49 CET] <jya> ok.. if I force it as FLTP now it plays fine... [16:03:00 CET] <jya> hmmm what's going on [16:03:08 CET] <JEEB> sounds like you're reading the uninitialized value [16:03:18 CET] <JEEB> or well, initial initialization [16:03:22 CET] <JEEB> before actual decoding [16:03:31 CET] <JEEB> as opposed to the decoded avframe [16:04:26 CET] <jya> that's old mythtv code, it has a special callback when the format changes... it may not be called (and that indicate I screwed my resync). mythtv maintains its own fork . mostly because of the mpegts demuxer [16:08:29 CET] <jya> would need to one day propose all the mythtv changes back to ffmpeg; lots of support for extra type of subtitles, dsmc etc [16:09:27 CET] <nevcairiel> usually such projects have rather hacky changes, ie. it work for their use case (tv) but may have problems with other stuff, of course maybe mythtv is different =p [16:10:24 CET] <jya> it's certainly is hacky :) [16:10:45 CET] <jya> we had to handle change of stream content well before ffmpeg had something [16:10:59 CET] <wm4> I never understood the need for private ffmpeg forks [16:12:07 CET] <jya> wm4: IIRC (though I joined the mythtv project only circa 2008). most of the changes myth did to support change of stream, subtitles etc.. always got knocked back when they tried to submit the changes upstream [16:12:11 CET] <jya> in the end they gave up [16:12:35 CET] <nevcairiel> being able to hack together some quick solution without having to worry about it working everywhere is attractive for many =p [16:14:17 CET] <jya> the project is slowly dying unfortuantely, not many devs left... reworking the stream change to work with the proper ffmpeg API would require a big change... no one is willing to spend the time on it [16:16:53 CET] <jya> nevcairiel: the AVFrame.format after decoding is 8 which appears to be AV_SAMPLE_FMT_S32P [16:17:02 CET] <jya> so no FLTP there either [16:17:35 CET] <nevcairiel> 8 is FLTP [16:18:03 CET] <nevcairiel> S32P is 7 [16:18:14 CET] <jya> ah yeah, I was off by one :) [16:19:51 CET] <jya> allright, will look into it tomorrow ... thank you for your help... it does look like it's not detecting the change of stream. That or the previous decoder returned FLTP right after setup, so we initialised the audio output properly [16:32:52 CET] <jya> allright, got it to work... we monitor the AVCodecContext format change, that seems to happen after we decode a return the first frame. So the first sample looks bad, fine after that. [16:33:53 CET] <wm4> huh? [16:34:01 CET] <wm4> so just wrong order of operation? [16:35:17 CET] <jya> wm4: one day I'll update for the new API, for now it's just being kept alive :) [17:06:45 CET] <atomnuker> the asm framework doesn't make much sense to me right now [17:06:49 CET] <atomnuker> cglobal ssd_int8_vs_int16, 3, 3, 3, pix1, pix2, size [17:07:02 CET] <atomnuker> so the function takes 3 arguments, uses 3 registers [17:07:11 CET] <atomnuker> but what's the thrid '3' for? [17:07:28 CET] <nevcairiel> 3 simd regs [17:07:33 CET] <nevcairiel> gprs and simd are separate [17:08:36 CET] <atomnuker> huh, odd, the function only uses eax [17:09:24 CET] <atomnuker> also at the end it does INIT_MMX mmx SSD_INT8_VS_INT16 INIT_XMM sse2 SSD_INT8_VS_INT16 [17:09:36 CET] <atomnuker> so it defines 2 functions for sse2 and mmx [17:09:52 CET] <atomnuker> but it still only uses mmx (mm#) registers [17:10:15 CET] <nevcairiel> first things first, it only uses eax explicitly for the return value [17:10:27 CET] <nevcairiel> all other regs are hidden behind symbolic names from the parameters [17:10:32 CET] <nevcairiel> pix1, pix2 and size [17:10:38 CET] <nevcairiel> pix1q, sizeq in the code [17:10:44 CET] <nevcairiel> q is the size of the register to access [17:11:26 CET] <atomnuker> so the numer of general purpose registers needs to be at least the # of arguments [17:11:40 CET] <nevcairiel> not necessarily, you can also access arguments from stack [17:11:46 CET] <nevcairiel> but if you have enough gprs, sure [17:12:22 CET] <nevcairiel> then, m# is the syntax to access the native simd register type depending on which init function you called [17:12:27 CET] <nevcairiel> mm# would be for mmx explicitly [17:12:33 CET] <nevcairiel> so with INIT_MMX m# [17:12:38 CET] <nevcairiel> so with INIT_MMX m# expands to mm# [17:12:44 CET] <nevcairiel> with INIT_XMM it expands to xmm# [17:13:01 CET] <nevcairiel> so you can declare mmx/sse variants without much duplication [17:13:32 CET] <nevcairiel> its a lot of macro magic :) [17:25:32 CET] <atomnuker> why does yasm prevent me from doing vmovdqa [dataq+(locq*32)], ymm1 ? [17:25:40 CET] <atomnuker> dataq+locq works [17:27:15 CET] <kierank> stop using that notation as nevcairiel says [17:27:22 CET] <kierank> use mova and mm1 [17:27:32 CET] <kierank> the macros do all of this for you [17:29:01 CET] <atomnuker> ...he did not say anything about not using that notation [17:29:24 CET] <kierank> 4:12 PM <"nevcairiel> then, m# is the syntax to access the native simd register type depending on which init function you called [17:29:24 CET] <kierank> 4:12 PM <"nevcairiel> mm# would be for mmx explicitly [17:29:42 CET] <kierank> obviously I mean m1* [17:29:50 CET] <atomnuker> so how am I supposed to access a pointer? [17:30:58 CET] <kierank> mova [dstq], m0 or whatever [17:38:13 CET] <jkqxz> The offset multipler in a load like that is limited to 1, 2, 4, or 8 because of the encoding, anyway. [19:00:11 CET] <nevcairiel> Frame-reordering in H.264 can never go beyond GOP boundaries, right? Even in Open-GOP, it could only reference an earlier frame, but not cause anything to re-order beyond the boundary? [19:09:38 CET] <kierank> nevcairiel: I think no [19:19:17 CET] <jkqxz> Why not? It's not like GOPs are actually a thing in H.264 - the only real restriction is that you can't reorder too far, and MMCOs let referencing be completely arbitrary. [19:20:40 CET] <nevcairiel> well the video type this really concerns are all blu-ray compatible encoded, where this is luckily all a bit stricter [19:21:45 CET] <kierank> blu-ray has weird open-gop [19:23:24 CET] <nevcairiel> initial tests show that my logic should be fine [19:23:34 CET] <nevcairiel> lets finish this and run it through more samples [19:32:11 CET] <jamrial> fuck integer 32bit scalarproduct where the result is 64bits [20:28:11 CET] <pengvado> nevcairiel: h264 can't reorder across an IDR-frame (and you would never want to either). however, in open-GOP it actually has no concept of GOPs at all, and can reorder across I-frames. [20:29:25 CET] <JEEB> so in theory you could have a sync point sei and then an I-picture + things that in theory could be reordered on both sides of that I-picture? [20:29:50 CET] <JEEB> (not sure I got the name of the SEI correctly) [20:30:03 CET] <pengvado> yes [20:30:08 CET] <JEEB> ok [20:40:23 CET] <jkqxz> H.265 makes some of this relationship explicit. In particular, RASL frames are specifically those that cause trouble in the case you stated: they follow an I-frame (CRA or whatever) in decoding order but precede it in display order, and also depend on something before the I-frame in decoding order. [20:43:13 CET] <jkqxz> (RASL being the NAL unit type, so you can skip it immediately in the seeking case. For the same case in H.264 you need to decode more to work out that you won't be able to use it.) [21:10:51 CET] <ubitux> wm4: flags2 +sub_ass_reset_readorder_on_flush sounds good to you? [21:11:51 CET] <ubitux> pengvado: ok so just parallelizing color planes, thx [21:15:43 CET] <ubitux> wm4: actually, i'll swap the logic of the flag meaning so it doesn't have to be set by default (i'm afraid of ppl resetting flags2 without honoring its current/default value) [21:17:40 CET] <ubitux> will go for flags2 +ass_ro_flush_noop -> do not reset ASS ReadOrder field on flush [21:18:35 CET] <wm4> ubitux: sounds good [21:18:48 CET] <wm4> (what does "ro" mean?) [21:18:52 CET] <ubitux> readorder :( [21:18:58 CET] <wm4> lol ok [21:19:31 CET] <wm4> btw. a new libass with API to disable the RO check was just released [21:19:42 CET] <wm4> or at least will be released shortly [21:21:54 CET] <ubitux> ah [22:57:19 CET] Action: ubitux just realized our subrip encoder is producing fucking ass alignment tags [22:57:29 CET] <ubitux> no nononooo nuifufufewwde12d1 [22:57:35 CET] <JEEB> \o/ [22:57:47 CET] <ubitux> on fucking purpose moreover [22:57:59 CET] <ubitux> srt_print(s, "{\\an%d}", alignment); [22:59:41 CET] <wm4> lol [23:00:12 CET] <wm4> well there are people who put microdvd tags into srt [23:01:16 CET] <ubitux> anyway, i'm finally getting the timing fix as a nice side effect of the patchset [23:09:24 CET] <ubitux> last steps: test zvbi, document, and deprecate the whole timing thing. [23:09:34 CET] <ubitux> such an adventure.. [23:10:18 CET] <wm4> how is zvbi different here? [23:13:35 CET] <kierank> Zvbi is a bit "special" [23:13:53 CET] <kierank> It's a crazy library in many ways [23:14:15 CET] <wm4> it's part of the big club, huh [23:17:02 CET] <llogan> kierank: looks like trac is down again. are you still working on it? [23:17:06 CET] <ubitux> wm4: zvbi isn't covered by fate (it's a lib, we can't test the wrapper because of this), it's crafting sub events itself in the AVSubtitle and doing weird shit wrt timings, ...\ [23:17:23 CET] <ubitux> it also has a text and bitmap mode [23:18:02 CET] <kierank> llogan: no [23:18:21 CET] <ubitux> i'd love to get rid of it tbh [23:18:22 CET] <kierank> Works for me [23:19:48 CET] <llogan> now it's working here too, but it must have been down for at least 5-15 mins because i got an alert [23:19:55 CET] <ubitux> wm4: i see a bunch of mplayer commits... you're still monitoring its activity? most of it probably don't apply to mpv anymore though [23:20:32 CET] <wm4> mplayer commits usually affect code that is either removed or rewritten in mpv [23:21:00 CET] <ubitux> yeah, not a surprise, but i saw a sudden peak of activity [23:21:03 CET] <ubitux> so just wondering [23:21:33 CET] <rcombs> ubitux: oh, the timing fix as in that one from the ML a while back with SRT timestamps getting rounded off? [23:21:45 CET] <ubitux> rcombs: yes [23:21:47 CET] <ubitux> it's fixed [23:21:52 CET] <rcombs> cool [23:22:05 CET] <kierank> llogan: ah that was me [23:23:27 CET] <ubitux> rcombs: https://github.com/ubitux/FFmpeg/compare/ass-2016 [23:23:32 CET] <ubitux> see fate changes [23:23:46 CET] <ubitux> (yes cc are still "broken") [23:24:23 CET] <llogan> kierank: would you like me to add your email and/or mobile to CC for the alerts regarding trac.ffmpeg.org? they would come from the stupidly named "statuscake" service. [23:24:30 CET] <rcombs> ubitux: cool [23:25:09 CET] <rcombs> ubitux: btw, are you up for a sample showing some caption_dec issue [23:25:32 CET] <ubitux> mmh, you'd better ask tmm1 for a fix, but i'm curious about the issue [23:25:36 CET] <ubitux> :) [23:25:43 CET] Action: rcombs finds link [23:25:59 CET] <kierank> llogan: yes [23:26:09 CET] <kierank> I have an alert too possibly using the same site [23:29:54 CET] <rcombs> ubitux: http://puu.sh/nfl6E/4fcc73d8cf.wtv [23:32:15 CET] <ubitux> what's the issue? [23:32:37 CET] <ubitux> ffmpeg finds 3 events for this [23:33:40 CET] <ubitux> and part of the 4th [23:34:23 CET] <ubitux> (trying ffmpeg -f lavfi -i "movie=4fcc73d8cf.wtv[out0+subcc]" -f ass -) [00:00:00 CET] --- Sun Feb 21 2016

1 0

ffmpeg.log.20160220
by burek 21 Feb '16

21 Feb '16

[00:07:16 CET] <J_Darnley> If you aren't scaling it then it is still 720p [00:07:54 CET] <J_Darnley> Low quality and a lack of details can make it look worse than you might want. [00:08:28 CET] <J_Darnley> You can either spend more bits to preserve quality or spend more time encoding. [00:30:34 CET] <harej> J_Darnley: I would be happy to do that; just not sure how if I am already setting the CRF to 0 [00:34:04 CET] <J_Darnley> Increase cpu-used perhaps [00:34:20 CET] <J_Darnley> Otherwise find some help for libvpx [00:34:33 CET] <J_Darnley> I don't know what options it has. [00:37:50 CET] <harej> Wouldn't increasing cpu-used just make it go faster? Or does it refer to something else? Anyways, will check out the libvpx docs. (Now I know to check that out specifically; was fruitlessly looking at ffmpeg docs earlier.) [00:39:55 CET] <furq> harej: http://www.webmproject.org/docs/encoder-parameters/#2-encode-quality-vs-spe… [00:40:22 CET] <harej> Thank you; will look at that after dinner [00:40:54 CET] <TD-Linux> harej, "weird color splotches" sounds like some other problem. what player are you using? [00:41:36 CET] <TD-Linux> also -crf 0 -b:v 7M will mean that you're basically always limited to 7Mb/s [00:41:45 CET] <TD-Linux> also did you switch to libvpx-vp9 or not? [00:48:33 CET] <furq> the same crf value with 10-bit x264 should be higher quality than with 8-bit, right [00:49:23 CET] <furq> is the equivalent value just 8-bit-crf * (63/51) or is there more of an art to it than that [00:50:57 CET] <J_Darnley> x264 adjusts internally for the bitdepth [00:51:30 CET] <J_Darnley> I recall that crf can go negative for 8 and 10 bits [00:52:12 CET] <J_Darnley> After the high depth was added but before the adjustment files were coming out massively larger than 8 bit. [00:52:27 CET] <furq> i'm guessing there isn't really a fixed equivalent crf [00:53:00 CET] <J_Darnley> crf was supposed to be The One True Quality Knob(TM) [00:53:24 CET] <J_Darnley> it tries to be but can come up short in some cases [00:54:13 CET] <Plorkyeran_> crf initially could go negative for 10-bit, but then it was rescaled so that 0 would be lossless [00:54:16 CET] <J_Darnley> The recommendation was to stick with the same value when using higher depth [00:54:19 CET] <Plorkyeran_> like with 8-bit [00:54:24 CET] <furq> increasing by 2 for 10-bit is working pretty well anyway [00:55:33 CET] <furq> plus it helps compensate for the reduced speed [03:24:56 CET] <rajkosto> how do i tell the h264 decoder (using from C lib) that the packets are not annexb (it seems to be forever waiting for startcode) [03:30:15 CET] <rajkosto> i have a=fmtp:97 profile-level-id=640020; packetization-mode=1; sprop-parameter-sets=z2qaikwrqcgc3yc1aq0bqaaa+gaadtayaaajiwaabszdu8ud44zu,ao48sa== it seems i need to dump that into extradata somehow [03:35:40 CET] <rajkosto> ill try doing what sdp_parse_fmtp_config_h264 does [06:30:15 CET] <adc> I'm building a small script that adds a sound at a list of specified points in a sound file - I have the basic functionality done, by looping over this command: http://pastebin.com/m6TLauek (and output). I'm running into an issue with the placement of the sound, with a slight drift per sound; after adding a few hundred (or thousand) sounds to the file it's drifted by close to a full second or more, which makes the output unusable. [06:30:27 CET] <adc> Is there any way to make ffmpeg more precise in terms of sound placement? [08:32:58 CET] <durandal_170> adc: delay is in double, so use decimal [08:33:32 CET] <adc> Can you give me an example of format? [08:34:22 CET] <adc> Not sure what you mean by "decimal". What unit is 1? Seconds? [08:35:59 CET] <durandal_170> 1000 of second [08:37:02 CET] <adc> Documentation claims my use is correct (for a delay of 250 milliseconds). Could you give me an example? [19:56:05 CET] <rajkosto> i must be doing somethign wrong with this decode [19:56:28 CET] <rajkosto> it says every frame has all the MV errors in ? type frame [19:56:38 CET] <rajkosto> and it uses a LOT of cpu to decode [19:57:45 CET] <rajkosto> (so much that it can barely keep up with 720p30 on this monster machine (granted it is using only one core) [20:00:58 CET] <jkqxz> Your decode must be mostly right to get that far. [20:01:54 CET] <jkqxz> Where is the stream coming from? Could it be corrupted somehow (having gone over an unreliable channel), or otherwise somehow incomplete (truncated, say)? [20:05:44 CET] <malenki> hi [20:06:15 CET] <malenki> why can ffprobe tell me the bitrate of an opus audio file bot not the bitrate of an opus audio stream of a video? [20:06:40 CET] <DHE> when there's just 1 stream it's easier to measure than when there's 2 [20:06:59 CET] <malenki> or better: how can i know the bitrate of an opus audio stream inside a video? [20:07:45 CET] <BtbN> extract the whole stream, divide size by runtime [20:14:42 CET] <rajkosto> jkqxz, it was because i compiled my own ffmpeg with toolchain=msvc [20:14:49 CET] <rajkosto> (so i could have pdbs and stuff while developing) [20:15:05 CET] <rajkosto> using zeranoe dlls cpu usage is normal and no errors [20:15:59 CET] <BtbN> so you built without yasm or something like that? [20:16:04 CET] <rajkosto> nope it used yasm [20:16:07 CET] <rajkosto> i saw it during make [20:17:57 CET] <rajkosto> i assume the cpu usage was because it thought all the MVs had errors so was trying to conceal [20:41:22 CET] <rajkosto> jkqxz, now i tried a stream that uses intra refresh, and it took like a full minute or so for it to give me a frame [20:41:52 CET] <rajkosto> is there something i need to pass for it to recognize intra refresh sequence points ? [20:42:23 CET] <JEEB> you must have a really long refresh period [20:42:38 CET] <rajkosto> i dont know how to set it [20:42:41 CET] <rajkosto> i did keyint=3 [20:42:43 CET] <rajkosto> 30 [20:45:05 CET] <rajkosto> is there a way to set it so i get garbled mess anyway? instead of waiting for something [20:45:33 CET] <JEEB> there's IIRC a parameter that would output broken pictures, yes [20:45:46 CET] <JEEB> "Disables IDR-frames, instead x264 uses intra coding for each macroblock in the frame every --keyint frames. Blocks are refreshed in a horizontally scrolling column - the 'refresh wave'. This benefits low-latency streaming by making it possible to achieve more constant frame sizes than is possible with standard IDR-frames. It also increases the resilience of the video stream to packet loss. This option does r [20:45:52 CET] <JEEB> educe compression efficiency, hence only use it when needed." [20:46:03 CET] <JEEB> hmm, not sure how to read that [20:46:18 CET] <rajkosto> it should output a SEI that says how many frames after it you need to decode to get a full frame [20:46:27 CET] <JEEB> umm [20:47:39 CET] <jkqxz> Is the source a whole stream beginning with an IDR frame, or is the point here that you are turning up randomly in the middle of the stream and then waiting until a whole picture is present that you can decode? [20:47:47 CET] <rajkosto> its a rtp stream [20:47:51 CET] <rajkosto> so random in the middle [20:48:06 CET] <rajkosto> with non intra refresh its about a second or two, consistent with my keyint [20:48:11 CET] <rajkosto> with intra refresh its forever [20:48:19 CET] <jkqxz> From multicast or whatever, so you can't send an RTCP intra refresh request? [20:48:30 CET] <rajkosto> yes its onetomany [20:48:49 CET] <JEEB> trying to see how exactly intra refresh works with x264 [20:49:00 CET] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=cde39046222b112261179144033e… is the commit that added it [20:49:50 CET] <JEEB> so in theory if you have keyint=30 then it should refresh in 30 pictures if I understand correctly [20:49:56 CET] <JEEB> and after that you should have correct image [20:50:59 CET] <rajkosto> also, if i have the SPS,PPS, and stuff in extradata of AvCodecContext i shouldnt have to use the mp4toannexb filter, right ? [20:51:30 CET] <JEEB> mp4toannexb filter is only required if you need to convert from that type to another type [20:51:40 CET] <JEEB> I mean, AVCc to Annex B [20:51:55 CET] <jkqxz> RTP streams are just NAL units, once you've reassembled the fragmentation units and whatnot. You need to add the start code, but nothing else. [20:52:21 CET] <rajkosto> rtp is headerless, so i add length header because my extradata is avcc format [20:53:51 CET] <rajkosto> nvm, it seems it all works [20:54:01 CET] <JEEB> ok, so the sei recovery point just contains your "h->param.i_keyint_max = X264_MIN( h->param.i_keyint_max, (h->param.i_width+15)/16 - 1 );" [20:54:29 CET] <JEEB> which should be 30 pictures if your keyint is set correctly [20:54:54 CET] <rajkosto> yeah its fine i bungled something [21:23:02 CET] <adc> I'm building a small script that adds a sound at a list of specified points in a sound file - I have the basic functionality done, by looping over this command: http://pastebin.com/m6TLauek. I'm running into an issue with the placement of the sound, with each sound drifting a bit; after adding a few hundred (or thousand) sounds to the file it's drifted by close to a full second or more, which makes the output unusable. Is there any way t [21:25:26 CET] <adc> Also, would there be any faster way to do what I want to do? As it is it takes over an hour for a 50~ minute long file because it has to decode and re-encode each time it adds a sound, but I can't figure out a way to add the same sound multiple times in one pass. [21:30:23 CET] <J_Darnley> Render your additions into one continuous audio stream and then mix that once? [21:31:39 CET] <adc> I can't figure out how to do that - as far as I can tell, it's not possible to use the same input twice in one statement? [21:32:25 CET] <J_Darnley> There's the split filter(s) [21:32:44 CET] <J_Darnley> but I probably wouldn't do that with ffmpeg anyway. [21:33:17 CET] <adc> I'm open to suggestions [21:34:03 CET] <J_Darnley> Well I don't know what exactly what you're doing [21:34:28 CET] <J_Darnley> For a few "randomly" placed sounds I would probably use audacity [21:34:40 CET] <adc> I'm adding game sounds to a TAS I built [21:35:08 CET] <adc> Doing it manually isn't really an option, since there are thousands of individual sounds to add [21:35:09 CET] <J_Darnley> For many regularly occuring sounds I would have a script conat sounds and silence as I needed. [21:35:30 CET] <J_Darnley> How do you know when they occur? [21:36:06 CET] <adc> I had the game output a time-since-game-start (in milliseconds) each time a sound played. [21:36:17 CET] <J_Darnley> ah [21:37:20 CET] <J_Darnley> asplit won't help you much there either. [21:37:39 CET] <J_Darnley> You would be "splitting" thousands of times. [21:38:41 CET] <J_Darnley> I would either cobble something outside ffmpeg or write a really ugly filter to do it inside ffmpeg. [21:39:36 CET] <adc> Like I said, I'm open to suggestions but I couldn't find any other way to do it while searching for a solution [21:41:02 CET] <J_Darnley> Sorry, I don't have anything better than that. [21:41:29 CET] <J_Darnley> Although you could see if sox has a better way of adding those sounds. [21:41:42 CET] <adc> I do have the ffmpeg part working, it's just not accurate enough [21:42:06 CET] <J_Darnley> I thought you were also complaining about speed. [21:42:25 CET] <adc> Yeah, it's annoying but if I can get an accurate output I can survive with it [21:45:39 CET] <adc> A couple hours of processing is so much better than 30 hours of manual work, so. [23:54:15 CET] <qwertzsqwert> From the docs the following does not work for me: ffmpeg -f jack -i ffmpeg -y out.wav [23:54:59 CET] <durandal_170> error? [23:55:00 CET] <qwertzsqwert> Any ideas? [23:55:32 CET] <qwertzsqwert> Sure: unknown input format [23:56:01 CET] <JEEB> have you built with jack? [23:56:31 CET] <durandal_170> than ffmpeg is not compiled with it [23:56:47 CET] <qwertzsqwert> What is the build prefix? [23:57:28 CET] <qwertzsqwert> ^switch [23:58:58 CET] <JEEB> ./configure --help | grep 'jack' [00:00:00 CET] --- Sun Feb 21 2016

1 0

ffmpeg-devel.log.20160219
by burek 20 Feb '16

20 Feb '16

[01:44:02 CET] <ethe> Do the GSoC things have to be done for GSoC? The only reason I'm asking is that, I'm not eligible for GSoC (at least I think I'm not), but I'm interested in one of the tasks (AAC one). [01:47:51 CET] <iive> ethe: The tasks are created by FFmpeg, google just approves them. [01:50:38 CET] <ethe> Yeah, but maybe they'd like actual GSoC candidates to get full choice, there's no point two people doing the same task. Just wondering, I find it's better to ask than to have complications later. [01:50:52 CET] <iive> ethe: this means, that google have to accept the task first, then a student must be picked... and when he is done he will get his payment. [01:51:26 CET] <iive> yeh.. it would be bad if two people are working on same thing, gsoc or not. especially if one of them expect to be paid for it. [01:53:18 CET] <iive> i don't remember is ffmpeg participated in last year gsoc... I think it did., didn't it? [01:53:27 CET] <ethe> I just checked, I am definitely not eligible for GSoC, you have to have finished secondary education. (personally, I think this is a silly requirement, but whatever) [01:54:57 CET] <iive> indeed... [01:55:08 CET] <iive> if you can handle the task... [02:04:47 CET] <michaelni> ethe, theres also outreachy, which ffmpeg is also participating in. And the aac task has actually no mentor so a gsoc student couldnt even do it currently. that is if you want to work on that it shouldnt conflict with anything [02:06:48 CET] <cone-349> ffmpeg 03Michael Niedermayer 07master:98a0053d0f90: avcodec/h264: Execute error concealment before marking the frame as done. [02:08:40 CET] <ethe> michaelni that seems exclusively for women (and minorities) [02:11:35 CET] <michaelni> ethe, yes, all these things have some eligibility constraints ... [02:14:12 CET] <ethe> Unfortunately I don't think I'm eligible for any, not that it really matters, I wasn't interested in joining any of them. I just wanted to see if I could do the task, I'm more interested in learning, and AAC was one of the things I wanted to learn about [02:15:00 CET] <michaelni> you can, but without gsoc/outreahcy its volunteer work so you would not get any money [02:16:16 CET] <michaelni> thats the same with almost everyone working on FFmpeg, its all unpaid work we do :) [02:25:20 CET] <michaelni> also atomnuker and Claudio Freire know aac (more encoder side though), so if you have questions about AAC they might know the awnsers [02:50:20 CET] <Timothy_Gu> michaelni: http://fatebeta.ffmpeg.org/report/armv7l-panda-gcc4.4-armv4t/20160122221842 looks odd [02:50:33 CET] <Timothy_Gu> the date is a month ago, but the revision is 3 days old [02:52:24 CET] <Timothy_Gu> hmm looking at http://fatebeta.ffmpeg.org/history/armv7l-panda-gcc4.4-armv4t with descending sort for revision the date setting looks all messed up [03:18:59 CET] <Timothy_Gu> RiCON: thanks, fixed [03:19:20 CET] <michaelni> Timothy_Gu, date fixed on panda arm board [03:19:27 CET] <Timothy_Gu> cool thanks [08:23:59 CET] <Timothy_Gu> https://github.com/blog/2111-issue-and-pull-request-templates [08:29:33 CET] <CoJaBo> yuv4mpegpipe doesn't support yuvj420p; is this a bug, or is it intended for some convoluted reason? [08:30:17 CET] <wm4_> CoJaBo: tried yuv420p + setting color_range? [08:31:01 CET] <CoJaBo> I want to minimize the number of color format conversions [08:34:08 CET] <wm4_> yuvj is deprecated, setting the range is the preferred replacement [08:34:31 CET] <CoJaBo> ..how do i do that? [08:35:26 CET] <wm4_> hm just looked, our yuv4mpegenc doesn't check color range, so signalling full range is probably completely unsupported [08:35:43 CET] <CoJaBo> I can't find much of anything on either color_range or yuvj >_> [08:40:08 CET] <JEEB> raw video colorimetry beyond ycbcr/rgb and bit depth is usually not supported in containers, if even that [08:43:02 CET] <JEEB> also of yoi need pipe'able container for raw video I do recommend nut nowadays due to how it also has timestamps and can contain audio. also if it uses the yuvj identifier to write the type of data included it might even work with full range by chance (usually thus stuff is recorded in the video format rather than the container) [08:55:03 CET] <CoJaBo> JEEB: ..what is yuvj and full-range anyway? is this supposed to be documented somewhere? [08:59:36 CET] <JEEB> full/tv range. with ycbcr it's 0-255 (rare) vs 16-235/240 (the usual) [08:59:45 CET] <JEEB> tv or limited range [09:00:49 CET] <JEEB> basically historical artifacts of digital video that are not going away any time soon [09:07:00 CET] <jrosser> consider any fir filer on video, it will introduce under/overshoot [09:07:15 CET] <jrosser> thats why the headroom above and below black and white is there [09:07:35 CET] <jrosser> so its very relevant today, not just historical [09:28:27 CET] <JEEB> jrosser: yeah but usually those filtering steps are done in float and the output of the filter should then be limited to the proper range for output of that filter. so for in and out parts it shouldn't really matter. [09:29:24 CET] <jrosser> there is a widely held misconception that tv range video should be clamped to 16-235, thats not the case [09:29:59 CET] <jrosser> this is all in Poyntons excellent book [09:30:10 CET] <JEEB> well the only cases where I've seen actual content outside the range have been mastering fuck-ups [09:30:33 CET] <JEEB> I know if you want to keep the output between filters it can be useful (like, including the overshoot) [09:30:47 CET] <JEEB> but in that case I'd think the stuff would be in float for the duration of the filtering chain [09:30:56 CET] <flux> clamping is not as nice as not clamping.. :) [09:31:24 CET] <jrosser> you are thinking software, in a tv facility where its all hardware/FPGA and integer arithmetic.... [09:31:31 CET] <JEEB> well sure :P [09:31:37 CET] <jrosser> anyway, preserving that headroom is agood thing [09:31:51 CET] <jrosser> and clamping it once at mastering / before TX is alos likely a good thing [09:32:03 CET] <wm4_> what do you do with out of range rgb anyway [09:32:16 CET] <jrosser> but doing it all over the place has implications for frequency domain badness [09:32:20 CET] <JEEB> yes, sure [09:32:20 CET] <flux> you show blacker black and whiter white! [09:32:23 CET] <JEEB> I do agree with that [09:33:08 CET] <JEEB> just that a general user should only get stuff within that range, be it a mastering person encoding a blu-ray/archival version or getting a broadcast that is properly within the range [09:34:02 CET] <jrosser> test card has above white and below black spots to set up your screen properly [09:34:10 CET] <jrosser> so we really should pass that everywhere [09:37:28 CET] <nevcairiel> setup properly = not visible? :d [09:38:08 CET] <nevcairiel> some users make a huge deal out of absolutely requiring the BTB/WTW values to be delivered to their screen, while a properly calibrated screen should probably never be able to show them [09:40:06 CET] Action: jrosser backs away from this - theres ways you do setup in a broadcast facility which are confusing/irellevant to home environments [10:00:05 CET] <JEEB> do we have any current examples of having a library-based muxer? [10:00:31 CET] <JEEB> because I'm currently not sure if I want to expand our current movenc, or add a muxer (ab)using L-SMASH, which already supports some stuff [10:05:05 CET] <wm4_> isn't the problem that multiple muxers/demuxers are not possible with the API or something (or was that only with regards to demuxers & probing or so) [10:05:47 CET] <nevcairiel> its possible but you need to explicitly request them [10:48:35 CET] <cone-088> ffmpeg 03Paul B Mahol 07master:4956dc88d1fe: avcodec/cdxl: add support for raw videos with chunky format [11:07:31 CET] <wm4_> meh, so much h264 annexb bsf usage in decoders [11:11:35 CET] <wm4_> mateo`: what exactly does the mediacodec h264 decoder require for input? [11:14:42 CET] <mateo`> h264 bitstream - annex b [11:15:45 CET] <wm4_> mateo`: so what's all that messing with the parser? [11:15:59 CET] <wm4_> libavcodec input should already be 1 frame per packet [11:16:06 CET] <mateo`> speaking about that (i don't have the time to send a proper email atm), my next iteration on the patchset is to put all the jni stuff in lavc, avpriv -> ff, and drop the content uris stuff for now [11:16:20 CET] <mateo`> wm4_: in the annex b form ? [11:16:35 CET] <wm4_> no, the annex b conversion you still have to do [11:16:39 CET] <wm4_> (usually) [11:17:08 CET] <mateo`> then, this is what i'm doing with the parser in mediacodecdec_h264 [11:19:54 CET] <wm4_> is the parser maybe just a leftover that's not used anymore? [11:23:03 CET] <mateo`> the parser is here to make the conversion if needed, (unless i'm guaranteed to always get one frame in the annex b format) [11:24:25 CET] <wm4_> well looking a bit harder, the parser is initialized, but then never used and not even destroyed [11:25:32 CET] <nevcairiel> parsers are not used for such conversion, you want the bitstream filter [11:25:55 CET] <mateo`> mmm sorry, i was thinking about the bitstream filter the whole time [11:26:10 CET] <mateo`> well the parser can be removed [11:26:18 CET] <mateo`> it's clearly a left over [11:31:11 CET] <mateo`> i'm asking to be sure i'm not going in the wrong direction, but are you ok that I put all the jni stuff in lavc, makes all this mess private [11:31:20 CET] <mateo`> and see later what we do about the content uris ? [11:32:34 CET] <wm4_> so mediacodec really wants you to extract the sps and pps manually? [11:32:50 CET] <wm4_> mateo`: sounds good to me [11:33:09 CET] <mateo`> yes it wants the sps / pps in the annex b format separately according to the document [11:33:26 CET] <wm4_> keep it in a separate file, later we might access it from libavformat via #include "libavcodec/jni.c" [11:33:29 CET] <mateo`> i might be possible to submit it as one chunk, i haven't tested that [11:33:34 CET] <wm4_> nevcairiel: would that be reasonable? [11:34:01 CET] <wm4_> I thought the annex b bsf already inserts the sps and pps in the stream [11:34:55 CET] <wm4_> hm [11:35:05 CET] <wm4_> or at least it overwites avctx->extradata with it [11:36:11 CET] <wm4_> it might be doing both [11:38:26 CET] <nevcairiel> it does both [11:38:53 CET] <nevcairiel> unless you set the option for it not to [11:39:18 CET] <wm4_> I don't really get the point of annex b extradata though, it's redundant? [11:39:28 CET] <nevcairiel> kinda yes [11:39:29 CET] <wm4_> (by design) [11:39:39 CET] <nevcairiel> but some decoders like to initialize before getting bitstream [11:39:57 CET] <nevcairiel> but i think mediacodec should work with inband annexb [11:40:12 CET] <BtbN> Hm, I realy wonder weather I should add that CUDA Input-Frame thing from libav nvenc. I never heard of anyone asking for that, and I'm not a fan of AV_PIX_FMT_CUDA. [11:40:36 CET] <BtbN> Also, I'd have to put up quite some effort to even be able to test it. [11:41:01 CET] <nevcairiel> they also added a avfilter which can simply upload and create cuda frames for you, does that not work [11:41:13 CET] <BtbN> Sure, but... why? [11:41:18 CET] <nevcairiel> for testing [11:41:18 CET] <nevcairiel> :D [11:41:23 CET] <BtbN> That doesn't add any functionality [11:41:42 CET] <nevcairiel> thats what i said, but presumably they have plans to add cuda processing or something [11:42:02 CET] <wm4_> isn't it FAST [11:42:14 CET] <wm4_> so you can avoid going over the CPU for some things [11:42:18 CET] <BtbN> Why would it be faster if you manualy upload the frame to CUDA instead of letting NVENC do that? [11:42:35 CET] <wm4_> well, if you have something that can decode to cuda surfaces [11:42:42 CET] <nevcairiel> nvidia is the most painless when it comes to down/upload anyway [11:42:43 CET] <wm4_> nvcuvid maybe? (lol) [11:42:46 CET] <mateo`> wm4_, nevcairiel: i'll be off irc / ml for the next few days, the updated patchset can be expected for monday [11:42:55 CET] <nevcairiel> wm4_: in fact it does =p [11:43:20 CET] <nevcairiel> but nvcuvid is kinda dead, they havent worked on it in ages and it accumulated a few bugs [11:43:57 CET] <wm4_> mateo`: ok... I'm still not sure if I understand the complex dataflow interaction with mediacodec, I guess I'll delay that until the new patch [11:44:21 CET] <BtbN> The only thing where it'd be interesting with is NvFBC, which grabs the framebuffer right on the Nvidia GPU, so you can encode it without it ever hitting the system ram [11:44:33 CET] <BtbN> But the NvFBC is under NDA [11:44:37 CET] <BtbN> +API [11:45:04 CET] <nevcairiel> reverse engineer it, if you didnt sign anything, you also didnt violate it [11:45:06 CET] <BtbN> And it gives you D3D Surfaces instead of CUDA [11:45:18 CET] <BtbN> I already did, it leaked several times [11:45:30 CET] <BtbN> no need to reverse it, they just included the full SDK in some drivers accidentialy [11:45:35 CET] <kierank> Can we get rid of this http server task for gsoc [11:45:36 CET] <nevcairiel> the d3d11 screen grabbing works in similar ways though [11:45:57 CET] <BtbN> The Win10-Exclusive DesktopDup thing? [11:45:59 CET] <BtbN> Yeah, it's the same [11:46:07 CET] <nevcairiel> its 8 upwards, not 10 only [11:46:31 CET] <nevcairiel> and that API isnt secret =p [11:46:47 CET] <nevcairiel> and relatively easy to use, as surprising as that sounds [11:47:47 CET] <nevcairiel> 200 odd lines with boilerplate overhead [11:49:13 CET] <nevcairiel> if mingw wouldnt suck so bad with d3d11 apis, i might even provide one for ffmpeg just as a PoC and example for others to follow =p [11:50:29 CET] <wm4_> what's even the point of NDA'd APIs [12:01:24 CET] <BtbN> So people pay you for the SDK. [12:02:41 CET] <BtbN> Just went through all the changes the libav nvenc encoder ever had, and they all don't apply to the ffmpeg implementation. The CUDA frame input thing is the only actualy new feature, and I'm not sure how usefull it is. [12:03:32 CET] <BtbN> Well, and there is https://git.libav.org/?p=libav.git;a=commitdiff;h=1520c6ff05d835da4b793318f… which I'm not sure about, is that usefull? Would be trivial to add [12:06:57 CET] <BtbN> I'm also not a fan of linking to the actual CUDA SDK. That thing is a mess [12:07:31 CET] <BtbN> OpenCL seems like a much more reasonable choice for ffmpeg, but there is no interop aparently. [12:08:24 CET] <wm4_> maybe there's opencl and cuda interop? [12:08:31 CET] <wm4_> or opencl/opengl and opengl/cuda interop [12:08:46 CET] <wm4_> why do I feel like I'm trolling [12:10:47 CET] <BtbN> I'm also still amazed by that Nvidia-Hack-Patch they cassualy include in ther "How to NVENC with ffmpeg" guide PDF. [12:10:52 CET] <BtbN> +i [12:11:06 CET] <atomnuker> there's already interops between vaapi and vdpau and people use them [12:11:21 CET] <wm4_> atomnuker: these are just emulation layers [12:11:42 CET] <wm4_> not passing hardware surfaces from one API to another [12:46:33 CET] <nevcairiel> BtbN: the cbp thing should be in our nvenc, i think i ported that one over since its largely independent of the nvenc implementation [13:07:23 CET] <ethe> Did I send my patch correctly? (the one about jack) I've never sent a patch using git send-mail before, and I just want to make sure I did it right [13:26:21 CET] <nevcairiel> didnt try applying it, but it looks ok on a quick glance [13:48:17 CET] <BBB> whts the status of the automatic bitstream filters? [13:50:54 CET] <nevcairiel> done and done? [13:51:13 CET] <BBB> ah good [13:51:32 CET] <wm4_> so where are we with m:n decoding [13:51:49 CET] <J_Darnley> Is that some spam that slipped through on -cvslog? The no subject email? [13:53:03 CET] <wm4_> I see 3 choices: 1. just do what the audio API does (partial packet consumption), 2. add something that amounts to the same thing, but is on the granularity of not accepting input packets, so the user has to repeat them (like setting a flag in got_frame), 3. completely new API with separate packet input/frame output functions [13:53:55 CET] <nevcairiel> dont think partial consumption is good or required, you would only consume a frame or not anyway [13:54:38 CET] <nevcairiel> a clean new api is probably best, but also the most involved to design [13:54:42 CET] <wm4_> partial consumption would simply cover this case, and it would be equal to the audio API [13:54:59 CET] <wm4_> but I think partial consumption is fragile, and decoders will for example not "consume" padding garbage [13:56:10 CET] <alexyecu> Hi everybody. Here is a question about building an ffmpeg 2.0 without optimization under Win x64. Looks like this does not work. Possibly here is the problem: http://pastebin.com/gBAK3PTd [13:59:51 CET] <michaelni> ethe, it applied cleanly but it disables jack here (see mail) [14:02:01 CET] <nevcairiel> alexyecu: this is a known limitation, ffmpeg requires the compiler to still perform dead code elimination even when optimizations are disabled, if it doesnt then you cannot build like that [14:07:13 CET] <alexyecu> nevcairiel, as I understand, It`s impossible to use debug in Visual Studio with current code. But the second variant (from the past) makes this possible for all compilers. So, why not to use it? [14:07:51 CET] <nevcairiel> because its arguably uglier and it was decided a long time ago to use the current form [14:08:23 CET] <nevcairiel> and if you want to develop with visual studio, i would recommend to temporarily disable optimizations in the files you are working on using a compiler pragma [14:08:25 CET] <nevcairiel> works wonder for me [14:08:59 CET] <ethe> michaelni right. I'm so stumped for that configure script. I guess I'm going to have to get a VM [14:19:48 CET] <alexyecu> nevcairiel, but there are about 30 files using pasted construction, temporary disabling of optimizatiom looks like not very good idea. BTW, that`s not me, but my colleague works with current code, but I decided to ask here about his problem. [14:20:34 CET] <kierank> http://obe.tv/obe-news/item/27-accelerating-the-use-of-vc-2-hq-for-software… [14:20:59 CET] <kierank> blah blah marketing [14:21:01 CET] <nevcairiel> alexyecu: i said you should disable it for the code in question you are working on, not everywhere [14:23:11 CET] <wm4_> kierank: nice [15:01:38 CET] <ethe> how can I print the values of stuff like enabled jack_indev in the configure script for debugging? I tried: echo $(enabled jack_indev) but that didn't seem to output anything [15:15:49 CET] <J_Darnley> ethe: you can run it in the shell like bash -x configure [15:15:56 CET] <J_Darnley> but that might be a little too verbose [15:18:19 CET] <BBB> maybe bsf api should be rewritten so it consumes/outputs packets instead of what it does now? [15:18:26 CET] <BBB> nice refcounting etc [15:18:59 CET] <wm4> sounds like a nice idea [15:22:54 CET] <durandal_1707> evilril plan is that already [15:26:55 CET] <jamrial> speaking of bsf, a gsoc project could be adding some or the missing ones, like latm to asc [15:27:36 CET] <jamrial> there's a feature request ticket about it, even [15:28:04 CET] <ubitux> BBB: do you remember when you worked on porting the png paeth prediction asm? [15:28:11 CET] <BBB> nope [15:28:19 CET] <ubitux> :D [15:28:25 CET] <BBB> I can try to help anyway [15:28:28 CET] <BBB> what did I do wrong? [15:28:44 CET] <BBB> durandal_1707: oh cool ok then I wont have to [15:28:46 CET] <BBB> thanks elenril [15:28:46 CET] <ubitux> oh probably nothing, i'm just wondering how efficient it could actually be [15:29:03 CET] <ubitux> since every pixel seems to depend on the previous or something [15:29:05 CET] <BBB> some of it was written by loren and is inherently scalar [15:29:25 CET] <BBB> so its just abusing the fact that loren > compiler [15:29:28 CET] <ubitux> and code is hard to follow (mainly because of the dst pointer hacks) [15:42:30 CET] <wm4> so ffmpeg doesn't support opus gapless playback from .opus (ogg) [15:43:09 CET] <wm4> hm according to the code it adds end trimming but none on the start? [15:48:36 CET] <cone-088> ffmpeg 03Michael Niedermayer 07master:7ac962af38f0: avformat/avienc: Store pal8 palette [15:56:57 CET] <kierank> can we remove this http server crap [15:57:36 CET] <wm4> +1 [15:59:01 CET] <nevcairiel> i dont see that anymore [15:59:06 CET] <nevcairiel> unless we're talking about other things [15:59:37 CET] <kierank> I saw it this morning [16:00:11 CET] <kierank> maybe that was an old page [16:17:41 CET] <wm4> ah wtf, ffprobe.c does partial video frame decoding, while ffmpeg.c does not [16:17:53 CET] <JEEB> funky [16:18:37 CET] <wm4> ffprobe does partial decoding even for subtitles [16:19:05 CET] <wm4> oh well ffmpeg.c also does [16:22:14 CET] <wm4> wtf, avconv.c also does for video [16:22:16 CET] <BBB> partial decoding [16:22:18 CET] <BBB> what is that [16:22:24 CET] <nevcairiel> consuming half a packet [16:22:30 CET] <wm4> maybe a better term is partial packet reading [16:22:46 CET] <wm4> so the only thing which doesn't do this is ffmpeg.c with video [16:23:05 CET] <wm4> does that imply libav decoders return correct values, while ffmpeg's sometimes do not? [16:23:43 CET] <nevcairiel> no it just means that it would bug out with some formats on libav =p [16:24:48 CET] <BBB> michaelni: how do I disable the non-monotonous timestamp check in ffmpeg.c? [16:24:56 CET] <BBB> michaelni: (from libavformat) [16:25:22 CET] <BBB> michaelni: its triggering in a way that is not actually buggy (two subsequent write_interleaved with same pts, but only the second one gets past my bitstream filter) [16:25:54 CET] <BBB> rcombs: actually, this is a auto-bsf bug [16:26:07 CET] <BBB> rcombs: the auto-bsfs trigger that warning but manual bsfs don't [16:29:05 CET] <wm4> interlaced HEVC produces two frames, right? why doesn't the parser just separate them? [16:31:42 CET] <nevcairiel> on decoding thats what happens [16:31:58 CET] <nevcairiel> the problem is with encoding, where one input frame would produce two packets [16:33:10 CET] <wm4> wouldn't it just produce 2 concatenated packets? [16:33:14 CET] <nevcairiel> interlaced in hevc is nothing special, just encoding two half-height frames individually and a few bits of metadata [16:33:34 CET] <nevcairiel> wm4: then timestamps would be screwed up, the big magic of interlaced is that its temporally distinct points [16:34:04 CET] <wm4> but that's already done for interlaced in general [16:34:06 CET] <nevcairiel> so if oyu want to encode proper hevc interlaced, you need 1:2 api =p [16:37:31 CET] <michaelni> BBB, AVFMT_TS_NONSTRICT may work but may or may not be what you are searching for [16:38:40 CET] <michaelni> if its not container specific then the check possibly would need to be extended to allow whatever allows it [16:41:08 CET] <JEEB> hmm, was there anything special regarding writing signed integers? avio_wb32 just fine? [17:04:42 CET] <BBB> michaelni: see patch on ML [17:05:07 CET] <BBB> michaelni: I really think ffmpeg.cs check is broken and should disappear or only enabled when specifically asked [17:08:13 CET] <kierank> avdev is going down for a week [17:08:34 CET] <BBB> kierank: tnx for mentioning [17:09:01 CET] <ubitux> hey BBB, would you know why? https://twitter.com/tusbar/status/700709620659068928 [17:09:23 CET] <BBB> nope :-p [17:09:42 CET] <ubitux> the nda is strong with this one [17:09:46 CET] <ubitux> okay :) [17:10:40 CET] <BBB> nda? [17:10:43 CET] <BBB> I dont work for youtube [17:10:52 CET] <BBB> I dont know anything [17:10:53 CET] <ubitux> you were close, no? [17:11:05 CET] <ubitux> anyway just a jk :) [17:11:09 CET] <BBB> team was in chrome [17:11:23 CET] <BBB> I would hang out every once in a while, but otherwise not really, no [17:16:52 CET] <BtbN> I'd guess they make those IDs in a way so they are able to compensate for a typo? [17:17:26 CET] <wm4> a typo for the last character? [17:18:03 CET] <BBB> michaelni: I guess what Im looking for is some way to say I did not use these input packets, or alternatively some way to let the muxer auto-select bsfs (rcombs hi) but be able to run the bsfs manually so I know whether it caused a pkt skip or not [17:18:38 CET] <BBB> (pkt skip happens when merging two frames into one superframe) [17:21:05 CET] <rcombs> BBB: if you manually insert a BSF, lavf won't [17:21:30 CET] <BBB> it works fine with manual insertion [17:21:41 CET] <BBB> auto-insertion causes the non-monotonous pts errors [17:21:53 CET] <BBB> and id like that warning to go away with auto-insertion [17:22:08 CET] <BBB> because the warning is full of bullshit [17:22:18 CET] <BBB> there is no pts error, its just that ffmpeg.c wasnt aware of it [17:27:20 CET] <JEEB> ok, so looking at some fragmented isobmff that lavf writes [17:28:00 CET] <JEEB> would implementing trun v1 semantics with negative composition time offsets for b-picture delay sound like a bad idea to people? [17:28:21 CET] Action: JEEB is currently looking at how much of a PITA it would be [17:34:44 CET] <nevcairiel> BBB: the warning kinda makes sense, because the auto-bsf happens after ffmpeg.c code, and for ffmpeg you are sending two or more frames with the sme timestamp [17:35:02 CET] <nevcairiel> while manual bsf happens inside ffmpeg.c [17:35:20 CET] <nevcairiel> not sure how to make it happier though [17:36:45 CET] <BBB> right, thats exactly my problem [17:36:53 CET] <BBB> I understand why ffmpeg.c currently emits the warning [17:37:03 CET] <BBB> but the warning is bollocks nonetheless [17:37:14 CET] <BBB> so Id like some way to prevent triggering that warning in such cases [17:37:28 CET] <BBB> so users dont see warnings and freak out or get slightly adjusted timestamps for no reason whatsoever [17:42:34 CET] <michaelni> IIUC, somethng link AVFMT_TS_NONSTRICT could be added at codec level or simply a codec_id == AV_CODEC_ID_VP9 check in ffmpeg [17:44:51 CET] <Timothy_Gu> ethe: enabled jack_indev && echo enabled || echo disabled [17:45:17 CET] <ethe> thanks. (i got it now anyways though) [17:45:19 CET] <Timothy_Gu> enabled doesn't print anything so $() doesn't work [17:45:25 CET] <Timothy_Gu> ok [17:45:31 CET] <ethe> sem_timed was the problem [17:46:15 CET] <ethe> sem_timewait*, it wasnt being checked, im just about to revert to a clean tree to see if it worked before (because it doesnt even look like it should have worked before on any OS) [17:58:50 CET] <BBB> michaelni: it only happens for vp9 when you use -c:v copy [17:58:57 CET] <BBB> michaelni: during regular encoding this doesnt occur [18:03:28 CET] <BBB> michaelni: maybe a check for vp9 && codec==copy would make sense [18:04:58 CET] <BBB> michaelni: although Im not quite familiar with how ffmpeg.c works so some sample code would be helpful [18:08:00 CET] <michaelni> BBB to detect copy you should be able to use the stream_copy field or encoding_needed field [18:11:31 CET] <michaelni> detecting vp9 should be trivial, theres already code there that checks codec_type so the check doesnt trgger for odd streams, the same context should have a codec_id ... [18:29:34 CET] <ethe> michaelni damn. sorry, I messed up git send-email [18:48:03 CET] <cehoyos> BBB: Did it work without braces? (Why?) [18:48:25 CET] <BBB> I only tested ivf, so no idea [18:48:32 CET] <cehoyos> Ok, thanks [18:48:34 CET] <BBB> I agree there should be braces regardless [18:49:10 CET] <cehoyos> I don't know what the compiler should do and I was unable to find an explanation online, so I wondered if you know... [18:49:34 CET] <cehoyos> I still believe it cannot work though... [18:50:13 CET] <BBB> it probably doesnt then [18:51:37 CET] <nevcairiel> gcc warns about such constructs [18:51:52 CET] <cehoyos> I thought so but didn't test [18:53:22 CET] <nevcairiel> technically both interpretations are valid according to the strictest language grammer, but i believe its always mapped to the inner if [18:58:50 CET] <cehoyos> Thank you [19:01:59 CET] <wm4> cehoyos: so are you ok with the videotoolbox encoder configure change? [20:32:07 CET] <BBB> michaelni: just tested that ffmpeg.c change, and that makes it worse, now Im triggering compute_muxer_pkt_fields errors [20:32:18 CET] <BBB> [ivf @ 0x7fa1cb00f600] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 33 >= 33 [20:32:54 CET] <cone-088> ffmpeg 03James Almer 07master:76af0c78772f: checkasm: fix dependencies for vf_blend tests [20:33:13 CET] <BBB> Ill test if applying auto-bsfs before compute_muxer_pkt_fields fixes that [20:33:31 CET] <BBB> yes it seems it does [20:58:49 CET] <cehoyos> wm4: I had not seen it yet, where can I find it? [20:59:06 CET] <cehoyos> But if it does not use auto-detection this leads to unavoidable bitrot;-( [21:02:01 CET] <ethe> what's the practise for amending a patch? do resend the whole patch, send a patch for the patch? it's only a couple lines which have to be fixed [21:04:53 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:84d7933e3b9c: lavc/libvpx: Fix high-bitdepth pix_fmts on big endian. [21:05:14 CET] <jamrial> ethe: resend the whole patch as a reply to the previous version [21:10:51 CET] <ethe> are all the indevs on by default? [21:11:33 CET] <wm4> cehoyos: he resent the patch (v6) [21:12:28 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:432be6362c31: lavc/libvpx: Fix support for RGB colorspace. [21:12:29 CET] <cone-088> ffmpeg 03Carl Eugen Hoyos 07master:73781741b7bf: lavc/libvpx: Reindent after last commit. [21:27:15 CET] <cehoyos> wm4: He added the autodetection, I believe this is a good idea [21:30:11 CET] <wm4> then I'll apply the patch tomorrow or so [23:09:43 CET] <cone-088> ffmpeg 03Marton Balint 07master:51afd9f4e1f7: avformat/dvbtxt: add raw demuxer for dvb teletext probing [23:09:44 CET] <cone-088> ffmpeg 03Marton Balint 07master:6c905dd3c24a: avcodec/libzvbi-teletextdec: use common functions for matching data_unit_id and data_identifier [23:09:45 CET] <cone-088> ffmpeg 03Marton Balint 07master:308ac2f7e204: ffmpeg: init input streams before opening encoders [23:26:12 CET] <nevcairiel> michaelni: your freebsd systems are out of space (ie. x86_32-debian-kfreebsd-gcc-4.4-cpuflags-sse3 and more) [00:00:00 CET] --- Sat Feb 20 2016

1 0

ffmpeg.log.20160219
by burek 20 Feb '16

20 Feb '16

[00:02:00 CET] <wintershade> hmm let me try... [00:03:08 CET] <wintershade> kepstin: okay, I tried ffprobe -show_format file.m4v |grep duration |sed s:duration=::g [00:03:20 CET] <wintershade> and it got me the integer (well, float, but that's okay) [00:03:35 CET] <wintershade> but it also printed a wall of text before that in the output [00:03:48 CET] <wintershade> starting with ffmpeg version 2.6.8... etc. [00:04:24 CET] <kepstin> sure, that wall of text is on stderr. There's some options to hide the banner, or you can just do 2>/dev/null on the ffprobe command [00:09:31 CET] <C0nundrum> Is there a way to customize the message the rtmpt sends ? [00:15:27 CET] <wintershade> kepstin: great! that worked, thanks [00:15:35 CET] <wintershade> kepstin: I'll try tinkering around that one now [06:36:46 CET] <CoJaBo> ..so here's yet another stupid problem: I have a camera that has the second line burned out. Is there a sane way to edit that out? [06:44:10 CET] <furq> crop? [06:50:30 CET] <CoJaBo> furq: Cropping would leave me with a really weird-sized video [06:57:44 CET] <furq> weird how [07:00:32 CET] <furq> i guess you could try delogo but idk how well that will work on a 1px high line [07:46:56 CET] <CoJaBo> furq: ..how do I delogo? [07:47:28 CET] <CoJaBo> An additional question came up; is there something like yuv4mpegpipe that supports YUVJ? [07:55:44 CET] <relaxed> CoJaBo: you could do -c:v rawvideo -pix_fmt yuvj420p [07:56:17 CET] <relaxed> look at "ffmpeg -pix_fmts | grep j" for other options [07:59:19 CET] <CoJaBo> How do I read the rawvideo format? [08:01:33 CET] <relaxed> you can try, -pix_fmt yuvj420p -f yuv4mpegpipe [08:01:45 CET] <relaxed> but I'm not sure if it's supported [08:04:17 CET] <CoJaBo> relaxed: That's the problem; it complains about it not being supported [08:04:23 CET] <CoJaBo> but... why? [08:06:53 CET] <relaxed> if it's not supported and you need yuvj420p, then use -c:v rawvideo -pix_fmt yuvj420p and output it in matroska [08:07:41 CET] <CoJaBo> I want to actually pipe it tho, to some other tool (and then back to ffmpeg) [08:07:44 CET] <relaxed> libx264 supports yuvj420p [08:08:48 CET] <relaxed> you can pipe matroska or nut [08:09:16 CET] <relaxed> ffmpeg -i input -c:v rawvideo -pix_fmt yuvj420p -f matroska - | ffmpeg -i - ... [08:09:42 CET] <CoJaBo> what is nut? [08:09:58 CET] <relaxed> a container, like .mkv or .mp4 [08:10:54 CET] <relaxed> why do you need to pipe from ffmpeg to ffmpeg? what are you doing? [08:11:16 CET] <CoJaBo> I want to edit it in the middle somehow [08:13:27 CET] <CoJaBo> (I often need to do bizarre things, like duplicating the second scanline of every second frame, un-fishbowling the clip, or doing a skew effect to the image) [08:23:44 CET] <relaxed> what's expected in the middle is the info you need [08:24:33 CET] <relaxed> can you send raw yuv? [08:24:47 CET] <CoJaBo> That's what I want to do, yes [08:25:07 CET] <CoJaBo> is nut the best format to use for that? [08:25:24 CET] <CoJaBo> I'd previously used yuv4mpegpipe, but it appears to no longer be supported.. [08:25:31 CET] <relaxed> -pix_fmt yuvj420p -f rawvideo - [08:27:23 CET] <relaxed> yuv4mpegpipe with yuvj420p? [08:28:37 CET] <CoJaBo> yuv4mpegpipe doesn't support yuvj420p [08:28:49 CET] <CoJaBo> I don't know why; might be a bug? [08:30:00 CET] <relaxed> I mean you said it worked in the past. What doesn't work now? [08:30:38 CET] <CoJaBo> It worked before because my other camera shot yuv420p [08:32:35 CET] <relaxed> oh, then use -pix_fmt yuv420p -f yuv4mpegpipe - [08:32:47 CET] <CoJaBo> I want to minimize the number of color format conversions [08:33:57 CET] <CoJaBo> I'm hoping to edit directly in yuvj420p; tho I might have to convert to RGB, in which case I'm actually probably better off using nut/rawvideo anyway.. gah.. [08:35:06 CET] <relaxed> like I said, if whatever you're using in the middle supports raw yuv, then -pix_fmt yuvj420p -f rawvideo - [08:36:07 CET] <CoJaBo> rawvideo alone loses the headers [08:36:12 CET] <relaxed> indeed [08:36:31 CET] <CoJaBo> which I kinda need lol [08:38:06 CET] <relaxed> lossless h264 in matroska [08:54:21 CET] <CoJaBo> relaxed: ..that is not at all easy to work with lol [10:02:51 CET] <dystopia_> is there an easy way to cat vp6 flash video? [10:03:00 CET] <dystopia_> with out encoding to another format first [10:20:00 CET] <claw> dystopia_: mkvmerge [10:20:32 CET] <claw> oh sorry you are talking about vp6 [10:21:07 CET] <claw> nevermind [10:36:14 CET] <dystopia_> mkvmerge worked claw [10:36:18 CET] <dystopia_> thanks for the suggestion [10:36:39 CET] <claw> well be both learned something [10:36:49 CET] <dystopia_> :) [10:41:18 CET] <dystopia_> ahh it didn't work :( [10:41:31 CET] <dystopia_> i was testing with files i had already encoded out, when i tried the source files it failed [13:14:15 CET] <t4nk692> Hello, I need some help. Does anybody know where I can update my yasm/nasm or somehow make my ffmpeg installation work? This is the log: Jonathans-MacBook-Pro:~ jonathan$ /Users/jonathan/Downloads/ffmpeg-3.0/configure ; exit; yasm/nasm not found or too old. Use --disable-yasm for a crippled build. If you think configure made a mistake, make sure you are using the latest version from Git. If the latest version fails, report the prob [13:17:58 CET] <J_Darnley> Build yasm or nasm from source? [13:18:08 CET] <J_Darnley> http://yasm.tortall.net/ [13:18:56 CET] <J_Darnley> and I think nasm moved here http://www.nasm.us/ [13:22:16 CET] <ethe> t4nk692 you can get it from homebrew [13:22:38 CET] <ethe> (or macports, I believe, although I've never used it) [13:23:01 CET] <t4nk692> Right, I was through the yasm-site before during my search for a solution. I don't quite get how to perform a build from source. But I'll give it another shot. [13:23:16 CET] <t4nk692> Trying the nasm site, downloading now. [13:23:26 CET] <t4nk692> and will check homebrew [13:23:28 CET] <cowai> My input is "720x576 [SAR 16:15 DAR 4:3]", how should I scale that to get the best possible square image? [13:23:33 CET] <ethe> homebrew will be 100x easier [13:23:52 CET] <cowai> right now I am using bwdif=0:0:0,scale=768x576 [13:23:57 CET] <ethe> you dont have to build from source, it generally already has binary packages, but if not, it automates building from source. [13:24:09 CET] <TekniQue> cowai: square image or square pixels? [13:24:14 CET] <cowai> pixels [13:24:18 CET] <cowai> sorry :P [13:24:18 CET] <TekniQue> 768x576 [13:24:33 CET] <TekniQue> gives you a 4:3 square pixel image [13:24:44 CET] <cowai> that is what I am using currently. [13:24:52 CET] <cowai> is that the most correct one? [13:24:55 CET] <TekniQue> yes [13:25:29 CET] <cowai> even when deinterlacing? [13:25:38 CET] <ethe> t4nk692: and if you're just looking to get an ffmpeg release then you can get that from homebrew as well (using brew install ffmpeg), and if you want the latest git from within homebrew: brew install --HEAD ffmpeg [13:25:41 CET] <TekniQue> yes [13:26:13 CET] <cowai> so the image that I get by using -filter:v "bwdif=0:0:0,scale=768x576" is the best I can get with ffmpeg? [13:27:01 CET] <cowai> I have been suggested to try to scale it up to twice the size and then use unsharp mask to try to make it better. Is that worthwhile you think? [13:27:15 CET] <TekniQue> what's bwdif? [13:27:25 CET] <cowai> ffmpegs newest deinterlacer :) [13:27:31 CET] <t4nk692> alright <ethe> I'm going into that now. Thank you! [13:27:35 CET] <cowai> commited by durandal_1707 yesterday [13:27:44 CET] <cowai> its a mix of yadif and w3fdif [13:27:51 CET] <TekniQue> ok [13:28:03 CET] <cowai> I have tried it with nice results [13:28:23 CET] <cowai> more "balanced" for my use case which is a live stream with lots of different content. [13:29:01 CET] <cowai> https://ffmpeg.org/ffmpeg-filters.html#bwdif [13:29:02 CET] <TekniQue> but for scaling, yes it may give a smoother image to do it that way [13:29:48 CET] <TekniQue> but even just applying the unsharp mask to it as is may produce a more pleasant image [13:29:55 CET] <cowai> my output will be a hls stream, with different qualities. Today I have 192p, 360p and 576p. The source is a decklink card with SD-SDI [13:30:04 CET] <TekniQue> I'd have to see a screenshot to be sure of what's going on [13:30:21 CET] <TekniQue> normally I would let the player worry about scaling the picture [13:30:33 CET] <TekniQue> unles you're using a codec that requires square pixels [13:30:53 CET] <cowai> I think HLS requries it. [13:31:18 CET] <TekniQue> nope [13:31:50 CET] <cowai> I am also playing hls with hls.js and flashls. [13:31:51 CET] <TekniQue> source: I've been using HLS since 2009 [13:32:13 CET] <cowai> I think when I didnt scale it, some of the different players made the image squeezed [13:32:30 CET] <Mavrik> But that has nothing to do with interlace [13:32:34 CET] <Mavrik> That's wrong SAR [13:32:38 CET] <Mavrik> Or players not listening to it. [13:34:27 CET] <cowai> Mavrik: We were talking about SAR [13:35:00 CET] <Mavrik> Anyway, broadcasting HLS to bunch of clients and didn't have requirement for square pixels. [13:35:11 CET] <Mavrik> AR switch is another issue. [13:44:33 CET] <cowai> Thanks. Should I let the other levels/qualities be the same SAR as the original when downscaling? [13:54:45 CET] <TekniQue> yes [13:55:16 CET] <cowai> do I just do scale=-1:360 after deinterlacing then? [13:55:23 CET] <cowai> for a height of 360? [13:55:33 CET] <cowai> and the SAR will be like it was? [13:55:48 CET] <TekniQue> no I'd scale down on horizontal and vertical [13:56:13 CET] <TekniQue> what I usually do is make the smaller pictures 1:1 PAR [13:56:28 CET] <TekniQue> err, SAR [13:56:49 CET] <J_Darnley> PAR=SAR [13:57:18 CET] <TekniQue> yes, I'm used to talking about pixel aspect ratio and not sample aspect ratio [13:57:46 CET] <TekniQue> for the same thing [14:00:49 CET] <cowai> I must admit I am not sure that the difference is :/ [14:02:00 CET] <J_Darnley> There isn't one as far as you are concerned. [14:02:04 CET] <J_Darnley> samples are pixels [14:02:08 CET] <J_Darnley> pixels are samples [14:03:31 CET] <cowai> Is there any new formats that will ever use a non 1:1 PAR? Isn't this just for legazy CRT monitor stuff? [14:04:04 CET] <J_Darnley> Blurays probably still do in some of their dark corners [14:04:26 CET] <cowai> :P [14:04:27 CET] <J_Darnley> Broadcast might still do anamorphic 1080p [14:04:37 CET] <J_Darnley> DVDs of course [14:04:43 CET] <cowai> yes, [14:05:12 CET] <cowai> But as the world moves towards HD anamorphic will die right? [14:05:17 CET] <J_Darnley> It wouldn't surprise if some "cheap" cameras do [14:05:42 CET] <J_Darnley> I doubt it. [14:05:49 CET] <J_Darnley> Video formats will support it [14:05:49 CET] <cowai> I am trying to find the reason it was created in the first place. [14:06:01 CET] <J_Darnley> So someone will still make videos that have it. [14:06:15 CET] <J_Darnley> Ah [14:06:32 CET] <J_Darnley> That probably goes back to early cinema cameras [14:07:06 CET] <J_Darnley> One of the film formats used a lens which produced this kind of distortion [14:07:13 CET] <cowai> I mean who in their right mind created "1440x1080" HDV [14:07:37 CET] <J_Darnley> People without enough bandwidth or processing power for full hd [14:07:39 CET] <cowai> I would rather have 720p forever then crazy 1440x1080 [14:08:04 CET] <Mavrik> Pretty much all SD broadcast TV has non 1:1 SAR [14:08:53 CET] <J_Darnley> I would rather we stayed at SD. No need for anything bigger. [14:09:29 CET] <cowai> I work in a SD TV channel and the amount of work we need to worry about fields is crazy in this HD age. [14:09:43 CET] <J_Darnley> Now interlacing is another matter [14:09:47 CET] <cowai> yes [14:09:54 CET] <Mavrik> Interlacing must be taken outside and shot. [14:10:07 CET] <J_Darnley> Anyone who produces an interlaced video should be publically executed [14:10:32 CET] <cowai> Agreed [14:10:34 CET] <Mavrik> Even though, people love that sweet 50i [14:10:41 CET] <dv_> isnt interlacing effectively gone in HEVC? [14:10:47 CET] <dv_> IIRC it is just present as a marker [14:10:53 CET] <dv_> but no MBAFF or anything like that [14:11:02 CET] <J_Darnley> That's not the problem [14:11:09 CET] <J_Darnley> The content is the problem [14:11:44 CET] <J_Darnley> Interlaced content remains interlaced no matter what encoding features are present. [14:15:15 CET] <cowai> my tv provider at home scales 720p50 to 1080i before reencoding it to lower bitrate. And then the reciever deinterlaces this to 1080p. [14:15:39 CET] <cowai> doesnt much worse then that. [14:15:56 CET] <J_Darnley> my condolences [14:21:03 CET] <IntelRNG> It sounds awful. [16:41:24 CET] <eightfold> hi there [16:42:52 CET] <eightfold> i have two questions. i use -ss and -t when remuxing to move segments of files into a new container. [16:43:15 CET] <eightfold> is there a way to set -t to "the end of the file", without specifying the exact length of the file? [16:43:28 CET] <J_Darnley> Yes, don't give -t [16:43:40 CET] <eightfold> J_Darnley: oh, thanks! :) [16:44:44 CET] <eightfold> my second question. it would be simpler to calculate time if i could put the position of the -t in "time into the file" instead of "time from -ss" [16:45:02 CET] <eightfold> is that possible? i've tried "-to", but it seems to work the same way as -t [16:45:31 CET] <J_Darnley> Are you using -t or -to as an input or output option? [16:46:56 CET] <eightfold> J_Darnley: hmm, i don't know, i though -to replaced -t [16:47:19 CET] <J_Darnley> Do you put it before the input file or before the output file? [16:49:14 CET] <eightfold> J_Darnley: after input and before output [16:49:44 CET] <J_Darnley> Try moving -to to before the input file. It might work as you expect then. [16:51:10 CET] <eightfold> J_Darnley: ok, i'll try. thanks! [16:58:57 CET] <monkkey> Hi, is there? [17:00:17 CET] <eightfold> J_Darnley: when doing these kind of moves, should i add any option for better syncing or so? currently looks like this: [17:00:18 CET] <eightfold> ffmpeg -ss 00:00:00.000 -i input.mp4 -t 00:39:01.500 -c copy output.mp4 [17:00:45 CET] <eightfold> i'm running ffmpeg 2.8.4 [17:01:29 CET] <J_Darnley> It can be a little imprecise when copying but I don't know what options may help fix/prevent that. [17:01:46 CET] <J_Darnley> You can try looking at the various sync options. [17:03:06 CET] <monkkey> Please, if someone can help me... I do it: ./opencvvehicletrack | ffmpeg -f rawvideo -pix_fmt gray -i - out.avi (opencvvehicletrack generate raw video) and then I get the next result: https://www.youtube.com/watch?v=HqpAv_oi3u4 [17:03:26 CET] <eightfold> J_Darnley: seems to be ok with preciseness [17:03:50 CET] <J_Darnley> monkkey: you have a size or stride problem [17:04:04 CET] <monkkey> stride? [17:04:15 CET] <J_Darnley> aka pitch or linesize [17:04:32 CET] <J_Darnley> (the number of bytes to move to the next line) [17:05:33 CET] <monkkey> I send to the pipe raw image (mat of opencv) [17:05:49 CET] <monkkey> and these mat are in the same size of the output [17:06:13 CET] <monkkey> if I change the sizes, I get an error [17:07:38 CET] <J_Darnley> Well, I'm surprised that the exact command you've shown doesn't just return an error. [17:07:50 CET] <J_Darnley> You've not set the frame size at all [17:09:07 CET] <monkkey> I'm sorry I delete it to simplify the question, here complete: [17:09:34 CET] <monkkey> ./opencvvehicletrack | ffmpeg -f rawvideo -pix_fmt gray -s 720x480 -i - -an out.avi [17:10:07 CET] <monkkey> Do you say that I should focus on size issues? [17:10:29 CET] <J_Darnley> Yes. [17:11:06 CET] <J_Darnley> It would appear that the output video is not exactly what it should be. [17:11:44 CET] <J_Darnley> Your other tool should be writing exactly 345600 bytes per frame [17:12:19 CET] <monkkey> ahhh I don't know that! [17:12:37 CET] <monkkey> Thanks!! [17:12:45 CET] <J_Darnley> How many bytes did you think were in a greyscale 720x480 frame? [17:13:30 CET] <monkkey> 345600 :D [17:14:21 CET] <monkkey> I didn't figure out counting the mat size [17:15:37 CET] <eightfold> J_Darnley: i tried: [17:15:43 CET] <eightfold> ffmpeg -ss 00:21:07.000 -to 00:38:22.000 -i input.mp4 -c copy output.mp4 [17:16:04 CET] <eightfold> but got: "Option to (record or transcode stop time) cannot be applied to input file"... [17:16:13 CET] <J_Darnley> Ah [17:16:30 CET] <J_Darnley> I guess you can't do that then [17:21:22 CET] <eightfold> J_Darnley: a good idea for a future i think. i have never come across a situation where i want "time from -ss". often times i think most people look up a time for start and one for end in an existing file. right now i use https://www.timeanddate.com/date/timeduration.html to calculate the time between... [17:22:35 CET] <J_Darnley> You can specify both those values in seconds if it help you at all. [17:24:04 CET] <J_Darnley> I must say that I often want to do only a short bit. I just give -t 10 (or whatever) in that case. [17:29:08 CET] <monkkey> the size is ok, I forget that I write to disk the output, and get an avi with the correct size [17:29:27 CET] <monkkey> May be the problem is how ffmpeg take the rawvideo? [17:31:34 CET] <monkkey> after hours, the "scroll" is vertical and horizontal... [17:32:02 CET] <guillaumekh> Hi all, looking for help :) Trimming audio files with -ss/-to genrerates a "click" sound at both ends of the file (see screenshot : https://www.dropbox.com/s/5wydz3zsspyzuj5/Screenshot%202016-02-19%2017.22.1…) Anyone familiar with this and ways to circumvent that ? The file is a 44kHz 16bit stereo PCM stream encoded in AAC LC 192kbps. [17:32:51 CET] <kepstin> guillaumekh: what's the full command? are you transcoding or using -c:a copy? [17:33:19 CET] <monkkey> Should I send between image and image a kind of separator byte? [17:33:22 CET] <kepstin> I would expect something that when trimming with copy, simply because of how lossy audio codecs work. [17:33:42 CET] <kepstin> monkkey: nope, raw input to ffmpeg is the raw binary bytes of each frame, right after eachother. [17:34:06 CET] <kepstin> it uses the input size and pixel format options to determine how many bytes to read. [17:37:51 CET] <cjbo> Hi! I'm thinking about a use of ffmpeg and would like to know about feasibility and hints. I want to split a video into two streams, one for left eye, another for right eye. Left eye would be 4x4 filtered stream of the original, where some squares are black, Right eye the complementary image. [17:38:21 CET] <J_Darnley> Sounds horrible for compression! [17:38:37 CET] <J_Darnley> At least make them macroblock sized. [17:39:10 CET] <cjbo> When viewed with a 3d viewer like bino and anaglyph glasses, the viewer must integrate both images in his brain to be able to view it. I want it to help my son's amblyopia, hope having explained myself enough [17:39:46 CET] <J_Darnley> As for doing that, I can't think of a simple way. Perhaps abusing a lut filter. [17:45:29 CET] <monkkey> yes, sorry my writting is horrible :( [17:46:15 CET] <monkkey> I do: matriz.height * matriz.width... and OK [17:46:38 CET] <monkkey> but, I count the bytes of the matrix and there is one more byte [18:09:57 CET] <podman> alright, i figured out how to install the nvidia drivers on an EC2 instance running ubuntu and got ffmpeg installed with nvenc. w00t [18:11:39 CET] <colde> Remember to make an AMI so you dont have to battle it again :) [18:11:52 CET] <podman> colde: yeah, actually about to do that! [18:12:22 CET] <podman> and then i use packer to install everything else on that base AMI and create a new AMI [18:12:24 CET] <podman> fun times [18:15:25 CET] <cjbo> a simpler question: I have a 4x4 checker board image file, I want to use it as a mask to an input video. Output video is visible only in white squares, black squares remain black.... [18:15:57 CET] <J_Darnley> Try the blend filter for that. [18:16:19 CET] <cjbo> J_Darnley: ok, thanks [18:16:50 CET] <J_Darnley> I still suggest bigger squares [18:16:59 CET] <jas99> Hi thr [18:17:46 CET] <J_Darnley> Unless you aren't planning on encoding the output with a typical codec. [18:18:50 CET] <jas99> Can I add misc data in any container [18:19:05 CET] <cjbo> J_Darnley: Well, I don't mind having quite large files. I want them as a some sort of eye exercise for lazy eye treatment. [18:19:19 CET] <J_Darnley> Typically no. As metadata, often. [18:19:43 CET] <jas99> hey thx for reply J [18:20:51 CET] <jas99> Not worked with metadata but can I have my own keys in key-value pairs in metadata?? [18:21:33 CET] <jas99> I guess muxing will be required [18:23:54 CET] <jas99> Hi guys [18:24:14 CET] <jas99> Anybody thr [18:24:16 CET] <J_Darnley> In formats which support it [18:24:59 CET] <jas99> oh really cool, does mkv one of them? [18:25:05 CET] <J_Darnley> I believe so. [18:25:14 CET] <jas99> nice thx mate [18:25:39 CET] <furq> -metadata foo=bar [18:26:06 CET] <jas99> fruq: oh cool thx very much mate [18:26:16 CET] <jas99> *furq [18:27:05 CET] <jas99> I was googling for another thing can I add presentation time PTS on frame manually? [18:27:24 CET] <jas99> i am using c++ [18:28:05 CET] <J_Darnley> You can control many things through the API [18:28:31 CET] <furq> can you control the thoughts of inferior species [18:28:32 CET] <J_Darnley> If you want to change timestamps then do it for whatever data structures you have. [18:28:41 CET] <furq> like "hu-mans" [18:29:03 CET] <jas99> but can't init the codec without setting framerate [18:29:12 CET] <jas99> lol [18:29:21 CET] <jas99> i second that [18:29:54 CET] <jas99> btw where are you guys from> [18:30:00 CET] <J_Darnley> .be [18:30:01 CET] <jas99> ? [18:31:10 CET] <jas99> .be?? [18:31:58 CET] <J_Darnley> it borders .fr, .nl, .de [18:32:16 CET] <furq> it's in .eu [18:32:31 CET] <DHE> some IRC clients have a /country command for easy reference to this kind of thing [18:32:35 CET] <furq> and also in .world [18:32:36 CET] <jas99> belgium? [18:32:55 CET] <J_Darnley> Congrats you triggered my highlighting [18:33:30 CET] <furq> do you get highlighted by belgium [18:33:38 CET] <J_Darnley> Yes [18:33:42 CET] <furq> that sounds like an innuendo [18:34:07 CET] <J_Darnley> belgian too I think [18:34:37 CET] <furq> my hostmask says i'm from belgium but i'm not really. it's an elaborate plot [18:34:42 CET] <furq> nobody will ever know where i'm from [18:34:59 CET] <J_Darnley> omg criminal scum [18:35:08 CET] <furq> that joke would work better in the channel where i mention it all the time [18:35:10 CET] <jas99> I love bitcoin [18:35:16 CET] <jas99> just random thought [18:35:38 CET] <jas99> i feel like speaking in jar [18:36:07 CET] <jas99> expect it talks back often useful info [18:39:12 CET] <jas99> so do i need to set framerate?? [18:39:37 CET] <J_Darnley> Usually no, the timing is done from timestamps [18:40:24 CET] <jas99> but my codec won't initiate and asks to set framerate [18:41:05 CET] <jas99> using ffv1 from api [18:42:23 CET] <J_Darnley> Should I state the obvious then? Set the framerate. [18:44:45 CET] <jas99> sorry for being dumb :( :( [18:45:00 CET] <jas99> inferior species [19:08:46 CET] <cjbo> J_Darnley: I'm doing it drawing black boxes with drawbox... can i specify relative sizes to match videos of any size? [19:11:52 CET] <J_Darnley> Check the docs to see if it supports expressions. [19:13:19 CET] <cjbo> https://ffmpeg.org/ffmpeg-filters.html#drawbox it mentions 'expressions' in the parameters, does that mean yes? [19:14:26 CET] <J_Darnley> yes [19:15:47 CET] <cjbo> ...so i think i'm able to put something like 'width/4' or similar? I beg for a hint o words to search.... [19:16:43 CET] <J_Darnley> The link you just gave gives you several varibales you can use yourself [19:16:56 CET] <J_Darnley> in_w and in_h [19:18:37 CET] <cjbo> J_Darnley: thx, i think i'm too old for this sh... ;-) [19:20:55 CET] <cjbo> I get only the last specified box... ffmpeg -i v1.mp4 -vf drawbox=0:0:160:80:color=black:t=max -vf drawbox=321:0:160:80:color=black:t=max -q:v 0 salida.mkv [19:21:41 CET] <J_Darnley> the next vf overrides the previous. [19:21:51 CET] <J_Darnley> join the two chains with a comma [19:22:04 CET] <cjbo> great! [19:52:44 CET] <rajkosto> yo why avcodec_decode_video2 return "invalid data found when processing input", im giving it one NAL(i tried both without 0x00000001 prefix and with) per invocation [19:52:51 CET] <rajkosto> h264 decoding [19:56:19 CET] <cjbo> J_Darnley: http://picpaste.com/captura-L8fjaDum.png [20:03:33 CET] <cjbo> J_Darnley: http://picpaste.com/captura2-W4vvu7eL.png [20:10:49 CET] <J_Darnley> Colourful [20:11:35 CET] <cjbo> J_Darnley: thats for the anaglyph... i'll try in a normal 3D television [20:30:24 CET] <rajkosto> playing the NAL frames with 0x00000001 prefix dumped to a .264 file works with mplayer [23:32:03 CET] <harej> I am trying to convert a file from MP4 to WebM. (Yes, compressed to compressed is not ideal, but it's what I have.) The source video is 720p. Despite setting high bitrate settings and setting the crf to 0 (!) I get these weird color splotch artifacts in the converted product. What setting should I change to avoid these? Are they unavoidable? [23:32:17 CET] <harej> These are the settings I am using: -cpu-used 4 -threads 16 -crf 0 -b:v 7M -c:a libvorbis [23:37:11 CET] <furq> -b:v 7M is overriding -crf [23:37:37 CET] <furq> you can use both with vpx, the -b:v value is the bitrate cap [23:37:58 CET] <furq> if you want a lossless encode then use -lossless 1 [23:41:01 CET] <harej> And it does it make sense to use lossless if my source material is compressed? Will I be rid of the annoying color splotches? [23:41:16 CET] <furq> well that's what people normally expect when they do -crf 0 [23:41:29 CET] <furq> i've never done a lossless vpx encode so i couldn't tell you [23:41:48 CET] <harej> And are there other settings you'd recommend? [23:41:59 CET] <furq> i'd just get rid of -b:v 7M for now [23:42:16 CET] <furq> that's probably not going to work well in conjunction with -crf 0 [23:42:35 CET] <furq> also make sure you're using vp9 and not vp8 (-c:v libvpx-vp9) [23:59:25 CET] <harej> furq, so I did the conversion and now I am free of the artifacts, but I find that the resulting output is not as high-quality as the source [23:59:34 CET] <harej> what can i do to preserve the 720p resolution? [00:00:00 CET] --- Sat Feb 20 2016

1 0