michaelni changed the topic of #ffmpeg-devel to: Welcome to the FFmpeg development channel | Questions about using FFmpeg or developing with libav* libs should be asked in #ffmpeg | This channel is publicly logged | FFmpeg 7.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
Kwiboo has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 260 seconds]
cone-177 has joined #ffmpeg-devel
<cone-177>
ffmpeg Leo Izen master:3fca5877d034: avcodec/pngdec: avoid hard failure on illegal sBIT chunks
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #ffmpeg-devel
iive has quit [Quit: They came for me...]
IndecisiveTurtle has quit [Ping timeout: 260 seconds]
<fflogger>
[newticket] uttam_32472: Ticket #11463 ([undetermined] Bitstreams with long Closed Captions do not get passed through in transcode flows) created https://trac.ffmpeg.org/ticket/11463
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Traneptora>
Marth64> eia608 and interlacing can burn in the same hell
<Traneptora>
don't forget IVTC
<Traneptora>
and /1001 framerate denominators
jannau has quit [Ping timeout: 260 seconds]
jannau has joined #ffmpeg-devel
<Lynne>
telecine is by far the worst
<Lynne>
imo odd framerates are perfectly okay, if you don't properly use a timebase for calculations, you shouldn't be writing a player
<Lynne>
I have some horribly telecine'd live events shot on 24fps, telecined to 30fps, and they're completely unrecoverable
<Lynne>
on a blu-ray!
<nevcairiel>
NTSC frame rates are definitely the least offensive in the bunch
<nevcairiel>
telecine is not bad in theory, but in practice its so often messed up
<Traneptora>
in this house we do not love or respect pulldown
<IQLeader>
congratulations, such an advanced dev skills!
<IQLeader>
beats leader at ease
<haasn>
why are AV_PIX_FMT_XV30BE / AV_PIX_FMT_XV30LE defined as AV_PIX_FMT_FLAG_BITSTREAM ?
<haasn>
as I understood, this flag is useful mainly for formats where pixels are not aligned with byte boundaries
<haasn>
but xv30 is aligned, it has 2 bits of padding in bitween each pixel
<Lynne>
that flag most definitely does not mean that
<haasn>
oh even weirder, xv30be is bitstream while xv30le is not
<Lynne>
otherwise we wouldn't have bitpacked or v210 decoders
<IQLeader>
yes, bitstream flag as used in some spots is invalid
<IQLeader>
bitstream means aligned is not on byte boundary, so bits need to be moved around in more complex manner
<Lynne>
but it does mean that there's still an alignment requirement for all values for a single pixel or component pairs to fit in a byte-aligned value
<Lynne>
rather than a continuous bitstream of say 10bit values
<Lynne>
its infuriating
<IQLeader>
v210 need more patterns to self describe