Analysis of Facebook's video encoders

Material Information

Analysis of Facebook's video encoders
Wolanin, Jacek Emil
Place of Publication:
Denver, CO
University of Colorado Denver
Publication Date:

Thesis/Dissertation Information

Master's ( Master of science)
Degree Grantor:
University of Colorado Denver
Degree Divisions:
Department of Music and Entertainment Industry Studies, CU Denver
Degree Disciplines:
Recording arts
Committee Chair:
Grigoras, Catalin
Committee Members:
Smith, Jeff
Burgess, Scott


Ever since Facebook’s launch in 2004 by Mark Zuckerberg, Dustin Moskovitz, Chris Hughes and Eduardo Saverin the social media site has only grown and expanded in popularity, features and products. In 2006, two years after its launch, Facebook announced a brand new feature for cell phones; Facebook Mobile. A year later (2007), Facebook launches another new feature; Facebook Video. This new application allowed people to upload their videos and share them with other people for the first time as well as upload them using just their cellphones [1]. When Facebook first expanded its registration to everyone in 2006, it had 12 million active users [1]. Most resent statistics show that in December 2017 there are over 1.4 billion daily active users, and around 2.13 billion active users monthly [2]. Because there are so many users and these two features have been around for over 10 years, lots of videos get uploaded to the cloud for individuals to view. The main purpose of this study is to observe how Facebook’s encoders affect different resolutions uploaded and downloaded using the Facebook mobile application and different internet browsers. Because there is a wide variety of cellphone manufactures, only two smartphone were used; Samsung Galaxy J7 and Apple iPhone 7. The browsers that were utilized were: Chrome, Firefox and Safari.

Record Information

Source Institution:
University of Colorado Denver
Holding Location:
Auraria Library
Rights Management:
Copyright Jacek Emil Wolanin. Permission granted to University of Colorado Denver to digitize and display this item for non-profit research and educational purposes. Any reuse of this item in excess of fair use or other copyright exemptions requires permission of the copyright holder.


This item is only available as the following downloads:

Full Text


by JACEK EMIL WOLANIN B.S ., University of Colorado Denve , 2015 A thesis submitted to the Faculty of the Graduate School of the University of Colorado in partial fulfillment of the requirements for the degree of Master of Science Recording Arts Program 2018




iii This thesis for the Master of Science degree by Jacek Emil Wolanin Has been approved for the Recording Arts Program by Catalin Grigoras, Chair Jeff Smith Scott Burgess Date: May 12, 2018


iv Wolanin, Jacek Emil (M.S., Recording Arts Program ) Thesis directed by Associate Professor Catalin Grigoras ABSTRACT Hughes and Eduardo Saverin the social media site has only grown and expanded in popularity, features and products. In 2006, two years afte r its launch, Facebook announced a brand new feature for cell phones; Facebook Mobile. A year later (2007), Facebook launches another new feature; Facebook Video. This new application allowed people to upload their videos and share them with other people for the first time as well as upload them using just their cellphones [1]. When Facebook first expanded its registration to everyone in 2006, it had 12 million active users [1]. Most resent statistics show that in December 2017 there ar e over 1.4 billion daily active users, and around 2.13 billion active users monthly [ 2]. Because there are so many users and these two features have been around for over 10 years, lots of videos get uploaded to the cloud for individuals to view . The mai n purpose of this study is to obser s affect different resolutions uploaded and downloaded using the Facebook mobile application and different internet browsers. Because there is a wide variety of cellphone manufactures , only two sm artphone were used ; Samsung Galaxy J7 and Apple iPhone 7 . The browsers that were utilized were: Chrome, Firefox and Safari.


v The form and content of this abstract are approved. I recommend its publications. Approved: Catalin Grigoras


vi DEDICATIONS I would like to dedicate this to my parents ; Mariusz and Ursz ula Wolanin, and my sister Aleksandra Kolodziej, whom w ithout them I would not be where I am .


