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

[burek]

[00:02:10 CET] <kierank> the first two don't crash for me
[00:02:20 CET] <nevcairiel> hm here is an interesting result, dca-xll_51_16_192_768_1 has the first two frames with the same checksum, but the dmix2 variant has varying md5s for the first two frames, somehow i would think that would also want to match :D
[00:11:28 CET] <jamrial> it does if you use -ac 2 (swr dowmixing) instead of using request_channel_layout
[00:11:38 CET] <nevcairiel> maybe coeffs change
[00:12:31 CET] <jamrial> it also sounds considerably different
[00:13:14 CET] <nevcairiel> like, better or worse
[00:14:40 CET] <nevcairiel> its a sine wave, how different can it sound
[00:17:04 CET] <nevcairiel> hm odd, i wrote both to wav and it mis-detects it as some adpcm
[00:17:43 CET] <nevcairiel> oh my bad
[00:18:52 CET] <nevcairiel> but yes, they sound quite differently
[00:19:01 CET] <nevcairiel> hard to tell, might be intentional
[00:21:27 CET] <nevcairiel> i think it actually is intentional
[00:21:42 CET] <nevcairiel> the stereo downmix uses another audio source
[00:21:52 CET] <nevcairiel> ie sine _2
[00:26:07 CET] <nevcairiel> if anything, the request channel layout version makes for a much nicer and cleaner audio spectrum
[00:26:36 CET] <jamrial> yeah
[00:28:29 CET] <nevcairiel> so working as intended, i guess
[00:28:34 CET] <Daemon404> dirac pro in rtp...
[00:28:36 CET] Action: Daemon404 blames kierank 
[00:28:50 CET] <kierank> prolly
[00:29:50 CET] <nevcairiel> jamrial: what do you think about just testing downmix of every sample to simplify the test setup? michael seems to like that
[00:30:03 CET] <Daemon404> patch is broken
[00:30:09 CET] <Daemon404> do people copy/pasta patches into their client or something
[00:30:14 CET] <nevcairiel> yes they do
[00:30:25 CET] <Daemon404> .. paste*
[00:30:29 CET] <Daemon404> damn internet reuined my brain
[00:30:34 CET] <Daemon404> ruined veen
[00:30:40 CET] <Daemon404> eh, i give up.
[00:31:38 CET] <jamrial> nevcairiel: you can reuse pcm ref samples (just change the REF line accordingly), so i guess we could
[00:32:08 CET] <nevcairiel> well if i make my function generate them, i can't re-use ref samples
[00:32:38 CET] <nevcairiel> unless they get manually overwritten after the auto-generation
[00:34:49 CET] <jamrial> i mean, you simply write "REF = $(SAMPLES)/dts/dcadec-suite/x96_xxch_71_24_96_3840-dmix_6.pcm" for both dmix_2 and dmix_6 tests
[00:34:57 CET] <jamrial> and it generates only that file
[00:35:13 CET] <nevcairiel> of course, but the idea is to simply let my two macros generate dmix tests for all files
[00:35:17 CET] <nevcairiel> and that one cant special case
[00:37:55 CET] <jamrial> you can in the patch you just sent. unless you mean a new patch that tests dowmix for all samples using a single macro
[00:38:34 CET] <nevcairiel> yes that was the idea, extend the existing macros used for the non-dmix cases to simply also create dmix tests, so no need to explicitly list tests
[00:39:02 CET] <nevcairiel> although that would mean a bunch of duplicate outputs
[00:39:54 CET] <nevcairiel> i could just do it for xll and leave a few select lossy cases for manual checks
[00:48:27 CET] <nevcairiel> that seems better, no unnecessary pcm references, only a few duplicate xll reference text files that harm noone
[02:01:25 CET] <cone-301> ffmpeg 03Timothy Gu 07master:838abfc1d711: x86: vc1dsp: Convert vc1_inv_trans_*_dc to NASM format
[02:19:54 CET] <jamrial> nevcairiel: heh, changing the tests to use f32 and creating the ref pcm files using cpuflags 0 makes all of them fail if i then run them with sse/avx enabled :p
[02:20:18 CET] <jamrial> need to add a fuzz of about 8 to fix it
[03:56:43 CET] <cone-301> ffmpeg 03Michael Niedermayer 07master:1dba8371d93c: avformat: add protocol_whitelist
[04:25:10 CET] <cone-301> ffmpeg 03Michael Niedermayer 07master:fe3fed0b143e: Update demuxers and protocols for protocol whitelist support
[05:41:42 CET] <cone-301> ffmpeg 03Timothy Gu 07master:f5e2b8de55cb: diracdsp_mmx: Fix indentation
[05:48:12 CET] <cone-301> ffmpeg 03Timothy Gu 07master:dd57b316c109: diracdsp_mmx: Fix some more indentations
[10:29:47 CET] <durandal_1707> wm4: so mpv have lua scripting support
[10:30:29 CET] <durandal_1707> how was it done? the filtering side of story
[10:33:32 CET] <wm4> mpv has no scripting in filtering, other than some high-level control
[10:33:49 CET] <wm4> if you want a filter framework with scripting integrated, look at vapoursynth
[10:55:01 CET] <durandal_1707> wm4: I do not want framework I want to create it
[10:56:11 CET] <wm4> yes, but first understand what makes avs and VS great
[10:57:15 CET] <durandal_1707> they are like cancers to me
[10:57:30 CET] <nevcairiel> so you want to create more cancer?
[10:57:50 CET] <wm4> nah he wants ffmpeg to replace them
[10:57:54 CET] <wm4> for the better or worse
[12:10:24 CET] <JEEB> did lavfi nowadays handle cases where input aspect ratio changes?
[12:10:47 CET] <JEEB> so if I have a scale+pad into a specific res (let's say 16:9) and the input at first is 4:3
[12:11:27 CET] <JEEB> if and when it switches to 16:9. would it still work or bork?
[12:16:59 CET] <durandal_1707> JEEB: define bork
[12:18:16 CET] <JEEB> not understand that the input aspect ratio got updated, and recalculate some things
[12:18:55 CET] <Workday> for mpeg2 video does ffmpeg traverse through the whole video file to get total frames or does it do an approximation?
[12:18:56 CET] <JEEB> like recalculation of the scale and pad filters
[12:20:25 CET] <durandal_1707> that two filters may use expr so it should work
[12:21:41 CET] <JEEB> http://up-cat.net/p/b2312b24
[12:21:47 CET] <JEEB> so if something like this would bork
[12:22:01 CET] <JEEB> {} is just for visibility
[12:24:31 CET] <JEEB> should test at some point
[12:24:51 CET] <JEEB> but those should be expressions that should work IFF they get poked :)
[12:24:59 CET] <JEEB> when the AR changes
[13:14:51 CET] <Daemon404> j-b must have so much HN karma
[13:15:27 CET] <j-b> Daemon404: 7000+
[13:15:59 CET] <Daemon404> :D
[13:17:48 CET] <iive> tell me when it goes over 9000
[13:22:32 CET] <iive> ;)
[13:32:54 CET] <Compn> lol the comments... people hate the cone! 
[13:32:56 CET] <Compn> :p
[13:33:17 CET] <J_Darnley> Of course HN would hate the cone.
[13:33:38 CET] <J_Darnley> It doesn't fill their beliefs of what constitutes good design.
[13:34:12 CET] <J_Darnley> "It's too noisy, it should be 'flat'"
[13:34:55 CET] <J_Darnley> "It doesn't have your name in it"
[13:38:11 CET] <thardin> cone?
[13:38:30 CET] <Compn> vlc icon
[13:38:37 CET] <Compn> is a traffic cone
[13:38:44 CET] <thardin> ohhh
[13:41:03 CET] <kierank> J_Darnley: the cone is a symbol of government regulation in markets
[13:41:54 CET] <JEEB> hmm, anyone can spot what I'm doing wrong in this? http://up-cat.net/p/e73fcf91
[13:42:11 CET] <durandal_1707> and of masons
[13:42:13 CET] <JEEB> I do yadif, scale, pad and then setsar/format
[13:42:52 CET] <J_Darnley> You're not esacping the commas
[13:43:20 CET] <JEEB> that's because it's within ""
[13:43:25 CET] <JEEB> it doesn't seem to be a parsing issue
[13:43:40 CET] Action: J_Darnley wonders how that works
[13:43:41 CET] <JEEB> because the thing works, except the input aspect ratio is not followed
[13:43:45 CET] <J_Darnley> What is the error then?
[13:44:05 CET] <JEEB> the input is 720x576 + 16:9 AR
[13:44:21 CET] <JEEB> output is correct AR and res, but it's as if the input format aspect ratio is not taken into mention
[13:44:54 CET] <J_Darnley> scale thinks it has square pixels?
[13:45:11 CET] <JEEB> let me double-check. either 4:3 or square pixels
[13:46:27 CET] <J_Darnley> Perhaps yadif isn't setting output frame properties correctly.
[13:46:54 CET] <kierank> is that guy seriously trying to do hevc on rpi2?
[13:47:07 CET] <wm4> wat
[13:47:12 CET] <JEEB> yeah, it seems to have a 720:576 aspect ratio thing in the middle
[13:47:19 CET] <JEEB> so it seems like it's taken in as 1:1
[13:48:40 CET] <JEEB> ffprobe does show that the DAR is taken into mention
[13:49:00 CET] <JEEB> Stream #0:1[0x64]: Video: mpeg2video (Main) ([2][0][0][0] / 0x0002), yuv420p(tv), 720x576 [SAR 64:45 DAR 16:9]
[13:50:51 CET] <J_Darnley> I don't know what to say then.
[13:51:12 CET] <J_Darnley> yadif appears to call the correct funtion (av_frame_copy_props)
[13:51:15 CET] <Compn> JEEB : why not setdar while you are at it ?
[13:55:36 CET] <ubitux> JEEB: btw, any reason not to use force_original_aspect_ratio instead of the ifery?
[13:56:11 CET] <ubitux> ah mmmh, misread
[13:56:38 CET] <Compn> isnt there also a container aspect you have to set somewhere ?
[13:56:43 CET] Action: Compn remembers setting container aspect
[13:58:40 CET] <JEEB> Compn: setsar handles that too
[13:58:53 CET] <JEEB> the main thing is I know that sar should be 1:1
[14:03:48 CET] <JEEB> J_Darnley: I guess I'll test once more with latest HEAD
[14:04:46 CET] <JEEB> but it seems like yadif hasn't gotten changes after the commit I am on except for the context change
[14:04:56 CET] <JEEB> (which I think was the point of libav merge)
[14:13:31 CET] <JEEB> yeah, same result with current master
[14:13:32 CET] <JEEB> welp
[14:17:06 CET] <J_Darnley> I wasn't suggesting you should update.
[14:17:14 CET] <JEEB> yeah, I just wanted to make sure
[14:17:24 CET] <J_Darnley> Anyway.  I guess it tis time for some printf debugging.
[14:17:30 CET] <JEEB> actually
[14:17:33 CET] <JEEB> take a look at the SAR value
[14:17:38 CET] <JEEB> 64:65
[14:17:40 CET] <JEEB> oh wait
[14:17:42 CET] <JEEB> 45
[14:17:44 CET] <JEEB> ok, that looks better
[14:17:59 CET] Action: J_Darnley thought he saw the right value before.
[14:18:27 CET] <JEEB> yeah, I for a moment thought I saw 64:65 and thought "how the hell can that be 64:65"
[14:18:34 CET] <JEEB> which is deffo not 16:9 with a 720x576 res
[14:18:42 CET] <JEEB> ok, yadif+scale works
[14:19:38 CET] <JEEB> wait what
[14:20:37 CET] <JEEB> ok, that's ok
[14:22:31 CET] <JEEB> ok, I think I have misdone some math
[14:22:35 CET] <JEEB> or misused something
[14:24:55 CET] <JEEB> yeah, it's my brainfart at calculating the scale
[14:25:02 CET] <JEEB> I'm keeping the input aspect ratio
[14:45:05 CET] <kierank> JEEB: read etsi ts 101 154
[14:45:11 CET] <kierank> PAL aspect ratios are non trivial
[14:47:14 CET] <durandal_1707> I wrote lavfi lua script that's capable of registering random filter and doing log calls, very useful indeed
[14:47:26 CET] <JEEB> kierank: I know that
[14:47:41 CET] <kierank> JEEB: I doubt ffmpeg does though
[14:47:44 CET] <JEEB> yeah
[14:48:01 CET] <JEEB> and I'm just failing at life at making my own parameters correct
[14:48:17 CET] <JEEB> basically you'd have to change some AR logic to set the "real" PAL/NTSC aspect ratios
[14:48:30 CET] <JEEB> but that would then probably break a lot of people's assumptions on what is going to be pushed out of their workflows
[14:48:53 CET] <JEEB> we had a long discussions about this with baptiste in like 2011
[14:49:37 CET] <kierank> and I did with nicolas last year...
[14:49:48 CET] <kierank> the nvidia driver was doing the right thing
[14:49:54 CET] <kierank> but this was unacceptable apparently
[15:05:58 CET] <BBB> j-b: congrats! almost of drinking age :-p
[15:08:02 CET] <Daemon404> not in the usa
[15:08:15 CET] <BBB> well theyre not us-based
[15:08:34 CET] <Daemon404> j-b mentioned moving to .ca next year
[15:08:40 CET] <Daemon404> but i suppose thats not all vlc
[15:08:43 CET] <BBB> \o/
[15:08:52 CET] <BBB> well effectively it sort of is
[15:08:53 CET] <BBB> but ohwell
[15:09:41 CET] <j-b> Daemon404: well, yes. I really want to move to .ca or .nz
[15:09:44 CET] <BBB> was it vancouver where the asian food was so good?
[15:10:01 CET] <Daemon404> hongkouver, yes
[15:10:31 CET] <BBB> should do a vlcdevmeetup in hongkouver then
[15:10:49 CET] <Daemon404> wouldnt work, it's outside schengen
[15:13:12 CET] <BBB> WhoCares
[15:13:17 CET] <BBB> schengen is practically dead
[15:16:03 CET] <nevcairiel> wasnt this in ireland once
[15:16:08 CET] <nevcairiel> thats also not technically schengen
[15:16:26 CET] <Daemon404> yes, and people protested
[15:16:34 CET] <Compn> j-b to canada?! ehe
[15:16:46 CET] <Daemon404> but realistically, most of vlc is in europe, so it would be $$$ to fly everyone to vsncouver.
[15:16:55 CET] <nevcairiel> because they need to get a passport or what .p
[15:17:07 CET] <Daemon404> certain people also wont fly.
[15:17:29 CET] <BBB> certain people wont even come if its in paris
[15:17:31 CET] <BBB> ...
[15:19:19 CET] <Compn> i wonder how paris is doing now
[15:19:43 CET] <Compn> do they put army guys at airport/trains like usa ?
[15:20:29 CET] <av500> brussels was full of them
[15:20:36 CET] <nevcairiel> every airport and bigger train stations had at least heavily armed police forces the last couple weeks in europe
[15:21:15 CET] <kierank> nevcairiel: ireland was great
[15:21:18 CET] <kierank> no passport control
[15:21:27 CET] <kierank> CTA ftw
[15:21:32 CET] <nevcairiel> for you from the UK yes =p
[15:21:39 CET] <atomnuker> michaelni: I did send all the patches to the ML as a patchset
[15:21:44 CET] <atomnuker> but they got delayed quite a bit
[15:21:56 CET] <atomnuker> and for some reason that patch for the diractab got split from the rest
[15:22:10 CET] <atomnuker> so yeah, apply that one first
[15:22:46 CET] <nevcairiel> atomnuker: no patch arrived on the ML that actually adds the new diractab.c/h files
[15:22:50 CET] <Daemon404> kierank, i had passport control ;p
[15:22:57 CET] <nevcairiel> i would think 1/4 did that, but it looks like it misses them
[15:23:09 CET] <nevcairiel> are you sure you didnt miss a git add :D
[15:23:11 CET] <Daemon404> in fact the stupid irish visa took up an entire oage of my passport
[15:23:15 CET] <kierank> Daemon404: in the uk?
[15:23:16 CET] <kierank> rofl
[15:23:21 CET] <atomnuker> nevcairiel: damn it I did
[15:23:30 CET] <Daemon404> kierank, yes. 
[15:23:40 CET] <kierank> interesting, I went through a CTA door
[15:23:51 CET] <Compn> i did a bunch of customs going us > uk > ireland > uk > us.
[15:23:51 CET] <Daemon404> it could just be where flybe lands
[15:23:59 CET] <Daemon404> i did exeter<->dublin
[15:24:28 CET] <kierank> maybe exeter doesn't have cta
[15:24:47 CET] <Daemon404> CTA = ?
[15:24:59 CET] <kierank> common transfer area
[15:25:05 CET] <kierank> mini-schengen
[15:25:05 CET] <nevcairiel> its always interesting when you arrive at a local-only gate on an airport, you just go through two doors and are suddenly on the outside, while totally expecting some checks still to come
[15:25:17 CET] <Daemon404> kierank, of course it doesnt
[15:25:23 CET] <kierank> bristol did
[15:25:25 CET] <kierank> separate exit
[15:25:35 CET] <Daemon404> next to no flights would go foriegn->exeter->foriegn
[15:25:42 CET] <Daemon404> why would you have two 50 minutes flights
[15:25:46 CET] <Daemon404> instead of one 1.5 hr one
[15:27:00 CET] <nevcairiel> it really depends if the airport in question has separate gates for domestic/CTA flights, so the people can be separated
[15:27:08 CET] <Daemon404> we dont
[15:27:19 CET] <nevcairiel> if you dont, then everyone has to go through the checks =p
[15:27:21 CET] <Daemon404> UK doesn't really have "real" domestic airports
[15:27:28 CET] <Daemon404> there's London, and London, and London
[15:27:57 CET] <Daemon404> people can claim Manchester or Birmingham do... theyre not, really.
[15:28:04 CET] <nevcairiel> medium-sized airports could still have separate gates for domestic and international flights
[15:28:18 CET] <nevcairiel> the very small ones probably dont
[15:28:21 CET] <Daemon404> yes
[15:29:38 CET] <nevcairiel> for all the security the US usually has regarding airports, when I got on and off a domestic flight, there was practically no checks to speak of
[15:29:57 CET] <Daemon404> i've never flown domestically in the usa
[15:30:10 CET] <Daemon404> and when i fly .ca -> .us, there is pre-clearance in .ca
[15:30:16 CET] <Daemon404> so no border control when i land
[15:31:15 CET] <kierank> If I want to output a PAL8 for debug, how do I output that?
[15:31:44 CET] <nevcairiel> first time I had to fly to the US for work I stayed a couple days in NYC to see the city, had to get where I was going afterwards, so =p
[15:50:45 CET] <kierank> ubitux: is there an equivalent of "rawvideo" for subtitles?
[15:51:15 CET] <ubitux> i don't think so, it doesn't make much sense
[15:51:21 CET] <ubitux> since subtitles timing are sparse
[15:51:34 CET] <kierank> I just want to visually see the dvb teletext
[15:51:54 CET] <kierank> the packets are decoded but ffplay don't show them for some reason
[15:52:09 CET] <ubitux> so we have a decoder for these?
[15:52:11 CET] <ubitux> ccaption dec?
[15:52:16 CET] <kierank> no dvb_teletext
[15:52:18 CET] <kierank> it's a bitmap
[15:52:28 CET] <wm4> do you have a sample?
[15:52:31 CET] <ubitux> then mmh with the overlay we have a hack right?
[15:53:17 CET] <kierank> wm4: maybe I can find one
[15:53:27 CET] <ubitux> ffmpeg -i input.ts -filter_complex '[#0x2ef] setpts=PTS+1/TB [sub] ; [#0x2d0] [sub] overlay' -sn -map '#0x2dc' output.mkv
[15:53:31 CET] <ubitux> (from the doc)
[15:53:50 CET] <ubitux> 0x2* being mts pid)
[15:54:22 CET] <durandal_1707> we should have two kind of subtitle decoders, bitmap which uses rawvideo and text only ones
[15:54:39 CET] <wm4> durandal_1707: but there are formats which mix text and bitmaps
[15:55:38 CET] <kierank> [Parsed_overlay_1 @ 0x225dfc0] [framesync @ 0x1ea6748] Buffer queue overflow, dropping
[15:55:40 CET] <kierank> all over the place
[15:55:52 CET] <kierank> oh i see
[15:56:23 CET] <durandal_1707> use fifo
[16:00:42 CET] Action: kierank hopes this isn't teletext without PTS
[16:01:46 CET] <kierank> can't get that overlay to work
[16:03:23 CET] <Timothy_Gu> my strange good friends, I want to use ffmpeg do some work but I used ffmpeg.exe with trouble.
[16:03:29 CET] <Timothy_Gu> best wish.. I'm from china.
[16:03:37 CET] <durandal_1707> kierank: have you inserted fifo filter?
[16:03:50 CET] <kierank> no but why do I need tha
[16:03:55 CET] <kierank> It encodes now
[16:03:56 CET] <ubitux> kierank: "(0x2d0, 0x2dc and 0x2ef are the MPEG-TS PIDs of respectively the video audio and subtitles streams; 0:0, 0:3 and 0:7 would have worked too)"
[16:03:58 CET] <kierank> but there's no overlay
[16:04:01 CET] <kierank> yeah did that
[16:04:12 CET] <kierank> ./ffmpeg -loglevel debug -i ttx.ts -filter_complex '[#0x1002] setpts=PTS+1/TB [sub] ; [#0x1000] [sub] overlay' -sn -map '#0x1001' -vcodec mpeg2video -b:v 100000 output.mkv
[16:05:15 CET] <JEEB> btw, do I have to use eval=frame with scale filter to make sure it notices when aspect ratio changes?
[16:05:17 CET] <durandal_1707> kierank: because bunch of subtitles are demuxer before others
[16:05:53 CET] <nevcairiel> JEEB: if the alternative is  to only eval once, then it sure sounds like it
[16:06:14 CET] <JEEB> "Only evaluate expressions once during the filter initialization or when a command is processed."
[16:06:18 CET] <JEEB> the last part is what sounds interesting
[16:06:23 CET] <JEEB> "or when a command is processed"
[16:06:36 CET] <durandal_1707> JEEB: isn't there variable that contains ar
[16:06:43 CET] <nevcairiel> sending commands is not something you can just do that easily from the CLI =P
[16:06:49 CET] <JEEB> durandal_1707: ?
[16:06:53 CET] <JEEB> yes
[16:07:02 CET] <JEEB> which I am using
[16:07:24 CET] <durandal_1707> and what ffmpeg version?
[16:07:32 CET] <JEEB> ?
[16:07:36 CET] <JEEB> I've been testing with HEAD now
[16:07:41 CET] <JEEB> I got my stuff fixed
[16:07:51 CET] <JEEB> it was my PEBKAC that I was keeping the aspect ratio as 1:1
[16:07:59 CET] <JEEB> now I'm juts asking if I requrie that init var
[16:08:09 CET] <JEEB> I could of course create conent with an AR change
[16:08:11 CET] <JEEB> and test it
[16:08:17 CET] <JEEB> but I didn't have any at hand
[16:08:49 CET] <kierank> what's the difference between PAL8 and RGB24?
[16:09:01 CET] <durandal_1707> Yes, you need sbsl frame
[16:09:03 CET] <nevcairiel> PAL8 is palettized, RGB24 is RGB?
[16:09:03 CET] <nevcairiel> :D
[16:09:07 CET] <durandal_1707> *eval
[16:09:08 CET] <JEEB> sbsl?
[16:09:10 CET] <JEEB> oh, ok
[16:09:14 CET] <JEEB> cheers
[16:09:30 CET] <kierank> nevcairiel: basically how do I view PAL*?
[16:09:34 CET] <kierank> PAL8*
[16:09:50 CET] <durandal_1707> dosbox
[16:09:52 CET] <nevcairiel> convert it to RGB?
[16:10:22 CET] <Daemon404> PAL8 is not even a colorspace
[16:10:24 CET] <Daemon404> its a hack
[16:10:42 CET] <nevcairiel> PAL8 is two planes, one with an 8-bit color index per pixel, and one plane with 256 RGB palette entries (ie. 1024 byte)
[16:11:02 CET] <Daemon404> see: not a colorspace
[16:11:12 CET] <nevcairiel> its another form of RGB really
[16:11:40 CET] <Daemon404> it's rgb. it's a hack to pass around the palette "in case we need it"
[16:11:47 CET] <Daemon404> e.g. gif->gif
[16:11:48 CET] <Daemon404> or somethin
[16:11:49 CET] <Daemon404> g
[16:11:59 CET] <kierank> ubitux: ah I think setpts is unnecessary
[16:12:01 CET] <kierank> or wrong
[16:12:03 CET] <nevcairiel> the concept of keeping data close to the original isnt that bad
[16:12:44 CET] <nevcairiel> and we have far weirder pixel formats :p
[16:12:48 CET] <kierank> really what I need is a PAL8 to RGB converter
[16:12:52 CET] <kierank> that can output me raw pictures
[16:12:54 CET] <nevcairiel> swscale :)
[16:13:07 CET] <kierank> yeah but I want to do this without going through the api currently
[16:13:10 CET] <Daemon404> or a loop.
[16:13:12 CET] <kierank> just to see whether the teletext actually exists
[16:13:16 CET] <Daemon404> it's just a LUT
[16:13:20 CET] <nevcairiel> the code is easy, yes
[16:14:48 CET] <nevcairiel> two loops and a buffer to write into, its like 6 lines of code
[16:15:16 CET] <cone-623> ffmpeg 03Michael Niedermayer 07master:d117b090211e: avformat/tls_securetransport: Add missing include
[16:20:47 CET] <JEEB> how did I show help for specific filters?
[16:21:35 CET] <durandal_1707> -h filter-negate
[16:21:39 CET] <Daemon404> man ffmpeg-filters
[16:22:50 CET] <JEEB> seems like this build on this other box is from october... ffmpeg -h filter-scale doesn't give naything
[16:23:15 CET] <durandal_1707> you can't use -
[16:23:28 CET] <durandal_1707> use brain
[16:23:37 CET] <nevcairiel> ffmpeg -h filter=scale
[16:24:12 CET] <wm4> durandal_1707: if you want to say the syntax can be guessed intuitively, then HAHAHAHAHA....... NO.
[16:24:51 CET] <durandal_1707> you need to have IQ high for sure
[16:25:35 CET] <JEEB> sorry, tired as fuck at this point :V
[16:25:58 CET] <durandal_1707> just I can't type that character from phone
[16:27:11 CET] <cone-623> ffmpeg 03Kevin Mitchell 07master:5120b03d6987: avformat: add windows.h to SChannel SSP TLS code
[16:27:13 CET] <ubitux>   param0            <double>     ..FV.... Scaler param 0 (from INT_MIN to INT_MAX) (default 123456)
[16:27:17 CET] <ubitux> original value
[16:28:23 CET] <jamrial> ubitux: coverage.ffmpeg.org is not working
[16:28:31 CET] <jamrial> gives 403 error
[16:28:33 CET] <ubitux> ah yeah someone told me i forgot to answer
[16:28:39 CET] <ubitux> yeah going to look at it now
[16:29:16 CET] <jamrial> and 404 if i try to open any link in my browser history (libavcodec directory and such)
[16:30:29 CET] <ubitux> jamrial: http://lucy.pkh.me/ffmpeg-coverage-snapshots/ you have old snapshots here
[16:30:31 CET] <ubitux> some are working
[16:30:53 CET] <ubitux> it broke around 25/01
[16:31:10 CET] <jamrial> i was mostly interested in seeing how the dca decoder will look after we push nevcairiel's patch, but thanks :p
[16:31:19 CET] <ubitux> yep
[16:31:25 CET] <nevcairiel> an up-to-date before would be nice too
[16:31:28 CET] <ubitux> you'll be able to compare with that
[16:31:39 CET] <ubitux> yeah trying to fix asap
[16:32:16 CET] <nevcairiel> would be curious to know how much coverage the three existing samples do give
[16:32:51 CET] <nevcairiel> also, why was I worrying about a few hundred KBs of reference data, the existing xll sample has 8mb of pcm reference, twice!
[16:33:58 CET] <jamrial> yeah, i wonder why it was uploaded twice
[16:34:06 CET] <nevcairiel> decoder was changed
[16:34:17 CET] <nevcairiel> and we dont break old samples so old fate can still pass
[16:34:47 CET] <nevcairiel> it was part of the partial bitexactness of the old decoder
[16:35:11 CET] <jamrial> ah right, those non bitexact xll changes. kinda shortsighted to add 16mb of ref files when it was inevitably going to become bitexact at some point...
[16:35:55 CET] <nevcairiel> i would've probably at least taken the chance to shorten the sample
[16:40:35 CET] <jamrial> and the current samples should be testing both the standard float and fixed codepaths, except probably the x96 stuff (synth_filter64, lfe2, etc) and xch/xxch
[16:53:33 CET] <aworan> Hi all, I am using ffmpeg on my raspberry pi 2 under Ubuntu mate. I recompiled ffmpeg to enable mmal decoders and it work great. I have a question to makes things better on raspberry pi. By default, ffplay or another 3part software like Firefox use h264 decoder. So I want to do a build (modifying source code if needed) to replace h264 decoder code by h264_mmal decoder. Do you think it is possible ? Or a stupid idea ? 
[17:00:50 CET] <ubitux> i think i found the problem
[17:01:02 CET] <ubitux> it's probably due to b46aae093634271931395d65f422f4b2a23112d3 ...
[17:01:54 CET] <ubitux> apparently lcov doesn't like to follow the links
[17:08:19 CET] <jamrial> lol, even more issues because of these hacks
[17:10:18 CET] <ubitux> could probably be fixed by adding a if toolchain=gcov but well
[17:10:39 CET] <wm4> aworan: you need to move the mmal entry above the builtin one in allcodecs.c
[17:13:28 CET] <aworan> OK thank you, I will try it !
[17:17:10 CET] <nevcairiel> ubitux: sounds fun =p
[17:17:42 CET] <ubitux> should i look for a fix or i let Andreas handle it?
[17:18:00 CET] <ubitux> note: you can run the coverage yourself
[17:18:08 CET] <ubitux> revert the commit locally
[17:18:53 CET] <ubitux> you can reset lcov counters with make lcov-reset
[17:19:00 CET] <ubitux> so you can make comparison that way
[17:19:06 CET] <nevcairiel> wonder if my system has gcov
[17:19:35 CET] <nevcairiel> appaers it does
[17:46:06 CET] <kierank> ubitux: ok so got the overlay to work but the subtitles are in the wrong place
[17:46:28 CET] <kierank> how do I debug that
[17:46:53 CET] <kierank> ./ffmpeg -i dest_flavour.ts -filter_complex '[#0x1000] [sub] overlay' -sn -map '#0x1001' -vcodec mpeg2video -b:v 100000 output.mkv
[17:47:15 CET] <ubitux> maybe -canvas_size?
[17:49:24 CET] <kierank> ooh
[17:49:27 CET] <kierank> looks right, thanks ubitux 
[17:51:18 CET] <nevcairiel> (in before fate turns yellow)
[17:51:20 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:da6ee11ecf28: dca: split decoder fate tests into dca.mak
[17:51:20 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:084ab3104953: dca: add new fate tests based on the dcadec-samples test suite
[18:00:15 CET] <nevcairiel> jamrial: definitely improves the coverage quite a bit
[18:02:45 CET] <nevcairiel> dca_core.c 42.8% -> 76.9%, dca_exss.c 49.1% -> 57.5%, dca_xll.c 57% -> 80.8%, dcadec.c 53% -> 75%, dacdct.c 53% -> 100%, dcadsp.c  43% -> 88%
[18:03:09 CET] <nevcairiel> oh and synth_filter.c is also up to 100
[18:05:24 CET] <nevcairiel> now to watch fate for a bit
[18:09:41 CET] <jamrial> you should have probably waited a day for the samples to spread :p
[18:09:57 CET] <nevcairiel> i was told once we dont do that anymore
[18:10:44 CET] <jamrial> oh? ok then
[18:11:17 CET] <jamrial> i thought the fate clients were still purposely doing an rsync per day or so
[18:16:25 CET] <jamrial> nevcairiel: curious, the ref files you uploaded do need after all a fuzz higher than the ones i created locally
[18:17:33 CET] <nevcairiel> my build did use x87 fpmath, not sse, maybe that changes that still
[18:18:52 CET] <jamrial> ah, could be. gcc x86_64 defaults to sse math
[18:28:45 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07n2.4.13:HEAD: dca: add new fate tests based on the dcadec-samples test suite
[18:46:46 CET] <durandal_1707> anybody interested in lavfi having scripting support?
[18:50:36 CET] <atomnuker> durandal_1707: and do stuff like what with it?
[18:52:02 CET] <durandal_1707> changing filter options per call
[18:52:39 CET] <durandal_1707> conditional filtering
[18:52:56 CET] <atomnuker> yeah, that could be nice actually, filtering entire files based on a timeline in your script
[18:57:09 CET] <durandal_1707> thing is there is no way to get Nth frame from input, the only filter with seeking support is movie source
[18:58:39 CET] <durandal_1707> saste: ping
[18:58:54 CET] <saste> durandal_1707, pong
[18:59:35 CET] <durandal_1707> saste: have done anything new regarding scripting in lavfi?
[18:59:52 CET] <saste> durandal_1707, no
[19:00:08 CET] <TD-Linux> isn't that basically vapoursynth?
[19:00:27 CET] <saste> durandal_1707, I propose to create a GSoC for that, it's unlikely that I'll find the time to do it myself
[19:00:42 CET] <atomnuker> yeah, that's basically vapoursynth
[19:01:03 CET] <saste> it's not only about filtering, it's also about scripting all operations
[19:01:40 CET] <durandal_1707> I'm doing it inside lua
[19:01:48 CET] <atomnuker> yes, do it, Lua is awesome
[19:01:51 CET] <saste> for example i could want to send an event to a remote server when a transcoding operation finishes
[19:01:59 CET] <saste> lua looks like a good choice
[19:02:08 CET] <TD-Linux> I mean, adding an API to step the filter graph by frame and reconfigure it might be neat
[19:03:59 CET] <durandal_1707> some filters don't work/conflict with this, they keep local cache of stuff, so I need to find way how to handle it
[19:04:26 CET] <TD-Linux> but I don't see why you'd put the scripting language interpreter itself in ffmpeg
[19:06:09 CET] <durandal_1707> I put it into filter
[19:52:55 CET] <nevcairiel> jamrial: so i am having the weirdest error, calling avcodec_flush_buffers on the new dca decoder somehow causes playback to go completely foobar for me, and I have no clue wtf it might be doing that could ever cause this
[19:53:28 CET] <nevcairiel> i neven weirder news, it does not happen when compiled with msvc =p
[19:53:54 CET] <jamrial> haha
[19:54:07 CET] <jamrial> did you try another gcc version, like 4.9?
[19:54:20 CET] <nevcairiel> not yet
[19:54:33 CET] <nevcairiel> i am trying to cmment out a variety of the flush code
[19:55:21 CET] <nevcairiel> unfortunately i dont think fate tests this
[19:56:12 CET] <jamrial> a seek test might
[19:56:27 CET] <nevcairiel> seems like erase_adpcm_history in core_flush causes it
[19:57:34 CET] <jamrial> AV_ZERO128?
[19:57:51 CET] <jamrial> is this x86_32? it might need an emms_c
[19:57:58 CET] <nevcairiel> yes it is
[19:58:11 CET] <jamrial> try adding one
[19:59:50 CET] <nevcairiel> hm yeah it uses mmx regs there
[20:00:04 CET] <nevcairiel> dangerous macro this one
[20:00:26 CET] <jamrial> the header warns about it, though
[20:01:23 CET] <nevcairiel> all other users are video codecs
[20:01:26 CET] <nevcairiel> lets try
[20:01:51 CET] <nevcairiel> that might explain the totally incomprehensible results i got
[20:02:10 CET] <nevcairiel> yeah that fixes it
[20:02:13 CET] <jamrial> and why it didn't happen with msvc
[20:02:15 CET] <jamrial> no inline asm there
[20:02:18 CET] <nevcairiel> indeed
[20:02:22 CET] <jamrial> \o/
[20:04:21 CET] <nevcairiel> i suppose i could just push that, no need to go to the ML and get an ok from you is there =p
[20:04:42 CET] <nevcairiel> http://pastebin.com/jjyqSxFE
[20:05:27 CET] <jamrial> looks good
[20:12:18 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:0b1972d4096d: dca: add emms_c after AV_ZERO128 macros
[20:41:04 CET] <nevcairiel> jamrial: what ever happened to the float dsp fix? I had it fail again just now
[20:43:42 CET] <nevcairiel> float_dsp-test: random seed 2323630816
[20:43:42 CET] <nevcairiel> 96: -34.500125914490 - -34.500125914490 = -7.1054273576e-015
[20:43:43 CET] <nevcairiel> :(
[20:54:50 CET] <jamrial> never really sent the fix to the ml since i'm not sure if it's correct. or correct-er than the current check
[20:55:26 CET] <jamrial> it at least fixed that one seed i tested back then
[21:01:58 CET] <jamrial> nevcairiel: http://pastebin.com/n8p18db5 seems to fix this seed as well
[21:05:34 CET] <nevcairiel> i'm slightly confused what the patch really does, it seems a rather long way to write a float comparison =p
[21:06:53 CET] <nevcairiel> the inaccuracy scales with the size of the number?
[21:07:36 CET] <nevcairiel> because that would move the precision away from the low digits, i guess
[21:09:06 CET] <jamrial> i'm not sure either! that's essentially the result of a google search for how to compare floats while having the least amount of innacurate results as possible :p
[21:10:28 CET] <jamrial> the current check also fails with seed 2323630821
[21:10:58 CET] <nevcairiel> suspiciously close to my number
[21:12:08 CET] <jamrial> yes, and the one seed that failed a few weeks ago was 2331579809
[21:12:38 CET] <nevcairiel> what does it seed these with, unix time
[21:13:16 CET] <jamrial> on windows it uses CryptGenRandom
[21:13:34 CET] <nevcairiel> hm indeed
[21:13:52 CET] <nevcairiel> if that works, that is
[23:09:14 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07n2.5.11:HEAD: dca: add emms_c after AV_ZERO128 macros
[23:19:06 CET] <jamrial> nevcairiel: dca_core also uses AV_COPY128, so i guess we should add emms_c there as well
[23:19:34 CET] <jamrial> wonder why they didn't break playback for you, though
[23:19:55 CET] <nevcairiel> the two i fixed were  in dca_core
[23:20:04 CET] <nevcairiel> the only two outside of video decoders
[23:21:18 CET] <jamrial> i mean, wonder why the two av_copy128 didn't break for you like the two av_zero128 did
[23:21:25 CET] <nevcairiel> oh copy
[23:21:28 CET] <nevcairiel> lets see
[23:22:21 CET] <jamrial> oh, maybe they didn't because av_copy128 also has an sse version
[23:22:35 CET] <nevcairiel> ah yeah
[23:22:40 CET] <nevcairiel> should still add it though
[23:22:44 CET] <jamrial> and you're compiling your x86_32 build with -msse
[23:22:47 CET] <jamrial> yeah
[23:24:18 CET] <jamrial> wonder why av_zero128 is written in sse2. like av_copy128 it could just use xorps and movaps
[23:25:13 CET] <wm4> I have a user who reports a strange playback breakage with the new decoder, but the emms thing doesn't fix it (neither does --disable-asm)
[23:26:30 CET] <jamrial> wm4: we're still missing a couple emms, so it could be that.
[23:26:57 CET] <nevcairiel> interestingly my usual test builds of ffmpeg are not with -msse and those didnt fail
[23:28:30 CET] <jamrial> they neither have -mmmx
[23:28:35 CET] <nevcairiel> hm right
[23:28:40 CET] <nevcairiel> that makes sense
[23:28:43 CET] <jamrial> default march is i686
[23:30:03 CET] <cone-623> ffmpeg 03Hendrik Leppkes 07master:5fc310f7ca2a: dca: add emms_c after usage of AV_COPY128
[23:30:11 CET] <nevcairiel> use of those macros seems rather silly
[23:30:22 CET] <nevcairiel> but shrug
[23:32:41 CET] <jamrial> memset/memcpy probably couldn't be used in those cases. he does use them elsewhere after all
[23:33:07 CET] <nevcairiel> smells like micro-optimization to me
[23:33:29 CET] <nevcairiel> happens to be 16 byte or something, just use the macro
[23:34:22 CET] <jamrial> well, a single emms call after the loop is going to be considerably faster than several memset/memcpy calls inside the loop anyway :p
[23:34:45 CET] <nevcairiel> maybe a compiler would optimize a memcpy of a small defined size
[23:37:25 CET] <nevcairiel> but yeah, emms_c might look kinda ugly there, but doesnt do any harm in some generic code
[23:44:49 CET] <jamrial> nevcairiel: a memcpy with a size of 16 is indeed optimized if -msse is used, but not with -mmmx
[23:47:07 CET] <wm4> anyway, I made the user add emms after the decoder returns, and it's still broken, so my problem is probably something else
[23:47:24 CET] <nevcairiel> can you describe the problem somehow?
[23:47:38 CET] <nevcairiel> the emms problem was rather... crazy
[23:48:06 CET] <nevcairiel> not sure it would have occured to me quickly if jamrial hadn't said something about it
[23:48:47 CET] <nevcairiel> when everything starts misbehaving and you dont see how it could ever do that, you sit there puzzled for a bit
[23:49:39 CET] <jamrial> only reason i knew it could be that was because not too long ago i toyed with the idea of adding an av_zero/copy256 using avx and saw the warning about mmx :p
[23:49:50 CET] <wm4> nevcairiel: just getting mysterious A/V desync, which I thought might be a problem with FPU state getting messed up
[23:50:00 CET] <nevcairiel> ah avx would have similar crazyness indeed
[23:50:04 CET] <nevcairiel> at least on ymm
[23:50:40 CET] <jamrial> yeah, basically each call would need a vzeroupper and probably kill any performance gain compared to sse
[23:51:41 CET] <nevcairiel> wm4: if you are on 64-bit, none of this mmx code would ever execute, just fyi, since it has sse(2) variants then, since most linux users are on 64-bit i would wager
[23:52:16 CET] <wm4> I for one can't reproduce this problem anyway
[23:52:46 CET] <jamrial> and if he's using x86_32, make him test with current git head, to see if the latest emms patch fixes it for him
[23:53:00 CET] <nevcairiel> in my case, the messed up fpu caused the playback rate to go bananas, screwing with everything
[23:53:16 CET] <nevcairiel> sound was garbled and video was practically frozen =p
[00:00:00 CET] --- Wed Feb  3 2016