On Mon, 21 Feb 2022, Eran Kornblau wrote:
On Mon, Feb 21, 2022 at 5:07 PM Eran Kornblau <eran.kornb...@kaltura.com> wrote:
Hi all,
We've recently upgraded our ffmpeg version, and we got a playback issue on some
Sony TV models that are playing HBBTV/DASH+DRM - video plays fine, audio
doesn't play at all.
Listing here some of the affected models (not pasting all, the list is long...)
- KDL-32W600D, KDL-40W650D, KDL-48W650D, KDL-43W750D, KDL-49W750D, KDL-55W650D.
After some investigation, we found the cause was the addition of the
'btrt' atom to the mp4 –
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2FFFmpeg%2FFFmpeg%2Fcommit%2F3838e8fc210aa09a9f9058506c0ce80b6a
d9b9c3&data=04%7C01%7C%7Cc96aade7b4354115844508d9f5665925%7C0c5037
48de3f4e2597e26819d53a42b6%7C1%7C0%7C637810642206022682%7CUnknown%7CTW
FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn0%3D%7C3000&sdata=Na7ZxDQTby8Xq9CjB51lJyP1IOMdwLqoRLNODUC4nX0%3D
&reserved=0 The TV decoder expects to get the sinf atom right
after esds, and doesn't properly handle the btrt atom in between (our
packager adds the sinf atom at the end of the original stsd entry that was read
from the mp4 file).
Since, in my understanding, the btrt atom was added mostly for reporting
reasons, IMHO, it should be a config option - off by default.
I would happily submit a patch for it, but sending this first, in case there
are any concerns/objections.
In case the use case was unknown, the primary reason for adding this was to
utilize this box to inform a media server of an incoming live stream's bit
rate, since the overall bit rate cannot be calculated for something that isn't
done yet
(https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdashif-documents.azurewebsites.net%2FIngest%2Fmaster%2FDASH-IF-Ingest.html&data=04%7C01%7C%7Cc96aade7b4354115844508d9f5665925%7C0c503748de3f4e2597e26819d53a42b6%7C1%7C0%7C637810642206178898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=auOsZ4L7jR35BZxi45Onk9UQWoio2xOzJ%2BqcdN7yASk%3D&reserved=0
as an example of one such use case). This being an alternative to nonstandard
things such as ISML manifests.
Additionally, since it seemed to be specified at the end of the given
structures, I added it at the end of these given boxes. Apparently thus it made
your live patching of that box no longer compatible with these parsers, since
you just append your required things to the end of it. Am I understanding
things correctly?
Our code adds the sinf box after the existing stsd entry, it is correct also
when btrt is present, as an evidence to this - playback works fine on all other
devices.
The problem, in my understanding, is in the decoder present on the affected
Sony TV models - it seems the decoder is making an assumption that the sinf box
should come right after the esds box,
while AFAIK, the spec does not mandate any order. Verbatim response we got from Sony:
"btrt box in the audio chunk is causing the TV decoder to fail. TV decoder is
expecting sinf box after esds box.".
So, even though it seems the TV decoder is the culprit, since the btrt atom can
cause such failures, IMHO it should be omitted by default.
Users who need the benefits this atom provides, will be able to enable this
functionality, of course.
Ability to turn it off is OK, changing default to not write it does not
seem right.
Also you are poiting at btrt atom, but in fact sony said: "TV decoder
expecting sinf box after sdds box", so the proper fix seems to be to
change the order of the atoms, and add a big fat warning to the code that
because of some sony TV models, sinf box must be immediately after esds
box. Is this doable?
Thanks,
Marton
Thanks
Eran
Jan
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmpeg-devel&data=04%7C01%7C%7Cc96aade7b4354115844508d9f5665925%7C0c503748de3f4e2597e26819d53a42b6%7C1%7C0%7C637810642206178898%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OBl349gLsGcHI%2FY%2FukRf%2BrulgovZ1t8%2BE511hsxcH%2FI%3D&reserved=0
To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject
"unsubscribe".
_______________________________________________
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".
_______________________________________________
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".