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

[burek]

[05:43:47 CEST] <rcombs> [12:31:40]  <@ubitux>	rcombs: reordering is easy to do
[05:43:47 CEST] <rcombs> [12:31:49]  <@ubitux>	with vt at least
[05:43:55 CEST] <rcombs> ubitux: ^ what were you referring to here?
[05:44:12 CEST] <rcombs> (I could easily be missing something in the API; the docs are non-great)
[05:51:41 CEST] <Zeranoe> So if patches are being sent to the ffmpeg-devel ML inline with the email body, how are they getting out and into git? Are they literally copied out, or are they being retained elsewhere during the submission to the ML
[06:08:52 CEST] <c_14> git am?
[06:13:40 CEST] <rcombs> Zeranoe: yeah, `git am`
[06:13:58 CEST] <rcombs> takes a raw email and applies it as a commit
[06:14:23 CEST] <rcombs> most clients are capable of exporting the standard format for that, or store messages in it somewhere internally
[06:14:38 CEST] <Zeranoe> So what's the proper way to submit a revised patch when the original patch is in the ML?
[06:14:53 CEST] <Zeranoe> I'm not sure how I can reply with git send-email
[06:16:06 CEST] <rcombs> `--in-reply-to=<message ID>`
[06:16:23 CEST] <Zeranoe> nice
[06:17:34 CEST] <rcombs> the message ID can either come from your client (look at the raw headers) or from the web archive (it's kinda awkward to find but it's in the mailto: link)
[06:35:56 CEST] <Zeranoe> I'm not sure if that worked... I used --in-reply-to=815624355.20160530155907 at nablet.com ... oh well
[09:36:17 CEST] <ubitux> rcombs: i missed the part where you implied packets with no timestamps
[09:36:34 CEST] <ubitux> but i don't think you have to handle that case
[09:37:14 CEST] <ubitux> (can't you use genpts or sth?)
[09:50:11 CEST] <rcombs> (don't think that'll fly for reordering)
[09:50:29 CEST] <nevcairiel> reordering on timestamps only is not a valid approach and I would complain loudly on the ML :p
[09:50:49 CEST] <nevcairiel> (for that matter, I also would do that when you re-implement re-ordering just to avoid being a hwaccel)
[09:52:43 CEST] <ubitux> so the hwaccel is actually the good choice for vtdec?
[09:52:55 CEST] <rcombs> it's& awkward
[09:53:05 CEST] <nevcairiel> if vt doesnt provide the means to actually be a full decoder
[09:57:14 CEST] <ubitux> but how can we make hwaccels async? :(
[09:57:56 CEST] <nevcairiel> ask apple to make better APIs
[09:58:15 CEST] <nevcairiel> timestamps are not reliable and re-implementing full re-ordering for h264 and hevc is just extremely complex
[09:58:52 CEST] <nevcairiel> other hardware APIs can use the full extent of the hardware without needing such things
[10:41:50 CEST] <nevcairiel> why do people think porting an external library into the avfilter code is a good idea
[10:42:20 CEST] <ubitux> re: libebur128?
[10:42:44 CEST] <nevcairiel> yes
[10:43:19 CEST] <ubitux> yeah well i don't know, i raised disagreement but apparently some people were ok with that so i let it slip
[10:52:31 CEST] <kierank> nevcairiel: nih
[10:52:58 CEST] <nevcairiel> nih would be re-implementing it entirely, ubitux's filter comex closer to that =p
[10:53:05 CEST] <nevcairiel> comes*
[10:53:22 CEST] <kierank> ok then, no technical leadership in the project
[11:00:16 CEST] <mateo`> so when this port is done, ubitux's work will go to ~limbo (or at least we will end up with two filters doing almost the same thing) ?
[11:01:13 CEST] <nevcairiel> very similar things, but for some reason extending ubitux's filter was out of the question for some reason
[11:01:14 CEST] <ubitux> well his attempt was to replace the native code with the library one inside f_ebur128 to end up with loudness being a superset of f_ebur128
[11:01:20 CEST] <ubitux> and then get rid of it
[11:01:27 CEST] <ubitux> i suppose that was the strategy
[11:02:01 CEST] <nevcairiel> well having another filter that depends on an external libebur128 isnt that bad, i think that one got already pushed anyway?
[11:02:13 CEST] <nevcairiel> but what I'm concerned with is porting a complex library into avfilter
[11:02:38 CEST] <ubitux> i'm relatively ok with that, as i said i let it slip even though i don't think it makes much sense
[11:03:01 CEST] <ubitux> but right now he's making the "external library" a "native one" by copying it
[11:03:23 CEST] <ubitux> so f_ebur128 won't have much purpose, especially after it's changed to use that code
[11:03:39 CEST] <ubitux> anyway, nasty strategy, i don't like it much :p
[11:04:10 CEST] <nevcairiel> i asked on the ML what reasons he might have to warrant porting such a library and not using it like any other external library we support
[11:04:23 CEST] <nevcairiel> i forsee filmsy reasons like "its not packaged on any distributions"
[11:04:53 CEST] <nevcairiel> which would not fly with me :p
[11:05:24 CEST] <atomnuker> it's a very small library which is why I said it might be a good idea to port it in
[11:07:25 CEST] <ubitux> i'm starting to wonder if this whole thing isn't because of f_ebur128 being gpl
[11:17:01 CEST] <durandal_1707> yes, gpl is evil
[11:18:03 CEST] <durandal_1707> Nobody wants to remove f_ebur128
[11:18:31 CEST] <durandal_1707> just there should be alternatives
[11:18:54 CEST] <ubitux> i might be ok with relicensing if it's an issue
[11:19:15 CEST] <ubitux> but kyle didn't question it, so i assumed it wasn't the issue
[11:19:37 CEST] <ubitux> even though there is something fishy in this whole thing :p
[11:19:48 CEST] Action: ubitux takes his tinfoil hat
[11:25:58 CEST] <ubitux> durandal_1707: dropping the ebur128 logic from f_ebur128 is close to it though
[11:42:15 CEST] <ubitux> what's exactly special about fate-samples/h264/lossless.h264?
[11:42:49 CEST] <ubitux> i broke something in the sei merge (there is a small visual difference)
[11:42:52 CEST] <ubitux> "small"
[11:44:07 CEST] <ubitux> http://ubitux.fr/pub/pics/sei-merge-visual-diff-last-frame.png
[11:44:24 CEST] <ubitux> (all frames differ, the error just propagates)
[11:49:21 CEST] <durandal_1707> ubitux: f_ebur128 could reuse lgpl code
[11:50:10 CEST] <ubitux> nowadays i care much less about f_ebur128 being gpl or not
[12:01:30 CEST] <ubitux> actually starting to differ at the second frame
[12:03:17 CEST] <nevcairiel> i'm  kinda surprised SEIs can influence the actual image like that at all
[12:04:50 CEST] <nevcairiel> unless related to recovery info maybe
[12:07:18 CEST] <ubitux> http://b.pkh.me/lossless-ref2.png vs http://b.pkh.me/lossless-out2.png typically
[12:07:23 CEST] <ubitux> (2nd frame)
[12:14:19 CEST] <nevcairiel> the only SEI the lossless sample even has is SEI_TYPE_USER_DATA_UNREGISTERED
[12:14:45 CEST] <nevcairiel> oh
[12:14:58 CEST] <nevcairiel> lossless encodes from x264 are "broken" according to the spec
[12:15:03 CEST] <nevcairiel> maybe it fails to parse the x264 string?
[12:16:02 CEST] <ubitux> ah, related to that x264_build thing then?
[12:16:07 CEST] <nevcairiel> thats my guess
[12:16:10 CEST] <nevcairiel> i'll keep poking
[12:16:16 CEST] <iive> i remember that there were something ammended in lossless format
[12:16:36 CEST] <nevcairiel> th SEI parser fills x264_build properly, maybe its read wrong somewhere
[12:16:59 CEST] <iive> and i think x264 uses the new fprmat
[12:17:25 CEST] <nevcairiel> one particular macroblock size was encoded wrong according to the spec, in later builds they turned off encoding that size iirc
[12:19:22 CEST] <nevcairiel> ubitux: somewhere the x264 value gets set back to -1
[12:19:40 CEST] <nevcairiel> its read correctly once, then passed around correctly, but then reset
[12:19:52 CEST] <ubitux> probably in the reset function then yes
[12:20:02 CEST] <ubitux> let me check, thanks
[12:20:45 CEST] <nevcairiel> it used to be only reset in init_context, but the new reset sei function is called in more places
[12:21:22 CEST] <nevcairiel> so should probably just move the x264 reset back to its original place
[12:21:43 CEST] <nevcairiel> that should fix the lossless one
[12:25:27 CEST] <ubitux> nevcairiel: oh i derped somewhere
[12:26:53 CEST] <nevcairiel> i also saw this, ff_h264_sei_uninit(&h->sei.a53_caption); .. warns as well, wrong struct passed :)
[12:27:39 CEST] <ubitux> yeah
[12:27:45 CEST] <ubitux> that was what i was talking about
[12:27:48 CEST] <ubitux> but it didn't help
[12:28:02 CEST] <ubitux> (either calling it on h->sei or only touching a53_caption)
[12:28:21 CEST] <nevcairiel> http://pastebin.com/Mkekga2C
[12:28:25 CEST] <nevcairiel> this fixes lossless
[12:29:48 CEST] <ubitux> libav doesn't have this but decodes fine
[12:30:03 CEST] <ubitux> would it be related to the update thread function?
[12:30:07 CEST] <nevcairiel> they probably dont support lossless files that are encoded by anything but x264
[12:30:34 CEST] <nevcairiel> we added support for lossless strict to the latest spec 
[12:30:44 CEST] <ubitux> do we have a sample?
[12:31:37 CEST] <ubitux> it doesn't explain why they decode this sample fine without your change
[12:31:55 CEST] <nevcairiel> like I said, because their decoder always uses the x264 friendly way
[12:32:12 CEST] <nevcairiel> while we support strict spec conform decoding, and x264-broken decoding
[12:32:44 CEST] <nevcairiel> i'm trying to find the trac ticket about that
[12:32:47 CEST] <ubitux> aah indeed, they don't have the x264_build check 
[12:32:48 CEST] <nevcairiel> it might have a sample
[12:33:46 CEST] <ubitux> alright, i'm integrating your change
[12:33:50 CEST] <ubitux> thanks!
[12:35:00 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=6f7ca1f55be1270e0d7c33409de4473e4dd00add
[12:35:04 CEST] <nevcairiel> no trac reference :(
[12:35:46 CEST] <ubitux> look for the hash on the trac
[12:36:41 CEST] <nevcairiel> there was a sample link on the ML
[12:36:43 CEST] <nevcairiel> but its dead
[12:37:12 CEST] <nevcairiel> anyway my patch makes the reset behavior of x264_build the same as before
[12:37:47 CEST] <ubitux> i updated the branch
[12:38:02 CEST] <ubitux> i'm rechecking a full fate and will test the other ticket/samples i flagged
[12:55:42 CEST] <michaelni> nevcairiel, if theres a unique filename i could check if i have it locally still
[12:55:54 CEST] <nevcairiel> the mail doesnt mention it
[12:56:00 CEST] <michaelni> :(
[12:58:27 CEST] <ubitux> damn i hate those trac ticket with unformated output
[12:58:31 CEST] <ubitux> the markup make them unreadable
[13:00:15 CEST] <ubitux> here we go, much better.
[13:07:31 CEST] <ubitux> michaelni, nevcairiel, i updated https://github.com/ubitux/FFmpeg/commits/merge-libav
[13:07:34 CEST] <ubitux> it's ready for testing
[13:07:55 CEST] <ubitux> details are in the last commit 
[13:08:11 CEST] <nevcairiel> i honestly dont expect sei stuff to have that huge of an impact if you tested the recovery info to be still intact
[13:09:13 CEST] <ubitux> i'm still uncertain about certain changes
[13:09:24 CEST] <ubitux> the diff in libavcodec/h264_refs.c
[13:09:27 CEST] <ubitux> for instance
[13:09:50 CEST] <nevcairiel> oh yeah i saw that, apparently that variable has gone away
[13:10:39 CEST] <ubitux> yes because i can't have access to h264context inside sei decode
[13:11:16 CEST] <ubitux> but no_recovery_ffmpeg_cut.h264 still decodes fine...
[13:11:48 CEST] <nevcairiel> has_recovery_point used to be set to 1 in the IDR slice parser, but that line vanished without replacement
[13:12:53 CEST] <ubitux> mmh that's right
[13:13:12 CEST] <nevcairiel> has_recovery_point was also never ever unset
[13:13:13 CEST] <nevcairiel> once it was set
[13:13:20 CEST] <nevcairiel> so the semantic may not be entirely correct
[13:13:48 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vo21D
[13:13:48 CEST] <KGB> 13FFV1/06master 14b99b92f 15Jérôme Martinez: SliceContent description update...
[13:14:02 CEST] <ubitux> there is a behaviour change, but the file in question still decodes fine (and dropping the chunk in h264_refs indeed kinda breaks it)
[13:14:04 CEST] <nevcairiel> maybe re-introduce that variable and just set it outside of SEI parsing when recovery frame count is set
[13:14:28 CEST] <ubitux> right, just like dtg_active_format and stuff?
[13:14:44 CEST] <nevcairiel> i guess so
[13:15:26 CEST] <ubitux> i'd like michaelni's opinion on this as he introduced it
[13:15:30 CEST] <nevcairiel> h->has_recovery_point = h->has_recovery_point || h->sei.recovery_point.recovery_frame_cnt != -1;
[13:15:38 CEST] <nevcairiel> or something
[13:16:10 CEST] <nevcairiel> that would mimick the previous behavior
[13:16:26 CEST] <nevcairiel> and re-add it to lin 1094 or so as well
[13:17:29 CEST] <ubitux> there is a similar frame packing thing
[13:17:32 CEST] <ubitux> the frame_packing_arrangement_cancel_flag
[13:17:51 CEST] <ubitux> which is not reset inside the uninit
[13:17:56 CEST] <nevcairiel> thats just metadata, what do i care :)
[13:18:29 CEST] <michaelni> ubitux, my gcc says "libavcodec/h264.c:660:9: warning: comparison of unsigned expression >= 0 is always true [-Wtype-limits]"
[13:19:35 CEST] <ubitux> ugh yeah it's int in libav but we have it in an enum starting at 0
[13:22:21 CEST] <michaelni> you can add a enum value with -1 to force it to be signed
[13:22:45 CEST] <michaelni> or just remove the >= 0 if its never going to be <0
[13:29:18 CEST] <michaelni> ubitux, about the has_recovery_point, its a heuristic, theres no way i know which way is better, it could be either way
[13:29:33 CEST] <michaelni> probably only bug reports would tell which way is better
[13:30:00 CEST] <ubitux> what approach would you prefer?
[13:30:02 CEST] <nevcairiel> i would vote for keeping the current logic, if it should be changed at some point later, it should not be in the merge
[13:30:02 CEST] <michaelni> if it changes in the merge it probably should be documented in the commit message though so that if a bisect ends at it one knows what to do
[13:30:19 CEST] <michaelni> true
[13:30:31 CEST] <nevcairiel> we know the current way works
[13:30:35 CEST] <nevcairiel> so lets stick to that :)
[13:30:51 CEST] <ubitux> ok, i'll do that and poke again in a moment
[13:30:57 CEST] <ubitux> again, fate test welcome :(
[13:34:26 CEST] <michaelni> iam not aware of anything changing from this merge, just saying so no need to wait for me with pushing this (ill be afk for maybe 3h or so soonish)
[13:34:55 CEST] <ubitux> alright, thanks :)
[13:47:19 CEST] <ubitux> nevcairiel: applied your suggestion and fixed the type-limits warning; it's documented in the commit message
[13:47:27 CEST] <ubitux> i'll wait for your ok to push
[13:47:42 CEST] <ubitux> s/to push/to squash and push/
[13:47:50 CEST] <ubitux> (branch updated)
[13:48:01 CEST] <nevcairiel> line 1094 looks fishy
[13:48:10 CEST] <nevcairiel> it should just remain has_recovery_point = 1
[13:48:15 CEST] <nevcairiel> (h264.c)
[13:49:06 CEST] <ubitux> mmh right
[13:50:18 CEST] <ubitux> fixed
[13:55:57 CEST] <nevcairiel> the license header in h264_sei.h is not quite correct for ffmpeg
[13:56:43 CEST] <ubitux> ah i missed that the name occurs in several place
[13:56:44 CEST] <nevcairiel> otherwise looks good to me
[13:56:50 CEST] <ubitux> alright, thanks
[13:57:06 CEST] <ubitux> i'll apply in a moment and start the next one
[13:57:17 CEST] <nevcairiel> hopefully they should get a bit easier now
[13:57:29 CEST] <ubitux> extradata is another tricky one iirc
[13:57:38 CEST] <nevcairiel> dont think its that bad
[13:57:39 CEST] <ubitux> but it should be the last one
[13:57:52 CEST] <nevcairiel> the big part of that was decoupling the ps stuff
[13:58:06 CEST] <nevcairiel> unless it writes evil things into h264context which it shouldnt
[13:58:07 CEST] <nevcairiel> who knows
[13:58:08 CEST] <nevcairiel> .D
[14:08:21 CEST] <cone-719> ffmpeg 03Anton Khirnov 07master:728d90a0c197: h264: decouple h264_sei from the h264 decoder
[14:08:21 CEST] <cone-719> ffmpeg 03Clément BSsch 07master:5584f019b5eb: Merge commit '728d90a0c1973661a9e73da697bf4f90c9d19577'
[14:10:57 CEST] <ubitux> alright, next monster.
[14:11:08 CEST] <cone-719> ffmpeg 03Clément BSsch 07master:b51d5c99b899: lavc/h264_parse: remove tabs introduced in a2922b5d
[14:57:19 CEST] <ubitux> any idea why in 98c97994c5b90bdae02accb155eeceeb5224b8ef the chunk about "sps and pps in the avcC always have length coded with 2 bytes, so put a fake nal_length_size = 2 while parsing them" disappeared?
[15:06:19 CEST] <Compn> ubitux : you mean in gitlog, ml, or other ?
[15:12:43 CEST] <ubitux> ?
[15:13:39 CEST] <ubitux> in the commit, there is a h->nal_length_size = 2 preceded by that comment. both the comment and assignment are gone in this commit
[15:13:55 CEST] <ubitux> the question is "why"
[15:14:29 CEST] <ubitux> anyway, just like previously, the merge is available in my github branch
[15:14:37 CEST] <ubitux> help fixing the fate issues welcome
[15:19:24 CEST] <nevcairiel> ubitux: it looks like the reading of the nal size was moved to the calling code so overriding that value is no longer required
[15:19:57 CEST] <nevcairiel> hm or maybe not
[15:20:02 CEST] <nevcairiel> willl look at it closer later
[15:20:15 CEST] <nevcairiel> oh
[15:20:16 CEST] <omerjerk> Hi, so I'm done with my patch to add floating point support in the ALS decoder.
[15:20:22 CEST] <nevcairiel> the 2 is hardcoded in decode_extradata_ps now, ubitux
[15:20:31 CEST] <nevcairiel> so it doesnt need to be set in a context
[15:20:31 CEST] <omerjerk> this is the patch - https://github.com/omerjerk/FFmpeg/commit/f53f388552673af4aa7c7369f371442ea7e1ee32
[15:20:54 CEST] <omerjerk> Comments are welcome. 
[15:22:06 CEST] <ubitux> nevcairiel: ah, as argument to ff_h2645_packet_split()? ok
[15:22:09 CEST] <ubitux> thanks
[15:22:12 CEST] <nevcairiel> yes
[17:27:43 CEST] <ubitux> yay fate passing with extradata merge
[17:29:48 CEST] <thebombzen> you know that error message "non-monotonically increasing DTS etc etc etc"? it's complaining for me with -f null. I feel like this is a bug. is it? should I report it?
[17:36:48 CEST] <thebombzen> my thought process is that ideally, with -f null, it's irrelevant if the muxer doesn't like the DTS. (also, it's weird that it doesn't happen with -f matroska - >/dev/null, but whatever)
[17:43:31 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/vo2dQ
[17:43:31 CEST] <KGB> 13FFV1/06master 14718bf65 15Jérôme Martinez: Add definition of Line()...
[17:43:33 CEST] <ubitux> nevcairiel, michaelni: branch updated with latest merge, comments welcome
[17:43:56 CEST] <ubitux> (fate passes, no issue known yet)
[17:44:25 CEST] <michaelni> why does omerjerk ask a question and then disappear :/
[17:45:38 CEST] <ubitux> thebombzen: maybe send a patch to add AVFMT_TS_NONSTRICT to nullenc, but i feel like i've seen such patch discussed in the past already
[17:46:05 CEST] <Zeranoe> Asked in #ffmpeg but I'll ask here too: does anyone have a 5th generation Intel CPU running Windows that they'd be willing to try a few FFmpeg commands for me?
[17:47:10 CEST] <thebombzen> ubitux: I'm not a C developer. I'd just file a bug report on trac. I'll do a search to see if it's already come up though.
[17:48:22 CEST] <ubitux> thebombzen: if you are a developer and knows git, it's just about adding AVFMT_TS_NONSTRICT in the flags in libavformat/nullenc.c
[17:48:50 CEST] <thebombzen> ah, that I can do. I think. I'll try it.
[17:49:23 CEST] <ubitux> i don't know if it will fix your issue, but it might be worth a try
[17:50:02 CEST] <ubitux> https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/162006.html
[17:50:08 CEST] <ubitux> ah, got a discussion about that here ^
[17:50:19 CEST] <thebombzen> ubitux: interestingly, AVFMT_NOTIMESTAMPS is already there. is this significant?
[17:50:33 CEST] <ubitux> AVFMT_TS_NONSTRICT ` AVFMT_NOTIMESTAMPS
[17:51:00 CEST] <ubitux> you might want to check the thread i linked
[17:51:27 CEST] <ubitux> but in the end, you might be better opening a ticket with a sample etc
[17:51:56 CEST] <thebombzen> I see. so apparently adding TS_nonstrict just treats the symptom of the problem. the real problem is that it's throwing the error for nonTS-marked muxers.
[17:52:07 CEST] <thebombzen> that's something that's outside of my reach.
[17:53:12 CEST] <thebombzen> I'll patch my personal FFmpeg and file a trac about having NOTTIMESTAMPS automatically imply TS_NONSTRICT.
[17:54:32 CEST] <ubitux> you'd better submit the sample that's causing such errors
[17:54:46 CEST] <ubitux> (and cli used)
[17:55:40 CEST] <thebombzen> x11grab. so no sample.
[17:56:21 CEST] <thebombzen> I'll build a simple copy without any libs. you know, the usual process. see if the error still occurs. 
[17:56:41 CEST] <thebombzen> It actually causes problems when you stop the process with Ctrl+Z, and then resume it. it doesn't cause problems until you do that. it's a bit odd.
[18:07:04 CEST] <jkqxz> Zeranoe:  Are you actually looking for gen8 Intel graphics rather than a Broadwell CPU?  I can try on a Braswell if you make it easy (Windows 7 and not a dev setup, so would need a suitable prebuilt binary).
[18:08:35 CEST] <Zeranoe> jkqxz: Starting with gen 5 cpus and will narrow it down from there. build: https://ffmpeg.zeranoe.com/shared/hITBqt5QX8E7An05/ffmpeg.exe command: for %a in (veryfast,faster,fast,medium,slow,slower,veryslow) do ffmpeg.exe -i in.mp4 -look_ahead 0 -strict -2 -vf unsharp=lx=7:ly=7:la=0.56:cx=7:cy=7:ca=0.28 -c:v h264_qsv -b:v 2000k -preset:v %a -y out.mp4
[18:09:00 CEST] <Zeranoe> jkqxz: in.mp4 is any HD video, but I can provide media if you need.
[18:11:21 CEST] <jkqxz> Just a moment for me to get this set up...  Are you meaning HD = 720p or 1080p (or doesn't matter) there?
[18:11:52 CEST] <Zeranoe> jkqxz: 1080p is preferred but it should happen with 720.
[18:13:04 CEST] <jkqxz> I'll use Big Buck Bunny at 1080p then.
[18:13:46 CEST] <Zeranoe> perfect
[18:17:51 CEST] <jkqxz> Running.  What am I expecting to happen here?
[18:18:44 CEST] <jkqxz> (Speed on veryfast is 0.15x, so this will take a long time to run to completion, if that's necessary.)
[18:19:38 CEST] <Zeranoe> jkqxz: A hang forever
[18:20:33 CEST] <Zeranoe> shorter media might be better, but it theoretically could hang mid way through. It's unpredictable....
[18:21:00 CEST] <jkqxz> Does the preset matter?
[18:21:34 CEST] <Zeranoe> That also needs to be narrowed down. So short answer is IDK
[18:23:06 CEST] <jkqxz> Ok, I'll let it move to the next preset once it's been running for a while.
[18:23:49 CEST] <Zeranoe> jkqxz: Thanks. Let me know if it doesn't happen on any of them and I'll have you try a build that should cause it.
[18:25:54 CEST] <Zeranoe> jkqxz: What's your CPU btw?
[18:28:19 CEST] <jkqxz> That's a Braswell N3700.  Slow low-power CPU cores, but the graphics are pretty much the same as a Broadwell.
[18:29:43 CEST] <michaelni> ubitux "./ffmpeg -i http://samples.ffmpeg.org/V-codecs/smv2/ref_10.avi -f null -" breaks with your next merge
[18:32:33 CEST] <ubitux> ok, looking at it
[18:43:59 CEST] <michaelni> ill upload the sample to fatesamples and will make a fate test its quite small
[18:49:47 CEST] <jkqxz> Zeranoe:  It managed over 2000 frames in all seven presets.  I've left it running again for longer now.
[18:51:12 CEST] <jkqxz> Or I can try your other binary if that's more useful.
[18:56:52 CEST] <Zeranoe> jkqxz: Same command, try this one: https://ffmpeg.zeranoe.com/shared/hITBqt5QX8E7An05/ffmpeg-bad.exe
[19:01:37 CEST] <jkqxz> Ok, running with that now.
[19:40:30 CEST] <jkqxz> Zeranoe:  That ran fine for 3000 frames on each preset.
[19:40:52 CEST] <Zeranoe> Of course it did...
[19:51:07 CEST] <Zeranoe> jkqxz: Can you try one more for me? https://ffmpeg.zeranoe.com/shared/hITBqt5QX8E7An05/ffmpeg-bad2.exe
[19:55:07 CEST] <jkqxz> Running.
[20:05:04 CEST] <ubitux> michaelni: so, i know you don't care much, but this sample doesn't work with libav/master, didn't after the commit i'm merging, and didn't either before
[20:05:37 CEST] <ubitux> but if you know a commit that might have fixed it in ffmpeg i'm interested
[20:33:54 CEST] <ubitux> michaelni: so, if i understand correctly, this is due to decode_nal_units() call being replaced by ff_h2645_packet_split()
[20:34:09 CEST] <ubitux> and for some reason, ff_h2645_packet_split() isn't able to find a startcode
[20:34:37 CEST] <jkqxz> Zeranoe:  Also ran fine for 3000 frames on each preset.
[20:35:28 CEST] <jkqxz> ("08bcc75222745e005ec6a8689bc99b1d  ffmpeg-bad2.exe", to make sure I was actually running the right thing there.)
[20:37:40 CEST] <Zeranoe> jkqxz: ugh
[20:39:02 CEST] <Zeranoe> jkqxz: Are you using your CPU as your main display device? Also, what driver versions? Do you have the Media SDK installed (it's a totally separate thing than drivers)?
[20:40:25 CEST] <michaelni> ubitux, it should work before the commit aka wih ffmpeg git master
[20:40:58 CEST] <michaelni> otherwise i wonder how i made the fate test
[20:41:06 CEST] <michaelni> let me double check
[20:42:52 CEST] <jkqxz> Zeranoe:  Yes; driver is 10.18.14.4234 (08/06/2015); no Media SDK.
[20:44:14 CEST] <jkqxz> If this is timing dependent, the slow CPU might be hiding the problem by spacing out all of the operations.  (It was only getting 9fps throughout that testing.)
[20:44:32 CEST] <michaelni>  ubitux "make fate-h264-sm2v-ref10" passes with git master
[20:44:42 CEST] <michaelni> doesnt it pass for you ?
[20:44:50 CEST] <michaelni> or i misunderstood?
[20:45:11 CEST] <Zeranoe> jkqxz: I know very little as to what it's dependent on... I sent you a really old build, a new build, a custom build, and none of them hung so....
[20:46:36 CEST] <Zeranoe> jkqxz: The hang I believe is due to the CPU getting "confused" while lots going on while trying to encode. "confused" being lots going on. I was able to reproduce it on another 5th gen without the vf and other processes hogging CPU cycles
[20:46:44 CEST] <michaelni> ubitux, i think someone sent me this file by private mail
[20:47:22 CEST] <michaelni> but the mail doesnt say much, i dont know if it somewhere else
[20:49:14 CEST] <michaelni> ubitux, also i get "No start code is found." errors with it master too, that is not what breaks the sample it seems
[20:49:29 CEST] <Zeranoe> jkqxz: Does yours support look ahead? You can test with (notice no -look_ahead 0): ffmpeg -i in -c:v h264_qsv -vf unsharp=lx=7:ly=7:la=0.56:cx=7:cy=7:ca=0.28 -b:v 2M -preset:v veryfast -y out.mp4
[20:52:27 CEST] <jkqxz> That looks like it's running ok.  (Using ffmpeg-bad2.exe, still.)
[21:01:11 CEST] <michaelni> ubitux, returnig 0 instead of first goto fail in decode_extradata_ps() makes the file play
[21:31:31 CEST] <jkqxz> Zeranoe:  Also fine to 3000 frames on each preset.
[21:32:51 CEST] <jkqxz> Is this a relatively recent problem?  I can try upgrading the graphics driver, there is a newer version on the Intel website.
[21:34:09 CEST] <Zeranoe> jkqxz: It isn't new, but it's spotty and hard to nail down. http://trac.ffmpeg.org/ticket/4832
[21:40:10 CEST] <ubitux> michaelni: i meant in libav
[21:40:33 CEST] <ubitux> michaelni: yeah i noticed the error messages in git master that weren't here before
[21:50:24 CEST] <jkqxz> Zeranoe:  The driver I'm using does predate the first report there.  I'll update and try again.
[22:00:29 CEST] <jkqxz> Hmm, nope.  The web page lies about the version.  Actually this is the latest one.
[22:03:08 CEST] <jkqxz> So I guess that doesn't really show very much at all (maybe it doesn't happen on this machine).  I'm happy to do more testing if you come up with something, but it doesn't look like this line of enquiry is going anywhere.
[22:07:30 CEST] <Zeranoe> jkqxz: I'd agree. It doesn't seem to affect my 4th gen and perhaps not the N* line. Which doesn't make much sense but who knows
[22:09:26 CEST] <Zeranoe> I submitted a patch yesterday to fix QSV for the 4th gen so I could even test it.
[22:38:15 CEST] <michaelni> ubitux, does the goto/return solve this or should i look more into this ?
[22:39:43 CEST] <Easyfab> jkqxz: here new driver for braswell http://www.station-drivers.com/index.php?option=com_remository&Itemid=352&func=fileinfo&id=2271&lang=en if you want to test with 1.16 msdk
[22:48:04 CEST] <jkqxz> "Operating System(s): Microsoft Windows* 10 64".  Looking a bit further at the Intel site, it suggests support for Windows < 10 on Braswell has been ended already.
[23:18:58 CEST] <Zeranoe> Classic Intel
[23:25:57 CEST] <Compn> i dont get how microsoft ends win7 support
[23:26:05 CEST] <Compn> win10 is not even an os yet
[23:26:22 CEST] <ubitux> michaelni: feel free to make a patch, otherwise i'll look into it tmr
[23:29:21 CEST] <jamrial> Compn: win7 is almost seven years old by now
[23:30:47 CEST] <jamrial> and it's not like they are fully dropping support. security patches are guaranteed for a few more years afaik
[23:47:20 CEST] <Illya> ubitux: so I spoke to the libopenmpt guys, and apparently get_channels actually gets the tracks in the tracked file. So it's up to the end user to decide if they want 4/2/1 channels. They also suggested to use 2channels for most things, even for mono and surround sound, as most tracked files dont do either very well. I was thinking to default to stereo and then have overrides for mono and surround, how does this
[23:47:21 CEST] <Illya>  sound? (also, the layout for surround is FL/FR/RL/RR)
[23:50:05 CEST] <ubitux> Illya: a private option to force a user channel layout? sure
[23:50:25 CEST] <ubitux> you even have AV_OPT_TYPE_CHANNEL_LAYOUT
[23:50:44 CEST] <ubitux> Illya: btw, i think the most important thing would be a fast probe function
[23:51:13 CEST] <ubitux> something to say, from a given buffer, if the file is likely supported/openable or not by the library
[23:53:25 CEST] <Illya> yes, I will look into it further, maybe I was using the probe function wrongly
[00:00:00 CEST] --- Sun Jun 19 2016