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

[burek]

[01:17:31 CET] <Compn> what
[09:35:47 CET] <ubitux> thardin: ah mmh interesting the gif fix
[09:35:57 CET] <ubitux> i'm going to look at this
[11:12:02 CET] <thardin> ubitux: you can just download the files off my webzone and run the script to see the differences
[11:13:29 CET] <ubitux> why do you tell me this? what script?
[11:13:39 CET] <ubitux> took me a while but i noticed the black dots
[11:14:45 CET] <thardin> yeah you need to zoom
[11:15:03 CET] <thardin> it's more noticable on the say 32 or 16 color sample that's in the same directory on my server
[11:15:31 CET] <thardin> the dithering turns everything into chaos tho
[11:15:45 CET] <ubitux> :)
[11:17:09 CET] <thardin> it's rather crappy that the best way to get a small looping video working in every browser is still a gif
[11:17:52 CET] <thardin> firefox is a bit better now tho and doesn't block muted looping videos by default
[11:22:18 CET] <nevcairiel> unless i'm mistaken, but why would you make 32 or 64 color gifs? afaik it either has a 16 color palette, or a 256 color palette, using any intermediates seems wasteful?
[11:23:51 CET] <ubitux> it probably improve the lzw after that
[11:24:17 CET] <ubitux> zipping a limited range of value might compress more, but i dunno
[11:24:30 CET] <ubitux> also, palette filter speed maybe?
[11:24:45 CET] <ubitux> last one, "style"
[11:26:51 CET] <ubitux> output-fixed-64.gif  1.7M
[11:26:52 CET] <ubitux> output-fixed-128.gif 1.9M
[11:26:54 CET] <ubitux> output-fixed-256.gif 2.1M
[11:27:53 CET] <thardin> yeah for size
[11:28:05 CET] <thardin> this goes out to 200k readers or so
[11:29:17 CET] <nevcairiel> i would think the reduction in dithering noise might offset some of the smaller-number gains, but perhaps not enough
[11:31:16 CET] <JEEB> hmm, I wonder if anyone can hint to me what I'm doing wrong with my subtitle decoder
[11:31:30 CET] <JEEB> https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff
[11:31:43 CET] <thardin> nevcairiel: output-fixed-32.gif is larger than output-fixed-64.gif so it's certainly a factor
[11:31:46 CET] <JEEB> currently it's a minimal thing just that grabs the basic "all the text without styling"
[11:31:52 CET] <ubitux> JEEB: do you have a full readable diff?
[11:32:25 CET] <JEEB> new file so https://github.com/jeeb/ffmpeg/blob/673dea189ba3e4b7f81f3beeb937b1617ded4641/libavcodec/libaribb24.c
[11:32:33 CET] <thardin> it also struck me that a zopfli-type effort for lzw might be good
[11:32:33 CET] <JEEB> in MPEG-TS I just set the AVCodec ID
[11:32:40 CET] <nevcairiel> thardin: ah, but the a dvantage of course dissipates as you get more colors already
[11:32:54 CET] <JEEB> (and profile and AVCodec type)
[11:32:55 CET] <JEEB> https://kuroko.fushizen.eu/videos/arib_captions_colors_positioning_ruby_subpics.ts
[11:32:59 CET] <JEEB> sample file
[11:33:07 CET] <thardin> nevcairiel: yes there's a sweet spot in this case
[11:33:11 CET] <ubitux> JEEB: btw, i hope you will add a fate test, cause im breaking shit currently
[11:33:16 CET] <JEEB> yes, I will
[11:33:22 CET] <thardin> with fixed dither it's a different story
[11:33:32 CET] <thardin> then you typically always get smaller files the fewer colors you have
[11:33:57 CET] <nevcairiel> but also ugly ugly results
[11:33:57 CET] <nevcairiel> :D
[11:34:01 CET] <thardin> yeah :)
[11:34:02 CET] <JEEB> ubitux: with `ffprobe -show_frames` for that stream I'm getting valid-looking stuff, and `ffmpeg -fix_sub_duration -i input.ts -map "0#0x114" -c:s ass out.ass` seems to work
[11:34:05 CET] <JEEB> *but*
[11:34:13 CET] <JEEB> for whatever reason mpv doesn't show the subs
[11:34:20 CET] <JEEB> so either mpv is bugged or my code is bugged
[11:34:24 CET] <JEEB> (or does something different)
[11:37:43 CET] <ubitux> what decoder did you use as reference? does the one you used as reference work for mpv?
[11:38:07 CET] <ubitux> if it does, compare the demuxers and check if pts/duration are set similarly
[11:38:10 CET] <JEEB> I checked what things libzvbi and webvtt do
[11:38:25 CET] <ubitux> does libzvbi works with mpv?
[11:38:57 CET] <JEEB> I /think/ it does, I've seen the text spam from the time when it set the subtitle duration to 30 sec by default
[11:39:21 CET] <ubitux> i'd compare the demuxers
[11:39:23 CET] <JEEB> but yea, mostly it's if I'm forgetting to set some value somewhere, that's why I started looking at webvtt etc
[11:39:25 CET] <ubitux> debug the packets with ffprobe
[11:39:49 CET] <JEEB> libzvbi and this are both from MPEG-TS so there's that at least
[11:39:49 CET] <ubitux> also, check the decoder flags, and check if mpv has exception wrt ccaption
[11:40:23 CET] <JEEB> but yea, the AVSubtitles at least seem to have sane'ish PTS and duration.
[11:40:30 CET] <JEEB> AVPacket I will have to double-check
[11:40:42 CET] <JEEB> but since AVSubtitle probably gets init from the AVPacket
[11:40:53 CET] <ubitux> in my current work i have a lot of trouble with ccaption and their delay
[11:41:53 CET] <ubitux> sorry, no other hint for now, i don't have time to debug it right now
[11:42:31 CET] <JEEB> ok, but at least it's positive that I'm getting semi-sane values from ffprobe's -show_frames, and .ass output seems to be OK
[11:42:47 CET] <JEEB> (just needs -fix_frame_duration for the AVSubtitles where your duration is INT32_MAX)
[11:43:44 CET] <cone-288> ffmpeg 03Gyan Doshi 07master:f60fdbc96074: avfilter/extractplanes: add support for 12-bit YUVA formats
[11:51:22 CET] <thardin> hm right fate needs updating for the palettegen patch
[11:56:34 CET] <kurosu> thardin: "that a zopfli-type effort for lzw might be good" <- aren't there some better GIF encoders around, which are bound to have better LZW engines
[11:57:18 CET] <thardin> I'd say it's likely
[11:58:10 CET] <kurosu> gifsicle iirc, but I don't know if the source code is available/split in nice modules/libs
[11:58:42 CET] <kurosu> oh, I skimmed a bit fast, it is about gif
[11:59:01 CET] <kurosu> I thought it was only about subtitles
[12:02:33 CET] <thardin> hm maybe it can be run as a secondary stage
[12:06:56 CET] <thardin> uhm running gifsicle with --optimize made the result larger
[12:08:53 CET] <thardin> ah -O3 got the size down
[12:10:00 CET] <thardin> 1970455 -> 1934731 bytes
[12:11:37 CET] <glynd> Hi
[12:12:30 CET] <durandal_1707> thardin: is hash same?
[12:13:34 CET] <glynd> Think I've found / identified / fixed a minor bug in ffmpeg options processing - trying to identify the correct process to verify the fix doesn't break anything
[12:14:14 CET] <thardin> durandal_1707: what before and after optimizing? no?
[12:14:23 CET] <thardin> or of the raw frames maybe. hmm
[12:14:56 CET] <durandal_1707> raw frames
[12:15:37 CET] <thardin> yep!
[12:15:48 CET] <thardin> tested like so: ffmpeg -i output-fixed-128.gif -f rawvideo - | sha1sum
[12:16:14 CET] <durandal_1707> thardin: ffmpeg have own hash muxer
[12:16:34 CET] <thardin> so I suspected
[12:17:01 CET] <kurosu> -f framecrc ?
[16:21:49 CET] <jamrial> ubitux: can i also get a review for my paletteuse patch? :p
[16:51:49 CET] <ubitux> jamrial: done
[16:52:06 CET] <jamrial> ubitux: thanks!
[16:52:08 CET] <ubitux> jamrial: i suppose you didn't expect nor observe any perf gain?
[16:53:03 CET] <ubitux> just curious, how did you come across this code? grep or while casually looking around?
[16:54:53 CET] <jamrial> didn't bench it, just made sure the fate tests didn't fail
[16:54:57 CET] <jamrial> there's going to be a gain but it's probably negligible
[16:55:13 CET] <jamrial> and yeah, grep for av_frame stuff out of curiosity :p
[17:27:05 CET] <cone-288> ffmpeg 03James Almer 07master:af05070ddf8e: avfilter/vf_paletteuse: don't constantly free and realloc internal frames
[22:54:18 CET] <cone-360> ffmpeg 03Guo, Yejun 07master:1ef4828276e4: avutil: add ROI (Region Of Interest) data struct and bump version
[22:54:18 CET] <cone-360> ffmpeg 03Guo, Yejun 07master:aceb9131c169: avcodec/libx264: add support for ROI-based encoding
[00:00:00 CET] --- Fri Jan 18 2019