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

[burek]

[03:03:14 CET] <j-b> thardin: VLC does not have a MXF demuxer (yet)
[04:58:46 CET] <mkver> pkt->duration == 0 means "unknown duration"; for subtitles this usually means "display until the next subtitle", but in the past, IIRC a negative duration was also used for this purpose. Is this really a thing of the past or does a muxer still need to check for this?
[05:37:27 CET] <byte_> Hi
[05:38:03 CET] <byte_> I want to create custom filter in ffmpeg
[09:54:59 CET] <mkver> cehoyos: Do you have a sample for which 7a5356c7281d39ee168bfa984ae081969e47da27 fixed HEVC-remuxing from mpeg-ts to Matroska? I am asking because of ticket 8042: Here the fact that the mp4 muxer doesn't check the return value led to the creation of an invalid file (it was annexb in mp4).
[10:05:25 CET] <cehoyos> I was under the impression that any file would allow to reproduce the issue this commit fixed: Am I wrong?
[10:44:52 CET] <mkver> I have found a file where your commit made it possible to mux; the created file has no extradata and is in annexb, which is against the specifications. This is actually not surprising: ff_isom_write_hvcc only starts writing anything after it has checked that everything is ok. But current ffmpeg can handle this just fine, it finds extradata. Probably the introduction of extract_extradata_bsf fixed this.
[10:49:59 CET] <cehoyos> That the bsf fixed something makes sense to me.
[10:50:27 CET] <cehoyos> Note that at the time of the commit, nobody could say if the output was against the specification or not.
[10:54:06 CET] <mkver> Why not?
[10:54:36 CET] <cehoyos> I don't know, I asked and nobody answered.
[11:23:11 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:8e2a832a5521: avfilter/vf_median: clip radius instead of erroring out
[11:52:43 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:84e9a55d8ed7: avfilter/af_afftdn: simplify changing commands
[12:09:54 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:fbcb141c06a7: avfilter/vf_fillborders: add support for commands
[12:26:25 CET] <thardin> j-b: I'd use bmx instead of lavf tbh
[12:26:50 CET] <durandal_1707> ban him ^
[12:26:53 CET] <thardin> I believe I'm on-record on the mailing list as being opposed to even having our own demuxer for mxf
[12:27:03 CET] <durandal_1707> ban him ^
[12:27:25 CET] <thardin> witch!
[12:28:48 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:9bd4df16542b: avfilter/vf_chromashift: add support for commands
[12:29:10 CET] <thardin> over the years I've learned that pointing out NIH is heresy
[12:29:51 CET] <durandal_1707> bmx is crap, and it does not support all what lavf supports
[12:30:10 CET] <kierank> sure but it does a lot of stuff that lavf cannot
[12:30:26 CET] <thardin>  /ignore durandal_1707 
[12:30:33 CET] <durandal_1707> cite something sensible
[12:31:15 CET] <nevcairiel> the concept of "one thing that does everything" is often how bad things are born, targeted tools that do one thing well, like handling a crazy format like mxf, are fine
[12:31:45 CET] <durandal_1707> but bmx does not handle all mxf stuff that lavf can
[12:31:52 CET] <thardin> such as?
[12:31:57 CET] <durandal_1707> everything
[12:32:03 CET] <durandal_1707> prores
[12:32:17 CET] <thardin> oh wow adding a codec ul. really hard
[12:32:44 CET] <durandal_1707> go hide under a rock
[12:35:07 CET] <j-b> thardin: yes, this was the question
[12:35:17 CET] <j-b> thardin: bmx seems nice
[12:35:21 CET] <j-b> and there was a vlc plugin
[12:35:39 CET] <thardin> neat
[12:35:52 CET] <thardin> I suspect vlc is better architectured to handle the higher operational patterns
[12:35:52 CET] <j-b> but testing lavf vs bmx for MXF is difficult, because of the number of versions of MXF there is
[12:36:04 CET] <thardin> like OP3a
[12:36:13 CET] <j-b> and things like linked-files
[12:36:14 CET] <thardin> ffmpeg sure isn't
[12:36:32 CET] <j-b> we have our own DCP plugin
[12:36:34 CET] <thardin> yeah no, external files you need a middleware for
[12:36:47 CET] <j-b> vlc can support external files, without issues
[12:36:53 CET] <thardin> yeah but you need like
[12:36:57 CET] <j-b> I think this is hard from within lavf
[12:36:58 CET] <thardin> an entire MAM
[12:37:55 CET] <thardin> a MAM would keep track of every MXF file by UUID, so that you can open them when referenced by another MXF
[12:38:15 CET] <thardin> or by an AAF
[12:38:20 CET] <j-b> sure
[12:38:27 CET] <j-b> but we have that for MKV already
[12:38:39 CET] <j-b> and you look in the same folder
[12:39:17 CET] <j-b> anyway, my knowledge of MXF is too light
[12:40:31 CET] <j-b> but with the support of TC (DF and NDF) in VLC 4, I fear I need to know more
[12:40:43 CET] <thardin> timecode?
[12:41:49 CET] <j-b> yes
[12:41:59 CET] <thardin> fun
[12:42:00 CET] <j-b> HH:MM:SS;FF
[12:42:08 CET] <j-b> and other crap that profesional like
[12:42:18 CET] <thardin> don't forget skip frame timecodes
[12:42:22 CET] <j-b> yes
[12:42:25 CET] <j-b> DF
[12:42:36 CET] <j-b> supported
[12:42:45 CET] <thardin> ah. it's been a while so I'm not 100% up to snuff
[12:43:37 CET] <thardin> speed is perhaps the word
[12:44:04 CET] <j-b> Drop Frame and Non-Drop-Frame
[12:44:21 CET] <thardin> right, thanks
[12:45:34 CET] <thardin> hum, ffmpeg only obeys st->start_time for subtitles?
[13:00:06 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:f89ebf88a1d1: avfilter/vf_scroll: add support for slice threading
[13:10:41 CET] <JEEB> cehoyos: cheers for grabbing the MPEG-H Audio sample
[13:10:47 CET] <JEEB> too bad we don't have the decoder :<
[13:10:51 CET] <JEEB> or well, a decoder
[13:12:57 CET] <JEEB> j-b: linking as such is not hard, it's just that people seem to be opposed to opening files although I'm not sure if it was regarding file names or scanning the `pwd` for a file with matching UUID (latter is what matroska does)
[13:13:16 CET] <JEEB> although I might have spotted support for file references in lavf's mov/mp4 demuxer
[13:16:33 CET] <durandal_1707> job sucks
[13:21:32 CET] <thardin> JEEB: yes, MOV has filenames for references, so mov.c opens those
[13:24:10 CET] <JEEB> thardin: so the problem was just with scanning files for UUIDs I guess
[13:24:34 CET] <durandal_1707> yes, you need to scan one million files in directory
[13:24:53 CET] <thardin> you might get away with looking at just the current directory non-recursively
[13:24:58 CET] <thardin> for files that end in .mxf or .MXF
[13:25:05 CET] <JEEB> yea, same for matroska
[13:25:21 CET] <JEEB> I think the original reasons why segment linking didn't hit was due to some security reasonings
[13:25:25 CET] <JEEB> but I'm not sure if those hold any more
[13:25:27 CET] <thardin> maybe an option for having it search recursively
[13:25:31 CET] <thardin> or not search at all
[13:25:38 CET] <durandal_1707> i have million of anime porn in .mkv in same directory
[13:25:41 CET] <JEEB> yes, definitely should be controllable
[13:25:51 CET] <thardin> maybe default to no searching, then ask the user if a file has references
[13:26:11 CET] <BtbN> What kind of broken design even is that, to reference another file by some of its contents?
[13:26:26 CET] <thardin> it's the broadcast way
[13:26:51 CET] <thardin> what you actually do is query a database
[13:27:05 CET] <thardin> that is, you ask your MAM
[13:27:07 CET] <JEEB> durandal_1707: I only have dozens but it's a Very Valid Point. that said others have already come up with the default of nonrecursive search by default, and then tick that lets you not go through that
[13:31:28 CET] <cehoyos> JEEB: Too bad the Sony guy apparently wanted to meet us;-(
[13:32:07 CET] <JEEB> aye
[13:34:03 CET] <durandal_1707> he wanted to give decoder code
[13:35:27 CET] <JEEB> unlikely
[13:35:45 CET] <JEEB> I think the interest in MPEG-H Audio is due to the broadcasters playing with it
[13:36:09 CET] <JEEB> and since they have their own proprietary decoders they mostly care about getting demux out of FFmpeg
[13:36:41 CET] <JEEB> I just hope that if it gets utilized, there would be work on getting an OSS decoder out there
[13:37:09 CET] <durandal_1707> isn't there open available specs?
[13:37:29 CET] <JEEB> yes, but they're ISO payware unless you find the final drafts
[13:37:44 CET] <JEEB> even the MPEG-H Audio in MP4 spec is not free >:|
[13:37:53 CET] <JEEB> like 14496-15
[13:38:01 CET] <JEEB> I don't fully understand the reasoning for making them not free
[13:41:29 CET] <JEEB> ah, actually
[13:41:29 CET] <JEEB> I wonder
[13:41:30 CET] <JEEB> https://mpeg.chiariglione.org/standards/mpeg-h/3d-audio/text-isoiec-23008-3201xpdam-3-mpeg-h-3d-audio-phase-2
[13:41:33 CET] <JEEB> if this is the last draft
[13:41:48 CET] <JEEB> since the sony guy links https://www.iso.org/standard/69561.html
[13:44:01 CET] <JEEB> at least it has no ref to mhm1
[13:45:20 CET] <JEEB> ah, ha! https://mpeg.chiariglione.org/standards/mpeg-h/3d-audio/n15847-thoughts-isoiec-23008-32015dam-2-mpeg-h-3d-audio-file-format
[13:45:40 CET] <JEEB> this actually seems to contain the related parts
[13:45:47 CET] <JEEB> mhm1 and mha1
[13:46:15 CET] <JEEB> > Especially in streaming or broadcast environments based on, e.g. MPEG-DASH or MPEG-H MMT, the MPEG-H 3D Audio configuration may change at arbitrary positions of the stream and not necessarily only on fragment boundaries. To enable this use-case the mhm1 and mhm2 MHASampleEntry provides an in-band configuration mechanism for MPEG-H 3D Audio files.
[13:46:21 CET] <JEEB> why am I not surprised :D
[13:48:01 CET] <JEEB> so the 'mha*' stuff was defined first and has the MHADecoderConfigurationRecord
[13:48:19 CET] <JEEB> while 'mhm*' stuff puts the decoder config stuff in-band
[13:50:33 CET] <JEEB> but yea, this means the sony guy's patch can not only be tested with samples but also compared to a reference :)
[13:50:48 CET] <JEEB> (spec)
[13:51:26 CET] <JEEB> I expect unless we want to put effort into it, we only want to support muxing with the mhm* codec tags if we want to support muxing it at all
[13:51:40 CET] <JEEB> since that doesn't require implementing parsing the MPEG-H bit stream... I think?
[13:51:48 CET] <JEEB> (and genreating the configuration box)
[14:17:41 CET] <perseiver> Hello,
[14:18:50 CET] <perseiver> I am new to ffmpeg and trying to use ffmpeg in my C code.  
[14:19:32 CET] <perseiver> I have written below code to find the AMR-NB parser using below code
[14:19:34 CET] <perseiver>   codec = avcodec_find_decoder(AV_CODEC_ID_AMR_NB);
[14:19:34 CET] <perseiver>   if(!codec) {
[14:19:34 CET] <perseiver>     fprintf(stderr, "Codec not found\n");
[14:19:34 CET] <perseiver>     exit(1);
[14:19:34 CET] <perseiver>   }
[14:19:36 CET] <perseiver>   parser = av_parser_init(codec->id);
[14:19:38 CET] <perseiver>   if(!parser){
[14:19:40 CET] <perseiver>     fprintf(stderr, "Parser not found\n");
[14:19:42 CET] <perseiver>     exit(1);
[14:19:44 CET] <perseiver>   }
[14:19:52 CET] <perseiver> But when I run program, I always getting "Parser not found"
[14:20:54 CET] <perseiver> Do, I other codec like AV_CODEC_ID_MP2 found and I have no problem with this. What should I do, so that I can parse AMR file.
[14:21:34 CET] <nevcairiel> not ever codec has a parser, and for using ffmpeg, you should ask in #ffmpeg
[14:22:34 CET] <BtbN> And please don't spam the channel with code pastes.
[14:23:10 CET] <perseiver> ok. thanks
[14:23:32 CET] <jdarnley> There are 3 amr demuxers, so I assume you should be using one of those.
[14:24:28 CET] <perseiver> yes, My build is already have this.  I have look into source code of av_parser_init(), what I see is they matching the codec
[14:24:47 CET] <perseiver> number upto 5 only.
[14:25:13 CET] <perseiver> And I guess, this result me as "Parser not found"
[14:26:04 CET] <perseiver> Or may be its third party library, i will have to find the parser in different way!
[14:35:28 CET] <j-b> JEEB: linking is hard, because fopen-ing is hard.
[14:53:52 CET] <thardin> hum, is it possible to change username on trac?
[14:56:16 CET] <durandal_1707> no, keep username you already have
[15:50:47 CET] <JEEB> j-b: true
[15:50:51 CET] <JEEB> all the IO layers
[15:59:05 CET] <durandal_1707> name all the IO layers:
[17:01:58 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:08f7968fc408: avfilter/vf_lumakey: add support for 12bit yuva formats
[17:01:59 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:6b9862f6145b: avfilter/vf_lumakey: change options to doubles, so that values are automatically scaled
[17:02:00 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:ae6c4168e67c: avfilter/vf_lumakey: add support for commands
[17:21:22 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:94c0b2739787: avfilter/vf_chromakey: add support for commands
[17:24:54 CET] <j-b> JEEB: fopen on iOS, Android (with the new permission model), WinRT/UWP/Windows10X and so on...
[17:25:01 CET] <j-b> sandboxing and such
[17:32:31 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:09fd1b18f041: avfilter/vsrc_testsrc: simplify color filter commands parsing
[17:40:51 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:d83304d5392e: avfilter/vsrc_sierpinski: fix another typos
[17:40:52 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:c98d8b2bf56a: avfilter/vsrc_sierpinski: change seed option type
[18:10:02 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:103effebc1f1: avfilter/vf_datascope: add support for commands in oscilloscope
[18:36:25 CET] <cone-129> ffmpeg 03Paul B Mahol 07master:55ca21d54e40: avfilter/vf_amplify: add timeline support
[21:55:37 CET] <JEEB> j-b: best when you have no listings or file names available. just unique content uris
[22:16:42 CET] <cone-417> ffmpeg 03leozhang 07master:4a3aa77d7437: avfilter/avfilter: fix indentation
[22:16:42 CET] <cone-417> ffmpeg 03Zhao Zhili 07master:bbb68be0ccf4: avfilter/graphdump: fix use of uninitialized variables
[23:40:57 CET] <cone-417> ffmpeg 03Paul B Mahol 07master:9cd56bb94c85: avfilter/af_aiir: fix array length when selecting conjugate poles
[00:00:00 CET] --- Fri Nov 22 2019