技术领域
本申请涉及数据传输处理领域，尤其是涉及视频上传方法、系统、用户终端、服务器及存储介质。
背景技术
视频上传通常是指将终端本地的视频发送给服务器进行存储的行为。在终端本地存储空间不够时，可以将相关视频数据上传到服务器，减少视频数据对终端本都存储空间的占用；或者将视频数据上传服务器进行存储，实现备份的作用，避免数据丢失。
目前，可以一次上传一个视频文件，也可以同时上传多个视频文件；当用户存在多个视频文件需要上传时，通过同时上传多个视频文件的方式，显然更符合用户需求，因为可以减少重复操作，提高上传效率。
每一次上传可以是直接传输整个视频文件，也可以先对视频文件进行切分，针对切分后的各个视频分片分别进行上传。前一方式容易导致传输中断的情况，尤其是当视频文件较大时更甚，同时由于是串行处理，因此存在传输效率低的问题；后一方式因为每一视频分片的数据量小，因此传输更稳定，传输中断情况较少出现，且基于高并发并行处理，因此传输效率更高。
因此，当存在多个视频文件需要上传时，选择多个视频文件同时上传，且采用视频分片的方式，或许应该是一种高效稳定的上传方式。但实际情况是多视频分片上传，容易导致服务器在合成视频分片形成完整视频时出现合成混乱的情况。
发明内容
为了解决多视频分片上传，容易导致服务器在合成视频分片形成完整视频时出现合成混乱的问题，本申请提供了视频上传方法、系统、用户终端、服务器及存储介质。
第一方面，本申请提供一种视频上传方法，应用于用户终端，采用如下的技术方案：
获取各待上传视频分别对应的唯一标识；
基于所述唯一标识对与该唯一标识对应的所述待上传视频的视频名称进行修改，使得修改后的视频名称至少包含所述唯一标识；并将视频名称修改后的所述待上传视频作为待切分视频；
调用预设视频切分工具对各所述待切分视频进行切分，使得每一所述待切分视频被切分后将对应得到至少两个视频分片，且每个所述视频分片的分片名称包含分片序号以及对应所述待上传视频的唯一标识；
基于所述视频分片对应的视频内容数据、所述分片序号及所述唯一标识，生成第一请求；
将所述第一请求发送给目标服务器；
接收所述目标服务器基于所述第一请求返回的第一响应消息；所述第一响应消息包含所述目标服务器为所述视频分片分配的上传地址URL；
基于各所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL，生成第二请求；
将所述第二请求发送给所述目标服务器；
接收所述目标服务器基于所述第二请求返回的第二响应消息；所述第二响应消息包含所述目标服务器基于各所述视频分片进行合成得到完整视频所对应的存储地址。
通过采用上述技术方案：对需要上传的多个待上传视频，用户终端首先获取其唯一标识，通过采用待上传视频的唯一标识对视频名称进行修改的方式，使得待上传视频被切分后的视频分片的分片名称不仅包含分片序号，还包含该唯一标识；生成第一请求将视频分片发送给服务器；服务器返回视频分片的上传地址；用户终端当接收到各个待上传视频的所有视频分片均返回得到对应的上传地址后，基于各视频分片对应的分片序号、唯一标识以及上传地址URL，生成第二请求，以请求服务器对各视频分片按照分片序号、唯一标识进行拼接合成完整视频；从而可以保证具有相同唯一标识的所有视频分片能够被合成到一起，避免不同视频的视频分片被合成到一起所出现的混乱问题；且按照分片序号可以保证合成的顺序正确；保证了多视频分片上传的稳定性、可靠性，避免了视频分片合成时容易产生合成拼接混乱问题。
可选的，所述唯一标识包括全局唯一标识符GUID。
通过采用上述技术方案，使用全局唯一标识符GUID作为待上传视频的唯一标识，便于生成或获取。
可选的，所述基于各所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL，生成第二请求包括：
针对所述唯一标识相同的所有视频分片，按照各所述视频分片对应的所述分片序号，依次获取各所述视频分片对应的所述上传地址URL，形成视频分片顺序数组集合；基于所述视频分片顺序数组集合生成一个所述第二请求。
通过采用上述技术方案，在某一个待上传视频的所有视频分片都返回了对应的上传地址后，即可立即生成该待上传视频的第二请求，以请求服务器对该待上传视频的全部视频分片进行合成处理；无需等待其他待上传视频的视频切分过程或者返回上传地址是否完成，可提高视频上传效率。
可选的，所述第二请求还包括文件类型、视频格式、分片大小、分片数量。
通过采用上述技术方案，进一步限定了第二请求所包含的具体内容。
可选的，所述视频上传方法还包括：
当超过预设响应时间仍未接收到所述第一响应消息时，判断所述第一请求发送失败；重新生成所述第一请求并发送给所述目标服务器。
通过采用上述技术方案，当没有及时获取到相应视频分片的上传地址时，能够及时判定请求失败，并触发重新生成第一请求以获取相应视频分片的上传地址，保证上传效率。
第二方面，本申请提供一种视频上传方法，应用于服务器，采用如下的技术方案：
接收用户终端发送的第一请求；
解析所述第一请求，以获取得到对应视频分片的视频内容数据、分片序号及唯一标识；
为所述视频分片分配上传地址URL，以存储所述视频分片的所述视频内容数据；
根据所述视频分片的所述分片序号、所述唯一标识以及所述上传地址URL，生成第一响应消息；
将所述第一响应消息发送给所述用户终端；
接收所述用户终端基于所述第一响应消息发送的第二请求；
解析所述第二请求，以获取得到各所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL；
针对所述唯一标识相同的所有视频分片，依次从对应的所述上传地址URL中，获取各所述视频分片对应的所述视频内容数据；
按照各所述视频分片对应的所述分片序号，依次对各所述视频分片进行拼接合成，得到完整视频；
为所述完整视频分配存储地址，以对所述完整视频进行存储；
基于所述存储地址，生成第二响应消息，并发送给所述用户终端。
通过采用上述技术方案，能够保证服务器可将具有相同唯一标识的所有视频分片合成到一起，避免不同视频的视频分片被合成到一起所出现的混乱问题；且按照分片序号可以保证合成的顺序正确；保证了多视频分片上传的稳定性、可靠性，避免了视频分片合成时容易产生合成拼接混乱问题。
第三方面，本申请提供一种视频上传系统，采用如下的技术方案：
包括通信互联的用户终端和服务器；
所述用户终端用于获取各待上传视频分别对应的唯一标识；基于所述唯一标识对与该唯一标识对应的所述待上传视频的视频名称进行修改，使得修改后的视频名称至少包含所述唯一标识；并将视频名称修改后的所述待上传视频作为待切分视频；调用预设视频切分工具对各所述待切分视频进行切分，使得每一所述待切分视频被切分后将对应得到至少两个视频分片，且每个所述视频分片的分片名称包含分片序号以及对应所述待上传视频的唯一标识；基于所述视频分片对应的视频内容数据、所述分片序号及所述唯一标识，生成第一请求；将所述第一请求发送给所述服务器；
所述服务器用于接收所述用户终端发送的第一请求；解析所述第一请求，以获取得到对应视频分片的视频内容数据、分片序号及唯一标识；为所述视频分片分配上传地址URL，以存储所述视频分片的所述视频内容数据；根据所述视频分片的所述分片序号、所述唯一标识以及所述上传地址URL，生成第一响应消息；将所述第一响应消息发送给所述用户终端；
所述用户终端用于接收所述第一响应消息；解析获得所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL；基于各所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL，生成第二请求；将所述第二请求发送给所述服务器；
所述服务器用于接收所述用户终端发送的第二请求；解析所述第二请求，以获取得到各所述视频分片对应的所述分片序号、所述唯一标识以及所述上传地址URL；针对所述唯一标识相同的所有视频分片，依次从对应的所述上传地址URL中，获取各所述视频分片对应的所述视频内容数据；按照各所述视频分片对应的所述分片序号，依次对各所述视频分片进行拼接合成，得到完整视频；为所述完整视频分配存储地址，以对所述完整视频进行存储；基于所述存储地址，生成第二响应消息，并发送给所述用户终端；
所述用户终端接收所述服务器返回的第二响应消息；解析得到所述服务器基于各所述视频分片进行合成得到完整视频所对应的存储地址。
通过采用上述技术方案，通过用户终端与服务器之间的相互交互处理，保证了多视频分片上传的稳定性、可靠性，避免了视频分片合成时容易产生合成拼接混乱问题。
第四方面，本申请提供一种用户终端，采用如下的技术方案：
包括第一处理器、第一存储器以及存储在所述第一存储器中并可在所述第一处理器上运行的计算机程序，所述第一处理器执行所述计算机程序时实现如上应用于用户终端的任意一项所述的视频上传方法。
通过采用上述技术方案，提供了能执行实现上述视频上传方法的用户终端。
第五方面，本申请提供一种服务器，采用如下的技术方案：
包括第二处理器、第二存储器以及存储在所述第二存储器中并可在所述第二处理器上运行的计算机程序，所述第二处理器执行所述计算机程序时实现如上应用于服务器的视频上传方法。
通过采用上述技术方案，提供了能执行实现上述视频上传方法的服务器。
第六方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：
所述计算机存储介质存储有计算机程序；所述计算机程序被处理器执行时，实现如上应用于用户终端的任意一项所述的视频上传方法或如上应用于服务器的视频上传方法。
通过采用上述技术方案，提供了视频上传方法的计算机程序的载体。
综上所述，本申请包括以下至少有益技术效果：
1.保证了多视频分片上传的稳定性、可靠性，避免了视频分片合成时容易产生合成拼接混乱问题。
2.提高了视频上传效率。
附图说明
图1是本申请实施例中一种视频上传方法的流程框图；
图2是本申请实施例中一种用户终端界面示意图；
图3是本申请实施例中另一种视频上传方法的流程框图；
图4是本申请实施例中一种视频上传系统网络架构框图；
图5是本申请实施例中又一种视频上传方法的流程框图；
图6是本申请实施例中一种用户终端结构框图；
图7是本申请实施例中一种服务器结构框图；
附图标记说明：
61、第一处理器；62、第一存储器；71、第二处理器；72、第二存储器。
具体实施方式
为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图1-7及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。
本申请实施例公开一种视频上传方法。
参考图1，一种视频上传方法，应用于用户终端（User Equipment），包括以下步骤：
S101：获取各待上传视频分别对应的唯一标识。
参考图2，用户可勾选需要上传到服务器进行存储的视频文件，在勾选完成后，即可对所勾选的全部视频文件同时进行上传。无需针对每一个视频文件分别进行操作，减少重复操作，方便用户使用。
可本申请可选实施例中，继续参考图2，当用户点击“上传”按钮时，终端将接收到用户该点击操作指令，从而触发上传过程。
具体的，用户终端将用户最终勾选的视频文件作为待上传文件；针对每个待上传视频文件，按照预设方式生成其对应的唯一标识。
应当理解的是，预设方式可以选用现有任意方式，只要能够为每个视频文件生成不同的唯一标识即可。所采用的预设方式不同，对应生成的唯一标识的形式可能不同。
在本申请可选实施例中，唯一标识包括GUID（Globally Unique Identifier，全局唯一标识符）。
S102：基于唯一标识对与该唯一标识对应的待上传视频的视频名称进行修改，使得修改后的视频名称至少包含该唯一标识；并将视频名称修改后的待上传视频作为待切分视频。
在得到待上传视频的唯一标识GUID后，重点在于合理利用该唯一标识GUID，从而指导服务器正确完成视频分片的正确合成拼接。为此，本申请实施例中，是利用唯一标识GUID对待上传视频的视频名称进行修改。
在本申请可选实施例中，用户终端直接控制将待上传视频的视频名称修改为其唯一标识GUID。可利用唯一标识GUID为纯数字标识符的特性，可避免待上传视频被第三方视频切分工具切分时容易导致视频分片命名异常问题，能够保证切分后的各个视频分片命名的唯一性、规范性；有利于保证后续服务器合成时的准确性。
然后，将视频名称修改后的待上传视频作为待切分视频，从而调用预设视频切分工具对各待切分视频进行切分。
S103：调用预设视频切分工具对各待切分视频进行切分，使得每一待切分视频被切分后将对应得到至少两个视频分片，且每个视频分片的分片名称包含分片序号以及对应待上传视频的唯一标识。
本申请可选实施例中，预设视频切分工具可以采用现有任意视频切分工具，只要能够按照需要将待切分视频切分为多个视频分片即可，本实施例对此不做限制。
预设视频切分工具可以按照预设分片大小进行切分，例如预设分片大小为64k、1M等；也可以按照预设视频时长进行切分，例如预设视频时长为10秒、1分钟等。使得待上传视频通常会被切分得到至少两个视频分片。
通过视频切分处理，每个视频分片的分片名称包含分片序号，以及对应待上传视频的唯一标识GUID。
S104：基于视频分片对应的视频内容数据、分片序号及唯一标识，生成第一请求。
应当理解的是，第一请求主要用于请求服务器存储视频分片的视频内容数据。
第一请求中携带有所请求存储的视频分片的视频内容数据、分片序号及唯一标识。应当理解的是，第一请求中可能还包括用于实现请求的其他必要信息，包括但不限于请求头header、请求key值、请求方式method、是否异步async等信息；本实施例对此不做限制。
本申请可选实施例中，第一请求可采用XMLHttpRequest请求，请求方式method采用post。
本申请可选实施例中，对预设视频切分工具的视频切分过程实时监听，每切分得到一个视频分片，立即生成一个与之对应的第一请求，以将该视频分片的视频内容数据发送给服务器存储。视频切分完成，第一请求发送完成。在封装生成第一请求的过程中，由于单独为每个视频分片进行封装，因此数据量较小，响应更快；同时在得到一个视频分片后，即可立即对其进行封装处理，无需等待其他视频分片的切分过程，因此使得视频上传效率更高；可以充分利用高并发处理的优势。
S105：将第一请求发送给目标服务器。
基于用户终端与服务器之间的通信连接，实现两者之间的信息交互，可采用现有任意方式，对此不再赘述。
S106：接收目标服务器基于第一请求返回的第一响应消息；第一响应消息包含目标服务器为视频分片分配的上传地址URL。
基于第一请求，服务器将为第一请求中视频分片的视频内容数据分配存储地址，以对该视频内容数据进行临时存储；为了让用户终端知晓临时存储地址，因此返回携带有该视频分片的上传地址URL（即临时存储地址）的第一响应消息。
在本申请可选实施例中，当超过预设响应时间仍未接收到第一响应消息时，判断第一请求发送失败；此时重新生成对应的第一请求，并发送给目标服务器。针对没有及时获取到视频分片上传地址的异常请求，做到及时发现，及时处理，保证了视频上传效率、稳定性与可靠性。
S107：基于各视频分片对应的分片序号、唯一标识以及上传地址URL，生成第二请求。
在本申请可选实施例中，针对唯一标识相同的所有视频分片，按照各视频分片对应的分片序号，依次获取各视频分片对应的上传地址URL，形成视频分片顺序数组集合；基于视频分片顺序数组集合，生成一个第二请求。也即是，若多个待上传视频同时上传，每个待上传视频将对应生成一个第二请求，以请求服务器对该待上传视频的多个视频分片进行合成拼接形成完整视频。
视频分片顺序数组集合可参见如下表1所示：
表1 视频分片顺序数组集合示例
基于视频分片顺序数组集合的相关信息，封装生成第二请求，使得第二请求中携带有唯一标识相同的所有视频分片的唯一标识GUID、分片序号以及上传地址URL，以请求服务器对该待上传视频的所有视频分片进行合成拼接形成完整视频。应当理解的是，第二请求的具体形式以及封装过程并非本发明重点，可以采用现有方式实现，对此不再赘述。
应当理解的是，第二请求中可能还包含实现请求服务器完成合成拼接的其他必要信息，包括但不限于文件类型、视频格式、分片大小、分片数量等。
其中，文件类型为视频流类型，即file：(binary)。
视频格式根据待上传视频的实际视频格式配置，例如可以是video，也可以是MP4。
分片大小可根据待上传视频的数据大小以及实际需要灵活设置，对此不做限制；例如设置为1M。
分片数量可根据视频切分结果得到。例如对于一个1G大小的待上传视频，若分片大小设置为1M，则分片数量可能是1G/1M=1024，也即是会被切分为1024个视频分片。
在某一个待上传视频的所有视频分片都返回了对应的上传地址后，即可立即生成该待上传视频的第二请求，以请求服务器对该待上传视频的全部视频分片进行合成处理；无需等待其他待上传视频的视频切分过程或者返回上传地址是否完成，可提高视频上传效率。
S108：将第二请求发送给目标服务器。
请求的发送可采用现有任意方式，对此不再赘述。
S109：接收目标服务器基于第二请求返回的第二响应消息；第二响应消息包含目标服务器基于各视频分片进行合成得到完整视频所对应的存储地址。
通过解析第二响应消息，即可得到对应完整视频的存储地址，通过该存储地址，可查看该完整视频。具体的，可在线播放、下载该完整视频。
基于同一设计构思，本实施例还公开一种视频上传方法，应用于服务器，参考图3，该视频上传方法主要包括以下步骤：
S301、接收用户终端发送的第一请求。
第一请求中包含对应视频分片的视频内容数据、分片序号及唯一标识。同一待上传视频的所有视频分片，唯一标识相同，但是分片序号不同。
S302、解析第一请求，以获取得到对应视频分片的视频内容数据、分片序号及唯一标识。
请求的解析方法可采用现有任意方式，在此不再赘述。
S303、为视频分片分配上传地址URL，以存储视频分片的视频内容数据。
基于第一请求，为视频分片分配存储地址，以临时存储对应的视频内容数据。
S304、根据视频分片的分片序号、唯一标识以及上传地址URL，生成第一响应消息。
根据用于存储对应视频内容数据的存储地址，结合视频分片的分片序号以及唯一标识GUID，封装生成第一响应消息，返回给用户终端；使得用户终端知晓各视频分片的存储地址，即上传地址URL。
S305、将第一响应消息发送给用户终端。
S306、接收用户终端基于第一响应消息发送的第二请求。
在待上传视频的所有视频分片上传完成后，用户终端将生成一个视频分片顺序数组集合，以将该上传视频的所有视频分片的集合信息，通过第二请求发送给服务器；服务器据此请求，对集合中所请求的全部视频分片进行合成拼接得到完整视频。
S307、解析第二请求，以获取得到各视频分片对应的分片序号、唯一标识以及上传地址URL。
S308、针对唯一标识相同的所有视频分片，依次从对应的上传地址URL中，获取各视频分片对应的视频内容数据。
S309、按照各视频分片对应的分片序号，依次对各视频分片进行拼接合成，得到完整视频。
具体的，将集合中的全部视频分片，按照分片序号，例如从分片序号chunk1开始，依次从对应的上传地址URL获取视频分片的视频内容数据，然后将后一视频内容数据拼接在前一视频内容数据之后。
例如chunk2的视频内容数据拼接在chunk1的视频内容数据之后，chunk3的视频内容数据拼接在chunk2的视频内容数据之后，……, chunk(n)的视频内容数据拼接在chunk(n-1)的视频内容数据之后，直至将待上传视频的最后一个视频分片拼接到倒数第二个视频分片之后，完成整个视频文件的拼接，得到完整视频。避免同一待上传文件的各个视频分片之间拼接顺序出错，或者不同待上传视频的各个视频分片之间混合拼接的混乱问题。
S310、为完整视频分配存储地址，以对完整视频进行存储。
在合成拼接得到完整视频后，服务器可根据实际情况或预设机制为该完整视频分配存储地址，以对该完整视频进行存储。
S311、基于存储地址，生成第二响应消息，并发送给用户终端。
然后向用户终端返回第二响应消息，使得用户终端知晓完整视频的存放位置，便于后续查看下载。
基于同一设计构思，本实施例还公开一种视频上传系统。
参考图4，一种视频上传系统，包括通信互联的用户终端41和服务器42；用户终端41和服务器42之间相互交互，实现如下视频上传方法的步骤，参考图5：
用户终端用于获取各待上传视频分别对应的唯一标识；
基于唯一标识对与该唯一标识对应的待上传视频的视频名称进行修改，使得修改后的视频名称至少包含所述唯一标识；并将视频名称修改后的待上传视频作为待切分视频；
调用预设视频切分工具对各待切分视频进行切分，使得每一待切分视频被切分后将对应得到至少两个视频分片，且每个视频分片的分片名称包含分片序号以及对应待上传视频的唯一标识；
基于视频分片对应的视频内容数据、分片序号及所述唯一标识，生成第一请求；
将第一请求发送给服务器；
服务器用于接收用户终端发送的第一请求；
解析第一请求，以获取得到对应视频分片的视频内容数据、分片序号及唯一标识；
为视频分片分配上传地址URL，以存储视频分片的所述视频内容数据；
根据视频分片的分片序号、唯一标识以及上传地址URL，生成第一响应消息；
将第一响应消息发送给用户终端；
用户终端用于接收第一响应消息；
解析获得视频分片对应的分片序号、唯一标识以及上传地址URL；
基于各视频分片对应的分片序号、唯一标识以及上传地址URL，生成第二请求；
将第二请求发送给服务器；
服务器用于接收用户终端发送的第二请求；
解析第二请求，以获取得到各视频分片对应的分片序号、唯一标识以及上传地址URL；
针对唯一标识相同的所有视频分片，依次从对应的上传地址URL中，获取各视频分片对应的视频内容数据；
按照各视频分片对应的分片序号，依次对各视频分片进行拼接合成，得到完整视频；
为完整视频分配存储地址，以对完整视频进行存储；
基于存储地址，生成第二响应消息，并发送给用户终端；
用户终端接收服务器返回的第二响应消息；
解析得到服务器基于各视频分片进行合成得到完整视频所对应的存储地址。
通过用户终端41与服务器42之间的相互交互处理，具体交互过程可参见以上描述，在此不再赘述。保证了多视频分片上传的稳定性、可靠性，避免了视频分片合成时容易产生合成拼接混乱问题。
基于同一设计构思，本实施例还公开一种用户终端。
参考图6，一种用户终端，包括：
第一处理器61、第一存储器62以及存储在第一存储器62中并可在第一处理器61上运行的计算机程序，第一处理器61执行计算机程序时实现如上应用于用户终端的视频上传方法。具体可参见以上描述，在此不再赘述。
参考图7，一种服务器，包括：
第二处理器71、第二存储器72以及存储在第二存储器72中并可在第二处理器71上运行的计算机程序，第二处理器71执行计算机程序时实现如上应用于服务器的视频上传方法。具体可参见以上描述，在此不再赘述。
基于同一设计构思，本申请还提供一种计算机可读存储介质，存储有能够被处理器加载执行时实现上述视频上传方法的步骤。
所述计算机可读存储介质例如包括：U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
以上所述，以上实施例仅用以对本申请的技术方案进行了详细介绍，但以上实施例的说明只是用于帮助理解本申请的方法及其核心思想，不应理解为对本申请的限制。本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。