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
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 252 seconds]
iive has quit [Quit: They came for me...]
thilo_ has quit [Ping timeout: 246 seconds]
thilo_ has joined #ffmpeg-devel
thilo_ has quit [Changing host]
thilo_ has joined #ffmpeg-devel
lexano has quit [Remote host closed the connection]
vipyne has joined #ffmpeg-devel
em___ has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 252 seconds]
lexano has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
arch1t3cht0 has joined #ffmpeg-devel
arch1t3cht has quit [Ping timeout: 252 seconds]
arch1t3cht0 is now known as arch1t3cht
mkver has quit [Ping timeout: 246 seconds]
jamrial has quit []
Martchus has joined #ffmpeg-devel
Martchus_ has quit [Ping timeout: 245 seconds]
em___ has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
em___ has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
feiw1 has quit [Ping timeout: 245 seconds]
feiw1 has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 272 seconds]
Krowl has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 248 seconds]
IndecisiveTurtle has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
IndecisiveTurtle has quit [Remote host closed the connection]
IndecisiveTurtle has joined #ffmpeg-devel
IndecisiveTurtle has quit [Ping timeout: 276 seconds]
Krowl has joined #ffmpeg-devel
<thardin>
I'm looking at EIA-608 again and I'm thinking maybe there's interest for a bsf for adding them to h.264? I see filter_units can remove them, so the opposite would be useful. perhaps reading them from a pipe
<elenril>
how would you do synchronization?
<thardin>
good question
<thardin>
in this case it's for a live stream so synchronization is done by the stream itself
<termos>
i had an issue with eia-608 being dropped randomly by the fps filter when dropping frames, so i added them to a buffer before the filter graph and stripped them with filter_units, then i re-apply them after the filter graph again
<thardin>
nice
<termos>
in my case the closed captions are coming from the input stream though
<thardin>
in this case we want CC:s out ASAP
<thardin>
so the bsf could select() a CC pipe
<elenril>
yeah no
<termos>
we just had a `get_buffer(pts)` that assembles the packets into a an `AVBufferRef` with padding added if the buffer is not full
<thardin>
I don't expect it to make its way upstream, but for this specific client it's probably enough. they already maintain their own fork
cone-765 has joined #ffmpeg-devel
<cone-765>
ffmpeg Tomas Härdin master:baa23e40c190: lavf/mxfdec: Set a scan direction explicitly
Krowl has quit [Read error: Connection reset by peer]
<JEEB>
I can LGTM that after $dayjob, so if you are available right now feel free to do it. testing it is pretty simple. try running `make fate-ffmpeg-spec-disposition` without SAMPLES being set. it should give an error, not run and fail :)
<elenril>
either way it seems obviously correct
<JEEB>
yeh
<JEEB>
so LGTM and apply if you are able to, since I'll still need to take some time to get access to my private email
mkver has joined #ffmpeg-devel
microchip_ has quit [Quit: There is no spoon!]
IndecisiveTurtle has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 245 seconds]
microchip_ has quit [Quit: There is no spoon!]
Krowl has joined #ffmpeg-devel
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
Workl has quit [Ping timeout: 246 seconds]
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
microchip_ has joined #ffmpeg-devel
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 265 seconds]
Xaldafax has joined #ffmpeg-devel
jamrial has joined #ffmpeg-devel
microchip__ has quit [Remote host closed the connection]
microchip_ has joined #ffmpeg-devel
microchip_ has quit [Client Quit]
IndecisiveTurtle has quit [Ping timeout: 252 seconds]
cone-765 has quit [Quit: transmission timeout]
microchip_ has joined #ffmpeg-devel
microchip__ has joined #ffmpeg-devel
microchip_ has quit [Ping timeout: 265 seconds]
Workl has joined #ffmpeg-devel
Workl4 has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 252 seconds]
Workl has quit [Ping timeout: 265 seconds]
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 246 seconds]
cone-904 has joined #ffmpeg-devel
<cone-904>
ffmpeg James Almer master:72f8f76d45d0: avutil/pixdesc: ensure the component being read or writen to is valid
<cone-904>
ffmpeg James Almer master:8debc5aa417d: avfilter/vsrc_testsrc: use the alpha component information for XV3{0,6} and V30X
<cone-904>
ffmpeg James Almer master:dfd7acf3edd4: avfilter/vf_pixdesctest: also take into account undefined alpha components
<cone-904>
ffmpeg James Almer master:8f1de9ccd960: avutil/pixdesc: add alpha component information to pixfmts with reserved but undefined alpha bits
<cone-904>
ffmpeg James Almer master:0bb53948acdd: swscale/swscale_unscaled: clear the low bits in planar8ToP01xleWrapper
<cone-904>
ffmpeg James Almer master:60b8f0d00436: fate/filter-video: make fate-filter-pixdesc compare the hashed output with and without pixdesctest filtering
Workl4 has quit [Read error: Connection reset by peer]
microchip__ is now known as microchip_
<cone-904>
ffmpeg James Almer master:8d940a07d190: avutil/pixdesc: fix alpha offset for X2{RGB,BGR}10BE
Krowl has joined #ffmpeg-devel
System_Error has quit [Remote host closed the connection]
odrling has quit [Ping timeout: 265 seconds]
Lynne has quit [Ping timeout: 265 seconds]
Lynne has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
names_are_hard has joined #ffmpeg-devel
<names_are_hard>
Hi! I'm trying to extend support for existing libavformat/mlvdec.c - is that on topic here?
<JEEB>
yes
<JEEB>
actual FFmpeg internal development is here
<names_are_hard>
Cool, thanks, I'm an ffmpeg dev noob so wanted to check. I have an uncontroversial change to mlvdec.c itself, and a question about mjpegdev.c
<names_are_hard>
Here's my total change, which works locally, adds support for LJ92 compressed MLV files: https://pastebin.com/pJkvQhBR
<names_are_hard>
I am forcing s->bayer in the ugliest way possible and clearly that's not right - how should I be doing that part?
odrling has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
vipyne has quit [Client Quit]
<JEEB>
you'd probably have to look at where the specification says the "am I bayer or not" flag is coded
<names_are_hard>
The demuxer knows that it's bayer, I don't know how to get mjpegdec to know it's bayer when the demuxer selects that as the codec
<JEEB>
looking at `git grep -i -C4 "bayer" -- libavcodec/mjpeg*` I don't see mjpegdec itself setting that value
<names_are_hard>
Yeah, that's my confusion. It seems like I want the passed in MjpegDecodeContext to already have it set. But being an ffmpeg noob, I don't know how to do that from the demuxer
<names_are_hard>
tiff (see changes in above linked commit) does it in dng_decode_jpeg()
<names_are_hard>
I guess I could make a new codec, libavcodec/mlv_lj92.c possibly, and copy the Tiff pattern. This feels overkill, given I literally want to set one flag, but maybe it's normal?
<JEEB>
right, tiff doesn't have proper separation of demux and decode
<JEEB>
thus it just creates a relevant decode context depending on what's there in the TIFF
<JEEB>
while this mlv thing is properly split
<names_are_hard>
But only has a demuxer
<names_are_hard>
If it helps, I also control the MLV format :D
<names_are_hard>
I didn't write the current mlv demuxer
<JEEB>
does bayer flag in mjpegdec set some specific pix_fmt?
<JEEB>
if yes, that could be utilized
<JEEB>
since codecpar stuff does get moved to codec context generally when transferring demux info to decoder
<names_are_hard>
No, but lack of it makes it complain further down - MLV uses 14 bit bayer, lossless, and the mjpeg checks become sad if bayer isn't set
<names_are_hard>
Oh, okay, I could maybe read a codecpar field in mjpeg and set bayer conditionally?
<JEEB>
no, you would then get that field into the avctx, such as the pix_fmt
<names_are_hard>
It's around this line that it grumbles: case 0x11110000: /* for bayer-encoded huffman lossless JPEGs embedded in DNGs */
<JEEB>
since it's container level info that needs to get passed to the codec context which would then affect the decoder
<JEEB>
in the worst case you could define a side data for it, but I'd try with something like pix_fmt first
<names_are_hard>
We're currently doing: vst->codecpar->format = AV_PIX_FMT_BAYER_RGGB16LE;
<JEEB>
so if during avctx init you already have a specific pix_fmt, then you set the bayer flag
<JEEB>
as apparently the JPEG stream itself doesn't contain any info on whether it's bayer or not :P
<JEEB>
(which sucks)
Marth64 has joined #ffmpeg-devel
<JEEB>
but yea, I see that being quite possible. you set the codecpar pix_fmt in demuxer, then that should get transferred to the decoder avctx
<JEEB>
and thus when the decoder handles it (like that decode_sof thing), you check for a bayer pix_fmt and set the flag accordingly
<names_are_hard>
Do I want to invent a new format, AV_PIX_FMT_BAYER_RGGB16LE_LJ92? I don't get how I'm supposed to handle the layering
<names_are_hard>
Set new format in demux, so when it gets to decode, it knows it's LJ92 over bayer?
<JEEB>
is there a need for a new pix_fmt?
<Lynne>
which sensor outputs it?
<Lynne>
or rather camera
<names_are_hard>
I don't know, I'm confused by how demux connects with codec
<JEEB>
so far I only see you mentioning that you want to do bayer = 1
<JEEB>
in the avctx
<JEEB>
which means that you can set the pix_fmt to bayer_* and that should work as a flag
<names_are_hard>
If I force mjpeg to always consider it to be bayer, I have working local code to play these files
<names_are_hard>
I don't know the right way to signal (maybe via the demuxer?) mjpeg that these kinds of inputs are bayer
<JEEB>
yea so if AV_PIX_FMT_BAYER_RGGB16LE works then you utilize that, and then in mjpegdec utilize the pix_fmt descriptor and check if it's a bayer pix_fmt?
<names_are_hard>
This format is generated by Magic Lantern, a software hack that runs on top of some Canon DSLRs
<JEEB>
and then boom bob's your uncle?
<JEEB>
right, there's AV_PIX_FMT_FLAG_BAYER
<names_are_hard>
It's effectively raw canon sensor data, in a lightweight container controlled by Magic Lantern project. In this specific case, we pass the sensor data through their lossless jpeg compressor hw first
<JEEB>
so in ff_mjpeg_decode_sof for example (just because you changed that one in the diff), you do `desc.flags & AV_PIX_FMT_FLAG_BAYER` and then set s->bayer = 1
<names_are_hard>
Ah, that sounds like a piece I was missing, thank you. desc.flags can be set in the demuxer?
<JEEB>
it's the pixel format descriptor that you can get from the pixel for that should get automagically transferred via codecpar to codec context
<JEEB>
*from the pixel format
<JEEB>
so if in the demuxer you set a bayer pix_fmt, that should get automagically transferred to decoder
<JEEB>
and thus unless it gets overridden you then can interpret it in the decoder
<names_are_hard>
I believe we set that, yes. I'll see if I understand this enough to implement it :D
<JEEB>
that returns you the descriptor for that pixel format, and then you can check the flags for bayer
<names_are_hard>
Great, that makes sense. Demuxer is saying where data is and format, codec uses that to decompress. But it's not obvious as a noob that pix fmt can be checked in codec
<JEEB>
usually the decoder sets that based on the data received, but when you need to receive some information from the outside due to the format itself not containing that information, then passing down of such information can be utilized. not perfect by any means (if you don't take into account the information from codecpar, interpretation changes), but eh
ccawley2011 has joined #ffmpeg-devel
<JEEB>
I recommend adding an av_log in mjpegdec's initialization function to make sure no parser or something is overriding the pix_fmt before the decoder gets involved, something like logging the avctx's av_get_pix_fmt_name
<JEEB>
(of the avctx's format)
<JEEB>
if nothing overrides it, then at that point you should still have the bayer format there
<JEEB>
and you can proceed with testing your logic on the mjpegdec level
<names_are_hard>
Haha, okay :) Man, doing stuff the right way is always a pain for large complex projects
<names_are_hard>
But I understand why
<names_are_hard>
av_log says: format: bayer_rggb16le, so that's promising
<Lynne>
the only reference to it I found is from a raspberry pi cam
<Lynne>
you're implementing this as a codec, right? if lj92 == lossless jpeg
<names_are_hard>
Yes, lossless jpeg. The support to handle that is already there in ffmpeg n7.2-dev, for DNG, and this is the same kind of compression. We use Canon hw decompressor, which is designed to output DNG. But we are running our own software on their OS, and can use the output of the decompressor directly (so, no DNG headers)
<names_are_hard>
This allows us to implement raw video on cameras that only natively support mov or mp4
<Lynne>
yeah, but you mendioned inventing a new pixel format for lj92
<Lynne>
you definitely shouldn't do that, pixel formats can't represent bitstream data
<names_are_hard>
I thought that might be the way to signal to mjpeg that it was lj92 over bayer, I was corrected :)
<names_are_hard>
Nice, querying pix_fmt works. Turns out the mjpegdec code was already doing this: s->pix_desc = av_pix_fmt_desc_get(s->avctx->pix_fmt);
<names_are_hard>
But, it was doing it later than I needed. I've moved it before the first check against s->bayer, and set s->bayer based on it. Is that likely to be stupid? Maybe av_pix_fmt_desc_get() was placed late because it's expensive or something?
Krowl has quit [Read error: Connection reset by peer]
vipyne has joined #ffmpeg-devel
em___ has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
Workl has joined #ffmpeg-devel
Krowl has quit [Ping timeout: 264 seconds]
Traneptora has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
<JEEB>
names_are_hard: nah, it's not really expensive esp. if you're calling it once in a function or so
Workl has quit [Ping timeout: 264 seconds]
<names_are_hard>
Yup, just once. Then I think it's worth trying to get this reviewed. Preferred method is git patches to mailing list, I think?
<JEEB>
aye, git send-email can do it for you, or you can first go through git format-patch -o directory/ and then send-email that directory manually (or otherwise send those patches)
Workl has joined #ffmpeg-devel
<names_are_hard>
Great, thanks for all the help! You made a complicated thing easy :)
Krowl has quit [Ping timeout: 252 seconds]
Krowl has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
Traneptora has joined #ffmpeg-devel
em___ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Workl has quit [Ping timeout: 265 seconds]
em___ has joined #ffmpeg-devel
cone-904 has quit [Quit: transmission timeout]
em___ has quit [Client Quit]
em___ has joined #ffmpeg-devel
em___ has quit [Client Quit]
em___ has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
vipyne has quit [Quit: Leaving.]
vipyne has joined #ffmpeg-devel
vipyne has quit [Client Quit]
Krowl has quit [Read error: Connection reset by peer]
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
microlappy has joined #ffmpeg-devel
microlappy has quit [Client Quit]
Traneptora has joined #ffmpeg-devel
vipyne has joined #ffmpeg-devel
vipyne has quit [Ping timeout: 265 seconds]
ngaullier has quit [Ping timeout: 248 seconds]
vipyne has joined #ffmpeg-devel
Traneptora has quit [Quit: Quit]
vipyne has quit [Ping timeout: 260 seconds]
cone-935 has joined #ffmpeg-devel
<cone-935>
ffmpeg Emily master:3565903c638f: fate/ffmpeg: add samples dependency to fate-ffmpeg-spec-disposition
<cone-935>
ffmpeg Emily release/7.1:9fbbd924f286: fate/ffmpeg: add samples dependency to fate-ffmpeg-spec-disposition
<JEEB>
elenril: thanks for mentioning the earlier patch, now it's merged
<JEEB>
Sebastinas: not the patch I sent out on Sunday, but at least it is now fixed on the release branch, too :)