Video Sample Production Summary

1. Video Sample Production Summary Leigh ThorpeNortel Paris, 7-11 May 2007

2. Video Clip Production Lab Setup Real Mobile Producer (Envivio) -used to produce the sample clips encoded at the required format from source YUV files NAS Drives -containing the SRC and PVS Encoding PC network 47.135.125.10 47.135.125.11 Client PC Server PC Ineoquest Singulus -used to generate dropped packets Baystack Switch -Ethernet switch to connect everything together Real Helix Mobile Server -plays out the clips when requested from the client Client PC with SQQTClient capture -receives the clips over ethernet with dropped packets, and converts back to uncompressed YUV Step 1 – upload SRC to Encoding PC Step 2 – Encode SRC and upload to Server PC Step 3 – Stream encoded file through Singulus for packet loss to Client PC and capture resulting PVS Step 4 – upload PVS to NAS drive

3. Video Clip Production Procedure video clip is sent over a network with dropped IP packet impairments generated by Ineoquest Singulus source YUV file from VQEG pool CIF and QCIF (16-bit or 12-bit) file encoded to .3gp using Real Mobile Producer video clip is stored in Real Helix Mobile server for streaming (hint tracks used) video clip received with impairments video clip converted to YUV format using SwissQual tool (appears to be 24-bit)

4. Notes on the Common Files Processing • Create scenarios reflecting typical current mobile video operating conditions • Settings based on reviews of services in Europe and North America • QCIF • MPEG-4 part 2 SP encoding, 3gppv5 format, 500 bytes / packet setting • 10 fps • 128 kbps • 1% packet loss • CIF • H.264 encoding, 3gppv6 format, 1000 bytes / packet setting • 20 fps • 256 kbps • 1% packet loss

5. Sample Impairment Stills

6. Comments Based on Preliminary Work • Comments: • User experience impacts of packet loss are highly dependent on the player’s response to packet loss • stability in face of packet loss • loss concealment mechanisms • OS and platform and other handset implementation specific details • Packet loss also dependant on bytes / packet settings used in hint tracks when encoding the files for streaming • particularly for low bit rate streams • we selected settings that resulted in a number of RTP packets streamed that aligns with what is being used in networks we’ve studied • Packet loss effects will be dependent on encoder and levels / profiles used • Some effects of packet loss are masked by motion or encoding impairments particularly at QCIF resolutions and low bit rates • Some packet loss results in frame loss and no other obvious impairments (like slice / block errors) on other frames and at low frame rates (10 fps) the lost frames may not be obvious

7. Issues and Questions based on Preliminary Work • SQQTClient Capture tool • Some quirks in capture tool operation (need to close the file explicitly or exit the program between captures as per the Readme) • Not sure how the frame timestamps are derived - we see indication of delayed (and likely lost) frames during our IP packet drops but also see variability in timestamps when streaming encoded files without drops (but playback indicates consistent frame rate) • see CIF Timecompare tab in uploaded spreadsheet • QCIF seems OK • Could be on Real Helix server side • Seem to be getting a few frames dropped from the end of the files when streaming in some cases – not a problem since we’ll drop 2 seconds anyway • Ex. On QCIF time compare tab in spreadsheet - .3gp file is 12.0 s but streamed and captured .avi is 11.23 s (Quicktime properties view) and .log files shows 117 frames and would have expected 120 frames (10 fps * 12s)

8. Nortel / CRC CIF Production Matrix Note: Only 136 of the 576 combinations are produced

9. Nortel / CRC QCIF Production Matrix Note: Only 136 of the 576 combinations are produced

10. Notes on the Production Matrix • Not all combinations are produced • 136 will be produced at each resolution • (see the detailed spreadsheet for detailed combinations) • Typically the higher the frame rates, the higher the bit rates • Therefore the low frame rate/high bit rate and high frame rate/low bit rate are not sensible combinations in the real world • This is because if more bandwidth is available, both frame rate and bit rate are increased in order to achieve higher quality video • In addition, there will be 16 sequences produced as follows: • 8 x QCIF, MPEG-4 Part 2 SP, 128 kb/s, 10 fps, 500-byte packets, 1% burst loss • 8 x CIF, H.264, 256 kb/s, 20 fps, 1000-byte packets, 1% burst loss

11. Backup Slides

12. Notes on the Swiss Qual tool -open URL under “file” -press “play” under “movie” -under “movie”, click “stop” and “rewind” twice -press “record” followed by “play” and the video should download once and be converted to an AVI -be sure to “close AVI” when done -if the procedure needs to be repeated, change the file name or delete the previous AVI and log files, or else the next result will show up in another directory -check “UDP” under options

13. Helix Producer -set to 3GPPv6 singlerate for both MPEG4SP and H.264 -make sure the source and destination file names are correct (so that the encoded file can be found again) -keep a record of the encoding details for each output file name

14. Helix Producer -select the bit rate, encoding format, and frame rate -uncheck audio to make sure the bit rate is all video

15. Helix Producer -uncheck “resize” and/or make sure the resolution is correct

16. Helix Producer -check “Progressive Download Profile” so that MPEG4 metadata arrives at beginning of stream -check “Streaming-server profile” to generate hint tracks -set maximum packet size to 500 or 1000 to improve error granularity

17. Typical File Sizes and Dropped Packets note: these figures should be independent of CIF or QCIF