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

[burek]

[00:51:20 CEST] <philipl> jkqxz: care to look at my last diff on the cuvid hwaccel stuff?
[01:05:59 CEST] <cone-658> ffmpeg 03KongQun Yang 07master:45dbb40cd1b3: Update mp4 object type for VP9
[05:21:23 CEST] <LongChair> @jkqxz : you more likely need to rebuild mpp from here, i guess the image you got doesn't have a recent one https://github.com/rockchip-linux/mpp
[05:22:31 CEST] <LongChair> jkqxz: by the way started the update work : https://github.com/LongChair/FFmpeg/commits/rockchip-new
[05:51:59 CEST] <LongChair> jkqxz: your patch also seems to lack the deployment of hwcontext_drm.h (see one of the latest commits on my GH)
[06:20:20 CEST] <LongChair> jkqxz, wm4: i was looking in using that format (with mpv & egl first). The only annoying thing from usage point of view is typical DRM_FORMAT_NV12 format which basically means i have 2 sets of offset/pitches (one for Y, one for UV), then i have one format and one fd for the whole thing. handling this in a generic way means that i have to browse planes and check if the DRMPlaneDescriptor.format changed to know if i need to switch textures. 
[06:20:20 CEST] <LongChair> in only one texture, where the vaapi format would result in 2 textures if i got it right. Ofc this is doable, just adds a bit of complexity in the code. But I guess that this is what you guys expected ? :)
[06:45:02 CEST] <LongChair> just wondering if something like this wouldn't be easier to work with https://gist.github.com/LongChair/710d25ed60adce5b2ec146737226f0c9
[11:08:45 CEST] <jkqxz> LongChair:  Doesn't that duplicate the file descriptor for Intel?  (One of the things we were strongly trying to avoid.)
[11:09:16 CEST] <jkqxz> Also it's missing the object sizes.
[11:11:19 CEST] <jkqxz> That version on github doesn't have MPP_DEC_GET_FREE_PACKET_SLOT_COUNT either.  Do you have a git hash for the version you are using?
[14:09:06 CEST] <thardin> TIL about a new old format: windows metafile (wmf)
[14:11:04 CEST] <RiCON> it's been used for something other than an exploit?
[14:11:38 CEST] <thardin> it's used as output format of some vibration testing program
[14:13:14 CEST] <thardin> swedish institute of space physics has an old P3 running XP that spits out such files (in addition to a rawer binary data form)
[14:13:45 CEST] <thardin> I recall kostya ranting about formats like this. struct dumps of GDI calls
[14:16:51 CEST] <thardin> like that screen capture program for win3.1
[14:57:20 CEST] <wm4> what is no_rasl_output_flag in hevcdec?
[14:58:49 CEST] <wm4> anyway I'm trying to fix that someone seems to have codec the idea into hevcdec that mastering display data side data should be emited only on an irap, not every frame
[14:58:52 CEST] <wm4> which is nonsense
[15:01:13 CEST] <JEEB> huh
[15:13:50 CEST] <wm4> urgh it has to do with frame threading
[15:19:12 CEST] <nevcairiel> no_rasl_output_flag is in the spec
[15:20:18 CEST] <nevcairiel> see NoRaslOutputFlag
[15:20:39 CEST] <nevcairiel> its some condition for random access and frame output
[15:20:59 CEST] <Th3On3> hi there... i am trying to build ffmpeg under windows, using msys2 and after i installed the packages needed to build, i go to ffmpeg rootpath i execute a default command: "./configure --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config" and i get a "Unknown option: --target-os=mingw32". What am i doing wrong ????? 
[15:28:09 CEST] <BBB> whats wrong with that flag?
[15:28:12 CEST] <BBB> I thought I fixed it?
[15:28:32 CEST] <wm4> BBB: probably nothing
[15:28:46 CEST] <wm4> also naively copying some sei stuff in hevc_update_thread_context appears to fix it
[15:28:54 CEST] <wm4> but I have no idea how this is supposed to work
[15:31:13 CEST] <wm4> does anyone have a hevc sample with a53 captions?
[15:31:27 CEST] <wm4> also why the fuck are people using hevc with a53 captions?
[15:40:14 CEST] <Th3On3> who can help me ? 
[15:40:23 CEST] <Th3On3> hi there... i am trying to build ffmpeg under windows, using msys2 and after i installed the packages needed to build, i go to ffmpeg rootpath i execute a default command: "./configure --arch=x86 --target-os=mingw32 --cross-prefix=i686-w64-mingw32- --pkg-config=pkg-config" and i get a "Unknown option: --target-os=mingw32". What am i doing wrong ????? 
[15:42:05 CEST] <J_Darnley> configure quite clearly says
[15:42:34 CEST] <wm4> "What am i doing wrong ????? " <- everything, there us no user help in this channel
[15:45:28 CEST] <wm4> is, even
[15:45:37 CEST] <Th3On3> ok ty
[15:45:48 CEST] <wm4> try #ffmpeg
[15:46:53 CEST] <Th3On3> yes... i am trying
[15:46:54 CEST] <Th3On3> ty
[15:59:42 CEST] <cone-746> ffmpeg 03Paul B Mahol 07master:4d681269e096: avcodec/gdv: add decompression for 2 and 5 method
[16:09:46 CEST] <TMM> durandal_170, sorry for causing those fuzzing errors on mve, I thought that bytestream2 would prevent most of those by itself, sorry.
[16:11:27 CEST] <TMM> durandal_170, if you'd prefer I can go over those crashes myself in the future
[16:12:20 CEST] <durandal_170> TMM: there is one open crash repot
[16:12:30 CEST] <RiCON> BBB: 840b41b2a seems to have broken yuv444p10 decoding
[16:12:54 CEST] <TMM> durandal_170, ok, I'll try to figure it out. I don't want to patch and run :)
[16:15:17 CEST] <TMM> durandal_170, so, you're not supposed to rely on bytestream2 then to prevent overreads? You have to check before reading anyway?
[16:15:22 CEST] <wm4> BBB, RiCON: and the sample was https://0x0.st/0rJ.mkv I think?
[16:16:13 CEST] <RiCON> yeah, the SEI errors are probably to the stripping of x264 information
[16:16:49 CEST] <nevcairiel> if you have a file that was encoded with old x264, then strip its SEI and then complain that it doesnt decode right ... then your file is just broken :)
[16:17:14 CEST] <nevcairiel> because old x264 produced broken files
[16:17:40 CEST] <BBB> I was going to say, was this file generated with old x264 but not signaled as such?
[16:18:05 CEST] <durandal_170> TMM: crash is in overwrites
[16:18:54 CEST] <TMM> durandal_170, I was looking at your other patches 
[16:19:18 CEST] <BBB> you could probably write a bitstream modifier (filter?) to parse the h264 stream and rewrite it using the fixed context?
[16:19:21 CEST] <BBB> I wonder how hard that would be
[16:19:36 CEST] <BBB> then you can manually insert it if the SEI is stripped
[16:19:37 CEST] <nevcairiel> the commit suggests its in cabac, so possibly annoying
[16:19:39 CEST] <durandal_170> TMM: those are not overreads, just invalid args passed to function
[16:19:39 CEST] <BBB> and keeps h264dec clean
[16:19:42 CEST] <BBB> but maybe not worth it
[16:19:52 CEST] <BBB> well a bitstream filter can use cabac
[16:19:56 CEST] <BBB> Im not saying this is easy
[16:19:57 CEST] <BBB> :-p
[16:20:05 CEST] <BBB> Im just saying it can be done
[16:22:18 CEST] <RiCON> so vlc/mpc-hc/lavfilters happen to work because they use older commits and will be broken later?
[16:23:48 CEST] <nevcairiel> yeah, h264dec was mostly written against libx264 streams, so some odd parts of the spec that were wrong in  x264 were also wrong in h264dec, but standards compliance should obviously be preferred - and any "broken" streams should probably retain the SEI to identify them as such
[16:27:20 CEST] <nevcairiel> one of the more annoying problems is however that if you try to start playback from the middle of such a file, the decoder might actually never see the SEI in the first place
[16:30:14 CEST] <jamrial> nevcairiel: mkv and mp4 both should have the SEI in extradata. problem would i guess be raw streams, and maybe mpegts
[16:30:30 CEST] <nevcairiel> mkv and mp4 dont specify SEI in h264 extradata
[16:31:19 CEST] <nevcairiel> unless they amended the specs at some point
[16:31:26 CEST] <nevcairiel> in which case h264dec probably doesnt read it
[16:31:26 CEST] <jamrial> they do, hvcc extradata contains sei
[16:31:40 CEST] <nevcairiel> wrong codec =p
[16:31:54 CEST] <TMM> durandal_170, one of your changes broke the simcity movie playback 
[16:32:15 CEST] <durandal_170> TMM give sample
[16:32:45 CEST] <TMM> durandal_170, https://trac.ffmpeg.org/ticket/4740 the one in this ticket
[16:33:10 CEST] <TMM> durandal_170, there seem to be artifacts now that weren't there before, I'm reverting everything now to make sure I'm not hallucinating 
[16:33:52 CEST] <jamrial> nevcairiel: ah yeah, whoops :p
[16:33:55 CEST] <durandal_170> TMM: please give sample name
[16:35:03 CEST] <TMM> durandal_170, I don't understand what you want
[16:36:16 CEST] <TMM> durandal_170, http://samples.mplayerhq.hu/game-formats/interplay-mve/MARIO1.MVE <-- that one shows the same problem in the beginning now 
[16:36:46 CEST] <TMM> durandal_170, if I revert all your changes it plays correctly
[16:38:53 CEST] <TMM> durandal_170, is that the correct information? That sample url? Or do you need something else?
[16:44:34 CEST] <cone-746> ffmpeg 03Paul B Mahol 07master:3821c004e260: avcodec/interplayvideo: fix regression causing artifacts
[16:56:55 CEST] <TMM> durandal_170, looks good again, thanks :)
[18:01:32 CEST] <cone-746> ffmpeg 03Clément BSsch 07master:2658e66cd1be: lavu/cpu: disable MMX warning on non x86 platforms
[18:11:57 CEST] <tdjones> What is the best way to encode multiple short packets during a single call to encode_frame in an audio encoder if the total number of output samples is constant?
[18:13:07 CEST] <atomnuker> tdjones: you can only output 1 packet per encode_frame
[18:13:25 CEST] <nevcairiel> with the new api you can just not consume more input tho
[18:14:57 CEST] <atomnuker> you could always do that (this is for the vorbis encoder, not for api users)
[18:15:20 CEST] <tdjones> I should've clarified that, sorry nevcairiel.
[18:16:46 CEST] <tdjones> If I'm understanding it correctly, each short window of samples must be in a separate ogg page, so each window must be a separate packet?
[18:19:22 CEST] <atomnuker> right, so there's no way for the encoder to signal it doesn't need any input right now
[18:20:02 CEST] <atomnuker> just mark it in your context that you'll be outputting a transient, you already have a lookahead so you know how long it'll last
[18:20:27 CEST] <atomnuker> and you just output them 1 short window at a time, and you'll be supplied with a new avframe which you just reference in your queue
[18:21:29 CEST] <atomnuker> throughput and waiting isn't a problem since one short window is always going to be more than or equal to the frame size so you won't see the API user starved of frames
[18:21:44 CEST] <atomnuker> (or rather samples)
[18:23:26 CEST] <nevcairiel> like i hinted to above, if you use the new API you can control when you receive new input - but of course that would mean that the encoder doesnt work for anyone using the old public API
[18:24:13 CEST] <wm4> <nevcairiel> one of the more annoying problems is however that if you try to start playback from the middle of such a file, the decoder might actually never see the SEI in the first place <- this is indeed a problem
[18:24:28 CEST] <atomnuker> nevcairiel: it is? how?
[18:24:30 CEST] <wm4> already got a second report with a similar sample that works when decoding from the beginning, but not with seeking
[18:25:44 CEST] <wm4> also can someone ack my hevc patch?
[18:26:42 CEST] <BBB> ack
[18:26:43 CEST] <BBB> :-p
[18:26:48 CEST] <BBB> or you want it on ml?
[18:27:12 CEST] <wm4> the latter (I'd also add a micro bump so the bug fix can be detected by API users)
[18:27:26 CEST] <wm4> s/ack/review/
[19:42:22 CEST] <durandal_1707> what solution to pick for unaligned filtering?
[19:43:11 CEST] <durandal_1707> clearly interlace filter thinks it will allways get aligned frame
[19:55:42 CEST] <durandal_1707> michaelni: fine to push prores patch?
[21:29:29 CEST] <J_Darnley> An odd question...  Does the count argument given to avctx.execute2\? signal the maximum number of things that can be executed in parallel?
[21:34:56 CEST] <atomnuker> wut?
[21:35:11 CEST] <atomnuker> no, that's detemined by the thread count
[21:35:43 CEST] <atomnuker> well, its the FFMIN(thread count, count)
[21:36:11 CEST] <J_Darnley> Ah.  That is what I think I wanted to know.
[21:36:25 CEST] <atomnuker> you shouldn't care about how many threads there are, all your inputs and outputs should be independent
[21:37:03 CEST] <J_Darnley> I don't I'm just trying to track what values go where
[21:48:15 CEST] <kierank> J_Darnley: in vc-2 a thread can either be decoding the coeffs of a slice
[21:48:18 CEST] <kierank> or doing the transform
[21:48:29 CEST] <kierank> (ignore the fact you can thread planes)
[21:48:43 CEST] <kierank> at the moment we decode all slices then do the transform single threaded
[21:48:48 CEST] <kierank> (again ignore chroma planes)
[22:05:19 CEST] <atomnuker> (actually the transform is per-plane threaded)
[22:07:22 CEST] <kierank> atomnuker: that's what I said ;)
[22:28:59 CEST] <J_Darnley> Who was the retard at Lenovo who thought it was a good idea to put the battery status light on the side of this shitty laptop?
[22:30:54 CEST] <atomnuker> the same one that only looked that the windows battery status on the taskbar?
[22:31:55 CEST] <atomnuker> nevcairiel: ping, how do you signal you don't want any input from an encoder (with the new api)?
[22:33:52 CEST] <iive> J_Darnley: how else would you see the battery status when the laptop is closed?!
[22:35:53 CEST] <J_Darnley> I think I need to configure a bigger flashier warning
[22:44:37 CEST] <Compn> J_Darnley : probably you can hack the keyboard leds to indicate battery
[22:44:49 CEST] <durandal_1707> atomnuker: have you managed to complete something?
[22:45:42 CEST] <RiCON> J_Darnley: someone who liked macbooks doing the same
[22:45:49 CEST] <LongChair> jkqxz: you want to use the "for_linux" mpp branch
[22:45:55 CEST] <atomnuker> durandal_1707: not yet, I have a dayjob, you know?
[22:46:55 CEST] <durandal_1707> atomnuker: quit it, come work for me!
[22:54:44 CEST] <Compn> durandal_1707 : what are you paying ?
[22:55:13 CEST] <durandal_1707> food only
[22:58:39 CEST] <J_Darnley> Good it managed to restore from hibernate today
[23:10:10 CEST] <durandal_1707> atomnuker: so how you plan to make bireader fast on both x86 and x64?
[23:12:05 CEST] <atomnuker> dunno... since everything would use the same API I was thinking get_bits.h would just include get_bits_cached.h on 64 and get_bits_uncached on 32 bit systems
[23:12:59 CEST] <atomnuker> or I could probably just ifdef a typedef on the storage type used for the cache to 32 bits
[23:13:03 CEST] <durandal_1707> what would cached have?
[23:13:38 CEST] <atomnuker> (in fact I think I'll do that first rather than leave the 2)
[23:13:46 CEST] <atomnuker> the libav bitstream reader
[23:15:32 CEST] <durandal_1707> i think better approach is just increasing cache with define in existing header
[23:16:09 CEST] <atomnuker> the issue is the cache is not kept anywhere and looking at vlc decoding theirs does less operations to read
[23:16:26 CEST] <atomnuker> extending the current reader to keep a cache also isn't easy
[23:16:57 CEST] <iive> there used to be a bitstream reader that kept cache
[23:16:57 CEST] <atomnuker> since some things like the cabac reader and some codecs do their own caching and updating
[23:17:47 CEST] <durandal_1707> iive: how big cache?
[23:18:42 CEST] <iive> 2x32bit iirc
[23:19:18 CEST] <durandal_1707> probably didnt helped with get vlc2
[23:19:54 CEST] <wm4> I thought it helps to simply copy the bit reader state to the stack?
[23:20:03 CEST] <wm4> since the compiler won't be plagued by possible aliasing anymore
[23:21:23 CEST] <iive> what aliasing?
[23:22:00 CEST] <wm4> pointers
[23:22:48 CEST] <wm4> functions using the bitstream reader typically have the bitstream state as pointer argument
[23:24:07 CEST] <iive> i still don't understand what aliasing you are talking about...
[23:26:18 CEST] <kierank> rcombs: still in London?
[23:27:28 CEST] <durandal_1707> kierank: i still want it
[23:30:12 CEST] <kierank> durandal_1707: I will give it if I can upload
[23:50:42 CEST] <kurosu> hi, regarding libav bitstream reader, I'm no longer able to publish what I've done
[23:50:52 CEST] <kurosu> but you can somewhat contrive it to use native reg size
[23:51:52 CEST] <kurosu> unfortunately, can break easily, as soon as you read more than 16 bits, so you need to do 8b/16b reloads instead of 32b-always for 64b archs
[23:52:04 CEST] <kurosu> Then LONG_BITSTREAM_READER requires it to be dynamical
[23:52:17 CEST] <kurosu> ie if LONG_BITSTREAM_READER, you can't use native reg size
[23:53:15 CEST] <kurosu> or you spend a lot of time finding the one function call that does read more than 24b on occasion, and then you use bitstream_read_63 for instance
[23:54:52 CEST] <kurosu> https://pastebin.com/HbtRpjA9 <- benchmarks to see on HSW-E/x86832 whether using 32b regs was effective: it is
[23:55:24 CEST] <jamrial> hi kurosu
[23:55:26 CEST] <jamrial> why is that?
[23:55:42 CEST] <kurosu> ah, and some codecs like to do 32b reads (_xbits, exp-golomb), so one can try to reduce what it reads
[23:55:48 CEST] <kurosu> why is that what ?
[23:56:00 CEST] <jamrial> not being able to publish what you've done
[23:56:43 CEST] <kurosu> because I had always done that pro bono, and it became difficult to manage that with $payjob
[23:57:04 CEST] <kurosu> and also freetime greatly reduced
[23:57:12 CEST] <jamrial> ah, i see :(
[23:58:22 CEST] <kurosu> same, module extracting the joint table feature of huffyuvdec to use it in eg magicyuv or actually any huffman-based lossless decoder
[23:59:16 CEST] <kurosu> libav bitstream reader + that is like >2x time speedup on those codecs
[00:00:00 CEST] --- Fri Jun 30 2017