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

[burek]

[07:43] -:#ffmpeg-devel- [freenode-info] channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[09:13] <pigoz> [Als
[10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:5d8619595b84: lavd/xv: simplify write_packet
[10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:57bca5a2b613: lavd/xv: add more supported formats
[10:00] <cone-827> ffmpeg.git 03Lukasz Marek 07master:995f450b44be: lavd/xv: free resources on errors
[10:24] <ubitux> oh wow
[10:24] <ubitux> BBB: did you look at the diff to the vp9 decoder?
[10:24] <ubitux> they are not trivial
[10:24] <ubitux> at all
[10:26] <ubitux> there are a lot of functionnal changes hidden in the cosmetics ones
[10:26] <nevcairiel> they love doing that
[10:28] <ubitux> and they split the files, so it makes diffing much harder
[10:28] <ubitux> i see some clipping added
[10:30] <ubitux> ...and they're going to push it
[10:31] <plepere> ok, I'm sorry, but I need some assembly help again. :(
[10:31] <ubitux> plepere: this is what this channel is for :p
[10:32] <ubitux> BBB: http://lucy.pkh.me/vp9diff.html
[10:33] <plepere> http://pastebin.com/0azLQNBZ
[10:33] <plepere> bit depth is set to 8 for the asm, so the shift is set to 6.
[10:34] <plepere> I think my problem is that dst is a int16* and not int8
[10:34] <nevcairiel> asm doesnt have types
[10:34] <ubitux> plepere: you're not doing any simd?
[10:35] <plepere> ubitux, I have a SIMD version, but it doesn't work, so i told myself "just stick with loops going 1 by 1"
[10:35] <ubitux> [libav-commits] lavc: VP9 decoder
[10:35] <ubitux> aaaaand it's pushed
[10:37] <plepere> nevcairiel, I can't get movb and movq working
[10:38] <nevcairiel> anyhow your plain mov will move native sized values i assume, so you would need to use fixed-size movs that match the value sizes
[10:39] <nevcairiel> src is 8-bit and dst is 16?
[10:39] <plepere> yes
[10:42] <plepere> http://pastebin.com/kiJGSjTu for the full code with the commented SIMD
[10:43] <nevcairiel> http://pastebin.com/5EdwQ5De
[10:43] <nevcairiel> i made 3 modifications, i think that may be better
[10:44] <nevcairiel> it loads only 8-bit using the r9b syntax, writes only 16-bit using r9w, and the dst address calculation was adjusted for 16-bit
[10:44] <plepere> I see the r9b and r9w yes
[10:46] <plepere> and the 2*r7 for the 16bit
[10:46] <nevcairiel> yeah, because it has twice the number of bytes
[10:46] <plepere> the image looks better
[10:46] <nevcairiel> correct better, or just better? :d
[10:47] <plepere> just better
[10:47] <plepere> but it's a good thing !
[10:48] <nevcairiel> is that unsigned or signed numbers?
[10:48] <nevcairiel> for signed, might need to use sign-extension
[10:48] <plepere> uint8 and int16
[10:56] <nevcairiel> i think your simd would work as well, just needs adjustments to the address calculation
[10:57] <nevcairiel> so just add the *2 in the dst address like in the normal asm
[10:57] <plepere> nope
[10:57] <plepere> my intrinsics code is :
[10:57] <plepere>                 x1 = _mm_loadu_si128((__m128i *) &src[x]);
[10:57] <plepere>                 x2 = _mm_unpacklo_epi8(x1, x0);
[10:57] <plepere>                 x2 = _mm_slli_epi16(x2, 6);
[10:57] <plepere>                 _mm_storeu_si128((__m128i *) &dst[x], x2);
[10:58] <nevcairiel> well C code handles the addresses automatically because of the variable types, you dont have that in asm
[10:58] <plepere> yes.
[10:59] <plepere> when using the asm with SSE, I put 2*r7
[10:59] <plepere> but there are still errors
[11:01] <plepere> hmmm
[11:01] <plepere> could it be because dststride and srcstride are ptrdiff_t types in C ?
[11:02] <nevcairiel> thats fine, ptrdiff_t always maps to native register size
[11:24] <ubitux> i should have fwd this to ffmpeg-devel: https://lists.libav.org/pipermail/libav-devel/2013-November/053159.html
[11:45] <ubitux> oh wow they really skipped a lot of fixes
[11:45] <nevcairiel> they didnt pull any fixes since the original patch
[11:45] <ubitux> :')
[11:49] <nevcairiel> i just hope merging doesnt revert the fixes
[11:50] <ubitux> they changed parameter ordering in vp9dsp
[11:51] <ubitux> they're gonna have fun backporting optimized code
[11:51] <nevcairiel> maybe it should just not be merged at all :p
[11:51] <ubitux> yeah but it looks like there are some fixes
[11:51] <ubitux> some i'm gonna dig a bit
[11:52] <j-b> there are some security fixes in libav commit of VP9, if you are speaking about that.
[11:52] <ubitux> j-b: i found one, fixed differently
[11:53] <ubitux> j-b: can you point them out?
[11:53] <ubitux> or this is a secret?
[11:53] <j-b> I don't remember
[11:53] <ubitux> great
[11:53] <j-b> I saw vectors crashing
[11:54] <j-b> through a lot of fuzzing
[11:54] <nevcairiel> report them to the authors of the decoder then
[11:54] <nevcairiel> :)
[11:55] <j-b> This will get even more ugly as time passes
[11:55] <ubitux> j-b: no
[11:55] <ubitux> we will find those fixes, i'll likely take my week end on this merge
[11:56] <ubitux> but i'm not going to backport the cosmetics
[11:56] <j-b> no, I mean, as major decoders arrive, it will get more and more ugly
[11:56] <j-b> and people will choose the fork depending on VP9 and H265 speed
[11:56] <ubitux> ah then that's a good news.
[11:57] <ubitux> michaelni: please don't backport anything from the vp9 bomb (just metadata)
[11:57] <ubitux> i'll look into it this week end
[11:58] <j-b> diff | git apply
[11:58] <ubitux> no
[11:58] <ubitux> we have a lot of fixes they don't have
[11:58] <ubitux> as well as optim actually
[12:04] <ubitux> btw, still no answer on the debian thread?
[12:08] <cone-827> ffmpeg.git 03Alex Sukhanov 07master:86b3435fc010: af_aresample: Fix timestamp of first padded PCM audio packet
[12:09] <michaelni> ubitux, ok about vp9, ill leave it to you
[12:10] <ubitux> i hope BBB will be available too though :)
[12:17] <JEEB> long thread is long indeed
[12:24] <cone-827> ffmpeg.git 03Diego Biurrun 07master:e8fcdebb17fc: build: Allow specifying extra object files when linking HOSTPROGS
[12:24] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:3e78ceadf913: Merge commit 'e8fcdebb17fc59375fd9fc6c0a02a1d2e6d9fb23'
[12:34] <ubitux> 12:34:30 <+j-b> JEEB: yeah, why can't they merge it?
[12:35] <ubitux> j-b: my question exactly: https://trac.ffmpeg.org/ticket/2686#comment:226
[12:35] <JEEB> yup
[12:35] <JEEB> noted that :)
[12:37] <j-b> you meant encoder?
[12:38] <ubitux> j-b: fixed
[12:41] <BBB> ubitux: so ... do we want these changes?
[12:42] <BBB> it sounds to me like we don't
[12:49] <iive> if it is about the aac encoder. there is no reason to keep them away. Who knows maybe in time it could get enough polish.
[12:51] <j-b> "also the patch should be split into self contained fixes, 1 issue == 1 patch when its submitted to ffmpeg-devel." lol
[12:55] <ubitux> BBB: there are some fixes
[12:55] <ubitux> and i want to make sure we don't miss any
[12:57] <cone-827> ffmpeg.git 03Diego Biurrun 07master:3cbe11265304: dv: Split DV data table declarations into their own header
[12:57] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:e28130bcaf48: Merge commit '3cbe1126530449336e2ce59b194bdb8c4eb4abb4'
[13:05] <Compn> j-b : you want to mix cosmetics patch with feature patch ? :P
[13:05] <j-b> I want a working encoder for AAC that does not suck bollocks
[13:06] <BBB> ubitux: but this is really hard to review if there's 10 fixes with 1000000000 cosmetic changes and file moves, plus no reason for each individual change (like: is there a sample that this applies to?)
[13:12] <Compn> j-b : lol you see michaels second comment ?
[13:12] <Compn> right under 1 patch 1 issue
[13:12] <Compn> We can apply a huge monolithic patch too if thats the only option but it will give everyone working on aac headaches (that is you all) when theres a regression and git bisect then ends up just pointing to a huge all in one change.
[13:13] <Compn> if you're for it, just say that 
[13:13] <durandal_1707> where? what?
[13:14] <ubitux> BBB: i will extract every change
[13:14] <Compn> epic 228 comment aac encoder trac ticket
[13:14] <Compn> durandal_1707
[13:15] <ubitux> BBB: my plan is to re-do the cosmetics patches and extract the functionnal changes in separate patches
[13:15] <ubitux> then we will pick the relevant functionnal changes
[13:15] <ubitux> and we will not apply the cosmetics ones
[13:16] <ubitux> (unless you want them)
[13:18] <durandal_1707> merge merge merge
[13:18] <Compn> i would think luca would commit with history , but i guess i dont know libav development rules on such things
[13:21] <ubitux> Compn: well, don't remember with ffv1?
[13:21] <ubitux> they picked dozens of commits, squashed them, cosmetics them and pushed it
[13:21] <ubitux> trashing in the process the relevant history
[13:22] <BBB> ubitux: well I don't care either way about the cosmetic changes; I'm intruiged by the functional changes, similar to your email - why?
[13:22] <BBB> ubitux: without a why, it's hard to apply a functional change
[13:22] <ubitux> yes, but i'll start by isolating all of them
[13:22] <ubitux> so we can have a better overview
[13:22] <JEEB> I remember you asking it on IRC as well, and to be honest I'm surprised you didn't get an answer
[13:23] <ubitux> surprised? :))
[13:23] <ubitux> come on, it happens all the time
[13:23] <BBB> JEEB: I asked 20 times
[13:23] <BBB> JEEB: I get no answer
[13:23] <JEEB> yeah
[13:23] <JEEB> yes, very unpleasantly surprised. There have been some derps at libav, but that's on pretty bad level
[13:23] <BBB> JEEB: figures why I don't want anything to do with the forkifork business anymore
[13:24] <BBB> I didn't do this to make things worse
[13:25] <BBB> ubitux: moving last_frame_invisible out of VP9Context is ok, I think (I remember why I added it in, but since then I moved that information into s->use_last_frame_mvs, we don't need it anymore)
[13:25] <ubitux> ok
[13:29] <Compn> ubitux : i try not paying attention :)
[13:30] <Compn> but no i didnt know that about ffv1 , thats sad :(
[13:31] <iive> libav is in stagnation and decline. but it would take a few more years until it reaches a breaking point.
[13:32] <ubitux> Compn: http://git.libav.org/?p=libav.git;a=commit;h=0f13cd3187192ba0cc2b043430de6e279e7b97c3
[13:36] <Compn> iive : you reading ohloh stats again ? :P
[13:36] <Compn> ubitux : the real question is why do they smush author tag ?
[13:36] <iive> i can't recall what ohloh is... sounds familiar...
[13:36] <Compn> maybe patch author = author to them
[13:37] <ubitux> Compn: "Based on code from Carl Eugen Hoyos, Michael Niedermayer and Paul B Mahol."
[13:37] <ubitux> all the code is modified by cosmetics
[13:37] <ubitux> so he took authorship i guess
[13:37] <iive> ohloh.net ?
[13:40] <BBB> 'sb' does not stand for 'subblock' btw
[13:40] <BBB> that's funny
[13:40] <mateo`> iive: it summarizes your open source contributions (but you have to add the projects you're working on manually)
[13:41] <mateo`> iive: so you can compare with others, see who has the biggest one :D
[13:42] <ubitux> BBB: http://lucy.pkh.me/vp9diff2.html
[13:42] <ubitux> this is the block diff part
[13:42] <ubitux> gonna add the dsp one while at it
[13:44] <ubitux> BBB: and here is the dsp one: http://lucy.pkh.me/vp9dspdiff.html
[13:45] <iive> the problem with each kind of metric, is that diego can fake it :)
[13:45] <ubitux> BBB: note how they changed the parameter ordering
[13:51] <BBB> I objected to that several times
[13:51] <BBB> but their problem, the simd won't always work
[13:51] <ubitux> they didn't pick it yet
[13:52] <ubitux> at least not all
[13:52] <BBB> const removal is bad in decode_coeffs
[13:53] <ubitux> any idea why it was done?
[13:53] <BBB> can you diff the header also?
[13:53] <ubitux> ok
[13:53] <BBB> I added it later, when I made these table-tables const
[13:53] <BBB> they probably missed that patch
[13:53] <BBB> (i.e. some tables don't live in rodata for them)
[13:54] <ubitux> ah i see
[13:54] <ubitux> the header is "empty" (just a few extern)
[13:54] <ubitux> everything is in a .c
[13:55] <ubitux> BBB: http://lucy.pkh.me/vp9datadiff.html
[13:55] <ubitux> (.h against .c)
[13:56] <ubitux> ahaha i was sure they would break the hierchical indent
[13:56] <nevcairiel> they probably thought it was just bad indent
[13:56] <nevcairiel> they dont think about such things
[13:56] <ubitux> i think they know
[13:57] <ubitux> but "it's better to be consistent than pragmatic"
[13:57] <nevcairiel> diego also has a thing against tables in headers, so thats why it was moved probably
[13:58] <ubitux> was it ever duplicated?
[13:58] <ubitux> we can prevent duplicated include easily btw
[13:58] <ubitux> if that's the problem
[13:59] <ubitux> #ifdef AVCODEC_VP9DATA_H #error ... on top of those include-once-header should do
[14:00] <ubitux> so far it's only included once so there is no such problem
[14:01] <wbs> ubitux: the issue with tables in headers isn't if the header is included multiple times in the same compilation unit, but if you accidentally later start including the same header in multiple files
[14:01] <wbs> which depending on compiler and linker might or might not lead to duplicated tables
[14:02] <ubitux> right, but that's not supposed to happen in here
[14:02] <ubitux> -in
[14:02] <wbs> I'm not commenting on the actual case here, just in general
[14:02] <wbs> (haven't looked at that)
[14:02] <ubitux> yeah sorry, my workaround wouldn't work indeed
[14:02] <wbs> and the problem with "not supposed to happen" is that it can easily be overlooked and changed later by someone who doesn't keep this in mind
[14:03] <wbs> the downside obviously is that you can't inline individual constants from the table if you have an access like table[42] somewhere
[14:03] <BBB> ubitux: where is VP9Context defined?
[14:03] <ubitux> libavcodec/vp9.h
[14:04] <BBB> can you diff our vp9.c to their vp9.h?
[14:04] <ubitux> yes i was going to
[14:04] <BBB> the int64_t/unsigned thing you mentioned I agree with, I don't quite see why
[14:04] <BBB> it's read as AV_RB32
[14:04] <BBB> so it always fits an unsigned
[14:04] <BBB> and then I think it's safely compared?
[14:04] <BBB> maybe they think that pkt->size can go negative?
[14:05] <ubitux> BBB: http://lucy.pkh.me/vp9hdiff.html
[14:05] <ubitux> mmh.
[14:05] <BBB> the av_clip in the fw update function seems unnecessary, the table only has so many entries so it can never go outside range
[14:05] <ubitux> i should diff against something else
[14:06] <BBB> but it's not functionally relevant so they can keep it as a documentation cosmetic I guess
[14:06] <BBB> hm yeah
[14:06] <BBB> the memcpy is broken
[14:06] <BBB> you can't memcpy a table of [11] and [3] to each other and expect things to work
[14:06] <BBB> there's a reason that was a loop
[14:07] <BBB> I don't see any other functional changes
[14:07] <ubitux> huh they removed the vp9dsp.h
[14:07] <BBB> yeah that's in vp9.h
[14:07] <BBB> oddly
[14:07] <BBB> I always tended to split dsp stuff in its own header since arch-specific code depends on that header
[14:07] <BBB> and you obviously don't want them to include all of vp9.h
[14:07] <BBB> just the dsp parts
[14:07] <ubitux> right
[14:08] <ubitux> ffmpeg/libavcodec/vp9dsp.h libav/libavcodec/vp9.h raises no relevant diff
[14:08] <BBB> so one good change, a few broken ones, a few unnecessary ones
[14:08] <ubitux> gonna try vp9.c vs vp9.h
[14:08] <BBB> and a shitton of cosmetics
[14:08] <BBB> long live the fork :(
[14:09] <ubitux> ok well
[14:09] <ubitux> fb removed
[14:10] <ubitux> BBB: http://ubitux.fr/pub/pics/vp9-h-vs-c-diff.png
[14:10] <ubitux> relevant part of vp9.c vs vp9.h
[14:10] <BBB> yeah I saw them renaming f to cur_frame
[14:10] <BBB> that's fine I guess, but still a cosmetic
[14:11] <ubitux> yeah but fb removed
[14:11] <BBB> fb[] removal is fine I guess, I haven't looked very closely at it, the loops appeared similar
[14:11] <BBB> did they change frame allocation behaviour?
[14:11] <ubitux> BBB: yes, a little
[14:11] <ubitux> they unref instead of ref
[14:12] <BBB> *confused*
[14:12] <BBB> well if it works
[14:12] <ubitux> BBB: see around L3454 (left) in http://lucy.pkh.me/vp9diff.html
[14:13] <BBB> oh that's kind of cute
[14:13] <BBB> I like that change
[14:13] <BBB> see, small good changes get lost in a sea of cosmetics
[14:13] <BBB> so sad
[14:14] <ubitux> that's why i wanted to extract the relevant part
[14:14] <ubitux> +s
[14:14] <ubitux> BBB: what about the switch to while?
[14:14] <ubitux> (a bit below)
[14:15] <ubitux> (demacrotization)
[14:15] <BBB> that's silly
[14:15] <BBB> it adds an extra and to each loop iteration
[14:15] <BBB> I don't think it's performance critical, so if you dislike macros, that's fine
[14:15] <BBB> but I don't think it's better
[14:15] <ubitux> no i don't dislike it
[14:15] <ubitux> just curious
[14:16] <BBB> thye do know 'res' means 'result' right?
[14:16] <BBB> is ret 'return_value'?
[14:16] <BBB> it's an odd naming change
[14:16] <ubitux> ret is often used
[14:17] <ubitux> BBB: interested in picking the frame allocation thing?
[14:17] <ubitux> (i mean re-doing the patch yourself)
[14:32] <BBB> the change suggests res is invalid english or so
[14:33] <BBB> i can try to pick it over the weekend
[14:33] <BBB> weekdays are bad
[14:33] <ubitux> i'm pretty sure it's a consistency/i-like-red-better thing
[14:33] <BBB> right
[14:34] <ubitux> BBB: don't worry too much about it, i can do the extraction myself
[14:34] <ubitux> and will send you some patches for review
[14:34] <ubitux> it was just in case you wanted to work on this
[14:35] <ubitux> but if you prefer working on MT or SIMD& :)
[14:36] <BBB> nah, I'll do mt and simd
[14:37] <BBB> but so little time :(
[14:37] <BBB> time to go to work, bbl
[14:45] <sspiff> ubitux: it seems to me that av_interleaved_write_frame is meant for the kind of stuff that's occuring with the DVB subtitles: queuing packets for being written later on in the container, based on their DTS?
[14:46] <sspiff> judging from the fact that it eventually calls ff_interleave_packet_per_dts, adding it to AVFormatContext->packet_buffer
[14:47] <ubitux> i would guess it's for anything that require re-ordering
[14:47] <ubitux> b-frames stuff 
[14:47] <sspiff> so the fact that compute_fields2 complains about the fact that the DTS is not monotonically increasing seems like superfluous and maybe even wrong to me?
[14:47] <plepere> in ffmpeg, is there something against // comments ?
[14:47] <ubitux> plepere: no
[14:47] <plepere> ok thanks
[14:47] <ubitux> plepere: but better use ; in asm :p
[14:48] <plepere> In order to keep myself from loosing too much hair, I'm putting all versions of openHEVC x86 optimisations together.
[14:48] <sspiff> ubitux: sure, but since it uses interleave_compare_dts means that the DTS'es can be non-monotonic?
[14:48] <plepere> so it's mostly refactoring
[14:49] <plepere> but otherwise, my angry stares did not intimidate my asm to fix itself
[14:49] <ubitux> sspiff: i don't remember which of pts and dts is ordered :p
[14:50] <sspiff> dts is ordered, pts is not generally
[14:51] <sspiff> (in case of video GOPs at least)
[14:52] <sspiff> I was thinking of adding a queue (AVPacketList) to output streams to buffer packets based on DTS, but it looks like that's already there :P
[14:52] <sspiff> (for the stupid DVB subtitle bug)
[14:52] <ubitux> i don't think i can help you in that area
[14:52] <ubitux> :p
[14:53] <sspiff> do you know who would know how this interleaving code works and how I can abuse it?
[14:53] <ubitux> yeah, you should harass michaelni about such pts/dts thing, keeping in mind he's busy :p
[14:54] <ubitux> or ask on ffmpeg-devel, maybe
[15:08] <saste> ubitux, any progress with perlin noise source?
[15:08] <ubitux> saste: huh?
[15:08] <ubitux> i don't remember working on this
[15:09] <saste> you mentioned that, some time in the past
[15:09] <saste> nevermind
[15:09] <cone-827> ffmpeg.git 03Ronald S. Bultje 07master:458446acfa14: lavc: Edge emulation with dst/src linesize
[15:09] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:91e00c4a785d: Merge commit '458446acfa1441d283dacf9e6e545beb083b8bb0'
[15:10] <ubitux> ah, maybe
[15:10] <ubitux> as a source filter?
[15:10] <ubitux> would be nice indeed :))
[15:13] <clever> ubitux: ah looks like i dont want to create a second _hwaccel struct
[15:13] <clever> the pix_fmt on that struct should be my custom one
[15:13] <clever> so, why is it trying to call ff_find_hwaccel with AV_PIX_FMT_YUV420P10LE instead of AV_PIX_FMT_RPI, hmmm
[15:14] <ubitux> i didn't follow what you were trying to do, already did, or currently have some trouble with
[15:14] <ubitux> except maybe adding r-pi hwaccel 
[15:15] <clever> ubitux: http://privatepaste.com/1f842c4dbf
[15:15] <clever> i have this 'working' for 8bit h264
[15:15] <clever> it properly gets the bitstream
[15:15] <clever> but for 10bit h264, the code just isnt even ran
[15:15] <ubitux> what is AV_PIX_FMT_RPI?
[15:15] <clever> a custom format that only works with the vo module i made in mplayer
[15:15] <ubitux> oh just like VDPAU ok
[15:15] <clever> it passes the bitstream data directly to the vo module
[15:15] <clever> i based everything off the vdpau code
[15:16] <clever> so ff_find_hwaccel must be ran with AV_PIX_FMT_RPI to find that struct
[15:16] <ubitux> i thought it required a _<codec> suffix
[15:16] <ubitux> but seems not
[15:16] <clever> but for 10bit files, it uses AV_PIX_FMT_YUV420P10LE
[15:17] <wm4> I think 10 bit stuff directly works bypasses the hw accel layer? it used to just crash
[15:17] <wm4> clever: what kind of API does rpi use for hw decoding and display? something EGL related?
[15:18] <j-b> OMX, of course
[15:18] <clever> wm4: openmax i believe
[15:18] <clever> http://privatepaste.com/3206505237
[15:18] <clever> this is the debug output with my extra debugging added
[15:18] <wm4> k
[15:18] <clever> it starts out with pixel format -1, then 0, then it goes back to -1, and somehow decides to use 110 (AV_PIX_FMT_RPI) right at the end
[15:19] <clever> then using AV_PIX_FMT_RPI it does ff_find_hwaccel and everything works
[15:19] <clever> thats how 8bit files work
[15:20] <clever> and here is the 10bit files, http://privatepaste.com/26726b29a4
[15:20] <clever> it starts out as -1, then jumps to 0
[15:20] <smarter> [14:07:35] <BBB> I always tended to split dsp stuff in its own header since arch-specific code depends on that header
[15:20] <smarter> [14:07:41] <BBB> and you obviously don't want them to include all of vp9.h
[15:20] <clever> i mean 72
[15:20] <smarter> why not?
[15:20] <clever> then goes back -1, then 72, and stays 72
[15:21] <clever> it never switches to AV_PIX_FMT_RPI (110)
[15:21] <wm4> clever: well, I doubt rpi can decode 10 bit files...?
[15:21] <clever> wm4: i already checked, it can
[15:22] <wm4> can it really, or does it just decode it as 8 bit? (which should give funky artifacts)
[15:22] <clever> yeah, i do see a bit of artifacting
[15:22] <JEEB> real 10bit decoder ASICs after all cost four-five digit sums :P
[15:22] <clever> so its just ignoring 2 of the bits?
[15:23] <JEEB> it's more than that
[15:23] <JEEB> it's broken decoding
[15:23] <JEEB> plain and simple
[15:23] <clever> still looks useable, far better then trying to software decode it
[15:23] <JEEB> you can look into the AVC/H.264 spec for more details
[15:23] <nevcairiel> they implemented such evil hackery on the rpi?
[15:23] <nevcairiel> another reason never to buy yone
[15:24] <JEEB> well, it really depends. It doesn't take much of a stream to just output a picture that is completely borked
[15:24] <JEEB> of course if you want that instead of it just telling you the stream can't be played...
[15:24] <clever> it looks 95% good
[15:24] <clever> just every now and then, it gets a small artifact somewhere
[15:24] <JEEB> it just happens to look so right now, with the sample you have
[15:24] <clever> yeah
[15:24] <clever> it would depend on the encoding
[15:25] <clever> id still rather fix it, and print a warning that 10bit isnt fully supported
[15:25] <clever> rather then fully ignore the files
[15:25] <JEEB> nevcairiel, I don't see anything special, nvidia and ATi/AMD used to let such stuff through as well
[15:25] <JEEB> probably intel as well
[15:25] <JEEB> nowadays the check is in the drivers or the HW decoding API
[15:26] <clever> i just need to know why its trying to do ff_find_hwaccel with AV_PIX_FMT_YUV420P10LE instead of AV_PIX_FMT_RPI
[15:26] <nevcairiel> because thats the pixel format for it
[15:26] <nevcairiel> its hard-wired to only try hwaccel formats for 420 8-bit
[15:26] <clever> ah
[15:26] <clever> let me check arround h264_hwaccel_pixfmt_list_420
[15:27] <clever> this looks related
[15:27] <clever> let me hack the crap out of get_pixel_format and figure out what its doing
[15:29] <wm4> <nevcairiel> its hard-wired to only try hwaccel formats for 420 8-bit <- in theory, the library user should just never try hw decoding with profiles where it doesn't work, but mplayer doesn't check profiles
[15:29] <clever> and i'm trying to force something thats already confirmed as broken
[15:29] <nevcairiel> since there is no hardware for decoding any other profiles, this hard-wired check isn't wrong
[15:30] <nevcairiel> but its not complete either, can still have lossless 420 8-bit which blows up in the decoder
[15:30] <clever> its asking for configure to be reran, so this will take a few hours
[15:31] <clever> i'll be back later once it compiles and i get some sleep
[15:31] <clever> pretty sure the problem is that get_pixel_format isnt picking my custom format
[15:31] <nevcairiel> the problem is thats its hard-wired to never use hwaccel for 10-bit
[15:32] <clever> yeah, it looks like case 10: is catching things before it reaches case 8:
[15:32] <wm4> clever: do you have your mplayer patch somewhere?
[15:32] <clever> dang, the names are so obvious now!
[15:33] <clever> wm4: let me upload it
[15:33] <Compn> clever : lol @ case 10 v case 8 
[15:33] <clever> Compn: i was just ignoring them, they usualy have little meaning
[15:34] <clever> until i'm forced to tell you what they are, and aha!
[15:34] <cone-827> ffmpeg.git 03Ronald S. Bultje 07master:72ca830f511f: lavc: VP9 decoder
[15:34] <cone-827> ffmpeg.git 03Michael Niedermayer 07master:97962b278a8a: Merge remote-tracking branch 'qatar/master'
[15:36] <clever> wm4: finding the url...
[15:36] <clever> wm4: http://ext.earthtools.ca/download/patch.tar
[15:36] <wm4> thanks
[15:37] <cone-827> ffmpeg.git 03Compn 07master:5592d1b74192: riff: add G264 to mpeg4, only decodes keyframes
[15:37] <clever> that also has a fix for a double free i found in ffmpeg
[15:37] <Compn> j-b : ^^^ g264 added
[15:37] <Compn> ehe
[15:37] <wm4> clever: I see, no display yet
[15:37] <clever> wm4: yeah, it has everything except the openmax code
[15:38] <clever> all it can do is pipe the bitstream down to the vo module, and then save it to /tmp/
[15:38] <clever> http://ext.earthtools.ca/download/git.diff ctrl+f for fail, and read the comments in that region
[15:38] <clever> there is a double-free bug in ffmpeg
[15:39] <clever> av_freep(&priv) releases some memory, then av_buffer_unref tries to reference it, then use a callback inside that to release it again
[15:40] <clever> and its only gone un-noticed, because only broken codecs trigger that code
[15:41] <j-b> Compn: wow
[15:41] <ubitux> "only decodes keyframes"
[15:42] <Compn> who needs all of those other frames ?
[15:42] <Compn> also its flipped :)
[15:42] <Compn> i guess i could add it to flipped list
[15:42] <Compn> but whoever fixes non-keyframes can do that
[15:43] <clever> i should get some sleep while this recompiles
[15:43] <clever> later all :)
[15:43] <Compn> L264 is lead h264 . LEAD always messes with stuff...
[15:46] <Compn> so no, its not mpeg4
[15:46] <Compn> :(
[15:46] <Compn> luckily no one uses L264 so we can ignore :)
[15:49] <Compn> i should find binary codec for l264
[15:49] <Compn> hmm
[15:50] <Compn> https://forum.videolan.org/viewtopic.php?f=14&t=50293&start=0
[15:50] <Compn> by Jean-Baptiste Kempf » Fri Sep 19, 2008 8:13 pm 
[15:50] <Compn> Well, even while forcing L264 codec, it doesn't decode those, because they are not H264 compliant.
[15:51] <Compn> j-b : how come you no remember saying this, 5 years ago ?
[15:51] <j-b> I do
[15:51] <j-b> hence my question
[15:51] <Compn> its not like those files became magically compliant :)
[15:51] <Compn> but ok , good question :)
[15:52] <Compn> lead idiocy, not geovision gpl violating idiocy i guess
[16:07] <j-b> Why the hell do you allow FLAC in mov?
[16:09] <durandal_1707> I?
[16:10] <ubitux> is there some remaining decoders still setting only the number of channels instead of the channel layout?
[16:10] <ubitux> or users are still supposed to jungle between codec->nb_channels and codec->channel_layout?
[16:10] <durandal_1707> sonic
[16:12] <ubitux> mmh ok
[16:12] <ubitux> i guess i'll have to jungle then
[16:13] Action: ubitux copies/paste guess_input_channel_layout()
[16:14] <durandal_1707> ubitux: nobody uses sonic
[16:14] <ubitux> is it the only remaining one?
[16:15] <durandal_1707> it is useless pile of vapourware
[16:36] <sspiff> ubitux: how do I go about submitting this patch for feedback?
[16:36] <sspiff> I'd love to get this thing merged, eventually :)
[16:37] <ubitux> you send it as a git format-patch to ffmpeg-devel at ffmpeg.org
[16:51] <sspiff> ah, damn, sent from my wrong email! now the message is awaiting moderator approval -_-
[16:54] <sspiff> ubitux: how long does this approval process take, generally?
[16:55] <ubitux> depends, 24h?
[16:55] <ubitux> i think you can ask Compn 
[16:55] <ubitux> llogan too but he isn't online it seems
[17:00] <sspiff> ubitux: I can wait 24h, that's fine.
[17:10] <Compn> sspiff : i can accept it now
[17:10] <Compn> what llist
[17:10] <Compn> heh
[17:10] <Compn> just gotta enter my password
[17:10] <Compn> 12345
[17:10] <Compn> there
[17:11] <Compn> sspiff : ok your email was approved
[17:12] <sspiff> Compn: thanks!
[17:12] <nevcairiel> it looks like you copy/pasted the patch file into your mail client, there is wrapping on some lines
[17:12] <nevcairiel> it might not work anymore
[17:14] <sspiff> nevcairiel: doh! How am I supposed to get it into my mail client (being gmail) without copy pasting?
[17:14] <sspiff> ah wait
[17:14] <nevcairiel> usually you could use git send-email, but that needs a bit of setup, otherwise just attach the file
[17:14] <sspiff> alright, thanks
[17:16] <sspiff> sorry for all the trouble!
[17:17] <ubitux> sspiff: did you try to play with the AVFMT_NOTIMESTAMPS  and AVFMT_TS_NONSTRICT?
[17:18] <sspiff> ubitux: AVFMT_TS_NONSTRICT shouldn't help, since they're actually non-monotonic, even in the non-strict sense
[17:18] <sspiff> didn't see AVFMT_NOTIMESTAMPS
[17:19] <ubitux> not sure if that one really is relevant but well :)
[17:20] <sspiff> ubitux: the accompanying comment says that's for formats that don't need timestamps, but MPEG-TS desperately needs them, no?
[17:20] <ubitux> i guess so :)
[17:22] <sspiff> ubitux: I thought AVFMT_TS_NONSTRICT might help (I think it disables the check that makes the transcoding abort), but the comment seems to say that I shouldn't rely on this working, so I didn't
[17:27] <sspiff> nevcairiel: did my second email come through alright?
[17:29] <nevcairiel> yes, looks fine
[17:29] <sspiff> nevcairiel: thanks for verifying :)
[17:51] <durandal11707> Compn: where you type that password?
[17:55] <ubitux> is anyone interested in having av_audio_fifo acting as an audio ring?
[17:55] <Compn> durandal11707 : you want to help moderate the ffmpeg-devel list ? :)
[17:56] <Compn> durandal11707 : lou logan is moderator too, he works hard at it :)
[17:56] <Compn> i'm sure he would be happy for some help
[17:57] <wm4> ubitux: doesn't it already act as a ring?
[17:57] <ubitux> wm4: if you drain manually
[18:04] <ubitux> also, probably have the initial buffer completely full with silence at init
[18:07] <wm4> doesn't the buffer have a size (which is 0 initially)?
[18:07] <wm4> by which I mean av_audio_fifo_size()
[18:08] <ubitux> yes
[18:08] <ubitux> afaict
[18:08] <ubitux> but the idea would be to have av_audio_fifo_size() always at the same size than the init size
[18:08] <ubitux> (aka buffer filled with silence, and you push samples at the end)
[18:09] <ubitux> (and the older ones go out)
[18:09] <ubitux> i can write that in my app but i was wondering if some ppl would be interested in such api
[18:11] <wm4> what is the use case? i.e. what exactly does your app need it for?
[18:13] <durandal11707> ubitux: iirc something like that is used in couple of filters in request_frame at eof
[18:13] <durandal11707> perhaps it can be refactored......?
[19:01] <ubitux> wm4: the use case is a bit special, i need the last seen N samples at a given time t
[19:01] <ubitux> and i need exactly N samples all the time
[19:02] <ubitux> so i want to fill a ring buffer continuously, and read all of it sometimes
[19:02] <ubitux> (without draining the data)
[19:02] <wm4> hm
[20:59] <llogan> i liked carl's answer here http://ffmpeg.org/pipermail/ffmpeg-user/2013-November/018530.html
[21:42] <cone-876> ffmpeg.git 03Jan Gerber 07master:d03eea36b2c3: lavf/matroska*: add support for signed integers
[21:42] <cone-876> ffmpeg.git 03Michael Niedermayer 07master:cddd15ba5c9c: avformat/matroska: simplify signed int access code
[21:47] <Daemon404> 42
[22:10] <ubitux> anyone has part 2 of mpeg4 standard?
[22:13] <ubitux> kierank: aren't you hiding it under your jacket?
[22:13] <kierank> is it not in the specs folder
[22:24] <nevcairiel> ubitux: if a slightly outdated version is ok
[22:25] <ubitux> nevcairiel: better than nothing :P
[22:27] <nevcairiel> ubitux: http://files.1f0.de/tmp/MPEG4Part2.pdf
[22:27] <ubitux> thx!
[22:28] <ubitux> nevcairiel: is this sharable or not?
[22:28] <nevcairiel> i dont care, i just got it from the interwebs
[22:28] <nevcairiel> someone else violated the license
[22:28] <nevcairiel> :D
[22:28] <ubitux> ok perfect
[22:28] <ubitux> :)
[22:29] <nevcairiel> even has the license watermark in the footer
[22:29] <nevcairiel> but hey
[22:29] <nevcairiel> the stnadard has some weird things about 3d mesh coding in it, never heard of that before
[22:36] <JEEB> nevcairiel, yeah -- MPEG-4 Visual had a lot of new stuff tried out
[22:36] <JEEB> the problem is it wasn't really feasible
[22:36] <JEEB> AVC/H.264 was then a coming-back to the old style
[22:37] <JEEB> also I think many of the features never got into any profile
[23:02] <Compn> someone working on h264 mvc ?
[23:02] <Compn> ehe
[23:02] <Compn> oh mpeg4 3d nevermind
[23:29] <cone-876> ffmpeg.git 03Clément BSsch 07master:150c5543ffee: avcodec/vp9: fix "initialize" typo.
[23:37] <llogan> ubitux: might be a good candidate for patcheck
[23:38] <ubitux> [~/src/ffmpeg]- git grep -i intia
[23:38] <ubitux> [~/src/ffmpeg]- 
[23:38] <ubitux> seems not
[23:38] <llogan> lazy>intellect
[00:00] --- Sat Nov 16 2013