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

[burek]

[00:00:57 CEST] <nevcairiel> fritsch: the reason why using the stream->codec was bad is that it was used by too many things for different purposes .. the parser in avformat uses it, the decoder on your end uses it .. and those two parse/decode different frames from different points in the bitstream, so you end up with an inconsistent state
[00:01:12 CEST] <nevcairiel> fritsch: so its much cleaner for you to just get codec parameters from avformat and manage your own  codec context
[00:06:35 CEST] <nevcairiel> (which is really only like 3 more calls, two creation and one deletion)
[02:31:08 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:0a72b6988997: MAINTAINERS: remove 2.4 as 3.1 was released
[02:31:08 CEST] <cone-414> ffmpeg 03Aman Gupta 07master:4448f16ef51b: avcodec/ccaption_dec: implement tab offset commands
[02:34:18 CEST] <ubitux> michaelni: for (int i = 0; i < lo - 0x20; i++) { 
[02:38:21 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:6cc4c422265a: avcodec/ccaption_dec: Fix mixed declaration and statement.
[02:38:26 CEST] <michaelni> ubitux, fixed
[03:25:35 CEST] <cone-414> ffmpeg 03Michael Niedermayer 07master:c0cb53cd1f91: avdevice/decklink_common: Replace rare spelling of Succesfully by 500 times more common one
[04:57:30 CEST] <rcombs> atomnuker: playing this file results in lavc asking me to upload a sample, so here ya go (if you're interested): http://eraser.de-ge.so/dl/bs11_aac_switch.ts
[04:58:06 CEST] <rcombs> "Remapped id too large" and some other things (some of which are likely a result of the file being badly trimmed)
[05:27:59 CEST] <andrey_turkin_> pfelt: as I noted before you do need to fix decklink decoder. Ensure data going into queue_put is properly reference counted. 
[05:30:18 CEST] <andrey_turkin_> basically replace av_init_packet&manual setting of pkt.data/size with av_packet_from_data
[05:41:08 CEST] <pfelt> andrey_turkin: this in ref to my email to the list?
[05:41:17 CEST] <andrey_turkin_> yes
[05:41:42 CEST] <pfelt> ah.  if you'd said that before i completely missed it
[05:45:27 CEST] <pfelt> andrey_turkin: ok.  so it looks like i can get rid of something like 4 lines and replace it with av_packet_from_data()
[05:45:46 CEST] <pfelt> (init call, data, size (which is two lines in code))
[05:46:15 CEST] <pfelt> and i see there are multiple calls to init i'll have to replace
[05:50:28 CEST] <andrey_turkin_> also don't forget to unref if queue_put fails
[06:13:54 CEST] <pfelt> andrey_turkin: if it does succeed, the pkt gets unref'd somewhere else deeper in libav*, if i'm following right
[06:19:56 CEST] <andrey_turkin_> right. queue_get or queue_flush or whatever will take care of that
[06:21:50 CEST] <pfelt> sadly i can code it up tonight, but not test it.
[07:42:46 CEST] <j-b> 'morning
[07:47:46 CEST] <kierank> i need an intern, is it kosher to mention this on ffmpeg-devel
[08:37:08 CEST] <fritsch> nevcairiel: that's what I did - thx to andrey_turkin_ that told me
[08:38:00 CEST] <fritsch> andrey_turkin_ nevcairiel I got another question though, the old api returend the number of bytes from the pkt used to e.g. decode to a frame. Is this the same as when you call: av_frame_get_pkt_size(m_pFrame1); after the receive_frame call?
[08:38:30 CEST] <nevcairiel> the new api always consume entire packets
[08:38:33 CEST] <nevcairiel> +s
[08:38:46 CEST] <nevcairiel> it says so in the docs. :)
[08:39:27 CEST] <fritsch> okay, so the it always return pkt->size?
[08:39:34 CEST] <fritsch> so, one can assume that
[08:40:04 CEST] <fritsch> err, one can assume that send_packet always eats the whole avpkt
[08:40:06 CEST] <fritsch> good
[08:40:28 CEST] <nevcairiel> you may need to call receive several times after send so the entire packet is consumed
[08:40:33 CEST] <nevcairiel> but the api docs should explain that
[08:40:54 CEST] <nevcairiel> you get EAGAIN when the other of the function pair needs to be called first
[08:42:07 CEST] <fritsch> http://paste.ubuntu.com/18013162/
[08:42:17 CEST] <fritsch> okay
[08:43:29 CEST] <nevcairiel> thats really the entire reason why we have a new api, to allow a m:n relationship between input and output
[08:44:14 CEST] <fritsch> okay, I got it
[08:44:19 CEST] <fritsch> will handle the EAGAIN directly
[08:44:22 CEST] <fritsch> for send and receive
[09:23:58 CEST] <durandal_1707> kierank: take me
[09:24:41 CEST] <kierank> I think you are too expensive for us ;)
[09:27:50 CEST] Action: durandal_1707 thinks atomnuker is starving
[10:20:59 CEST] <mateo`> ubitux, nevcairiel: are you currently working on the next merge ?
[10:43:36 CEST] <nevcairiel> not me, i'm trying to fix some fate failure
[10:45:25 CEST] <ubitux> mateo`: i'm not
[11:18:44 CEST] <michaelni> ubitux, there are some inaccuracies on coverage.ffmpeg.org like (av_file_map is marked as not exeuted but it should be from libavutil/tests/file.c also unmap is executed ...)  
[11:20:23 CEST] <michaelni> i can only guess blindly that the compiler inlined it and then lost track what actually got executed
[11:29:45 CEST] <atomnuker> rcombs: I'll look into it when I get the chance to, but it might be just a cut/corrupt bitstream
[12:15:03 CEST] <ubitux> michaelni: dunno&
[12:15:09 CEST] <ubitux> nevcairiel: http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195483.html did you see that?
[12:15:21 CEST] <ubitux> (related to the VS problem)
[12:15:55 CEST] <mateo`> 0cd5e281df3f69c1ed8f2a72a5bcbf9691e1b5d5 introduced a regression on some devices (which requires the nal headers to be present in the pps/sps), I'll send a fix asap (and will backport to the 3.1 branch)
[12:21:01 CEST] <nevcairiel> ubitux: so pnmdec is maybe just buggy as f' ? :)
[13:11:46 CEST] <andrey_turkin> nevcairiel: mind posting objdump of pnmdec.o on gist or something?
[13:17:25 CEST] <nevcairiel> andrey_turkin: http://pastebin.com/3hmk87ck .. not thats its very readable :)
[13:21:07 CEST] <andrey_turkin> no relocations there. yes, not that readable )
[13:34:06 CEST] <andrey_turkin> not that optimized
[13:43:34 CEST] <andrey_turkin> nothing obviously wrong that I can see around init_put_bits. and I expected better optimization than that
[13:45:50 CEST] <nevcairiel> well it is pretty generic code
[13:46:24 CEST] <nevcairiel> init_put_bits seems to be inlined, and my guess is that it screws that up then
[13:46:34 CEST] <andrey_turkin> doen't look that way
[13:46:47 CEST] <nevcairiel> there is no reference to it calling init put buts
[13:47:02 CEST] <andrey_turkin> it is inlined but I don't see any obvious errors there
[13:48:09 CEST] <nevcairiel> well i dont know where the actual issue is in the asm, a single code change like that can change the entire optimization as it needs another register and things
[16:25:09 CEST] <pfelt> andrey_turkin: per your suggestion, i replaced all the av_init_packet() calls with av_packet_from_data() and removed manual sets to both AVPacket::size and AVPacket::data and it segfaults now
[16:28:57 CEST] <nevcairiel> you still need av_init_packet i think
[16:29:22 CEST] <nevcairiel> av_packet_from_data only replaces setting data/size
[16:34:21 CEST] <pfelt> grumble
[16:34:52 CEST] <pfelt> i can try adding them
[16:40:03 CEST] <pfelt> nevcairiel: it still faults for me
[16:40:13 CEST] <pfelt> different place though, i'm trying to figure out why
[16:41:36 CEST] <BBB> is this still decklink?
[16:41:49 CEST] <BBB> dont we have a decklink module maintainer that can do that?
[16:44:28 CEST] <pfelt> i'm in decklink yeah.  i submitted a couple of patches last night and got some pointer that i was doing it wrong
[16:45:33 CEST] <pfelt> which oddly don't happen when i don't use av_packet_from_data() and then unref in a couple of places
[16:47:36 CEST] <nevcairiel> packet from data makes a refcounted packet, so the data needs to be owned by you since ownership transvers to the packet
[16:52:04 CEST] <pfelt> well, i'll leave that change to a future fix.  it still works in the old non-ref counted model.  it needs to be changed, but i'm thinking now isn't the right time.
[17:18:25 CEST] <andrey_turkin_> ah, damn it. sorry pfelt I totally misled you. Looks like there is no existing function to just clone data into new packet. So probably best way to tackle this is to use av_new_packet and memcpy
[17:19:13 CEST] <pfelt> we'll revisit that once i finish up a couple of other things.  there seems to be a lot of work here
[18:39:35 CEST] <ubitux> michaelni: if you're interested; http://sprunge.us/KfXB
[19:32:07 CEST] <fritsch> now I got it - marillat is the debian-multimedia author, though his kodi packages are unsupported by us - as we never know what he currently bumps into them. So if he says: kodi is broken - that's worth not worth much for now.
[19:59:11 CEST] <ubitux> fritsch: i hope the issue is not because we introduced an abi issue between 3.0 and 3.1
[19:59:49 CEST] <ubitux> because in such case, that's indeed a mistake from us
[20:00:11 CEST] <ubitux> i wouldn't be surprised at all if that was the case
[20:01:24 CEST] <Compn> didnt we have a kodi dev ?
[20:01:28 CEST] <Compn> to test our releases ?
[20:03:44 CEST] <ubitux> it's not related to kodi afaict from the very first sentence
[20:17:31 CEST] <fritsch> ubitux: he replied
[20:17:34 CEST] <fritsch> ubitux: see what he did
[20:17:49 CEST] <fritsch> he bumped from ffmpeg 3.0.2 to 3.1 and did not rebuild kodi against it
[20:17:54 CEST] <fritsch> and soname was bumped
[20:18:03 CEST] <fritsch> so I don't know why he expects it to work
[20:18:16 CEST] <fritsch> Compn: ffmpeg 3.1 is fine with kodi (including the deprecated api)
[20:18:28 CEST] <fritsch> we just found one regression for now concerning dvd menus but are on it
[20:18:55 CEST] <ubitux> there should be no abi breakage on minor bumps
[20:19:04 CEST] <jamrial> fritsch: 3.1 has the same major version for all libraries as 3.0
[20:19:07 CEST] <ubitux> so why would it be a problem?
[20:19:23 CEST] <fritsch> wasn't there a bump cause of the dxva hevc-10 bit addition?
[20:19:30 CEST] <ubitux> major?
[20:19:53 CEST] <fritsch> now as you ask me - I am not sure anymore, but thought from 56 to 57 or something
[20:20:00 CEST] <ubitux> http://ffmpeg.org/download.html is see no major versions mismatch between 3.0.x and 3.1.x
[20:20:16 CEST] <fritsch> okay
[20:20:22 CEST] <fritsch> so - it should work
[20:21:16 CEST] <jamrial> lavf mp3dec got only five commits since february (3.0 release date)
[20:23:14 CEST] <fritsch> such things we (kodi) don't catch as our official builds are all static
[20:24:22 CEST] <jamrial> codecpar conversion, some change to the probe function and 1c9215e5 which is the only notable change to header parsing
[20:25:06 CEST] <ubitux> what happened to upstream-tracker.org?
[20:25:34 CEST] <fritsch> jamrial: if he rebuilds against 3.1 - all is fine for him
[20:26:06 CEST] <fritsch> so I don't think there is a problem in mp3 parsing
[20:50:32 CEST] <jamrial> ubitux: http://upstream.rosalinux.ru/ they aren't running checks anymore
[21:02:17 CEST] <fritsch> jamrial: https://dav.saraev.ca/pub/compat_reports/libavcodec.so.57/3.0.2_to_3.1/compat_report.html
[21:02:57 CEST] <fritsch> and here is the rest: https://dav.saraev.ca/pub/compat_reports/
[21:03:25 CEST] <fritsch> https://dav.saraev.ca/pub/compat_reports/libavformat.so.57/3.0.2_to_3.1/compat_report.html#Type_Binary_Problems_High 
[21:04:14 CEST] <nevcairiel> a bunch of our structs include "private" fields by convention, documented as such in the header, those reports dont know about that
[21:04:22 CEST] <fritsch> okay
[21:04:27 CEST] <fritsch> just trying to help
[21:04:27 CEST] <nevcairiel> and flag changes in that areas as problematic
[21:04:37 CEST] <fritsch> no finger pointing
[21:04:57 CEST] <fritsch> still wondering what breaks for marillat
[21:24:58 CEST] <fritsch> from what I see though - the AVCodec struct was broken
[21:25:42 CEST] <fritsch> AV_PIX_FMT_NB has been changed from 337 to 341
[21:25:54 CEST] <nevcairiel> NB elements are never part of the public ABI
[21:26:14 CEST] <nevcairiel> it just means we got 4 new pixfmts
[22:00:28 CEST] <fritsch> seems carl tracked it down to 10424024a16a7646169b9c9008c5f7b77cbc2211
[22:07:36 CEST] <nevcairiel> all context changes in that are documented private
[22:08:05 CEST] <jamrial> yet it the problem can be reproduced with ffplay
[22:09:30 CEST] <nevcairiel> ffplay and ffmpeg arent the best examples of clean public-only api usage :d
[22:13:09 CEST] <ubitux> in the merge, the hw_frames_ctx is not added at the end
[22:13:15 CEST] <ubitux> of AVFilterLink
[22:13:20 CEST] <nevcairiel> its added in the area marked private though
[22:13:28 CEST] <jamrial> doens't matter, it's below the private mark
[22:13:29 CEST] <nevcairiel> so it should be fine
[23:22:35 CEST] <cone-872> ffmpeg 03Martin Vignali 07master:2bdb26b4eeec: fate/webp : add test for lossy compression.
[00:00:00 CEST] --- Wed Jun 29 2016