BtbN 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.0 is released
xx has quit [Ping timeout: 264 seconds]
shibboleth has joined #ffmpeg
chandash has quit [Ping timeout: 252 seconds]
iive has quit [Quit: They came for me...]
Mister_Magister_ has joined #ffmpeg
Mister_Magister has quit [Ping timeout: 265 seconds]
Mister_Magister_ is now known as Mister_Magister
chandash has joined #ffmpeg
\\Mr_C\\ has joined #ffmpeg
wziko has joined #ffmpeg
wziko has quit [Ping timeout: 265 seconds]
chandash has quit [Ping timeout: 252 seconds]
Marth64 has quit [Quit: Leaving]
chandash has joined #ffmpeg
chandash has quit [Ping timeout: 265 seconds]
Kruppt has quit [Quit: Leaving]
Tano has joined #ffmpeg
lavaball has quit [Remote host closed the connection]
chandash has joined #ffmpeg
shibboleth has quit [Quit: shibboleth]
chandash has quit [Ping timeout: 260 seconds]
Lynne has quit [Remote host closed the connection]
<TCH>
libx264-dev is installed, --pkg-config-flags="--static" --enable-pthreads --extra-libs="-lpthread" are passed to ./configure and yet: "ERROR: x264 not found using pkg-config"
<TCH>
and /usr/lib/x86_64-linux-gnu/pkgconfig/x264.pc is in place
neilt has joined #ffmpeg
<TCH>
i had tried 5.1.6, 7.0.2 and 7.1; all of them gives this error message
<TCH>
any ideas?
<another|>
pkg-config is there?
<TCH>
where?
<TCH>
the x264.pc?
<TCH>
it is at /usr/lib/x86_64-linux-gnu/pkgconfig/x264.pc
wziko has joined #ffmpeg
<another|>
I mean the executable
<TCH>
"/usr/bin/pkg-config"
<TCH>
it is there
wziko has quit [Ping timeout: 246 seconds]
<TCH>
without --enable-x264, it compiles all ok
<another|>
hmm.. maybe some version mismatch?
<TCH>
even --enable-x265 worked
<TCH>
for all ffmpeg versions?
<TCH>
5.1.6 should work with x264 160 what i have
<TCH>
the resulting binary have some problems
<TCH>
ffmpeg: error while loading shared libraries: libavdevice.so.61: cannot open shared object file: No such file or directory
<TCH>
wtf
<TCH>
if the required libavdevice is not available, then how did it compile?
<TCH>
if it is, then why can not it find it?
<another|>
no idea, sorry
<aaabbb>
TCH: might be a bit overkill but when that happens, i usually get onto a gentoo system and compile it there and compare how it does it to how i am doing it
<TCH>
i do not have a gentoo system
<aaabbb>
hence why overkill since installing a whole distro in a vm :p
<aaabbb>
but it has saved my ass when having compilation issues
<TCH>
i believe it, but i have neither the time, nor the space to set up a gentoo and assemble the entire environment in it
<TCH>
ffmpeg 5.1.6 built without x264 and seems to be working
<TCH>
7.1 does not work
<TCH>
despite succesfully building, it does not find libavdevice
<TCH>
well, whatever, with the new options, 5.1.6 supports vorbis now
<TCH>
so vorbis was a bad example, because that did not worked until now with the old non-default config either, but i don't remember what did not worked with the default config, it was too long ago
<TCH>
i hope disabling x264 will not cause a lot of videos to not work...
<TCH>
thanks, the help
<TCH>
bye all
TCH has quit [Quit: FEAR BILL GATES]
stolen has joined #ffmpeg
StephenLynx has quit [Remote host closed the connection]
SupUser has quit [Ping timeout: 244 seconds]
Jiggy has quit [Quit: Greenout]
Jiggy has joined #ffmpeg
billchenchina has joined #ffmpeg
billchenchina has quit [Ping timeout: 252 seconds]
intrac has quit [Ping timeout: 252 seconds]
intrac has joined #ffmpeg
manwithluck has quit [Ping timeout: 244 seconds]
coldfeet has joined #ffmpeg
manwithluck has joined #ffmpeg
manwithluck has quit [Read error: Connection reset by peer]
lusciouslover has quit [Ping timeout: 252 seconds]
manwithluck has joined #ffmpeg
stolen has quit [Quit: Connection closed for inactivity]
wziko has joined #ffmpeg
bencoh has quit [Ping timeout: 244 seconds]
bencoh has joined #ffmpeg
fairway has joined #ffmpeg
<fairway>
everybody ffmpeg is refusing to fix this huge bug
<aaabbb>
what bug?
* galad
inserts the "oh shit, here we go again" meme
<fairway>
aaabbb ffprobe.exe latest version is showing 30fps as 60fps
<fairway>
old version did NOT do this
<furq>
where's the bug report
<fairway>
furq what do you think about this major bug
alexherbo2 has quit [Remote host closed the connection]
CruxOfTheB has joined #ffmpeg
CruxOfTheB has quit [Remote host closed the connection]
CruxOfTheB has joined #ffmpeg
CruxOfTheB has quit [Ping timeout: 264 seconds]
CruxOfTheB has joined #ffmpeg
YuGiOhJCJ has joined #ffmpeg
javabean has quit [Ping timeout: 272 seconds]
CruxOfTheB has quit [Ping timeout: 264 seconds]
guemax has joined #ffmpeg
<guemax>
Hello! I am trying to convert a bunch of images to a video using "ffmpeg -framerate 24 -i image-%04d.jpg video.mp4", however ffmpeg only shows that every third image is being processed (1, 4, 7, 10, ...). Do I have to worry about that?
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
<CounterPillow>
furq what do you think about this major bug
<fairway>
jeeb that's not same as testing yourself though with multiple players that you have on your computer
<another|>
fairway: I don't that's silly. Do you have actual reason to believe that what it reports is wrong?
<Marth64>
I didn't ask about what VLC said. I asked what Windows says. Its the reference stack for this format
<fairway>
another| because it's 30 fps file
<another|>
And?
<JEEB>
basically if you don't understand why I'm telling this, it's because then we see what the values are that are part of what might get utilized for whatever calculation
<another|>
fps != timebase
<fairway>
marth64, i don't know how to check fps in Windowsmediaplayyer
<JEEB>
technically avformat probably utilizes the packets, but might as well do the full monty
<another|>
If you cannot understand or accept that, then this discussion is moot.
<fairway>
another| then why is version 5.x or lower showing as 30 tbr
<fairway>
you cannot answer that
<JEEB>
in other words I'm not interested in saying what is wrong and what is correct, I'm recommending checking what the underlying data is. if you don't trust FFmpeg with that, then have fun finding a nice analyzer for the ASF format (like boxdumper or atomicparsley for MP4, or DVBInspector for MPEG-TS)
<another|>
fairway: I already did. Probably a bug.
<fairway>
another| already did what
<another|>
I already answered that.
<another|>
<another|> If 5.0 reported something different, then I assume it was a bug that was fixed.
<minimal>
fps and tbr are calculated in 2 completely different ways...
<fairway>
Stream #0:1: Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 480x320, 500 kb/s, 15 tbr, 1k tbn , why is it showing 15 TBR for this file this file is 15 fps
<fairway>
you saying fps and tbr is not same yet it acts like it's same for 15 fps wmv file
<minimal>
fairway: you've repeatedly been told that fps and tbr are NOT the same thing
<JEEB>
because whatever it bases the logic on happens to set that value is the answer to the question
<fairway>
then explain why it's showing correctly for this file
<JEEB>
ohhh
<JEEB>
if you look at the last packets
<JEEB>
also the show_frames that was posted
<another|>
fairway: what is shown correctly?
<JEEB>
there are shorter frames there at the end :P
olndrxyz has quit [Read error: Connection reset by peer]
<minimal>
fairway: showing WHAT correctly? tbr is NOT fps, tbr is tbr, just because something they have the same value doesn't mean they are the same thing
<JEEB>
that is your answer, whatever encoded that did variable frame rate indeed
<redeeman>
mediainfo says the file is "origianl frame rate 15"
olndrxyz has joined #ffmpeg
<JEEB>
both 30 and 60 fit 60
<Marth64>
JEEB: hah. nice find
<Marth64>
I strongly assumed it was VFR that proves it
<JEEB>
alternatively the writer of this file messed up and set a funky duration flag for some packets
<fairway>
there are 15527 lines that txt log, just tell me the line #
<redeeman>
very last entry
<redeeman>
scroll to bottom of file
<Marth64>
we are not a concierge service. you can search and see
<JEEB>
it starts not too far into the file tbh
<JEEB>
there are 551 matches and each of them means that the file contained info that the duration of that frame should be 16ms
<JEEB>
or well, probably that packet (which contains a frame)
<JEEB>
and yea, looking at the packets, there are essentially gaps in the time line. since those packets have +33ms timestamps, but then mark duration of themselves as 16ms
<Marth64>
can I ask what software or hardware is encoding and muxing this file?
<JEEB>
and since r_frame_rate is calculated over N amount of packets for a stream, you are getting the common denominator between the durations
<JEEB>
Marth64: some random "free video editor" looking at the metadata
<fairway>
i've seen this issue with other 1080p wmv files too (not just from clipchamp)
<Marth64>
maybe they share an underlying encoder in common
<Marth64>
and don't do 1080p right for this format
<fairway>
martha64 maybe
<Marth64>
i would look at the encoder perspective too
wziko has joined #ffmpeg
wziko has quit [Max SendQ exceeded]
<JEEB>
and the difference between versions most likely is that nowadays FFmpeg takes the packet's recorded duration into account more
<JEEB>
since when you do not have a packet duration written in the input, of course the duration is the dts difference in packets
<JEEB>
but if you explicitly have in a packet a duration mentioned
<Marth64>
funny thought... is ffmpeg the encoder?
<Marth64>
might try later
<another|>
Marth64: ffmpeg does not have a vc1 encoder
<JEEB>
it says mediafoundation in the metadata so the Windows encoder was utilized
<Marth64>
got it
<JEEB>
or at least it highly hints at that
<Marth64>
ok ill check it with windows media player in a vm later if it says anything useful
<JEEB>
ASF and packet durations seem like a fun thing looking at libavformat/asfdec_f, so if someone really cares they could attempt to check why that duration suddenly appears after... quite a few packets/frames.
rv1sr has joined #ffmpeg
rex has quit [Read error: Connection reset by peer]
rex has joined #ffmpeg
<fairway>
another| does ffmpeg have wma encoder then
<JEEB>
for wmav1 and wmav2, yes... one does not want to utilize those formats
jemius has quit [Quit: Leaving]
<fairway>
ffmpeg -i sample.wmv sample.mp4 creates a 60 fps .mp4 file so it's not even just ffprobe bug, it's ffmpeg bug tooo
<JEEB>
ffprobe itself has very little logic, it generally just exposes what avformat/avcodec expose :P
<JEEB>
and unsurprising that if you have packets marked as 60fps duration-wise that the command line application will take it into account.
<fairway>
actually wait, it doesn't, nevermind what i said
<JEEB>
because the input had packets which are flagged 60fps, and then it depends on how far it reads for the average
<JEEB>
the ffprobe packet/frame output shows you how the libraries read the data from the input, and then in ffmpeg the tool the components just get plugged together. so if you have something in the input, then most likely that gets passed to the output
<fairway>
then shouldn't ffprobe sample.wmv also show as 30.02 fps
fling has quit [Remote host closed the connection]
fling has joined #ffmpeg
<JEEB>
no
<JEEB>
since exact logic of trying to get those values depends on the amount of reading and checking the input format requires
<JEEB>
so whiel container X might require you to read some amount of packets, container Y might not due to information being somewhere easily readable in the structure or so
JanC has quit [Ping timeout: 260 seconds]
JanC has joined #ffmpeg
<JEEB>
so it's all due to how nowadays duration is exposed for some packets out of the input ASF file. and any effects you see further down the line is due to that.
CruxOfTheB has quit [Remote host closed the connection]