Vb.Net 2015 - VideoFileWriter - H264

[gegsrl]

Hello,

I have a problem with VideoFileWrite and H264 codec.
If I use VideoCodec.MPEG4 (v1, v2 or v3), my application can write video files correctly.
If I only change VideoCodec to H264, I get a "System.AccessViolationException" (Attempted to read or write protected memory) on WriteVideoFrame method.

Stream is a MJPEGStream

Private VWriter as VideoFileWriter

 Private Sub btnStart_Click(sender As System.Object, e As System.EventArgs) Handles btnStart.Click
                VWriter = New VideoFileWriter
                VWriter.Open("C:\Test\Test.avi", 1088, 1088, 20, VideoCodec.H264)
End Sub

    Private Sub Stream_NewFrame(sender As Object, eventArgs As NewFrameEventArgs) Handles Stream.NewFrame
        Try
            If Not VWriter Is Nothing Then VWriter.WriteVideoFrame(eventArgs.Frame)
        Catch ex As Exception
            msgbox (ex.message)
        End Try
    End Sub

Thank you and excuse for my english

[gustav21]

I have the same problem. I get System.AccessViolationException while using VideoCodec.H264 in VideoFileWriter.
Look at this issue - there is System.AccessViolationException in Accord.Video.DirectShow and topicstarter found that the reason is in the H264 codec.
So, I guess these two issues are related.

And one more fact:
The Screencast Capture Lite tool is working fine while its using VideoCodec.H264. We can be sure.

[gegsrl]

Hi Gustav21.
Yes, it seems the same problem.
The Screencast Capture Lite tool is working fine while its using VideoCodec.H264 too for me.
Could somebody help us?

Thank you in advance

[cesarsouza]

Hi @gegsrl,

Can you please provide a more complete source code so that I could include it as a unit test in the framework and start investigating? In particular, can you provide a few of the frames that you are trying to write, and some standalone, but complete, code that could trigger the issue?

The point is that I have not been able to reproduce it so far, so it is quite hard to debug without having a working example that reliably reproduces the issue (sorry for not asking about it before, btw).

Regards,
Cesar

[dhudy]

I too received a similar issue regarding the H264/H265 codec when used by the VideoFileWriter. I am unable to provide any of my data sets as they are medical xrays and it would break HIPAA compliance. I can include the stack trace and my relevant code to help you guys narrow it down.

Stack Trace:
System.AccessViolationException: 'Attempted to read or write protected memory. This is often an indication that other memory is corrupt.'
at avcodec_encode_video2(AVCodecContext* , AVPacket* , AVFrame* , Int32* )
at Accord.Video.FFMPEG.VideoFileWriter.Flush()
at Accord.Video.FFMPEG.VideoFileWriter.Close()
at Accord.Video.FFMPEG.VideoFileWriter.Open(String fileName, Int32 width, Int32 height, Rational frameRate, VideoCodec codec, Int32 bitRate, AudioCodec audioCodec, Int32 audioBitrate, Int32 sampleRate, Int32 channels)
at Accord.Video.FFMPEG.VideoFileWriter.Open(String fileName, Int32 width, Int32 height, Rational frameRate, VideoCodec codec)

Executing code block: https://pastebin.com/3ARhuZyc

Description:

