breakpad in Uverse

I integrated breakpad into AT&T U-verse STB crash logging system starting 2015.
breakpad is google’s open-source multiplatform crash reporting system.
1. smaller dump file. The core dump is usually hundreds of MB, hundred times larger than breakpad dump, or mini dump.
2. its minidump file follows Windows MiniDump MDMP format, standard format generating call stack for all threads.
cons: in-process reporting, but fixed by Crashpad, out-of-process reporting

1. Establish a way to link to breakpad library and run init:
This can be done without touching the main application binary file, which is named TV2MonoClient.
start application: LD_PRELOAD=/mnt/ TV2MonoClient
we hood up breakpad with TV2MonoClient in DllMain() of
2. tell TV2MonoClient where to save the minidump upon crash in DllMain:
c++ code: new google_breakpad::ExceptionHandler(MinidumpDescriptor, NULL, dumpCallback, NULL, true, -1);
MinidumpDescriptor has the full file name of the minidump
dumpCallback is called when the dump has been created, where we can, e.g. upload the dump.
3. parse the minidump into plain text file
all the symbol files of TV2MonoClient and .so files are needed.
Parsing was done on a windows server, and the key tool is minidump_stackwalk.exe from google, like so:
minidump_stackwalk.exe minidumpfile .\appSymbolFiles >plainStackOutput.txt 2>err.txt
plainStackOutput.txt receives the call stacks.

Sequence of video ad

Here is a sample sequence, using preroll as an example.
get VMAP, Video Multiple Ad Playlist, form DFP, e.g. vmap.xml, which has preroll midroll ad.
vmap.xml look like this, with URLs for preroll:

The AdTagURI above returns a preroll ad, which is a VAST, e.g. vast.xml, and looks like the following:

<Ad id=”7096…..”>
<Creative id=”578610…..
<Tracking event=”start”>;
<ClickThrough id=”GDFP”>;
<MediaFile id=”GDFP”…/file.mp4

Some of the key fields are:
Impression: call this URL to tell that this ad has been viewed.
Tracking: call this URL to tell that the video ad has started playing
ClickThrough: the URL to go to when the ad is clicked.
MediaFiles: the .mp4 if the video ad

For JW Player, vast.xml is passed into Setup() as:
advertising.schedule.adbreak1.tag, with adbreak1.offset=pre


Here is one way of doing SSAI, Server Side Ad Insertion
Encoder outputs with SCTE35 metadata track gets translated to HLS.
Live video input in HSL origin.m3u8, with markers like this:
#EXT-X-CUE-OUT:9 ad time start here, for 9 seconds
#EXT-X-CUE-OUT-CONT:ElapsedTime=4,Duration=9 ad time 4 seconds passed
#EXT-X-CUE-IN ad time ends
Ad insertion service replace the things like EXT-X-CUE* with ad segments ad.ts
Ad insertion service output regular playlist dai.m3u8
Player requests dai.m3u8, which includes things like movie234.ts and ad23.ts
Player requests movie234.ts from CDN, and ad23.ts from Ad insertion service

More reachable players: Player doesn’t have to do the stitching since server does it
Harder to block the ads:
Hard to detect ads: No calls are made to DFP asking what ad to play
There is no ready-to-use movie stream

More likely fraud: no need to fake many players; just fake the server.
since the server sends ad impression tracking on the player’s behalf, even with X-Forwarded-For


Client side ad insertion flows like this:
Video comes in with SCTE35 to indicate ad breaks.
Client send VAST request to DFP for ad video URL.
Insert the ads video into main video.
Video experience is not as good due to delay and different resolution and FPS.
These ads can be blocked too by detecting ad video from known ad server.