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

[burek]

[00:12:12 CET] <rcombs> I know of a few random devices that support RS422; no idea what they do with it, though
[00:12:33 CET] <rcombs> the Ki Pro supports it
[00:12:44 CET] <rcombs> I guess it's used for shuttle control; probably common in tape decks?
[00:14:02 CET] <Chloe> yes, I think it's related to tape hardware
[00:14:50 CET] <llogan> maybe dericed has some
[00:15:42 CET] <rcombs> I've got access to a few Ki Pros (and maybe some tape decks); why do you ask?
[00:17:45 CET] <Chloe> I'm nearing the end of writing my avdevice for the macOS CoreMediaIO API, but I don't support much, due to me having only one piece of hardware (an old consumer level camcorder from 2005-ish), so I was wondering if anyone had something and would be interested in working with me to test the Interfacing/Control part of the CMIO API
[00:18:15 CET] <TD-Linux> Chloe, I have a CRT with RS422, but a custom protocol that I reverse engineered
[00:18:33 CET] <TD-Linux> very similar to the sony VHS control one though
[00:50:27 CET] <Chloe> rcombs: the other issue is that you'd have to be integrated into the macOS environment to get any use from this. I'm not sure how the multimedia industry sways in terms of operating system usage with tape stuffs (I assume windows or maybe linux)
[00:50:50 CET] <rcombs> I dunno what anyone still uses tape for
[00:51:04 CET] <rcombs> nor the shuttle interfaces on HDD/SSD recorders
[00:51:45 CET] <rcombs> I guess you could use those in a live-broadcast environment for replay or other video playback?
[00:51:54 CET] <TD-Linux> vaporwave production
[00:51:58 CET] <rcombs> but you'd integrate that with your switcher, not with a regular machine
[00:54:32 CET] <Chloe> So leave out the interface stuff entirely?
[01:01:29 CET] <beastd> lol @ "Map edited" makes us look like an OSM-like project ;-)
[01:03:20 CET] <llogan> it was a profound edit
[01:31:23 CET] <beastd> about passing encoder options to the turingcodec lib: i guess they do it that way for having a "cheap" C library interface. internally they have an Encoder class that takes a variable map (some boost data type), and they have a command line app which means they have the code for creating that variables map from the process arguments
[01:32:52 CET] <beastd> anyway the code constructing the command line in ffmpeg encoder init looked strange, if it isn't wrong it is at least awkward i would say. but maybe i am missing things.
[01:37:04 CET] <Chloe> I just love how the new apple developer website is absolutely, completely useless. The header files are 10000x better...
[02:16:41 CET] <cone-306> ffmpeg 03Steven Liu 07master:4696f7639b22: avformat/flvdec: add debug message to list keyframes index metadata
[02:18:51 CET] <cone-306> ffmpeg 03James Almer 07master:2ab50647ff65: avformat/utils: add av_stream_add_side_data()
[02:22:11 CET] <cone-306> ffmpeg 03James Almer 07master:77f033eb98d0: avformat/mov: use av_stream_add_side_data() for displaymatrix side data
[05:24:13 CET] <philipl> 5~
[15:53:34 CET] <Kuroe> Anyone know what '3G Text' subtitles are?
[15:56:30 CET] <nevcairiel> https://en.wikipedia.org/wiki/MPEG-4_Part_17 probably
[15:56:46 CET] <nevcairiel> sometimes called tx3g or 3gpp timed text
[15:59:12 CET] <Kuroe> ah thanks, what's the CODEC_ID--I can't seem to find it? (surely ffmpeg supports it)
[15:59:42 CET] <Compn> uhmmmm
[15:59:57 CET] <nevcairiel> mov_text i think?
[15:59:58 CET] <Compn> we have timed text samples, dunno about 3gpp timed text tho
[16:00:45 CET] <Compn> CODEC_ID_MOV_TEXT
[16:01:34 CET] <cone-757> ffmpeg 03James Almer 07master:eb3a59c903bd: avformat/mov: reuse existing err variable
[16:03:45 CET] <Compn> http://samples.ffmpeg.org/mov/subtitles-embedded/
[16:05:32 CET] <Compn> Kuroe : but if you have sample files which do not work, let us know. :)
[16:06:55 CET] <Kuroe> I'm trying to match up CoreMedia FourCCs to FFmpeg AVCodecIDs
[16:07:23 CET] <Kuroe> I can do a lot of them, but some of them I don't know. 
[16:11:15 CET] <nevcairiel> if its an apple t hing its most definitely mov_text
[16:22:13 CET] <cone-757> ffmpeg 03James Almer 07master:2343f23e4d7e: avformat/matroska: use av_stream_add_side_data() for stereo3d side data
[17:21:47 CET] <durandal_1707> is having video to captions/codes filter OK? 
[17:22:25 CET] <durandal_1707> eia-608 
[17:27:22 CET] <Kuroe> what's the 'normal' jpeg codecid?
[17:27:47 CET] <Compn> normal as in mjpeg or single image ?
[17:28:05 CET] <Compn> durandal_1707 : you mean ocr? or ?
[17:28:18 CET] <Kuroe> single image
[17:28:39 CET] <Kuroe> although this is probably mpjeg actually
[17:29:01 CET] <Compn> ffplay says a .jpg file is mjpeg 
[17:29:21 CET] <Compn> the only other fourcc is 'ijpg' really,  but there are a lot more 
[17:37:11 CET] <nevcairiel> jpg images usually just live in their own jpg files, not a typical fourcc for them
[17:37:25 CET] <durandal_1707> Compn: no, it's coded as pixels on special rows 
[17:40:25 CET] <Kuroe> Well, posted it to the ML, can see what people think
[17:43:27 CET] <nevcairiel> the real question is, what exactly is that good for
[17:52:33 CET] <Kuroe> It would make working with coremedia + ffmpeg tons easier, although I guess it could be bundled in every application instead of added to ffmpeg. Also getting a AVCodecID from a CMDescriptionRef with the least amount of pain
[17:52:59 CET] <Compn> durandal_1707 : oh you mean a filter to convert text to the analog video signal pixel rows ?
[18:12:11 CET] <nevcairiel> Chloe: some of thoise don't seem particularly helpful, particularly muxed and metadata tags, we don't handle those as codecs (timed id3 is something else)
[18:13:18 CET] <nevcairiel> and I would think t hose are practically the same as the mp4/isom mappings for  other codecs?
[18:23:20 CET] <durandal_1707> Compn: other way around 
[18:23:35 CET] <philipl> BtbN, nevcairiel: IT'S HAPPENING.
[18:24:03 CET] <philipl> Latest nvidia drivers (375.20 on linux) have 12bit hevc decode and p010 (probably p016) output
[18:24:16 CET] <BtbN> via cuvid? Or did they update vdpau?
[18:24:28 CET] <philipl> cuvid
[18:24:51 CET] <philipl> Undocumented without an sdk update, of course.
[18:24:56 CET] <philipl> I just decided to try it out and it worked.
[18:26:13 CET] <wm4> philipl: wow
[18:26:37 CET] <wm4> so I guess nvidia don't care about vdpau anymore?
[18:27:12 CET] <nevcairiel> i've been looking at their dxva2 devices if they added a new p016 device or such, but nothing yet
[18:27:27 CET] <nevcairiel> there is a unnamed guid with p010 output, i was wondering if thats maybe the 12 bit device
[18:27:32 CET] <nevcairiel> but without 12 bit output its meh
[18:28:29 CET] <nevcairiel> and by try it you mean you just requested a output format "2" ? :p
[18:28:58 CET] <philipl> output format 
[18:29:02 CET] <philipl> "1"
[18:29:09 CET] <philipl> 0 is nv12. previously 1 didn't work
[18:29:10 CET] <nevcairiel> oh right nv12 was 0
[18:29:32 CET] <philipl> and I tried a 12bit sample and it worked where that didn't before
[18:33:46 CET] <BtbN> Yeah, I think we should get that set merged to get cuvid useable. Not looking good for vdpau.
[18:34:53 CET] <philipl> quite so
[18:35:41 CET] <philipl> do we have a p016 format?
[18:35:58 CET] <philipl> I don't it or p012
[18:36:18 CET] <philipl> Unclear if 12bit is being dithered down to 10bit or whether they are populating the extra bits
[18:37:06 CET] <philipl> running strings on the cuvid library only shows P016 so I'd like to think "1" is P016
[18:53:01 CET] <Chloe[m]> nevcairel: the muxed tags are the most useful
[18:55:04 CET] <nevcairiel> philipl: p012 is not something i ever heard before
[18:55:11 CET] <Chloe[m]> The CoreMediaIO API can output muxed data
[18:55:26 CET] <nevcairiel> Chloe[m]: how is that, ffmepg cant handle it as that
[18:58:54 CET] <Chloe[m]> Also it would be silly to have all the mappings except for one or two. A complete list would help to keep things together
[18:59:25 CET] <nevcairiel> but it gives an illusion of being something ffmpeg understands
[18:59:28 CET] <nevcairiel> which it is not
[19:00:52 CET] <philipl> nevcairiel: true enough. It goes straight to p016
[19:01:38 CET] <nevcairiel> philipl: not that it really matters, the memory layout of those is the same since its a msb-packed format
[19:01:46 CET] <nevcairiel> just more or less zeros
[19:02:02 CET] <Chloe> nevcairiel: ffmpeg can't demux/decode DV?
[19:02:23 CET] <nevcairiel> Chloe[m]: it can decode dv and it can demux dv, but it doesn't use codec ids for demuxing
[19:02:37 CET] <nevcairiel> it needs an already demuxed track for the codecid to make sense
[19:03:20 CET] <nevcairiel> same for the mpeg2ts codec id, thats just some hack for very special use-cases, ffmpeg cant do anything with it
[19:05:57 CET] <Chloe> ok, so which would be useful? audio, video and subtitle/text/cc?
[19:06:32 CET] <nevcairiel> yeah those things that are actually codecs
[19:06:38 CET] <nevcairiel> mostly all of them except mux and meta
[19:07:13 CET] <nevcairiel> although it feeld odd to split various incantations of subtitles into 3
[19:07:17 CET] <nevcairiel> but if apple has it that way
[19:07:35 CET] <Chloe> yeah that's how it is, I thought it'd be better to leave it as is
[19:07:42 CET] <Chloe> What would be the best way to handle muxed and metadata?
[19:08:19 CET] <Chloe> AV_CODEC_ID_PROBE for muxed?
[19:08:32 CET] <nevcairiel> just not bunch it in w ith codec ids
[19:08:38 CET] <nevcairiel> there are none that make sense
[19:08:51 CET] <nevcairiel> you need to use entirely different APIs to process muxed streams then codec streams
[19:09:15 CET] <nevcairiel> avformat vs avcodec
[19:09:19 CET] <Chloe> yes, ok
[19:10:35 CET] <nevcairiel> and metadata is just an entirely different concept .. its not a stream of data, but like a dictionary
[19:10:46 CET] <nevcairiel> avformat usually just extracts that from the container
[21:06:22 CET] <philipl> I assume no one objects if I throw out support for 10bit -> nv12 dithering in cuvid. It'll be hard to handle the logic if we can't assume it goes to p010
[21:17:00 CET] <wm4> shouldn't the API user be able to ask for a pixfmt?
[21:22:36 CET] <nevcairiel> on a decoder level that seems a bit silly, just let it output the native one and thats that
[21:24:34 CET] <wm4> true
[21:25:59 CET] <nevcairiel> people have been harassing me for cuvid hevc10 support and i told them no because 8-bit rounded output is dumb, guess when this  hits an actual sdk i will need to implement that <.<
[21:31:06 CET] <wm4> but why
[21:31:14 CET] <wm4> it makes no sense since dxva2 works?
[21:33:35 CET] <nevcairiel> thats what i keep telling them
[21:34:01 CET] <nevcairiel> the only advantage cuvid has it that you get deinterlacing basically for free
[21:34:09 CET] <nevcairiel> without needing a renderer to access that
[21:35:11 CET] <wm4> you can deint with the d3d video processor
[21:35:18 CET] <nevcairiel> i know
[21:35:22 CET] <nevcairiel> would just need to build that
[21:35:26 CET] <wm4> (although I haven't found out how to select the damn deint alg)
[21:35:27 CET] <nevcairiel> with cuvid its like one flag
[21:51:45 CET] <philipl> ff_get_format seems to do the wrong thing in the case where cuvid is being used with copy-back.
[21:52:10 CET] <philipl> It doesn't try and choose the right pix fmt - it just picks the last entry in the list.
[21:52:28 CET] <philipl> I can obviously work around it in cuvid.c easily enough but it seems dumb.
[21:55:47 CET] <nevcairiel> you need to have two lists and only call it with the  one that has the correct format at the end
[21:55:52 CET] <nevcairiel> thats what hevc does, f.ex.
[22:00:05 CET] <philipl> so check the input pix_fmt first and then call with the right list?
[22:00:26 CET] <nevcairiel> pretty much
[22:52:51 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/5d678acc8983ca311dfe0c8eb3630cb3a65e9897
[23:14:58 CET] <nevcairiel> adding p016 support wouldnt be terribly hard
[23:15:10 CET] <nevcairiel> if p010 gets converted to yuv420p10le the 2 extra bits are just shifted out
[23:18:45 CET] <nevcairiel> but being able to use them interchangabliy otherwise is part of their design, thats why they use a msb layout
[23:21:13 CET] <philipl> small favours.
[23:21:24 CET] <philipl> But this code isn't right yet :-(
[23:21:34 CET] <philipl> It assumes the pix_fmt will be set when the decoder init is called.
[23:21:39 CET] <philipl> That's true for mp4 containers; not for mkv
[23:21:49 CET] <philipl> I'm not sure how I break the cycle here.
[23:24:02 CET] <wm4> philipl: are you testing this with mpv? because the libavformat demuxer decodes some video to determine a pixfmt, while mpv's mkv demuxer doesn't
[23:24:25 CET] <nevcairiel> a decoder like that really shouldnt rely on the pixfmt being set, it should set it itself
[23:26:36 CET] <philipl> wm4: yes, I am.
[23:26:53 CET] <philipl> nevcairiel: Yeah. I'm not sure how to bootstrap it though.
[23:27:26 CET] <nevcairiel> just wait until the cuvid parser calls the config callback and set it then? :)
[23:27:42 CET] <nevcairiel> by that time you have bistream info
[23:27:59 CET] <philipl> I'm concerned that's too late.
[23:28:12 CET] <philipl> but I can try
[23:28:51 CET] <wm4> I don't know what callback cuvid has there, but why would it be too late?
[23:29:25 CET] <nevcairiel> thats how h264/hevc etc work as well, they only figure out the pixfmt once it was determiend from the stream
[23:29:40 CET] <philipl> Ok. I'll push on that angle.
[00:00:00 CET] --- Sun Nov 20 2016