vii ACKNOWLEDGEMENTS I would like to thank Catalin and Jeff for the opportunity to attend and be ing a part of the graduate program . I have learned so much through ng forward to keep learning about media forensics and being an active member of the forensic community. This w ould not be possible without them . I would also like to thank Leah and Emma for making sure I have everything filled out correctly and being extremely helpful throughout the whole program. And finally I would like to thank Scott Burgess for giving me the opportunity of working in the recor ding core. There you let me experiment with lar ge scale projects where you allowed me to figure things out on my own ; but when things got a little too difficult for me, you were there to guide me through it all.


viii TABLE OF CONTENTS Chapter I. . 1 II. . 3 ... 3 H.264/AVC HEVC ... 5 Browsers 5 III . 7 Originals ... 7 Upload 12 Dow IV . Results Samsung Down Metadata Atom Structure Browser iP hone Downlo ad Metadata Atom Structure 23 Encoder Settings 23


ix Browser V. Conclusion Futur .............. 25 List of Abbreviations List of Figures and Tables REFERENCES APPENDIX .. 29


x LIST OF ABBREVIATIONS AVC Advanced Video Codec AAC Advanced Audio Codec MD5 Merkle Damgard 5 (Hash value algorithm) CAVLAC Context adaptive variable length codes CABAC Context adaptive binary arithmetic coding EXIF Exchangeable Image File Format FPS Frames Per Second


xi LIST OF FIGURES AND TABLES Figure 1. 2. 3. 4. .. 15 5. Missing Section Table 1. Original 2. 3. 4. 5. Original Samsu 6. 7. 8. 9. Original iPhone Audio 10. 11. 17 12. 13. Samsung Downloaded Video Inform 14. Samsung Do wnloaded Audio 15. 21


xii 16. 17. 18. 19. 20.


1 CHAPTER I INTRODUCTION Facebook has been around for a long time and has been available to everybody since September 26 , 2006 [1] . Since then Facebook has grown in popularity as one of the major social networks for people to utilize. Because this , it has had to evol ve and add many feature s to keep it relevant and competitive to other social network platforms that have been developed in the past couple of years. Many of the things that were added in the beginning were for user s to share informat ion about themselves to others , for example Facebook Wall . This feature gave people a place to post messages and other items for their friends to view . Then came the Facebook mobile applications and the video upload tool [1] . Because of the expanding features that have been added over time, Facebook has been a relevant social network for individuals to utilize and most likely will stay that way for a long time. Because Facebook is one of the largest social networks in the world and has so many active users on a monthly bases it is important to study it for forensic purposes and have a base understanding of it functions and a understanding of how possible evidence can be modified comparatively to the originals [2] . As stated in the abstract, the goal o f this thesis is to create a foundation of how Facebook encoders affect vid eos that are uploaded via both smartphone and computer a nd then downloaded via computer . Previous Research In recent years there has been a larger focus on Facebook and other so cial media sites on understanding how files are modified when uploaded and downloaded from their servers. Her research focused on how Facebook compression algorithms affect s purposely


2 manipulated images. In addition to this, it also covered whether the manipulations can be detected using DCT (Discrete Cosine Transformation) and ELA (Error Level Analysis). The results of her test showed that due to the heavy compression rates that Facebook uses on digital images, all results caused the manipulated areas to disappear. Thus it is difficult to detect manipulated i mages once uploaded to Facebook [3] .


3 CHAPTER II TECHNICAL OVERVIEW The goal of this chapter is to have a better understanding of file structure and encoders in videos files. This is important as to identify specifics sections of metadata in the originals and see how they are changed after they are downloaded from Facebook . Beca use this research relies on these items so heavily, having an understanding of how they work and look is needed. File Format Most digital video files are structured in the same manner. They all contain a container, video data, audio data, and metada ta. According to SWGDE t he container is a standardized structural method to store the variety of elements necessary to represen t video and audio information [4 ]. Container s can be very complex or very simple. Complex ones can support and large variety of d ifferent audio and video file types while simple ones can only accommodate a very specific video or audio file type. Video codecs are algorithms that encode or decode a video stream, and are used to compress data for efficient transmission of the record ing. Some video codecs compress vide o files while other s do not. Non compressing codec s are called lossless , because they do not degrade the video quality and no information is los t in the compression process . Video encoders that do ha ve compression with d ata loss are called lossy compressors . These algorithms remove re dundant or irrelevant data to reduce the size of the file. [4 ] Metadata is information that is stored in the file. This can contain anything from the size of the file, creation time, author, and GPS information.


