This fix EsOutDrainCCChannels() not being called in the nominal case.
But this does not fix any issues since the es_out don't have access to CC
dec pointers: EsOutDrainCCChannels() is a noop (will be fixed in a next
commit).
It's only needed from the ES_OUT_SET_ES_FMT control and when the demuxer
is deleting an ES.
The normal drain polling is done via ES_OUT_GET_EMPTY.
Both solutions are not good, but it's not for VLC 4.0...
And also check that:
- CC selection works for channel > 1
- Adding CC tracks at non-continuous indexes (10 and 64)
- 2 SPU tracks can be rendered at the same time.
The index of the cc track is now the bitmap index, and not the array
order.
video/0/cc/spu/auto/0 is now video/0/cc/spu/auto/1 (if the first bitmap
is valid, otherwise, the last digit can be between 1 and 64).
The last digit of cc track str_id now match the log:
main input debug: Adding CC track 1 for es[0]
main input debug: ES track added: 'video/0/cc/spu/1' (fourcc: 'c708')
main input debug: Adding CC track 2 for es[0]
main input debug: ES track added: 'video/0/cc/spu/2' (fourcc: 'c708')
main input debug: Adding CC track 3 for es[0]
main input debug: ES track added: 'video/0/cc/spu/3' (fourcc: 'c708')
main input debug: Adding CC track 4 for es[0]
main input debug: ES track added: 'video/0/cc/spu/4' (fourcc: 'c708')
New scenarios with a text_renderer may go through the rendering/blend
step in video_output.c and trigger an assert if the picture don't have
valid data.
This fixes the following non systematic assert:
test_src_input_decoder: ../../src/misc/picture.c:385: plane_CopyPixels: Assertion `p_in' failed.
Thread 63 "vlc-vout" received signal SIGABRT, Aborted.
[Switching to Thread 0x7ffff58ba6c0 (LWP 1264089)]
0x00007ffff7ceed3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
0 0x00007ffff7ceed3c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
1 0x00007ffff7c9ff32 in raise () from /lib/x86_64-linux-gnu/libc.so.6
2 0x00007ffff7c8a472 in abort () from /lib/x86_64-linux-gnu/libc.so.6
3 0x00007ffff7c8a395 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
4 0x00007ffff7c98e32 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
5 0x00007ffff7f43d33 in plane_CopyPixels (p_dst=0x7fffec0011c0, p_src=0x7fffe0001a20) at ../../src/misc/picture.c:385
6 0x00007ffff7f43dd2 in picture_CopyPixels (p_dst=p_dst@entry=0x7fffec001130, p_src=p_src@entry=0x7fffe0001990)
at ../../src/misc/picture.c:415
7 0x00007ffff7f43e41 in picture_Copy (p_dst=p_dst@entry=0x7fffec001130, p_src=p_src@entry=0x7fffe0001990)
at ../../src/misc/picture.c:425
8 0x00007ffff7f1eea4 in PrerenderPicture (out_subpic=<synthetic pointer>, out_pic=<synthetic pointer>,
render_now=<synthetic pointer>, filtered=0x7fffe0001990, sys=0x7fffe801c640)
at ../../src/video_output/video_output.c:1231
9 RenderPicture (sys=sys@entry=0x7fffe801c640, render_now=render_now@entry=false)
at ../../src/video_output/video_output.c:1312
10 0x00007ffff7f2014d in DisplayPicture (vout=0x7fffe801c640) at ../../src/video_output/video_output.c:1521
11 Thread (object=0x7fffe801c640) at ../../src/video_output/video_output.c:1845
12 0x00007ffff7ced044 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
13 0x00007ffff7d6d61c in ?? () from /lib/x86_64-linux-gnu/libc.so.6
VLC_CODEC_BGR555 should be defined on BE architectures as VLC_CODEC_BGR555BE and not VLC_CODEC_BGR565BE
Fixes build failure:
video_filter/blend.cpp: In constructor ‘{anonymous}::CPictureRGB16::CPictureRGB16(const {anonymous}::CPicture&)’:
video_filter/blend.cpp:357:9: error: duplicate case value
357 | case VLC_CODEC_BGR555:
| ^~~~
video_filter/blend.cpp:347:9: note: previously used here
347 | case VLC_CODEC_BGR565:
| ^~~~
video_filter/blend.cpp: In constructor ‘{anonymous}::convertRgbToRgbSmall::convertRgbToRgbSmall(const video_format_t*, const video_format_t*)’:
video_filter/blend.cpp:506:9: error: duplicate case value
506 | case VLC_CODEC_BGR555:
| ^~~~
video_filter/blend.cpp:496:9: note: previously used here
496 | case VLC_CODEC_BGR565:
| ^~~~
The output is a bitstream in some codec, not a chroma that can be used as such.
The codec value should not be set as a chroma in the video_format_t.
The output video format is only used to force some dimensions on the output
that may not be the ones from the source.
This can avoid 3 extra lock/unlock when deleting the decoder in a
normal scenario.
The 4-64 CCs decoder where not cleaned (leaking) due to the
VLC_CODEC_CEA608 hardcoding.
This is the error we have:
../../../modules/codec/png.c:162:49: warning: '%zu' directive output may be truncated writing between 1 and 20 bytes into a region of size between 18 and 37 [-Wformat-truncation=]
162 | "block size %zu too small for %zu encoded bytes",
| ^~~
../../../modules/codec/png.c:162:19: note: directive argument in the range [1, 18446744073709551615]
162 | "block size %zu too small for %zu encoded bytes",
So we can pass a chroma description in place of a chroma, rather than having
to combine them.
It's the same storage size in memory/code but provides extra possibilities.
Pierre Lamot
Steve Lhomme
Thomas Guillem
Benjamin King
Fatih Uzunoglu
Gianfranco Costamagna
Maxime Chapelet
Steve Lhomme