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

burek burek021 at gmail.com
Thu Mar 7 03:05:03 EET 2019


[06:35:37 CET] <cone-615> ffmpeg 03joepadmiraal 07master:056a2ac16813: avformat/dashenc: Added #EXT-X-PROGRAM-DATE-TIME to HLS playlists
[09:50:56 CET] <JEEB> durandal_1707: ghidra seems really promising
[09:51:04 CET] <JEEB> (NSA's open source reverse engineering tool)
[09:57:45 CET] <durandal_1707> NSA? I'm feeling very secure right now.
[11:09:27 CET] <thardin> cool, a whole bunch of those mxf hevc samples
[11:09:47 CET] <JEEB> soon we should have some 22.2 samples
[11:09:53 CET] <JEEB> (MMTP madness)
[11:10:51 CET] <thardin> that starts to become somewhat significant bandwidthwise
[11:12:32 CET] <JEEB> apparently some of the Japan 8K test airings
[11:12:51 CET] <JEEB> we can play guesswork on which library we want to use for the IP packet parsing :P
[11:13:02 CET] <JEEB> since MMTP recordings seem to be pure packet dumps
[11:13:24 CET] <JEEB> and MMTP is madness of MPEG-TS-like variable length packet encapsulation -> IPv6|4 -> multicasts
[11:13:35 CET] <JEEB> and those multicasts then finally contain MP4 fragments
[11:21:18 CET] <nevcairiel> sounds similar to ATSC 3.0 where they married DASH and broadcast
[11:31:43 CET] <JEEB> yea, I think both ARIB and ATSC spec'd both MPEG-TS and MMTP for next-gen broadcast :)
[11:31:53 CET] <JEEB> MMTP being "perfect for hybrid"
[11:32:04 CET] <JEEB> (in theory the streams can come either through the broadcast, or HTTP, or whatever)
[11:32:49 CET] <kurosu> it's packet encapsulations all the way down
[11:33:21 CET] <JEEB> yes
[11:33:28 CET] <JEEB> all the layers of abstraction
[11:40:08 CET] <atomnuker> "spec'd both MPEG-TS" <- that's a 30 year old standard with 188 byte packet sizes that was shit then and its shit now
[11:40:18 CET] <JEEB> yes
[11:40:27 CET] <JEEB> but it's not better than MMTP
[11:40:30 CET] <JEEB> like, seriously
[11:40:34 CET] <atomnuker> fits next gen broadcasting perfectly
[11:41:08 CET] <JEEB> (´4@)
[11:41:28 CET] <JEEB> they did variable length packets for MMTP's IP packetization
[11:41:58 CET] <JEEB> too bad it was so many layers of stuff :P
[11:43:05 CET] <JEEB> so it's no longer a media format, but rather the receiver will be a RX only network adapter
[11:49:38 CET] <kierank> durandal_1707: JEEB: yes ghidra looks really interesting
[11:49:46 CET] <kierank> ida without the piracy
[11:54:37 CET] <atomnuker> "In the meantime, enjoy using Ghidra on your SRE efforts, developing your own scripts and plugins, and perusing the over a million lines of Java and Sleigh code"
[11:55:17 CET] <atomnuker> is c++ not corporate enough anymore for a huge gov't agency?
[12:03:03 CET] <nevcairiel> i never even heard of sleigh
[12:04:14 CET] <kierank> atomnuker: probably they wanted multiplatform ui and started before qt
[12:22:32 CET] <thardin> hum hum.. how do I add a simple FATE decode test again?
[12:23:18 CET] <thardin> looks like h264-conformance-* are good cribs
[12:23:56 CET] <thardin> ah but yes, since this is hevc in mxf perhaps I should only test demux
[12:25:19 CET] <nevcairiel> you can test both, but of course the focus should be on what you really want to test, the mxf demuxer or the hvec decoder
[12:25:32 CET] <thardin> indeed
[12:26:31 CET] <thardin> why is there a demux.mak with fate-mxf-demux when there is also mxf.mak with a bunch of demux tests?
[12:27:55 CET] <nevcairiel> demux.mak used to collect single demuxing tests of various formats, and when a format got more complex tests they end up in their own file. Sometimes, the former is not removed when the latter happens
[12:29:38 CET] <thardin> right. and diego split off that file in 2011 even
[12:30:04 CET] <thardin> and then mxf.mak came along in 2015
[12:31:33 CET] <thardin> let's see if it isn't possible to use a big 'ol list in this thing since there's 25 samples
[12:34:49 CET] <thardin> something like fate-mxf-xf-hevc-%: CMD CMD = framecrc -i $(TARGET_SAMPLES)/mxf/xf-hevc/%.mxf -c:v copy
[12:34:59 CET] <thardin> err minus on CMD
[12:36:02 CET] <nevcairiel> we use something like that for the h264 ref samples you already found, so that should definitely cut down the number of lines
[12:36:39 CET] <nevcairiel> actually h264 only does it half
[12:36:47 CET] <nevcairiel> hevc ref samples does it properly
[12:37:03 CET] <nevcairiel> with a loop and everything
[12:38:07 CET] <thardin> I'm thinking I can just add a bunch of FATE_MXF += fate-mxf-xf-hevc-2500p-1080-45M
[12:38:18 CET] <thardin> where 2500p-1080-45M is the name of the sampel
[12:40:35 CET] <thardin> didn't know make had $(foreach)
[12:40:58 CET] <thardin> then I only need to figure out how to have it spit out refs the first time around
[12:41:27 CET] <nevcairiel> run make with GEN=1, that'll generate files instead of trying to compare to them
[12:42:33 CET] <thardin> cool
[12:42:46 CET] <thardin> hm no, it's empty
[12:44:31 CET] <thardin> ./ffprobe -show_packets shows it demuxes ok, and I can transcode it
[12:47:13 CET] <thardin> ah it's the % replacement that's not working
[12:47:36 CET] <thardin> I'll just do what the HEVC test does then
[12:51:43 CET] <thardin> success!
[12:56:49 CET] <durandal_1707> this codec is ugly and uses floats a lot
[13:02:14 CET] <thardin> and also it fails as expected when the patch isn't applied
[13:14:42 CET] <thardin> this matthew fellow went off-list for some reason, so I'll wait for him to ACK it. but I suspect that was just by mistake
[13:15:38 CET] <durandal_1707> what?
[13:15:51 CET] <nevcairiel> some mail clients fail at mailing list responses
[13:16:02 CET] <thardin> indeed
[13:16:23 CET] <nevcairiel> especially if you CC the people in that thread, which is really annoying
[13:16:40 CET] <nevcairiel> not sure why people do that, isnt everyone subscribed anyway :)
[13:17:11 CET] <thardin> I think they just hit reply all and it gets to From: as well
[14:43:45 CET] <thardin> did my mxf-hevc mail make it properly to the list? I had some e-mail client issues
[20:32:37 CET] <cone-813> ffmpeg 03Paul B Mahol 07master:93402561fda4: avcodec/imm4: add support for mid-stream size changes
[20:34:11 CET] <durandal_1707> why GPL2 for checkasm license of v210?
[20:36:16 CET] <kierank> Came from x264 I guess
[20:37:03 CET] <durandal_1707> GPL is cancer
[20:40:09 CET] <J_Darnley> Yes, it is.  It does ensure you get source code for things used over a network.
[20:40:14 CET] <J_Darnley> *doesnt
[20:41:01 CET] <J_Darnley> Also I just submitted a very dumb patch
[20:41:18 CET] <durandal_1707> AGPL is murder
[20:42:54 CET] <J_Darnley> Honestly it is gpl because I just started it with the v210enc checkasm file which is also gpl
[20:43:58 CET] <durandal_1707> ok
[20:44:33 CET] <JEEB> durandal_1707: https://www.nsa.gov/resources/everyone/ghidra/
[20:44:38 CET] <JEEB> this is the thing that NSA released
[20:44:44 CET] <JEEB> seems surprisingly good
[20:46:15 CET] <durandal_1707> JEEB: please stop sending me good linux rootkits, my system already belongs to Carl
[20:47:52 CET] <durandal_1707> i will use it once full source code (including for decompiler) is put somewhere (github)
[20:48:08 CET] <JEEB> yup
[20:50:40 CET] <j-b> tsup
[20:52:51 CET] <j-b> durandal_1707: IMM5? :D
[20:52:55 CET] <atomnuker> durandal_1707: there is a repo and they're working on actually uploading it there
[20:53:10 CET] <atomnuker> but I still would be somewhat skeptical about its usability as its java
[20:53:21 CET] <atomnuker> and some other lang without a wiki page
[20:53:30 CET] <JEEB> marcan tried it and it seemed really nice
[20:53:38 CET] <JEEB> https://twitter.com/marcan42/status/1103186324394205184
[20:54:43 CET] <j-b> marcan is not a name I like
[20:55:08 CET] <JEEB> don't like console hacking?
[20:55:20 CET] <JEEB> although I don't think he's done much after PS4
[20:57:33 CET] <durandal_1707> j-b: i'm busy with AC-4, IMM5/CFHD?!? will happen latter
[20:58:18 CET] <j-b> JEEB: he's a twitter bully. Really not my type
[20:58:32 CET] <JEEB> interesting
[21:00:53 CET] <j-b> JEEB: but I love console hacking. It is sooo fun
[23:46:53 CET] <cone-813> ffmpeg 03Michael Niedermayer 07master:53248acfb3b2: avcodec/scpr: Fix use of uninitialized variable
[00:00:00 CET] --- Thu Mar  7 2019


More information about the Ffmpeg-devel-irc mailing list