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

[burek]

[00:10] <ubitux> ffmpeg -f lavfi -i testsrc -f lavfi -i sine -t 10 out.web
[00:10] <ubitux> ffmpeg -f lavfi -i testsrc -f lavfi -i sine -t 10 out.webm
[00:10] <ubitux> unplayable in browsers
[00:10] <ubitux> can anyone confirm?
[00:10] <ubitux> (--enable-libvpx + --enable-libvorbis)
[00:11] <ubitux> works fine without audio
[00:13] <ubitux> it reminds me of the -avoid_negative_ts thing
[00:16] <ubitux> (note: doesn't work better with native vorbis encoder)
[00:58] <cone-411> ffmpeg.git 03Andreas Cadhalpun 07master:b28652599d78: doc: fix spelling errors
[00:59] <cone-411> ffmpeg.git 03Andreas Cadhalpun 07master:928322c15f98: doc: correct license template for t2h.pm
[01:01] <michaelni> ubitux, is that a regression?
[01:02] <michaelni> ubitux, seems to work in firefox here
[01:05] <ubitux> not sure if it's a regression, but doesn't work in firefox 33.1.1 nor chromium 39.0.2171.71, using libvpx 1.3.0 and libvorbis 1.3.4
[01:05] <ubitux> i tried ffmpeg 2.4 and master/HEAD
[01:08] <ubitux> same in 2.0.4
[01:09] <michaelni> does your firefox play other vorbis in webm files ?
[01:09] <michaelni> libvprbis 1.3.2 here
[01:10] <ubitux> oh wait... maybe that's again related to this pulseaudio crap
[01:10] <michaelni> :)
[01:10] <ubitux> flash works fine though
[01:10] <ubitux> but it probably doesn't use it
[01:12] <ubitux> ok, that's that kind of related shit again, so false alert, sorry
[01:13] <ubitux> killing the flashplugin seems to release resources from some audio stack somewhere and getting the other stuff in the browser to get played (mp4, webm, ...)
[01:13] <ubitux> reminds me of the freeze in mpv when audio started...
[01:17] <cone-411> ffmpeg.git 03Andreas Cadhalpun 07release/2.4:883f3e18ddcc: doc: correct license template for t2h.pm
[01:53] <cone-411> ffmpeg.git 03Michael Stypa 07release/2.3:0cc15f7c83aa: fix Makefile objects for pulseaudio support
[02:19] <cone-411> ffmpeg.git 03Michael Niedermayer 07release/2.4:dd2394754d8c: Changelog: update for 2.4.4
[02:37] <cone-411> ffmpeg.git 03Andreas Cadhalpun 07fatal: ambiguous argument 'refs/tags/n2.4.4': unknown revision or path not in the working tree.
[02:37] <cone-411> Use '--' to separate paths from revisions
[02:37] <cone-411> refs/tags/n2.4.4:HEAD: doc: correct license template for t2h.pm
[03:31] <jamrial> gcc 5 seems to have entered the last stage of development (feature freeze), so it may be a good idea to set up a couple fate systems to avoid another fiasco like 4.9.0
[07:49] <nevcairiel> as if they react to bug reports this fast
[08:25] <jamrial> they fixed the 4.9.0 bug in less than a month. it was just reported too close to release
[11:57] <ubitux> so i'm looking at the edit lists again
[11:58] <ubitux> i'm basically adding a timeline system in every AVStream
[11:59] <ubitux> and i'm going to make a first api where you feed an AVFrame, and it basically either drops it, or truncate it before it can be processed
[11:59] <ubitux> now the question is... do i need to make pts adjustment for the gaps?
[12:00] <ubitux> or the timestamps of the full segments are actually overlapping?
[12:00] <wm4> I suppose the timestamps of the final output should be linear
[12:01] <ubitux> so... i guess i need a "mode" to substract the durations of the gaps
[12:02] <ubitux> not sure which to pick, and it might be format relevant
[12:03] <ubitux> well i'll make a PoC and see how it goes
[12:03] <wm4> yeah this kind of stuff might be format specific, I suppose
[13:56] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:b50e003e1cb6: avcodec/motion_est: use 2x8x8 for interlaced qpel
[14:10] <ubitux> wm4: about the flushing allowing the codec not to be open i agree with such thing
[14:10] <ubitux> wm4: i suppose it's useful to simplify error paths?
[14:10] <ubitux> like, you want to flush uncondtionnally at the end
[14:12] <wm4> yes, that's what I did
[14:12] <ubitux> anyway, generally speaking (even thought i didn't do it last time) it think it would be a good idea to document the change in the doxy, such as "Can be called with closed context since lavc 5xx.yyy.zzz"
[14:13] <ubitux> because apps using a recent ffmpeg might rely on that behaviour (by looking at the code) and could assume it was here forever, even thought it's actually recent
[14:13] <wm4> hm yes
[14:14] <ubitux> i added NULL checks in one or two functions like this, but i forgot to do that
[14:14] <ubitux> maybe i should do it... it's more relevant than documenting it in doc/APIchanges, or at least not enough there
[16:01] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:24fdf7334d2b: avformat/utils: Search harder for missing stream information in flv by default
[18:03] <anshul_mahe> Hello, do we have to follow some legal procedure to write copyright thing in newly implemented decoder or encoder
[18:04] <anshul_mahe> or is it just copy paste with name change
[18:04] <anshul_mahe> I have never added any file in ffmpeg, so dont know about it
[18:07] <ubitux> yeah you just copy a random lgpl copyright boilerplate from another file
[18:07] <ubitux> and you update LICENSES and configure if it's not actually lgpl code
[18:08] <koda> hey ubitux can you something about the colormatrix filter?
[18:08] <koda> do you know if it correctly support limited/full range values?
[18:08] <koda> (tv/pc color ranges)
[18:09] <ubitux> sorry, i have no idea
[18:09] <nevcairiel> it converts the color matrix, the range remains untouched
[18:09] <ubitux> i just adjusted the code without thinking of the "overall functionnal" part
[18:10] <ubitux> and i don't remember anything about it
[18:10] <koda> ubitux: kk
[18:13] <koda> nevcairiel: let me re-re-read the filter to be sure
[18:13] <nevcairiel> it just reads all input pixels and does math on them without even caring about the matrix.
[18:14] <nevcairiel> no idea if it would clip or behave oddly on fullrange though
[18:15] <koda> oh maybe the answer is simpler than i thought
[18:15] <koda> the pix_fmts supported do not list full range formats
[18:15] <koda> so there is an implicit conversion to that anyway
[18:16] <nevcairiel> thats not necessarily a sign of anything, since the fullrange formats are of the devil and not everything uses them :p
[18:16] <koda> well if the user does not signal that a video is full range there is no way anyone could do anything
[18:24] <Compn> koda : its easier just to make a sample and a quick command line that shows what you want then to ask what the code actually does ehe
[18:28] <ubitux> except it's faster to read the code and see all code path that testing a black box
[19:02] <koda> nevcairiel: yeah colormatrix inserts a scale filter which takes care of the range
[19:02] <koda> when input is full
[20:16] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:3384d76503b4: avcodec/wmaprodec: Use avpriv_float_dsp_alloc()
[20:16] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:00d4759134de: avcodec/opus_celt: Use avpriv_float_dsp_alloc()
[20:17] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:51f2422c2b7a: avcodec/vorbisdec: Use avpriv_float_dsp_alloc()
[20:49] <ubitux> ok, got a working PoC with edit lists
[20:49] <ubitux> at least it seems so
[20:49] <cbsrobot_> nicw
[20:50] <cbsrobot_> *nice
[20:52] <ubitux> i still have not much use case
[20:53] <ubitux> the multiple stsd sample looks completely broken for another reason here
[20:53] <kierank> use case for edit lists?
[20:53] <ubitux> samples*
[20:54] <ubitux> like, the only sample i have here is used to drop one frame or so
[20:54] <ubitux> every once in a while
[20:55] <kierank> when you edit something in final cut and don't press export you get an edit list i am told
[20:55] <ubitux> looks like the sample is broken because of regression though
[20:56] <ubitux> kierank: i'd love a sample with random starting time and multiple edit list entries with large gaps
[20:56] <kierank> ask thierry
[20:56] <ubitux> to make sure i'm not doing something obviously wrong
[20:56] <cbsrobot_> ubitux: will it fix the famous "multiple edit list entries, a/v desync might occur, patch welcome" ?
[20:56] <kierank> he can make one
[20:56] <ubitux> cbsrobot_: yeah
[20:56] <cbsrobot_> I have one sitting around
[20:56] <ubitux> please share
[20:57] <ubitux> kierank: mmh well, too lazy to mail people
[20:57] <ubitux> i'll just ask when sending the rfc
[20:57] <cbsrobot_> uploading ....
[20:57] <beastd> ubitux: i might have one lying around.
[20:57] Action: beastd is looking
[20:59] <llogan> is Christophe Gisquet ever here?
[21:00] <kierank> yes
[21:00] <kierank> he is kurosu 
[21:00] <llogan> thanks. i couldn't remember.
[21:01] <llogan> kurosu: i can't get an adaptation of your noise bsf example to work: -bsf noise=1. "Unknown bitstream filter noise=1"
[21:02] <ubitux> [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f3814000920] Concatenated H.264 or H.265 might not play correctly.
[21:02] <ubitux> oh ffs
[21:02] <ubitux> is this serious
[21:02] <ubitux> wth is wrong with people
[21:03] <koda> :|
[21:05] <jdm07> does ffmpeg support hw acceleration on android for 2.3(gingerbread and above)? i.e. stagefright integration for h264 playback
[21:05] <llogan> --enable-libstagefright-h264  enable H.264 decoding via libstagefright
[21:05] <llogan> is taht what you need?
[21:06] <jdm07> that sounds great thanks
[21:07] <jdm07> just to be sure that is the best way to do things on android these days yes/no?
[21:07] <rcombs> ubitux: watch out for https://github.com/mstorsjo/libav/commits/dash-full as there's some other edit-list-related work in there
[21:09] <ubitux> rcombs: http://www.reactiongifs.com/r/oh-shi.gif
[21:10] <cbsrobot_> ubitux: https://www.dropbox.com/sh/h27z612qofsk2th/AAAJBxzLdUOIYk66fPD4URsSa?dl=0
[21:10] <rcombs> though I didn't catch if you were working on the muxer or demuxer
[21:10] <cbsrobot_> please let me know when you downloaded it
[21:11] <llogan> kurosu: nevermind. i was messing around with the wrong build. i need to clean up my pig sty.
[21:12] <ubitux> cbsrobot_: thx, downloading
[21:12] <jamrial> anyone seen plepere? it's been a while
[21:13] <jamrial> the influx of hevc asm suddenly stopped :(
[21:13] <jamrial> we still lack idct or sao
[21:15] <ubitux> would be nice to have someone working on those yeah
[21:15] <ubitux> it's been a while we haven't seen anything in that regard
[21:17] <jamrial> i think he started porting some of those from intrinsics to yasm, but stopped midway then disappeared
[21:17] <jamrial> i recall someone mentioning openhevc hired him until october, so that would be why
[21:27] <ubitux> beastd: ack, thx
[21:29] <ubitux> cbsrobot_: received, thx
[21:31] <cbsrobot_> cool
[21:32] <cbsrobot_> ubitux, I'm not sure about the license ... so please do not share ;-)
[21:32] <ubitux> sure ok
[21:32] <ubitux> it doesn't have any audio or..?
[21:38] <cbsrobot_> nope
[21:38] <cbsrobot_> sorry
[21:38] <cbsrobot_> but playing it with ffplay you will see some jumps
[21:38] <cbsrobot_> it's playing smoothly with qt
[21:40] <ubitux> ok it seems to behave better but might not be exactly correct
[21:41] <ubitux> thank you
[21:41] <cone-149> ffmpeg.git 03Reinhard Tartler 07master:e4a77dc204f8: Make the RELEASE file match with the most recent tag
[21:41] <cone-149> ffmpeg.git 03Michael Niedermayer 07master:9978916c531d: Merge commit 'e4a77dc204f80a6876cbd91de9b71c30feebe119'
[22:04] <kurosu> llogan: "./ffmpeg_g.exe -i $INPUT -vcodec copy -acodec copy -bsf:v noise=1
[22:04] <kurosu> -vframes 1000 -y $OUTPUT" doesn't complain here
[22:05] <kurosu> -bsf noise=1 doesn't either
[22:05] <kurosu> llogan, sorry, fifo mode, didn't see you solved the issue
[22:06] <kurosu> jamrial, plepere contract ended and he was hoping for a job in singapore iirc
[22:07] <kurosu> I think the influx of openhevc patches will seriously slow down, not because the extensions are finished but rather than things are moving around in many companies
[22:08] <kierank> hopefully hevc will die like mpeg-4 part 2
[22:09] <kierank> a solution without a problem
[22:09] <kurosu> yeah, it's uncertain whether it's too early - my original opinion
[22:09] <jdm07> with 4k tv's etc what will become the new standard if not hevc(265)?
[22:10] <kurosu> though several ISPs expressed interest in it, and it's likely DVB will have it mandatory for ultrahd
[22:10] <kierank> 4k is shaky to begin with
[22:10] <kurosu> main10 + bt2020
[22:10] <iive> kierank: the plan is h264 to die first, then h266 would kill h265
[22:11] <kierank> h264 won't die
[22:11] <kierank> mpeg-2 is still alive and kicking
[22:11] <kurosu> yeah, I don't see a point in 4K, I wouldn't tell the difference except on a 60" at a <3m range
[22:12] <kurosu> but well, companies got to renew their products and shove down customers' throat some new stuff
[22:12] <gnafu> I can only see value in projection situations, and there really aren't any "affordable" options for home 4K projectors.
[22:12] <gnafu> I sit close enough to my 100"
[22:12] <gnafu>  screen that I believe I could tell the difference between 1080p and 2160p.
[22:12] <rcombs> gnafu: there weren't any affordable options for home 1080p projectors several years ago
[22:13] <iive> kierank: mpeg2 is alive, but I wouldn't say it is kicking.
[22:13] <jdm07> yeah the hw is definitely outpacing content at the moment.
[22:13] <gnafu> rcombs: True.  I'm just saying, it's funny to me that there are so few options in the area I feel it matters most :-).
[22:13] <gnafu> But I understand why.
[22:13] <kurosu> low bandwidth is probably the only realistic scenario, where avc won't be able to compete in 3 or 4 years
[22:13] Action: gnafu is still rocking an older 720p projector XD.
[22:14] <gnafu> I'm just hoping to move to 1080p in a year or so; I won't be upgrading to 4K until it's under $1,500 for a projector that is otherwise comparable to my current one.
[22:18] <rcombs> but ~muh pixels~
[22:18] <Compn> dust in the air blurring muh pixels
[22:18] <Compn> professional hepa filter required
[22:19] <rcombs> aberrations on corneas blurring muh pixels
[22:19] <rcombs> LASIK required
[23:48] <cone-149> ffmpeg.git 03Christophe Gisquet 07master:55a06b461935: doc: mention the noise_bsf parameter in the docs
[00:00] --- Tue Dec  2 2014