bugGnash - The GNU Flash player - Bugs: bug #24628, Time dependent youtube

 
 

bug #24628: Time dependent youtube

Submitted by:  Sandro Santilli <strk>
Submitted on:  Wed 22 Oct 2008 09:03:01 AM UTC  
 
Category: videoSeverity: 5 - Blocker
Release: trunkStatus: Fixed
Privacy: PublicAssigned to: Sandro Santilli <strk>
Open/Closed: Closed

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 24 Oct 2008 01:33:55 PM UTC, comment #7:

Committed revision 10075.

Late A/V frames should be used now, so time shouldn't make a difference.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 23 Oct 2008 04:22:09 PM UTC, comment #6:

file #16723 attached in bug #24540
contains a patch for late a/v frame.

Worth testing for this bug too as it should fix it as well.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Thu 23 Oct 2008 03:13:30 PM UTC, comment #5:

I'm working on allowing hot-plug of streams (see bug #24540), which should fix this.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 22 Oct 2008 02:52:28 PM UTC, comment #4:

Yeah, I wasn't trying to be very accurate there.

Bastiaan Jacques <bjacques>
Project Member
Wed 22 Oct 2008 12:06:49 PM UTC, comment #3:

Just a note:
4. MediaParser::MediaParser checks whether _audio and _video are present.

You mean something in NetStream_as, not MediaParser. Right ?

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 22 Oct 2008 12:00:44 PM UTC, comment #2:

Good analisys Bastiaan !
I confirm it happens with ffmpeg too.

Sandro Santilli <strk>
Project MemberIn charge of this item.
Wed 22 Oct 2008 10:33:57 AM UTC, comment #1:

I suspect this is a consequence of the current design that requires the MediaParser (in this case, FLVParser) to start the parser thread in its constructor. So what happens is:

1. FLVParser::parseHeader probes up to 8192 bytes, finds nothing, stops probing.
2. FLVParser::FLVParser starts the parsing thread.
3. The parsing thread detects the media types in the stream.
4. MediaParser::MediaParser checks whether _audio and _video are present.

Now, since step 3 is threaded, it might happen before step 4 (playback scenario). But it might happen afterwards (no playback).

Of course, if I'm correct then this should be reproducible using Ffmpeg.

Bastiaan Jacques <bjacques>
Project Member
Wed 22 Oct 2008 09:03:01 AM UTC, original submission:

http://www.youtube.com/watch?v=7PlUn9jwMao

Sometimes works, sometimes doesn't (no A/V).
A page reload is what I use for testing the two cases.

The log sais (non-working case):

SECURITY: Connecting to movie: http://www.youtube.com/get_video?video_id=7PlUn9jwMao&t=OEgsToPDskLIWkiZXPjGnUvbODkERGvu
ERROR: Corrupt FLV: previous tag record (0) unexpected (actual size: 9281)
ERROR: Couldn't find any video frame in the first 8192 bytes of FLV advertising video in header
ERROR: Couldn't find any audio frame in the first 8192 bytes of FLV advertising audio in header
ERROR: Unexpected video tag found at offset 9294 of FLV stream advertising no video in header. We'll warn only once per FLV, expecting any further video tag.
ERROR: Unexpected audio tag found at offset 11303 FLV stream advertising no audio in header. We'll warn only once for each FLV, expecting any further audio tag.

Nothing surprising up there, but surprising is the log
for the working case:

SECURITY: Connecting to movie: http://www.youtube.com/get_video?video_id=7PlUn9jwMao&t=OEgsToPDskKp9yCV3ydd57XG6aBaMpSN
ERROR: Corrupt FLV: previous tag record (0) unexpected (actual size: 9281)
ERROR: Couldn't find any video frame in the first 8192 bytes of FLV advertising video in header
ERROR: Couldn't find any audio frame in the first 8192 bytes of FLV advertising audio in header
ERROR: Unexpected video tag found at offset 9294 of FLV stream advertising no video in header. We'll warn only once per FLV, expecting any further video tag.
ERROR: Unexpected audio tag found at offset 11303 FLV stream advertising no audio in header. We'll warn only once for each FLV, expecting any further audio tag.

What's surprising about the second case (working run)
is that it works at all !! How can it work if it couldn't
find any video/audio frames in the initial probing ?!

This is trunk built against gstreamer version: 0.10.18.

Sandro Santilli <strk>
Project MemberIn charge of this item.

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by bjacques (Posted a comment)
  • -unavailable- added by strk (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 8 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 24 Oct 2008 10:43:22 PM UTCstrkStatusReady For Test=>Fixed
      Open/ClosedOpen=>Closed
    Fri 24 Oct 2008 01:33:55 PM UTCstrkStatusIn Progress=>Ready For Test
    Thu 23 Oct 2008 03:13:29 PM UTCstrkStatusNone=>In Progress
    Wed 22 Oct 2008 12:00:44 PM UTCstrkSeverity4 - Important=>5 - Blocker
      ReleaseNone=>trunk
      Assigned toNone=>strk
      SummaryTime dependent youtube/gst ?=>Time dependent youtube

    Back to the top


    Powered by Savane 3.1-cleanup1