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

[burek]

[03:22:45 CEST] <cone-107> ffmpeg 03Alex Agranovsky 07master:276ab7c148b9: avformat/mpjpegdec: Allow mpjpeg headers parsing to succeed upon EOF, if required headers are present
[09:50:26 CEST] <bahador> HI
[09:50:44 CEST] <bahador> is there some on here to helping me 
[09:51:12 CEST] <bahador>  is there any transition effect in ffmpeg .. for between two image ..
[10:24:35 CEST] <iive> https://lkml.org/lkml/2015/9/9/602 on the topic of new interfaces :)
[10:40:39 CEST] <fritsch> iive: but linus is right and it is not about the interface but about the implementation
[10:41:19 CEST] <iive> it is about having less bugs.
[10:44:36 CEST] <fritsch> in fact he says: don't replace a buggy system with a better designed one, but buggy implemented
[10:45:18 CEST] <iive> it's designed with flaw.
[10:56:56 CEST] <Plorkyeran> the problem there is that it's fairly inevitable that when porting lots of code to a new API, some of the porting will be done incorrectly
[10:57:13 CEST] <Plorkyeran> so a new API which exists only to reduce bugs will actually increase bugs in the short term
[10:57:30 CEST] <Plorkyeran> and if you keep replacing the interfaces, you never get the long-term benefits
[10:59:56 CEST] <kurosu> nevcairiel, you can always try reaching the openhevc guys, but don't hold your breath for a reply (on that NoRASL output thingy or anything)
[11:00:20 CEST] <nevcairiel> yeah I mailed them
[11:00:26 CEST] <kurosu> as for the patch, I'm surprised no further check on nalu type and poc is needed, but as it works...
[11:00:58 CEST] <nevcairiel> thats what the spec seems to say, only drop frames for idr, bla, or first cra after eos/start
[11:01:19 CEST] <kurosu> except there shouldn't be rasl for some types of idr/bla
[11:01:29 CEST] <nevcairiel> although BLAs dont seem to usually exist much
[11:01:44 CEST] <nevcairiel> they seem to get created artificically from CRAs when stitching streams
[11:02:23 CEST] <kurosu> I haven't followed the logic, but it seemed the checks didn't answer that question: are those rasl and has the relevant "associated" picture that flag, and how do you find it is "associated'
[11:02:46 CEST] <kurosu> *does the relevant ... have that flag
[11:03:31 CEST] <kurosu> anyway, it fixes things, and until it is found to be unsufficient/break some other things
[11:03:39 CEST] <kurosu> I wouldn't bother much
[11:03:55 CEST] <kurosu> with improving your patch
[11:05:39 CEST] <kurosu> nevcairiel, were the affected streams experimental dvb dumps? or just a collage of streams?
[11:06:04 CEST] <kurosu> (experimental as in the specs aren't finalized and published iirc)
[11:06:08 CEST] <nevcairiel> nothing of that sort
[11:06:22 CEST] <nevcairiel> the one i first encountered it with with a UHD demo stream from samsung
[11:07:09 CEST] <kurosu> so it is not completely sure they aren't broken ?
[11:09:16 CEST] <nevcairiel> with the number of streams this has affected over the time, i'm confident the streams would appear to be correct
[11:09:48 CEST] <kurosu> ok
[11:13:51 CEST] <fritsch> all those streams:
[11:14:04 CEST] <fritsch> http://www.libde265.org/downloads-videos/
[11:14:06 CEST] <fritsch> are affected
[11:14:18 CEST] <fritsch> (if we talk about the problem / solution from yesterday)
[11:19:13 CEST] <kurosu> all encoded and generated by the divx encoder it seems
[11:19:40 CEST] <kurosu> iirc, another instance of that system also generated incorrect spses
[11:20:34 CEST] <kurosu> (rather the vui)
[11:21:06 CEST] <nevcairiel> (noone cares about the vui)+
[11:21:50 CEST] <kurosu> well the issue is that you're not sure it is the vui which is broken or that something went wrong in the sps
[11:22:46 CEST] <kurosu> plus that may cause you to read incorrect extension flag bits
[11:24:47 CEST] <fritsch> out of my 20 hevc samples, this (now fixed issue) happened with ~ 11 of them
[11:25:19 CEST] <kurosu> I'm not saying this shouldn't applied
[11:25:26 CEST] <fritsch> i was just speaking as a user
[11:25:35 CEST] <kurosu> the hevc decoder has code to handle other broken things
[11:25:44 CEST] <kurosu> as other past codecs
[11:26:07 CEST] <fritsch> what I wanted to understand: I had the chance to test on windows with the "current" mpc-hc
[11:26:13 CEST] <fritsch> which uses ffmpeg from 6 months ago
[11:26:18 CEST] <fritsch> and here this problem did not happen
[11:26:38 CEST] <fritsch> so, there was some hevc change in ffmpeg that produced a more strict decoder?
[11:26:56 CEST] <kurosu> the sps issue I'm referring to is much older
[11:27:07 CEST] <fritsch> okay
[11:27:10 CEST] <kurosu> the norasl thingy is another matter
[11:27:32 CEST] <fritsch> i mainly talk about https://trac.ffmpeg.org/ticket/4185#comment:7
[11:27:36 CEST] <kurosu> and iirc, most windows codecs are not using vanilla ffmpeg, but iirc, nevcairiel's patched version
[11:27:52 CEST] <fritsch> concerning hevc he upstreamed everything, he told me
[11:28:02 CEST] <nevcairiel> hevc dxva, i said =p
[11:28:22 CEST] <nevcairiel> mpc-hc uses the patch from that ticket
[11:28:24 CEST] <nevcairiel> well the old patch
[11:28:28 CEST] <fritsch> ah!
[11:28:36 CEST] <fritsch> lol - now that makes sense
[11:29:00 CEST] <kurosu> doesn't that part also matter for dxva, or are the dxva decoders only fed sps/pps/nalus ?
[11:29:04 CEST] <fritsch> we will keep it in kodi for the time being (after it is pushed), was too much noise by users with hevc issues the last days
[11:29:10 CEST] <kurosu> (the rasl thing)
[11:29:13 CEST] <nevcairiel> of course it matters
[11:29:37 CEST] <nevcairiel> but it took some time to identify which part was the problem, and at first people only said hw decoders were broken
[11:30:11 CEST] <fritsch> yeah, we thought it's a vaapi limitation, but philipl could reproduce on nvidia and after having tested on a i7 rig in sw - it was clear
[11:30:17 CEST] <fritsch> that there is something deeper
[11:30:47 CEST] <fritsch> but, hehe - without your mpc-hc ... we would have said: file is broken
[11:37:15 CEST] <kurosu> well, anyway, I don't expect a reply from openhevc, and current patch is as good as it gets
[12:01:21 CEST] Action: Daemon404 wonders if j-b's train existed today
[12:44:09 CEST] <atomnuker> the more I look at it the more I'm convinced LTP is the most screwed up AAC extensions out of all of them
[12:44:25 CEST] <atomnuker> I'd ramble all about it now but then I'd run out of things to say about at the VDD
[12:44:44 CEST] <nevcairiel> lol
[12:53:39 CEST] <nevcairiel> kurosu: i dont expect them to respond either, we've notified them about hte issue month ago and nothing happened, sending them the new patch was more a courtesy than anything else
[12:56:02 CEST] <Daemon404> nevcairiel, so openhevc was another pump-n-dump operation?
[12:56:33 CEST] <nevcairiel> ever since their original p roject finished, they havent really done anything anymore
[12:56:58 CEST] <Daemon404> so yes,.
[12:57:29 CEST] <nevcairiel> they have some weird things in there which ffmpeg doesnt have, like frame+slice threading at the same time, ie. use slice threading for key frames to speed up their decoding
[12:58:01 CEST] <Daemon404> that sounds like it potentially end up worse speed-wise in some situations
[12:58:10 CEST] <nevcairiel> i suppose it can also help
[12:58:32 CEST] <Daemon404> indeed.
[13:40:26 CEST] <kurosu> Daemon404, it does help, but you need cores. 30% speedup for appropriate streams on 4 cores+HT, 0% on 2-cores+HT
[13:40:57 CEST] <kurosu> the issue is more the threading decision in libavcodec/ffmpeg, it should be asking the codec after it has parsed some syntax
[13:41:11 CEST] <Daemon404> kurosu, i thought on some sorts of streams (lower res, certain frame-patterns) it could cause excessive waiting on the slice threads to finish
[13:41:26 CEST] <Daemon404> but thats probably at a level of ricing that is useless
[13:41:44 CEST] <kurosu> well, on those streams, you'd be fine speedwise with one thread anyway
[13:42:04 CEST] <Daemon404> i figured threading could make it marginally slower
[13:42:08 CEST] <Daemon404> in such a case
[13:42:11 CEST] <kurosu> nevcairiel, the most active openhevc guys have moved to other companies, and the remaining ones are mostly not very competent and more interested in academic stuff
[13:42:30 CEST] <kurosu> it makes 4k60p playable on those systems
[13:42:50 CEST] <wm4> "This project is intended to have backward compatibility for all. It is not a competition between machines. It is an open source project to be shared."
[13:42:57 CEST] <wm4> it's easy to see how this project ended up where it is
[13:43:10 CEST] <fritsch> kurosu: playback is a matter of rendering I think ...
[13:43:20 CEST] <wm4> oh wrong channel
[13:43:23 CEST] <wm4> and wrong network
[13:43:24 CEST] <fritsch> e.g. decoding + displaying 60 fps
[13:43:36 CEST] <kurosu> fritsch, yes, and it's indeed very narrow in that case
[13:43:46 CEST] <fritsch> we worked with intel mesa people
[13:43:49 CEST] <kurosu> that 4 cores+HT does 80fps
[13:43:56 CEST] <fritsch> and got zero copy nv12 share via drm
[13:44:12 CEST] <fritsch> 4k at 60p is no issue anymore even on celeron 1037U
[13:44:17 CEST] <wm4> fritsch: how well does the EGL interop work? any problems?
[13:44:20 CEST] <kurosu> I meant main10
[13:44:24 CEST] <fritsch> wm4: none at all
[13:44:25 CEST] <kurosu> main8 is like 120fps
[13:44:28 CEST] <fritsch> kurosu: ouh main10 :-)
[13:44:36 CEST] <fritsch> no main10 support in vaapi at all
[13:44:39 CEST] <wm4> fritsch: sounds almost too good to be true
[13:44:46 CEST] <fritsch> wm4: you can try it? usb stick ready?
[13:45:02 CEST] <wm4> fritsch: sure
[13:45:02 CEST] <fritsch> wm4: you are the mpv maintainer aren't you?
[13:45:06 CEST] <wm4> yes
[13:45:20 CEST] <kurosu> he has a skylake iirc, that can decode 4k120/ level 6.2 iirc
[13:45:21 CEST] <fritsch> yeah and you still use glx copy or texture from pixmap?
[13:45:30 CEST] <wm4> I'm waiting until arch updates to mesa 11, because I run that on my macbook
[13:45:35 CEST] <fritsch> so each frame needs to be copied?
[13:45:43 CEST] <wm4> fritsch: texture from pixmap, seems to work slightly better
[13:45:45 CEST] <fritsch> okay, we patched those into mesa 10.6.6
[13:45:49 CEST] <fritsch> not at all
[13:45:53 CEST] <fritsch> ah as glxcopy
[13:45:54 CEST] <fritsch> yes
[13:46:00 CEST] <fritsch> we used texture from pixmap, too
[13:46:08 CEST] <fritsch> but hey - this damn vaapi full rgb scale
[13:46:10 CEST] <wm4> this EGL thing is the ideal API though
[13:46:13 CEST] <fritsch> banding by default
[13:46:15 CEST] <wm4> s/API/mechanism
[13:46:32 CEST] <fritsch> wm4: http://fritsch.fruehberger.net/openelec/
[13:46:36 CEST] <fritsch> pick the newest img.gz, please
[13:46:38 CEST] <fritsch> gunzip it
[13:46:44 CEST] <fritsch> and dd it to an usb stick
[13:46:45 CEST] <fritsch> sync
[13:46:51 CEST] <fritsch> boot it, enter "live" on start
[13:47:08 CEST] <wm4> I'll give it a try
[13:47:10 CEST] <fritsch> it also has bsw hevc support
[13:47:16 CEST] <fritsch> with the fix nevcairiel did yesterday
[13:47:36 CEST] <fritsch> i suggest to enable Adjust refreshrate to match video on start / stop
[13:47:40 CEST] <fritsch> 2nd: disable vdpau
[13:47:48 CEST] <fritsch> 3rd: Sync Playback to Display: yes
[13:47:51 CEST] <fritsch> that's bsaically it
[13:48:00 CEST] <fritsch> you run kodi before?
[13:48:11 CEST] <fritsch> if not - just ask - the user experience is not apple like :p
[13:48:29 CEST] <wm4> not much, I feel like it's not very accessible for testing and debugging
[13:48:35 CEST] <fritsch> exactly
[13:48:38 CEST] <fritsch> we debug remotely
[13:48:41 CEST] <fritsch> via gdbserver
[13:49:16 CEST] <kurosu> I'm actually hesitating between the next gen which should have main10 hw (and vp9), or some amlogic s9xx (which aren't out and hit and miss), instead of leaving to the tv
[13:49:27 CEST] <kurosu> so kodi vs capable tv
[13:49:32 CEST] <fritsch> the amlogic things ...
[13:49:33 CEST] <wm4> fritsch: what significance does sync to display have for EGL interop?
[13:49:37 CEST] <fritsch> do direct VPU to fb
[13:49:42 CEST] <fritsch> no influence on the colors at all
[13:50:03 CEST] <fritsch> wm4: we use swapbuffer as reference clock
[13:50:08 CEST] <fritsch> and resample audio to it
[13:50:09 CEST] <kurosu> i'm not a color freak, and my familly wouldn't care in the least
[13:50:13 CEST] <fritsch> hehe
[13:50:34 CEST] <fritsch> i hope on flags, e.g. that you tell nvidia: give me studio colors and do interop
[13:50:36 CEST] <kurosu> plus I won't wait for that hdr stuff in dvb
[13:50:39 CEST] <fritsch> or give me full range and do interop
[13:50:47 CEST] <fritsch> to not break any given api
[13:50:59 CEST] <fritsch> using nvidia vdpau without glinterop is a nightmare
[13:51:07 CEST] <fritsch> especially older readeons are slow as hell
[13:51:11 CEST] <fritsch> and it is unusable here
[13:51:31 CEST] <fritsch> iirc we implemented vdpau for amd the same time as zgreg did for mpv wm4 
[13:52:52 CEST] <wm4> fritsch: hm? mpv vdpau support is inherited from mplayer; I know zgreg did some AMD/Mesa driver work, but that is orthogonal to mpv
[13:53:03 CEST] <wm4> fritsch: btw. what kind of vdpau gl interop are you using?
[13:53:03 CEST] <fritsch> ah oh
[13:53:11 CEST] <fritsch> we use gl interop
[13:53:15 CEST] <wm4> do you go over the videomixer or map the video textures directly?
[13:53:22 CEST] <fritsch> both is possible
[13:53:31 CEST] <fritsch> there is a setting to enable / disable mixer
[13:53:54 CEST] <wm4> hm, I see
[13:54:38 CEST] <wm4> we just use the videomixer, so vdpau postprocessing can always be used
[13:54:58 CEST] <wm4> also the "interlaced" representation of the video textures is icky
[13:55:28 CEST] <fritsch> hehe our interlacing works in a separate thread
[13:55:35 CEST] <fritsch> with 5 surfaces
[13:55:50 CEST] <wm4> shared GL contexts?
[13:56:04 CEST] <fritsch> our vdpau was written by fernetmenta and is yeah - some say a bit overdone
[13:56:46 CEST] <atomnuker> what the hell, I'm no longer getting warnings about mixed variable declaration and code or for (int i = ..) loops
[13:56:55 CEST] <atomnuker> did we switch to using c99 by default?
[13:57:16 CEST] <fritsch> wm4: yeah, https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/VDPAU.cpp
[13:57:53 CEST] <fritsch> see the CThreads
[13:58:03 CEST] <fritsch> actor pattern
[13:58:10 CEST] <fritsch> hard to debug :-)
[13:58:22 CEST] <fritsch> but ckoenig of amd managed that quite well - within 1 day he had finished gl interop
[13:58:52 CEST] <wm4> I've just avoided shared GL contexts as much as I could
[14:14:53 CEST] <wm4> fritsch: hm, can't get the macbook to boot from the stick... usually works with other linux distros
[14:16:39 CEST] <fritsch> you got a legacy mode?
[14:16:45 CEST] <fritsch> perhaps it does not like our uefi hacks
[14:17:15 CEST] <wm4> refind doesn't üick it up either
[14:17:18 CEST] <wm4> *pick
[14:17:58 CEST] <fritsch> not good - any other computer to test?
[14:20:32 CEST] <wm4> does openelec mount any linux partitions it finds on other disks on the computer?
[14:24:30 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:6bed88ac78c2: avformat/flvdec: Print terminator value found if it differs from AMF_END_OF_OBJECT in AMF_DATA_TYPE_MIXEDARRAY
[14:24:30 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:fd6296e412ed: avformat/flvdec: Print last packet size at trace level
[14:24:30 CEST] <cone-705> ffmpeg 03Michael Niedermayer 07master:56291434335c: avformat/flvdec: Use the first index entry to find the first packet if there was a parsing error in the header
[14:38:20 CEST] <fritsch> wm4: yeah
[14:38:25 CEST] <fritsch> wm4: :-)
[14:38:38 CEST] <fritsch> wm4: so you got it to boot?
[14:38:49 CEST] <wm4> that would break software suspend, so I can't try it on my desktop pc
[14:39:12 CEST] <fritsch> good that you asked in advance
[14:39:28 CEST] <fritsch> oki - then no idea, sorry
[14:39:32 CEST] <fritsch> you run ubuntu?
[14:39:37 CEST] <fritsch> if yes - i can give you ppas
[14:39:40 CEST] <fritsch> ah no you said arch
[14:40:14 CEST] <wm4> debian on the desktop
[14:40:22 CEST] <fritsch> no ppa for debian, sorry
[14:40:25 CEST] <wm4> arch on the macbook, because it was the first that installed at all there
[14:40:45 CEST] <fritsch> advantage of drm
[14:41:05 CEST] <fritsch> a) NV12 is directly copied -> no color banding, we add dithering 8 bit if we scale to full or keep it as is if output is limited
[14:41:11 CEST] <fritsch> b) high performance
[14:41:14 CEST] <wm4> fritsch: did you guys get intel to implement the EGL interop by bugging them?
[14:41:14 CEST] <fritsch> that's basically it :-)
[14:41:20 CEST] <fritsch> nope - I asked nicely
[14:41:34 CEST] <fritsch> i told gb that his buffer export api sucks, as we can only transfer RGB
[14:41:38 CEST] <fritsch> hehe
[14:41:45 CEST] <fritsch> then we came into discussion with ben widawski
[14:41:48 CEST] <fritsch> and chad versace
[14:41:54 CEST] <fritsch> and chad said: i do it for you
[14:42:01 CEST] <fritsch> one day later it was done + piglit tested and accepted
[14:42:10 CEST] <fritsch> chad versary is his name
[14:42:52 CEST] <wm4> nice work then
[14:43:04 CEST] <fritsch> s/copied/reused/
[14:43:06 CEST] <fritsch> we don't copy
[15:39:13 CEST] <durandal_1707> some doom folks don't understand simple filters like w3dif and think it is simpler kerndeint
[16:23:06 CEST] <fritsch> wm4: ^^ we just got a bug
[16:25:01 CEST] <wm4> in vaapi's EGL code?
[16:25:05 CEST] <fritsch> nope
[16:25:10 CEST] <fritsch> in some hls change
[16:25:17 CEST] <fritsch> old kodi, old mpv work
[16:25:22 CEST] <fritsch> only change: ffmpeg bump I think
[16:25:35 CEST] <fritsch> Ticket #4846
[16:26:16 CEST] <wm4> ah
[16:30:00 CEST] <wm4> at least I can confirm the regression
[16:32:26 CEST] <wm4> playback abort doesn't work either
[16:32:32 CEST] <wm4> (interrupt callback)
[17:38:50 CEST] <j-b> a1m
[18:35:13 CEST] <philipl> Why is v408/ayuv an encoder/decoder instead of a pixel format?
[18:44:19 CEST] <durandal_1707> because swscale experience points are impossible to get?
[18:48:44 CEST] <nevcairiel> philipl: because packed formats are terribly annoying :D
[19:10:56 CEST] <philipl> durandal_1707: Right. My attempt at a pixel format is still sitting here, still clearly broken.
[19:12:09 CEST] <durandal_1707> you don't need big endian variant
[19:12:43 CEST] <philipl> No, but that's not really the problem.
[19:12:44 CEST] <durandal_1707> look how uyvy is handled
[19:12:51 CEST] <philipl> I tried. It didn't help.
[19:14:01 CEST] <durandal_1707> what happened wrong colors or everything shifted wrong?
[19:14:05 CEST] <philipl> I tried basing it on the 16bit version and scaling it to 8bits but I've done something wrong.
[19:14:31 CEST] <philipl> Well, I did it to try and feed into vdpau, which nominally claims to support 444 using a packed format in a specific way.
[19:14:45 CEST] <philipl> That ends up on screen too dark. Colours appear correct but it's all way too dark.
[19:15:00 CEST] <philipl> If I try and fiddle the shifts a bit it looks worse in either direction.
[19:15:02 CEST] <durandal_1707> no, base it on uyvy version
[19:15:27 CEST] <philipl> But it's complicated by the fact that vdpau can only display it through a call that also requires a colourspace conversion matrix.
[19:15:33 CEST] <philipl> So it's possible that's where that problem is.
[19:15:59 CEST] <philipl> But I tried with standard 601 and 709 and it didn't seem to make a difference.
[19:16:26 CEST] <philipl> I tried a round trip conversion and everything came out shades of green.
[19:16:52 CEST] <philipl> the input side seems simple enough that I'm pretty sure I got that right
[19:32:14 CEST] <ubitux> durandal_1707: some data here if you want btw: http://b.pkh.me/sc.py
[19:34:16 CEST] <ubitux> well, let's see if i can guess something obv from the slope
[19:37:33 CEST] <philipl> durandal_1707: So I've tried to base in yuyv and now it looks pink instead of dark.
[19:38:10 CEST] <durandal_1707> wrong order of yuv?
[19:39:11 CEST] <philipl> I need to try more combinations...
[19:50:08 CEST] <philipl> durandal_1707: I don't think so. I think I've identified the elements correctly. I know which is Y and which is A and switching U/V just gives me different types of pink. The shifts are wrong.
[19:50:18 CEST] <philipl> but they're the same as in yuyv
[19:57:12 CEST] <BBB> philipl: pink means all bits set to 1, right?
[19:57:19 CEST] <BBB> philipl: is this 8bpc or more?
[19:58:00 CEST] <philipl> 8bpc output
[19:58:09 CEST] <BBB> ok then no idea sorry
[19:58:16 CEST] <BBB> for higher bpc sometimes unused bits are not zero
[19:58:31 CEST] <BBB> is it possible chroma bits are not unsigned? i.e. you need to ^ 0x80 them
[19:58:39 CEST] <BBB> that would be weird, but & who knows
[19:59:58 CEST] <philipl> Maybe. That's what I was roughly doing when based on the ayuv64 code
[20:00:16 CEST] <philipl> and it looked more correct.
[21:07:50 CEST] <cone-464> ffmpeg 03Paul B Mahol 07master:a0a2ca024bd0: avfilter/af_ladspa: support simpler syntax for controls
[21:43:01 CEST] <cone-464> ffmpeg 03Paul B Mahol 07master:39c61d845947: avfilter: add audio limiter filter
[22:42:26 CEST] <cone-464> ffmpeg 03Ganesh Ajjanagadde 07master:d13a2df8de62: avfilter/vsrc_mandelbrot: use the name 's' for the pointer to the private context
[00:00:00 CEST] --- Mon Sep 14 2015