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

[burek]

[00:14:38 CET] <realies> trying to fix a mxf file, but https://dpaste.de/QZ9N/raw
[00:15:18 CET] <realies> any ideas?
[00:16:42 CET] <JEEB> seems to lack required headers and is corrupted. not sure how MXF works, so I don't know how you can cut it
[00:17:38 CET] <realies> i think camera power was lost and it didn't finish writing
[00:21:22 CET] <realies> i can find this http://aeroquartet.com/movierepair/fix-mxf-files
[00:21:36 CET] <realies> but they seem to charge more than $350 for doing it
[00:23:00 CET] <realies>  -vcodec dnxhd -b 220M -f mov fixed.mov doesn't find a valid frame either
[00:23:12 CET] <realies> [mpeg2video @ 0x3e68ec0] Invalid frame dimensions 0x0. \n Error while decoding stream #0:0: Invalid data found when processing input
[00:23:35 CET] <JEEB> yes, it lacks the headers
[00:23:56 CET] <JEEB> I'm just not sure if they're repeated in the file or if the file format has them separately (usually at the end of the file)
[00:25:42 CET] <realies> file came from a panasonic pmw 2
[00:25:51 CET] <realies> wonder if i find working footage from it if that wouldnt help
[00:26:21 CET] <JEEB> usually that's what fixing such stuff starts with since then you could extract the decoder initialization data if the parameters match otherwise
[00:29:38 CET] <realies> difficult to get one, assuming all panasonic pmw cameras would have identical headers for mxf files, no?
[00:30:01 CET] <JEEB> it's the initialization data for MPEG-2 Video specifically
[00:30:18 CET] <JEEB> although I don't remember how much stuff there is in MPEG-2 Video compared to AVC
[00:30:20 CET] <realies> so the outside mxf container doesn't matter?
[00:30:22 CET] <JEEB> AVC had a lot of stuff
[00:30:47 CET] <JEEB> with enough care and a hex editor you should be able to implant those headers somewhere, they're the primary part
[00:31:06 CET] <JEEB> most likely you need some content from the same camera with the same resolution/frame rate/bit depth
[00:31:14 CET] <JEEB> and interlacing mode etc
[00:32:37 CET] <realies> oh :S
[00:35:57 CET] <realies> I'll try and get some working content
[00:36:04 CET] <realies> couldn't find samples online
[00:36:28 CET] <realies> I have never done hex work on video files
[00:36:46 CET] <JEEB> yea, fixing stuff ends up being manual work often
[00:37:06 CET] <JEEB> where you need to know about the structure of the container you're dealing with
[00:37:16 CET] <JEEB> (And of the video format in question)
[00:37:21 CET] <realies> how does one find the boundaries of the header and know where to implant it when let's say the file cuts of mid-way through the streams
[00:37:30 CET] <realies> i see
[00:37:50 CET] <JEEB> you'd look into how those headers are usually stored in MXF
[00:38:15 CET] <JEEB> then decide if you want to go that way, or if you try to hack around it and extend the first video packet to also have the headers there first
[00:38:25 CET] <JEEB> in-band vs out-of-band basically
[00:40:12 CET] <realies> so injecting it in the beginning might make the decoder aware of what it's dealing with and not complain that it know nothing?
[00:40:20 CET] <JEEB> yes
[00:40:28 CET] <realies> knows*
[00:40:31 CET] <realies> makes sense
[00:41:13 CET] <JEEB> or maybe not extend a packet but add a new packet and move the rest one packet further (depends on how many entities the initialization data is in MPEG-2 Vide)
[00:41:16 CET] <JEEB> *Video
[00:41:27 CET] <realies> imagine sourcing the correct information being very difficult to find and understand
[00:41:29 CET] <JEEB> in AVC I think you need at least three different pieces of init data
[00:41:34 CET] <JEEB> or was it two?
[00:42:10 CET] <JEEB> I think it shouldn't be too *difficult* , just requires effort and reading about the format by either means of specification or the relevant parser code
[00:43:19 CET] <realies>  Stream #0:0: Video: mpeg2video, none(tv, top first), 1920x1080, 50000 kb/s, 25 fps, 25 tbr, 1200k tbn, 50 tbc
[00:43:25 CET] <realies> how does it know all that when... it doesnt?
[00:43:36 CET] <realies> or mpeg2video is not the actual stream
[00:44:04 CET] <JEEB> oh
[00:44:40 CET] <JEEB> ah
[00:44:45 CET] <JEEB> that info comes from the container
[00:44:46 CET] <JEEB> most likely
[00:44:51 CET] <JEEB> since it lacks the pixel format
[00:45:02 CET] <realies> interesting
[00:45:04 CET] <JEEB> containers generally have resolution and timestamps etc
[00:45:11 CET] <JEEB> and lavf can initialize the stream with that first
[00:45:17 CET] <JEEB> which is why that info shows up
[00:45:29 CET] <realies> so how come the container is there, but header isn't? what's the difference?
[00:45:33 CET] <realies> the stream header you mean?
[00:45:49 CET] <JEEB> so there's some generic stream-specific metadata in the container
[00:45:53 CET] <realies> i see the container as the outer layer of the file, containing all streams and information about them
[00:45:56 CET] <JEEB> but there's no data available from the stream itself
[00:46:32 CET] <realies> so the stream header
[00:46:51 CET] <JEEB> you don't *need* to have the stream info in the container, but generally some basic info is written into most containers
[00:47:04 CET] <JEEB> like width/height/general stream type
[00:47:07 CET] <realies> sure
[00:47:26 CET] <realies> so the stream header which should be at the end of the file is missing
[00:47:27 CET] <JEEB> which is why it knows it's MPEG-2 Video, 1920x1080
[00:47:41 CET] <JEEB> that's how it looks like, although I have no real knowledge of MXF
[00:47:50 CET] <JEEB> last I looked into it, it seemed like a mess
[00:48:04 CET] <realies> well i have more knowledge than i had half an hour ago, so thanks
[00:48:26 CET] <JEEB> np
[00:48:53 CET] <realies> wonder if i can do something with it without the missing header
[00:49:13 CET] <JEEB> can't really initialize the decoder without that
[00:49:15 CET] <JEEB> as you can see
[00:49:33 CET] <realies> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[00:49:41 CET] <realies> perhaps it does repeat but in really long intervals?
[00:49:51 CET] <realies> or unlikely
[00:50:26 CET] <JEEB> feel free to set both very large
[00:50:50 CET] <JEEB> and see if it does anything else than fail similarly or use a lot of time
[00:51:26 CET] <realies> will do, "The PMW-300K1 captures Full HD 1920 x 1080 video using the broadcast-quality MPEG-2 HD 422 codec at 50 Mbps. It creates industry-standard MXF files. The camcorder can also record Full HD video in MPEG-2 HD 420 at 35 Mbps."
[00:51:36 CET] <realies> "broadcast-quality MPEG-2 HD 422 codec at 50 Mbps", very descriptive
[00:51:46 CET] <JEEB> well that tells us the chroma subsampling
[00:51:55 CET] <JEEB> but doesn't tell us if it's 8 or 10 bit
[00:52:04 CET] <JEEB> oh
[00:52:09 CET] <JEEB> "can also do 420"
[00:52:10 CET] <JEEB> :<
[00:52:13 CET] <JEEB> so it's one or the other
[00:52:21 CET] <JEEB> oh, it's the 50mbps one
[00:52:23 CET] <JEEB> so 4:2:2
[00:53:55 CET] <realies> 1920x1080i50 50Mbit, codec still missing
[00:54:18 CET] <realies> at least got the camera model, checking specs
[00:54:18 CET] <JEEB> the video format is something that the MXF told us
[00:54:22 CET] <JEEB> MPEG-2 Video
[00:55:02 CET] <JEEB> so yea, time to see how many things are required for decoding I guess?
[00:55:06 CET] <JEEB> in teh initialization data
[00:55:34 CET] <JEEB> and seeing if filling the stuff in manually makes any sense
[00:55:40 CET] <JEEB> if it's anything like AVC, probably not
[00:57:46 CET] <realies> Movies Format:	112 Mbps max., MPEG-4 AVC/H.264, UDF, XAVC, XAVC-I mode: CBG
[00:57:50 CET] <realies> it could be both ha
[00:58:10 CET] <JEEB> well the MXF you have identifies as MPEG-2 Video
[00:58:52 CET] <realies> oh!
[00:59:14 CET] <realies> xdcam?
[00:59:19 CET] <JEEB> so yes, teh stream specific headers in the container do tell you something
[00:59:31 CET] <JEEB> (50mbps, mpeg-2 video, 1920x1080
[01:00:07 CET] <realies> mpeg-4 avc/h.264 is not mpeg-2 though
[01:00:15 CET] <JEEB> definitely
[01:00:24 CET] <JEEB> but your MXF says 50mbps mpeg-2 video as far as it can be parsed
[01:00:25 CET] <realies> so possibilities reduced to UDF, XAVC, XAVC-I mode: CBG
[01:00:54 CET] <JEEB> it most likely isn't any of those
[01:01:01 CET] <JEEB> the thing you mentioned first sounds most likely
[01:01:15 CET] <realies> xdcam?
[01:01:20 CET] <JEEB> "MPEG-2 HD 422 codec at 50 Mbps"
[01:01:35 CET] <JEEB> because that matches the resolution, video format and bit rate
[01:01:59 CET] <realies> it's not 4:2:0 as that is up to 35Mbps according to what i've read
[01:06:25 CET] <JEEB> yup
[01:07:04 CET] <realies> whoops, running ffmpeg with a huge analyzeduration/probesize killed a vm
[01:09:44 CET] <realies> https://dpaste.de/67zy/raw
[01:09:52 CET] <realies> nothing useful that i can see
[01:10:04 CET] <JEEB> yea
[01:10:17 CET] <JEEB> lacks video stream's initialization data = goes nowhere
[01:11:12 CET] <realies> so strange that goes by the end of the file
[01:11:24 CET] <realies> can't see why that's useful
[01:11:39 CET] <JEEB> if it's written into an index structure or so I guess?
[01:11:51 CET] <JEEB> standard mov/mp4 also does this
[01:12:21 CET] <realies> welp
[01:12:22 CET] <realies> bad
[10:09:47 CET] <_raven__> sfan5 + others: this is the log output of the corrupted transcoding: https://pastebin.com/Tm5s865q BUT the output should be about 75 minutes. it seems to have crashed due to out of memory on 8gb
[10:10:20 CET] <_raven__> the successful transcoding runs on a machine with only 4gb ram
[12:20:17 CET] <sfan5> no obvious errors indeed
[12:20:28 CET] <sfan5> _raven__: have you tried a more up-to-date ffmpeg?
[12:28:47 CET] <_raven__> not yet cause it is the stock deb9 package and already newer than the (working) reference on ubuntu16.04lts. running a strace test at the moment. maybe that will show something
[13:17:57 CET] <sine0> hello video fans. I have a question that is probably off topic but you are the guys in the know
[13:18:27 CET] <durandal_1707> yes?
[13:18:32 CET] <sine0> for forgive me in advance. there is this video and I have removed the token on the end https://fpdl.vimeocdn.com/vimeo-prod-skyfire-std-us/01/4520/9/247604141/895690196.mp4?token=
[13:19:02 CET] <sine0> which is access toke etc. how can I download this video to my box, can I use ffmpeg or curl
[13:19:16 CET] <durandal_1707> that is illegal!
[13:19:18 CET] <sine0> im not sure where the saving of streamed media fits in
[13:19:24 CET] <sine0> durandal_1707: its not
[13:19:27 CET] <kepstin> sine0: use youtube-dl
[13:19:36 CET] <sine0> kepstin: exactly right, so i tried that and it does not work
[13:19:42 CET] <sine0> because that is my go to python
[13:19:55 CET] <kepstin> sine0: well, then file a bug with them? :/
[13:20:14 CET] <kepstin> note that it takes the video playback page, not the direct stream link
[13:20:45 CET] <sine0> if i paste it in directly with the key to a new browser incog, it plays direct in
[13:21:21 CET] <kepstin> it that works, then you ought to be able to just wget it (unless they're checking user agent or something)
[13:21:27 CET] <sine0> ok ill try
[13:22:11 CET] <sine0> operation not permitted. prob useragent like you said
[13:22:18 CET] <sine0> curl?
[13:22:29 CET] <sine0> but im not sure if a stream saves as a file..
[13:22:35 CET] <sine0> ill ask bagder
[13:24:40 CET] <sine0> woot curl with -A --output something.mp4 is looking good
[17:30:03 CET] <giosga> hi i have a yamaha wr 125 r, it is very fun to drive
[17:30:08 CET] <giosga> 2 stroke
[17:32:48 CET] <giosga> ohi
[18:29:10 CET] <memo1> hi, im using the opction segments to create portion of videos.  I like the optin segments_wrap but only works when the output files are out%03d.mp4.  I want to use wrap with output file names like web_cam-%Y%m%d-%H%M%S.mp4 but it nevers start again.
[18:29:33 CET] <memo1> any ideas?
[23:29:11 CET] <Cracki> memo1, what gives you the idea that you can use these format specifiers?
[00:00:00 CET] --- Sun Mar 25 2018