x264enc encoding parameters

[Ian Davidson]

I have a C program which records a video file from a camera.

The video part of the pipeline (assuming that I have transcribed it correctly) is

v4l2src ! queue ! videorate ! videoscale ! video/x-raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1 ! queue ! videoconvert ! x264enc ! mp4mux ! filesink location=foo/bar

The program works fine and the degree of compression achieved by the encoder is impressive. However, when there is significant movement in the image, there is a very obvious 'interleave effect' which remains visible for quite a while. I would be prepared to pay the cost of less aggressive compression/greater file size to improve the image quality.

I have attempted to change the behaviour of the encoder, for example by setting bitrate to 6000, but I have not found anything which seems to make any difference.

How should I go about getting better picture quality?

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Tim Müller]

On Thu, 2017-03-23 at 18:28 +0000, Ian Davidson wrote:

Hi David,

> I have a C program which records a video file from a camera.
> The video part of the pipeline (assuming that I have transcribed it
> correctly) is
> v4l2src ! queue ! videorate ! videoscale ! video/x-
> raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1
> ! queue ! videoconvert ! x264enc ! mp4mux ! filesink location=foo/bar
> The program works fine and the degree of compression achieved by the
> encoder is impressive. However, when there is significant movement in
> the image, there is a very obvious 'interleave effect' which remains
> visible for quite a while. I would be prepared to pay the cost of
> less aggressive compression/greater file size to improve the image
> quality.
> I have attempted to change the behaviour of the encoder, for example
> by setting bitrate to 6000, but I have not found anything which seems
> to make any difference.
> How should I go about getting better picture quality?

It might be helpful if you put up a couple-of-second-long sample mp4
somewhere on your website, so we can check out the exact problem.

What is the device that produces this? Is it an analogue video capture
device by any chance? Is it possible the device produces interlaced
video? You could try adding a 'deinterlace' element to see if it makes
a difference.

Cheers
 -Tim

--
Tim Müller, Centricular Ltd - http://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ian Davidson]

I have attached a short sample where the effect can be seen.

The feed to the computer is via a video mixer using a composite signal.  
I expect that that implies that the signal is interleaved.

Where in the pipeline would you recommend that I put the deinterlace?

Thanks.

Ian


On 23/03/2017 18:48, Tim Müller wrote:

> On Thu, 2017-03-23 at 18:28 +0000, Ian Davidson wrote:
>
> Hi David,
>
>
>> I have a C program which records a video file from a camera.
>> The video part of the pipeline (assuming that I have transcribed it
>> correctly) is
>> v4l2src ! queue ! videorate ! videoscale ! video/x-
>> raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1
>> ! queue ! videoconvert ! x264enc ! mp4mux ! filesink location=foo/bar
>> The program works fine and the degree of compression achieved by the
>> encoder is impressive. However, when there is significant movement in
>> the image, there is a very obvious 'interleave effect' which remains
>> visible for quite a while. I would be prepared to pay the cost of
>> less aggressive compression/greater file size to improve the image
>> quality.
>> I have attempted to change the behaviour of the encoder, for example
>> by setting bitrate to 6000, but I have not found anything which seems
>> to make any difference.
>> How should I go about getting better picture quality?
> It might be helpful if you put up a couple-of-second-long sample mp4
> somewhere on your website, so we can check out the exact problem.
>
> What is the device that produces this? Is it an analogue video capture
> device by any chance? Is it possible the device produces interlaced
> video? You could try adding a 'deinterlace' element to see if it makes
> a difference.
>
> Cheers
>   -Tim
>

--
--
Ian Davidson


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Peter Maersk-Moller-2]

Hi Ian.

You are recording in interlaced mode. Don't ... unless you display it on an old interlaced CRT that actually syncs to the same interlace frequency the material was recorded with .... and very few people does that any more ... anywhere ... except perhaps north korea

Perhaps the camera being the source for the v4l2src is "interlaced only" and then you should get another camera.

You need a progressive as opposed to interlaced camera.

Perhaps the camera can do both interlaced and progressive, but not progressive at the geometry and framerate you have chosen. Try to list the camera (v4l2 device) capabolities. Use v4l2ctl or something.

