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

[burek]

[00:01:07 CEST] <BBB> use a preset
[00:01:25 CEST] <BBB> (set private codec option preset to some value like ultrafast or veryslow)
[01:38:17 CEST] <cone-279> ffmpeg 03Marton Balint 07master:8009a1f1fdce: avisynth: fix setting stream timebase
[02:22:45 CEST] <cone-279> ffmpeg 03Michael Niedermayer 07master:d21ab8e4119e: avcodec/dvbsubdec: Print field lens in case they are too lerge
[02:34:31 CEST] <cone-279> ffmpeg 03Ganesh Ajjanagadde 07master:1bbb5ea10d9e: avformat/tls_gnutls: correct version detection for certificate support
[09:50:15 CEST] -:#ffmpeg-devel- [freenode-info] channel flooding and no channel staff around to help? Please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
[10:12:07 CEST] <bove> If I define a new pixel format in pixfmt.h and pixdesc.c, is that enough? Or would I need to create conversion filters manually?
[10:16:36 CEST] <wm4> bove: conversion is done in libswscale, which even in simple cases is not trivial
[10:35:40 CEST] <bove> wm4: So it's not as simple as defining the format?
[10:36:26 CEST] <nevcairiel> unfortunately, no
[10:36:36 CEST] <nevcairiel> with some trivial formats it may be almost that easy
[10:36:43 CEST] <nevcairiel> but anything not fitting the general pattern
[10:36:52 CEST] <nevcairiel> .. and we likely already have all the common format patterns
[10:39:56 CEST] <bove> nevcairiel: I've gone through all the different pixel formats, but I can't find a matching pattern for this special format. First on my list is a yuv420 format that does not match any of the existing 12 bits per pixel yuv formats
[10:41:01 CEST] <nevcairiel> what evil company invented yet a new way to store these 12 bits
[10:41:01 CEST] <durandal_1707> is there resource that describe format?
[10:41:02 CEST] <wm4> what's your pixel format?
[10:41:14 CEST] <wm4> durandal_1707: pixfmtdesc?
[10:41:35 CEST] <nevcairiel> its not detailed enough to allow a generic handling of formats though
[10:42:10 CEST] <wm4> such a generic description would be too complicated anyway
[10:42:12 CEST] <durandal_1707> wm4: I'm asking bove for description of pixel format
[10:42:19 CEST] <nevcairiel> and generic converters way too slow
[10:43:15 CEST] <wm4> durandal_1707: right, me too
[10:43:20 CEST] <bove> It's the SGO Mistika js format. I can probably get hold of descriptions
[10:43:29 CEST] <wm4> js??
[10:43:39 CEST] <bove> just the extension
[10:44:35 CEST] <nevcairiel> that sounds more like a codec than a pixelformat
[10:44:56 CEST] <bove> I'm currently working on the demuxer. The format supports a number of raw (pixel) formats
[10:45:18 CEST] <wm4> such cases can be left to a raw decoder too
[10:45:26 CEST] <wm4> we do this for some pixel formats which are "too special"
[10:45:29 CEST] <nevcairiel> some pixel formats are too obscure, so we sometimes build a "decoder" to convert them to a normal one
[10:45:39 CEST] <wm4> like v210
[10:47:08 CEST] <bove> wm4: I should probably have a look at that then ...
[10:50:34 CEST] <bove> I'll try the v210 decoder on a Mistika 422 10bits stream an see what happens ...
[10:51:38 CEST] Action: durandal_1707 hate doom9 moderators
[12:50:20 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:4ec4454ccf72: avformat/wavdec: Do not discard sample_count due to rounding
[12:50:21 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:acbd78a001e1: avformat/wavdec: Detect wrongly interpreted specification about the sample value in the fact chunk
[14:46:43 CEST] <Daemon404> mp3 in wav is a thing?
[14:46:48 CEST] <kierank> yes
[14:46:55 CEST] <kierank> probably many ways of doing it too
[14:48:12 CEST] <Daemon404> but why
[14:48:18 CEST] <Daemon404> (inb4 some terrible spdif-like thing)
[14:50:04 CEST] <nevcairiel> wav can actually hold a codec id, its just that shit like dts-in-wav doesnt actually set one  =p
[14:53:37 CEST] <Daemon404> nevcairiel, but why
[14:53:41 CEST] <Daemon404> my question does unanswered
[14:53:44 CEST] <kierank> so it passes through spdif
[14:53:50 CEST] <Daemon404> fff so i was right
[14:53:56 CEST] <kierank> dunno about mp3 in wav
[14:53:59 CEST] <kierank> dts in wav is because of that
[14:54:03 CEST] <nevcairiel> thats the reason for dts yes
[14:54:23 CEST] <nevcairiel> but wav with codec id would be just any generic container
[15:06:23 CEST] <iive> afair wav have 2 bytes for codec id
[15:06:27 CEST] <nevcairiel> yes
[15:07:10 CEST] <wm4> why would you want to use mp3 with spdif
[15:07:16 CEST] <wm4> it makes literally no sense at all
[15:07:48 CEST] <nevcairiel> why are you hung up on the spdif thing
[15:07:59 CEST] <nevcairiel> why cant there just be anything other than pcm in a wav container
[15:08:04 CEST] <nevcairiel> avi doesnt just come with one video codec
[15:08:09 CEST] <nevcairiel> wav is just avi without video =p
[15:08:21 CEST] <wm4> if there's a proper codec id, fine
[15:08:37 CEST] <wm4> but at least ac3 in wav doesn't have anything to identify it
[15:09:01 CEST] <nevcairiel> thats probalby the same deal as dts, for spdif sillyness
[15:12:25 CEST] <nevcairiel> those are the two spdif codecs a fterall
[16:35:31 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:bd2d4cc4a94e: avcodec/faxcompr: Print the unsupported mode number
[16:35:32 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:38025e6898ef: avcodec/faxcompr: Support cmode == 9 && xxx == 7
[16:35:33 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:dd1b4ed6d98f: avcodec/tiff: Support uncompressed G4 CCITT fax
[17:12:36 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:a4f9bb228bb3: avcodec/faxcompr: Support uncompressed escapes in decode_group3_1d_line()
[17:12:37 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:7727f76230e6: avcodec/tiff: Support uncompressed G3 CCITT fax
[18:55:00 CEST] <cone-056> ffmpeg 03James Almer 07master:1184795db634: crypto_bench: add support for blowfish
[18:55:01 CEST] <cone-056> ffmpeg 03James Almer 07master:a791e32b15d1: crypto_bench: add support for rc4
[18:55:02 CEST] <cone-056> ffmpeg 03James Almer 07master:bd1fe53eab95: crypto_bench: add support for xtea
[18:55:03 CEST] <cone-056> ffmpeg 03James Almer 07master:1c10c1aa3cc1: crypto_bench: add support for ripemd-128
[23:31:16 CEST] <cone-056> ffmpeg 03Michael Niedermayer 07master:5fec7942bf29: doc/developer: Suggest everyone to help with patch reviews
[00:00:00 CEST] --- Fri Aug 14 2015