Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2017

1 participants
62 discussions

ffmpeg-devel.log.20170805
by burek 06 Aug '17

06 Aug '17

[00:05:16 CEST] <michaelni> thardin, i didnt follow the discussion but why do you need a mandatory option ? [00:11:26 CEST] <michaelni> AVOptions is a API to access C structs with introspection, enumeration, and much nicer forw/backw compatibility than direct struct access. It isnt the exclusive way to access (in general, it may be in specific cases), normal C style access can co-exist so its difficult for it to detect that a value has not been set except by a special default value [00:13:13 CEST] <michaelni> can you explain why using a NOT_SET value as default is worse than a flag ? [00:15:40 CEST] <michaelni> One could of course do both (flag and non valid default) and have the code check that both or neither occurs, not sure thats smethig you would prefer [00:15:53 CEST] <thardin> michaelni: raw codec2 streams need -mode specified to make sense of [00:16:23 CEST] <thardin> NOT_SET? didn't see that in there [00:17:08 CEST] <thardin> ah like the -1 suggestion from BBB. not perfect, but it does work [00:17:57 CEST] <thardin> with a flag you could make -h full a bit nicer [00:18:19 CEST] <michaelni> ahh, yes, for help text it would make sense [00:19:35 CEST] <thardin> a solution that doesn't require much logic is to just allow some extra help string [00:19:44 CEST] <thardin> for each class [00:19:52 CEST] <michaelni> btw i realize now we already have mandatory options, like width / height for raw video [00:20:10 CEST] <thardin> so I could put in my codec2raw_demux_class .extra_help = "option -mode is mandatory" [00:21:07 CEST] <michaelni> adding a flag should be super easy if you want, it just would still need the default value invalid and wouldnt do anything besides afecting the help text [00:21:43 CEST] <thardin> it would be nice not to have to expand the range of "legal" values [00:22:06 CEST] <thardin> including checks for them. but that's more a "nice to have" [00:27:26 CEST] <michaelni> you could add a av_opt_validate() that checks that all options are set (not invalid) in a struct. and then call that from the avfilter / avcodec / avformat core. I might be forgetting something but i think theres no existing code that gets executed from avoptions after all is set that could check easily [00:28:19 CEST] <michaelni> av_opt_validate() could print a message / warning for not set mandatory options [00:28:30 CEST] <michaelni> and return an error [00:29:03 CEST] <thardin> right, just before init() is called or so [01:54:22 CEST] <ZeroWalker> still having problems with swscale. I think it should be all fine, i get a packet and have the format context, which should have all the data i need. I basically just do av_image_fill_arrays and align to 1 (for safety), but still it fails. The destination is allocated with the resuled format size [01:54:42 CEST] <ZeroWalker> http://paste.awesom.eu/xVkm [02:07:02 CEST] <DHE> email to the list is still the way for patch submissions? [02:07:22 CEST] <JEEB> yes [02:13:44 CEST] <DHE> man I hope I don't botch this... [02:32:32 CEST] <DHE> tfw a patch takes a feature away and didn't fix the documentation when it did it [02:36:22 CEST] <ZeroWalker> No ideas, not missing anything obvious;o? [02:38:34 CEST] <DHE> "tfw" is one of those meme things. but it did happen [02:39:39 CEST] <DHE> intentionally presented as though the original patch was bad in both concept and execution, partially because I personally don't like taking that feature away. [10:39:58 CEST] <cone-138> ffmpeg 03Paul B Mahol 07master:c47491041466: doc/filters.texi: add yet another laplacian edge detector [17:29:43 CEST] <durandal_1707> what about if i write lavfi edit preview app in qt? [17:33:03 CEST] <atomnuker> gtk or death [17:33:23 CEST] Action: JEEB inserts a goject into atomnuker [17:33:26 CEST] <JEEB> *gobject [17:33:36 CEST] <durandal_1707> death? [17:34:37 CEST] <atomnuker> JEEB: gobject or not, it still looks the best, supports the most platforms and backends and won't kill you with dependencies [17:34:58 CEST] <JEEB> have you looked at GTK+ text boxes in windows? [17:35:14 CEST] <atomnuker> they can't be worse than wx or qt [17:35:26 CEST] <JEEB> I'm not saying it won't work but non-*nix is very much a non-priority for GTK+ [17:35:36 CEST] <JEEB> so it really depends on one's priorities [17:35:46 CEST] <JEEB> and yes, wxwidgets is awful, and Qt is also awful in a different way [17:36:11 CEST] <JEEB> but so far for me Qt's awful emulation of native is the least awful. but that's just my experience and opinion [17:36:37 CEST] <JEEB> gtk+ is very good on *nix and if you don't care about anything else it's a good selection since most DEs base on GTK+ or similar [17:40:30 CEST] <durandal_1707> i will use qt [17:50:15 CEST] <JEEB> yea, I didn't expect random comments on the internets to sway you :D [18:25:52 CEST] <iive> just don't make ffmpeg depend on qt [18:28:57 CEST] <nevcairiel> gtk apps look terrible pretty much anywhere, they just blend into the uglyness of full gtk desktops so people dont notice. at least wx uses native widgets on windows =p [18:29:53 CEST] <BtbN> wx is just broken in general [18:30:04 CEST] <BtbN> After seeing the dolphin guys rage about it, I wouldn't want to touch it [18:30:13 CEST] <iive> link? [18:30:30 CEST] <BtbN> dolphin-emulator. GameCube/Wii emu [18:30:51 CEST] <JEEB> yea, Myrsloik also handles wx [18:31:08 CEST] <JEEB> there's plenty of stuff about how awful its "write once, debug everywhere" ratio is [18:31:45 CEST] <JEEB> Aegisub the subtitle editor went for wx back in the day which might have been a good idea then. [18:36:54 CEST] <Compnn> i'm probably the only one that doesnt care about gtk / qt... :P [18:49:15 CEST] <Blubberbub_> I like Tk. But i've only ever used it from Python, so... [18:50:06 CEST] <JEEB> Compn: it's generally not that people care so vehemently about the framework itself, but as you gain experience in where they work and don't work you start getting an opinion. of course, if stuff just works for the use cases you need on the systems you care about - there really is no discussion about anything in that case. [18:51:54 CEST] <Compn> i was just talking about the uglyness [18:52:16 CEST] <Compn> which i understand if its not brushed metal and clear fonts... people have a fit [19:04:11 CEST] <JEEB> I remember someone mentioning that the post/pre incrementing in loops is a C++ thing? was there a thing written about that somewhere? [19:05:43 CEST] <JEEB> https://google.github.io/styleguide/cppguide.html#Preincrement_and_Predecre… [19:05:46 CEST] <JEEB> ah [21:10:22 CEST] <cone-093> ffmpeg 03Paul B Mahol 07master:2cc56741b1f4: avfilter: add floodfill filter [23:24:36 CEST] <cone-093> ffmpeg 03James Cowgill 07master:013ec23cbe5d: swscale: fix gbrap16 alpha channel issues [23:24:37 CEST] <cone-093> ffmpeg 03Steven Siloti 07master:949debd1d1df: avformat/utils: fix memory leak in avformat_free_context [00:00:00 CEST] --- Sun Aug 6 2017

1 0

ffmpeg.log.20170805
by burek 06 Aug '17

06 Aug '17

[05:21:37 CEST] <Ch3ck> Is there any ffmpeg go library? [05:22:03 CEST] <Ch3ck> I"m working on a video downloader, so I'll need some video processing and conversions to mp3 format [05:22:11 CEST] <Ch3ck> I think ffmpeg will be a good choice here [05:25:19 CEST] <furq> not really [05:31:07 CEST] <Ch3ck> furq, what do you mean? [05:31:14 CEST] <Ch3ck> Tell me more [05:31:48 CEST] <furq> i mean there isn't any ffmpeg go library [05:32:03 CEST] <furq> all the ones that i know of are incomplete and/or abandoned [05:32:13 CEST] <furq> like most (all?) ffmpeg bindings [05:33:05 CEST] <furq> i expect anyone doing video processing stuff is just invoking ffmpeg or just binding the specific lavc/lavf functions that they need [05:33:30 CEST] <Ch3ck> furq, I see [05:33:44 CEST] <Ch3ck> Just found some stuff on github, but like you said they're no longer maintained [05:33:53 CEST] <furq> yeah and the api changes a lot [05:34:07 CEST] <furq> granted you'd probably want to static link that and ship binaries [05:34:07 CEST] <Ch3ck> Guess I might have to use 'cgo' in this case [05:34:17 CEST] <furq> does this video downloader do anything that youtube-dl doesn't [05:34:29 CEST] <Ch3ck> I just want to write something in native Go [05:34:37 CEST] <Ch3ck> furq, youtube-dl is python [05:34:53 CEST] <furq> if you're just doing it as a learning exercise then just invoke ffmpeg [05:34:58 CEST] Action: Ch3ck python sucks! [05:35:08 CEST] <furq> it does suck, but youtube-dl is good [05:35:27 CEST] <Ch3ck> furq, Yeah, I'm just experimenting implementing something like that in Go [05:35:36 CEST] <furq> youtube-dl invokes ffmpeg [05:35:41 CEST] <Ch3ck> besides "youtube-dl" is a seemingly old project [05:35:48 CEST] <furq> nah it's still pretty active [05:35:54 CEST] <furq> that's the gold standard really [05:36:01 CEST] <Ch3ck> Yeah, so I've hard [05:36:04 CEST] <Ch3ck> *heard* [05:36:29 CEST] Action: Ch3ck is thinking of may be starting a go binary support for ffmpeg [05:36:42 CEST] <Ch3ck> *binding* support for ffmpeg [05:36:49 CEST] <furq> for a lot of videos (hls/dash) ytdl just finds the playlist/manifest url and and invokes ffmpeg [05:36:53 CEST] <furq> it doesn't even download the video itself [05:37:22 CEST] <Ch3ck> furq, I have no experience with ffmpeg [05:37:24 CEST] <furq> most of the hard work is taking a video page url and figuring out where the video is [05:37:37 CEST] <Ch3ck> yeah, I guess so [05:37:48 CEST] <Ch3ck> But it'll be a learning experience for sure [05:38:07 CEST] <furq> not to discourage you from writing bindings, because i'd like to see some decent ones [05:38:11 CEST] <Ch3ck> furq, any links to some beginner docs [05:38:15 CEST] <furq> for ffmpeg? [05:38:20 CEST] <furq> not really [05:38:24 CEST] <Ch3ck> Yep [05:38:30 CEST] <Ch3ck> For ffmpeg [05:38:30 CEST] <DHE> seconding youtube-dl being awesome [05:38:40 CEST] <furq> https://ffmpeg.org/ffmpeg-all.html [05:38:44 CEST] <furq> nothing more beginner-friendly than that [05:38:47 CEST] <Ch3ck> lol [05:38:52 CEST] Action: Ch3ck opens link [05:39:01 CEST] <furq> https://ffmpeg.org/documentation.html [05:39:11 CEST] <furq> you probably want the split version on there [05:39:15 CEST] <DHE> ffmpeg-all is great for being able to just CTRL+F for anything you need... [05:39:17 CEST] <furq> yeah [05:40:15 CEST] <Ch3ck> I'll take a look at this tomorrow [05:40:20 CEST] <Ch3ck> It's been a long day coding [05:40:40 CEST] <Ch3ck> Just need something to do the hard work of decoding and stuff for me [05:40:47 CEST] <Ch3ck> ffmpeg should work fine [08:02:31 CEST] <xacktm> hey guys, I'm having trouble with nvenc on my gtx 1060 - get a "Cannot init CUDA" for latest HEAD source - any ideas? https://bpaste.net/show/b6dc126a1354 [08:57:16 CEST] <xacktm> this forum post looks like the same issue as me, but no leads https://devtalk.nvidia.com/default/topic/740805/linux/nvenc-h-264-encoder-i… [11:12:38 CEST] <PaoloP> Given an audio stream sampled at 44100, mono, which is the minimum playback latency (alsa)? [11:12:44 CEST] <PaoloP> (non-realtime) [12:51:01 CEST] <DavidGG> hello, i have a command like this to inject 2 image as watermark to video : /usr/bin/ffmpeg -i ori.mp4 -y -i 1.png -i 2.png -filter_complex "[0:v][1:v]overlay=20:20[bkg];[bkg][2:v]overlay=(main_w-overlay_w)-20:(main_h-overlay_h)-20" -codec:v libx264 -crf 18 -preset slow -pix_fmt yuv420p -c:a aac -strict -2 out.mp4 it work great on large width video. problem come when the video size is 320x240. the watermark is large as half of video [12:52:10 CEST] <DavidGG> https://pastebin.com/jkx0Vx99 [12:52:41 CEST] <BtbN> so, scale the watermark first [12:53:26 CEST] <DavidGG> how to scale [12:53:31 CEST] <BtbN> with the scale filter. [12:53:58 CEST] <BtbN> Or any image editing program of your choice beforehand [13:37:31 CEST] <DavidGG> found scale2ref but no idea how to get it work with above command [14:07:03 CEST] <DavidGG> any help? [14:08:34 CEST] <DavidGG> https://stackoverflow.com/questions/45521436/ffmpeg-scale-logo-size-accordi… [14:38:43 CEST] <luc4> Hello! Im experimenting with h264_videotoolbox but I see it is not possible to set a crf option. What would be a good way to set the quality of the result? [14:39:55 CEST] <JEEB> crf is something that comes out of the libx264 encoder, so naturally nothing else really has it [14:40:17 CEST] <luc4> JEEB: I see, but isnt there anything equivalent? [14:40:25 CEST] <JEEB> no idea, check the available AVOptions [14:40:49 CEST] <luc4> JEEB: I cannot find a list. Can I get it somehow? [14:40:57 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/videotoolboxenc.c#L… [14:41:06 CEST] <BtbN> it seems to be hardcoded into ABR mode [14:41:08 CEST] <JEEB> there was a help option to list them [14:41:17 CEST] <JEEB> but I don't remember how it went :P [14:41:22 CEST] <JEEB> but yea, looking at the code is also fast [14:41:36 CEST] <BtbN> it uses the normal bitrate and max_rate options [14:41:46 CEST] <BtbN> That seems to be all the control over the bitrate it gives you [14:42:37 CEST] <luc4> BtbN: so I should see what bitrate decides libx264 for a specific crf and set the same with h264_videotoolbox? [14:42:53 CEST] <BtbN> libx264 does not decide on a bitrate in crf mode. [14:43:02 CEST] <BtbN> vtenc does not have a constant quality mode [14:44:03 CEST] <JEEB> also different encoders have completely different compression ratios [14:44:35 CEST] <JEEB> so you will not get the same quality with the same bit rate with VTB [14:44:39 CEST] <luc4> JEEB: which means& the only way I have is to set a random bitrate? [14:44:59 CEST] <JEEB> you come up with a bullshit bit rate and get a bullshit result [14:45:37 CEST] <luc4> JEEB: no bitrate set -> result horrible [14:45:51 CEST] <luc4> JEEB: maybe I can try with a higher bitrate? [14:47:52 CEST] <JEEB> I think the libavcodec default is like 200kbps :P [14:49:47 CEST] <luc4> JEEB: similar video with crf 22 is around 12000kbps [14:50:29 CEST] <luc4> Ill try something like that [19:14:02 CEST] <leeaandrob> hello, so I have a little question, it's possible transcode two files on same time with only a single core processor? [19:14:13 CEST] <npn> Hi. I have a series of mp4 training videos. I would like to serve them up to our users, but dynamically watermark each one with the user's login name. The best I can come up with right now is that each time a new user subscribes, we encode the entire list of mp4s with the watermark and store them for some period to serve him - that doesn't seem ideal. Would rather do it dynamically and live. Any ideas? [19:27:56 CEST] <iive> npn waited whole 10 minutes.... [19:30:44 CEST] <amey> npn: The videos you are serving are for download or to watch online only? [19:32:09 CEST] <iive> either way, if he wants a watermark that cannot be easily removed, he has to embed it into the video [19:32:24 CEST] <iive> and this means recoding for each user. [19:37:50 CEST] <andai> so I'm adding -strict -2 but i keep getting the message that I need to add -strict -2 [19:38:45 CEST] <andai> oh i see. needs to be before last argument [19:38:47 CEST] <durandal_1707> andai: order is important [19:38:52 CEST] <andai> is there any reason for that [19:49:08 CEST] <leeaandrob> hello, so I have a little question, it's possible transcode two files on same time with only a single core processor? [19:52:23 CEST] <JodaZ> of course, speed will be a little bit under half for each of the two transcodes if you run them at the same time [19:56:19 CEST] <leeaandrob> How is calculate the time from a transcoder? If i have a single core how many threads can i use? @JodaZ? [19:57:47 CEST] <JodaZ> leeaandrob, you can use as many threads or processes as you want, but you will not gain any advantage from using more than one [19:58:45 CEST] <leeaandrob> hmmm understood.. I am building a Sass to transcoder and streaming videos on demand using hls but my pain it's how i will transcoder the files.. [19:58:50 CEST] <leeaandrob> @JodaZ [19:59:23 CEST] <JodaZ> saas? [20:04:32 CEST] <JodaZ> producing on demand hls segments is a unsolved problem as of now [20:08:27 CEST] <JEEB> not really, there are vendors doing that [20:08:38 CEST] <JEEB> in OSS even there's a base for that [20:08:42 CEST] <leeaandrob> yes.. hls is it good for solve problems videos on demand? [20:08:59 CEST] <JEEB> nginx-rtmp contains on-demand HLS and DASH conversion from a live stream [20:09:24 CEST] <leeaandrob> I am building a product for the ead but are will used on Brazil :) [20:09:26 CEST] <JEEB> so in theory as a problem it's solved, it's just that nobody has wanted to make their thing open source [20:09:37 CEST] <JodaZ> JEEB, continuous segmenting is trivial, issue is if you want to seek [20:09:51 CEST] <JEEB> JodaZ: you have an index of the segments [20:09:59 CEST] <JEEB> then convert to Annex B/AVCc as needed [20:10:04 CEST] <leeaandrob> I am working and I made a partner on area EAD and Together We will building a product Sass to solve the problem of the on demand. [20:10:07 CEST] <JEEB> and mux into isobmff or hls [20:10:37 CEST] <JodaZ> JEEB, in theory its not difficult, in practice there is no software that allows you to live transcode just "segment 5" of some source video [20:10:57 CEST] <JEEB> transcode, no. we're talking about segmenting into formats of an already available video stream [20:11:10 CEST] <JEEB> serving media and transcoding are two separate things IMHO [20:11:38 CEST] <JodaZ> segmenting is just seeking to the nearest ts boundary [20:12:11 CEST] <JEEB> yes, as long as you have a database of segments and their start timestamp you should be a-OK [20:12:12 CEST] <leeaandrob> I will use AWS solutions, [20:12:45 CEST] <leeaandrob> I was using Elastic transcoder but the same was expensive :( [20:13:34 CEST] <JodaZ> i wish there was a all in one solution to transcode and segment in one [20:17:07 CEST] <JEEB> I really think it's worth separating those two [20:18:29 CEST] <JodaZ> well, if you could you'd finally have live transcoding with seeking natively in most browsers [20:19:00 CEST] <JEEB> live transcoding is something you generally only want to do for live sources [20:19:20 CEST] <JEEB> and then you feed that transcoded stuff into a thing that will package as required to actual watchers [20:19:33 CEST] <JodaZ> in professional broadcasting, yes, but if you want to access your own dvd library on your homeserver... [20:20:06 CEST] <JEEB> in that case you might almost just be remuxing and pushing to client [20:20:18 CEST] <JodaZ> often enough, yes [20:20:18 CEST] <JEEB> and in that case you would have the things already on your server and indexed [20:20:39 CEST] <JodaZ> aac audio isn't supported by most browsers tho [20:20:49 CEST] <JEEB> that's actually most supported I think now :P [20:21:12 CEST] <JEEB> firefox does it with either MF, macos framework or libavcodec, chromium does it with libffmpeg.so, mobiles do it [20:21:31 CEST] <JodaZ> hmm, one of the codecs i encounter typically isn't supported [20:21:42 CEST] <JEEB> mp3 in mp4 might not be supported often [20:21:45 CEST] <JEEB> or something like that [20:21:46 CEST] <JodaZ> whats bluray use again? [20:21:58 CEST] <JEEB> raw PCM often, TrueHD/DTS are the other ones [20:23:06 CEST] <JodaZ> oh yeah, DTS is the one [20:23:30 CEST] <furq> you're probably thinking of ac3 [20:23:36 CEST] <JodaZ> or that [20:23:46 CEST] <JodaZ> example i just hit had DTS [20:23:49 CEST] <furq> ac3 is what you almost always get on dvds [20:25:54 CEST] <leeaandrob> so hls is not a good solution? [20:26:08 CEST] <leeaandrob> for the streaming on browsers? [20:26:29 CEST] <leeaandrob> I a builded a solution using, elastic transcoder, s3 and cloud front on aws. [20:27:18 CEST] <DHE> are you also dealing with multiple bitrates/qualities? [20:27:37 CEST] <furq> hls is the only real solution for livestreaming on browsers [20:27:59 CEST] <furq> but for vod you might as well just use a single mp4 [20:28:23 CEST] <furq> the big sites only use hls/dash for vod because it makes it easier to use a cdn [20:32:45 CEST] <JodaZ> leeaandrob, no, the issue is only that you have to transcode in advance [20:32:54 CEST] <JodaZ> leeaandrob, if you do that, its all trivial [20:33:14 CEST] <JodaZ> you just have to loadbalance the transcoding and do cdn [20:33:25 CEST] <leeaandrob> yes, thats the ideai JodaZ [20:33:37 CEST] <leeaandrob> but what do your opinion about other codecs? [20:33:43 CEST] <leeaandrob> exists other solutions better that hls? [20:34:47 CEST] <JodaZ> no, as furq said, hls/dash are the de-facto solution [20:36:08 CEST] <leeaandrob> thanks JodaZ :) I will start mabye monday the development and I will bring news here :) [21:31:39 CEST] <Tzimmo> How to find out which subtitle formats ffmpeg can convert to which other format? Is that documented somewhere? I haven't been able to find such information. [21:32:51 CEST] <JEEB> generally subtitles (text based) are converted into ASS as internal format, and then that internal format gets converted to some other subtitle (text) format, and then finally the muxers support certain avcodec values [21:33:28 CEST] <JEEB> so easiest to see the end result is by checking the list of supported a/v/s formats for that container in the code (I don't think there's an interface yet to list the supported things for a container format) [21:33:45 CEST] <JEEB> using the API you should be able to create such lists and check against them [21:34:04 CEST] <Tzimmo> So basically mostly text->text? And very restricted (if almost any) bitmap->bitmap? [21:34:57 CEST] <JEEB> yea, I don't think people have tested/thought too much of bitmap to bitmap [21:35:00 CEST] <Tzimmo> $ ffmpeg -i outdir/00800.track_4608.sub -map 0:0 -scodec dvbsub foo.sub [21:35:06 CEST] <Tzimmo> Stream mapping: Stream #0:0 -> #0:0 (dvd_subtitle (dvdsub) -> dvb_subtitle (dvbsub)) [21:35:09 CEST] <Tzimmo> Could not write header for output file #0 (incorrect codec parameters ?): Operation not permitted [21:35:29 CEST] <JEEB> yup, and the actual error is somewhere up from that last message [21:35:38 CEST] <Tzimmo> it looks so good and quite simple operation because there is dvbsub encoder and dvdsub decoder but still... or which extension should I use? [21:36:07 CEST] <Tzimmo> [microdvd @ 0x2c71020] Exactly one MicroDVD stream is needed. [21:36:23 CEST] <Tzimmo> mmm... did I provide more than one? [21:36:29 CEST] <JEEB> no, probably none [21:36:49 CEST] <JEEB> I mean, you want dvbsub but it picked the "container" as MicroDVD subtitles which is a text format thing [21:36:58 CEST] <JEEB> it probably probed that the input is dvdsub [21:37:01 CEST] <Tzimmo> Ah, true, so extension is wrong... [21:37:19 CEST] <Tzimmo> Any idea which extension (if any) could be used for dvbsub? [21:37:19 CEST] <JEEB> I'm not sure if you can even write dvb subs into a separate file :P [21:37:24 CEST] <JEEB> I'd just put them into mpeg-ts or something [21:37:37 CEST] <JEEB> since that's how you usually use DVB subtitles [21:37:47 CEST] <Tzimmo> true... -> foo.m2ts did something [21:38:07 CEST] <Tzimmo> I have written software to OCR dvb subtitles and it works perfectly. [21:38:44 CEST] <Tzimmo> I was trying to avoid writing dvd subtitle or bd subtitle reader to it if I could just convert dvd subtitle into dvb subtitle and just use what I already have. [21:39:11 CEST] <JEEB> yea, there's no in-built stuff like that. usually what you'd do in an API client is that you'd use libavcodec to decode to a subpicture, and then you OCR and write a subtitle "frame" out of the result [21:39:40 CEST] <JEEB> also wasn't DVD/DVB/teletext subtitle stuff "fun" in the way that you don't necessarily know the duration of the subtitle - you just need to wait until the next packet in that case [21:40:45 CEST] <Tzimmo> Could be... I have usually used projectx to extract DVB subtitles into .son format (better than the other alternative there) and then I read that format and do OCR there. [21:41:13 CEST] <Tzimmo> But projectx cannot handle HD formats or BD so it doesn't work too well there. [21:41:29 CEST] <JEEB> I think subtitle edit had some OCR capabilities built-in? [21:41:37 CEST] <Tzimmo> Is it command line tool? [21:41:37 CEST] <JEEB> for DVD/BD [21:41:44 CEST] <JEEB> not sure if it had an interface for that [21:41:51 CEST] <Tzimmo> I know some GUI tools but I want this to be repeatable process easily. [21:42:02 CEST] <JEEB> yea I get that :) [21:42:48 CEST] <JEEB> but yea, dealing with files where you can go through the whole thing is nice [21:42:54 CEST] <Tzimmo> I was actually loading subtitleedit web page while asking these questions because there was some network lag but now it opened. [21:42:57 CEST] <JEEB> live input tends to be a bit less simple [21:43:13 CEST] <JEEB> esp. if the subtitle format doesn't have the duration field necessarily [21:43:26 CEST] <JEEB> (and you want to OCR/use the text from that subtitle to convert into text) [21:44:19 CEST] <Tzimmo> subtitleedit looks like Windows-only tool...? [21:44:35 CEST] <JEEB> could be, I didn't check if they ran on mono [21:44:38 CEST] <Tzimmo> "Note: SE requires Microsoft .NET Framework Version 4.0 or later" [21:45:41 CEST] <Tzimmo> My TV fails with most bitmap based subtitles every now and then... like when watching m2ts bluray format, it shows like 60% of the subtitles but loses about half. [21:45:46 CEST] <Tzimmo> At random. :( [21:45:56 CEST] <JEEB> mine fails at mp4 timed text [21:46:04 CEST] <Tzimmo> So when you watch it again, you may see different subtitles being showed and omitted. [21:46:05 CEST] <JEEB> I can randomly get some random memory locations [21:46:07 CEST] <JEEB> on the screen [21:46:55 CEST] <Tzimmo> And for dvb subtitles it shows usually the first line there but the second line is below the screen... only topmost pixels of the second line fit on screen. :( [21:47:19 CEST] <JEEB> sounds like you cropped the video ;) [21:47:23 CEST] <Tzimmo> Using mplayer or mpv or vlc or anything on computer shows those subtitles fine, but TV fails with their position somehow. [21:47:38 CEST] <JEEB> because image based subtitles usually have the canvas size there [21:47:53 CEST] <JEEB> usually happens with blu-ray subtitles when people download random 720p or whatever rips [21:48:10 CEST] <JEEB> so the location of the subpictures is 100% correct but the canvas size is larger than video size [21:48:21 CEST] <Tzimmo> The video doesn't seem to lose anything. Just the TV renders the subtitle in DVB format (unless I burn them to the picture) too low. [21:49:16 CEST] <Tzimmo> The source for those DVB subtitles comes from the official TV channels. [21:49:33 CEST] <JEEB> yes, but if you've then poked the video to mismatch the canvas [21:49:33 CEST] <Tzimmo> I have to convert them to DVD subtitles in order to make them fit on screen. [21:49:58 CEST] <Tzimmo> I don't touch video or audio. [21:50:03 CEST] <JEEB> (of course there can be other bugs in plastic toys but generally it's a canvas mismatch when such things happen [21:50:30 CEST] <Tzimmo> Or even subtitles when I just try to use the original file. But after subtitle conversion (without touching video or audio) to DVD subtitles they are visible on screen. [21:51:11 CEST] <JEEB> yea, what I mean is that if you downloaded some blu-ray rip with 1920x8xx resolution for example. and then the subpictures that come with it of course are planned to be shown on a 1920x1080 canvas [21:51:25 CEST] <JEEB> and since usually the canvas in a lot of renderers starts from top left corner [21:51:34 CEST] <JEEB> you can often get stuff out of the screen at the bottom :P [21:52:13 CEST] <JEEB> of course if it's your original sources then that's not it [21:52:30 CEST] Action: JEEB has just seen way too many of those mismatching things on the internet [21:52:44 CEST] <Tzimmo> I haven't downloaded any from any unofficial sources. [21:52:59 CEST] <Tzimmo> Just from DVB-T/DVB-T2, Bluray discs or DVDs. [21:53:32 CEST] <Tzimmo> So at least some of the originals should be correctly done. [21:54:28 CEST] <durandal_1707> you are doing illegal stuff [21:54:57 CEST] <Tzimmo> But it seems that if I want to automate this, I have to read/parse HDMV PGS and/or DVD subtitles myself. [21:55:10 CEST] <JEEB> you can use libavformat/libavcodec for that [21:55:21 CEST] <JEEB> then you get RGB subpictures with timing [21:55:26 CEST] <Tzimmo> durandal_1707: Yes, decrypting DVD/BD can be seen illegal. [21:55:42 CEST] <JEEB> then the subpicture I would probably push to some OCR library [21:57:27 CEST] <Tzimmo> I tried to use gocr for those bitmaps but I got too bad results with it. It didn't understand a "line" of text, so some "'" in the lower line became "," for the upper line, it didn't always support scandinavian characters too well, and even when I tried to restrict the character set to use [21:57:32 CEST] <Tzimmo> -c string - list of chars (_ = not recognized chars, debug) [21:57:34 CEST] <Tzimmo> -C string - char filter (ex. hexdigits: 0-9A-Fx, only ASCII) [21:57:58 CEST] <Tzimmo> to restrict the character set, it still gives me for example í (i + '), á (a + '), etc [21:58:05 CEST] <durandal_1707> tesseract? [21:58:17 CEST] <Tzimmo> so it combines the "," from the upper line with "aeiou" from the lower line. [21:58:45 CEST] <Tzimmo> What is tesseract? [21:58:56 CEST] <durandal_1707> ocr lib [21:59:58 CEST] <Tzimmo> durandal_1707: Thanks, haven't tried that out... [00:00:00 CEST] --- Sun Aug 6 2017

1 0

ffmpeg-devel.log.20170804
by burek 05 Aug '17

05 Aug '17

