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

[burek]

[00:08] <rcombs> should the null muxer be flagged AVFMT_TS_NONSTRICT?
[00:08] <rcombs> I'd say "probably"
[00:10] <jamrial> if that gets rid of the "Encoder did not produce proper pts, making some up." warning when using it, and there are no bad side effects, I'm all for it
[00:10] <rcombs> jamrial: I want it to get rid of the "Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 6" error
[00:13] <rcombs> to get rid of that warning, I think https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mux.c#L478 needs ` && !(s->oformat->flags & AVFMT_NOTIMESTAMPS)`
[00:34] <rcombs> or, should AVFMT_NOTIMESTAMPS imply AVFMT_TS_NONSTRICT?
[00:40] <rcombs> https://gist.github.com/0e26f490ec13d67996fd simple enough
[02:00] <llogan> relaxed: ping
[02:44] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:331b1f7d813a: huffyuvdec: fix old (v1) rgba
[02:44] <cone-753> ffmpeg.git 03Christophe Gisquet 07master:50a35f0d2e1a: fate: add test for old (v1) huffyuv and rgba
[02:47] <relaxed> llogan: pong
[09:37] <ubitux> kierank: so, what's the plan for ilpack?
[09:38] <ubitux> if we are able to get the same behaviour with swscale, we should probably drop the filter mentioning an example of equivalence
[09:40] <nevcairiel> i think we determined that swscale cannot do interlace chroma upsampling, while ilpack can do that
[09:41] <wm4> ilpack is a simple filter, it could be ported quickly (but not by me)
[09:41] <wm4> what about the pp ones?
[09:41] <ubitux> nevcairiel: the last entry in the thread is about {src,dst}_[vh]_chr_pos options in sws
[09:42] <ubitux> wm4: i thought uspp was useful
[09:42] <nevcairiel> isnt that for different subsampling schemes, or can that even handle interlaced chroma?
[09:43] <nevcairiel> in other news, my new opengl video players works \o/
[09:43] <ubitux> are you going to merge it in ffplay/glplay ?
[09:43] <ubitux> :-°
[09:43] <nevcairiel> you wish
[09:43] <nevcairiel> this is proprietary code
[09:43] <wm4> ubitux: libavdevice already has opengl output
[09:43] <nevcairiel> ie. i get paid!
[09:43] <ubitux> :)
[09:43] <wm4> ubitux: so you can probably make ffmpeg output to libavdevice
[09:44] <ubitux> what about a/v sync?
[09:44] <nevcairiel> i looked at that one for inspiration briefly, but its really quite basic only
[10:56] <kierank> nevcairiel: we decided it was possible with swscale
[10:59] <ubitux> kierank: can you provide an equivalent command line example?
[10:59] <kierank> nevcairiel: though thinking about it now I don't see how swscale can associate a single chroma line with two fields
[11:21] Action: rcombs presents https://gist.github.com/0e26f490ec13d67996fd again
[11:23] <nevcairiel> AVFMT_NOTIMESTAMPS  should probably rather imply that
[11:23] <nevcairiel> unless all other things with AVFMT_NOTIMESTAMPS  also have the flag set already
[11:24] <nevcairiel> (which they don't, apparently)
[11:24] <henry0312> wm4, kierank: I added some comments, https://gist.github.com/henry0312/b0feccedd5b9fd2e636b. If it is good, I'll submit it.
[11:25] <henry0312> (also including small changes, https://gist.github.com/henry0312/b0feccedd5b9fd2e636b/revisions)
[11:33] <wm4> henry0312: hm I'd just send it
[11:36] <kierank> Yes just send it
[11:42] <henry0312> so I need to send it only in the form of format-patch? Or some mail messages would be good?
[11:45] <wm4> using either git send-email or a format-patch as attachment should be fine
[11:45] <wm4> git send-email is probably harder to configure at first
[11:46] <henry0312> a format-patch as attachment should be fine <-- I see.
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:c1b663bc92d3: avfilter/vf_lenscorrection: get rid of some floats
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:2450ca0f3344: avfilter/vf_lenscorrection: get rid of all floats per frame
[11:55] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:32cb6c1fe28f: avfilter/vf_lenscorrection: get rid of floats in init code
[12:34] <cone-895> ffmpeg.git 03Clément BSsch 07master:980a5b01fd07: avutil/motion_vector.h: fix coordinate types
[12:36] <cone-895> ffmpeg.git 03Clément BSsch 07master:f5ddce0753c5: doc/APIChanges: fill 2 hashes from my recent API additions
[13:27] <kierank> ubitux: afaik it's not possible to do interlaced upsampling from the cli
[13:27] <kierank> you'd have to hack the scale filter to use the same chroma line for each luma line
[13:28] <ubitux> do you think it would be a better solution than porting the filter?
[13:36] <Compn>  rcombs : i'll post it to the list for you :)
[13:38] <henry0312> Anyone uploads https://dl.dropboxusercontent.com/u/25391619/aribu_sub_sample.ts to somewhere and post the thread, https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/161619.html, please.
[13:38] <henry0312> Probably, Japanese law prohibits me to do that.
[13:39] <Compn> henry0312 : ok , i can do it :)
[13:39] <henry0312> Compn: thanks!
[13:39] <Compn> henry0312 : can we put this sample on http://samples.ffmpeg.org ? or should we keep it a private sample ?
[13:40] <Compn> that only devels can access
[13:40] <henry0312> Compn: I think it's better to keep it private..
[13:40] <Compn> ok, private it is.
[13:43] <Compn> henry0312 : no arib sub profile b support? :P
[13:43] <Compn> ehe
[13:43] <Compn> ( i dont know if it even exists)
[13:44] <henry0312> Compn: yeah, I think aribb24 doesn't support profile b. https://github.com/nkoriyama/aribb24
[13:45] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:b09ea25fec61: avfilter/vf_lenscorrection: fix memleak
[13:46] <Compn> ah
[13:46] <Compn> henry0312 : ok, sample uploaded, thanks
[13:46] <henry0312> Compn: thx!
[14:10] <Compn> argh, why is atilla flaming so hard on the list
[14:10] <Compn> crazyness
[14:16] <kurosu> henry0312, if you want a sample to remain private, don't paste its link in a channel that is logged ;)
[14:16] <J_Darnley> Is that thread still going on?
[14:17] <Compn> J_Darnley : yes
[14:17] <Compn> and it is super flame
[14:18] <Compn> i ask all ffmpeg devels to not engage with the flames on deb-devel.
[14:18] <Compn> feel free to flame on our lists of course :P
[14:18] <nevcairiel> they stopped CCing ffmpeg-devel, i dont get the shit anymore
[14:19] <henry0312> hmm....
[14:19] <ubitux> yes, they mail privately now ;)
[14:19] <Compn> henry0312 : anyways, you should be ok copyright wise for sharing a small clip. of course i know japanese copyright can be tricky now...
[14:27] <henry0312> Compn: sound more familiar with japanese copyright than I xD
[14:27] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:4728cdd88033: imc: reject files with unfathomable sampling rates
[14:38] <michaelni> ubitux, is "[PATCH] Disable chunked output for Icecast" ok ? i think you know/worked on icecast ?
[14:38] <ubitux> just as a user; i don't know icecast nor its relationship with chunked post
[14:39] <ubitux> i didn't have such issue, so dunno
[14:45] <J_Darnley> > unfathomable
[14:45] <J_Darnley> brilliant
[14:47] <nevcairiel> discussions always get much more interesting when people bring out the big words to sound more believable
[14:56] <kurosu> next on my list: put furlong per fortnight in a commit message
[14:58] <nevcairiel> hm, didnt the x264asm automatically insert mova's when using 3 argument forms on non-avx?
[14:58] <ubitux> it should yes
[14:59] <nevcairiel> i'm mostly wondering about blocks like this: http://pastebin.com/paHyAGQQ
[14:59] <nevcairiel> but maybe i'm missing something
[14:59] <kurosu> nevcairiel, hopefully you are just kidding and not blaming me for tricking or being... highfalutin ?
[15:00] <ubitux> nevcairiel: maybe for forcing pairing? dunno
[15:00] <ubitux> not sure if that's actually relevant
[15:01] Action: nevcairiel will just ask the author of said patch
[15:02] <kurosu> yeah, unless you have a cpu with poor ooe (atom?), I don't see the benefit
[17:23] <cone-895> ffmpeg.git 03Stefano Sabatini 07master:aade9884e95c: lavfi/apad: fix logic when whole_len or pad_len options are specified
[17:23] <cone-895> ffmpeg.git 03Stefano Sabatini 07master:7e4a4bda0e5a: doc/filters/apad: extend documentation
[17:33] <michaelni> kurosu, ive a better fix for #3866
[17:35] <michaelni> theres a integer overflow
[17:42] <kurosu> in the patch (I thought all computations added were on int64_t), or as the source of the error ?
[17:43] <kurosu> michaelni, anyway, please post
[17:43] <kurosu> I think the patch is somewhat incorrect anyway because it makes an error of something that was swallowed on purpose previously
[17:44] <michaelni> kurosu, posted, ok to push ? 
[17:50] <kurosu> michaelni, ok
[17:50] <kurosu> I really didn't notice that one
[17:51] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:a9f3bb14ba8b: avformat/mov: use 64bit for size in mov_skip_multiple_stsd()
[17:51] <michaelni> kurosu, pushed, thx
[18:06] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:4a5cc34b46a8: wavpackenc: assert on too small buffer
[19:26] <alexfu> i'm attempting to display live streaming video directly from device to device over a network and i'm noticing a ~20sec delay. I read ffmpeg streaming guide and it pointed out that one way to reduce latency is by specifying more frequent I frames. where does this configuration go in terms of the ffmpeg C api?
[19:27] <kierank> that doesn't affect latency
[19:27] <kierank> i-frames affect seek time
[19:27] <JEEB> and how long it takes for a client to get a proper picture
[19:28] <JEEB> when joining at a random point of time
[19:28] <JEEB> but yes, latency-wise it really doesn't affect :P
[19:28] <alexfu> i notice about a 4 sec initial startup
[19:28] <JEEB> you should make sure 1) ffmpeg doesn't buffer much data and 2) your encoder doesn't buffer much data if you want to minimize latency
[19:29] <JEEB> for x264 -tune zerolatency, for ffmpeg I just don't know :P
[19:32] <alexfu> JEEB: what's a reasonable size for a buffer in this scenario?
[19:32] <nevcairiel> 20 seconds is way more than your usual encoder latency. Sounds more like something buffers too much when streaming
[19:33] <JEEB> alexfu, I meant pictures getting buffered :P
[19:33] <JEEB> and/or input data
[19:39] <alexfu> oh. if i'm correct, i think an entire picture is being buffered at a time and then being displayed.
[20:01] <alexfu> yeah, i have no idea where to start looking.
[20:35] <alexfu> anything in this http://pastebin.com/HRV0A7KS that might appear to be completely incorrect for live streaming?
[20:59] <rcombs> nevcairiel: hmm, I pondered that as well; think we can safely make that change? (i.e. have AVFMT_NOTIMESTAMPS be a mask containing AVFMT_TS_NONSTRICT)
[21:01] <nevcairiel> I would just change the code that checks the flag to check for either
[21:02] <nevcairiel> Can't be more then 1-2 spots
[21:11] <wm4> __gb__: so any news on the vaapi locking issue?
[21:13] <cone-895> ffmpeg.git 03James Almer 07master:54ca4dd43bdc: x86/hevc_res_add: refactor ff_hevc_transform_add{16,32}_8
[21:30] <cone-895> ffmpeg.git 03Diego Biurrun 07master:11cd727fbd60: vsrc_movie: Adjust a silly typo from b977b287f61fea48ecd6251d54a26334213b7ec6
[21:30] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:24e81a0a8d86: Merge commit '11cd727fbd603197cb1e49654fce3352d56f8fd8'
[21:38] <cone-895> ffmpeg.git 03Diego Biurrun 07master:7cb66ebc0be4: error_resilience: Drop asserts from guess_mv()
[21:38] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:f6ff1cb1bae5: Merge commit '7cb66ebc0be48489785f7166c9d15eac594b0763'
[21:44] <cone-895> ffmpeg.git 03Diego Biurrun 07master:8fc6a70c2167: mpeg12enc: Add missing #include for PICT_FRAME
[21:45] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:4f49c39a2fec: Merge commit '8fc6a70c2167b645b7a37d0cbc0e276e7b787cc9'
[21:56] <cone-895> ffmpeg.git 03Diego Biurrun 07master:593aaee953f8: setpts: Add missing inttypes.h #include for PRId64
[21:56] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:2bfd4ff16ddd: Merge commit '593aaee953f8b07c141ff115e67bae85ef0350c7'
[22:02] <cone-895> ffmpeg.git 03Nidhi Makhijani 07master:13c90bc9a359: adts: Return more meaningful error codes
[22:02] <cone-895> ffmpeg.git 03Michael Niedermayer 07master:fca76dc61ed6: Merge commit '13c90bc9a359e969cc2b7f7e8199b02a0e4c6ec9'
[22:14] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:0625a3806628: hevc_ps: check overflow and test alternate syntax
[22:51] <Compn> rcombs : what if people use nullenc and want to know about timestamp errors ?
[22:54] <rcombs> Compn: do they?
[23:12] <cone-895> ffmpeg.git 03Christophe Gisquet 07master:b3d6543caf3b: dpxenc: fix padding in encode_gbrp12
[23:15] <kurosu> michaelni, the stream found in #3872 seems something we will hardly ever encounter again
[23:16] <kurosu> no real point in me mentioning it, just maybe we should not worry if we have to change that code again
[23:16] <Compn> rcombs : no idea , its possible :P
[23:16] <Compn> rcombs : apparently our fate tests use timestamp info
[23:16] <Compn> in nullenc
[23:17] <Compn> there are replies to your patch on ffmpeg-devel
[23:17] <Compn> if you care to read them
[23:18] Action: rcombs looks
[23:19] <michaelni> kurosu, iam not sure its so rare, there are h264 streams with strange truncated or non escaped SPS too
[23:20] <michaelni> but the hevc case isnt just "not escaped"
[23:21] <rcombs> Compn: hmm, I tend to agree with h.leppkes (and nevcairiel) that it'd make more sense to adjust the code that prints the error. As for people who want that error, maybe it could be an option?
[23:21] <ubitux> h.leppkes and nevcairiel rarely disagree
[23:22] <ubitux> they're like brothers
[23:22] <ubitux> twins, even
[23:23] Action: rcombs WHOISs
[23:23] <rcombs> oh, well then
[23:23] <gnafu> ubitux: iseewhatyoudidthere.jpg
[23:28] <kurosu> michaelni, I suspect this was from an encoder whose sps writing code wasn't updated at the time
[23:28] <kurosu> the mkvmerge code seems to have it correct since day 1 (which seems to be early 2013)
[00:00] --- Fri Aug 22 2014