4 Figure 1. Simplified File Format H.264/AVC H.264 /AVC was developed by the Joint V ideo Team (JVT). This group consisted of members from the Video Coding Experts Group (VCEG) and Moving Picture Expert Group (MPEG). The first iteration of the H.264 /AVC was approved on May 30 th , 2003 and had a provisional name of H.26L. Since then there have been 12 amendments to the encoder. One of the largest and most noticed is the Fidelity Range Extensions (FRExt) which co nt ains the High Video Profiles. [5 ] H.264/AVC is a very versatile encoder that can support various application s like video broadcasting, video streaming, video conferencing over fi xed and wireless networks and over different transport protocols . [5 ]


5 H.264/AVC contains eight different Video P rofiles: Baseline, Main, Extended, High , High 10, High 4:2:2, and High 4:4:4 . Video P rofiles are designed for specific applications of video streaming. Baseline P rofile is designed for real time conversational services like video conferencing and videophone. Main Profile is designed for digital storage and television broadcasting. Extended Profile is designed for multimedia streaming over IP. T he High Profiles were created for content distribution, content contribution, studio editing and post processing. The Baseline Profile and Extended Profile use CALVC while the Main Profile and High Profiles use CABAC. CALVC and CABAC are entropy encoders a nd are used after the H.264/AVC algorithm reduce s the size of the video file. [6 ] HEVC HEVC formal development was started in January 2010 by ITU T Video Coding Experts Group (VCEG and the ISO/IEC Moving Picture Expert Group (MPEG) ) . Another name for HEV C is H.265. Prior to this both groups were already working on investigatory work in compression capabilities and different algorithmic techniques. The reasoning for developing HEVC was not just to improve compression as much as possible but also help enabl e the deployment of new service s such as ultra high definition television (UHDTV) and vid eo with higher dynamic range. [7 ] Since its release HEVC has gotten 5 amendments added. The most resent being in February of 2018. [8] Browsers Web browsers are applications that are used on a daily bases , so defining them is important . A web browser can be summed up as a software application that is designed to retrieve, present or transfer information on a network. As of 2015 Chrome is the most popular web brows er with 64.9% usage, 21.5% usage going to Firefox, 3.8% usage to Safari


6 and 9.8% usage to all other web browsers. This is particularly interesting since Safari was the first of the three to be intro duced which was in 2003. Firefox came out in 2004, and Chr ome was the last b e i ntroduced which was in 2008. [9 ]


7 CHAPTER III Materials and Methods The programs that were used to extract the infor mation from the originals and downloaded files were FFMPEG, Exiftool, Mediainfo and Atomic Parsley . FFMPEG is an open source, cross platform framework that uses command line to play, convert, and stream [10 ] . FFMPEG also have the capabilities of extracting some metadata as well as video and a udio information about the file [11] . Exiftool is command line application for reading, writing and editing metadata information [12] . Mediainfo is a user interface or command line application that can view container information, metadata, video formats, audio formats and other analytics [13] . Atomic Parsley is also a command line tool that extracts atom location and division [14] . The rest of this chapter will discuss the how the original files were created and look , as well as how the videos were uploaded and downloaded. Originals The origin al videos were created using two different smart phon es; a Samsung Galaxy J7 Prime and an Apple iP hone 7. Each phone created two sets of videos with four different resolutions. The Samsung was capable of creating four different resolutions: 640x480, 1072x 1072, 1280x720 and 1920x1080. All the videos had the same container (mp42) and where encoded AVC (Advanced Video Codec) . T he 640x480 and 1920x1080 videos had a variable frame rate of around 29. 970fps while the 1072x1072 and 1280x72 0 had a variable frame rate of 30fps . All the videos had slightly different video profiles. 640x480 had Baseline@L3, 1072x1072 had Baseline@ L 3.2 , 1280x720 and Baseline@ L 3.1 , and