[00:05:28 CEST] <J_Darnley> Does anyone here have any first hand experience with the Intel Atom C2750 cpu, in particluar with its performance? [00:16:11 CEST] <rcombs> spoilers: it's bad [00:17:15 CEST] <rcombs> I say with confidence by the data points (a) it's from 2013 and (b) you said "Atom" [00:21:39 CEST] <J_Darnley> I thought that too [00:22:08 CEST] <J_Darnley> but since all my other CPUs are so old I went looking for a comparison [00:22:16 CEST] <J_Darnley> https://www.cpubenchmark.net/compare.php?cmp[]=772&cmp[]=2185&cmp[]=1049 [00:24:38 CEST] <jkqxz> Expect IPC something like 1/3 that of a modern Intel high-power core. [00:24:48 CEST] <jkqxz> (From Silvermont.) [00:26:00 CEST] <jkqxz> Those ones don't have graphics either, which does work reasonably well with quick sync stuff on similar chips. [00:26:03 CEST] <jkqxz> I think they are only of value if the SoC I/O is useful to you. [00:28:05 CEST] <J_Darnley> Good point. [00:30:06 CEST] <jkqxz> That range were basically supplanted by Broadwell-D, anyway - running the larger cores a bit slower ends up better overall when it's not being sold into a market which wants the cheapest possible (i.e. smallest and least complicated) chip that you can make. [00:32:48 CEST] <cone-259> ffmpeg 03Yogender Gupta 07master:2e8679373ab6: hwupload_cuda : Add 10/16 bit format support [00:32:49 CEST] <cone-259> ffmpeg 03Yogender Gupta 07master:3407d8118c72: hwcontext_cuda : Support YUV444P16 format [00:33:42 CEST] <J_Darnley> Hm. I shouldn't be so cheap and spend more on a motherbard fora ryzen. [00:34:08 CEST] <J_Darnley> Some of those Atom boards cost a bomb anyway [01:54:48 CEST] <cone-259> ffmpeg 03Muhammad Faiz 07master:f2d23ec03f28: avfilter/vf_ssim: fix temp size calculation [11:24:08 CEST] <JEEB> rcombs: had you looked at webvtt in isobmff yet? [11:24:35 CEST] <rcombs> briefly [11:24:51 CEST] <JEEB> it seems to be a bit less insane than ttml in isobmff [11:24:58 CEST] <rcombs> basically enough to decide that it's way more trouble than it's worth, and potentially altogether impractical to implement in a manner that round-trips properly [11:24:59 CEST] <JEEB> although the overlap handling is kind of meh [11:26:07 CEST] <JEEB> (probably because isobmff doesn't let you do multiple samples with overlapping times) [11:26:18 CEST] <rcombs> yeah [11:26:39 CEST] <rcombs> the overlap handling is annoying but not unworkable [11:26:49 CEST] <rcombs> it's the event extensions that are really bad [11:26:59 CEST] <rcombs> like, starting an event in one sample, and continuing it into the next [11:27:12 CEST] <JEEB> continuation-cues etc? [11:27:21 CEST] <rcombs> it means you can't emit a packet until you've read the _next_ sample to check if it contains an extension [11:27:23 CEST] <rcombs> yeah, those [11:27:31 CEST] <JEEB> yea, that's what I meant with the overlap stuff [11:27:31 CEST] <rcombs> I forget the terminology [11:27:46 CEST] <rcombs> yeah, I guess it's all part of the same thing [11:27:57 CEST] <rcombs> ultimately the whole thing is completely useless [11:28:08 CEST] <rcombs> there's no use-case where you're not better-off just using text files [11:29:47 CEST] <rcombs> it ends up bigger despite WebVTT's considerable timestamp-header-text overhead, _and_ it's way more complex to parse [11:29:58 CEST] <JEEB> yea [11:30:07 CEST] <rcombs> and it's not like people want to mux it alongside other tracks [11:31:11 CEST] <JEEB> there's some insanity related to it with regards to live streaming [11:31:23 CEST] <JEEB> but yea, I'm totally thinking how to make it off-band if only possible [11:33:04 CEST] <rcombs> don't people only want this in DASH, which only ever has one track per segment file [11:33:59 CEST] <rcombs> I ended up just telling the people asking me for this to use libjass [11:34:03 CEST] <rcombs> which is what they were already doing anyway [11:35:39 CEST] <JEEB> well, HLS and DASH it seems [11:36:02 CEST] <JEEB> also lol libjass, I wonder how to do live subtitles with that [11:36:17 CEST] <rcombs> you can feed it lines live [11:36:33 CEST] <JEEB> also then you'd have to implement something similar in mobile clients etc [11:36:48 CEST] <JEEB> while TTML/WebVTT seems to be already implemented [11:36:56 CEST] <JEEB> even if shit on a stick sandwich [11:37:00 CEST] <JEEB> why is this stuff like this ;_; [11:37:31 CEST] <rcombs> I guess; Android's ExoPlayer has support for generic WebVTT text files and HLS supports WebVTT-in-HLS (which is also just text files) [11:37:43 CEST] <JEEB> yea [11:38:09 CEST] <JEEB> which is where the "let's see if we can get by with just separate files" comes into play [11:47:59 CEST] <cone-142> ffmpeg 03Paul B Mahol 07master:80bc648e7797: avfilter: add tlut2 filter [15:34:18 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07release/3.1:fef71d661b7a: Update for 3.1.10 [15:53:28 CEST] <cone-077> ffmpeg 03Michael Niedermayer 07release/3.1:afa34cb36edc: RELEASE: Update release number [16:09:04 CEST] <cone-077> ffmpeg 03Steven Liu 07master:738b29cfb69b: avformat/hlsenc: support fmp4 single file mode [16:10:58 CEST] <cone-077> ffmpeg 03Steven Liu 07n3.1.10:HEAD: avformat/hlsenc: support fmp4 single file mode [16:21:26 CEST] <cone-077> ffmpeg 03Steven Liu 07master:44e9783ab9a1: doc/libav-merge: remove the hls merge TODO [17:07:16 CEST] <durandal_1707> people consider dnxhd frame threading useful [17:14:31 CEST] <atomnuker> its intra only so it works best there [18:35:56 CEST] <BBB> TD-Linux: how does av1 solve the problem of not being able to combine tile row threading and frame threading? [23:04:09 CEST] <thardin> bluh, battling AVOptions [23:05:15 CEST] <thardin> I somehow managed to get -h full into an infinite loop [23:10:36 CEST] <nevcairiel> dont re-use the same class for multiple things [23:10:43 CEST] <nevcairiel> otherwise that happens [23:10:50 CEST] <thardin> so I noticed [23:11:17 CEST] <thardin> AV_OPT_TYPE_CONST is still giving me grief. or maybe ffprobe doesn't print encoder options [23:14:55 CEST] <thardin> so it seems. a bit strange [23:18:08 CEST] <TD-Linux> BBB, do you mean the stall that you'd get with "up" motion vectors on the bottom tile? [23:18:39 CEST] <BBB> yes [23:18:48 CEST] <thardin> is there a way to make an option mandatory? [23:21:03 CEST] <BBB> thardin: initialize it to an invalid value and then make sure its set to something else in _init [23:21:16 CEST] <thardin> that's what I'm thinking [23:21:48 CEST] <thardin> the options system could potentially detect that, via default being outside min/max [23:22:10 CEST] <thardin> or a flag, which would be cleaner I think [23:22:41 CEST] <BBB> Im sure that could be done, yes; but right now, using current impl, this is how you can do it ;) [23:22:56 CEST] <thardin> kk [23:23:20 CEST] <TD-Linux> BBB, that is not solved. the only thing fixed is coding dependencies across rows [23:23:36 CEST] <BBB> TD-Linux: thats a problem [23:23:46 CEST] <TD-Linux> (or rather it's configurable) [23:23:54 CEST] <BBB> configurable is good [23:23:59 CEST] <BBB> because it costs performance (quality) [23:24:08 CEST] <BBB> and having to give up that quality even if frame threading scales better [23:24:11 CEST] <BBB> is kind of crappy [23:24:28 CEST] <TD-Linux> BBB, so currently you're allowed to change the tiling on a per frame basis [23:24:29 CEST] <BBB> i.e. Id prefer frame-mt + tile-col-mt over tile-col-mt + tile-row-mt [23:25:13 CEST] <TD-Linux> so enforcing something like "MVs can't cross tile boundaries" is not really doable [23:26:12 CEST] <BBB> no, no, Im not suggesting you do that [23:26:16 CEST] <BBB> I think that would be a terrible idea [23:26:22 CEST] <BBB> the concern is more conceptual [23:26:35 CEST] <BBB> it means you cant combine tile-row-mt with frame-mt [23:26:44 CEST] <BBB> and thus making tile-row-mt idnuced quality loss optional solves the issue [23:26:48 CEST] <BBB> because then its just like in vp9 [23:26:49 CEST] <BBB> which is fine [23:26:53 CEST] <BBB> not great, but fine [23:32:14 CEST] <TD-Linux> right. the cases you'd do heavy tile-row-mt are cases where a high latency caused by frame-mt would be unacceptable [23:32:19 CEST] <thardin> BBB: unfortunately it skips setting the option to the default value in the case, leaving it at zero due to av_mallocz() [23:32:38 CEST] <thardin> I guess I could make -1 "legal" [23:32:39 CEST] <BBB> thardin: no, no, I dont mean setting it to something outside range [23:32:44 CEST] <BBB> you need to make the invalid value legal [23:32:45 CEST] <BBB> yes [23:32:52 CEST] <BBB> so as an examplem for a required boolean [23:32:55 CEST] <BBB> set range to [-1,1] [23:32:56 CEST] <thardin> eww [23:32:57 CEST] <BBB> init to -1 [23:32:59 CEST] <thardin> but ok [23:33:03 CEST] <BBB> and then require that its 0 or 1 in init [23:33:07 CEST] <BBB> its evil, yes, absolutely [23:35:33 CEST] <BBB> thardin: isnt ffmpeg full of ewwwh stuff? :D [23:35:57 CEST] <thardin> no, it's all sunshine and rainbows :] [23:36:04 CEST] <BBB> sweet [23:36:09 CEST] <thardin> [codec2raw @ 0x7efdb4000920] -mode must be set in order to make sense of raw codec2 files [23:36:12 CEST] <thardin> good 'nuff [23:36:25 CEST] <BBB> :D [23:36:29 CEST] <BBB> tres bien [23:36:37 CEST] <thardin> unless I want to dive into the arcane logic of opt.c [23:37:10 CEST] <thardin> a mandatory flag would be nice for a lot of things I suspect [23:37:31 CEST] <BBB> yes [23:45:53 CEST] <thardin> -_- more than 6000 lines of options parsing code [23:50:55 CEST] <thardin> seems michael stefano anton and lukasz are the ones that have touched it most [00:00:00 CEST] --- Sat Aug 5 2017

1 0

ffmpeg.log.20170804
by burek 05 Aug '17

05 Aug '17

[02:38:46 CEST] <EodiV> I have 24 bit depth audio, I have doubt whether it is simply re-encoded 16 bit depth audio, how would I test this? [05:17:57 CEST] <bdheeman> hello [05:20:45 CEST] <bdheeman> any possibility of continuing a convertion after system crash, hangour and, or power failures? ffmpeg processes the media streams frame by frame, why it can't continue? [05:21:44 CEST] <bdheeman> s/hangour/hangout/ [05:38:09 CEST] <thebombzen> bdheeman: it depends on what you're converting it to [05:38:27 CEST] <thebombzen> if you're converting it to an mp4 or mov? No, sorry. [05:38:42 CEST] <thebombzen> If it's a streamable format, perhaps [05:42:58 CEST] <bdheeman> thebombzen: dose not, it depends on both the input and output container formats? [14:18:31 CEST] <cq1> EodiV: Can you paste ffmpeg's output? [14:49:06 CEST] <Mockarutan> I'm having trouble with quality loss over time in VP8 encoding. My own C++ code. I'm not settings any special variables my self, just have deadline at "good" and cpu_used at 5. But at like ~150 frames, this happens in 1 frame: https://gyazo.com/7d82cc869bbe9342ee2a98ab68a3ee61 [14:49:13 CEST] <Mockarutan> Anyone have any tips? [15:07:39 CEST] <nofacetimber> I'm looking to convert videos to mp4 and upload them to Amazon S3 storage for streaming. No other video manipulation is necessary except for maybe retrieving a thumbnail for the video. What standard libraries are required for this? Or rather which standard libraries could I forgo? Would you recommend using the qt-faststart tool as well for streaming purposes? [15:14:51 CEST] <Mavrik> You don't need qt-faststart if you add the faststart flag to ffmpeg encode command [15:26:23 CEST] <nofacetimber> Thank you, the standard installation comes with all the libraries I might need? I'm looking to install ffmpeg via homebrew and If I type "brew options ffmpeg" there are a lot of options there. [17:11:21 CEST] <Bear10> Does anyone know how to include a 3rd party lib into the makefile by any chance? Is there anything special I'd need to do other than add to LD_FLAGS? [17:12:12 CEST] <pgorley> does ffmpeg do cpu detection on android? i haven't found anything related to cpu-features.h in the code [17:13:28 CEST] <JEEB> the usual ways work [17:13:36 CEST] <JEEB> for ARM generally there's very little runtime CPU detection [17:13:40 CEST] <JEEB> IIRC [17:14:00 CEST] <JEEB> for x86 the usual capability checks are done [17:14:28 CEST] <pgorley> JEEB: thanks [17:16:00 CEST] <pgorley> i know that arm has little cpu detection to be done, but i know that libvpx does it anyway, so i was just wondering [17:16:53 CEST] <JEEB> yea if a dependency library does it that's up to it of course [17:17:10 CEST] <JEEB> (if you are using it) [17:17:54 CEST] <pgorley> i guess it's mostly neon that needs chekcing though [17:18:38 CEST] <JEEB> yea, and in FFmpeg as far as I can tell it's a build time switch [17:18:43 CEST] <pgorley> yup [17:19:04 CEST] <JEEB> oh wait no [17:19:09 CEST] <JEEB> it's checked if the compiler can output them [17:19:21 CEST] <JEEB> but then checkasm does check for it [17:19:21 CEST] <JEEB> tests/checkasm/checkasm.c: { "NEON", "neon", AV_CPU_FLAG_NEON }, [17:19:29 CEST] <JEEB> or at least it has a flag for it [17:32:56 CEST] <crot> Hello all, I am using ffmpeg to transcode live broadcast tv and audio on my output the audio goes silent randomly. I was wanting to detect said silence on the output and restart the stream. What is the best to to accomplish this? [17:39:46 CEST] <thebombzen> crot: try using the silencedetect filter [17:40:57 CEST] <thebombzen> !filter silencedetect [17:40:57 CEST] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-filters.html#silencedetect [17:43:08 CEST] <crot> thebombzen: that is what I'm currently testing just wanted to see if there were any better ways to go about it. [17:43:25 CEST] <thebombzen> it is literally exactly designed to detect silence in a configurable way [17:43:31 CEST] <thebombzen> I'm not sure what else you want [17:49:39 CEST] <crot> No that sounds perfect. [18:00:22 CEST] <Raigin> Hey guys, I've got an interesting question/setup that I'd like to get your opinion on. I'm using ffmpeg to have a 24/7 live-stream broadcasting that runs a python script to adhere to a scheduled broadcast. [18:00:50 CEST] <Raigin> What I'd like to do is configure ffmpeg (or setup something else) to have the option to "Go Live" from a secondary stream without having to stop and restart the stream. [18:02:15 CEST] <Raigin> Kind of like a "barge" thing. Right now I have ffmpeg to listen in on a UDP port and that's what Python streams to. ffmpeg converts it and then sends it to another UDP stream that goes on the tele. Any ideas on how to do this? [18:03:07 CEST] <Raigin> I'm thinking another ffmpeg process that has priority over the first one listening on a different port? [19:07:55 CEST] <arthure> Is there a way to get metadata information about each AVFrame of an input video (e.g. PTS and pkt pos) without decoding them (e.g. calling avcodec_decode_video2 and avcodec_decode_audio4 on the old API)? [19:13:31 CEST] <DHE> usually the PTS is still available in the AVPacket. did you check there? [20:30:30 CEST] <mickie> Hi All, I want to transcode a video which has #0:1 (pcm_u8 (native) -> mp2 (native)) - but I'm getting an error: "Error while opening encoder for output stream #0:1 - maybe incorrect parameters such as bit_rate, rate, width or height". What is the correct syntax to achieve this? [20:31:01 CEST] <mickie> i.e. input of raw pcm_u8 and output of mp2 [20:31:25 CEST] <klaxa> we'll need more than that [20:34:20 CEST] <mickie> Thanks fflogger, I had missed -b:a in my syntax, as soon as I added it all worked out fine! [22:22:38 CEST] <leeaandrob> hello, I am building a ott system and I want to use ffmpeg to encode mp4 to hls.. [22:23:06 CEST] <leeaandrob> what the recommendation to use that a better way? [22:29:18 CEST] <user890104> leeaandrob: you can use nginx rtmp module, and push your video using ffmpeg .... -f flv rtmp://nginx-host/..., then use the HLS stream from nginx module (it also provides DASH) [22:30:22 CEST] <furq> if this is vod then you can just use the hls muxer [22:30:24 CEST] <furq> !muxer hls [22:30:24 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#hls-1 [22:30:36 CEST] <leeaandrob> so I was using the aws elastic transcoder but it's very very expansive and I am thinking on change of the aws for the ffmepg [22:31:46 CEST] <leeaandrob> I will build a application using python and django to receive the file, after uploaded I will use the ffmpeg to encode for the hls and after i will streaming using s3 and cloud front. [22:32:21 CEST] <furq> do you really need to transcode [22:36:21 CEST] <leeaandrob> yes. [22:36:46 CEST] <leeaandrob> for example I am thinking to use 1 single core to create a queue and transcode the files that the users did upload [22:37:09 CEST] <leeaandrob> but i don't know if exists better way to do this, for example using threads and etc.. [22:45:13 CEST] <leeaandrob> what do you think about that @furq? [22:49:44 CEST] <arthure2> DHE: [23:11:27 CEST] <DHE> leeaandrob: are we talking live video, or just on-demand viewing? (ie. TV or Netflix) [23:14:11 CEST] <leeaandrob> on-demand viewing DHE [23:14:47 CEST] <leeaandrob> I am looking for aws lambda solutions to help me auto transcoder and after save on s3 bukets [23:16:39 CEST] <leeaandrob> *buckets [23:23:59 CEST] <DHE> that could work [23:53:05 CEST] <leeaandrob> nice.. i will try [00:00:00 CEST] --- Sat Aug 5 2017

1 0

ffmpeg-devel.log.20170803
by burek 04 Aug '17

04 Aug '17

