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

burek burek021 at gmail.com
Mon May 21 03:05:04 EEST 2018


[00:06:24 CEST] <jamrial> jdarnley: sample?
[00:06:41 CEST] <jamrial> libavformat can't parse it?
[00:08:22 CEST] <jdarnley> No it cannot.  It doesn't have "OggS" markers.  They seem to have been replaced with 04 86 86 c5 (hex)
[00:08:41 CEST] <jdarnley> I will put a sample somewhere
[00:09:03 CEST] <jamrial> xored file?
[00:09:47 CEST] <jdarnley> I considered that
[00:10:32 CEST] <jdarnley> Not all bytes of the oggs marker get the same result when I try to xor ith oggs
[00:11:27 CEST] <jdarnley> it I would guess it is the same "factor" for each byte because the replacement appears to be the same on the first 2 or 3 pages
[00:12:52 CEST] <jdarnley> https://0x0.st/segq.ogg
[00:15:24 CEST] <jdarnley> yes, vgstream has produced a good decode.
[00:15:33 CEST] <jdarnley> Now I just need to find out how.
[00:19:21 CEST] <jamrial> jdarnley: xor with 0xF0 then bitswap
[00:19:37 CEST] <jamrial> 0xF, sorry
[00:19:49 CEST] <jdarnley> damn, you spoiled it!  :)
[00:19:55 CEST] <jamrial> pointless obfuscation
[00:19:56 CEST] <jamrial> haha
[00:20:58 CEST] <jamrial> it was obvious a xor thing seeing all the 0xF0 where zeroes should be
[00:21:36 CEST] <jdarnley> I was thinking maybe a randomised lut.
[00:24:00 CEST] <jdarnley> I found it in the code.  xor 0xf0 and a nibble swap
[00:24:48 CEST] <jamrial> xor with 0xf then rot4 each byte is what i did
[00:24:49 CEST] <jdarnley> Up yours NIS America!  You spent too long DRMing the music and not enough time on everything else!
[00:26:20 CEST] <jdarnley> Time to write my own.
[00:26:28 CEST] <jdarnley> ... decrypter.
[00:28:19 CEST] <JEEB> :)
[00:28:23 CEST] <JEEB> hacking on games is fun
[00:28:56 CEST] <JEEB> I wish I had the time to poke around bink2 to get these tales of zestiria openings playable without RAD's player
[03:52:08 CEST] <atomnuker> speaking of reverse engineering, I wish someone did directmusic files (and soundbanks)
[03:52:45 CEST] <atomnuker> it was nih-midi and only used for a brief moment in microsoft games before they nih'd midi again with xna but there's some good game music made for it
[04:06:03 CEST] <Compn> atomnuker : upload samples ?
[04:09:28 CEST] <atomnuker> https://pars.ee/temp/mm2_dmusic.zip
[04:09:58 CEST] <atomnuker> there's a simple client in there too which uses directmusic to decode them (windows only ofc)
[04:10:34 CEST] <atomnuker> might still run on modern windows versions, it ran fine on win7 years ago
[04:11:51 CEST] <Compn> should i put in samples.ffmpeg.org ?
[04:14:46 CEST] <atomnuker> nah, there are no midi files there, I don't think they should be there either
[04:15:31 CEST] <Compn> midi files in /karaoke/ actually
[04:19:10 CEST] <atomnuker> yeah, ok, put them up there
[04:19:28 CEST] <atomnuker> seems like the list isn't big but games up to 2010 used them
[04:19:30 CEST] <atomnuker> http://www.vgmpf.com/Wiki/index.php/SGT
[04:19:55 CEST] <atomnuker> and the windows version of ff 8
[04:23:07 CEST] <Compn> any sample is a good sample
[04:23:13 CEST] <Compn> and these game formats are useful for people learning RE
[04:24:04 CEST] <TheAMM> I wish I knew how to extract the images/sprites from Hotel Dusk
[04:26:34 CEST] <atomnuker> I think each game did its own thing
[04:28:06 CEST] <TheAMM> Yep
[04:28:33 CEST] <TheAMM> Some games use the same thing, either because of some library or same developer
[10:48:47 CEST] <kierank> gagandeep: i understand a bit better now, cineform only allows zero runs
[10:48:56 CEST] <kierank> So that is why they memset and skip forward
[10:52:04 CEST] <gagandeep> i guess, but the real working is how they are building fsm while initializing decoder so i haven't been able to see that
[10:53:21 CEST] <gagandeep> i understand the simple idea of entropy coding but in cineform they do that under the radar
[10:53:58 CEST] <gagandeep> kierank: i can use functions both from get_bits and bytestream files right?
[10:54:28 CEST] <gagandeep> and directly accessing GetBitContext is not allowed, right?
[10:54:51 CEST] <kierank> You should need to do that, I think just check peaks for all coefficients
[10:55:04 CEST] <kierank> Should wlrk, you don't need to use thekr fsm
[10:55:42 CEST] <gagandeep> yeah
[11:07:55 CEST] <durandal_1707> huh, we broke abi recently ?
[11:11:06 CEST] <durandal_1707> tmm1: why you commited stuf that broke ABI?
[12:24:47 CEST] <nevcairiel> durandal_1707: the ABI is fine
[12:28:26 CEST] <wm4> APIchanges says "Add program_num, pmt_version, pmt_stream_idx to AVStream" even though they are private fields
[12:28:50 CEST] <nevcairiel> yeah that should probably be cleaned up
[12:28:58 CEST] <nevcairiel> but the ABI changes were all in the private sections regardless
[12:29:10 CEST] <wm4> yes
[12:37:40 CEST] <JEEB> ok, so DVB and ARIB text conversion seems to have been put into a linutv.org fork of gconv
[12:38:04 CEST] <JEEB> those are LGPLv2
[12:39:57 CEST] <JEEB> > gconv people see these as application specific > linuxtv.org people see them as standard-defined charsets
[12:40:01 CEST] <JEEB> such a delicious clusterduck
[12:43:44 CEST] <JEEB> right, https://git.linuxtv.org/v4l-utils.git/tree/contrib/gconv
[12:43:58 CEST] <JEEB> all this makes me one sad two-legged monkey
[13:19:52 CEST] <cone-030> ffmpeg 03Jerome Borsboom 07master:ca878845ae03: avcodec/vc1: DIRECTBIT is only present in inter MBs
[13:19:52 CEST] <cone-030> ffmpeg 03Jerome Borsboom 07master:2b86472a65b7: avcodec/vc1: fix calculation of the last line of a slice
[13:19:52 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:60d179277972: avformat/mp3dec: Require probing data to be 50% mp3 frames for low score probing to succeed
[13:19:52 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:81b3e7c9c3ad: avformat/mp3dec: Require 50% of the file to be mp3 frames in the maxframes>200 probing test
[13:19:52 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:cadf7a7f3901: avformat/mp3dec: require 90% of a file to be mp3 if only 1 mp3 frame is found in sequence
[16:40:55 CEST] <gagandeep> kierank: i have checked that i am pointing to the same place in bytestream for peak table as cineform decoder but my values are not correct 
[16:41:00 CEST] <gagandeep> any idea
[16:41:53 CEST] <gagandeep> i am using bytestream2_get_be() for values at the pointed index of bytestream
[16:44:00 CEST] <gagandeep> also i have directly refferenced the bytestream buffer as gb.buffer for current position at the time of reading the peak tag
[16:44:10 CEST] <gagandeep> and then add the offset to point to the table
[16:44:29 CEST] <gagandeep> checked in cineform sdk, that the index pointed in the bytestream is the samme
[16:46:50 CEST] <gagandeep> no, i am using bytestream_get_be() to directly read the buffer at the pointed place
[16:52:11 CEST] <durandal_1707> atomnuker: have you read that paper? i do not understand how it create weight matrix
[17:45:03 CEST] <philipl> BtbN: how's the deinterlacing going?
[17:45:14 CEST] <BtbN> not at all
[17:46:03 CEST] <philipl> heh
[17:46:14 CEST] <kierank> gagandeep: surely it's little endian
[17:46:18 CEST] <kierank> it points directly to the table, no?
[19:13:29 CEST] <klaxa> ok, finally got the commits more or less the way i want, do i send the whole patchset including the other work i already sent as well? it's 13 commits
[19:13:42 CEST] <klaxa> in total i mean
[20:16:57 CEST] <tmm1> if the previous commits didnt change just send the new ones
[20:18:21 CEST] <tmm1> JEEB: i ran into that too trying to decode dvb eit data
[20:18:45 CEST] <JEEB> yea :&
[20:18:59 CEST] <JEEB> the worst thing is that it's merged into the linuxtv.org stuff
[20:19:01 CEST] <JEEB> buuut
[20:19:06 CEST] <JEEB> how are you supposed to use it from there
[20:19:37 CEST] <tmm1> nevcairiel: so abi changes in private sections are okay, so no version bump is required?
[20:20:22 CEST] <JEEB> but yea, since libaribb24 seemingly has licensing issues according to j-b I might just go with 0p1pp1's ARIB caption decoder if I can just put the text decoding into I guess avutil (since both libavcodec and libavformat would be utilizing at least the ARIB text decoding thingamajig)
[20:20:53 CEST] <JEEB> which kind of sucks since libaribb24 is already utilized by VLC and I haven't been able to compare those two implementations yet
[20:33:47 CEST] <durandal_1707> atomnuker: what are you doing?
[20:42:11 CEST] <durandal_1707> atomnuker: hello?
[20:44:32 CEST] <atomnuker> learning french so I can get unstuck off this rock before it sinks?
[20:48:11 CEST] <kierank> atomnuker: you chose nice then?
[20:48:43 CEST] <atomnuker> yep
[20:49:15 CEST] <durandal_1707> atomnuker: aren't you in UK?
[20:49:20 CEST] <atomnuker> yep
[20:53:04 CEST] <durandal_1707> atomnuker: when you gonna finish fft/dct ?
[21:09:01 CEST] <durandal_1707> atomnuker: please, answer
[21:43:13 CEST] <atomnuker> don't know, sometime next week if I can
[21:59:13 CEST] <durandal_1707> atomnuker: you said same thing last week
[22:50:40 CEST] <kierank> durandal_1707: stop being mean
[22:52:17 CEST] <durandal_1707> kierank: then i gonna be very rude
[22:52:59 CEST] <durandal_1707> ubitux: found paper describing patch lifting for nlmeans
[23:55:14 CEST] <durandal_1707> iive: hello!
[23:56:24 CEST] <iive> durandal_1707, hello!!
[00:00:00 CEST] --- Mon May 21 2018


More information about the Ffmpeg-devel-irc mailing list