5 Replies Latest reply on Mar 31, 2014 6:43 AM by sinious

    Video truncation in Android: Please check this ticket and vote for it

    Gaius Coffey Level 2

      Hi,

      I have resubmitted bug 3545316 as it was closed without fixing, despite being replicated, but it remains a major business issue for us.

       

      I would ask anybody who uses video in Android to check this ticket and vote for it: https://bugbase.adobe.com/index.cfm?event=bug&id=3731463

       

      The ticket uses a Flash Builder project, but the code is pure ActionScript so it will also affect Flash built using Flash Professional. If anybody requires the code for Flash Professional to recreate the bug, let me know.

       

      Either way, this is a mission critical failure that undermines the use of Flash / AIR for mobile.

       

      I am highly unimpressed by the handling of this one.

      G

        • 1. Re: Video truncation in Android: Please check this ticket and vote for it
          sinious Most Valuable Participant

          Looking into it myself but on a Galaxy Note 3 it only missed by 0.287.

           

          Step: 0.106 remaining: 0.790

          Step: 0.145 remaining: 0.645

          Step: 0.101 remaining: 0.544

          latestResultsStr: [trait d: 60.011 t: 59.594 ] [NetStream t: 59.594 ] [Step: 0.127 remaining: 0.417]

          latestResultsStr: [trait d: 60.011 t: 59.712 ] [NetStream t: 59.712 ] [Step: 0.118 remaining: 0.299]

          latestResultsStr: [trait d: 60.011 t: 60.000 ] [NetStream t: 60.000 ] [Step: 0.288 remaining: 0.011]

           

          [ERROR NETSTREAM HAS JUMPED BY 0.2879999999999967 SECONDS FOR NO ADEQUATELY EXPLAINED REASON.]

           

          latestResultsStr: [trait d: 60.011 t: 60.011 ] [NetStream t: 60.000 ] [Step: 0.011 remaining: 0.000]

           

          This is a pretty small amount and I'm not sure how much is attributed to OSMF.

           

          I'd need you to verify 3 things before this is truely an issue.

           

          1) Play the MP4 using StageVideo and verify the same glitch exists.

          2) Play the MP4 using NetConnection and NetStream via a Video object and verify the same results (remove OSMF).

          3) Verify the video is produced properly for known Flash issues, such as the VideoEvent.COMPLETE event not firing off on videos that don't end on a keyframe or a whole second (e.g. 60.011 duration instead of 60).

           

          If doing any of the above fixes the issue then it's not really an issue.

           

          Edit:

           

          Out of my own curiousity for using the play Video object and performance I did #2 myself. I did the easiest possible implementation with NC and NS and on your video it stops on a random frame before it finishes on the Galaxy Note 3.

           

          I don't trace every ENTER_FRAME. I made a Vector.<Number> to hold the NS.time values after it reached 55 seconds (you used a really long test video). After NetStream.Play.Stop I then trace() out the last 20 ns.time values captured each frame and the difference between them.

           

          This is going to be long...

           

          On desktop I get what I expect, video ends on the 59:24 frame:

           

          NetStatusEvent: NetStream.Play.Start

          Duration: 60.010666666666665

          NetStatusEvent: NetStream.Buffer.Full

          [SWF] DebugAdvert.swf - 3,199 bytes after decompression

          NetStatusEvent: NetStream.Buffer.Flush

          NetStatusEvent: NetStream.Play.Stop

          stop time: 60

          t:59.31, diff: 0.027000000000001023

          t:59.337, diff: 0.04399999999999693

          t:59.381, diff: 0.021999999999998465

          t:59.403, diff: 0.04100000000000392

          t:59.444, diff: 0.03999999999999915

          t:59.484, diff: 0.021999999999998465

          t:59.506, diff: 0.03999999999999915

          t:59.546, diff: 0.03200000000000358

          t:59.578, diff: 0.03399999999999892

          t:59.612, diff: 0.027000000000001023

          t:59.639, diff: 0.04399999999999693

          t:59.683, diff: 0.021999999999998465

          t:59.705, diff: 0.04100000000000392

          t:59.746, diff: 0.030999999999998806

          t:59.777, diff: 0.031999999999996476

          t:59.809, diff: 0.030000000000001137

          t:59.839, diff: 0.04100000000000392

          t:59.88, diff: 0.030999999999998806

          t:59.911, diff: 0.030999999999998806

          t:59.942, diff: 0.04099999999999682

          NetStatusEvent: NetStream.Buffer.Empty

           

          On the phone (quad core, 3GB ram), a little strange, and each time the video ended on the frame saying 59:20 not 59:24:

           

          [SWF] DebugAdvert.swf - 3,199 bytes after decompression

          NetStatusEvent: NetStream.Play.Start

          NetStatusEvent: NetStream.Buffer.Full

          Duration: 60.010666666666665

          NetStatusEvent: NetStream.Buffer.Flush

          NetStatusEvent: NetStream.Play.Stop

          stop time: 60

          t:59.425000000000004, diff: 0

          t:59.425000000000004, diff: 0

          t:59.425000000000004, diff: 0.11599999999999966

          t:59.541000000000004, diff: 0

          t:59.541000000000004, diff: 0

          t:59.541000000000004, diff: 0

          t:59.541000000000004, diff: 0.14499999999999602

          t:59.686, diff: 0

          t:59.686, diff: 0

          t:59.686, diff: 0.10000000000000142

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0

          t:59.786, diff: 0.21399999999999864

          NetStatusEvent: NetStream.Buffer.Empty

           

          Then again:

           

          [SWF] DebugAdvert.swf - 3,199 bytes after decompression

          NetStatusEvent: NetStream.Play.Start

          NetStatusEvent: NetStream.Buffer.Full

          Duration: 60.010666666666665

          NetStatusEvent: NetStream.Buffer.Flush

          NetStatusEvent: NetStream.Play.Stop

          stop time: 60

          t:59.325, diff: 0

          t:59.325, diff: 0

          t:59.325, diff: 0.10900000000000176

          t:59.434000000000005, diff: 0

          t:59.434000000000005, diff: 0

          t:59.434000000000005, diff: 0

          t:59.434000000000005, diff: 0.12099999999999511

          t:59.555, diff: 0

          t:59.555, diff: 0

          t:59.555, diff: 0.125

          t:59.68, diff: 0

          t:59.68, diff: 0

          t:59.68, diff: 0

          t:59.68, diff: 0.12600000000000477

          t:59.806000000000004, diff: 0

          t:59.806000000000004, diff: 0

          t:59.806000000000004, diff: 0

          t:59.806000000000004, diff: 0

          t:59.806000000000004, diff: 0

          t:59.806000000000004, diff: 0.1939999999999955

          NetStatusEvent: NetStream.Buffer.Empty

           

          That eliminates #2, a simple NetStream/NetConnection/Video setup removing OSMF from fixing the issue. I don't have time to report back on StageVideo at the moment.

           

          That said, I voted up your bug report.

          1 person found this helpful
          • 2. Re: Video truncation in Android: Please check this ticket and vote for it
            Gaius Coffey Level 2

            Thanks, Sinious,

             

            (you used a really long test video)

             

            The bug was first noticed on a thirty-second video advert about buying your weekly groceries... It was a) naff b) horrid c) comparatively massive and d) belonging to a customer. The timer one was just a nice and easy one that fell to hand when compiling the bug report media.

             

            Thanks also for your vote, a .287 seconds may not sound much but it may make the difference between a customer's name being pronounced correctly or being clipped. However... you also cited your device stopping on "a random frame" and I have been seeing very variable times for the same video on the same device. Case in point, before uploading my latest little tantrum, I ran it five or six times on a Motorola Xoom and saw times varying from a quarter of a second to well over a second... Previously, I had been seening between 1 and 4 seconds...

             

            So, not only is it enough to upset customers, it isn't even something they can adjust their videos to get around.

             

            Very glad to know it's not OSMF, I probably should have done those tests myself!

             

            All good, thank-you,

             

            G

            • 3. Re: Video truncation in Android: Please check this ticket and vote for it
              sinious Most Valuable Participant

              Much like we learn to live in safe frames for TV cropping, you should always include a generous portion of end-frame roll. Creating a 2 second landing screen in the video will solve all your problems it seems. But it's just a good idea in general in this crazy world of clipping and cropping.

               

              Maybe tomorrow I'll get a chance to see if StageVideo has any better results. That'll at least narrow it down to being a NetConnection/NetStream issue (which I'm fairly sure it is anyhow).

              1 person found this helpful
              • 4. Re: Video truncation in Android: Please check this ticket and vote for it
                Gaius Coffey Level 2

                Thanks,

                The issue is not with our main content - which can stand a few seconds clippage out of a programme of 60 minutes or more - but with customer supplied advertising content ranging from ten to thirty seconds. A three second loss out of a fifteen second video means that customers might lose as much as a fifth of the advertising slot that they have paid for. This is significant in the eyes of the advertiser.

                 

                It really doesn't seem like too much to ask that a fixed length, pre-recorded, quality-checked binary file be interpreted reliably. You would not, for example, be advising me to build in an inch of additional space around the icons in my buttons. A JPEG of 32 pixels by 32 pixels should always be relied on to be 32x32. I don't see why I can't rely on a 30 second video to play for 30 seconds when there is absolutely nothing else going on at the time to mess with it.

                G

                • 5. Re: Video truncation in Android: Please check this ticket and vote for it
                  sinious Most Valuable Participant

                  The type of media I often produce has an ending screen with information on it. I tend to already do this so it's probably easier for me to suggest. But I know what you mean.

                   

                  That said, even on some pretty old hardware (galaxy 2, asus transformer (original), etc) I'm only getting a fraction of a second loss using the NetConnection / NetStream method but I see bigger jumps using OSMF. Perhaps the more event listeners you attach (complication) the more the end of the video will jump. I'm sure OSMF is listening for buffer emptying, flush, etc etc.. Maybe later today I'll get a chance to check StageVideo but I'm not betting it's a solution.

                  1 person found this helpful