ChanServ changed the topic of #ffmpeg to: Welcome to the FFmpeg USER support channel | Development channel: #ffmpeg-devel | Bug reports: https://ffmpeg.org/bugreports.html | Wiki: https://trac.ffmpeg.org/ | This channel is publically logged | FFmpeg 7.1.1 is released
fling has joined #ffmpeg
sentriz has quit [Ping timeout: 276 seconds]
MyTDT has joined #ffmpeg
MyTDT has quit [Ping timeout: 260 seconds]
sentriz has joined #ffmpeg
YUiNA has quit [Remote host closed the connection]
Kei_N has joined #ffmpeg
Kei_N_ has quit [Ping timeout: 248 seconds]
CHR0N0S has quit [Read error: Connection reset by peer]
Traneptora has quit [Quit: Quit]
Madiator2011 has quit [Remote host closed the connection]
Madiator2011 has joined #ffmpeg
Traneptora has joined #ffmpeg
OGU has joined #ffmpeg
mven9713 has quit [Quit: Goodbye.]
mven9713 has joined #ffmpeg
^Neo has quit [Ping timeout: 260 seconds]
minimal has quit [Quit: Leaving]
MyTDT_ has joined #ffmpeg
MyTDT_ has quit [Ping timeout: 276 seconds]
YUiNA has joined #ffmpeg
upekkha has quit []
upekkha has joined #ffmpeg
ramman has joined #ffmpeg
Dagger has quit [Ping timeout: 268 seconds]
<ramman>
Can you make a clip using the frame numbers?
k777__ has quit [Remote host closed the connection]
MyTDT_ has joined #ffmpeg
MyTDT_ has quit [Ping timeout: 276 seconds]
OGU has quit [Ping timeout: 265 seconds]
maxim_d33 has quit [Ping timeout: 276 seconds]
maxim_d33 has joined #ffmpeg
Dagger has joined #ffmpeg
Quackdoc has joined #ffmpeg
Quackdoc has quit [Client Quit]
fling has quit [Ping timeout: 264 seconds]
fling has joined #ffmpeg
_whitelogger has joined #ffmpeg
JanC has joined #ffmpeg
JanC is now known as Guest8482
Guest8482 has quit [Killed (tungsten.libera.chat (Nickname regained by services))]
BSaboia has quit [Remote host closed the connection]
mark4o has joined #ffmpeg
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
OGU has quit [Ping timeout: 252 seconds]
five618480339176 has joined #ffmpeg
markh has quit [Ping timeout: 268 seconds]
mark4o is now known as markh
BSaboia has joined #ffmpeg
BSaboia has quit [Remote host closed the connection]
kasper93 has quit [Quit: kasper93]
BSaboia has joined #ffmpeg
kasper93 has joined #ffmpeg
OGU has joined #ffmpeg
OGU has quit [Changing host]
OGU has joined #ffmpeg
figushki has joined #ffmpeg
demicv_ has joined #ffmpeg
T2D1 has joined #ffmpeg
figushki has quit [Client Quit]
System_Error has quit [Remote host closed the connection]
OGU has quit [Ping timeout: 252 seconds]
peacefight has quit [Ping timeout: 252 seconds]
figushki has joined #ffmpeg
<demicv_>
How can I find out the exact container with ffprobe? I want to only allow widely-supported formats on my site, but ffprobe shows the same format for e.g. { MP4, MOV }, { MKV, WebM }, which are wildly different in terms of compatibility. I can theoretically just use GNU file but I feel like domain-specific tool such as ffprobe should be more accurate than that?
System_Error has joined #ffmpeg
<JEEB>
for mp4-like subformats the major_brand is exposed
jmcantrell has joined #ffmpeg
<JEEB>
for matroska vs webm there really is no major method of identification, since if you look at the spec it mostly says "this is matroska with this feature, this feature and this feature utilized" https://www.webmproject.org/docs/container/
<JEEB>
or wait, OK. doctype could be a thing in webm... /me checks
<demicv_>
JEEB, yeah the major brand is the same for MP4 and MOV ("isom"). GNU find can still tell the difference.
<JEEB>
demicv_: that means that the "mov" file is actually based on MP4 ^^; MOV aka QTFF is supposed to have a qtff brand
rsx has quit [Quit: rsx]
<JEEB>
of course you may have minor brands regarding that but let me pull the apple spec
<demicv_>
quite likely. I just punched `ffmpeg -i file.mp4 file.mov` to test that
YUiNA has quit [Remote host closed the connection]
<JEEB>
so apparently they currently they no longer define the major brand, but rather just that the compatible brands should contain 'qt ' if it's supposed to be a QTFF file
<JEEB>
that said I have quite a few mov files here and there definitely is a major brand of the qt type
coldfeet has quit [Quit: Lost terminal]
<JEEB>
yea I have one definitely final cut studio generated one that has 'qt ' as the major brand, as well as one atomos generated. but both also have 'qt ' in the compatible brands list
<JEEB>
but basically having 'isom' in the major brand means that the primary specification the file can be interpreted as is ye normal mp4
<JEEB>
which is not surprising since QTFF files output by iOS devices for example mostly are just ISOBMFF aka MP4 (with some QTFF additions)
<JEEB>
also the reason why relative internals for similar enough formats are not usually exposed is because if you just need to figure out what is within the file (streams, metadata, packets etc), that really is not often relevant
<JEEB>
in theory though if someone really wants, the doctype could be exposed from the matroska demuxer for example
figushki has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<demicv_>
I kinda just need to determine is a video is playable by Chrome & other major web browsers
BSaboia has joined #ffmpeg
figushki has joined #ffmpeg
<JEEB>
in that case I'd probably just look at the codecs in general. you could in theory have vp9|vp8 + opus|vorbis in matroska, but it's quite unlikely
<JEEB>
for example those isom qtff files play just fine in browsers with H.264 and AAC since the major brand is ISOBMFF
<JEEB>
and now that browsers added HEVC hwdec even the HDR files created by iOS play with HEVC and AAC
<JEEB>
also actually not sure if a browser would nope at matroska doctype if the codecs in streams are vp9 and opus for example
<JEEB>
OK, mostly for the extension they are nope'ing. let's just rename the extension :P
<JEEB>
yea, firefox opens a matroska doctype with a supported readed video format just fine
<JEEB>
let's see chromium
<JEEB>
yea, same
<JEEB>
so neither firefox or chromium actually limits reading of EBML to webm doctype
figushki has quit [Ping timeout: 268 seconds]
<JEEB>
^ demicv_ , so with webm its doctype is not that important.
<JEEB>
(also funny enough this was with a video codec that is not officially part of webm at all - AV1. it was never added into the webm container specification since GOOG never cared about it as they moved on to using MP4 for AV1)
<demicv_>
But e.g. MKV files genereted by OBS are absolutely unplayable despite having the same Matroska / WebM output in ffprobe
<JEEB>
which codecs in streams?
<JEEB>
basically I'd expect the matroska parsers in browsers to support webm subset plus av1
<JEEB>
(even though av1 is not part of webm spec at all)
<demicv_>
h264 I see
minimal has joined #ffmpeg
<JEEB>
yup, that's unlikely to be supported, and as I noted checking the stream codecs is more useful than possibly wanting the doctype string since neither chromium or firefox seem to care about it
<JEEB>
the mime type or extension is what seems to decide whether the browser opens it at all or not. for a local file I had to rename the file to dot-webm but then the matroska-doctype'd file worked just fine.
stolen has quit [Quit: Connection closed for inactivity]
T2D1 has quit [Remote host closed the connection]
T2D1 has joined #ffmpeg
Liver_K is now known as FurStaku
FurStaku is now known as Liver_K
a0z has joined #ffmpeg
<ossifrage>
TIL ffmpeg has a fairly low max image size: [ffmpeg] IMGUTILS: Picture size 17408x17408 is invalid
<JEEB>
yea, that's because various bits including AVFrame just uses int
<JEEB>
and then you need to keep in mind X on Y and all that jazz
<JEEB>
so yes, hysterical raisins and it could be changed to int64_t, but that requires quite a code base wide adjustment, possibly in the SIMD paths as well
<ossifrage>
I often use uint16_t or int16_t for width/height and int32_t for stride,
<JEEB>
and yea, that technically even with X times Y doesn't hit 31 bits, but 29.
<kepstin>
gonna be funny if folks keep making higher and higher resolution video standards, and eventually they hit a point where nobody adopts the new standard because ffmpeg doesn't support frames sizes that large :)
<JEEB>
I'd have to look up the actual limitation
<ossifrage>
sqrt(2**31) is 46340
<JEEB>
> if (w==0 || h==0 || w > INT32_MAX || h > INT32_MAX || stride >= INT_MAX || stride*(h + 128ULL) >= INT_MAX) {
<kepstin>
sure, but also you have to account for the fact that each pixel is multiple bytes (in most pixel formats)
<JEEB>
I will guess the last thing is what fails there?
<kepstin>
hmm, how to planes factor into this?
<ossifrage>
In my case it was a jpeg in a tif (ugg), 3 channel, 8 bit YUV
<JEEB>
kepstin: I think it's mostly relevant when things are packed, which is what I expect it's checking for
<JEEB>
which affects the stride
YUiNA has joined #ffmpeg
<kepstin>
yeah, if indexing is done separately for each plane, that wouldn't be likely to cause problems.
<ossifrage>
17408*3*(17304+128) < 2**31
<ossifrage>
[err typo, but close enough]
<kepstin>
i do recall there being a separate limit somewhere to prevent excessive memory usage, rather than based just on limits of types?
<JEEB>
yea, but this specific message he posted has that if
<JEEB>
it depends on the exact stride etc utilized, so you'd have to print those out to figure out what was utilized
<kepstin>
interesting, if the av_image_get_linesize() fails for some reason, it assumes stride of 8 * width
<ossifrage>
I assumed the normal worst case stride would be 3 widths, but I've used weird layouts in the past so who know
<kepstin>
(17408×8+128×8)×(17304+128) is > INT_MAX
<kepstin>
right, if that's decoded as planar then the longest stride will be for the y plane, and it should just be the image width (1 byte per sample) plus padding...
T2D1 has quit [Quit: Leaving]
<JEEB>
probably if the sample is share'able that'd probably be the best way for kepstin to poke at it
<ossifrage>
I ended up using feh to display it, pqiv was having trouble zooming, the gnome doc viewer crapped out when it tried zooming
kasper93_ has joined #ffmpeg
kasper93 has quit [Killed (tantalum.libera.chat (Nickname regained by services))]
kasper93_ is now known as kasper93
<kepstin>
huh, kinda surprised that i don't have a debug build of ffmpeg handy. have to fix that :)
<ossifrage>
I'd assume we are fairly close to having an off the shelf image sensor with similar resolution. I'm more of a big pixel fan then a many pixel fan, but to each their own
<kepstin>
hmm. that's weird. av_image_check_size2 is getting called with AV_PIX_FMT_NONE
kasper93_ has joined #ffmpeg
<kepstin>
via "decode_simple_internal"
<ossifrage>
The jpeg inside of a tiff is kinda odd
<kepstin>
ok, so the problem appears to be that that "ff_set_dimensions" libavcodec/utils.c:93 is unconditionally passing AV_PIX_FMT_NONE instead of using the pixel format from the AVCodecContext?
<kepstin>
in all the tiff code, the pix_fmt is set right, it's just getting ignored in the call to "ff_set_dimensions" :/
<kepstin>
allows ffmpeg to decode the sample tiff for me.
* JEEB
runs FATE on that
<JEEB>
initially passes at least
flotwig_ has quit [Read error: Connection reset by peer]
<JEEB>
kepstin: fyi with that patch applied that linked sample still fails
<kepstin>
hmm. well, if it's failing it must be getting further an then failing in a different spot then? I'll admit that i didn't test very thoroughly