[00:01:15 CEST] <Compn> ZeroWalker : so you're building your own app ? [00:01:29 CEST] <Compn> why not just list the devices yourself and then pass to ffmpeg api ? [00:01:38 CEST] <Compn> er i guess thats complicated [00:02:46 CEST] <ZeroWalker> that's what i am doing currently, it's messy, but it "works", but the format isn't crystal clear, hence the RGB24 BGR confusion [00:02:53 CEST] <Compn> oh [00:02:57 CEST] <Compn> mplayer lists devices [00:02:59 CEST] <Compn> in dshow [00:03:04 CEST] <Compn> maybe you can steal from it :P [00:03:11 CEST] <nevcairiel> windows RGB is always BGR [00:03:22 CEST] <ZeroWalker> well i can list devices fine [00:03:23 CEST] <ZeroWalker> oh [00:03:29 CEST] <ZeroWalker> why? [00:03:38 CEST] <ZeroWalker> that's like, really confusing xd [00:03:57 CEST] <Compn> er nevermind i'm dumb [00:04:07 CEST] <nevcairiel> thats just how its defined [00:04:09 CEST] <Compn> ZeroWalker : probably part of dshow spec [00:04:15 CEST] <nevcairiel> RGB32 and RGB24 are both BGR order [00:04:17 CEST] <Compn> which you should be reading... :P [00:04:26 CEST] <nevcairiel> and if it gives you a negative height, then its also upside down [00:05:06 CEST] <rcombs> <nevcairiel> RGB32 and RGB24 are both BGR order [00:05:14 CEST] <rcombs> why do they call it that then :| [00:05:23 CEST] <nevcairiel> because the format is called RGB :P [00:05:51 CEST] <rcombs> I dunno, when it's in BGR order I call it BGR [00:06:37 CEST] <ZeroWalker> haha yeah precisely rcombs! [00:07:38 CEST] <ZeroWalker> Compn, and that spec is so messy, if it was possible i would just want to talk directly with the device to get the data, and not mess around with all the directshow layers as it's so messy (at least if you only want to get the data, if you wana do more stuff it makes sense) [00:08:12 CEST] <rcombs> I forget if windows runs on any big-endian platforms but I wonder if it's backwards there [00:08:22 CEST] <nevcairiel> it does not [00:08:52 CEST] <nevcairiel> BE platforms basically dont exist anymore anyway [00:09:12 CEST] <rcombs> what is there, some PPC variants? [00:09:21 CEST] <rcombs> can't ARM technically run in BE mode but nobody does it? [00:09:43 CEST] <nevcairiel> yeah like POWER8 or something, but thats such a rare platform, and I believe they can even run in LE now [00:10:15 CEST] <nevcairiel> and nothing of value was lost [00:11:03 CEST] <ZeroWalker> oh i thought that all PPC ran in BE [00:11:24 CEST] <rcombs> I guess some random microcontrollers might be BE? [00:11:59 CEST] <ZeroWalker> i would probably prefer BE cause it's more logical when seeing the memory. But i rather not change it now haha xd [00:19:03 CEST] <J_Darnley> Shitty gnome/gtk programs! That corner isn't 0,0 on Windows. [00:23:24 CEST] <dcherednik> atomnuker: I understand it is float. But according to current implementation, samples is not scaled to (-1,1). Right? [00:34:38 CEST] <dcherednik> atomnuker: Why I asked. I generate 1000 hz(-6db) + 21000 hz (-84db) signal, and got energy of last band 6db greater (approximately) than ath. Is it expected threshold? [00:51:03 CEST] <ZeroWalker> is there any list of the Pixel Formats in string form (CLI)? [01:01:15 CEST] <drv> ffmpeg -pix_fmts [01:03:13 CEST] <Compn> ZeroWalker : [19:01] <drv> ffmpeg -pix_fmts [01:03:33 CEST] <ZeroWalker> ah was looking at the codes, thanks [01:11:05 CEST] <BBB> TD-Linux: in much the same way as an IPPPP stream isn't frame parallel decodeable in H.264 < what? [01:11:47 CEST] <BBB> TD-Linux: why wouldnt IPP be frame parallel decodeable in h264? and how does ffh264 frame-mt work then? [01:12:38 CEST] <BBB> (2d tiling and symbol adaptivity are good things btw) [01:12:58 CEST] <TD-Linux> BBB, if each frame references the previous frame's pixels I don't see how you'd do frame mt [01:13:28 CEST] <TD-Linux> unless ffh264 is doing sub frame synchronization [01:13:28 CEST] <BBB> you wait until these pixels are reconstructed, as you do in any frame-mt scenario :) [01:13:36 CEST] <BBB> of course it does sub-frame synchronization [01:13:59 CEST] <TD-Linux> ah okay. I had assumed it relied on B frame structure without actually looking [01:14:04 CEST] <BBB> nope [01:15:03 CEST] <nevcairiel> that would probably not scale very well for any bitstreams [01:15:46 CEST] <TD-Linux> BBB, updated [01:17:22 CEST] <TD-Linux> BBB, because ffvp9 didn't have vp9 tile threading, do you jump between the tiles to avoid stalling for an entire tile to complete? [01:21:35 CEST] <BBB> TD-Linux: yes [01:22:00 CEST] <BBB> TD-Linux: we do one sbrow for each tile within a set of tile columns within one tile row [01:22:06 CEST] <BBB> (i.e. exactly what youd expect) [01:22:22 CEST] <BBB> in encoders (but not decoders) you could probably mt for tile-rows also [01:22:54 CEST] <BBB> the only dependency is reconstruction pixels (and some contexts which you really only need during post-r/d-frame bitstream writing), so you can just force not using any pred modes using top edge for that one row [01:22:57 CEST] <TD-Linux> okay, thanks. sorry, I've been staring at libvpx too long :) [01:23:01 CEST] <BBB> and then you get 2d tile mt in vp9 also [01:23:15 CEST] <BBB> joy [01:23:16 CEST] <BBB> :D [01:23:51 CEST] <TD-Linux> BBB, with AV1 you don't need to do post bitstream writing anymore (but you still could) [01:27:01 CEST] <TD-Linux> BBB, I think libvpx's recently added row-mt does what you're describing (but not lined up to tiles, as if you're doing post writing there's no reason to) [01:27:27 CEST] <BBB> thats nice [01:27:35 CEST] <BBB> (not having to do post-bitstream writing) [01:27:54 CEST] <BBB> why is row-mt not lined up to tiles? [01:28:17 CEST] <BBB> is it just b/c it doesnt matter where the separator is? [01:28:21 CEST] <TD-Linux> you can also restart entropy coder on tile rows, so that's probably actually what you'd do [01:28:22 CEST] <BBB> (from a mt pov) [01:28:52 CEST] <BBB> so you *do* align it to tile row boundaries (for row-mt)? [01:28:56 CEST] <BBB> or you do *not*? [01:29:49 CEST] <TD-Linux> BBB, it's not aligned with tile boundaries for vp9 libvpx. [01:30:07 CEST] <BBB> where is it aligned? :-p just halfway the frame? [01:30:28 CEST] <BBB> or just at every n_sb_rows/n_row_mt_threads sbrow? [01:30:29 CEST] <TD-Linux> not sure, I'd assume so (I haven't really looked at it in detail) [01:30:37 CEST] <BBB> hmk [01:30:59 CEST] <BBB> none of this matters from a compression perspective, although a dc-like prediction from top would be nice if the left intra predictor isnt very good [01:31:03 CEST] <BBB> (h) [01:34:09 CEST] <TD-Linux> for av1 it's not clear you'd want to do that vs just restarting the entropy coder every row (especially if you start with the last frame's cdfs) [01:35:20 CEST] <BBB> every sbrow? or every tilerow? [01:35:33 CEST] <TD-Linux> tilerow [01:35:38 CEST] <BBB> right. that makes sense [01:35:46 CEST] <BBB> every sbrow seems a little extreme [01:35:53 CEST] <TD-Linux> (which you can't do in vp9) [01:36:23 CEST] <BBB> right, its per-frame only [01:36:38 CEST] <BBB> its why vp9 intra-only comparisons vs. hevc are so bad [01:37:11 CEST] <BBB> (or at least its one of the main reasons) [01:39:20 CEST] <ZeroWalker> hmm, shouldn't AVRational{100,3000} equal 30fps? [01:41:27 CEST] <BBB> as time base? yes [01:43:12 CEST] <ZeroWalker> well i set both fps and timebase, but for some reason the file ends up with 30.060fps [02:16:25 CEST] <ZeroWalker> no ideas;o [02:16:36 CEST] <BBB> not really, sorry :( [02:18:43 CEST] <ZeroWalker> hmm, how does the fps system work, i mean i get the timebase part. but say for example [02:19:15 CEST] <BBB> its very very complicated ;) [02:19:16 CEST] <ZeroWalker> if i have the timebase in ms, and just feed it the current ms that the frame came, the end result will be a variable framerate [02:19:39 CEST] <BBB> yes you dont want that, you need something more definitive than that [02:20:14 CEST] <ZeroWalker> so i then assume if you always input a constant number, like 1 sample (which will be 1 frame) it will end up as a constant framerate [02:20:28 CEST] <BBB> yes [02:20:33 CEST] <ZeroWalker> even if i fed it 1000 frames in one second, it would still be, say 30fps right? [02:21:37 CEST] <BBB> I think so [02:22:51 CEST] <ZeroWalker> hmm, if that is the case, then the logical conclusion would be that the 100,3000 either isn't followed, or it does not equal 30fps for some reason [12:17:21 CEST] <J_Darnley> I don't get it! Why is this transform screwing up if I move the dsp init function slightly further out? [12:17:40 CEST] <J_Darnley> And then why only on the border between slice rows? [12:19:40 CEST] <J_Darnley> atomnuker: why does diracdec add 2 to the wavelet_idx parameter before passing it to ff_spatial_idwt_init()? [12:24:16 CEST] <atomnuker> there was something, I can't remember, take a look at how the index is signalled in the encoder [12:24:42 CEST] <J_Darnley> okay [14:20:58 CEST] <J_Darnley> atomnuker: the answer to my question: the enum controlling the transform function selection has two Snow values before the 0 value in Dirac. [15:01:38 CEST] <thardin> is carl not on irc these days? [15:06:22 CEST] <BBB> thardin: not usually, but he reads the irc archives [15:06:28 CEST] <BBB> thardin: when hes online, his nick is cehoyos [15:08:12 CEST] <thardin> maybe I'll just put my thoughts here then: I'm giving a probe score of 10 if codec2 major version is outside expectations, does that seem reasonable? [15:08:27 CEST] <thardin> plus an appropriate AVERROR_PATCHWELCOME [15:08:36 CEST] <thardin> [codec2 @ 0x5566f3720ae0] Format codec2 detected only with low score of 10, misdetection possible! [15:08:39 CEST] <thardin> [codec2 @ 0x5566f3720ae0] Major version 1 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [15:08:43 CEST] <thardin> /tmp/report2074-major.c2: Not yet implemented in FFmpeg, patches welcome [15:12:46 CEST] <BBB> I dont know, sorry, if this is about something he said/suggested, best to discuss with him [15:13:05 CEST] <thardin> alright, just tossing it out there [15:14:50 CEST] <BBB> sorry :) [15:15:59 CEST] <BBB> look at this beautiful code: [15:16:02 CEST] <BBB> if (av_codec_is_encoder(avctx->codec) && [15:16:02 CEST] <BBB> avctx->codec_id == AV_CODEC_ID_MPEG1VIDEO && [15:16:03 CEST] <BBB> avctx->height > 2800) [15:16:04 CEST] <BBB> thread_count = avctx->thread_count = 1; [15:16:19 CEST] <thardin> but why [15:17:15 CEST] <thardin> you'd think you'd want more threads the higher the resolution [15:19:01 CEST] <JEEB> .... [15:19:07 CEST] <JEEB> BBB: excuse me while I my eyes [15:19:25 CEST] <BBB> hehehe [15:19:26 CEST] <thardin> is there a test for that even? [15:19:58 CEST] <BBB> sometimes open source is good [15:20:01 CEST] <BBB> at least we can all see it [15:20:55 CEST] <JEEB> yea [15:21:50 CEST] <BBB> I bet its related to some fuzz [15:21:59 CEST] <BBB> or timeout on a automatic test [15:22:00 CEST] <BBB> or whatever [15:22:46 CEST] <cbsrobot> BBB: sorry for the user question, but is it possible to tell colorspace filter, that the input is linear xyz ( with gamma 2.6) ? [15:23:00 CEST] <BBB> no [15:23:09 CEST] <BBB> its possible to extend it to support that input [15:23:14 CEST] <BBB> but right now it doesnt support it yet [15:23:21 CEST] <cbsrobot> ok thanks [15:23:24 CEST] <BBB> I can teach you how to extend the code to do that ;) [15:24:00 CEST] <cbsrobot> I'll let you know when I have more time ... [15:25:25 CEST] <BBB> okiedokie [15:29:55 CEST] <jkqxz> 2800 is a relevant number for MPEG-1/2, so I could believe there is some not-entirely-stupid reason for that code. [15:30:00 CEST] <jkqxz> (It's the point where slice start codes containing the position run out - above it you have to look inside the slice to work out where it goes.) [15:30:48 CEST] <kierank> BBB: wtf [15:31:32 CEST] <BBB> kierank: hehehehe [15:31:42 CEST] <BBB> kierank: Im sure we can find more funny pieces of code before our beer [15:33:07 CEST] <kierank> BBB: might need to be something stronger [15:33:21 CEST] <BBB> whatever works for you :-p [18:18:31 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:d1bfa80ec464: avcodec/h264idct_template: Fix integer overflow in ff_h264_idct_add() [18:18:32 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:4ff94558f23a: avcodec/hevc_cabac: Check for ff_init_cabac_decoder() failure in cabac_reinit() [21:36:58 CEST] <ZeroWalker> hmm, any ideas what might be the problem if sws_scale fails on one device with YUY2 720x576, but succeeds on another? [21:37:25 CEST] <ZeroWalker> it fails with reading at bad memory basically, so i can only imagine the data being different somehow, which makes no sense [21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:effd2e7291a1: speedhq: fix behavior of single-field decoding [21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:45ffe4645e68: speedhq: add FATE tests [21:53:18 CEST] <cone-259> ffmpeg 03Steinar H. Gunderson 07master:e67d6c37ee34: Add myself as speedhq maintainer, per request. [22:52:58 CEST] <cone-259> ffmpeg 03James Almer 07master:cae2f1db107d: avcodec/htmlsubtitles: fix format specifier in av_bprintf calls [00:00:00 CEST] --- Fri Aug 4 2017

1 0

ffmpeg.log.20170803
by burek 04 Aug '17

04 Aug '17

[00:13:47 CEST] <LABcrab> Hi room. I have a DVD with letterboxed 16:9. Should I import it at 720x405 or at 640x360? [00:15:04 CEST] <c_14> I'd report it without the black bars (640x3640), but it's probably up to you [00:15:11 CEST] <c_14> If I had the raws, I'd crop it [00:15:29 CEST] <LABcrab> I have the VOB files. [00:21:30 CEST] <furq> 720x405 anamorphic [00:21:54 CEST] <LABcrab> I don't think it's anamorphic, though. Doesn't anamorphic mean that the video is 720x480 but stretches to 854x480? [00:22:39 CEST] <furq> anamorphic in digital content generally just means non-square pixels [00:23:04 CEST] <c_14> yeah, but if the pixels are square but there are just black bars in the video it isn't anamorphic [00:23:56 CEST] <c_14> And as a viewer, I find the "cropped" resolution more interesting than the one with black bars [00:24:03 CEST] <furq> actually yeah, this just sounds badly mastered [00:24:10 CEST] <furq> 720/405 is 1.77 [00:24:45 CEST] <furq> so it sounds like you just want to do a straight crop of this [00:25:04 CEST] <LABcrab> Yeah. I deal with many Christian DVDs (I'm a Christian myself, I just dislike the letterboxed videos) that have the bars. Only once in a while do I see anamorphic. Unfortunately, I have an encrypted anamorphic DVD (Pure Forgiveness) that needs something like MacTheRipper. [00:25:10 CEST] <c_14> Well, depending on input quality cropping might just make it worse [00:25:18 CEST] <furq> if you're encoding it, i mean [00:25:43 CEST] <furq> also obviously you'll need to go to 720x404 because the height needs to be an even number [00:25:46 CEST] <c_14> yeah [00:25:48 CEST] <c_14> If you are already encoding it, crop it [00:25:51 CEST] <LABcrab> Even big studios like Warner Brothers use letterboxing. [00:25:59 CEST] <furq> letterboxing on DVDs is usually for 2.35:1 [00:26:17 CEST] <furq> DVDs don't support that aspect ratio because of some kind of terrible decision making [00:26:28 CEST] <LABcrab> Or Word Records (owned by Warner Music Group), to be precise. [00:26:33 CEST] <furq> so you have to encode it with 16:9 AR plus black bars [00:26:39 CEST] <furq> but the numbers don't add up in this case [00:27:07 CEST] <furq> you'd end up with 2.15ish [00:27:16 CEST] <furq> so i assume someone's just encoded 16:9 with a 4:3 AR and black bars [00:27:21 CEST] <furq> which happens a lot with amateur stuff [00:27:26 CEST] <LABcrab> NTSC video is 720x480. VLC plays it back at 4:3, though. [00:27:47 CEST] <furq> yeah if it plays at 4:3 with black bars then the actual video is 16:9 [00:27:57 CEST] <furq> in which case, if you're encoding it, you just want to crop it and nothing else [00:28:02 CEST] <LABcrab> And of lower resolution. -_- [00:28:10 CEST] <furq> right [00:30:12 CEST] <furq> 720x404 is fine anyway [00:30:21 CEST] <LABcrab> Why 404 and not 405? [00:30:31 CEST] <LABcrab> 720 / 16 * 9 = 405. [00:30:37 CEST] <furq> the dimensions can't be odd numbers if you're using yuv420p [00:30:47 CEST] <LABcrab> I'm using ffmpeg2theora [00:30:49 CEST] <furq> and it's better to overcrop by 1px than have a black line at the bottom of the frame [00:30:56 CEST] <furq> theora only supports yuv420p iirc [00:31:11 CEST] <furq> the source is yuv420p anyway because all dvd video is [00:31:48 CEST] <LABcrab> Yeah, but black bars mean that it's 720x480 anyway. [00:31:57 CEST] <furq> right, but i assume you want to crop those out [00:32:03 CEST] <furq> it's just wasted space [00:32:11 CEST] <LABcrab> I'll take a screenshot and open it in GIMP. [00:33:42 CEST] <LABcrab> Yeah, you're right, there's a black pixel line. I don't like the number 404. :-/ [00:34:55 CEST] <Dark-knight> alexp: thanks for your help [00:36:26 CEST] <LABcrab> If I want two profiles (640x360 and 480x270), what is the best way to do this? [00:41:26 CEST] <Cracki_> are you tlking about anamorphic video [00:41:43 CEST] <Cracki_> 480 lines, usually sampled at 720 pixels/line, can be 4:3 or 16:9 [00:41:52 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB -vf pad=720:480:0:67 -x 640 -y 360 -a 6 -o 09_360p.ogv [00:42:44 CEST] <LABcrab> I also added -v 6 [00:50:33 CEST] <cq1> LABcrab: Sorry, I'm jumping in and may have missed some context, but is there any particular reason you're using Ogg container and Theora? [00:50:45 CEST] <LABcrab> For TenFourFox compatibility and to avoid MP4. [00:51:09 CEST] <LABcrab> I mentioned that on another day, so I don't blame you if you don't know. [00:52:10 CEST] <LABcrab> The video is 362p. >_< How can I make it 360p? [00:52:23 CEST] <Cracki_> crop or rescale [00:53:06 CEST] <cq1> LABcrab: Got it. Sometimes people come here and are using some weird mixture of codecs and it turns out they don't realize how much they stand to gain by using state-of-the-art formats instead. [00:53:12 CEST] <TD-Linux> theora actually supports odd sized yuv420p [00:53:36 CEST] <LABcrab> TD_Linux: How would I do this? [00:53:45 CEST] <TD-Linux> just use an odd size [00:53:55 CEST] <TD-Linux> that said... don't bother and just use 404 [00:54:07 CEST] <LABcrab> It's not 404, though, I was wrong. [00:54:11 CEST] <TD-Linux> oh okay [00:54:22 CEST] <LABcrab> The crop is 60 top, 58 bottom. [00:55:42 CEST] <LABcrab> Well, I figure that scaling from 720x362 to 640x360 should be fine. What exactly happens when I scale from 362 to 360, though? Do lines get deleted? [01:01:21 CEST] <Cracki_> no everything is resampled [01:01:28 CEST] <Cracki_> so it's gonna get blurrier [01:02:33 CEST] <LABcrab> This is complicated. [01:03:56 CEST] <Cracki_> only scale if you're sure you end up with the right geometry [01:04:15 CEST] <Cracki_> so, if you WANT square pixels, make sure after rescaling, a circle is still a circle [01:04:36 CEST] <Cracki_> if you have rectangular pixels already, don't scale. [01:04:46 CEST] <Cracki_> display aspect ratio is handled by players [01:06:30 CEST] <LABcrab> I am getting a blurry bottom line just by cropping. I'm not even scaling yet. How come? [01:06:58 CEST] <kepstin> what's the offset you're using on the crop? [01:07:12 CEST] <LABcrab> I'd like to use 60 and 60. [01:07:34 CEST] <kepstin> yeah, that should work fine [01:10:57 CEST] <LABcrab> It's still giving me a blurry line of two pixels at the bottom. [01:16:23 CEST] <kepstin> you're only cropping, right? not scaling? [01:16:44 CEST] <kepstin> if so, then your source just has some blurry lines in it, so crop a smaller region. [01:24:48 CEST] <LABcrab> The source seems fine. [01:26:43 CEST] <LABcrab> It does that on all my VOB files. :-( [01:29:05 CEST] <LABcrab> I'll send an Imgur. [01:35:02 CEST] <LABcrab> Figured it out. VLC is glitchy. [01:36:34 CEST] <LABcrab> The video plays just fine in Firefox. [01:39:15 CEST] <LABcrab> Here is the right way: ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_14_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 -o AwesomeVideo.ogv [01:52:23 CEST] <thebombzen> why use Theora at all? :thinking: [01:54:13 CEST] <cq1> thebombzen: See above where I asked. [02:02:31 CEST] <LABcrab> thebombzen: For compatibility with TenFourFox and for avoiding any licensing issues with MP4. I'm not avoiding MP4 altogether, but if a file I have wasn't originally encoded in MP4 (it was from a DVD, for example), I will encode to Theora. [02:03:16 CEST] <LABcrab> Even assuming there are no licensing issues, I would rather have Theora by default, or at the very least as an option. [02:03:30 CEST] <LABcrab> However, if TenFourFox handles VP8 or VP9 better, I may switch. [02:04:44 CEST] <thebombzen> cq1: I can't see from before because I hadn't joined the channel yet [02:05:05 CEST] <TD-Linux> thebombzen, it's being decoded on slow PPCs [02:05:28 CEST] <thebombzen> hardware compatibility would be a good reason for Theory over VP8 [02:05:47 CEST] <TD-Linux> there's no hardware decode at all on those machines. [02:05:54 CEST] <thebombzen> Yea, but "slow PPCs" [02:06:04 CEST] <LABcrab> So, you're telling me that Theora is better than VP8 in terms of CPU usage? [02:06:23 CEST] <TD-Linux> generally yes, but always test [02:06:24 CEST] <thebombzen> LABcrab: yea, Theora is computationally much simpler than VP8. Theora is derived from VP3, for reference [02:06:40 CEST] <thebombzen> It won't be as efficient though in terms of quality per bitrate [02:06:41 CEST] <LABcrab> On G4 and G5, there's AltiVec. On G3, there isn't. AltiVec and VP8 do well enough together, but if you say that Theora is lightweight, all the better. [02:07:15 CEST] <LABcrab> The issue is that WordPress rejets .ogv [02:07:30 CEST] <LABcrab> and .ogg >_< [02:07:40 CEST] <thebombzen> WordPress probably is requiring WebM compliance [02:07:53 CEST] <thebombzen> consider using vp8 + opus inside WebM [02:07:56 CEST] <LABcrab> This is https://BarlowGirl.ca (not hosted by WordPress.com) [02:08:11 CEST] <TD-Linux> you could ask the admin to add those extensions to the whitelist [02:08:23 CEST] <LABcrab> I'm the admin. :-) [02:08:24 CEST] <TD-Linux> (or try a vp8 version on a G3 and see if it's fast enough) [02:08:35 CEST] <LABcrab> I see it now. "jpg jpeg png gif" etc allowed. [02:08:45 CEST] <LABcrab> ogg and ogv are there, though. [02:10:30 CEST] <thebombzen> how is it rejecting it? [02:10:38 CEST] <LABcrab> "Désolé, ce type de fichier nest pas autorisé pour des raisons de sécurité." [02:10:53 CEST] <heth> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks [02:10:59 CEST] <thebombzen> LABcrab: "Sorry, this type of file is not allowed for security reasons." [02:11:24 CEST] <thebombzen> You probably could guess that though cause it's so close to the English [02:11:35 CEST] <LABcrab> Yeah. :-) I have the site bilingual. [02:13:08 CEST] <LABcrab> Disable Real MIME Check. I'm told to use that. [02:15:58 CEST] <LABcrab> https://BarlowGirl.ca/?p=726 is my Theora file. [02:19:22 CEST] <farfel> I have an mpeg ts stream stored as udp packets from packet capture; can ffmpeg extract stream from udp ? I don't want it demuxed, just extracted [02:50:03 CEST] <LABcrab> One of my Theora files is 88 MiB. Is this fine for web streaming, or should I lower it? [03:07:39 CEST] <thebombzen> LABcrab: it depends on the length [03:07:44 CEST] <thebombzen> the bitrate is more important than the file size [03:08:17 CEST] <thebombzen> it also depends on the dimensions [03:08:34 CEST] <thebombzen> more specifically, users will expect to use bandwidth when playing videos [03:08:42 CEST] <thebombzen> bitrate matters more than total file size [03:13:23 CEST] <LABcrab> It is a 360p file. [03:18:01 CEST] <LABcrab> If anyone wants to see it to find out, it's almost ready. [03:40:14 CEST] <LABcrab> https://BarlowGirl.ca/wp-content/BigShinyPlanet/SK_Devo_360p.ogv [03:44:35 CEST] <heth> hi! I'm getting "Failed to reload playlist" as per line 1040 here: https://www.ffmpeg.org/doxygen/2.4/hls_8c_source.html when playing HLS m3u8 files that needs to be reloaded to get new chunks [03:48:10 CEST] <LABcrab> Playback is smooth on an iBook G4 once the video is fully loaded. Thanks for the help, everyone! :-) [05:02:14 CEST] <alexpigment> hey guys, i've got an issue that hopefully one of you guys can help out with [05:02:38 CEST] <alexpigment> there are certain channels (Cooking Channel) that take old SD content, then do a non-linear stretch on [05:02:54 CEST] <alexpigment> so the middle is 4:3 and it stretches further as you get closer to the edges [05:02:57 CEST] <alexpigment> it's fucking awful [05:03:05 CEST] <alexpigment> anyway, is there a creative way to reverse this process? [05:17:53 CEST] <LABcrab> I'm sorry, I wouldn't know. I've dealt with adapting a letterbox 720x480 DVD today so that the right resolution, 640x360, is used instead. [05:19:26 CEST] <alexpigment> yeah, that's not too bad. I've done a lot of "fixing dumb resolution/aspect changes". this one though... i don't know what to do [05:19:43 CEST] <LABcrab> Of course 854x480 > 640x360. :-) [05:19:56 CEST] <LABcrab> Cooking Channel? Why is it in SD? Do you have an HD feed? [05:20:04 CEST] <alexpigment> there's a "warped resize" function in avisynth, but i've never really figured out how to incorporate avisynth into my workflow [05:20:10 CEST] <alexpigment> i have an HD feed [05:20:23 CEST] <alexpigment> and to placate the idiots out there, they do stretching on 4:3 content [05:20:28 CEST] <alexpigment> but it's a non-uniform stretch [05:20:30 CEST] <LABcrab> I did ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_43_1.VOB --croptop 60 --cropbottom 58 -x 640 -y 360 -v 6 -a 6 --deinterlace -o 43_360p.ogv [05:20:33 CEST] <LABcrab> (for my task) [05:20:55 CEST] <alexpigment> why 60 and 58, out of curiosity? [05:21:05 CEST] <alexpigment> why not 60/60 or 62/58? [05:21:21 CEST] <LABcrab> I'm trying to remember why. [05:21:49 CEST] <alexpigment> mathematically, you want to actually take off 120 pixels to get from 480 to 360; anything else would cause stretching [05:22:24 CEST] <alexpigment> obviously, sometimes the thing is not vertically centered, but the total should add up to 120 [05:22:39 CEST] <alexpigment> anyway, just my two cents on preserving the most quality [05:23:17 CEST] <LABcrab> Actually, I used this: ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_14_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 -o AwesomeVideo.ogv [05:23:30 CEST] <alexpigment> ah good [05:23:31 CEST] <LABcrab> So, I did not specify a height. [05:23:46 CEST] <alexpigment> based on that, it should end up as exactly 640x360 [05:24:04 CEST] <LABcrab> I might have to run my script again. [05:24:19 CEST] <alexpigment> yep, it's also worth potentially using a more optimized deinterlace [05:24:40 CEST] <alexpigment> like for true 30i or 25i content, you want to deinterlace to 60p or 50p respectively [05:24:46 CEST] <LABcrab> - - deinterlace right? [05:24:50 CEST] <alexpigment> or as i do, maintain the interlacing and just use a good player [05:25:05 CEST] <LABcrab> It's for web video. [05:25:08 CEST] <alexpigment> i always use ffmpeg command line, so i specify yadif=1:0:0 [05:25:11 CEST] <alexpigment> yeah [05:25:20 CEST] <LABcrab> In any event, I'd have to rerun everything another time. It took up a lot of my day. [05:25:36 CEST] <alexpigment> in which case, either deinterlace to 60p (NTSC) or 50p (PAL), but if you know it's telecined, use an inverse telecine [05:25:54 CEST] <LABcrab> It's NTSC. What is telecine? The video "looks" interlaced. [05:26:08 CEST] <alexpigment> no worries, just giving you my opinions because i've learned a lot over time, and more importantly, learned what *not* to do [05:26:45 CEST] <alexpigment> telecine is when you take 24fps (or 23.976fps) native content and conform to NTSC specs by going to 29.97 interlaced [05:26:54 CEST] <LABcrab> Amen. I have to learn over time because it's not like I have someone showing me these things IRL. [05:27:23 CEST] <alexpigment> in that case, you can usually go back to a perfect 23.976p signal without losing any quality via inverse telecining [05:27:53 CEST] <furq> uh [05:27:59 CEST] <alexpigment> i usually just gauge by the motion. is it fluid (e.g. watching the news) or is it movie-like [05:28:33 CEST] <LABcrab> It's 29.97 according to VLC. I wouldn't know if it's telecined. [05:28:42 CEST] <alexpigment> i sense some dissenting opinions in furq's one-word post ;) [05:29:13 CEST] <furq> i mean that's true if you have a lossless source [05:29:16 CEST] <alexpigment> that's fine, it's just that telecined material looks much smoother at 59.94fps progressive than 29.97fps progressive [05:29:31 CEST] <alexpigment> quality = frame fidelity [05:29:35 CEST] <furq> it gets less true as you lower the bitrate [05:29:54 CEST] <furq> also you can tell if it's telecined by framestepping with deinterlacing disabled [05:29:57 CEST] <alexpigment> you can restore the original frame fidelity. of course your bitrate changes the quality [05:30:04 CEST] <furq> you'll have a 3-2 pattern of progressive and interlaced frames [05:30:42 CEST] <LABcrab> Here is an example. https://barlowgirl.ca/wp-content/BigShinyPlanet/SK_Devo_360p.ogv [05:30:45 CEST] <alexpigment> i guess i'm just used to eyeing it because it's very obvious to tell when the source is 24 vs 30i [05:30:52 CEST] <LABcrab> I believe I did not deinterlace it. It plays well on my iBook G4. [05:31:06 CEST] <furq> alexpigment: i mean if you have e.g. a telecined dvd source, you get cross-field artifacts [05:31:23 CEST] <alexpigment> right, which is why you can inverse telecine to 23.976 [05:31:27 CEST] <furq> which make it harder to reconstruct the original signal [05:31:49 CEST] <alexpigment> labcrab: i'd guess that's originally 30i material [05:32:09 CEST] <furq> LABcrab: as a general rule, if it wasn't shot on film then it's not telecined [05:32:12 CEST] <alexpigment> unless they went to 30p at some point in the process (which would be a noob move, but it happens even at major studios) [05:32:31 CEST] <furq> video cameras traditionally all shoot 30i [05:32:38 CEST] <furq> or 60i or whatever you want to call it [05:32:50 CEST] <alexpigment> yeah, i've never figured out what to call it either [05:32:58 CEST] <furq> and modern digital cameras will shoot progressive [05:32:58 CEST] <alexpigment> i use them interchangeable depending on who i'm talking to [05:33:12 CEST] <alexpigment> furq: even at major networks? [05:33:20 CEST] <alexpigment> do they interlace from 60p to 60i? [05:33:21 CEST] <furq> i suppose you could shoot 24p on a digital camera and then burn it to dvd or broadcast it on ntsc [05:33:53 CEST] <furq> but you'd only do that if you had a reason to also use the 24p footage directly, for use in a theatre or something [05:34:13 CEST] <furq> alexpigment: i have no idea, i don't work in broadcasting and i don't live in america [05:34:23 CEST] <alexpigment> ah [05:34:30 CEST] <furq> i don't think any networks broadcast 1080p60 [05:34:35 CEST] <alexpigment> right [05:34:43 CEST] <alexpigment> you said all digital cameras will shoot progressive [05:34:50 CEST] <alexpigment> which i guess i read "will" as "do" ;) [05:34:53 CEST] <alexpigment> at any rate [05:34:55 CEST] <furq> yeah [05:35:00 CEST] <furq> i meant consumer stuff [05:35:03 CEST] <alexpigment> yeah [05:35:10 CEST] <alexpigment> i deal with mostly tv stuff [05:35:12 CEST] <LABcrab> Over the air, it's either 1080i or 720p. 480p, one channel in my area has it as a fallback. [05:35:18 CEST] <alexpigment> and it's all either 1080i or 720p60 [05:35:38 CEST] <furq> some stations here broadcast 1080p25 [05:35:43 CEST] <furq> or 1080i50 for sports [05:35:44 CEST] <alexpigment> weird [05:35:57 CEST] <furq> i know the bbc broadcasts 1080p25 [05:36:01 CEST] <alexpigment> 1080p25 seems like a bad idea to me, unless you're just showing sped-up movies [05:36:22 CEST] <LABcrab> What happens when new codecs get launched? We have to upgrade hardware again, I suppose? [05:36:25 CEST] <alexpigment> i get a lot of bbc rips - there's still 1080i25 content [05:36:49 CEST] <furq> it probably also depends on the capture box used [05:36:56 CEST] <alexpigment> LABcrab: well, a lot of new satellites in europe are already doing H.265/HEVC. they just make the consumers get new boxes [05:37:10 CEST] <furq> yeah dvb-t2 in europe uses hevc in some countries [05:37:12 CEST] <alexpigment> furq: well, the effective frame rate of the content is definitely 50p [05:37:36 CEST] <alexpigment> for what it's worth, it's specifically from BBC4 [05:37:46 CEST] <furq> i assume it also depends on the camera etc [05:37:53 CEST] <alexpigment> anyway, i'll stand by my assertion that 1080p25 broadcast is a bad idea ;) [05:38:01 CEST] <furq> do you mean compared to 1080i50 [05:38:02 CEST] <LABcrab> I should get going soon. What do you suggest I add to my command? [05:38:10 CEST] <alexpigment> yeah, compared to 1080i50 [05:38:16 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB --croptop 60 --cropbottom 58 -x 640 -y 360 -v 6 -a 6 --deinterlace -o yay.ogv [05:38:30 CEST] <LABcrab> (I will remove -y 360 because it doesn't matter.) [05:38:37 CEST] <alexpigment> LABcrap: honestly, this material is originally 30i, so going to 30p progressive just makes it half as smooth. there is no added judder [05:39:04 CEST] <alexpigment> it looks fine to me unless you want to go to 60p (and most people don't do that for player compatibility reasons) [05:39:20 CEST] <LABcrab> Is this what --deinterlace does? [05:39:45 CEST] <furq> i don't know if anyone here remembers how to use ffmpeg2theora [05:39:51 CEST] <alexpigment> i don't know how to use theora either [05:39:53 CEST] <alexpigment> ;) [05:39:55 CEST] <furq> you're probably better off just using regular ffmpeg [05:39:57 CEST] <LABcrab> If the glove fits. :-) [05:40:02 CEST] <alexpigment> but yes, it's ending up as 29.97p [05:40:49 CEST] <furq> ffmpeg in.vob -vf crop=640:360:0:60,yadif -c:v libtheora -q:v 6 -c:a libvorbis -q:a 6 out.ogv [05:40:52 CEST] <furq> i assume that does the same thing [05:41:10 CEST] <LABcrab> I am giving this player an overhaul. https://BarlowGirl.ca/wp-content/BigShinyPlanet/BigShinyPlanet.html [05:41:37 CEST] <LABcrab> Almost everything is letterboxed 16:9 [05:42:03 CEST] <alexpigment> yeah, if it's letterboxed 16x9 and you're going to true 16x9 640x360, that's a good plan [05:42:11 CEST] <LABcrab> Stuff that isn't 16:9 (like the Jessie Daniels devo) will have a separate player. [05:42:26 CEST] <furq> lol [05:42:34 CEST] <furq> i hate to do this to you, but the first video i picked there [05:42:39 CEST] <furq> https://barlowgirl.ca/wp-content/BigShinyPlanet/B429_TV_1.ogv [05:42:42 CEST] <alexpigment> you could have a separate player, or you just let it fit to the 16x9 player like youtube does [05:42:45 CEST] <furq> graphics in the bars [05:42:49 CEST] <furq> everyone's favourite [05:43:04 CEST] <LABcrab> Yeah, bad editing. I have a caption below for that. [05:43:31 CEST] <alexpigment> btw, that particular video has interlacing issues. not sure if you did the same command on it [05:43:43 CEST] <alexpigment> but it could be that the interlacing occurred somewhere earlier in the process [05:43:48 CEST] <LABcrab> No. I have to run the command again. There are four DVDs. [05:43:53 CEST] <alexpigment> gotcha [05:44:03 CEST] <alexpigment> anyway, the command you have looks good to me [05:44:15 CEST] <furq> did you try vp8 btw [05:44:16 CEST] <LABcrab> This is fun, though. I can upload these videos at higher quality than YouTube while having good performance with Theora. [05:44:20 CEST] <alexpigment> i'd go with x264 if you have the option, but theora will work if you have a need for it [05:44:24 CEST] <LABcrab> VP8 doesn't play nice on PowerPC. [05:44:31 CEST] <furq> h264/aac in mp4 is the most widely compatible [05:44:35 CEST] <furq> i can see why you'd want to avoid it though [05:45:15 CEST] <alexpigment> yeah, out of curiosity, is the decision to do theora just based on using your powerpc laptop? [05:45:27 CEST] <LABcrab> It's not even "graphics in the bar", it's how some of it leaks into the 16:9 frame. >_< [05:45:33 CEST] <alexpigment> if so, it may be worth taking one for the team and just assuming that h.264/aac will play better on everything else [05:45:42 CEST] <furq> i'm surprised vp8 doesn't work really [05:45:57 CEST] <LABcrab> It's based on that and other older Mac. I also want to use open source technology, and the quality is fine for the context. [05:46:01 CEST] <alexpigment> vp8 is pretty processor intensive for a PowerPC chip, i'd think [05:46:09 CEST] <furq> the decoder in firefox is fast and apparently one of the tenfourfox guys added altivec to libvpx [05:46:25 CEST] <LABcrab> VP8 (in TenFourFox) has AltiVec optimizations. VP9 does too, but VP9 is slow. [05:46:31 CEST] <alexpigment> furq: we're talking about a chip that's pre-2006 [05:46:42 CEST] <furq> if it's a laptop then maybe that makes sense [05:46:57 CEST] <alexpigment> no hardware decoding to speak of at that point in time either [05:46:57 CEST] <LABcrab> iBook G4 is roughly equivalent to a low-end netbook today. [05:47:03 CEST] <LABcrab> I'm saying that loosely enough. [05:47:12 CEST] <furq> i figured 480p would be fine considering that altivec was added to libvpx specifically for this use case [05:47:24 CEST] <furq> but maybe a laptop cpu can't deal with it [05:47:46 CEST] <LABcrab> Theora 480p is great on G5, a little skippy on G4. [05:47:57 CEST] <furq> oh nice, 1.3ghz single-core [05:48:12 CEST] <furq> my 2006 laptop is feeling pretty smug right now [05:48:23 CEST] <alexpigment> 2006 would be intel, right? [05:48:28 CEST] <furq> it's not a mac, so yes [05:48:32 CEST] <furq> it's a core duo [05:48:34 CEST] <alexpigment> core duo or core 2 duo? [05:48:37 CEST] <furq> core duo [05:48:37 CEST] <alexpigment> yeah, i figured [05:48:42 CEST] <alexpigment> right after the transition [05:48:44 CEST] <furq> i686 [05:48:47 CEST] <furq> which is annoying [05:48:58 CEST] <furq> it does pretty well for its age though [05:49:09 CEST] <furq> it'll play back 1080p30 avc in mpv no problems [05:49:10 CEST] <alexpigment> furq: i gotta say, the macbook air is an amazing deal if you can find one. get 2013 or later [05:49:28 CEST] <furq> i don't really use the laptop enough to justify having a good one [05:49:40 CEST] <furq> especially not since i got a tablet [05:49:42 CEST] <alexpigment> everyone is getting rid of them for retina screens, so the air doesn't resell high [05:49:48 CEST] <alexpigment> anyway, just throwing that out there [05:50:02 CEST] <furq> it would also break my streak of not owning any apple products [05:50:38 CEST] <alexpigment> man, you can hate on apple all day, but their laptops are still fairly unrivaled [05:50:48 CEST] <furq> probably [05:51:15 CEST] <alexpigment> also, i can't watch 60p streams via any browser on my beefy windows desktop without microstutters [05:51:16 CEST] <furq> i mean this laptop has linux, a tiling window manager, firefox with pentadactyl, vim etc [05:51:21 CEST] <furq> so i never have to use the garbage trackpad [05:51:22 CEST] <alexpigment> but my macbook handles it just fine [05:51:45 CEST] <alexpigment> if you're a linux guy, i hear you [05:51:48 CEST] <furq> i mean it's some toshiba trackpad from 2006 so it's hardly state of the art, but man [05:51:53 CEST] <furq> no thanks [05:52:07 CEST] <alexpigment> yeah, trackpads are largely garbage in the windows-pc world [05:52:07 CEST] <furq> i've set everything up such that i never have to remember it exists [05:52:15 CEST] <LABcrab> I'd want to run Linux for OBS and the many other software on there. [05:52:48 CEST] <alexpigment> LABcrab: i've always said, if you do any real video work, you at least need a PC around [05:52:54 CEST] <alexpigment> the linux tools are just not mature enough [05:53:11 CEST] <furq> i wouldn't do anything on a laptop that would necessitate better screen capturing than ffmpeg and xcbgrab [05:53:16 CEST] <furq> and i doubt i'd even need that [05:53:17 CEST] <alexpigment> and Mac is fine if you're dealing with all in-spec stuff. Windows has a lot of little tools that handle the not-quite-to-spec stuff [05:53:20 CEST] <LABcrab> What platform is best for OBS, though? Wouldn't Linux be best? ffmpeg is treating me well for now. [05:53:37 CEST] <alexpigment> I'd assume Windows is best for OBS [05:53:44 CEST] <furq> probably windows just because there's not much reason to use it otherwise [05:53:49 CEST] <alexpigment> specially considering that hardware accelerated capture is better on windows [05:53:56 CEST] <alexpigment> or rather, more mature [05:53:56 CEST] <LABcrab> Okay. [05:53:59 CEST] <furq> OBS is good if you need to hook into directx windows and stuff [05:54:05 CEST] <furq> ffmpeg is hopeless at that [05:54:24 CEST] <LABcrab> ffmpeg can do borders, overlays, etc. fine. [05:54:28 CEST] <furq> and gdigrab is generally a bit crap (sorry kepstin) [05:54:35 CEST] <furq> you probably won't be doing much gaming on linux, so if you're using x11, ffmpeg will do a perfectly good job [05:54:52 CEST] <alexpigment> throwin shade on kepstin ;) [05:54:58 CEST] <furq> that's fine he admits it sucks [05:55:02 CEST] <furq> it's not his fault, it's GDI's [05:55:05 CEST] <alexpigment> i'm just kidding anyway ;) [05:55:38 CEST] <LABcrab> For the DVD, I should deinterlace it and remove the (optional) height, right? [05:55:43 CEST] <alexpigment> but yeah, i think for OBS, you want to ideally capture via the GPU to free up CPU for other tasks. in which case, i'd recommend Windows with an Nvidia GPU [05:56:00 CEST] <alexpigment> LABcrab: what you did with the first video you sent looks very good [05:56:04 CEST] <alexpigment> you're doing the right thing [05:56:10 CEST] <alexpigment> deinterlacing and cropping to 640x360 [05:56:42 CEST] <LABcrab> Thanks. :-) I had some help here and from looking at the web a little, so I'm glad I'm doing it right. [05:56:50 CEST] <furq> are you sure 640*360 is right if you're cropping 118 pixels from 720*480 [05:56:56 CEST] <furq> that doesn't seem like the AR will come out right [05:57:16 CEST] <furq> actually nvm i guess that's 16:9 [05:57:29 CEST] <alexpigment> furq: he ammended his statement [05:57:31 CEST] <LABcrab> ./ffmpeg2theora /Volumes/DVD/VIDEO_TS/VTS_09_1.VOB --croptop 62 --cropbottom 58 -x 640 -v 6 -a 6 --deinterlace -o 09_360p.ogv [05:57:36 CEST] <alexpigment> he's cropping 62 and 58 [05:57:37 CEST] <alexpigment> = 120 [05:57:57 CEST] <furq> yeah i meant the horizontal resolution [05:58:08 CEST] <furq> but if it's 16:9 with borders then that's right [05:58:18 CEST] <LABcrab> The people look "fat" at 720, but at 640, they're fine. [05:58:19 CEST] <furq> i feel like i was already wrong about this once today [05:58:24 CEST] <alexpigment> haha [05:58:42 CEST] <LABcrab> I had the video in VLC for reference, and so 640 it is. [05:58:42 CEST] <alexpigment> i mean it would be comical if it were a 16x9 dvd with pillarbox and letterbox :) [05:59:00 CEST] <alexpigment> but no, it's just a 4x3 dvd from what i can tell. in which case, LAB is doing the right command [05:59:00 CEST] <furq> i'm pretty sure i've seen that [05:59:17 CEST] <furq> i used to buy a lot of real trash DVDs [05:59:18 CEST] <alexpigment> furq: i see it on SD tv channels. it's dumb [05:59:35 CEST] <alexpigment> furq: it sounds like it :) [05:59:53 CEST] <furq> what's really annoying is a lot of bbc/channel 4 dvds have pillarboxing that changes in every scene [05:59:56 CEST] <LABcrab> Well, I should get going. Thanks again for the help. See you next time. :-) [06:00:03 CEST] <alexpigment> later LABcrab [06:00:06 CEST] <furq> i know i complain a lot about bbc and channel 4 dvds but they are the bane of my existence [06:00:27 CEST] <alexpigment> how does the pillarboxing change in every scene? [06:00:39 CEST] <alexpigment> that would imply it's baked into the source [06:01:06 CEST] <furq> it changes in every shot sometimes [06:01:10 CEST] <furq> father ted is particularly bad for this [06:01:18 CEST] <alexpigment> weird [06:01:29 CEST] <alexpigment> on BBC America, they show reruns of star trek TNG [06:01:36 CEST] <alexpigment> and it's an HD channel [06:01:44 CEST] <alexpigment> and they definitely do letterbox + pillarbox on it [06:02:04 CEST] <alexpigment> which just goes to show you that no one there has real-world experience with content [06:02:51 CEST] <alexpigment> just feeding the 480i/576i 4x3 source into their 16x9 system without a thought about fixing it [06:05:41 CEST] <furq> http://imgur.com/a/ESiXl [06:05:47 CEST] <furq> those screenshots are one second apart [06:06:08 CEST] <alexpigment> oh that's real common on true analog content [06:06:15 CEST] <alexpigment> this is a pre-digital show, right? [06:06:19 CEST] <furq> yeah [06:06:20 CEST] <furq> 95 [06:06:24 CEST] <alexpigment> yeah, extremely commn [06:06:27 CEST] <alexpigment> *common [06:06:37 CEST] <alexpigment> i think it's a side effect of analog avid systems [06:06:40 CEST] <furq> that's actually not that egregious, it was just the first example i could find [06:06:56 CEST] <furq> there's been stuff i've ended up overcropping to like 672px wide [06:07:05 CEST] <alexpigment> i have a huge collection of music videos from DVD and VHS sources. i just gave up cropping left and right [06:07:30 CEST] <alexpigment> top & bottom is OK, but even then, i only crop the bottom to get rid of VHS noise [06:07:36 CEST] <furq> it also tends to get really bad when they have external cameras [06:07:54 CEST] <furq> it's just annoying that they wouldn't clean that stuff up for the dvd [06:08:02 CEST] <alexpigment> yeah. trust me. this is EXTREMELY common for analog [06:08:12 CEST] <furq> at least they left this one interlaced instead of doing a crap job of it [06:08:13 CEST] <alexpigment> well, they probably mastered the DVD when overscan was still a thing [06:08:24 CEST] <furq> this comes in well past the overscan region though [06:08:30 CEST] <furq> overscan is 704 isn't it [06:08:36 CEST] <alexpigment> no [06:08:51 CEST] <alexpigment> 704 is the max width for analog [06:09:09 CEST] <alexpigment> so the overscan is more in the 600s [06:09:36 CEST] <furq> oh fun [06:09:45 CEST] <alexpigment> the area between 704 and 704 is like the "digital blanking" area or something [06:09:48 CEST] <alexpigment> er [06:09:52 CEST] <alexpigment> between 704 and 720 [06:09:59 CEST] <furq> yeah i thought that was the overscan area [06:10:15 CEST] <alexpigment> sadly not :( [06:10:19 CEST] <furq> i'm not old enough to have experience of the horrors of analogue [06:10:37 CEST] <furq> other than watching it [06:10:41 CEST] <alexpigment> i have a fondness for analog, but i do know a lot about its shortcomings [06:11:10 CEST] <alexpigment> a lot of DVDs have these alternating white noise signals at the top [06:11:14 CEST] <alexpigment> like 2 pixels [06:11:20 CEST] <alexpigment> but they blink rapidly [06:11:37 CEST] <alexpigment> i think it was originally info carriers (e.g. closed captions or something) [06:12:06 CEST] <alexpigment> but there are so many people out there making dvds that they don't all think to clean that up [06:13:00 CEST] <alexpigment> and obviously, it's well within the overscan area, but it makes me rethink my policy of never re-encoding a dvd source [06:13:09 CEST] <furq> i'm well beyond that point [06:13:21 CEST] <furq> i've mentioned this before but the best thing about qtgmc is the filter for cleaning up bad deinterlacing [06:13:30 CEST] <alexpigment> man, i need to look into that [06:13:40 CEST] <alexpigment> i have quite a few dvds that i can't figure out what's going on with the interlacing [06:13:41 CEST] <furq> it's properly brilliant [06:13:57 CEST] <alexpigment> i hear only good things about it [06:14:09 CEST] <furq> i mean the regular deinterlacer is great for sd mpeg2 stuff [06:14:16 CEST] <furq> but the bad deinterlacer cleanup is amazing [06:14:26 CEST] <furq> i have quite a few bbc dvds that have been really poorly deinterlaced [06:14:30 CEST] <alexpigment> i have a good number of music video dvds where there will be combing *only* at scenecuts. and this doesn't happen on a player [06:14:57 CEST] <alexpigment> may qtgmc is in my future [06:15:04 CEST] <furq> including stuff that was shot in 2007 and released on dvd in 2009 [06:15:11 CEST] <furq> by which time you'd think they'd know better [06:15:32 CEST] <alexpigment> again. lots of people making dvds out there. only some of those people know how to deal with content [06:15:42 CEST] <furq> you'd think the bbc would know better, but apparently not [06:16:01 CEST] <furq> on the plus side they are exactly 720*576 [06:16:05 CEST] <alexpigment> eh, i can only speak from my BBC4 Top Of The Pops rips... [06:16:17 CEST] <furq> http://avisynth.nl/index.php/QTGMC#Progressive_Input [06:17:00 CEST] <alexpigment> good to know [06:17:15 CEST] <furq> that's the killer feature really [06:17:20 CEST] <alexpigment> i need to actually just figure out how to use avisynth someday [06:17:29 CEST] <furq> vapoursynth is better these days [06:17:43 CEST] <furq> you really need one of the multithreaded avisynth forks to get passable speeds out of qtgmc, and those are all unstable [06:17:49 CEST] <furq> vs has multithreading built in [06:18:16 CEST] <alexpigment> i encoding 99.9% of everything in interlaced. if i have to wait longer for a bad interlaced video here and there, not a huge deal [06:18:30 CEST] <alexpigment> but yeah, i'm aware of vaporsynth's existence [06:18:44 CEST] <alexpigment> does ffmpeg support vaporsynth input? [06:18:57 CEST] <furq> there's a tool that ships with vapoursynth which pipes out y4m [06:19:00 CEST] <furq> you can just pipe that into ffmpeg [06:19:09 CEST] <alexpigment> good to know [06:19:20 CEST] <alexpigment> again, i just need to force myself to figure out how to use that [06:20:22 CEST] <alexpigment> plus, i do deinterlace from time to time, and from everything i hear qtgmc is miles ahead of yadif for even basic bob-like deinterlacing [06:22:51 CEST] <alexpigment> furq: i don't know if you saw my post from earlier up there, but do you know of a way to fix non-linear stretching in ffmpeg? [06:23:11 CEST] <furq> uh [06:23:16 CEST] <furq> that's not something i've ever encountered [06:23:50 CEST] <furq> there's probably an avisynth filter for it though [06:24:02 CEST] <alexpigment> i've got these episodes of Good Eats from Cooking channel that were originally 4x3 480i, but they stretched them to 16x9 with a nonlinear stretch to satisfy idiots who require that the video fills their HDTV screen [06:24:22 CEST] <alexpigment> so the center is correct, but the edges are overstretched [06:24:43 CEST] <furq> http://avisynth.nl/index.php/External_filters#Rotation.2FShear.2FSkew.2FPer… [06:24:46 CEST] <furq> maybe one of those? [06:25:00 CEST] <furq> you could probably do it with geq in ffmpeg but that's really slow [06:25:35 CEST] <alexpigment> https://forum.videohelp.com/threads/356521-Convert-non-linear-stretched-16x… [06:25:45 CEST] <alexpigment> they recommend WarpedResize [06:25:57 CEST] <alexpigment> i was really hoping for something native in ffmpeg [06:26:05 CEST] <alexpigment> i'll look into geq [06:26:13 CEST] <furq> geq will be incredibly complicated [06:26:33 CEST] <furq> doesn't look like there's a vs port of warpedresize [06:27:21 CEST] <alexpigment> oh well [06:27:27 CEST] <alexpigment> this isn't mission critical really [06:27:46 CEST] <alexpigment> i was just hoping to replace some old xvid tvrips with some pure DTV rips [06:28:07 CEST] <alexpigment> i hate ripping groups and the decisions they make, so i always try to get my own copy [06:28:36 CEST] <alexpigment> it's just the penalty of working in the video world and not being able to turn off that quality-hyper-sensitive part of my brain i guess :) [06:34:11 CEST] <alexpigment> aight, bed time. later furq [06:54:33 CEST] <durandal_1707> one could use perspective filter, but thats too hard for furq to grasp [08:36:48 CEST] <cbsrobot> CAn someone explain why the following happes? When I amerge 8 mono files to a 8 channel audio file and mux it to aac the last channel will get a filter applied. [08:36:54 CEST] <cbsrobot> see https://transfer.sh/7ilvS/Screen%20Shot%202017-08-03%20at%2008.29.21.png [08:37:23 CEST] <cbsrobot> left side aac, right side wav [08:46:24 CEST] <cbsrobot> ah probably i can set the -cutoff option .... [08:48:04 CEST] <atomnuker> cbsrobot: probably the layout maybe [08:48:24 CEST] <atomnuker> if the last channel is marked as lfe [08:48:44 CEST] <cbsrobot> atomnuker: the cutoff is not the solution [08:50:01 CEST] <cbsrobot> but how do I mux 8 discreet channels not applying any postprocessing but still set the channel layout to 7.1 ? [08:53:40 CEST] <atomnuker> dunno [08:54:52 CEST] <Nacht> I take it you've read this ? https://trac.ffmpeg.org/wiki/AudioChannelManipulation [08:55:29 CEST] <cbsrobot> seems libfdk_aac(enc) honors the cutoff option while the aac(enc) does not ... [08:55:52 CEST] <cbsrobot> Nacht: yeah - not all but most [08:56:33 CEST] <atomnuker> cbsrobot: no, aac will honor the cutoff option [08:57:07 CEST] <atomnuker> cbsrobot: oh, wait, the filtering happens due to the encoder [08:57:15 CEST] <cbsrobot> atomnuker: cant find it in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/aacenc.c [08:57:20 CEST] <atomnuker> if a channel is marked as LFE it'll be lowpassed [08:57:25 CEST] <cbsrobot> but it's in https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/libfdk-aacenc.c [08:57:28 CEST] <atomnuker> this is specified by AAC [08:57:36 CEST] <cbsrobot> ah gosh [08:57:43 CEST] <atomnuker> so you can't have an LFE channel which isn't lowpassed [08:57:47 CEST] <cbsrobot> there is no way to avoid this ? [08:58:14 CEST] <atomnuker> nope, its specified by AAC, if the layout has an LFE channel it'll be lowpassed [08:58:34 CEST] <cbsrobot> atomnuker: thanks - time to try opus :-) [08:58:34 CEST] <Nacht> libfaac.c does support it [08:58:49 CEST] <cbsrobot> I guess the cutoff is used for all channels [08:58:57 CEST] <cbsrobot> not only lfe [08:59:00 CEST] <atomnuker> yes, its used for all channels of course [09:00:24 CEST] <atomnuker> cbsrobot: opus still seems like it'll do special things to a channel if its marked as LFE [09:00:39 CEST] <atomnuker> select a layout which does _not_ have an lfe channel and it'll all work [09:01:44 CEST] <cbsrobot> hmm whats the default container for opus ? is it opus ? [09:01:54 CEST] <atomnuker> "octagonal" seems what you have [09:02:27 CEST] <atomnuker> though if the layout is 7.1 where one channel is LFE it'll be incorrect [09:03:04 CEST] <cbsrobot> well - actually it's not [09:03:30 CEST] <cbsrobot> but I was wondering why that happens anyway [09:03:39 CEST] <atomnuker> ok, I thought you were being stupid for not wanting an actual LFE channel to be treated differently than an LFE channel [09:06:12 CEST] <cbsrobot> seems setting -channel_layout octagonal will not cripple the last channel [09:06:27 CEST] <cbsrobot> ah wait [09:08:32 CEST] <cbsrobot> no - at least not for aacenc [09:09:12 CEST] <cbsrobot> and libfdk_aac won't allow octagonal layout [09:09:49 CEST] <cbsrobot> and opus is lie: [libopus @ 0x7fe392074200] Invalid channel layout octagonal for specified mapping family -1. [09:09:54 CEST] <cbsrobot> *like [09:11:35 CEST] <atomnuker> cbsrobot: try -mapping_family 255 [09:11:44 CEST] <cbsrobot> for opus ? [09:11:47 CEST] <atomnuker> yes [09:12:01 CEST] <atomnuker> aacenc doesn't support non-standard layouts [09:12:04 CEST] <cbsrobot> does audacity support opus yet ... ? [09:12:38 CEST] <cbsrobot> seems not [09:13:15 CEST] <cbsrobot> well aacenc allows me to set -channel_layout octagonal on the command line, but the last channel gets treated as LFE [09:13:54 CEST] <atomnuker> yes, it thinks its 7.1 instead, it only uses the channel count [09:14:26 CEST] <atomnuker> supporting non-standard layouts in aac is difficult, confusing and practically guaranteed to not decode with the correct layout [09:16:02 CEST] <atomnuker> opus with -mapping_family 255 seems to work here [09:16:13 CEST] <atomnuker> (with octagonal layout) [09:17:10 CEST] <cbsrobot> atomnuker: I'm figuring out the showwavespic options .... because audacity cannot open it [09:20:14 CEST] <cbsrobot> atomnuker: yeah that seems to work [09:20:15 CEST] <atomnuker> -filter_complex showspectrumpic=split_channels=yes [09:20:19 CEST] <cbsrobot> thanks a lot [09:21:11 CEST] <cbsrobot> I used showwavespic=s=1024x960:split_channels=1 [09:24:12 CEST] <cbsrobot> guess it's showspectrumpic=mode=separate [10:35:55 CEST] <Ajey> Hi folks, I was wondering is there a way in FFMPEG where it only uses hardware to decode h264? Basically I do not want to use software decode (even as a fallback). [10:36:19 CEST] <Ajey> It should always use the hardware for decode. How do I achieve this. Any pointers would be helpful :) [10:41:07 CEST] <Nacht> For encoding you mean I take it ? [10:42:14 CEST] <Nacht> Here some info regarding it: https://trac.ffmpeg.org/wiki/HWAccelIntro [10:43:05 CEST] <dystopia_> when i tested hardware decoding and software encoding, the diffrence was negligible [12:03:56 CEST] <nyuszika7h> I have some problematic .mkv files, if I make a copy with -ss greater than 2 seconds, some metadata like x264 encoding settings are lost [12:04:34 CEST] <nyuszika7h> also when remuxing with mkvtoolnix it strips them completely, which it normally doesn't - but then I realized it's not an mkvtoolnix regression, something is wrong with the files [12:04:43 CEST] <nyuszika7h> is there any way to "fix" them? [12:06:30 CEST] <nyuszika7h> oh wait it also only happens with mkvtoolnix if I strip the first 2 seconds [12:07:06 CEST] <nyuszika7h> ok looks like remuxing them with mkvtoolnix as-is fixes it [12:33:11 CEST] <damdai> what is better? ATI Radeon HD 5850 or geforce gt 1030 [14:34:35 CEST] <kepstin> furq: alexpigment well, yeah, the idea behind getting the gdigrab stuff in was just to have *something* that works on basically all windows systems. [14:36:38 CEST] <kepstin> I use it as part of a screen sharing application for the educational market, people do things like spreadsheets and quick demos there, not games. [16:20:42 CEST] <Mista-D> While encoding X264 to MP4, what is the method to set "fixed_frame_rate_flag" to 1 please? [16:28:57 CEST] <jkqxz> Mista-D: -x264opts force-cfr=1 [16:29:15 CEST] <jkqxz> (And make sure your input really is CFR.) [16:32:28 CEST] Action: JEEB would recommend x264-params instead of x264opts [16:33:14 CEST] <Mista-D> Thanks. -x264-params force_cfr=1:... [16:33:16 CEST] <jkqxz> Yes, I should too. Sorry. [17:19:44 CEST] <thebombzen_> Out of curiosity, who is the Arch Linux downstream maintainer for ffmpeg? [17:55:12 CEST] <jya> high, how do you get ffmpeg to produce fragmented mp4 with base-data-offset-present not set? [17:55:29 CEST] <jya> right now it's always set, which makes it non compliant to ISOBMFF for using with Media Source Extension [19:05:02 CEST] <Dark-knight> hello [19:05:20 CEST] <Dark-knight> is anyone busy helping someone? [19:05:28 CEST] <Dark-knight> not* [19:06:47 CEST] <Dark-knight> I'd like to create a .bat file that converts all the mkv files in a folder to mp4 in one click, while keeping the same file names for each. [19:07:18 CEST] <Blubberbub_> the ffmpeg part of this is probably easier than the bat-part... granted you already have ffmpeg installed... [19:07:56 CEST] <Dark-knight> the bat file is simply for my own ability to reuse this at a later date without having to remember anything [19:11:27 CEST] <furq> are these mkvs all mp4 compatible [19:11:34 CEST] <Dark-knight> I believe so [19:12:13 CEST] <Dark-knight> AVC video and AAC audio [19:12:49 CEST] <Dark-knight> I have about 50 mkvs [19:12:57 CEST] <furq> http://vpaste.net/1btIJ [19:13:00 CEST] <furq> something like that then [19:13:16 CEST] <Dark-knight> hmm [19:13:25 CEST] <Dark-knight> I don't quite understand it, but thank you [19:14:00 CEST] <furq> i tend to install msys on windows systems so i don't ever have to deal with batch [19:14:01 CEST] <Dark-knight> so I just put that in a .bat file and put it in the "bin" folder, along with all the files right? [19:14:09 CEST] <furq> right [19:14:42 CEST] <Dark-knight> its a shame I can't figure out how to get the bat file to work anywhere outside the bin folder [19:15:26 CEST] <Dark-knight> quick question [19:15:42 CEST] <Dark-knight> is the -map necessary? [19:16:16 CEST] <furq> maybe [19:16:20 CEST] <furq> -map 0 will keep every stream [19:16:29 CEST] <furq> if you omit it then the outputs will all have one audio and one video stream [19:16:57 CEST] <Dark-knight> I have a .bat file that converts single file mkvs to mp4s and it doesn't use -map [19:17:07 CEST] <Dark-knight> should I add -map to it then? [19:17:25 CEST] <Dark-knight> it doesn't matter if there is only 1 stream for each right? [19:17:39 CEST] <furq> not really but there's no harm in keeping it [19:18:02 CEST] <Dark-knight> it only matters if there are multiple audio or sub streams right? [19:19:46 CEST] <Dark-knight> what does adding the n to "%%~nf" do? [19:20:24 CEST] <JEEB> batch script thing, look up batch scripting [19:20:26 CEST] <Blubberbub_> i think that removes the file extension from whatever is in %f [19:21:18 CEST] <Dark-knight> furq: you mentioned msys? [19:25:19 CEST] <Dark-knight> anyway thanks for the help [19:38:40 CEST] <Mockarutan> So I'm trying to understand the frame_size (FR) in audio codec better (Opus and Vrobis). When opening Opus, the FR is 960, when opening Vorbis it's 64. My frames are 1024. Is swr_convert suppose to solve both by itself? [19:50:10 CEST] <durandal_1707> no [20:03:24 CEST] <durandal_1707> there is code in lavu though [20:05:07 CEST] <Mockarutan> Not familiar with lavu? libvautil or what? [20:05:40 CEST] <Mockarutan> libavutil* [20:06:00 CEST] <durandal_1707> yes [20:26:14 CEST] <Mockarutan> Hmm, can you point me to any specific functions? [20:26:51 CEST] <durandal_1707> fifo or something like that [20:45:26 CEST] <rpw> I'm building ffmpeg from source on a ububtu16.04 VM. Getting this error during configure. "cuda_sdk not found" [20:46:08 CEST] <rpw> cuda_sdk is installed in /usr/local with softlink /usr/local/cuda to v8.0 [20:46:25 CEST] <BtbN> well, something it needs is missing [20:46:30 CEST] <BtbN> check the config.log and fix it [20:47:03 CEST] <BtbN> But do you really need the cuda_sdk parts? [20:47:07 CEST] <BtbN> It's fairly minimal so far [20:47:09 CEST] <rpw> i do [20:47:16 CEST] <rpw> I'll check the log. please standby [20:47:20 CEST] <BtbN> For what? [20:47:27 CEST] <BtbN> The only thing it enables is scale_cuda. [20:47:46 CEST] <rpw> i'm using that actually haha [20:57:36 CEST] <rpw> gcc -L/usr/local/cuda/lib64 [20:57:46 CEST] <rpw> /usr/bin/ld: cannot find -lcuda [20:57:48 CEST] <rpw> collect2: error: ld returned 1 exit status [20:57:49 CEST] <rpw> ERROR: cuda_sdk not found [20:58:33 CEST] <JEEB> as root, `find / -iname '*cuda*.so'` [20:58:37 CEST] <JEEB> (that will take a while) [20:59:41 CEST] <rpw> /usr/local/cuda-8.0/targets/x86_64-linux/lib/stubs/libcuda.so [20:59:43 CEST] <rpw> /usr/local/cuda-8.0/targets/x86_64-linux/lib/libcudart.so [20:59:53 CEST] <BtbN> libcuda.so is part of the nvidia driver [20:59:54 CEST] <BtbN> not the SDK [21:00:11 CEST] <JEEB> ^that's it [21:00:25 CEST] <rpw> so I just need to provide that library path to the linker? [21:00:34 CEST] <BtbN> you need to install the nvidia driver [21:00:53 CEST] <rpw> can that be done on a virtual box? [21:00:59 CEST] <JEEB> why not? [21:01:08 CEST] <JEEB> it's not like you need to *load* it :P [21:01:18 CEST] <JEEB> although isn't that stuff nonfree so you can't distribute that binary [21:01:39 CEST] <BtbN> if you just want to build it, you can as well just copy that stub library to somewhere in your search path [21:01:42 CEST] <BtbN> that's what it's there for [21:01:52 CEST] <JEEB> ok if the stuff works [21:01:54 CEST] <rpw> just want to build it for testing [21:02:06 CEST] <JEEB> then -L/usr/local/cuda-8.0/targets/x86_64-linux/lib/stubs/ into extra ldflags [21:02:16 CEST] <rpw> as for installing the driver, does it matter which version I install? [21:04:21 CEST] <rpw> thanks guys! that worked! [21:04:26 CEST] <rpw> you're awesome [21:17:29 CEST] <MacITguy> Hello, Im trying to create a video mosaic from multiple synced videos that are of 35GB each, which is working fine, as long as Im processing the entire length of the sources. Id like to create the mosaic from a trimmed version of the sources, without duplicating content. For that I use the -ss and -to parameters, but I was only able to apply them to the output, so there is a long seek time before the encoding starts. Can -ss and -to be applied to [21:17:30 CEST] <MacITguy> of the sources in order to shorten the seek time? Thanks in advance [21:21:51 CEST] <pgorley> hi, vp8_mediacodec doesn't seem to work on my armv7 (cortex-a7, mali-400 mp) [21:22:35 CEST] <pgorley> on vlc ACodec's onOutputBufferDrained is called every time onInputBufferFilled is called, but with FFmpeg, it's never called [21:26:13 CEST] <pgorley> is this a known bug? [21:26:13 CEST] <pgorley> also, for FFmpeg, onInputBufferFilled prints a negative timestamp, whereas with VLC it's a positive timestamp [21:34:03 CEST] <m3e33> Hey everyone. Is it possible to take a rtmp stream and convert it in to a ffm stream? [21:35:51 CEST] <m3e33> I tried doing ffmpeg -i rtmp://localhost:1935/live http://localhost:9609/feed1.ffm and it doesnt work :( [21:36:27 CEST] <BrightScripters> Would anyone care to help? Here is the command line: ffmpeg -n -v error -report -an -i '3.mp4' -i '4.mp4' -i '5.mp4' -ss 00:07:06.000 -to 00:10:27.000 \ [21:36:28 CEST] <BrightScripters> -filter_complex "color=c=purple:size=3840x2160 [base]; \ [21:36:29 CEST] <BrightScripters> [0:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [upperleft]; \ [21:36:31 CEST] <BrightScripters> [1:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [lowerleft]; \ [21:36:32 CEST] <BrightScripters> [2:v] crop=819:1456:3276:424, transpose=1, setpts=PTS-STARTPTS, scale=1920x1080 [upperright]; \ [21:36:34 CEST] <BrightScripters> [base][upperleft] overlay=shortest=1 [tmp1]; \ [21:36:35 CEST] <BrightScripters> [tmp1][upperright] overlay=shortest=1:x=1920 [tmp2]; \ [21:36:37 CEST] <BrightScripters> [tmp2][lowerleft] overlay=shortest=1:y=1080\ [21:36:38 CEST] <BrightScripters> " -c:v libx265 -x265-params bitrate=25000:vbv-bufsize=8000:vbv-maxrate=40000 -pix_fmt yuv420p -r 29.97 'Player_6.mp4' [21:36:52 CEST] <BrightScripters> Sorry for the multiple lines [21:41:17 CEST] <owenthewizard> hey guys, is anyone here experienced with ffserver? [21:41:31 CEST] <owenthewizard> I'm trying to stream video from the camera on my Raspberry Pi [21:41:44 CEST] <owenthewizard> I setup my ffserver config like so: https://pastebin.com/fc5swATk [21:42:18 CEST] <owenthewizard> I just need to get the correct ffmpeg command to send video [21:42:59 CEST] <owenthewizard> I have the h264_omx encoder and the h264_mmal decoder enabled, if that helps [21:44:55 CEST] <owenthewizard> When i do `ffmpeg -f v4l2 -i /dev/video0 -f ffm -vcodec h264_omx http://localhost:8090/feed1.ffm` I get a 404 not found [21:45:54 CEST] <Trevor__> Hi! Why is this not working for me? "ffmpeg -r 30 -i D:/BeginningIntro%04d.tif streamintro.mp4" the file names are formatted BeginningIntro0000.tif.... [21:48:51 CEST] <BtbN> ffserver is dead, don't use it. [21:49:58 CEST] <owenthewizard> Oh, this is news to me! [21:51:19 CEST] <JEEB> people keep trying to keep it in the tree but you're highly unlikely to get any support for it [21:51:31 CEST] <JEEB> you generally want to use ffmpeg.c with some media server [21:51:31 CEST] <BtbN> it's only kept alive by some people blocking its removal, but nobody of them actually maintains it [21:51:57 CEST] <BtbN> The only fixes it got lately have been related to keep it working at all, no bug fixes, nothing [21:53:29 CEST] <Trevor__> Hi! why is ffmpeg not finding the file? "ffmpeg -r 30 -i D:/BeginningIntro%04d.tif streamintro.mp4" is what I type in, the file names are formatted BeginningIntro0000.tif, BeginningIntro0001.tiff, .... and the folder is in D:/ [21:55:16 CEST] <Trevor__> nevermind, didn't specify the folder, then the files [21:55:23 CEST] <Trevor__> <3 you guys [21:55:49 CEST] <BrightScripters> Trevor__: you have a character in the file name that is not helping& %04 [21:57:53 CEST] <Trevor__> Oh, just %04? [22:01:14 CEST] <BrightScripters> Trevor__: you could try and rename the file so it has letters, numbers, -_ and nothing else. No spaces [22:32:35 CEST] <pgorley> does ffmpeg support packet loss concealment for opus? [22:50:53 CEST] <goiko> hi, i am working on a project that uses ffmpeg: https://pitube.github.io/ - feedback welcome! #pitube - pre-alpha version - thanks =) [23:28:43 CEST] <vincentjames501> Just out of curiosity, why does the absence of the `--enable-nonfree` compilation flag include encoders/decoders that are clearly not free such as H.264? [23:36:28 CEST] <jkqxz> vincentjames501: The freedom being considered there is the ability to distribute what gets built. Any licences which might be required to actually run it in specific countries is not relevant to that. [23:38:33 CEST] <furq> vincentjames501: nonfree in this case specifically refers to lgpl compatibility [23:40:21 CEST] <alexpigment> oh weird. i was under the impression that "nonfree" had to do with the fraunhofer aac encoder [23:40:35 CEST] <alexpigment> i guess i'm just used to my build script asking me about non-free codecs [23:40:44 CEST] <alexpigment> and it specifically mentions that one (and only that one) [23:41:07 CEST] <furq> fdk is gpl incompatible [23:41:15 CEST] <alexpigment> right [23:41:16 CEST] <furq> there's some stupid fraunhofer clause in the license that makes it nonfree [23:41:16 CEST] <alexpigment> which is fine [23:42:06 CEST] <alexpigment> i'm just saying that i thought nonfree referred to that, and "enable-gpl" was more related to distrubiting non-lgpl encoders [23:42:21 CEST] <alexpigment> i didn't realize nonfree also dealt with lgpl/gpl licensing stuff [23:43:22 CEST] <vincentjames501> We want to use FFmpeg in our application to convert a few different audio formats to pcm_mulaw (Opus, Vorbis, MP3, and other free codecs). We will be invoking the FFmpeg binary as a separate process. We will never distribute the FFmpeg binary as it's just server side when users upload audio files. Our application will also reject and never convert non-free codecs, are we fine to use the FFmpeg binary [23:43:23 CEST] <vincentjames501> distributed on the ffmpeg site? We can deal with the GPL restrictions. [23:43:28 CEST] <jkqxz> --enable-nonfree essentially implies --enable-gpl, because if you can't distribute something at all then you are certainly going to be able to conform to the GPL's requirements on you if you do distribute it. [23:43:45 CEST] <furq> vincentjames501: if you're not distributing binaries, you don't have to comply with the gpl [23:44:02 CEST] <furq> with that said, it sounds like you don't actually need nonfree [23:44:12 CEST] <furq> the builtin decoders are all lgpl [23:44:51 CEST] <vincentjames501> furq, can my company get in trouble just because the FFmpeg binary CAN encode H.264 for example even if we don't use it? [23:44:52 CEST] <jkqxz> You do have to comply with the GPL, but it imposes no restrictions on you whatsoever if you don't distribute it. That's not quite the same as saying you don't have to comply with it :) [23:44:55 CEST] <alexpigment> vincentjames501: you're actually in the best case scenario for not having to worry ;) [23:45:20 CEST] <furq> vincentjames501: i very much doubt it [23:45:55 CEST] <furq> you'd probably be most likely to get in trouble for decoding patented audio codecs [23:46:08 CEST] <alexpigment> dolby used to be a big stickler about that [23:46:14 CEST] <furq> but that stuff only really applies if you're making money within the US [23:46:15 CEST] <alexpigment> but their ac3 patents expired [23:46:42 CEST] <furq> and we never heard from them again [23:46:44 CEST] <furq> oh wait [23:47:32 CEST] <furq> but yeah if your product decodes patented audio codecs then you should probably look into licensing it [23:47:33 CEST] <alexpigment> no i'm just talking about having an application that makes money and decodes ac3. they were very diligent about C&D notices [23:47:36 CEST] <DHE> vincentjames501: enable-gpl and enable-nonfree are about licenses. as everyone's said, if you keep the libraries and binaries private then you can do anything you want. I'm using x264 (gpl) + libfdk_aac (non-free) here. I just can't give you my EXE [23:48:11 CEST] <jkqxz> vincentjames501: If you have some specific reason to be worried about that then you can disable codecs you don't want to include at configure time. [23:48:22 CEST] <furq> vincentjames501: you still technically need a license if the product/service is free, but it's unlikely anyone will ever bother coming after you [23:50:35 CEST] <furq> i'm not really sure how licensing would work for a web service [23:50:50 CEST] <furq> aac has a flat per-unit charge and nothing else afaik [23:51:24 CEST] <vincentjames501> furq, our product is not free, but audio encoding isn't at all what we do. We also only plan on supporting Opus, Vorbis, MP3, and other free codecs. [23:51:35 CEST] <furq> well you're only encoding to ulaw so that bit is fine [23:51:46 CEST] <furq> but you'd still need a license for decoding aac [23:52:20 CEST] <vincentjames501> Ok, if we don't ever decode aac (aka we reject the user upload), are we still on the hook then? [23:52:26 CEST] <furq> probably not [23:52:34 CEST] <vincentjames501> Assuming the binary is "capable" of doing it [23:52:47 CEST] <furq> i mean you can remove the patented codecs from your ffmpeg binary if you're paranoid [23:53:13 CEST] <vincentjames501> I'm just trying to avoid a complex compilation command, having to compile it for a bunch of different environments, updates, etc [23:53:14 CEST] <furq> but there's not really any way for via corp or whoever to know that you're selling a service that uses a binary that's capable of decoding aac [23:53:32 CEST] <vincentjames501> I agree furq, just being overly paranoid [23:53:45 CEST] <furq> well yeah it's not that complicated to disable decoders [23:54:11 CEST] <furq> aac is a very popular codec though so it might be worth looking into licensing it [23:54:55 CEST] <vincentjames501> Yeah, we may if users actually request it. [23:55:15 CEST] <furq> it's 0.98 USD "per unit", whatever that means for a web service [00:00:00 CEST] --- Fri Aug 4 2017

1 0

ffmpeg-devel.log.20170802
by burek 03 Aug '17

03 Aug '17

[01:38:42 CEST] <rcombs> jamrial: actually I just realized I can't make the change you suggested in flacenc because it conflicts with my change to rewrite the sample count value in-muxer [01:39:09 CEST] <jamrial> how so? [01:39:52 CEST] <rcombs> see the last patch in the set [01:40:25 CEST] <rcombs> it overwrites the sample count with the actual number of samples written at the end, regardless of whether the extradata was otherwise updated [01:41:10 CEST] <rcombs> I suppose I could do one write for the updated extradata (only if it had actually changed), and then another seek+write for sample count [01:42:35 CEST] <jamrial> if this header editing you're doing per packet invalidates the contents of STREAMINFO, then you should make sure that's updated to reflect said changes, yes [01:42:37 CEST] <rcombs> but that ends up reading from streaminfo anyway (*shakes fist at 36-bit integers*) so it doesn't really simplify anything [01:44:19 CEST] <jamrial> in any case, i'm not sure if libavformat is the correct place for this kind of bitstream handling [01:44:20 CEST] <rcombs> it's actually sort of tangential to the per-packet editing [01:44:33 CEST] <jamrial> this seems more the job for an avcodec bitstream filter [01:44:50 CEST] <rcombs> e.g. do ffmpeg -i input.flac -c copy -t [period shorter than the duration] out.flac [01:45:09 CEST] <rcombs> currently you'll end up with an incorrect duration in the output, because we copy the streaminfo from the input [01:45:39 CEST] <jamrial> also an invalid md5 checksum, i suppose [01:45:43 CEST] <rcombs> streaminfo and some portions of the FLAC header behave less like codec headers and more like container headers [01:46:47 CEST] <rcombs> (a decent portion of both are completely redundant when muxed into some other container format) [01:47:56 CEST] <rcombs> I can't really fix the md5 thing because it operates on raw audio data, for reasons I will never understand [01:48:34 CEST] <rcombs> but it doesn't actually affect demuxing so I care less about it [01:50:30 CEST] <jamrial> because it's a lossless format. you care about the decoded pcm data, not the encoded flac data [01:51:56 CEST] <rcombs> I mean, an integrity check on one is equivalent to an integrity check on the other [01:52:10 CEST] <rcombs> except doing it on the encoded data would let me rewrite it in the muxer [01:56:02 CEST] <rcombs> I guess it serves as a validation check of the decoder implementation, but& eh [02:24:02 CEST] <atomnuker> dcherednik: it takes floats [02:24:09 CEST] <atomnuker> float samples [03:37:06 CEST] <ZeroWalker> Hmm, if you have Audio and Video encoded in different threads, is there any good practice on how to flush the packets to av_interleaved_write_frame, as it (as far as i can tell) should be done on a singlethread [04:23:40 CEST] <DHE> ZeroWalker: you can have 2 threads do writes as long as you do your own synchronization. like a mutex for them [04:27:34 CEST] <ZeroWalker> so, a CriticalSection (windows) would be fine to use just on that place where it writes? [04:32:14 CEST] <DHE> I decline to answer anything involving APIs I know nothing about [04:35:56 CEST] <ZeroWalker> okay, thanks though, the mutex gives the clear picture:) [08:57:21 CEST] <ldts> I am testing master before rebasing (commit 1193301 lavc/htmlsubtitles: reindent after previous commits) and fate seems to be broken https://hastebin.com/egobehutoq.pas [11:26:16 CEST] <cone-576> ffmpeg 03Paul B Mahol 07master:c79e7534712f: avfilter: add unpremultiply filter [13:12:34 CEST] <J_Darnley> atomnuker: may I bug you with more questions? About diracdec this time. [13:12:56 CEST] <J_Darnley> How does it arrange the coeffs after dequant? [13:13:57 CEST] <J_Darnley> The templated dequant_subband appears to place them in the 4 orientation layout. [13:15:25 CEST] <J_Darnley> because it writes to the buffer with "*dst_r++ = c*sign" [13:17:55 CEST] <atomnuker> its different than the encoder [13:18:25 CEST] <J_Darnley> Well, yeah [13:18:37 CEST] <atomnuker> IIRC during dequant they're reordered [13:20:06 CEST] <J_Darnley> Oh, I should say I'm not looking at master but at your "trimmed" branch on github, if that makes a difference. [13:20:38 CEST] <J_Darnley> I cannot see where the transform interleaves, or treats as interleaved, the coeffs [13:21:21 CEST] <atomnuker> I think the transforms did that themselves as one step [13:21:28 CEST] <atomnuker> so it's not a separate step [13:32:53 CEST] <J_Darnley> Okay. I did find the interleave templated function. (NOTE: I really need to run that through cpp) [13:34:30 CEST] <J_Darnley> Now the idwt_plane function does the idwt over a series of 16 lines [13:35:16 CEST] <J_Darnley> oh ignore that [13:36:05 CEST] <J_Darnley> the coefs can't be laid out so that you could do an idwt of 16 lines because only haar can be done as a block transform. [13:38:02 CEST] <J_Darnley> I do see why you said to look at the encoder first. It is so much simpler. [13:41:47 CEST] <atomnuker> its not [13:49:11 CEST] <J_Darnley> Huh? The encoder is much more simple. Only 1 32-bit data type, only 1 dsp struct, no templating. [13:52:41 CEST] <atomnuker> oh, sorry, I read "I do not see" [13:52:58 CEST] <J_Darnley> Ah [13:55:34 CEST] <J_Darnley> :( I forgot that make doesn't clean a file after cpp like it does for nasm preprocessing [14:35:28 CEST] <iive> J_Darnley: what are you working on? [14:38:27 CEST] <J_Darnley> Trying to make the dirac decoder able to decode anything less than a whole picture. [14:39:01 CEST] <J_Darnley> ideally: make it able to decode a slice independantly of any other [14:39:32 CEST] <J_Darnley> but that extreme is only possible with the haar transform/kernel [16:26:05 CEST] <J_Darnley> atomnuker: is init_planes() in diracdec.c called every frame or just when frame properties change? [16:26:30 CEST] <J_Darnley> It is called from dirac_decode_picture_header [16:27:11 CEST] <J_Darnley> which itself is called Sometimes(tm) [16:28:33 CEST] <atomnuker> dirac packets can have multiple subtypes of packets in them [16:28:59 CEST] <atomnuker> but there must always be a picture header, some other header [16:29:22 CEST] <atomnuker> and they're always wrapped in those start of sequence headers [16:29:41 CEST] <atomnuker> so its not called sometimes, its called on every frame [16:31:25 CEST] <J_Darnley> thankyou [17:07:06 CEST] <J_Darnley> Yay! Something has come out which looks a littke like what it should. [17:08:12 CEST] <ZeroWalker> how do you use avdevice_capabilities_create, i am trying to use it on a dshow device format context [17:08:51 CEST] <J_Darnley> On second thoughts, that is *very* like what it should be. [17:11:38 CEST] <J_Darnley> I am clearly missing the last row of slices [17:12:01 CEST] <J_Darnley> so my if condition must be wrong [17:12:34 CEST] <J_Darnley> Ah! Should be less than or equal to. [17:14:50 CEST] <J_Darnley> Oh wow. I don't believe it. [17:14:59 CEST] <J_Darnley> That fixed all my problems? [17:43:08 CEST] <J_Darnley> oh... not quite all my problems [17:43:35 CEST] <J_Darnley> 420 doesn't work completely [17:47:27 CEST] <kierank> J_Darnley: don't waste too much time on that if you can't get it to work [17:57:38 CEST] <J_Darnley> Oh, I think it is just the chroma from the last row of slices not being transformed [17:58:17 CEST] <J_Darnley> hd720only has 360 chroma lines which is not mod16 [17:58:52 CEST] <J_Darnley> That means I need to test hd1080 [18:00:51 CEST] <J_Darnley> Hm. Needs more work. 1080 has wrong lines throughout [18:17:57 CEST] <Compn> anyone test 8k workflow in ffmpeg ? [20:05:47 CEST] <BBB> Compn: you mean other than -s 7680x4320? [20:05:56 CEST] <BBB> Compn: or are you talking about how slow is it"? [20:55:09 CEST] <Compn> BBB : real world samples, testing if all filters and containers handle it, etc [20:57:34 CEST] <BBB> hm& nope; only on 4K from me so far [20:57:39 CEST] <BBB> sorry :/ [20:58:33 CEST] <Compn> is ok [20:58:38 CEST] <Compn> i've heard youtube trial 8k [20:58:41 CEST] <Compn> is why i ask :) [20:59:13 CEST] <Compn> http://neumannfilms.net/?product=ghost-towns-8k [21:05:54 CEST] <thardin> is relying almost entirely on compute_pkt_fields() kosher? [21:06:16 CEST] <thardin> I just compute pkt->duration and make use of ff_pcm_read_seek(), seems to work just fine [21:15:27 CEST] <ZeroWalker> when you get data from a dshow device, shouldn't it be event based, or are you supposed to poll av_read_frame? [21:16:24 CEST] <BtbN> the libav* APIs are synchronous [21:17:50 CEST] <ZeroWalker> so av_read_frame will block till data arrives? [21:18:07 CEST] <BtbN> if you don't use nonblocking mode, yes. [21:18:20 CEST] <ZeroWalker> nice:) [21:53:12 CEST] <cone-058> ffmpeg 03Aleksandr Slobodeniuk 07master:0aa8fa963f79: avformat/riff.h : remove unused function parameter "const AVCodecTag *tags" of "void ff_put_bmp_header()" [21:53:13 CEST] <cone-058> ffmpeg 03Aleksandr Slobodeniuk 07master:50aeb6e4edf6: avformat/riff: remove useless tag correlation 'mpg2'->MPEG1VIDEO. [23:18:51 CEST] <ZeroWalker> hmm, how do i know if something is RGB or BGR (except looking at the end result) [23:19:23 CEST] <ZeroWalker> cause of example, in directshow a device shows RGB24, but in ffmpeg it shows as BGR [23:20:15 CEST] <ZeroWalker> though then again, it's flipped in ffmpeg, and it has some exadata thing that says "bottom up" i think [23:23:19 CEST] <Compn> ZeroWalker : depends on your source [23:32:45 CEST] <ZeroWalker> hmm, well why i wonder is cause as far as i can tell, you can't list the dshow devices programatically, so i have to do it the normal way and then give ffmpeg the information afterwards [23:33:46 CEST] <ZeroWalker> and it's kinda hard is the source says RGB24 but it's actually BGR for ffmpeg, so unless there's a way to know it, it's a guessing game:( [23:33:57 CEST] <Compn> yes in mplayer its interesting [23:34:07 CEST] <Compn> since we have binary codecs, so we have to add "flip" code to them sometimes [23:34:14 CEST] <Compn> to get them working in vfw/dshow [23:34:20 CEST] <Compn> (and display right side up) [23:34:30 CEST] <Compn> thats all enumerated with guid in dshow/windows [23:34:50 CEST] <Compn> so you're trying to add a new dshow device ? [23:35:01 CEST] <Compn> or are you trying to figure out if a webcam will display correctly ? [23:35:10 CEST] <Compn> because i can offer solutions and ideas [23:35:22 CEST] <Compn> depending on what you are doing haha [23:38:06 CEST] <ZeroWalker> well i simply want first list All dshow devices and there capabilities (formats etc) in ffmpeg (if it's possible programatically), cause that would solve that problem [23:39:07 CEST] <ZeroWalker> If that's not possible and i have to get all that information via Windows itself, then i need to somehow be able to intrepretet the mediatype information cause i guess somehow you can tell if it's flipped, BGR and whatnot. Even if Windows just says "RGB24" [23:44:23 CEST] <J_Darnley> It must be possible to list dshow devices programtically, ffmpeg.exe does it. [23:44:43 CEST] <J_Darnley> I have no idea how you would do that with the ffmpeg API though. [23:45:30 CEST] <ZeroWalker> https://trac.ffmpeg.org/wiki/DirectShow [23:45:43 CEST] <ZeroWalker> FFmpeg does not provide a native way to do this yet, but you can lookup the devices yourself or just parse standard out from FFmpeg [23:45:52 CEST] <ZeroWalker> it's really weird:( [23:46:09 CEST] <ZeroWalker> perhaps that information is old though, what do i know [23:46:49 CEST] <ZeroWalker> i mean, there are functions that seems to do what i want, but i can't get them to work and basically no information on examples can be found with it either. Or i am just bad at googling xd [23:47:44 CEST] <J_Darnley> Yeah, that is what I was thinking of. [23:48:01 CEST] <J_Darnley> I know nothing of using the API though. [23:49:11 CEST] <J_Darnley> To me the command line just looks to me like API use of: opening a "file", library printing stuff, then returning. [23:51:15 CEST] <ZeroWalker> yeah, it basically looks like a hacky way [23:51:33 CEST] <ZeroWalker> in the API i would assume it to be something like avdevice_list_input_sources this one or something [23:51:55 CEST] <ZeroWalker> but, can't get any of these to work, so i am doing something wrong, or they aren't what i think they are [23:52:46 CEST] <nevcairiel> avdevice is just a hack around the existing demuxer api, it doesnt expose any magic function. if you're lucky the devices support enumeration to the log, but as a API user that doesn't help you, so basically you're stuckj there [23:53:53 CEST] <ZeroWalker> hmm [23:53:57 CEST] <nevcairiel> dshow in any case has the log device list thing, which may be useful for the CLI, but nothing else [23:54:34 CEST] <ZeroWalker> how does it actually get the dshow input etc in the first place? [23:55:13 CEST] <ZeroWalker> cause it's Really messy to get directshow data cause of the filters, you have to use samplegrabber etc (as far as i know), and using ffmpeg (as i am encoding it anyhow) is much cleaner in that regard [00:00:00 CEST] --- Thu Aug 3 2017

1 0

ffmpeg.log.20170802
by burek 03 Aug '17

03 Aug '17

[00:28:23 CEST] <SolarAquarion> for some reason video isn't playing for the videos [00:28:24 CEST] <SolarAquarion> only the audio [00:28:29 CEST] <SolarAquarion> only gstreamer based players work, not ffmpeg based players [00:28:49 CEST] <SolarAquarion> Only ffmpeg2.8 is working fine [00:28:53 CEST] <SolarAquarion> weird [02:38:04 CEST] <stapler> hi, is it possible to have a muxer write to a buffer in memory instead of a file? [03:14:22 CEST] <klaxa> stapler: see the custom io example maybe? https://www.ffmpeg.org/doxygen/trunk/avio_reading_8c-example.html [03:14:26 CEST] <klaxa> that does exactly that [03:14:33 CEST] <klaxa> except for reading [03:14:45 CEST] <stapler> oh, thank you [03:14:49 CEST] <klaxa> you'll have to write it for writing instead, it works basically the same though [09:09:57 CEST] <manjaro-kde5_> Good morning, anyone here? [09:11:21 CEST] <manjaro-kde5_> I'm using a blackmagic decklink card as an video input and want to place that output with ffplay on my screen on a certain spot. [09:12:53 CEST] <manjaro-kde5_> I found that you can make a borderless window with "-noborders" and being able to set the resolution with the "-x" and "-y" switches, but how can I place the video somewhere like 50 pixels from top right on the screen without moving it by hand? [09:13:24 CEST] <manjaro-kde5_> Do I have to use any special filters to achive that? [11:55:52 CEST] <thebombzen> I have /usr/local/lib added to my ld.so.conf so /usr/local/bin/ffmpeg can find it [11:56:26 CEST] <thebombzen> unfortunately this makes it so /usr/bin/ffmpeg (installed from the package manager) also see these and the library mismatch makes it useless without LD_PRELOAD [11:56:53 CEST] <thebombzen> is there an easy way to make /usr/bin/ffmpeg point to /usr/lib/libav* other than adding a custom post-install hook to do that? [12:55:51 CEST] <the_k> would it be possible to scan for a specific colour range in an incoming video stream? [12:56:32 CEST] <the_k> i.e. a security camera overwatching a front door - when a guy with a specific colour jacket (postman/deliveryman) comes into the scene, it could trigger something [13:01:02 CEST] <Bear10> Hello, does anyone know how to have an overlay of an image that you can change dynamically? Or if maybe someone knows of a way to achieve this via another means maybe something like writing to a mjpeg from another process or something? [13:04:10 CEST] <Nacht> Bear10, define 'Dynamically'. Using FFMPEG to add an overlay will just recode the entire clip, thus the 'overlay' pixels become part of the movie itself. [13:04:12 CEST] <sine0> I have converted some cctv video to libx264 for my boss but he cant play it on his default computer, what is the best, low filesize compression type to give to people ? [13:04:29 CEST] <sine0> will play in windows media player etc [13:04:37 CEST] <Bear10> Nacht: well I'm working on live streams and so I want to be able to add an image in, then take it out etc as I'm streaming live [13:05:08 CEST] <Nacht> Bar10, you mean like OBS does ? [13:05:12 CEST] <Bear10> Nacht: exactly [13:06:14 CEST] <Nacht> Bear10, then the obvious question comes, why not use OBS ? [13:06:52 CEST] <Bear10> Nacht: because we're developing a platform that's very specific to our users, can't have them installing software on their pcs or anything as advanced as OBS [13:09:23 CEST] <Nacht> afaik, FFMPEG will take the image used for overlay and store it in memory the first time, so changing the image during the stream won't do much, as ffmpeg already has the intial one and will ignore it. [13:10:20 CEST] <Bear10> yeah that's what I imagined [13:10:40 CEST] <Nacht> It will prolly require custom coding, which uses the same processes as FFMPEG does when using overlay, only with constant refreshing before encoding the frames [13:11:17 CEST] <Nacht> So bascily, a sort of 'OBS lite' [13:12:12 CEST] <Bear10> Exactly, I thought maybe there'd be a way for me to use let's say 2 video streams and have one be an mjpeg, write to it and see if it would keep streaming [13:12:22 CEST] <Bear10> but it didn't seem very efficient (haven't tested the hypothesis either) [13:13:11 CEST] <Nacht> There are ways with clients as well, so you put the overlay on the client side. But that would really depend on your use-case [13:15:54 CEST] <Bear10> yeah hmm [13:15:59 CEST] <Bear10> do you have any suggestions regarding the custom coding [13:16:22 CEST] <Bear10> if i should be looking at ffmpeg github and modifying the CLI tool or seeing if i can somehow incorporate it into a new C app/tool or something? [13:20:08 CEST] <Nacht> Not much I can say about that. However, I've seen quite a few people mentioning using the AV library's of FFMPEG to use in their codes. There's something about it in the FAQ: [13:20:08 CEST] <Nacht> http://ffmpeg.org/faq.html#Are-there-examples-illustrating-how-to-use-the-F… [13:22:32 CEST] <Bear10> awesome thank you Nacht [13:49:13 CEST] <manjaro-kde5_> Hi there [13:49:36 CEST] <manjaro-kde5_> I'm using a blackmagic decklink card as a video input and want to place that output with ffplay on my screen on a certain spot. I found that you can make a borderless window with "-noborders" and being able to set the size of that window with the "-x" and "-y" switches, but how can I place the video somewhere like 50 pixels from top right on the screen without moving it by hand? Do I have to use any special filters to achive that? [13:50:51 CEST] <SolarAquarion> I have a weird issue with the playing of videos that isn't in ffmpeg2.8 version. Like Videos have a framerate of 0, IE they don't play at all but the videos do [13:51:07 CEST] <SolarAquarion> i mean the audio [13:57:20 CEST] <elmarikon> does it help to set the framerate manually? [13:57:28 CEST] <elmarikon> ex. -r 25 [13:58:10 CEST] <Nacht> manjaro-kde5_>: So you want to position the window ? Windows or Linux ? [13:59:15 CEST] <manjaro-kde5_> Win [13:59:30 CEST] <Nacht> You'll need something like this for that: [13:59:31 CEST] <Nacht> https://ritchielawrence.github.io/cmdow/ [13:59:31 CEST] <elmarikon> manjaro-kde5_ maybe u can use -vf pad=640:480:0:40 [13:59:36 CEST] <elmarikon> sth. like that... [14:00:06 CEST] <manjaro-kde5_> Thanks a lot [14:00:44 CEST] <manjaro-kde5_> Thought there is an option to place it bei doing something linke -resolution 1024x786+50+50 [14:01:13 CEST] <Nacht> It's not really the video itself you want to manipulate, but the ffplay window itself [14:03:18 CEST] <Nacht> if you would do something like '1024x786+50+50' you would only end up with a bigger video, but the position of the window wouldnt really change much. You'd just end up with a weirdly sized video [14:32:22 CEST] <manjaro-kde5_> Yes, thats what I found out already... [14:32:37 CEST] <manjaro-kde5_> Thanks anyway, Nacht... [14:39:30 CEST] <momomo> i am testing to feed youtube live a livestream [14:40:29 CEST] <momomo> what is the best way to minimize cpu usage on the ffmpeg running server ? raw serving .. is that possible ... i'd like to do really through tvheadend .. but I don't think youtube can make the request, but I have to connect to youtube [14:49:01 CEST] <Nacht> momomo: Youtube's required live encoder settings: https://support.google.com/youtube/answer/2853702?hl=en&ref_topic=6136989 [14:52:22 CEST] <momomo> Nacht: i want to try to feed it raw from tvheadend [14:52:32 CEST] <momomo> that page suggest formatting it [14:52:46 CEST] <Nacht> as well as feeding them RTMP [14:52:51 CEST] <oerg866> hello again [14:53:25 CEST] <oerg866> i'm archiving a couple of very old VHS tapes and a few of them were recorded with really bad reception... what's the best method for denoising these with ffmpeg [14:53:34 CEST] <oerg866> the files are lossless avi files (lagarith) [14:54:29 CEST] <oerg866> http://img.ctrlv.in/img/17/08/02/5981cb6333976.png <-- this is the kind of noise level we're talking about here [14:55:12 CEST] <momomo> Nacht: so the command would be? I have these variabnts as of now: [14:55:13 CEST] <momomo> https://hastebin.com/ikiyuxozig.m [15:01:13 CEST] <Nacht> momomo: The 2nd one looks valid enough. I'm not sure what kind of stream tvheadend gives off ? Is it already in H.264/AAC/MP3 ? Cause if so, you could just copy and have hardly any CPU usage [15:01:35 CEST] <Nacht> momomo: input would be something like 'http://ip.of.tvheadend.streamer:9981/stream/channelid/number_of_channel' ? [15:01:48 CEST] <Nacht> I'm not really familiar with tvheadend [15:13:34 CEST] <momomo> yes [15:54:33 CEST] <elmarikon> oerg866: looks like removegrain could help, sice thios is more gran then noise... [15:55:01 CEST] <elmarikon> -o [15:55:50 CEST] <guikos> Hi, i'm trying to transcode an h264 HD1080p 29,97fps video into DVCPRO25 without too much stutter and without loosing audio sync. Any ideas? [16:32:01 CEST] <elmarikon> you could use the filter "fps"... [16:32:03 CEST] <elmarikon> http://ffmpeg.org/ffmpeg-filters.html#fps-1 [16:32:16 CEST] <elmarikon> But I do not know how good it looks... [16:32:59 CEST] <elmarikon> or drop to 23.976 and the speed up to 25 again... that's how it is done very often... [16:33:45 CEST] <guikos> @elmarikon Thanks, I'll try that [16:48:25 CEST] <djgl> Dropping to 23.976 fps only works for videos that were sped up from 23.976 to 29.97 before [16:57:58 CEST] <sikilikis> so I need help. I'm streaming 24/7 to youtube on my raspberry pi using ffmpeg. No matter what I do, I always seem to get disconnected from youtube with a generic "connection reset by peer" type of error [16:58:25 CEST] <sikilikis> here's a pastebin with how I have ffmpeg configured, the ffmpeg command, and the errors I'm seeing with timestamps: https://pastebin.com/xGmBnwxM [16:59:13 CEST] <sikilikis> I'm running ffmpeg in a loop so that when it gets disconnected it can hopefully reconnect and resume the stream, but sometimes it doesn't reconnect for like ten minutes. I've tried both using librtmp-dev and whatever the native ffmpeg rtmp lib is [16:59:27 CEST] <sikilikis> both are giving me generic disconnect errors and I can't figure out what is causing it [17:00:42 CEST] <JodaZ> JASTON, you got any further with individual live segmenting? [17:02:09 CEST] <sikilikis> sometimes it will stream for days without errors and sometimes it errors after an hour. Or minutes [17:02:46 CEST] <JodaZ> sikilikis, can you send anything besides flv? [17:03:01 CEST] <sikilikis> to youtube? don't think so [17:03:24 CEST] <JodaZ> sikilikis, connection reset by peer could either be youtube shutting the connection or basically anything in between you and them (firewall, router, your isp etc etc) [17:03:24 CEST] <sikilikis> and just for the record, it DOES work. It just randomly disconnects [17:04:10 CEST] <sikilikis> What can I do to get more info? Because this has been an issue for me for months and I can't find anything about it [17:05:21 CEST] <elmarikon> djgl: that's not true. [17:17:04 CEST] <sikilikis> no ideas anyone? [17:29:32 CEST] <djgl> elmarikon: yeah, you can try to run IVTC algorithms on material that never underwent TC, but it will look worse than picking 25 approximately equidistant frames per second from the 29.97 frames that are available. [17:41:18 CEST] <cq1> Does anyone here know where I could find some lossless 2160p source for testing compression? [17:41:37 CEST] <cq1> I only need enough to plausibly form a GOP or two at reasonable parameters (10 seconds is fine). [18:05:37 CEST] <Aerroon> so i gather that ffmpeg is not allowed to be distributed in a fashion where it includes nvenc support? [18:06:06 CEST] <Diag> Did somebody say GOP [18:06:36 CEST] <Diag> also Aerroon graphics card encoding sucks [18:06:46 CEST] <Aerroon> ehh [18:06:49 CEST] <Aerroon> isn't it good enough? [18:06:49 CEST] <Diag> you need like 10x the bitrate for a similar quality video [18:06:50 CEST] <thebombzen> cq1: jellyfish.us [18:06:59 CEST] <Diag> Its fast, yes [18:07:02 CEST] <Aerroon> no i mean [18:07:20 CEST] <thebombzen> cq1: err, http://jell.yfish.us/ [18:07:22 CEST] <Aerroon> ssim and psnr gave me similar results from nvenc on obs to x264 cbr [18:07:25 CEST] <Aerroon> at same filesize [18:07:33 CEST] <Diag> yes, CBR [18:07:49 CEST] <Diag> hardly anyone uses cbr [18:07:53 CEST] <Aerroon> but i'm not 100% certain that it was similar, because i can't guarantee that the frames are in sync unless i fully reencode [18:07:57 CEST] <Diag> unless its for a standard [18:07:57 CEST] <Aerroon> uh [18:08:00 CEST] <Aerroon> well, i do [18:08:04 CEST] <Aerroon> for streaming i do use cbr [18:08:06 CEST] <DHE> Aerroon: GPU encoding is worse than software encoding in terms of quality, but it's very fast and low CPU impact [18:08:07 CEST] <thebombzen> cq1: they're not lossless, but if you pick the ones with enormous bitrates it might be close enough [18:08:13 CEST] <Aerroon> again [18:08:21 CEST] <Aerroon> it gave a higher ssim and psnr result [18:08:30 CEST] <Diag> Why not use the obs that supports nvenc? [18:08:36 CEST] <Aerroon> i want to compare again, but this time i want to encode all the sources with ffmpeg so it's better to compare [18:08:42 CEST] <Aerroon> i am going to use obs with it [18:08:44 CEST] <Aerroon> i want to compare quality [18:08:51 CEST] <Diag> Its like a completely different codec almost though [18:08:52 CEST] <Aerroon> to make sure there are no wrong frame problems in comparisons [18:09:06 CEST] <thebombzen> Aerroon: x264 vastly outperforms NVENC in quality per bitrate [18:09:11 CEST] <Aerroon> oh boy [18:09:16 CEST] <thebombzen> this is well-known [18:09:16 CEST] <Aerroon> do i have to say this a third time again? [18:09:29 CEST] <Aerroon> which part of "ssim and psnr gave me similar numbers" is so difficult to understand [18:09:35 CEST] <Diag> Show us [18:09:36 CEST] <thebombzen> did you use preset ultrafast? [18:09:36 CEST] <Aerroon> so i want to test further [18:09:48 CEST] <thebombzen> we're all very skeptical, because it's well-known that x264 is better than nvenc [18:10:00 CEST] <Diag> Aerroon: set that shit to placebo and be amazed [18:10:01 CEST] <Aerroon> https://docs.google.com/spreadsheets/d/1lkmYF2lphAxkdVWVy2qxgLR--88fDBTjbu4… [18:10:05 CEST] <thebombzen> the only way I can see this happening is if you used the ultrafast preset [18:10:12 CEST] <Aerroon> these are the results [18:10:14 CEST] <Aerroon> of ssim [18:10:23 CEST] <Aerroon> but my question is not about this [18:10:34 CEST] <Aerroon> it's about whether i need to compile ffmpeg myself if i want nvenc support [18:10:34 CEST] <thebombzen> out of curiosity, did you use --tune ssim? [18:10:41 CEST] <Aerroon> no [18:10:45 CEST] <thebombzen> well there you go [18:10:58 CEST] <thebombzen> x264 optimizes for humans, not SSIM. Unless you disable that and use --tune ssim [18:11:55 CEST] <thebombzen> Also, your spreadsheet disagrees with you. x264 beats NVENC [18:12:10 CEST] <Aerroon> https://pastebin.com/Y2PxtXCy [18:12:15 CEST] <Aerroon> this is what i got [18:12:19 CEST] <Aerroon> yeah [18:12:23 CEST] <Aerroon> x264 beats nvenc [18:12:32 CEST] <Aerroon> at settings my cpu can't actually encode at [18:12:34 CEST] <Diag> As far as AMDs first gen gpu encoding goes, i have to encode at 35mbps at 60fps to get the same quality as a tiny ass x264 encoded file [18:12:50 CEST] <Aerroon> and i'm not here to argue about this [18:12:52 CEST] <thebombzen> Aerroon: well what did you expect would happen if you turned x264's settings down so you can encode it in realtime [18:12:52 CEST] <Aerroon> i want to test this [18:13:00 CEST] <Diag> lol [18:13:03 CEST] <Aerroon> let's see [18:13:12 CEST] <Aerroon> i mentioned it was going to be for streaming [18:13:24 CEST] <Diag> I think he/shes just looking for high performance adequate quality video encoding [18:13:26 CEST] <Aerroon> and now you're telling me "oh of course it doesn't work if you turn settings down" [18:13:30 CEST] <Aerroon> no, i'm not [18:13:34 CEST] <Diag> no? [18:13:37 CEST] <Diag> then youre crazy lol [18:13:38 CEST] <Aerroon> i'm asking if i need to compile ffmpeg myself to try nvenc [18:13:42 CEST] <Aerroon> or if i can find a redistributed build [18:13:54 CEST] <Aerroon> i will run the tests myself and see what results i get and then decide [18:14:09 CEST] <thebombzen> ffmpeg's Zeranoe builds have nvenc support built in. On Linux, it depends on the downstream build flags [18:14:24 CEST] <Aerroon> visually looking at it i can't actually tell much of a difference between the x264 settings i can run at this limited bandwidth and nvenc or even quicksync [18:14:36 CEST] <Aerroon> i can tell that the quality isn't very good, but i can't tell which one is better [18:14:44 CEST] <Aerroon> thebombzen, thank you! [18:15:16 CEST] <Aerroon> the problem with my tests so far is that they are basically recordings with obs and simply hoping that they compare the exact same frames [18:15:29 CEST] <Aerroon> but i'd like to make sure, and ffmpeg is amazing [18:15:45 CEST] <thebombzen> What you should do is make a short recording in OBS with lossless x264 ultrafast [18:15:53 CEST] <thebombzen> and then use the CLI tool to process that [18:16:05 CEST] <thebombzen> warning, it'll be absolutely enormous. hence, short. [18:16:07 CEST] <Aerroon> well that's the plan [18:16:17 CEST] <Aerroon> well i'm not gonna record it [18:16:22 CEST] <Aerroon> i'm gonna go look for some lossless source [18:16:28 CEST] <Aerroon> a few come to mind already [18:17:15 CEST] <Aerroon> thank you for your help guys [18:17:59 CEST] <Diag> make sure to show us the results [18:18:09 CEST] <Diag> im interested [18:20:37 CEST] <Aerroon> sure [18:20:40 CEST] <thebombzen> Aerroon: try http://jell.yfish.us/ [18:20:50 CEST] <thebombzen> it's not lossless but the bitrates are so enormous that it might be good enough for your purposes [18:21:50 CEST] <Aerroon> okay now i need to figure out why my ffmpeg version is still showing the old one [18:22:09 CEST] <thebombzen> what do you mean "my ffmpeg version is still showing the old one" [18:22:15 CEST] <thebombzen> on Windows, it's probably a PATH thing [18:22:18 CEST] <Aerroon> yep [18:22:20 CEST] <Aerroon> and i updated path [18:22:28 CEST] <thebombzen> restart your command prompt [18:22:32 CEST] <thebombzen> it caches that [18:23:12 CEST] <Diag> why not use fraps to record [18:23:21 CEST] <Diag> its already lossless and not even h264 iirc [18:24:02 CEST] <Aerroon> imagemagick [18:24:07 CEST] <Diag> ? [18:24:15 CEST] <Aerroon> imagemagick dropped another ffmpeg version into my path [18:24:16 CEST] <Diag> what of it [18:24:18 CEST] <Aerroon> that's why it didn't update [18:24:19 CEST] <Diag> lol [18:24:32 CEST] <Diag> does imagemagick have an interface? [18:24:38 CEST] <Diag> I thought it was just a library [18:24:59 CEST] <thebombzen> Diag: yes [18:25:04 CEST] <thebombzen> convert, identify, etc. [18:25:07 CEST] <thebombzen> those are ImageMagick [18:25:09 CEST] <Diag> weird [18:25:23 CEST] <thebombzen> as for "Why not use FRAPS" [18:25:26 CEST] <thebombzen> well OBS is much better [18:25:38 CEST] <Diag> well yes and no [18:25:54 CEST] <thebombzen> how is OBS not better than FRAPS [18:26:03 CEST] <Diag> In this situation, I think fraps is a good substitute if youre looking for a 30 second video thats not compressed [18:26:10 CEST] <thebombzen> Why? [18:26:18 CEST] <Diag> because fraps is simple [18:26:21 CEST] <Aerroon> how good is nvenc's lossless version? [18:26:28 CEST] <Diag> probably worse XD [18:26:43 CEST] <Aerroon> fraps you can literally have it write separate images if you so desire [18:26:55 CEST] <thebombzen> You can also do that with OBS. But you shouldn't. [18:27:00 CEST] <Aerroon> i do think i have to find something other than jellyfish though [18:27:07 CEST] <thebombzen> Aerroon: NVENC's lossless is not good, but it's fairly comparable to anything that encodes losslessly in realtime. [18:27:08 CEST] <Aerroon> 3 hours to download [18:27:35 CEST] <thebombzen> Realtime lossless encoding is not something that's going to be efficient [18:27:45 CEST] <dsc_> why record things if you can 'live the moment'. Priceless parts of life can't be recorded. With or without fraps/obs, it doesnt matter. Some moments are too precious to capture. [18:27:51 CEST] <dsc_> for anything else you can use mastercard [18:27:58 CEST] <Diag> lol [18:28:02 CEST] <Diag> I love my radeon relive [18:28:08 CEST] <Diag> its the greatest shit [18:28:31 CEST] <dsc_> is it geforce experience but then for radeon? [18:28:32 CEST] <thebombzen> Some things require a known exact configuration. [18:28:36 CEST] <Diag> nope [18:28:37 CEST] <thebombzen> For everything else, there's git master [18:28:57 CEST] <Diag> dsc_: its literally built right into the radeon software shit, no extra bullshit, no accounts [18:28:58 CEST] <Diag> more options [18:29:01 CEST] <Diag> more streaming options [18:29:10 CEST] <Diag> less gpu impact [18:29:10 CEST] <thebombzen> Aerroon: anything that can do it (utvideo, ffvhuff, x264 lossless ultrafast, nvenc lossless) is going to be inefficient in realtime [18:29:11 CEST] <dsc_> yeah and worse drivers because its ATI ? [18:29:14 CEST] <dsc_> ;') [18:29:19 CEST] <thebombzen> so NVENC is not great, but nothing is. [18:29:23 CEST] <Aerroon> oh yeah i know [18:29:24 CEST] <Aerroon> i meant [18:29:25 CEST] <Diag> nvidia has horrible ass drivers [18:29:28 CEST] <Aerroon> is nvenc lossless actually lossless [18:29:36 CEST] <Diag> probably [18:29:48 CEST] <thebombzen> Aerroon: I'm not sure if it's bit-exact [18:29:53 CEST] <thebombzen> but there's no quantization [18:30:01 CEST] <thebombzen> it's lossless in that sense [18:31:05 CEST] <thebombzen> Aerroon: note that NVENC doesn't support RGB H.264 [18:31:19 CEST] <thebombzen> you'll need to convert it to yuv444p (also called I444) first. This might be lossy [18:31:23 CEST] <thebombzen> or at least, not bit-exact. [18:31:46 CEST] <Diag> why would they do that [18:32:25 CEST] <thebombzen> why would they do what [18:32:34 CEST] <Diag> https://www.youtube.com/watch?v=k2ByHspr9sQ [18:32:38 CEST] <Diag> why would they do that ^ [18:34:23 CEST] <Aerroon> so i have a video in images [18:34:30 CEST] <Aerroon> what should i encode it as to be the main thing to compare to [18:35:01 CEST] <thebombzen> Diag: same reason people do this: https://www.youtube.com/watch?v=GDU-fW36qaA [18:35:07 CEST] <BtbN> thebombzen, nvenc can take RGB input just fine. But it will convert it to yuv internally [18:35:18 CEST] <thebombzen> BtbN: that's the same issue though [18:35:25 CEST] <thebombzen> "not big-exact" [18:35:27 CEST] <thebombzen> bit* [18:42:53 CEST] <Diag> thebombzen: i died a littler [18:42:58 CEST] <Diag> little* [18:44:58 CEST] <Diag> holy fuck [18:44:58 CEST] <cq1> Does anyone know how good GoPro's hardware H.264 encoders are? I always approach anything other than x264 with extreme skepticism, and assume that their encoders are absolute rubbish. [18:45:08 CEST] <cq1> thebombzen: Thanks for the resource. [18:45:27 CEST] <Diag> thebombzen: so this guy brings me his computer telling me its running slow [18:45:32 CEST] <Diag> 107 days of uptime [18:45:36 CEST] <Diag> hes just been putting it to sleep [18:45:53 CEST] <BtbN> That's what Windows does by default when you tell it to Shutdown [18:46:03 CEST] <Diag> yes [18:46:08 CEST] <BtbN> Only an explicit reboot actually reboots it... [18:46:10 CEST] <Diag> I just cannot believe that it has 107 days [18:46:19 CEST] <Diag> its a laptop, it should shut down from other crpa [18:46:28 CEST] <BtbN> it'll just suspend to disk [18:46:29 CEST] <Diag> hibernation is disabled [18:46:47 CEST] <Diag> no disk suspension [18:46:50 CEST] <Diag> its been asleep [18:47:57 CEST] <cq1> thebombzen: Yeah, this looks okay enough. I guess HEVC 10-bit at 400 Mbps (assuming it was encoded by a non-trash encoder) will probably be high enough quality for my purposes. Thanks. [18:59:43 CEST] <Aerroon> thebombzen, https://pastebin.com/XdUr27Pk this is what i got [18:59:47 CEST] <Aerroon> i'm on a gtx 1080 [19:00:08 CEST] <Aerroon> but unfortunately i don't think these results are very useful for me and i'll have to revisit it [19:00:54 CEST] <Aerroon> the source isn't high enough resolution and when i looked through the results in vlc i noticed that the bitrates were throwing way too high [19:01:20 CEST] <thebombzen> Aerroon: again, if you're trying to use ssim, you should use -tune:v ssim [19:01:48 CEST] <thebombzen> x264's psychovisual optimizations give visually better results with worse ssim [19:02:01 CEST] <thebombzen> if you want ssim to be useful, you should tell x264 to optimize for SSIM, rather than subjective quality [19:02:53 CEST] <thebombzen> Aerroon: other things about x264 - don't set the profile if you're just testing. x264 picks the most restrictive profile that can encompass the other encoding settings. Setting the profile explicitly is not recommended unless you're targeting a device that has that restriction [19:02:57 CEST] <Aerroon> well even then the problem witht he source video would still be there [19:03:12 CEST] <Aerroon> thebombzen, as i will use this for streaming eventually [19:03:14 CEST] <thebombzen> Don't set the pixel format to nv12 [19:03:17 CEST] <Aerroon> i think it's useful [19:03:21 CEST] <thebombzen> It's completely useless [19:03:22 CEST] <Aerroon> and of course i will set pixel format to nv12 [19:03:27 CEST] <Aerroon> that's what i'm going to use when i'll stream [19:03:28 CEST] <thebombzen> Don't set it to nv12 [19:03:31 CEST] <Aerroon> so why would i not mimic those settings [19:03:41 CEST] <thebombzen> because nv12 is non-planar [19:03:52 CEST] <thebombzen> x264 internally converts it to to planar (i.e. yuv420p, or I420) [19:04:02 CEST] <thebombzen> you should use -pix_fmt yuv420p [19:04:12 CEST] <thebombzen> also, it's -pix_fmt, not -pixel_format. long story. [19:04:40 CEST] <thebombzen> nv12 is interleaved, and yuv420p is planar. x264 works in planar so you're going to want to use that [19:05:30 CEST] <Aerroon> thanks [19:05:34 CEST] <JEEB> detail: x264 actually natively works in nv12 [19:05:37 CEST] <JEEB> ;) [19:05:38 CEST] <Aerroon> but [19:05:58 CEST] <thebombzen> JEEB: lol, haha [19:05:58 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=387828eda87988ad821ce30f8188… [19:06:02 CEST] <Aerroon> "this is what i'm going to end up using so i should run tests with it too" [19:06:11 CEST] <JEEB> it was changed in 2010 to improve SIMD'ification [19:06:14 CEST] <thebombzen> Aerroon: you should not use -pix_fmt nv12 for the final result either [19:06:28 CEST] <thebombzen> x264 receives yuv420p [19:06:30 CEST] <JEEB> most likely the libavcodec wrapper still feeds it planar stuff [19:07:00 CEST] <thebombzen> yea. if you use -pix_fmt nv12, avcodec's libx264 will reject that and request planar input [19:07:19 CEST] <JEEB> shouldn't be too hard to patch it to take in nv12 as well I guess? [19:07:27 CEST] <JEEB> "This change also extends the API to allow direct NV12 input" [19:07:49 CEST] <thebombzen> probably. I'm not sure if it ignores the -pix_fmt nv12, or if it autoinserts scale,format=nv12,scale,format=yuv420p [19:08:08 CEST] <Aerroon> thebombzen, but doesn't it end up nv12 on youtube anyway? [19:08:12 CEST] <thebombzen> No [19:08:23 CEST] <thebombzen> Youtube H.264 is in yuv420p [19:08:40 CEST] <thebombzen> given that the video you're capturing will be in planar when FFmpeg sees it, it's best to let libx264 handle any sort of nv12 conversion [19:08:54 CEST] <Aerroon> ??????? [19:08:56 CEST] <Aerroon> okay [19:08:58 CEST] <JEEB> well, technically I bet it's coded in separate planes but what the decoder output is depends on the decoder [19:09:01 CEST] <Aerroon> so i'm doing this entire thing [19:09:15 CEST] <Aerroon> to compare encoders in quality to know which one to use with obs for *streaming* [19:09:18 CEST] <thebombzen> Aerroon: what I'm telling you is that most software tools abstract away any sort of nv12 from the user so you can pretend most of the time that it's always yuv420p [19:09:32 CEST] <thebombzen> nvenc is the exception, which whines about that. [19:09:48 CEST] <JEEB> the difference between the two is only in how the data is kept, basically [19:10:03 CEST] <JEEB> nv12 = luma and a single plane for chroma, interleaved (aka "half-packed") [19:10:05 CEST] <thebombzen> Aerroon: yuv420p means planar. Y plane, followed by U, followed by V [19:10:20 CEST] <thebombzen> nv12 is partially interleaved [19:10:25 CEST] <thebombzen> as jeeb-said, half-packed. [19:10:38 CEST] <JEEB> yuv420p = each plane is separate [19:10:41 CEST] <JEEB> (planar) [19:10:54 CEST] <thebombzen> it's like how rgb24 is a sequence of 24-bit integers, each of which is red,green, then blue [19:10:57 CEST] <Aerroon> i don't understand [19:10:59 CEST] <JEEB> so conversion between the two is a simple pack/unpack [19:11:06 CEST] <Aerroon> what i don't understand is why you want me to switch it [19:11:29 CEST] <thebombzen> Aerroon: I'm not asking you to switch to it, I'm recommending you remove explicitly setting options that the tools will choose for you correctly [19:11:29 CEST] <JEEB> (although swscale is lulz so you've been warned) [19:11:43 CEST] <thebombzen> for this, swscale is fine [19:11:48 CEST] <Aerroon> thebombzen, but you seem to be missing the entire point of what i'm doing here [19:11:53 CEST] <JEEB> yea, as long as you hit the "fast path" [19:11:56 CEST] <Aerroon> i'm trying to compare the results i will get [19:12:11 CEST] <JEEB> Aerroon: then you will be getting a bit stream of some sort and you decode it, no? [19:12:12 CEST] <thebombzen> Aerroon: and I'm telling you that you shouldn't put those options here *or* in your final recording [19:12:12 CEST] <Aerroon> obs defaults to nv12 and i do not see a reason to switch away from it [19:12:25 CEST] <Aerroon> so why would i NOT use nv12 when i'm going to be testing for it [19:12:38 CEST] <JEEB> if the encoder cannot take it in (or at least the lavc wrapper cannot?) [19:12:47 CEST] <thebombzen> Aerroon: becuase nv12 and yuv420p are different ways of arranging mathematically identical data [19:12:47 CEST] <JEEB> it only takes the separate-planes thing in [19:12:50 CEST] <thebombzen> you don't need to make that choice. [19:13:00 CEST] <Aerroon> again please listen [19:13:03 CEST] <thebombzen> nv12 and yuv420p are mathematically the same data, just arranged differently [19:13:16 CEST] <Aerroon> i'm trying to compare the quality of the recordings of the encoders [19:13:24 CEST] <thebombzen> I know that [19:13:25 CEST] <Aerroon> to see which one would be a better fit for using with streaming [19:13:25 CEST] <JEEB> yes, so you just want to encode some sort of 4:2:0 [19:13:30 CEST] <Aerroon> the streaming will use nv12 [19:13:40 CEST] <Aerroon> so why would i want it to be something different during testing [19:13:42 CEST] <thebombzen> Aerroon: again, it doesn't *really* matter from a mathematical perspective which one you use, because it's the same data arranged differently [19:13:45 CEST] <thebombzen> it won't affect the quality at all [19:13:54 CEST] <JEEB> Aerroon: so YCbCr has three planes, right? [19:14:05 CEST] <Aerroon> so what difference does it make if i set or don't set it? [19:14:15 CEST] <thebombzen> Aerroon: I'm telling you not to set it because the tools will pick whichever one you want in this case correctly. [19:14:23 CEST] <JEEB> depends on the encoder and your input [19:14:25 CEST] <thebombzen> and also not setting it avoids swscale [19:14:45 CEST] <Aerroon> so let me get this straight [19:14:45 CEST] <thebombzen> Aerroon: libx264 wants yuv420p input, and nvenc wants nv12. It's the same data, but arranged differently. [19:15:03 CEST] <JEEB> but between NV12 and planar 4:2:0 (what yuv420p is) the difference is how it's arranged in memory [19:15:04 CEST] <Aerroon> during testing i should use different settings than for the actual streaming later on [19:15:09 CEST] <JEEB> uhh [19:15:14 CEST] <JEEB> if your thing can use libx264 [19:15:25 CEST] <JEEB> then effectively you are either pushing planar 4:2:0 or NV12 to it [19:15:28 CEST] <JEEB> which are the same data [19:15:35 CEST] <thebombzen> Aerroon: well you should listen to us [19:15:35 CEST] <JEEB> just arranged differently in memory [19:15:44 CEST] <thebombzen> and when we tell you that yuv420p and nv12 are mathematically the same data [19:15:47 CEST] <thebombzen> but arranged differently [19:15:53 CEST] <thebombzen> then you should understand this means there's no quality difference [19:15:54 CEST] <Aerroon> then why does it matter if they're the same [19:16:08 CEST] <JEEB> because the encoders are specific about what they take in [19:16:10 CEST] <JEEB> in libavcodec [19:16:15 CEST] <JEEB> and if you say "I want you to take in X" [19:16:24 CEST] <JEEB> and the encoder hasn't been set to take it in [19:16:28 CEST] <JEEB> it will say "nope" [19:16:32 CEST] <JEEB> or the wrapper [19:16:44 CEST] <JEEB> in this case lavc's libx264 wrapper could be patched to also take in nv12 [19:16:50 CEST] <JEEB> because libx264 actually supports it [19:16:58 CEST] <thebombzen> libx264's avcodec wrapper wants yuv420p. If you tell it that you're feeding it nv12, it will automatically insert a converstion from nv12 to yuv420p [19:17:08 CEST] <thebombzen> you don't want to do this [19:17:24 CEST] <BtbN> uhm, I'm pretty sure x264 takes in nv12 natively [19:17:27 CEST] <JEEB> yes [19:17:29 CEST] <BtbN> and it's even the prefered format [19:17:29 CEST] <JEEB> I've said that N times [19:17:33 CEST] <JEEB> and linked the commit [19:17:40 CEST] <thebombzen> Aerroon: they're mathematically identical data, so it's generally a good idea to not force an explicit conversion (which is just a rearrangement) unless the tools are necessary [19:17:49 CEST] <JEEB> and thus I said "the wrapper could be patched" [19:17:49 CEST] <thebombzen> BtbN: >[13:16:58] <thebombzen> libx264's avcodec wrapper [19:17:50 CEST] <JEEB> :P [19:18:16 CEST] <thebombzen> Given that the data is the same, you should not force it to be rearranged unless it's necessary [19:18:20 CEST] <BtbN> libx264.c supports NV12, and _a lot_ of other formats, just fine [19:18:21 CEST] <JEEB> Aerroon: basically you're hitting details which most higher-abstraction tools would hide from you :P [19:18:22 CEST] <Aerroon> so i fixed pix_fmt [19:18:26 CEST] <Aerroon> it outputs it just fine [19:18:49 CEST] <JEEB> Aerroon: in theory you shouldn't be setting either nv12 or yuv420p but saying something like "I want 4:2:0 YCbCr" [19:18:54 CEST] <JEEB> and the thing should internally do whatever [19:18:57 CEST] <Aerroon> Stream #0:0: Video: h264 (libx264) (H264 / 0x34363248), nv12, 1920x1080 [SAR 1:1 DAR 16:9], q=-1--1, 6000 kb/s, 24 fps, 1k tbn, 24 tbc [19:19:12 CEST] <thebombzen> Aerroon: we're telling you not to force options that you do not need to force [19:19:39 CEST] <thebombzen> BtbN: that being said, there's still merit in letting x264 do the I420 -> NV12 conversion, because it's probably faster than swscale [19:19:40 CEST] <Aerroon> but then the option is going to be different in the testing vs actual use [19:19:59 CEST] <thebombzen> WE ARE ALSO TELLING YOU NOT TO SET IT FOR THE ACTUAL USE [19:20:00 CEST] <JEEB> if you are going to want to use libx264 then it would be exactly that unless the thing you're using is a different piece of software [19:20:01 CEST] <thebombzen> please listen [19:20:02 CEST] <Aerroon> i get that it doesn't change anything here now [19:20:17 CEST] <Aerroon> thebombzen, it defaults to nv12 in obs [19:20:22 CEST] <Aerroon> there is no "do not touch this option" button [19:20:27 CEST] <Aerroon> you explicitly have to select one [19:20:29 CEST] <thebombzen> -_- [19:20:33 CEST] <JEEB> then it's a different piece of software [19:20:37 CEST] <JEEB> and it is hiding/setting things accordingly [19:20:38 CEST] <Aerroon> yeah, it is [19:20:45 CEST] <JEEB> it is hiding details from you [19:20:55 CEST] <JEEB> although to be honest already showing NV12 to you is "too much" :P [19:21:05 CEST] <JEEB> for you it is 4:2:0 YCbCr [19:21:10 CEST] <JEEB> that's all you really care about [19:21:13 CEST] <thebombzen> yea tbh OBS shouldn't actually differentiate between I420 and NV12 [19:21:15 CEST] <JEEB> since that's the data [19:21:30 CEST] <thebombzen> I420 and NV12 are the same pixel data but arranged differently [19:21:38 CEST] <thebombzen> OBS shouldn't allow you to choose between the two [19:21:45 CEST] <thebombzen> and it should pick the correct one depending on context [19:21:46 CEST] <Aerroon> since we're on that topic [19:21:50 CEST] <JEEB> (I420 is the windows fourcc name for what is called yuv420p in FFmpeg) [19:21:55 CEST] <Aerroon> would I444 look any better? [19:22:08 CEST] <JEEB> if your filter chain doesn't fuck up, yes [19:22:11 CEST] <JEEB> esp. reds etc [19:22:13 CEST] <thebombzen> Aerroon: probably not. don't stream in I444 [19:22:17 CEST] <JEEB> ahahaha [19:22:26 CEST] <JEEB> thebombzen: you're giving the right recommendation but for the wrong reason [19:22:34 CEST] <JEEB> 4:4:4 isn't hardware decode'able [19:22:43 CEST] <JEEB> thus most clients will not be able to play it [19:22:43 CEST] <BtbN> it's not browser decodable as well [19:22:48 CEST] <JEEB> effectively yes [19:22:55 CEST] <thebombzen> JEEB: I know that I444 does look better for CRF, but finite bitrate means I444 might actually look worse [19:23:08 CEST] <JEEB> he said colorspace vs colorspace [19:23:10 CEST] <BtbN> I think nvidia can decode it? But I'm not 100% and would need to check [19:23:18 CEST] <JEEB> BtbN: I think it was encode only? [19:23:25 CEST] <JEEB> at least DXVA2 doesn't have it [19:23:51 CEST] <thebombzen> JEEB: Yea, I444 is better than I420, but also remember that if you're encoding at a finite CBR, it might allocate too many bits for the extra data [19:23:52 CEST] <Aerroon> anyways thanks guys [19:24:06 CEST] <BtbN> hm, cuvid in theory supports it. But anything else than 420 is not implemented by the driver [19:24:08 CEST] <JEEB> thebombzen: yes but that is different from 4:2:0 vs 4:4:4 [19:24:23 CEST] <thebombzen> JEEB: I know, but I was answering Aerroon's question [19:24:27 CEST] <JEEB> I would then add separately that if you're constrained it might or might lead to worse compression [19:24:30 CEST] <JEEB> no [19:24:30 CEST] <JEEB> his question was [19:24:31 CEST] <thebombzen> or rather in the context of their question [19:24:37 CEST] <JEEB> "< Aerroon> would I444 look any better?" [19:24:47 CEST] <JEEB> (against 4:2:0) [19:24:51 CEST] <JEEB> thebombzen: yes you add details then [19:24:53 CEST] <JEEB> goddamnit [19:25:01 CEST] <Aerroon> also i have to say [19:25:05 CEST] <thebombzen> well yea but I assume the question was specifically about streaming in CBR in OBS [19:25:08 CEST] <Aerroon> i haven't seen this channel be this alive before [19:25:12 CEST] <thebombzen> I444 does look better but in this particular case probably not [19:25:18 CEST] <JEEB> it really depends [19:25:26 CEST] <JEEB> I've had lower bit rate streams look better in 4:4:4 [19:25:42 CEST] <thebombzen> but Aerroon: whether or not it looks better here is mostly irrelevant because I444 will break compatibility [19:25:51 CEST] <JEEB> yes, as I noted [19:25:53 CEST] <Aerroon> yup, already got that part [19:25:56 CEST] <thebombzen> most mobile devices won't be able to view it and many browsers as well [19:26:23 CEST] <thebombzen> JEEB: either way, the 4:4:4 vs 4:2:0 seems to be a bit of a hot topic here [19:26:34 CEST] <thebombzen> whehter it's worth the extra bitrate [19:26:43 CEST] <JEEB> it depends is the real answer [19:26:50 CEST] <thebombzen> probably on the source [19:26:55 CEST] <thebombzen> my guess is for film it's probably not [19:26:58 CEST] <JEEB> source, parameters etc [19:26:59 CEST] <thebombzen> but for anime maybe [19:27:13 CEST] <Aerroon> actually one more question [19:27:16 CEST] <JEEB> also screen capture is most likely gonna like 4:4:4 [19:27:31 CEST] <JEEB> although to be honest it also depends on how fucked up your filtering chain is [19:27:36 CEST] <Aerroon> if i limit bitrate to 6000k, i should also limit buffer size, right? but o what? [19:27:39 CEST] <Aerroon> or should i set a -maxrate? [19:27:40 CEST] <JEEB> going through 4:2:0 and back is welp [19:27:51 CEST] <JEEB> Aerroon: uhh since you're using OBS I don't think we can help you [19:27:57 CEST] <JEEB> since you need help wrt OBS options [19:27:58 CEST] <JEEB> not FFmpeg options [19:27:59 CEST] <Aerroon> well i meant for ffmpeg [19:28:02 CEST] <Aerroon> for the test part [19:28:12 CEST] <JEEB> maxrate+bufsize are always to be used together [19:28:24 CEST] <JEEB> since you calculate maxrate over bufsize [19:28:58 CEST] <JEEB> (that's how VBV/HRD works) [19:29:27 CEST] <Aerroon> bufsize + maxrate will be the highest the bitrate will go to, right? [19:31:24 CEST] <JEEB> no [19:31:27 CEST] <JEEB> maxrate is the highest [19:31:47 CEST] <JEEB> thus if maxrate is the minimum average bandwidth a client has to be able to keep [19:31:52 CEST] <Aerroon> okay, i'm sorry i was an idiot [19:32:08 CEST] <JEEB> and bufsize is on how much buffer both encoder and client work with [19:32:27 CEST] <JEEB> the bigger the bufsize the more leeway the encoder has, of course [20:04:04 CEST] <pgorley> hi, is there a way to get ffmpeg logs in android studio? "adb shell setprop log.redirect-stdio true" doesn't work [20:05:54 CEST] <BtbN> I doubt anyone in here has any clue about android IDEs [20:08:38 CEST] <JEEB> pgorley: you will have to tell libavutil to log into your logging thing [20:08:49 CEST] <JEEB> if you're not using the APIs then you're fucked [20:09:20 CEST] <pgorley> so av_log_set_callback? [20:09:26 CEST] <JEEB> yes [20:09:33 CEST] <JEEB> then map that to the android logging framework [20:10:48 CEST] <pgorley> ok, thanks [20:30:02 CEST] <Dark-knight> will anything negative happen to my file if I use "-i input.mkv -c copy output.mp4"? [20:30:54 CEST] <Dark-knight> the audio is 2 ch stereo AAC [20:55:54 CEST] <Dark-knight> simply what I'm asking is, will it actually work to change a .mkv to a .mp4 [20:56:06 CEST] <Dark-knight> I'm trying to get it to play on my xbox [20:56:24 CEST] <Dark-knight> and it won't work if the file isn't actually an mp4 [20:57:32 CEST] <kepstin> assuming the audio+video codecs in your file are compatible with mp4 container and are supported on your xbox, I'd expect that to be fine [20:58:03 CEST] <kepstin> also, running that command to test it would have probably gone faster than waiting for someone to respond :/ [21:08:01 CEST] <strepto> Top of the morning! This must be the most crowded IRC channel I've seen since the wall fell. [21:09:31 CEST] <dahlquist> Hello all [21:09:47 CEST] <thebombzen> sounds like you haven't been on Rizon then [21:10:00 CEST] <DHE> or just #gentoo [21:10:17 CEST] <thebombzen> I haven't been there but I absolutely believe that [21:10:26 CEST] <DHE> currently 1098 users [21:10:34 CEST] <thebombzen> I wonder about #archlinux or whatever it's called [21:10:36 CEST] <dahlquist> new to ffmpeg.. struggling to merge 3 video of short length. (works on longer lengths) Using -f concat -safe 0 -i "${TMP_MERGER_FILE_INPUT1}" -c copy "${TMP_MERGED_VIDEO_FILE}" [21:11:45 CEST] <thebombzen> DHE: #archlinux has 1788 [21:11:52 CEST] <dahlquist> problem is the playback stops at the start of the 3rd video after merge when the lengths of the elements are 2/6/1 seconds in length respectively... [21:12:27 CEST] <dahlquist> no problem when the length of the 3rd piece is more then 5 seconds [21:12:33 CEST] <thebombzen> we can't help you if we don't actually know anything about the videos or their lengths or what you tried [21:12:34 CEST] <strepto> I am looking into setting up an audio stream, streaming only lossless files, most of it being .aiff and .wav, with a bitrate from 1411 to 2304 kbps. Would "ffserver" be able to provide that kind of streaming capability? The other tools I've looked at, like icecast2, offers only lossy streams.. [21:12:55 CEST] <thebombzen> dahlquist: you haven't really told us anything that allows us to help you [21:13:24 CEST] <thebombzen> strepto: ffserver is deprecated [21:13:45 CEST] <thebombzen> you could possibly set up an nginx instance as a multicast stream. but you also shouldn't stream uncompressed audio [21:14:01 CEST] <thebombzen> if you're going to do that, you should encode it to FLAC on the fly [21:14:24 CEST] <strepto> thebombzen: I didn't know lossless compression could be added to a stream of the fly. [21:15:03 CEST] <thebombzen> strepto: it definitely can. The issue with compressing stuff on the fly is it takes CPU. but audio is not cpu-intensive enough for that to be an issue. [21:15:16 CEST] <thebombzen> you can encode flac at like 100x realtime speed with even mediocre hardware. [21:16:17 CEST] <thebombzen> strepto: what you probably want to do for streaming is compress the audio in advance. You honestly could even stream in high-bitrate Opus. It's lossy but for streaming on the fly if you set the bitrate to 320 kbps or something absurd it should easily be transparent enough. [21:16:19 CEST] <strepto> In any case, I'd need to find a way to stream it first. Ironically, VLC supports this out of the box, but .. doesn't really scale from a service perspective. [21:17:06 CEST] <thebombzen> One advantage of Opus is that it's specifically designed for that purpose and it works incredibly well with chunking and starting and stopping [21:17:13 CEST] <strepto> I have no problems setting up a lossy stream using icecast2 or similar. Still, the very point of my project is to offer lossless audio. In my case, bw and cpu/hw resources isn't a problem. [21:17:28 CEST] <JodaZ> icecast claims to support flac [21:17:29 CEST] <strepto> I will look into Opus. [21:17:34 CEST] <thebombzen> Opus *is* lossy fyi [21:18:13 CEST] <thebombzen> it's higher quality than every other lossy codec in existence (including aac, vorbis, mp3, etc) and it maintains nice qualities for streams like low-delay and that stuff [21:18:45 CEST] <thebombzen> Icecast says it supports FLAC, so if you got a lossy icecast stream to work before, you might want to consider encoding your wav to flac in advance and then just trying that. [21:18:56 CEST] <thebombzen> "ffmpeg -i input.wav output.flac" should do it [21:19:10 CEST] <thebombzen> and then use the FLAC files the same way you used the lossy files [21:19:27 CEST] <strepto> That could work. [21:19:28 CEST] <JodaZ> thebombzen, barbaric, just pipe it in directly [21:20:54 CEST] <strepto> Hm, there's nothing in the official icecast documentation to suggest flac support. But I'll keep on digging. [21:21:08 CEST] <furq> http://icecast.org/faq/ [21:21:17 CEST] <furq> Icecast is a streaming server, which can stream audio (and video) to listeners/viewers. It supports Ogg (Vorbis, Theora), Opus, FLAC and WebM (VP8/VP9), [21:21:46 CEST] <furq> flac support is landing in browsers as well now [21:21:50 CEST] <thebombzen> JodaZ: yea, but I have no idea what setup they used to get icecast to work. if it was VLC then that won't work [21:21:51 CEST] <furq> i know firefox supports it [21:22:01 CEST] <furq> also you can use ffmpeg as an icecast source client [21:22:54 CEST] <DHE> thebombzen: you win then [21:23:05 CEST] <thebombzen> lol [21:23:23 CEST] <thebombzen> I have all of the wins [21:24:03 CEST] <strepto> Thank you furq :) [21:24:43 CEST] <thebombzen> your_solution = (Ice) stream; [21:35:30 CEST] <RandomCouch> So I need help with a problem that is probably too complicated, I'm working on mobile app for android, I have ffmpeg compiled and running on android, the app records a video from the mobile's camera, and then concats that video with another video on the device [21:35:50 CEST] <RandomCouch> the problem is the output video, and this problem does not exist on all android devices, recent ones play it just fine [21:36:06 CEST] <RandomCouch> but some devices like the Samsung S4 freeze at the end of the video playback [21:36:14 CEST] <RandomCouch> the video player freezes and becomes unresponsive [21:36:32 CEST] <RandomCouch> The way I concat these 2 videos is, I first create intermediates [21:36:44 CEST] <RandomCouch> the command for transforming the recorded video into itnermediate vid is this [21:36:51 CEST] <RandomCouch> -acodec copy -vcodec copy -bsf:v h264_mp4toannexb -b:v 1M -preset fast -r 30 [21:37:06 CEST] <BtbN> that's not a transcode. And just use -c copy. The bsf should not be needed anymore. [21:37:22 CEST] <RandomCouch> I've tried that too [21:37:33 CEST] <RandomCouch> it still made the video player unresponsive at the end, what did fix it though [21:37:38 CEST] <RandomCouch> is when I used -vcodec libx264 [21:37:51 CEST] <BtbN> that's an actual transcode [21:37:54 CEST] <BtbN> but still, -c:v [21:37:56 CEST] <RandomCouch> the problem with that is that it took way too long to transcode it [21:38:04 CEST] <RandomCouch> it's a 15 second long video [21:38:16 CEST] <RandomCouch> and it took about 200 seconds to transcode it [21:38:27 CEST] <BtbN> that's about expected on a phone [21:38:41 CEST] <RandomCouch> well, when I skip the transcoding, it's much faster but bugs out on some devices [21:38:48 CEST] <RandomCouch> do you know why that happens? [21:38:56 CEST] <BtbN> Because phones have bad players [21:39:06 CEST] <RandomCouch> the second video that gets mixed with it is transcoded with libx264 [21:39:23 CEST] <RandomCouch> like it's already transcoded when I put it on the device [21:39:30 CEST] <RandomCouch> so I don't need to do it again when concatenating [21:39:49 CEST] <RandomCouch> so if I can figure out a way to transcode it the right way, a way where I won't have to transcode the first video which is recorded by the phone [21:39:55 CEST] <RandomCouch> then I can just concat them [21:39:59 CEST] <RandomCouch> and it would be quick [21:40:16 CEST] <BtbN> the phone probably uses a hardware encoder for it [21:40:34 CEST] <BtbN> You can't really produce an input video that is compatible with everything any hw decoder could ever throw out [21:40:37 CEST] <RandomCouch> the video that is recorded by the phone has a variable frame rate [21:40:44 CEST] <RandomCouch> uses h264 and aac encoders [21:41:16 CEST] <RandomCouch> I mean codecs [21:53:47 CEST] <Shootfast> Hi, I'm trying to convert from yuv420p to yuv444p, adjusting only the srcRange and dstRange via sws_setColorspaceDetails, but the set call fails due to a check in libswscale/utils.c:884 that hopes to find differences in the yuv coefficient tables (which I am not changing). Could anyone confirm that changing only the YUV subsampling and range is an acceptable operation for swscale? [21:59:47 CEST] <BtbN> it should work fine. But is 100% pointless [22:05:03 CEST] <Shootfast> @BtbN What makes it pointless? [22:05:18 CEST] <BtbN> It makes it bigger, for no gain in quality. [22:05:30 CEST] <BtbN> The information is already lost, it's not going to come back. [22:22:35 CEST] <Shootfast> Yes, the data is lost, but I'm manipulating the data elsewhere with other full range sources and wanted everything in one range. [22:25:20 CEST] <Dark-knight> whats the difference between 10bit and 8bit? I'm trying to chose which file I want to convert. [22:27:33 CEST] <Cracki_> Dark-knight, more context please [22:27:45 CEST] <Cracki_> in any case: the difference is 2bit [22:29:30 CEST] <Dark-knight> well one says, 10bit 1080p and the other says 8bit 1080p [22:30:14 CEST] <klaxa> is it anime? [22:30:14 CEST] <Dark-knight> idk what 10bit means [22:30:21 CEST] <Dark-knight> maybe [22:30:27 CEST] <alexp> 8-bit equals 256 stops per color channel [22:30:35 CEST] <alexp> 10-bit is 1024 stops I believe [22:30:40 CEST] <Dark-knight> ah [22:30:48 CEST] <Dark-knight> so 10bit is always better [22:30:50 CEST] <alexp> so you have the benefit of getting more accurate colors and more smooth gradation [22:31:06 CEST] <alexp> not to compatibility. 8-bit is always a safer bet if you want compatibility [22:31:27 CEST] <alexp> but 10-bit is a fairly big improvement for very little (if any) difference in file size for H.264 [22:31:50 CEST] <Dark-knight> cool [22:32:10 CEST] <alexp> i don't think Windows Media Player will play 10-bit H.264 videos on my Win7 machine, fwiw [22:32:11 CEST] <Dark-knight> so you're saying 8bit so more likely to work on media players and consoles? [22:32:16 CEST] <alexp> yeah, certainly [22:32:29 CEST] <alexp> 10-bit support is going to be somewhat rare [22:32:34 CEST] <Dark-knight> but its wouldn't hurt to try 10bit right? [22:32:40 CEST] <Dark-knight> it* [22:32:57 CEST] <alexp> are you trying to distribute it, or is there only one hardware or software player that you're going to use and can test for compatibility? [22:33:06 CEST] <alexp> that should determine your answer [22:33:09 CEST] <Dark-knight> why is it rare, if you mind me asking? [22:33:31 CEST] <alexp> all distribution formats up until UHD Blu-ray have been 8-bit [22:33:41 CEST] <alexp> including all digital TV, all DVD, all Blu-ray [22:33:48 CEST] <alexp> all internet video [22:33:49 CEST] <alexp> etc [22:33:57 CEST] <alexp> so the hardware has never needed to support it [22:34:00 CEST] <alexp> nor has the software [22:34:26 CEST] <alexp> it's historically just been used for high end filming, high end video editing, etc [22:34:37 CEST] <Dark-knight> so blueray players and computers are the only things that can play 10bit so far? [22:34:39 CEST] <Cracki_> (ffmpeg and vlc of course can work with it) [22:34:41 CEST] <alexp> but now it happens to be part of the "HDR" spec [22:35:17 CEST] <Dark-knight> well that helps me chose which file I use. [22:35:22 CEST] <alexp> Dark-knight - not regularly Blu-ray. UHD (4K) Blu-ray players [22:35:28 CEST] <Dark-knight> oh [22:35:45 CEST] <Dark-knight> well then, I'll choose this file https://pastebin.com/QYM65mUt [22:35:59 CEST] <Dark-knight> can it be converted into .mp4 with no problem? [22:36:16 CEST] <alexp> yes, you don't need to re-encode [22:36:24 CEST] <alexp> just stream copy [22:36:35 CEST] <alexp> both the video and audio streams in that file are MPEG-4 container compliant [22:37:00 CEST] <alexp> ffmpeg -i [inputfile.mkv] -c copy [outputfile.mp4] [23:24:55 CEST] <feistyFrank> Anyone familiar with compiling ffmpeg for android? [23:27:24 CEST] <JEEB> lol [00:00:00 CEST] --- Thu Aug 3 2017

1 0

ffmpeg-devel.log.20170801
by burek 02 Aug '17

02 Aug '17

[02:38:05 CEST] <ZeroWalker> can you obtain the input/output information from SwrContext? [02:38:13 CEST] <ZeroWalker> like samplerate, format etc [04:06:18 CEST] <atomnuker> rcombs: got the time to fix yer flac coverart embedding? [04:06:27 CEST] <rcombs> was there still something wrong with it [04:06:36 CEST] <rcombs> apart from "is not merged" [04:07:28 CEST] <atomnuker> I think jamrial had some issues which is why you didn't merge them [04:09:23 CEST] <ZeroWalker> is there any function that does the linesize etc when using sws to convert? Feels kinda weird as i set it up when i initialize it, but when then using sws_scale i have to give it some information again [04:37:07 CEST] <jamrial> atomnuker: i asked for some changes i think but it was a while ago [05:18:42 CEST] <ZeroWalker> guess not;( [05:38:03 CEST] <cone-913> ffmpeg 03James Almer 07master:8f2f166c99df: avcodec/atrac3p: use float_dsp in ff_atrac3p_power_compensation [06:12:38 CEST] <rcombs> jamrial: I think this covers all your concerns? https://github.com/rcombs/FFmpeg/tree/cue [06:16:40 CEST] <ZeroWalker> am i failing to understand how swscale works. Aren't you supposed to feed it the Source raw buffer and linesizes, and a Destination raw buffer and line size. So the Source just needs to be the raw data from whatever source you get it. And the Destination can be an allocated with av_image_alloc [06:19:38 CEST] <jamrial> rcombs: you're still not flushing the buffered packets on oom. look at mp3enc.c [06:24:45 CEST] <rcombs> I do feel a little bit uneasy about that OOM behavior [06:25:04 CEST] <rcombs> because it allows the operation to succeed, with only a log line indicating that something went wrong [06:25:22 CEST] <rcombs> which the user won't see in all use-cases [06:25:31 CEST] <jamrial> then you should make it abort, not write the current audio packet [06:26:13 CEST] <rcombs> that's what I did at first :| [06:27:10 CEST] <rcombs> still, whatever behavior we land on, it should be consistent [06:27:34 CEST] <rcombs> so, in general, should ffmpeg recover lossilly from OOM, or fail hard? [06:27:42 CEST] <jamrial> it either flushes the buffer then continues from the current packet, so the output audio is correct, or it aborts the whole thing [06:28:05 CEST] <rcombs> is it possible to set AV_EF_EXPLODE on a muxer? [06:28:33 CEST] <jamrial> imo, what the mp3 muxer does is best. not abort and write the file without the image that didn't show up on time [06:28:34 CEST] <jamrial> yes [06:29:06 CEST] <rcombs> maybe make it conditional on that, then [06:29:46 CEST] <jamrial> you definitely can't make it write the current audio packet without first flushing the buffer. that's a lot of data lost [06:30:08 CEST] <rcombs> yeah that's clearly wrong [06:30:44 CEST] <atomnuker> where do you need to allocate and couldn't you use refcounting to avoid it? [06:33:09 CEST] <atomnuker> I'd also prefer to have the micro bumped once either as a separate commit or with the last commit [06:34:08 CEST] <rcombs> gotta keep a queue [06:35:19 CEST] <rcombs> AVPacketList [06:35:28 CEST] <rcombs> which is pretty small per packet, of course [06:35:58 CEST] <rcombs> oh, I'm currently using av_copy_packet, which I shouldn't be [06:40:03 CEST] <jamrial> the packet functions are a mess. there are three different functions that do the same thing in some cases [06:40:52 CEST] <jamrial> some are supposedly deprecated but not wrapped in deprecation guards, or wrapped in guards but not tagged as such [06:43:44 CEST] <rcombs> there you go [06:47:18 CEST] <jamrial> rcombs: next is sharing the flac image code so the ogg muxer can use it :p [06:48:28 CEST] <rcombs> do you care enough about that to block merge [06:48:49 CEST] <atomnuker> does ogg really let you mux coverart in? [06:51:46 CEST] <jamrial> rcombs: of course not [06:52:06 CEST] <rcombs> alright, any objections to the full patchset now? [06:52:27 CEST] <jamrial> atomnuker: yeah, it's crazy. it's flac picture format, encoded in base64 and put inside a vorbiscomment tag [06:52:46 CEST] <rcombs> &wat [06:52:59 CEST] <rcombs> "you know what would make this better? base64" [06:53:46 CEST] <rcombs> --nobody, ever [06:54:04 CEST] <jamrial> --someone, at xiph [06:55:49 CEST] <jamrial> rcombs: did you get any reviews for the cue and segment patches? if not, send the whole patchset to the ml first [07:00:02 CEST] <rcombs> 2 of the segment patches got LGTM/looks fine'd; 1 never really got anything [07:00:21 CEST] <rcombs> cue got one comment about opening arbitrary URLs, which is why it now restricts itself to side-by-side files [07:01:52 CEST] <atomnuker> just push it, break your f5 key on recent fate tests and check email for coverity complaints [07:47:00 CEST] <ZeroWalker> is there something special with RGB24 when convering to YV12, cause i get read/write access error, so i assume it reads/writes too much data or something [07:48:03 CEST] <atomnuker> alignment and padding [07:48:47 CEST] <atomnuker> (actually IIRC you can give libswscale unaligned input and it'll take a slow path) [07:49:40 CEST] <ZeroWalker> even aligning to 1 doesn't help [07:50:42 CEST] <ZeroWalker> i am converting from RGB24 to YV12, i have an AVFrame that's setup for YV12, and RGB24 is raw data so i use av_image_alloc and av_image_fill_arrays to set it up before passing it to sws_scale [07:55:12 CEST] <ZeroWalker> hmm might be something else, need to check some stuff out, cause i could get for example YUY2 720x480 work from one source, but it would fail on another, which makes no sense unless the data is different somehow [07:57:55 CEST] <ZeroWalker> or not, okay this is weird i know i produced a correct output [08:06:41 CEST] <ZeroWalker> hmm okay well the only thing that works is if the source is RGB32, so it must be something with the padding i guess, YUY2 (YVYU or whatever) doesn't work and neither does RGB24. so i must have something set up wrong [08:41:17 CEST] <atomnuker> remember rgb is not planar [08:53:35 CEST] <rcombs> &do we have a policy against defining variables at the top of a block scope? [08:53:58 CEST] <nevcairiel> no [08:54:11 CEST] <rcombs> didn't think so [08:54:19 CEST] <nevcairiel> just not in the middle of code, otherwise the compiler whines [08:54:39 CEST] <rcombs> (re: https://ffmpeg.org/pipermail/ffmpeg-devel/2017-August/214361.html ) [08:55:08 CEST] <rcombs> nevcairiel: why do we still have that warning anyway [08:55:37 CEST] <rcombs> didn't we stop supporting 20th-century compilers at some point [08:55:39 CEST] <nevcairiel> because we probably still have compilers that don't like it, also its generally not too bad of a idea to stick to i t [08:55:43 CEST] <atomnuker> tidyness [08:56:03 CEST] <nevcairiel> the only case is loop variables that I don't think gcc even complains about [08:56:15 CEST] <nevcairiel> ie. for (int i = 0; ...) [08:56:23 CEST] <rcombs> it's often tidier, but I wouldn't say always [08:56:25 CEST] <nevcairiel> technically i guess its inside some sort of block [08:58:47 CEST] <thebombzen> IIRC, ANSI C requires variables to be declared at the beginning of their block scope, but ISO C99 doesn't require that anymore [08:59:12 CEST] <thebombzen> so the for (int i = 0; ...) that stuff is allowed in C99 [09:00:21 CEST] <thebombzen> ah, Wikipedia's C99 article lists this: intermingled declarations and code: variable declaration is no longer restricted to file scope or the start of a compound statement (block), facilitating static single assignment form [09:44:00 CEST] <rcombs> &huh [09:44:11 CEST] <rcombs> raise your hand if you've ever heard of a short _first_ frame in FLAC [10:11:37 CEST] <nevcairiel> that sounds dumb for a lossless codec, its not like it needs decoder priming or anything that might need any magic at the beginning of the stream [12:24:49 CEST] <ldts> I am hitting a regression when running the fate tests and I'd appreciate some help with it (source-check.sh is complaining about av_clip in a file that doesnt have the call). the trace: https://hastebin.com/umilirokum.cs [12:25:10 CEST] <ldts> any suggestions will be very welcome [12:25:55 CEST] <nevcairiel> you're reading that wrong, those are the headlines for the next section, you would need to find the headline for the previous section [12:26:32 CEST] <ldts> ah ok, it is just that I added those new compat files and I thought I had tripped over something. cool. I'll check. thanks! [12:27:38 CEST] <ldts> also tests/data/fate/source.err is empty ...not sure if it is relevant? [12:28:07 CEST] <nevcairiel> i would still question including kernel headers however, it should just disable itself if headers are not available - its not like its actually going to run if the kernel is too old [12:30:18 CEST] <ldts> right, but as the api evolves we cant just check that every single macro is present ...since the kernel will not break userspace -and to avoid build issues- this seems to be the standard solution (the folks at gstreamer have opted for the same btw) [12:31:27 CEST] <nevcairiel> if they are constantly going to break the headers in incompatible manner, maybe wait until they are done =p [12:32:14 CEST] <ldts> I dont think it will ever be done :) [12:32:30 CEST] <ldts> the point is to make sure that the code that we have does compile on all kernels... [12:33:05 CEST] <ldts> the v4l2 encoder/decoder might not work at runtime (ie if there is an API that it is needed and it is not present in the running kernel) [12:33:15 CEST] <J_Darnley> ldts: I think the include guard is wrong [12:33:25 CEST] <ldts> yes I noticed that! [12:33:27 CEST] <ldts> thanks :) [12:33:39 CEST] <ldts> I had to rename the file and forgot the include guard... [12:33:55 CEST] <nevcairiel> my point is that there is no point to compile it if its not going to run anyway, and maintaining a bunch of imported headers should always have a stronger argument then "some systems are too old to build it" [12:33:56 CEST] <J_Darnley> :) that test is one of the more annoying ones. [12:35:33 CEST] <ldts> nevcairiel: I agree with you but how do you propose that happens? an alternative was to test the presence of all the V4L2 calls but that was a massive pain for little gain.. [12:36:09 CEST] <ldts> J_Darnley: the source test? [12:36:13 CEST] <J_Darnley> yeah [12:36:17 CEST] <nevcairiel> well do they really break the headers in incompatible manners all the time? Or do you just need a sufficient recent state and they are not going to remove existing things again? [12:36:24 CEST] <ldts> I am still trying to figure out where to get the section that is failing... [12:36:45 CEST] <nevcairiel> because if its the second, you can just check for whatever latest symbol you require and assume everything else is present [12:37:25 CEST] <nevcairiel> (and the first would be a terrible way to define APIs, especially if they dont have versioning) [12:43:24 CEST] <ldts> nevcairiel: but backwards compatibility is not broken, it is only that new features are added. And if you try to use the newer features in your code and build it on an old machine it will just not build....it is hard for me to disagree with you because it is about choosing the lesser of two not great options. the way I am posting in v2 only requires updates very few years and if the new calls are required. Didnt NVIDIA do the same adding to compat/nvdec? [12:45:46 CEST] <ldts> ...was about to post v2 when hit this evil test :) maybe we can have the discussion on the ML just so we can track it? [12:46:47 CEST] <ldts> as soon as I pass the fate tests will post (tested encoders and decoders - and concurrent hw decoding/encoding) [12:57:20 CEST] <Shiz> w 25 [13:04:15 CEST] <ldts> nevcairiel: um, not sure where to look...https://hastebin.com/sirutecusu.diff [13:34:33 CEST] <ubitux> any objection to the subrip patchset? [13:49:53 CEST] <BBB> no [13:50:02 CEST] <BBB> ubitux: did you have an opinion on libvmaf/pkgconfig? [13:55:33 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:46e407554968: avcodec/dirac_vlc: Fix invalid shift [13:55:34 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:880f5c59139e: avcodec/diracdec: Check weight_log2denom [13:55:35 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07master:b2d9d7226943: avcodec/diracdsp: fix integer overflow [14:02:11 CEST] <nevcairiel> ldts: just requiring a recent version of a system-provided header is what we do for all sorts of hardware stuff (eg. vaapi), the nvidia stuff is a tad bit special because the headers are not packaged on linux distros and obtaining them from the official source requires registration, so the barrier is just so much higher [14:07:06 CEST] <jkqxz> The Nvidia stuff also habitually updates to and requires the newest version, because the lack of distribution support allows that. [14:07:09 CEST] <jkqxz> That isn't true of anything else, which has to work on old versions in old distributions. [14:08:25 CEST] <jkqxz> I think if it works in sensible older-but-still-supported distributions (e.g. Debian 8, Ubuntu 14.04, CentOS 6) then it's fine; if it doesn't then that's maybe a bit dubious. [14:14:47 CEST] <ldts> nevcairiel: jkqxz : just fixed the fate tests I broke (it was just a trivial addition missing in tests/ref/fate/source). will post v2 to the ML and we can continue there if that is ok (the solution of adding v4l2 headers to compat is inline with what other projects with similar requirements is doing...if the ffmpeg project doesnt think it is reasonable, we can certainly have other solutions in line to what you are saying (just like Groucho would say: these [14:14:47 CEST] <ldts> are my principles, if you dont like them ..I have others ) [14:18:49 CEST] <ldts> (sorry, I just want to get as much input on that compat discussion as possible, that is all) [14:20:55 CEST] <BtbN> jkqxz, every time the nvidia headers are updated, they require a driver with support for the header version [14:46:28 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:62b536690d27: avcodec/tiff: Update pointer only when the result is used [14:46:29 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:10a085a21f2d: avcodec/takdec: Fix integer overflow [14:46:30 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:b3cf49b6f9a2: avcodec/wavpack: Fix integer overflow [14:46:31 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:f626a479f412: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1 [14:46:32 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:62e942ab1c04: avcodec/wavpack: Fix integer overflow in wv_unpack_stereo() [14:46:33 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:750fec58e175: avcodec/apedec: Fix integer overflow [14:46:34 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:634e9a696d85: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int() [14:46:35 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:73f42b7b58ca: avcodec/vb: Check vertical GMC component before multiply [14:46:36 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:d2452b9e20ec: avcodec/cfhd: Fix invalid left shift of negative value [14:46:37 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:0837678cbd33: avcodec/hevc_ps: Fix integer overflow with beta/tc offsets [14:46:38 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:965f15551fb0: avcodec/h264_slice: Fix signed integer overflow [14:46:39 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:be1f146a0f1c: avcodec/wavpack: Fix invalid shift [14:46:40 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:215d6f897d3e: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise() [14:46:41 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:51f0580c5f43: avcodec/ylc: Fix vlc of 31 bits [14:46:42 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:910878e4d90a: avcodec/aacps (fixed point): Fix multiple signed integer overflows [14:46:43 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:506bbbc09929: avcodec/mjpegdec: Clip DC also on the negative side. [14:46:44 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:94077cf6735a: avcodec/magicyuv: Check that vlc len is not too large [14:46:45 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:a2c3c9bc6038: avcodec/aacdec_template: Fix undefined integer overflow in apply_tns() [14:46:46 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:02bec657f371: avcodec/aacdec_template (fixed point): Check gain in decode_cce() to avoid undefined shifts later [14:46:47 CEST] <cone-353> ffmpeg 03Vodyannikov Aleksandr 07release/3.1:c6d9d0022093: avcodec/cfhd: Fix decoding regression due to height check [14:46:48 CEST] <cone-353> ffmpeg 03Brice Waegeneire 07release/3.1:2453c66b0ff8: doc/filters: typo in frei0r [14:46:49 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:918d45ec82ea: avcodec/aacdec_fixed: fix: left shift of negative value -1 [14:46:50 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:2755c73d55b2: avcodec/aacps: Fix multiple integer overflow in map_val_34_to_20() [14:46:51 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:a0edd7f583b8: avcodec/ylc: Fix shift overflow [14:46:52 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:65304d33a20f: avformat/oggparsecelt: Do not re-allocate os->private [14:46:53 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:7f3124e08c30: avcodec/hevc_ps: fix integer overflow in log2_parallel_merge_level_minus2 [14:46:54 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:956f2db21ffc: avcodec/dnxhddec: Move mb height check out of non hr branch [14:46:55 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:f4c844923831: avcodec/diracdec: Fix integer overflow in signed multiplication in UNPACK_ARITH() [14:46:56 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:54a6c1368cdb: avformat/rtmppkt: Convert ff_amf_tag_size() to bytestream2 [14:46:57 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:06ce68d8a07d: avformat/rtmppkt: Convert ff_amf_get_field_value() to bytestream2 [14:46:58 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6274709c1c11: avcodec/takdec: Fix integer overflow in decode_subframe() [14:46:59 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6b1c71040d17: avcodec/diracdec: Fix integer overflow in divide3() [14:47:00 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:acedc53186c4: avcodec/dirac_dwt: Fix multiple integer overflows in COMPOSE_DD97iH0() [14:47:01 CEST] <cone-353> ffmpeg 03Michael Niedermayer 07release/3.1:6d849e2706d0: avcodec/diracdec: Check weight_log2denom [14:57:23 CEST] <BtbN> Hm, I wonder if the HLS muxer properly handles a discontinuity if it's writing fmp4 with an initial segment [15:36:39 CEST] <paras2052> durandal_1707: hi, there is no global header. [15:36:55 CEST] <paras2052> Each packet has its own header [15:37:24 CEST] <paras2052> There are slight differences between header of first packet and other packets [15:38:20 CEST] <durandal_1707> what difference? [15:39:03 CEST] <paras2052> The first keyword is SIMPLE = T for first packet. For rest it is XTENSION = 'IMAGE' [15:39:26 CEST] <paras2052> PCOUNT, GCOUNT keywords are not mandatory for first packet but they are for rest [15:39:58 CEST] <durandal_1707> does first packet have extension? [15:40:07 CEST] <paras2052> no [15:40:43 CEST] <durandal_1707> than just do one muxer [15:41:45 CEST] <paras2052> yes, but the muxer will just append the packets one after another. So, it will be exactly same as RAW muxer. Should i just use that or create separate ? [15:41:56 CEST] <ubitux> BBB: https://patchwork.ffmpeg.org/patch/4413/ this? [15:42:30 CEST] <ubitux> "link" is the wrong word here [15:42:45 CEST] <BBB> that doenst load for me because certificate is revoked :( [15:43:05 CEST] <BBB> configure: require pkg-config for libvmaf [15:43:06 CEST] <BBB> that one [15:43:32 CEST] <ubitux> "This patch makes libvmaf filter link to pkg-config of libvmaf." this sentence is incorrect [15:43:46 CEST] <ubitux> content of the patch should be fine; though, you may want to add a version check [15:43:59 CEST] <ubitux> "libvmaf >= 0.1.2" or whatever version [15:47:10 CEST] <ubitux> seems it was added in git/master only [15:47:19 CEST] <ubitux> so not available in any release so far [15:47:31 CEST] <BBB> right [15:47:38 CEST] <ubitux> like, it was merged 10 days ago [15:48:25 CEST] <ubitux> you may want to at least wait a release [15:48:54 CEST] <BBB> okay [15:49:24 CEST] <ubitux> alternative is to make a fallback on a require that will stay there forever [15:55:14 CEST] <BBB> the library itself isnt in a release either [15:55:19 CEST] <BBB> ashish added the library [15:55:21 CEST] <BBB> and the pkg-config file [15:55:35 CEST] <BBB> the pkg-config came after the library (a few weeks later) based on comments here [15:55:45 CEST] <BBB> so the window for lib-but-no-pkgconfig is small [15:55:47 CEST] <BBB> I think its ok [15:57:20 CEST] <durandal_1707> paras2052: whatever you prefer [15:58:02 CEST] <paras2052> okay [16:02:25 CEST] <ubitux> BBB: https://github.com/Netflix/vmaf/releases [16:02:31 CEST] <ubitux> i see releases here [16:07:33 CEST] <BBB> ubitux: but not with the library in it [16:07:48 CEST] <ubitux> oh, ok [16:08:00 CEST] <ubitux> well then, no opinion [16:08:06 CEST] <ubitux> feel free to update desc then [16:09:17 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:f0f8da545d80: lavc/htmlsubtitles: improve handling broken garbage [16:09:18 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:55949e3e5189: lavc/tests: add htmlsubtitles [16:09:19 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:e80037186327: lavc/htmlsubtitles: improve line breaks handling [16:09:20 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:479ab8c3f842: lavc/htmlsubtitles: handle colors starting with many '#' [16:09:21 CEST] <cone-353> ffmpeg 03Clément BSsch 07master:1193301758b8: lavc/htmlsubtitles: reindent after previous commits [16:27:04 CEST] <ubitux> i'll be away for while starting tomorrow, don't expect any answer from me [16:34:01 CEST] <BBB> sure, np [16:40:06 CEST] <durandal_1707> ubitux: what you mean? [16:41:53 CEST] <atomnuker> he's from France [16:42:11 CEST] <atomnuker> have you been to France during August? [16:43:39 CEST] <iive> You mean that they are using their one month paid vacation to be on the beach? [16:44:57 CEST] <atomnuker> dunno what they do, not sure where they all go [16:46:37 CEST] <atomnuker> is the riviera big enough? [16:50:11 CEST] <ubitux> i'll just move away from the country as i'm unable to leave the planet [16:50:15 CEST] <ubitux> will be good enough for a start [16:53:44 CEST] <atomnuker> do the french have french rivieras elsewhere? [16:54:09 CEST] <atomnuker> but wait, would a french riviera still be a french riviera if its not french? [16:54:45 CEST] <atomnuker> I guess the italians have one, but its an italian riviera, not sure if its the same thing [17:02:19 CEST] <BBB> I thought ubitux was belgian? [17:04:34 CEST] <J_Darnley> The Belgians also spend their holidy on French beaches. [17:21:44 CEST] <BBB> I suppose thats true [17:21:47 CEST] <BBB> so will I, btw ;) [17:50:42 CEST] <durandal_1707> kierank: where are you going for vacation? [17:51:02 CEST] <kierank> The pub [17:52:09 CEST] <durandal_1707> lies. you are always traveling somewhere [17:53:29 CEST] <kierank> no not really [17:53:33 CEST] <kierank> compared to people like daemon404 [18:45:16 CEST] <ZeroWalker> what's the format for i420? [18:47:23 CEST] <nevcairiel> isnt that just yuv420p [18:48:57 CEST] <FishPencil> Does FFmpeg attempt to detect the input media format from the file extension? If so, where is that code snippet located? [18:51:23 CEST] <Blubberbub_> AVInputFormat has an extension-property or something like that, i think [18:52:09 CEST] <FishPencil> Is there some sort of case that defines what decoder to use based on the extension? [18:53:17 CEST] <J_Darnley> As I understand it avformat will use the demuxer that gives the highest probe score. If a demuxer only matches by extension then it is supposed to give a fairly low score. [18:53:19 CEST] <nevcairiel> no, if anything the extension only decides the demuxer, and the demuxer decides the decoder based on the file contents [18:53:37 CEST] <nevcairiel> although many times files are actually probed for a magic number instead of extension based matching [18:54:23 CEST] <FishPencil> nevcairiel: Where is the demuxer decided from the extension? [18:55:03 CEST] <nevcairiel> somewhere in libavformat? :) probably utils.c, if I have to look it up, so can you =p [18:55:57 CEST] <iive> probe is the used term, and i think the function had it in its name [18:56:57 CEST] <iive> as J_Darnley said, the type is decided by content first, and if the content is not definitive enough, then the extension could be used in the mix. [18:57:29 CEST] <ZeroWalker> nevcairiel, it is? doesn't the "i" makes it, non-P ? [18:57:34 CEST] <iive> e.g. mpeg video and mp3 share same format [18:57:47 CEST] <nevcairiel> ZeroWalker: we dont have separate raw formats for interlaced or progressive [18:58:13 CEST] <nevcairiel> the "p" stands for planar, not progressive [18:58:18 CEST] <ZeroWalker> ah my bad, meant [18:58:22 CEST] <ZeroWalker> interleaved/planar [18:58:46 CEST] <nevcairiel> The only I420 I know is planar [18:58:55 CEST] <nevcairiel> like YV12 just without flipped U/V planes [18:59:02 CEST] <J_Darnley> FishPencil: if you want to modify a demuxer, first start by locating the file that contains the definition of it. [18:59:19 CEST] <ZeroWalker> but wait, isn't yuv420p == YV12 [18:59:37 CEST] <nevcairiel> almost but not quite [18:59:46 CEST] <nevcairiel> YV12 has the u/v planes in a different order then yuv420p [19:00:07 CEST] <J_Darnley> yuv420p == I420 [19:00:20 CEST] <ZeroWalker> so what is YV12 in ffmpeg? [19:00:27 CEST] <nevcairiel> nothing [19:00:35 CEST] <nevcairiel> take yuv420p and flip data pointers [19:00:41 CEST] <J_Darnley> We don't have one. We have the planes in the "correct" order [19:01:14 CEST] Action: J_Darnley goes afk [19:01:18 CEST] <ZeroWalker> ah, not sure how to flip them, but i guess it's the [4] array thing? [19:01:43 CEST] <ZeroWalker> that's good to know, i always thought YUV420P was YV12 (cause, it's yuv, 420 and planar), but it's not that easy xd [19:01:56 CEST] <ZeroWalker> so is NV12 the same as i420? [19:02:09 CEST] <iive> no [19:02:14 CEST] <iive> nv12 is mixed format [19:02:27 CEST] <iive> it has 2 planes. One pure Y (luminance) [19:02:43 CEST] <iive> and a second with interleaved UV (chroma) [19:02:50 CEST] <nevcairiel> we do have a separate NV12 format =p [19:02:53 CEST] <ZeroWalker> ah [19:02:57 CEST] <ZeroWalker> oh xd [19:03:06 CEST] <ZeroWalker> but why are there so many different formats for the same thing? [19:03:09 CEST] <ZeroWalker> or am i missing something [19:03:50 CEST] <iive> inteleaved format are more useful for presentation [19:04:10 CEST] <iive> because you have all the data in one read block. [19:04:26 CEST] <ZeroWalker> ah, so this is why you often have to use planar in say, avisynth? [19:05:21 CEST] <iive> planars are easier for software decoding, because their blocks are by separate colors/planes [19:06:22 CEST] <iive> nv12 is compromise, since uv usually are of the same size and threated in the same way. [19:06:53 CEST] <ZeroWalker> wait, so when you say presentation, you don't mean decoding it? [19:07:12 CEST] <iive> no, i mean turning it into rgb and output to monitor [19:07:25 CEST] <ZeroWalker> isn't that what decoding is? [19:07:57 CEST] <iive> decoder turns compressed bitstream into yuv pictures [19:08:22 CEST] <ZeroWalker> ah thought you meant, Decoding the raw data to rgb or something, then i get it [19:09:24 CEST] <ZeroWalker> hmm, so how is that other format related, ybcpr (or something?). Think i remember reading that it was able to somehow losslessly convert between RGB and itself [19:09:41 CEST] <iive> when i say presentetion, this also could include the video card hardware. [19:10:27 CEST] <ZeroWalker> ah okay [19:11:02 CEST] <iive> in the past overlays did the yuv->rgv in hardware, so having all the data in one place made things easier for them. [19:11:37 CEST] <iive> cr cb the official standard nams for U V, they are color differentials. [19:11:49 CEST] <ZeroWalker> is this like that "Overlay mixer" thing in Windows? [19:12:05 CEST] <iive> to reg and blue i think. [19:12:07 CEST] <ZeroWalker> oh so they are the same [19:13:03 CEST] <iive> yes, overlay is a special trick, unfortunately having more than one at a time is very tricky. [19:14:16 CEST] <ZeroWalker> oh, how so, doesn't it just take the data and convert it, would think it was a straightforward thing [19:14:53 CEST] <iive> it does it on the fly. [19:15:18 CEST] <ZeroWalker> so it has no clue on the source or something? [19:15:33 CEST] <iive> the overlay is like a second desktop, that is visible only when a specific key color is present on the first fron desktop [19:15:55 CEST] <iive> fron/front [19:16:20 CEST] <ZeroWalker> oh, had no clue, thought it was like a renderer [19:16:47 CEST] <iive> then something like another dac is used that access a second memory region. the dac does the yuv->rgb conversion. [19:17:19 CEST] <iive> renders usually convert the color into new texutre and then blit it on command. [19:17:53 CEST] <iive> anyway... that's now video card ancient history. [19:18:39 CEST] <ZeroWalker> sounds like quite procedure o.o [19:18:55 CEST] <ZeroWalker> so now it's just handled by the gpu, feed yuv get rgb? [19:19:08 CEST] <iive> yeh, let the shaders do the work. [19:20:02 CEST] <ZeroWalker> nice, well don't have much experience with shaders, never really understood how you can use them to convert between colorspaces, as i thought pixelshaders were, per pixel [19:20:41 CEST] <iive> you read 3 values, you use the formulas, you get 3 results. [19:20:43 CEST] <JEEB> if you are interested mpv has plenty of stuff in opengl shaders [19:20:57 CEST] <JEEB> tone mapping, colorspace conversions, scaling [19:22:22 CEST] <ZeroWalker> ah interesting, will have to give it a look. Is that something to prefer even in ffmpeg, or is the cost too large [19:24:45 CEST] <JEEB> it would be interesting to see how performant those things would be in ffmpeg use cases [19:25:10 CEST] <JEEB> but nobody has had the interest to kmplement gpu upload / download or the filters [19:31:36 CEST] <ZeroWalker> ah thought it was something well known. As i know that it's expensive if you have things on the CPU to than let the GPU handle it (compared to if the GPU had the source to begin with). But have no clue when it would be worth that cost, would imagine it being on very large sources (but what do i know;p) [19:33:27 CEST] <Blubberbub_> i would expect some speedup for some filters - but one would need to reimplement everything for the gpu. And for chaining filters one would need to make sure to not copy the data all the time [19:45:27 CEST] <iive> JEEB: i thought that some filters do opencl [19:59:51 CEST] <JEEB> iive: yes there's opencl filters in FFmpeg but nobody knows if they're actually useful or faster than something on the CPU [20:35:52 CEST] <RiCON> last time i tried them, they were a bit faster [20:36:50 CEST] <RiCON> 130fps vs 240fps with an amd 7870 [20:37:16 CEST] <JEEB> what sort of filter did you use? [20:37:19 CEST] <RiCON> unsharp [20:37:55 CEST] <RiCON> didn't test too hard, just a single run w/o filter, w/ filter then w/ filter and opencl [20:39:49 CEST] <RiCON> the only other opencl-enabled filter is deshake [20:46:58 CEST] <ZeroWalker> hmm, so if i try to convert my i420 source by just feeding the raw buffer as &pointer. and av_image_fill_linesizes for the linesize, the source is basically green [20:47:09 CEST] <ZeroWalker> so i guess some plane is flipped or something;d [20:48:22 CEST] <ZeroWalker> oh wait could just use the fill pointers [21:06:49 CEST] <J_Darnley> Green sounds like you're passing in zeros as the chroma [21:17:58 CEST] <ZeroWalker> well it probably just got the wrong place as using the fill_pointers solved it. i jsut gave it the main buffer and hoped for the best before it [21:18:30 CEST] <ZeroWalker> also, the align thing, if you set it to 1, will it cause performance loss even if the data can be aligned to like 32 or something [21:23:06 CEST] <J_Darnley> I don't know the answer to that. [21:23:26 CEST] <J_Darnley> I would assume that ffmpeg would copy it into an aligned buffer at some point. [21:24:02 CEST] <J_Darnley> Many parts of ffmpeg need alignment and assume a buffer to be aligned. [21:25:51 CEST] <kepstin> i remember seeing someone having issues recently when they used the crop filter, which unaligned the buffer, then ran the result through another filter that expected aligned data :/ [21:26:32 CEST] <J_Darnley> I remember that story too but didn't pay much attention to it. [21:52:31 CEST] <thardin> is there a way to suppress "Estimating duration from bitrate, this may be inaccurate"? it is 100% accurate in the case I'm poking with [21:53:30 CEST] <nevcairiel> then calculate it yourself and set a duration in the demuxer [21:53:37 CEST] <nevcairiel> the generic code cannot know [21:53:58 CEST] <thardin> hum-hum.. I don't know the bitrate in read_header [21:54:10 CEST] <thardin> or I *could*, I just have to open the codec real quick [22:03:10 CEST] <ZeroWalker> hmm, that might be problematic as it can't ensure the size, though, i guess i could enforce at least align by 4 as that's needed for YV12 anyway, i think [23:29:29 CEST] <dcherednik> Hi. I am wondering. What is the expected maximum value of input coefficients for AAC psychoacoustic? [00:00:00 CEST] --- Wed Aug 2 2017

1 0

ffmpeg.log.20170801
by burek 02 Aug '17

02 Aug '17

[00:07:26 CEST] <ffpure> guys, is there any filter to set opacity of video to 50% for the entire movie? [00:08:30 CEST] <ffpure> making it into a semi-transparent alpha-channel movie? [00:10:54 CEST] <BtbN> There's not a lot of video codecs which support an alpha channel. [00:11:05 CEST] <BtbN> And for the ones that do it's kind of a hack [00:19:05 CEST] <ffpure> well, i really need it for playback time, like ffplay [00:28:25 CEST] <furq> i don't think ffmpeg displays alpha channels anyway [00:28:29 CEST] <furq> s/ffmpeg/ffplay/ [00:49:45 CEST] <YokoBR> hi folks [00:50:33 CEST] <YokoBR> please, I want to create a "playlist" (several files to play in sequence) on an icecast server [00:50:37 CEST] <YokoBR> how do I do that? [00:51:21 CEST] <ffpure> furq: well, what i am looking for is like fade filter. but same opacity for entire duration [01:23:34 CEST] <twosee> [Parsed_concat_0 @ 000000002a05bb80] Input link in10:v0 parameters (size 1280x720, SAR 2049:2048) do not match the corresponding output link in0:v0 parameters (1280x720, SAR 1:1) [01:23:42 CEST] <twosee> hey trying to figure out what this means: what is SAR? [01:24:28 CEST] <DHE> sample aspect ratio [01:24:54 CEST] <DHE> should be 1:1 for square pixels [01:26:00 CEST] <dl2s4> the movie is squeezed and your player plays it in DAR [01:27:22 CEST] <twosee> im concatting a bunch of video files together as part of an automated process done daily... there isnt errors normally but i guess im hitting some weird edgecase [01:33:10 CEST] <DHE> a slightly odd sample aspect might happen if, for example, you input 1920x1088 whereas you output at 1920x1080 (1080 vs 1088) [01:36:00 CEST] <twosee> yeah all the videos are resolution 1280x738 with display 720p [01:36:50 CEST] <twosee> im concatting 15+ inputs, so I setsar=1:1 on each one? [01:37:02 CEST] <YokoBR> please folks [02:29:54 CEST] <new_guy> Hey everyone, I'm trying to downmux some 5.1 channel audio to 2 channel whilst keeping the 5.1 audio as a second track, I can get it working without keeping the second track but can't see where I'm going wrong otherwise. I'm getting an error telling me the filtergraph was defined for audio out stream 0:2 but codec copy was selected with the following script: ffmpeg -i "****.mkv" -map 0:0 -map 0:1 -map 0:1 -c:v copy -c:a:0 aac -ac:a:0 [02:30:21 CEST] <new_guy> ffmpeg -i "****.mkv" -map 0:0 -map 0:1 -map 0:1 -c:v copy -c:a:0 aac -ac:a:0 2 -af:a:0 "pan=stereo|FL=FC+0.30*FL+0.30*BL|FR=FC+0.30*FR+0.30*BR" -c:a:1 copy "****(new).mkv" [02:30:32 CEST] <new_guy> Sorry, looks like I hit a character limit [02:31:11 CEST] <JASTON> Hey gang, I'm trying to create a system that converts arbitrary multimedia file into an HLS VOD stream (h264/aac) consisting of 10s mpegts segments. [02:31:29 CEST] <JASTON> The hls muxer works great, but I really want to generate the segments on demand if i can, instead of having to preprocess the whole stream. What I have so far works okay, but audio falls out of sync after a while into the stream (noticibly at, say 15 minutes). [02:31:36 CEST] <JASTON> When I try to validate the streams I'm creating I get lots of reports for continuity errors, and I'm wondering if thats the root cause of the drift. I haven't been able to find a way around that, is the on-demand idea a lost cause? or can someone point me in the right direction? [02:33:12 CEST] <thebombzen> new_guy: if you just have one video and one 5.1 audio stream in the input file, try this: ffmpeg -i input.mkv -map 0:0 -map 0:1 -map 0:1 -c:0 copy -c:1 copy -c:2 aac -ac:2 stereo out.mkv [02:33:15 CEST] <thebombzen> or something like that [02:35:15 CEST] <thebombzen> new_guy: it appears you have that, and the command you put there should work, so you should paste the complete command and full console output [02:35:47 CEST] <new_guy> Sure thing give me a sec [02:40:22 CEST] <YokoBR> please, how can I use ffmpeg to stream mp3 to icecast? [02:41:33 CEST] <new_guy> Thought I'd use pastebin hope that's cool. https://pastebin.com/fqbdv5CL [02:42:37 CEST] <thebombzen> new_guy: try using direct indices [02:43:22 CEST] <thebombzen> new_guy: try using -c:1 aac -ac:1 2 -af:1 your_filter -c:2 copy [02:43:50 CEST] <thebombzen> your command looks like it should work [02:44:16 CEST] <thebombzen> but it doesn't. I tested the above just now and it worked for me, so it might just be a bug [02:45:11 CEST] <new_guy> Just tried and threw the same error, very weird [02:46:09 CEST] <thebombzen> new_guy: ah, figured it out. so apparently -af is an alias for "-filter:a" and ignores the stream specifier after it [02:46:16 CEST] <thebombzen> replace -af:a:0 with -filter:a:0 [02:46:18 CEST] <thebombzen> and it should work [02:47:27 CEST] <new_guy> Seems to have worked perfectly, thanks so much! [02:50:40 CEST] <YokoBR> okay, got it [03:58:11 CEST] <codebam> how do I force ffmpeg to never output video [03:59:18 CEST] <codebam> when transcoding to ogg opus from flac with the extention .ogg it makes it a theora video with opus audio with the album art as the video [03:59:30 CEST] <codebam> which breaks playback in basically every music player that plays opus [04:01:17 CEST] <furq> -vn [04:01:31 CEST] <codebam> thank you [04:02:13 CEST] <Cracki> cheers. trying to do a 1000x time lapse with integrated/blended frames, so ideally I'd like 1000 frames averaged into one (output rate = input rate). [04:02:15 CEST] <Cracki> wat do? [04:02:31 CEST] <Cracki> all I see is either taking just two neighboring frames, or nearest neighbor. [04:02:54 CEST] <Cracki> right now I'm using tblend=all_mode=average,framestep=2 [04:06:43 CEST] <kepstin> if you repeat that list of filters 10 times, it'll give you one output frame for every 1024 input frames. [04:06:53 CEST] <kepstin> might be good enough? :) [04:09:51 CEST] <Cracki> yeah but I was hoping for something smarter [04:10:04 CEST] <Cracki> also I'm not sure if that filter does twice the work and then discards half of it [04:10:40 CEST] <Cracki> it probably does... tblend applies this for each of 25 frames/sec, so framestep=2 decimates after the work has been done [04:11:03 CEST] <Cracki> but if I framestep=2 before that, I'm left with 12.5 frames/sec, so the intermediate ones are gone [04:11:35 CEST] <Cracki> I'm considering getting into PyAV and coding it up myself real quick :P [04:12:15 CEST] <Cracki> what are recommended python bindings for ffmpeg these days? pyav seems good to me, but is quite new [04:13:01 CEST] <kepstin> "quite new" probably isn't entirely a bad thing, since it means it'll compile against recent ffmpeg and will work with python3. [04:13:15 CEST] <kepstin> that said, I haven't used any python ffmpeg bindings, so :/ [04:13:17 CEST] <Cracki> it does and does [04:13:33 CEST] <Cracki> I've used it with h264_qsv and _cuvid for hw decode [04:13:50 CEST] <Cracki> the h264 software decoder is still faster if I give it 2-4x cpu count [04:14:23 CEST] <Cracki> especially fun is that I can seek in my source videos... and skip feeding (suspected) b-frames to the codec context [04:14:27 CEST] <Cracki> and also some p-frames [04:14:43 CEST] <Cracki> so I can very quickly decode video from which i only need every n-th frame [04:15:00 CEST] <Cracki> (if it's a multiple of p-frame frequency) [04:18:03 CEST] <Cracki> it unfortunately has a very bare docs export. [04:18:20 CEST] <Cracki> and ffmpeg libs themselves don't even link the docs: https://ffmpeg.org/libavcodec.html [04:22:02 CEST] <kepstin> You probably want https://ffmpeg.org/doxygen/trunk/index.html (linked as "API Documentation" off the main ffmpeg docs page) [04:23:14 CEST] <Cracki> aye [04:23:55 CEST] <Cracki> are the examples in that doxygen "recent"? [04:24:54 CEST] <Cracki> also, any document that ties together how to use that bunch of libraries? [04:25:29 CEST] <Cracki> a getting started or 101 or something that explains the "rules of the game", what are the concepts, primitives, building blocks, etc... [04:25:43 CEST] <Cracki> conventions, math, etc [04:25:53 CEST] <Cracki> e.g., I understand dts and pts [04:26:08 CEST] <kepstin> hmm, not really. The usual suggestion is to look at the C example files to get started [04:26:12 CEST] <Cracki> and from exploring, I figured out that stream seeking in pyav seeks the DTS [04:26:27 CEST] <kepstin> They should all be updated to the modern encode/decode apis now, i think [04:26:32 CEST] <Cracki> I think pyav needs a bunch of articles... [04:26:45 CEST] <Cracki> good good [05:11:51 CEST] <Cracki> would be nice to give tblend option of decimating frames and blending more than two... or rolling that into a new filter... maybe :D [05:43:11 CEST] <tezogmix> hey all, do you happen to know of a utility for windows or even via ffmpeg possibly to allow me to view as a list of all the resolution & frame rate/fps of multiple files at once? [05:59:54 CEST] <tezogmix> Ah, I think I'm able to view some of this with mediainfo utility when loading a folder, just need to tinker with the viewing options [07:42:34 CEST] <kam187> Any idea how to apply translationmatrix side data at a set time? [07:51:48 CEST] <kam187> So I can see I need to use av_display_rotation_set [07:54:43 CEST] <kam187> Oh I see I add it as side data to the frame [07:54:45 CEST] <kam187> Nvm [11:26:16 CEST] <nahsi> I have a DVD9 video that looks like this https://lut.im/EQin5S1Dkk/W3MoIsJN21OkzWlW.png Is there is nothing I can do? Mediainfo reports that it's progressive 23.876 with 2:3 Pulldown. But it's not soft telecined , right? I tried ffmpeg with fieldmatch and decimate filter - it did nothing [11:27:34 CEST] <BtbN> this looks like there's two entirely seperate videos in each field oO [11:27:55 CEST] <nahsi> It's a cut from one frame to the other [11:28:26 CEST] <BtbN> so usually it's just normal interlacing artifacts, and this is an extreme example of a cut? [11:30:54 CEST] <nahsi> Well, it's not extreme. There are a lot of these 'cuts'. Video seems to be progressive i.e. in some scenes there are no 'combing' artefacts at all. mpv reports variable frame rate ~23~29. [11:31:49 CEST] <BtbN> try deinterlacing it. If there is low motion, it will be barely noticable [11:33:50 CEST] <nahsi> I tried. It removes all the combing, video gets blurred and there are lots of artifacts (flicering and jaggering) [11:34:34 CEST] <nahsi> And if if it's soft telecined like it reports then there is the way to restore original framerate right? [11:34:43 CEST] <nahsi> And get ideal result [11:38:11 CEST] <nahsi> screenshot form 'deinterlaced' version https://lut.im/rTPfFk803h/WyJ1FXZh1HlAmddn.png [12:07:23 CEST] <BtbN> Have you tried the pullup filter? https://ffmpeg.org/ffmpeg-filters.html#pullup-1 [12:08:03 CEST] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#detelecine is also a thing [12:08:42 CEST] <BtbN> https://ffmpeg.org/ffmpeg-filters.html#telecine has a list of common patterns [12:08:43 CEST] <nahsi> Thanks I'll try that out [13:41:25 CEST] <BtbN> Can ffmpeg append to an existing m3u8? [13:42:25 CEST] <BtbN> seems like it can [15:22:38 CEST] <Bear10> Hi there I'm attempting to stream an h264 and I'm not having any luck it says [AVBSFContext @ 0x7fa0d6e258c0] No start code is found. and 0:0: could not find codec parameters [15:22:58 CEST] <Bear10> the command I'm executing is as follows: ffmpeg -re -f avfoundation -c:v h264 -c:a libfdk_aac -pix_fmt uyvy422 -framerate 30 -i "0:0" -bufsize 6000k -maxrate 4000k out.mp4 [15:23:22 CEST] <Bear10> I'm on a mac, I checked out the code and installed with libx264 enabled [15:23:30 CEST] <Bear10> Help would be much appreciated [16:31:49 CEST] <leif> Does anyone know why I would be getting an EPERM error when calling av_seek_frame? [16:42:20 CEST] <kepstin> leif: I dunno specifically that error, but is your input read from a protocol that supports seeking? [16:44:37 CEST] <leif> kepstin: Here is the file I'm seeking: https://gist.github.com/LeifAndersen/5a53172cefae2dc95c60f3edf7f24af1 [16:45:20 CEST] <leif> So, h264 and aac. [16:45:25 CEST] <leif> Do they not support seeking? [16:45:38 CEST] <kepstin> mp4 container read from a local file? that should be fine [16:46:30 CEST] <leif> hmm...okay. [16:46:52 CEST] <leif> Would it be possible to get that error if you try to seek to a position out of range? [16:48:32 CEST] <kepstin> ... av_seek_frame doesn't return an error code [16:48:40 CEST] <kepstin> it just returns 0 on failure and >0 on success [16:48:55 CEST] <kepstin> where are you getting an error code from? [16:49:51 CEST] <kepstin> er, wait no that's wrong [16:49:59 CEST] <kepstin> >= 0 on success [16:50:14 CEST] <kepstin> but I don't think it returns any specific error codes on failure [16:50:37 CEST] <leif> kepstin: up, your second one is right (per the doc page anyway) [16:50:40 CEST] <leif> yup* [16:50:48 CEST] <leif> However, I'm getting back a -1. [16:50:59 CEST] <leif> Which is EPERM on my system. [16:51:04 CEST] <leif> Which I find....odd... [16:51:05 CEST] <kepstin> yeah, -1 is returned by the function in several places if the seek fails. [16:51:14 CEST] <kepstin> it's not an error code, just a number that's not >=0 [16:51:21 CEST] <leif> Ah, okay, that makes sense. [16:51:29 CEST] <leif> So irs probably just out of range or something like that. [16:51:33 CEST] <leif> Thanks kepstin :D [16:51:52 CEST] <kepstin> I mean, that still doesn't help you much, seeking should be working in that file :) [16:53:29 CEST] <kepstin> the most usual cause of that is that the avformat is unable to seek, e.g. you're reading from a pipe or some types of streams rather than a file [16:55:14 CEST] <kepstin> but assuming you've just done avformat_open_input on the local file without a customized aviocontext, it should work fine... [16:59:55 CEST] <leif> kepstin: ya, I did to avformat_open_input. [17:00:08 CEST] <leif> Although I'm checking to see if I asked it to seek off the end of thefile. [17:00:17 CEST] <leif> (Like,if I mixed up the timebases of the two streams.) [17:00:50 CEST] <kepstin> yeah, I think attempting to seek past the last keyframe would give an error [17:01:16 CEST] <kepstin> depending on seek options? not sure. [17:07:23 CEST] <leif> mmm...that makes sense. [17:07:32 CEST] <kepstin> leif: note that with av_seek_frame, you fairly often will want to use AVSEEK_FLAG_BACKWARDS to have it return the closest keyframe before the seek point, rather than the closest keyframe after [17:07:34 CEST] <leif> I'll try it out and see what happens. Thanks. :) [17:07:52 CEST] <leif> Oh, cool, thank yo, I didn't realize that. [17:07:58 CEST] <leif> That is very helpful actually. [17:08:32 CEST] <kepstin> that's ... poorly documented, unfortunately. [17:09:31 CEST] <leif> Ya, that happens. [17:10:01 CEST] <leif> FWIW, I'd be happy to fix that. Is the proper way to do it to modify it in the source repo and send a patch to the dev mailing list? [17:10:28 CEST] <kepstin> the newer avformat_seek_frame method is a lot more flexible & the docs are more clear, but it's still listed as "under construction" and "do not use this yet" :/ [17:11:05 CEST] <leif> Yup. I hear you. [17:11:16 CEST] <leif> Also, iirc, its avformat_seek_file, which I found to be a bit confusing. [17:11:39 CEST] <leif> I just went with av_seek_frame because the docs didn't say that one was under construction. :) [17:12:18 CEST] <kepstin> It's just the newer naming scheme really; it takes an avformat context and operates only on the format level not codec, so, that's how it's named. [17:12:55 CEST] <kepstin> and yeah, making a commit in a local clone of the git repo, then posting that as a patch on the dev ml should be fine for documentation patches. [17:15:14 CEST] <leif> cool, thanks. [17:19:05 CEST] <leif> Also, just using the backwards flag made the error go away. [17:19:13 CEST] <leif> Thanks a lot kepstin That really helped. :D [17:19:36 CEST] <kepstin> if you were seeking past the end of the file, that would, yeah; it'll return the last keyframe in the file rather than an error. [17:20:37 CEST] <leif> kepstin: Ah, okay. So I should still check for that. Thanks. [17:20:56 CEST] <leif> (Or I could have been seeking between the last keyframe in the file, and the end of the file, and it was trying to jump off the end.) [17:20:58 CEST] <leif> Either way, thanks. :) [17:21:37 CEST] <leif> Also ya, I was trying to seek past the end of the file. It looks like the video is only a few seconds long, and I was trying to seek to 50 seconds in. :) [17:21:40 CEST] <kepstin> yeah, you have to check the pts of the frames you get back after the seek, and decide what to do if they don't match where you wanted to be [17:21:42 CEST] <leif> So ya, thanks. [17:22:31 CEST] <kepstin> with the backwards seek option, what you'll typically want to do is decode and discard frames until you reach the frame you're actually interested in. [17:23:32 CEST] <leif> kepstin: Yup, that is exactly what I"m doing. [17:23:44 CEST] <leif> Hence going to the keyframe before what I want is perfectly fine. [17:24:00 CEST] <leif> Hell, in a sense starting from the beginning of the file is fine, but slower. ;) [19:39:36 CEST] <JASTON> Hey gang, I'm trying to create a system that converts arbitrary multimedia file into an HLS VOD stream (h264/aac) consisting of 10s mpegts segments. [19:39:37 CEST] <JASTON> The hls muxer works great, but I really want to generate the segments on demand if i can, instead of having to preprocess the whole stream. What I have so far works okay, but audio falls out of sync after a while into the stream (noticibly at, say 15 minutes). [19:39:46 CEST] <JASTON> When I try to validate the streams I'm creating I get lots of reports for continuity errors, and I'm wondering if thats the root cause of the drift. I haven't been able to find a way around that, is the on-demand idea a lost cause? or can someone point me in the right direction? [19:41:36 CEST] <SolarAquarion> some reason for ffplay, mpv and others i'm getting a black screen [19:41:40 CEST] <kepstin> JASTON: I assume you're generating each segment by, separately for each segment, seeking to a specific spot in the file, encoding 10s to a file? [19:41:43 CEST] <SolarAquarion> when i use totem it works fine [19:41:52 CEST] <SolarAquarion> or a frame rate of zero [19:42:20 CEST] <JASTON> kepstin exactly right [19:42:38 CEST] <SolarAquarion> Resolution: 512x384, Framerate: 0.000 Hz [19:43:07 CEST] <kepstin> JASTON: using the ffmpeg cli, or a custom app with libav*? [19:44:02 CEST] <JASTON> kepstin: ffmpeg, v 3.2.4 fwiw [19:44:03 CEST] <JodaZ> JASTON, been trying to do that a while ago, never got it right [19:44:42 CEST] <kepstin> I don't think you'll be able to get that to work with the ffmpeg cli, since it doesn't have much ability to select exactly which stream you're syncing to with seek [19:44:44 CEST] <JodaZ> JASTON, basically you'd want to do timestamp passthrough, but ffmpeg never gets audio packet splitting right, it always fills with silence [19:45:18 CEST] <JodaZ> JASTON, if you get it right, tell me i'd be very interested [19:45:42 CEST] <kepstin> and doing concatenated packets from separate audio encodes is almost always gonna give a discontinuity - that's tricky because of how encoder preroll & overlapped transforms are handled [19:47:14 CEST] <JASTON> ahhh, kepstin JodaZ think I might be better off trying to get HLS going with fMP4 segments? Or think I'll just run into different problems there? ;) [19:47:17 CEST] <JodaZ> if you just need to mux it should be easy, just drop some packets into the ts, and the ones after into the next - but ffmpeg still gives you hell [19:47:49 CEST] <JodaZ> JASTON, same problems, ffmpeg just has issues with cutting audio at packet boundaries [19:49:22 CEST] <JodaZ> JASTON, i just gave up personally, serving full size mp4's works for most of my devices [19:50:04 CEST] <JASTON> there must be some cryptic combination of flags that would make it work? the hls muxer works great [19:50:34 CEST] <JASTON> JodaZ: ill look into that, thanks for your feedback. also thanks to kepstin [19:51:05 CEST] <kepstin> JASTON: I don't think you'll be able to do it with the ffmpeg cli tool; this is such a specialized case you'd have to make a custom application using the apis to get it to do what you want [19:51:41 CEST] <kepstin> and it would require a fair bit of codec knowledge to get properly concatable segments, particularly audio. [19:54:00 CEST] <JodaZ> JASTON, for continuous operation the hls muxer can just open a new file every once in a while [19:54:39 CEST] <kepstin> yeah, it's really just writing a single continuous mpeg-ts stream, just starts writing to a new file every once and a while. [20:29:57 CEST] <hiru> when using the -map option, how can I select only the source that contains a given language? I found this doc http://ffmpeg.org/ffmpeg.html#Advanced-options [20:30:07 CEST] <hiru> and this example: ffmpeg -i INPUT -map 0:m:language:eng OUTPUT [20:30:23 CEST] <hiru> can I use :language:eng with v and a streams? [20:36:15 CEST] <kepstin> hiru: not sure. it looks like the 'm' is special there, in that it means "match against track metadata" [20:36:29 CEST] <kepstin> so I think it should be able to select any type of stream [20:37:27 CEST] <hiru> so it should be something like -map 0:a:language:jpn right? [20:37:58 CEST] <hiru> I'll try this with a multitrack source.. hopefully it will work [20:41:02 CEST] <hiru> when using -ss and -to how can I set -to to automatically select the end of the stream? [20:41:34 CEST] <kepstin> not sure what you mean, ffmpeg will go until it reaches the end of the stream without needing -to [20:44:32 CEST] <Mockarutan> Good afternoon. I'm having some problem trying to encode Opus into webm. I've written the encoder in c++ and it has worked for H.264+AAC into mp4, and VP8+Opus into ogg. Then with Opus into webm it works only in VLC *but* is totally broken in ffplay and youtube, there is only "click" noises. Can't find much help anywhere I look. I have not found any example that I can get to work with the latest ffmpeg AND encode Opus in webm. But t [20:44:33 CEST] <Mockarutan> TL;DR: Does anybody have any idea why my Opus into webm encoder produces click sounds? More info in StackOverflow post: https://stackoverflow.com/questions/45440374/ffmp [20:44:53 CEST] <Mockarutan> (sorry for wall of text out of nowhere...) [20:45:20 CEST] <kepstin> Mockarutan: hmm. given that opus in webm works perfectly well via the ffmpeg cli tool, this sure ought to be possible. [20:47:17 CEST] <kepstin> Mockarutan: one thing to note: you should probably be selecting the encoder "libopus" by name, rather than codec id. [20:47:26 CEST] <kepstin> similarly for other codecs [20:47:30 CEST] <Mockarutan> Yeah I can make it produce a ogg file with VP8 and Opus, and then convert it to VP9 and opus via ffmpeg.exe tool and it works! I've even gone though a lot of the source code for in ffmpeg.c to so what's different... but can't find much [20:47:50 CEST] <Mockarutan> Alright, I will try that right away! [20:50:06 CEST] <kepstin> depending on the ffmpeg version you're using that shouldn't make a difference, tho. Not sure how the experimental status on the internal opus encoder is handled via the api. [20:50:50 CEST] <Mockarutan> I just yesterday tried the latest stable. [20:52:26 CEST] Action: kepstin notes that opus uses a (sort of) fixed 48kHz internal sampling rate, so the problem might actually be that it's triggering your resampling code, which the other codecs didn't [20:52:32 CEST] <kepstin> so make sure that's working correctly. [20:55:36 CEST] <Mockarutan> Tried with 'avcodec_find_encoder_by_name("libopus");' Did not work. But if the resampler is not working, how can VLC still play it? [20:57:36 CEST] <Mockarutan> Btw, all my sound will likely be in 48hz either way, it's sampled directly from FMOD which is configured for 48. But since Opus wants 960bit frame sizes for some reson, I figure I need the resampler anyway. [20:58:56 CEST] <Mockarutan> *960 bytes not bits... [21:05:55 CEST] <Mockarutan> Also, about the resample. it works in an ogg file... [21:12:21 CEST] <kepstin> hmm, yeah, maybe not the problem then. hard do say. [21:14:42 CEST] <kam187> hmm why doesn't this work [21:14:46 CEST] <kam187> https://www.irccloud.com/pastebin/c0DwVJmj/ [21:23:44 CEST] <ChocolateArmpits> Should a major release be expected somewhere around September? [21:25:08 CEST] <JEEB> no idea [21:26:37 CEST] <thebombzen> kepstin: it's not quite accurate to say that "Opus uses a fixed 48 kHz internal sampling rate" but rather that Opus doesn't support arbitrary sample rates [21:27:11 CEST] <kepstin> that's why I put "(sort of)" in there [21:27:30 CEST] <thebombzen> it's more that 48 kHz is the smallest supported sampling rate greater than 40 kHz [21:27:38 CEST] <thebombzen> it supports 96 kHz [21:28:21 CEST] <thebombzen> I think the most relevant thing is that Opus doesn't support 44.1 kHz, which is a deliberate choice by the developers [21:28:21 CEST] <kepstin> hmm? no, standard opus doesn't support >48kHz sampling; there's no point since it uses a 20kHz lowpass anyways [21:29:00 CEST] <kepstin> I mean, I think you can force libopus to use other sample rates in celt-only mode, but the result isn't a standard-compliant audio stream. [21:29:05 CEST] <thebombzen> ah I was wrong, you're right [21:29:12 CEST] <thebombzen> it does apply a strict band-limit [21:29:58 CEST] <thebombzen> The documentation explains it well, as usual [21:30:07 CEST] <thebombzen> >Opus encoding tools like opusenc will happily encode input files that are sampled at 96 or 192 kHz. However, files at these rates are internally converted to 48 kHz and then only frequencies up to 20 kHz are encoded. [21:30:41 CEST] <thebombzen> So yes what you said is correct in terms of the 48 kHz internal but it applies to higher frequences [21:30:44 CEST] <kepstin> the sampling rates used internally are all just divisors of 48kHz to ease the internal resampling used when e.g. mixing stuff in different encoding modes [21:31:05 CEST] <thebombzen> lower ones like 44.1 kHz aren't "interally 48 kHz" but rather explicitly not supported [21:31:41 CEST] <thebombzen> this makes sense to be honest since digital audio stuff resamples 44.1 music to 48 upon playback [21:31:54 CEST] <thebombzen> so it shifts the responsibility of resampling onto the encoder, not the decoder [21:32:06 CEST] <thebombzen> which makes sense [21:32:39 CEST] <ChocolateArmpits> >digital audio stuff resamples 44.1 music to 48 upon playback [21:32:45 CEST] <ChocolateArmpits> Would like a source on that [21:32:54 CEST] <thebombzen> Most soundcards internally use 48 [21:33:09 CEST] <ChocolateArmpits> There's lots of sound equipment outside of sound cards [21:33:24 CEST] <ChocolateArmpits> or audio chipsets [21:33:42 CEST] <ChocolateArmpits> I think you're making a too broad statement [21:34:19 CEST] <thebombzen> ChocolateArmpits: for people who care about that sort of stuff, don't use Opus. [21:34:40 CEST] <thebombzen> "but muh 44.1 -> 48 resampling errors" [21:34:49 CEST] <thebombzen> don't use Opus [21:36:33 CEST] <thebombzen> because 44.1 -> 48 is actually a mathematically possible thing on a band-limited signal (unlike converting 60 fps -> 24 fps without judder), it's not a big deal. If you really care all that much, then use FLAC. Opus devs say this too [21:37:43 CEST] <kepstin> now I'm imagining what a temporally band-limited signal would look like [21:37:51 CEST] <kepstin> quite blurry, i guess :) [21:37:55 CEST] <kepstin> video signal* [22:24:36 CEST] <RandomCouch> I'm trying to convert .3gp to .ts [22:24:41 CEST] <RandomCouch> not getting errors but losing image [22:24:44 CEST] <RandomCouch> the audio stays [22:25:10 CEST] <RandomCouch> using this command ffmpeg -i myvideo.3gp -c copy -qscale:v 2 -f mpegts output.ts [22:27:34 CEST] Action: kepstin notes that the '-qscale:v' does nothing when you're using -c copy [22:27:42 CEST] <kepstin> can you pastebin the complete output of the command, please? [22:28:38 CEST] <RandomCouch> Sure thing, give me a few moments [22:30:17 CEST] <RandomCouch> ok, I'm using an .mp4 video now and it works.. I actually need help with smoething bigger than this [22:30:57 CEST] <RandomCouch> I'm using ffmpeg on an Android device in my Unity application. The application records videos from the device camera, and then merges it with another video on the device, this other video is yet to be given to us by the client so we're using a placeholder one [22:31:05 CEST] <JEEB> most likely the video format you had can be put into mpeg-ts, but the playback device doesn't support it [22:31:09 CEST] <RandomCouch> the issue is when the two videos are merged, the playback is weird [22:31:27 CEST] <JEEB> see ffprobe file.3gp [22:31:35 CEST] <JEEB> and compare to ffprobe file.mp4 [22:31:41 CEST] <RandomCouch> when it plays the first part of the video, it plays fine, but when it gets to the second part, which is the second video file it starts playing it very choppy [22:31:46 CEST] <RandomCouch> like the frame rate drops significantly [22:32:39 CEST] <RandomCouch> if I play both videos separately they both play fine [22:32:52 CEST] <RandomCouch> but when they're concatenated, the second part is choppy [22:33:13 CEST] <kepstin> RandomCouch: how are you concatenating them? [22:33:24 CEST] <RandomCouch> I'm using this command to concat them (they're both .ts files) -f concat -i files.txt -bsf:a aac_adtstoasc -c copy output.mp4 [22:33:36 CEST] <RandomCouch> in files.txt I'm just naming both files [22:35:43 CEST] <RandomCouch> I'm running more tests, but would like to point out that this issue isn't consistent across all android devices, some devices can play the concatenated video jsut fine [22:36:37 CEST] <kepstin> my guess is that the second video is higher framerate that the other, and the player has issue switching? [22:36:42 CEST] <kepstin> hard to say [22:37:14 CEST] <RandomCouch> The first video, which is recorded by the device, has a variable frame rate [22:37:20 CEST] <RandomCouch> while the second video has a fixed frame rate [22:37:39 CEST] <RandomCouch> I wasn't able to find anything on how to make a video have a fixed frame rate [22:38:20 CEST] <kepstin> usually requires re-encoding it, and duplicating/dropping frames to even out the rate. [22:38:40 CEST] <kepstin> (ffmpeg can do this with -vf fps or equivalently the -r output option) [22:38:40 CEST] <RandomCouch> I'm not exactly sure how to do that [22:38:49 CEST] <RandomCouch> hm [22:38:53 CEST] <RandomCouch> I've tried -r 30 [22:38:58 CEST] <RandomCouch> but it didn't change anything [22:39:25 CEST] <kepstin> you're using "-c copy", right? This requires re-encoding the video. [22:39:31 CEST] <RandomCouch> O [22:39:48 CEST] <RandomCouch> I'm first reencoding the recorded video to mpegts using this command [22:39:53 CEST] <RandomCouch> -c copy -bsf:v h264_mp4toannexb -r 30 -f mpegts [22:40:21 CEST] <kepstin> yeah, the -r there does nothing. I'm actually surprised that it doesn't give you an error, tbh. [22:40:33 CEST] Action: RandomCouch shrugs [22:40:48 CEST] <RandomCouch> I don't know much on video encoding and such, so I mostly jsut try things out and see what works [22:40:55 CEST] <RandomCouch> at this point nothing is working though [22:41:00 CEST] <kepstin> (you would have gotten an error if you'd used "-vf fps=30" - which should do the exact same thing) [22:41:24 CEST] <kepstin> but yeah, I really don't know why you're seeing choppy playback with the concatenated file [22:43:32 CEST] <RandomCouch> Hm yeah I'm thinking it's possibly an android issue [22:43:40 CEST] <RandomCouch> maybe specific devices don't support some specific codec [22:44:16 CEST] <RandomCouch> Anyway time to head home, thanks for the help guys! [22:44:18 CEST] <RandomCouch> :) [23:26:51 CEST] <SolarAquarion> for some reason video isn't playing for the videos [23:26:59 CEST] <SolarAquarion> only the audio [00:00:00 CEST] --- Wed Aug 2 2017

1 0