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

[burek]

[02:31:45 CET] <linjie> https://github.com/FFmpeg/FFmpeg/blob/637742b45dc8df329b8593f6ad8f4e154d609415/libavformat/utils.c#L3778
[02:32:46 CET] <linjie> An indentation issue? or it's arranged intentionally?
[02:38:39 CET] <kierank> looks like a bug
[02:41:07 CET] <jamrial> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=077939626eeaa0c1364065414c18ab9b3a072281
[02:41:24 CET] <jamrial> guess the indentation was never fixed after that
[02:51:20 CET] <linjie> thx
[13:43:58 CET] <rcombs> ^ so who wants to implement the CSS parser in lavc then
[13:48:54 CET] <thardin> css is turing-complete if I'm not mistaken
[13:49:06 CET] <thardin> so that's going to be a "no"
[14:05:14 CET] <JEEB> I think VLC already had some parser, but I would bet it's C++
[14:27:45 CET] <hero100> JEEB: https://code.videolan.org/videolan/vlc/blob/master/modules/codec/webvtt/css_parser.c
[14:27:58 CET] <JEEB> oh, C
[14:50:22 CET] <rcombs> huh, doesn't look too awful as a base to start from
[14:50:47 CET] <rcombs> thardin: also CSS isn't properly turing-complete on its own
[14:51:12 CET] <thardin> it's still pretty bad
[14:51:15 CET] <rcombs> it's just stupidly complex for a subtitle format, and can be made turing-complete by hooking it up to other stuff
[14:51:29 CET] <rcombs> but you don't really need most of the more complex bits
[14:51:53 CET] <rcombs> like, a pretty minimal subset of actual CSS rules would cover 99%+ of WebVTT
[14:52:09 CET] <rcombs> most of the required complexity is in lexing the damn thing
[14:52:58 CET] <rcombs> which is still really fucking annoying but it's not, like, web-browser-level
[14:59:29 CET] <thardin> brace for yet more ad-hoc parsing
[15:15:28 CET] <mkver> Someone with experience with Real Media files here?
[15:27:10 CET] <Stevenliu> Just play rmvb file look "FBI Warning" :D
[15:29:31 CET] <JEEB> kostya and his multimedia.cx mind dumps are probably the main source for that by now?
[15:29:53 CET] <JEEB> also if it's matroska I think the old haali.su codec mappings pdf is still alive
[15:31:11 CET] <mkver> I am actually interested in the question of how many packets can a Matroska block contain?
[15:32:06 CET] <mkver> Right now the number is (sub_packet_cnt +nb_laces) / sub_packet_h * sub_packet_h * frame_size / block_align.
[15:33:51 CET] <mkver> frame_size can be as big as UINT16_MAX, block_align could be 1 and one could have as many as UINT16_MAX * UINT16_MAX AVPackets resulting from one block.
[15:35:10 CET] <mkver> I am looking for some sane limits to apply to this to not run into an OOM scenario.
[15:40:18 CET] <cone-873> ffmpeg 03James Almer 07n3.4.7:HEAD: fate/cbs: add a decode model AV1 test
[17:36:22 CET] <cone-873> ffmpeg 03Zhao Zhili 07master:f9d436691257: avfilter/buffersrc: remove write-only variable
[19:10:14 CET] <cone-873> ffmpeg 03James Almer 07master:5985ca0436f2: avcodec/av1_parser: skip frames with spatial_id > 0
[19:10:15 CET] <cone-873> ffmpeg 03James Almer 07master:968c4cbf2281: fate/cbs: add svc AV1 tests
[19:43:06 CET] <williamto> Hi everyone, I am looking forward to contributing to FFmpeg. Recently I tried to profile ffmpeg and found a significant overhead on aarch64 system. It is in the `get_cabac` function. I don't have much experience in ffmpeg development. I was wondering if someone could explain why there is such an overhead percentage on aarch64 system?
[19:43:17 CET] <williamto> Here is a screenshot of what i found
[19:43:18 CET] <williamto> https://imgur.com/a/JA5fWyU
[19:44:17 CET] <JEEB> CABAC is the way of compressing the coded data
[19:44:41 CET] <nevcairiel> bitstream parsing is the biggest bottleneck in most optimized decoders
[19:44:48 CET] <nevcairiel> because its very hard to optimize
[19:45:12 CET] <BBB> williamto: x86 has hand-written asm for cabac (not simd; this is regular scalar assembly). that could be done for aarch64 as well
[19:45:26 CET] <BBB> although I'm surprised it doesn't have that already TBH
[19:45:33 CET] <williamto> oh yes
[19:45:43 CET] <williamto> I tried the same command on a x86_64 system
[19:45:43 CET] <BBB> oh it does actually
[19:45:49 CET] <BBB> why is that not active on yuor system?
[19:45:56 CET] <BBB> check arm/cabac.h
[19:45:58 CET] <williamto> and the overhead was significantly lower (around 20%)
[19:46:03 CET] <BBB> maybe that's only on 32bit armv7?
[19:46:16 CET] <BBB> (depends on HAVE_ARMV6T2_INLINE)
[19:46:19 CET] <williamto> oh let me check my system
[19:50:06 CET] <williamto> oh i checked `arm/cabac.h`
[19:50:35 CET] <williamto> tbh I don't have much experience in Assembly either haha, just learning here. But the code looks different.
[19:50:54 CET] <BBB> check if it's used in your build
[19:52:13 CET] <BBB> there's apparently an aarch64/cabac.h also
[19:52:20 CET] <BBB> I guess that's what's supposed to be used
[19:52:38 CET] <williamto> yes
[19:52:47 CET] <williamto> i don't think `arm/cabac.h` was used in my build
[19:52:53 CET] <williamto> it was `aarch64/cabac.h`
[19:57:46 CET] <williamto> is there a reason for the overhead difference between `x86_64` and `aarchie64`/`arm`?
[19:58:06 CET] <BBB> uhm... yes, they are architecture-specific assembly
[19:58:17 CET] <BBB> so obviously you can't use x86-64 asm on aarch64 or vice versa
[19:58:28 CET] <williamto> ohhh I see
[20:00:29 CET] <williamto> also I am wondering another thing. When I tried to annotate `get_cabac` with `perf` on my system, it is pointing to the `ldrb` command which resulted in the high overhead. Do you know why that command alone would take such a high amount of time?
[20:01:43 CET] <nevcairiel> ldrb is the load instruction, its pretty reasonable that this might be the most time spent
[20:02:21 CET] <williamto> ohh I see, that makes sense
[20:04:08 CET] <williamto> Thank you for explaining guys!
[20:04:27 CET] <williamto> it seems like I can't easily optimize this functionality
[20:04:47 CET] <nevcairiel> we're still waiting for the day someone can make a magical fast cabac
[20:05:05 CET] <williamto> haha
[20:05:38 CET] <williamto> is CABAC used by default in ffmpeg no matter what the architecture/platform is? Is there an option for me to use CAVLC instead?
[20:06:13 CET] <nevcairiel> that depends on the video
[20:06:20 CET] <nevcairiel> when encoding you get a choice
[20:08:43 CET] <williamto> oh I see
[23:57:29 CET] <BenLubar> Are there any demuxers that use external files? I'm curious whether https://github.com/BenLubar/libcmv/blob/master/README.md would be possible to implement in ffmpeg and whether there's anything I can look at for reference.
[23:59:12 CET] <JEEB> if you look at libavformat/mpeg.c that already refers to the vobsub .sub file if you give it an .idx file
[23:59:57 CET] <JEEB> also not sure 100% sure but I think mov also has some sort of references implemented
[00:00:00 CET] --- Tue Dec  3 2019