On Fri, 22 Nov 2024, Anton Khirnov wrote:
Quoting Marton Balint (2024-11-19 22:47:31)
The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
Rework the parser logic to work similar
Quoting Marton Balint (2024-11-19 22:47:31)
> The current parser does things which a parser should not, like skipping parts
> of the packet header, but it does not actually able to packetize a raw DNXUC
> bitstream.
>
> Rework the parser logic to work similar to other parsers and be able to
> corr
On Fri, 22 Nov 2024, martin schitter wrote:
On 20.11.24 22:03, Marton Balint wrote:
The parser's primary job is to packetize a non-packetized stream and maybe
get some basic information about the packets which normally the container
has.
As long as we only support single component va
On 20.11.24 22:03, Marton Balint wrote:
The layering issue is for the decoder to take care of, not the parser.
Yes, we could handle it in the decoder just like in case of OpenEXR,
where we use a special `-layer` option to specify the component/layer
to pick out of the input stream.
But
On Wed, 20 Nov 2024, martin schitter wrote:
On 19.11.24 22:47, Marton Balint wrote:
The current parser does things which a parser should not, like skipping
parts
of the packet header, but it does not actually able to packetize a raw
DNXUC
bitstream.
You're right! I simply can't reje
On 19.11.24 22:47, Marton Balint wrote:
The current parser does things which a parser should not, like skipping parts
of the packet header, but it does not actually able to packetize a raw DNXUC
bitstream.
You're right! I simply can't reject this judgment about the obvious
flaws of the curr
