[Ffmpeg-devel-irc] ffmpeg.log.20160617

burek burek021 at gmail.com
Sat Jun 18 02:05:01 CEST 2016


[00:01:26 CEST] <furq> it's measuring "quality of experience"
[00:01:32 CEST] <furq> that well-defined metric
[00:03:30 CEST] <kepstin> in my experience, "quality of experience" measurements tend to be more interested in things like packet loss, jitter, network congestion for live streaming than actual measurement of video or audio quality.
[00:03:45 CEST] <furq> yeah that would have been my guess as well
[00:04:13 CEST] <kepstin> hmm. but that's usually called "quality of service"
[00:04:45 CEST] <Sashmo> sorry guys, but kepstin is right thats QOS, not QOE
[00:05:00 CEST] <Sashmo> trust me, this is some sort of measurement on the video quality after decoding.... 100%
[00:07:47 CEST] <kepstin> https://www.sandvine.com/technology/video-quality-of-experience.html has a paper talking about some related stuff, it's looking at a mix of things like playback smoothness/buffering, switches between different adaptive qualities.
[00:08:18 CEST] <furq> apparently qos and qoe can both cover both of those things
[00:08:28 CEST] <furq> not that i don't believe you that this chart is measuring perceived video quality
[00:08:59 CEST] <furq> but it is still a bit useless without something more concrete on the y-axis
[00:09:23 CEST] <kepstin> but yeah, it looks like "quality of experience" is usually used to refer to the experience of playback at a customer site after streaming, so it doesn't really seem like something you can calculate locally in non-realtime.
[00:09:37 CEST] <furq> at least until ffmpeg finally gets an -experience:v switch
[00:14:20 CEST] <kepstin> with regular tcp-based streaming as is typically used, there's no actual picture quality degredation from transmitter to receiver, so attempting to measure that doesn't make sense
[00:14:57 CEST] <kepstin> and that's all controlled and can be tested at the sender end before the stream even starts, so you don't /have/ to measure it
[00:15:27 CEST] <kepstin> so this "quality of experience" stuff appears to mostly measure things like buffer stalls, quality level switches, etc.
[00:16:50 CEST] <kepstin> but yeah, I could imagine that someone ran a video analysis tool over your video, and got some meaningless information about apparentl mpeg artifacts in some spots.
[00:22:36 CEST] <Sashmo> kepstin: could be
[00:22:48 CEST] <Sashmo> I'll keep digging
[00:55:38 CEST] <DHE> I think I figured out my API issue...
[01:06:26 CEST] <CoJaBo> kepstin: ...isn't sandvine that company who sold products to deliberately degrade "quality-of-experience"? rofl
[01:14:42 CEST] <CoJaBo> So I'm still at this webm thing; I have a server that streams video as webm/MP4. I need some tool to somehow convert this into a real streaming format. Ideas?
[01:17:20 CEST] <DHE> CoJaBo: that's one thing it does, yes.
[01:18:09 CEST] <CoJaBo> DHE: ?
[01:18:13 CEST] <DHE> sandvine
[01:20:00 CEST] <CoJaBo> I've been stuck on this for datys now :/
[01:20:40 CEST] <CoJaBo> I'm almost to the point of trying to just decompile the damn thing and reverse-engineer how in the hell it handles them. but i was hoping to use something standard >_>
[01:21:00 CEST] <DHE> MPEG-DASH? HLS? nginx-rtsp ?
[01:21:40 CEST] <CoJaBo> Absolutely any of those would be fine
[01:22:15 CEST] <CoJaBo> The problem is getting anything to read the diced-webm/mp4 format from the source
[01:22:23 CEST] <DHE> typically you choose based on client capability. Apple loves HLS. MPEG-DASH is the official standard
[01:22:27 CEST] <DHE> ah
[01:22:52 CEST] <CoJaBo> Frankly, even just outputing clean webm would be perfectly 100% fine
[01:24:41 CEST] <CoJaBo> :/
[01:26:41 CEST] <Sashmo> kepstin: http://www.acceptv.com/en/media/documents/AccepTV%20-%20Video%20Quality%20Monitor%20-%20Datasheet.pdf
[01:47:12 CEST] <Sashmo> does anyone know how to get the audio volume levels from a file at a specific time? ideally I want to graph the volume levels over a duration of time, or whole file
[01:48:27 CEST] <kepstin> Sashmo: use the ebur128 filter for that
[01:48:40 CEST] <Sashmo> thanks kepstin
[01:49:15 CEST] <kepstin> Sashmo: one of its modes can log the loudness in 100ms intervals, iirc.
[01:49:26 CEST] <Sashmo> cool, thanks again kepstin
[02:26:31 CEST] <CoJaBo> :/
[02:49:31 CEST] <hazardous> might be a dumb question, but how do i pull the last frame of a .webm with ffmpeg as an image (jpeg or png is fine)? i tried googling but not sure the phrase to search for, keyframe?
[02:56:42 CEST] <c_14> maybe something like `ffmpeg -sseof -0.1 -i video -frames:v 1 out.png'
[02:57:01 CEST] <c_14> you might have to adjust the -0.1 depending on the video fps
[02:57:23 CEST] <c_14> It would probably be better to run an ffprobe on the input file and dump the pts of the last frame and use -ss with that
[03:04:02 CEST] <totaln00b> I can't figure out how to get ffprobe on debian. I've installed ffmpeg successfully but it doesn't have ffprobe. I'm doing this CLI btw
[03:04:11 CEST] <c_14> how'd you install it?
[03:04:12 CEST] <DHE> is ffprobe included in the ffmpeg package?
[03:04:24 CEST] <totaln00b> I used apt-get install ffmpeg
[03:04:48 CEST] <c_14> what debian version?
[03:04:57 CEST] <totaln00b> and I have ffmpeg but when I try to use ffprobe it says command not found
[03:05:22 CEST] <totaln00b> 7.8
[03:08:10 CEST] <codebam> hey, I'm trying to make a video with a sequence of images made in blender. they start at 0001.png. how do I do this? I was trying -start_frame 0001 and %03d.png
[03:08:19 CEST] <codebam> but file not found
[03:08:24 CEST] <kepstin> totaln00b: hmm, you didn't actually install ffmpeg then, you've got the 'ffmpeg' compatibility wrapper tool from libav.
[03:08:43 CEST] <kepstin> codebam: you need %04d.png - '4' because it's 4 digits.
[03:08:53 CEST] <codebam> ahh okay thanks!
[03:08:57 CEST] <totaln00b> oh :(  How should I go about installing the actuall ffmpeg then
[03:09:15 CEST] <codebam> worked great thanks
[03:10:06 CEST] <c_14> totaln00b: either from source, or I believe the static builds include ffprobe
[03:10:44 CEST] <totaln00b> okay, I'll try that
[03:10:46 CEST] <totaln00b> Thank you!
[03:10:47 CEST] <kepstin> totaln00b: alternatively, it's packaged in debian... 'testing' I think right now? You'd probably have to upgrade a good chunk of your system to get that.
[03:11:34 CEST] <kepstin> there's a backport to jesse, but i think you're out of luck for a packaged version on wheezy
[03:11:43 CEST] <codebam> will changing the extension on the output file change the filetype?
[03:11:59 CEST] <codebam> can I just change it to .webm
[03:12:08 CEST] <kepstin> codebam: if you're not using a '-f' option to set it manually, ffmpeg guesses the output format from the extension
[03:12:20 CEST] <codebam> oh okay cool
[03:12:48 CEST] <codebam> I got an error when trying to use webm
[03:13:14 CEST] <kepstin> great. if you read it, it might tell you what went wrong ;)
[03:13:23 CEST] <kepstin> alternately,
[03:13:41 CEST] <codebam> says only VP8 and VP9 video are supported for webm
[03:13:44 CEST] <codebam> I'll paste it
[03:14:10 CEST] <kepstin> ok, that means that you're asking for it to encode some other codec (e.g. with a -c:v option)
[03:14:22 CEST] <codebam> https://ptpb.pw/NWIW
[03:14:52 CEST] <kepstin> you missed the part where it asks for the exact ffmpeg command you're running...
[03:14:54 CEST] <codebam> kepstin: oh yeah you're right
[03:15:28 CEST] <codebam> also ffmpeg -start_number 0001 -i %04d.png -r 24 -pix_fmt yuv420p out.webm
[03:15:49 CEST] <codebam> after changing it
[03:16:16 CEST] <codebam> should I worry about the warning about past duration too large
[03:16:30 CEST] <codebam> and what does it mean
[03:16:34 CEST] <kepstin> I still have no idea what that even means :/
[03:16:48 CEST] <kepstin> it was added to some recent version of ffmpeg and it just confuses everyone
[03:17:08 CEST] <codebam> lol okay
[03:17:33 CEST] <codebam> well thanks for the help guys, have to study for finals tomorrow now
[03:17:36 CEST] <kepstin> anyways, if you don't specify an encoder (with -c:v) or any settings, then ffmpeg will select some random encoder that works with your output format, and some usually not particularly reasonable settings
[03:17:50 CEST] <codebam> oh
[03:17:52 CEST] <kepstin> so you almost always want to manually say the encoder, and set some quality settings
[03:18:08 CEST] <codebam> so I should redo this with the proper webm encoder?
[03:18:26 CEST] <kepstin> it's being done "properly", but the quality might not be very good
[03:19:14 CEST] <codebam> well I'll watch it when its done and see how it looks. then use the webm_dash_manifest with higher quality if I can
[05:50:57 CEST] <trelane> I'm running: ffmpeg -strict -2 -r "30" -i "bees.mp4" -vcodec "copy" "bees30.mp4" and getting the error: [aac @ 0x21fbd20] The encoder 'aac' is experimental but experimental codecs are not enabled, add '-strict -2' if you want to use it.
[05:50:57 CEST] <trelane>   What am I missing?
[05:51:51 CEST] <kepstin> trelane: first of all, you should upgrade to ffmpeg >=3.0 where the aac encoder is no longer marked experimental :)
[05:53:15 CEST] <trelane> kepstin, hrm, perhaps it's time to move this box to 16.04
[05:53:17 CEST] <kepstin> trelane: if you're stuck on this version, try moving the '-strict -2' to the output side (i.e. after all the input files)
[05:54:14 CEST] <trelane> kepstin, I can always compile it if needed :)
[05:54:26 CEST] <trelane> might be easier than moving the box to 16.04 at htis time
[05:54:37 CEST] <kepstin> well, even ubuntu 16.04 only has ffmpeg 2.8.6 :/
[05:55:11 CEST] <trelane> ok
[05:55:14 CEST] <trelane> compiling from source!
[05:55:27 CEST] <trelane> <-- only uses ubuntu due to EXTREME apathy
[06:01:16 CEST] <trelane> kepstin, who wrote the configure script?
[06:01:34 CEST] <kepstin> what, ffmpeg's? Many, many people.
[06:01:46 CEST] <kepstin> over a long period of time :)
[06:02:43 CEST] <trelane> the output (and the lack of scrolling of garbage I don't care about) is quite elegant.
[06:03:48 CEST] <kepstin> yeah, but particularly on slow boxes it's kind of annoying because there's no feedback that it's actually doing anything
[06:24:39 CEST] <trelane> hrm, I'm running that command now and am ending up with a file LARGER than what I started with, and it doesn't seem to be converting from 60 to 30 fpw
[06:24:42 CEST] <trelane> fps
[06:35:20 CEST] <kepstin> hmm, I don't think you can change the framerate with ffmpeg unless you're re-encoding.
[06:36:05 CEST] <kepstin> what's your goal? play the video at half speed?
[06:36:34 CEST] <kepstin> you can probably do that by modifying the framerate of the file with MP4Box.
[06:37:06 CEST] <kepstin> if you want the video to play back at the same speed, but with half the framerate, you need to re-encode (you can't just drop half the frames from an encoded video and expect it to work...)
[09:05:19 CEST] <CoJaBo> So I'm still at this webm thing; I have a server that streams video as webm/MP4. I need some tool to somehow convert this into a real streaming format. Ideas?
[09:12:19 CEST] <Betablocker> what do you call "real streaming format" ?
[09:12:44 CEST] <Betablocker> and what kinde server streams webm ?
[09:13:01 CEST] <Betablocker> -e+a
[09:59:39 CEST] <Renault> hello all
[10:00:19 CEST] <Renault> do you know if someone works on MJPEG codec with QSV for hardware acceleration?
[10:01:39 CEST] <Renault> My compagny are interested by that, I could work on probably if necessary, but we shoumd avoid to replicate this work... :)
[10:03:23 CEST] <basisbit> Renault, you could check https://trac.ffmpeg.org/ for any bugs regarding these issues
[10:03:48 CEST] <Renault> I didn't find a report about that
[10:07:53 CEST] <basisbit> Renault, also, if you are new to ffmpeg development, please feel free to read ffmpeg.org/developer.html#Code-of-conduct
[10:09:22 CEST] <Renault> ok, thanks :)
[10:29:19 CEST] <CoJaBo> Betablocker: The problem is that I can't resume at any point in a webm file
[10:30:13 CEST] <CoJaBo> Betablocker: I have the header of the webm, missing data, then resume at a completely arbitrary position in that file.
[11:13:37 CEST] <dystopia> hello, i'm trying to dump the ffprobe info of a video file to a text file
[11:13:48 CEST] <dystopia> ffprobe.exe file.ts >> info.txt
[11:14:10 CEST] <dystopia> it outputs the file info to the command window but the text file is empty
[11:14:19 CEST] <dystopia> is there an easy way to do this
[11:15:03 CEST] <furq> ffprobe file.ts 2>&1 >> info.txt
[11:16:09 CEST] <dystopia> thats still creating an empty text file
[11:19:10 CEST] <furq> ffprobe file.ts &> info.txt
[11:20:32 CEST] <luciovito> hi folks!!!
[11:22:08 CEST] <dystopia> C:\Users\jse\Desktop\release\test>ffprobe.exe Qualifying.ts &> test3.txt
[11:22:08 CEST] <dystopia> The syntax of the command is incorrect.
[11:22:19 CEST] <dystopia> http://i.imgur.com/rapr63e.jpg
[11:22:28 CEST] <dystopia> any other ideas furq
[11:23:06 CEST] <luciovito> I need help. I have to use decklink on ubuntu. I've installed successfully drivers etc. I have also the SDK. When I try to configure ffmpeg using this command: ./configure --enable-decklink --extra-cflags=-l/usr/src/BlackmagicDeckLinkSDK/Linux/include --extra-ldflags=-L/usr/src/BlackmagicDeckLinkSDK/Linux/include
[11:23:07 CEST] <luciovito> ./configure --enable-decklink --extra-cflags=-l/usr/src/BlackmagicDeckLinkSDK/Linux/include --extra-ldflags=-L/usr/src/BlackmagicDeckLinkSDK/Linux/include
[11:23:07 CEST] Last message repeated 1 time(s).
[11:23:07 CEST] <luciovito> I need help for compile ffmpeg with decklink on ubuntu
[11:24:21 CEST] <luciovito> console return me that DeckLinkAPI.h header not found, but file is present
[11:57:58 CEST] <luciovito> statevi bene mai una informazione!!!
[11:57:59 CEST] <Threads> dystopia you using windows cmd prompt right
[12:05:32 CEST] <pZombie> hi
[12:06:29 CEST] <pZombie> does anyone know if there is any good alternative to the patented h264 codec for capturing with virtualdub?
[12:07:06 CEST] <pZombie> i compiled vfw vp8, but even with the best settings, it looks terrible compared to vfwx264
[12:07:25 CEST] <pZombie> is there really nothing else out there?
[13:10:54 CEST] <DHE> pZombie: ffv1 is ffmpeg's own lossless codec. if lossless is your thing, you can use that. I don't think there are any patents on it
[13:13:26 CEST] <pZombie> what about theora?
[13:13:44 CEST] <pZombie> what about vp9?
[13:14:01 CEST] <pZombie> where are vfw builds for those two?
[13:14:18 CEST] <pZombie> why has ffdshow removed all it's encoder codecs almost?
[13:15:28 CEST] <pZombie> is this a conspiracy? The whole fucking internet and you can barely find any information on alternatives to capturing video in a reasonable compression format
[14:34:38 CEST] <Josh1_> Hello. I'm using sometime ffmpeg for merge segments .ts from a m3u8. The TS are on my pc, i'm not downloading from a website. I have this error:
[14:34:54 CEST] <Josh1_> [crypto @ 033aaae0] Unable to open resource - [hls,applehttp @ 033a8c40] Failed to open segment of playlist 0
[14:35:06 CEST] <Josh1_> Is the first time i'm see it. Thanks for any help
[15:22:22 CEST] <die_hoernse> Hello. I got a broken mp4 file from a captured VHS source. The capture hardware produces VFR mp4 and seems to insert negative samlple_durations at random (in fact, there are correlating factors but that is now not the issue). I got as far as this:
[15:23:53 CEST] <die_hoernse> 1.) A frame gets a sample duration that is too long so that it takes up multiple frames' time.
[15:23:58 CEST] <die_hoernse> 2.) The following sample tries to make up for the lost time by having negative length.
[15:24:35 CEST] <BtbN> So the timestamps are just broken?
[15:25:09 CEST] <BtbN> If the video is in fact CFR and you know the correct framerate, you can just generate new ones.
[15:25:20 CEST] <die_hoernse> 3.) This can be sort-of-fixed by using -bsf:v h264_mpftoannexb. - The lost time is now made up by letting the next few samples have a sample_duration of "1"
[15:25:26 CEST] <BtbN> Otherwise, I don't think there is a way to fix this
[15:26:26 CEST] <die_hoernse> - But then the frame that is too long kinda freezes for a few frames length, while there are unused frames that could be displayed in the meantime.
[15:27:01 CEST] <die_hoernse> @BtbN: yeah, it seems it is only the sample_durations
[15:27:21 CEST] <die_hoernse> i have a mp4dump snippet here: http://pastebin.com/J696tKxs
[15:27:38 CEST] <die_hoernse> it shows the original ant the kind-of-fixed durations.
[15:28:19 CEST] <BtbN> mp4toannexb doesn't do anything with the timestamps though, it just changes the internal h264 bitstream format.
[15:29:21 CEST] <die_hoernse> creating CFR would always be a bit off. i notice slight drifts in framerate when viwing whole file dumps (about 3 hours in some files - little offsets get noticeable)
[15:30:50 CEST] <die_hoernse> well, mp4toannexb was the last suggestion before the vendor started ignoring me. it kinda does the trick by having the sample_durations clamp at "1"
[15:31:55 CEST] <BtbN> sample_duration is gone once the mov demuxer is done with the file. The bsf never sees it. It doesn't even touch dts/pts/duration at all.
[15:34:09 CEST] <die_hoernse> As I understand it, the sample's time code gets rewritten from length-encoding to start time encoding... so I thought it would be rewritten in any case.
[15:34:35 CEST] <die_hoernse> well, at least it definitely produces the result shown in the pastebin link
[15:34:41 CEST] <BtbN> The mov demuxer transforms it into dts, pts and duration.
[15:34:51 CEST] <BtbN> Most stuff in ffmpeg only cares for dts/pts
[15:35:30 CEST] <die_hoernse> Ah. So what you are trying to tell me is, that any remuxing would have the pasted outcome?
[15:35:44 CEST] <die_hoernse> Not specifically mp4toannexb
[15:35:58 CEST] <BtbN> I'm just telling you that the bsf does not touch any timestamps, at all
[15:36:16 CEST] <die_hoernse> Ok, got that.
[15:36:51 CEST] <die_hoernse> Then i must have understood https://www.ffmpeg.org/ffmpeg-bitstream-filters.html#toc-h264_005fmp4toannexb wrong.
[15:37:24 CEST] <die_hoernse> Thought "Convert an H.264 bitstream from length prefixed mode to start code prefixed mode" means it changes the timecodes.
[15:37:43 CEST] <BtbN> No, that's referring to the internal bitstream format.
[15:38:24 CEST] <die_hoernse> Nevermind. Is there a way to specifically change the sample duration of a certain video sample? - Best whilst not de-synching audio?
[15:39:21 CEST] <BtbN> None that I'm aware of.
[15:41:02 CEST] <die_hoernse> I tried it half a year ago via a c++ API (don't remember which) - the mp4dump'd values werde correct but the file was unplayable. Out of despair I basically sought out the sample_duration in void memory and changed it - so I did not expect it to work.
[15:41:24 CEST] <die_hoernse> Too bad.
[15:43:45 CEST] <die_hoernse> Is this actually the right place to ask? It's my first try to contact the ffmpeg community in that matter, so I am still not familiar with the ecosystem.
[15:44:24 CEST] <JEEB> API/command line usage help is here
[15:44:34 CEST] <JEEB> mostly users on this channel, maybe some developers sometimes
[15:44:57 CEST] <JEEB> anyways, at work so can't help you right now :P
[15:45:20 CEST] <die_hoernse> no problem :)
[15:46:08 CEST] <die_hoernse> Thank you, BtbN and JEEB.
[15:46:50 CEST] <BtbN> What source even is this, that it generates VFR?
[15:47:35 CEST] <die_hoernse> This -> http://www.hauppauge.com/site/products/data_hdpvr2-gaming.html
[15:47:58 CEST] <BtbN> Dealt with that thing before, it's trash.
[15:48:25 CEST] <die_hoernse> I used it to capture (now irrecoverably dismantled) VHS- and Hi8-tapes.
[15:48:53 CEST] <ritsuka> uh how can they store negative durations in mp4 when the spec says it's an unsigned integer? :|
[15:49:11 CEST] <die_hoernse> From what I learned the hardware seems to count up frames by edges it detects on analogous inputs.
[15:49:54 CEST] <die_hoernse> For example when the VCR was emitting noise due to FF or FRwnd, the frame rate went up to 600.
[15:50:16 CEST] <die_hoernse> ritsuka, that's funny:
[15:51:15 CEST] <die_hoernse> I also found the spec saying it's unsigned. But many APIs treat it as signed. Including the Hauppauge firmware, driver and mp4dump.
[15:51:38 CEST] <die_hoernse> The C++ API I used also gave out the duration as an int.
[15:51:54 CEST] <BtbN> https://ffmpeg.org/doxygen/trunk/group__avio__read.html#gf089361fd70426624d19d436a10f87ad
[15:52:11 CEST] <BtbN> that's the function used in https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/mov.c#L2520 to read the sample_duration. It's indeed unsigned.
[15:52:45 CEST] <BtbN> And it's almost immediately converted to an int64_t, so there is no way it overflows somewhere
[15:53:23 CEST] <BtbN> hm, unless it being an int at first is a problem
[15:54:17 CEST] <BtbN> I wonder if this a bug, and changing that to an unsigned int would help with your problem.
[15:54:56 CEST] <BtbN> Your negative sample duration would become a very long positive sample duration. Maybe that's more appropiate?
[15:55:16 CEST] <die_hoernse> I found several commits in ffmepg and libav dealing with negative sample_durations
[15:55:24 CEST] <die_hoernse> Nope.
[15:56:04 CEST] <die_hoernse> That's how i noticed it: Avidemux made 40 hours of a 2 hour movie file. One frame was 38 hours :/
[15:56:26 CEST] <BtbN> Yeah, that's what it actually does
[15:56:28 CEST] <die_hoernse> *of -> out of
[15:56:53 CEST] <BtbN> as mov doesn't have negative durations, there are two frames with a huge duration
[15:57:09 CEST] <BtbN> well, or rather one with a slightly longer one and one with a huge one
[15:58:19 CEST] <BtbN> -3595 actually is 4294963701
[15:58:46 CEST] <Regda> If i write something like -filter_complex "[0:v] anyvideofilter" will it be the same as -filter_complex "[0:v] anyvideofilter [0:v]" ?
[15:59:02 CEST] <die_hoernse> The bug is the Capturing process not noticing when frame times overlap, letting them get negative length, not noticing the overflow. Then the file ends up broken. Players can handle it - they just skip over said samples (meaning MPC's mp4 lib and VLC also use signed!). But cutting software examines it and makes either looong files (avidemux) or crashes (Hauppauge's own editing software ^^)
[15:59:03 CEST] <BtbN> I'd also guess that the negative number to compensate the previous one is what the muxer intended, but it doesn't exactly achive that.
[16:00:06 CEST] <BtbN> MPC-HC and vlc both use libavformat.
[16:00:36 CEST] <BtbN> No idea if VLC has its own mov implementation though
[16:01:14 CEST] <die_hoernse> Would not surprise me if it hab.
[16:01:18 CEST] <die_hoernse> *had
[16:01:20 CEST] <hid|ninja> use mpv lads
[16:02:46 CEST] <die_hoernse> ninja: Well, I'd like to edit my stack of 25 years worth of family home videos first before thinking about a player.
[16:03:43 CEST] <die_hoernse> Just to stress this: Playing is usually not a big deal (hinting that players threat duration as signed). Editing is. Editing software is more thorough in examining the file.
[16:03:59 CEST] <BtbN> Doesn't that thing have a propper dshow driver, so you can just capture with ffmpeg?
[16:04:09 CEST] <die_hoernse> sadly not
[16:04:24 CEST] <die_hoernse> It comes with it's own USB ecosystem.
[16:05:05 CEST] <BtbN> And what application are you using to record?
[16:05:23 CEST] <die_hoernse> Also, most of the Tapes in question got destroyed in the capturing process - They were kept in the attic. Had mold and heat deformations and all kinds of dirt on them.
[16:06:03 CEST] <die_hoernse> I was using the Hauppauge capture software.
[16:06:48 CEST] <BtbN> obs-studio does support it. Might be not as straight forward, but it does have a propper muxer.
[16:06:49 CEST] <die_hoernse> Tests I did during the capture phase (March - August 2015) showed no errors. But when I started editing large files in October it got interesting.
[16:07:48 CEST] <die_hoernse> Fun fact: I think Hauppauge capture got a new Button end 2015 because of my nagging :)
[16:08:06 CEST] <BtbN> it clearly does something very wrong
[16:08:10 CEST] <die_hoernse> Conclusion: The feature behind said button is not fixing anything.
[16:09:05 CEST] <die_hoernse> Yep. But recapturing is not an option anyway. Need to work with the files I got.
[16:13:34 CEST] <ritsuka> I guess one could write a script to smooth the frame durations around those negative values
[16:13:49 CEST] <die_hoernse> It is tempting: it is totally obvious which sample durations have to be changed. I would also do this by hand in every file. That is what saturdays are made for. I bet all frames are in the stream and the negative ones just are not shown. But I do not know the tools to do it.
[16:15:46 CEST] <die_hoernse> ritsuka: I would not even script it. The past I showed is a benevolent case. Around analogous distortions it can get a bit messier (sample durations deviating by factors between 0.5 and 2 for prolonged periods). I'd like to Libre-Office-Calc this out and them C&Ping the new values ;)
[16:15:56 CEST] <ritsuka> mp4v2 lets you read end edit each duration of the mp4 file if I remember correctly
[16:16:00 CEST] <die_hoernse> *past -> paste
[16:17:06 CEST] <Regda> how can i limit the frames of an specific stream ?
[16:17:14 CEST] <die_hoernse> mp4v2? the muxer? so... remux with mp4v2, then use an API to access it?
[16:17:30 CEST] <Regda> -frames:v:1 180 or -frames:1:v 180 does not work
[16:17:31 CEST] <ritsuka> no, use the api directly to modify it
[16:18:23 CEST] <die_hoernse> sorry, what api specifically? i am really not very deep into it yet
[16:19:18 CEST] <die_hoernse> *"it" being the media codec universe. i am an industrial application dev
[16:21:13 CEST] <c_14> Regda: probably a bug. check/report it on trac
[16:21:37 CEST] <Regda> hm
[16:22:00 CEST] <die_hoernse> ritsuka: all mp4v2 api/lib htis i find go to googlecode to 404 :)
[16:22:11 CEST] <zamba> can ffmpeg grab directly off dv?
[16:22:34 CEST] <ChocolateArmpits> You mean via firewire?
[16:22:38 CEST] <zamba> yes
[16:23:35 CEST] <c_14> zamba: it should work if you build with libec1844 (i think that's what it was called)
[16:23:49 CEST] <c_14> libiec61883
[16:24:32 CEST] <ritsuka> die_hoernse: mm the public mp4v2 can only set the rendering offset, so you have to read each sample and rewrite it to a new file: create a new mp4, create new tracks with the same extradata as in the original file, and call MP4ReadSample and MP4WriteSample for each sample
[16:25:49 CEST] <ritsuka> probably you can do the same with ffmpeg too, I don't know which one is easier to learn
[16:26:29 CEST] <Regda> c_14: because the bug, i've read "-frames[:stream_specifier] framecount (output,per-stream)" maybe i missunderstand the (output,per-stream) ?
[16:26:30 CEST] <BtbN> you can't.
[16:26:44 CEST] <die_hoernse> Now that you write it... I remember, that is what I was avoiding to do and tried to write back in the void memory of the loaded file. Ok, thank yo. Seems I just have to learn to do that.
[16:27:02 CEST] <c_14> Regda: nah, it should work
[16:27:03 CEST] <BtbN> It's probably possible to hack it into the mov demuxer though
[16:27:20 CEST] <BtbN> die_hoernse, do you have a short sample that's damaged in that way?
[16:27:34 CEST] <die_hoernse> (I think I used mp4v2 or Bento... dont have the old project here right now)
[16:28:53 CEST] <die_hoernse> BtbN, sadly not. The shortest sample that is not very private is nearly 2 gigabyte.
[16:29:20 CEST] <BtbN> Does it have the issue in one of the first frames?
[16:29:37 CEST] <die_hoernse> i tried to edit a broken part out, but the editing process either crashes the editing software or alters the error to... still an error, but different
[16:29:57 CEST] <die_hoernse> yes, it does. but see above message
[16:30:28 CEST] <BtbN> then run qt-faststart on it, and then just cut the first few MB, or however much is needed for it to have a broken set of frames
[16:34:25 CEST] <die_hoernse> BtbN, never heard of it. I will have to read into it and then try to create a file that conserves the error. Do you have any prefered upload site? Size? I have an appointment soon, thus I must leave. Will bee working on it again tomorrow and would contact you then
[16:39:48 CEST] <Regda> c_14: can you take a look at the filter_complex part and the -frames parameter ?
[16:39:50 CEST] <Regda> http://pastebin.com/57YcpS5T
[16:40:51 CEST] <BtbN> die_hoernse, the ffmpeg ftp server seems to be down, anything is fine
[16:41:02 CEST] <BtbN> just use head to cut the file
[16:41:14 CEST] <BtbN> And see if there is still a broken frame in it after that
[16:42:11 CEST] <furq> Regda: there is only one video stream in the output
[16:42:13 CEST] <furq> just use -frames:v
[16:42:18 CEST] <die_hoernse> ok. i assume "head" is an option anywhere in qt-faststart. will do and look for you again. thank you and have a nice day :)
[16:42:21 CEST] <vade> hi - im using the new codecpar API, and im decoding a video stream with my own manually created codec context using avcodec_parameters_to_context from the codecpar on my target stream I want to be decoding. Codec par does not have a frame_rate struct entry, and intersringly, my streams->codec->framerate differs from my customCodecContext->framerate - is this expected?
[16:42:36 CEST] <furq> or -frames:v:0 since you seem to want to be overly verbose
[16:42:56 CEST] <c_14> Regda: get rid of the -r:0 and -r:1
[16:43:31 CEST] <vade> basically, I do something like avformat_alloc_context, avformat_open_input, avformat_find_stream_info, av_find_best_stream. Then, I avcodec_alloc_context3 to make my own codec context, and assign avcodec_parameters_to_context from my best stream to my newly created context
[16:43:32 CEST] <c_14> (the input ones)
[16:43:36 CEST] <BtbN> die_hoernse, no, litteraly the head command. It has an option to operate on bytes instead of lines.
[16:43:59 CEST] <vade> at that point, avcodec_open2 and my streams codec vs my custom codec have some differing settings.
[16:44:15 CEST] <die_hoernse> uhm.. ok. I'll ask if i don't find it
[16:45:10 CEST] <die_hoernse> but you mean qt-faststart. the application. right? or an api or what?
[16:45:34 CEST] <furq> Regda: actually, don't use -frames:v at all, it won't do what you think it does
[16:45:40 CEST] <furq> unless you want the output file to be 180 frames long
[16:45:51 CEST] <BtbN> die_hoernse, the tool that's part of ffmpeg, yes.
[16:46:11 CEST] <BtbN> It moves the mp4 header to the beginning of the file, otherwise cutting it like that breaks it
[16:47:36 CEST] <die_hoernse> Now I got it. Thank you. Sorry, I really am green in this field.
[16:47:58 CEST] <die_hoernse> Ok, gotta go. Thank you very much for you kind help. See you soon :)
[16:49:59 CEST] <Zaneo> If I have a single const uint_8 pointer for my data (from an AVFrame, containing YUV420P), do I need to manually calculate the pointers for the other channels, and pass that to sws_scale?
[16:50:31 CEST] <Zaneo> const uint8_t pointer*
[16:51:41 CEST] <vade> nope, you can just send frame.getAvFrame()->data, lineSize, etc
[16:53:45 CEST] <Zaneo> Darn
[16:54:16 CEST] <vade> I mean, im sure you can put whatever you want in there
[16:54:43 CEST] <vade> if you want to just pixel format convert or scale a frame you dont need anything too fancy so to speak
[16:55:35 CEST] <Zaneo> I just want to convert pixel format
[16:57:02 CEST] <vade> sure, so you do someting like : https://gist.github.com/vade/12cff17a193fd1d7d407e26eb412b14d
[16:57:38 CEST] <vade> frame.getAvFrame is just an accessor for an AVFrame*
[16:58:21 CEST] <vade> that does YUV -> RGB
[16:58:21 CEST] <Zaneo> I have something similar, https://git.io/vogLE
[16:58:30 CEST] <Zaneo> But I'll try what you've suggested, thanks
[16:59:18 CEST] <vade> i think AVPicture has been deprecated or isnt currently the suggested. Im not entirely sure, it depends on if you are using newer FFMPEG code base / api stuff
[16:59:30 CEST] <Regda> furq: i want that the v:1 stream to be 180 frames long
[16:59:38 CEST] <vade> honestly im not 100% positive on the nuances but i recall reading it somewhere :)
[16:59:42 CEST] <Regda> not the output file
[17:00:39 CEST] <furq> that's not what -frames does
[17:01:09 CEST] <Regda> uhm ? but in the documentation stands it would work per stream ?
[17:01:21 CEST] <Regda> i am confused
[17:02:32 CEST] <furq> per output stream
[17:02:40 CEST] <furq> http://vpaste.net/2wh6S
[17:02:45 CEST] <furq> i just tested that and it works fine
[17:03:14 CEST] <furq> it still gives the thread_queue_size warning but i'm pretty sure you can ignore that
[17:03:19 CEST] <furq> i increased it and it didn't run any faster
[17:04:41 CEST] <Regda> yeah, by increasing the threa_queue_size on an infinity stream it runs slower on my machine
[17:04:52 CEST] <furq> that's not the one it's blocking on
[17:05:02 CEST] <furq> it's blocking on %06d.png
[17:05:18 CEST] <furq> either way it doesn't seem to make any difference
[17:11:26 CEST] <Zaneo> vade: Is the align 64 specific to your application?
[17:12:31 CEST] <vade> hm?
[17:13:39 CEST] <Zaneo> for the av_frame_get_buffer, you align to 64 for the buffer
[17:15:18 CEST] <vade> oh. ha. yea. Just experimenting with alignment. I had issues prior
[17:15:41 CEST] <vade> im also vending frames to an external API that likes things aligned
[17:15:48 CEST] <Zaneo> Sweet it works now, thanks for the help
[17:15:50 CEST] <vade> so you can safely ignore I think
[17:15:54 CEST] <vade> awesome!
[17:20:26 CEST] <arduinoob> \part
[18:46:40 CEST] <xxx_> Hi. I need split media file, convert parts and then join. But result have some sound artifacts, how to avoid them . it's my script
[18:46:42 CEST] <xxx_> #!/bin/sh
[18:46:42 CEST] <xxx_> set -o xtrace
[18:46:42 CEST] <xxx_> SRC=~/vimperor/shared0/src/test/resources/audio._kuznechik.mp3
[18:46:42 CEST] <xxx_> #SRC=~/vimperor/shared0/src/test/resources/000.orig.5352357791787324393.mp3
[18:46:42 CEST] <xxx_> RES=/tmp/aa.m4a
[18:46:44 CEST] <xxx_> rm -f $RES /tmp/p*
[18:46:46 CEST] <xxx_> #ffprobe -show_frames -select_streams a -print_format csv -show_entries frame=index,pkt_dts_time ~/vimperor/shared0/src/test/resources/audio._kuznechik.mp3
[18:46:51 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 0.025057 -ss 0.0 -t 0.967596 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p0.ts
[18:46:54 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 1.018776 -ss 1.018776 -t 0.96653 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p1.ts
[18:46:57 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 2.011429 -ss 2.011429 -t 0.96653 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p2.ts
[18:47:00 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 3.004082 -ss 3.004082 -t 0.992653 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p3.ts
[18:47:05 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 4.022857 -ss 4.022857 -t 0.966531 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p4.ts
[18:47:08 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 5.015510 -ss 5.015510 -t 0.966531 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p5.ts
[18:47:11 CEST] <xxx_> avconv -analyzeduration 50000000 -probesize 50000000 -i $SRC -force_key_frames 6.008163 -ss 6.008163 -t 0.966531 -c:a aac -strict -2 -b:a 128k -ac 2 -vn -f mpegts -y /tmp/p6.ts
[18:47:14 CEST] <xxx_> avconv -i concat:/tmp/p0.ts\|/tmp/p1.ts\|/tmp/p2.ts\|/tmp/p3.ts\|/tmp/p4.ts\|/tmp/p5.ts\|/tmp/p6.ts -strict experimental -fflags +genpts -flags +global_header -c copy -bsf:a aac_adtstoasc -y $RES
[18:47:19 CEST] <xxx_> vlc $RES
[18:49:58 CEST] <Regda> xxx_: better using pastebin as irc for long codes
[18:50:11 CEST] <durandal_1707> You are not using ffmpeg
[18:51:00 CEST] <xxx_> hi
[18:51:01 CEST] <xxx_> $ avconv -version
[18:51:02 CEST] <xxx_> ffmpeg version 2.8.6-1ubuntu2 Copyright (c) 2000-2016 the FFmpeg developers
[18:51:02 CEST] <xxx_> built with gcc 5.3.1 (Ubuntu 5.3.1-11ubuntu1) 20160311
[18:53:44 CEST] <hid|ninja> :o
[18:56:49 CEST] <durandal_1707> omg
[18:59:29 CEST] <durandal_1707> xxx_: there's not much that can be done to avoid artifacts, except splitting at different points
[19:17:46 CEST] <iive> i lived to see avconv linking to ffmpeg :D
[19:23:57 CEST] <CoJaBo> Well I suppose 99.9999999999999999945789891375724778299627359956502914429% ought to be good enough for anyone, right? <_<
[20:28:51 CEST] <ChocolateArmpits> xxx_: you should probably use the included segmenter to split files https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-ssegment
[20:29:13 CEST] <ChocolateArmpits> then convert them and stitch back together
[20:55:45 CEST] <xxx_> I know about segmenter I try to use it with same points but then, after encode each part to aac and join music contains artifacts
[20:56:03 CEST] <xxx_> ffmpeg -i /home/xxx/vimperor/shared0/src/test/resources/000.orig.5352357791787324393.mp3 -strict -2 -codec aac -map 0 -f segment -segment_times 1.018776,2.011429,3.004082,4.022857,5.015510,6.008163,7.000816,8.019592,9.012245,10.004898,11.023673,12.016327,13.008980,14.001633,15.020408,16.013061,17.005714,18.024490,19.017143,20.009796,21.002449,22.021224,23.013878,24.006531,25.025306,26.017959,27.010612,28.003265,29.022041,30.014694,31.007347,32.000000,33.018776,3
[20:56:03 CEST] <xxx_> 4.011429,35.004082,36.022857,37.015510,38.008163,39.000816,40.019592,41.012245,42.004898,43.023673,44.016327,45.008980,46.001633,47.020408,48.013061,49.005714,50.024490,51.017143,52.009796,53.002449,54.021224,55.013878,56.006531,57.025306,58.017959,59.010612,60.003265 /tmp/out%d.nut
[20:56:26 CEST] <xxx_> ffmpeg -analyzeduration 50000000 -probesize 50000000 -i /tmp/out0.nut -c:a aac -strict -2 -b:a 256k -ac 2 -vn -fflags +genpts -f mpegts -fflags +genpts -flags +global_header -y /tmp/p0.ts
[20:57:40 CEST] <xxx_> first command with segmenter contains "-codec copy" not "-codec aac" it's just copypast from my console. :)
[21:03:44 CEST] <zamba> i'm having issues with A/C sync with all my captures.. i have no idea what i'm doing wrong, but A/V is always out of sync
[21:04:00 CEST] <zamba> dvgrab --format raw - | /usr/bin/ffmpeg -f dv -i - -f mp4 -deinterlace filename.mp4
[21:04:03 CEST] <zamba> this is the simple command i'm using
[21:07:00 CEST] <kepstin> zamba: how is it out of sync? constant offset, or getting worse over time? Is it in sync if you just dump the raw DV to a file and play that?
[21:15:09 CEST] <zamba> kepstin: yeah, the raw dv file seems to be in sync
[21:15:42 CEST] <zamba> kepstin: it starts out seemingly in sync.. but it looks like it gets worse.. also a lot of glitches in the sound.. distortion..
[21:17:06 CEST] <kepstin> weird. Does the dvgrab stuff need to run realtime?
[21:17:23 CEST] <kepstin> if so, it might be that the ffmpeg encoding step is simply too slow, so data's being lost
[21:17:48 CEST] <zamba> i wonder if these are a hint: [mp4 @ 0x138d140] Non-monotonous DTS in output stream 0:1; previous: 122240341, current: 96776192; changing to 122240342. This may result in incorrect timestamps in the output file
[21:17:55 CEST] <zamba> lots and lots of those
[21:20:53 CEST] <kepstin> zamba: yeah, that pretty much means that something's gone wrong prior to the output; either the dv input is screwed up, or something in the filter chain has gone wrong
[21:21:13 CEST] <kepstin> (note that I'd recommend using "-vf yadif" instead of "-deinterlace" in most cases)
[21:22:17 CEST] <furq> or -vf nnedi if you don't mind it taking forever
[21:22:27 CEST] <furq> oh nvm this is realtime so don't do that
[21:24:07 CEST] <zamba> well.. i can do it in two steps
[21:24:12 CEST] <zamba> first dvgrab and then ffmpeg
[21:24:21 CEST] <kepstin> if you have the disk space, that would be ideal
[21:24:36 CEST] <kepstin> since doing h264 encoding at realtime means using a lower quality encoding mode
[21:24:57 CEST] <zamba> how does ffmpeg handle the splitting of the files that dvgrab does?
[21:25:32 CEST] <kepstin> you can use the concat input format or demuxer, or just combine them with 'cat' and send them to stdin
[21:25:39 CEST] <zamba> ah, ok
[21:25:43 CEST] <zamba> what about options for ffmpeg?
[21:26:32 CEST] <zamba> best quality/size ratio.. this is for archiving.. i'm digitalizing old DV tapes.. so it would be nice to have decent quality
[21:28:09 CEST] <furq> -crf is the general quality setting
[21:28:16 CEST] <furq> 23 is the default, lower values are higher quality/larger size
[21:28:34 CEST] <furq> there's also -preset but if you're already getting dropouts then you probably don't want to use anything slower
[21:28:50 CEST] <zamba> furq: well, i won't be doing this in realtime no more
[21:28:58 CEST] <zamba> so i can afford stuff taking longer
[21:29:06 CEST] <furq> well yeah -preset veryslow if you don't mind it taking a very long time
[21:29:16 CEST] <zamba> furq: what's a "very long time"?
[21:29:22 CEST] <furq> depends on the input and your cpu
[21:29:28 CEST] <furq> but it's called "veryslow" for a reason
[21:29:35 CEST] <zamba> can you show me an example of a full command?
[21:30:05 CEST] <zamba> cat filename*.dv | ffmpeg -i - <fill in some more options> -preset veryslow output.mp4
[21:30:18 CEST] <furq> -i foo.mkv -c:v libx264 -crf 18 -preset veryslow -vf nnedi bar.mp4
[21:30:34 CEST] <furq> nnedi is incredibly slow but it should look nicer than yadif
[21:30:43 CEST] <zamba> what about audio codec selection?
[21:31:00 CEST] <viric> furq: when nnedi came into ffmpeg? 3.0?
[21:31:02 CEST] <furq> i believe that defaults to the builtin aac encoder at 128kbps
[21:31:04 CEST] <furq> and yeah i think so
[21:31:20 CEST] <furq> it's single-threaded though so it's comically slow
[21:31:31 CEST] <zamba> oh, btw.. unrelated.. will dvgrab terminate when it's done capturing the tape?
[21:31:39 CEST] <furq> probably, i've never used it
[21:37:29 CEST] <zamba> [Parsed_nnedi_0 @ 0x47578c0] No weights file provided, aborting!
[21:37:30 CEST] <zamba> [AVFilterGraph @ 0x4757e80] Error initializing filter 'nnedi'
[21:38:10 CEST] <zamba> ffmpeg version 3.0.1-static http://johnvansickle.com/ffmpeg/  Copyright (c) 2000-2016 the FFmpeg developers
[21:39:05 CEST] <furq> https://ffmpeg.org/ffmpeg-filters.html#nnedi
[21:39:08 CEST] <furq> you need the weights file listed there
[21:39:25 CEST] <furq> or alternatively just use yadif, it's much faster and it looks reasonably good
[21:39:51 CEST] <furq> but yeah if you do use nnedi then -vf nnedi=weights=nnedi3_weights.bin
[21:43:05 CEST] <zamba> ok, got it running now, at least
[21:43:22 CEST] <zamba> errors like this, though:
[21:43:24 CEST] <zamba> [dvvideo @ 0x4b75b40] Concealing bitstream errors
[21:43:26 CEST] <zamba> [dvvideo @ 0x4b75b40] AC EOB marker is absent pos=65
[21:58:50 CEST] <kepstin> zamba: if you're doing permanent archiving, you might actually want to look at using a lossless codec on the otherwise unprocessed DV data, maybe "ffv1"
[21:59:18 CEST] <kepstin> h264/mp4 is good if you want to post videos online for folks to watch tho
[22:00:30 CEST] <kepstin> since stuff like deinterlacing and lossy compression is always getting better - you might some day see this video and go "oh, man, those yadif artifacts are annoying, I wish I could re-do the deinterlacing, and then maybe use h.269 codec instead"
[22:16:12 CEST] <hyponic> Can nvidia GT cards be used for multiple stream encoding? bypassing the 2 stream limit?
[22:16:36 CEST] <jnorthrup> ffv1 <3
[22:17:48 CEST] <hyponic> jnorthrup ffv1 ?
[22:18:45 CEST] <zamba> kepstin: do you have the command options for that?
[22:19:03 CEST] <zamba> kepstin: i was thinking about doing one archiving format and one online format
[22:19:16 CEST] <zamba> kepstin: so one lossless and one lossy
[22:19:32 CEST] <jnorthrup> ffv1 as an interim codec in nut format has been my go-to workaround for a decade :)
[22:20:05 CEST] <kepstin> zamba: just use -c:v ffv1 to pick the codec, and put it in an mkv or nut or something. Pick a suitable audio codec - either flac, or just straight pcm, or whatnot.
[22:20:13 CEST] <Regda> why using nvidia gt ?
[22:20:19 CEST] <Regda> why not gtx ?
[22:20:26 CEST] <Regda> or quadro.......
[22:20:33 CEST] <zamba> kepstin: just that?
[22:20:37 CEST] <zamba> kepstin: no other options?
[22:21:26 CEST] <zamba> kepstin: i'm new to ffmpeg and quite tired of messing up.. so i need to be spoon fed options :)
[22:21:27 CEST] <furq> the defaults should be fine
[22:21:45 CEST] <furq> https://trac.ffmpeg.org/wiki/Encode/FFV1#FFV1version3
[22:21:49 CEST] <furq> if you want to be sure
[22:21:58 CEST] <kepstin> hyponic: the 2-stream count on the encoding is a software/marketting limit. It's only lifted on the "quadro" branded cards, iirc.
[22:22:26 CEST] <furq> does 2-pass give an appreciable compression increase for ffv1
[22:23:00 CEST] <furq> i assume it makes no difference with -g 1 at least
[22:23:00 CEST] <hyponic> kepstin is there a workaround for that?
[22:23:21 CEST] <kepstin> hyponic: not that I know of.
[22:23:55 CEST] <jnorthrup> how would 2 pass change either  pass?
[22:24:21 CEST] <kepstin> I have no idea why ffv1 even has a 2-pass mode, the usual reason for that is for rate-control in lossy codecs...
[22:24:28 CEST] <furq> https://en.wikipedia.org/wiki/FFV1#Compression_details
[22:24:39 CEST] <kepstin> you'd think anything a 2-pass ffv1 mode does could be done by just adding lookahead :/
[22:24:39 CEST] <furq> i assume it's something to do with the context model mentioned there
[22:24:50 CEST] <furq> although yeah i can't imagine it's much use
[22:25:11 CEST] <hyponic> kepstin if it is a software limitation there must be a "hack" for that :D
[22:25:16 CEST] <zamba> i went for this: ffmpeg -i - -c:v ffv1 -c:a flac output.nut
[22:25:24 CEST] <furq> hyponic: have you tried drawing on the gpu with a pencil
[22:25:26 CEST] <jnorthrup> you could run ffv1 encode first pass then switch over to your x264 for 2nd pass?
[22:25:46 CEST] <furq> that doesn't seem like a thing that works
[22:26:09 CEST] <hyponic> furq i don't have physical access to the card
[22:26:20 CEST] <furq> shame
[22:26:34 CEST] <zamba> is my command sane?
[22:26:39 CEST] <furq> zamba: looks fine
[22:26:45 CEST] <kepstin> hyponic: it might be enforced in firmware on the card, I've heard that *some* cases where the quadro and a consumer card were otherwise identical, you could cross-flash firmare. I don't think that applies to any modern cards.
[22:27:26 CEST] <hyponic> kepstin i have the GT970
[22:36:45 CEST] <jfindley> Hello, can anyone explain to me why the first bits of a file allegedly encoded with flac contain OggS, and further in the head of the file there is a line "reference libFLAC 1.2.1"?
[22:36:45 CEST] <zamba> hehe, using -c:v ffv1 and -c:a flac actually produces a larger file than the original DV files.... :)
[22:38:40 CEST] <jnorthrup> yeah ffv1 is lossless dct
[22:39:20 CEST] <jfindley> nevermind, seems ogg is just a container =/
[22:40:25 CEST] <furq> jfindley: presumably it's ogg flac, which isn't very widely used
[22:40:44 CEST] <furq> you can just remux it to flac if it's a problem
[22:41:32 CEST] <jfindley> The weird thing is, I'm testing an alpha speech to text API and if I specify the encoding as LINEAR16 it processes this file fine, but if I specify FLAC encoding, it does not
[22:42:07 CEST] <jfindley> So I'm trying to figure out why that might be, but I have no experience with ogg or flac, so not much to go on =/
[22:42:30 CEST] <jfindley> Thanks for the help, though.
[22:48:37 CEST] <kepstin> jfindley: if you have some api that needs a certain input, just pipe everything through ffmpeg and have ffmpeg convert/deocde it :)
[22:50:56 CEST] <jfindley> kepstin: That's the idea, but personally I prefer pydub which handles the interesting bits in a really decent way, using avconv as the backend.
[22:52:14 CEST] <kepstin> you mean ffmpeg? 'avconv' is the tool from libav :)
[22:52:44 CEST] <kepstin> looks like it can use either, i guess
[23:18:57 CEST] <CoJaBo> "[webm @ 0x3e2a000] Non-monotonous DTS in output stream 0:0; previous: 59966, current: 59466; changing to 59966. This may result in incorrect timestamps in the output file."
[23:19:07 CEST] <CoJaBo> It does, and the effect is... quite trippy.
[23:36:11 CEST] <zamba> with dv it's simple to just grab the raw video/audio with dvgrab.. i have another usb capture card to get video/audio from vhs cassettes.. i don't want to perform realtime encoding.. how can i get this to a "raw" format.. and then perform the conversion later on?
[23:37:15 CEST] <zamba> meaning a format and a container that's fast.. to avoid drops
[23:40:42 CEST] <kepstin> zamba: a good choice is something simple like 'ffvhuff' as a video codec. That's a really fast lossless codec that'll reduce the size a bit. Then just use, I dunno, PCM audio or something, in an mkv or nut container.
[23:40:56 CEST] <kepstin> you'll just have to test to make sure you have disk bandwidth and space for your target usage
[23:42:10 CEST] Action: kepstin assumes the capture card is returning something like raw YUV 4:2:2 or 4:2:0 data
[23:42:19 CEST] <zamba> hehe, and again i need the full options.. <input> -c:v ffvhuff -c:a pcm ouput.nut ?
[23:42:32 CEST] <zamba> kepstin: yeah, that sounds familiar
[23:42:59 CEST] <kepstin> '-c:a pcm_s16le' probably. neither encoder needs any options
[23:43:07 CEST] <zamba> awesome
[23:43:34 CEST] <zamba> the only video filter could be simple cropping
[23:43:46 CEST] <zamba> just to get rid of black borders and some artifacts
[23:43:52 CEST] <kepstin> some capture cards have onboard mpeg encoders; if you can grab the raw video realtime, I'd avoid using the mpeg stream
[23:44:00 CEST] <kepstin> is this ntsc?
[23:44:07 CEST] <zamba> you ask more than i can answer
[23:44:26 CEST] <kepstin> ok. what country is the video from? :)
[23:44:33 CEST] <zamba> how can i norway
[23:44:35 CEST] <zamba> hehe
[23:44:38 CEST] <zamba> norway :)
[23:44:44 CEST] <zamba> so i guess it's PAL?
[23:45:42 CEST] <kepstin> yeah, pal then. You'll want to use '-vf crop=704:576:8:0' probably, if your input is 720x576, which is typical
[23:46:10 CEST] <zamba> shouldn't i just adjust the crop value based on visual inspection?
[23:46:13 CEST] <kepstin> might end up also cropping some vhs noise off the top or bottom, but that '704:576' will get you the nominal video area
[23:46:27 CEST] <zamba> just remove all black borders?
[23:46:48 CEST] <kepstin> personally, I'd just grab the full-size video in the initial capture, then do the cropping on the re-encode after some visual inspection
[23:47:08 CEST] <kepstin> the 'cropdetect' filter in ffmpeg is also useful, it can do some automatic guessing of likely crop rectangles
[23:47:25 CEST] <zamba> yeah.. but you crop based on visual inspection, right?
[23:47:43 CEST] <kepstin> if you can afford to visually inspect everything, then sure
[23:48:13 CEST] <kepstin> if you can't, 'crop=704:576:8:0' will grab the nominal picture area, which might still have some artifacts sometimes :)
[23:48:49 CEST] <kepstin> The "cropdetect" filter is basically a way to semi-automate the visual inspection step. It's not perfect, but it's often good.
[23:49:38 CEST] <zamba> yeah, i've experienced that myself
[23:49:47 CEST] <zamba> it's an ok starting point, but i have to manually adjust
[23:51:30 CEST] Action: kepstin deals with mostly ntsc - american, japanese - stuff
[23:51:59 CEST] <kepstin> it's annoying there, because different devices pick different video lines for the '480' lines of video height, so you often get 1 or 2px black bars on the top or bottom
[23:52:04 CEST] <kepstin> that you just have to deal with :/
[23:53:03 CEST] <kepstin> (apparently professional  capture stuff will often capture 486 lines instead, to cover everything that might be needed)
[23:56:08 CEST] <zamba> what do you expect the disk bandwidth requirements to be?
[23:57:03 CEST] <zamba> i was thinking about shuffling this directly to an usb disk
[23:59:15 CEST] <kepstin> well, raw yuv420p pal video is about 15mb/s, audio will add <1mb/s to that. And huffyuv compression will probably bring it down to about 75-80% size I think?
[23:59:25 CEST] <echo1877> hi there ffmpeg experts, I've been having an issue linking against the current snapshot for some reason
[23:59:31 CEST] <kepstin> should be ok on USB, even 2.0 will do 25mb/s peak
[23:59:44 CEST] <echo1877> i'm building for iOS, here's the error I'm getting: Undefined symbols for architecture arm64:
[23:59:45 CEST] <echo1877>   "_ff_adpcm_mtaf_stepsize", referenced from:
[23:59:45 CEST] <echo1877>       _adpcm_mtaf_expand_nibble in libavcodec.a(adpcm.o)
[00:00:00 CEST] --- Sat Jun 18 2016


More information about the Ffmpeg-devel-irc mailing list