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

[burek]

[00:08:14 CET] <cone-707> ffmpeg 03Michael Niedermayer 07master:1ef336e912a7: avformat/utils: Do not init parser if probing is unfinished
[00:37:28 CET] <nevcairiel> great another bunch of tests failing on windows, now I can't run fate in any config unless some get fixed. :D
[00:51:04 CET] <cone-707> ffmpeg 03Hagen Schmidt 07master:7bf465abf369: mpegtsenc: add vc-1 support to MPEG-TS muxer (ticket 2141)
[00:54:06 CET] <atomnuker> ff_draw_pc_font() rocks
[02:24:32 CET] <cone-707> ffmpeg 03Bryan Huh 07master:dfa98c4f839e: ffmpeg: Fixing typos and adding comments to fps code
[02:24:33 CET] <cone-707> ffmpeg 03Bryan Huh 07master:1fe82abac7ec: ffmpeg: Simplify fps code related to delta0
[09:09:17 CET] <kierank> Firefox moves to FFmpeg
[09:23:08 CET] <wm4> kierank: ?
[09:24:17 CET] <kierank> https://www.phoronix.com/scan.php?page=news_item&px=Firefox-FFmpeg-Default
[09:27:46 CET] <wm4> nice
[09:28:09 CET] <wm4> I wonder why they didn't remain with gstreamer
[09:43:59 CET] <ubitux> now the it's going to be funny if they do not blacklist formats & codecs
[09:45:55 CET] <wbs> ubitux: I'm pretty sure they still will; also, it's only libavcodec, they've got their own demuxer (like for dash/MSE)
[09:49:25 CET] <ubitux> ok :)
[09:49:49 CET] <ubitux> i thought that was one of the main reason chromium was shipping its own version of ffmpeg
[09:50:00 CET] <ubitux> while firefox seems to make use of the system one
[09:53:38 CET] <JEEB> yeah, if I had specific libavcodec version installed I guess I could enjoy AVC/AAC decoding now on my linux boxes as well
[11:20:30 CET] <cone-348> ffmpeg 03Marton Balint 07master:9bd4f26b55c8: fate: fix concat demuxer tests on msys/cygwin by using relative paths
[11:20:31 CET] <cone-348> ffmpeg 03Marton Balint 07master:c9944f759610: fate: fix concat demuxer extended tests on windows
[11:53:36 CET] <durandal_1707> there are bunch of ivr in wild found by googling
[12:03:43 CET] <wm4> can you tame them?
[12:17:02 CET] <cone-348> ffmpeg 03Bryan Huh 07master:a01c24e8c591: avformat/aviobuf: Improve readability of aviobuf (Add comments and docs)
[12:17:03 CET] <cone-348> ffmpeg 03Bryan Huh 07master:a01ba7f579f4: avformat/aviobuf: Simplify avio_read() and avio_seek()
[12:30:48 CET] <BtbN> wm4, is mpv git master compatible with libass 0.13.0? The gentoo ebuild refuses to build with it because the enca useflag is gone from libass 0.13.
[12:33:33 CET] <wm4> BtbN: yes, also enca was removed from libass (because it was completely 100% useless)
[12:33:48 CET] <BtbN> Ok, so I can just drop the use dep
[13:32:51 CET] <durandal_1707> wm4: mostly ivr I found are gay porno torrent
[13:42:48 CET] <wm4> durandal_1707: surely that's worth all the trouble
[13:43:13 CET] <nevcairiel> i never even heard of that format
[13:43:40 CET] <cone-348> ffmpeg 03Ganesh Ajjanagadde 07master:f0197e1637bb: avformat/mov: fix memory leak
[13:43:41 CET] <cone-348> ffmpeg 03Ganesh Ajjanagadde 07master:8adff79b6d30: avformat/mov: remove redundant assignment
[13:44:10 CET] <nevcairiel> but its related to realmedia, so it cant be good
[13:44:21 CET] <wm4> xD
[13:44:36 CET] <durandal_1707> there are some Chinese music videos
[13:47:27 CET] <durandal_1707> and serie with Roger Moore that have 0 seeders
[13:49:53 CET] <Compn> i've heard of ivr
[13:50:07 CET] <Compn> realplayer had some kind of dumpstream option for a while, and it dumped to ivr.
[14:04:45 CET] <kierank> durandal_1707: there is a program that finds samples
[14:04:48 CET] <kierank> forgot the name
[14:04:50 CET] <kierank> uses the bing api
[14:10:56 CET] <kierank> wow fuzzing server almost frozen during vp9 
[14:18:55 CET] <Daemon404> i still bet it is hitting swap
[14:50:54 CET] <flux> is it bad form to indent = -characters in a sequence of variable definitions below each other?
[14:51:50 CET] <J_Darnley> I'm following completely but we do like = characters to be aligned
[14:52:15 CET] <flux> good :)
[15:05:15 CET] <kierank> Daemon404: 
[15:05:16 CET] <kierank> avdev at avdev:~$ free
[15:05:16 CET] <kierank>              total       used       free     shared    buffers     cached
[15:05:16 CET] <kierank> Mem:       8112068    5587488    2524580        844      17516      45032
[15:05:16 CET] <kierank> -/+ buffers/cache:    5524940    2587128
[15:05:16 CET] <kierank> Swap:      8323068      86768    8236300
[15:05:17 CET] <kierank> avdev at avdev:~$
[15:05:23 CET] <kierank> all memcpying of large frames I think that hits it
[15:05:51 CET] <Daemon404> i always just disable swap completely
[15:05:59 CET] <Daemon404> i'd rather procs be OOM killed than cripple the system
[15:06:36 CET] <nevcairiel> IME, the OOM killer will kill something you still need, not the thing thats causing trouble =P
[15:06:48 CET] <kierank> [55703.682790] fffuzz[28137]: segfault at 2b583b548c48 ip 000000000058748a sp 00002b5818ac2650 error 4 in fffuzz[400000+31b000]
[15:06:56 CET] <Daemon404> nevcairiel, ive only ever had it oom kill the offending application
[15:09:00 CET] <Daemon404> nevcairiel, btw anything i can do to help merge ffmpeg this time? i need other of martin's commits =p
[15:09:18 CET] <nevcairiel> merge the next commit in line and fix his unit test in ffmpeg
[15:09:20 CET] <nevcairiel> i cba
[15:09:29 CET] <Daemon404> sure
[15:09:34 CET] <Daemon404> just that one?
[15:09:46 CET] <nevcairiel> some of the results seem like some thing is bugged in our movenc
[15:09:54 CET] <nevcairiel> some may be intentional differences
[15:10:00 CET] <Daemon404> results where
[15:10:03 CET] <Daemon404> teh unti test?
[15:10:05 CET] <Daemon404> unit*
[15:10:06 CET] <nevcairiel> yes
[15:10:10 CET] <Daemon404> ok
[15:10:19 CET] <Daemon404> im pretty well acquianted with the dash and mov stuff by now
[15:10:21 CET] <Daemon404> i will look
[15:10:48 CET] <nevcairiel> the unit test tool has a mode to output the generated files, so shoving them at boxdumper or something should hopefully show whats different
[15:10:55 CET] <nevcairiel> i just didnt get the motivation to do that yet
[15:11:12 CET] <Daemon404> sure.
[15:11:26 CET] <Daemon404> i spend half my days starign at mp4 boxes
[15:11:32 CET] Action: Daemon404 twitches
[15:11:48 CET] <Daemon404> i even wrote my own tool to dump/patch boxes
[15:12:14 CET] <nevcairiel> some of the cases are a bit weirder, the tool expects two different modes to generate exactly the same file
[15:12:16 CET] <nevcairiel> yet, it does not
[15:12:19 CET] <nevcairiel> so maybe a bug in movenc
[15:12:30 CET] <Daemon404> might be
[15:14:07 CET] <nevcairiel> the commit should merge without conflicts iirc, it just doesnt pass the test :D
[15:16:47 CET] <Compn> kierank : program that finds samples??
[15:17:33 CET] <kierank> there's a program that uses the bing api, yes
[15:17:36 CET] <kierank> to find samples
[15:17:37 CET] <Compn> wow
[15:17:39 CET] <kierank> but i forget the name
[15:17:41 CET] <kierank> and I can't find it
[15:17:44 CET] <Compn> i just type filetype:ivr into google
[15:17:45 CET] <Compn> https://www.kunst-stoffe-berlin.de/images/stories/video/RTEthinkgreen2.ivr
[15:18:00 CET] <Compn> i want that program though , because i dont know how to use bing to do that
[15:19:13 CET] <Compn> i guess bing also accepts filetype: option
[15:19:39 CET] <Compn> no, it used to maybe
[15:20:24 CET] <Daemon404> nevcairiel, cant test it
[15:20:25 CET] <Daemon404> make: *** No rule to make target `libavcodec/pixblockdsp_template.c', needed by `libavcodec/pixblockdsp.o'.  Stop.
[15:20:28 CET] <Daemon404> make: *** Waiting for unfinished jobs....
[15:20:31 CET] <Daemon404> :D
[15:20:42 CET] <nevcairiel> remove stale files
[15:20:44 CET] <Compn> kierank : any idea where bing program came from or who authored it or what language it was written in ( open source?)
[15:20:51 CET] <Daemon404> nevcairiel, d'oh right
[15:21:02 CET] <Compn> durandal_1707 : https://www.kunst-stoffe-berlin.de/images/stories/video/RTEthinkgreen2.ivr
[15:21:28 CET] <Daemon404> nevcairiel, i always forget since only ffmpeg has this problem with its build system
[15:21:38 CET] <Compn> durandal_1707 : http://www.raebridgman.ca/setfree/raebridgman_shawinterview.ivr
[15:22:08 CET] <nevcairiel> Daemon404: i think the problem is that the makefiles do a wildcard include of all d files that exist, which causes this
[15:22:12 CET] <durandal_1707> Compn: got those already
[15:22:16 CET] <Compn> oh  ok :P
[15:22:24 CET] <Daemon404> nevcairiel, ah.
[15:28:25 CET] <wbs> nevcairiel: the problem is that there are .d files that say that to produce a .o (i.e. to compile the .c file that actually exists), it depends on a .c file that doesn't exist any longer. there's a special case rule for .h files for make, that basically tells it to try do a no-op and then assume the file exists (and try that compilation), which won't fail since the included file (that doesn't exist) isn't required any longer
[15:29:56 CET] <Daemon404> nevcairiel, i see why it was a PITA to test now
[15:30:02 CET] <Daemon404> i need to clone and build libav too
[15:30:16 CET] <nevcairiel> for the comparison refernces, yes
[15:30:22 CET] <nevcairiel> but thats not the PITA part
[15:30:29 CET] <nevcairiel> for me its not knowing mov good enough =p
[15:30:36 CET] <Daemon404> ah
[15:31:01 CET] <nevcairiel> wbs: ah that makes sense, i guess, all the C template files like this one that got removed
[15:31:26 CET] <nevcairiel> it should just try to re-generate the dependency file when it hints to a missing file
[15:31:56 CET] <wbs> nevcairiel: yep. iirc the reason has been that .h files (that are included) get renamed pretty often, but .c files are seldom included and even more seldom renamed, thus no workaround for that in the makefile
[15:32:10 CET] <wbs> well, regenerating the dependency file happens at the same time as you try to compile it
[15:32:24 CET] <nevcairiel> .d files are only used to track when its needed to re-compile a specific file, arent they?
[15:32:30 CET] <nevcairiel> so when d is broken, just recompile anyway
[15:32:34 CET] <nevcairiel> dont abort
[15:32:38 CET] <wbs> yep
[15:33:03 CET] <nevcairiel> but thats not what happens, so. . oh well :)
[15:34:08 CET] <wbs> well, that's not how make works. the .d file says that the dependency file really really needs to be there, and make doesn't dare to try. when these deps are generated with gcc/clang, you can add -MP to have it inject dummy entries to the .d files to the same effect
[15:34:28 CET] <wbs> but since the .d files can be generated with other things than gcc/clang, that's not relied on
[15:34:44 CET] <wbs> but a similar thing is done as a global thing in Makefile, but only for .h files
[15:35:32 CET] <wbs> (look for "Dummy rule")
[15:36:05 CET] <nevcairiel> i usually clean anyway, often even with git clean to get rid of everything, so this rarely ever affected me, but others in here run into it often enough
[15:40:32 CET] <Daemon404> ok so there are some sample differences
[15:40:40 CET] <Daemon404> but first of all: ffmpeg is not writing the iods bx
[15:40:41 CET] <Daemon404> box*
[15:40:42 CET] <Daemon404> and libav is
[15:41:44 CET] <nevcairiel> skip_iods is set to 1 by default in ffmpeg
[15:41:55 CET] <Daemon404> goctha
[15:42:02 CET] <Daemon404> let me set that to 0 just so i can compare better
[15:42:17 CET] <Daemon404> otherwise i get 9000 pos/size diffs
[15:43:40 CET] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=0988a6a03594aa02047abe6528edbedd926711bc fwiw, dont ask me which ever way is better
[15:45:20 CET] <nevcairiel> could  overwrite that in the unit test calls to explicitly enable it again for better matches, or change the refs, whichever makes more sense to you
[15:45:27 CET] <Daemon404> ok so
[15:45:33 CET] <Daemon404> now i see the timescales differ
[15:45:54 CET] <Daemon404> and thus all timestamps
[15:45:58 CET] <Daemon404> and chunk offsets differ.
[15:46:10 CET] <nevcairiel> that happens sometimes, timestamp/scale logic is different in generic code
[15:46:42 CET] <Daemon404> -                    timescale = 30
[15:46:42 CET] <Daemon404> -                    duration = 30 (00:00:01.000)
[15:46:42 CET] <Daemon404> +                    timescale = 15360
[15:46:42 CET] <Daemon404> +                    duration = 15360 (00:00:01.000)
[15:46:46 CET] <Daemon404> like that
[15:46:56 CET] <nevcairiel> which is ours
[15:46:58 CET] <Daemon404> yes
[15:47:03 CET] <nevcairiel> 30 or 15360?
[15:47:36 CET] <Daemon404> latter
[15:48:36 CET] <nevcairiel> you could probably try to explicitly set the timebase in init_fps in the unit test tool
[15:48:41 CET] <nevcairiel> instead of only the stream timebases
[15:49:09 CET] <Daemon404> iirc you cant force the timescale in movenc
[15:49:14 CET] <Daemon404> i could be mistaken
[15:51:07 CET] <nevcairiel>                 while(track->timescale < 10000)
[15:51:07 CET] <nevcairiel>                     track->timescale *= 2;
[15:51:13 CET] <nevcairiel> thats where your value comes from
[15:51:18 CET] <nevcairiel> i have no clue why
[15:51:27 CET] <Daemon404> reasons maybe
[15:51:46 CET] <nevcairiel> you can override with a privoption video_track_timescale
[15:51:48 CET] <nevcairiel> but meh
[15:51:56 CET] <Daemon404> im not worried
[15:52:02 CET] <Daemon404> just commetning it out to test further
[15:52:10 CET] <Daemon404> so far both things are non-issues
[15:52:24 CET] <nevcairiel> if its just intentional differences, then updating the ref should be fine
[15:52:55 CET] <Daemon404> yeah
[15:53:02 CET] <Daemon404> but there are further issues and warnings
[15:53:08 CET] <Daemon404> which seem to eb legit
[15:53:25 CET] <Daemon404> [mp4 @ 0x2547380] track 1: codec frame size is not set
[15:53:25 CET] <Daemon404> [mp4 @ 0x2547380] Malformed AAC bitstream detected: use the audio bitstream filter 'aac_adtstoasc' to fix it ('-bsf:a aac_adtstoasc' option with ffmpeg)
[15:53:28 CET] <Daemon404> there is a lot of those 2
[15:53:30 CET] <Daemon404> from the tool
[15:53:32 CET] <Daemon404> not in libav
[15:53:47 CET] <Daemon404> and chunk offsets differ
[15:53:55 CET] <Daemon404> as does some bitrate info
[15:53:59 CET] <nevcairiel> we may have introduced the warning
[15:54:04 CET] <Daemon404> 412: delay_moov differs from empty_moov
[15:54:05 CET] <nevcairiel> its not actually writing valid frame data
[15:54:07 CET] <Daemon404> and stuff like that
[15:54:09 CET] <Daemon404> which seems wrong
[15:54:17 CET] <Daemon404> (they shouldnt differ)
[15:54:55 CET] <Daemon404> -                                            maxBitrate = 200000
[15:54:55 CET] <Daemon404> -                                            avgBitrate = 0 (variable bitrate)
[15:54:58 CET] <Daemon404> +                                            maxBitrate = 128000
[15:54:59 CET] <Daemon404> this is probably some option
[15:55:01 CET] <Daemon404> +                                            avgBitrate = 1378
[15:56:40 CET] <nevcairiel> the aac thing may turn out annoying, the test tool writes dummy data, and movenc tries to check if the aac frame is valid :p
[15:57:22 CET] <Daemon404> ok so... i need to ask wbs about this one
[15:57:44 CET] <Daemon404> 412: delay_moov differs from empty_moov <-- the difference between the two is delay_moov has an elst
[15:57:47 CET] <Daemon404> empty_moov doesnt
[15:58:07 CET] Action: Daemon404 wonderes if use_elst has different defaults
[15:59:13 CET] <nevcairiel> there is a condition in movenc that disables editlist with fragment and !delay
[15:59:43 CET] <Daemon404> that is wbs' code though, im pretty sure
[15:59:46 CET] <Daemon404> and thus should not differ
[16:00:11 CET] <nevcairiel> looks identical, so hrm
[16:00:14 CET] <cbsrobot> Daemon404: you can force the timescale if you want
[16:00:37 CET] <Daemon404> cbsrobot, i think the *2 loop will always run.
[16:00:39 CET] <cbsrobot> on cli it's -video_track_timescale
[16:01:18 CET] <cbsrobot> if I remember well michaelni added the *2 loop to accomodate video / audio track drifts
[16:01:35 CET] <Daemon404> im not concerned about it
[16:01:48 CET] <Daemon404> a higher timebase cannot be worse
[16:01:54 CET] <Daemon404> well maybe overflows =p
[16:02:03 CET] <cbsrobot> Well I had some devices not laying these files
[16:02:20 CET] <cbsrobot> and 10'000 was just a choice he made
[16:03:54 CET] Action: cbsrobot reads the backlog
[16:10:29 CET] <Daemon404> nevcairiel, looks like edts writing is always done if possible in ffmpeg
[16:10:33 CET] <Daemon404> no reason is given
[16:10:37 CET] <Daemon404> it was done i na merge commit
[16:10:39 CET] <Daemon404> afaict
[16:11:31 CET] <Daemon404> makes fixing the test kinda.... ugh
[16:11:49 CET] <nevcairiel> send a patch
[16:12:02 CET] <nevcairiel> change behavior
[16:12:12 CET] <Daemon404> only one difference left
[16:12:15 CET] <Daemon404> to check
[16:12:26 CET] <Daemon404> the stsc box
[16:18:12 CET] <Daemon404> seems it might be due to fc09bf57a
[16:20:28 CET] <Daemon404> yep
[16:23:35 CET] <Daemon404> ok edts fixed in unit test
[16:23:47 CET] <nevcairiel> did you just force it off
[16:24:21 CET] <Daemon404> yes
[16:24:26 CET] <Daemon404> theres other stuff tho
[16:27:41 CET] <Daemon404> only one last thing to investiagte
[16:28:17 CET] <Daemon404> differign media_time in elst for e.g. the vfr test
[16:31:43 CET] <ubitux> mmh libav nih'ed avfoundation?
[16:34:07 CET] <Daemon404> hmmm
[16:42:03 CET] <Daemon404> ugh it traces back AGAIN to inside a merge commt
[16:42:05 CET] <Daemon404> with no info on why
[16:42:09 CET] <Daemon404> like everythign else so far
[16:43:07 CET] <kierank> of course it does
[17:02:24 CET] <Daemon404> nevcairiel, http://chromashift.org/a.txt
[17:02:31 CET] <Daemon404> that should be good for the merge
[17:02:39 CET] <Daemon404> i looked at all the differences, all seem to be intended.
[17:08:59 CET] <nevcairiel> Add a Merged-by line and do it :p
[17:10:56 CET] <Daemon404> is it custom to put it in the merge commit with a description
[17:10:57 CET] <Daemon404> or after
[17:11:31 CET] <nevcairiel> Huh
[17:11:41 CET] <Daemon404> separate commit or not
[17:12:17 CET] <nevcairiel> Don't mege broken stuff, so fix it in the merge
[17:12:35 CET] <Daemon404> eh ok
[17:13:06 CET] <nevcairiel> I can do it later if you want, but busy right now
[17:13:11 CET] <Daemon404> nah.
[17:25:28 CET] <cone-348> ffmpeg 03Martin Storsjö 07master:59e8ec0aa8ab: movenc: Add an API unit test for fragmenting options/calls
[17:25:29 CET] <cone-348> ffmpeg 03Derek Buitenhuis 07master:61344c04ca89: Merge commit '59e8ec0aa8ab174701d01a3bfe96fedd0b7fcead'
[18:08:15 CET] <cone-348> ffmpeg 03Marton Balint 07master:bcac6416b8f5: fate: fix concat demuxer extended test portability
[18:59:26 CET] <cone-348> ffmpeg 03Michael Niedermayer 07master:a62178be80dd: avcodec/pngdec: Replace assert by request for sample for unsupported TRNS cases
[19:16:11 CET] <llogan> did i miss anything in the last ~10 days?
[19:31:07 CET] <gnafu> llogan: Only everything, dude.
[19:31:12 CET] <gnafu> It's all different now.
[19:35:42 CET] <Compn> llogan : i only checked mod queue like three times :P
[19:35:52 CET] <Compn> and only for -devel :P
[19:37:05 CET] <durandal_1707> u lazy
[19:56:11 CET] <llogan> michaelni_: who has access to ffmpeg-trac ML admin. I don't. did you manually unsubscrbe the guy who complained because he couldn't figure it out himself?
[19:56:46 CET] <llogan> glen_alexndr at hotmail
[20:10:38 CET] <michaelni_> llogan, you have access now "FFmpeg-trac list run by michaelni at gmx.at, lou at lrcd.com"
[20:11:04 CET] <michaelni_> feel free to change the password for the ffmpeg-trac ML i remember none anyway
[20:15:07 CET] <llogan> michaelni_: thanks. how did you access the admin to add my address if you don't remember the pw?
[20:15:31 CET] <michaelni_> magic
[20:15:54 CET] <llogan> oh, you mean the browser remembered?
[20:16:24 CET] Action: J_Darnley guesses root access
[20:21:40 CET] Action: iive gives llogan a cookie
[20:39:42 CET] <llogan> i wish the trac machine had a bigger /boot
[21:11:09 CET] <kierank> llogan: it's what the ubuntu installer gave :(
[21:18:56 CET] <llogan> kierank: no big deal. i just have to remember to autoremove old kernel junk now and then. also, it needs a reboot, but i hate doing that.
[21:19:41 CET] <kierank> I am 2m away from it
[21:19:43 CET] <kierank> So feel free
[21:20:23 CET] <wm4> nevcairiel: so you still support XP?
[21:20:33 CET] <wm4> in lavfilters
[21:23:48 CET] <kierank> llogan: OK rebooting
[21:24:17 CET] <llogan> kierank: thanks. i was about to, then couldn't connect, then sat there stupidly for a few seconds
[21:25:02 CET] Action: llogan doesn't actually enjoy most server admin stuff
[21:25:11 CET] <kierank> Seems up now
[21:25:53 CET] <llogan> lgtm. now i'll remove some old kernel dingleberries
[21:26:02 CET] <llogan> since only 63M is left
[21:26:12 CET] <J_Darnley> lovely image :)
[21:26:44 CET] <llogan> ever see a musk oxen?
[21:27:17 CET] <J_Darnley> I don't think so
[21:31:06 CET] <J_Darnley> oh my https://en.wikipedia.org/wiki/File:Ovibos_moschatus_qtl3.jpg
[21:33:54 CET] <llogan> i automatically read "oh my" in George Tekai voice.
[21:36:42 CET] <J_Darnley> good
[21:57:13 CET] <nevcairiel> wm4: kind of, it just never broke, so i had no reason to not fix it =p
[21:57:34 CET] <wm4> ok
[22:31:49 CET] <atomnuker> https://0x0.st/--7.png
[22:32:19 CET] <nevcairiel> you must be bored
[22:34:10 CET] <atomnuker> bored?
[22:35:39 CET] <wm4> a state of not being able of doing anything interesting with your time
[22:35:45 CET] <wm4> I'm sure you are unfamiliar with it
[22:36:36 CET] <nevcairiel> people working on decoders for formats that are years away from mattering are usually bored, otherwise they would have no time for that! :)
[22:37:02 CET] <nevcairiel> (especially formats that are still changing on a daily basis)
[22:37:20 CET] <atomnuker> it was fun so that made it worth it
[22:37:43 CET] <atomnuker> besides working on _finished_ formats is not so interesting
[22:37:47 CET] <Daemon404> nevcairiel, as opposed to writing decoders for things year past being relevant?
[22:37:55 CET] <Daemon404> :P
[22:38:01 CET] <nevcairiel> Daemon404: well those files still exist at least
[22:38:06 CET] <nevcairiel> while in the other case they dont exist yet :D
[22:38:16 CET] <Daemon404> i still cant play the videos from my old NOX cds
[22:38:25 CET] <Daemon404> we dont support the proper variant of the game codec
[22:38:29 CET] <nevcairiel> sounds like you have your work cut out for you
[22:38:48 CET] <Daemon404> i dont even think i need to
[22:38:55 CET] <wm4> Daemon404: is it blink?
[22:38:56 CET] <Daemon404> some old games that used the codec are open source now
[22:38:58 CET] <Daemon404> wm4, no
[22:39:12 CET] <Daemon404> started with a v...
[22:39:26 CET] <nevcairiel> the games going open source may not necessarily include the video codec they licensed
[22:39:35 CET] <Daemon404> they did
[22:39:39 CET] <Daemon404> i read it once
[22:40:21 CET] <Daemon404> http://wiki.multimedia.cx/index.php?title=VQA
[22:40:26 CET] <Daemon404> there it is
[22:40:41 CET] <Daemon404> awww yiss, it's VQ
[22:47:23 CET] <atomnuker> at least it only has 3 versions
[22:47:35 CET] <atomnuker> bink2 has a different one for each game IIRC
[22:47:53 CET] <Daemon404> not sure
[22:47:56 CET] <atomnuker> (and the versions there aren't signalled in the bitstream)
[22:48:04 CET] <Daemon404> all i know about bink coems from ryg's (awesome) blog
[22:48:27 CET] <Daemon404> and thats mostly the (i)dct
[22:49:56 CET] <Daemon404> oh sweet, nox is on gog
[22:58:33 CET] <JEEB> yeah
[22:58:59 CET] <llogan> never heard of it. did it use a baldur's gate engine?
[22:59:01 CET] <JEEB> a lot of my late 1990s-early 2000s history is on there
[23:00:23 CET] <Daemon404> llogan, no it's westwood studios
[23:09:02 CET] <llogan> Daemon404: damn you, looks like another game i'll have to play.
[23:09:14 CET] <nevcairiel> cant resist those 15 year old games? :)
[23:09:59 CET] <llogan> there are so many...I don't play often but I just finished Grim Fandango and King of Dragon Pass (that one was hard)
[23:11:43 CET] <llogan> KoDP is a little different than any other game i've played
[23:18:26 CET] <rcombs> anyone know why 100 was chosen in particular in aea5db97?
[23:19:04 CET] <rcombs> I've got a TrueHD file here that only gets `valid` up to 24, but decodes just fine when I explicitly pick truehd as the format
[23:19:14 CET] <rcombs> (demuxed from a MPEGTS)
[23:19:30 CET] <nevcairiel> that sounds odd
[23:19:57 CET] <nevcairiel> although i'm not sure that check is entirely valid
[23:20:06 CET] <nevcairiel> that sync header is only present on major sync frames
[23:20:11 CET] <nevcairiel> there can be other frames in between
[23:20:30 CET] <rcombs> yeah
[23:20:37 CET] <rcombs> and it only counts the major sync ones
[23:20:52 CET] <rcombs> it reads other ones just fine
[23:20:58 CET] <rcombs> but they don't count towards `valid`
[23:21:03 CET] <nevcairiel> truehd frames are extremely small though, so 100 frames is probably not too bad
[23:21:45 CET] <rcombs> this file has about 128 frames per major sync
[23:23:09 CET] <nevcairiel> seems to be about 0.8333ms per frame in general, adapted for sample rate
[23:23:12 CET] <wm4> sounds like a terrible format
[23:23:13 CET] <rcombs> maybe only require a few major sync frames, and count other frames as well
[23:23:44 CET] <rcombs> also https://gist.github.com/f5714700f902afb16bfe
[23:24:11 CET] <nevcairiel> where would that be required
[23:26:16 CET] <rcombs> TrueHD carried in MPEGTS as STREAM_TYPE_PRIVATE_DATA
[23:26:50 CET] <nevcairiel> why would you do that
[23:26:55 CET] <rcombs> no idea
[23:26:57 CET] <rcombs> but somebody did
[23:27:00 CET] <nevcairiel> truehd only exists on blu-ray, i have never seen it in any different form
[23:27:10 CET] <rcombs> want a sample?
[23:27:20 CET] <nevcairiel> no
[23:27:23 CET] <nevcairiel> just tell them to gtfo
[23:28:23 CET] <nevcairiel> mpegts stream mapping is rather strictly specified, you do it wrong, your file no worky
[23:30:39 CET] <rcombs> alright, I'll trash these changes for now
[23:30:40 CET] <nevcairiel> the patch probably doesnt hurt, but one should not expect such files to work
[23:31:05 CET] <rcombs> and if someone comes up with a sample that actually matters, we can apply
[23:31:11 CET] <rcombs> but otherwise ignore this broken sample
[23:31:48 CET] <nevcairiel> does anything else play this track?
[23:32:08 CET] <rcombs> not sure; trying to get in contact with the guy who provided the sample
[23:32:55 CET] <rcombs> I'd imagine this came from some ancient version of ffmpeg
[23:33:11 CET] <nevcairiel> i dont know if we even have proper truehd muxing support
[23:33:16 CET] <nevcairiel> definitely not blu-ray compatible
[23:33:20 CET] <nevcairiel> since that requires the ac3 substream
[23:33:44 CET] <rcombs> some guy who goes by the name "John Galt"
[23:36:31 CET] <rcombs> messaged him; I'll keep you posted
[23:38:01 CET] <rcombs> MediaInfo identifies the stream correctly, but (1) lolmediainfo and (2) still no idea if anything actually plays it
[23:38:20 CET] <nevcairiel> mediainfo probably probes everything as well
[23:38:34 CET] <rcombs> I'd imagine so
[23:38:35 CET] <kierank> yeah mediainfo has independent probing
[23:38:37 CET] <nevcairiel> but like I said, its unlikely that something will break from the probing patch
[23:38:47 CET] <nevcairiel> so its probably fine
[23:39:07 CET] <rcombs> and as for the mlp/truehd probe itself?
[23:39:18 CET] <rcombs> right now it's too strict for this file
[23:39:27 CET] <rcombs> (expects sync frames too often)
[23:39:55 CET] <nevcairiel> I would need to look into the truehd details again to judge that, not sure atm
[23:40:02 CET] <rcombs> and that's probably slightly more real
[23:40:34 CET] <rcombs> this is one of those Dolby channel-check files
[23:40:55 CET] <rcombs> I think the truehd stream is remuxed from the mkv at http://www.demo-world.eu/2d-demo-trailers-hd/
[23:44:20 CET] <nevcairiel> the probe code generally seems fine, it scans for major sync headers and just skips over the other frames
[23:44:55 CET] <nevcairiel> did you trace if it fails, or just exhausts the buffer?
[23:45:16 CET] <rcombs> it exhausts the buffer
[23:45:17 CET] <nevcairiel> 100 major syncs is probably a few too many
[23:45:25 CET] <rcombs> after 24 major syncs
[23:45:30 CET] <rcombs> and a lot of non-major-sync frames
[23:45:50 CET] <wm4> isn't the parser supposed to reassemble these frames or something?
[23:45:59 CET] <nevcairiel> probing is long before that
[23:46:03 CET] <nevcairiel> and no
[23:46:20 CET] <nevcairiel> major syncs and the "minor" frames are still distinct packets
[23:46:42 CET] <wm4> doesn't this cause a shitload of overhead?
[23:46:52 CET] <nevcairiel> not really
[23:47:03 CET] <nevcairiel> well, not in the bitstream at least
[23:47:18 CET] <nevcairiel> the packets are really nearly identical
[23:47:29 CET] <nevcairiel> except that the major sync frames have a header with stream info
[23:47:33 CET] <nevcairiel> and the minor ones do not
[23:47:45 CET] <rcombs> sounds like AC3, I think
[23:48:36 CET] <nevcairiel> (the minor frames have a few parity bits and a size  header, 2 bytes in all, iirc)
[23:49:16 CET] <rcombs> 12 bits of size, 4 bits of somethingorother
[23:50:49 CET] <rcombs> want the raw TrueHD sample, then?
[23:51:03 CET] <nevcairiel> anyway, should check how the probe function behaves in your file, if frames are just too big to get 100 into the default probe buffer, or if it loses sync in between (or garbage at the beginning)
[23:51:12 CET] <nevcairiel> i suppose
[23:51:15 CET] <rcombs> no loss of sync
[23:51:38 CET] <rcombs> it just has rather few sync frames and runs through to the end of the 1MB buffer
[23:52:32 CET] <rcombs> lowering the required number of sync frames down to 20 makes it work for this file, but I think the probe should have non-sync frames count for something as well
[23:52:46 CET] <nevcairiel> it kind of does count them
[23:52:53 CET] <nevcairiel> well
[23:53:26 CET] <nevcairiel> if there would be garbage instead, it would read some rather arbitrary size value, lose sync, and not increment valid anymore
[23:53:33 CET] <rcombs> yeah
[23:53:57 CET] <nevcairiel> lets see if the BD spec calls for some particular sync frame distance
[23:54:09 CET] <rcombs> I don't have that one
[23:56:25 CET] <nevcairiel> The interval between two consecutive major_syncs shall be 8 to 128 MLP synchronization frames
[23:56:49 CET] <nevcairiel> 128 sounds like a bunch
[23:57:01 CET] <nevcairiel> lets log your file and see what it spits out
[23:59:25 CET] <nevcairiel> btw, 128 samples seems unusual for truehd
[23:59:39 CET] <nevcairiel> specs call for 40, 80 or 160, at 48, 96 or 192 khz respectively
[00:00:00 CET] --- Tue Nov 17 2015