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

[burek]

[00:34:03 CEST] <cone-872> ffmpeg 03Michael Niedermayer 07master:8a3221cc67a5: avformat/mov: Check sample size
[02:19:49 CEST] <Illya> ubitux: test atrac1-1 seems broken, I set my demuxer's probe to always return 1, and then ran `make fate-atrac1-1` which failed because it was picking it up as libopenmpt, but when I set it to return always 0 it passes (as expected because it wouldnt be recognised as libopenmpt). Considering that with a confidence of 1% it still chooses libopenmpt, I dont think this is my fault. What's your take on this?
[02:23:13 CEST] <nevcairiel> you should probably add a cut-off when you return 0, low probe scores on all sorts of random files are a plague that cause all sorts of issues
[02:23:56 CEST] <nevcairiel> we already have a few formats that cause misdetections, better not add new ones
[02:38:25 CEST] <Illya> heh. This probe function is giving atrac1-1 70% confidence before I filter it. that seems very broken
[02:49:09 CEST] <durandal_1707> Illya: atrac probe could be made better?
[02:55:04 CEST] <Illya> durandal_1707: I was thinking that, I'll look into it tomorrow. I've notified the libopenmpt guys, and given them some samples just now.
[04:50:22 CEST] <MelchiorGaspar> https://trac.ffmpeg.org/ticket/4478
[09:40:13 CEST] <cbsrobot> ubitux: do you still have that link to that "video analysis page" you posted here recently ?
[09:44:47 CEST] <cbsrobot> ah found it ...
[10:05:40 CEST] <ubitux> any suggestion on how i could create a file with various fucked up start time with ffmpeg?
[10:58:59 CEST] <cone-963> ffmpeg 03Matthieu Bouron 07master:db0af7250a27: lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers
[11:01:40 CEST] <cone-963> ffmpeg 03Clément BSsch 07release/3.1:25f0ea9ece79: lavc/pnm_parser: disable parsing for text based PNMs
[11:01:41 CEST] <cone-963> ffmpeg 03Matthieu Bouron 07release/3.1:8fd56690774b: lavc/mediacodecdec_h264: add missing NAL headers to SPS/PPS buffers
[11:04:25 CEST] <BtbN> hm, this "ABI breakage" could be easily fixed, but then it would break stuff built against 3.1.0, if 3.1.1 comes out
[11:04:55 CEST] <nevcairiel> i dont care about apps that use private api/abi :p
[11:05:39 CEST] <cone-963> ffmpeg 03Vittorio Giovara 07master:c3ed259e4fef: fate: Move Canopus decoder tests to a separate file
[11:05:40 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:dd1b1e32238b: Merge commit 'c3ed259e4fef64a1af4f6537be545fba47491aa9'
[11:05:55 CEST] <BtbN> Where is it documented that those fields are private? I can't see it from the header.
[11:06:52 CEST] <nevcairiel>      * All fields below this line are not part of the public API. They
[11:06:52 CEST] <nevcairiel>      * may not be used outside of libavfilter and can be changed and
[11:06:52 CEST] <nevcairiel>      * removed at will.
[11:07:38 CEST] <cone-963> ffmpeg 03Paul B Mahol 07master:6e2ad28cf764: aic: add frame threading support
[11:07:38 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:ee7d01e81a7f: Merge commit '6e2ad28cf76461b02d85ad178087ba0c628b8d9d'
[11:07:52 CEST] <BtbN> That's confusing enough for even ffplay to fail at it.
[11:08:25 CEST] <nevcairiel> like I said yesterday, ffplay and ffmpeg arent known for their API/ABI cleanlyness
[11:08:29 CEST] <BtbN> My idea for this would be: As it's not public ABI, move the field again, to the end of the struct. So existing debian and stuff can update without too much breakage. And then fix ffplay.
[11:09:46 CEST] <cone-963> ffmpeg 03Paul B Mahol 07master:2a48a75a6f50: sgirledec: simplify, no need to use reget buffer
[11:09:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:1994a73a6ba4: Merge commit '2a48a75a6f508121b96b0732a9fe03a46303f579'
[11:17:59 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:b7f98659f21d: Remove unnecessary get_bits.h #includes
[11:18:00 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9b35242370be: Merge commit 'b7f98659f21dce438c33b512e25fd64b8d07c347'
[11:19:56 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:09c4e5c5988c: indeo2: Drop disabled big-endian ir2_codes table
[11:19:57 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:543142990b6f: Merge commit '09c4e5c5988c0037d108c5fc2a137d9ad488f7f4'
[11:21:57 CEST] <BtbN> nevcairiel, are the fields in AVFilterContext also non-public?
[11:21:59 CEST] <andrey_turkin> libav merge queue is nearing next h264 wave
[11:22:19 CEST] <nevcairiel> BtbN: all changes in that commit are in non-public areas
[11:22:28 CEST] <BtbN> That's not from that commit though
[11:23:22 CEST] <BtbN> I'm looking at git diff n3.0.2..HEAD libavfilter/avfilter.h  https://gist.github.com/BtbN/79571efbc0e822b98ae48e1347f0f4eb
[11:23:53 CEST] <BtbN> vs. https://gist.github.com/e2fdebdb7f52cd8670bd1404fdd3abef
[11:24:19 CEST] <BtbN> later one is how it currently is in ffmpeg, first one is how it would have avoided the problems
[11:27:53 CEST] <nevcairiel> the change to avfiltercontext might be problematic as those fields are note delcared private, although with their lack of docs in general probably not used much
[11:28:06 CEST] <nevcairiel> the change to avfilterlink is just apps being bad and using things they shouldnt
[11:37:02 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:b668662939de: get_bits: Move BITSTREAM_READER_LE definition before all relevant #includes
[11:37:02 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:ae753dbd0de4: Merge commit 'b668662939de3a02454cfc9ba3e6d10b87527a40'
[11:37:57 CEST] <ubitux> any idea why the merge in 59c6509 is "silly"?
[11:38:05 CEST] <ubitux> s/merge/assert/
[11:38:45 CEST] <nevcairiel> probably because it compares a bunch of compile time constants?
[11:39:44 CEST] <nevcairiel> and MIN_CACHE_BITS as part of the old bitstream reader is probably scheduled for removal
[11:40:49 CEST] <nevcairiel> at least i assume thats where the define come sfrom
[11:40:56 CEST] <ubitux> ok
[11:41:17 CEST] <ubitux> i wouldn't call this "silly" but whatever, i'll merge it
[11:42:30 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:59c6509d9f02: mss2: Drop a silly assert
[11:42:31 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:f755aa5ebdb8: lavc: move 2 more BITSTREAM_READER_LE definitions
[11:42:32 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9afa64dfdffd: Merge commit '59c6509d9f0236acbc317198eab76dab8320bced'
[11:44:02 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:6d8fd614ff95: vorbis: Kill some pointless debug code
[11:44:03 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:f8beca6f1081: Merge commit '6d8fd614ff957af242efcd8a6a0619874382f3a4'
[11:45:16 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:85b8403c6fd1: svq1enc: Drop unused GetBitContext context member
[11:45:17 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c7253353f8f1: Merge commit '85b8403c6fd11e1c570caa970c7f435ac5f9583e'
[11:46:11 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:42dc21432363: mpc: Drop unused GetBitContext context member
[11:46:12 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:0501305e38ad: Merge commit '42dc214323637464759354912e18b2bee1884dd1'
[11:49:27 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:81f769fa129e: gsm: Move requant_tab table to the gsm tables file
[11:49:28 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:daedfa72541c: Merge commit '81f769fa129edc51c28285649c2df6da717e718f'
[11:51:25 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:6ac52f05a6fc: dvbsub_parser: Add missing mem.h #include
[11:51:26 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:bf7d01621917: Merge commit '6ac52f05a6fcadb84972c9557b28c67a416f866b'
[11:55:30 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:197ae68e7878: Drop unnecessary unary.h #includes
[11:55:31 CEST] <cone-963> ffmpeg 03Diego Biurrun 07master:4f81f8dba735: Drop unnecessary golomb.h #includes
[11:55:32 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4b9574b275c2: Merge commit '197ae68e78784524a7ccf97a3c301092715305d3'
[11:55:33 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:bef74ef36705: Merge commit '4f81f8dba735c212efae077c4fec8ad4fe53b352'
[12:00:04 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:2e4a7bd553ec: h264: drop unused H264Context.gb
[12:00:05 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:fc0eafb7f8b2: Merge commit '2e4a7bd553ec7c805b4a3b90733405a14ba69072'
[12:00:51 CEST] <ubitux> alright, i'm at the new h264 wave
[12:01:02 CEST] <ubitux> which begins with vaapi stuff
[12:01:10 CEST] <ubitux> hopefully i can test those...
[12:01:12 CEST] <nevcairiel> BtbN: looking at the ABI diffs linked yesterday, the AVFilterContext appears to be the only one that is truely wrong according to your documentation and usage, if you want to send a patch to the ML to move it we can properly discuss it there
[12:01:32 CEST] <BtbN> did exactly that one minute ago
[12:01:38 CEST] <nevcairiel> ah
[12:01:54 CEST] <nevcairiel> ubitux: the vaapi encoder is basically identical to libav i think, so you could just merge them
[12:02:08 CEST] <nevcairiel> (its also unrelated to the h264 set as such)
[12:03:26 CEST] <ubitux> ah indeed
[12:03:39 CEST] <ubitux> no conflict, compiles
[12:04:47 CEST] <nevcairiel> if you have any troubles with the vaapi encoder i'm sure jkqxz will also be happy to answer any questions
[12:05:10 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:081961f819c0: vaapi_h264: Add support for VUI parameters
[12:05:11 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:19d7667a8149: vaapi_encode: Add support for writing arbitrary additional packed headers
[12:05:12 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:48e2967cd50c: vaapi_h264: Add support for SEI messages
[12:05:13 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:02fa1ad9266f: vaapi_h264: Add source version identifier as unregistered SEI
[12:05:14 CEST] <cone-963> ffmpeg 03Mark Thompson 07master:2940e196c5e4: vaapi_h265: cu_qp_delta should not be used in constant-QP mode
[12:05:15 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3e71e34333c7: Merge commit '081961f819c0b16c7a860d7da7d39f1fd91bd2f0'
[12:05:16 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:19fe328f12f6: Merge commit '19d7667a81499d4357ec8e0851701e17c238e584'
[12:05:17 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:cc3de390b724: Merge commit '48e2967cd50c2e1a2a539fd697d20ead2c5c4cc8'
[12:05:18 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4b90413cb26e: Merge commit '02fa1ad9266f9b1ea11565ac2f93f45853e351e8'
[12:05:19 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:6c841e03ceba: Merge commit '2940e196c5e439d9869f8c02a49a318d0847453c'
[12:05:57 CEST] <ubitux> now at the wave.
[12:11:57 CEST] <jkqxz> He would :)  But yes, the code has had no opportunity to diverge (and I will try to keep it that way).
[12:53:39 CEST] <ubitux> michaelni: could you test "[PATCH] lavc/h264_slice: move au_pps_id and current_sps_id assignment earlier" with the security relevant samples?
[12:54:18 CEST] <BtbN> Any in-progress merges right now, or am free to push without causing more work?
[12:55:22 CEST] <BtbN> ubitux, ^ i guess
[12:57:21 CEST] <ubitux> it's ok, go ahead
[12:57:35 CEST] <ubitux> i'm blocked currently because of my latest patch
[12:58:17 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1bd9fb6de59b: ffplay: Fix usage of private lavfi API
[12:58:18 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1eb43af1a0e5: lavfi: Move new field to the end of AVFilterLink
[13:14:33 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:cd427a9d07e8: ffplay: Fix usage of private lavfi API
[13:14:34 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:0a6d7602308e: lavfi: Move new field to the end of AVFilterLink
[14:02:40 CEST] <ubitux> michaelni: thanks :)
[14:25:22 CEST] <BtbN> how do I read the "git show" of a merge commit? What do the two columns of + and - mean?
[14:26:12 CEST] <BtbN> git show 8688d3a has https://bpaste.net/show/8eab46d16574 and I'm quite sure the fields after hw_device_ctx existed before that?
[14:28:29 CEST] <ubitux> yes that's why they are on the 2nd column of addition
[14:28:39 CEST] <ubitux> that is, diff from the 2nd parent (libav)
[14:29:28 CEST] <BtbN> ah, so this ABI break occured because the later fields didn't exist in libav, and it was merged in front of them?
[14:30:18 CEST] <BtbN> Yeah, looks like it
[14:30:19 CEST] <ubitux> git diff 8688d3a~1..8688d3a
[14:30:53 CEST] <ubitux> yes it was added on top of our fields
[14:31:04 CEST] <ubitux> which are private so it shouldn't have been a problem
[14:31:08 CEST] <ubitux> but in practice it is :p
[14:31:13 CEST] <BtbN> They are private?
[14:31:27 CEST] <ubitux> yes
[14:31:37 CEST] <BtbN> The ones in AVFilterLink are marked as such, but the ones in AVFilterContext?
[14:32:41 CEST] <ubitux> mmh indeed not in AVFilterContext
[14:33:18 CEST] <BtbN> Funny enough moving the fields that are marked as private was what caused stuff to break.
[14:33:31 CEST] <BtbN> Nothing seems to be using the fields in the Context
[14:33:35 CEST] <BtbN> nothing external
[14:34:21 CEST] <BtbN> Moving it to the end now would break stuff though, namely all the ff* tools. So I'm not sure what to do about it.
[14:48:17 CEST] <mateo`> Someone knows where the h264 decoder adjust its width/height in case of interlaced pictures ?
[14:49:48 CEST] <JEEB> I think it just outputs two images interleaved or something?
[14:49:55 CEST] <JEEB> only the hevc decoder actually outputs separate ones
[14:50:07 CEST] <JEEB> and then I think not a lot of stuff is able to habla that :D
[14:51:03 CEST] <mateo`> I was not able to find where the avctx->width is adjusted in that case (not that I've searched a lot though)
[14:52:17 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:e6e8750e9432: avcodec/h264: Remove current_sps_id
[14:52:18 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:0c50f6905fb3: avcodec/h264: Remove au_pps_id
[14:52:29 CEST] <ubitux> \o/
[14:52:41 CEST] <ubitux> thanks :)
[15:02:03 CEST] <mateo`> got it (        h->mb_height = sps->mb_height * (2 - sps->frame_mbs_only_flag);
[15:02:05 CEST] <mateo`> )
[15:02:17 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:d06e4d8aab9c: h264: start splitting decode_slice_header()
[15:02:19 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:77a1e2c5f8f8: h264: move direct mode inits out of h264_slice_header_parse()
[15:02:19 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:b93c0aed79f7: h264: drop an outdated comment
[15:02:20 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c54e2740e1f4: Merge commit 'd06e4d8aab9c679b6aea2591d2a9b382df9e5f74'
[15:02:22 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3c5a3882f988: Merge commit '77a1e2c5f8f8250dfacff24b993eb473260ed13e'
[15:02:23 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:7f607120d997: Merge commit 'b93c0aed79f7f942e0dec26e53c147f297ce2ff6'
[15:05:46 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:b16e9b9ac9db: h264: move initialising the explicit pred weight table for MBAFF
[15:05:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:d7a245168844: Merge commit 'b16e9b9ac9db449cae2242767dd3c3fc309357c4'
[15:23:38 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:7b50d60442af: h264: call ff_h264_fill_mbaff_ref_list() when constructing the normal ref list
[15:23:39 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:527a57932765: Merge commit '7b50d60442af8d9527e9da46818011fe15a5265a'
[15:32:12 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:fa5705907919: h264: move initialising the implicit pred weight table for MBAFF
[15:32:13 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:cdecb39fca81: Merge commit 'fa57059079190242517701120cfdccad93c866da'
[15:44:26 CEST] <michaelni> ubitux, this crashes: ./ffmpeg -skip_frame nokey   -i /ld/michael/videos/h264_intra_first.ts  -an -f null -
[15:45:42 CEST] <ubitux> where can i find this sample?
[15:48:08 CEST] <ubitux> (maybe related to a833ff6?)
[15:50:11 CEST] <michaelni> ubitux, sample uploaded to fatesamples and patch for fate test posted, iam an idiot i had this test locally and thought its redundant
[15:58:16 CEST] <Illya> where is the atrac probe?
[15:59:57 CEST] <ubitux> michaelni: ok something went wrong in the first merge (c54e2740)
[16:04:24 CEST] <ubitux> [ps]ps may actually be mismatching h->ps.[ps]ps
[16:09:27 CEST] <ubitux> oh ok i get it
[16:11:31 CEST] <ubitux> michaelni: http://sprunge.us/bDTP
[16:11:37 CEST] <ubitux> can you try this with your fate test?
[16:12:57 CEST] <nevcairiel> oh right it returns those silly threading error codes still
[16:14:06 CEST] <ubitux> yeah
[16:14:10 CEST] <ubitux> and they are positive
[16:20:17 CEST] <michaelni> the new fate seems passing
[16:20:33 CEST] <ubitux> yeah just tried and it works
[16:20:46 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:a2901472fe18: lavc/h264_slice: properly forward positive "error" code
[16:25:41 CEST] Action: ubitux annoyed by ff_h264_decode_ref_pic_list_reordering() not having a const h264 context
[16:26:25 CEST] <ubitux> oh wait that could be fied
[16:26:28 CEST] <ubitux> fixed
[16:51:36 CEST] <cone-963> ffmpeg 03Michael Niedermayer 07master:89cccfc905f7: fate/h264: add test for skip-nointra and skip-nokey
[17:07:28 CEST] <ubitux> question on ff_h264_decode_ref_pic_list_reordering() in h264_refs.c
[17:07:38 CEST] <ubitux> abs_diff_pic_num is read with get_ue_golomb_long()
[17:08:00 CEST] <ubitux> while the same value is read as get_ue_golomb() (pic_id, second case)
[17:08:18 CEST] <ubitux> in the next merge this reading is decoupled from here
[17:08:26 CEST] <ubitux> and the reading of the value is unified
[17:08:37 CEST] <ubitux> should i: 1) use get_ue_golomb_long() to read all values
[17:08:55 CEST] <ubitux> 2) conditionnal read depending on the op (modification_of_pic_nums_idc)
[17:08:58 CEST] <ubitux> ?
[17:09:16 CEST] <nevcairiel> the long variant is slightly lower but allows for higher max values, our codebase has switched a bunch of  them to _long presumably because they can be higher then the normal variant allows
[17:09:19 CEST] <nevcairiel> so just use long imho
[17:09:19 CEST] <ubitux> (libav doesn't make a difference because they're using get_ue_golomb())
[17:09:30 CEST] <ubitux> (and we made the change in c51c08e0e70c186971385bdbb225f69edd4e3375)
[17:10:03 CEST] <ubitux> nevcairiel: ok, won't affect speed© ?
[17:10:41 CEST] <nevcairiel> marginally
[17:11:04 CEST] <nevcairiel> compared with another branch to split it, probably not worth uglifying the code for
[17:11:12 CEST] <ubitux> btw, it's stored as uint8_t in libav
[17:12:28 CEST] <Illya> durandal_1707: where can I find the atrac probe?
[17:17:15 CEST] <ubitux> it's not that clear in the specs what are the ranges
[17:18:11 CEST] <nevcairiel> well we already know that one value thats being read needs it, so i really wouldnt bother adding another if and whatnot there to save one cycle of execution time in a function executed at most once per slice or something
[17:19:40 CEST] <ubitux> i'm concerned about the storage for the value now
[17:19:46 CEST] <ubitux> libav uses u8
[17:19:58 CEST] <ubitux> i'm tempted to use at least u32 since we use the _long() version
[17:20:02 CEST] <ubitux> and maybe larger
[17:20:13 CEST] <nevcairiel> we used u32 before and it worked, so stick to that imho
[17:20:52 CEST] <ubitux> ah, _long is for u32 ok
[17:21:00 CEST] <durandal_1707> Illya: oma demuxer?
[17:21:50 CEST] <Illya> Ah, well I got a reply from the libopenmpt guys, they said they've fixed it now. I'm gonna ask them to release a version so that we can support that as the minimum
[17:36:15 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:ed9a20ebe4a8: h264: split reading the ref list modifications and actually building the ref list
[17:36:15 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:2aff557c6acb: Merge commit 'ed9a20ebe4a89de119ea97bdccf688ece8c6648c' into merge-libav-new
[17:42:33 CEST] <jkqxz> abs_diff_pic_num can be up to MaxPicNum, so 2 * MaxFrameNum, so 2 ^ (log2_max_frame_num_minus4 + 4).  log2_max_frame_num_minus4 is constrained to [0,12], so the max is 2^17.
[17:43:16 CEST] <ubitux> so much more than 255 :p
[17:43:29 CEST] <ubitux> i'd love such a sample
[17:43:41 CEST] <jkqxz> In practice it will never be higher than max_num_ref_frames (i.e. 16), though, because noone is going to keep moving short term pictures around to do that.
[17:44:45 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:0bad25430035: h264: move initing the implicit pred weight table out of h264_slice_header_parse()
[17:44:46 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:6dd996c7c815: h264: move building the reference list out of h264_slice_header_parse()
[17:44:47 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:3b95452ca8bb: Merge commit '0bad254300356005af4aef00a706bf2e8eee96bc'
[17:44:48 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:9ab6f01839e3: Merge commit '6dd996c7c81575a1e4969987ab175a6df7beab3d'
[17:45:13 CEST] <jkqxz> (That is, if the difference is that big, you would have put it in the long-term list instead.)
[18:03:30 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:4cec43a9eeb5: h264: move calculating the POC out of h264_slice_header_parse()
[18:03:31 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:4890b0851c5e: Merge commit '4cec43a9eeb58eb9e581a2d9d25f78e5bfbb0960'
[18:04:37 CEST] <ubitux> going home, i'll continue the merge in about an hour
[18:04:55 CEST] <ubitux> 114 commits left
[18:25:31 CEST] <JEEB> gg
[18:40:07 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07master:1a75145559d3: lavfi: Move new field to the end of AVFilterContext
[19:02:55 CEST] <cone-963> ffmpeg 03Timo Rothenpieler 07release/3.1:1fdf54946244: lavfi: Move new field to the end of AVFilterContext
[19:05:48 CEST] <jamrial> michaelni: wouldn't it be a good idea to release 3.1.1 asap to make sure distros update to that instead of 3.1?
[19:06:10 CEST] <jamrial> Arch (the fastest distro to update packages) hasn't done it yet, for example
[19:07:38 CEST] <BtbN> Someone should also check if other ABI breaks sneaked in. Couldn't find any other altered structs with stuff added in the middle so far though.
[19:07:49 CEST] <jamrial> funny enough, the one change that apparently broke everything is the one that was never supposed to be public api
[19:08:04 CEST] <jamrial> so library users are at fault for abusing the api :P
[19:08:20 CEST] <andrey_turkin_> jamrial: Gentoo is faster...
[19:08:25 CEST] <michaelni> are there any other regressions we should fix before releasing ?
[19:08:43 CEST] <JEEB> andrey_turkin_: > gentoo > not taking ages to get something to being the default version of something
[19:08:51 CEST] <jamrial> andrey_turkin: not as stable
[19:09:02 CEST] <ubitux> the pnm regression fix was backported by mateo` 
[19:09:03 CEST] <jamrial> they update packages fast but leave them masked
[19:09:06 CEST] <ubitux> i don't know any other
[19:09:16 CEST] <andrey_turkin_> agreed on that..
[19:11:18 CEST] <jamrial> IMO, if it wasn't for the AVFilterContext public abi break (which apparently has no real effect since nothing accessed the affected fields) i would have left the AVFilterLink stuff intact
[19:11:41 CEST] <nevcairiel> broken software is broken
[19:11:44 CEST] <jamrial> it was a good chance to let library users know they are really not supposed to directly access fields marked as "do not access directly"
[19:11:50 CEST] <jamrial> and fix their code
[19:11:56 CEST] <BtbN> That mark is quite easy to miss though
[19:12:19 CEST] <BtbN> Isn't it possible to hide those fields, via an internal-only define or something?
[19:12:30 CEST] <BtbN> Or would changing the struct size break external stuff?
[19:13:14 CEST] <nevcairiel> should just move them to an internal struct
[19:13:16 CEST] <jamrial> if a five lines long warning about private fields is not enough, then what? a big 10 lines long, all caps, exclamation mark filled warning?
[19:13:55 CEST] <ubitux> having a x->internal field instead of "fields below are private" would probably be appropriate yes
[19:14:04 CEST] <ubitux> or maybe we should just prefix these fields by "_"?
[19:14:27 CEST] <andrey_turkin_> is there some __attribute__((cant_touch_this)), similar to deprecated?
[19:15:34 CEST] <jamrial> what ubitux is a good idea. we do that for other structs
[19:15:45 CEST] <Illya> andrey_turkin: I believe it's called __attribute__((hammer_time))
[19:16:12 CEST] <andrey_turkin_> probably not in clang yet
[19:17:34 CEST] <andrey_turkin_> #define INTERNAL(x) _x to use on field names in public headers? Ugly but it will get the point across
[19:18:13 CEST] <nevcairiel> should just move them to AVFilterLinkInternal like many other structs do
[19:18:34 CEST] <nevcairiel> no need to invent new fancy ways
[19:18:53 CEST] <ubitux> "AV"? FF and internal header
[19:19:11 CEST] <nevcairiel> the internal things are all called like that
[19:19:15 CEST] <nevcairiel> $structInternal
[19:19:28 CEST] <nevcairiel> but its struct definition is not public
[19:39:06 CEST] <cone-963> ffmpeg 03Petru Rares Sincraian 07master:2b1995e3eeb3: fate: add test for asetnsamples
[19:46:38 CEST] <atomnuker> jamrial: any tips on how to save 2 registers on the signed_rect asm to make it run on 32 bits?
[19:50:44 CEST] <jamrial> use the reg you were using for height (r6 i think), and handle the height value directly from stack, since you can use arithmetic instructions with a memory operand
[19:51:40 CEST] <jamrial> look at the m and mp suffixes in x86inc, DECLARE_REG macro
[19:58:48 CEST] <michaelni> jamrial, for 3.1.1 https://trac.ffmpeg.org/ticket/5676 and https://trac.ffmpeg.org/ticket/5678 and maybe https://trac.ffmpeg.org/ticket/5671 should be fixed first i think
[20:03:35 CEST] <nevcairiel> 5676 is fixerd by the things jamrial refers to
[20:03:57 CEST] <nevcairiel> the dvd ticket lacks any information to reproduce it
[20:04:44 CEST] <michaelni> the last comment  in 5676 says "release/3.1 is still broken" 
[20:04:47 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:7ab5d577a9af: h264: move initializing the slice start out of h264_slice_header_parse()
[20:04:48 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:c28aecc56ace: Merge commit '7ab5d577a9affe3397c08b032f983f9bf7101865'
[20:05:33 CEST] <nevcairiel> both these tickets lack any useful information then
[20:09:09 CEST] <cone-963> ffmpeg 03Anton Khirnov 07master:39ab2ea53121: h264: rename mmco_index to nb_mmco
[20:09:10 CEST] <cone-963> ffmpeg 03Clément BSsch 07master:57d30fde9ea8: Merge commit '39ab2ea53121b9976a619cd545fbd3464b908696'
[20:37:10 CEST] <jamrial> i think i found why mpv still fails
[20:37:32 CEST] <jamrial> "mp_chmap_from_channels(&lavc_chmap, avframe->channels);" in audio/audio.c
[20:37:43 CEST] <jamrial> avframe->channels should not be accessed directly
[20:37:56 CEST] <jamrial> commit 1a708780f3d4b431996d118df4e448b4f2a7942e changed its position
[20:48:54 CEST] <jamrial> https://github.com/mpv-player/mpv/issues/3295
[20:57:21 CEST] <jamrial> since we dropped compatibility with libav, we should probably just allow direct access to fields like these from avframe next time we bump major
[21:00:47 CEST] <jamrial> well, wm4 closed and locked the above ticket...
[21:03:59 CEST] <nevcairiel> enocare then
[21:05:02 CEST] <nevcairiel> he doesnt even recognize that his code is the one being dumb, but what can you do
[21:05:21 CEST] <jamrial> he recognized it in a following comment, but still said he didn't care
[21:05:58 CEST] <jamrial> i wondered why wm4 hasn't joined this channel for weeks now. guess i know why now...
[21:06:40 CEST] <nevcairiel> he is butthurt for some reason again
[21:08:59 CEST] <jamrial> i'm going to guess it's the whole circus from a month ago
[21:09:08 CEST] <jamrial> he's probably fed up for a while, and i don't blame him
[21:09:58 CEST] <jamrial> still doesn't justify keeping a bug in his code, though
[21:22:48 CEST] <jamrial> yep, kodi as well :p
[21:24:29 CEST] <jamrial> i'll probably kill all this get/set crap for fields in public headers as soon as we bump major. the ones that exist because of libav compat
[21:30:24 CEST] <nevcairiel> might be nice to keep the functions, but some re-ordering and removing comments might be nice
[21:30:47 CEST] <fritsch> yeah, he reacted quite strange
[21:30:58 CEST] <fritsch> we (kodi) are happy to get such reports and like to fix these
[21:31:28 CEST] <jamrial> the functions should remain but deprecated for two years as usual, yeah
[21:31:40 CEST] <jamrial> fritsch: thanks
[21:31:50 CEST] <fritsch> so i now "fix" those methods in and in 2 years I remove them again? :-)
[21:32:00 CEST] <fritsch> if you can do a short grep and just point me the issues I will fix thme
[21:32:10 CEST] <fritsch> though it's quite hard for downstream to use these correctly
[21:32:16 CEST] <nevcairiel> if you dont care about running with any other version then the one you built with, you can also keep it as is
[21:32:29 CEST] <fritsch> we don't care - yes
[21:32:31 CEST] <fritsch> but ...
[21:32:34 CEST] <fritsch> arch, gentoo
[21:32:35 CEST] <fritsch> debian
[21:32:41 CEST] <nevcairiel> tell them to suck it :p
[21:32:41 CEST] <fritsch> debian-multimedia
[21:32:43 CEST] <fritsch> will bug you
[21:32:50 CEST] <fritsch> as you see on current trac
[21:33:01 CEST] <fritsch> that's what we don't want - so we need to use the api correctly
[21:34:39 CEST] <fritsch> jamrial: so in case you stumble on something do not hessitate to add these here: https://github.com/xbmc/xbmc/pull/10043
[21:35:22 CEST] <fritsch> fernet did not want to fix these, cause we linked against ffmpeg statically in the first place, to not have support every single distro building against ffmpeg 3 years old, libav from tomorrow and so on
[21:36:09 CEST] <nevcairiel> you should see firefox that ship binaries that are supposed to be compatible with every ffmpeg on this planet
[21:36:13 CEST] <nevcairiel> their wrapper is pure madness
[21:36:36 CEST] <fritsch> nope, that's not what we want
[21:36:37 CEST] <JEEB> and then they use C++ templates to switch
[21:37:05 CEST] <fritsch> we try to base on latest stable as good as it works and that must be enough
[22:56:37 CEST] <michaelni> nevcairiel, do you want to take over release management ?
[22:57:39 CEST] <ubitux> https://github.com/mpv-player/mpv/issues/3295 we lost someone it seems
[23:01:07 CEST] <nevcairiel> michaelni: no, but that doesnt prevent me from having an oppinion either way
[23:02:14 CEST] <michaelni> nevcairiel, i would like to fix the issue so distributions can just use 3.1 and not have everything randomly break
[23:02:32 CEST] <nevcairiel> I want app developers to notice their usage is wrong and fix it, its not our bug
[23:02:55 CEST] <michaelni> nevcairiel, we already lost wm4 and mpv IIUC
[23:03:04 CEST] <jamrial> really, the only actual abi break was the avfiltercontext one and that's already fixed
[23:03:29 CEST] <ubitux> mpv will break everytime there is a need for getters btw
[23:03:29 CEST] <nevcairiel> we have a separation between public and private fields in a bunch of contexts for a reason
[23:03:41 CEST] <nevcairiel> and we have added new public fields above the private marker before
[23:03:45 CEST] <nevcairiel> so its not a new "problem"
[23:03:46 CEST] <ubitux> (because wm4 is very reluctant to use them)
[23:03:50 CEST] <nevcairiel> for some reason it matters this time tho
[23:03:56 CEST] <jamrial> and no, mpv still works. their readme now states that they will not bother with issues regarding private fields anymore
[23:04:39 CEST] <nevcairiel> private fields should ideally be moved into a $structInternal context instead of this separation
[23:04:48 CEST] <nevcairiel> so no project uses fields that break
[23:04:54 CEST] <ubitux> i'm against adding more getters/setters; we don't need abi compat with libav anymore
[23:05:02 CEST] <ubitux> we have to be careful with private/public things
[23:05:24 CEST] <michaelni> can we bump major of all libs ?
[23:05:26 CEST] <ubitux> and maybe the internal field is the way to go to actually prevent users (and ourselves) from fucking up everything
[23:05:43 CEST] <ubitux> i think libav plans to bump
[23:05:46 CEST] <nevcairiel> so whats different in 3.1 that warrants this entire discussion, when previous releases have added new public fields and changing the offset of private fields?
[23:06:02 CEST] <rcombs> move all private fields to internal structs; bump major versions
[23:06:09 CEST] <rcombs> sounds good
[23:06:19 CEST] <ubitux> and deprecate getters
[23:06:22 CEST] <ubitux> +setters
[23:06:30 CEST] <michaelni> you misunderstand
[23:06:42 CEST] <michaelni> can we bump major in 3.1 ?
[23:06:49 CEST] <nevcairiel> 3.1 is released already
[23:06:54 CEST] <michaelni> 3.1.1 
[23:07:15 CEST] <nevcairiel> just make it 3.2 and forget 3.1 ever existed then
[23:07:32 CEST] Action: rcombs shrugs
[23:07:39 CEST] <michaelni> can we remove the recommandition of people upgrading to 3.1 ?
[23:07:40 CEST] <ubitux> if you bump major, also bump major of the main ffmpeg version (4.0)
[23:08:03 CEST] <rcombs> oh boy, are we becoming Chrome
[23:08:11 CEST] <ubitux> and maybe make a proper release notes and not do it in a hurry again
[23:08:15 CEST] <jamrial> michaelni: yeah, that's a good start (remove recommendation)
[23:08:17 CEST] <ubitux> to prevent mess like this
[23:08:23 CEST] <rcombs> (what does the main ffmpeg major version even mean)
[23:08:24 CEST] <michaelni> jamrial, ill send a patch
[23:09:08 CEST] <jamrial> It will be a mess if we bump major in a branch. if it comes to it, we should bump major in master, make private fields public as needed, deprecate accessors as needed, and release 3.2
[23:09:26 CEST] <jamrial> but really, the one abi break was in libavfilter. everything else is misuse by librayr users...
[23:09:45 CEST] <nevcairiel> <nevcairiel> so whats different in 3.1 that warrants this entire discussion, when previous releases have added new public fields and changing the offset of private fields? 
[23:09:48 CEST] <nevcairiel> ^^ still wondering about that
[23:09:54 CEST] <rcombs> what broke with mpv anyway
[23:10:04 CEST] <jamrial> they accessed a private field in avstream
[23:10:05 CEST] <ubitux> access to .channels
[23:10:19 CEST] <nevcairiel> jamrial: avfilterlink i think
[23:10:20 CEST] <jamrial> when we added a new public one above it, offset changed for the private fields
[23:10:29 CEST] <nevcairiel> or avstream as well?
[23:10:37 CEST] <ubitux> we had a getter but they didn't want to use it iiuc
[23:10:38 CEST] <jamrial> mpv? just avstream afaik
[23:10:51 CEST] <jamrial> avfilterlink was ffplay only it seems
[23:11:00 CEST] <rcombs> oh, AVFrame::channels?
[23:11:00 CEST] <nevcairiel> ah no mpv uses avframe
[23:11:08 CEST] <jamrial> yeah, frame
[23:11:10 CEST] <jamrial> my bad
[23:11:18 CEST] <jamrial> ugh, sorry. mixing names
[23:11:29 CEST] <nevcairiel> those getters should probably go away, but in the documented 3.0/3.1 ABI the change is still "ok"
[23:11:31 CEST] <jamrial> mpv was api misuse from their part. not an abi break
[23:11:54 CEST] <nevcairiel> back when we still wanted libav compat, this would've been the only way
[23:12:04 CEST] <rcombs> why is that semi-private anyway
[23:12:05 CEST] <jamrial> AVFilterContext was broken and already fixed
[23:12:16 CEST] <nevcairiel> rcombs: remnant from libav-compat
[23:12:30 CEST] <jamrial> AVFilterLink was never broken, but we moved a private field around just to make it easier for those applications misusing the api
[23:12:34 CEST] <nevcairiel> because we had to reserve the right to add new fields below the line where libav fields existed
[23:12:42 CEST] <michaelni> "<jamrial> but really, the one abi break was in libavfilter. everything else is misuse by librayr users..." <-- the misuse is in our code and i would like to fix that
[23:12:58 CEST] <nevcairiel> the avfilter misuse was fixed in ffplay
[23:13:23 CEST] <jamrial> michaelni: you mean the avstream fields by ffmpeg, ffprobe, src_movie and tools/uncoded_frame?
[23:13:29 CEST] <michaelni> jamrial, yes
[23:13:57 CEST] <michaelni> it may be not a major thing as fate didnt crash but it itches me i want t fix this
[23:14:24 CEST] <nevcairiel> What I would like to see for some future release is getting rid of all those private fields in public contexts (moving them into *Internal contexts) and getting rid of the accessors that only exist for libav compat (after deprecation of course), that way all fields they see in a header can be treated equally
[23:14:39 CEST] <michaelni> nevcairiel, +1
[23:14:48 CEST] <michaelni> i dont know why we forgot this 
[23:16:15 CEST] <ubitux> can we target this for 4.0 in 3 months?
[23:16:22 CEST] <jamrial> we didn't forget. private fields are old, be it because of libav compat or just because when the struct was designed nobody thought about an *internal field
[23:17:04 CEST] <michaelni> we should have moved our intended to be public fields in the public area before 3.0
[23:17:21 CEST] <jamrial> but yeah, next major bump should clean all this private crap to instead use new opaque *internal fields containing everything
[23:31:27 CEST] <anticw> re: mpegts i see the continuity counter as either 0 or 1, i expected to see increasing then wrapping values; is this related to #2828  ?
[23:31:47 CEST] <anticw> https://trac.ffmpeg.org/ticket/2828 (sorry, thought meebe doing #<n> would have a bot give the URL)
[23:32:36 CEST] <BBB> whats going on?
[23:32:57 CEST] <BBB> michaelni: I have the feeling youre overreacting
[23:33:57 CEST] <jamrial> BBB: we found out AVFilterContext abi was broken (already fixed), then that at least two library users are misusing the avframe api, and then that ffmpeg and ffprobe is also misusing the avstream api
[23:34:28 CEST] <BBB> I can see that, but why is michael suggesting we remove the recommendation to upgrade to 3.1?
[23:34:43 CEST] <BBB> that seems & a little much?
[23:35:06 CEST] <jamrial> ffmpeg/ffprobe compiled with 3.0 but run using 3.1 libraries can crash because of said avstream misuse
[23:35:22 CEST] <BBB> but that is highly unlikely to happen
[23:35:28 CEST] <nevcairiel> my main question could not be answered yet: we've added public fields before the marker in previous releases, why is 3.1 a problem nw?
[23:35:36 CEST] <BBB> on normal systems, an upgrade of libav*.so also upgrades ffmpeg/ffprobe
[23:35:40 CEST] <nevcairiel> now*
[23:35:54 CEST] <BBB> (not to mention that these are bugs in ffmpeg/ffprobe)
[23:36:33 CEST] <nevcairiel> of course the ultimate goal should be to get of this entire concept so such probelms are impossible
[23:37:01 CEST] <nevcairiel> but it requires at least a couple days of working that out and testing and reviewing -- and still breaks the API/ABI of those that (mis-)used those fields
[23:37:51 CEST] <BBB> we should recommend that people upgrade to 3.1 tools-and-libs-at-the-same-time
[23:38:13 CEST] <nevcairiel> that should always be a recommendation regardless of what we do :)
[23:38:31 CEST] <jamrial> either that or removing the recommendation altogheter is much better than adding accessors that will be there for, at the very least, two years before we can remove them, yeah
[23:39:57 CEST] <andrey_turkin_> anticw: do you mean you see continuity counter errors in single mpegts file?
[23:40:14 CEST] <jamrial> nevcairiel: regarding that question, i guess previous cases of adding public fields above private markers never broke ffmpeg/ffprobe/ffplay because they were used properly, or not at all
[23:40:17 CEST] <BBB> so practically, we had struct { /* public */ a; /* private */ b; }
[23:40:19 CEST] <jamrial> whereas this time it happened
[23:40:24 CEST] <BBB> and a libav merge pulled in a c in between
[23:40:29 CEST] <BBB> and something accessed b directly
[23:40:31 CEST] <nevcairiel> pretty much
[23:40:36 CEST] <BBB> where something is ffplay/ffmpeg/mpv/etc., right?
[23:40:48 CEST] <michaelni> yes
[23:40:48 CEST] <jamrial> yeah
[23:40:51 CEST] <BBB> so can we release a 3.1.1 that moves c to after b?
[23:40:56 CEST] <jamrial> no
[23:40:58 CEST] <jamrial> because c is public
[23:41:05 CEST] <BBB> ah...
[23:41:05 CEST] <BBB> ok
[23:41:08 CEST] <anticw> andrey_turkin_: no errors, just reading the wikipedia page (sorry) i expected to see the values increase to 15 then wrap
[23:41:14 CEST] <BBB> yeah so then youre screwed :)
[23:41:19 CEST] <BBB> you need to fix tools to not access b
[23:41:23 CEST] <BBB> or move b to be public
[23:41:31 CEST] <michaelni> there are several b
[23:41:37 CEST] <anticw> andrey_turkin_: so nothing wrong just unexpected values or more likely perhaps my lack of understanding
[23:41:42 CEST] <BBB> I would probably move b (or a set of b) to be public then
[23:42:07 CEST] <nevcairiel> that was one suggestion, but it still leaves those apps broken until they recompile
[23:42:12 CEST] <BBB> (if they are deemed worthy to be public)
[23:42:17 CEST] <BBB> nevcairiel: indeed
[23:42:19 CEST] <andrey_turkin_> anticw: you know they are per-PID? Do you see CC values repeating in single PID?
[23:42:24 CEST] <BBB> nevcairiel: I dont think that can be prevented
[23:42:30 CEST] <jamrial> there's probably no solution that doesn't require recompilation
[23:42:35 CEST] <BBB> right
[23:43:42 CEST] <nevcairiel> which leaves us with a few choices, do that quick and dirty and put it into 3.1.1, or do it thoroughly and do a 3.2 as soon as we deem feasible, with a major bump
[23:43:52 CEST] <nevcairiel> (or both)
[23:43:54 CEST] <jamrial> I vote the latter
[23:44:33 CEST] <jamrial> ffmpeg/ffprobe compiled with 3.0 but run with 3.1 is an use case so niche that's not worth making a mess of fields or adding accessor functions
[23:45:24 CEST] <BBB> I agree with what jamrial says
[23:45:28 CEST] <nevcairiel> mpv and kodi seem both affected to different degrees, but at least kodi seems open to fixing those abi misuse issues in their code, and both projects really dont officially support running with a mis-matched library anyway
[23:45:46 CEST] <jamrial> and i agree with BBB, instead of removing the recommendation, just make it clear that tools and libraries should ideally be updated at the same time and not mixed
[23:45:51 CEST] <anticw> andrey_turkin_: as best as i can tell for a given pid they are repeating
[23:45:56 CEST] <jamrial> because, even though it's supported, shit happens
[23:46:00 CEST] <BBB> there is an issue that we need to address, which is what do we do about future libav merges that break our upgrades
[23:46:11 CEST] <BBB> because shit happened and shit will happen again
[23:46:21 CEST] <andrey_turkin_> anticw: can you provide a sample for me to lok at?
[23:46:27 CEST] <ubitux> we don't support libav abi compat anymore so it's not a problem
[23:46:27 CEST] <nevcairiel> BBB: since we dont care about compat with them, we just have to be careful to put new members at the bottom
[23:46:44 CEST] <nevcairiel> bugs will happen, but public struct merges should just be reviewed very carefully
[23:46:45 CEST] <jamrial> and outside of the avfiltercontext merge, nothing else broke api/abi
[23:46:48 CEST] <BBB> what if they add new public members and we find ffplay was accessing another private member directly?
[23:46:54 CEST] <ubitux> having the internal field in all the struct will prevent doing such mistake in the future
[23:46:57 CEST] <BBB> just dont care until it happens?
[23:47:03 CEST] <BBB> and hope for the best?
[23:47:09 CEST] <nevcairiel> BBB: the plan is to get rid of the private fields in public structs and move them into an opaque internal struct
[23:47:11 CEST] <BBB> (Im fine with that, we should jst be explicit about it)
[23:47:18 CEST] <BBB> nevcairiel: that would be sweet
[23:47:22 CEST] <jamrial> make sure to not write patches for ffplay/ffmpeg/ffprobe using private fields is a good start...
[23:47:49 CEST] <BBB> ok I think we have a solution then
[23:47:51 CEST] <anticw> andrey_turkin_: i can later yes (it's rtsp->mpegts from a security camera so i need to make sure it's pointed at something like a blank wall)
[23:48:02 CEST] <nevcairiel> BBB: in that process, we'll at the very least find out which fields are accessed "wrongly", and can then decide to promote them to public or the app had no business using it either way
[23:48:14 CEST] <michaelni> jamrial, can you post a patch that changes thre recomandition to all libs/tools or changes the release notes ? 
[23:48:17 CEST] <BBB> michaelni: so I think the web recommendation should go but the recommendation should also be to not use ffmpeg/ffprobe 3.0 with libavcodec/* 3.1 because of a bug in the old tools
[23:48:33 CEST] <BBB> nevcairiel: yes, agreed
[23:48:53 CEST] <andrey_turkin_> anticw: you can chop first 16 kbs of the file or so; should be enough to see what's going on
[23:50:17 CEST] <jamrial> michaelni: alright
[23:50:35 CEST] <jamrial> michaelni: what's the web repository?
[23:50:48 CEST] <michaelni> thx, i think it will need fewer iterations without me being the author ;)
[23:50:58 CEST] <ubitux> https://git.ffmpeg.org/ffmpeg-web
[23:52:01 CEST] <anticw> andrey_turkin_: yeah, can do, it's not hard to see, diag output at http://f00f.org/tmp/mpegts-pid-contcount.txt means it shows up very early on and exists in most pkts so 16k will be plenty
[23:52:20 CEST] <jamrial> michaelni: not really, my english often sucks :p
[23:52:25 CEST] <jamrial> ubitux: thanks
[23:54:41 CEST] <BBB> michaelni: I dont think your authorship is the issue, although you do tend to have some consistently recurring typos :-p
[23:55:22 CEST] <BBB> brb
[00:00:00 CEST] --- Thu Jun 30 2016