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

[burek]

[00:03] <Compn> :)
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:61c68000eda6: avcodec/mjpegdec: Add some sanity checks to ljpeg_decode_rgb_scan()
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:cb026ac30364: avcodec/mjpegdec: make "unknown colorspace" error more informative
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:4ced30908fb7: avcodec/jpeg2000dec: make SOC finding code more robust
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:38f8640df81e: avcodec/mjpegdec: fix yuv ljpeg prediction 5/6/7 with point transforms
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:b394ccfe47e7: avcodec/mjpegdec: fix rgb ljpeg prediction 5/6/7 with point_transform
[01:47] <cone-497> ffmpeg.git 03Michael Niedermayer 07master:b042712a875c: avcodec/mjpegdec: Simplify masking in ljpeg_decode_yuv_scan()
[05:48] <cone-613> ffmpeg.git 03Michael Niedermayer 07release/1.0:e12ada6fd1e5: avcodec/dsputil: fix signedness in sizeof() comparissions
[05:48] <cone-613> ffmpeg.git 03Michael Niedermayer 07release/1.0:11586b077e6e: avfilter/vf_fps: make sure the fifo is not empty before using it
[07:55] <ubitux> heh paul ported w3fdif
[09:13] <ayad_> hello
[09:13] <ayad_> I installed the ffmpeg-1.2, i need to find a command line to get the video with mjpeg and read or optimize with flv/swf
[09:13] <ayad_> thank's to help me 
[09:14] <av500> try #ffmpeg
[10:39] <ubitux> Daemon404: what came out of the vid.stab thing?
[10:39] <ubitux> did you find nice other foss things?
[10:42] <ubitux> i guess i'll port this properly to FFmpeg at some point...
[11:23] <Daemon404> ubitux, no
[12:44] <durandal_1707> ubitux: roll, that error you spotted, that adj was not used at all is present in original code
[12:45] <durandal_1707> so filter is broken in ffmbc for ages
[12:46] <ubitux> did you try it?
[12:46] <ubitux> is the filter suddenly more efficient?
[12:46] <durandal_1707> not yet
[12:47] <durandal_1707> tried with this change....
[12:47] <durandal_1707> but one i tested yadif was slower....
[12:47] <durandal_1707> s/one/when
[12:48] <ubitux> which one was slower?
[12:48] <durandal_1707> yadif
[12:48] <ubitux> ok...
[12:48] <ubitux> is that filter really efficient?
[12:48] <durandal_1707> i used interlace
[12:49] <ubitux> yeah but well, maybe you should use real material
[12:49] <ubitux> captured interlaced
[12:50] <durandal_1707> both filters showed some small artifacts anyway...
[12:56] <durandal_1707> michaelni: i guess gbr(a)p can be added to yadif
[13:29] <durandal_1707> hmm, it probably was slower because i tested yadif=0 but should yadif=1
[13:30] <durandal_1707> yadif=1 is faster, 94 vs 116 for first 900 frames
[13:30] <durandal_1707> this is not much...
[13:32] <durandal_1707> so considering code quality (there was dead code, and it could not work at all correctly with yuv422 - the only format not commented)
[13:32] <durandal_1707> its output looks better than yadif=1
[13:32] <durandal_1707> but i dunno what I should do at start/end
[13:33] <durandal_1707> original one at start set prev/cur/next to first frame
[13:33] <durandal_1707> i picked different approach where I do this at end with last frame
[13:34] <durandal_1707> results it that first few frames are dropped when compared to yadif=1 output
[13:42] <cone-488> ffmpeg.git 03John Stebbins 07master:26b241c0791b: matroskaenc: Allow chapters to be written in trailer
[13:43] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:2230d85cebee: Merge remote-tracking branch 'qatar/master'
[14:03] <durandal_1707> the other question is does w3fdif from ffbmc outputs frame for each field or for each frame?
[14:06] <durandal_1707> also for one sample i have (and interlace applied) yadif shows 'artifact' on first line of first frame
[14:07] <nevcairiel> first frame lacks the previous frame to interpolate against, so its never going to be really perfect
[14:12] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:a67dcd74abd2: avfilter/vf_yadif: add gbr(a)p support
[14:47] <durandal_1707> so is ffmbc dead or what?
[14:53] <av500> is it?
[14:55] <Daemon404> no
[14:55] <Compn> i dont think so
[14:55] <Compn> have to ask bcourduier
[14:55] <Daemon404> [18:19] < baptiste> hey guys
[14:55] <Daemon404> [18:19] < baptiste> mdsh, did you test the rewrapping yet ? :)
[14:55] <Daemon404> [18:19] < baptiste> I need to release rc9
[14:55] <Daemon404> just yesterday
[14:56] <JEEB> yeah, there's an active business around ffmbc
[14:56] <JEEB> so no way it would be dead
[15:00] <durandal_1707> rc7 or 8 was in 2011
[15:01] <Daemon404> what?
[15:01] <Daemon404> it was march 20th 2013
[15:01] <Daemon404> what drugs are you smoking?
[15:01] <Daemon404> sorry, march 13th
[15:01] <nevcairiel> the ffmpeg is based on is just from 2011
[15:01] <Daemon404> thats somethign different
[15:01] <nevcairiel> at least thats what the release notes claim
[15:01] <Daemon404> see the definition of "fork"
[15:14] <durandal_1707> ubitux: have you samples where i could test deint=interlaced?
[15:15] <ubitux> mmh not here
[15:15] <ubitux> i'm not at home
[15:15] <ubitux> i'm sure some ppl here can provide you some real telecined content
[15:16] <ubitux> then you can play with fieldmatch to make it works well or bad, and set a lot of frames interlaced
[15:16] <ubitux> durandal_1707: maybe with vf idet you can try something
[15:25] <durandal_1707> telecine,idet,yadif=deint=1 does funny things
[15:55] <Daemon404> Stream #0:0(und): Video: h264 (High 4:4:4 Predictive) (avc1 / 0x31637661), gbrp(tv, GBR), 1280x720, 286958 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
[15:55] <Daemon404> 1) how is it pssible for rgb to be "tv range"
[15:55] <Daemon404> 2) why does it ignore the actual range parameter in the x264 bitstream
[15:55] <nevcairiel> rgb can also be 16-235 :P
[15:55] <Daemon404> see #2
[15:55] <Daemon404> it says tv for all.
[15:55] <nevcairiel> its uncommon, but people manage to create the weirdest shit
[15:56] <Daemon404> and certainly tv as default is wrong for rgb
[15:56] <durandal_1707> from where its picked? demuxer?
[15:56] <nevcairiel> considering hwo rare rgb in h264 is, its just not a case thats being considered
[15:56] <nevcairiel> but if the bitstream has a range flag, it should be respected
[15:57] <durandal_1707> well if same can be created with ffmpeg, than its bug
[15:57] <Daemon404> durandal_1707, it can
[15:57] <Daemon404> and yes its a bug
[16:02] <durandal_1707> what is this yadif-mod ?
[16:02] <JEEB> the avs filter?
[16:02] <JEEB> I think it just let you use other filters for actual deint or so?
[16:02] Action: durandal_1707 reading: http://casparcg.com/forum/viewtopic.php?t=1113
[16:09] <kierank> Daemon404: because the x264 parameter is usually bullshit
[16:09] <Daemon404> kierank, tv range rgb is a fucking terrible default
[16:09] <Daemon404> and so is ignoring it
[16:10] <kierank> true
[16:10] <kierank> rgb should be full range that's true
[16:10] <JEEB> were there some full rage flagged blu-rays or so?
[16:10] <kierank> probably
[16:10] <kierank> a lot of full range flagged tv broadcasters
[16:11] <JEEB> yes
[16:11] <JEEB> at least blu-ray checking apps usually check for the flag
[16:49] <ubitux> durandal_1707: thx for the deint!
[16:52] <wm4> I thought the original author (who is mentioned nowhere) planned to send a new patch with threading?
[16:53] <ubitux> i only remember some rants from yesterday
[16:54] <nevcairiel> wm4: the author is in the file header in the patch
[16:54] <ubitux> saste: no need for metadata
[16:54] <nevcairiel> well, several authors
[16:54] <ubitux> you can mark frames are interlaced already
[16:54] <ubitux> and i think we have it exported as variables in select
[16:54] <nevcairiel> one that wrote the deint itself, one that made it a lavfi filter, etc :
[16:56] <saste> ubitux, yes, although I see no way to do it with idet at the moment
[16:57] <ubitux>         idet->cur->interlaced_frame = 1;
[16:57] <ubitux> AVFrame are marked or not as interlaced
[16:58] <ubitux> that's what fieldmatch uses to make yadif (and soon w3fdf thx to durandal_1707) as fallback
[16:59] <saste> ubitux: yeah, i was wrong (another time)
[17:00] <saste> idet docs are lacking
[17:00] <saste> so basically it is already doable
[17:46] <ubitux> are we going to war with libav to who is going to submit the most useless/funny things?
[17:46] <ubitux> i remember they started with plan9
[17:46] <ubitux> we replied with aix
[17:46] <ubitux> and now they go for tinycc
[17:46] <ubitux> so what are we gonna do?
[17:47] <ubitux> meeting time guys, this is important
[17:48] <wm4> how about not caring about this stupidf shit
[17:49] <ubitux> come on wm4 
[17:49] <ubitux> let's be fairplay
[17:49] <ubitux> and play the game to the end
[17:50] <durandal_1707> so what QTGMC is? its bunch of plugins or what?
[17:54] <ubitux> durandal_1707: random context grep for QTGMC from this channel: http://pastie.org/pastes/8300770/text
[17:54] <saste> ubitux: we have the xface codec, we won
[17:54] <saste> (not to mention life and cellauto)
[17:55] <Daemon404> we havent won until ffmpeg can be connected to as if it were a remote X11 server
[17:55] <Daemon404> for streaming purposes
[17:55] <ubitux> saste: oh i forgot the awesome filters indeed mmh
[17:56] <durandal_1707> vf_copy
[17:57] <ubitux> i could add a pokemon r/b sprite decoder for FFmpeg, but that's a bit meaningless unless you know how to "demux" them from the ROM
[17:58] <ubitux> ...but I could write a demuxer
[17:58] <wm4> let's add more meaningless crap to look better than the fork
[17:58] <ubitux> (that was a joke)
[17:59] <ubitux> (even thought i want to do it now)
[18:05] <durandal_1707> ubitux: didn't you planed to port nnedi3 vs plugin?
[18:06] <ubitux> yeah but mmh
[18:06] <ubitux> i got confused with another filter
[18:06] <ubitux> one was simple, and the other one not at all
[18:07] <ubitux> the one from vs is the simple and apparently useless one
[18:07] <Daemon404> ?
[18:07] <Daemon404> the vs nnedi3 is full featured
[18:07] <Daemon404> pengvado's lacks some stuff and doesnt work on x86-32
[18:07] <ubitux> yes that one is the complex one
[18:07] <ubitux> i was thinking of the native one with a similar combination of 'n', 'e' and '3'
[18:08] <ubitux> s/'n'//
[18:08] <Daemon404> native to what
[18:08] <ubitux> builtin
[18:08] <Daemon404> to what
[18:08] <Daemon404> vs?
[18:08] <durandal_1707> https://github.com/dubhater/vapoursynth-nnedi3
[18:09] <Daemon404> yes
[18:09] <ubitux> yes builtin to vs
[18:09] <Daemon404> ubitux, youre htinking of eedi3, which is in teh vs repo, is NOT in the core
[18:09] <Daemon404> its sitll a plugin
[18:09] <Daemon404> but it's alsoo entirely useless
[18:09] <Daemon404> if oyu have nnedi3
[18:09] <Daemon404> which is superior if every way
[18:10] <ubitux> yeah, well
[18:10] <ubitux> what i said.
[18:10] <ubitux> 18:06:39 <@ubitux> i got confused with another filter
[18:10] <ubitux> 18:06:47 <@ubitux> one was simple, and the other one not at all
[18:10] <ubitux> 18:06:59 <@ubitux> the one from vs is the simple and apparently useless one
[18:10] <Daemon404> oh
[18:10] <Daemon404> i missed that last ibit
[18:11] <durandal_1707> so for change, what about stop adding useless stuff?
[18:11] <durandal_1707> so which filter is actually useful?
[18:11] <Daemon404> nnedi3
[18:11] <Daemon404> is /very/ useful
[18:11] <durandal_1707> the one i linked?
[18:11] <Daemon404> yes
[18:14] <durandal_1707> it is basicaly upscaling?
[18:14] <Daemon404> it is interpolation, yes
[18:14] <Daemon404> using a trained neural network
[18:15] <durandal_1707> what?
[18:15] <JEEB> one of tritical's fancy things :)
[18:16] <Daemon404> durandal_1707, i used all standard terms there
[18:16] <Daemon404> look it up.
[18:16] <Daemon404> also: http://pastebin.com/raw.php?i=wENfm7J1
[18:16] <Daemon404> it's far mroe useful with scripting, which lavfi cannot do
[18:16] <Daemon404> i.e. QTGMC will do motion compensated bobbing with nnedi3
[18:16] <Daemon404> using an external mocomp filter and masking
[18:31] <pengvado> Daemon404: my nnedi works on x86_32 (though I didn't include a configure script)
[18:32] <Daemon404> pengvado, it iddnt when i tred
[18:32] <Daemon404> it might have only been the asm
[18:32] <Daemon404> also CImg is evil
[18:32] Action: Daemon404 runs
[18:32] <pengvado> worksforme, including asm
[18:33] <Daemon404> weird
[18:33] <JEEB> :)
[18:43] <pengvado> suggest a less evil replacement for CImg?
[18:44] <Daemon404> im not sure off the top of my head
[18:45] <Daemon404> i do know cimg does a *lot* of unneeded memcpying
[18:45] <Daemon404> iirc a ridiculous amount
[18:50] Action: durandal_1707 gonna remove dint, fil and eq
[18:51] <wm4> no, not fil!
[18:51] <wm4> what does fil do again?
[18:52] <Compn> uh oh
[18:52] <Compn> h265 is coming
[18:52] <Compn> its on slashdot
[18:52] <kierank> Compn: you have a slashdot beard
[18:52] <kierank> i imagine all slashdot users look like you
[18:53] <durandal_1707> it's not gray
[18:53] <Compn> haha
[18:57] <mdsh> durandal_1707: thanks for doing something with w3fdif
[18:58] <durandal_1707> mdsh: can you explain why it only used one field all the time (I failed to notice difference anyway)
[18:59] <mdsh> durandal_1707: it doesn't
[18:59] <mdsh> you did do -r 50 after the filter chain
[18:59] <Daemon404> careful when explaining
[19:00] <Daemon404> -r does different things in ffmbc
[19:00] <Daemon404> i think
[19:00] <mdsh> ffmbc cannot change the frame rate in the video filter
[19:01] <mdsh> so in ffmbc, for an i25 source you need to tell ffmbc to output at p50
[19:04] <durandal_1707> w3fdif outputs fields per frame or frame per frame?
[19:06] <mdsh> fields per frame
[19:07] <mdsh> for an i25 source w3fdif outputs p50
[19:12] <durandal_1707> what about adding frame mode? (like it is in yadif) possible?
[19:13] <mdsh> Not what the filter coef's are designed for
[19:33] <karpina> hello! on #ffmpeg seems there is sleeping time, so I'll try to ask here
[19:33] <karpina> imagine I want to create "helloWorld" app with ffmpeg support in MSVC++ ... for example simple colsole app .. .what ffmpeg files do I need for this? 
[19:36] <karpina> silence )) 
[19:42] <karpina> :( 
[21:08] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:4ff5b2683cc8: avfilter/vf_yadif: fix "incompatible pointer type" warning
[21:08] <cone-488> ffmpeg.git 03Michael Niedermayer 07master:59b9ecc92a62: avfilter/vf_yadif: Treat mode as a field of flags
[21:17] <karpina> anyone here?
[21:17] <j-b> where are the aacenc modification, btw?
[21:21] <j-b> https://trac.ffmpeg.org/ticket/2686 ?
[21:31] <Compn> karpina : no one here but us chickens
[21:34] <Compn> j-b : theres only 142 comments. needs more.
[21:35] <j-b> Compn: :)
[21:35] <michaelni> any aac patches that are ready to be commited ?
[21:36] <j-b> doubt it
[21:36] <j-b> but I'll apply them anyway :)
[21:41] <Compn> michaelni : what about applying dxva2 patch from highgod / wei gao ?
[21:43] <j-b> what does it fix?
[21:46] <durandal_1707> leave dxva2
[21:47] <wm4> Compn: well, that patch does read-back to system RAM, so it's not so useful
[21:57] <Compn> j-b : ability to use ffmpeg binary to encode with dxva2
[21:57] <Compn> its very limited usefulness. for people with dxva2 cards and slow cpu
[21:58] <Compn> or just people who want to use their cpu for more than video encoding...
[21:58] <durandal_1707> this hardware crap is just bloating codebase
[21:58] <wm4> durandal_1707: like these opencl filters?
[21:58] <durandal_1707> exactly
[21:58] <wm4> I wonder if anyone ever used them
[21:58] <Compn> durandal_1707 : should we have a seperate branch for hardware accel ?
[21:58] <wm4> and what results they give
[21:59] <durandal_1707> people fail to compile it...
[22:00] <durandal_1707> so nobody against removing dint?
[22:00] <durandal_1707> filter description says : drop interlaced frames, but it actually drops only first interlaced frame it encounter
[22:01] <durandal_1707> i'm also removing fil filter, as it doesn't work in 99.9999999999% cases
[22:02] <Compn> i dont think i've seen anyone ask about dint filter in mplayer
[22:17] <durandal_1707> what is point of kerndeint? it seems worse than yadif
[22:51] <gnafu> durandal_1707: Is it at least faster?
[22:51] Action: gnafu has no idea.
[22:53] <JEEB> there was no yadif back then
[22:53] <JEEB> IIRC
[22:55] <wm4> isn't kerndeint needed in combination with another shitty filter
[22:55] <wm4> I can't remember which one
[23:12] <cone-488> ffmpeg.git 03Paul B Mahol 07release/1.1:f1f8c0e558c6: w64dec: fix skipping of unknown guids
[23:12] <cone-488> ffmpeg.git 03Paul B Mahol 07release/1.1:b438451b7eb8: w64dec: fix end position of summarylist guid
[23:12] <cone-488> ffmpeg.git 03Carl Eugen Hoyos 07release/1.1:1a65ce923a67: Read h264 headers from v4l2 to allow stream-copying.
[23:12] <cone-488> ffmpeg.git 03Paul B Mahol 07release/1.2:ece54c7085dc: w64dec: fix skipping of unknown guids
[23:13] <cone-488> ffmpeg.git 03Paul B Mahol 07release/1.2:3c523bdda84f: w64dec: fix end position of summarylist guid
[23:13] <cone-488> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:06a927a6b534: Read h264 headers from v4l2 to allow stream-copying.
[23:13] <cone-488> ffmpeg.git 03Paul B Mahol 07release/2.0:6c0fef576282: w64dec: fix skipping of unknown guids
[23:13] <cone-488> ffmpeg.git 03Paul B Mahol 07release/2.0:6158eec53f98: w64dec: fix end position of summarylist guid
[23:13] <cone-488> ffmpeg.git 03Carl Eugen Hoyos 07release/2.0:fc4c29bc6efd: Read h264 headers from v4l2 to allow stream-copying.
[23:40] <cone-488> ffmpeg.git 03Paul B Mahol 07master:0a8bb91505ff: lavfi/mp: remove mp=dint
[23:40] <cone-488> ffmpeg.git 03Paul B Mahol 07master:d2e237338db2: lavfi/mp: remove mp=fil
[23:51] <durandal_1707> ffmpeg -flags2 +fast -i /fate-suite/mpeg2/mpeg2_field_encoding.ts -f null - crashes here
[00:00] --- Fri Sep  6 2013