8 1920x1080 had High@L3 . All the videos had audio formats of AAC (Advanced Audio Codec) with audio prof iles of LC. In addition to this all the videos had two audio channels with 16 bit depth and 48000 sample rate. This information can all be viewed in tables 1, 3 and 4 down below. Table 2 contains creation and modify data and table 5 contains the original M D5 HASH s of the files. Table 1 . Original Samsung Metadata I nformation 1 Table 2 . Original Samsun g Metadata Information 2


9 Table 3 . Original Samsung Video Information Table 4 . Original Samsung Audio Information Table 5 . Original Samsung MD5 HASH Values The iP hone was capable of creating four videos as well. 1280x720 p at 30fps , 1920x 1080p at 30fp s, 1920x1080p a t 60fps and 3840x2160 (4k) at 30fps . The container for


10 all the videos was qt ( QuickTime ). The video format for all the videos was HEVC (High Efficiency Video Coding). The video profiles for all the videos was also slight ly different. 1280x720 30 fps was Main@L3.1@Main , 1920x1080 30fps was Main@L4@Main , 1920x1080 60fps was Main@L4.1@Main , and 3840x2160 at 30fps was Main@L5@Main . All th e videos had a LC audio profile with a n mp4a audio f ormat. Also all the videos were single channel with a 16 bit depth and a 44100 audio sample rate. The sound handler was also appl. This information can all be viewed in tables 6, 8 and 9. Just like with the Table 6 . Original iPhone File Information 1 Table 7 . Original iPhone Metadata Information 2


11 Table 8 . Original iPhone Video Information Table 9 . Original iPhone Audio Information Table 10 . Original iPhone MD5 HASH Values


12 Uploads Once all the videos were created and information extracted , they were uploaded through the Facebook application on the smartphone s and uploaded through a browser on the computers. The Samsung Facebook applications vers ion was and the iP hone version was The videos were uploaded to the timeline as th at was the only place to upload all the videos using the smartphones . In the settings of the Facebook application there was a function that allo wed the videos to be uploaded in HD. Figure 12 s hows where the setting can be changed. All videos were uploaded with the setting on and off. Figure 2 . Network Upload Mobile Settings


13 Once the uploads were done with the smartphone s , they were tr ansferred to the computers via USB cable and uploaded using Google Chrome on both computers. The settings in Facebook for both computers video default quality was set to default. Which can be s een in Figure 3 just below . Figure 3 . Network Upload Desktop Settings Downloads Due to how Facebook currently functions, all videos had to be downloaded from the nal account because the videos could not be downloaded from a different account. In addition to this, all the videos ha d to be downloaded via computer because the Mobile Facebook Application does not have the capability to download videos. T he downloads we re done using three different computers because of the three browsers that were used for the test. Videos that were downloaded using Google Chrome and Firefox were


14 downloaded by a Lenovo Z50 laptop and the videos that were downloaded by Saf ari were done by a MacBook Pro and an iMac .


15 CHAPTER IV Data Overview This chapter goes over the changes that happened to the originals after they were downloade d using the three major browsers . After the videos files were downloaded ( procedure explain ed in the previous chapter), a batch script was created to extract information about the files using command line tools: FFMPEG , Mediainfo, Exiftool and Atomic Parsley . Some of the outcomes were expected ; for example all creation times a nd modification times were all wiped from the metadata. Another expected change was the renaming of the files by Facebook . All the video files were got renamed with 8 numerical characters at the beginning followed by a underscore with another 15 or 16 nume rical chara cters followed by another under score with 18 or 19 numerical characters follow ed by the last underscore with the letter An example can be seen below. Figure 4 . File Name Sample Samsung Download Overview Metadata The first videos that were examined were the videos that were originally produced by the S amsung Galaxy J7 . After the downloads, the videos got re encoded by Facebook into


