On Fri, 22 Nov 2024, Scott Theisen wrote:
On 11/22/24 16:12, Marton Balint wrote:
On Fri, 15 Nov 2024, Scott Theisen wrote:
From: ulmus-scott <scott.the....@gmail.com>
DVB VBI data is defined in ETSI EN 301 775 and can include EBU teletext
data
as defined in ETSI EN 300 472.
ETSI EN 300 468 defines teletext_descriptor, VBI_data_descriptor, and
VBI_teletext_descriptor, which has the same definition as, but different
use
from, teletext_descriptor.
Hmm, adding a new codec for VBI data might be OK, but I am not sure if
there is a better way to automagically let the framework know if there are
teletext compatible VBI packets, so the teletext decoder can be used.
Would another AVCodecID AV_CODEC_ID_DVB_VBI_WITH_TELETEXT that would use the
teletext decoder work? Would this be AVMEDIA_TYPE_SUBTITLE even though it
also includes data? (Also, what teletext decoder?)
I am not that big fan of adding both DVB_VBI and DVB_VBI_WITH_TELETEXT,
considering these use the same essence format.
And VBI_teletext_descriptor is an additional descriptor to
VBI_data_descriptor as far as I understand the standard. (Although ETSI EN
300 468 6.2.47 seems to be referring to teletext_descriptor as an
additional descriptor, but that makes little sense to me, they meant
VBI_teletext_descriptor here?)
Or maybe we should simply set the codec id to DVB_TELETEXT if there is a
VBI_TELETEXT_DESCRIPTOR, and make the teletext decoder parse all data
units in search for a comptaible data unit id?
That would work only if you don't want to use any of the other VBI data,
which is what MythTV currently does, ignoring packets where data_identifier
is not EBU data and data_field()s where data_unit_id is not EBU teletext data
as defined in ETSI EN 300 472.
My main concern is if someone wants to decode the other types of VBI data how
would they do that, or know to try, if it claims it is just EBU teletext
data?
FFmpeg does not have data decoders, so the user has to parse the packets
anyway if he is interested in VBI.
Because if we set the codec to VBI for VBI_TELETEXT cases, won't this
break the automatic probing of unknown codecs? (which otherwise might
recognize the stream as teletext)? So maybe for VBI_TELETEXT_DESCRIPTOR
case we should keep the coded id NONE and rely entirely on probing?
I have no idea how this would interact with the automatic probing.
Me neither to be honest, and relying entirely on probing is not very nice
in the first place, so let's just forget this.
Maybe we should stick to your original idea, use a single codec for the
VBI streams, but make it AVMEDIA_TYPE_SUBTITLE, considering it can contain
teletext (even if there is no VBI teletext descriptor in case of inverted
teletext) and even closed captions, which our decoders might be able to
decode to something meaninful.
Then anybody interested can add a new decoder for this new codec ID
(which obviously can share code with libzvbi-teletextdec), so it will be
able to decode teletext as well.
Regards,
Marton
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