I am reading in DICOM video files (which are stored as an image series). I save the individual frame images then coalesce the image series into a video file. I have tried using both H265 and H264 with no success. Other video formats seem to work (other than RAW which gives an entirely different error which i won't go into details about here as the issue may be on my end). Let me know if there is anything more I can do to help narrow down the issue.

Cheers,
Hudy

[yvdh]

Hello,

I confirm the same exact error (@hudy: also when creating a Dicom Dataset .using fo-dicom) with the H264 codec.

[EvK]

Can confirm. I just capture video stream from my Logitech webcam and feed it to VideoFileWriter via writer.WriteVideoFrame using H264 codec, no other code involved. On the very first WriteVideoFrame it throws AccessViolationException. If I use other codec (tried VP8 for example) - all is fine.

[cesarsouza]

Hi @yvdh, @EvK,

Could you please prove a sample video that triggers the issue, as well as a small code sample showing how you are using the VideoFileWriter class, such that I could investigate?

Thanks a lot in advance!

Regards,
Cesar

[yvdh]

Hi there, Happens during capture. I am not at work now where I have the code and will only be back in 2 weeks time. I will mail back then ... Cheers, Yves From: César Souza [mailto:notifications@github.com] Sent: Thursday, 21 September 2017 20:17 To: accord-net/framework <framework@noreply.github.com> Cc: YVES VANDER HAEGHEN <Yves.VanderHaeghen@UGent.be>; Mention <mention@noreply.github.com> Subject: Re: [accord-net/framework] Vb.Net 2015 - VideoFileWriter - H264 (#721) Hi @yvdh<https://github.com/yvdh>, @EvK<https://github.com/evk>, Could you please prove a sample video that triggers the issue, as well as a small code sample showing how you are using the VideoFileWriter class, such that I could investigate? Thanks a lot in advance! Regards, Cesar — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#721 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/APy82UoeGUJ9vvbuikiex61WX6uuFUJwks5skqgRgaJpZM4OcrYA>.

[cesarsouza]

It is likely that this issue will be fixed in the next release. I will update this issue when a pre-release is available on NuGet.

[cesarsouza]

A new (pre-release) version of Accord.Video.FFMPEG has just been pushed to NuGet. If it helps solving the issue (and if it isn't too late for you of course, as I realize it has been some time since the issue was first opened), please let me know!

Regards,
Cesar

[woehrl]

As a hint I'ld like to add that sometimes the problem might also be caused by debugging countermeasures within a codec. I experienced unhandled exceptions when my application was started from the VS.NET IDE with the debugger attached. This happens due to countermeasures of the codecs - they want to avoid their algorhithms revealed. When the application is started in release mode, everything runs fine. The codecs that obviously cause that kind of trouble are for example Bosch H.264 and DivX. I had to uninstall those to keep debugging functionality...

Best regards,
Florian

[lorenlew]

still the same issue with 3.8.2-alpha package version
VideoFileWriter with "Accord.Video.FFMPEG.VideoCodec.H264" config

[benoit-bernard]

I think i have the same issue with last stable version and 3.8.2 alpha. You can download a sample to reproduce here : https://we.tl/yjIQqZcrct
It crashes the process (AccessViolationException) with any mp4 screen record made with accord VideoFileWriter, a sample GoPro video and many other mp4 video.

Best regards

[kavanagh21]

I also have the same problem. The application I'm using it in is available on GitHub (kavanagh21/TifyVBNet). Whenever I try to export a video using WriteVideoFrame I get the same error.
You should be able to load any images in, click on Export Options and get the error (unless it's machine specific).

[1192360619]

Yes,I get same error while using H264 or H265, I tested V3.4 that H264 is ok, but V3.5-V3.8.2 all bad. Hope you update this problem help us, thank you very much!@cesarsouza

[1192360619]

If the next new version of screencast-capture can be used accord.net v3.8.2 that is nice!@cesarsouza

[XenonLX]

The issue is also reproducing for me when writing live 4096*2048 MJPEG stream with H.264 codec into mp4 container. It is not reproducing on lower resolutions. A version of Accord used - 3.8.2-alpha. Same reproduce on latest stable - 3.8. Ran a few more tests with H264, sometimes (rarely) it works fine, so the issue may be floating.

[JoeJoeCoder]

This issue is also happening for me. If I run my monitor at 800x600, it is OK. 1024x768, it throws access error writing first frame to the video writer. It ALSO fails on 1280x1024, but it works on 1920x1200. I followed the advise above to downgrade from 3.8.0 to 3.4.0, and it is working on ALL my resolutions. Very Odd.

[nesteruk]

I am also experiencing this issue. With H265 it happens with all resolutions whereas with H264 it happens at resolutions above 1080p.