16 Lavf version 56.40.101. This information can be viewed in Table 11 (page 17 ). Also the container s were changed from mp42 to isom. As can be viewed in Table 12 ( page 17 ) , the resolu tion changed quite a bit in some of the video s and o ne original resolution was depended on how the video was uploaded. The 1920x1080 videos changed to 1280x720 and were not depended whether they were originally uploaded using a smartphone or computer. 1280x720 did not change at all in resolution compared to the originals . This is an interesting observation as later in this chapte r this correlates to the iPhone results. Similarly to the 1280x720, the 1072x1072 also did not change from the original resolution. The most interesting resolution though was the 640x480. This is the only res olution that was upload dependent. If the original was uploaded using a smartphone the download resolution turned to 400x300 while if the video was uploaded with a computer the resolution stayed at 640x480 ( Table 12, page 17 ). Unlike the resolutions, most of the video information stayed the same excluding the Samsung upload of 640x480 . All the videos go t the same Compressor ID (avc1) and the same encoder library (x264 core148) no matter what resolution the original video was. The video format also stay ed the same from the originals (AVC). One interestin g result was that the 640x480 resolution Video Profile . Like the resolutions this was dependent on whether the original video was uploaded using a smartphone or a computer. When the video was uploaded wit h a computer the Video Profile turned into High@L3.1 just like all the other resolutions , but if the video was u ploaded using a smartphone the Video Profile was Baseline@L3 ( Table 13 , page 18 ). The audio information stayed mostly the same comparatively to the original files. The audio information was still AAC, two channels, 16 bit, and 48k sample rate. The only


17 difference in the audio information was that the Audio Profile was changed to HE AAC/ LC comparatively to the original which was just LC. (Table 14 , page 18 ). Table 11 . Samsung Downloaded Encoder/Container Table 12 . Samsung Downloaded Resolution Change


18 Table 13 . Samsung Downloaded Video Information Table 14 . Samsung Downloaded Audio Information Atom Structure Metadata within an ISO base media file is structured into unites of data which are called atoms. Atoms can be of various lengths and atoms are contained within other atoms. At the beginning of each atom there i s a tag that are represented by ASCII character that help programs identify how to interpret the data within the atom. Atomic Paisley can extract this tag and organize it in successive order. All the video files had the same atom structure except 640x480 that was uploaded using a smartphone . This video file is missing an atom that all the other files are not. The According to the QuickTime file format Specification s the


19 s atom provides the decoding information and video presentation if they are not stored in order in a video file [15] . To see the location of were the atom is and where it is missing in the atom structure, refer to Appendix Figure A. Encoder Settings With the Samsung videos tha t were 1920x1080 and 1280x720 resolutions, the encoder settings were identical . A point of interest is that all the iPhone videos had the same encoder settings as these two resolutions had. See Appendix F igure B and C. In these f igures the encoder settings start with CABAC = 1. This indicates whether a file was encoded using the CABAC algorithm, if th e files starts with CABAC = 0 it means that it did not use the CABA C algorithm. 1072x1072 encoder settings were very similar to th e ones that 1920x1080 and 1280x720 had. The only difference s were: threads = 33 and lookahead_threads = 5 . 1920x1080 and 1280x720 had: thread = 40 and lookahead_threads = 6. See Appendix figure B and C, differences are highlighted. Once again the 640x480 resolutions differed in encoder settings in whether they were originally uploaded via smartphone or computer. When the 640x480 resolution was uploaded using a smartphone and downloaded via computer there were many set tings that were different comparatively to the other one. The most significant observations would be that an entire section of the encoder settings is no present comparatively to the other files which can be vi ew just on the next page.


20 Figure 5 . Missing Section This section that is not present would be located between / bframes=3 / and / weightp=1 / . Another major difference is the 640x480 smartphone upload start with CABAC = 0 which none of the other files had, including the iPhone files. Like stated earlier, this means th at this resolution in th is upload style is the only one that is not encoded in CABAC. Other differences are: threads=12 , lookahead_threads=2 , weightp=0 , rc_ lookahead=40 , vbv_maxrate=450 and vbv_bufsize=900 . All of differences comparatively to the 1920x 1080 and1280x720 can be viewed in the Appendix, Figures B and C, and are highlighted. The last resolutions, 640x480 that was uploaded using a computer had similar differences that the 1072x1072 resolutions had. These changes were in the encoder settings of thread = 20 and lookahead_threads = 3. Unlike the 640x480 that was uploaded via smartphone, no section was missing. Browser Results An interesting observation was that it did not matter what browser the files were downloaded by ; whether it was Chrome, Safari, or Firefox all the downloaded files were exactly the same to each other. In the table below are the HASH values that were created after the file was downloaded. The colors in the table are to easily view that across the different browsers t hat when the file was downloaded the same HASH valve was created.


