<linext_>
can ffmpeg print shoutcast/icecast song data as it comes in?
<linext_>
i thought "icy_metadata_packet 1" would do it, but it's only showing the first song
thilo has quit [Ping timeout: 268 seconds]
thilo has joined #ffmpeg
jtgd has quit [Quit: WeeChat 4.1.2]
jtgd has joined #ffmpeg
jtgd has quit [Client Quit]
jtgd has joined #ffmpeg
BUSY has joined #ffmpeg
qaph has joined #ffmpeg
omegatron has quit [Quit: Power is a curious thing. It can be contained, hidden, locked away, and yet it always breaks free.]
kron has quit [Ping timeout: 246 seconds]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
VinylS has joined #ffmpeg
Muimi__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<VinylS>
hello, i've recently started converting a large bit of music and it came to my attention that the art cover isnt embedded because some code hasn't been merged yet, I wanted to ask if it could be https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7314
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
LionEagle has quit [Quit: Leaving]
Keshl_ has joined #ffmpeg
Keshl has quit [Ping timeout: 245 seconds]
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
nrg has quit [Ping timeout: 255 seconds]
nrg has joined #ffmpeg
Hackerpcs has quit [Quit: Hackerpcs]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
Hackerpcs has joined #ffmpeg
Hackerpcs has quit [Max SendQ exceeded]
Hackerpcs has joined #ffmpeg
FH_thecat has quit [Ping timeout: 256 seconds]
AbleBacon has quit [Read error: Connection reset by peer]
waleee has quit [Ping timeout: 240 seconds]
emmanuelux has quit [Quit: au revoir]
bitoff has quit [Ping timeout: 245 seconds]
VinylS has quit [Quit: Leaving]
jagannatharjun has joined #ffmpeg
bitoff has joined #ffmpeg
Dariusz has quit [Remote host closed the connection]
FH_thecat has joined #ffmpeg
Muimi__ has joined #ffmpeg
Muimi__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
Keshl__ has joined #ffmpeg
Keshl_ has quit [Read error: Connection reset by peer]
YuGiOhJCJ has joined #ffmpeg
MootPoot has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
HarshK23 has joined #ffmpeg
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
rvalue has quit [Read error: Connection reset by peer]
rvalue has joined #ffmpeg
bitbinge has quit [Quit: bitbinge]
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
bitbinge has joined #ffmpeg
lavaball has joined #ffmpeg
jagannatharjun has quit [Quit: Connection closed for inactivity]
BillTorvalds has joined #ffmpeg
treefrob has joined #ffmpeg
treefrob has quit [Max SendQ exceeded]
MootPoot has quit [Quit: Connection closed for inactivity]
treefrob has joined #ffmpeg
emanuele6 has quit [Quit: kernel++]
emanuele6 has joined #ffmpeg
Blacker47 has joined #ffmpeg
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
hjckr has quit [Ping timeout: 246 seconds]
Tinos has quit [Quit: Client closed]
hjckr has joined #ffmpeg
treefrob has quit [Remote host closed the connection]
Keshl__ is now known as Keshl
LuKaRo_ has quit [Ping timeout: 256 seconds]
<Bombo>
when i try this on my raspi: ffmpeg -f kmsgrab -i - -vf "hwdownload,format=bgr0" output.mp4 i get an error: [hwdownload ...] invalid output format bgr0 for hwframe download... what fornat do i need?
<JEEB>
you'd have to check the sw_format on that received frame. not sure if the filter chain logs it
<Bombo>
in the ffmpeg output? i see Video: wrapped_avframe, drm_prime ... does that help?
<Bombo>
[kmsgrab @ 0x55af564590] Using plane 80 to locate framebuffers.
<Bombo>
[kmsgrab @ 0x55af564590] Template framebuffer is 292: 1360x768 format 36314752 modifier 0 flags 2.
<Bombo>
or that
<JEEB>
drm_prime is the primary pix_fmt I guess
<JEEB>
there's a AVFrame->sw_pix_fmt or sw_format or whatever it was
<JEEB>
since it contains the actual content within that hw pix_fmt
<JEEB>
alternatively you figure out what format 36314752 is in DRM/KMS
<JEEB>
no idea if that logged format is in hex or not since it has no 0x :D
<JEEB>
it may be, it may not be
<JEEB>
ok, it's PRIx32
<JEEB>
so that is a hex
<JEEB>
... lol.
<CounterPillow>
lol wtf RG16
<JEEB>
ah at least those two log lines are slightly different
<JEEB>
there was another "Template framebuffer" log line in kmsgrab
<JEEB>
thankfully they're a bit different so it is indeed the hex-format one
<Bombo>
phew ;)
omegatron has joined #ffmpeg
<JEEB>
anyways, the problem with figuring that out is that you have no idea what that is then mapped against in FFmpeg since you need the FFmpeg pix_fmt for that
<JEEB>
lol
<Bombo>
hmm
<JEEB>
with current master I only see 2 references to RG1616
<JEEB>
in the vaapi hwcontext
<JEEB>
and the vulkan one
navi has joined #ffmpeg
<Bombo>
drm_prime is a pix_fmt
<Bombo>
can i just use that?
<Bombo>
-pix_fmts says ..H.. drm_prime
ivanich has joined #ffmpeg
<JEEB>
that is the hardware format type which has nothing to do with the actual data included in that hw buffer
<JEEB>
welcome to how HW (GPU etc) formats were added to FFmpeg
<JEEB>
in order to "keep things simple", there is a single format for each HW pix_fmt
<CounterPillow>
I am extremely suspicious of the framebuffer reporting RG16. No general purpose framebuffer is going to use 2 components of 16 bits each
<JEEB>
which in your case is drm_prime
<JEEB>
CounterPillow: P010 and P012 etc apparently do?
<JEEB>
but it is indeed sus
<JEEB>
Bombo: that is why when hw formats were added
<JEEB>
you got a > sw_format
<JEEB>
which is supposed to get checked when the main pix_fmt is a HW format
<JEEB>
which describes the data layout of that frame
<JEEB>
:D
<CounterPillow>
I'd expect a P010 framebuffer to report as something like RGB10A2
<CounterPillow>
Ah, okay then it makes more "sense" though I'd have assumed they'd name it some NVsomething, but I guess no need since it already exists as RG16
<JEEB>
NV12 and NV16 etc got already used I guess
<JEEB>
so MS went with Pxyz for high bit depth foramts
<JEEB>
>8bit
<JEEB>
Bombo: it would be nice if hwdownload could be made to just by default download whatever format you have there, but right now that is not the case. simplest would probably be to patch kmsgrab to log the sw_format :D
<JEEB>
since av_hwframe_ctx_init only logs it if it's not supported by the device type etc
ZedHedTed has joined #ffmpeg
<JEEB>
also do note that you can attempt to get other formats with the kmsgrab module's "format" option
<JEEB>
I /think/ `ffmpeg -h demuxer=kmsgrab` should output it?
<Bombo>
so that rg16 is definitely not the sw_fornat?
<JEEB>
(IIRC avdevice devices show up as demuxers)
<JEEB>
Bombo: if it is, it is not under such name, check `ffmpeg -pix_fmts`
<JEEB>
in kmsgrab you have > ctx->frames->sw_format = ctx->format
<JEEB>
and around there you need to add an av_log
<CounterPillow>
p010le would be appropriate I guess if this is p010?
<Angus1234>
Hello, has anyone had problems with the configure step for FFmpeg with x265 included? I was able to complete a build with it around 6 months ago, but after taking the latest builds it no longer works
<JEEB>
nope, you will see the exact error in ffbuild/config.log under your build root
<Angus1234>
Yeah I've been wrestling with that for a few weeks now, but I'm not sure what the actual issue is. Is it possible to send a log file to this chat?
<Angus1234>
The final error line is: "ERROR: x265 not found using pkg-config" but I don't think that is the actual issue itself. I think something else is going wrong with the lib and thats just the error it reports. When I use the pkg-config check it can find that package no problem, and if I for example rename the lib file, it reports specifically not being able to find the file.
<Angus1234>
My assumption is its to do with these lines here, but I have no idea how to resolve this: test.o : error LNK2019: unresolved external symbol _x265_api_get_208 referenced in function _check_x265_api_get
<kepstin>
Angus1234: is your libx265 just too old? if the version in the pkg-config file isn't new enough, that would result in it not being found with pkg-config, and that would explain why it's not finding an api version symbol.
<Angus1234>
I pulled and built whatever the latest in bitbucket is, so it shouldn't be out of date at all
<Angus1234>
Sorry I should have specified, I'm building x265 myself, I'm not just using whatever comes with pkg-config.
<Angus1234>
Followed all the instructions that comes with that, and its worked for all previous builds I did with this about 6 months ago.
<Angus1234>
I've updated the PKG_CONFIG_PATH with the location of the install (that also includes x264 which I built), and then pkg-config is able to find and prints no errors when checking that. Its only at the configure step for FFmpeg itself that it blows up when it gets to x265
bitbinge has joined #ffmpeg
<JEEB>
pkg-config is how C project flags are provided
<JEEB>
so when you install x265 you get the pc file
<JEEB>
anyways, sounds like you are lacking linker flags?
minimal has joined #ffmpeg
<JEEB>
not sure if _x265_api_get_208 is exposed
<JEEB>
or supposed to be
<JEEB>
if it is, then if the linker cannot find it, there's something wrong
<JEEB>
sounds like some MSVC shenanigans most likely
<Angus1234>
Hmm, is there a good way to diagnose this then?
LuKaRo has joined #ffmpeg
<JEEB>
well it tells you a function is not found so the libraries you linked against do not expose that function. you should check whether x265 project is supposed to be exposing that. if yes, then time to figure out why your build does not expose it :)
<JEEB>
msvc and shared vs static seem to be fun so when figure whether it should be externally visible or not, then you need to keep in mind what sort of build of x265 you were making
<Angus1234>
I'll have a look and see if those functions are kicking about
<Angus1234>
And yes I'm building shared as I'm also looking to configure FFmpeg to shared
<JEEB>
yea basically there was a fun thing with MSVC that when building shared/static the definition for some functions needs to be different
<JEEB>
also I am not sure if the MSVS project from cmake does the install portion which puts the stuff into their final resting position under your configured prefix?
<Angus1234>
It does, if you build the INSTALL solution in the visual studio project
<JEEB>
ok
<JEEB>
anyways, I'm really sorry but MSVC specific knowledge outside of building FFmpeg itself is very limited. we have FFmpeg itself building and tested in the FATE system, but external libraries are just supposed to work with the flags you get from pkg-config (nowadays pkgconf is the preferred implementation tho)
<Angus1234>
Is there a good resource I could use to do that correctly? Where I use the pkgconf to get x265, but then still build FFmpeg as shared?
<JEEB>
as I said, pkgconf is not a package manager
<JEEB>
(or pkg-config)
<JEEB>
when you do that INSTALL solution it installs the pc file
<Angus1234>
Yup
<JEEB>
hopefully with the correct linker flags
<JEEB>
and compiler flags
<JEEB>
and in ffbuild/config.log you should then be seeing the exact compiler line, as well as the result (which currently I presume is the failure)
<JEEB>
since it will ask pkg-config/pkgconf for the flags
<JEEB>
(those are created by the project you built so they hopefully are correct - at least outside of MSVC the x265 pc file seems to work)
<Angus1234>
Unfortunately I'm not seeing a compiler line
<JEEB>
pastebin your ffbuild/config.log and link it here? :V
<Angus1234>
I can paste the x265 section from when it initially does that pkg-config check if you want? Its not long
<Angus1234>
Sure one sec. Sorry for being a hassle!
<Angus1234>
Relevant bit will be end of the 2nd half I assume, but I've included all so its all there
<JEEB>
thanks
<JEEB>
uhh
<JEEB>
one thing I will say is that disable-optimizations might be problematic with MVSC
<JEEB>
and generally for debug you do not require that
<Angus1234>
Ok
<JEEB>
also I think FFmpeg by default builds with debug symbols (`ffmpeg` vs `ffmpeg_g` in the build root), if you never want the build system to strip them then `--disable-stripping` is the option
<JEEB>
so yea, at the end of the second one you have the x265 pkg-config check
<Angus1234>
Alright thanks
<JEEB>
then you can see the results as test_ld and test_cc afterwards
<JEEB>
and that then gets finally into cl.exe and mslink calls
<JEEB>
so that is the compiler and linker
<JEEB>
compiler is mostly saying that it ignores the unknown libpath
<JEEB>
linker then warns that /IC:/.../include is unknown and ignored
<JEEB>
> x265.lib : warning LNK4272: library machine type 'x64' conflicts with target machine type 'x86'
<JEEB>
also uhh
<JEEB>
what cl and linkers do you have in PATH? :D
<JEEB>
library machine type seems correct but it kinda sounds like the stuff you've compiled and linked is 32bit
<JEEB>
as in FFmpeg
Dotz0cat_ has joined #ffmpeg
<Angus1234>
x265 should all be x64
Muimi__ has joined #ffmpeg
<Angus1234>
I made sure to select that in visual studio
Dotz0cat has quit [Ping timeout: 252 seconds]
<JEEB>
yes, which is why it says *library* machine type 'x64'
<JEEB>
then it says "conflicts with *target* "
<JEEB>
which is why I ask, what is in your PATH as cl.exe
<JEEB>
I expect that the cl.exe there is the 64bit one
Dotz0cat_ is now known as Dotz0cat
<Angus1234>
Ok, lemme check PATH
<Angus1234>
However I'm running msys2 via the 2022 developer tools command line
<JEEB>
what I mean with that, check which cl.exe pops up
<Angus1234>
and I've made sure that msys2 inherits that
<JEEB>
it sounds like where you are building FFmpeg the cl.exe is the 32bit one
<Angus1234>
alright I'll check
<JEEB>
I think for 64bit there's the separate developer tools?
<Angus1234>
There is, I may have been selecting the wrong one, just going to check now
<Angus1234>
I'll kick myself if this is it :(
<JEEB>
at least there's a clear mismatch between the library (x265) and FFmpeg build
<JEEB>
which the linker is then telling you about
<Angus1234>
Ok I've specifically ran the shell via the x64 command prompt. Running the configure step on FFmpeg now
<JEEB>
I recommend you've cleared the build root from which you called configure so there are no leftovers :) but I hope that if you never got to the end of it, there isn't too much of those :P
<Angus1234>
I didn't clear it (hardly anything there), however if it fails I'll clear it and configure again
<Angus1234>
you mentioned it after it had already started :D
<Angus1234>
Holy moly that worked. Now I get the opposite error with my x264 build, which I've clearly done as x86 instead of x64
<Angus1234>
thank you so much!
<JEEB>
np
<JEEB>
if it was something else, I would have been rather unlikely to have helped :D
<JEEB>
or well, been able to
<JEEB>
since I'm very bad with MSVC linking internals
<JEEB>
which is what such stuff tends to end poking at
<Angus1234>
Well, I say it works..... It gets to x264 first and then fails. Let me fix that and see if x265 gets through as well :D
<JEEB>
you could first disable x264 once I guess?
<JEEB>
so you can check if that works first
<Angus1234>
Ah good shout
<Angus1234>
That has worked, thank you so much
fling has quit [Ping timeout: 240 seconds]
Angus1234 has quit [Quit: Leaving]
Sciencentistguy9 has joined #ffmpeg
Sciencentistguy has quit [Ping timeout: 268 seconds]
Sciencentistguy has joined #ffmpeg
Sciencentistguy9 has quit [Ping timeout: 240 seconds]
BtbN has quit [Remote host closed the connection]
lavaball has quit [Remote host closed the connection]
jess has quit [Quit: Lost terminal]
jess has joined #ffmpeg
<Bombo>
JEEB: now i tried the line with Xorg started, got a new error ;)
<Bombo>
[kmsgrab @ 0x55b6fdf590] No handle set on framebuffer: maybe you need some additional capabilities?
<Bombo>
pipe:: Invalid argument
lavaball has joined #ffmpeg
<Bombo>
using ffmpeg -f kmsgrab -i - -vf "hwdownload,format=bgr0" output.mp4
<Bombo>
and without ,format=bgr0 it's the same
<Bombo>
someone in #raspberrypi said it's either 0bgr or rgb0 hm
<CounterPillow>
"maybe you need some additional capabilities?" reminds me that unless you fiddle around with capabilities you'll probably need to be root for kmsgrab
<JEEB>
Bombo: you can actually `-format bgr0` or the other one before input to attempt to receive that pix_fmt from kmsgrab :P
<JEEB>
since as I said, kmsgrab has a format option
<JEEB>
`ffmpeg -h demuxer=kmsgrab`
BetweenUs has joined #ffmpeg
<another|>
ar
kasper93_ has joined #ffmpeg
Sciencentistguy3 has joined #ffmpeg
Sciencentistguy has quit [Ping timeout: 252 seconds]
Sciencentistguy3 is now known as Sciencentistguy
LionEagle has quit [Quit: Leaving]
BetweenUs has quit [Quit: Leaving]
LionEagle has joined #ffmpeg
kasper93_ has quit [Remote host closed the connection]
BUSY has quit [Ping timeout: 252 seconds]
Sciencentistguy has quit [Ping timeout: 245 seconds]
rvalue has quit [Ping timeout: 276 seconds]
Sciencentistguy has joined #ffmpeg
jagannatharjun has quit [Quit: Connection closed for inactivity]
<s7m0n>
hi there, using ffmpeg from git. It seems current git has broken vaapi hw encoding - i get segfaults. Tested on another machine using latest with differen hw i also get a segfault. Reverting to a older version works again. Any hints on how to proceed (supply needed details)
<JEEB>
a default build of FFmpeg should have a debug symbol enabled binary `ffmpeg_g` in the build root. if you always want debug symbols `--disable-stripping` in the configure script enables that
<s7m0n>
i think i need to remerge it for debug and nostrip - let me try that quickly
<JEEB>
debug specifically is not required unless your distro is doing that
<JEEB>
since FFmpeg's default build config is release with debug symbols, which should be good enough for most debug
<JEEB>
I don't think I've had to yet do actual debug build (with less optimizations)
<JEEB>
and after you get symbols and make sure you have major dependencies such as libva and the VA driver with debug symbols too, then oppan gdb backtrace time
<jkqxz>
It dies on the assertion at libavfilter/avfiltergraph.c:670, which would be a segfault with assertions disabled.
<JEEB>
ahh
<jkqxz>
Something in the recent filter negotiation changes then.
<JEEB>
is that the YUVJ removal stuff?
<JEEB>
yea that's the most recent reneg stuff
<s7m0n>
oh so you already got it
<jkqxz>
Yeah, always happens immediately with vaapi encode for me as well.
<JEEB>
great
<JEEB>
(repro wise)
Haxxa has quit [Quit: Haxxa flies away.]
<s7m0n>
are you in depth and fix it or report it or should i try to get there with symbols and create an issue on the bug tracker
Haxxa has joined #ffmpeg
Marth64 has joined #ffmpeg
fling has joined #ffmpeg
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
ZedHedTed has quit [Quit: leaving]
whatsupdoc has joined #ffmpeg
BtbN has joined #ffmpeg
LuKaRo has quit [Ping timeout: 245 seconds]
epony has quit [Remote host closed the connection]
Muimi__ has quit [Quit: Going offline, see ya! (www.adiirc.com)]
LuKaRo has joined #ffmpeg
AbleBacon_ has joined #ffmpeg
AbleBacon_ has quit [Quit: I am like MacArthur; I shall return.]
epony has joined #ffmpeg
Blacker_47 has quit [Quit: Life is short. Get a V.90 modem fast!]
BillTorvalds has quit [Quit: Leaving]
s7m0n has quit [Ping timeout: 268 seconds]
rv1sr has quit []
iive has joined #ffmpeg
apteryx has joined #ffmpeg
<apteryx>
hello; is there a convenient way to download the test suite data, such as for packaging it for a distro?