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
CarlFK has joined #ffmpeg
lemoniter has quit [Ping timeout: 265 seconds]
sentriz has quit [Ping timeout: 252 seconds]
FlorianBad has quit [Quit: Konversation terminated!]
theracermaster has quit [Ping timeout: 245 seconds]
sugoi has quit [Ping timeout: 248 seconds]
waleee has quit [Ping timeout: 246 seconds]
Traneptora has joined #ffmpeg
xx has quit [Ping timeout: 260 seconds]
Suchiman has quit [Quit: Connection closed for inactivity]
yans has joined #ffmpeg
lusciouslover has quit [Read error: Connection reset by peer]
lusciouslover has joined #ffmpeg
theracermaster has joined #ffmpeg
minimal has quit [Quit: Leaving]
yans has quit [Ping timeout: 246 seconds]
Tinos has joined #ffmpeg
theracermaster has quit [Ping timeout: 246 seconds]
theracermaster has joined #ffmpeg
jarrhed has quit [Ping timeout: 260 seconds]
jarrhed has joined #ffmpeg
lucasta has joined #ffmpeg
Tinos has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
psykose has joined #ffmpeg
CarlFK has quit [Ping timeout: 260 seconds]
FlorianBad has joined #ffmpeg
robobub has joined #ffmpeg
SystemError has quit [Remote host closed the connection]
lucasta has quit [Remote host closed the connection]
SystemError has joined #ffmpeg
sugoi has joined #ffmpeg
Seamus has joined #ffmpeg
sugoi has quit [Ping timeout: 244 seconds]
Seamus has quit [Client Quit]
SystemError has quit [Remote host closed the connection]
SystemError has joined #ffmpeg
sugoi has joined #ffmpeg
sugoi has quit [Ping timeout: 248 seconds]
jagannatharjun has joined #ffmpeg
Tinos has joined #ffmpeg
rv1sr has joined #ffmpeg
realies has quit [Quit: Ping timeout (120 seconds)]
lavaball has quit [Remote host closed the connection]
lavaball has joined #ffmpeg
txtsd has quit [Remote host closed the connection]
lemoniter has joined #ffmpeg
emanuele6 has quit [Ping timeout: 244 seconds]
fling has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
emanuele6 has joined #ffmpeg
alexherbo2 has joined #ffmpeg
txtsd has joined #ffmpeg
vlm has joined #ffmpeg
TinosNitso has quit [Ping timeout: 256 seconds]
sentriz has joined #ffmpeg
Tinos has quit [Ping timeout: 256 seconds]
vlm has quit [Quit: Leaving]
Tinos has joined #ffmpeg
Blacker47 has joined #ffmpeg
SystemError has quit [Remote host closed the connection]
rsx has joined #ffmpeg
vlm has joined #ffmpeg
five61848033918 has joined #ffmpeg
five6184803391 has quit [Ping timeout: 276 seconds]
five61848033918 is now known as five6184803391
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
vlm has quit [Quit: Leaving]
Tinos has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
Tinos has quit [Remote host closed the connection]
lavaball has quit [Remote host closed the connection]
Tinos has joined #ffmpeg
Tinos has quit [Remote host closed the connection]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
Teraii has quit [Ping timeout: 260 seconds]
yans has quit [Ping timeout: 276 seconds]
Teraii has joined #ffmpeg
txtsd has quit [Read error: Connection reset by peer]
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
txtsd has joined #ffmpeg
txtsd has quit [Read error: Connection reset by peer]
gioyik has joined #ffmpeg
txtsd has joined #ffmpeg
Akosmo has quit [Quit: Client closed]
lordmzte95 has joined #ffmpeg
ewomer has joined #ffmpeg
<lordmzte95>
Hello! I'm using the ffmpeg CLI for transcoding a webm (audio only) file to .mp3 using the command `ffmpeg -i x.webm x.mp3`. This works, but is quite slow for some reason, only reaching about 48x speed. Notable, I cannot quite figure out what the limiting factor for ffmpeg's speed is here. The ffmpeg process is not even remotely using a whole CPU
<lordmzte95>
core, neither is the disk at its IO limit. What's preventing ffmpeg from going faster here?
Buliarous has quit [Remote host closed the connection]
gioyik has quit [Ping timeout: 260 seconds]
mven979 has joined #ffmpeg
mven97 has quit [Ping timeout: 252 seconds]
mven979 is now known as mven97
<ewomer>
How do I use hawaccel (cuda) with the double pass method on this page https://developers.google.com/media/vp9/settings/vod to convert from mp4(x264) to webm (vp9) I keep getting this message >> Impossible to convert between the formats supported by the filter 'Parsed_null_0' and the filter 'auto_scale_0' << using this line >> ffmpeg -y -hwaccel cuda -hwaccel_output_format cuda -i
Teraii has quit [Read error: Connection reset by peer]
Teraii_ has joined #ffmpeg
vlm__ has joined #ffmpeg
vlm__ has quit [Remote host closed the connection]
Teraii_ is now known as Teraii
gioyik has joined #ffmpeg
vlm__ has joined #ffmpeg
vlm__ is now known as vlm
vlm has quit [Client Quit]
gioyik has quit [Ping timeout: 260 seconds]
lexano has joined #ffmpeg
gioyik has joined #ffmpeg
gioyik has quit [Ping timeout: 260 seconds]
gioyik has joined #ffmpeg
lucasta has joined #ffmpeg
gioyik has quit [Ping timeout: 260 seconds]
sugoi has joined #ffmpeg
vlm has joined #ffmpeg
<tykling>
intrac: ok so I still don't have this working as smooth as I want, even on a modern laptop, but quite a few hours of digging at least taught me a lot about all of this and I think I am beginning to understand that the issue is the rawvideo served from this camera, where yours works great because it is compressed to mjpeg
<tykling>
I have a couple of other regular webcams in a laptop and an external one and both work great and are very responsive even at high resolutions with the overlay
<tykling>
but as soon as I go for the microscope camera which only does rawvideo everything slows to a crawl.. I can get 5 fps at 1920x1080 with maybe 0.5-1 second delay
<furq>
are the other cameras usb3
sugoi has quit [Ping timeout: 260 seconds]
<tykling>
the one with the issue is usb3 and connected to an usb3 port and works great with ffplay directly, but as soon as I add a picture overlay it becomes very slow
vlm has quit [Quit: Leaving]
<tykling>
I dont know what usb version the other cameras are, but since they can deliver a compressed output the amount of data is much smaller I guess, and ffmpeg can smoothly do the overlay at high resolution and framerate with no issues
rsx has quit [Quit: rsx]
gioyik has joined #ffmpeg
<tykling>
I am not sure what to do from here, maybe see if I can replace the camera in the microscope somehow, or live with the low fps and delay. I promised intrac to get back with the results and I leaned a lot which is always nice :d
<tykling>
:D even
<furq>
that sounds strange
<furq>
especially if it has the same issue on a modern laptop
elvis_a_presley has quit [Ping timeout: 248 seconds]
gioyik has quit [Ping timeout: 260 seconds]
vlm has joined #ffmpeg
elvis_a_presley has joined #ffmpeg
lordmzte95 has quit [Quit: Client closed]
txtsd has quit [Read error: Connection reset by peer]
vlm has quit [Quit: vlm]
minimal has joined #ffmpeg
Haxxa has quit [Ping timeout: 246 seconds]
txtsd has joined #ffmpeg
elvis_a_presley has quit [Ping timeout: 246 seconds]
Haxxa has joined #ffmpeg
gioyik has joined #ffmpeg
SystemError has joined #ffmpeg
cxc has quit [Quit: Client shutdown]
gioyik has quit [Ping timeout: 260 seconds]
<tykling>
it is strange
gioyik has joined #ffmpeg
Akosmo has joined #ffmpeg
gioyik has quit [Ping timeout: 260 seconds]
Akosmo has quit [Client Quit]
Akosmo has joined #ffmpeg
lavaball has joined #ffmpeg
gioyik has joined #ffmpeg
vlm has joined #ffmpeg
gioyik has quit [Ping timeout: 260 seconds]
shibboleth has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
gioyik has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
vlm_ has joined #ffmpeg
gioyik has quit [Ping timeout: 260 seconds]
dbal has quit [Ping timeout: 244 seconds]
vlm has quit [Quit: vlm]
vlm has joined #ffmpeg
vlm_ has quit [Quit: Leaving]
elvis_a_presley has joined #ffmpeg
shibboleth has quit [Quit: shibboleth]
gioyik has joined #ffmpeg
elvis_a_presley has quit [Quit: smoke-bomb ; grapple-hook]
elvis_a_presley has joined #ffmpeg
elvis_a_presley has quit [Client Quit]
elvis_a_presley has joined #ffmpeg
elvis_a_presley has quit [Client Quit]
elvis_a_presley has joined #ffmpeg
EmleyMoor has quit [Ping timeout: 260 seconds]
ewomer has quit [Quit: WeeChat 4.4.1]
vlm has quit [Quit: vlm]
alexherbo2 has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
Traneptora_ has quit [Quit: Quit]
Traneptora has joined #ffmpeg
lemourin has quit [Read error: Connection reset by peer]
lemourin has joined #ffmpeg
llyyr has quit [Quit: Quit]
FlorianBad has quit [Remote host closed the connection]
llyyr has joined #ffmpeg
FlorianBad has joined #ffmpeg
ewomer has joined #ffmpeg
bitblit has quit [Quit: WeeChat 3.5]
alexherbo2 has joined #ffmpeg
alexherbo2 has quit [Remote host closed the connection]
alexherbo2 has joined #ffmpeg
<intrac_>
tykling: Did you try in 8 bit mode?
<intrac_>
I noticed the camera does various colour formats, eg RGB, YUV, etc
<tykling>
yes, and it helps a bit, but I still have to go very low in resolution to make it work, and over time it gets a bigger and bigger delay
<intrac_>
That's strange
<tykling>
right now it is more than 1 minute delayed, I put a clock under it
<furq>
if it works fine without overlaying then you have some other weird issue
<furq>
maybe run with -v verbose
<intrac_>
You might want to use the v4l utilities to check what the camera can do
<tykling>
I can pastebin a bit of the relevant info, maybe I am missing something obvious
<intrac_>
This might be as simple as an error with specifying the frame rate
<intrac_>
Note that when you control a camera with v4l, it's common for it to choose the nearest available option if you try and set something that it can't do. Rather than throw an error.
<furq>
if it works without the overlay then it presumably isn't a v4l issue
<furq>
or anything on the input side
<intrac_>
I wonder if ffmpeg filters might be much slower if this is an unusual colour format
<furq>
it shouldn't make that much difference
<furq>
and yuy2 isn't really unusual
<intrac_>
Otherwise, the difference between YUV, mjpeg, h264 should really only be relevant for the transmission from the camera over USB. As once it's received by ffmpeg it's decoded to uncompressed in all cases
<furq>
right
<intrac_>
What is CPU use when this setup is running?
<intrac_>
I'm away from my main computer. Will try to look at any example parameters later
EmleyMoor has joined #ffmpeg
iconoclasthero has joined #ffmpeg
iconoclasthero is now known as iconoclast_hero
<another|>
ewomer: hwdownload
iconoclast_hero is now known as iconoclasthero_
iconoclasthero_ is now known as iconoclast_hero
iconoclast_hero is now known as iconoclasthero_
iconoclasthero_ is now known as iconoclasthero
<tykling>
ok here are the camera formats and info for the microscope camera (which only does rawvideo): https://dpaste.com/CASH3JUPU the only resolutions I can get are the default 2592x1944 and then 1920x1080 and 640x480. I have tried "-input_format bayer_grbg8" instead of the default yuyv422 which helped some. I have to go eat dinner but I will be back with a bunch more info in an hour or so! :)
<tykling>
btw I have a "Intel(R) Core(TM) i7-4710MQ CPU @ 2.50GHz" cpu but it doesn't seem to be fully utilized even when it doesn't run well
<tykling>
bbl!
vincejv has joined #ffmpeg
gioyik has quit [Quit: WeeChat 4.4.1]
<delthas>
Hi, I'm using ffmpeg to capture my microphone audio, encode it as Opus, and send it to me (eg locally over TCP).
<delthas>
I'd like to vary the volume of the capture over time, specifically to mute the audio when I need to (I can't do it myself after it is encoded to Opus).
<delthas>
Searching the web I found that a way to do this would be to use the azmq filter to vary the volume of a volume filter
<delthas>
-> But this isn't ideal because ZeroMQ doesnt appear to be commonly built in in ffmpeg builds in mainstream distributions, and this requires my program to link against zeromq, too, which isn't small (speficially i'd like to this from Go and there is no maintained pure go zeromq impl)
<delthas>
would there be some other way to control a ffmpeg filter over time (when pulling from a realtime source)?
<BtbN>
Can just send commands via keyboard if you like
<BtbN>
but to script it, zmq is much nicer
<delthas>
technically i could run one ffmpeg to capure the audio, send it to my go program, multiply each sample by my volume, then send it to another ffmpeg thats there just to encode to opus but that sounds kinda hacky
<delthas>
BtbN: like just sending commands by text over stdin?
<BtbN>
by keyboard on the tty
<delthas>
oh that sounds like it could really help. i'll look into it. thanks!
<BtbN>
But why would you not be able to just link libzmq?
sugoi has joined #ffmpeg
Akosmo has quit [Quit: Client closed]
<delthas>
i'd like to add audio call support to my Go program, but this is a small experimental feature. i'm currently not linkin against any C library so i'd like to avoid adding dependencies just for this feature. i'm trying to see if i can do audio calls with just pure Go and exec calls, so no C bindings
sugoi has quit [Ping timeout: 248 seconds]
<delthas>
also zeromq not being included in the default ffmpeg build in eg archlinux makes it more difficult to use. i dont want to ask my users to recompile ffmpeg with that option.
<delthas>
hmm apparently debian does include --enable-libzmq, interesting. maybe i could ask archlinux to add that to their ffmpeg build
lucasta has quit [Remote host closed the connection]
olspookishmagus has joined #ffmpeg
<olspookishmagus>
hello, is there a way to have N operations done on MP3 files without having to re-encode N times? what I do is actually convert from stereo to mono, and then re-encode to CBR
<DHE>
if each version is different, then N re-encodes are necessary. but stereo->mono and conversion to CBR as a single output only requires 1 conversion
<DHE>
as opposed to making 2 MP3s: both CBR, but one is stereo and one is mono. or something like that
<olspookishmagus>
DHE: an example of this done in one go?
<BtbN>
I'm not entirely sure if they're propagated as exit codes
<NoImNotNineVolt>
and indeed, i've been searching the web and unable to find anything else on the topic.
<BtbN>
What is the actual issue you're trying to solve? ffmpeg should always write a readable error to stdout when failing
<NoImNotNineVolt>
i'm using other software which uses ffmpeg under the hood. it bails on its higher level operations on non-zero return codes from ffmpeg.
<BtbN>
well, if that software does not forward the error output, that's virtually impossible to debug
<NoImNotNineVolt>
specifically i'm doing fast seek on video files that are missing keyframes at the start (e.g. recorded live streams)
<NoImNotNineVolt>
and so ffmpeg complains on stdout or stderr, but still generates the requested output file.
<NoImNotNineVolt>
but it returns a nonzero code.
<NoImNotNineVolt>
causing this third party softwre to abandon the higher level operation, despite ffmpeg having handled the malformed input successfully.
<NoImNotNineVolt>
i'm addressing this now by just wrapping calls to ffmpeg in a bash script that swallows return code 69.
<NoImNotNineVolt>
i just wanted to know what i'm breaking by doing this. like, what other conditions might cause an error 69.
<NoImNotNineVolt>
e.g. inputs that are completely broken, rather than merely missing a keyframe at the start, and which therefore don't produce any output files, are those also just going to return an error 69 (which would now be swallowed by my wrapper)?
<NoImNotNineVolt>
(i'm assuming that when needed keyframes are missing, ffmpeg falls back to slow seek, which is why the errors are not fatal? https://trac.ffmpeg.org/wiki/Seeking doesn't go into any detail regarding error handling, etc.)
<BtbN>
if ffmpeg exits with an error code, it was not successful
psykose has quit [Remote host closed the connection]
TheSilentLink has quit [Ping timeout: 252 seconds]
TheSilentLink has joined #ffmpeg
<tykling>
intrac_: So these are with regular loglevel for now: https://dpaste.com/G6JQTDMKK I would love to get the delay down to less than 1 second for the full resolution. the lower resolutions are not really usable, because the camera doesn't scale down to the lower res, it cuts off part of the picture, so it is no longer a picture around the center of the microscope bed so that wont work.
alexherbo2 has quit [Remote host closed the connection]
<tykling>
I think the conclusion for today is that 2592x1944 in rawvideo is a lot of pixels to handle. I will sleep on it and check back tomorrow with a fresh mind. I learned a lot about ffmpeg today, and learned to seperate some concepts that have previously been very muddled together for me. So that is nice :)
<tykling>
a few questions at the top of my mind, why is the 8bit slower than yuyv422, and why is there a delay when there is cpu free, I would think cpu would be at 100%. But I might be thinking about it wrong
<sugoi>
Is there any reason not to add a timestamp options to ffplay or command to toggle an overlay? Might be nice or bloat and just use vlc
<NoImNotNineVolt>
BtbN: that's not my experience.
<BtbN>
Just cause the file exists does not mean it's intact
<NoImNotNineVolt>
oh but it is.
<BtbN>
it'll almost always create an output fike, but if it gets forcefully interrupted before cleanly finishing, the exit code will be negative
<NoImNotNineVolt>
e.g. i'm trying to export an image from a video after seeking to a specific point. output file looks fine, exit code is 69.
<NoImNotNineVolt>
let me see if i can provide a minimal test case with which i can demonstrate this.
sihloo has joined #ffmpeg
Blacker47 has quit [Quit: Life is short. Get a V.90 modem fast!]
emanuele6 has quit [Ping timeout: 252 seconds]
Dagger has quit [Ping timeout: 244 seconds]
emanuele6 has joined #ffmpeg
jprjr has joined #ffmpeg
Haxxa has quit [Quit: Haxxa flies away.]
Haxxa has joined #ffmpeg
Dagger has joined #ffmpeg
rv1sr has quit []
vlm has quit [Quit: Leaving]
jemius has joined #ffmpeg
jagannatharjun has quit [Quit: Connection closed for inactivity]
Rue has quit [Ping timeout: 272 seconds]
Rue_ has joined #ffmpeg
dostoyevsky2 has joined #ffmpeg
<intrac>
tykling: ok. I can't think what might cause the slowdown, but if I think of anything I'll post it here.
<Kaybi__2>
The segment generated is not the same that the upper command generated (duration is 3s vs 0.1s) as if my keyframe was not being used..
<Kaybi__2>
So the question is: How can I create a single segment using the exact same keyframes that ffmpeg is using when generating the whole playlist?
<Kaybi__2>
Hope this is clear enough and that someone will be kind enough to help me out, thanks for reading!
<intrac_>
Kaybi__2: your last ffmpeg example has a time range of about 3 seconds (between the -ss and -to), so getting a clip of that length on the output makes sense
<intrac_>
Why didn't you set the -to value to the -ss value+one frame?
<intrac_>
Alternatively, I think there's a filter to only pass through keyframes, so perhaps you could also use that to ensure only keyframes are passed to the output
<Kaybi__2>
Yes the 3s is the expected value but I'm getting 0.1s whith the last command
<Kaybi__2>
(thanks for answering me) "Why didn't you set the -to value to the -ss value+one frame?" is this what I should be doing?
<Kaybi__2>
I thought I only had to give pts of two keyframes to generate a clean segment
<intrac_>
So to clarify; you don't just want to extract the key frames, you want a set of segments each starting on a key frame but also including the other frame types until the next key frame?
<Kaybi__2>
Exactly yes
<intrac_>
So basically split the input video into its GOPs (group of pictures)
<intrac_>
Hm, not sure about that
<Kaybi__2>
I want to produce the same segments that this command produces:
<Kaybi__2>
Even the 'good' segment is weird tho because the pts_time of the keyframe is not aligned with the one extracted from a ffprobe on the original file..
<intrac>
in future, you should use a code pasting site rather than direct to the channel
<intrac>
I'll see if I can reproduce this
<Kaybi__2>
Yes sorry
jtgd has quit [Quit: WeeChat 4.4.1]
jtgd has joined #ffmpeg
<intrac>
Kaybi__2: one thing to try; the position of -ss matters. (from memory) if you put -ss before the -i then it is interpreted differently to after the input filename
<Kaybi__2>
yes after asking gpt, claude, etc I tried this and it sadly produces the same output ;(
<intrac>
I can reproduce your issue with your command, but if I put the -ss before the -i, then I get a chunk out of about the correct duration
<intrac>
the time given by ffprobe isn't *quite* the same as the I-frame index list, but I don't know if that's some rounding issue
<intrac>
but I get a chunk out, rather than a single frame
<Kaybi__2>
by putting -ss before -i I get a whole lot more frames (like you) but I also get many keyframes instead of only one
<Kaybi__2>
and the segment has a duration of 19s instead of the 3s expected
<intrac>
could it be that the audio track has it's own frames and ffmpeg is splitting at the nearest audio frame (which in your case might be larger chunks than the video, or at least aligned differently)?
<Kaybi__2>
by putting both -ss and -to before -i I get a file slightly better (from 19s to 6s) but still not 3s and with many keyframes
<intrac>
try only processing the video and exclude the video as a test (see above)
<intrac>
what is the audio format in your case?
<Kaybi__2>
excluding the audio gives the same output (6s for the latest command)
<Kaybi__2>
it is eac3
lemoniter has quit [Ping timeout: 265 seconds]
<intrac>
hm, then it seems like the maximum frame size for eac3 at 48000Hz is 32ms, so that wouldn't account for the extra duration you're getting
<intrac>
what is the video codec?
<Kaybi__2>
you're full of knowledge aha, I'm new to ffmpeg and this is harsh '=D
<Kaybi__2>
video codec is hevc
<intrac>
:)
<intrac>
it's all good
<intrac>
I'm not at all familiar with hevc
<intrac>
my tests are with the older h264
<intrac>
I wonder if that would account for the difference
<Kaybi__2>
well I can reproduce with a h264 file with aac audio
<intrac>
in my case, I always get something which is a consistent duration and always 10ms longer than I specify. I'm not sure why :'
<intrac>
:/
<intrac>
eg, if I put -ss 0.000000 -to 11.700000 (which is the duration of 4 keyframes)
<intrac>
the output is reported by ffprobe as: Duration: 00:00:11.80
<Kaybi__2>
yes I get that weird thing too, the ffmpeg command reports a duration completely different from the file
<intrac>
well, in my case the duration given by ffprobe and the actual file look consistent
<intrac>
only that it's always 10ms longer than I specify with -ss and -to
<Kaybi__2>
oh I take back what I said, on my h264 file by putting -ss and -to before -i, I get a good segment looking like the one from my playlist command
<intrac>
put I can play it with ffplay and it plays ok and the output appears to be the correct length
<intrac>
oh ok
CAT_S has quit [Ping timeout: 244 seconds]
<intrac>
if you've been experimenting with several clips, check the obvious, like the i frame list you're using isn't from an earlier test on a different file, etc
<intrac>
just thought I'd mention it, as it's the sort of thing I've done in the past
<Kaybi__2>
on my h264 file it's weird though, first two keyframes are 0.000000,K__ and 1.958333,K__.
<Kaybi__2>
In my first segment, the keyframe starts at 1.400000,K__, X)
<Kaybi__2>
Maybe this is expected but since I'm a noobie I was expecting my first segment to start with 0.000000,K__
<intrac>
Kaybi__2: sometimes the video/audio aren't aligned (especially if this is taken from a broadcast stream like digital satellite, cable etc, as in broadcast the video/audio might be handled with different physical encoders and be offset)
<intrac>
there is metadata to make sure things are aligned correctly on playback, but the actual raw streams might not be
<intrac>
so I think it's sometimes possible for the video/audio in a file to not always start at '0.0'
<intrac>
but I'm speculating a bit
<Kaybi__2>
Ok I understand
<intrac>
is this something that you have encoded yourself (from a sequence of still images) or got from another source?
<Kaybi__2>
It's basically a movie file
<Kaybi__2>
Can I explain you my use case so maybe you can tell me if it seems doable or not?
<intrac>
sure
<Kaybi__2>
Thanks! I'm developping a media server and I'm working on a transcoder. I'm giving the possibilities to stream raw file (if player have codecs), hls stream with remuxing, hls stream with transcoding
<Kaybi__2>
The prupose of keeping control on segments was to safely move from and to hls streams
<Kaybi__2>
For instance while transcoding this is quiet easy since we can write our own keyframes
<intrac>
do you particularly want to design this part of the server yourself? aren't there off the shelf solutions that can do this? (stream the original quality, if supported or a lower quality transcode on the fly)?
<Kaybi__2>
I didn't find anything doing that :x
<intrac>
I *thought* media servers like PLEX could do this
<intrac>
but I'm really not sure. just a vague memory
<Kaybi__2>
Plex is indeed doing something like this (using ffmpeg)
<Kaybi__2>
but Plex isn't FOSS and isn't good at all for privacy which is why I decided to create my own
<intrac>
"Media that is incompatible with your device will be transcoded to a playable format. The process is automatic and you don’t need to worry about specific details. However, there are some things that happen during transcoding that deserve your consideration."
<intrac>
aah ok
<Kaybi__2>
and since I can't just generate all segments before playing, I need to be able to generate them on demand
<intrac>
designing a media server is low level stuff
<Kaybi__2>
my take on this was to extract keyframes on file indexing, compute segments -ss and -to and generate the index.m3u8 programatically
<intrac>
I'm not sure why the hevc is not working
<Kaybi__2>
you gave me good progress on h264 though so I'm super happy ahaha
<Kaybi__2>
understanding how ffmpeg generates segments on the playlist command must be the way I suppose, I'll try and dig into the code =D
Sciencentistguy has quit [Ping timeout: 245 seconds]
<intrac>
someone else here might have some insight into the alignment issues
<intrac>
do you have the mediainfo utility/program? it can be useful as another way to verify metadata and the specifics of a file
<Kaybi__2>
no I do not have it and some friends told me that it was a bit clunky
<intrac>
eg, for some of my off-air recordings, it reports something like:
<intrac>
Delay relative to video : -762 ms
<intrac>
(that's from the audio section)
<intrac>
so you can see there that the audio and video streams aren't aligned - almost by a second
<intrac>
which can be important to factor in
<intrac>
I'm not saying this relates to the issue you're having, but it's an example of where oddities can occur
<Kaybi__2>
Mh I don't find the delay info on my h265 file but I can see the framerates differs between video and audio
ewomer has quit [Quit: WeeChat 4.4.1]
<Kaybi__2>
thank you a lot for helping me out intrac, it's getting late in France so I'll go to bed for now I'll try to reconnect here to get some more help and I'll give answers if I find some '=D
<intrac>
Kaybi__2: I think the 'audio frames' are likely separate alignment and spacing to video frames. so a difference there is quite possibly expected
<intrac>
Kaybi__2: ok, it would be interesting to know if you find the cause of this :)
<Kaybi__2>
I'll keep digging, I can't go further in my project if I do not resolve this anyway hehe
Sciencentistguy has joined #ffmpeg
Kaybi__2 has quit [Quit: Client closed]
emmanuelux has joined #ffmpeg
Sciencentistguy has quit [Ping timeout: 246 seconds]