LionEagle has quit [Remote host closed the connection]
rvalue has quit [Ping timeout: 260 seconds]
LionEagle has joined #ffmpeg
squeaktoy has quit [Quit: WeeChat 4.0.4]
squeaktoy has joined #ffmpeg
rvalue has joined #ffmpeg
kasper93_ is now known as kasper93
minimal has joined #ffmpeg
emmanuelux has joined #ffmpeg
cosimone has quit [Remote host closed the connection]
Dannn has joined #ffmpeg
iive has quit [Ping timeout: 240 seconds]
<Dannn>
hey - is anyone able to help me understand why a conversion is failing?
<linext_>
can ffmpeg output icecast Now Playing as the song changes?
<Dannn>
we're dealing with a camera recording snapshots, trying to convert those snapshots to a video. conversion is successful with .mp4 file extensions, but we're having trouble with .mp4 on the receiving end, basically all of the stills are proper, but the video is DOA. i figured I could change it to .avi, but it seems to be throwing conversion failed. i'm not a developer by any means, i'm just trying
<drv>
you probably need the actual ffmpeg output (that "Conversion failed!" looks like it's from some kind of wrapper)
<Dannn>
could it be...
<Dannn>
- duplicating last frame failed: '/usr/data/printer_data/timelapse/frames/frame000018.jpg' and '/usr/data/printer_data/timelapse/frames/frame000018.jpg' are the same file
<Dannn>
otherwise idk, lol. i don't have full access to the ffmpeg output unless i can somehow force it
<Marth64>
linext_: I've not tried it but my assumption is probably not. I don't think metadata tags like title/artist can change in-flight
squeaktoy has joined #ffmpeg
<Marth64>
Dann: avi and mp4 should handle mjpeg. What would help is a full log from ffmpeg itself, looks like in your example its being wrapped around
squeaktoy has quit [Client Quit]
<Marth64>
Also I noticed -y after the output filename in your command instead of the beginning. I don't think its valid, but I haven't tried it before
thilo has quit [Ping timeout: 256 seconds]
<Dannn>
Marth: thanks for the feedback. I'm actually dealing with a Creality K1 3d printer. This is the default config of moonraker's "timelapse.py" function. My issue is that for some reason, the default .mp4s are failing. They seem like they get put together, but the file itself is actually un-readable.
thilo has joined #ffmpeg
<Dannn>
My hack-around was to see if I could get the renderer to spitout any other file format
LionEagle has quit [Quit: Leaving]
<Dannn>
so I could verify if it's something with the command or else.
<Dannn>
unfortunately, I assume they have the output wrapped, and I wouldn't know where to begin to find that
<Dannn>
here's the paste, i'm more than happy to take suggestions on how to rebuild the command, if you have any. it doesn't have to be .avi specifically.
<linext_>
Marth64, yes the meta data does change when a new song comes on the icecast station
<linext_>
ffmpeg doesn't print it it though
<Marth64>
Dann: ffmpeg is trying to demux your jpeg files as image2 format. What happens if you put -f mjpeg _before_ the -i
<Dannn>
can try it
squeaktoy has joined #ffmpeg
<Marth64>
linext_: makes sense, I am meaning to say I don't think ffmpeg can handle that change
<Marth64>
Does that metadata get loaded as a tag? What's a sample command output look like? Would be pretty easy to tell from that how ffmpeg is handling it on start time of the job. I haven't tried icecast
<Marth64>
I could very well be wrong. just a guess here, but don't think it would work
<Marth64>
ACI-XCIX_0001: haven't used zscale filter, on surface looks like it should work, but have you considered trying to use colorspace filter to set those new values?
<Dannn>
had to make sure it wasnt me
<Dannn>
reply: /usr/data/printer_data/timelapse/frames/frame%6d.jpg: No such file or directory
<Dannn>
have 000001-000012 in there tho
<Marth64>
Dannn: Can you run it without python involved? Let's rule out any funky shell escapes
<Marth64>
I removed the -y, as you mentioned running as root, and I do not want to give you a command that overwrites anything forcefully.
<Marth64>
Also, you had a extra space by "-b:v 7M"
<Dannn>
cheers
<Dannn>
i copy and pasted yours
<Dannn>
same error
<Marth64>
kk .. then yeah it doesnt like your sourc files
<Dannn>
[mjpeg @ 0xaaca20] No JPEG data found in image Error while decoding stream #0:0: Invalid data found when processing input [mjpeg @ 0xaaca20] No JPEG data found in image Error while decoding stream #0:0: Invalid data found when processing input Cannot determine format of input stream 0:0 after EOF Error marking filters as finished
<Dannn>
Finally, I found that this is a ffmpeg related problem. The error message "No JPEG data found in image" can be found in the source code of ffmpeg/libavcodec/mjpegdec.c. Manually compile ffmpeg and use new version of libavcodec will do the trick. Since I successfully extracted feature without any error in ubuntu 18.04, I checked the build information of opencv and found that the version of libavcode
<Dannn>
found that the version of libavcodec is different. (57.107.100 in ubuntu 18.04, 56.60.100 in ubuntu 16.04).
<Dannn>
(sorry it got cut off)
<Marth64>
That is always a possibility, bugs are fixed all the time, and not every build is the same. What distribution are you on? A similar type of operation works fine for me
<furq>
if your version of ffmpeg is older than the one in ubuntu 18.04 then you should update it anyway
<furq>
and probably update everything else
<Marth64>
yea, 18.04 is old
<Dannn>
i'm not sure that's what i'm on
<Marth64>
lsb_release -a
<Dannn>
i'm like a 2/10 with linux/unix, give me the tldr how to find out
<Marth64>
or cat /etc/distribution
<Dannn>
ty
<Marth64>
one of them will tell you
<furq>
the ubuntu version number is the year and month
<furq>
you can just use -c:v copy for jpeg to mjpeg
<Marth64>
(if needed)
<Dannn>
Incompatible pixel format 'yuv420p' for codec 'mjpeg', auto-selecting format 'yuvj420p' [swscaler @ 0xc5c250] deprecated pixel format used, make sure you did set range correctly [mjpeg @ 0xc47cf0] MJPEG CBR encoding works badly with frame multi-threading, consider using -threads 1, -thread_type slice or a constant quantizer.
<furq>
you can ignore all of those
<Dannn>
sweet
<Marth64>
yea, definitely would do what furq said about the -c:v. I copied that from your original command. It's lowering the quality
<Marth64>
ignore those +1
<furq>
the last one is important but you have no reason to encode mjpeg when you already have jpegs
<Dannn>
yea people do complain that the quality is dogshit
<Dannn>
that was part of my exploring this
<Marth64>
yes change to -c:v copy
<Dannn>
let me pull the actual command that runs
<Dannn>
maybe we can just tune that better
<Marth64>
in this case you are stringing literal jpeg frames together, no reason to re-encode
<furq>
probably less stressful for whatever cpu is in that printer
<Marth64>
poor anemic mips cpu trying to compress video
<Dannn>
should i replace yuv420p with something better?
<Dannn>
that is just defaulted
<Marth64>
it doesnt matter since you are doing stream copy, at that point pix_fmt is just setting the format in the header. if it was defaulted then its accurate anyway
<furq>
you can just remove the -pix_fmt line anyway
<furq>
also that command doesn't actually set the framerate
<furq>
so it'll be 25fps
<Marth64>
change to subprocess.run() or subprocess.check_output() someday when you are refactoring this to save yourself from shell escape hell, wouldn't say you need to do it now but if this python script is to get love and care i would do that
<Dannn>
i think it fills the -r in from the gui field
EmleyMoor has joined #ffmpeg
<furq>
oh it's on the input
<furq>
well never mind then
<Marth64>
yea it looks ok
<furq>
that should be -framerate instead of -r though
<Marth64>
furq good pt. they diverged at some point I forgot
<Marth64>
would change -r to -framerate like furq said
<Dannn>
i got a 3 minute print
<Dannn>
lets try it
ACI-XCIX_0001 has quit [Quit: Client closed]
<Dannn>
as it's printing, i just chose avi because mp4 wasn't working
<Dannn>
is there a better format you'd suggest in terms of size/quality compression, i think the internal storage on this thing is like 5gb or somethin
<Dannn>
i plan to rip them off
<Marth64>
its not the format that influences size as much as the codec
<Dannn>
given its a printer doing the stitch together and everything, too
<Dannn>
ok
<Marth64>
in this case they are already small jpeg files being stuck together, it wont matter if you go mp4 or avi unless you change the codec
<Dannn>
got it
<Marth64>
which i would recommend but again running on a 3d printer probably too much for the cpu
navi has quit [Quit: WeeChat 4.0.4]
<Dannn>
haha yeah
<Dannn>
i could always rip the jpegs off
<Dannn>
but i figured ease of use
<Dannn>
i know of one of user with this same problem as me, so given it works (and it should), i'll suggest the same to him
lemourin7 has joined #ffmpeg
lemourin7 is now known as lemourin
lemourin has quit [Killed (mercury.libera.chat (Nickname regained by services))]
<Marth64>
nice
<Marth64>
I had got a printer as a gift but no chance to try it yet
<Dannn>
ok so
<Dannn>
looks like it worked
<Dannn>
57 frames generated
<Dannn>
4054kb .avi
<Dannn>
ah
<Dannn>
they have it in .mp4 because their web gui won't see the .avi
<aaabbb>
Marth64: what format with lossless support, best supported by browsers, has the best compression ratio? i was able to get h264 down to a very tiny fraction of its size (half a megabyte for several minutes of 60fps 1920x1200)
<Marth64>
I have not studied lossless support in browsers, I'm sorry. AFAIK AV1 does lossless but mainstream support is still a work in progress given hardware decoders are still rolling out
<Marth64>
maybe try hevc if you don't have patent restrictions, but will have to test and see
<kepstin>
lossless vp9 will ... probably work in several major browser vendors, depending on hardware
<aaabbb>
hevc seemed to have really terrible lossless performance compared to avc, and isn't very well supported on mobile browsers
<kepstin>
(i think it's specifically unlikely to work on mobile apple devices)
<aaabbb>
if i have to i might go with animated webp, but that's a 40x increase in file size (20 megs instead of 0.5)
<furq>
webp and apng are your choices if you want universal support
<Marth64>
does it need to be lossless? I assume you chose for a reason but just checking. like, you can go visually lossless too with the right crf if using h264
<furq>
i'm guessing it also needs to be not subsampled
<Dannn>
i mean its like a tiny ass timelapse so lol
<aaabbb>
this is one of those niche situations where lossless is way way smaller than anything else
<Marth64>
understood
<aaabbb>
(frame buffer recording for documentation, in a virtual terminal, mpdecimated)
<kepstin>
but yeah, the h264 lossless mode is part of the high 4:4:4 predictive profile, which has really poor support. ffmpeg can decode it, of course, but there's basically no hardware support for it outside of maybe niche pro video stuff.
<aaabbb>
it's low bitrate (30kbit/s) and average fps of like 4, so no need for hardware support
<aaabbb>
long as software can supports it
<Dannn>
got an error with your command for 264
<Dannn>
lemme see
<kepstin>
if you want lossless video that plays in a web browser, lossless vp9 is pretty much the best choice atm.
<Marth64>
aaabbb: did you mean .mov?
<Marth64>
try .mov it might trick the browser to accepting it
<Peter>
im trying to read an FLV-HTTP stream that's sent by a Ubiquiti camera. I've tried using socat to pipe to ffmpeg, but the stream always exits on me. Any thoughts? I can get it to read the streamName metadata, so something is happening: https://paste.pfak.org/BE9Ji6
thilo has quit [Ping timeout: 260 seconds]
<Marth64>
try add ,fork to your socat
minimal has quit [Quit: Leaving]
Dannn has quit [Remote host closed the connection]
<Peter>
tried that, I just get tons of copies all exiting with no stream output, I've tried using EXEC:"" for socat, Ive tried using 'pipe:' instead of '-' for ffmpeg input and PIPE instead of STDOUT on soca.t
<Peter>
I redirected socat to a file, and file(8) shows it as Macromedia Flash Video
<Marth64>
ffmpeg is saying there are no a/v streams in the stream; it's possible, you need to increase your analyze duration to give it some more time to assess the stream
<Marth64>
well, it sees one subtitle but that's not outputting anywhere
<Peter>
i tried -timeout 15000 but it didnt seem to like that? (and -stimeout 15000) but maybe im doing it wrong
<Peter>
is there a probesize/analyzeduration for ffmpeg that im not aware of?
<Marth64>
try this jut before your "-i", the values are exaggerated just to see if it works
<Marth64>
good luck, yeah, it looks like unifi is pumping out some non-standard stream
<Marth64>
from your pastebin provided, it tells me that ffmpeg isn't seeing any video/audio streams, just some metadata and a sbutitle stream
<Marth64>
and from an earlier pastebin, ffmpeg was complaining/dropping about some packets
<Peter>
okay
<Peter>
so there's 4 streams, apparently
<Peter>
or more (?)
<Peter>
socat keeps exiting
<Marth64>
yea, looks like socat is closing and re-opening, so ffmpeg running 4 times
<Marth64>
in sequence, not long-standing
<Marth64>
Stream #0:0, 1, 1/1000: Subtitle: text <-- this is the only one getting picked up possibly because socat is closing quickly
<aaabbb>
noob question: for x264/x265, does 2pass abr give the same quality as crf if they both average the same bitrate? i always thought 2pass abr acted as an "infinite lookahead" and would result in a 1000kbps video being slightly higher quality than a 1000kbps video created via crf
<Marth64>
Peter: all that stuff indented under Metadata isn't actually taking any effect, it's just metadata. so the camera is probably reporting the streams that way, but not in the standard flv container way. if that makes sense
<Peter>
it does
<Marth64>
aaabbb: it depends on the src material, e.g. high vs low complexity in whatever factors the codec cares about, for example motion. so it might end up the same quality based on the source material or drastically different.
<Peter>
im just scratching my head on how ffmpeg can manage to put something together that the actual ubiquiti NVR will pick up, but cant read it
<Marth64>
Are you trying to stream to ubiquiti nvr or taking their stream and forwarding it?
<aaabbb>
Marth64: but is the quality of 2pass at a given bitrate >= the quality of crf at the same bitrate?
<Peter>
Marth64: taking their stream
<Peter>
I wrote a WebSocket proxy to intercept the camera heh
<aaabbb>
like if i have infinite time, doesn't 2pass act as infinite lookahead and will never result in worse quality than crf at the same bitrate? (i know you can't choose bitrate precisely with crf)
<Peter>
Im trying to salvage what's left of this garbage system and use Frigate while Im still living here and then buying RTSP cameras for my next home (=
<Peter>
Marth64: but that unifi-cam-proxy uses ffmpeg to pretend to be a ubiquiti camera, so ..
<Marth64>
aaabbb: I understand the question better now. I'm actually not sure. thinking
<Peter>
i wonder if socat is terminating the connection or if its the camera itself :)
<aaabbb>
Marth64: i know that vp9 has a huge benefit from 2pass but i always thought x264/x265 gave a slight benefit because of the effectively inifnite lookahead. or is 2pass abr for x264/x265 literally just internally using crf, but choosing like crf 18.5819054 (or something equally high precision that can't otherwise be specified)
<Marth64>
aaabbb: to me it makes sense what you are saying. in theory I will lean with "2pass >= crf" at same bitrate but I am not qualified to be certain. I don't have to tune a lot for the things I do with ffmpeg. I'm sorry!
<Marth64>
it sounds as if it should be true
<Marth64>
because the lower complexity scenes will get a higher bitrate than they would with just the crf, but also the encoder needs to meet the average so it depends on the overall composition of the source
<Marth64>
i don't think there's a flat correlation
<Peter>
interesting each file dumped to disk by socat starts with FLV
<Marth64>
Peter: maybe camera is sending it in little chunks that repeat the header
<Marth64>
and this is confusing ffmpeg
<aaabbb>
Marth64: but on the other hand, with crf it really doesn't care about bitrate, so the only benefit i can think of for x264/x265 is the effectively infinite lookahead which makes decisions like bframe placement more accurate
<aaabbb>
i'll do some tests with -tune ssim
<Peter>
that does sound likely
<Peter>
hrm VLC wont even read the distinct chunks
<aaabbb>
and set the 2pass abr bitrate to whatever crf spits out
<Marth64>
aaabbb: yea curious what you find, my uneducated hunch on that partiular question is inconsistent outcome but curious
<Peter>
okay and just to confirm im not crazy: ffmpeg doesnt support listening for a TCP connection on input?
<Peter>
i know it does for output
<Peter>
tcp://localhost:3949?listen
<Marth64>
Peter: it should, there is a tcp protocol handler for input
<Marth64>
ffmpeg -h protocol=tcp
waleee has quit [Ping timeout: 260 seconds]
<Marth64>
never used it
<aaabbb>
my hunch is that the quality difference will be so mild that the slight inaccuracy of abr will dominate the tests (unless i do pass=3 so many times in a row that it's refined enough to be exactly the same file size), also idk how good ssim is as a tool for this
<Marth64>
haven't used the rtsp muxer so you may have to rely on `ffmpeg -h muxer=rtsp` from here
<Peter>
Marth64: haha that will be so far awya. we need to find some old house to buy, then have it renoed.. then move :)
<Peter>
Everything in our price range is 70 years old and hasn't had a thing done to it in 70 years.
<Peter>
And is still $2 million+
* Peter
cries in Canada
Muimi has joined #ffmpeg
<Marth64>
but on the positive note you have Timmy's coffee up there
<Marth64>
it's good on the go
<Peter>
coffee subtitute~
<Marth64>
lolol
FH_thecat has joined #ffmpeg
<Marth64>
dropping for real now, good l uck
AbleBacon has quit [Read error: Connection reset by peer]
Vonter has quit [Ping timeout: 260 seconds]
Vonter has joined #ffmpeg
bitbinge has quit [Ping timeout: 240 seconds]
ACI-XCIX_0001 has joined #ffmpeg
MisterMinister has joined #ffmpeg
<ACI-XCIX_0001>
Marth64 thank for your answer !
<ACI-XCIX_0001>
yes tried the filter with colorspace but the `transfer` remains gamma remains `bt1886` instead of `smpte2084`, this for that reason that JEEB purposed to use zscale instead of filter.
<ACI-XCIX_0001>
does ouputs a half black image and the colorimatrix is still in bt709 and the levels is still in limited while it s specified otherwise in the command
ajshell11 has joined #ffmpeg
ajshell1 has quit [Ping timeout: 245 seconds]
ajshell11 is now known as ajshell1
Ogobaga has quit [Quit: Konversation terminated!]
Ogobaga has joined #ffmpeg
<Marth64>
ACI-XCIX_0001: got it. I would trust JEEB's method more than mine in this case. I did not get a chance to run this command myself
<Marth64>
do you have a ffmpeg output log, just curious what it is thinking before it starts the encode
<Marth64>
I would make these two improvements to the command 1: put the -t 10 before -i 2: move the -vf clause and filterchain before -c:v
yo0O0o has joined #ffmpeg
<Marth64>
so it is more like, ffmpeg -t 10 -loop 1 - i INPUT.whatever -c:v libx265 .... -vf zscale=.... OUTPUT.mkv
<Marth64>
errr
yo0O0o has quit [Read error: Connection reset by peer]
<Marth64>
so it is more like, ffmpeg -t 10 -loop 1 - i INPUT.whatever -vf zscale=.... -c:v libx265 .... OUTPUT.mkv
<Marth64>
good luck sorry it probably cannot fix your issue but I think wiring the pipeline that way will be less error-prone later
<Marth64>
also consider if you need to apply the color primaries as stream metadata, I am not sure ffmpeg will automatically do that for you
<ACI-XCIX_0001>
did not fix the issue, but still interested in the metadata path you are presenting.
<ACI-XCIX_0001>
can ask you how you would apply the primaries directly to the metadata ?
<Marth64>
e.g. -color_primaries:s:0 bt2020 -color_trc:s:0 smpte2084 -colorspace:s:0 bt2020nc -color_range:s:0 full
<Marth64>
yes :)
<Marth64>
^
<Marth64>
stuff all that after -pix_fmt
<Marth64>
after -pix_fmt yuv420p10
<ACI-XCIX_0001>
nice thank trying !
<ACI-XCIX_0001>
(y)
<Marth64>
np
<Marth64>
i always explicitly set it when i can, not a big fan of ambiguity, so i am not sure if ffmpeg may have already done it for you.. but worth a shot
<ACI-XCIX_0001>
sure
<ACI-XCIX_0001>
does not appear to like it : same for each added metadata option :`[out#0/matroska @ 00000000006fb5c0] Codec AVOption color_range (color range) has not been used for any stream. The most likely reason is either wrong type (e.g. a video option with no video streams) or that it is a private option of some encoder which was not actually used for any
<ACI-XCIX_0001>
stream.`
Vonter has quit [Ping timeout: 260 seconds]
<Marth64>
drop the :s, try this instead
<ACI-XCIX_0001>
ok
<Marth64>
-color_primaries:0 bt2020 -color_trc:0 smpte2084 -colorspace:0 bt2020nc -color_range:0 full
<Marth64>
sorry, i am a braindead zombie tonight and making bunch of typos
jarthur has quit [Quit: jarthur]
<ACI-XCIX_0001>
aa ! no issue you are welcome !
<ACI-XCIX_0001>
already very nice to you to help !
<Marth64>
in previous one i was accidentally targetting a subtitle lol
<Marth64>
np
<ACI-XCIX_0001>
aa !
Vonter has joined #ffmpeg
<ACI-XCIX_0001>
yes the metadata appllies as intended but the half picture black and the hdr information lost with overexposed highlights and desaturated colors are still there
<Marth64>
ok. maybe we start with half picture black
<Marth64>
is it top half? bottom half? every other frame, etc
<ACI-XCIX_0001>
here is the source image trying to remux in video
<ACI-XCIX_0001>
you also have the resulting mkv with the half black picture
<aaabbb>
some of them i can just guess by the name
<Marth64>
aaabbb: thx for sharing. it's possible, I haven't seen it in the docs.you might have to refer to the code itself.
<aaabbb>
at first i thought 2pass would act as infinite lookahead, but it seems that the bframe placement at the least is chosen at the first pass, so the second pass (as far as i know) doesn't gain anything from more accurat eplacement
<Marth64>
ACI-XCIX_0001: maybe since the issue is down to one layer now try reasking here every day or so and maybe if any HDR specialist is around?
<JEEB>
Marth64: yes, trac is the bug tracker
<Marth64>
thx!
<Marth64>
ACI-XCIX_0001: can I keep and share your sample image to the bug tracker?
realies has quit [Read error: Connection reset by peer]
realies has joined #ffmpeg
realies has quit [Read error: Connection reset by peer]
<boxrick>
Also perhaps someone knows... any way to pad out a video file with black screen for a few seconds?
<boxrick>
Specifically I have a true-hd soundtrack from a lower resolution film, and a much higher resolution version I want to combine. The only difference is the video file is 2s shorter so I need to add that duration to the start of the higher resolution file.
<boxrick>
So with that in mind can I add a very specific amount of black frames to my video at the start using FFMPEG?
realies has joined #ffmpeg
vampirefrog has joined #ffmpeg
epony has joined #ffmpeg
apteryx has joined #ffmpeg
<apteryx>
should I expect breakage going from 6.0 to 6.1 in a distro (Guix) ?
<apteryx>
I see it fixes 2 vulnerabilities
<psykose>
no
<apteryx>
great
<BtbN>
vulnerability fixes are backported to all branches anyway though?
<Marth64>
You can't add 2 seconds to the start without re-encoding the video, but you might be able to get away with the inverse operation (chopping 2 seconds from the start of audio to line up with the video)
<Marth64>
You can also do it in a way where there is a timestamp delay but I was never fan of that
<apteryx>
could this be caused by ffmpeg 6.0 -> 6.1 ? ../mpd-0.23.14/src/decoder/plugins/FfmpegIo.cxx:44:24: error: ‘AVERROR_EOF’ was not declared in this scope
zsoltiv has quit [Remote host closed the connection]
<boxrick>
Marth64: The Audio is TrueHD which is hard to modify without making it LPCM... I cut 2s~ from the front of the video then just added it to the front of itself... :p
<boxrick>
ffmpeg -i video.mkv -ss 00:00:00 -to 00:00:01.800 -c copy video_output.mkv ... obviously it only aligns with the frames
<boxrick>
But it was close enough
<boxrick>
Lipsync looks perfect.
<Marth64>
perfect
<Marth64>
yea thd isn't fun :)
<Marth64>
maybe a strange strategy and it take a lot more storage, but i like to render out thd/dts to their different 2.0/5.1/7.1 presentations in flac
rv1sr has quit []
<Marth64>
at least it's liberated at that point
beaver has joined #ffmpeg
* Marth64
grew to dislike proprietary fmts
bitbinge has joined #ffmpeg
<zeratul>
can ffmpeg output fragmented mp4 files ?
<Marth64>
zeratul: I believe so. See `ffmpeg -h muxer=mp4` there appears to be fragmentation options there
MootPoot has quit [Quit: Connection closed for inactivity]
<zeratul>
Marth64, I want ffmpeg to output mp4 files that can be played back even if they're incomplete
<Marth64>
zeratul: gotcha...sorry I do not use mp4 and can't give better examples. just a starting point, possibly there are mp4 experts here that will see this and provide advice
Tano has quit [Quit: WeeChat 4.0.4]
bitbinge has quit [Ping timeout: 240 seconds]
<iive>
zeratul, there was a tool that moves the index to the start of the file..
<iive>
something to do with "faststart"
<iive>
yep, the tool is "qt-faststart" or you could use ffmpeg -movflags +faststart
<BtbN>
zeratul: that's simply not a thing. Even fragmented mp4 needs intact segments and its init segment
<BtbN>
if you want to do a live recording where stuff can crash, use anything but mp4
LionEagle has quit [Quit: Leaving]
<iive>
mpeg-ts is like the gold standard for streaming.