Error when seeking mpg video

woud you please tell me what this errors says and what is the problem?

[2022-06-05 09:37:43.866] [info]    Received message from LOADBG 1-1 "video/3" CUT 0 linear RIGHT SEEK 301\r\n
[2022-06-05 09:37:43.866] [info]    Received message from PLAY 1-1\r\n
[2022-06-05 09:37:43.866] [info]    Received message from PAUSE 1-1\r\n
[2022-06-05 09:37:43.866] [info]    Sent message to MIXER OK\r\n
[2022-06-05 09:37:43.870] [info]    Sent message to LOADBG OK\r\n
[2022-06-05 09:37:43.870] [info]    Sent message to PLAY OK\r\n
[2022-06-05 09:37:43.870] [info]    Sent message to PAUSE OK\r\n
[2022-06-05 09:37:43.918] [info]    ffmpeg[D:/Projects/Cgtemplate//video/1.mpg|0/2272] Destroyed.
[2022-06-05 09:37:44.029] [error]   [ffmpeg] [mp2 @ 000001DF6B5ABEC0] Header missing
[2022-06-05 09:37:44.029] [error]
[2022-06-05 09:37:44.097] [error]   Exception: C:\Program Files (x86)\Jenkins\workspace\casparcg-server-dep\master\src\modules\ffmpeg\producer\av_producer.cpp(153): Throw in function auto __cdecl caspar::ffmpeg::Decoder::()::<lambda_cf087faeeb9dabf84379bbd46f77baec>::operator ()(void) const
[2022-06-05 09:37:44.097] [error]   Dynamic exception type: class boost::exception_detail::clone_impl<struct caspar::ffmpeg::ffmpeg_error_t>
[2022-06-05 09:37:44.097] [error]   [struct boost::errinfo_api_function_ * __ptr64] = avcodec_send_packet(ctx.get(), input.front().get())
[2022-06-05 09:37:44.097] [error]   [struct boost::errinfo_errno_ * __ptr64] = 1094995529, "Unknown error"
[2022-06-05 09:37:44.097] [error]   [struct caspar::ffmpeg::tag_ffmpeg_errn_info * __ptr64] = -1094995529
[2022-06-05 09:37:44.097] [error]   [struct caspar::tag_stacktrace_info * __ptr64] =  0# 0x00007FF7DA16A37E in casparcg
[2022-06-05 09:37:44.097] [error]    1# 0x00007FF7DA199690 in casparcg
[2022-06-05 09:37:44.097] [error]    2# 0x00007FF7DA3A12E0 in casparcg
[2022-06-05 09:37:44.097] [error]    3# 0x00007FF7DA3A4602 in casparcg
[2022-06-05 09:37:44.097] [error]    4# tbb::detail::r1::acquire_writer in tbb12
[2022-06-05 09:37:44.097] [error]    5# tbb::detail::r1::acquire_writer in tbb12
[2022-06-05 09:37:44.097] [error]    6# tbb::detail::r1::acquire_writer in tbb12
[2022-06-05 09:37:44.097] [error]    7# tbb::detail::r1::acquire_writer in tbb12
[2022-06-05 09:37:44.097] [error]    8# tbb::detail::r1::acquire_writer in tbb12
[2022-06-05 09:37:44.097] [error]    9# configthreadlocale in ucrtbase
[2022-06-05 09:37:44.097] [error]   10# BaseThreadInitThunk in KERNEL32
[2022-06-05 09:37:44.097] [error]   11# RtlUserThreadStart in ntdll
[2022-06-05 09:37:44.097] [error]
[2022-06-05 09:37:44.097] [error]
[2022-06-05 09:37:44.097] [error]    0# 0x00007FF7DA16A37E in casparcg
[2022-06-05 09:37:44.097] [error]    1# 0x00007FF7DA169CAF in casparcg
[2022-06-05 09:37:44.097] [error]    2# 0x00007FF7DA6E8ED7 in casparcg
[2022-06-05 09:37:44.097] [error]    3# 0x00007FFC9C2E1030 in VCRUNTIME140
[2022-06-05 09:37:44.097] [error]    4# is_exception_typeof in VCRUNTIME140
[2022-06-05 09:37:44.097] [error]    5# RtlCaptureContext2 in ntdll
[2022-06-05 09:37:44.097] [error]    6# 0x00007FF7DA3A0825 in casparcg
[2022-06-05 09:37:44.097] [error]    7# 0x00007FF7DA5338E3 in casparcg
[2022-06-05 09:37:44.097] [error]    8# configthreadlocale in ucrtbase
[2022-06-05 09:37:44.097] [error]    9# BaseThreadInitThunk in KERNEL32
[2022-06-05 09:37:44.097] [error]   10# RtlUserThreadStart in ntdll
[2022-06-05 09:37:44.097] [error]

Any idea? …

Seems to me that this is the main problem. Is your file a “legal” one? Are you able to play it with other tools (i.e. vlcplayer or ffmpeg itself)?


Yes i play with vlc without problem
And i can seek the file smoothly in vlc

Seeking a specific frame when using Long-GOP codecs is a very complex process. In answer to a question posted in May 2021 hreinnbeck suggests that when seeking to a frame is used the file should use I frame encoding only.

Obviously MPEG encoders can create I Frame only coding, for example when used in IMX codecs. You report that CasparCG and VLC can play your file from the start, implying the bitstream syntax is probably ok. So several questions:

Is your file using long GOP, if so is frame 301 an I frame?
What frame rate operations are you using? This impacts on audio-video presentation in the number of audio samples per picture (5 frame cyclic variance in 29.97 Hz based operations).
Is the file muxed as a program stream or a transport stream?
Which audio codec is in use?

You can obtain information about the streams using the ffprobe.exe command line tool. A copy of this tool is available in your CasparCG server folder. A summary of file properties is reported by a command line of the format below.

<path_to_CasparCG_Folder>\ffprobe <path_to_video_file>\myMpegFile.mpg -hide_banner

If your file probe says the audio is encoded using mpeg-1 layer 2 codec (also called mp2 codec) the error you see in attempting a seek is likely to be an issue related to the mechanism used to find the access point into the audio stream.

MPEG uses the concept of a presentation unit for it’s operations. In the video stream the presentation unit is 1 picture, but the audio presentation unit varies. In MPEG-1 layer 1 the presentation unit is 8ms, whereas MPEG-1 layer 2 uses a presentation unit that is 24ms duration.

The data reduced information with the header descriptor passes to the packetisation processes, along with the clock synchronisation (PCR or SCR) and the relative output timing for the presentation unit (PTS). Program stream multiplexing uses a single layer packetising operation, transport streams use a two-layer packetisation. DVD tends to use single layer multiplexing.

The data-reduced information is encapsulated into a Packetised Elementary Stream (PES) that includes the PTS timestamp. The PES packet may be split into multiple fixed size packets for program stream multiplexing requirements (for example to map a PES packet into a physical sector of a DVD disk).

In transport streams the large audio PES packet is mapped into 188-byte transport packets (4 header bytes, 184 payload bytes). The rule is that a PES packet must be mapped into an integer number of transport packets, with transport packet padding inserted as required to fill the packets. Depending on the audio data rate used this wrapping can produce very poor efficiency because large amounts of padding get inserted relative to the user payload.

To improve bitstream efficiency some multiplexers combine multiple audio presentation units into a PES packet resulting in a much lower percentage of stuffing required. Many broadcast services I have examined in detail have 5 audio presentation units per PES - this is 120ms of audio content.

When decoding starts the processing has to regenerate the system clock, and decide which stream it will initially start (video or audio). Once that stream is outputting sample data the decoder looks for a random access point into stream 2 - typically via the Payload Unit Start Indicator in the transport stream header indicating that transport packet contains the start of a PES packet.

In general, consumer based decoders in digital TVs or adapter boxes tend to output the audio first, later showing a picture when an I frame occurs. Professional decoders tend to start up the picture stream first (as this normally has the system clock stream in same transport packets as the video) then looking to output the synchronised audio once video decoding starts. Note neither decoder is seeking a specific frame number, they are just doing random access into the stream.

I would not be surprised that ffmpeg issues an error message if it does not see the two payload start markers within a small time frame.