Is the Waveform properly calibrated ?
When I analyze a sequence of SMPT ntsc SD color bars generated by my DV camera. The Waveform correctly indicates that the black bands are at 7.5 IRE but places the white band at around 92 IRE instead of 100 IRE and the colored bands around 70 IRE instead of 75 IRE... This in a project in DV ntsc YUV 720x480 format with the preferences "YUV colors space" to BT601 and "YUV color range" to JPEG. If you choose instead the preference "YUV color range" in MPEG, the white band is correctly at 100 IRE and the colored bands are 75 IRE, but... the black bands are now wrongly at 0 IRE... So no possibility to have a good reading. This is true whether I use the X11-OpenGL video driver or just X11. I got the same results (problems) using the color bar from the Grass Valley site: http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DV25_colorbar.avi http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DV50_colorbar.avi http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DVCAM_colorbar.avi Is the Waveform properly calibrated ? Pierre
В сообщении от Friday 20 November 2020 01:51:29 Pierre autourduglobe via Cin написал(а):
When I analyze a sequence of SMPT ntsc SD color bars generated by my DV camera. The Waveform correctly indicates that the black bands are at 7.5 IRE but places the white band at around 92 IRE instead of 100 IRE and the colored bands around 70 IRE instead of 75 IRE...
This in a project in DV ntsc YUV 720x480 format with the preferences "YUV colors space" to BT601 and "YUV color range" to JPEG. If you choose instead the preference "YUV color range" in MPEG, the white band is correctly at 100 IRE and the colored bands are 75 IRE, but... the black bands are now wrongly at 0 IRE...
Unfortunately I don't even know off-head what IRE mean in this context ... :( But yes, there is possibility some settings not applied uniformely (because whole jpeg/mpeg thing was implemented relatively lately in Cin's life) You might try other Cin forks and see if they behave correctly... I on mu side have some sad reincarnation of now-closed bug about inconsistent frame in compositor. I was trying to make screenshot of exact (timecoded) frame , and ...I never figured out seqyence of actions (play, seek, framestep) to get my exact frame. It often works OK initially, but after just few seeks around it become off-by-one (usually one frame behind), and sometimes it return back to consisten state (I look at bottom of main window for hh:mm:ss.frames reading ... and I added this patch to assetpopup.C: diff --git a/cinelerra-5.1/cinelerra/assetpopup.C b/cinelerra-5.1/cinelerra/assetpopup.C index b414455c..915f3b63 100644 --- a/cinelerra-5.1/cinelerra/assetpopup.C +++ b/cinelerra-5.1/cinelerra/assetpopup.C @@ -959,6 +959,7 @@ int SnapshotMenuItem::handle_event() double position = edl->local_session->get_selectionstart(1); int64_t source_position = (int64_t)(position * edl->get_frame_rate()); + printf("source_position from snapshot: %i \n", source_position); ret = !render_engine.vrender ? 1 : render_engine.vrender->process_buffer(frame, source_position, 0); if( !ret ) it prints frame number each time I try to use snapshot function .... I see Cin uses LocalSession::get_selectionstart(int highlight_only) in localsession.C and then /searching for keyword 'position'/ mwindow->edl->align_to_frame . Not sure, may be those two actually round things slightly differently? But I tried to use align_to_frame in this screenshot function and it was consistently in step with original method ...in the wrong cases too! I haven't tried render one frame yet, but I had problem seeing (and rendering!) very first timecode "...21" on this dvcam video I tried to use to check interlaced encoding .. :/ I tried to set in/out points by seeking to very beginning and framestepping, and by mouse selection ... I sometimes see first frame flashing if I do play backward - but render still starts from "...22"!
So no possibility to have a good reading.
This is true whether I use the X11-OpenGL video driver or just X11.
I got the same results (problems) using the color bar from the Grass Valley site: http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DV25_colorbar.avi http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DV50_colorbar.avi http://www.gvgdevelopers.com/K2DevGuide/Clips2/NTSC_SD_DVCAM_colorbar.avi
Is the Waveform properly calibrated ?
Pierre
I just checked under Cinelerra-CV 2.3... The display has the same calibration problems. The white square is not displayed at 100 IRE. Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE. Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar. Pierre Le 20-11-19 à 18 h 47, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 01:51:29 Pierre autourduglobe via Cin написал(а):
When I analyze a sequence of SMPT ntsc SD color bars generated by my DV camera. The Waveform correctly indicates that the black bands are at 7.5 IRE but places the white band at around 92 IRE instead of 100 IRE and the colored bands around 70 IRE instead of 75 IRE...
This in a project in DV ntsc YUV 720x480 format with the preferences "YUV colors space" to BT601 and "YUV color range" to JPEG. If you choose instead the preference "YUV color range" in MPEG, the white band is correctly at 100 IRE and the colored bands are 75 IRE, but... the black bands are now wrongly at 0 IRE... Unfortunately I don't even know off-head what IRE mean in this context ...:(
But yes, there is possibility some settings not applied uniformely (because whole jpeg/mpeg thing was implemented relatively lately in Cin's life)
You might try other Cin forks and see if they behave correctly...
В сообщении от Friday 20 November 2020 03:33:10 Pierre autourduglobe via Cin написал(а):
I just checked under Cinelerra-CV 2.3...
The display has the same calibration problems. The white square is not displayed at 100 IRE.
Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE.
Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar.
Does ffmpeg's filter work as intended? https://trac.ffmpeg.org/wiki/WaveformMonitor if yes, we probably can look how it works rel. to Cinelerra's .....
Pierre
Le 20-11-19 à 18 h 47, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 01:51:29 Pierre autourduglobe via Cin написал(а):
When I analyze a sequence of SMPT ntsc SD color bars generated by my DV camera. The Waveform correctly indicates that the black bands are at 7.5 IRE but places the white band at around 92 IRE instead of 100 IRE and the colored bands around 70 IRE instead of 75 IRE...
This in a project in DV ntsc YUV 720x480 format with the preferences "YUV colors space" to BT601 and "YUV color range" to JPEG. If you choose instead the preference "YUV color range" in MPEG, the white band is correctly at 100 IRE and the colored bands are 75 IRE, but... the black bands are now wrongly at 0 IRE... Unfortunately I don't even know off-head what IRE mean in this context ...:(
But yes, there is possibility some settings not applied uniformely (because whole jpeg/mpeg thing was implemented relatively lately in Cin's life)
You might try other Cin forks and see if they behave correctly...
I don't know how to check these filters, they don't match the Cinelerra-GG plugin names. Pierre Le 20-11-19 à 19 h 31, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 03:33:10 Pierre autourduglobe via Cin написал(а):
I just checked under Cinelerra-CV 2.3...
The display has the same calibration problems. The white square is not displayed at 100 IRE.
Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE.
Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar.
Does ffmpeg's filter work as intended?
https://trac.ffmpeg.org/wiki/WaveformMonitor
if yes, we probably can look how it works rel. to Cinelerra's .....
I don't know how to check these filters, they don't match the Cinelerra-GG plugin names. Pierre Le 20-11-19 à 19 h 31, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 03:33:10 Pierre autourduglobe via Cin написал(а):
I just checked under Cinelerra-CV 2.3...
The display has the same calibration problems. The white square is not displayed at 100 IRE.
Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE.
Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar.
Does ffmpeg's filter work as intended?
https://trac.ffmpeg.org/wiki/WaveformMonitor
if yes, we probably can look how it works rel. to Cinelerra's .....
В сообщении от Friday 20 November 2020 04:31:08 Pierre autourduglobe via Cin написал(а):
I don't know how to check these filters, they don't match the Cinelerra-GG plugin names. Pierre
I mean with standalone ffplay (must be new enough, 2.8 lacks many of those parameters)
Le 20-11-19 à 19 h 31, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 03:33:10 Pierre autourduglobe via Cin написал(а):
I just checked under Cinelerra-CV 2.3...
The display has the same calibration problems. The white square is not displayed at 100 IRE.
Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE.
Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar.
Does ffmpeg's filter work as intended?
https://trac.ffmpeg.org/wiki/WaveformMonitor
if yes, we probably can look how it works rel. to Cinelerra's .....
В сообщении от Friday 20 November 2020 04:31:08 Pierre autourduglobe via Cin написал(а):
I don't know how to check these filters, they don't match the Cinelerra-GG plugin names. Pierre
also found this article, it says software monitors not always right ... http://www.glennchan.info/articles/technical/setup/75IREsetup.html ==== Video Levels - Digital Digital video formats that follow ITU-R Rec. 601 (DV, DVD, etc.) store video in Y'CbCr form. In simple terms, the Y' component (luma) stores the "black and white" information (Cb and Cr are the color difference components). The Y' component determines black level and white level. For 8-bit formats like DV and DVD, the Y' component can range from the values 0 - 255. Video is primarily stored in the range of values from 16 -235. The remaining values are for video over/undershoot. (And the value 0 may be reserved for synchronization purposes.) Please note that the analog unit IRE does NOT apply to the digital domain. Proper black level is at 16 (Y'). Proper white level is at 235 (Y'). This is true for the DV and DVD formats, both PAL and NTSC. Please note that application-based waveform monitors (i.e. in your NLE) are unable to measure analog levels! They cannot tell if your digital-analog converter will convert levels properly or not. Don't get confused by any settings that mention 7.5 IRE! Typically, these settings are for you to tell the software whether or not your digital-analog converter will convert levels properly. This is because the software waveform monitor cannot figure this out on its own. It does not know whether or not the analog levels are correct. =======
Le 20-11-19 à 19 h 31, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 03:33:10 Pierre autourduglobe via Cin написал(а):
I just checked under Cinelerra-CV 2.3...
The display has the same calibration problems. The white square is not displayed at 100 IRE.
Contrary to the CinGG Waveform there is the option (identified "Y'CbCr") to display two horisontal lines corresponding to the levels 7.5 and 92(?) IRE.
Unfortunately even these lines do not seem to correspond to the values displayed by the Colors bar.
Does ffmpeg's filter work as intended?
https://trac.ffmpeg.org/wiki/WaveformMonitor
if yes, we probably can look how it works rel. to Cinelerra's .....
В сообщении от Friday 20 November 2020 04:31:08 Pierre autourduglobe via Cin написал(а): And there was thread from 2015 on old Cin mail list discussing very same topic .... https://lists.cinelerra-cv.org/pipermail/cinelerra/2015q4/003654.html
Thank you for this discovery... I had forgotten that discussion I had (5 years ago) with Igor Ubuntu about this subject... I am currently re-reading the many texts quoted in this document. I had forgotten all this complexity and the multiple distinctions between the IRE values that only concern analog video and the Waveform monitor (VideoScope) of Cinelerra-GG which only calculates % of the digital 0-255 scale. It's not easy to understand that a YCbCr source image (16-235) corresponds to 6.3-92% on the Waveform grid, especially since there are no visual cues on the grid to indicate this and to show the video level overruns that could cause problems depending on the destination of the editing ... Pierre Le 20-11-19 à 21 h 06, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 04:31:08 Pierre autourduglobe via Cin написал(а):
And there was thread from 2015 on old Cin mail list discussing very same topic ....
https://lists.cinelerra-cv.org/pipermail/cinelerra/2015q4/003654.html
В сообщении от Friday 20 November 2020 19:42:52 Pierre autourduglobe via Cin написал(а):
Thank you for this discovery...
I had forgotten that discussion I had (5 years ago) with Igor Ubuntu about this subject...
I am currently re-reading the many texts quoted in this document.
I had forgotten all this complexity and the multiple distinctions between the IRE values that only concern analog video and the Waveform monitor (VideoScope) of Cinelerra-GG which only calculates % of the digital 0-255 scale.
It's not easy to understand that a YCbCr source image (16-235) corresponds to 6.3-92% on the Waveform grid, especially since there are no visual cues on the grid to indicate this and to show the video level overruns that could cause problems depending on the destination of the editing ...
I added (by trial and error!) those two lines ... they assume WAVEFORM_DIVISIONS 12 but I guess they only valid for some types of footage and some setting of mpeg/jpeg toggle .... diff --git a/cinelerra-5.1/cinelerra/scopewindow.C b/cinelerra-5.1/cinelerra/scopewindow.C index 6f34a155..e1cfe335 100644 --- a/cinelerra-5.1/cinelerra/scopewindow.C +++ b/cinelerra-5.1/cinelerra/scopewindow.C @@ -754,6 +754,32 @@ void ScopeGUI::draw_overlays(int overlays, int borders, int flush) waveform->draw_line(0, y, wave_w, y); waveform->draw_rectangle(0, 0, wave_w, wave_h); } + + int y1 = wave_h * 1.8 / WAVEFORM_DIVISIONS; + int text_y1 = y1 + wave_y + get_text_ascent(SMALLFONT) / 2; + CLAMP(text_y1, waveform->get_y() + get_text_ascent(SMALLFONT), waveform->get_y() + waveform->get_h() - 1); + char string1[BCTEXTLEN]; + sprintf( string1, "%d",(int)lround((FLOAT_MAX - + 1.8 * (FLOAT_MAX - FLOAT_MIN ) / WAVEFORM_DIVISIONS ) * 100) ); + int text_x1 = wave_x + get_text_width(SMALLFONT, string1) - margin +wave_w; + set_color(text_color); + draw_text(text_x1, text_y1, string1); + CLAMP(y1, 0, waveform->get_h() - 1); + set_color(dark_color); + waveform->draw_line(0, y1, wave_w, y1); + + int y2 = wave_h * 10.4 / WAVEFORM_DIVISIONS; + int text_y2 = y2 + wave_y + get_text_ascent(SMALLFONT) / 2; + CLAMP(text_y2, waveform->get_y() + get_text_ascent(SMALLFONT), waveform->get_y() + waveform->get_h() - 1); + char string2[BCTEXTLEN]; + sprintf( string2, "%d",(int)lround((FLOAT_MAX - + 10.4 * (FLOAT_MAX - FLOAT_MIN ) / WAVEFORM_DIVISIONS) * 100) ); + set_color(text_color); + draw_text(text_x1, text_y2, string2); + CLAMP(y2, 0, waveform->get_h() - 1); + set_color(dark_color); + waveform->draw_line(0, y2, wave_w, y2); + set_line_dashes(0); waveform->draw_point(); set_line_dashes(1);
Pierre
Le 20-11-19 à 21 h 06, Andrew Randrianasulu a écrit :
В сообщении от Friday 20 November 2020 04:31:08 Pierre autourduglobe via Cin написал(а):
And there was thread from 2015 on old Cin mail list discussing very same topic ....
https://lists.cinelerra-cv.org/pipermail/cinelerra/2015q4/003654.html
Andrew, Pierre: After some testing, I checked into GIT Andrew's waveform mod to add the additional IRE 92.2% + 6.3% lines for the waveform. Interesting discussion - past and present.
I had forgotten all this complexity and the multiple distinctions
between the IRE values that only concern analog video and the Waveform monitor (VideoScope) of Cinelerra-GG which only calculates % of the digital 0-255 scale.
It's not easy to understand that a YCbCr source image (16-235) corresponds to 6.3-92% on the Waveform grid, especially since there are no visual cues on the grid to indicate this and to show the video level overruns that could cause problems depending on the destination of the editing ...
I added (by trial and error!) those two lines ... they assume WAVEFORM_DIVISIONS 12
but I guess they only valid for some types of footage and some setting of mpeg/jpeg toggle ....
participants (3)
-
Andrew Randrianasulu -
Phyllis Smith -
Pierre autourduglobe