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
mkver has joined #ffmpeg-devel
tufei_ has quit [Quit: Leaving]
<BtbN>
jamrial: was just looking at a nice way to refactor the mastering display writing stuff in nvenc.c... But the way the lifetime of those structs is managed, there really isn't a much nicer way to do it.
<BtbN>
Wanted to shrink nvenc_send_frame() a bit again
<BtbN>
eh, still somewhat reasonably possible to just pull it out to its own function
<BtbN>
Anyone got a sample of h264/hevc with timestamps, that ffmpeg extracts as s12m?
aaabbb has quit [Ping timeout: 260 seconds]
tufei has joined #ffmpeg-devel
aaabbb has joined #ffmpeg-devel
<compnn>
BtbN, can ask on twitter /s
<BtbN>
Some people seem to really want those time codes, but I can't find anyone actually using them in the wild :D
cone-090 has joined #ffmpeg-devel
<cone-090>
ffmpeg Andreas Rheinhardt master:ebf0d3428113: avcodec/h261enc: Use LUT to write motion vector differences
<cone-090>
ffmpeg Andreas Rheinhardt master:58f9e497dcd9: avcodec/mpeg12enc: Move resetting last_dc to encoder
<cone-090>
ffmpeg Andreas Rheinhardt master:9a46c0160f3c: avcodec/mpeg12dec: Move resetting last_dc to decoder
<cone-090>
ffmpeg Andreas Rheinhardt master:5826166836e3: avcodec/h263dec: Clean intra tables in decoder, not ff_mpv_reconstruct_mb
<cone-090>
ffmpeg Andreas Rheinhardt master:fc64b2ee5d5d: avcodec/mpegvideo_enc: Don't reset intra buffers in mpv_reconstruct_mb()
<cone-090>
ffmpeg Andreas Rheinhardt master:b05ec7fec9e1: avcodec/mpv_reconstruct_mb_template: Merge template into its users
<cone-090>
ffmpeg Andreas Rheinhardt master:8f2af8fda68d: avcodec/mpegvideo_{dec,enc}: Reindent after the previous commit
thilo has quit [Ping timeout: 260 seconds]
thilo has joined #ffmpeg-devel
thilo has quit [Changing host]
thilo has joined #ffmpeg-devel
<devinheitmuell-1>
BtbN: They’re pretty common in live production workflows. I can get you some samples.
<BtbN>
That'd be neat
<devinheitmuell-1>
(both with H.264 and HEVC)
<BtbN>
I'm testing encoding them, so the source does not matter too much. But having both would be nice
<devinheitmuell-1>
It is done through SEI, in the picture_timing section, but some encoders won’t let you set it directly because picture_timing is setup for other reasons. For example, I have a patch for x264 to support it that somebody sent me a while ago.
<BtbN>
nvenc can already write S12M to HEVC and AV1
<BtbN>
but for h264 you need to translate it back into the fields of the picture_timing sei
<BtbN>
Which is what I'm testing right now
<BtbN>
the struct they picked is super weird
<devinheitmuell-1>
Some encoders like x264 let you add arbitrary SEI information (for example, CEA-708 captions, AFD, etc), but picture_timing is already being sent by the encoder, so an API change is needed to change the picture_timing that x264 is already sending.
<BtbN>
like, it wants deinterlacing info, but then says it only uses that to derive the amount of timecodes
<devinheitmuell-1>
It’s kind of a mess, because the SEI format doesn’t exactly match up to the S12-2 spec, because it counts up to 59.94, whereas 12-2 counts up to 29.97 and sets the field bit.
<devinheitmuell-1>
S12-2 supports setting timecodes on individual fields, which is part of why it’s more complicated.
<devinheitmuell-1>
Because different codecs had different APIs, and some didn’t support it at all, for an internal project we actually just carry it as opaque data through the encoder, and then rewrite the picture_timing after it comes out of the encoder.
<devinheitmuell-1>
^ had the benefit of working regardless of the codec implementation.
<devinheitmuell-1>
It’s 9pm here, so ping me tomorrow and I’ll see if I can dig up some samples.
<devinheitmuell-1>
(I’ve got plenty of content but I can’t redistribute it, so would have to generate some colorbars and encode it)
aaabbb has quit [Ping timeout: 252 seconds]
aaabbb has joined #ffmpeg-devel
System_Error has quit [Ping timeout: 264 seconds]
aaabbb has quit [Ping timeout: 252 seconds]
aaabbb has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #ffmpeg-devel
tufei_ has joined #ffmpeg-devel
tufei has quit [Ping timeout: 264 seconds]
tufei_ has quit [Ping timeout: 264 seconds]
<jamrial>
BtbN: did they fix the zeroed mdm sei problem?
<BtbN>
That's also zeroed?
<jamrial>
i remember one of the two, mdm or cll, did not really contain the values we passed to them
<BtbN>
I'd hope that the fix for all the other sei stuff also reaches that, but who knows
mkver has quit [Quit: Leaving]
<cone-090>
ffmpeg James Almer master:87d7b8ff4b02: fate/demux: add a test for Theora in OGG
minimal has quit [Quit: Leaving]
^Neo has quit [Ping timeout: 252 seconds]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 276 seconds]
aaabbb has quit [Changing host]
aaabbb has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
cone-090 has quit [Quit: transmission timeout]
bhaskar has joined #ffmpeg-devel
rvalue- has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 252 seconds]
rvalue- is now known as rvalue
j45_ has joined #ffmpeg-devel
j45 has quit [Ping timeout: 248 seconds]
j45_ is now known as j45
j45 has quit [Changing host]
j45 has joined #ffmpeg-devel
bhaskar has quit [Read error: Connection reset by peer]
RustyLeader has joined #ffmpeg-devel
<RustyLeader>
what CVEs need fixing?
rvalue has quit [Read error: Connection reset by peer]
kepstin has quit [Remote host closed the connection]
kepstin has joined #ffmpeg-devel
DauntlessOne4 has quit [Quit: Ping timeout (120 seconds)]
DauntlessOne4 has joined #ffmpeg-devel
<RustyLeader>
>>> This is what’s known as a load. Note that the “q” suffix refers to the size of the pointer *(*i.e in C it represents *sizeof(*src) == 8 on 64-bit
<RustyLeader>
there is too many '*' above
<RustyLeader>
its little awkwardly phrased
IndecisiveTurtle has joined #ffmpeg-devel
<welder>
Where does the template for hscale16to15_4 live? I'm having hard time finding it. I optimized the existing NEON version since it's often used in my workflow, but I noticed that there are no tests for it (I found some from 3 years ago on mailing lists that pass for arm64 but fail for x86).
<RustyLeader>
welder: somewhere in libswscale/aarch64/ ?
<ramiro>
haasn: init_range_convert_constants() assumes c->dstBpc goes from 0 to 16, and uses that to figure out what the internal representation will be (15 bpc or 19 bpc). c->dstBpc is 32 for grayf32le, but that's the size of the float samples. the internal representation still seems to be 19 bpc. should we add a field with the proper size of the internal representation, or should we add checks for c->dstBpc
<ramiro>
being 32 every time and treat it as 16?
lemourin has joined #ffmpeg-devel
<cone-947>
ffmpeg James Almer release/7.1:04fd3f69b3c3: avformat/iamf_parse: add missing av_free() call on failure path
<cone-947>
ffmpeg James Almer release/7.1:b06845c6727a: avformat/iamf_parse: add missing constrains for num_parameters in audio_element_oub()
<cone-947>
ffmpeg James Almer release/7.1:9abf2aef37a4: avformat/iamf_parse: ensure there's at most one of each parameter types in audio elements
Marth64 has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
<haasn>
ramiro: do what's easier, this code won't be needed after the rewrite
<haasn>
I think easiest is adding the bpc > 16 ? 19 : ... check for now
<haasn>
or using isFloat() if you wanna be facny
Marth64 has joined #ffmpeg-devel
<haasn>
(said rewrite is in the process of being polished atm so I can submit it for review)
<ramiro>
haasn: I'm curious. which part of this code won't be needed after the rewrite?
<haasn>
ramiro: all of it, the entire SwsContext is no longer needed
<haasn>
the rewrite is on top of SwsGraph and opaque operations kernels (SwsOp)
<haasn>
it solves range conversions in an entirely different way
<haasn>
it coincidentally also does generic range conversions using floating point math
<haasn>
but that's just because it's faster
<haasn>
more importantly, there is no more thing as a "range conversion" step
<ramiro>
haasn: I'm looking forward to seeing it!
<haasn>
expect something on the ML very soon :)
<haasn>
AV_PIX_FMT_P410BE, ///< interleaved chroma YUV 4:4:4, 30bpp, data in the high bits, big-endian
<haasn>
can somebody explain this format to me?
<haasn>
ditto P416
<haasn>
is P416 just like AYUV64 but without the alpha channel?
<haasn>
and P410 like rgb101010a2?
<jkqxz>
Those are Y410/Y416.
<jkqxz>
I'd guess it's meant to be a two-plane 4:4:4 with the chroma plane twice the size of the luma? No idea what the use of that would be, though.
mkver has quit [Quit: Leaving]
<cone-947>
ffmpeg Pavel Koshevoy master:5021764413a1: avformat/mov: (v4) fix get_eia608_packet
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
<fflogger>
[editedticket] pkoshevoy: Ticket #11470 ([avformat] get_eia608_packet misparses well formed files and corrupts Close Captions since 2020) updated https://trac.ffmpeg.org/ticket/11470#comment:1
bhaskar has joined #ffmpeg-devel
minimal has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<haasn>
philipl: can you explain XV36 to me?
<haasn>
the documentation says 48 bpp but the description makes it seem like 64 bpp
<haasn>
and implementing it as documented does not seem to work
<haasn>
given uint8_t y8, u8, v8; should I be doing: uint16_t *out; out[0] = v8 << 8; out[1] = y8 << 8; out[2] = u8 << 8; ?
<haasn>
out += 3;
<haasn>
or out += 4?
<haasn>
hmm, wayland docs seem to suggest the memory order is XVYU with 64 bpp
<haasn>
but this also doesn't match sws reference
<Lynne>
wayland uses big-endian notation
<Lynne>
same as drm
<haasn>
my code works for xv30le but produces a different result from sws for xv36le
DauntlessOne4 has joined #ffmpeg-devel
<jkqxz>
XV30, XV36 and XV48 are respectively Y410, Y412 and Y416 without an alpha channel.
<jkqxz>
XV36 and XV48 have the same layout in memory but for XV36 you ignore the low 4 bits (1.0 is 0xfff0 rather than 0xffff).
<haasn>
I get a deviation from swscale for both xv36 and xv48
<haasn>
(actually, both should be the same conversion from yuv444p)