Respect video FPS and audio frame length when seeking.
Video PTS are now x(1/fps), even after a seek.
Audio PTS are now x(audio_sample_length), even after a seek.
In the default config, audio packets are 40ms long and video is 25/1
frame per seconds, so frames are displayed every 40ms. When changing
framerate to 50/1, everything still works correctly and the DemuxVideo
call will generate two frames for one audio packet, and the sys->clock
accumulator will move forward 40ms too.
However, when using any frame rate value that would make 40ms not
divisible by the video frame duration, eg. 60/1fps which is a period of
16.666ms, then the video would drift apart from the other tracks.
Symmetrically, when using any frame rate value < 25/1 that would not be
divisible by 40ms, the audio would drift apart from the other tracks.
It came from the fact that video and audio were allowed to move forward
the same amount starting from their previous pts value, which is not the
same starting point for each track in case the divisibility condition is
not met.
The following graph represents the situation by drawing the two tracks
with different origins to show how the video makes more progress than
the audio in the case audio has 40ms packet and video is 60/1fps.
PTS video
^ audio * --+
| * / | We go further than the
| / * | audio track here. But
| / / | we'll continue sending
| / * --+ packets by group of 3.
| / /
| * *
| / /
| / *
| / /
| / *
| * /
| / * --+
| / / | This shows we can generate three
| / * | video packet for each audio
| / / | packet in the current state.
| * * --+
| / /
+---------------------------------------->ts
By keeping the track-specific start point, we don't miss any value, and
by setting the maximum date from sys->clock instead of the
track-specific start point, we ensure we don't send more packets than
wanted.
Fix#29122
Even if for now, we have only one string (that was freed correctly).
Add the possibility to use strings in track options without leaking when
the option is overridden.
The parameter allows to inject a fixed amount of images, which is useful
when checking the drain behaviour of video pipeline in playback or
transcode.
It will trigger EOS for the input regardless of the length= parameter.
So that the requested audio_sample_length * rate / CLOCK_FREQ has more
change to be divisible. It's a not issue if that not the case, the
module will use its own sample_length near to the requested one.
This can be useful to test the order of colors in RGB with mask.
The 15-bit and 16-bit values are currently written as Little-Endian to verify
that's what Windows expects. It can be extended when we add hardcoded
LE and BE chromas.
The chroma is set by the user, it may be one of the RGB with a mask chromas.
And the user can't specify a mask, so later is will be assumed to be using
these masks.
Example:
"mock://node[2]{video_track_count=1};node_count=4;length=1000000;node[1]{length=2000000}"
Will create the following sub items:
- input_item_New(mock://length=1000000, submock[0]);
- input_item_New(mock://length=2000000, submock[1]);
- input_item_New(mock://video_track_count=1, submock[2]);
- input_item_New(mock://length=1000000, submock[3]);
If specified with node[]{}, a sub item will use the params between "{}".
If not specified, all subitems will use the same params from the url (here:
"length=1000000").
This will be needed for the future and reworked media_list_player test.
The PTS is a fraction of the length but should always be re-normalized
by adding VLC_TICK_0 to be a valid timestamp.
test_input_decoder_mock decoder: Wait for the picture to be flushed from the vout
main input debug: control type=2
main input debug: ES_OUT_RESET_PCR called
main input error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR !
see e967f81f6a.
note, this does **not** affect cat-based module selection items
(of which there are just three in use by the core), since that
mechanism uses subcats not cats.
The config "advanced" flag was unused and has been removed by
6a7a137f7b.
It has been removed from many add_*() macros, but not all. Remove it
from the remaining macros.
Usage: ./vlc 'mock://<mock options>;video_orientation=<orientation>'
The video_orientation option is an integer representing the raw
values of video_orientation_t. Thus the range of possible values
is ORIENT_TOP_LEFT = 0 -> ORIENT_RIGHT_BOTTOM = 7.
Fix#25054
Signed-off-by: Alexandre Janniaux <ajanni@videolabs.io>
And use the default pts delay.
There is a double MS<->TICK conversion in order to keep the same unit than
"file-caching" and "network-caching" arguments.