Re: [FFmpeg-user] error avformat_open_input
Hi, > and the video its in the same path that the project. I don't think that's the issue, because the error description says: > ... unresolved external symbol "int __cdecl avformat_open_input(struct > AVFormatContext * *,char const *,struct AVInputFormat *,struct AVDictionary * > *)" > (?avformat_open_input@@YAHPAPAUAVFormatContext@@PBDPAUAVInputFormat@@PAPAUAVDictionary@@@Z) > referenced in function "bool __cdecl load_video(char const *)" > (?load_video@@YA_NPBD@Z) Also, I think questions on using the libraries and troubleshooting your code are referred to the libav list and leaves this list for help on how to use the command line tools themselves, unless something changed recently. Regards, Ted Park ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
After more research, I’ve found that the two other encoders that I have which write Prores create files that Afterburner recognizes as Prores and plays them in real time. Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll have to switch to AME for this going forward. Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss it! Thanks all. > On Aug 28, 2020, at 6:49 AM, Phil Rhodes via ffmpeg-user > wrote: > > On Friday, 28 August 2020, 09:34:48 BST, Paul B Mahol > wrote: > >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.h;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdata.c;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec.h;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.h;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdsp.c;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresdec2.c;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_anatoliy.c;hb=HEAD >> >> http://git.videolan.org/?p=ffmpeg.git;a=history;f=libavcodec/proresenc_kostya.c;hb=HEAD > Do any of those things actually have effects that are likely to affect users? > I don't think there is any way to tell without being an expert on the > low-level implementation. > If they do, that should be written up in a public-facing manner so that it > can be understood by users. > This is not public-facing documentation; these are internal notes for > developers. Users cannot be expected to comprehend the real-world results of > "infer array length," for instance. > (Well, you can expect people to understand it, but you will be disappointed.) > P > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] A query on mpegts and global headers
Hello there, With mpegts output, should global headers be used or not, set via -fflags +global_header? And if there are exceptions to that, based on the codec type wrapped in mpegts, when should global headers be used for mpegts? I ask because of the dump_extra bitstream filter documentation, which shows a similar use case: https://ffmpeg.org/ffmpeg-bitstream-filters.html#dump_005fextra Which implies that global headers should not be used with mpegts, *but* even if that's the case, it can be corrected via the video bitstream filter dump_extra. Another example of this, cited by Gyan in this answer on Stackoverflow: https://video.stackexchange.com/a/25797/19326 Please help on clarifying this. The ffmpeg documentation can be a bit daunting at times. Regards, Dennis. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] A query on mpegts and global headers
On 30-08-2020 06:52 pm, Dennis Mungai wrote: Hello there, With mpegts output, should global headers be used or not, set via -fflags +global_header? No. And if there are exceptions to that, based on the codec type wrapped in mpegts, when should global headers be used for mpegts? Global header is for formats that store codec parameters out of band i.e. in container metadata. Enabling the flag tells the encoder to store parameters in AVStream->extradata from where it is used by muxers of such formats. Additionally, the flag also suppresses periodic announcement of these parameters within the stream (in-band). MPEG-TS has no global header since it is meant for use as a 'continuous' transport stream. to which clients may start listening at an arbitrary point. So periodic parameter set transmission is required. When generating an output for use by a single muxer, the muxer has a flag which will be conveyed to the encoder automatically, so the user doesn't have to set anything. However in case of the tee muxer, which sends data to multiple muxers, some of which require global headers, the flag has to be manually set and periodic parameter sets reinserted using dump_extra for muxers such as mpegts. Regards, Gyan ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] Hoping to make multiple input seeking outputs based on a text file (inspired by concat)
Hi, > Seems like a very simple script to do this. IMHO, this type of task shouldn't > be built into ffmpeg. It seems to me that is the prevalent opinion. Why is that? To exhume a dead horse and start beating it again, the jumbled up program streams in a DVD's VOB transport streams require this exact maneuver to play. Or is the idea that a separate library should deal with this? I guess that's what bluray does... Regards, Ted Park ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] seeking not working as expected
I'm using a Zeranoe 64-bit Windows build, ffmpeg version git-2020-06-28-4cfcfb3 on Win7. I am trying to split DV-AVI files, using https://trac.ffmpeg.org/wiki/Seeking as my guide. For example, I want to extract a segment from 4h54m24s to 4h57m08s into its own file. The following syntax works great, but is, as promised by the wiki, painfully slow: ffmpeg -i splitme.avi -ss 4:54:24 -t 2:44 -c copy -y out.avi The wiki suggests that the following should work too, but much faster: ffmpeg -ss 4:54:24 -i splitme.avi -t 2:44 -c copy -y out.avi It definitely starts fast, but unexpectedly, it produces a segment from 0:08:21 to, well, I don't know because my disk filled up, so it was many hours long! Am I doing something wrong? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
On 8/30/20, Carl Eugen Hoyos wrote: > Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost : >> >> ’ve got a question about the Prores implementation in ffmpeg because I’ve >> seen >> some odd behavior here with FCPX (running on a very beefy 16-core Mac Pro >> with 192Gram and an Afterburner card). >> >> When I output files from ffmpeg in ProresLT format and bring them into >> FCPX, they stutter badly… > > Command line and complete, uncut console output missing, but see below... I think he uses one of ffmpeg prores encoders, but yes currently provided information is far from helpful. > >> playback is ~5fps. But when I transcode/optimize them in FCPX, which >> creates Prores422 >> versions of those files, they play back in FCPX seamlessly. >> >> The ffmpeg files _used_ to play back seamlessly on this machine when I was >> doing this Jan-March > > Which commit broke the behaviour? > > This is the most important question, continuing the discussion without > the answer makes very little sense. No ffmpeg commit caused it, he uses different decoder for playback, probably hardware accelerated. > > Carl Eugen > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] seeking not working as expected
Am So., 30. Aug. 2020 um 21:32 Uhr schrieb Mike Brown : > > I'm using a Zeranoe 64-bit Windows build, ffmpeg version > git-2020-06-28-4cfcfb3 on Win7. > > I am trying to split DV-AVI files, using https://trac.ffmpeg.org/wiki/Seeking > as my guide. > For example, I want to extract a segment from 4h54m24s to 4h57m08s into its > own file. > > The following syntax works great, but is, as promised by the wiki, painfully > slow: > > ffmpeg -i splitme.avi -ss 4:54:24 -t 2:44 -c copy -y out.avi > > The wiki suggests that the following should work too, but much faster: > > ffmpeg -ss 4:54:24 -i splitme.avi -t 2:44 -c copy -y out.avi > > It definitely starts fast, but unexpectedly, it produces a segment from > 0:08:21 to, well, I don't know because my disk filled up, so it was many hours > long! > > Am I doing something wrong? Complete, uncut console output missing. (Feel free to press q before your disk is full.) Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
Am Fr., 28. Aug. 2020 um 02:01 Uhr schrieb Gary Yost : > > ’ve got a question about the Prores implementation in ffmpeg because I’ve seen > some odd behavior here with FCPX (running on a very beefy 16-core Mac Pro > with 192Gram and an Afterburner card). > > When I output files from ffmpeg in ProresLT format and bring them into FCPX, > they stutter badly… Command line and complete, uncut console output missing, but see below... > playback is ~5fps. But when I transcode/optimize them in FCPX, which creates > Prores422 > versions of those files, they play back in FCPX seamlessly. > > The ffmpeg files _used_ to play back seamlessly on this machine when I was > doing this Jan-March Which commit broke the behaviour? This is the most important question, continuing the discussion without the answer makes very little sense. Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
On 8/30/20, Edward Park wrote: > Hi, > >> After more research, I’ve found that the two other encoders that I have >> which write Prores create files that Afterburner recognizes as Prores and >> plays them in real time. Unfortunately ffmpeg’s Prores isn’t recognized >> as such by the Mac and I’ll have to switch to AME for this going forward. >> Too bad because ffmpeg is so beautifully multithreaded and fast… I’ll miss >> it! > > Well, Adobe pays Apple to use their ProRes codec in AME, so that should be a > foolproof option. > > Basically, authorized partners have access to a lot more comprehensive and > definitive specifications and architectural directives from the original > authors when they develop their codecs, and they go through the pass/fail > tests that all but guarantees that their output works with any and all other > official implementation. Th > > On the other hand, and I might be wrong about this, but the ProRes > implementation in FFmpeg was pretty much reverse engineered by a couple > (extremely talented) people, and it was done a long time ago. As talented as > the authors are, obviously it is impossible to replicate the codec perfectly > without the "blueprints." Nevertheless, it worked fine (until now), and it > is definitely maintained, but some significant updates were made by Apple > that I don't think have been fully realized by the changes in FFmpeg, > especially in the last few minor versions of motion. > > Since you are on a Mac, implementing the ProRes encoder through videotoolbox > would be your solution. I tried to tackle that a few weeks ago actually, but > I think I may have been in way over my head, haha. Since it's a feature that > would only benefit macos builds, priority might be low, I don't know how > much you want ProRes+FFmpeg, but I'm thinking you could hire whoever does > the heavy lifting in macos videotoolbox to implement the prores encoder as > well. Again just typical FUD from same person. > >> Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll >> have to switch to AME for this going forward. Too bad because ffmpeg is >> so beautifully multithreaded and fast… I’ll miss it! > > I'm a bit confused this comment though... How beneficial additional threads > are to performance is firstly dependent on the actual codec, FFmpeg, and AME > more like orchestrates the multi-threading, and I can't see AME falling > behind very much in this specific case... Do you mean ProRes rendering > doesn't rev up the CPU usage over 300% or 600% if you use AME?? (Depending > on source) Ultimately it's the same as all the other "Apple authorized" > ProRes apps, videotoolbox. It is obviously slower, hahaha. > > Regards, > Ted Park > > ___ > ffmpeg-user mailing list > ffmpeg-user@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
Hi, > After more research, I’ve found that the two other encoders that I have which > write Prores create files that Afterburner recognizes as Prores and plays > them in real time. Unfortunately ffmpeg’s Prores isn’t recognized as such by > the Mac and I’ll have to switch to AME for this going forward. Too bad > because ffmpeg is so beautifully multithreaded and fast… I’ll miss it! Well, Adobe pays Apple to use their ProRes codec in AME, so that should be a foolproof option. Basically, authorized partners have access to a lot more comprehensive and definitive specifications and architectural directives from the original authors when they develop their codecs, and they go through the pass/fail tests that all but guarantees that their output works with any and all other official implementation. Th On the other hand, and I might be wrong about this, but the ProRes implementation in FFmpeg was pretty much reverse engineered by a couple (extremely talented) people, and it was done a long time ago. As talented as the authors are, obviously it is impossible to replicate the codec perfectly without the "blueprints." Nevertheless, it worked fine (until now), and it is definitely maintained, but some significant updates were made by Apple that I don't think have been fully realized by the changes in FFmpeg, especially in the last few minor versions of motion. Since you are on a Mac, implementing the ProRes encoder through videotoolbox would be your solution. I tried to tackle that a few weeks ago actually, but I think I may have been in way over my head, haha. Since it's a feature that would only benefit macos builds, priority might be low, I don't know how much you want ProRes+FFmpeg, but I'm thinking you could hire whoever does the heavy lifting in macos videotoolbox to implement the prores encoder as well. > Unfortunately ffmpeg’s Prores isn’t recognized as such by the Mac and I’ll > have to switch to AME for this going forward. Too bad because ffmpeg is so > beautifully multithreaded and fast… I’ll miss it! I'm a bit confused this comment though... How beneficial additional threads are to performance is firstly dependent on the actual codec, FFmpeg, and AME more like orchestrates the multi-threading, and I can't see AME falling behind very much in this specific case... Do you mean ProRes rendering doesn't rev up the CPU usage over 300% or 600% if you use AME?? (Depending on source) Ultimately it's the same as all the other "Apple authorized" ProRes apps, videotoolbox. Regards, Ted Park ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] A query on mpegts and global headers
On Sun, 30 Aug 2020 at 18:11, Gyan Doshi wrote: > > > On 30-08-2020 06:52 pm, Dennis Mungai wrote: > > Hello there, > > > > With mpegts output, should global headers be used or not, set via -fflags > > +global_header? > > No. > > > And if there are exceptions to that, based on the codec type wrapped in > > mpegts, when should global headers be used for mpegts? > > Global header is for formats that store codec parameters out of band > i.e. in container metadata. Enabling the flag tells the encoder to store > parameters in AVStream->extradata from where it is used by muxers of > such formats. Additionally, the flag also suppresses periodic > announcement of these parameters within the stream (in-band). > > MPEG-TS has no global header since it is meant for use as a 'continuous' > transport stream. to which clients may start listening at an arbitrary > point. So periodic parameter set transmission is required. > > When generating an output for use by a single muxer, the muxer has a > flag which will be conveyed to the encoder automatically, so the user > doesn't have to set anything. However in case of the tee muxer, which > sends data to multiple muxers, some of which require global headers, the > flag has to be manually set and periodic parameter sets reinserted using > dump_extra for muxers such as mpegts. > > Regards, > Gyan > > Many thanks for clearing that up, Gyan. Most appreciated. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] seeking not working as expected
On Sun, Aug 30, 2020 at 09:36:42PM +0200, Carl Eugen Hoyos wrote: > Am So., 30. Aug. 2020 um 21:32 Uhr schrieb Mike Brown : > > > > I'm using a Zeranoe 64-bit Windows build, ffmpeg version > > git-2020-06-28-4cfcfb3 on Win7. > > > > I am trying to split DV-AVI files, using > > https://trac.ffmpeg.org/wiki/Seeking as my guide. > > For example, I want to extract a segment from 4h54m24s to 4h57m08s into its > > own file. > > > > The following syntax works great, but is, as promised by the wiki, > > painfully slow: > > > > ffmpeg -i splitme.avi -ss 4:54:24 -t 2:44 -c copy -y out.avi > > > > The wiki suggests that the following should work too, but much faster: > > > > ffmpeg -ss 4:54:24 -i splitme.avi -t 2:44 -c copy -y out.avi > > > > It definitely starts fast, but unexpectedly, it produces a segment from > > 0:08:21 to, well, I don't know because my disk filled up, so it was many > > hours > > long! > > > > Am I doing something wrong? > > Complete, uncut console output missing. > (Feel free to press q before your disk is full.) OK, I pressed q after 11900 frames (requested duration 2:44 should only yield ~4915 frames). I've also tried this same command line with more verbose time specs (04:54:24.0 and 00:02:44.0), but it made no difference. I:\video workspace\captures>ffmpeg -loglevel debug -ss 4:54:24 -i splitme.avi -t 2:44 -c copy -y 34.avi ffmpeg version git-2020-06-28-4cfcfb3 Copyright (c) 2000-2020 the FFmpeg developers built with gcc 9.3.1 (GCC) 20200621 configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore- amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml 2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libgsm --disable-w32threads --enable -libmfx --enable-ffnvcodec --enable-cuda-llvm --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf libavutil 56. 55.100 / 56. 55.100 libavcodec 58. 93.100 / 58. 93.100 libavformat58. 47.100 / 58. 47.100 libavdevice58. 11.100 / 58. 11.100 libavfilter 7. 86.100 / 7. 86.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 libpostproc55. 8.100 / 55. 8.100 Splitting the commandline. Reading option '-loglevel' ... matched as option 'loglevel' (set logging level) with argument 'debug'. Reading option '-ss' ... matched as option 'ss' (set the start time offset) with argument '4:54:24'. Reading option '-i' ... matched as input url with argument 'splitme.avi'. Reading option '-t' ... matched as option 't' (record or transcode "duration" seconds of audio/video) with argument '2:44'. Reading option '-c' ... matched as option 'c' (codec name) with argument 'copy'. Reading option '-y' ... matched as option 'y' (overwrite output files) with argument '1'. Reading option '34.avi' ... matched as output url. Finished splitting the commandline. Parsing a group of options: global . Applying option loglevel (set logging level) with argument debug. Applying option y (overwrite output files) with argument 1. Successfully parsed a group of options. Parsing a group of options: input url splitme.avi. Applying option ss (set the start time offset) with argument 4:54:24. Successfully parsed a group of options. Opening an input file: splitme.avi. [NULL @ 00448580] Opening 'splitme.avi' for reading [file @ 00449e80] Setting default whitelist 'file,crypto,data' [avi @ 00448580] Format avi probed with size=2048 and score=100 [avi @ 0044a080] use odml:1 [avi @ 00448580] ODML index invalid st:1 removing common factor 4 from timebase [avi @ 00448580] ODML index invalid [avi @ 00448580] Before avformat_find_stream_info() pos: 34816 bytes read:688128 seeks:6 nb_streams:2 [avi @ 00448580] parser not found for codec dvvideo, packets or times may be invalid. [avi @ 00448580] parser not found for codec pcm_s16le, packets or times may be invalid. [avi @ 00448580] parser not found for codec dvvideo, packets or times may be invalid. [avi @ 00448580] parser not found for codec pcm_s16le, packets or times may be invalid. [avi @ 00448580] All info found [avi @ 00448580] After avformat_find_stream_info() pos: 158928 bytes read:840904 seeks:6 frames:2 Guessed Channel Layout for Input Stream #0.1 : stereo Input #0, avi, from 'splitme.avi': Duration:
Re: [FFmpeg-user] ? About ffmpeg's prores implemention
Hi, > Again just typical FUD from same person. I'm not sure what you are referring to, what's there to spread fud about?? > It is obviously slower, hahaha. What is, AME or one of the prores encoders included in FFmpeg? I mean obviously it'd depend on the job and hardware but for what it's worth I compared prores_ks with xq and it took around twice the wallclock time. It did indeed take way more than twice the cpu time though, but if its output has problems then the whole point is moot :/ Regards, Ted Park ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
