Quoting Anton Khirnov (2024-09-14 11:01:27)
> It is, but mainly as a testing/development aid, I do not expect it to be
> generally useful. Or is there a particular reason you need to
> interleave the views into one stream?
Understood. Since we can extract both views synchronized with the view
spe
Quoting James Almer (2024-09-13 22:57:44)
> It's probably not misplaced but mistagged as nuh_layer_id == 0 when it
> should be 1 (Can SEI NALUs be in anything other than the base layer?).
> The SEI is User Data Unregistered, and its contents are different than
> the one preceding the base layer VCL
Quoting Danny Hong (2024-09-13 19:58:53)
> Quoting Anton Khirnov (2024-09-13 12:44:55)
> > Note that -view_ids is a decoder option and does nothing with
> > streamcopy.
> > Also, that option is intended for API users, with ffmpeg CLI you should
> > be using view specifiers instead.
>
> Thanks! T
On 9/13/2024 5:51 PM, Danny Hong wrote:
Quoting James Almer (2024-09-13 22:19:35)
Are you talking about decoding the resulting raw bitstream created from
doing stream copy from the source mov? If so, what's happening is
probably that the parser is splitting AUs when the second SEI with
layer_id
Quoting James Almer (2024-09-13 22:19:35)
> Are you talking about decoding the resulting raw bitstream created from
> doing stream copy from the source mov? If so, what's happening is
> probably that the parser is splitting AUs when the second SEI with
> layer_id == 0 shows up in those non-conforma
On 9/13/2024 2:58 PM, Danny Hong wrote:
Quoting Anton Khirnov (2024-09-13 12:44:55)
Note that -view_ids is a decoder option and does nothing with
streamcopy.
Also, that option is intended for API users, with ffmpeg CLI you should
be using view specifiers instead.
Thanks! Tried with "-map 0:
Quoting Anton Khirnov (2024-09-13 12:44:55)
> Note that -view_ids is a decoder option and does nothing with
> streamcopy.
> Also, that option is intended for API users, with ffmpeg CLI you should
> be using view specifiers instead.
Thanks! Tried with "-map 0:v:view:all" and the result is the sam
Quoting Danny Hong (2024-09-09 19:45:57)
> Thanks for the patch set! Ran some initial tests and here are some
> findings:
>
> 1. Tested using the HTM ref SW encoded bitstreams; the HTM encoded 2 layer
> MV-HEVC elementary streams are decoded by both the HTM decoder and ffmpeg,
> and both resulted
Thanks for the patch set! Ran some initial tests and here are some
findings:
1. Tested using the HTM ref SW encoded bitstreams; the HTM encoded 2 layer
MV-HEVC elementary streams are decoded by both the HTM decoder and ffmpeg,
and both resulted in the same decoded pixels for both views.
2. Teste
Quoting Anton Khirnov (2024-09-03 11:57:48)
> If nobody objects or wants more time for review, I'd like to push
> patches up to 24 (excluding 04 and 05) in a few days. That includes
> mainly
> * av_opt_set_array(), which we want anyway, whatever happens to the rest
> of the set;
> * adding HEVC m
If nobody objects or wants more time for review, I'd like to push
patches up to 24 (excluding 04 and 05) in a few days. That includes
mainly
* av_opt_set_array(), which we want anyway, whatever happens to the rest
of the set;
* adding HEVC multiview, which is trivial and independent of actual
d
On 8/27/2024 12:04 PM, Anton Khirnov wrote:
One potential point of discussion is that the caller may want to know
the view ID in its get_buffer2() callback (this is actually used in the
ffmpeg CLI code). One potential option is attaching the view ID side
data before calling get_buffer2(), but tha
Hi,
this patchset adds support for decoding MV-HEVC (multiview, typically
used for stereoscopic 3D video). The code currently supports at most two
views, with the second depending on the first (i.e. using it for inter
prediction). Both views have to be of the same size; the spec allows
them not to
13 matches
Mail list logo
