[vlc-devel] Re: Do we have a MPEG expert in VLC?

[R. Bernstein]

Gildas Bazin writes:
 > I just tried the above sample and the problem doesn't come from VLC but from 
 > the file itself. 

I think more precisely, VLC's interpretation of the file. Details are
below, but the system clock reference numbers (SCRs) that confuses
vlc's MPEG demuxer are those coming from packets of the private stream
in the subtitle.

Anyone know if an MPEG private stream is required to have SCR's that
are synchronized with video or audio streams that may surround it?
I don't see why it should -- can't the two be independent? -- but I
really don't know that much about this. Or could it be that the
subtitle appears way in advance of where it is supposed to fit in the
SCR or that this SCR indicates is when the subtitle finishes.

Is there an MPEG expert in the house?

As for changing vlc to handle this kind of situation, I don't see a
simple solution. The "scr" that vlc acts upon (demux/mpeg/system.c
DemuxPS around line 1052) is seen before the packet which has the
stream ID for the private stream (called from the "else" part in
DemuxPS part at 1132).  An short excerpt:

Pack [0xd1ee8]
  scr = 408856:0
  ^^^^^^^^^^^^^^  Does this appear before ...
  mux = 23356 - (1167800 bytes/second) 
  stuffing = 0
     Packet [0xd1ef6]
       stream_id = 0xbd  (private_stream_1)
                   ^^^^ before this ?

 > There are invalid SCR (system clock reference) timestamps 
 > happening randomly (?) in the stream. VLC relies on this information to 
 > read the stream at the right pace (contrary to other players like xine/
 > mplayer which don't use this info and synchronise everything on the audio 
 > output clock).
 > 
 > Here is an extract of the logs I produced:
 > 
 > [00000199] mpeg_system input warning: scr: 261600
 > [00000199] mpeg_system input warning: scr: 262200
 > [00000199] mpeg_system input warning: scr: 262800
 > [00000199] mpeg_system input warning: scr: 263400
 > [00000199] mpeg_system input warning: scr: 408856   <----- PROBLEM HERE

I think this warrants a closer investigation.  I used
vk_tools/view_knot_dump to give more detailed information about this
and here is what it reports around this area:

Pack [0xd15d4]
  scr = 263400:0
  mux = 6972 - (348600 bytes/second) 
  stuffing = 0
	Packet [0xd15e2]
	  stream_id = 0xe0  (video_stream)
	  pes_packet_length = 2304 (ends @ 0xd1ee8)
	  pes_scrambling_control = 0
	  data_alignment_indicator = 0
	  copyright = 0
	  original_or_copy = 1
	  PTS_DTS_flags = 3
	  ESCR_flag = 0
	  ES_rate_flag = 0
	  DSM_trick_mode_flag = 0
	  additional_copy_info_flag = 0
	  PES_CRC_flag = 0
	  PES_extension_flag = 1
	  pes_header_data_length = 13
	  PTS = 321004
	  DTS = 308992
	  extension_data -
		private_data_flag = 0
		pack_header_field_flag = 0
		program_packet_sequence_counter_flag = 0
		P-STD_buffer_flag = 1
		PES_extension_flag_2 = 0
		P-STD_buffer_scale = 1
		P-STD_buffer_size = 230
		P-STD_actual_buffer_size = 235520
Pack [0xd1ee8]
  scr = 408856:0
  mux = 23356 - (1167800 bytes/second) 
  stuffing = 0
     Packet [0xd1ef6]
       stream_id = 0xbd  (private_stream_1)
       pes_packet_length = 1952 (ends @ 0xd269c)
       pes_scrambling_control = 0
       data_alignment_indicator = 0
       copyright = 0
       original_or_copy = 1
       PTS_DTS_flags = 2
       ESCR_flag = 0
       ES_rate_flag = 0
       DSM_trick_mode_flag = 0
       additional_copy_info_flag = 0
       PES_CRC_flag = 0
       PES_extension_flag = 1
       pes_header_data_length = 8
       extension_data -
         private_data_flag = 0
         pack_header_field_flag = 0
         packet_sequence_counter_flag = 0
         P-STD_buffer_flag = 1
         PES_extension_flag_2 = 0
         P-STD_buffer_scale = 1
         P-STD_buffer_size = 58
         P-STD_actual_buffer_size = 59392
     Packet [0xd269c]
       stream_id = 0xbe  (padding_stream)
       pes_packet_length = 346 (ends @ 0xd27fc)

Pack [0xd27fc]
  scr = 264000:0
  mux = 6972 - (348600 bytes/second) 
  stuffing = 0
     Packet [0xd280a]
	stream_id = 0xe0  (video_stream)
...

 > > Why multiple ES's with the same aspect ratio but different frame sizes
 > > are detected for those VCD MPEG such as here:
 > > http://www.vcdimager.org/pub/vcdimager/examples/test_svcd/
 > test_svcd_ntsc.xml
 > > 
 > 
 > Didn't have a look yet.

Okay. Would appreciate it if someone who knows MPEGs and vlc could, sometime. 

And there's also the problem of being able to tell VLC that we've gone
from a still frame for an MPEG with one resoultion to an MPEG with
another.

Thanks.

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html
If you are in trouble, please contact <postmaster at videolan.org>