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 6.1.1 has been released! | Please read ffmpeg.org/developer.html#Code-of-conduct
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Marth64>
(tried it on master without changes. also pulled sample set from scratch)
<jamrial>
Marth64: passes here
<jamrial>
and that test doesn't use a sample from the fate sample suite
<Marth64>
hmm
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
<Marth64>
it was my environment. all good
rvalue has quit [Ping timeout: 256 seconds]
rvalue has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
cone-428 has quit [Quit: transmission timeout]
<Marth64>
kierank: my VCD didn't have captions, but my understanding from reading online is VCD keeps CC in a separate dedicated file, so nothing embedded in the MPEG-1.
<kierank>
Yeah, I think atsc was first and that was mpeg2
<Marth64>
cool
thilo has quit [Ping timeout: 272 seconds]
jarthur_ has quit [Quit: jarthur_]
thilo has joined #ffmpeg-devel
<kierank>
Marth64: LOL there are samples with both scte20 and ga94
<kierank>
That's funny
<Marth64>
yup haha, it's a miserable 2mbps 4:3 too
<Marth64>
but some things are worth preserving right
<Marth64>
i basically want eia608 decimated from my personal library
<Marth64>
src_movie filter will set up the eia608 stream from the side data, then ccaption_dec renders the stream to assa
<compn>
vcd captions whoa
<Marth64>
yeah apparently they go in a sidecar file
<Marth64>
i am curious if it's real eia608 cc or something else
<Lynne>
Marth64: I don't mind, but that's rather uncomfortable to use for API users
<Lynne>
also elenril thinks the movie filter is satanic cultism, which I'd agree with
<Marth64>
I agree it's a painful process. I was thinking to start fixing what's already there with CC and work my way to making it a better experience somehow gradually
<Marth64>
The subcc mechanism has existed for a long time
<Marth64>
I wouldn't care too much normally but I am very picky with subtitle presentation and preservation
<Marth64>
I figure if I can render the CCs to ASS and they look as intended with positioning and CC-like box/monospace, I can preserve that instead of this complex proprietary format
<Marth64>
This is also why I made rcwtenc, so you can keep the raw bits for later processing with ffmpeg or ccextractor. rcwtdec will come
pzy has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
jamrial has quit []
agrosant has joined #ffmpeg-devel
Marth64 has quit [Remote host closed the connection]
pzy has quit [Ping timeout: 264 seconds]
System_Error has quit [Remote host closed the connection]
System_Error has joined #ffmpeg-devel
rajivharlalka has joined #ffmpeg-devel
AbleBacon has quit [Read error: Connection reset by peer]
agrosant has quit [Ping timeout: 264 seconds]
agrosant has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
Martchus_ has quit [Ping timeout: 255 seconds]
Martchus has joined #ffmpeg-devel
justache is now known as justache_Test
justache_Test is now known as justache
pzy has joined #ffmpeg-devel
pzy has quit [Ping timeout: 268 seconds]
Kei_N has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
pzy has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 250 seconds]
pzy has quit [Ping timeout: 264 seconds]
rajivharlalka has quit [Quit: Connection closed for inactivity]
System_Error has quit [Ping timeout: 260 seconds]
System_Error has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
pzy has joined #ffmpeg-devel
pzy has quit [Ping timeout: 255 seconds]
Krowl has quit [Read error: Connection reset by peer]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
tufei has quit [Remote host closed the connection]
tufei has joined #ffmpeg-devel
cone-242 has joined #ffmpeg-devel
<cone-242>
ffmpeg Gyan Doshi master:3d1860ec8db7: avfilter: update filter timeline state only on main link
agrosant has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
qeed_ has joined #ffmpeg-devel
qeed has quit [Ping timeout: 260 seconds]
<cone-242>
ffmpeg Niklas Haas master:9aecd717ab9f: avcodec/dovi_rpu: implement support for profile 10
<cone-242>
ffmpeg Niklas Haas master:a5d1e69b3bd0: avcodec/libdav1d: parse DV profile 10 T.35 OBU
<cone-242>
ffmpeg Niklas Haas master:da39a19aadca: avcodec/av1dec: parse DV profile 10 T.35 OBU
<haasn>
what exactly is the purpose of MAINTAINERS?
<Lynne>
who to ping for reviews
agrosant has quit [Ping timeout: 264 seconds]
pzy has joined #ffmpeg-devel
CAT_S has quit [Read error: Connection reset by peer]
agrosant has joined #ffmpeg-devel
agrosant has quit [Ping timeout: 264 seconds]
Krowl has joined #ffmpeg-devel
<thardin>
elenril: did you see the SEPARATE_FIELDS discussion (interlaced j2k in mxf)? if so, thoughts?
<thardin>
conforming to MIXED_FIELDS should be fine. my main concern is that we do not have to do double work when inevitably some other codec used for the same purpose comes along
CAT_S has joined #ffmpeg-devel
<thardin>
and also putting container-specific stuff in a decoder smells
agrosant has joined #ffmpeg-devel
Krowl has quit [Read error: Connection reset by peer]
ngaullie has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 268 seconds]
jamrial has joined #ffmpeg-devel
mkver has joined #ffmpeg-devel
Krowl has joined #ffmpeg-devel
kurosu has joined #ffmpeg-devel
<haasn>
does FATE have an example of a file that changes resolution mid-stream?
<elenril>
haasn: h264/reinit*
<haasn>
thanks
<jamrial>
haasn: so dovi in hevc hijacks a unused NALu but in av1 it's properly implemented as registered ITU T35 metadata?
<haasn>
jamrial: yep
<haasn>
clearly av1 is the superior codec
<JEEB>
yea it's funny how that differs
<JEEB>
of course they then added that E-AC-3 metadata layer
<JEEB>
so you have T.35 where you have EMDF and in EMDF you have RPUs
agrosant has quit [Ping timeout: 264 seconds]
cone-242 has quit [Quit: transmission timeout]
<nevcairiel>
does AV1 support ELs?
<nevcairiel>
not that we support those in HEVC
<JEEB>
I think the same RPU payloads can be utilized?
<JEEB>
and the which streams to use information is in container
<JEEB>
so you say track X and track Y
<nevcairiel>
but with HEVC you can throw the EL into the same track as the BL, mostly wondering if AV1 would allow that, or thats not a design goal
<nevcairiel>
(thats the official storage in MP4/MKV afterall)
<JEEB>
uhh, I don't recall them being in the same track officially at least
<JEEB>
but yes, you can mux the RPUs to be in the same track in which case it just becomes a BL
<nevcairiel>
its still an EL and you have to split it out and decode it separately, and merge in rendering
<JEEB>
yea that's AFAIK not the official thing
<JEEB>
officially they're always split into streams|tracks
<JEEB>
I think the unofficial matroska thing does use those sub-packets
<JEEB>
the ones which VP9 uses for alpha etc
<nevcairiel>
i'm looking at the mp4 spec just now, the dual-track layout is unsupported for new applications, favoring a single-track dual-layer setup
<JEEB>
huh
<JEEB>
so they switched from tracks to nuh_layer_d
<JEEB>
*nuh_layer_id ?
<nevcairiel>
no it uses those reserverd nalu entries, 62 is used for RPU, 63 for EL
<nevcairiel>
63 has a header that then indicates what type the actual NALU inside is, since its essentially a nested HEVC stream
<JEEB>
ah
<JEEB>
I had seen those 63s
<JEEB>
the positive: it gets rid of the "is demuxer synchronized" issue
<nevcairiel>
yes, i kinda like it, i think the streams are also designed to have the same decoder delay
<JEEB>
yea
<JEEB>
negative: "lol more wrapping"
<Daemon404>
oh man
<Daemon404>
i thought EL was always a separate stream
<Daemon404>
2nd track i mean
<Daemon404>
nested 2nd stream hidden in a first stream ... D:
System_Error has quit [Remote host closed the connection]
jarthur has joined #ffmpeg-devel
System_Error has joined #ffmpeg-devel
TheSashmo has quit [Ping timeout: 272 seconds]
Kei_N has quit [Ping timeout: 260 seconds]
Krowl has quit [Read error: Connection reset by peer]
Kei_N has joined #ffmpeg-devel
blb has quit [Ping timeout: 255 seconds]
TheSashmo has joined #ffmpeg-devel
blb has joined #ffmpeg-devel
agrosant has joined #ffmpeg-devel
emptty has joined #ffmpeg-devel
jarthur has quit [Ping timeout: 268 seconds]
jarthur_ has joined #ffmpeg-devel
rvalue has quit [Ping timeout: 240 seconds]
ngaullie has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg-devel
jarthur_ is now known as jarthur
mkver has quit [Ping timeout: 240 seconds]
mkver has joined #ffmpeg-devel
blb has quit [Quit: brb]
<Lynne>
does anyone have a MIPS machine? I refactored AAC a lot, and there's a ton of MIPS intrinsics (half of which don't make sense, like the LTP code)
<BtbN>
Not a useful one
<BtbN>
My router uses a MIPS CPU
<BtbN>
Can't you just qemu it?
<BtbN>
Won't be great, but enough to determine if it's broken
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
blb has joined #ffmpeg-devel
Dmitri_Ovch has quit [Ping timeout: 256 seconds]
Dmitri_Ovch has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
<elenril>
x264 with multiple threads is supposed to be non-reproducible, right?
<JEEB>
only with VBV/HRD
<elenril>
huh
<elenril>
fun
cubicibo has joined #ffmpeg-devel
<frankplow>
Is there anywhere you can view oss-fuzz crashes just without the inputs, or are all results hidden if you don't have permissions?
Sean_McG has joined #ffmpeg-devel
* Sean_McG
peeks in
cone-744 has quit [Quit: transmission timeout]
Traneptora has joined #ffmpeg-devel
hamzah has quit [Quit: Client closed]
<Marth64>
Lynne: I have a really old router I can try to put DD-WRT on it for you
<Marth64>
I think it's only 16MB RAM, and unclear if it will even run DD-WRT but I can try
<Sean_McG>
ahhh dd-wrt, I remember those days
<Sean_McG>
all my equipment is Ubiquiti now
<Marth64>
:)
<Marth64>
I use MikroTik but I have an old WRT54G in my museum
<Marth64>
If it can run ffmpeg, impressive
<Sean_McG>
I think those were MIPS32... good luck have fun (as I recently discovered)
<Marth64>
hahaha I'm terrified now
<Sean_McG>
basically the MIPS/Loongson cross-pollination has made it almost impossible to find a lowest common denominator configuration between any of them, even just for the purpose of running another big-endian FATE node.
Marth64 has quit [Ping timeout: 264 seconds]
Marth64 has joined #ffmpeg-devel
<JEEB>
nice, merge conflict :3
<Sean_McG>
hi JEEB
<JEEB>
ohai
Livio has joined #ffmpeg-devel
ngaullier has joined #ffmpeg-devel
ngaullier has quit [Ping timeout: 264 seconds]
cubicibo14 has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 250 seconds]
<JEEB>
elenril, jamrial - posted a v8, just to not keep too long pauses between versions if possible :P
<JEEB>
I applied the flag rename, from_sd -> clone , from_buf -> add
<JEEB>
the 0/0 has a diff between v7 and v8
<JEEB>
did not touch the _extend VS avcodec function stuff since I want to first make sure there will not be stuff going the other way :P
<jamrial>
JEEB: still a lot of "to_set", but you can change them before pushing if this set is ultimately ok to commit
<JEEB>
yea there could be internal functions I didn't rename :P
<jamrial>
yeah
<JEEB>
I'm pretty sure various bits of this set have been good enough for inclusion at least a few times :P even if we ignore other stuff that gets merged. it's just that I'm trying to do things correctly and actually ask for reviews.
MisterMinister has quit [Ping timeout: 268 seconds]
<JEEB>
I think at at least one point I felt like I should just say I drop the set, and attempt to move to something more fun instead of doing something that seems useful but that ends up not being fun. but then the sunk cost fallacy hits and you go "OK, if I drop it then what were all those late night hours poking at that thing :P "
<jamrial>
no, because configuring encoders is useful :p
<jamrial>
elenril may have comments about 7 though, but i personally think this way is proper
<JEEB>
alright
<elenril>
jamrial: why?
<elenril>
the caller never wants to keep the ref
<jamrial>
because functions that take an AVBufferRef as input create a new reference to it if they need it, not take ownership of it
<elenril>
this sounds like a circular argument
<elenril>
or I don't understand what you're saying
<jamrial>
for starters, why would the caller not want to keep the ref?
<jamrial>
the very first user, av_frame_side_data_clone(), keeps the ref
<elenril>
because av_frame_new_side_data_from_buf() takes ownership, and as far as I can see all its callers are happy with that
<kepstin>
having the function create a new reference if some code will use the buffer after the function returns is the "safer" option, leads to memory leaks instead of referencing deallocated or re-used memory in cases where someone missed calling a memory management function.
Livio has quit [Ping timeout: 246 seconds]
<elenril>
kepstin: it's not really safer, just makes the bug harder to notice
<kepstin>
there certainly are cases where "passing ownership" of an existing ref is more ergonomic, but in plain C it's pretty easy to make a mistake and keep accessing via the reference that's no longer yours :/
<elenril>
a NULL dereference crashes immediately, which is highly visible and easy to debug
<kepstin>
with buffer pool allocators the bug with using something you don't have a reference to can be hard to notice, since it's still a valid pointer to allocated memory that now just doesn't contain the data you expect.
<elenril>
people generally don't use buffer pools for side data
<kepstin>
i'd have to actually look at the code in question to see, but the only way you'd get a NULL pointer later is if something is explicitly setting it to NULL - which means the function would need to take a AVBufferRef **buf so it could update it?
<elenril>
yes, that's the idea
<kepstin>
well, as long as people behave and don't put a struct AVBufferRef directly on the stack that's fine. I guess at that point it's mostly down to ergonomics - whether the expected and known callers are more likely to need to keep the reference for themselves for later or not.
<jamrial>
well, the first caller, a helper which in turn will be called by the cli, keeps the ref
hamzah has joined #ffmpeg-devel
cubicibo14 has quit [Ping timeout: 250 seconds]
cubicibo has joined #ffmpeg-devel
cubicibo has quit [Ping timeout: 250 seconds]
cubicibo has joined #ffmpeg-devel
mkver has quit [Ping timeout: 260 seconds]
agrosant has quit [Ping timeout: 264 seconds]
hamzah has quit [Ping timeout: 250 seconds]
clarkh_ has joined #ffmpeg-devel
cubicibo has quit [Quit: Client closed]
rvalue has quit [Ping timeout: 264 seconds]
rvalue has joined #ffmpeg-devel
Marth64 has quit [Ping timeout: 255 seconds]
mkver has joined #ffmpeg-devel
hamzah has joined #ffmpeg-devel
MrZeus has joined #ffmpeg-devel
MrZeus has quit [Read error: Connection reset by peer]