[Ffmpeg-devel-irc] ffmpeg-devel.log.20141026

[burek]

[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