21 Table 15 . Samsung Browser Hashes i P hone Download Overview Metadata The most interesting observations that can be made about the iPhone videos that were uploaded and downloaded is that no matter the resolution or the previous format , all the video s were encoded exactly the same. Every single video was modified to the same resolution, with the same Video Format, Profile and the same Encoder Library as the Samsung. The one thing that do es stand out from the Samsung results is the Audio Sample rate of 44,1 0 0 that got carried over from the originals ( Table 19, page 22 ) .


22 Like the Samsung result s everything was encoded w ith Lavf version 56.40.101 and the container was changed to isom ( Table 16 ). All the videos got a new resolution of 1280x720 which can be see n in table 17 just below. One result that is interesting is that rather than being HEVC they are now H.264/AVC like the Samsung video ( Table 18 , page 23 ) . Another observation about the audi o information is that originally the a udio information showed that they were mono (see Chapter III, sub chapter Originals) , but after being downloaded, they are now dual channel (Table 19 , page 23 ) . Table 16 . iPhone Downloaded Encoder/Container Table 17 . iPhone Downloaded Resolution


23 Table 18 . iPhone Downloaded Video Information Table 19 . iPhone Downloaded Audio Information Atom Structure Like in the metadata that was extracted from all the video s , the iPhone videos that were downloaded had all the same atom structure. It did not matter whether the video was downloaded with a different browser or had the HD on or off in the upload. The one thing that is interesting about this atom structure is that it is exactly the same as the Samsung at om structure (excluding the Samsung 640x480 mobile upload). (Appendix, Figure A) Encoder Settings Just like all the other information that was extracted from all the iPhone files, the results came back that every video resolution came out with the exact s ame encoder settings. Unlik e the Samsung results, there were no discrepancies among the extract ed information.


24 Another interesting observation to note is that the Encoder Settings are exactly the same as the Samsung 1920x1080 and 1280x720 resolution. (Appe ndix Figures B and C) Browser Results After all the videos were downloaded each video was hashed using MD5 just like the Samsung video files . In Table 20 it can be seen that between the three different browsers that were used none of them affected the dow nload process of the video s . Table 20 . iPhone Browser Hashes


25 CHAPTER V Conclusion One very surprising d iscovery in this test are the results of the iPhone video files. Every video got the exact same encoding scheme even though they were all different from each other. In th e end all the iPhone videos were re encoded with a resolution of 1280x720 no matter what the original resolution was. Also all the iPhone videos got encoded with the same settings and which also in cludes all the same metadata information. The only information that was not altered was the bit depth which was 16, the sample rate which was 44 , 100, audio format (mp4a) and the sound handler (appl). Because of this there is nothing connect ing the original videos to the Facebook downloaded ones (excluding the content in the videos). On the other hand the Samsung videos had some very interesting results especially the 640x480 resolutions. The fact that one of the resolution s is upload dependen t compared to all the other (including the iPhone videos) shows that there is a correlation to the Samsung. This is not definite though because there is always a possibility that all videos uploaded at 640x480 with a smartphone go through the same encoding process that these showed. Just like all the video that were 1280x720, 1920x1080, and 4K all ended up at 1280x720 with all the same metadata information being the same, it is very likely that videos that are 640x480 and uploaded with a smartphone through the application will end up with the same metadata inf ormation and encoder settings. Future Research With the data that has been collected there is still plenty of research that can be done to Facebook and its extensions . A large r group with more varying resolutions could show


26 how different resolutions are effected when they are re . Another test that this study did not truly undertake was how different frame rate are effected by the encoder. An approach that this test did not take is how different Facebook application updates effect video when it is downloaded. Because updates are controlled by Facebook, there is a possibility that a new version could have different encoder settings. Another possibility i s Facebook might up date to HEVC rather than keep H.264/AVC because smartphones and videos are moving towards higher resolutions and frame rates. With the results of this test and seeing that 640x480 is upload depended , the most interesting test would be seeing if there is a difference in videos that are uploaded to Facebook using the Mobile Application and the smartphone brow ser. This test would bring insight into whether the e ncoder settings are embedded in the application or whether they are smartpho ne related.


27 REFERENCES [1] Our History | Company Info | Facebook Newsroom. (n.d.). Retrieved from info/ [Accessed 11 March 2018] [2] Stats | Company Info | Facebook Newsroom. (n.d.). Retrieved from info/ [Accessed 11 March 2018] University of Colorado at Denver, April, 2016 Technical Overview of Digital [5] Home | ITU T Recommendations (n.d.) Retrieved from T/recommendations/rec.aspx?rec=6312&lang=en [Accessed 20 Ma rch 2018] [6] Soon Journal of Visual Communication and Image Representation., Volume 17, Issue 2, 2006, Pages 186 216 d Systems. Springer, Cham, 2014 [8] Home | ITU T Recommendations (n.d.) Retrieved from T/recommendations/rec.aspx?rec=13433&lang=en [Accessed 9 April 2018] [9 of web browsers/


28 ocuments/documents [11] About | FFMPEG (n.d) Retrieved from, [Accessed 15 April 2018] [12] Exiftool by Phil Harvey (n.d.) Retrieved from [Accessed 15 April 2018] [13] Medi ainfo | About (n.d.) Retrieved from [Accessed 15 April 2018] [14] Atomic Parsley (n,d.) Retrieved from [Accessed 15 April 2018] [15] Movie Atom | QuickTime File Format Specification s (n.d.) Retrieved from qtffPreface.html#//apple_ref/doc/uid/TP40000939 CH202 TPXREF101 [Accessed 19 April 2018


29 APPENDIX A. Atom Structures of all video files after download from Facebook. Atom Structures All iPhone Structures Other Samsung Structures Samsung Browser 640x480 Samsung Mobile 640x480 ftyp ftyp ftyp ftyp moov moov moov moov mvhd mvhd mvhd mvhd trak trak trak trak tkhd tkhd tkhd tkhd edts edts edts edts elst elst elst elst mdia mdia mdia mdia mdhd mdhd mdhd mdhd hdlr hdlr hdlr hdlr minf minf minf minf vmhd vmhd vmhd vmhd dinf dinf dinf dinf dref dref dref dref url url url url stbl stbl stbl stbl stsd stsd stsd stsd avc1 avc1 avc1 avc1


30 avcC avcC avcC avcC stts stts stts stts stss stss stss stss ctts ctts ctts ______ stsc stsc stsc stsc stsz stsz stsz stsz stco stco stco stco trak trak trak trak tkhd tkhd tkhd tkhd edts edts edts edts elst elst elst elst mdia mdia mdia mdia mdhd mdhd mdhd mdhd hdlr hdlr hdlr hdlr minf minf minf minf smhd smhd smhd smhd dinf dinf dinf dinf dref dref dref dref url url url url stbl stbl stbl stbl stsd stsd stsd stsd mp4a mp4a mp4a mp4a esds esds esds esds


31 stts stts stts stts stsc stsc stsc stsc stsz stsz stsz stsz stco stco stco stco udta udta udta udta meta meta meta meta hdlr hdlr hdlr hdlr ilst ilst ilst ilst ©nam ©nam ©nam ©nam data data data data ©too ©too ©too ©too data data data data free free free free mdat mdat mdat mdat size: size: size: size: data: data: data: data: free free free free version: version: version: version:


32 B. Comparative chart of encoder settings for all files after downloading from Facebook.


33 C. Comparative chart of encoder settings for all files after downloading from Facebook (continuation of B.)