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

[burek]

[12:50:49 CEST] <J_Darnley> What would be the best way to enhance the contrast of the blend filter's difference128 mode?  I want to see +/-1 differences more easily.
[12:58:36 CEST] <J_Darnley> Adding my own mode it seemd.
[13:00:18 CEST] <atomnuker> stick another filter on front, something like fftfilt
[13:06:19 CEST] <thardin> can a decoder have options?
[13:06:54 CEST] <thardin> so it seems
[13:09:49 CEST] <thardin> considering writing some freedv/codec2 glue in lavc and lavf
[13:34:15 CEST] <atomnuker> yep, they can have options
[13:34:40 CEST] <atomnuker> (do remember they go before the -i argument if using ffmpeg.c)
[13:45:32 CEST] <thardin> context is raw streams that need to know what mode they are to decode correctly
[13:46:04 CEST] <thardin> like 700B and 700C which are both 700 bit/s modes but slightly different
[13:47:12 CEST] <nevcairiel> Usually you would specify that in some parameter, like codec_tag for simple cases, or otherwise some data in extradata for the decoder to parse
[13:51:08 CEST] <thardin> the suggestion I made on their list is to make use of riff twocc:s
[13:51:31 CEST] <thardin> something like 0xC2XX where XX = mode
[13:51:58 CEST] <nevcairiel> yeah thats what codec_tag would be in our world
[13:54:26 CEST] <thardin> and -codec_tag exists too
[13:56:05 CEST] <thardin> there's some debate whether to create a custom container format. I suggested that .wav can work just fine, unless some special features are needed. one example would be not explicitly writing decoder samplerate
[13:56:33 CEST] <thardin> because of the way it works you can encode from 8 kHz but decode to 48 kHz say
[14:04:38 CEST] <atomnuker> that's what opus does
[14:04:52 CEST] <atomnuker> it always decodes to 48khz regardless of input signal bandwidth
[14:05:33 CEST] <atomnuker> thardin: is there absolutely no way to detect?
[14:09:09 CEST] <cone-290> ffmpeg 03Paul B Mahol 07master:b664d1f3ffbc: doc/filters.texi: add another lut2 example
[14:15:52 CEST] <thardin> atomnuker: at 700 bit/s each packet is 28 bits, so no :)
[14:16:05 CEST] <thardin> hence the need for some kind of container
[14:17:30 CEST] <thardin> these would mostly be dumps of QSOs (radio conversations), but there's also been interest for other applications. one guy used the codec to compress audiobooks
[14:18:21 CEST] <nevcairiel> You would think our storage and connectivity would have evolved beyond extremely low bandwidth codecs like that =p
[14:19:27 CEST] <thardin> depends on how much you want to store :)  plus many people are still stuck with shitty connections, and data caps
[14:19:53 CEST] <thardin> and for radio the lower the data rate the more energy you can put into each bit
[14:26:39 CEST] <J_Darnley> durandal_1707: thanks for the lut2 line.  I'll test the speed of my patch, eventually.
[14:27:27 CEST] <J_Darnley> Or maybe I can squeeze a quick test in now
[14:43:36 CEST] <iive> atomnuker: would you commit pvq_search, it's been 5 days since the last patch.
[14:53:46 CEST] <atomnuker> I'll ping jamrial to take a look at it tonight and commit it tomorrow if there are no issues
[14:53:56 CEST] <atomnuker> or nevcairiel if he has the time
[15:10:08 CEST] <iive> atomnuker: they had enough time
[15:10:33 CEST] <iive> if they want something changed, they can do it after the commit.
[15:13:14 CEST] <atomnuker> chill, tomorrow I'll push it, need to go to sleep now, wouldn't be able to fix fate if it broke something
[15:52:20 CEST] <iive> according to what timezone do you live by? I though you are in GMT
[16:02:47 CEST] <atomnuker> I don't live by any timezone, that's the thing
[16:03:01 CEST] <atomnuker> besides, what's the point of even living by any timezone in the summer
[16:03:33 CEST] <atomnuker> its always bright enough outside to read a book, even at 03:30
[16:04:25 CEST] <atomnuker> I wonder how people up north live like that, I bet they have some pretty thick curtains in every room
[16:05:03 CEST] <atomnuker> just yesterday I was looking at how much of "night" there is up north, and the answer is there isn't any
[16:05:05 CEST] <atomnuker> https://www.timeanddate.com/sun/finland/helsinki
[16:05:46 CEST] <Gramner> you either use curtains or just get used to it.
[16:06:00 CEST] <atomnuker> look at the day/night length, there is no night between april and september and there's usually more day than there is night
[16:08:28 CEST] <Gramner> on the flip side there's hardly any daylight in the middle of the winter here though instead
[16:09:45 CEST] <Gramner> thank <insert deity> for the existence of computers and the Internet. it's the only way of getting through the winter alive
[16:09:57 CEST] <atomnuker> how come?
[16:10:27 CEST] <atomnuker> hm, you have a point
[16:10:48 CEST] <atomnuker> electricity bills are a huge bother and you have to keep yourself distracted from how much you're freezing
[16:12:04 CEST] <atomnuker> whole damn year I've been waiting for summer to hit so I needn't worry and now there's so much daylight at any time runing all the fun it sucks
[16:13:24 CEST] <atomnuker> you know where they don't have issues like that? the equator, truly the home of the human race
[16:13:35 CEST] <Gramner> freezing is overrated unless you actually spend significant time outdoors working or something. I generally use jeans and sneakers unless it's below -40° C
[16:14:31 CEST] <atomnuker> it gets below -40 where you live?
[16:14:37 CEST] <Gramner> yes
[16:14:45 CEST] <iive> atomnuker so I guess you follow this guideline : https://www.youtube.com/watch?v=LO1mTELoj6o (CGP Gray ) :D
[16:18:00 CEST] <J_Darnley> Woo.  I am the laundy pile
[16:18:52 CEST] <atomnuker> iive: its not by choice that I go to bed at nearly 16:00 here, its the incredibly unforgiving oversleep thresholds caused by the total lack of darkness
[16:19:21 CEST] <atomnuker> you delay going to bed each night by 1 hour or so during the winter, nothing happens
[16:20:04 CEST] <atomnuker> in the summer, no, 1 hour is fatal and messes everything up
[16:22:02 CEST] <iive> atomnuker: i though you had said that you are in UK... they are not that close to the north pole, are they?
[16:23:02 CEST] <atomnuker> https://www.timeanddate.com/sun/bulgaria/plovdiv vs https://www.timeanddate.com/sun/uk/london
[16:25:37 CEST] <iive> quite close indeed.
[16:36:22 CEST] <nevcairiel> the nights are not dark enough for you in summer in london? buy shades =p
[16:39:12 CEST] <atomnuker> shades and curtains are not enough
[16:39:50 CEST] <atomnuker> I have to tape random bits and tshirts to get any darkness and not get waken up early in the morning because the sun's shining in my window
[16:40:46 CEST] <atomnuker> and even then it still gets warm and the few stray indirect beams provide plenty of light
[16:40:49 CEST] <iive> you can use some heavy bankets and nail them to the windows. I've heard that the winter is cold, so you must have blankets :D
[16:40:49 CEST] <nevcairiel> also dont get windows to the east
[16:41:23 CEST] <atomnuker> I did not have such problems in my basement
[16:41:33 CEST] <Gramner> windows with built in blinds between the glass panels are amazing fyi
[16:42:04 CEST] <atomnuker> they build things to different specs up there
[16:42:29 CEST] <atomnuker> insulation for the winter and complete light blocking in the summer
[16:43:24 CEST] <atomnuker> well, at least its giving me more motivation to move elsewhere
[16:44:04 CEST] <iive> what? you don't have basement where you live?
[16:48:13 CEST] <atomnuker> no
[17:42:17 CEST] <thardin> hum.. can one dump raw essence data to a file?
[17:42:29 CEST] <thardin> .. gotta add one in rawenc.c it seems
[18:35:07 CEST] <J_Darnley> Is there some option I can use on Linux to not segfault when *reading* from outside an allocated buffer?
[18:35:24 CEST] <Blubberbub_> that sounds wrong...
[18:35:40 CEST] <J_Darnley> Well sure it is
[18:36:09 CEST] <J_Darnley> but I would rather make progress in the middle of my frame than handle the edge cases right now.
[18:36:25 CEST] <Blubberbub_> if its not allocated its not your frame
[18:36:29 CEST] <Blubberbub_> it contains random data
[18:37:03 CEST] <J_Darnley> Sure, at the edge that's true, the rest of the reads will be within the frame.
[18:38:53 CEST] <Blubberbub_> you could just allocate a bigger memory then
[18:39:18 CEST] <J_Darnley> Sure, somewhere, whereever testsrc2 allocates its frames.
[18:39:43 CEST] <kierank> J_Darnley: show me the code
[18:39:44 CEST] <kierank> I will fix it
[18:40:08 CEST] <J_Darnley> If you're really looking for things to do, sure
[18:40:11 CEST] <Blubberbub_> there are only 4 edge cases, aren't there? ;)
[18:42:46 CEST] <Blubberbub_> could also change your code, so it does ignore the edges by only processing the inner part
[18:44:05 CEST] <J_Darnley> OH YES!  DON'T DOEXACTLY WHAT I AM TRYING TO DO.  THAT SOUND LIKE A GREAT IDEA.
[18:44:24 CEST] <Blubberbub_> you misunderstood me
[18:45:17 CEST] <Blubberbub_> your code segfaults because it accesses data out of the frame? shrink your working area so "out of the frame" is inside the frame
[18:45:25 CEST] <iive> Blubberbub_: 4 edges and 4 corners :D
[18:45:35 CEST] <J_Darnley> No.  You mean I shouldn't copy from -2..width+2 which is exactly what I need to do.
[18:45:39 CEST] <iive> Blubberbub_: you mean, allocate frame with bigger width/height
[18:46:15 CEST] <Blubberbub_> that idea was already dismissed earlier. 
[18:46:33 CEST] <Blubberbub_> but yea - boils down to the same thing
[18:47:03 CEST] <iive> i thought that the idea that was dismissed was to allocate more, in the malloc part.
[18:47:49 CEST] <J_Darnley> kierank: pushed to dirac3
[18:48:23 CEST] <J_Darnley> if you really want: move the copying back from dwt_slice into encode_frame
[18:49:06 CEST] <J_Darnley> or do it conditionally in dwt_slice, whichever
[18:49:14 CEST] Action: J_Darnley goes for a piss
[19:54:13 CEST] <thardin> is there a way to set options on a stream?
[19:54:41 CEST] <thardin> in my case I want to manually set codec_tag in a demuxer
[19:56:53 CEST] <thardin> format option is a possibility I suppose, but it'd be nice to be able to use an existing option
[20:47:26 CEST] <thardin> seems it's just that avformat_find_stream_info() tries to open the decoder, which is expecting codec_tag to be set for now
[20:54:58 CEST] <thardin> I think I'll add a -mode option instead or something
[22:29:27 CEST] <artic> Hi! I am trying to seek a h264 file using av_seek_frame(), and I always get the error code which translates to string as "Operation not permitted". Does anyone know what could the error be? Is there any possible way to correctly seek a file like this?
[22:30:01 CEST] <BtbN> is the file even seekable? Or is it a stream/pipe/something?
[22:30:37 CEST] <artic> I read that this conversation already took place here 4 years ago, but no solutions were found: http://lists.ffmpeg.org/pipermail/ffmpeg-devel-irc/2013-May/001376.html
[22:31:19 CEST] <JEEB> I would use a wrapper like ffms2 if you need seeking in raw bit streams (unless you hit a bug in ffms2)
[22:31:36 CEST] <JEEB> a wrapper would index the positions of seekable spots
[22:31:39 CEST] <artic> @BtbN It is a file. Is there a way to know whether I a file is seekable or not?
[22:31:54 CEST] <BtbN> if it's on a normal local disk, it is
[22:35:08 CEST] <artic> @JEEB Unfortunately I cannot use a wrapper since the project I am working on is already fully based on ffmpeg libraries
[22:36:03 CEST] <artic> I don't know if this information is valuable, but ffmpeg is not able to extract such video's duration
[22:36:44 CEST] <BtbN> because it does not have one
[22:36:51 CEST] <BtbN> it also has no framerate
[22:37:27 CEST] <BtbN> the only thing it has is a frame count. And to get that you need to parse the whole thing
[22:38:38 CEST] <JEEB> artic: then if you are required to seek in files without any index you will have to implement something similar
[22:39:45 CEST] <artic> @BtbN However, I have an MJPG video (which contains an audio stream). I am able to seek the video file using timestamp. However, ffmpeg is not able to return me a valid duration. Can ffmpeg still seek the file because it has an audio stream perhaps?
[22:40:13 CEST] <BtbN> if it is in a proper container, which it probably is when there is audio, yes
[22:40:20 CEST] <BtbN> the container provides the neccessary meta data
[22:40:32 CEST] <JEEB> of course you have containers where there is no seeking related metadata
[22:40:34 CEST] <JEEB> like mpeg/ts
[22:40:39 CEST] <JEEB> *mpeg-ts
[22:41:01 CEST] <BtbN> I'm pretty sure it will offer rudmimentary seeking for ts though
[22:41:11 CEST] <BtbN> Not perfect, but somewhat working
[22:41:16 CEST] <JEEB> yes, but that will not end up where you want in general
[22:41:21 CEST] <JEEB> unless you do bytewise seek
[22:44:53 CEST] <artic> JEEB BtbN: Got it. I think I will need to preprocess the whole video in this case then. I was thinking about mapping frame timestamps to byte positions. Would you have recommended resources where I can read about bytewise seek?
[22:45:14 CEST] <JEEB> it's just a flag :P
[22:45:16 CEST] <BtbN> just remux it into mp4 or something?
[22:45:31 CEST] <BtbN> you generally don't want to deal with raw h264
[22:45:38 CEST] <JEEB> I agree :P
[22:45:45 CEST] <JEEB> too bad ffmpeg.c IIRC still failed with raw H.264
[22:45:55 CEST] <JEEB> so you have to use something like l-smash's muxer
[22:46:35 CEST] <artic> I agree as well hehe. This is purely an user request ):
[00:00:00 CEST] --- Tue Aug  1 2017