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

[burek]

[00:11] <cehoyos> BadClown: Samples are always welcome, you can just send an email to the user mailing list.
[00:38] <cehoyos> kierank, thardin: Do your players show a correct ratio for the sample from ticket 4107? http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4107/
[00:38] <kierank> I don't have any player
[00:38] <kierank> but it's probably avci-50 where the SAR is wrong
[00:38] <kierank> you have to "fix" it and make it 4:3
[00:40] <cehoyos> Do you mean it is wrong in the file?
[00:40] <cehoyos> Or in the extradata we add?
[00:40] <cehoyos> It also shows incorrectly if I remove the code that adds extradata.
[00:54] <kierank> it's wrong in the file at least
[00:55] <kierank> probably also in the extradata
[00:55] <cehoyos> kierank: I just looked in the mxf header and it sets dar to 16:9
[00:55] <kierank> yeah but the avc SAR is 3:4
[00:55] <cehoyos> Is it likely that this is how it is meant to be read: codec SAR is wrong, container DAR is what should be used?
[00:56] <kierank> no
[00:56] <kierank> it's just a mistake in the encoder
[00:56] <cehoyos> So (as you already explained to me months ago) the SAR in the H264 stream is really set to 3:4, there is nothing to be fixed?
[00:56] <kierank> either you respect the container or you detect it's avci-50 and "fix" the sar
[00:56] <kierank> or both
[00:56] <cehoyos> But generally, we prefer the container aspect over the codec aspect, to this should still be played correctly.
[00:57] <cehoyos> Unfortunately, DAR is useless for avcodec context...
[00:57] <cehoyos> Or AVStream in this case.
[00:57] <cehoyos> You mean AVC-50 has always SAR=4:3?
[00:58] <cehoyos> AVCI-50
[01:11] <kierank> it shoul
[01:11] <kierank> d
[01:52] <cone-979> ffmpeg.git 03Vittorio Giovara 07master:4b39cc1a093c: riff: support ProRes in avi (APCN fourcc)
[01:52] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:720a8d2b7518: Merge commit '4b39cc1a093c239412ded522c4a899744e7f2008'
[01:54] <cone-979> ffmpeg.git 03Thilo Borgmann 07master:e4cb6abb2f46: bgmc: fix sizeof arguments
[01:54] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:ac1735e76dc9: Merge commit 'e4cb6abb2f46910c72178e2f987a0198f0fd10b1'
[02:00] <cone-979> ffmpeg.git 03Vittorio Giovara 07master:3a6ddfb8745e: exr: check return value
[02:00] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:a5adeff45745: Merge commit '3a6ddfb8745e4b306a5637927fb057f630345e2f'
[02:13] <cone-979> ffmpeg.git 03Vittorio Giovara 07master:60e0ee7ca25b: lpc: always initialize ref and err
[02:13] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:d4065a9f4755: Merge commit '60e0ee7ca25bd3bea54043b0607efe4cd51acaf3'
[02:13] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:85929b9caa90: avcodec/lpc: remove unneeded {}
[02:26] <cone-979> ffmpeg.git 03Vittorio Giovara 07master:d16ec1b6db25: atrac3plus: always initialize refwaves
[02:26] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:53ab7846eeb6: Merge commit 'd16ec1b6db25bc348b0d4800c9a0c9b7070e3710'
[02:44] <cone-979> ffmpeg.git 03Kieran Kunhya 07master:2e1704059ae8: vf_interlace: Add SIMD for lowpass filter
[02:44] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:6f373d75e892: Merge commit '2e1704059ae8625beda2ffde847ad22c5ba416dc'
[02:51] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:05e0ea60507d: avfilter/vf_tinterlace: Fix output top field first flag for MODE_INTERLACEX2
[02:51] <cone-979> ffmpeg.git 03Mark Reid 07master:933eca91e605: libavformat/mxfdec.c: refactored resolving timecode component
[04:18] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:f043965cd514: avfilter/vf_tinterlace: fix linesize vs. width
[04:18] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:9d548fce2405: avfilter/tinterlace: split context definition into seperate header so it can be used by future optimizations
[04:18] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:18b46ecc93bf: avfilter/tinterlace: Move lowpass_line to a separate function and call it through a function pointer
[04:18] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:fb3eb573699e: avfilter/tinterlace: add Support for ff_lowpass_line_avx() & ff_lowpass_line_sse2()
[04:18] <cone-979> ffmpeg.git 03Michael Niedermayer 07master:05e4b25e9b0a: avfilter/x86/vf_interlace: rewrite asm
[10:03] <funman> /usr/bin/ld: /usr/local/lib/libavcodec.a(hevc_cabac.o): relocation R_X86_64_PC32 against symbol `ff_h264_cabac_tables' can not be used when making a shared object; recompile with -fPIC
[10:03] Action: funman finds ticket 17143
[10:03] <funman> 1713*
[11:51] <cone-398> ffmpeg.git 03Marvin Scholz 07master:3a6bb9735053: Icecast: Send 100-continue header if possible
[11:51] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:f3c324a0fefd: Merge commit '3a6bb9735053c453f806ceab1d91124648d90aca'
[12:04] <cone-398> ffmpeg.git 03Marvin Scholz 07master:8562c1483ba6: Icecast: Send content-type in all cases
[12:04] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:42c8db69b686: Merge commit '8562c1483ba647f562e4c1df68a9231274b80e6b'
[12:12] <cehoyos> Daemon404: Hi, any news about ffmpeg -i output for the Prores sample? Thank you.
[12:12] <cone-398> ffmpeg.git 03Mika Raento 07master:b08fd7ea7879: mov.c: fix handling of seek return in read_mfra
[12:32] <cehoyos> The following sample plays with gray bars with FFplay but black bars with vlc:
[12:32] <cehoyos> http://streams.videolan.org/issues/12764/Test_mov_MJPEG_pcm_s24be_320x240_3151Kbps_24fps.mov
[12:32] <cehoyos> Which one is correct?
[12:40] <Compn> whatever quicktime says is correct :P
[12:42] <cehoyos> Could you test?
[12:46] <relaxed> I'm at work and Windows 7/WMP shows black bars, for what it's worth.
[12:47] <cehoyos> Thank you!
[12:51] <cone-398> ffmpeg.git 03Shin-ichi Toyama 07master:12630fa821ea: avcodec/dvdsubdec: New option for obtaining global palette from .IFO file (experimental)
[13:13] <kierank> michaelni: what's the point of pxor m0, m6 ?
[13:17] <kierank> oh m6 is now all 1
[13:22] <cehoyos> relaxed: Does wmp play this file? http://streams.videolan.org/issues/12767/Test_mov_h261_pcm_s16le_352x288_251Kbps_15fps.mov
[13:22] <cehoyos> It shows many error messages with FFmpeg.
[13:22] <cehoyos> Or QT?
[13:29] <cehoyos> j-b: Can you provide the sample for videolan ticket 12768 ?
[13:31] <cehoyos> I would also like to test 12770
[14:40] <cone-398> ffmpeg.git 03Brandon Lees 07master:ffaf2074ebbc: Fix the timeout option not working when connecting to a HTTP url that requires authentication.
[14:41] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:deccb4d827d6: avformat/http: simplify chained_options copying
[14:44] <relaxed> cehoyos: sorry, I'm no longer at work.
[15:39] <wm4> funny, with a ffmpeg produced file, seeking in ffplay will print [mpeg4 @ 0x7fffd80015e0] Failed to parse extradata
[15:45] <kierank> why does this happen?
[15:45] <kierank> http://pastie.org/private/31z6minb9clhjusookmgrg#13
[15:46] <kierank> ah --disable-avformat does the trick
[16:01] <cehoyos> keirank: Are you searching for --disable-network or --disable-all?
[16:03] <cehoyos> You can do "--enable-filter=drawtext,format,interlace" since several years
[16:04] <cehoyos> Do you really have mp1 samples? There were difficult to find iirc...
[16:06] <cehoyos> kierank: Are you searching for --disable-network or --disable-all?
[16:07] <kierank> cehoyos: all broadcast audio is mp1
[16:48] <cehoyos> kierank: Is this audio that is sent to TV stations for broadcast? Or do I misunderstand?
[16:49] <kierank> in all the channels I transmit they are MPEG 1 Layer II
[16:49] <kierank> as opposed to MPEG 2 Layer II
[16:49] <kierank> which is for 32khz and below iirc
[16:51] <cehoyos> But MPEG1 Layer II == "mp2" in FFmpeg terms
[16:51] <cehoyos> "mp1" is MPEG1 Layer I
[16:51] <cehoyos> Which you are enabling in your configure line and for which we have one sample iirc
[16:51] <kierank> ah
[16:52] <cehoyos> And I believe --disable-all will make your configure line simpler
[16:52] <cehoyos> --disable-everything is more a debug tool to make bisecting faster
[16:53] <cehoyos> wm4: Does mpv play this sample? http://streams.videolan.org/issues/12767/Test_mov_h261_pcm_s16le_352x288_251Kbps_15fps.mov
[16:54] <kierank> cehoyos: ah possibly I've always been looking for --disable-all
[17:00] <wm4> cehoyos: as "well" as ffplay
[17:08] <j-b> aka, not well
[17:08] <cehoyos> It works fine here with ffplay, only MPlayer fails...
[17:09] <j-b> fine?
[17:09] <j-b> you don't have the grey bar?
[17:09] <cehoyos> j-b: Do you have samples for tickets 12768 and 12770?
[17:09] <cehoyos> Yes, the same grey bar as for every mov file with cropping.
[17:09] <cehoyos> But MPlayer fails completely
[17:09] <wm4> cehoyos: in ffplay I see black borders which don't seem to belong there, and " qscale has forbidden 0 value" is spammed
[17:10] <wm4> and a grey bar
[17:10] <j-b> cehoyos: 770 is 2GB, so no way to upload it.
[17:10] <j-b> 768, yes, I do.
[17:10] <j-b> and for me 767 is annoying because I have seen no player playing it correctly
[17:10] <j-b> so either the sample is broken, or everyone is based on ffmpeg
[17:11] <cehoyos> I don't understand: You can use mplayer -vc -ffh261,
[17:13] <cehoyos> But was is incorrect with libavcodec?
[17:21] <JEEB> is that 767 like http://www.cccp-project.net/beta/test_files/h263_adpcm_lolborders.mov ?
[17:21] <JEEB> grey bars and mov reminded me of this
[17:22] <wm4> yes, exactly
[17:22] <rcombs> lolborders
[17:24] <Compn> seen lots of files like that, mostly h263
[17:27] <wm4> so how are they cropped?
[17:38] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:18fcdc098162: avcodec/mpeg4videodec: forward return code in ff_mpeg4_decode_picture_header()
[17:38] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:10411afdff10: avcodec/mpeg4videodec: replace some return -1 by more specific error codes
[17:38] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:7d37e45f6bac: avcodec/mpeg4video_parser: fix spurious extradata parse warnings
[17:59] <j-b> JEEB: yes, same lolborder
[18:23] <Compn> wm4 : the video file (not sure if both container and codec) has metadata that says crop x:y , and the player is supposed to do it automatically
[18:23] <Compn> probably i misunderstood the question :P
[18:25] <Daemon404> [16:27] <+wm4> so how are they cropped? <-- at work we have a special check for them, and crop if need be.
[18:25] <Daemon404> pure class.
[18:25] <j-b> Daemon404: how?
[18:25] <Compn> i'd guess dump crop metadata, have script pass -vf cropdetect to ffmpeg
[18:25] <Daemon404> mediainfo provides "original" and "cropped" res for it
[18:25] <Daemon404> abs(orig-cropped)==1
[18:27] <Compn> s/cropdetect/crop
[18:27] <j-b> interesting
[18:27] <Compn> derp
[18:27] <j-b> is it in the mp4 format?
[18:27] <Daemon404> mov or mp4 or some bastardization of it yes
[18:38] <rcombs> if the codec has that meta, I'd expect it to be done at the decoder level
[18:38] <cehoyos> Daemon404: any news about the Prores sample?
[18:38] <Daemon404> no
[18:39] <Daemon404> rcombs, ffmpeg makes the decision to not crop it
[18:39] <Daemon404> cause it is yv12
[18:39] <Daemon404> and this returning an extra line is deemed better than one too few
[18:39] <Daemon404> (since it was originally an odd number of lines)
[18:39] <j-b> rcombs: that was my question. Is the codec or the demux aware?
[18:39] <wm4> what's the problem with cropping the right/bottom borders
[18:39] <rcombs> j-b: dunno, I'm just expressing expectations
[18:39] <Daemon404> wm4, you lose one legitimate line
[18:39] <Daemon404> technically.
[18:40] <wm4> lavc can return odd width/height with jpeg and 4:2:0
[18:40] <Daemon404> well i dunno why h263 or avc doesnt then
[18:41] <JEEB> <j-b> is it in the mp4 format? <- I think it's another resolution noted in the container or so
[18:42] <Daemon404> i think it might be noted in the bitstream
[18:42] <Daemon404> but dont quote me.
[18:42] <JEEB> I remember looking into it once
[18:42] <JEEB> basically it's a flag in mov to scale the picture to that res
[18:42] <JEEB> but yes, it's lavc doing it
[18:42] <JEEB> since it gets the data as the resolution and starts decoding the picture into it
[18:42] <JEEB> which is why you get grey
[18:43] <JEEB> boxdumper will probably tell you moar
[18:43] <JEEB> because what QT does is take the actual picture and scale it to that size
[18:44] <Daemon404> qt crops the line off
[18:44] <JEEB> lavc will take the resolution as a resolution, and then decode into it a smaller picture
[18:44] <Daemon404> not scale
[18:44] <JEEB> lemme find the comparison pic for my file
[18:45] <Daemon404> right now im trying to find out something for mp4 that i *havent* solved yet
[18:45] <Daemon404> i.e. how the shit do i detect the ios6 "slo-mo" shit in mp4/mov
[18:45] <Daemon404> QT can
[18:45] <Daemon404> boxdumper had nothing stand out to me
[18:45] <JEEB> http://i4.minus.com/iyF0ALNoDz61c.png
[18:46] <Daemon404> JEEB, i usually only see 1px
[18:46] <JEEB> so it's cropping and scaling
[18:46] <JEEB> it would seem
[18:46] <JEEB> because the AR is clearly different
[18:46] <Daemon404> who needs NLE project files?
[18:46] <Daemon404> just use ALL OF THE MOV FEATURES
[18:47] <JEEB> :D
[18:47] <wm4> why is mov so terrible
[18:47] <Daemon404> the idea of atoms/boxes itself is pretty sane
[18:47] <Daemon404> the spec is insane though
[18:47] <Daemon404> well specs.
[18:47] <Daemon404> and Way Too Much STuff
[18:48] <Daemon404> still. ill take boxes/atoms over EBML any day.
[18:48] <wm4> ebml isn't much different after all...
[18:48] <JEEB> Yeah, the Way Too Much Stuff is the real problem
[18:48] <JEEB> no-one read it properly
[18:48] <Daemon404> vague-as-hell specs dont help
[18:49] <wm4> and at least matroska has a proper concept of interleaving
[18:49] <JEEB> and you need to read X,Y,Z specs to implement shit properly
[18:49] <Daemon404> specs that are fragmented over like 100 different specs
[18:49] <Daemon404> all of which cost like 200chf each
[18:49] <JEEB> yup
[18:49] <Daemon404> well at least there are specs
[18:49] <Daemon404> i guess
[18:49] <JEEB> yeh
[18:49] Action: Daemon404 stares at mkv
[18:50] <JEEB> maybe I should reopen that one document I had on "marumoska"
[18:50] <j-b> [qcelp @ 0x7f8040c5c660] Frame #1, IFQ: bitrate cannot be determined.
[18:50] <cehoyos> JEEB: I suspect for your sample the mov container sets the display size (as done for many other samples), the sample in question does not contain such data afaict.
[18:50] <JEEB> k
[18:50] <JEEB> you can check with boxdumper
[18:50] <JEEB> comes from the L-SMASH project
[18:50] <JEEB> https://github.com/l-smash/l-smash
[18:51] <JEEB> a convenient way of getting a text dump of an mp4/mov/whatever file
[18:51] <cehoyos> Is your sample publically available?
[18:51] <Daemon404> he linked it above iirc
[18:51] <JEEB> <JEEB> is that 767 like http://www.cccp-project.net/beta/test_files/h263_adpcm_lolborders.mov ?
[18:51] <JEEB> <JEEB> grey bars and mov reminded me of this
[18:51] <Compn> do we have a slowmo sample ?
[18:51] <cehoyos> Daemon404: Can you copy the line?
[18:52] <Compn> i saw that on the teeeveee but never saw a sample of it...
[18:52] <cehoyos> Compn: The ticket is only missing the necessary info, sample is available.
[18:52] <Compn> cehoyos : which ticket is for slowmo sample ?
[18:54] <cehoyos> JEEB: The tkhd atom contains all necessary information, no problems here
[18:54] <cehoyos> the h261 sample may not contain the nececssary info, did anybody test with QT?
[18:54] <JEEB> k
[18:54] <cehoyos> Compn: Search for a "new" important ticket (a regression)
[18:54] <Daemon404> [17:51] <@cehoyos> Daemon404: Can you copy the line? <-- ?
[18:54] <Daemon404> i dont follow
[18:54] <Daemon404> Compn, yes. anyone with an iphone can also make one
[18:54] <cehoyos> I missed the lolborders sample link.
[18:54] <Daemon404> it's an OS feature
[18:55] <cehoyos> Not necessary, we already have a sample for this regression.
[18:57] <j-b> the mediainfo informations are not enough for crop
[18:57] <Compn> cehoyos : http://www.cccp-project.net/beta/test_files/h263_adpcm_lolborders.mov 
[18:57] <cehoyos> I have it three times now, thank you all!
[18:57] <Compn> lol
[18:58] <Compn> :)
[18:58] <cone-398> ffmpeg.git 03Arwa Arif 07master:a2f05d33373e: lavfi : change xBR filter to LGPL
[18:59] <Daemon404> Width                                    : 320 pixels
[18:59] <Daemon404> Original width                           : 352 pixels
[18:59] <Daemon404> Height                                   : 230 pixels
[18:59] <Daemon404> Original height                          : 288 pixels
[18:59] <Daemon404> that looks like enough info to crop, j-b 
[18:59] <Daemon404> (from JEEB's sample)
[18:59] <Daemon404> it's always bottom and right.
[19:03] <cehoyos> Daemon404: Any news about the ProRes sample? The patch looks very bad to me.
[19:03] <Daemon404> you asked about 3 times today
[19:03] <Daemon404> i replied already
[19:04] <Daemon404> [17:38] <@cehoyos> Daemon404: any news about the Prores sample?
[19:04] <Daemon404> [17:38] <@Daemon404> no
[19:04] <cehoyos> So where can I find the information?
[19:04] <Daemon404> what?
[19:04] <cehoyos> I thought two hours are sufficient to test one sample, sorry!
[19:04] <Daemon404> ...
[19:04] <Daemon404> the problem is not testing
[19:04] <Daemon404> it's GETTING it
[19:04] <Daemon404> it's sitting on a coworker's pc
[19:04] <cehoyos> I thought you know somebody who has it?
[19:04] <Daemon404> because the user deletec the original
[19:04] <Daemon404> yes and people tend to be away
[19:04] <Daemon404> and busy
[19:04] <Daemon404> on weekends
[19:04] <Daemon404> GO FIGURE
[19:04] <cehoyos> Actually who you gave it to, iiurc.
[19:05] <j-b> Daemon404: sure, but try the sample from the ticket
[19:05] <j-b> it says 180x
[19:05] <j-b> but if you crop 180x you loose half the picture
[19:05] <cehoyos> j-b: Does it work with QT?
[19:05] <Daemon404> cehoyos, what?
[19:06] <cehoyos> What what?
[19:06] <j-b> cehoyos: not for me
[19:06] <cehoyos> So the sample was either remuxed or is supposed to by played as vlc does currently?
[19:06] <Daemon404> [18:04] <@cehoyos> Actually who you gave it to, iiurc. <-- i dont follow
[19:06] <j-b> the lolborder one is correct
[19:06] <cehoyos> Or do you mean it does not play at all?
[19:07] <j-b> the one reprocessed by lavf is butchered, of course
[19:07] <cehoyos> Of course, vlc reads the tkhd atom.
[19:07] <j-b> it's lavf
[19:07] <cehoyos> No?
[19:08] <cehoyos> With --demux=ffmpeg, the sample plays incorrectly, with default demuxer it work fine.
[19:08] <cehoyos> Or do I misunderstand?
[19:09] <j-b> for me, in VLC all are wrong
[19:10] <j-b> using l-smash, lavf, or our demuxer
[19:10] <cehoyos> If I play h263_adpcm_lolborders.mov it works fine with vlc: The borders are correctly cropped.
[19:10] <j-b> cehoyos: wut?
[19:10] <j-b> cehoyos: indeed, works in 2.1
[19:11] <Daemon404> j-b, since when does vlc have l-smash support
[19:11] <cehoyos> Why shouldn't it: This was always a feature of vlc missing in (for example) ffplay
[19:11] <j-b> Daemon404: :D
[19:11] <cehoyos> Reading tkhd display resolution.
[19:11] <j-b> Daemon404: I did not say anything
[19:12] <Daemon404> j-b, i am an l-smash API user as well, FWIW
[19:12] <Daemon404> ;)
[19:17] <j-b> cehoyos: thanks a lot. It's a VLC 2.2.0 regression.
[19:18] <cehoyos> Can you add any information about 12768? Is it reproducible with FFmpeg?
[19:18] <j-b> not before monday
[19:18] <j-b> and yes, it was tested with FFmpeg.
[19:18] <cehoyos> So it crashes FFmpeg?
[19:19] <j-b> yessir
[19:20] <cehoyos> From your pov, how is FFmpeg supposed to know about such issues?
[19:22] <j-b> no idea.
[19:22] <j-b> when someone reports the bug
[19:22] <Compn> lol ;D
[19:22] <cehoyos> Ok, I read the bug report and I requested the sample: What else should I do?
[19:22] <cone-398> ffmpeg.git 03Luca Barbato 07master:74d7db586a2e: dv: Drop a spurious check
[19:22] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:89e705cd5c94: Merge commit '74d7db586a2e9aeb107e357739c7e4dde0b6991c'
[19:22] <j-b> wait for me to upload it?
[19:22] <j-b> and test again HEAD
[19:22] <Compn> cehoyos : wait monday and j-b will upload it with more info
[19:22] <cehoyos> What kind of into?
[19:23] <j-b> cehoyos: there are other bug reports, lately reported that are still reproduced on HEAD
[19:23] <Compn> gdb i assume
[19:23] <cehoyos> Could you point me to one you mean?
[19:25] <ubitux> michaelni: why is that message still in copyright boilerplate? (xbr)
[19:26] <ubitux> arwa: just saw your messages; you were looking for guidance for mp filters?
[19:27] <cehoyos> arwa: Here are two commits from ubitux which should help with porting uspp and fpss: 
[19:27] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=a2c547ff
[19:27] <arwa> yeah
[19:27] <cehoyos> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=852f74bd
[19:27] <cehoyos> fspp
[19:28] <ubitux> so we're really going to port uspp and fspp?
[19:28] <Daemon404> ubitux, well people refuse to delete the mplayer shim until theyre ported
[19:28] <Daemon404> so clearly someone thinks theyre Very Important
[19:28] <ubitux> i see 2 problems for each of them
[19:29] <ubitux> fspp is basically a simpler version of spp which is faster, but i wonder if it's any relevant nowadays
[19:29] <ubitux> and uspp has a libavcodec dependency
[19:30] <Daemon404> dont other things in lavfi have that too
[19:30] <ubitux> which is technically not really a problem but it needs to be considered
[19:30] <ubitux> yeah sure
[19:30] <ubitux> i think uspp is the simpler to port though
[19:31] <michaelni> ubitux, because it was in the patch and maybe someone reading it wonders why its LGPL when the code its based on was GPL
[19:31] <cehoyos> I think Reimar commented on fspp several times already.
[19:31] <michaelni> iam perfectly fine with remocing it
[19:31] <ubitux> michaelni: well it's in the commit message...
[19:31] <cehoyos> uspp has been requested a few times.
[19:31] <ubitux> michaelni: yeah i think that would be better
[19:32] <cehoyos> arwa: I believe the eq and eq2 filters are more difficult to port (but I may be wrong), a patch exists though.
[19:32] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:2fa6d21124bd: on2avc: Fix out of array access
[19:32] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:dcb10ef9bff3: Merge commit '2fa6d21124bd2fc0b186290f5313179263bfcfb7'
[19:32] <ubitux> no they're not "hard" actually
[19:32] <ubitux> the problem is how consistently we can integrate them
[19:32] <ubitux> saste: ping
[19:33] <ubitux> J_Darnley: ping too, how is eq/eq2 going?
[19:33] <ubitux> anyway, i can give guidance for the uspp port
[19:33] <saste> ubitux, pong
[19:33] <ubitux> saste: remember what was decided for eq/eq2?
[19:34] <ubitux> like how to merge them into one feature wise etc?
[19:35] <ubitux> btw, unrelated but we need something in the documentation to compare all the pp filters
[19:36] <ubitux> because no user is ever going to understand why we have pp, spp, fspp, uspp, ...
[19:37] <saste> ubitux, yes
[19:38] <saste> about eq/eq2, I remember some comments from paul
[19:38] <Compn> >why anyone cares about mplayer code in ffmpeg anyhow
[19:38] <saste> also, you mentioned that J_Darnley was working on that
[19:38] <saste> between the missing filters, I agree eq/eq2 seems the most useful
[19:39] <arwa_> So is my task is to port eq/eq2 filters?
[19:39] <saste> arwa_, when do you plan to start with your project? OPW program will officially start in December
[19:40] <saste> arwa_, we're discussing what filters we should port
[19:40] <ubitux> can we start a coop edit document of some sort to summarize the state of each remaining filter to port?
[19:41] <arwa_> I have exams in a week, I will not be able to do much work. But at least I can get some idea.
[19:42] <ubitux> so here is the thread for eq/eq2: http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-September/162930.html
[19:42] <saste> ubitux, i was thinking about the same thing
[19:44] <ubitux> current state for eq/eq2 @ http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2014-September/163005.html
[19:45] <ubitux> kierank: about mp=ilpack, so is swscale able to do what you want now?
[19:45] <ubitux> (and if so... how?)
[19:45] <kierank> not 100% sure but I'll find out in the next few weeks
[19:45] <kierank> it is on my todo list to write an interlaced upsampler
[19:45] <ubitux> ok so ilpack in stand-by
[19:47] <ubitux> softpulldown in standby? http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143262.html
[19:48] <ubitux> so uspp is a requested pp filter, using lavc/snow and no asm; could be ported relatively easy but needs some serious cleanup
[19:49] <ubitux> pp7: no comment.
[19:49] <wm4> state of the art in 2001
[19:49] <ubitux> thread about pp7 & fspp http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-June/144740.html
[19:50] <ubitux> and... done?
[19:51] <Compn> wm4 : should vaporsynth be ported to ffmpeg then ? :)
[20:04] <akira4> ubitux, done with my tests (for now atleast). Are you free now ?
[20:04] <ubitux> akira4: sure
[20:04] <akira4> right. So where do we start?
[20:05] <ubitux> mmh first, since i have no idea how the dvd libs work, maybe you should start figuring that out
[20:05] <ubitux> akira4: cehoyos told me that libdvdnav is probably what we should look for instead of libdvdread
[20:06] <akira4> oh. Also what about the dvdsubdec.c in libavcodec?
[20:06] <ubitux> this is the dvd subtitles decoder, but we're interesting in the demuxing part
[20:06] <ubitux> like, extracting the undecoded "chunks" out of dvds
[20:07] <ubitux> (is freenode drunk again or...?)
[20:07] <akira4> hmm. The patch you told me look into uses libdvdnav I think.
[20:07] <ubitux> ah, well then you should probably use that
[20:08] <ubitux> i don't know the relationship between dvdnav and dvdread, but dvdnav probably depends on dvdread
[20:08] <akira4> hmm. Do I need to externally download them?
[20:09] <ubitux> you could get the sources from videolan if you want to look at them
[20:09] <ubitux> but anyway, i guess the first thing would be to port the experimental dvdnav protocol reader as a demuxer
[20:09] <ubitux> do you have dvd images to test?
[20:10] <akira4> nope. couldn't find any :(
[20:10] <akira4> with subtitles I mean
[20:11] <ubitux> mmh, i could give you various copyrighted crap but that might not be wise for now
[20:11] <ubitux> let me check if i find something free
[20:11] <akira4> okay.
[20:14] <cone-398> ffmpeg.git 03Stefano Sabatini 07master:aea7616d39bb: lavfi/xbr: remove relicensing notice from copyright header
[20:22] <ubitux> seems i can't find anything so far
[20:22] <ubitux> damn.
[20:23] <ubitux> ah, found this: https://www.vhsretrostyle.com/creative-commons.html
[20:23] <ubitux> akira4: "Nasty.Old.People_2009.dvd.iso [3.7 GB]"
[20:23] <ubitux> mmh subtitles seems to be external
[20:24] <ubitux> still, it can be useful for now for dvd support
[20:24] <akira4> okay. I'll try testing with it.
[20:26] <akira4> umm ubitux , my university's proxy won't let me download the iso :-/
[20:27] <akira4> I'll try downloading from somewhere else I guess. 
[20:30] <ubitux> akira4: you can't borrow a real dvd from someone?
[20:31] <akira4> I can try. 
[20:40] Action: wm4 still has a dvd image from ubitux 
[20:40] <ubitux> ah? :D
[20:53] <BBB> grrr closed wrong window
[20:53] <BBB> ohwell
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:08bb6f919c0a: avfilter/xbr: do not pass unchanging r2y to macros
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:086487b633de: avfilter/xbr: localize some filtering variables
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:9f9c74177138: avfilter/xbr: avoid unecessary macro redirections
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:55f05ac0f1bf: avfilter/xbr: use different macro names for each dimension
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:e07048404043: avfilter/xbr: simplify width overread checks
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:6bf9786a9bd0: avfilter/xbr: mark source pointers as const
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:18e4bf4f54ca: avfilter/xbr: refactor the 21 pixels definition into a macro
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:7e91f77547b8: avfilter/xbr: refactor src/dst pointers definitions into a macro
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:a3c3ee697398: avfilter/xbr: misc cleanup in FILT[234] macros
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:fda209b74179: avfilter/xbr: simplify left/up conditions
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:a99004a926b3: avfilter/xbr: misc style fixes
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:d1529273fb2f: avfilter/xbr: make xbr[234]x a bit more consistent
[21:07] <cone-398> ffmpeg.git 03Clément BSsch 07master:9a796f7f18e4: avfilter/xbr: consistent copyright header
[21:08] <wm4> spam
[21:08] <ubitux> yeah sorry
[21:08] <ubitux> damn cosmetics
[21:08] <ubitux> still haven't figured a sane way of refactoring the logic of FILT[234] but should be good enough for now
[21:09] <ubitux> maybe i should make a relevant change now
[21:23] <cone-398> ffmpeg.git 03Clément BSsch 07master:c4fb79a3db1a: avfilter/xbr: remove FATE test entry from @todo
[21:23] <cone-398> ffmpeg.git 03Clément BSsch 07master:be96201e5bf1: avfilter/xbr: use function pointers for xbr[234]x
[21:23] <cone-398> ffmpeg.git 03Clément BSsch 07master:454b71428368: avfilter/xbr: add video and filtering flags to options
[22:13] <cone-398> ffmpeg.git 03Michael Niedermayer 07master:bd7d8604bd27: avcodec/nellymoserenc: update comment to match 5c805d69a49a1f32a7a8a1b16fb3d631d85ca56d
[22:16] <cone-398> ffmpeg.git 03Clément BSsch 07master:8bc1553cdb59: avfilter/xbr: add slice threading
[22:16] <ubitux> finally a "useful" commit
[22:16] <ubitux> anyway, back to more relevant stuff
[22:22] <ubitux> oh, not yet. got an idea for a relevant refactoring..
[22:37] <cone-398> ffmpeg.git 03Clément BSsch 07master:bca3c2cfc02c: avfilter/xbr: refactor xbr[234]x into a single function
[22:46] <cone-398> ffmpeg.git 03Clément BSsch 07master:7eece0693424: avfilter/xbr: clarify default "interpolated" pixels assignments
[22:48] <cone-398> ffmpeg.git 03Clément BSsch 07master:77204f7366d4: avfilter/xbr: fix style in FILT4() calls
[22:53] <J_Darnley> ubitux: the progress of eq hasn't gone any futher than in the mailing list message you linked to.
[22:53] <ubitux> J_Darnley: i think it would make sense to have it in "hue"
[22:53] <ubitux> (and that filter probably needs to be renamed)
[22:54] <ubitux> (or aliased)
[22:54] <ubitux> typically, to "levels" or whatever
[22:54] <ubitux> now it's always a bit tricky because of the eval level
[22:54] <ubitux> (to enable optims or not)
[23:27] <db0company> about the [FFmpeg-devel] [PATCH 4/4] web/style.less: Separate out .table-bordered from .table
[23:29] <db0company> I don't really care
[23:29] <db0company> it looks good with or without the border
[00:00] --- Sun Nov 16 2014