v4l2src fails to change video norm from PAL to NTSC

[wally_bkg]

This worked with v4l2src version 0.10.7 on Ubuntu 8.04, but when I moved to Ubuntu 10.04 64-bit which has v4l2src version 0.10.21 the norm doesn't change and the video window displays only an apparently static green screen.  When I close the video window to exit the program, everything works fine the next times as the norm is NTSC then.


It seems about half my video cards default to PAL after a restart, so I need to figure out why this no longer works.

Here is the norm setting code:

gst_element_set_state (pipeline, GST_STATE_PAUSED);
GstTuner *tuner = GST_TUNER( (GstTuner *) source); // get a pointer to access the tuner interface
GstTunerNorm *prevNorm=gst_tuner_get_norm(tuner);
g_print("Previous Norm: %s\n", prevNorm->label);

GstTunerNorm *ntsc=gst_tuner_find_norm_by_name (tuner, "NTSC"); // most have no NTSC-M :(
if(ntsc) goto norm_set;
ntsc=gst_tuner_find_norm_by_name (tuner, "NTSC-M"); // stupid card, no NTSC :(

norm_set:
if(ntsc) gst_tuner_set_norm (tuner, ntsc); else g_error("Can't set NTSC!\n");
g_print("Current Norm: %s\n\n", ntsc->label);

[wally_bkg]

Looks like another undocumented or unintentional change to gstreamer, need to set pipeline to READY instead of PAUSED now before using the interface.

Change:

 gst_element_set_state (pipeline, GST_STATE_PAUSED);

To:

gst_element_set_state (pipeline, GST_STATE_READY);

And the PAL to NTSC switch happens correctly now.

[Tim-Philipp Müller-2]

On Tue, 2010-12-07 at 15:39 -0800, wally_bkg wrote:

> Looks like another undocumented or unintentional change to gstreamer, need to
> set pipeline to READY instead of PAUSED now before using the interface.
>
> Change:
>
>  gst_element_set_state (pipeline, GST_STATE_PAUSED);
>
> To:
>
> gst_element_set_state (pipeline, GST_STATE_READY);
>
> And the PAL to NTSC switch happens correctly now.

I believe this change (open device when going to READY, not PAUSED) was
intentional, to align v4l2src with other elements (opening the device in
the NULL->READY state change), but by itself shouldn't break anything.
It shouldn't make a difference at the v4l2src level, since the device
will go to READY state before going to PAUSED state.

The reason this breaks for you between 0.10.7 and is probably that
you're dealing with the pipeline as a whole, and latency handling was
introduced around 0.10.12-0.10.14, which introduced behavioural
incompatibilities for some cases which were thought not to work properly
before anyway (there was a transition period with warnings for a few
releases, but that doesn't help if you upgrade from an ancient release
to a very new one of course).

 Cheers
  -Tim






------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[wally_bkg]

Tim-Philipp Müller-2 wrote

On Tue, 2010-12-07 at 15:39 -0800, wally_bkg wrote:

> Looks like another undocumented or unintentional change to gstreamer, need to
> set pipeline to READY instead of PAUSED now before using the interface.
>
> Change:
>
>  gst_element_set_state (pipeline, GST_STATE_PAUSED);
>
> To:
>
> gst_element_set_state (pipeline, GST_STATE_READY);
>
> And the PAL to NTSC switch happens correctly now.

I believe this change (open device when going to READY, not PAUSED) was
intentional, to align v4l2src with other elements (opening the device in
the NULL->READY state change), but by itself shouldn't break anything.
It shouldn't make a difference at the v4l2src level, since the device
will go to READY state before going to PAUSED state.

I've ran into this problem again now that I've split my pipeline into two pipelines.

v4l2src->appsink
appsrc->xvimagesink

I assumed this issue was closed from the above, but we had a power failure so my system was reset and of course defaults to PAL on power-up.  I was shocked to find it fail when I ran my code.

wally@wahine:~/gst-learn$ ./VideoPipeline
The v4l2 device is '/dev/video0'.
Previous Norm: PAL
Current Norm: NTSC
Signals will be emitted.
max buffers: 0
drop buffers: FALSE
Reading from appsrc to xvimagesink
Capturing from v4l2src to appsink
isource failed to go into PLAYING state
Main Loop Running...
Error: Could not negotiate format
Returned, stopping playback
Deleting pipelines

but simply running the program again after it terminates works:
wally@wahine:~/gst-learn$ ./VideoPipeline
The v4l2 device is '/dev/video0'.
Previous Norm: NTSC
Current Norm: NTSC
Signals will be emitted.
max buffers: 0
drop buffers: FALSE
Reading from appsrc to xvimagesink
Capturing from v4l2src to appsink
on_new_buffer_from_source Callback entered.
Main Loop Running...

I'm using the appsink-src.c as a guide and don't understand why the v4l2  NORM switch doesn't seem to happen until the program errors and exits now.  My "hello word" video program still works which is just:

v4l2src->xvimagesink


I can recreate the problem by stating XawTV, setting PAL mode and exiting it, leaving the card back in PAL mode.