[01:23] <iive> there seems to be unusually high level of trolling this month. [02:49] <Compn> iive : getting ready for holiday trolling level [02:00] <cone-669> ffmpeg.git 03Martin Storsjö 07master:851ace79a307: wtv: Avoid needlessly calling gmtime twice with the same argument [02:00] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:50697ac5b2e7: Merge commit '851ace79a307bea54b44bd6f7ecd3b7861c28ec6' [02:25] <cone-669> ffmpeg.git 03Martin Storsjö 07master:9dcf2397219c: lavf: Check the return value of strftime [02:25] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:3b709fd91274: Merge commit '9dcf2397219ca796f0fafce2a703770d6fd09920' [02:32] <cone-669> ffmpeg.git 03Martin Storsjö 07master:3f8f1c6ff24e: lavu: Provide fallbacks for gmtime_r and localtime_r [02:32] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:edb069e55689: Merge commit '3f8f1c6ff24ee858eb5b0bf47ef6d4605299a87e' [03:08] <cone-669> ffmpeg.git 03Martin Storsjö 07master:82ee7d0dda0f: Use gmtime_r instead of gmtime and localtime_r instead of localtime [03:09] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:4a39d4c65a72: Merge commit '82ee7d0dda0fec8cdb670f4e844bf5c2927ad9de' [03:22] <cone-669> ffmpeg.git 03Martin Storsjö 07master:6b9b42cc5576: drawtext: Remove the ifdef for localtime_r [03:22] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:4360c6ff610c: Merge commit '6b9b42cc5576e1819ad1e29d98940066fd14b2d6' [03:29] <cone-669> ffmpeg.git 03Martin Storsjö 07master:ed6dad3737bf: lavf: Implement ff_brktimegm using gmtime_r [03:29] <cone-669> ffmpeg.git 03Michael Niedermayer 07master:abaa41b6426c: Merge commit 'ed6dad3737bf7bb2d5e9fa9511dfdb44806010e8' [12:27] <kurosu> since the addition of tests/ref/fate/sub-*, changes are applied locally automatically (line endings?) [12:27] <kurosu> do I need to modify my git config in some way? [12:27] <kurosu> I have autocrlf = false [12:31] <kurosu> (btw under windows) [12:40] <kurosu> huh, alternated between different configs, switched back to the original, and the issue vanished [16:03] <cehoyos> pross: Hi, how did you test cinedec? [16:04] <cehoyos> I compared the tiff file in http://samples.mplayerhq.hu/V-codecs/Phantom_Cine/phantom_cine/ with what FFmpeg produces and it looks quite different. [16:05] <cehoyos> Do I just miss something important? [16:30] <akira4> umm...ubitux I was wondering about what to do next. Do you have anything in mind? [16:34] <ubitux> akira4: well, so far STL support is OK, we can look at supporting the markup, but there is probably more interesting things to do subtitles wise [16:34] <ubitux> you may want to have a look to https://trac.ffmpeg.org/query?status=!closed&keywords=~sub [16:35] <ubitux> you could start considering the vobsub muxer, but this might be quite troublesome for now so better postpone it for when you're more familiar with the code [16:35] <akira4> oh. Okay. [16:36] <ubitux> so this is https://trac.ffmpeg.org/ticket/2391 and https://trac.ffmpeg.org/ticket/2035 is kind of related [16:36] <ubitux> but it's a bit sensible [16:37] <ubitux> let me see what you could work on... [16:38] <akira4> cool [16:42] <ubitux> most of the current issue are related to the subtitles in various containers [16:43] <ubitux> like, in mpeg-ts, mov, or mkv [16:43] <akira4> I see... [16:43] <ubitux> and also bitmap related [16:43] <ubitux> you'll probably have to get familiar with these containers, and how bitmap subtitles work to deal with these issues [16:44] <ubitux> so far, for the big pictures, we have various big problems [16:44] <akira4> hmm. [16:44] <ubitux> for the big picture* sorry [16:44] <ubitux> like, for text subtitles, the decoded text is broken, but i'm currently working on this, so there isn't much you can do about it [16:44] <ubitux> and also, it's very API change related [16:45] <ubitux> the idea is to move the decoded subtitles structure from libavcodec to libavutil [16:45] <ubitux> that's what we did for audio and video (AVFrame) which is in libavutil [16:45] <ubitux> the main motivation for this is to be able to access them in libavfilter, without a dependency to libavcodec [16:46] <akira4> so then what exactly does libavcodec have? [16:46] <ubitux> so there are some boring api design involved here [16:46] <ubitux> libavcodec only has decoders and encoders [16:46] <akira4> okay. [16:46] <ubitux> libavfilter filters frames, but it doesn't need to know about codecs [16:47] <ubitux> like, you could have an application working on RGB data and willing to process the frames [16:47] <ubitux> without involving the codecs [16:47] <ubitux> that's the idea of not having a dependency on libavcodec in libavfilter [16:47] <ubitux> libavutil is basically the shared dependency of all the other libs [16:48] <ubitux> so that's where we put the common stuff, here AVFrame, and soon the subtitles [16:48] <akira4> big change huh [16:48] <ubitux> yeah, kind of [16:48] <ubitux> so anyway, for the text subtitles, i'm working on moving the structure to libavutil, and i'm not exactly sure what to do for the bitmap ones [16:48] <ubitux> (currently the structure is shared between bitmaps and text) [16:49] <ubitux> (AVSubtitle) [16:49] <akira4> oh. [16:49] <ubitux> anyway, so this is one of the issue [16:50] <ubitux> another big one is related to closed captions [16:50] <ubitux> they don't fit really well in the text and bitmap model, because they come along the video frames (afaiu) [16:50] <ubitux> kierank might be able to talk about it more [16:50] <ubitux> currently we seem to have a libzvbi wrapper to deal with that [16:51] <ubitux> i'm not exactly sure how well it works, but it wasn't exactly pretty last time i looked [16:51] <kierank> there are two types of closed captions [16:51] <kierank> one where it's a normal data stream [16:51] <kierank> and one where it sits in the video frame [16:51] <akira4> hmm. okay [16:52] <ubitux> kierank: do you think it would make sense to make akira4 work on the CC? [16:52] <ubitux> afaik that's a long standing issue, and you seemed interested in such support [16:52] <kierank> it's hard/impossible to integrate [16:52] <ubitux> haha [16:52] <akira4> ouch [16:53] <ubitux> akira4: alright, so here is another big issue, let's move to another one [16:53] <akira4> sure. [16:53] <ubitux> next, i could talk about the bitmap subtitles [16:54] <ubitux> this includes typically DVD, DVB or PGS (bluray ones) subtitles [16:54] <akira4> yep. They seem interesting [16:54] <kierank> ubitux: ebu-tt might be interesting? [16:54] <kierank> instead of cc [16:55] <ubitux> kierank: good question... are you interesting in this? i mentioned it in the wiki but i have no idea of the use cases [16:55] <kierank> ubitux: well it's similar to webvtt [16:57] <ubitux> i guess we can have a look to this, but it looks like another big thing with no demand so far [16:57] <ubitux> unless i missed it [16:57] <ubitux> well, i'm gonna finish my little speech about bitmap before we move to this [16:58] <akira4> alright. [16:58] <ubitux> akira4: so yeah, currently our DVD stack is not exactly good [16:58] <akira4> DVD stack? [16:59] <ubitux> yeah, like, if you want to take your dvd and encode it with ffmpeg well... it's not exactly the best way to do it [16:59] <ubitux> which is a shame given that the project is called FFmpeg and DVD are in mpeg :p [16:59] <akira4> haha. I see. [16:59] <ubitux> but basically dvd are into mpeg-ps containers (the .VOB files), and have also various files such as .IFO and stuff like that [17:00] <ubitux> which contain information about the subtitles [17:00] <ubitux> but my knowledge of this is fairly limited [17:00] <JEEB> the DVD specs were never pushed out into the hands of those who are not supposed to know [17:00] <JEEB> so yeah :/ [17:01] <JEEB> videolan seems to be maintaining the DVD reading and format parsing libraries these days [17:01] <ubitux> and as result, some dvd libs showed up years ago [17:01] <ubitux> libdvdread/libdvdcss [17:01] <ubitux> which are used by players to get a "clean" mpeg stream and stuff like that [17:01] <ubitux> indeed, now videolan maintains these [17:02] <akira4> hmm. [17:02] <ubitux> you can find them here: http://git.videolan.org/ [17:02] <ubitux> look at libdvd{nav,css,read} [17:02] <ubitux> that's what players use when they want to play dvds [17:02] <ubitux> and ideally, ffmpeg should be using those [17:03] <ubitux> so anyway, so far you can actually get video and audio somehow with ffmpeg even without those libs but the subtitles support is as you might guess, pretty bad [17:03] <akira4> I see. [17:03] <ubitux> some external tools are able to extract the subtitles from the dvd into a .sub and .idx couple [17:04] <ubitux> the .sub contains the bitmaps data, and the .idx is a text file informing the offset of the bitmaps, with timestamps, language, and various other metadata such as colors [17:04] <ubitux> in ffmpeg we have support for .sub/.idx for reading [17:04] <ubitux> ideally, we should be able to create such file [17:05] <ubitux> but that's a sensible issue [17:05] <ubitux> (because dvd subtitles are kind of tricky) [17:06] <akira4> okay. [17:06] <ubitux> so anyway, the dvd subtitles themselves can be stored in various containers [17:06] <ubitux> you can find them in the .VOB of the DVDs (with the .IFO giving additionnal information) [17:06] <ubitux> you can find them in .SUB files (with the .IDX giving timing and additional information) [17:06] <ubitux> (those being extracted from the VOB and IFO by random tools) [17:07] <ubitux> you can also find them muxed into .mkv [17:07] <ubitux> ffmpeg supports them in the 2 later (sub/idx and mkv), and maybe other formats [17:07] <ubitux> but directly from dvd, so far, we can't [17:07] <ubitux> SO, back to the subject, if we want such support [17:08] <ubitux> we probably want to add support for libdvdread typically [17:08] <ubitux> so we can read streams from the dvd, notably the subtitles [17:08] <cone-646> ffmpeg.git 03Michael Niedermayer 07master:a9564e859bfc: avformat/mlvdec: Check the return code from strftime() [17:08] <cone-646> ffmpeg.git 03Michael Niedermayer 07master:f0390638e0e1: avformat/matroskadec: Check the return code from strftime() [17:08] <cone-646> ffmpeg.git 03Michael Niedermayer 07master:c0002ddb019d: ffmpeg_opt: Check the return code from strftime() [17:08] <ubitux> and then be able for instance to create a .mkv with the subtitles out of the original dvd [17:08] <ubitux> which is very interesting for a user who wants to rip his own dvds [17:08] <ubitux> (which are currently dying) [17:09] <akira4> hmm. [17:09] <ubitux> so, this isn't a subtitles only project, but it could be interesting [17:09] <ubitux> and actually, an old patch already exists [17:09] <ubitux> which you could look into [17:09] <ubitux> are you interested in this, or we look at the ebu-tt thing? [17:09] <akira4> I'm interested in this one [17:10] <ubitux> the dvd? [17:10] <akira4> yep [17:10] <ubitux> alright, cool, i'm very also interested in seeing such support in ffmpeg [17:10] <ubitux> gonna dig Stefano's DVD patch then [17:10] <ubitux> give me a moment [17:10] <akira4> sure. [17:11] <ubitux> https://trac.ffmpeg.org/ticket/3280 a related ticket [17:12] <ubitux> this iso hasn't any subtitles though [17:12] <ubitux> akira4: ah yeah, there is also the dvdnav support which is basically refering to the menu and shit when you read a dvd [17:12] <ubitux> but we don't want to care about this for now [17:13] <akira4> okay. [17:13] <ubitux> libdvdread is to be able to read the dvd, libdvdcss is about the security shit, and libdvdnav is for the click menu stuff [17:13] <ubitux> you'll be only interested in libdvdread basically [17:13] <akira4> cool. [17:14] <ubitux> where is that patch grumbl. [17:15] <cehoyos> The link is in the ticket iiurc [17:15] <cehoyos> iiuc [17:15] <ubitux> ah! http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2012-January/119842.html [17:15] <ubitux> here it is [17:16] <ubitux> i think it will be wise to create a "dvd" format instead of protocol, which has too many limitation [17:16] <ubitux> otherwise, you'll be unable to export chapters and stuff [17:16] <ubitux> so... better pick the format model [17:16] <wm4> please don't add crappy unusable shit like the current bluray support [17:16] <wm4> make it useful for everyone [17:16] <wm4> but I can see it coming... [17:17] <akira4> I'll try. [17:17] <ubitux> wm4: yeah bluray is implemented through a protocol so it suck a bit [17:18] <wm4> "a bit" [17:18] <ubitux> thought, it was useful to have such support last time to dump a part of the video [17:18] <wm4> it's utterly unusable, except for creating bad transcodes [17:18] <ubitux> well, it was useful to dump the raw video at least [17:19] <ubitux> akira4: so anyway yeah, not useful for subtitles immediately, but if we can get the dvd subtitles from such support that will be great [17:19] <ubitux> akira4: because currently, you can still feed ffmpeg the vob and it will do just fine for the a/v [17:19] <wm4> my suggestion is implementing dvd support as demuxer [17:19] <ubitux> wm4: that's what i suggested as well [17:19] <ubitux> akira4: but for the subtitles... not so much :) [17:20] <ubitux> hopefully libdvdread is smart about the subtitles [17:20] <ubitux> otherwise... you might need to parse IFO files and stuff [17:20] <ubitux> you'll have to check this stuff by yourself [17:20] <ubitux> that's all i know about this [17:20] <akira4> hmm. okay. [17:21] <wm4> ubitux: libdvdread is a low level piece of shit that requires you to deal with the parsed dvd structures yourself [17:21] <ubitux> don't frighten akira4 :( [17:21] <ubitux> akira4: so yeah, your mission if you accept it would be to add dvd support as a demuxer (just like libavformat/stldec.c) using these libs [17:21] <ubitux> but instead of outputing just a single subtitles streams, it will output various audio, video and subtitles from it [17:21] <wm4> ubitux: frighten? this stuff _is_ bad and complicated [17:22] <ubitux> akira4: in other words, you want to be able to do ffmpeg -f dvd -i mydvd.iso -c copy out.mkv [17:22] <ubitux> (mkv can contain all the mpeg streams with no transcode right?) [17:23] <akira4> yeah. [17:23] <wm4> but please WITHOUT relying on the timestamp rewriting code in ffmpeg.c [17:23] <ubitux> how is that related? [17:24] <ubitux> do we have examples of dvd reading somewhere that could be used as a base? [17:24] <ubitux> wm4: mpv still has it? [17:25] <JEEB> VLC's is probably the least bad [17:28] <wm4> ubitux: has what? [17:28] <wm4> JEEB: I think vlc makes some simplifications [17:28] <ubitux> libdvd* support to read from dvd:// [17:28] <wm4> ubitux: yes, both [17:29] <ubitux> mmh GPL though [17:31] <wm4> ubitux: just like libdvdread? [17:31] <ubitux> yeah, but i mean i can't tell akira to look at this when adding the demuxer which will probably be lgpl [17:32] <wm4> does that make any sense? [17:33] <wm4> or are you expecting a gpl-free libdvdread replacement [17:33] <ubitux> vlc was relicensed to lgpl, this could happen libdvd* or a later fork/rewrite [17:33] <ubitux> not having to worry about the demuxer license will simplify this [17:49] <cone-646> ffmpeg.git 03Matthew Oliver 07master:2060f4cbba62: avutil/intmath: enable builtin intrinsics for icl and msvc. [17:52] <akira4> so then what do I do? [18:01] <ubitux> akira4: you can look at the patch from Stefano [18:01] <ubitux> it is implemented as a protocol so you'll have to implement it as a demuxer instead [18:02] <ubitux> then maybe look a bit at vlc code to see how to use it [18:02] <akira4> okay. I'll do that. [18:05] <cehoyos> Should it be a device? Or is that just nonsense? [18:06] <ubitux> not sure it makes much difference [18:06] <ubitux> just a different directory right? [18:07] <cehoyos> I may really misunderstand the basics but doesn't mean implementing it as a demuxer that an ugly hack will be needed for the used protocol? [18:07] <cehoyos> I thought devices are a little like protocol+demuxer [18:09] <ubitux> afaik devices are just (de)muxers in a different directory [18:09] <cehoyos> So which different protocols can be used for video4linux? [18:10] <cehoyos> Or said differently: Which protocol should be used with the libdvdread demuxer? [18:10] <ubitux> none? [18:10] <ubitux> -f dvd -i ... [18:11] <ubitux> just like lavfi (which is a device, right) [18:11] <cehoyos> But I believe our current demuxers either work with all or at least several protocols, or am I wrong? [18:11] <ubitux> but it's just a AVFMT_NOFILE flag or something like that [18:11] <ubitux> cehoyos: not sure what you mean here [18:12] <ubitux> like, -f v4l2 -i http:///dev/video0 ? [18:12] <ubitux> :p [18:12] <ubitux> can we really do that? [18:12] <ubitux> does it make any sense? [18:12] <cehoyos> No, that's why I believe that a device != a demuxer. [18:12] <ubitux> i wonder if there is really any technical differences [18:13] <cehoyos> And while I still may miss something (or everything) the more I think about it the more obvious it seems to me that dvdread must be a device. [18:14] <ubitux> well, if you prefer, maybe [18:14] <ubitux> it just sounds like a different directory to me :P [18:15] <cehoyos> Then please answer again: Which protocols should the libdvdread demuxer support? [18:15] <cehoyos> I would have expected that it cannot even work with file:// [18:16] <ubitux> well, you could have -f v4l2 -i http://mydvd.iso maybe? but dunno [18:16] <ubitux> http://foobar.com/mydvd.iso [18:16] <ubitux> not sure the avio layer is gonna like that much though [18:16] <wm4> libdvdread doesn't have support for this [18:16] <ubitux> but... let's say smb:// then [18:16] <wm4> although I believe j-b was interested in it [18:16] <cehoyos> So iiuc, you mean there is no problem using the file protocol with libdvdread? In this case, please ignore my comments, I simply misunderstood [18:17] <ubitux> i don't know libdvdread [18:17] <ubitux> not sure if you can define your own avio layer [18:17] <wm4> no, libdvdread AFAIK normally needs a dvd folder [18:17] <cehoyos> I thought it will not / cannot work with our current file protocol [18:17] <ubitux> wm4: so libdvdread handles the whole io layer? [18:17] <wm4> yes [18:17] <cehoyos> How else can it work? [18:18] <ubitux> well you could have io callbacks [18:18] <ubitux> for read & seek [18:18] <ubitux> which could be plugged on avio [18:19] <ubitux> it would make sense to me to be able to -f dvd -i smb://192.168.12.34/mydvd.iso [18:19] <ubitux> at some point [18:19] <cehoyos> Of course! [18:19] <wm4> so naive [18:19] <ubitux> haha sure, but in theory [18:19] <cehoyos> But do you believe that our current file protocol will support libdvdread demuxer? [18:20] <ubitux> in theory i don't think it would be an issue [18:20] <wm4> AFAIK libdvdread has no iso code (I might be wrong), and wants directory accesses [18:20] <ubitux> huh? i remember being able to read dvds from iso with mplayer [18:20] <wm4> same for libbluray [18:20] <cehoyos> Didn't you mount them? [18:20] <wm4> are you sure mplayer didn't try to read the iso as mpeg data [18:20] <ubitux> mmh not sure [18:20] <ubitux> good question [18:21] <nevcairiel> libbluray at least has a pluggable IO layer, you could give it IO functions that somehow read directly out of an ISO, but you would need to add that yourself [18:21] <ubitux> yeah sure, you would do the mapping to avio, shouldn't be impossible [18:22] <ubitux> but anyway, yeah maybe i was wrong about the iso [18:22] <ubitux> -dvd-device <path to device> (DVD only) [18:22] <ubitux> Specify the DVD device or .iso filename (default: /dev/dvd). You can also specify a [18:22] <ubitux> directory that contains files previously copied directly from a DVD (with e.g. vob [18:22] <ubitux> copy). [18:22] <ubitux> this is from mplayer manpage though [18:23] <wm4> then maybe it can do iso, but has no IO callbacks [18:23] <ubitux> yeah, right, for now :) [18:23] <ubitux> but it doesn't sound impossible [18:25] <ubitux> there is already a callback system in place [18:25] <ubitux> because of the dvdcss support [18:25] <ubitux> it just needs to be exposed somehow [19:18] <cone-646> ffmpeg.git 03Christophe Gisquet 07master:6fe02d25ee68: dv: fix weight table for 2x4x8 transform [19:39] <cone-646> ffmpeg.git 03Christophe Gisquet 07master:05da586fef86: dv: move inverse weight tables to decoder [20:00] <ubitux> arwa: please learn to bottom post :) [20:01] <arwa> umm....okay :D [20:13] <ubitux> arwa: use valgrind by the way [20:13] <ubitux> to debug the segfault [20:13] <ubitux> it might not crash on your system because you're lucky [20:14] <ubitux> it will show you where you're doing it wrong in memory [20:27] <arwa> okay [20:27] <arwa> I actually understood what is going wrong [20:28] <arwa> for boundry pixels, it is accessing the pixels which are not the part of the image. [20:29] <arwa> For that case should I zero pad the image? [20:31] <arwa> But when I was going through the writing_filters doc, they mentioned not to change the linesize. [20:37] <ubitux> xbr doesn't define how boundaries should be handled? [20:38] <ubitux> hqx just considers there is no difference when it's out of the boundaries [20:38] <ubitux> iirc [20:39] <ubitux> let me check actually [20:39] <ubitux> yeah well right, it compares against itself so.. [21:22] <arwa> " cp: cannot create regular file `ffmpeg': Text file busy " what does this mean? [21:23] <arwa> I googled it. It is suggesting that multiple processes are running, so i need to kill the process [21:23] <arwa> but after killing the process, its still giving me the same error [21:27] <ubitux> check with lsof [21:27] <ubitux> you just have a ffmpeg running somewhere [22:39] <cone-646> ffmpeg.git 03Kieran Kunhya 07master:74141f693ded: avcodec: Add support for Opus in MPEG-TS [22:39] <cone-646> ffmpeg.git 03Kieran Kunhya 07master:61e42c1124e4: avformat/mpegts: Add support for Opus in MPEG-TS [23:14] <kierank> woah [23:14] <nevcairiel> wee! [23:15] <nevcairiel> can we get muxing now too? [23:16] <kierank> probably [23:19] <kierank> will need to see if ffmpeg doesn't misdetect opus in ts as mp3 first [23:35] <cehoyos> kierank: As said, the only bug I know of is a transport stream that claims ac-3 but contains mp2 and plays fine with WMP / fails with FFmpeg (ticket 1798) [00:00] --- Mon Oct 27 2014