-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grabbing/recording packets doesn't work, EXCEPTION_ACCESS_VIOLATION. #818
Comments
What about the following example? What happens when you try it out? |
My test above was slightly modified version of your example. Nevertheless I tried your example verbatim.
The video file is here: |
@alicanalbayrak Any idea why your code would be broken? |
Is the very idea of recorder.start(grabber.getFormatContext()) correct? Shouldn't the context be cloned or something? |
Not sure, @alicanalbayrak implemented this feature using fields that became deprecated. We'll need to update/change all that eventually, so feel free to fix it up, and please make a contribution! |
Hi @samokhodkin @saudet , |
Hi all, |
Please try FFmpeg 3.4 with JavaCV 1.3.4-SNAPSHOT.
|
Tried FFmpeg 3.4 + JavaCV 1.3.4-SNAPSHOT today. My Android app is about golf swing video analysis, which demands that every frame of a video can be seeked to. The videos are generally only a few seconds long. They originate from the device's camera or might have been downloaded from the web. In any case, they all are imported in the app, which means they are reencoded with avcodec.AV_CODEC_ID_MPEG4 using FFmpegFrameGrabber and FFmpegFrameRecorder. The packet grabbing and recording is used for a lossless trimming functionality, which can be used to trim a video after encoding to only contain the golf swing. |
Thanks for testing! As I mention above, we need to get rid of the deprecated calls. Until that happens, you might be better off using an old version of FFmpeg... |
I've just released JavaCV 1.4.1, which uses FFmpeg 3.4.2. Maybe this is a bug that has been fixed upstream, so please try again with this new release! |
Thanks Samuel,
will try.
Markus
Am 31.03.18 um 05:27 schrieb Samuel
Audet:
I've just released JavaCV 1.4.1, which uses FFmpeg 3.4.2. Maybe
this is a bug that has been fixed upstream, so please try again
with this new release!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/bytedeco/javacv","title":"bytedeco/javacv","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/bytedeco/javacv"}},"updates":{"snippets":[{"icon":"PERSON","message":"@saudet in #818: I've just released JavaCV 1.4.1, which uses FFmpeg 3.4.2. Maybe this is a bug that has been fixed upstream, so please try again with this new release!"}],"action":{"name":"View Issue","url":"#818 (comment)"}}}
…--
Wilke gmx Signatur
_________________________________________________________________________
Markus Wilke
Diplom-Informatiker
Mobil :
+49 151 68402978
Office : +49 8133 996144
Mail : markus.wilke@gmx.de
|
Thanks for your work, Samuel. I have few free days and will play with this
new version. Will keep you updated.
Sergey
…On Sat, Mar 31, 2018 at 6:27 AM, Samuel Audet ***@***.***> wrote:
I've just released JavaCV 1.4.1, which uses FFmpeg 3.4.2. Maybe this is a
bug that has been fixed upstream, so please try again with this new release!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#818 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ARV_tBeTs5ufTP5fmUUOX45Or8W7x4opks5tjveIgaJpZM4QBjQA>
.
|
@samokhodkin Any updates ? as i've the same issue with javacv 1.4.1 |
I've came into a relative problem while extracting audio from video. I was using JavaCV 1.4.1 with FFMpeg 3.4.2 in Windows x86 64 platform.
The output in console is:
|
Could you also provide a code snippet to reproduce the issue? |
Ok. private static void grabStreaming() {
try {
// the source file is a video in MP4 format.
FFmpegFrameGrabber grabber = new FFmpegFrameGrabber(SOURCE_LOCAL_FILE);
File outputFile = new File("./build/output.mp3");
if (!outputFile.exists()) {
try {
outputFile.createNewFile();
} catch (IOException e) {
System.out.println("Error in create new file = " +
outputFile.getName());
}
}
FFmpegFrameRecorder recorder = new FFmpegFrameRecorder(outputFile, 1);
recorder.setAudioCodec(AV_CODEC_ID_MP3);
recorder.setAudioChannels(1);
grabber.start();
recorder.start();
Frame frame = null;
while ((frame = grabber.grabSamples()) != null) {
if (frame.getTypes().contains(Frame.Type.AUDIO)) {
System.out
.println("frame grabbed at " +
grabber.getTimestamp());
}
recorder.record(frame);
}
recorder.stop();
grabber.stop();
System.out.println("loop end with frame: " + frame);
} catch (FrameGrabber.Exception ex) {
System.out.println("exception: " + ex);
} catch (FrameRecorder.Exception ex) {
System.out.println("exception: " + ex);
ex1.printStackTrace();
}
System.out.println("end");
} |
@tuang Looks OK, but there's been a couple of issues fixed since then. |
Hasn't the problem been solved yet. @saudet |
@saudet @bug-rabbit |
I think that handling the 'AVPacket' itself is free to calculate and set ‘pts’ and ‘dts’, so I don't think this operation should be integrated into javacv, so I don't think this is a problem.Thanks. |
I also encountered such a mistake, how can I solve it? JavaCV 1.5.1 |
Warning: [flv @ 000000003ee33040] Timestamps are unset in a packet for stream 0. This is deprecated and will stop working in the future. Fix your code to set the timestamps properly Warning: [flv @ 000000003ee33040] Encoder did not produce proper pts, making some up. The version is up to date. @samokhodkin @saudet How to Solve the Problem??? |
moved question to new issue: #1616 |
@AndreSchulzBerlin It's crashing in |
i use the recordPacket method to push AVPacket packets to the srs server. Avoiding the encoding and decoding process is expected to reduce the CPU occupancy rate in this way. |
@zhangwei941913953 Please look at messages in the log for clues. |
here is the consul log :
|
The main logic code is as follows: public class PushTask implements Runnable {
private FFmpegFrameGrabber grabber;
private FFmpegFrameRecorder recorder;
private PipedOutputStream pos = new PipedOutputStream();
private PipedInputStream pis = new PipedInputStream();
public void initialGrabAndRecord() {
try {
grabber = new FFmpegFrameGrabber(pis, 0);
grabber.setFormat("h264");
log.info("start to initialize grabber!!");
grabber.start(true);
log.info("initialize frame push grabber over! :{}", taskName);
int width = grabber.getImageWidth();
int height = grabber.getImageHeight();
int videoCodecid = grabber.getVideoCodec();
double realFrameRate = grabber.getFrameRate();
double bitRate = grabber.getVideoBitrate();
int audioCodecid = grabber.getAudioCodec();
int audioChannels = grabber.getAudioChannels();
double audioBitrate = grabber.getAudioBitrate();
int sampleRate = grabber.getSampleRate();
log.info("===============grabber videoCodecid is: {}, realFrameRate is : {}, bitRate is {}, " +
" audioCodecid is: {}, audioChannels is: {}, audioBitrate is: {}, width is: {}, height is : {}, sampleRate is {} ==============",
videoCodecid, realFrameRate, bitRate, audioCodecid, audioChannels, audioBitrate, width, height, sampleRate);
recorder = new FFmpegFrameRecorder(rtmpAddr, 704, 576);
log.info("send data to rtmp address {}", rtmpAddr);
recorder.setVideoOption("vcodec", "copy");
recorder.setVideoCodec(avcodec.AV_CODEC_ID_H264);
recorder.setVideoOption("tune", "zerolatency");
recorder.setVideoOption("preset", "ultrafast");
recorder.setFormat("flv");
recorder.setVideoOption("crf", "18");
recorder.setAudioQuality(0);
recorder.setAudioBitrate(192000);
recorder.setSampleRate(8000);
recorder.setAudioChannels(AUDIO_CHANNEL);
recorder.setAudioOption("crf", "0");
recorder.setAudioCodec(avcodec.AV_CODEC_ID_AAC);
recorder.start(grabber.getFormatContext());
} catch (Exception e) {
log.error("start grabber or recorder error ! ", e);
}
}
public void run() {
initialGrabAndRecord();
while (!stop) {
pushVideoPackage();
}
release();
}
private void pushVideoPackage(){
FFmpegLogCallback.set();
try {
if (null == grabber) {
return;
}
recorder.recordPacket(grabber.grabPacket());
if (!isRecorderStarted) {
isRecorderStarted = true;
log.info("is recorder started");
}
if (!firstVideo) {
firstVideo = true;
log.info("first video");
}
} catch (Exception e) {
log.error("push data to srs error! {}", e);
}
}
} |
@zhangwei941913953 It looks like FFmpeg is failing on the input stream. It's probably corrupted. |
You should re-calculate pts and dts |
The video is interrupted after a period of normal play. In addition to network failures, the biggest cause may be the wrong pts and dts timestamps. |
Is the problem solved? |
您好,邮件已收到,谢谢。
|
Hi, when the problem came up, I worked around it and didn't try the fix since then. So I honestly don't know. Markus -- Markus ***@***.***+49 151 68402978Am 01.07.22, 03:39 schrieb HoganGolden ***@***.***>:
Is the problem solved?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>
|
@HoganGolden I had to update code that was using deprecated APIs when upgrading to FFmpeg 5.0, so it might work better now, but I haven't tested everything. Please give it a try with JavaCV 1.5.7 and/or with the snapshots: http://bytedeco.org/builds/ |
您好,邮件已收到,谢谢。
|
Hello,
I'm trying to send a stream from grabber to recorder without transcoding. I already received some help from Samuel Audet, who pointed me to this sample:
https://github.com/bytedeco/javacv/blob/master/samples/PacketRecorderTest.java#L53
I tried it, but it doesn't work, in two ways.
First, the grabbed packets are obviously incorrect, judging by their size (1 byte), always-zero timestamp and non-changing state of the grabber. And after I put the first such packet to the recorder, the JVM fails
with fatal error EXCEPTION_ACCESS_VIOLATION.
Here is the code:
and the output:
Did anyone have success with packet transmission?
Thanks a lot
The text was updated successfully, but these errors were encountered: