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.0 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
thilo has quit [Ping timeout: 256 seconds]
thilo has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 255 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
<ramiro>
mkver: in 6f2f496822b056db8c22763706da2a5103c96708 you changed Picture.reference in mpegvideo_dec.c from 0/3 to 0/1. the same could be done in mpegvideo_enc.c
<mkver>
ramiro: I know. What made you look at mpegvideo?
<Lynne>
courmisch: oh, instructions, not functions, I see
<courmisch>
as you know, assembler functions are made of instructions
Livio has joined #ffmpeg-devel
<ramiro>
mkver: my ffglitch project (used for bitstream editing). I needed to get a better understanding of the code.
<ramiro>
mkver: should I send a patch for mpegvideo_enc.c?
<mkver>
I can simply add it to my big patchset.
<mkver>
(But actually i wouldn't care about the value.)
<mkver>
The only reason I didn't change this is because I like to write nice commit messages that contain information like "It is only used as a boolean since commit foo", but for this I would need to dig into git history.
<mkver>
I think it had something to do with the H.264 decoder.
<ramiro>
mkver: yes, it was something related to h264. I did dig into git history but I didn't keep track of commit foo either :/
<ramiro>
I just tend to be wary of magic values.
Livio has quit [Ping timeout: 272 seconds]
<mkver>
ramiro: I think I found the commits. Will add this to my patchset.
<JEEB>
:)
Krowl has joined #ffmpeg-devel
lean1 has joined #ffmpeg-devel
<lean1>
hi
lean1 has quit [Client Quit]
lean1 has joined #ffmpeg-devel
lean1 has left #ffmpeg-devel [#ffmpeg-devel]
lean1 has joined #ffmpeg-devel
lean1 has left #ffmpeg-devel [#ffmpeg-devel]
<ramiro>
mkver: thank you. also thanks for bf8e40ae0d5975d3c18ef326ae62fe9052e746f6, it fixed another bug in wmalossless I had stumbled upon a few years ago.
<mkver>
What other bug?
<ramiro>
mkver: crashes in lossless-wma fate. I use a hacked GetBitContext in ffglitch, and that UB caused a crash.
<mkver>
Ok.
ccawley2011 has quit [Ping timeout: 264 seconds]
Krowl has quit [Read error: Connection reset by peer]
BBB has quit [Ping timeout: 252 seconds]
ccawley2011 has joined #ffmpeg-devel
BBB has joined #ffmpeg-devel
kurosu has quit [Quit: Connection closed for inactivity]
IndecisiveTurtle has joined #ffmpeg-devel
mkver has quit [Ping timeout: 252 seconds]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
cone-463 has quit [Quit: transmission timeout]
iive has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
wyatt8740 has joined #ffmpeg-devel
wyatt8740 has quit [Ping timeout: 255 seconds]
wyatt8740 has joined #ffmpeg-devel
cone-668 has joined #ffmpeg-devel
<cone-668>
ffmpeg PoorvaGaikar master:8b6e66d0f010: avfilter/f_select.c: add support for iw and ih variables
<cone-668>
ffmpeg Brad Smith master:9e674b31606c: lavd/v4l2: Use proper field type for second parameter of ioctl() with BSD's
Krowl has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 272 seconds]
ramiro has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 255 seconds]
ramiro has joined #ffmpeg-devel
darkapex has quit [Remote host closed the connection]
darkapex has joined #ffmpeg-devel
___nick___ has joined #ffmpeg-devel
kasper93_ has joined #ffmpeg-devel
ramiro has quit [Ping timeout: 268 seconds]
ramiro has joined #ffmpeg-devel
kasper93 has quit [Ping timeout: 268 seconds]
kasper93 has joined #ffmpeg-devel
kasper93_ has quit [Ping timeout: 256 seconds]
kurosu has joined #ffmpeg-devel
iive has quit [Ping timeout: 260 seconds]
iive has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
<mkver>
thardin: Do you know speedhq?
<mkver>
When I added the speedhq tests in 406c7fceeb9b0cfb82, I had to disable the vsynth3 tests (tests with a small resolution) because the encoder produces garbage (in the sense of: our decoder can't decode it; might also be a decoder bug).
<thardin>
mkver: not more than reading the multimedia wiki and the lavc decoder
<thardin>
sounds like something that might be worthwhile investigating. probably need NDI hardware to make a similar stream tho
<thardin>
it probably can't handle anything smaller than 64x64
<thardin>
maybe 64x8 or 64x16
ccawley2011 has quit [Read error: Connection reset by peer]