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

Tue Aug 23 03:05:02 EEST 2016

[01:35:47 CEST] <cone-310> ffmpeg 03Michael Niedermayer 07master:d7633ed7a59a: avformat/swfdec: Fix memleak on error
[02:57:17 CEST] <cone-310> ffmpeg 03Mark Reid 07master:61fac0ea0967: libavcodec/dnxhdenc: fix typo, check if profile is dnxhr 444 or hqx
[10:42:20 CEST] <ubitux> https://lists.libav.org/pipermail/libav-devel/2016-August/078814.html huh
[10:42:27 CEST] Action: ubitux confused
[10:43:54 CEST] <ubitux> bp0: libav didn't want it natively?
[10:48:40 CEST] <ubitux> bp0: btw, please be careful when adding new avoptions: you need to add them at the end or you might break command line usage
[10:52:49 CEST] <ubitux> (by adding disable_autoconvert at the top, you are breaking someone script using -af hdcd=true to set process_stereo)
[11:00:49 CEST] <durandal_1707> if I want to add some number to uint8 and that it max out on 255, what simd instruction should I use?
[11:03:23 CEST] <ubitux> paddusb?
[11:06:01 CEST] <ubitux> #5789  should we have a way to configure demuxers so they return a sub list of streams instead of all of them all the time (and then filtered user side)?
[11:10:48 CEST] <bp0> ubitux, i think they might have, but I mentioned that it was used in other places and they suggested a shared library
[11:11:04 CEST] <bp0> ubitux, I didn't know it could be used like that
[11:11:21 CEST] <bp0> ubitux, thank you, I'll be more careful of that in the future
[11:11:52 CEST] <ubitux> so you're going to maintain a library and the code natively in ffmpeg, or codebases are meant to diverge?
[11:13:57 CEST] <bp0> ubitux,  I don't know. I will try to keep them in sync. I was wondering what ffmpeg might think of using the library too, but I suspect that native is preferable.
[11:14:34 CEST] <ubitux> requiring an external library for something we already have natively could be considered a regression from a user PoV
[11:14:55 CEST] <ubitux> especially since the library is likely packaged nowhere for now
[11:15:55 CEST] <bp0> yeah
[11:16:18 CEST] <ubitux> btw, i think doc/filters.texi needs some update
[11:16:37 CEST] <ubitux> at least documenting the new option (and maybe more, i haven't followed closely)
[11:16:50 CEST] <bp0> I use deadbeef and quod-libet and I wanted hdcd to work in those, so I've created a dsp plugin for deadbeef using the library, and looking into gstreamer, but that seems like a hassle
[11:18:18 CEST] <bp0> doc/filters.texi has all the options, but not in the same order
[11:18:27 CEST] <bp0> as --help filter=hdcd
[11:18:37 CEST] <ubitux> ah; i missed the change then, sorry
[11:18:43 CEST] <ubitux> the order needs to be fixed then
[11:18:50 CEST] <ubitux> (in the filter or in the documentation)
[11:19:24 CEST] <bp0> ok
[11:21:20 CEST] <ubitux> http://ffmpeg.org/ffmpeg-filters.html#Filtergraph-syntax-1 it's documented here; 3rd point in the first list you see
[11:21:22 CEST] <ubitux> > A :-separated list of mixed direct value and long key=value pairs. The direct value must precede the key=value pairs, and follow the same constraints order of the previous point. The following key=value pairs can be set in any preferred order. 
[11:21:51 CEST] <ubitux> so for users relying on the documentation (and not -h filter=...), they may have suprises  
[11:24:30 CEST] <bp0> I will keep that in mind and not change the order in the future. Thank you for pointing it out.
[11:38:36 CEST] <cone-740> ffmpeg 03Burt P 07master:429b41e7b283: doc/filters: re-order hdcd options to match --help filter=hdcd
[11:46:54 CEST] <ubitux> bp0: thanks
[11:57:13 CEST] <bp0> how often does http://ffmpeg.org/doxygen/trunk/ get updated?
[12:04:54 CEST] <BtbN> Judging from the date it lists, I'd guess daily.
[12:10:01 CEST] <bp0> heh
[12:10:10 CEST] <bp0> I didn't notice that
[13:05:06 CEST] <cone-740> ffmpeg 03Jan Sebechlebsky 07master:2fc9a3eb7a8c: avformat/mux: Restore original ts in write_packet on error
[13:05:07 CEST] <cone-740> ffmpeg 03Mark Reid 07master:eb5f4b148269: tests/fate/vcodec: add dnxhr mov tests
[14:26:14 CEST] <BtbN> I just straight up copied the CopyFromUswc function from VLC now.
[14:26:23 CEST] <BtbN> Exactly the same speed of 25 FPS
[14:26:59 CEST] <BtbN> I wonder if this is some compiler-flag that breaks this?
[15:30:30 CEST] <cone-740> ffmpeg 03Umair Khan 07master:fb1f67a70b14: avutil: Softfloat implementation for IEEE 754 floating point
[15:30:30 CEST] <cone-740> ffmpeg 03Umair Khan 07master:eabdabb9822e: avcodec: Implement masked lz decompression
[15:30:31 CEST] <cone-740> ffmpeg 03Umair Khan 07master:dcfd24b10c7e: avcodec/alsdec: Implement floating point sample data decoding
[16:45:37 CEST] <cone-740> ffmpeg 03Stanislav Dolganov 07master:4edd74bd7c0a: avcodec/me_cmp: add median SAD compare function
[18:38:12 CEST] <omerjerk> so we're participating in outreachy or not?
[18:39:17 CEST] <durandal_1707> I gave up as being only admin
[18:44:59 CEST] <michaelni> durandal_1707, i can help with admining but i dont want to be the only admin either
[18:54:42 CEST] <omerjerk> so we have two admins who don't want to admin alone? :P
[18:58:10 CEST] <cone-740> ffmpeg 03Michael Niedermayer 07master:ebb9a320d707: avcodec/alsdec: Remove unused variable
[18:58:11 CEST] <cone-740> ffmpeg 03Michael Niedermayer 07master:360d3f3c187f: doc&tools: Add murge script, for analyzing 3 way conflicts.
[19:05:08 CEST] <michaelni> noone is listed as admin at: https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-12, if someone adds himself as admin, feel free to add me too as admin or backup admin
[19:06:12 CEST] <michaelni> would be ideal to have 3 admins probably
[19:06:23 CEST] <durandal_1707> but one need to contact outreachy
[19:06:37 CEST] <michaelni> yes
[19:07:16 CEST] Action: durandal_1707 not
[19:08:16 CEST] <michaelni> i can write that mail, but i wont before theres some admin listed on the wiki 
[19:08:43 CEST] <durandal_1707> what admin does?
[19:12:23 CEST] <michaelni> make sure wiki ideas page is in shape, make sure someone helps applicants /awnsers their questions / recruit mentors / solve unexpected issues like mentor disappearig / choose which applicant gets a slot if reynaldo doesnt do it (he did it really well previously)
[19:12:50 CEST] <michaelni> of course finding someone to do anything is as good or better tha doing it ourself
[19:13:42 CEST] <michaelni> awnser the rare question like for organization title or so from outreachy admins
[19:14:21 CEST] <michaelni> IIUC we have funding for one slot from SPI-ffmpeg IIRC from what saste said
[19:15:30 CEST] <CFS-MP3> michaelni, on the SCTE-35 comments which you said are ambiguous... trying to disambiguate :-) 
[19:16:17 CEST] <CFS-MP3> timestamp in scte-35 sometimes represent future video packet pts or dts and sometimes scte-35 says that start the commercial now
[19:16:57 CEST] <CFS-MP3> but SCTE-35 is a public document that anyone can actually just check... don't know what kind of wording you'd like to see.
[19:17:01 CEST] <michaelni> durandal_1707, if you missed my reply: http://pastebin.com/6VP3gMhd
[19:19:11 CEST] <durandal_1707> michaelni: I'm not sure if I could make it, so I don't want you only remain
[19:19:59 CEST] <michaelni> is there a 3rd admin volunteer ?
[19:20:28 CEST] Action: michaelni needs to go afk, ill be back in 1h
[19:46:41 CEST] <kierank> CFS-MP3: this is why scte35 don't fit in ffmpeg
[19:53:29 CEST] <CFS-MP3> kierank well, if it doesn't fit in ffmpeg where does it fit? Honestly I don't see any logic in saying that an industry standard that builds on a MPEG-TS doesn't fit into ffmpeg :-)
[19:54:06 CEST] <kierank> A lib built around MPEGTS like upipe
[19:54:15 CEST] <kierank> It doesn't build on MPEGTS at all
[19:54:20 CEST] <kierank> It's a huge hack
[19:56:35 CEST] <CFS-MP3> scte-35 support in ffmpeg is a very requested feature... I don't see why we should point existing ffmpeg users to other software when they are happy with ffmpeg and just need the scte-35 support this patch offers
[19:56:59 CEST] <CFS-MP3> I got some emails from people playing with the patch already
[19:57:59 CEST] <CFS-MP3> In any case if upipe is a library you can't really ask end users to use it instead of ffmpeg... 
[20:10:12 CEST] <kierank> Well if certain people (tm) weren't neckbeards FFmpeg could use a subset of features from a ts library
[20:10:38 CEST] <kierank> FFmpeg shouldn't be a dump for crap features that don't fit
[20:10:44 CEST] <kierank> Or the API should be changed
[20:14:32 CEST] <CFS-MP3> ok... internal politics references are lost on me, sorry... I'm new here
[20:15:50 CEST] <kierank> It's not politics
[20:15:57 CEST] <kierank> It's a technical discussion
[20:17:48 CEST] <michaelni> durandal_1707, 3rd admin found, wiki updated
[20:18:29 CEST] <rcombs> I, for one, didn't get what that code was trying to do
[20:18:55 CEST] <rcombs> the mpegts.c stuff seemed reasonable at least, though
[20:19:11 CEST] <Chloe> XPM encoder/decoder looks like a fun project
[20:20:21 CEST] <CFS-MP3> kierank when you mention "certain people (tm)" (I don't know who) and call them neckbeards that's not a technical discussion
[20:20:35 CEST] <Chloe> It's a silly format though :s
[20:23:21 CEST] <CFS-MP3> michaelni do you have a couple minutes to discuss the required comments for the scte-35 patch?
[20:23:24 CEST] <Chloe> michaelni: can I add a project to the outreachy page?
[20:24:13 CEST] <michaelni> Chloe, probably yes
[20:24:42 CEST] <michaelni> CFS-MP3, yes, if you dont mind that iam doing 2 other things at the same time and might reply slowly
[20:33:33 CEST] <CFS-MP3> michaelni that's fine. I'm also doing other things to be honest.
[20:34:20 CEST] <CFS-MP3> michaelni I said this before which I think you missed: 10:16] <CFS-MP3> timestamp in scte-35 sometimes represent future video packet pts or dts and sometimes scte-35 says that start the commercial now
[20:35:55 CEST] <CFS-MP3> Is there maybe some variable or function that needs specific attention to? Maybe that will help me understand what part is unclear. Or maybe some developer who isn't familiar with SCTE-35 can comment :-)
[20:40:50 CEST] <michaelni> CFS-MP3, if a packet has a dts or pts than "now" has meaning, otherwise "now" is a bit ambigous. do such packets have a dts or pts set ?
[20:49:59 CEST] <CFS-MP3> michaelni "now" in this context means -> Start the commercial when you get the packet
[20:52:39 CEST] <michaelni> CFS-MP3, that would mean that some care needs to be taken with any fifos that could delay it
[20:58:07 CEST] <CFS-MP3> michaelni : I check PTS in the next packet in video and when "INSERT now command" comes with duration of commercial, I remove scte packet at the time PTS of next video packet + duration
[21:00:01 CEST] <michaelni> CFS-MP3, this sounds a bit like a special case, isnt it easier to put some kind of timestamp on the packet at the demuxer ?
[21:01:49 CEST] <michaelni> also what video stream ? there could be multiple
[21:02:40 CEST] <michaelni> and does this work if ffmpeg reads 2 input files and exchanges streams between them ?
[21:04:32 CEST] <CFS-MP3> in Insert command, there is a flag splice_immediate_flag, which tell commercial need to be inseted from the next video packet
[21:04:32 CEST] <CFS-MP3> anyway we cant create splice ts in until we get I frame
[21:04:33 CEST] <CFS-MP3> there are already commercials running, if for some seonds we display the original commercials thats acceptable
[21:04:33 CEST] <CFS-MP3> so i dont think fifo is required
[21:07:02 CEST] <CFS-MP3> I dont think hls support multiple video stream in output
[21:07:02 CEST] <CFS-MP3> thats why I am reading video stream which we are going to place in manifest file
[21:09:12 CEST] <michaelni> CFS-MP3, i didnt mean to add fifos, rather there are fifos, in applications, in the libavfomrat muxer core and so on
[21:09:27 CEST] <CFS-MP3> michael, about more than one input file - it won't work. SCTE-35 signals are generally present only to broadcasters where only one ts files come in input. 
[21:09:31 CEST] <michaelni> also one might want to edit / replace a video stream 
[21:10:09 CEST] <michaelni> i mean i can take one ts file edit its video stream for whatever reason and then try to replace the video stream
[21:14:06 CEST] <CFS-MP3> If you wanted to do that then SCTE-35 would do nothing for you. SCTE-35 is about switching from one stream on another, on the fly, typically to insert local commercials at specific points signalled by the input stream. SCTE-35 tells you "this is an IN point for your commercials, you have X seconds for it". You don't really edit the stream, that defeats the purpose of SCTE-35 in the first 
[21:14:06 CEST] <CFS-MP3> place. 
[21:16:57 CEST] <CFS-MP3> So SCTE-35 data appears for example in streams that broadcasters send to their affiliates, which just use it to know when to insert local commercials. But the final TS that is delivered to the final user doesn't have any SCTE-35. One of the reason that it's so hard to actually get SCTE-35 samples - they're not "in the wild".
[21:18:05 CEST] <CFS-MP3> michaelni: if we start adding the data in fifo immidiatley when insert command is recieved, we would see some artifact, since video  wont be sliced properly
[21:18:05 CEST] <CFS-MP3> and in the next I frame we already sending scte-35 text in manifest file
[21:21:00 CEST] <michaelni> CFS-MP3, what you describe is the use case you have in mind, but why would tht be the only use case, people could want to use ffmpeg to mux scte35 into a new mpegts aka to create new content to be broadcasted and for that they need to combine it with some video stream
[21:33:07 CEST] <CFS-MP3> michaelni other use cases will be done as their appear in real life. The first iteration is about the one use case I've found (meaning a user came to me and asked for an implementation). I've received some emails about the patch which I'm replying to, but for now this seems to be the only use case people actually care about. Keep in mind that "people" here is really a small group, since 
[21:33:07 CEST] <CFS-MP3> SCTE-35 is just a industry thing.
[21:33:26 CEST] <CFS-MP3> michaelni also for the standard document: " This standard supports the splicing of MPEG
[21:33:26 CEST] <CFS-MP3> -2 transport streams for the 
[21:33:26 CEST] <CFS-MP3> purpose of Digital Program Insertion, which includes advertisement insertion and insertion of other 
[21:33:26 CEST] <CFS-MP3> content types."
[21:34:09 CEST] <CFS-MP3> That's pretty much the use case they had in mind with the specs :-)
[21:36:16 CEST] <michaelni> CFS-MP3, you can only add use cases later if the choice taken for the ABI between libavformat and the user app allows it
[21:38:15 CEST] <Chloe> Feel free to revert if you dont think it fits a criteria/dont like it
[21:40:51 CEST] <michaelni> CFS-MP3, about the use case itself, i only meant the use case described in the specs. but it seemed to me the patchset was a subset of this mpegts->hls but maybe i misunderstand
[21:41:24 CEST] <michaelni> can it do hls ->mpegts ? hls->hls ?
[21:41:41 CEST] <michaelni> creating new content by user app -> mpegts / hls
[21:43:18 CEST] <michaelni> or rather is the interface aka the AVPacket content and dts/pts reasonable for these use cases
[21:44:23 CEST] <michaelni> i think AVPackets with no dts/pts at all will be difficult to mux in many muxers
[21:44:44 CEST] <michaelni> as their code uses the dts to interleave packets
[21:45:33 CEST] <CFS-MP3> for now it's ts -> hls only
[21:45:36 CEST] <nevcairiel> maybe it should be passed as untimed metadata through other means, and not as a data stream
[21:45:42 CEST] <CFS-MP3> there is no breaking of ABI though, thats the reason the data packet are passed opaquely to  hlsenc.c
[21:47:33 CEST] <michaelni> if you change the AVPacket content syntax its a ABI break. The fact that ffmpeg.c does pass it back into libavformat does not gurantee all user apps will 
[21:48:08 CEST] <michaelni> some user app might interpret it or pass it to its own muxer not usig libavformat
[21:48:45 CEST] <michaelni> so you have to make sure whatever choice is taken now will be good enough for the near future
[21:49:14 CEST] <michaelni> not saying the choice in the pachset is not good just saying we cant change it easily later
[21:50:59 CEST] <CFS-MP3> User can ignore those AVPacket, nothing has been changed anything in AVPacket structure, we are just not using parts of it
[21:52:40 CEST] <CFS-MP3> michaelni I understand what you're saying... but honestly I think that there being  "near future" in this, there needs to be a present at some point... 
[21:53:09 CEST] <CFS-MP3> anyway I dont think there will be any problem later to implement hls->mpegts, hls->hls, there we can have similar code with hls side, and opaque data to mpegts
[21:53:57 CEST] <CFS-MP3> @navcariel The muxers that have problem will not read the data, we specify in the muxer that muxer support data stream in input
[22:02:26 CEST] <durandal_1707> michaelni: why 0 in gbrp becomes 2 in gbrp10
[22:14:03 CEST] <kierank> durandal_1707: because of rgb shifting
[22:16:20 CEST] <durandal_1707> kierank: is it wanted?
[22:16:56 CEST] <cone-596> ffmpeg 03Jan Sebechlebsky 07master:92b5f8fecdc1: avformat: Add fifo pseudo-muxer
[22:16:56 CEST] <cone-596> ffmpeg 03Jan Sebechlebsky 07master:0ed24bfc790b: MAINTAINERS: Add myself as maintainer of fifo muxer
[22:16:56 CEST] <cone-596> ffmpeg 03Jan Sebechlebsky 07master:b84c83144d65: avformat/fifo: Add fate test
[22:17:09 CEST] <kierank> durandal_1707: I believe yes
[22:17:20 CEST] <kierank> not for 0 actually
[22:17:48 CEST] <kierank> (x << n) | (x >> n) iirc or something like that
[22:18:01 CEST] <durandal_1707> yes, it breaks masks
[22:25:02 CEST] <michaelni> durandal_1707, how can it be reproduced ?
[22:25:58 CEST] <iive> you want most significant bits into the new/empty bits. so it is (x<<n) | (x>>(max_bits-n))
[22:26:51 CEST] <iive> so e.g. 0x00 -> 0x000 and 0xFF ->0xFFF ; 0x80 -> 0x808
[22:28:51 CEST] <mahol> michaelni:  ffmpeg -f lavfi -i color=pink,geq=r=0:g=0:b=0,format=gbrp10,datascope -f nut -c:v rawvideo -|mplayer
[22:33:55 CEST] <cone-596> ffmpeg 03James Almer 07master:69f7aad5710f: configure: force _WIN32_WINNT >= 0x0502 on mingw32 targets
[22:36:56 CEST] <CFS-MP3> michaelni so about this SCTE-35... is there anything else needed so it can be merged? 
[22:40:26 CEST] <kierank> CFS-MP3: just leave it as an out of tree patch or something
[22:40:28 CEST] <kierank> it's a total hack
[22:40:31 CEST] <kierank> nobody can actually use it
[22:40:36 CEST] <kierank> apart from a very small subset of users
[22:41:48 CEST] <CFS-MP3> kierank out of tree patches suck, they make life very difficult for users and maintainers
[22:43:16 CEST] <kierank> so are patches which don't fit at all in ffmpeg
[22:45:48 CEST] <CFS-MP3> here we disagree... scte-35 is an important specification... it may not have lots of end-users, but the broadcast industry is embracing it, and I don't see how such a thing doesn't "fit" into ffmpeg
[22:46:42 CEST] <CFS-MP3> you clearly just don't want it there, so I don't now what else to say on that regard... if michael doesn't want to merge it no matter what then I'll move on, or if it can be merged by doing something then I'll do it
[22:47:42 CEST] <michaelni> CFS-MP3, would it be possible to give these packets DTS values ? For video we also fill in DTS based on durations and last coded DTS and so on.
[22:49:18 CEST] <kierank> CFS-MP3: because it has no pts and dts
[22:49:27 CEST] <kierank> I'm fully aware it's an important specification
[22:49:32 CEST] <kierank> michael is not the leader
[22:50:25 CEST] <kierank> i blame clueless OTT providers for all of this
[22:50:37 CEST] <kierank> for years scte-35 and other horrid things we well out of ffmpeg
[22:50:42 CEST] <kierank> were*
[22:51:00 CEST] <michaelni> CFS-MP3, also see AV_CODEC_ID_DVB_TELETEXT code in mpegts.c maybe this can be used too ?
[22:54:42 CEST] <CFS-MP3> michaelni I'll check it out 
[22:56:04 CEST] <kierank> is it really better to make up a fake pts and dts
[22:56:07 CEST] <kierank> instead of doing it properly
[22:56:18 CEST] <kierank> no wonder libavformat is so bad
[23:02:12 CEST] <durandal_1707> put it into separate lib?
[23:03:07 CEST] <kierank> yes
[23:03:19 CEST] <kierank> for complex demuxers like mp4 (edit lists) and mpegts
[23:03:22 CEST] <kierank> muxers too
[23:03:28 CEST] <kierank> and ffmpeg uses a subset of the features
[00:00:00 CEST] --- Tue Aug 23 2016