Alternatively you can try to add the 'deinterlace' gstreamer module to your encoding pipeline, but it can only do so much for you. It will never be perfect.

On Sat, Mar 25, 2017 at 9:24 AM, Ian Davidson <[hidden email]> wrote:

I have attached a short sample where the effect can be seen.

The feed to the computer is via a video mixer using a composite signal.  I expect that that implies that the signal is interleaved.

Where in the pipeline would you recommend that I put the deinterlace?

Thanks.

Ian

On 23/03/2017 18:48, Tim Müller wrote:

On Thu, 2017-03-23 at 18:28 +0000, Ian Davidson wrote:

Hi David,

I have a C program which records a video file from a camera.
The video part of the pipeline (assuming that I have transcribed it
correctly) is
v4l2src ! queue ! videorate ! videoscale ! video/x-
raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1
! queue ! videoconvert ! x264enc ! mp4mux ! filesink location=foo/bar
The program works fine and the degree of compression achieved by the
encoder is impressive. However, when there is significant movement in
the image, there is a very obvious 'interleave effect' which remains
visible for quite a while. I would be prepared to pay the cost of
less aggressive compression/greater file size to improve the image
quality.
I have attempted to change the behaviour of the encoder, for example
by setting bitrate to 6000, but I have not found anything which seems
to make any difference.
How should I go about getting better picture quality?

It might be helpful if you put up a couple-of-second-long sample mp4
somewhere on your website, so we can check out the exact problem.

What is the device that produces this? Is it an analogue video capture
device by any chance? Is it possible the device produces interlaced
video? You could try adding a 'deinterlace' element to see if it makes
a difference.

Cheers
  -Tim

--

--
Ian Davidson


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ian Davidson]

Thanks for your help guys.

I am stuck with the camera system I have, so I have added deinterlace and I think that the resulting video looks better.

I have added the deinterlace as shown below - is that the best place?

v4l2src ! queue ! videorate ! videoscale ! video/x-raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1 ! queue ! videoconvert ! deinterlace ! videoconvert ! x264enc ! mp4mux ! filesink location=foo/bar

Ian

On 25/03/2017 08:36, Peter Maersk-Moller wrote:

Hi Ian.

You are recording in interlaced mode. Don't ... unless you display it on an old interlaced CRT that actually syncs to the same interlace frequency the material was recorded with .... and very few people does that any more ... anywhere ... except perhaps north korea

Perhaps the camera being the source for the v4l2src is "interlaced only" and then you should get another camera.

You need a progressive as opposed to interlaced camera.

Perhaps the camera can do both interlaced and progressive, but not progressive at the geometry and framerate you have chosen. Try to list the camera (v4l2 device) capabolities. Use v4l2ctl or something.

Alternatively you can try to add the 'deinterlace' gstreamer module to your encoding pipeline, but it can only do so much for you. It will never be perfect.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Nicolas Dufresne-5]

Le lundi 27 mars 2017 à 20:55 +0100, Ian Davidson a écrit :
> I have added the deinterlace as shown below - is that the best place?
> v4l2src ! queue ! videorate ! videoscale ! video/x-
> raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1
> ! queue ! videoconvert ! deinterlace ! videoconvert ! x264enc !
> mp4mux ! filesink location=foo/bar

It's most likely a better idea to deinterlace before scaling.

Nicolas
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Ian Davidson]

Hi Nicolas,

I totally understand why you say that.  However, I think that the
dimensions I have specified can be achieved by negotiation with the
source, so I suspect that the scaling is actually doing nothing.  In
that case, would the sequence of steps make a difference?

Ian


On 27/03/2017 21:34, Nicolas Dufresne wrote:
> Le lundi 27 mars 2017 à 20:55 +0100, Ian Davidson a écrit :
>> I have added the deinterlace as shown below - is that the best place?
>> v4l2src ! queue ! videorate ! videoscale ! video/x-
>> raw,format=(string)I420,width=720,height=576,framerate=(fraction)25/1
>> ! queue ! videoconvert ! deinterlace ! videoconvert ! x264enc !
>> mp4mux ! filesink location=foo/bar
> It's most likely a better idea to deinterlace before scaling.
>
> Nicolas

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel