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

[burek]

[01:08:54 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:df820af2c502: avcodec/error_resilience: Improve missing slice handling for mpeg2
[01:08:55 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07master:dc34fa6a9e64: avformat/riff: add M702
[03:39:58 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:74b8c4a60bb9: avformat/options_table: Add missing identifier for very strict compliance
[03:39:59 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:342b6d371895: avcodec/mjpegdec: Do not try to detect last scan but apply idct after all scans for progressive jpeg
[04:09:27 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07release/2.6:063382610fe3: Changelog: update for the last 2 commits
[04:13:12 CEST] <cone-273> ffmpeg 03Carl Eugen Hoyos 07release/3.0:e675926a4fa6: lavf/mpegts: Return small probe score for very short transport streams.
[04:13:13 CEST] <cone-273> ffmpeg 03foo86 07release/3.0:08c21bcb5dfd: avcodec/dca: fix sync word search error condition
[04:25:14 CEST] <cone-273> ffmpeg 03Michael Niedermayer 07n2.6.9:HEAD: avformat/riff: add M702
[09:24:08 CEST] <cone-282> ffmpeg 03Christophe Gisquet 07master:7d453aaf653d: wmalossless: allow calling madd_int16
[10:52:00 CEST] <cone-282> ffmpeg 03Carl Eugen Hoyos 07master:80d14de52db8: lavf/mpegts: Add E-AC3 registered stream specifier "EAC3".
[11:05:52 CEST] Action: Daemon404 sees absolutely noone helped merge while he has been busy 
[11:18:32 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:ad9d3384de08: svq3: move the dequant buffer to SVQ3Context
[11:18:33 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:12f13ecb2dcd: svq3: move mb strides/sizes to the SVQ3Context
[11:18:34 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:5a5db90edf71: svq3: move pict_type to the SVQ3Context
[11:18:35 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:297e2768dab3: Merge commit 'ad9d3384de08f02967d6eb11196ee8c78e8b2dba'
[11:18:36 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:1bfbdb8f0b81: Merge commit '12f13ecb2dcddfa3ee930167395370d3c6fff90c'
[11:18:37 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:5db920bcb605: Merge commit '5a5db90edf71ef4c60db8ad7b0ebaa9a810c2d9e'
[11:29:19 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:939b388383db: svq3: eliminate remaining H264SliceContext usage
[11:29:20 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:21b746932241: svq3: eliminate H264Context.cur_pic usage
[11:29:21 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:ea6ab02a174b: svq3: move the frame num variables to the SVQ3Context
[11:29:22 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:1848a154a49d: svq3: stop using H264Context.gb
[11:29:23 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:7bbdae81e895: svq3: move block_offset to SVQ3Context
[11:29:24 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:2d3cc682c4c4: Merge commit '939b388383db8d0db5b2ff483e3a197c27b79791'
[11:29:26 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:014fb816d104: Merge commit '21b746932241246be846a133abb3c5f91b1cab85'
[11:29:27 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:8bba752ae95f: Merge commit 'ea6ab02a174bcc11f3eaa1b840c9a4c895968690'
[11:29:27 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:f32a23c84912: Merge commit '1848a154a49d18c1f31f54ee75c7445dc49a7ecc'
[11:29:29 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:2a018be10fc8: Merge commit '7bbdae81e895a49125dba58bad01b98389966c39'
[11:40:15 CEST] <Daemon404> hmm shit.
[11:40:46 CEST] <wm4> shit?
[11:43:49 CEST] <Daemon404> trying to merge the last svq3 patch but it crashes
[11:43:55 CEST] <Daemon404> probably due to hacks
[11:51:13 CEST] <Daemon404> aha got it.
[11:52:39 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:a4d126dc59c3: svq3: eliminate remaining H264Context usage.
[11:52:40 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:43b7e5aa3204: Merge commit 'a4d126dc59c39bb03e5e444432d1b27af26a45b4'
[12:00:29 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:add1467e5e44: svq3: drop the build dependency on the h264 decoder
[12:00:30 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:a454ad670c77: Merge commit 'add1467e5e447b79e8743a0b05c54dcf58c61dfe'
[12:00:33 CEST] <Daemon404> svq3 = done
[12:01:12 CEST] <Daemon404> now, coffee, then maybe more merges whilst i deal with some irl annoyance.
[12:10:12 CEST] <wm4> what can I say, thanks for doing this
[13:21:41 CEST] <kierank> BBB: https://www.linkedin.com/pulse/another-vp9-codec-former-team-member-rsbultje-james-bankoski?trk=hp-feed-article-title-like
[13:27:49 CEST] <BBB> thats true :)
[13:54:51 CEST] <thardin> jeez, linkedin is slow
[13:59:54 CEST] <Daemon404> thardin, so are the people on it
[14:00:01 CEST] <Daemon404> /s
[14:00:40 CEST] <thardin> too contrarian
[14:00:58 CEST] <thardin> gotta keep it just right
[14:11:18 CEST] <Compn> but is ~5x slower.
[14:11:21 CEST] <Compn> in the trash it goes
[14:11:38 CEST] <Compn> doh he left
[14:16:35 CEST] <cone-282> ffmpeg 03Carl Eugen Hoyos 07master:fd0f1442eb78: lavf/mpegtsenc: Fix stream_type for low sample rate MP2/MP3.
[14:31:56 CEST] <nevcairiel> gnu did it again, latest binutils (2.26) seems to not build with gcc 6.1 :)
[14:32:09 CEST] <Daemon404> -Werror again?
[14:32:13 CEST] <nevcairiel> probably
[14:32:34 CEST] <nevcairiel> ../../../source/binutils-2.26/gas/config/tc-i386.c: In function 'optimize_imm':
[14:32:34 CEST] <nevcairiel> ../../../source/binutils-2.26/gas/config/tc-i386.c:4222:53: error: result of '2l << 31' requires 34 bits to represent, but 'long int' only h
[14:32:34 CEST] <nevcairiel>    && ((i.op[op].imms->X_add_number & ~(((offsetT) 2 << 31) - 1))
[14:33:22 CEST] <Daemon404> thats some nice operator soup
[14:33:27 CEST] <Daemon404> also >long
[14:42:50 CEST] <cone-282> ffmpeg 03Anton Khirnov 07master:a7829a2a3f8e: h264: reimplement 3aa661ec5 in a more explicit way
[14:42:51 CEST] <cone-282> ffmpeg 03Derek Buitenhuis 07master:7966ddfc0bb7: Merge commit 'a7829a2a3f8e6ec0b9f2673c11f56916800aeb33'
[14:47:31 CEST] <Daemon404> nevcairiel, ping, need help with a merge
[14:47:33 CEST] <Daemon404> or wm4 or ubitux 
[14:47:37 CEST] <jkqxz> Daemon404:  The next commit (ca2f19b9cc37be509d85f05c8f902860475905f8) breaks some hwaccel decodes because it changes the meaning of some parsing that they rely on (fixed later).  How do you deal with that sort of thing in merging?
[14:47:46 CEST] <ubitux> Daemon404: yes?
[14:47:48 CEST] <Daemon404> https://git.libav.org/?p=libav.git;a=commit;h=ca2f19b9cc37be509d85f05c8f902860475905f8
[14:47:57 CEST] <Daemon404> ^ im nto qualified to do this probably
[14:48:02 CEST] <Daemon404> nevcairiel probably is.
[14:48:25 CEST] <Daemon404> jkqxz, generally we cherry pick the commit that fixes them 
[14:48:29 CEST] <Daemon404> and then skip merging it later
[14:51:53 CEST] <wm4> I don't think I'm qualified either
[14:52:00 CEST] <mike_cook> I have a question about using VDPAU HW accelerated decoding with FFMPEG.  May I ask it here?
[14:52:03 CEST] <wm4> let me guess, the hard part is ffmpeg specific hacks?
[14:52:04 CEST] Action: Daemon404 stares at nevcairiel 
[14:52:16 CEST] <Daemon404> wm4, i dont know if theyre hacks or just features
[14:52:21 CEST] <Daemon404> we have some slicey stuff
[14:52:25 CEST] <Daemon404> i dont know h264 very well.
[14:52:29 CEST] <wm4> mike_cook: sure, normally API usage questions go on #ffmpeg, but hwaccels are underdocumented and tricky
[14:55:12 CEST] <jkqxz> Daemon404:  Ok, makes sense.  You want <https://git.libav.org/?p=libav.git;a=commit;h=b3051a460cf02a5b86ff0d1e14abba23ea55ff6d> to go with that one, then (I can easily test it if you don't have kit lying around to do it yourself).
[14:56:07 CEST] <Daemon404> sure
[14:56:17 CEST] <Daemon404> ill poke you when i get to it
[14:56:25 CEST] <nevcairiel> the same patch should apply to dxva as well, but apparently noone ever bothered to send a patch
[14:56:27 CEST] <jkqxz> There was some thought that old dxva2 might be broken as well, but noone could come up with any hardware to test it on.  So, maybe, and nothing in libav.
[14:56:32 CEST] <Daemon404> waiting on nevcairiel to slap me around a bit about nal parsing first
[14:56:39 CEST] <mike_cook> OK. Thank you. I have implemented HW acceleration in my project.  And it works OK.  I currently use VdpVideoSurfaceGetBitsYCbCr to retrieve YUV data from the VDPAU surface into my app.  I see a ~100% CPU usage using this technique.  I can retrieve the surface in RGBA format using VdpOutputSurfaceGetBitsNative, and this technique uses only ~2% CPU, but I need the pixels in YUV - not RGBA.  Is there a way for me to get the native get bits speed but 
[14:56:39 CEST] <mike_cook> have it return YUV? 
[14:57:58 CEST] <BtbN> did you look at how ffmpeg extracts the data?
[15:00:35 CEST] <mike_cook> BtbN: is that a question for me?  I was not aware that FFMpeg was involved...  I am making a call directly to the VDPAU driver.
[15:01:07 CEST] <wm4> ffmpeg CLI has its own code to do something similar
[15:01:18 CEST] <BtbN> it's in lavu, ffmpeg cli just uses it.
[15:01:18 CEST] <wm4> actually, in git, this code was moved to libavutil, so everyone can use it
[15:02:01 CEST] <BtbN> from a quick look, ffmpeg just calls VDP_FUNC_ID_VIDEO_SURFACE_GET_BITS_Y_CB_CR
[15:02:09 CEST] <BtbN> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/hwcontext_vdpau.c;h=37b740eaad124ab977200b398e835aca7ce2ceed;hb=HEAD#l289
[15:02:47 CEST] <BtbN> And i don't remember the ffmpeg cli using tons of CPU, so I'd guess you are doing something wrong.
[15:04:29 CEST] <mike_cook> It's 100% possible that I am doing something incorrectly.  But there's not much to it.  :-)
[15:05:59 CEST] <nevcairiel> Daemon404: the patch sure is unreadable
[15:06:13 CEST] <Daemon404> yes...
[15:06:36 CEST] <Daemon404> im really having trouble merging it, and my knowledge of the h264 nal code is not enough
[15:07:19 CEST] <BtbN> Will the avconv_vaapi.c be merged to become ffmpeg_vaapi.c, or does someone have to do that manually?
[15:08:15 CEST] <nevcairiel> Daemon404: first step, ff_h264_decode_nal had a few special cases the the h2645 version probably lost, so those should be re-added to maintain functionality
[15:08:28 CEST] <nevcairiel> then we can see about using it
[15:08:43 CEST] <Daemon404> im pretty sure im not qualified to do that
[15:24:14 CEST] <kierank> Daemon404: oh lord that patch
[15:24:27 CEST] <kierank> if it was me i'd skip it
[15:24:33 CEST] <kierank> the libav h264 parsing is awful
[15:24:35 CEST] <michaelni> Daemon404, 7966ddfc0bb7ee87dc2606b7b146701db6f6c717 breaks tickets/2580/58af5798-fa2c-42a2-997d-dc8e49de2d8a.flv (can be seen quicker with ./ffplay -ss 13 but happens too without if you wait)
[15:26:03 CEST] <Daemon404> how do you even find this stuff
[15:26:23 CEST] <Daemon404> anyway, im not sure how exactly to fix it
[15:26:27 CEST] <Daemon404> perhaps you do?
[15:27:16 CEST] <michaelni> file shuld be here: http://files.cousins-sears.com/0x2m2u110W3H
[15:28:33 CEST] <Daemon404> arent you you teh author of the relevant fix?
[15:33:27 CEST] <michaelni> yes, but iam not motivated to repair every case where someone reimlpements my fix in a difefrent way
[15:34:14 CEST] <Daemon404> thats nice, but im also not an walkign encyclopedia of of magic fixes for every single bug ever fixed in ffmpeg
[15:34:24 CEST] <Daemon404> so either give me a hint, tell me to revert, or fix it
[15:34:32 CEST] <Daemon404> "here is a file, fix it" is not vali.
[15:34:34 CEST] <Daemon404> valid*
[15:35:09 CEST] <michaelni> ok ill try to take a look
[15:35:33 CEST] <Daemon404> (i am very unfamiliar with h264 parser code)
[15:35:42 CEST] <Daemon404> whicg is why i havent done the next merge
[15:35:58 CEST] <durandal_1707> get real job with fully-stocked kitchen with snacks, pop and more
[15:37:52 CEST] <nevcairiel> do we have an example somewhere how to use the swscale chroma position thingy?
[15:38:18 CEST] <Daemon404> kierank's codebase probably has it
[15:38:26 CEST] <Daemon404> maybe in ffmpeg.c too
[15:38:27 CEST] <Daemon404> ?
[15:38:34 CEST] <kierank> nevcairiel: vf_scale has it
[15:39:08 CEST] <wm4> on a related note, does anyone know a good test for chroma positioning issues?
[15:39:58 CEST] <nevcairiel> kierank: i looked at your patch to overwrite the default chroma position, but i got confused because i think thats the default swscale behavior anyway? Or did your patch only fix interlaced?
[15:40:05 CEST] <kierank> fix interlaced
[15:40:10 CEST] <kierank> wm4: there's a video somewhere on trac
[15:40:17 CEST] <nevcairiel> ok so 128 is the same as default progressive as well
[15:47:21 CEST] <wm4> kierank: what should I search for?
[15:47:33 CEST] <kierank> interlaced chroma
[15:47:45 CEST] <kierank> it's a moving ball iirc
[15:53:32 CEST] <wm4> this? https://www.dropbox.com/s/u2lpm6np9re57yi/ffmpeg_chromabug.mpg?dl=1
[15:57:33 CEST] <nevcairiel> these chroma position numbers make no sense, we even have avcodec_enum_to_chroma_pos to generate them, but i still cant make any sense of them
[15:58:50 CEST] <nevcairiel> according to that function, mpeg2 is 128:128, and mpeg1 is 0:0 ... but mpeg2 and mpeg1 only differ on one axis, not on both
[15:59:04 CEST] <michaelni> Daemon404, posted a patch that fixes the file
[16:00:30 CEST] <Daemon404> michaelni, i dont have a problem with the patch, but i also am not qualified to say if is ok or not
[16:07:25 CEST] <michaelni> well, the new code doesnt cover the in stream case, only the extradata case, so until that is fixed by some other means the code is still needed
[16:08:12 CEST] <michaelni> ill apply the patch unless someone wants me to wait 
[16:10:31 CEST] <Daemon404> ok
[16:10:58 CEST] <Daemon404> wm4, its ffmpeg-specific. av_opt_{gs}et references pix_fmt here
[16:11:09 CEST] <wm4> lol
[16:11:17 CEST] <wm4> makes sense I guess
[17:04:44 CEST] <cone-282> ffmpeg 03Michael Niedermayer 07master:1ef267b83f8b: avcodec/h264: Put the removed SPS handling code back
[17:41:00 CEST] <wm4> so it seems some files have "legitimate" 0 sized packets in the middle or (in this case) start of the stream
[17:41:24 CEST] <wm4> but the new decode API strictly considers 0-sized input EOF, and won't leave the EOF state
[17:41:30 CEST] <Daemon404> like, entries in the index that are 0 sized?
[17:41:31 CEST] <wm4> what do
[17:41:39 CEST] <Daemon404> or? how else could it happen
[17:41:42 CEST] <wm4> ffprobe shows a 0-sized packet
[17:41:56 CEST] <Daemon404> what sort of file?
[17:41:58 CEST] <nevcairiel> avi uses that for vfr
[17:42:01 CEST] <wm4> aac in mp4
[17:42:24 CEST] <Daemon404> i suppose its possible in mp4
[17:42:31 CEST] <Daemon404> though i dont know why it would even be returned by the demuxer
[17:42:32 CEST] <nevcairiel> also, shouldnt eof just be NULL, not a 0 sized avpacket
[17:42:58 CEST] <wm4> nevcairiel: I'd say so too, but the API considers both EOF
[17:43:04 CEST] <wm4> I even had a reason for this, but I forgot
[17:43:07 CEST] <nevcairiel> you defined the api =p
[17:43:43 CEST] <wm4> it _might_ have been because ffmpeg.c set metadata on drain packets
[17:43:48 CEST] <wm4> so they couldn't be NULL
[17:59:15 CEST] <nevcairiel> did the old api handle those packets differently or how did it work there?
[18:34:14 CEST] <Daemon404> wm4 / nevcairiel - there is a patch in libav-land for dropping memalign hack
[18:34:23 CEST] Action: Daemon404 wonders how controversial this will be (it should not be)
[18:34:58 CEST] <JEEB> calculate how many things on FATE end up using it and see based on that
[18:35:12 CEST] <JEEB> probably close to zero, but just in case
[18:35:14 CEST] <wm4> nice
[18:36:31 CEST] <jkqxz> Does it make configure mock you for using random configure lines you found on the internet if you pass --enable-memalign-hack?  That should be a requirement.
[18:37:20 CEST] <Daemon404> lol
[18:39:01 CEST] <JEEB> :D
[19:05:02 CEST] <kurosu> found the bug in the vc2 encoder, clearly subtle
[19:05:28 CEST] <kurosu> I suspect this also means the bitstreams produced may not have been always spec-compliant
[19:07:55 CEST] <kurosu> (reorder the words in that last sentence as you see fit)
[19:09:07 CEST] <cone-282> ffmpeg 03Thomas Volkert 07master:f591b7b5265f: rtpenc: packetizer for VC-2 HQ RTP payload format (draft v1)
[19:10:45 CEST] <wm4> it's strange when a commit has "draft v1" in its subject line when it's pushed to master
[19:11:10 CEST] <nevcairiel> those rtp standards are all weird drafts
[19:12:53 CEST] <BtbN> have you ever looked at the commit log on android?
[19:13:18 CEST] <BtbN> litteraly over half of the commits there have "DO NOT MERGE" in them
[19:14:05 CEST] <wm4> isn't there some kind of unintuitive reason for that?
[19:16:50 CEST] <atomnuker> kurosu: where's the bug?
[19:17:01 CEST] <kurosu> see patchset posted to ml
[19:17:15 CEST] <kurosu> atomnuker, ^
[19:17:19 CEST] <JEEB> wm4: probably never rebased to remove it or something?
[19:17:33 CEST] <JEEB> although gerrit should let you do that
[19:18:17 CEST] <atomnuker> kurosu: I don't see it yet
[19:18:24 CEST] <Daemon404> JEEB, you mean amended
[19:18:35 CEST] <atomnuker> probably the mail being delayed again
[19:18:45 CEST] <Daemon404> i dont like how thinks like gerrit break gits model
[19:18:57 CEST] <Daemon404> as in, patch series model
[19:20:53 CEST] <nevcairiel> more vsynth tests, that will make for one happy Daemon404
[19:24:31 CEST] <kurosu> except I got the padding wrong and need to generate the patchset :(
[19:24:41 CEST] <kurosu> *regenerate
[19:29:28 CEST] <atomnuker> kurosu: you'll still get non-bitidentical files if someone bumps the major/minor/micro
[19:29:53 CEST] <kurosu> huh, why ?
[19:29:58 CEST] <nevcairiel> typically we have the bitexact flag to exclude that information, vc2 should probably obey that if it does not yet
[19:30:01 CEST] <atomnuker> you'll need to change aux_data[] = LIBAVCODEC_IDENT; to "ffmpeg"
[19:30:05 CEST] <kurosu> it's part of the version string ,
[19:30:11 CEST] <kurosu> ok
[19:30:16 CEST] <atomnuker> problem is that the bitexact flag isn't exposed in avcodeccontext
[19:30:24 CEST] <nevcairiel> sure is
[19:30:36 CEST] <nevcairiel> aacenc even supports it =p
[19:30:43 CEST] <nevcairiel> hence, you should know this!
[19:30:43 CEST] <nevcairiel> :D
[19:30:59 CEST] <kurosu> so the fate data must regenerated again as the version data will be changed?
[19:31:04 CEST] <atomnuker> shit, I was looking at the wrong thing
[19:31:10 CEST] <atomnuker> yeah, it's avctx->flags
[19:31:56 CEST] <kurosu> maybe I'll not generate again the fate data, if another patch is needed, the writing of which I delegate to the encoder's author :)
[19:32:08 CEST] <atomnuker> so just put an if (avctx->flags & AV_CODEC_FLAG_BITEXACT) aux_data = "ffmpeg" else aux_data = LIBAVCODEC_IDENT
[19:32:37 CEST] <atomnuker> I could do that, but in 2 hours when I'm home
[19:33:14 CEST] <kurosu> I'd prefer that, yes, as you'll probably the reviewer and pusher for that patchset
[19:33:41 CEST] <atomnuker> kurosu: pad_c can reach up to quite a few bytes, could you do a quick non-scientific performance test?
[19:33:51 CEST] <nevcairiel> so these vsynth tests actually check  for the bitexactness of generated bitstreams? doesnt that sound rather fragile, any improvement to the encoder would trip it?
[19:34:13 CEST] <kurosu> nevcairiel, that's also part of the plan
[19:34:34 CEST] <kurosu> like x264 should produce identical bitstreams given same parameters, whatever the platform
[19:34:52 CEST] <kurosu> if there's a change to the format, then updating fate is needed
[19:35:02 CEST] <kurosu> everything vsynth follows that principle
[19:35:33 CEST] <cehoyos__> kurosu: Did you compiare the speed of the new bitstream reader with and without av_likely()?
[19:35:41 CEST] <kurosu> (and there's plently lossy codecs in there, such as jp2K, mpeg2, dnxhd, ...)
[19:36:03 CEST] <kurosu> cehoyos__, no, I think I was generous enough with my time on it
[19:36:37 CEST] <kurosu> I'd say I haven't been paid back in kindness, so little incentive to pursue that
[19:37:29 CEST] <cehoyos__> Too bad to read;-(
[19:37:30 CEST] <kurosu> I was kind enough to work on vc2 :)
[19:37:45 CEST] <cehoyos__> That was definitely a good idea!
[19:38:24 CEST] <cehoyos__> kurosu:x264 multithreading is not reproducible, only single-threading is
[19:39:04 CEST] <kurosu> anyway, it was a minor inconvenience not warranting my stoping - the time spent is the reason for stopping
[19:39:14 CEST] <kurosu> cehoyos__, I think there's a --deterministic option for that
[19:39:33 CEST] <cehoyos__> I didn't know it, ty
[19:39:41 CEST] <JEEB> cehoyos__: multithreading is deterministic if VBV is not enabled
[19:39:56 CEST] <JEEB> VBV kills determinism
[19:40:14 CEST] <JEEB> (and I think but am not sure - changing the amount of threads - although don't quote me on othis)
[19:40:54 CEST] <cehoyos__> I was under the impression that threads themselves make it unreproducible but it's been some time I tested (and it isn't really FFmpeg-related anyway).
[19:41:45 CEST] <JEEB> and the option actually is non-deterministic :)
[19:41:46 CEST] <JEEB> IIRC
[19:44:10 CEST] <JEEB> https://mailman.videolan.org/pipermail/x264-devel/2015-April/011036.html
[19:44:34 CEST] <JEEB> so yeah, multithreading and VBV is the case where determinism goes out of the window
[20:18:15 CEST] <kurosu> atomnuker, regarding the memset, I think it is required because the padding value is 0xFF, unless you check the -strict setting and not do the memset, but somewhat risking writing an invalid bitstream
[20:33:38 CEST] <Shiz> so I'm caught in a bit of a pickle here -- I'm dealing with a format which is just MPEG-PS with a custom header, for which I've written the necessary mpeg.c enhancements
[20:33:56 CEST] <Shiz> the video is bog-standard h.264 and the audio is AT3 with a custom-ish header in PRIVATE_STREAM_1 packets
[20:34:17 CEST] <Shiz> so I've written a parser for these packets, but apparently setting avcodec params in parsers is a No Go
[20:34:30 CEST] <Shiz> but this header isn't exactly used anywhere else, and stuffing it in mpeg.c seems not very useful either
[20:35:17 CEST] <Shiz> (especially since the headers are repeated per frame, which yes technically can mean the audio format changes per frame)
[20:35:43 CEST] <Shiz> does anyone have thoughts on how to best approach dealing with this so that I can actually get it merged and not rejected for doing Bad Things
[20:35:45 CEST] <wm4> I think in theory parsers can very well set codec parameters, but I'm not sure about what kinds of interactions you have
[20:36:02 CEST] <Shiz> in theory yeah, which is what I'm doing right now
[20:36:09 CEST] <Shiz> I'm also told it's a pretty big no-no though
[20:36:13 CEST] <JEEB> I think the last ATRAC3+ MPEG-PS support patch got stopped at that point
[20:36:22 CEST] <nevcairiel> parsers shouldnt be required to set codec parameters
[20:36:27 CEST] <nevcairiel> either the codec does that, or the demuxer
[20:36:33 CEST] <JEEB> and since the comment was not clear enough the patch never got new versions
[20:36:51 CEST] <JEEB> yeah, so I guess the parser could stop stripping the frame headers and the demuxer would set a field?
[20:37:54 CEST] <JEEB> header_included = 1 or so
[20:38:05 CEST] <Shiz> stupid_custom_header = 1
[20:38:35 CEST] <JEEB> of course this also means that you have to move some init from init() to decode()
[20:38:44 CEST] <JEEB> since it would then init the values during the first frame appearing
[20:39:29 CEST] <JEEB> so yeah, currently the decoder is completely dependant on something setting the values before hand :)
[20:39:50 CEST] <JEEB> which is why both Shiz and the guy from 2014 tend to add the parameter setting into the parser
[20:39:51 CEST] <Shiz> i guess another approach is delegate to the OMA parser if such a thing is possible
[20:40:06 CEST] <Shiz> (no clue if you can do that from another demuxer0
[20:40:08 CEST] <Shiz> OMA demuxer*
[20:40:15 CEST] <Shiz> and deal with the custom header there
[20:40:20 CEST] <Shiz> since it does use some OMA tables
[20:41:01 CEST] <JEEB> you can use a demuxer in demuxer but I've never done double track drifting
[20:41:19 CEST] <wm4> <nevcairiel> parsers shouldnt be required to set codec parameters <- but they're perfectly in the position to do so
[20:41:40 CEST] <Shiz> it seems cleaner architecturally, maybe
[20:41:48 CEST] <Shiz> than adding custom header parsing to the AT3+ decoder
[20:42:37 CEST] <JEEB> not like we don't already have support for AVCc and Annex B AVC
[20:43:17 CEST] <JEEB> and unlike with those you could just set the correct value in the demuxer since the formats don't mish-mash (unlike with AVC where people stuck Annex B into MP4 etc)
[20:44:48 CEST] <JEEB> but yes, it means that the decoder would have to be changed which might not be fun
[20:45:34 CEST] <Shiz> gotta check how other stuff deals with nested containers
[20:45:43 CEST] <Shiz> i mean surely the entire intention of shit like matroska is nested containers
[20:45:49 CEST] <Shiz> maybe i should check the matroska dec- *gets shot*
[20:46:24 CEST] <wm4> ?
[20:46:37 CEST] <wm4> are you talking about mkv avi/qt support?
[20:48:09 CEST] <JEEB> yeah, those are generally handled by just having the decoder be able to handle them or so
[20:52:33 CEST] <wm4> the packet formats are usually the same, so only the headers need to be parsed additionally
[20:53:29 CEST] <Shiz> yeah
[20:53:37 CEST] <Shiz> the packets can be passed straight to the at3+ decoder
[20:53:59 CEST] <Shiz> with the headers removed ofc
[20:54:32 CEST] <JEEB> basically my pick would probably be the have the demuxer tell the decoder which mode it will be and whether a parser is needed
[20:54:47 CEST] <JEEB> and then move the value setting to decode()
[20:56:46 CEST] <durandal_170> when we gonna apply lbr dts patches?
[20:57:34 CEST] <Shiz> JEEB: how would i tell the decoder that?
[20:59:32 CEST] <JEEB> set a value in avcodeccontext. or use the extradata field
[21:01:22 CEST] <JEEB> side data is another modern way of passing info around I guess
[21:04:13 CEST] <wm4> JEEB: actually demuxers should set AVStream.codecpar fields
[21:04:15 CEST] <wm4> not avctx
[21:04:51 CEST] <JEEB> yes
[21:05:04 CEST] <JEEB> gotta get rid of the old calling habits
[21:05:33 CEST] <Shiz> lol
[21:05:40 CEST] <Shiz> hmm
[21:05:51 CEST] <Shiz> actually, adding the info to AVPacket side data doesn't seem bad
[21:05:58 CEST] <Shiz> that way the OMA demuxer can do it too
[21:06:13 CEST] <Shiz> and the parsing of that can be centralized to the a3+ decoder
[21:07:42 CEST] <JEEB> or you duplicate the header structure in extradata or so. and then if extradata is allocated and big enough you use it, otherwise from the stream
[21:08:19 CEST] <Shiz> luckily it's just a single byte
[21:08:20 CEST] <Shiz> :p
[21:08:25 CEST] <Shiz> err, maybe two
[21:08:27 CEST] <Shiz> yeah, two
[23:25:39 CEST] <pfelt> afternoon all. i think i've cleaned up this code enough for wider comment.  what's the proper way to get my patch to src_movie.c into the right hands?
[23:26:00 CEST] <pfelt> (i'm expecting comments and changes)
[23:27:05 CEST] <nevcairiel> if you think its ready for review, then it should be sent to the mailing list
[23:29:49 CEST] <thardin> https://imagetragick.com/
[23:41:08 CEST] <pfelt> nevcairiel: kk.  it's definitely ready for more eyes than mine, but i'm positive there'll be modifications to make
[23:42:45 CEST] <thardin> don't quite recall if ffmpeg used imagemagick ho
[23:42:47 CEST] <thardin> tho
[00:00:00 CEST] --- Wed May  4 2016