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

[burek]

[00:21:33 CET] <BBB> so, regarding that new codec registration thing, Im not really a fan of removing the static init functionality, or deprecating it, or whatever, is that really necessary?
[00:22:09 CET] <BBB> I dont think a relatively pedantic thing like const marking is worth losing a real feature for
[00:22:22 CET] <BBB> being able to fill in options tables at runtime is pretty powerful IMO
[00:22:52 CET] <jamrial> agree
[00:23:32 CET] <jamrial> it's what has allowed us to mark encoders from external libraries as experimental depending on the version available, for exampel
[00:54:08 CET] <wm4> so, I'll push the threading  + XP dropping patch
[01:07:58 CET] <RiCON> jamrial: seems there's no 9bit anymore?
[01:08:10 CET] <RiCON> you can only configure as 8, 10 or both
[01:23:34 CET] <jamrial> no, no more 9bit
[01:48:10 CET] <jamrial> wm4: new version of the x264 patch
[01:56:40 CET] <wm4> so it looks like we'll need some sort of replacement API for AVCodec.pix_fmts anyway
[01:57:33 CET] <iive> why are pix_fmts i avcodec anyway?
[01:57:38 CET] <iive> i/in
[02:06:45 CET] <wm4> michaelni added it this way in 2004 fcee01646748763cf63528c97b99e976d6c76da8
[02:50:20 CET] <cone-896> ffmpeg 03wm4 07master:9b121dfc3281: w32pthreads: always use Vista+ API, drop XP support
[02:50:21 CET] <cone-896> ffmpeg 03wm4 07master:a04c2c707de2: lavc: replace and deprecate the lock manager
[02:50:22 CET] <cone-896> ffmpeg 03wm4 07master:e24f192a9fd6: ffplay: drop lock manager use
[02:50:23 CET] <cone-896> ffmpeg 03wm4 07master:86a13bf2ffb4: lavc, lavf: move avformat static mutex from avcodec to avformat
[02:50:24 CET] <cone-896> ffmpeg 03wm4 07master:4ed66517c62c: lavc: remove complex debug code around avcodec init locking
[02:52:36 CET] <jamrial> \o/
[03:02:07 CET] <cone-896> ffmpeg 03wm4 07master:cf57cb3ae436: h264: add AVOption to set x264_build default
[03:02:54 CET] <wm4> I also contacted the OS/2 maintainer to add the needed mechanism to the OS/2 thread wrapper
[03:18:29 CET] <cone-896> ffmpeg 03James Almer 07master:613f789c1915: w32pthreads: remove some remaining superfluous checks
[03:22:40 CET] <wm4> were those mentioned in a review and did I forget those?
[03:29:54 CET] <jamrial> i don't think so
[03:30:22 CET] <jamrial> i told you to keep the two defines, but didn't say anything about removing the check wrapping them
[03:30:51 CET] <jamrial> i noticed them just now
[03:31:17 CET] <wm4> I actually looked at this MemoryBarrier thing and wondered if it was still needed
[03:31:32 CET] <wm4> I saw atomics use it, so I left it (but I overlooked the ifdeffery is only for pre-Vista)
[03:31:43 CET] <mistym> Got some feedback on a patch, but not sure the right way to handle it: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-December/222942.html Any suggestions?
[03:32:18 CET] <wm4> mistym: what he didn't tell you is that you just can't return errors from parsers
[03:32:22 CET] <wm4> it's basically an API bug
[03:32:32 CET] <mistym> wm4: Oh, so just log the error and keep going?
[03:32:39 CET] <wm4> negative return values mean something weird (a byte offset into the past or so?)
[03:32:42 CET] <wm4> yes
[03:32:44 CET] <mistym> Hah
[03:32:45 CET] <mistym> OK
[03:33:02 CET] <wm4> make sure that if the error is encountered the parser won't enter an endless loop by retrying
[03:33:11 CET] <wm4> so just signal that all data has been consumed or so
[03:33:18 CET] <mistym> Also, was wondering - the patchset I'm submitting is building on an unmerged patch from someone else. I was submitting their commit as-is and added a couple of fixup commits after; would it be better to squash fixup commits into their original commit?
[03:33:25 CET] <mistym> (Even if that means I'm attributing code they technically didn't write :b)
[03:33:32 CET] <mistym> Oh yeah, good point
[03:33:45 CET] <mistym> I don't think I have any data which triggers this to test with, oh well
[03:33:48 CET] <wm4> if you modify someone else's patch just add a signed-off header
[03:35:36 CET] <mistym> OK, thanks - will do
[03:36:31 CET] <jamrial> and maybe mention "X changes done by $name" in the commit message
[03:42:09 CET] <mistym> Oh good idea
[04:15:48 CET] <mistym> Oh good, I actually found a file with invalid ATRAC3P to test. Looks like simply removing the `return` statements has the right effect; it's able to continue without doing anything drastically wrong.
[04:51:23 CET] <Compn> mistym : nice job updating the patch :)
[04:51:47 CET] <Compn> you working on a game emulator or ?
[04:51:52 CET] <Compn> why atrac3? ehe
[04:54:18 CET] <jamrial> isn't atrac3 used in minidisc?
[05:01:23 CET] <Compn> yes that too
[05:01:31 CET] <Compn> was it cracked yet ? 
[05:01:36 CET] <Compn> many people lost recordings iirc ?
[05:51:29 CET] <wm4> looking at this 4:4:4 cabac stuff again... is libavcodec really showing uninitialized memory? (frames from a previous file)
[06:04:08 CET] <Compn> clearing the previous memory takes cycles :P
[06:04:24 CET] <Compn> also it could be gpu showing previous frames
[06:04:27 CET] <wm4> no
[06:04:30 CET] Action: Compn runs
[06:04:32 CET] <Compn> ehehe
[06:04:45 CET] <wm4> and clearing the buffer pool is only an initialization cost
[06:07:11 CET] <wm4> really not sure how it can happen at all, but it does
[06:08:01 CET] <wm4> normally you'd expect that when allocating the pool, malloc will always use mmap, since it's such a big memory block
[06:08:31 CET] <Compn> i  thought there was a configure or gcc switch to make the memory more secure hmm
[06:10:12 CET] <wm4> that's something completely different
[08:42:44 CET] <mistym> Compn: Thanks :) My fiancée's a huge PSP fan, and the MPEG files used on those UMD video discs and in games use MPEG with H.264 video and ATRAC-3 Plus audio
[11:16:33 CET] <atomnuker> michaelni: did you push mistym's samples to the fate repo? planning to push the patchset soon
[13:22:44 CET] <durandal_170> atomnuker: it cant be done, because only power of 2 fft matters in lavc
[13:23:58 CET] <atomnuker> you could use a dft though you'll not enjoy the speed
[13:38:32 CET] <Darshan> Hello everyone, and merry christmas
[13:38:45 CET] <Darshan> I was wondering if there is a specific reason why ffmpeg do not support the loading of external filter and you have to make a new build ( or use Frei0r). Is it a security problem?
[14:36:29 CET] <durandal_170> atomnuker: python can do it, and its fast
[14:55:57 CET] <Djfe> Hi, do you think it's possible to code an ffmpeg filter to achieve what Twitch did (at smaller scale)? (demuxed conference talk): https://www.youtube.com/watch?v=LsF5bHRxC_M
[14:56:36 CET] <Djfe> to elaborate the workflow I'm thinking of:
[14:58:51 CET] <Djfe> one rtmp input stream -> mkv output with x264 or av1 stream -> pipe into another ffmpeg -> complex filter, 3 outputs, all hls streams, resolutions: 1 - remux from pipe, 2 - 720p with idr frames at the same position as 1, 3 - 360p with idr frames [...]
[14:59:50 CET] <Djfe> in-case the output is av1 -> it's enough to sync the S-Frames (no need for IDR frame sync)
[15:00:48 CET] <Djfe> I know it's possible to disable scene-detection in x264 and so on, to get a consistant IDR frame interval, but since that reduces the output quality a lot (at the same bitrate):
[15:03:11 CET] <Djfe> I'm thinking off a filter, that decodes the x264 input (1080p in this case), detects the IDR frames and sends each segment (separated by IDR frames) on it's own through x264, in a way that x264 creates one gop from it. Those gops will then be joined to one stream in an HSL/TS container
[15:04:07 CET] <Djfe> av1 on it's own might not even need this, since you can safely tell it to create s-frames in an interval, but if you want to offer HLS with av1 and x264 at the same time, then this filter could help
[15:04:26 CET] <Djfe> the question is: can a filter access which frame in a source stream was an IDR frame?
[15:05:11 CET] <Djfe> and will it reduce the quality again, if you tell x264 to create one gop with only one IDR from a source?
[15:05:37 CET] <Djfe> an advantage this has: scene-detection and all that stuff will work across all resolutions :)
[15:08:04 CET] <Djfe> this concept needs probably two filters or something: one that creates the pattern/timecodes and one that accepts them in the complex streams to coordinate the encoder
[15:09:27 CET] <sfan5> that sounds like it requires fiddling with encoder internals, which a mere video filter is not able to do
[15:10:06 CET] <sfan5> you're probably better off writing your own solution (based on libav*) for an usecase this specialized
[15:12:32 CET] <Djfe> If I don't touch the encoder: would it require me to start and stop x264 for every segment of the stream separately?
[15:14:15 CET] <Djfe> The use-case is HLS streaming, if that wasn't obvious.
[15:15:13 CET] <Djfe> Thx for the tip, I'll think about modifying libav. Just wanted to get some feedback on the idea and how it could be done best and what I should look out for :)
[15:22:33 CET] <Compn> 4k is dead, long live 5.7k.....
[15:26:26 CET] <bencoh> Djfe: back a few years ago I implemented a multibitrate HLS solution with adaptative GOP and fixed-length segments, where we decided to close/open x264 for every segment (simultaneously for all variants)
[15:27:09 CET] <Djfe> ok cool, how did it perform?
[15:27:44 CET] <bencoh> the pipeline is based on upipe, but it could be achieved with plain avocdec/x264
[15:28:33 CET] <bencoh> (this one pipeline was not opensource though)
[15:32:58 CET] <Djfe> Would recommend doing it again, if needed or not?
[15:34:44 CET] <bencoh> would I recommend what? opening/closing encoder? probably, yeah
[15:35:16 CET] <Tzimmo> About using PMT for detecting stream types for mpeg-TS
[15:35:20 CET] <Tzimmo> Project-X:
[15:35:21 CET] <Tzimmo> -> PMT 0x0CDB refers to these usable streams:
[15:35:30 CET] <Tzimmo> Subpict.:
[15:35:30 CET] <Tzimmo> PID: 0x0CDF(fin_0x12_p1_a1 )
[15:35:30 CET] <Tzimmo> PID: 0x0CE0(dut_0x12_p15_a1 )
[15:35:39 CET] <Tzimmo> ffmpeg:
[15:35:41 CET] <Tzimmo>     Stream #0:5[0xcdf]: Unknown: none
[15:35:41 CET] <Tzimmo>     Stream #0:6[0xce0]: Unknown: none
[15:36:00 CET] <Tzimmo> Any idea why not recognized and how to debug further?
[15:36:08 CET] <bencoh> not sure you'd need to write an ffmpeg filter (or encoder) for that though
[15:37:16 CET] <nevcairiel> i assume 0x12 is the id? not sure what type that is
[15:37:59 CET] <nevcairiel> ISO/IEC 14496-1 SL-packetized stream or FlexMux stream carried in PES packets
[15:38:00 CET] <nevcairiel> hm
[15:39:00 CET] <nevcairiel> never handled one of those SL mpegts files
[15:40:27 CET] <Tzimmo> I don't know what it stands for without looking more into it
[15:41:35 CET] <Tzimmo> I changed code to force them dvb subtitles
[15:41:36 CET] <Tzimmo> [mpegts @ 0x2cba580] probed stream 5 failed
[15:41:36 CET] <Tzimmo> [mpegts @ 0x2cba580] forcing it dvbsubtitle
[15:41:36 CET] <Tzimmo> [mpegts @ 0x2cba580] probed stream 6 failed
[15:41:36 CET] <Tzimmo> [mpegts @ 0x2cba580] forcing it dvbsubtitle
[15:41:46 CET] <Tzimmo>     Stream #0:5[0xcdf]: Subtitle: dvb_subtitle
[15:41:47 CET] <Tzimmo>     Stream #0:6[0xce0]: Subtitle: dvb_subtitle
[15:41:56 CET] <Tzimmo> Stream mapping: Stream #0:4 -> #0:0 (copy) Stream #0:1 -> #0:1 (copy) Stream #0:5 -> #0:2 (dvb_subtitle (dvbsub) -> ass (ssa))
[15:42:03 CET] <Tzimmo> [ssa @ 0x2d52a20] Only SUBTITLE_ASS type supported.
[15:42:26 CET] <Tzimmo> What options do I have to convert subtitles in mkv? Any bitmap types supported there? No?
[15:42:34 CET] <sfan5> just copy it?
[15:42:37 CET] <Tzimmo> I guess there are some bitmap types supported...
[15:42:59 CET] <Tzimmo> I try copy...
[15:47:08 CET] <Tzimmo> Yes... mplayer can no longer show audio or subtitles any more but just video... BUT!
[15:47:23 CET] <Tzimmo> mpv is now able to show video, audio AND subtitles!
[15:48:12 CET] <Tzimmo> I'll investigate further what's the issue/difference. My mplayer codebase is slightly old so it may be one reason.
[15:49:30 CET] <Tzimmo> But still it required forcing that stream to a subtitle. What is that SL-packetized stream?
[15:49:41 CET] <Tzimmo> Tried to google for it but didn't get obvious hits...
[15:54:23 CET] <Tzimmo> Found a PDF about it with some Japanese/Chinese text :)
[15:56:05 CET] <Tzimmo> A bit unrelated to this issue, but for the background, my Sony TV has a buggy support for PGS subtitles (BluRay movies etc) so that about half of them are not displayed at random. So I'm working on a tool to convert those bitmap subtitles into text-based subtitles because they just work perfectly.
[15:56:37 CET] <Tzimmo> I'm wondering if ffmpeg could support some external(?) tool like gocr for converting bitmap subtitles into text.
[15:57:01 CET] <Tzimmo> I guess currently it doesn't do that, does it?
[15:58:22 CET] <cone-345> ffmpeg 03James Almer 07master:89f704cabab4: avcodec/libx264: use the pixfmt descriptor to check for high bit depths
[15:58:23 CET] <cone-345> ffmpeg 03James Almer 07master:2a111c99a60f: avcodec/libx264: fix compilation with x264 builds >= 153
[16:01:25 CET] <Djfe> maybe you can copy the streams into some raw bytecode output, pipe that into your tool and then pipe the subtitles back into ffmpeg in a format that ffmpeg can read ;)
[16:03:43 CET] <Djfe> ffmpeg -i video.ts -map 0:5 -codec copy -f data stream.txt
[16:07:47 CET] <Djfe> so yeah, that should work
[16:08:00 CET] <Djfe> maybe you can put the file on pastebin, so we can take a look ;)
[16:08:56 CET] <Tzimmo> The subtitle file? I'll check for its length... but it should be reasonable.
[16:13:47 CET] <Tzimmo> 1783291 bytes
[16:15:22 CET] <Tzimmo> Does pastebin support uploading a binary file?
[16:15:26 CET] <Tzimmo> Or how do you want it?
[16:15:35 CET] <jamrial> jkqxz: https://pastebin.com/raw/hiwjZ6Lv
[16:18:15 CET] <Djfe> Tzimmo: I meant that differently
[16:18:31 CET] <Djfe> don't tell ffmpeg, that it's a subtitle file and keep it as unknown
[16:19:35 CET] <Djfe> then only map one of the two (#5) and copy it (tell ffmpeg to demux the Transportstream and only keep packets from stream #5) and then just output that as binary (-f data), so you/we can take a look at the stream with a hex editor ;)
[16:19:47 CET] <Djfe> of course that will loose any timestamps
[16:19:59 CET] <Djfe> but it's good for figuring out, what the stream is exactly
[16:20:11 CET] <Djfe> then do that again for stream #6 but name it differently
[16:20:34 CET] <Djfe> then upload both and share them with us ;)
[16:21:02 CET] <Djfe> (I just remembered: pastebin might not be the best idea, if it's binary)
[16:25:14 CET] <Tzimmo> Djfe: I think it was exactly what I did.
[16:25:30 CET] <Tzimmo> And yes it is binary
[16:25:41 CET] <Tzimmo> 00000000  20 00 0f 10 00 01 00 02  03 d4 0f 80 00 01 00 00  | ...............|
[16:26:19 CET] <Tzimmo> I'll send a link for those
[16:27:57 CET] <Tzimmo> Oh, stream 6 is only 119 bytes
[16:28:36 CET] <Tzimmo> It is then no subtitle at all but maybe just some headers for it
[16:51:02 CET] <iive> Djfe: the mpeg standrads provide something called scalability. You can have one base streem at lower resolution, fps or colorspace and extend it with additional packets. Unfortunately this is almost never used.
[16:51:58 CET] <iive> Djfe: however x264 does support something called B-pyramid. where you have one base level stream and B-frames that use it for their own prediction.
[16:52:39 CET] <iive> if  x264 encodes every second frame as second layer, in theory you can strip them and get half fps stream from it.
[16:53:03 CET] <iive> the stripping could be done at bitstream level, so no reencoding.
[16:53:25 CET] <Tzimmo> Djfe: http://www.tzimmola.net/dl/mtv3hd-subtitle-stream5.tar.bz2
[16:54:21 CET] <Tzimmo> Djfe: I may have blacklisted some networks in my firewall configuration. Let me know if you can download that or not.
[16:55:31 CET] <iive> one more thing. The slowest operation in encoding is the motion estimation, and if you encode same frame multiple times, it should have relatively the same motion. So if you keep the MV from low resolution search, you just refine it for the higher resolution.
[16:55:46 CET] <iive> but this needs encoder change.
[16:56:55 CET] <cone-345> ffmpeg 03James Almer 07release/3.4:31d6f3df25ee: avcodec/libx264: use the pixfmt descriptor to check for high bit depths
[16:56:56 CET] <cone-345> ffmpeg 03James Almer 07release/3.4:650cb712efc4: avcodec/libx264: fix compilation with x264 builds >= 153
[16:57:11 CET] <iive> long time ago, real video encoders used to produce different bitstreams simultaniously
[18:02:23 CET] <Djfe> Tzimmo: sry I was afk for some time, your server responds with a 403 Forbidden
[18:03:48 CET] <Djfe> my IPs are 2003:e4:53cb:a800:8d94:5dc3:9c98:e78 and 217 . 253 . 81 . 161
[18:05:15 CET] <Tzimmo> ok I'll check
[18:05:30 CET] <Djfe> thx
[18:05:56 CET] <Djfe> @iive: I already heard about techniques like these (used in audio codecs like aac he (v1, v2 etc.)
[18:06:39 CET] <Tzimmo> Djfe: permissions fixed, retry please
[18:06:42 CET] <Djfe> @iive but it's not what I'm looking for, since Apple Http Live Streaming completely separates all video streams into different transportstreams and just lists them in playlist file (m3u8)
[18:06:58 CET] <Djfe> ok got it, you can close it again
[18:07:03 CET] <cone-345> ffmpeg 03Michael Niedermayer 07master:4d70fbeec8cb: avcodec/dirac_dwt: Fix integer overflow in COMPOSE_DD97iH0() and COMPOSE_DD137iL0()
[18:07:04 CET] <cone-345> ffmpeg 03Michael Niedermayer 07master:0c9ab5ef9c1e: avcodec/hevcdsp_template.c: Fix undefined shift in FUNC(dequant)
[18:07:05 CET] <Tzimmo> ok
[18:07:33 CET] <kierank> BBB: ping
[18:07:45 CET] <Djfe> @iive I'm not sure whether MPEG Dash would support this
[18:08:22 CET] <Djfe> aac does it because they need to stay backwards compatible to legacy hardware that only supports older versions so the new ones just add packets
[18:09:12 CET] <iive> Djfe: for 720p60 vs 720p30 , the idea is to encode is at p60 and then use bitstreamfilter (bsf) to remove the layer 2 frames.
[18:09:19 CET] <Djfe> the other reason would be to offer different presets for decoders, if some decoders are too stupid to encode high bitrate stuff
[18:10:03 CET] <Djfe> yeah but does the 720p30 client also download the full bitrate stream (all 60fps) and only decode 30?
[18:10:41 CET] <iive> that's what the bfs should do, remove the "extra" packets.
[18:11:17 CET] <iive> since it works on compressed bitstream, it is as fast as stream copy (well a tiny bit slower than it)
[18:11:33 CET] <Djfe> The reason why you need aligned IDR frames in apple HLS is, because the browsers switch freely between all available streams, depending on the available bitrate. They can switch at each segment (one GOP), therefore they need to be aligned. Else seconds are repeated or missing when the browser switches
[18:12:03 CET] <Djfe> yeah but it's on the client side so it doesn't save traffic only decoding complexity, right?
[18:12:22 CET] <Djfe> (if you remove half of the frames at the client side)
[18:12:28 CET] <iive> you run the bfs on the server side, after getting the 720p60 encode.
[18:12:36 CET] <iive> bsf
[18:12:52 CET] <iive> btw, I don't think such filter exists atm, but it could be done.
[18:13:24 CET] <nevcairiel> the filter isnt the only thing you would need, also an encoder to make every second frame exactly a discardable one
[18:13:43 CET] <jkqxz> jamrial:  The DESC2 structure is DESC with extra fields (DESC1 in between).  There is GetDesc2 (and GetDesc1) as well, but there was something funny about that case when I was writing it which I can't now remember.
[18:13:46 CET] <iive> b-pyramid is already implemented in x264
[18:14:05 CET] <nevcairiel> it doesnt do that however
[18:14:11 CET] <jkqxz> jamrial:  Maybe it could have a cast?  I'm pretty sure I didn't have that warning in my setup, though.
[18:14:33 CET] <nevcairiel> b-pyramic by itself only allows bframes as references
[18:14:42 CET] <nevcairiel> it doesnt ensure proper placement every other frame
[18:15:01 CET] <iive> no it doesn't.
[18:15:20 CET] <iive> but that's easier to solve problem.
[18:15:49 CET] <jamrial> jkqxz: how about changing desc into DXGI_ADAPTER_DESC?
[18:15:51 CET] <Djfe> Tzimmo: I was able to open it as a subtitle file using https://github.com/SubtitleEdit/subtitleedit/releases
[18:15:51 CET] <nevcairiel> besides you dont even need b-pyramid to do that
[18:15:51 CET] <iive> actually you don't need the b-pyramid, you can just discard b-frames. but then you'd need fixed frame order too.
[18:16:17 CET] <Djfe> Tzimmo: The software uses tesseract for OCR, so you can convert the subtitles to text ;)
[18:16:18 CET] <iive> but then you'd have to handle reorder of frame numbers in the bsf..
[18:16:27 CET] <iive> maybe you already need that.
[18:16:27 CET] <jamrial> it doesn't complain anymore with that change, and it's used only in an av_log call.
[18:17:10 CET] <jkqxz> IIRC I wrote that initially but it didn't compile.
[18:17:27 CET] <jkqxz> Looking now I think it should, but I'm not near any Windows machine to test.
[18:18:16 CET] <jamrial> no rush
[18:19:18 CET] <kierank> jdarnley: ping
[18:19:25 CET] <jdarnley> pong
[18:20:04 CET] <kierank> jdarnley: are you familiar with the 10-bit idct?
[18:20:06 CET] <kierank> in asm
[18:20:55 CET] <jdarnley> A little but only indirectly though my work on the 8-bit.
[18:23:05 CET] <kierank> jdarnley: any idea how much work it would be to add this to the simd https://www.irccloud.com/pastebin/hgz0N2IG/
[18:23:20 CET] <kierank> not I got rid of the dc-only hacks because they only work on 16-bit coeffs
[18:23:25 CET] <kierank> note*
[18:24:25 CET] <jdarnley> You need 32-bit?  Otherwise you might be able to resuse the existing ones.
[18:24:32 CET] <jdarnley> letme have a quick look
[18:25:10 CET] <kierank> 32-bit in 10-bit out
[18:25:12 CET] <kierank> and perhaps later 12-bit
[18:25:29 CET] <kierank> I basically just brute forced the shifts until it looked right
[18:26:37 CET] <Djfe> Tzimmo: it's VobSub (.sub/.idx) https://en.wikipedia.org/wiki/DirectVobSub you could either keep it a binary (error free) and tell ffmpeg this is VobSub, so it will correctly use it in the output file.
[18:26:55 CET] <Djfe> Tzimmo: or you burn them into the video: https://askubuntu.com/questions/391122/how-can-i-burn-vobsub-subtitles-using-ffmpeg
[18:27:46 CET] <Djfe> Tzimmo: or you use OCR (Subtitle Edit) to make them into an .srt file (involves work, because OCR doesn't work errorfree)
[18:33:35 CET] <cone-345> ffmpeg 03Mark Thompson 07master:e6a1dfc9ce81: mpeg4videodec: Fix unused variable warning
[18:37:24 CET] <Djfe> Tzimmo: never midn, I don't know the subtitle type exactly but subtitle edit says it's vobsub and is able to decode it
[18:38:01 CET] <jdarnley> kierank: the simple_idct code is fairly flexible with parameters for shifts and constants but all the math seems to use 16-bit input
[18:38:18 CET] <kierank> crap ok, a project for another time i think
[18:38:22 CET] <Djfe> dvb_subtitle seems to implay the same as vobsub
[18:38:33 CET] <jdarnley> The logic is probably sound so maybe some copy-paste and a little editing would be enough
[19:23:15 CET] <Compn> its fun to convert vobsub to srt
[19:23:19 CET] <Compn> ive done it a few times
[19:23:39 CET] <Compn> then manually edit file and change all I to L heh :\
[19:52:40 CET] <Djfe> at least there are tools like subtitle edit, that make this so much less work ^^
[20:48:51 CET] <durandal_170> as there is no reviews i will just commit deconvolve filter as its already better than imagetragick
[21:00:22 CET] <BBB> kierank: pong
[21:00:47 CET] <kierank> BBB: never mind, I found the correct idct shifts by trial and error. I might have questions later about the templating though
[21:44:14 CET] <Djfe> Tzimmo: ping
[22:01:10 CET] <durandal_1707> atomnuker: status report?
[22:05:50 CET] <kierank> michaelni: can you explain what you are doing in ff_update_block_index
[22:06:30 CET] <kierank> it seems to be working in 4:2:0 yet somehow affects mpegvideo.c which supports 422 and 444
[22:07:03 CET] <kierank> michaelni: to quote you in https://patchwork.ffmpeg.org/patch/2095/
[22:07:12 CET] <kierank> > Line 997: What is all this stuff going on with -1U, unless I remove this I
[22:07:12 CET] <kierank> > get a segfault. I do get a stripe on the left though.
[22:07:12 CET] <kierank> IIRC the 1U compensates the effect of ff_update_block_index()
[22:07:12 CET] <kierank> block_size in ff_update_block_index() looks wrong after your patch
[22:07:13 CET] <kierank> ????
[22:37:58 CET] <Tzimmo> Dfje: pong
[22:42:55 CET] <Tzimmo> Dfje: Ok. I think I've used some subtitleedit to OCR some subtitles on Windows some years ago but then I have been mostly able to get around without it.
[22:43:46 CET] <Tzimmo> But the issue from ffmpeg point of view is, why wasn't it detected as a subtitle in the first place?
[22:44:19 CET] <Tzimmo> There was PMT present and if the subtitle itself was even in a known format, why isn't it recognized as a subtitle?
[22:45:42 CET] <tmm1> the enum AVLockOp deprecation is throwing a lot of compiler warnings
[22:45:59 CET] <Tzimmo> And yes, I've been burning subtitles into image but kind of hate it to re-encode high quality HD stream just to burn subtitles into it.
[22:46:34 CET] <Tzimmo> But it is acceptable until I find a better working solution for it.
[22:48:35 CET] <tmm1> wm4: https://paste.ubuntu.com/26260221/
[22:59:15 CET] <kierank> oh god i think michaelni just hardcodes 4:2:0 in ff_update_block_index
[22:59:17 CET] <kierank> eugh what a mess
[23:08:34 CET] <Djfe> tzimmo: do the subtitles work if you enforce them as dvb_subtitles (vobsub)?
[23:08:40 CET] <Djfe> (like in VLC)
[23:08:55 CET] <nevcairiel> dvb is not vobsub, dvd is vobsub
[23:09:08 CET] <Djfe> are they detected in VLC in the source file?
[23:09:41 CET] <Djfe> thx nevcairiel very good to know!
[23:11:53 CET] <michaelni> kierank, i think codec implementations supporting more than 420 dont use ff_update_block_index(). mpeg12 directly updates dest[] for example. But its really long ago that i worked on this
[23:12:15 CET] <kierank> yes, I've confirmed it's all hardcoded for 4:2:0 8-bit
[23:12:25 CET] <Djfe> Tzimmo: good question! maybe you wanna open up a bug report in trac and upload a sample file
[23:13:35 CET] <Djfe> one thing I could think of: the subtitles aren't available through the whole stream (for example not at the beginning), or their identifier or something is different from what ffmpeg is looking for, so that other identifier only needs to be added
[23:13:47 CET] <Djfe> the PMT changes over time after all
[23:14:25 CET] <Djfe> maybe ffmpeg tells you more if you make the output verbose and log it to a file
[23:43:07 CET] <cone-741> ffmpeg 03James Almer 07master:7e60c7432935: avcodec/libx264: set supported pix_fmts at runtime rather than build time
[23:45:51 CET] <cone-741> ffmpeg 03James Almer 07release/3.4:d8104977bbfa: avcodec/libx264: set supported pix_fmts at runtime rather than build time
[23:58:23 CET] <cone-741> ffmpeg 03Aman Gupta 07master:2f9ca64556cb: avformat/hls: remove repeated http proto_name checks in open_url()
[23:58:24 CET] <cone-741> ffmpeg 03Aman Gupta 07master:a232a72d77cf: avformat/hls: return AVERROR_PROTOCOL_NOT_FOUND when http protocol is not available
[23:58:25 CET] <cone-741> ffmpeg 03Aman Gupta 07master:11f989945e17: avformat/http: avoid ff_http_do_new_request after http/1.0 response
[23:58:26 CET] <cone-741> ffmpeg 03Aman Gupta 07master:ac19e63b1845: avformat/hls: respect http_persistent only for http playlist urls
[23:58:27 CET] <cone-741> ffmpeg 03Aman Gupta 07master:039007c928b4: avformat/http: export http_version from response
[23:58:28 CET] <cone-741> ffmpeg 03Aman Gupta 07master:1dd82edea5ab: avformat/hls: enable http_multiple only for http/1.1 servers
[00:00:00 CET] --- Wed Dec 27 2017